Retromaster’s Electronics Projects

…related to old computers and other assorted stuff…

Posts Tagged ‘TFE’

UFE A500 Keyboard Daughterboard 2

Posted by retromaster on June 10, 2010

I’ve fixed the problems in the first A500 keyboard daughterboard I’ve made. Here are some images of the new one, including one that shows how it looks when installed on an A500. At the moment, it works fully with the UFE mainboard. The missing I2C slave writes have been implemented. UFE is fully controllable from the A500 keyboard.

There is one problem, though. The Amiga keyboard protocol requires that the transmitted key event be acknowledged by the Amiga once the full 8-bits of data has been received. If this acknowledgment is not received, the keyboard goes into “lost sync” mode. It stops sending key events, until sync is restored.

Normally, this behaviour poses no problem for UFE, but in some rare cases, some (poorly written) cracks/loaders temporarily assume complete control over the system, causing the acknowledgment to be not sent. For example, the Turrican 3 cracked loader flashes the screen to request the user to swap disks. When in this mode, the loader only checks if the disk is replaced and ignores everything else, including keyboard events. Since the keyboard becomes unusable in this mode, it becomes impossible to activate UFE.

I can think of some solutions to this problem. Probably, one of the more robust ones is to check for the “lost sync” condition in the keyboard daughterboard firmware. If the host fails to respond to the “lost sync” condition after eight 1s have been clocked in, let the keyboard daughterboard acknowledge the last key event. Since the keyboard always retransmits key events that are not acknowledged, no key presses will be lost. Eventually, the host will be able to handle keyboard events properly, and everything should be back to normal.

On a side note, to manufacture this new board, I’ve used a new “drilling technique”. Instead of aligning the toner transfer paper to CNC drilled holes, I did it the other way around. I first did the toner transfer (with holes in pads) and etched the board. Then, using CNC coordinate measurements for four corner pads, I computed the transformation from PCB software coordinate space to etched board CNC coordinate space. This transformation compensates for scaling, translation, rotation and shearing. I’ve written a Python script to do the computation and integrated it within my g-code converter script. As the PCB scans show, the results have been excellent.

I’ll soon update my “Making PCBs” page with all the new experiences I’ve obtained and I’ll release the Python sources for the scripts I use. I am also going to take some scans while I make the new PCB revision for UFE and update the page with those as well. They should be quite an improvement over the poorly lit photos I’ve got there right now.

Advertisements

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

UFE SDRAM Working

Posted by retromaster on May 6, 2010

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).

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

UFE SD Card Access Working

Posted by retromaster on May 3, 2010

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.

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

UFE Prototype Assembled

Posted by retromaster on April 26, 2010

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.

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

New UFE Design Ready

Posted by retromaster on April 19, 2010

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.

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

Floppy Write Clock Recovery

Posted by retromaster on April 14, 2010

To implement write support for the floppy emulator, the write clock must somehow be recovered from the write data input. The simplest (and probably least robust) way of doing this is in software. When the write enable line becomes active, a “change notice” interrupt on the write data input can be used to detect the first negative-going edge. When triggered, this interrupt would initiate the first SPI receive operation with the proper timing. The rest of the SPI receives would follow, and hopefully there would be little or no jitter on the data (since this is coming from the host). This assumes of course that the host sends data with a perfect 2us interval, which may or may not be the case.

With a little bit of additional circuitry, it is possible to implement more robust clock recovery, which is what I’ve been experimenting with the last few days. I’ve come across a simple circuit based on the 555 timer (CMOS version) used in the Amiga Floppy Reader project. The 555 timer is used to generate the 500khz write data clock, but the write data line is connected to the reset input of the 555 IC. is synchronizes the clock output to the negative-going edges of the write data signal, effectively recovering the clock from the data.

The tiny little board in the photos shows my test implementation of this clock recovery circuit. Early on during my first tests, I realized that there is a minimum width to the reset pulse. This causes the clock pulse to be late. It almost overlaps the positive-going edge of the data signal. Therefore I added a second 555 to delay and enlarge the low pulses of the data signal. That did not work as well as I expected, as the delay introduced by the 555 turned out to be a little too large, as the oscilloscope shot shows.

Another idea that I experimented seems to perform better. Instead of using a 555 for delaying the data signal, a 74hc14 is used to buffer the signal and an RC low pass filter is used to introduce a phase shift. Obviously, a 555 takes up less board space than a 74hc14 and that is why I was experimenting with two 555s instead. A small advantage of the 74hc14 circuit is that there is no need to invert the incoming signal on the MCU side.

As it should be evident from this post, I am already working on a completely new design that will use a PIC32 and on-board memory to fully implement read and write emulation. This is actually a cross between the TFE+ and UFE that I mentioned in one of my previous posts. That is why the test PCB I’ve made uses SMD parts and has a red soldermask, as it was a little exercise for manufacturing the new design.

Posted in Projects, Retrocomputing, Uncategorized | 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 »

TFE+ Floppy Read Emulation Working

Posted by retromaster on March 29, 2010

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.

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

TFE+ Progress

Posted by retromaster on March 25, 2010

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.

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

Built TFE+ Prototype Board

Posted by retromaster on March 20, 2010

I finally managed to build the TFE+ Amiga version prototype board. I fully assembled the board but did not install the ICs in their sockets yet.

Apparently, I did a rather sloppy job here. The toner transfer and etching went OK (done using glossy paper instead of the usual PnP Blue). I wanted to apply a soldermask afterwards and that’s where things went wrong. It seems I overcooked the board after applying the glass paint (that’s the reason for the discoloration of parts of the board) and I was not able to remove the masked areas after curing. So I removed the paint layer altogether, and just applied the protective flux layer instead. Well, it’s just a prototype, anyway.

Now, it’s time to get the firmware working on this board…

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