6502.org

(Might be worth noting that Acorn's BBC Micro's banking register is write-only - the OS keeps a copy in zero page so it knows what's going on.)

When I was writing memory management programs for the Apple II, I found keeping track of the bank number wasn't too difficult, but I understand your concerns.

I must say, the more I think about Jeff's "Ultra-fast Output" method, the more I like it. Being able to control those outputs from outside of I/O address space opens up some very interesting possibilities. Like a 64K memory map devoid of I/O address space, or, mapping any one of the three 16-byte I/O spaces into zero page "on demand". As a side note, writing code for I/O in zero page is kinda' fun. After studying the Acorn System-1 I re-assembled Sophie's 512-byte Monitor program for I/O in zero page and, IIRC, it shaved off something like 11 bytes.
Yes, the CLKGEN IC is a PIC microcontroller, as is the little 8-pin 16F18313 used to detect the single-cycle NOP fetch cycles.

Have fun. Good luck on your project.

Cheerful regards, Mike

Yeah, it's nice to be able save and restore. There are various approaches, offering different tradeoffs.

The BBC Micro solution Ed mentioned requires twice as much writing, as everything written to the (write-only) bank register must also be written to the image in memory to keep it current.

One way to beat the double-write business is to change the fact the bank register is write-only. To read it back all you need is to attach it to some unused bits of a VIA -- much as you plan to do now, except the VIA would be for reading only.

Of course the ultimate solution is an '816, which, upon interrupt and RTI, manages the save/restore of the entire 24-bit address transparently. But I admit there's educational value in doing things the hard way.

Edit: Thanks, Michael, for your thoughts on non-memory-mapped I/O. The 'C02 is an obvious candidate, as there are so many unused opcodes. But the '816 is also eligible, thanks mainly to WDM -- a two-byte NOP whose 8-bit operand is completely up for grabs.

-- Jeff

Did you run into any problems with interrupts triggering between the write to the bank register and to zero page?

I am not a person with Beeb expertise. However, I don't see a problem as long as the code always writes to the memory image first then the actual bank register second (not the other way around). If an interrupt intervenes then the save-restore code associated with the ISR and RTI will only harmlessly "restore" the value which is about to be written.

Indeed it does

Examples of potential pitfalls are convoluted, but updating the register and its memory copy should always be done under interrupt disable (although an occurring NMI will remain a potential problem even then). There is no formally 'safe' way of updating the pair without it.

Citation needed! That would be a very interesting example.

I think John is wrong on this (but am happy to be proven otherwise with an actual example).

On the Beeb, the established pattern is to always update the shadow first (&F4) before writing to the latch (&FE30).

If an interrupt does happen between the two instructions, all that happens is that the OS ends up restoring the "new" bank from &F4 before returning, making the write to the latch at &FE30 superfluous.

You'll find this pattern used in OS 1.20:
https://acorn.huininga.nl/pub/docs/sour ... 201629.asm

Just search for rom_select

Dave

I'd say it's pretty obvious that if the register and its OS copy are not updated atomically, e.g. an interrupt occurs after updating only one of the two, then the interrupt routine can no longer tell which ROM is selected. This may not matter if it doesn't need to know. But it certainly does matter if it does.

E.g. interrupt routine relies on some data or code in some specific ROM X, and, for efficiency, only selects ROM X temporarily if it's not already selected. If the currently selected ROM is Y != X, and the foreground switches to X, then if the OS copy has been updated to X but not the register, or vice versa : kaboom.

Convoluted ? Yes. Impossible ? No. Don't assume what you don't need to. You're rarely in complete control of both foreground code and background code.

Thanks - that is an interesting example.

Well, another day, another computer design from Alsi....

This is the schematic of the system that all this decoding logic was in aid of. Its still called the Nimbot, and is derived from what you have seen previously, but I decided that I wanted to go for something a bit simpler (in the sense of easier to route) but also more general purpose. I still plan to make a games machine at some point, but I think it'll probably be based on this design rather than the previous one. I am much happier with this one overall.

I am unsure whether to expand the I/O Board header (P3) so that I can use this same logic board for both a games machine and a general purpose one, swapping out only the I/O board (the I/O board would have the gamepad, screen, and sound generation circuitry on it for a games device and a character LCD, keypad and buzzer for a non-games device) or whether to KISS as it is and make the games device have modified logic board.