This is going to be a short post. I suddenly came upon a desire to remote-control my PCW8256 machine. This involves two things in this case.

Video output

The PCW comes with its built-in screen. This is black-and-white display with NTSC timing, but higher horizontal resolution. The video controller creates a composite sync signal and a digital video output. These are normally driven to the CRT display. My idea was to combine the signals into a composite video and feed it into a video capture dongle I had laying around. The circuit I've crated as the following:

The inverters serve two purposes: they buffer the signals, isolating the relatively high load of the video input from the PCW ULA and they generate well defined CMOS 5V high output signals. The resister dividers are chosen such that - when combined with the 75 ohm termination inside the capture card the generate proper video levels:

• 0V for sync
• 0.286V for black level
• 1V for white level

I've built the circuit up on a piece of prototyping board (with slightly different resistor values as I didn't have the exact ones at hand) and connected it to the both the PCW motherboards video output and my capture dongle. I've fired up VLC and booted:

The video quality is not the best, but certainly readable. One thing I did to get somewhat better quality is to connect the video signal to the luma pin of the S-VHS input. This caused the capture card not to attempt to decode color information and removed some artifacts. The quality unfortunately is not going to be much better then this though: the video generated by the PCW has much higher horizontal resolution than what normal NTSC bandwidth allows. The capture card is not designed to deal with it. Still, for next to free, it's not bad!

Keyboard input

The communication interface between the PCW and it's keyboard has been documented by others:

• https://www.seasip.info/Unix/Joyce/pcwkbd.html
• https://hackaday.io/project/27549-the-pcw-project/log/70757-keyboard-timings

These are great resources. My idea was to replicate the wave-forms shown in those articles from a PC, using an FTDI chip. If that worked, I could send key-strokes to the Amstrad, completing the remote-control capabilities.

The trouble is that the FTDI chip is much slower when used in bit-bang mode and the MPSSE mode is not really capable of putting the data-transitions in the middle of the clock edge. At least not on the FT2232D that I'm using for this purpose.

I had a hunch though that the timing doesn't matter all that much: the ULA used in the PCW is a relatively simple affair and it has to do a lot of thing, such as video generation, DRAM interfacing, address decide, memory refresh etc. It could not have dedicated all that many gates to keyboard interfacing. So, I was thinking that it simply looked at various edges to determine what to do next in a simple state-machine:

1. If there was a rising edge on the data line while clock is low, that would be a start condition. Maybe you need it repeated twice to register as a start-condition.
2. If there was a falling edge on the clock line, capture the state of the data-line.
3. Each packet is 12 bits, the first four is an address, the next 8 is a data.
4. After each packet is received, slap 0x3ff in front of the address, and write the data into memory.

If I'm right, the actual times described would not matter. Potentially even the full 17-packet transfer wouldn't matter.

I've written up a Python program to test this theory. I will attach it somehow to this post after some cleanup. It is rather simple in that it maintains the full 16-byte matrix in memory, updating with monitored key-presses and releases. Since transferring the whole matrix over the very slow bit-banged FTDI chip takes forever, instead it just transfers the bytes that were changed since the last transfer. That, and of course the last byte (offset 0xf) twice to handle hand-shaking with the host using the 'update flag' and the 'ticker' bits.

This (after fiddling a lot with the FTDI library) worked surprisingly well:

Why?

There are a few reasons. One is that this way I can remove the monitor and the power supply from my setup. I can lay the PCW motherboard flat on my table and do a much better job at wiring it up to all the life-support that I have around it.

The second is that I can now - if I so chose - have completely automated tests: I have control over the keyboard and the reset which are the main ways to create stimuli for the bard. I can put test-images on the Gotek drive I have as a floppy emulator and load them at will. Since I have access to the UnIC FPGA through JTAG, I can download test images, even access the internal logic analyzer and capture traces, examine bugs and try to reproduce them.

The third benefit is that I can remotely log into the PC that's hooked up to all of these FTDI chips and the screen grabber so I don't have to physically nearby to conduct experiments. Heck, I can even use the scope remotely if that's my fancy.

Final words

This was a fun little side-track. Some cleanup is needed and I really would want to find a better keyboard handling library for Python. The one I'm using right now (pynput) seems to capture keystrokes at a very low level, which means that it captures all key-presses in the system whether it was intended to the window it is running in or not.

For scripting purposes, it would also be necessary to be able to send keystrokes programmatically from - for instance - a stimulus file.

As an aside, I needed to find a different power supply for the motherboard, now that it's not hooked up to the monitor (which contains that in the PCW). The motherboard uses 5V. Yes, it receives the 12V and 28V supplies as well, but only to pass them on to the floppies and the printer respectively. Since the Gotek doesn't need 12V and I don't have a printer attached, I only need 5V. At the moment, I'm using my bench supply to generate the requisite 5V. It shows ~800mA power consumption. That is a bit higher - but not outrageously so - than the 500mA that a single USB connection can supply. I'm thinking of using a USB HUB to provide power as well. Tying two ports together would certainly work, I even have cables for that (old external hard drives rock!).