Remapping zeropage/stack?

Chat about anything CX16 related that doesn't fit elsewhere
TomXP411
Posts: 1785
Joined: Tue May 19, 2020 8:49 pm

Remapping zeropage/stack?

Post by TomXP411 »



On 7/16/2020 at 3:43 AM, Lorin Millsap said:






Actually that’s no longer true. The banking is done without using the VIAs at all. It is now selected using latches shadowed at $00 and $01. This freed up the valuable VIA pins.





Sent from my iPhone using Tapatalk



Thanks... that actually makes a lot more sense, and it lines up with how Commodore designed the 6510. 

It's easier to remember, too. ?

(Also, I was wondering where you got all the free VIA pins for the User port. Now I know.)

StinkerB06
Posts: 74
Joined: Tue Jun 30, 2020 12:32 am

Remapping zeropage/stack?

Post by StinkerB06 »


Doesn't turning off $A000 to $BFFF result in a "257th" high-RAM bank though? I don't think it's necessary as there's already plenty of high-RAM, therefore we can have a bit to disable $E000 onwards.

This is useful if you want to override the kernal's IRQ/NMI handlers with your own, however it'd be quite problematic with the reset vector. I think you'll need it to jump to a low-RAM location with your code that resets both zero-page latches, and does a BRK to soft-reset the machine back to its READY prompt.

Lorin Millsap
Posts: 193
Joined: Wed Apr 29, 2020 6:46 pm

Remapping zeropage/stack?

Post by Lorin Millsap »

Doesn't turning off $A000 to $BFFF result in a "257th" high-RAM bank though? I don't think it's necessary as there's already plenty of high-RAM, therefore we can have a bit to disable $E000 onwards.
This is useful if you want to override the kernal's IRQ/NMI handlers with your own, however it'd be quite problematic with the reset vector. I think you'll need it to jump to a low-RAM location with your code that resets both zero-page latches, and does a BRK to soft-reset the machine back to its READY prompt.

I don’t know how you figure. Firstly the high RAM is controlled with $0000 and $0001, with $0000 controlling which of the 256 possible banks is currently selected. But in the previous setup disabling does not create a 257th possibility. It is the same as bank0.

As to injecting the IRQ and NMI handlers as far as I knew there is already an injection point located in RAM.


Sent from my iPhone using Tapatalk
User avatar
StephenHorn
Posts: 565
Joined: Tue Apr 28, 2020 12:00 am
Contact:

Remapping zeropage/stack?

Post by StephenHorn »



7 hours ago, StinkerB06 said:




Doesn't turning off $A000 to $BFFF result in a "257th" high-RAM bank though? I don't think it's necessary as there's already plenty of high-RAM, therefore we can have a bit to disable $E000 onwards.



This is useful if you want to override the kernal's IRQ/NMI handlers with your own, however it'd be quite problematic with the reset vector. I think you'll need it to jump to a low-RAM location with your code that resets both zero-page latches, and does a BRK to soft-reset the machine back to its READY prompt.



 


5 hours ago, Lorin Millsap said:






I don’t know how you figure. Firstly the high RAM is controlled with $0000 and $0001, with $0000 controlling which of the 256 possible banks is currently selected. But in the previous setup disabling does not create a 257th possibility. It is the same as bank0.



As to injecting the IRQ and NMI handlers as far as I knew there is already an injection point located in RAM.





Sent from my iPhone using Tapatalk



If you really want to clobber the kernal's IRQ handling entirely, you can set the ROM bank to $04 and then overwrite the 6502 instructions starting at $038B, being careful not to overwrite more data than what the existing BASIC handler already uses.

If you just want the lean-and-mean kernal handler that chooses between the BRK vector and the IRQ vector, set the ROM bank to zero and then overwrite $0314-$0315 with the address of your custom IRQ handler. This should be plenty fast for anyone who doesn't already know they need absolutely bleeding-edge performance because they're writing a line IRQ for a demoscene project and they absolutely need that extra 20-ish cycles.

Developer for Box16, the other X16 emulator. (Box16 on GitHub)
I also accept pull requests for x16emu, the official X16 emulator. (x16-emulator on GitHub)
BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

Remapping zeropage/stack?

Post by BruceMcF »



On 7/19/2020 at 5:41 AM, StinkerB06 said:




Doesn't turning off $A000 to $BFFF result in a "257th" high-RAM bank though? I don't think it's necessary as there's already plenty of high-RAM, therefore we can have a bit to disable $E000 onwards.



This is useful if you want to override the kernal's IRQ/NMI handlers with your own, however it'd be quite problematic with the reset vector. I think you'll need it to jump to a low-RAM location with your code that resets both zero-page latches, and does a BRK to soft-reset the machine back to its READY prompt.



The most useful for $A000 to $BFFF are separate read and write switches, so you can copy between High RAM segments without allocating 8K of Low RAM. For example, you have a text document in High RAM, with a linked list of High RAM segments. You want to open up space to insert some text, you turn on Low RAM $A000-$BFFF to write, and have a loop that reads the part of the segment past the split and writes it back to the same address. The switch banks, set the Low RAM $A000-$BFFF to read instead, and do the same loop again.

Now, the write part doesn't actually need a bit, there is no contention if both Low RAM and High RAM are selected for writes to $A000-$BFFF. What would be needed would be the bit to flip select during read from the High RAM to the Low RAM.

But the issue is doing it. The bit may be available in the ROM latch, but it might need more glue logic ... and lots of tricks to reduce the number of glue logic chips required won't work because you can't ladder the logic very deep, without introducing too much delay to the memory select. They've already added more glue logic to the board for the $0000/$0001 High RAM / ROM latches, but that brought a useful UserPort. Adding more for just a "nice to have" feature is harder to justify.

"Overriding the Kernal's IRQ/NMI handlers" seems like it is already an option, since the ROM is 32, 16KB segments in a 512KB flash ROM. Just copy what the other non-Kernal banks do for the interrupt vectors, read out the system ROM banks and patch them so your copy of the Kernel does what you want it to do and your copy of the other system banks uses your copy of the Kernel. System reset will put everything back to the system ROM blocks, and then if you have the autostart program set up, it can jump into your patched set.

That wasn't possible, before, with the 128KB Flash ROM, but it seems that would let you play around with the system ROMs without risking bricking the system. Just pull out the SD card and reset and it will start up in original ROM Basic.

 

Post Reply