512K RAM/ROM

[Robb Bates]

Wayne/Spencer,

Looking at the schematic for the 512k RAM/ROM card...

Wondering why the A14 bit is going through the 4 bit register chip instead of being directly tied to the RAM and ROM.  If the banks that are swapped are always 32k.  Wouldn't it make more sense to not have to fiddle with that line and only set the bank by A15-A18?

Robb

[Bill Shen]

While RomWBW always uses 32K banks, other non-RomWBW OS may need 16K banks, so the flexibility of 512k RAM/ROM board to do 16K banks is useful.  In fact, I’ve modified my K80W design to have 16k banks options at the request of an user.

Bill

[ladislau szilagyi]

Hi Robb, hi Bill,

first of all, thank you again Bill for your effort to modify your K80W design, I really need those 16KB banks in order to adapt HiTech C, the TE editor, and other pieces of software, for K80W...

Robb, while it may seem that a design which uses 32KB ROM/RAM banks is good enough (as Wayne's RomWBW prove it...), in other cases, the 16KB ROM/RAM design might be a must for some software components. 

Why? Because it allows a more versatile use of the CP/M memory space, and this is absolutely important when you deal with large software apps (>32 KB) which require also large RAM memory space in order to store/load various data (e.g. a C compiler, or a text editor which keeps the edited text in the RAM memory...)

More precisely, I needed to "reserve" RAM, in the CP/M's TPA space, in order to use-it as a buffer for a "memory management" software component,  to move bytes between the "main" 64KB RAM and the "extended" 64/512KB RAM provided by various available hardware modules. But, 32KB banks are too big, it is very difficult (but not impossible - see Wayne's RomWBW) to handle them, while 16KB banks might be "mapped" more easily (at 0000H, or 4000H, or 8000H), according to the specific memory map of that particular CP/M app.

That's why, although I am aware that hardware that implements 16KB banks is more complicated, compared to the 32KB banks version, I always prefer the 16KB banks alternative.

Again, that's only my personal opinion...

thanks,

Ladislau

[Sergey Kiselev]

There is a bit of history here ;)

- The original system supported by RomWBW was the N8VEM SBC that used 32 KiB/32 KiB memory split, with the upper 32 KiB of the CPU address space always mapped to the top of physical RAM (e.g. 480 KiB - 512 KiB of the 512 KiB memory chip)

- The N8VEM SBC V2 had an improvement, where it was possible to configure it for 48 KiB/16 KiB memory split using jumpers. If I recall correctly it was made to support the M/PM OS. RomWBW still uses 32 KiB/32 KiB memory split on this board.

- When I designed Zeta SBC V2 (Zeta SBC V1 had the same memory implementation as the original N8VEM SBC), I wanted a more flexible MMU to support FUZIX, which requires banked memory, e.g. 16 KiB * 4 or 8 KiB * 8 configuration. Therefore, I implemented 16KiB * 4 configuration using page registers. RomWBW on this hardware still uses 32 KiB/32 KiB split by mapping two consecutive pages to the lower 32 KiB of the CPU address space, and two consecutive pages from the top of the physical RAM to the upper 32 KiB.

- Scott Baker used Zeta SBC V2 MMU design in his RC2014 compatible memory board.

- Spencer's 512k ROM 512k RAM Module design is largely based on the Scott Baker's design.

Of course this MMU design has advantages and disadvantages: Main disadvantage that it is a bit more complicated. Main advantage that it is flexible. It is also extendable to more memory. With the 4x8 register file it is possible to address up to 4 MiB (I don't think any system does that).

There are also "hacks" like Steve Cousins SC714 module,  which uses the same MMU I/O ports as the 512K ROM / 512K RAM module, but essentially has a 32 KiB / 32 KiB split. It ignores the lowest bit of the I/O port address. It also ignores the lowest bit of the data written to the page register. The upper 32 KiB of the CPU address space are always mapped to the top of the physical memory. So essentially instead of a 4x8 page register, it has a single 5-bit register to select the page for the lower 32 KiB of the CPU address space.

Best regards,

Sergey

[Alan Cox]

16K is also the minimum you need to do "large model" programming on Z80 where you work with 24 or 32bit pointers akin to segment registers and the "segment" is the MMU page. Does require you can pack the data and code nicely so that no single object overlaps a boundary unlike with 8K pages but it is doable.

Data is then accessed by stuffing bits 23-16 in the MMU reg and the low word is set to 0x8000+offset

Code needs a little helper for calls in the common/stack but you can either do it the same way or just concatenate all the functions (which is easier) across two segments sequentially so that any function under 16K long is always contiguously mapped. For C it works really well because your locals are stack relative (so always in C000-FFFF) and cheap to access and you can track the page for globals for efficiency. Pointer dereferences are rarer, and maths on pointers is still cheap as you don't allow an access to cross the boundary (akin to 8086 large v huge model)