Retromaster’s Electronics Projects

…related to old computers and other assorted stuff…

Posts Tagged ‘SD card’

Cumulus Stability Issues Solved

Posted by retromaster on December 13, 2010

I’ve finally managed to solve the stability problems exhibited by Cumulus. The solution was to implement buffering very similar to what is found in the AmpliBus.

At first, I noticed once more that attaching Cumulus directly to the Oric expansion bus provides very stable operation. I’ve also noticed that, using a cable connection causes major signal integrity problems, including crosstalk visible in the oscilloscope, even with a very short cable. Operation without a cable connection is not feasible, however, due to mechanical stresses placed on the connectors during SD card insertion/removal and button presses.

The first solution I tried was using better cabling. The 80-conductor IDE cables seemed to be very suitable for this purpose, as the ground lines between the signal lines significantly reduce crosstalk, to allow very fast signalling rates. I made a couple of custom adapters to be able to use the 80-pin cables, simple connections, no buffering.

The result was a definite improvement, but bus problems still existed, occurring at much lower frequency, but occurring nevertheless. To me, this indicated that the drive strength of the bus lines on the Oric side was very low, and/or cable loading on the bus lines had a big effect. The next logical step was to implement buffering, similar to the AmpliBus device. I replaced the adaptor on the Oric side with a new design that buffers all Oric output signals (address and control lines) with three 74(A)HCT541 chips. The 541 is the same as the 241/244 used in the original AmpliBus except for a pinout that makes PCB layout easier.

This time, I obtained excellent results, with absolutely stable operation. I’ve also tested operation over the full length of the cable. The IDE cable is great because it gives very good signal quality and it is still commonly available. The only problem with the IDE cables is that despite higher number of pins on the connector, actually, in terms of usable pins, it is one (or two) pins short, because many pins are grounded on the cable itself. To work around this, I opted to move the /RESET and VCC lines to a separate connector. There will not be any problems with simple cable connections for these lines.

At the moment, I am also testing if a regular 34-pin floppy cable will work with buffering. I’ve made yet another adapter for this purpose. So far it hasn’t worked yet but I’d like to figure out why before giving up. Based on the results of these tests, I’ll decide whether the new PCB design will contain a 34-pin connector or a 40-pin (IDE) connector.

It is still unclear to me how the original Microdisc drive even worked under these conditions. Perhaps, it is the pairing of different families of logic with Cumulus and Oric that caused the problems. In any case, a clock pulse (of just 1 Mhz) that does not look like a square wave is a big red flag, in the first place. Nevertheless, I am glad to have solved the stability problems.

Advertisements

Posted in Projects, Retrocomputing | Tagged: , , , , , , , | 15 Comments »

New Project Started: Cumulus

Posted by retromaster on September 18, 2010

I haven’t posted in a little while, mostly because I was busy working on a new project (called Cumulus). It is yet another SD/MMC floppy emulator project, but with a significant twist: It aims to emulate the WD177x/WD179x series of floppy disk controller chips (FDC), too. So, in essence, it is aimed towards certain retro-computers that originally came without built-in floppy controllers (e.g. MSX, CPC464, Oric, Spectrum, etc.). Back in the day, to add a floppy drive to these computers, the user had to install/connect a FDC card to the expansion port. Therefore, it is impossible to use a floppy emulator like TFE or UFE with these computers without the appropriate FDC expansion, which can be difficult to obtain.

There are significant advantages to integration of FDC emulation within a SD/MMC floppy emulator. First of all, there is no physical floppy disk interface (the 34-pin connector) to worry about, which means that MFM-conversion is out of the picture. Furthermore, there is no floppy disk rotation constraint to satisfy, so writes are much easier to implement and SD card performance issues pose much less of a problem.

The challenge here is that the floppy emulator needs to be directly interfaced to the host system bus, so it is difficult (if not impossible) to get away with using just a microcontroller. Consequently, a clean design dictates that the floppy emulator be host-system dependent (due to different CPU bus configurations, expansion port pinouts, glue logic, etc.). Apparently, the whole FDC card needs to be implemented within the floppy emulator.

For a first implementation (as a proof of concept), I decided to target the Oric Atmos computers… Why Oric? Well, actually, completely by chance… Right around the days when UFE was first released, I had just obtained an Oric Atmos, and a couple of people asked me if UFE could be used with an Oric, which got me thinking, and that’s actually where I got the project idea from. I found out that full schematics of the Oric Microdisc interface were available (along with dump and disassembly of the on-board ROM), and to the best of my knowledge there were no existing SD card solutions that could work with the OS software available (which is seemingly quite impressive, btw).

So, I started working on the Cumulus design. Bearing in mind all the issues outlined above, I went for a CPLD (Xilinx XC95 series) and MCU (PIC 18F series) combination for Cumulus. The CPLD will effectively implement the bus interface of the FDC chip, together with all the additional glue logic usually found on a FDC card. The MCU will communicate commands and data with the CPLD and handle SD Card access and user interface functions. I am sure it will be a difficult combination to debug, but I think I am up to the challenge :).

I have already finished the schematics and PCB layout. Right now, I am at the prototype manufacturing stage, as can be seen from the scan above. There will also be an optional UI daughterboard with an LCD. This is not absolutely required, since the Oric console can also be used effectively to control the emulator. Hopefully, the project will be successful, and it will breathe a new life into these computers.

Posted in Projects, Retrocomputing | Tagged: , , , , , , , , | 19 Comments »

More on SD Card Write Performance

Posted by retromaster on April 5, 2010

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.

Posted in Projects, Retrocomputing | Tagged: , , | Leave a Comment »

SD Card Write Performance and TFE+

Posted by retromaster on April 2, 2010

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.

Posted in Projects, Retrocomputing | Tagged: , , , , , , | Leave a Comment »

Overclocked the TFE+ ATmega644

Posted by retromaster on April 1, 2010

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.

Posted in Projects, Retrocomputing | Tagged: , , , , , | Leave a Comment »