It's not only U64 - U2 and U2+ have the very same problem.
Hallo Besucher, der Thread wurde 5,4k mal aufgerufen und enthält 43 Antworten
letzter Beitrag von markusC64 am
16k bzw. 24k Kernal
- markusC64
- Erledigt
-
-
FeralChild I just made a Prrof Of Concept for the 24k kernal working. Quite final, only the conditions to prevent accidental bank switching could be strengthened.
Well, until Gideon has rewritten Cartridge Subsystem, those enlarged kernals has to be started from a CRT file.
I tried with one containing 3 copies of the CBM kernal, 1st modified to have black border, 2nd modified to have white border and 3rd modified to have red border.
And I can switch bank sucessfully with this basic code:
or in assembler (untested):
Of course "ldx" or "ldy" or "cmp" can be used instead of "lda". The main thing is that the memory access takes place.
For that purpose, the adresses of the power on message at $e460-$e49f are treated specially. If they are accessed in the above order with no other access in between, banking switch is done. If they are accessed in any other order, no banking switch is done.
Current POC does not detect if access is to rom or to ram below ram - but kernals can be developed and tested with the current POC.
Edit: Accessing a memory address more then 1 time, but in the above order is decided to be ok on purpose, since it makes some things easier.
Edit 2: If changing bank from outside of kernal, you should do the very first "lda" twice. Basic 2.0 is doing that already, so I do not need it in my Basic Code: LDA (ZPAddr),Y with Y=0 is done. And that Instruction 1st loads what the ZPAddr points to and then loads what results after adding Y. So recommandation is met in Basic Sample.
That is to make sure that the right HIRAM signal is cached before entering the sequence. Implementations are allowed to use the cached signal from the kernal access before.
Edit 3: It might be possible that the Ultimate 64 will only offer 2 banks once it's implemented by Gideon at a later time.
-
OK, good to know. Should be usable, although there are some challenges:
1. IRQ and NMI interrupts redirectors will be needed in the additional bank(s).
2. Various pieces of code in both Kernal banks will have to be aligned; the current Open ROMs build system (we have quite a sophisticated tool to determine routine placement - to stay compatible in key places, and to fill-in remaining gaps in efficient way) does not support this, it will have to be extended.
3. I'll probably have to be careful what the Open ROMs build system puts into $e460-$e49f range - it would be best not to waste the whole area.
Background: if you start the Ultimate 64 (or MEGA65) Open ROMs build, you'll see 51199 BASIC BYTES FREE - because the BASIC memory ends at $cfff, not at $9fff. Therefore, $e000-$e4d2 is a very precious ROM area, as I enforce memory access subroutines to go there - they typically work in a scheme:
- unmap the $a000-$bfff BASIC ROM
- do in the RAM whatever is needed
- map the ROM again
This way I can provide 12KB more RAM to BASIC, and the performance penalty is likely to be very small.
-----
Is the test firmware available to download somewhere? How do I construct this special CRT file? Nevertheless, it will take some time before I can start working on this, I would like to finish the current 'sprint' of MEGA65 internal DOS improvements first. -
1. IRQ and NMI interrupts redirectors will be needed in the additional bank(s).
If space makes it possible, you can duplicate IRQ & NMI Routines.
2. Various pieces of code in both Kernal banks will have to be aligned; the current Open ROMs build system (we have quite a sophisticated tool to determine routine placement - to stay compatible in key places, and to fill-in remaining gaps in efficient way) does not support this, it will have to be extended.
Sure. But that's quite independent of bank switching logic - i. e. the classic one using the sense line from tape would have the same need for alignment.
3. I'll probably have to be careful what the Open ROMs build system puts into $e460-$e49f range - it would be best not to waste the whole area.
I see. I think I also see a "workaround": The pattern chosen is less than fetching one opcode at a time. So you could probably execure any code there, and do a JSR <adreessOfBankSwitchingSubroutine> there, which can be outside of that range.
PS: Above discussion brought me to the fact that 16 banks are possible for the bank switching logic, but U2+ only offers 3 or 2 (I think it's valid that the U2+ may offer one more than the U64, because we get it for free in that piece of hardware).
Anyway, Gideon asked me to maintain this patch - he 1st wants to see such a kernal in public that is used before supporting U64, too. So for the time being just for U2+. And if we find someone helping, it could possibly be implemented for the Easyflash 3.