Open fusin92 opened 5 years ago
Well - actually, I'm not planning to reimplement the C65 mode at all. It's memory layout is undocumented (and, AFAIK, differes significantly between C65 ROM releases), and there is almost no native C65 software. Besides, it was probably designed with C65 in mind, while Mega65 is much more powerful. And, last but not least - manpower is scarce, we need to be reasonable.
My current plan: to have one BASIC/Kernal implementation handling two modes:
C64 compatibility mode: 1 MHz by default (can be changed using SLOW/FAST commands - these were implemented recently), chipset switched to VIC-II personality when entering this mode
Native Mega65 mode: 40 MHz by default, VIC-IV personality mandatory, identified by 2 or 3 magic bytes in the C64 screen link-table area (in short, C64 has a table telling whether the line is standalone, or a part of virtual 80-character line). In this mode the screen will be up to 80x50 characters, screen memory will be placed outside of the first 64KB RAM, and the C64 screen area will be reserved for BASIC/Kernal to provide additional BASIC commands and other goodies (any functionality requiring this memory will be disabled in C64 compatibility mode). Load address will remain exactly the same.
I'm planning the following ways to switch between modes:
This way the average Joe after starting the machine will enjoy the Mega65 features - but when he runs any legacy software (or even a software designed to detect C64/C65 ROM and act accordingly), we will automatically switch the mode.
"GO 64" / "GO 65" commands work properly now. SYS switches to C64 compatibility mode, to avoid this issue a "GO SYS" instead. "IF MEGA65 THEN" and "IF MEGA65 GOTO" can be used to check if running on MEGA65 build.
Still untested: whether loading below $0800 will switch to C64 compatibility mode (can't be tested right now due to IEC support problems, working on it).
Might be speaking out of turn here, but it seems Commodore BASIC traditionally used 2 letter vars for such things (ST, TI, etc.). MEGA65 seems inconsistent.
Jim
This is not a variable. It is a pure hack, only 'IF' directive checks for the 'MEGA65' character sequence. I wanted a possibility to detect Open ROMs MEGA65 build in a way that won't trash the LIST output of the CBM BASIC and is unlikely to cause any compatibility problems - CBM BASIC will see 'IF ME THEN', it will check that ME variable does not exist -> create it with value 0 -> evaluate condition to false.
BTW. Legacy C64 mode variable engine is limited to 2 characters (like C64 one) and it will stay this way for compatibility purposes. Native mode doesn't need the compatibility - most likely there will be much higher limit, and all the variables (maybe with the exception of temporary strings) will go out of the C64 memory area.
It may be a hack, but I sense that folks will expect it to be legitimized later:
print "MEGA65 Mode:";MEGA65 print "TI Value:";TI
So, if it's MEGA65 for all time, then you'll have to do more hacks later to make a more legit variable, or stick the disclaimer in that it will only work with IF (and what about other conditional constructs?). I know, no good deed goes unpunished, but I wanted to at least point it out. I think the idea is sound, just have my concerns about the implementation and wanted to ensure you knew.
Jim
The proper way would be:
10 IF MEGA65 THEN ME=1 20 PRINT "MEGA65 BUILD: "; ME
but the real intent is to be able to write something like this:
10 IF MEGA65 THEN GO SYS 2060 ; launches program in OpenROMs current mode
20 IF PEEK(...) = ... THEN SYS 2070 ; launches program in C65 native mode
30 SYS 2080 ; launches program in C64 mode
Someday I'll write a better description of the BASIC extensions ( https://github.com/MEGA65/open-roms/blob/master/doc/Extended-BASIC.md ) - right now this is everything too fresh, probably a lot will change in the future.
[edit] Open ROMs Kernal API is going to be compatible with C64 one (with some small restrictions/deviations in a MEGA65 native mode), but not with C65 Kernal. One reason is that C65 is built around banking (and bank concept), which is suboptimal in case of MEGA65, which has a way to access extended memory in a linear way.
[edit2] I'm not even sure if it is a good idea to provide TI and TI$ variables in the MEGA65 native mode. They are a leftover from VIC-20, already obsolete on C64 (which has abundance of timers in it's two CIA's, more precise than TI/TI$). And each 'special' variable means a small slowdown - it would be best to provide access to RTC the MEGA65 has. Even the memory area containing TI is a ****, as it stores variable in a big-endian format, making it impossible for the MEGA65 ROM to use INW to update it.
reading Pauls statement in mega65/net forum about the MEGA65 mode Basic came in mind to use some 'magic-byte', so the computer could automatically go into the mode needed by the program (64/65/mega). The place for storing the 'magic byte' is quickly found. It's the load adress stored in basic programmfiles, as we all know CBM-Basic uses different load adresses (basic start) in different versions. Would that be difficult to implement in the kernal? or the load & run routines?
don't misunderstand me, it's only a proposal, not a request. I thought it is a food idea.
Alas I'm not a programmer, only a user since early 80ies