IDEAS: just some ideas, nothing special ...
Closed this issue · 5 comments
This project sounds quite interesting! Just some ideas for the future: maybe allow alternative ROM builds with a bit different implementation what would give us less compatibility but more performance/features ... Like:
for BASIC, I never understood the behaviour of the CBM/MS basic interpreter to parse numeral values run-time, that's slow, there is even common tricks to store even simple values like "12" in variables and use them that way ... So in fact, there should be some token assigned for numeric literals which then holds the binary form of the number already, and not the petscii/ascii string.
In fact, it even goes wild, ie encode GOTO targets with memory address, thus it's MUCH faster to use GOTO/GOSUB (surely it needs extra care to maintain these in case of editing the program ...), as the interpreter needs to "walk through" the basic program to find the given basic line.
Or the way that BASIC searches variables by name, instead of using memory pointer, what (AFAIK) Atari BASIC does as well (so there it's possible to strip "symbol information" thus then it's kinda impossible to edit the program but it's another question). Also the two letter long variable name is kinda hmm "unfortunate" especially in a programming language where you don't have local variables etc, and everything is global ...
But these maybe more a "mega65-basic" rather than c64/c65 clean/free re-implementation of the "original" ones.
And for the kernal, a sane way to easily allow to "expand" known devices, ie like allow additional routines "hooked in" for other device numbers, for example to allow to add other ROM routines then to access the SD card directly for some selected device number, etc. Ideally it should be done than no need for hacking the "base ROM" too much every time (and anyway I think the routines wouldn't fit there ...)
Hello,
Good work spotting this repo :) I'll announce it more publicly soon, as for now, it is a bit of an open-secret that I am working on this.
Many of the ideas you have mentioned I have also been thinking about. I have already begun trading off perfect compatibility for sensible improvements, like allowing use of 60KB RAM for BASIC, instead of just 38KB.
Some of that other 4KB I will use for thinks like a line number cache for GOTO etc.
I also plan to have a cache of parsed expression values either indexed by source code address, or perhaps even replacing the expressions with a special token and floating point value bytes directly in the source code. I will probably do the first, because it will then remain file compatible with the C64.
As for the KERNAL allowing extra devices, e.g., for direct SD access on the MEGA65, this is actually likely the first disk access that will be implemented. Most likely on device 7, like the old 64NET system I wrote more than 20 years ago.
In short, I don't feel myself obligated to be perfectly compatible. Mostly just enough to LOAD, RUN and SYS start a game, is actually enough for probably 80% of software already.
So, maybe make separate issues for each of these things, and then we will close this combined issue?
Paul.
Hi, Well surly just close it, maybe it would be better to mail you these only as it does not fit too much with the purpose issues page, and also the topic is just to vague at these scale at least. Just I wanted to avoid sending you too much mails, I've already did maybe too much :)
Well, yes, compatibility is extremely hard ... There are mad things, ie programs coded in assembly but using the BASIC floating point routines to - let's say - create its sine table (so the exact locations of these routines, the "floating point accumulator" RAM area etc must be at the very same location), and who knows what else ... Some ASM tutorials for C64 even suggests that for setting the V flag, one should do a BIT operation on some "random" ROM (surely not random, but I mean that maybe not the very same value there with the open-roms ...) location which causes the V bit set (as there is no opcode for setting the oVerflow CPU flag bit directly). And similar madnesses ... But probably you're right, it's impossible to provide a 100% compatibility without 100% original ROM ... And hopefully these kinds of trick are just the minority of the software. And a user still can "install" the original ROM if it's a problem. ...
OK, I'll close this and "distribute" over multiple ones instead then. Surely, I can't mark them with a label, that's another thing, I guess only the owner(s) of the repo can do that.
Sounds like a plan. I will label them,