I've got a question: are the '32 bit jumps' described in blog post implemented? If so - are there some preconditions to be met before they can be executed? When I try:
JSR somewhere (direct jump here)
it seems to just perform what 6510 would do.
From memory it needs to be first enabled via the Hypvervisor. I also don't recall off the top of my head if they are completely working.
Taking a look at the VHDL:
0. Enable with bit 2 of $D67D from inside Hypervisor.
1. It should be CLD / CLD / <JMP|JSR|RTS> to do the 32-bit addressed actions.
2. There might be a funny thing where you have to subtract $4000 from the 32-bit address for these operations, because they work internally using MAP-style mapping, which will add $4000 to the address at run-time.
But I don't know if I ever actually tested it.
Almost certainly not implemented in Xemu.
Ok, thank you for the information. I guess it will be safer to use MAP/EOM instead - especially that code I intend to put outside of the first 64K is not time critical nevertheless.
Well, if you test it on real hardware and it works, then it will be much easier than using MAP. MAP is the most horrible thing for almost every use-case: You lose all register contents, can't tell where you currently are etc.
Yes, this register usage is really pain in the... why didn't they simply fetch this data from memory (direct or indirect addressing)? Or maybe this was just a stopgap solution and they intended to develop something better.
It's hard to know, for sure. It might just have been the cheapest option in terms of silicon, an they figured that a pile of stack operations to conserve/restore registers was not too bad. In practice, CBM used absolute store/loads to save regs when context switching between KERNAL and DOS on the C65, which added a latency or probably 100 clock cycles, and which contributtes to slow load/save times on the C65's internal drive.
I have just migrated RAMTAS to external ROM, as a proof of concept, using MAP/EOM method:
- helper routines to map/unmap additional KERNAL_1 segment - mega65_map_helpers.s
- jumptable in the KERNAL_1 segment - 4000.mega65_jumptable_kernal_1.s (unfortunately we don't have a real linker; maybe someday...)
- RAMTAS routine itself - fd50.ramtas.s (in fact... it's possible to save 3 more bytes in the KERNAL_0 segment, at the cost of 2 bytes in KERNAL_1 segment by moving jmp map_NORMAL there, but such optimization might complicate things in the future, once more routines are moved to KERNAL_1).
I had to extend out build tool, so that it can be told (depending on the ROM layout and code segment) to ignore specified file or force it to be floating despite file name claiming otherwise. I will provide some developer documentation for this mechanism before the pull request. It should be possible to migrate code to ROM on a cartridge image in a very similar way.
Honestly, it does not look THAT bad - it should be possible to migrate a lot of code to external ROMs this way:
- various routines which are not time critical (like hardware initialization/reset; Mega65 has a lot of registers to reset with STOP+RESTORE)
- everything which is time consuming nevertheless (floating point routines - once we have them, byte transmission using standard IEC protocol, nearly whole tape loading code - with small modifications, etc.)
- certain new features (I hope to implement 80-column display for VIC IV someday)
We will have to warn Mega65 software developers to never call ROM routines with memory mapped-in, if they want to be compatible with feature-rich C64-compatible Mega65 ROM.
 I wonder if the DMAgic takes the mapping into account, or not. It should be possible to read a bunch of data into a buffer, and then DMA it back to proper place.
DMAgic ignores MAP status by design.