Computers Overview
Commodore PET
Sinclair ZX80
Sinclair ZX81
BBC Micro
Commodore 64
Sinclair Spectrum
Memotech MTX
      Hardware Hacks
      Legacy (1980s)
                  Ver.2 Z80
                  Ver.3 Z180
              Games ROM
              I/O Ports
              System Bus
          Design Data
      PAL Reader
    User Groups
    Video Wall
Memotech CP/M
Atari ST
DEC 3000 AXP
Raspberry Pi




"MTX Plus+" CPU Board V 2.0


CPU Board Specifications - Version 2

CPU Z80 20 MHz DIP40 Package
Clock Speed 16MHz With 8MHz, 4MHz and Ck4/13 (for serial ports) sub-clocks
RAM 512kB

Static RAM,  rather than the Dynamic RAM (DRAM) used in the MTX

Optional  additional SRAM, making up to 784KB of RAM available

ROM 128kB For additional details of the ROM configuration, see the Memory page
Glue Logic   Altera Max CPLD (EPM7128SLC84) (Or 3 x GAL)
CTC Z80CTC Z80 Counter/Timer for serial clocks and interrupt processing
RTC DS12887 24 pin encapsulated package
Reset MAX705 DIP8 Package - for uP supervisory functions (CPU reset)



Hardware - Control Bus Signals - Version 2 Board

The backplane distributes a number of control signals to the rest of the boards in the system, the majority of these are standard Z80 control bus signals, generated by the CPU, but there are also a number of other signals generated or used on the CPU board that are distributed over the backplane.

Name Description Source Direction

System clock signal (frequency set by bit switches 0 to 2)











  16 MHz (default)





  8 Mhz





  4 Mhz





  2 MHz





  1 MHz





  1 kHz





  8 Hz





  1 Hz

CPLD To Backplane
PHI4 Additional 4MHz clock signal CPLD To Backplane
PHI8 Additional 8MHz clock signal CPLD To Backplane
SER01 Clock for serial port 1 CTC To Backplane
SER02 Clock for serial port 2 CTC To Backplane
DIAG Signal to the Diagnostic board to latch 7-segment displays based on logic in the CPLD.

By reprogramming the CPLD and switching the position of jumper J5, simple on board status conditions can be shown using the on board "DEBUG" LED.

CPLD To Diag. board
/VDPINT Interrupt signal from VDP VDP From Video board


Design & Build

Martin and I will be using the same functional design for the CPU board, but our implementation of the glue logic will be different, as I described above, I shall be using an Altera EPM7128S CPLD whereas Martin is going to use a number of GALs on his board.

The draft schematic for my CPU board, including the CPLD.

Martin's board is essentially the same, but the glue logic uses three GALs, a GAL22V10 for RAM decoding, a GAL16V8 for ROM decoding and a GAL16V8 for I/O decoding. Martin also uses a 74HC273 for the Page Port outputs and two 74HC193s to divide the 32MHz oscillator frequency to generate the sub-clocks (16MHz, 8MHz, 4MHz, 2MHz and the serial port clock, 307KHz).

The component layout for Martin's board (viewed from the solder side), the GALs are the three chips in the shaded area in the centre of the board - the CPLD on my board will be located in the same area.
As usual, Martin's construction is a bit ahead of mine, a couple of photos of his board at various stages are shown here.

The solder side of Martin's board, plugged into his backplane.

Just the power and ground connections have been wired at this point.

Version 2.04 of the CPU schematic.

Page 1 includes the components common to the CPLD and PLD designs.

Page 2 shows the components for the two designs separately

KiCad PCB layout for the CPLD based design (Ver.2.02 ds)
KiCad PCB layout for the CPLD based design (Ver.2.02 ma)
Another update on the status of Martin's board - with the address lines wired up to the relevant ICs (blue) and the memory bus lines connected to the 74HC245 buffer, in preparation for wiring out to the required IC data connections (yellow).
And now with the data bus completed - "only" the control signals left to do

Some way behind Martin, my CPU board is finally taking shape . . . .

You may have noticed that the layout is a bit different to the schematic, I did a little more "optimisation" when I was test fitting the sockets which will hopefully make wiring it up a little easier.

Now with the power distribution wiring done on my board.

As you can see, the wiring below the PLCC socket is a bit congested, this is due to the 8 pairs of power and ground connections, along with decoupling capacitors. The caps are squeezed into the space between the base of the socket and the top surface of the board - they are visible in the component side photo.

Some progress on my board, A0 to A15 and D0 to D7 have been wired from the bus connector to the buffers and A0 to A7 have been fully wired up, i.e., from the buffer to the CPU, ROM, RAM and CPLD.
Now with the rest of the address lines wired from the buffers to the CPU, ROM and RAM. A13 to A15 are wired to the CPLD where the address decode logic will generate the OA14 to OA18 and RAMCS signals for the RAM and the RA13 to RA15 and ROMCS signals for the ROM. (These are currently not wired.)

I guess that the board is about 40% wired up at this point. 

Now with the data bus lines connected to all of the required components.

Like Martin's board above, "only" the control lines are left to wire, but that is still quite a few terminations to go. Most of them are "point-to-point", rather than being multi-dropped, so it should be relatively quick to do the final terminations.

Another update from Martin . . . .

Almost complete, just the GAL wiring to be completed

The wiring side of my completed board, I need to tidy of some of the longer wire runs, but it's essentially finished - subject to testing of course.

And the component side . . . .

The ROM A16 jumper has now been fitted adjacent to the ROM socket and an additional jumper installed at the top left corner of the board to select whether or not the RESET signal is applied to the RTC. (The RESET pin has no effect on the clock, calendar, or RAM)

The "final" version of the board, with some modifications made during development, including a buffer for the Z80 control lines, a 74HC273 for the Page Port, a GAL22V10 for Video speed optimisation and a dedicated 4MHz oscillator for PHI4.

In this photo, the Address, Data and Control buffers have been bypassed using shorting links, they were removed from the final design.


Martin and I will be using different testing strategies, Martin has gone straight to populating the board and programming the GALs with a minimum configuration to enable 32K of the 512K SRAM and the standard MTX ROMs in slots 0-2.

Martin's Testing

Martin's first test was to install a copy of his RAM-less test ROM on the CPU board and run it together with the Video board and diagnostics board plugged into the bus. However, no output was generated on the video display, the symptoms were the same as those seen on an MTX with bad RAM, i.e., a black display and constant tone from the sound chip. The status lights on the diagnostic board were also displaying unpredictable sequences and statuses.

After trying various combinations or ROM, RAM and GAL logic, Martin found that with the data buffer installed, there was no output from the video board, but with the buffer linked out, the display was active.

Initial Testing

With the GALs programmed to decode a 16K fixed ROM and 32K of RAM with no memory paging and the data buffer replaced with jumpers, Martin was able to boot the CPU from a copy of his test ROM.

When either the 74HCT245 data buffer or the 74HCT273 Page Port flip-flop was installed, there was no output to the display, so there appeared to be something amiss in the data bus.   

The display shows the stack test running at RAM location FF00 and the data read back is incorrect. In a similar test with the stack test pointing to a location in ROM, the read-back was correct, suggesting that the problem may have been with writing data. Using a range of different addresses and data values for the RAM stack test, there was no indication of obvious faults such as stuck or inverted bits.

When run with a clock frequency of 4MHz, the video display was as shown, when run at 8MHz, the test ran, but with some display corruption but at 16MHz, the system "black screened". The display corruption at 8MHz was corrected by inserting some delays in the VDP output routines to comply with the VDP specs, but even with delays inserted, the system would not run at 16MHz.

At this point, Martin thought that the issue with the system failing to run at high speeds was down to either the VDP timing still not being correct or there being an issue with the CPU - perhaps due to noise or skew or the like. There were strong indications that it was a CPU issue as the CPU was actually HALTing when not instructed to.

After trying various things such as installing additional bypass capacitors and trying another RAM chip without success, Martin decided to build the bare minimum CPU board shown here.

In addition to the CPU, the board has ROM, RAM, clock, a simple R-C reset circuit and a single logic IC (used to generate a combined logic signal for the test ROM).

For completeness (and as further demonstration of Martin's wiring skills), the wire side of the minimal CPU board.

Although the screen shot is not very clear and the colours in the display are not as expected, the basic CPU board executed the same test ROM code that failed on the MTXPlus+ CPU board without error.

As with the MTXPlus+ board, the ROM code could be run at 2, 4 and 8 MHz, but the "black screen" issue was also present at 16MHz.

After a lot of investigation, mainly by Martin, the symptoms described had a number of unrelated causes . . . . . . .


1. Clock Speed


Perhaps the most interesting issue was that the "20 MHz Z80 CMOS" CPUs that we were using were nothing of the kind. We found that it was possible to test from software whether a Z80 was NMOS or CMOS, the test shown here is running on a CMOS CPU which was able to run at its labelled speed, whereas the "20 MHz" versions were NMOS. 


More details of this issue can be found in this entry on my Notes page.

2. Memory Write / Read Errors

Memory write and read-back worked flawlessly on Martin's minimum complexity test board. Apart from having a reduced chip count, the main functional difference between the MTXPlus+ and test CPU boards was that the test board didn't do any memory address decoding in PALs.

For testing purposes, Martin modified his MTXPlus+ CPU board to simplify the memory map, omitting any memory paging, allocating 16KB of fixed ROM and 48K of fixed RAM. The ROM decode GAL was replaced with a single HC32 quad OR, using two of the gates to drive the ROM chip select (CS) signal and the RAM decode GAL logic was reduced to the bare minimum to enable the 48K of RAM.

SUCCESS ! - With this simplified memory configuration, the MTXPlus+ CPU board booted the test ROM and ran the RAM test routine without errors.

The root cause of the problem was that we had errors in the PAL (Martin's board) and CPLD (my board) address decode logic equations. A minimal memory map was now working and would "just" need modified to cater for the memory paging required for the 512K RAM and 128K ROM that we were using.

(You can see the result of the RAM test running on my board further down this page)

3. Video Display Colour Variability


Once the other issues had been resolved, Martin found that the variability in the screen colours did not occur on the MTXPlus+ CPU board. Martin has suggested that it may have been due to differences in the effect that the simple RC reset circuit used on the test board had on start-up of the CPU and VDP, perhaps the VDP was slower to start and may have missed part of the register setup code.


As the MTXPlus+ board, using the MAX705 based reset circuit, does not exhibit the same behaviour, then the issue does not really warrant further investigation.

4. Data Buffer Problems 

See the Design Development page for details

Until the design was modified and changes made to the buffer wiring and control logic, the work-around was just to run the CPU board with the data buffer bypassed.



"Final" Configuration & Testing

Memory Paging

With the core functionality of the CPU board now working, the remaining tasks were configuration of the Page Port memory map and I/O decoding for the RTC in the PALs / CPLD.


This image shows the output from Martin's test ROM before memory paging was configured. MTXPlus+ is running with a MTX512 memory map, i.e., a fixed 16KB of ROM (0-3FFFh) and 48KB of RAM, including the fixed RAM at 4000-BFFFh and the "common" block at C000-FFFFh.


With no paging, "Page" faults are reported for the "missing" RAM.

Once the GAL had been configured for RAM paging, the ROM was able to find the test the remainder of the RAM  as it was paged into the address range between 4000 and BFFFh.

(The difference in display colour is due to the ambient lighting when the photos were taken, the previous photo is closer to the true screen colour).

With the GAL updated to include the paging code and the MTX ROMs loaded into the on board ROM, a screen shot of Martin's screen output which, for obvious reasons, he named "So Close".

Hopefully, you recognise the screen as typical output from the MTX BASIC ROM. The error is what you might expect if an invalid command had been entered at the "Ready" prompt. It is likely that with no keyboard connected, the ROM is still trying to read the keyboard drive/sense lines and seeing an invalid key entry.

MTXPlus+ will page ROMs into the memory as required in the same way that Memotech did it for the MTX. There is a slight difference in that copies of the majority of the Memotech ROMs (apart from ROMs 2 and 7) will be held in the single on board ROM.

The image shows another of Martin's test programs, this one is checking that the stored image can be accessed and available for paging.

Not content with a "mere" 512KB of RAM on the board, Martin has allowed a bit of "scope creep" and made 784KB of RAM available on his board by squeezing in another 512K RAM chip.

You can see the additional RAM chip squeezed between the original and the RTC ship.

Also note that the ROM is temporarily installed in a ZIF socket to save wear & tear on the permanent socket whilst frequent updates to the test ROM were being made.

Martin's test ROM image has been updated to test the 784KB of RAM.

The "Fail" result for Block 1, Page F in ROM mode is "by design", thereís nothing to gain from paging in the 2nd chip for just 16k. In addition, the MTX ROM code expects to find a RAM page failure at some point while its starting up, as thatís how it identifies the last good page.

Real Time Clock
And now with the I/O address for the RTC being decoded.

At this point, the RTC clock registers are being read, but the clock has not been reset and displays whatever happened to be in the registers in the chip.

This photo shows the output from version 0.09 of the test ROM. At this point, the clock has been set to 01/01/15 and code has been added to test the CTC - the "System Up Time" is being calculated using the CTC.


My Testing

The pace of my testing was rather more leisurely than Martin's and my intention was to make use of my MTX to MTXPlus+ bus interface adapter to test the RAM, ROM and the associated address select logic in individual stages to make fault finding easier should there be any problems with the CPU board. As I was finishing off wiring the board, I thought that a programmable status indicator, driven by the CPLD, might be useful. Although the CPLD will have quite a bit of spare logic capacity, there was only 1 spare I/O pin, as it was likely to remain unused, I wired this out to the additional LED located above the DIP switch block.

I had spent a lot of time checking the board against the schematic with a multi-meter to make sure that the connections went to the right places. It is easy to check for continuity this way, but, without testing many adjacent connections, it is not so easy to pick up short circuits. Nevertheless, I was reasonably confident that the wiring was OK and the initial test was to connect the unpopulated CPU board to an MTX and check that the MTX would operate correctly with the CPU board hanging off the MTX bus. This did highlight a short circuit after all, there was a short between +5V and the M1 signal, which, not surprisingly, gave the MTX a bit of a problem. That fault was easy to find, and quickly fixed (the M1 connection to the CPU crossed over a 5V line and a break in the insulation created the short).

With the CPU board connected to the MTX and the address and data buffers not fitted, the address and data lines were only connected as far as the buffer input pins. In  this mode, only the control signals, clock lines and Page Port lines are being fully exposed to the MTX.

Without the buffer chips being installed (and controlled),  I needed to short out the buffer pins to connect the rest of the address and data bus wiring to the MTX. As the circuit diagram shows, the buffer inputs and outputs are conveniently located on opposite sides of the chip - as you can see from the photo, it was quite easy to make up shorting links - although the quality of my efforts improved by the time that I got to the data buffer. It's not really evident from the photo, but to avoid damaging the permanent sockets, the links are installed in blank sockets piggy-backed onto the soldered sockets.

With the links installed, no additional faults came to light and installing the MAX705 allowed the reset function to be tested. At this stage, I had a Eurocard sized external reset button connected to my MTX!

Unfortunately though, I was not able to get an MTX to boot using RAM installed on the CPU board. I initially suspected a problem with my RAM decode logic in the CPLD and spent some time working on this until Martin's RAM issue came to light. At that stage, I abandoned the idea of trying to test from the MTX and went straight to testing the CPU board with the MTXPlus+ video board. [It is now pretty certain that my problems were associated with my memory decode logic, I may go back an test MTX access to the CPU board at some point - should I ever get time.]


Initial Testing

At this point, the effort involved in building my diagnostic board proved its worth. I was not able to generate a display on the monitor, even using a copy of Martin's test ROM and no RAM installed or configured. Although I had tested the board with a meter a number of times, I was unable to find the problem.

With the test ROM installed and the CPU clock set to 2Hz, I was able to video the status display as the program executed and upload the video to Facebook to see if Martin could see anything untoward. Martin was able to confirm that the program appeared to have loaded and was stepping through correctly, but spotted that there was an error in the values seen for A0. Sure enough, I found that the daisy chained A0 line had become detached at the ROM pin - so much for my testing!

When the Z80 starts up, it executes its first instruction from memory address 0 - the image shows the display on the diagnostic board with the CPU in single step mode and having loaded the instruction at address 0 - "C3" is the Z80 JP instruction, and causes the program to jump to the location stored at the next memory address (in this case, "7C").
Having fixed the A0 problem, I was able to see the output from Martin's test ROM running on my CPU board.

As shown here, the memory write & read-back tests failed, confirming that the problem was common to both designs was and was more likely to be due to a design/configuration problem, rather than constructions errors.

To save a bit of space while I had a lot of equipment on my test bench (or, dining room table, as my wife calls it), I splashed out £16 on a new 7" TFT monitor off ebay, the output is not brilliant, but for testing purposes it does the job well enough.

The output of the RAM test running on my CPU board, using NTSC composite video output to my cheap monitor (still with the protective film on the screen which isn't helping the sharpness of the picture).

Martin's 784KB RAM test running on my MTXPlus+, showing "fail" for the "missing" memory that would be in the second 512K SRAM.

It appears that I may have the MTXPlus+ equivalent of the MTX500 !

 - functionally equivalent to the other model, but with less memory

Version 0.09 of the test ROM running on my system with output to my cheap 7" monitor.

The image is not too pretty, but all tested systems, RAM, ROM, RTC and CTC are working as they should.

The same test program with the output to a LCD TV, using the composite video input and sending a NTSC signal, screen format set to 4:3 which is  more consistent with MTX and MSX machines using the same type of VDP.



With the MTXPlus+ "megaROM" programmed with the standard MTX ROM images, the usual MTX BASIC "Ready" prompt was displayed, even before the I/O board was connected.


My CPU board has pull-ups on the data bus that appear to stop the bad data generating the BASIC error that Martin had (above).

With the modified GAL and keyboard ICs installed, and an original MTX computer keyboard connected, here you can see the first simple BASIC program running on my MTXPlus+

The system can "see" all 512KB of RAM, PRINT PEEK(64122) returns the expected "15" for the number of 32KB RAM pages.

Status Summary

At this point, the CPU board has pretty much been proven to meet original design intent for MTX compatibility - at least, when running at 4MHz like the original. However, as things progressed during the build, a number of changes were made to correct a couple of weaknesses in my design. Added to this was some degree of "scope creep" that led to other modifications and enhancements.

These "design developments" were originally documented on this page, but the number and magnitude of the changes probably justifies their description on a separate page that I've called, oddly enough, Design Development. The main items are now just bulleted below, for details of the changes, click on the links to open the new page.

Design Development




mailto: Webmaster

 Terms & Conditions