DWMC-16: Memory Considerations – Deprecated

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.


The first consideration will have to fall to the 16-bit registers, of which there will be 32.

General Register Layout


RegisterRegister Label
R0ZThe Value Zero
R22FFlag Register
R23SPStack Pointer
(R24,R25)GGeneral Purpose 32 bit Register
(R26, R27)
(R28, R29)
X, YRegisters for Indirect Adressing
(R30, R31)PCProgram 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 0Main OS Register Bank
Register Bank 1Interrupt Hander 1 Bank
Register Bank 2Interrupt Hander 2 Bank
Register Bank 3Interrupt Hander 3 Bank
Register Bank 4Interrupt Hander 4 Bank
Register Bank 5Interrupt Hander 5 Bank
Register Bank 6Interrupt Hander 6 Bank
Register Bank 7Interrupt 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 – 0x1FFFFFMonitor/OS
0x200000 – 0xFF77FFRAM
0xFF7800 – 0xFF7BFFMemory Mapped IO
0xFF7C00 – 0xFFBFFStack Area
0xFFFC00 – 0xFFFFFFRegister Context Banks


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.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.