UFE New PCB Assembled and Working

UFE Rev A2 Installed on Amiga 500 (Cover Off)

UFE Rev A2 Installed on Amiga 500 (Cover On)

Over the last couple of weeks, I’ve managed to assemble the new UFE board and make the necessary changes to the firmware to make it work with the PIC32MX575. I’ve also mounted the board in the floppy slot of an A500 to see how it would actually look. The result is quite nice and it is quite practical to operate with the A500 top cover closed. I’ve had to hot glue a couple of threaded posts to the base of the A500 case to be able to screw the board, but other than that, no case modding is necessary.

I am a little disappointed with the PIC32MX575 though. First of all, the I2C module has an embarassing bug which causes the module not to assume control of the output pins properly. To add insult to injury, the workaround specified in the errata document seemed to be insufficient in my case. In addition to manually declaring the pins as output, they also needed to be configured as open-drain, otherwise it did not work. Another issue (that still remains unresolved), is that I could not get the “IDLE” power save mode to work properly. The behaviour here seems to be different than the PIC32MX460, but I could not figure out what exactly is different. The IDLE mode is used by the UI code to wait for the vertical blanking period for video output. The code that worked fine on the 460 does not seem to work on the 575, so I’ve had to (hopefully temporarily) replace the IDLE mode with busy-wait loops.

Nevertheless, most of the basic functions of the UFE work fine in the new board. There is one remaining problem with the write clock recovery circuit that I could not get the component values right. Hopefully, I should be able to sort out that problem tonight. Afterwards, the first order of business will be to create a video of the UFE in operation and put up a new project page for it.

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.

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.

UFE Prototype Assembled

UFE Prototype Assembled

Here is a photo of the UFE prototype, fully-assembled. I am able to program the on-board PIC32 using the PicKit2 programmer. The clock line is connected to the Amiga. Actually, while I was taking this photo, the board was running a tiny test application that alternately blinked the two on-board LEDs. The PIC32 is running at ~75.6Mhz here. The system clock is derived from the 28.375Mhz Amiga system clock, by first dividing the input clock by 6 (to get a ~4.73Mhz clock suitable for the PIC32 PLL) and multiplying it by 16. I am hoping that using the PLL will reduce or eliminate the clock jitter as this was a problem in the earlier TFE+ design, partly due to the relatively long cable over which the clock signal is transmitted. Being able to run the PIC32 at a speed so close to the maximum is very good news, but of course there is no guarantee that problems will not occur with the much more complex setup that will ultimately arise during firmware development.

It is not all good, however. It turns out that my PCB making techniques are still in need of some finetuning. During the soldering process and the cleaning afterwards, the soldermask crackled and popped in several places. I thought it was due to the soldermask not being cured well enough, so it did some tests with a spare, new PCB. It turns out that a thicker layer of paint, plus a higher curing temperature created a much stronger soldermask. During mask removal, the soldermask seems to lose some of its strength, but it works well to cure the board a second time after this step. This step seems to really strengthen the soldermask and that way it is able to withstand soldering and cleaning. I’ll do some more tests to confirm these first findings and finetune the process. Nevertheless, it seems that even in its weak state, a soldermask like this is better than no soldermask at all, since it greatly protects the PCB, especially from the usual trace lifting problems that I frequently experienced previously.

Another issue I encountered with the prototype board was that some of the vias lost connection after the soldermask curing. I am guessing this is due to thermal expansion. I solved the issue by scraping the soldermask above the vias and soldering them on both sides (For hidden vias, I removed the excess solder using a solder wick). This way, a very reliable connection was formed. I’ll soon be updating the page on PCB making with my latest findings.

New UFE Design Ready

New UFE Board Layout Top Side

As I’ve indicated in my previous post, I’ve been working on a new floppy emulator design, and it’s ready.

The main idea is to implement (hopefully) fool-proof write support by including enough memory to store at least one MFM-decoded floppy image on board. Obviously, your average 40-pin MCU will not be able to access that much external memory, so it was necessary to switch to a more powerful MCU with more pins (in this case, a PIC32). Although static RAM would be simplest to use, they either do not come in the size required or when they do, they are too expensive. So I decided to use SDRAM instead, as there is still a lot of them out there available cheaply in the form of memory modules.

The PIC32 does not have a built-in SDRAM controller, which makes things a little complicated. Luckily, in this project, the external RAM is used like a fast storage area rather than being randomly accessed. So, the plan is to emulate the SDRAM controller in software. It will be accessed quite a bit slower than the usual 100/133Mhz which makes this somewhat easier. In theory, the PIC32 should be able to handle this task, as in comes with a lot of extra computing power, including a built-in DMA controller.

Besides the addition of memory, this new design is a hybrid between the TFE+ design and the older UFE design in terms of features. It features video output for the user interface, just like in the TFE+. The host system’s keyboard will be used to control the emulator, but the keyboard interface is moved to a daughterboard to make the base design host independent. The basic design elements in the original UFE design are in place (PIC32, SDRAM), but SD card is the disk image storage medium instead of a USB flash drive, mainly to reduce complexity of the firmware and simplify PCB layout a bit.

I’ve already started building the PCB for this design and it’s nearing completion. If all goes well, I may soon have another post with the pictures of the actual board.

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.

UFE Board Assembly Progress

UFE board with PIC32

PIC32 recognized

 

The pictures above show the UFE board with quite a few components (including the PIC32) assembled, and the PIC32 being recognized by Microchip’s PicKit2 programmer. I haven’t tested actually programming the PIC32 (since I do not have any appropriate binary to program it with), but I do not anticipate any problems at this stage. I’ll go on with assembling the rest of the components (possibly with the exception of the SDRAM, which I’ll leave for later). I might try writing a few lines of test code to blink a few LEDs I’ll connect to the LCD daughterboard connector. Soon, I plan to move on to building the LCD daughterboard.

While the UFE board seems to work fine at this point, the looks of it leave much to be desired. I used the old trick of painting the board with rosin-based flux and drying it. Once dried, it is no longer conductive (and sticky), and it protects the board from corrosion rather well and obviously, you can solder through it. The problem is that I prefer using the solder-and-wick method for SMD chips, and that results in a mess (that you can see in the picture above) that you cannot clean (otherwise you’ll remove the protective flux layer as well).

So, it would be great if I could apply a soldermask on my PCBs. Now, I know that it is possible to use UV-cured inks or films for the soldermask application. But they are somewhat difficult to obtain for me, and I am quite used to the toner transfer method and I am reluctant to add a radically-different step. While looking for an alternative on the net, I came across some great results obtained by using heat-curable Pebeo Vitrea paint as a soldermask (masked using toner).

Basically the glass-paint soldermask method works like this: 1. The PCB solder image is applied on the etched PCB using regular toner transfer. 2. The PCB is painted using the Pebeo Vitrea paint and cured. 3. The toner gets in between the PCB and the paint, preventing adhesion of the paint and effectively masking the areas to be soldered. 4. Removing the toner using acetone leaves the solder areas with bare copper and the rest of the paint intact.

I’ll experiment with this method while building the UFE LCD daughterboard and post the results. Hopefully, I’ll be able to obtain the Pebeo Vitrea around here, but otherwise, I guess other kinds of heat-curable glass paint might work.