MEMOrizer

"The definition of dangerous is a software engineer with a soldering iron"
   --- Hardware engineer

Not sure if I will proceed with this. The thing is, the REMEMOrizer approach looks to have less soldering, to be cheaper, and to be able to provide more functionality.

Why MEMOrizer?

Many MTX owners don't have a FDX, HDX or SDX, and so have no real access to random access storage. As a result they must use cassette tapes (or CD players). MEMOrizer is a potential alternative, allowing MTX owners to load their favorite games in seconds, and even save data.

MEMOrizer would be a hardware add-on to be inserted into a Memotech MTX512, which would provide it with memory based storage, which appears as disk.

It aims to be as simple (hardware and software), small, and cheap as possible.

The basic idea

MEMOrizer would plug into the Z80 socket on the motherboard, and the Z80 chip plug into it. In this way, it would gain access to all the signals visible to the Z80, and avoids needing to be connected either end of the MTX motherboard. This is handy, as I have peripherals (SDX and RS232 card) soldered to mine. It can therefore be present even if you have other peripherals plugged in.

When adding a persistent storage solution to the MTX, access must be provided to the hardware which will hold the data, and also software must be provided giving access to that data. The software ideally needs to include a boot ROM, and a BASIC ROM providing USER LOAD and similar commands to MTX BASIC.

In the case of the SDX add-on, the main hardware is the FDC chip. In older SDXs, a BASIC ROM is provided in ROM page 3. In later SDXs, a boot ROM is provided in ROM page 4 and a BASIC ROM is provided in ROM page 5.

MEMOrizer would provide both software and customer data from memory chips, visible through two ROM pages.

The MEMOrizer board would have three large sockets. One would have the right pinouts for a 2MB EPROM. Two would have the right pinouts for a 2MB NVRAM. You'd not be required to populate all of these. At any one time, at most two of them would be visible to CP/M and only one would be visible to MTX BASIC.

There would be a jumper block next to each socket which connected the socket to 5V, /DRIVEB chip-enable, or /DRIVEC chip-enable. Only one socket is allowed to be jumpered to each chip-enable. Other sockets must be jumpered to 5V.

Each chip is considered broken into 128 16KB "banks". Whichever bank is selected would appear as two 8KB blocks, visible in two 8KB ROM pages. Bank 0 holds images of the ROMs.

The MEMOrizer boot ROM and the low 8KB of each bank will appear in ROM page 2 or 6, as chosen by a jumper. This is to allow you to configure the MEMOrizer boot ROM before or after the SDX boot ROM in ROM page 4, in case you have this installed also. I am pretty confident the first boot ROM found will be booted.

The MEMOrizer BASIC ROM and the high 8KB of each bank will appear in ROM page 3 or 7, as chosen by a jumper. This is to allow you to configure the MEMOrizer BASIC ROM before or after the SDX BASIC ROM in ROM page 3 or 5, in case you have it installed also. Note that you can't use ROM page 3 if you have the older type of SDX which will also use ROM page 3. Note also that you can't use ROM page 7 if you have the NODE ROM installed.

Signals

A table of signals on the MEMOrizer board :-

Signal Description
BRESET Z80 /RESET output, input to IOBYTE and BANK registers
BRD Z80 /RD output, input to EPROM /G and input to NVRAM(s) /R
BWR Z80 /WR output, input to NVRAM(s) /W, input to port decode logic
BMREQ Z80 /MREQ output, input to ROM page decode logic
BIOREQ Z80 /IOREQ output, input to port decode logic
BM1 Z80 /M1 output, input to port decode logic
BA15-0 Z80 A15-0 output, input to port decode logic, input to ROM page decode, EPROM and NVRAM(s)
BD7-0 Z80 D7-0, input to IOBYTE and BANK registers, connected to EPROM and NVRAM(s)
BWRIOBYTEOutput of port decode logic /WRIOBYTE, input to IOBYTE register (latches on rising edge)
BWRBANK Output of port decode logic /WRBANK, input to BANK register (latches on rising edge)
BRELCPMH Output of IOBYTE register RELCPMH (0=ROM enable mode, 1=CP/M mode)
BP2-0 Output of IOBYTE register P2-0 (ROM page value)
BR3-0 Output of IOBYTE register R3-0 (RAM page value, not used)
BB7 Output of BANK register B7 (0=drive B:, 1=drive C:), input to ROM slot decode logic
BB6-0 Output of BANK register B6-0 (bank number, 0-127), input to EPROM and NVRAM(s) addressing
BDRIVEB Output of ROM page decode logic /DRIVEB, input to an EPROM or NVRAM /E (which is chosen by jumper)
BDRIVEC Output of ROM page decode logic /DRIVEC, input to an EPROM or NVRAM /E (which is chosen by jumper)
ROMPOS1 Output of jumper, input to ROM page decode logic (0=page 2, 1=page 6)
ROMPOS2 Output of jumper, input to ROM page decode logic (0=page 3, 1=page 7)

Equations

We need an IOBYTE register (must be at port 0x00) and a BANK register (which we choose to put at port 0x80) :-

WRIOBYTE = /IORQ * /WR * /M1 * /A7 * /A6 * /A5 * /A4 * /A3 * /A2 * /A1 * /A0
WRBANK   = /IORQ * /WR * /M1 *  A7 * /A6 * /A5 * /A4 * /A3 * /A2 * /A1 * /A0

We need to enable the memory chips when a memory request occurs, we are in ROM enable mode, when the ROM page register is a particular value, which corresponds to the ROM position jumper, and when memory accesses occur in the paged ROM part of the address space. Depending on the top bit of the BANK register, we want to enable drive B: or C: :-

DRIVEB  = /MREQ * /RELCPMH * /P2 *  P1 * /P0 * /ROMPOS1 * /A15 * /A14 * A13 * /B7
        | /MREQ * /RELCPMH *  P2 *  P1 * /P0 *  ROMPOS1 * /A15 * /A14 * A13 * /B7
        | /MREQ * /RELCPMH * /P2 *  P1 *  P0 * /ROMPOS2 * /A15 * /A14 * A13 * /B7
        | /MREQ * /RELCPMH *  P2 *  P1 *  P0 *  ROMPOS2 * /A15 * /A14 * A13 * /B7
DRIVEC  = /MREQ * /RELCPMH * /P2 *  P1 * /P0 * /ROMPOS1 * /A15 * /A14 * A13 *  B7
        | /MREQ * /RELCPMH *  P2 *  P1 * /P0 *  ROMPOS1 * /A15 * /A14 * A13 *  B7
        | /MREQ * /RELCPMH * /P2 *  P1 *  P0 * /ROMPOS2 * /A15 * /A14 * A13 *  B7
        | /MREQ * /RELCPMH *  P2 *  P1 *  P0 *  ROMPOS2 * /A15 * /A14 * A13 *  B7

Chips

The MEMOrizer plugs into the Z80 socket and the Z80 plugs into it. So the pinout is needed.

The I/O port decode logic has 11 inputs and 2 outputs and at most 1 OR term, and so comfortably fits within a TIBPAL16L8-15CN (available from Farnell for less than £2).

The memory chip enable logic has 11 inputs and 2 outputs and at most 4 OR terms, and so also comfortably fits within a TIBPAL16L8-15CN.

The IOBYTE register and BANK register can each be a 74LS273 (2x£1).

An 16Mbit (2M x 8bit) EPROM, such as the ST Microelectronics M27C160-50F1 (£7).

The 16Mbit (2M x 8bit) NVRAM(s) is a ST Microelectronics M48Z2M1Y (£63).

Circuit diagram

I used kicad to produce this SVG.

I had to add my own definitions of the NVRAM and EPROM chips to the library before I could draft the circuit.

Circuit board layout

TBD

Freeroute seems to do a good job of this.

Software

Software to access the memory disks would exist in bank 0 (ie: the first 16KB) of each memory chip. This would be comprised of 8KB of MEMOrizer boot ROM and 8KB of MEMOrizer BASIC ROM. Prior to using a memory disk, a pre-formatting step would set this up.

Banks 1-127 would contain customer data.

The MEMOrizer boot ROM would be based on the SCPM boot ROM. Instead of using ASIDISC.MAC to control the Silicon and RAM disk, an alternative implementation called AMEMDISK.MAC would be written which reads and writes banks 1-127 of the memory chip. Because AFDSC.MAC would still be present, it would be possible to boot from the floppy drive (if you have an SDX plugged in) or a memory drive. It would also be possible to configure and copy between the SDX floppy drive and the memory drive(s).

The MEMOrizer BASIC ROM would be based on the SDX BASIC ROM. Instead of reading or writing the SDX floppy drive, it would read or write the memory disk in memory drive B:. As the BASIC ROM can only access one drive at once, copying between memory disks is best done from CP/M using the PIP program. Aside: It might be possible to add a USER command to switch between B: and C:, although I suspect this may be impractical due to the fact I'd be patching the ROM image, not reassembling.

Preformatting an EPROM memory disk can be acheived by preparing an EPROM image including the 16KB bank 0, followed by whatever initial memory drive content is required (eg: a CP/M filesystem, possibly with files).

Preformatting an NVRAM memory disk can be acheived by running a Memotech CP/M program from SDX or other memory disk (EPROM or NVRAM), which saves bank 0. You'd then use SIDFMT to format it.

A Memotech CP/M program that sector by sector copies a complete memory disk (EPROM or NVRAM) to another NVRAM memory disk (including bank 0) could also be used.

A Memotech CP/M program which read a succession of files (from a SDX floppy, EPROM or NVRAM) disk and did sector by sector writes to a NVRAM memory disk could also be used to initialise them.

AMEMDISC.MAC, CONFIG.MAC and the SDX BASIC ROM would need amending to add a new type code (52 or 60?), corresponding to a 2MB memory disk.

Package

If this were to exist, given the fact the NVRAMs are expensive, I suppose people might be interested in picking and choosing from this list :-

The fact the MEMOrizer board would be delivered with an EPROM ensures the user has something that works, including MEMOrizer specific utilities, and a selection of games. In particular, as they are on EPROM, they can't be erased or corrupted. If they erase or corrupt EPROMs, or buy new ones, they are guaranteed to have the means to (re)initialise and start using them.

Online / downloadable :-

Challenges

*** I suppose I could redesign MEMOrizer to be a regular MTX add-on. It would plug in to the left hand side of the MTX (outside the case), or the right hand side of the MTX (inside the case). Presumably it would then be able to draw more power, and clearance wouldn't be an risk. I'd also be able to tap the RELCPMH and P2-0 signals on the connector, simplify the port decode logic in one of the PALs and eliminate a 74LS273 latch. However, I'd really need another MTX and ideally another SDX to be able to persue this option.

Author

The author of this document is Andy Key (email andy.z.key@googlemail.com).