4 ms·

You could maybe try implementing bank switching to handle more memory. This does make code more complex but it should be possible to use boilerplate to access a

by zaarn 5y ago

You could maybe try implementing bank switching to handle more memory. This does make code more complex but it should be possible to use boilerplate to access arbitrary memory. IIRC from when I toyed with making CPUs, a bank switch is implementable as a single extra register which simply drives the upper 16bit (or less) of your address line. It will probably be fairly slow.

jstanley 5y ago
Yes, that would be a good way to go. In practice I think bank-switching would be of great value even if none of the programs use it directly: currently context-switching is implemented by dumping the running process to disk and loading the new process from disk. If I had bank-switching then I could context switch much more rapidly by just giving each process its own bank(s) of memory. It's slightly more complicated than just having 1 register to drive the upper bits of the address, because if you just blindly switch on some of the upper bits of the address then suddenly all of your instructions go missing and the CPU starts executing whatever arbitrary bytes happen to be in memory. So you'd want some way to switch out just the parts you want to store data in, while leaving all your code still mapped in. I have an RC2014 with the bank-switching memory expansion. The RC2014 handles it by splitting memory into 4 (I think?) "pages" of 16K each, and allowing you to select which bank backs each page separately.
- zaarn 5y ago
  I believe the Apollo Guidance Computer used a hardwired lower segment that always points to Bank 0 and one for Bank 1. Then a few freely changeable segments. I also recall some systems where it works just as described, but you had to be incredibly careful about bank switching and IIRC there was a dedicated instruction to write the bank register and program counter register at the same clock cycle.

by zaarn 5y ago

jstanley 5y ago

Yes, that would be a good way to go. In practice I think bank-switching would be of great value even if none of the programs use it directly: currently context-switching is implemented by dumping the running process to disk and loading the new process from disk. If I had bank-switching then I could context switch much more rapidly by just giving each process its own bank(s) of memory. It's slightly more complicated than just having 1 register to drive the upper bits of the address, because if you just blindly switch on some of the upper bits of the address then suddenly all of your instructions go missing and the CPU starts executing whatever arbitrary bytes happen to be in memory. So you'd want some way to switch out just the parts you want to store data in, while leaving all your code still mapped in. I have an RC2014 with the bank-switching memory expansion. The RC2014 handles it by splitting memory into 4 (I think?) "pages" of 16K each, and allowing you to select which bank backs each page separately.

zaarn 5y ago
I believe the Apollo Guidance Computer used a hardwired lower segment that always points to Bank 0 and one for Bank 1. Then a few freely changeable segments. I also recall some systems where it works just as described, but you had to be incredibly careful about bank switching and IIRC there was a dedicated instruction to write the bank register and program counter register at the same clock cycle.