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.

Overclocked the TFE+ ATmega644

TFE+ 80 Columns with overclocked ATmega644

After getting TFE+ floppy read emulation to work, I fixed some bugs and made improvements. Afterwards, I started working on write support. As an optimization that could help with SD card I/O performance, I implemented the multiple block read/write access modes. The idea was to read/write in 2 or 3 sectors at a time instead of just 1. This way, SD card access time overhead is effectively reduced (at least) by half.

The idea worked, but during performance measurements, I noticed that the access time is not the biggest overhead (contrary to what I initially expected). Instead, data transfer time is significantly higher. In my case approximate numbers for read operation would be about 0.5ms to 1ms access time and about 4ms transfer time (for 1024 bytes). This works well for read emulation, but probably not near well enough to get write emulation working.

With some clever optimization of the read routines, I managed to get the transfer time down by about 20-25%. There is even more room for optimization, but the improvement would remain marginal at best. So, I turned to a far more radical solution: Overclocking the ATmega644. This was successfully done in other projects (such as the Uzebox) so I decided to give it a try. I disabled the system clock prescaler and directly used the host ~28Mhz clock instead of dividing it by two.

The results are quite good. The transfer time went down to about 1.5ms, making the total SD card read time around 2ms. After quite a bit of testing, there do not seem to be any stability problems, but it may be a good idea to test with other ATmega644s to see how far this goes. A nice side effect of overclocking was that I was able to implement 80 columns text video display as the image above shows.

It is not all quite so rosy, however. I’ve encountered an interesting problem. All the time during testing, I had my oscilloscope’s ground clip attached to the Amiga’s RF shield. With this, TFE+ runs great, but as soon as detach the clip, TFE+ becomes very unstable, and sometimes does not even boot. I do not think it is related to overclocking, as I’ve seen it before. It probably points to a strange grounding problem somewhere, perhaps something to do with the PCB layout. I’ll investigate this problem further.

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.

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.