After putting down the initial design for the ALU, I believe that its time to consider how to organise the memory of the system. Especially in view of the design goal of using a RAM based register-to-register design, like it was used in the Texas Instruments TMS9900, which itself was a single chip implementation of TI’s TI-990.
Registers
The first consideration will have to fall to the 16-bit registers, of which there will be 32.
General Register Layout
| R00 | R01 | R02 | R03 | R04 | R05 | R06 | R07 |
| R08 | R09 | R10 | R11 | R12 | R13 | R14 | R15 |
| R16 | R17 | R18 | R19 | R20 | R21 | R22 | R23 |
| R24 | R25 | R26 | R27 | R28 | R29 | R30 | R31 |
| Register | Register Label | |
|---|---|---|
| R0 | Z | The Value Zero |
| R22 | F | Flag Register |
| R23 | SP | Stack Pointer |
| (R24,R25) | G | General Purpose 32 bit Register |
| (R26, R27) (R28, R29) | X, Y | Registers for Indirect Adressing |
| (R30, R31) | PC | Program Counter |
Aside from the Special Registers, all other registers are general use. Somewhat special are the Flag Register, the Stack Pointer and the Program Counter, which are actually implemented into the general logic of the CPU, but need to be saved back into the RAM based registers if the CPU encountered a context switch into another register context bank.
While the CPU design is to use 24 address bits, the Stack Pointer is only 16 bit wide, because the stack is meant to be of a fixed length in a fixed address space and those 16 bit are a bit overkill for the size of the stack.
Register Context Banks
Speaking of Register Context Banks, there is also the general design for those. Thought that is simple. There are meant to be 32 banks of those registers.
With 32 times 32 registers, that means that the Register Context Banks take up 1kwords of memory.
Special Register Banks
| Register Bank 0 | Main OS Register Bank |
| Register Bank 1 | Interrupt Hander 1 Bank |
| Register Bank 2 | Interrupt Hander 2 Bank |
| Register Bank 3 | Interrupt Hander 3 Bank |
| Register Bank 4 | Interrupt Hander 4 Bank |
| Register Bank 5 | Interrupt Hander 5 Bank |
| Register Bank 6 | Interrupt Hander 6 Bank |
| Register Bank 7 | Interrupt Hander 7 Bank |
Of these 32 general use register banks, the first eight are special use. Register Bank 0 is meant to be used when the CPU is reset and initialised, running things such as Monitor and OS routines and the like.
The next seven register banks are hard wired to be used for interrupts. Acting as the interrupt handers for the CPU, they can easily be initialised during boot-up, setting the initial Program Counters for each interrupt separately.
The Interrupt Hander Banks will be separate from any context switching done by the Monitor or OS, disabling any method used to switch between contexts outside of interrupt handling.
Stack Pointers
Then of course there is the question how large the Stacks for each Register Context should be, where I am leaning towards 1kwords, which would make the entire stack 32kwords in size.
Reserved Memory Space
Since the entire design of the minicomputer is meant to be memory-mapped IO, this means that at least for some IO, there should be some reserved memory space. Again, I am leaning towards a size of 1kwords or maybe 2kwords, which would allow for quite a few devices to be added into the system.
It is certainly going to be used for any integrated character LCD and mini keyboard, as well as serial IO and mass storage.
Monitor/OS ROM
Now, there is the question of the Monitor or OS. I initially thought about using either an EPROM or an EEPROM to use for this, but then I remembered that Flash ROM are thing and that there are small Flash ROM ICs available in DIP packages, in either 1Mbit, 2MBit or 4Mbit, which would mean two of those ICs combine to 128kwords, 256kwords or 512kwords.
Here, I am leaning towards 128kwords.
General Memory Layout
Now the question is how the memory should be layed out.
Should all the above reside within the higher RAM or the lower RAM? I am leaning towards locating all these special use memory in the upper RAM, which would make address logic a bit easier.
Additionally, the monitor would reside in the lower RAM area, so that the CPU can be initialised with a memory of 0x000000 on a reset.
For any other memory, I certainly plan to use conventional SRAM ICs, though I recently learned there are such things as Ferromagnetic RAM ICs, which are pretty much core memory in IC form. More expansive than normal SRAM, but oh so very tempting to use for a more ‘authentic’ minicomputer experience.
Memory Layout
| 0x000000 – 0x1FFFFF | Monitor/OS |
| 0x200000 – 0xFF77FF | RAM |
| 0xFF7800 – 0xFF7BFF | Memory Mapped IO |
| 0xFF7C00 – 0xFFBFF | Stack Area |
| 0xFFFC00 – 0xFFFFFF | Register Context Banks |
Conclusion
I think I have made a relatively good initial design for the memory of the DWMC-16, which is open for more in-depth design later on.
An initial memory layout for the first few uses of the DWMC-16, I can see the use of the 128kword Monitor/OS in Flash, with an additional 128kword of RAM in the upper part of the memory, where all the important memory stuff resides.
Especially funny is that my discovery of Ferromagnetic RAM was me doing a quick search on Reichelt on the size of parallel Flash ROM ICs and seeing serial FRAM ICs, followed by looking whether there are parallel FRAM ICs.
