Page 2 of 2

Remapping zeropage/stack?

Posted: Sat Jul 18, 2020 9:43 am
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.)


Remapping zeropage/stack?

Posted: Sat Jul 18, 2020 9:41 pm
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.


Remapping zeropage/stack?

Posted: Sat Jul 18, 2020 10:58 pm
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

Remapping zeropage/stack?

Posted: Sun Jul 19, 2020 4:49 am
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.


Remapping zeropage/stack?

Posted: Mon Jul 20, 2020 4:43 am
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.