BASIC: intercepting USR and CALL
Jon Abbott (1421) 2651 posts |
I’ve been looking at incepting these so the code they call can be made 32bit compliant by ADFFS, from looking at the BASIC source it looks like the only solution is to move the BASIC module to RAM and modify the BASIC module code – a very nasty hack that isn’t forward compatible. Before I do that, I thought I’d best check here to see if there is a legal way of intercepting them. |
Steve Drain (222) 1620 posts |
If you want to run the BASIC and code as they stand, but intercept CALL in order to modify the code before running it, I think you would have to modify the BASIC module. For a simple break-out you could once use ROMPatch [correction] on the rom module, but I have no idea of its status on RO5. If you can modify the BASIC or code first, you might make either jump to your modifying program. I have long thought about more flexible CALL and USR for Basalt, which works by modifying the BASIC program at runtime. |
Jon Abbott (1421) 2651 posts |
Ideally it needs a service call, in the same way Service_ModulePreInit was added to give the opportunity to patch modules. I didn’t have a problem with modifying ROM based modules on RO3.1 to back port OS_CreateDynamicArea, but do with modules in an OS version that’s being actively developed – it doesn’t seem right! Anyhow, the likelihood of BASIC having extensions to add support for 26bit code is next to zero, so I guess I have no choice but to modify the module. I just need to make it as forward compatible as possible so it works with BASIC as it’s revised. |