Jump to content
Andre

Remapping zeropage/stack?

Recommended Posts

Sorry I'm late to the game, I am wondering why the zeropage and/or stack cannot be remapped to a different memory location (except I have overseen something) like e.g. in the C128.

I would make things like transient programs, or even multitasking so much easier, especially as the X16 is supposed to be 8 times faster than the old CBMs.

Thanks

Share this post


Link to post
Share on other sites
Sorry I'm late to the game, I am wondering why the zeropage and/or stack cannot be remapped to a different memory location (except I have overseen something) like e.g. in the C128.
I would make things like transient programs, or even multitasking so much easier, especially as the X16 is supposed to be 8 times faster than the old CBMs.
Thanks

Neither can be relocated under the current model.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
22 minutes ago, Lorin Millsap said:


Neither can be relocated under the current model.
 

That's what I noticed. So has this been discussed as an option? If so, what was the rationale to exclude this feature?

Share this post


Link to post
Share on other sites
That's what I noticed. So has this been discussed as an option? If so, what was the rationale to exclude this feature?

Because it wasn’t excluded. It would have to be implemented. Those are cpu functions and the X16 doesn’t have a MMU.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
5 minutes ago, Lorin Millsap said:


Because it wasn’t excluded. It would have to be implemented. Those are cpu functions and the X16 doesn’t have a MMU.
 

The X16 remaps an 8k window of RAM and a 16k window of ROM in the upper area. Remapping e.g. the lowest part could work similarly even without an MMU.

But I understand, someone has to implement it.

Share this post


Link to post
Share on other sites
The X16 remaps an 8k window of RAM and a 16k window of ROM in the upper area. Remapping e.g. the lowest part could work similarly even without an MMU.
But I understand, someone has to implement it.

Well short answer is it doesn’t have it. Technically remapping and banking are not the same thing. And remember the X16 is supposed to be simple.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

Implementing it is a problem because address decoding and banking (the stuff that's handled by the PLA in C64) is currently done by discrete logic on the motherboard (a handful of off-the-shelf electronic components). Remapping the stack and/or zeropage would require even more logic and a major overhaul of the motherboard layout. Eventually it would be easier to use the same sort of hacks that are used for PLA replacements: EPROM or another FPGA. Not sure it's realistic at this point in the development of the machine.

  • Like 1

Share this post


Link to post
Share on other sites

This would have been easy to do with a 65816, and it would have even made multitasking possible. But the 6502 simply does not have the hardware to remap Zero Page, and one of the design goals for the CX16 was to KISS. 

The banking logic in the 8K upper memory space is done by manipulating the address pins of the 512K (or 2MB) RAM modules with one of the VIA chips. The lower 13 bits come straight off the CPU's address bus, and the upper 8 bits are selected using the VIA parallel port. 

To do the same thing with Zero Page would require more chip select logic, additional memory chips, and another VIA manage the bank selection... or a custom MMU, like Commodore built for the C128. Since either option would be more expensive, I can see why they left that out. 

 

 

Share this post


Link to post
Share on other sites
This would have been easy to do with a 65816, and it would have even made multitasking possible. But the 6502 simply does not have the hardware to remap Zero Page, and one of the design goals for the CX16 was to KISS. 
The banking logic in the 8K upper memory space is done by manipulating the address pins of the 512K (or 2MB) RAM modules with one of the VIA chips. The lower 13 bits come straight off the CPU's address bus, and the upper 8 bits are selected using the VIA parallel port. 
To do the same thing with Zero Page would require more chip select logic, additional memory chips, and another VIA manage the bank selection... or a custom MMU, like Commodore built for the C128. Since either option would be more expensive, I can see why they left that out. 
 
 

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

Share this post


Link to post
Share on other sites
Posted (edited)
On 7/16/2020 at 6:51 AM, Andre said:

The X16 remaps an 8k window of RAM and a 16k window of ROM in the upper area. Remapping e.g. the lowest part could work similarly even without an MMU.

But I understand, someone has to implement it.

It actually doesn't REmap anything. Those windows are hardwired. An address in $C000-$FFFF triggers the chip select for ROM, the lower 14 bits are bused to the CPU address bus, the upper 5 bits are connected straight to the ROM segment latch. An address in $A000-$BFFF triggers what seems likely to be a 2-4 active low fanout from the upper two bits of the RAM segment latch, the lower six bits of the RAM segment latch are connected directly to the appropriate address lines of the SRAM, the bottom 13 bits are bused to the CPU address bus.

Each additional window is more glue logic and more chips and a bigger BOM.SUPPOSE you had a 2-4 fanout that is selected by A15=1, than combining the top two selects gives you the ROM select, the second select is directly the High RAM fan-out select (so both of those select ladders are only two deep), and the first select line can select the detect for the I/O page when A8-A13=1.
Now an entire additional detection has been set up for writing to $0000 and $0001, in the other half of the address space (those can be blind latches, because the RAM still stores the data).

Not only would detecting page zero and page 1 reads AND writes add direct additional complexity, you'd need somewhere to put it. AND you'd need redirect the physical address to one of the areas of RAM covered over (the I/O page, the High RAM or the ROM window). AND you'd need to protect that part of Low RAM from being overwritten when accessing that Window.

That extra physical design just so people don't have to learn how to use BASE,X and BASE,Y and (BASE),Y stacks probably doesn't seem worth the extra trouble.

If the unused three bits in the ROM register latch were used for anything, rather than remapping the zero and one page, I'd prefer if they turned off the $9F00-$9FFF, $A000-$BFFF and $C000-$DFFF selects and allowed the Low RAM "underneath" to be active for reads as well as writes ($E000-$FFFF ought to be left alone, since the interrupt vectors are at the top of the ROM space, plus there are only three bits to spare).

 

Edited by BruceMcF

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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.

 

Edited by BruceMcF
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use