Will the old C64 approach to extending BASIC V2 with tokenised commands and functions still work?
I'm asking because IIRC from the C64 days the BASIC ROM was copied in to shadow RAM and then had a few JSR or JMP targets changed to allow for the processing of the new tokens by the BASIC parser and the program listing function. All without the use of a wedge to trap "@" characters here & there...
I guess this can be done by having RAM in a cartridge that can be seen by the ROMB latch and copying the BASIC kernel in to that RAM in the cartridge.
But not everybody is going to have access to or want to buy such a RAM cartridge...
Thanks in advance.
Extending the BASIC command & function set
-
Martin Schmalenbach
- Posts: 140
- Joined: Tue Jul 21, 2020 10:08 pm
-
desertfish
- Posts: 1123
- Joined: Tue Aug 25, 2020 8:27 pm
- Location: Netherlands
Re: Extending the BASIC command & function set
I think such an approach will be frowned upon, as it is going to heavily depend on the precise location of all routines and tables in the ROM - something which may change in a next version.
Much better is to just hook into the command parsing via exposed vectors and do it like a wedge.
Much better is to just hook into the command parsing via exposed vectors and do it like a wedge.
-
Martin Schmalenbach
- Posts: 140
- Joined: Tue Jul 21, 2020 10:08 pm
Re: Extending the BASIC command & function set
I guess this will always be the case. And realistically how often is the BASIC ROM going to be changed to the extent that existing core routines get moved? I wager it will be infrequent and I’ll cross that bridge if I come to it.
That being said you’re not wrong in pointing out the downside with my suggested approach.
In the grand scheme of things the use of tokens for the extra commands or parsing the complete text of the command instead is small relative to the code that will provide the functionality for the new commands. As I understand things it will be more of a challenge I think where new functions are to be added - getting the expression evaluator to work as required without the new functions being tokenised will be a major challenge to do elegantly. It can be done via the USR function by passing the text of the function name as a string that is the single parameter for USR() and parsing that string to determine the required functionality. Any additional parameters needed would follow the USR() text in a comma-delimited format… and I suspect some of this would still rely on routines in the BASIC ROM that aren’t exposed through a vector table.
That being said you’re not wrong in pointing out the downside with my suggested approach.
In the grand scheme of things the use of tokens for the extra commands or parsing the complete text of the command instead is small relative to the code that will provide the functionality for the new commands. As I understand things it will be more of a challenge I think where new functions are to be added - getting the expression evaluator to work as required without the new functions being tokenised will be a major challenge to do elegantly. It can be done via the USR function by passing the text of the function name as a string that is the single parameter for USR() and parsing that string to determine the required functionality. Any additional parameters needed would follow the USR() text in a comma-delimited format… and I suspect some of this would still rely on routines in the BASIC ROM that aren’t exposed through a vector table.