CPC6128 Keyboard Daughterboard for UFE

UFE CPC6218 Kbd. Daughterboard Installed (Closeup)

UFE CPC6218 Kbd. Daughterboard Installed (Full)

UFE CPC6218 Kbd. Daughterboard Scan (Top)

UFE CPC6218 Kbd. Daughterboard in Operation

This time, a post unrelated to Cumulus (a Cumulus-related update will follow shortly).

At the request of my friend Alcofribas, I’ve been designing and building (in parallel with my work on Cumulus) a CPC6128 keyboard daughterboard for UFE. It allows one to control the UFE floppy emulator using the host keyboard on a CPC6128, just like one does on an Amiga 500 or 1200.

This daughterboard ended up being a bit complicated to setup (at least moreso than the other UFE keyboard daughterboard designs). The existing ribbon connectors on the CPC mainboard are desoldered and female headers are installed in their place. The ribbon connectors are then soldered to the daughterboard. The daughterboard has male headers that match the female headers installed on the CPC mainboard. So, the daughterboard sits upside down on top of the CPC mainboard, and the case cover can be closed without any problems. The rest of the installation is the same as any UFE installation.

The board contains a PIC16F877 along with three 74LS245 chips, four headers/connectors and lots of pull-ups. The 245 octal buffers control the connections between the CPC mainboard and the CPC keyboard, so that UFE can prevent the CPC host from receiving keypresses when its user interface is active. The PIC controls everthing, scans the key matrix and transmits keypresses to the UFE mainboard over I2C.

It seems to work well, but at the moment there is one complication: For the daughterboard to be able to detect the activation keypress, the CPC host must be actively scanning the keyboard. I am told that this may become a problem with some demos and games. So, I’ll need to devise a way to make the daughterboard scan the keyboard at times for the activation keystroke without interfering with the host scan of the keyboard. The most likely solution is that the daughterboard will determine when (or if) it needs to scan the keyboard, by dynamically adapting to the host’s scanning patterns. I am sure that with some more experimentation and practical thinking, a satisfactory solution may be obtained here.

A1200 Keyboard Daughterboard Working

UFE Rev A1 Installed on Amiga 1200 (Cover Off)

UFE Rev A1 User Interface on A1200

After implementing the I2C communications and a little bit of debugging, the UFE A1200 Keyboard Daughterboard is now operational. For testing, I had to use the previous Rev A1 development prototype of UFE, since the only existing Rev A2 prototype is now installed in an A500 machine and I did not want to remove it. I’ve had to make some cables and it also took some work with the hot glue gun to get the UFE installed in the A1200 case, but the results seem fine. In a little while, I’ll be updating the UFE page with this news; additional photos will be uploaded there as well.

UFE A1200 Keyboard Daughterboard Progress

UFE A1200 Keyboard Daughterboard Installed

UFE A1200 Keyboard Daughterboard Updated PCB (Preliminary)

I’ve made some good progress with the A1200 keyboard daughterboard for UFE.

I painfully found out that the PCB design I’ve mentioned in my previous post had a physical issue: It was a little too large! After I made the board, I tried to fit it in an A1200, but it wouldn’t since the corner of the board hit a capacitor. Fortunately, I had not soldered any components yet.

So, back to the drawing board… The solution I came up with was to move the components in the lower left quadrant of the old design to under the PIC chip. Of course, a precision socket had to be fitted in order to raise the PIC to allow components under it. This way, I was able to cut the lower left section altogether, which meant that the new design would fit even with the metal shield in place.

Once I manufactured the PCB, I was glad to see it fit very well. This board is definitely NOT one of my better manufacturing jobs, but it seems it will do the job. The copperclad I used is thinner than the usual stuff, so it fits directly in the flex cable socket once the white plastic lock is removed.

The board has a PIC16F877 installed (I had some handy), although I think that a PIC16F884 would be a better, cheaper alternative, and could be used without modifying the board. During my first tests last night, a funny thing happened. I had a PicKit 2 attached to the daughterboard for testing and it was powering the daughterboard. The PIC was recognized by the PicKit and it was able to program and verify it. But as soon as I plugged the board in the A1200, the PicKit would give VDD Voltage level errors… I was puzzled. I checked for shorts all around the board and I was wondering if the edge connector footprint was incorrect. Then, I realized: The A1200 was off and the poor PicKit was trying to power the whole Amiga through the VCC pin on the flex cable connector! Once I turned the A1200 on, the errors went away

Last night I managed to write some code for the PIC, too. Now I am able to scan the Alt and Amiga keys so that I can detect the activation keycombo. Once the activation keycombo is detected, the board prevents the A1200 from receiving any keypresses and it looks like it can scan the keyboard without any interference. So, the basic functionality of the board is in place, although I need to do more tests to confirm problem-free operation. Eventually, I’ll implement the I2C communication with the UFE mainboard and I am sure there will be some quirks to sort out.

UFE A1200 Keyboard Daughterboard Design

UFE A1200 Keyboard Daughterboard PCB Layout

After the initial release of information on UFE, quite a few people asked about A1200 support. So, here is the early result of my design efforts for an UFE A1200 keyboard daughterboard.

The board is designed to plug into the keyboard flex cable socket on the A1200 motherboard (see the edge connector on the bottom of the PCB). The flex cable from the keyboard goes into the connector on the top left side of the board. So, this board acts as a kind of pass-through.

A 40-pin PIC MCU sits on the right side and is responsible for scanning the keyboard and translating keycodes into the I2C protocol for UFE communication. A couple of 74ls245 chips are placed in between the keyboard and motherboard connectors. These are used to disable the column drivers on the Amiga side when UFE takes over control of the keyboard. This way UFE can scan the keyboard without interference from the Amiga keyboard MCU.

This should all work in theory, based on my understanding of the A1200 schematics and the reverse-engineered A1200 keyboard schematics. Of course, there is a decent chance it could fail, so that’s why there are no schematics accompanying this post. I’ll build the PCB soon and write the firmware for the PIC and see if it actually works . I haven’t checked the A600 schematics yet, but there is a good chance that this will also work with the A600 without modification.

Part of the challenge here was to make everything fit in the rather limited space. That’s why the board ended up being double-sided. It does not require plated-through holes, however, and there are only a few vias that can easily be handled by soldering wires on both sides. These measures should help keep the cost to a minimum. The current board layout also requires the A1200 metal shield to be removed, but this may perhaps be avoided, by elongating the board even further.

UFE Page Up!

I’ve just posted the UFE page, which contains detailed info, photos, a video and schematics.

UFE New PCB Assembled and Working

UFE Rev A2 Installed on Amiga 500 (Cover Off)

UFE Rev A2 Installed on Amiga 500 (Cover On)

Over the last couple of weeks, I’ve managed to assemble the new UFE board and make the necessary changes to the firmware to make it work with the PIC32MX575. I’ve also mounted the board in the floppy slot of an A500 to see how it would actually look. The result is quite nice and it is quite practical to operate with the A500 top cover closed. I’ve had to hot glue a couple of threaded posts to the base of the A500 case to be able to screw the board, but other than that, no case modding is necessary.

I am a little disappointed with the PIC32MX575 though. First of all, the I2C module has an embarassing bug which causes the module not to assume control of the output pins properly. To add insult to injury, the workaround specified in the errata document seemed to be insufficient in my case. In addition to manually declaring the pins as output, they also needed to be configured as open-drain, otherwise it did not work. Another issue (that still remains unresolved), is that I could not get the “IDLE” power save mode to work properly. The behaviour here seems to be different than the PIC32MX460, but I could not figure out what exactly is different. The IDLE mode is used by the UI code to wait for the vertical blanking period for video output. The code that worked fine on the 460 does not seem to work on the 575, so I’ve had to (hopefully temporarily) replace the IDLE mode with busy-wait loops.

Nevertheless, most of the basic functions of the UFE work fine in the new board. There is one remaining problem with the write clock recovery circuit that I could not get the component values right. Hopefully, I should be able to sort out that problem tonight. Afterwards, the first order of business will be to create a video of the UFE in operation and put up a new project page for it.

UFE New PCB Ready

UFE Rev A2 PCB Before Assembly

I haven’t posted in a while, but I was not lazy . I was working on making the PCB for the next UFE hardware revision. I’ve tried a some new things and ran into a few problems in the process, and eventually, came up with the board in the photo.

With this PCB, the soldermask is noticeably stronger than the previous UFE revision, especially on the top side. On the bottom side, the soldermask still lifted in a couple of places. I plan to do some more tests with dummy boards soon and hopefully improve on the process.

One thing that still bugs me here the pitting of copper in large plane areas. Admittedly, this problem is more of a cosmetic nature (as double-sided boards are already limited in terms of signal integrity and speed). I also want to do some further tests to see how this situation can be remedied. Perhaps some Pulsar Green TRF can be useful, or I can even switch back to PnP Blue if I can get it to work with CNC drilled holes.

ATARI 1040STE with UFE

UFE and ATARI 1040STE 1

UFE and ATARI 1040STE 2

UFE 1040STE Video Connections

As part of my on-going tests of UFE with its major target hosts, here are some photos from my tests with an ATARI 1040STE.

The video overlay works fine, although the UFE output drivers are a little weak compared to those of the 1040STE so they are unable to saturate the output for white pixels. In my opinion, it’s less than ideal, but it does not seem to be a big problem either.

I’ve added support for loading ST and MSA files to the firmware. Just like with the CPC, there is no write support yet, and a keyboard daughterboard will need to be designed for the ST keyboard. According to the schematics, (at least) the 1040STE has both SEL lines on the internal floppy connectors, but I have not tested dual drive operation. I do not expect any major problems there as it should be quite similar to the CPC.

So, now that I know that there are no major problems with the major target hosts of UFE, I’ll be moving on to manufacturing the next PCB revision.

Amstrad CPC6128 with UFE

UFE and CPC6128

UFE and CPC6128

UFE CPC6128 Video Connections

Before moving on to manufacturing the new PCB revision, I wanted to make sure that there were no showstoppers that could prevent operation with the major target hosts of the UFE. Or, that if I encountered any problems, I could fix them in the next PCB.

So, enter my tests with the CPC6128. The video is working fine. I’ve added .DSK read support to the firmware, which also seems to work fine, but the diversity of the .DSK images out there (including those with copy-protection) necessitates more testing. But the basic functionality is working. After a few small modifications to the firmware, dual drive support also works fine. In the UFE settings menu, the user needs to choose the CPC mode for correct handling of SEL lines.

Amstrad engineers made some interesting design choices with the CPC6128. The internal floppy connector is not standard. None of the connectors have SEL lines for both drives, and according to the schematics, SEL0 is actually SEL1 inverted. Nevertheless, UFE operation turned out to be a little problematic with the SEL1 connection from the external connector, so I took the SEL0 line from the internal connector with a patch cable. The same will need to be done for the MOT line.

Write support for .DSK images is missing at the moment and since there is no keyboard daughterboard for the CPC6128 yet, I’ve used my previous button interface to test things. Both of these features will need to wait until after I am done with the next PCB revision.

UFE A500 Keyboard Daughterboard 2

UFE A500 Keyboard Daughterboard Installed

UFE A500 Keyboard Daughterboard Top Side

UFE A500 Keyboard Daughterboard Bottom Side

I’ve fixed the problems in the first A500 keyboard daughterboard I’ve made. Here are some images of the new one, including one that shows how it looks when installed on an A500. At the moment, it works fully with the UFE mainboard. The missing I2C slave writes have been implemented. UFE is fully controllable from the A500 keyboard.

There is one problem, though. The Amiga keyboard protocol requires that the transmitted key event be acknowledged by the Amiga once the full 8-bits of data has been received. If this acknowledgment is not received, the keyboard goes into “lost sync” mode. It stops sending key events, until sync is restored.

Normally, this behaviour poses no problem for UFE, but in some rare cases, some (poorly written) cracks/loaders temporarily assume complete control over the system, causing the acknowledgment to be not sent. For example, the Turrican 3 cracked loader flashes the screen to request the user to swap disks. When in this mode, the loader only checks if the disk is replaced and ignores everything else, including keyboard events. Since the keyboard becomes unusable in this mode, it becomes impossible to activate UFE.

I can think of some solutions to this problem. Probably, one of the more robust ones is to check for the “lost sync” condition in the keyboard daughterboard firmware. If the host fails to respond to the “lost sync” condition after eight 1s have been clocked in, let the keyboard daughterboard acknowledge the last key event. Since the keyboard always retransmits key events that are not acknowledged, no key presses will be lost. Eventually, the host will be able to handle keyboard events properly, and everything should be back to normal.

On a side note, to manufacture this new board, I’ve used a new “drilling technique”. Instead of aligning the toner transfer paper to CNC drilled holes, I did it the other way around. I first did the toner transfer (with holes in pads) and etched the board. Then, using CNC coordinate measurements for four corner pads, I computed the transformation from PCB software coordinate space to etched board CNC coordinate space. This transformation compensates for scaling, translation, rotation and shearing. I’ve written a Python script to do the computation and integrated it within my g-code converter script. As the PCB scans show, the results have been excellent.

I’ll soon update my “Making PCBs” page with all the new experiences I’ve obtained and I’ll release the Python sources for the scripts I use. I am also going to take some scans while I make the new PCB revision for UFE and update the page with those as well. They should be quite an improvement over the poorly lit photos I’ve got there right now.