MTX Series ROM Firmware

Disclaimer

These pages were written as I attempted to gain a better understanding of the ROMs used in the MTX series of computers  The information here will likely evolve as I learn more, but it is not guaranteed to be accurate and may contain glaring errors, obvious to anyone who knows about these things - if you spot any, please let me know.

BASIC Editor Input Scanning

When I was trying to find a VRAM fault with my MTX512S2, I saw some strange effects that I could not understand at the time. The "Ready" prompt was displaying "Peady", but it wasn't just a character display problem as typing "R" at the keyboard also resulted in a "P" being displayed that was interpreted by BASIC as a "P" rather than an "R".

As the MTX schematic shows, the VRAMs are not directly connected to the Z80 data bus - data transfer is between the VDP and the VRAMs, so I could not understand how display corruption could affect the BASIC interpreter.

Some time later, when we were trying to increase the speed of MTXPlus+, we saw similar problems when over-clocking the VDP. As the system speed increased, we saw increasing amounts of display corruption. When the corruption occurred in the edit region under MTX BASIC, the BASIC ROM interpreted the data presented on screen, rather than the keystrokes that had been entered.

I had previously assumed (without actually looking at the ROM) that user input would have been read into a keystroke buffer before being passed to the BASIC interpreter, as it turns out, this is way off the mark. When Martin and I were discussing some of the screen problems with Tony, Tony cleared up my misunderstanding of the key stroke processing logic.

Unsurprisingly, the MTX BASIC editor uses VDP text mode when the user is editing programs or displaying text output. When entering text in the edit area, if the cursor is moved back over characters already entered at the keyboard, the highlighted character flashes in reverse video. Since text mode in the TMS9918/29 VDP does not have a colour table, it is not possible to simply invert the paper and ink colours for one char, so a "work-around" was required to achieve this effect.

The cursor routines in the ROM read the VRAM to find out what character is under the cursor and writes the inverted character (char no. + 128) back when necessary. It is the displayed character that is fed to the BASIC interpreter - not necessarily the key strokes that have been entered.

Credits

Some information provided by Tony Brewer