TFE+ Floppy Read Emulation Working

TFE+ Rick Dangerous title screen

TFE+ Rick Dangerous during loading

After a bit of debugging during the weekend, I managed to get the TFE+ floppy read emulation to work. The photos show Rick Dangerous in action and TFE+ UI overlays on top of them. They were taken with a camera from an older SD plasma screen, in reality the video output is nice and clear, and TFE+ overlays do not affect the quality.

At the moment, the TFE+ is functionally almost at the same level as the original TFE (except a few remaining bugs to work out). To make use of the extra memory of the mega644, I’ve enlarged the video output by an additional 5 text lines to 40×30. The image with the workbench shows the “no floppy in drive” message, because, just like the original TFE, video output and floppy emulation cannot be active at the same time, so TFE+ behaves as if there is no disk in it while the user interface is active. Once an image is selected the TFE+ user interface disappears and floppy emulation becomes active. This behaviour is due to a hardware limitation.

Once the few remaining bugs are sorted, I plan to shoot a video of how the whole thing works. I’ll probably soon put up a web page for the TFE+ project itself as well. I am also going to work on the more advanced features such as write support and on-board MFM encoding.

TFE+ Progress

TFE+ Prototype Board connected to the A500

TFE+ Settings Screen

Here is the TFE+ prototype board fully populated and connected to the A500 mainboard. The ribbon cable carries the system clock as well as video color and sync lines. On the mainboard end, it is soldered to appropriate points. This is good for reliability reasons, but I have also ordered some inexpensive test hooks that can be useful when easy installation is desired.

So far, I’ve got the video output, the keyboard control and the buzzer working. There might be some minor problems but hopefully nothing unsolvable. The photo on the left shows the settings screen, which I managed to navigate to using the keyboard. I haven’t tested the SD card access (and floppy emulation) yet, partly because I seem to have misplaced my SD card adapter. There is some new code to be tested there, as the floppy data output is now handled through the ATmega644 USART module (in SPI mode) as opposed to the external shift register in the previous TFE. Once that works, I’ll move on to more advanced features such as write support and on-board MFM decoding.

One of the tricky parts here was the communication between the keyboard MCU and the main MCU. The keyboard MCU detects keypresses for a set of keys (arrows, return, ESC) and when there is a change, it places the new keyboard state (8-bits, one bit per key) in the USI data shift register, which is operated in the external clock mode. The main MCU generates the clock for the USI shift register in software and reads the keyboard state output from the keyboard MCU. This way operation of the keyboard MCU remains independent of the keyboard state reads. To prevent clashes, during shift register content updates, the keyboard MCU asserts the clock line for a while. The main MCU looks out for this situation and restarts the read operation if an update occurs in the middle.

Built a Chu Moy Headphone Amplifier

My Chu Moy Headphone Amplifier

Just before I started working on the TFE+ hardware/firmware combination, I thought that improving my working environment was in order, so I took up a little side project. The sound output of the desktop I use for listening to music while working on electronics projects is a little low (especially when driving large headphones) and I thought a headphone amplifier would help. So, I decided to build a Chu Moy Headphone Amplifier.

The original design by Chu Moy is a very basic design around the OPA134 audio opamp. I used the OPA2134 (the dual version) instead to save a little space and simplify wiring a little. I am not using a battery to power the circuit but the simple voltage-divider based power supply splitting scheme is there. The input capacitors are larger (in capacitance and size) than those used in the original design, which should help with the low end frequency response. I did not include any a volume control pot as the desktop sound card volume control will suffice.

The amplifier is able to reach very high (unlistenable) sound volume. It is even able to drive my AKG 240 DF headphones (notoriously high input impedance at 600 Ohms, very difficult to drive) without much effort. The frequency response seems OK to my ears, although I am not able to describe these things as vividly as some “audiophiles” are able to. Overall the results are quite good. Unfortunately, however, there is some background hiss that is noticeable during silence although it is not very disturbing. This could probably be attributed to the rather high opamp gain and my crude construction methods, and a better power supply could definitely improve things. That said, I think that most of the hiss might actually be coming from the audio source. Nevertheless, the thing sounds good enough that I think this warrants a dedicated PCB in a proper metal case.

Built TFE+ Prototype Board

TFE+ Amiga Version Prototype Solder Side

TFE+ Amiga Version Prototype Component Side

I finally managed to build the TFE+ Amiga version prototype board. I fully assembled the board but did not install the ICs in their sockets yet.

Apparently, I did a rather sloppy job here. The toner transfer and etching went OK (done using glossy paper instead of the usual PnP Blue). I wanted to apply a soldermask afterwards and that’s where things went wrong. It seems I overcooked the board after applying the glass paint (that’s the reason for the discoloration of parts of the board) and I was not able to remove the masked areas after curing. So I removed the paint layer altogether, and just applied the protective flux layer instead. Well, it’s just a prototype, anyway.

Now, it’s time to get the firmware working on this board…

TFE+ Prototype Manufacturing Issues

It’s been a while since my last post. Most of this time I’ve been trying to deal with the problems I encountered making the TFE+ prototype PCB.

Since I use a CNC to drill the PCB holes, my process is that I get the holes drilled first and then apply the toner transfer. For this to work, it’s imperative that I get the laser printer printout to match the CNC-drilled holes. Previously, I had tested with some smaller boards, and I managed to obtain some fine results. The TFE+ board is quite a bit larger and this is where the problems started. It seemed that a non-linear error kept creeping into the printout and despite trying many different things, I never managed to get a good match.

The printer I’ve been using is a Samsung ML-1610. It’s a fine entry level printer and it has worked well with toner transfer during time I did manual drilling. Once I started having dimensional accuracy problems after the transition to CNC-drilling, I took a micrometer and measured the printout (on plain paper). It seemed that one side of the printout was smaller by almost a millimeter! The error was consistently there in subsequent printouts I took. I have no idea where this error comes from. I am sure that it was not in the source image. It could be a software/firmware error, or it might be that the some parts of the mechanism have worn-out (it’s more than 3 years old now). Or perhaps the printer was never intended to be very accurate (which is fine for a printer in its class).

Deciding that it is time to get a newer (and better) printer, I did some research and came up with the Kyocera Mita FS-1100. It is significantly more expensive than the ML-1610. But it’s built like a tank, it has a much higher speed and 1200dpi resolution, and it seems it may be more economical in the long run. In many ways it reminds me of the older Laserjet line of printers from HP. Last night I did some tests with laser printer transparencies (just to see). The printout from the FS-1100 still needed some scaling, but there was no non-linear error and I managed to get an almost perfect match. Far better than what I got with the ML-1610.

It still remains to be seen whether the FS-1100 output will work fine with toner transfer (e.g. with PnP blue paper). Over the weekend I’ll do some more tests, and if all goes well, I might even have a prototype PCB in my hands next week!

TFE+ A500 Version Schematics (Preliminary)

TFE+ A500 Version PCB Layout (Preliminary)

Having tested all the new circuitry over the weekend, I finished the schematics and board layout for the TFE+ Amiga version. The board is single-sided, with a few jumper wires (mostly for power distribution). This week, I plan to make and assemble a prototype and if all goes well, start with the modification of existing TFE firmware to match the new board.

The transition to ATmega644 turned out to be even better than I expected, as a simple comparison with the old TFE schematics will quickly reveal. First of all, the mega644 has a new “USART in Master SPI mode” functionality that allowed me to eliminate the 74HC166 shift register (and a potential 74HC164 for write support). Previously, I had experimented with the ATmega32 SPI module for video and floppy read support. It was not usable for this purpose since it was not able to continuously shift out data at a constant rate (most likely due to the data not being buffered). In contrast, all USART transactions in ATmega644 are double-buffered, and a breadboard test confirmed that I could obtain exactly the same video output as that with the external shift register.

Another useful feature of the mega644 is the “System Clock Prescaler”. With the mega32 breadboard tests in previous posts, I had to use a clock divider circuit to be able to use the Amiga system clock. With the prescaler in ATmega644, I was able to eliminate all that circuitry and simplify the board design even further. In fact, this makes it possible to (optionally) overclock the mega644. I’ve seen some projects that do this, so it is certainly possible. It could be useful for High Density disk emulation or on-board (or on-the-fly) image conversion support.