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.

UFE A500 Keyboard Daughterboard

UFE A500 Keyboard Daughterboard Prototype

Over the weekend, I built the A500 keyboard controller daughterboard and got it to work with UFE.

The operation is quite similar to the TFE+ board. The daughterboard sits in between the A500 host and the keyboard, listening for key events. Once it detects the UFE activation key combination, it starts to prevent the host from receiving the key events and redirects them to UFE instead. When the user is done modifying UFE settings, the daughterboard is signalled to stop redirection of keyboard events and the host becomes able to receive keyboard events again.

The daughterboard contains an 14-pin PIC24F04KA200 and it communicates with the PIC32MX on the UFE board via the I2C protocol. Currently I2C slave reads are implemented, but the slave writes are missing (so UFE is unable to reactivate the host keyboard event reception). I should be able to implement this soon.

Normally, the daughterboard is intended to be plugged right into the keyboard port on the A500. Unfortunately, I’ve made a couple of mistakes with the board schematics/layout. I’ve confused the keyboard input and output ports and I’ve made another oversight regarding the keyboard data line that I’ve had to fix with a couple of jumper wires. So, I’ll fix these issues and soon make a new PCB.