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 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 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.

Dual Drive Support in UFE

UFE Dual Drive Operation

Here is a screenshot of XCopy just after copying a floppy with UFE in dual drive mode. I think this was the second floppy for the game “Arabian Nights”. After copying this, I mounted the first floppy in DF0, rebooted the Amiga, and I was able to play the game without having to swap floppies (since the second floppy was already in DF1 after the copy operation). I need to modify the UFE user interface to have a suitable, practical way to mount floppies in each drive and make them write-protected if desired. 

During my tests, I’ve found out that the write clock recovery circuit I am using (based on the 555 timer) can be somewhat sensitive (probably to temperature) to the pot adjustment that controls the clock frequency. This issue manifests itself in the form of data corruption during writes. Reads are not affected on the Amiga as it is quite tolerant to changes in bitrate, a “feature” used by many protection schemes back in the day. Once the clock frequency is adjusted, writes work fine, independent of the disk image. I intend to address this sensitivity issue in the next board revision.

UFE ADF Read Emulation Working

UFE ADF Read Emulation

UFE firmware development is going strong. Now, floppy read emulation and on-board MFM encoding of ADF files work. The ADF file chosen by the user is loaded from the SD Card and converted on-the-fly to MFM and results are written to SDRAM, from where the floppy data is served. This is in contrast to the original TFE/TFE+, for which the ADFs had to be converted on the PC beforehand. Thanks to the raw speed of the PIC32, the loading and conversion process takes about 3 seconds.  There is still room for improvement there, but I’ve decided to move on to implementing write emulation before focusing on that.

Since I haven’t built the Amiga keyboard control daughterboard yet, I’ve hooked up a few buttons to the interface connector so that I can control the user interface during testing. I’ve also disconnected the clock input from the host system and tried using the built-in oscillator of the PIC32, which seems to have worked fine. This also has the nice side effect of a slight increase in PIC32 speed.

Now that the basic functionality has started to come together, I’ve also started making notes about the changes for the next PCB revision. Here is the current list:

1. Checkout the general purpose PIC32 variants, as the USB versions are not really required here.
2. Remove the host clock input, as it does not seem to be absolutely necessary.
3. Add standalone video output capability (as opposed to overlay-only).
4. Better allocation of SDRAM lines to PIC32 pins, to increase SDRAM throughput slightly.
5. Rework the placement of interface and programming connectors.

Also, now that I’ve tested to SDRAM code quite a bit and got it to work in a real situation, I am soon going to release source code for the SDRAM interface in the hope that it can be useful to others.

UFE Prototype Assembled

UFE Prototype Assembled

Here is a photo of the UFE prototype, fully-assembled. I am able to program the on-board PIC32 using the PicKit2 programmer. The clock line is connected to the Amiga. Actually, while I was taking this photo, the board was running a tiny test application that alternately blinked the two on-board LEDs. The PIC32 is running at ~75.6Mhz here. The system clock is derived from the 28.375Mhz Amiga system clock, by first dividing the input clock by 6 (to get a ~4.73Mhz clock suitable for the PIC32 PLL) and multiplying it by 16. I am hoping that using the PLL will reduce or eliminate the clock jitter as this was a problem in the earlier TFE+ design, partly due to the relatively long cable over which the clock signal is transmitted. Being able to run the PIC32 at a speed so close to the maximum is very good news, but of course there is no guarantee that problems will not occur with the much more complex setup that will ultimately arise during firmware development.

It is not all good, however. It turns out that my PCB making techniques are still in need of some finetuning. During the soldering process and the cleaning afterwards, the soldermask crackled and popped in several places. I thought it was due to the soldermask not being cured well enough, so it did some tests with a spare, new PCB. It turns out that a thicker layer of paint, plus a higher curing temperature created a much stronger soldermask. During mask removal, the soldermask seems to lose some of its strength, but it works well to cure the board a second time after this step. This step seems to really strengthen the soldermask and that way it is able to withstand soldering and cleaning. I’ll do some more tests to confirm these first findings and finetune the process. Nevertheless, it seems that even in its weak state, a soldermask like this is better than no soldermask at all, since it greatly protects the PCB, especially from the usual trace lifting problems that I frequently experienced previously.

Another issue I encountered with the prototype board was that some of the vias lost connection after the soldermask curing. I am guessing this is due to thermal expansion. I solved the issue by scraping the soldermask above the vias and soldering them on both sides (For hidden vias, I removed the excess solder using a solder wick). This way, a very reliable connection was formed. I’ll soon be updating the page on PCB making with my latest findings.

More on SD Card Write Performance

Over the weekend I was able to do some more test on SD card write performance. I’ve tested with two cards: A SanDisk Ultra II (Class 4) and a SanDisk Extreme (Class 10!).

Both cards are SDHC cards (4GB in size). So the first thing was to add SDHC support to the TFE+ firmware. After figuring out some of the quirks of the SD protocol, I was able to get it to work (fortunately, there are many open source examples on the net, which made the process much easier). Both cards were much better performers than the cards I’ve tested previously. However, there are still some unpredictable busy periods during write operations (can sometimes be up to 20ms even for the Class 10 card). They are much less in frequency and size, but they are still there, nevertheless. Due to the reasons explained in my previous post, this dictates having enough memory on board if writes are to be supported on the Amiga.

All that said, the class 10 card was able to support continuous operation to a certain degree and TFE+ was able to write several tracks to the card during a disk copy attempt with XCopy. Unfortunately, the track data was not valid as the SPI clock was not synchronized to the edges of the floppy write data. I may try to implement this synchronization and see if the data is recorded correctly. It also seems that some additional circuitry may be needed here, but I am not sure.

SD Card Write Performance and TFE+

Last night I did some tests to determine SD card write performance and its effect on TFE+. The results are not very promising, unfortunately.

It seems that SD cards will always accept incoming data, until some internal buffer is full. Once the buffer is full, there is a busy period of at least 100ms. The size of the buffer and the duration of the busy period varies from card to card. I tried 4 cards of 3 different brands/sizes, and they all exhibit the same behaviour. I am not entirely sure, but I also think some of the cards do not handle very well the situation where a sector is overwritten, and they block until the previous write to the sector is complete.

The trouble is, of course, that since the floppy rotates continously, it is not possible to continuously write to the floppy without hitting the busy period. Most of the time, one can expect that the track will not be continuously overwritten, and the write enable line will become inactive once the track has completed one revolution. Afterwards, the head will be moved to another track and there will be the head settling time. Perhaps, some of the newer, faster (and more expensive) cards will be able to keep up in this case, but it’s difficult to guarantee anything. It may work in some or most cases but probably not in all. It is definitely easier to get this to work in case of a floppy controller with well-defined behaviour, such as the WD1772 in the ST.

Anyway, I think that it makes sense to observe the behaviour of a real floppy drive in write situations and draw conclusions from that. Also, I’d like to measure the performance of some newer cards and see if they’ll be able to keep up. I think the newest of the cards I’ve tried already is at least a year old, and even that one wasn’t a high perfomance card.

Another issue is that, some of the cards do not even guarantee that the data will be written correctly to the SD card. The card specs actually state that there may be write errors and the data written must be verified to see if the write operation must be executed again. This is of course not acceptable in this case, as there is simply not enough time to perform the verification and one of the major advantages of a SD card floppy emulator over a standard floppy drive is (or should be) reliability .

The only proper, guaranteed way of doing this is to include enough memory (in the same order of magnitude as the size of a floppy) on board. All data read through the floppy port would be read from the on-board memory and all data written would go straight to the on-board memory. Then the SD card could be transparently read or written simultaneously in an intelligent manner and this could take as much time as necessary. A led would warn the user to not remove the card if there is data in memory not written to the SD card yet. MFM encoding/decoding could also be performed transparently, as well. Unfortunately, an ATmega644 does not have enough pins or processing power to be able to do this. This is the reason why I had chosen a PIC32 for the UFE project. Now, it seems like a cross between the TFE+ and the UFE may be a good idea.