*** M E M O R U M ***

Yet another rethink of the VHD design for the CPLD and the SD Card interface finally seems to work in both slow and fast mode.

Well at least moderately fast as I am currently clocking the Z180 at only 4MHz. I have yet to get a new 10MHz Oscillator, which I will then clock double to 20MHz.

My Z180 running CP/M

The boot process is slightly complicated.

Although Rememoriser and CFX both support multiple CP/M drives on a single media, they don't use partitions in the now usual PC (DOS, Windows or Linux) sense. Instead they just store the drive images in successive 8MB slices at the bottom of the media. This renders the media unusable for any other purposes unless it is reformatted.

My Z180 storage is using Micro SD cards. The minimum size of these readily available now is 8GB or 16GB. To use that amount of storage to just store four CP/M drive images (32MB) seemed to be a waste. I therefore partitioned the SD card in the modern PC sense. I created two partitions:

• A 32MB partition of type 0x52. This partition type is documented as being for CP/M. This is used to hold four 8MB CP/M drive images.
• The remainder of the space as a FAT32 partition. This can be used as normal from a PC to store any relevant files such as my Python assembler and any Z80 source.

Next I had to create a CP/M system image. To start I dumped the system tracks from a Memotech disk, and disassembled it, assisted by an existing CP/M disassembly published on the net. After a bit of work, this gave me a source code that I could re-assemble to duplicate the Memotech system image. The system image consists of four parts:

• System bootstrap loader - 0.25 KB
• CCP - Console command processor - 2.00 KB
• BDOS - Basic Disk Operating System - 3.50 KB
• BIOS - Basic Input Output System

The Memotech regards CP/M disks as having 26 sectors (128 bytes each) per track and the complete system image resides in the first two tracks. This gives 7.50 KB of space for the system image. The CPP and BDOS are fixed leaving only 2.00 KB for the loader and BIOS.

This is not much space for a complete BIOS, and the Memotech does not have one in the system image. Instead it relies upon routines previously loaded into high memory by the CP/M boot ROM. Interestingly, the same is true of the Digital Research example BIOS code which makes use of calls into existing Monitor code.

For me, for ease of development, I wanted to have most or all of the BIOS on the SD card, and this space was proving tight, particularly when I had to include code to debug a few issues with my CCP and BDOS port. I could have changed the format of the disk images, either using 32 sectors per track (which would have made some of the calculations easier), or using 3 tracks for the system image. But either of those changes would have meant I had to build new disk images from scratch rather than being able to simply copy ones from CFX.

As mentioned, I have partitioned the SD card. This means that the partition table is at LBA 0. However, the first partition does not start at LBA 1. Instead it starts at LBA 0x800 (=2048). Therefore there is nearly 1MB of free space between the partition table and the start of the first partition. In the PC world this would typically be used for boot loader code. I can therefore use it for similar purposes.

I have therefore decided that my Z180 code on SD card will start with the signature bytes "Z180EC". My ROM bootloader then works as follows:

• Load LBA 0 into memory. Check for the "Z180EC" signature, and if so jump into the code. This for media which has not been partitioned.
• Test for a valid partition table (last two bytes 0x55, 0xAA). If not declares the SD card not bootable.
• Loads LBA 1 into memory. Check for the "Z180EC" signature, and if so jump into the code. This for system images that will not fit in the SP/M drive image system tracks.
• Scans through the partition table, looking for partitions of type 0x52 (CP/M) or 0x7F (Experimental). If found, load the first block of the partition into memory. Check for the "Z180EC" signature, and if so jump into the code.
• Declare the SD card not bootable.

In the screen shot (top) the system has been booted from LBA 1. This second stage loader still has to scan the partition table to find the location of the CP/M drive images.

I have still to fit the RTC and FPU to my second board. However the main thing that prevents my Z180 system being stand-alone is that I am using a serial port for input, so I have to connect my laptop as a terminal. I did include connections which in theory should allow me to connect a keyboard to the display Propeller chip, however I don't think the chip has enough capacity to run both display and keyboard processing, certainly not USB.

Anyway, serial input is the most logical way to get key presses into the Z180. So my next move is probably to add a keyboard to serial board. I could use another Propeller or even an RPi Pico, which would support USB. But either of these seem excessive, so I will see whether I can do PS/2 to serial using a low end PIC chip.

Mark

PS/2 mouse and keyboard interfaces/code are seemingly pretty common for the arduino. I vey much doubt the need the full resources of the ATmega328 so maybe one of the smaller ATmegas or larger ATtinys could do the job ?

A CLPD would have no problem with the serialising, I wonder if there's enough resources in something like a 7032 for a state machine that would wake up a PS2 keyboard on reset and pass on key-presses ?

Nothing as powerful as an Arduino for the keyboard processor. I am planning to use a PIC 16F627 (18 pin DIP) since I have a few in hand. I did contemplate using a 16F84, but that would have required bit-bashing the communication with the Z180, while the 627 has a built in UART.

It looks as though the 627 has enough capacity to convert the messy PS/2 multi-byte mode 2 scan codes to single byte USB style codes, or even all the way to ASCII codes. Not actually tested yet, just drafting out the firmware.

Also, even though it is only 18 pins, having just a keyboard and the Z180 serial connection attached leaves a number of pins unused, which offends my frugal nature. Not quite enough pins for a Centronics interface, but perhaps enough to drive a small LCD display.

Serial Interface board for my Z180 computer. It has:

• MAX232 to provide RS232 levels for five wire serial (Tx, Rx, RTS, CTS, Gnd) for Z180 serial port 0.
• PIC 16F627 to convert keyboard PS/2 data to TTL serial for Z180 serial port 1.

The PIC chip can supply keyboard data in three formats:

• A straight relay of the keyboard scan codes.
• Conversion of the PS/2 data into single byte codes (based on USB codes) with high bit clear for key press or set for key release.
• Conversion to ASCII codes with custom extensions for non-printing keys. In this mode only key press (or repeat) is signaled, not key release.

The keyboard serial is at a non-standard rate of 15,625 baud (4MHz / 256), which happens to be convenient for both the PIC and Z180, and is similar to the PS/2 data rate.

That is a neat looking board. Single sided board and only 3 jumper wires too?

Yes, but then the circuit is very simple. Single sided boards are certainly easier to make.

As you say, three jumpers. Two for ground. One of these may be unnecessary, but the ground plane goes all round the board to get from one end of the link to the other. The third is for +5V.

I have seen comments on other forums that suggest routing power tracks first. However I usually find it easiest to route the power last.

I should stick to software. Or at least learn not to be impatient and triple check everything

I managed to mirror image the footprint of the PS/2 socket. Once I realised what I had done, correcting the layout and remaking the board did not take too long. Unfortunately, the reverse power applied by my original faulty PCB has destroyed my one and only PS/2 keyboard.

I know I can still buy a replacement, but I am cross with myself.

Still, having nothing to loose, I took the keyboard apart. The key contacts are formed by two layers of flexible PCB. Strangely, there is nothing separating the layers to form an open contact. Little rubber cones form the springs of the keys, and press down on the flexible PCB layers when the keys are pressed. Under the cones, the keys are clipped into the top frame. I wonder whether it would be possible to make anything that would connect to flexible PCBs and scan the key matrix. I doubt I could make anything that would fit inside the keyboard case.

There is another option for a keyboard.

"Mechanical" keyboards are all all the reage in some gaming quarters. I have one of the 3/4 size versions connected to the 2nd PC to save desk space, and it does have individual keys and not a membrane.
I've been told I'm crazy butchering a band new keyboard (Thanks Dave!), but I don't know anywhere when you can get 88 keys and 88 key caps for £30. So, I brought a 2nd one and removed the PCB. I've then wired it in a 11 x 8 matrix. Had I wanted to I could have gone for a very close to the MTX 10 x 8 matrix and used the ALT or windows keys for reset. I've actulally picked a keymap that puts all the modifier keys in one row which hopefully makes the decode software easier. Space under the keys is almost nil, however in the gap around the cursor cluster to fit a small PCB.It could just be a small board to take the "x" and "y" plugs and a 20 pin cable header. But some inteligence whould be preferable, 8 bit parallel being the easist to deal with for me but there's no reason why a microcontoller and serial output wouldn't fit instead. Under the space bar is another option.