UFE Firmware Progress

UFE UI New Main Menu

I have completely overhauled the UFE user interface. Now, upon activating the UI, a menu displays options that are available for all drives, including image insertion and ejection and write protect settings. While writing this, it has just occured to me that it might be useful to display the name of the currently mounted image for each drive. So, I’ll keep doing little UI improvements here and there it seems.

In addition, I’ve implemented full FAT32 support. There was a limitation carried over from the old TFE firmware, that the FAT32 filesystem needed to be defragmented, that is, “cluster following” was not properly implemented. This is no longer an issue with the UFE firmware, and furthermore, I’ve implemented support for directories as well.

Near the end of last week, I ordered the parts for the new hardware revision. The order basically consists of the newer PIC32MX575 which seems to be a just little more suitable for this project (with 3 SPI ports instead of the 2 for PIC32MX460). Until the parts arrive, I’ll keep making improvements to the firmware.

Advertisement

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 Write Access Working

The last crucial piece of main UFE functionality, write support, is now working (no pictures this time as it’s a little difficult to document that way).

In XCopy, I am able to copy floppies successfully. I am able to read a floppy in (also emulated by UFE), then mount an empty image in UFE (filled by zeros), and let XCopy write onto this image. At this point, the written floppy resides in the SDRAM, and works just like a normal floppy image. I can do a checkdisk in XCopy, or boot from this copied image. I can also dump it to the SD Card in raw MFM format.

I’ve tested this with a few ADFs and there are no apparent problems. I have not tested with any program other than XCopy yet, so I am unable to say anything about compatibility, although I do not think this will be a big issue.

At the moment, the UFE firmware does not do the conversion to ADF when writing to the SD card, but this should not be a problem, either. I plan to have the SD Card writes be performed automatically and transparently: Once the host turns the drive motor off, the data in SDRAM (modified tracks only) will be written automatically to the SD Card. One of the LEDs on the UFE board will be used to warn the user that a write operation is in progress, just like the activity light on a real floppy drive. It should not take more than a few seconds to write the whole floppy image to the SD card.

Yesterday, I also investigated the idea of having one UFE to emulate two drives (i.e. on the Amiga, having DF0 and DF1). This seems to be possible in theory, as there is enough space in SDRAM to hold up to four DD MFM images. I am not sure that four drives can be supported though, and maybe it’s not practical anyway, as internal floppy connectors on most systems have only two select lines. In any case, it seems that the Amiga I am using for the tests has a hardware issue as it’s unable to pull the SEL1 line down. I am going to see what can be done with multiple drive emulation once I fix this issue.

PIC32 Page Up

I’ve just put up a new page on PIC32 microcontrollers. The only thing there right now is a page on interfacing SDRAM to PIC32 (including source code), but I plan to add more soon.

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 SDRAM Working

SDRAM Debugging Setup

SDRAM Debugging O’Scope Shot

After some intense debugging, I managed to get the SDRAM on the UFE board to work.

First, I replaced the SDRAM chip with another one from the same module. At the same time, I also reworked the PIC32 solder connections. Unfortunately, that wasn’t enough. Then, I decided to make use of the logic analyzer on my oscilloscope. Lacking the proper means to attach the probes to the signal lines, I had to employ a little trick. I soldered very thin enameled magnet wire to the SDRAM pins. I soldered the other ends of the wires to a header, to which I attached the logic analyzer probes. I also had to slow the PIC32 clock quite a bit so that my 40Mhz oscilloscope would be able to show what was going on.

The oscilloscope shot shows the moment when I realised where my mistake was. The upper four signals are the SDRAM control lines, the red one is the clock, and the analog signal is the DQ0 line. It seems that the “read” command was registering with the SDRAM, but I was reading the data lines too early, I needed to wait for another clock edge to read it. Fixing that in the code gave me the right result. What a relief!

Anyway, several bug fixes later, now I am able to read and write the whole SDRAM chip without any apparent problems. I can fill the whole memory with a pseudo-random pattern and I am able to read it back. I haven’t really measured the throughput yet, but I am quite sure that it will be more than enough for my application. The SDRAM is clocked at close to 20Mhz (sysclk/4) and I use a burst size of 8. It could be clocked faster, even at sysclk perhaps with a slightly different design. The throughput would not increase as much though, since there would be more NOP cycles while the PIC32 is preparing data, etc. Anyway, there is even a little room for optimization in my current design. For example, my arrangement of the address lines turned out to be suboptimal, so I plan to fix that in the next PCB revision, to provide a slight increase in throughput.

I plan to test the SDRAM access functionality some more and implement some missing features such as the self refresh mode. Afterwards, my intention is to release source code so that it can provide an example for those who would like to interface SDRAM to a PIC32 (or any other microcontroller without a built-in SDRAM interface for that matter).

UFE SD Card Access Working

UFE SD Card Directory View

I’ve managed to get the SD card access working with the new UFE board. It was a mostly straightforward port from the TFE firmware, except for changing a few bits here and there related to the underlying SPI module usage. I have not implemented DMA yet, but I do not think that is going to be a big deal.

It is probably not clear from the photo above, but I also fixed the video flickering issue I mentioned in my previous post. It turns out that the SPI clock is free-running and SPI output gets synchronized to that clock and that made the video output start a pixel late sometimes. Reinitializing the SPI module on each video line did the trick. I chose to have 72 text columns per line this time, as that seems to be achieve a good balance between readability and amount of text shown, at least on my screen. I also implemented DMA for video output, lowering the CPU load. The CPU is not completely freed of video generation tasks however as it needs to prepare the data for the next line while DMA is outputting the current line.

Getting those out of the way, I’ve spent most of the weekend on getting the SDRAM to work. Unfortunately, I haven’t had any success. There are still a few things I would like to try with the software, before I take the drastic step of replacing the chip itself. I desoldered the chip from a SDRAM module that I know to be working beforehand. I might try soldering the chip back to the module just to try if it would still work on a PC. This way I would know at least if the chip is still intact.