Posted by retromaster on June 13, 2010
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.
Posted in Projects, Retrocomputing | Tagged: ATARI ST, Floppy Emulator, UFE | Leave a Comment »
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: Amiga, ATARI ST, ATmega644, PIC32, SD card, TFE, UFE | Leave a Comment »