TFE+ A500 Keyboard Part 2

TFE+ A500 Keyboard Interface on Breadboard

TFE+ A500 Keyboard Interface Schematics

Last night I had some more progress with the TFE+ A500 keyboard interface.

As shown in the schematics, there are two connectors: One for the keyboard, one for the A500 mainboard. All lines of both connectors are directly connected, with the exception of the CLK line. The CLK line goes through the 74LS01 which has one input tied to an ATtiny24 pin. When the TFE+ is supposedly inactive, the keyboard MCU simply monitors for key events, but does not do anything. Once it detects the keys Alt-Amiga-Tab being simultaneously pressed and released (TFE+ is supposed to become active at this point), it lowers the clock enable line, which prevents the clock pulses from the keyboard reaching the Amiga. This means the Amiga does not receive the keypresses, but the ATtiny24 still does. Obviously, in this mode, the acknowledgement must be issued by the ATtiny24 since the Amiga cannot do it.

Right now, the only thing missing here is the communication between the TFE+ main MCU and the keyboard MCU, which I’ll soon implement and test. But before that, I’d like to port the existing TFE firmware from the ATmega32 to the ATmega644.

Advertisement

TFE+ A500 Keyboard Progress

Reading the A500 keyboard with an ATtiny24

I received the parts I ordered for TFE+ yesterday evening, so I started working on the Amiga keyboard interface right away.

The photo shows an ATtiny24 on a breadboard with the A500 keyboard connected to it. I wrote a few lines of C code to read the output of the keyboard (as described in the Appendix H of the Amiga Hardware Reference Manual) and after a little bit of debugging, got it to work. When I press space, the red LED on the breadboard lights up (I did not connect the keyboard LED lines, that’s why those are not lit up).

Now that I can capture keypresses, the next stage will be to implement additional circuitry to prevent them from going to the Amiga mainboard when TFE+ is activated.

TFE+ Video Overlay Final

Video Overlay on A500 (Final)

Video Overlay Circuitry v2 on Breadboard

Video Overlay Circuitry v2 Partial Schematics

Here are the latest (and hopefully final) results of my recent work on video generation for TFE+. Instead of the previous transistor-based video overlay circuitry, I decided to use a 74HC245 instead. When the outputs of the 245 are active (VBL low), the 100 ohm resistors either saturate the analog video (from the Amiga) to bright white (for a high output), or dim it (for a low output). When the outputs are disabled (VBL high), the overlay is effectively disabled, with no significant effect on the video output from the Amiga. I could have extended the previous design to use more transistors for driving all three channels, but using the 245 resulted in a simpler circuit with better signal quality.

In addition to improvements in the driver circuitry, I’ve also worked on the video sync part of the circuit. It is quite stable now, with the sync separation performed on the AVR itself. I’ve used the Input Capture feature of the built-in ATmega timers to detect short (horizontal) and long (vertical) sync pulses. The actual video generation is driven by the timers but sync detection is being performed every frame so that sync is not lost during video mode changes.

The reason why there is a second breadboard to the left has to do with how I’ve had to solve the problem of overlay video flickering. Specifically, even after sync detection was fixed, the video kept jerking right/left by one pixel in a (seemingly) random fashion. The original TFE had a 16MHz clock oscillator on board which is what I was using for the TFE+ video tests. The PAL Amiga I am using has a clock oscillator of 28.37516MHz, from which all video signals are generated. The edge detector in the ATmega uses the input clock to detect changes in the input capture signal (which is the sync signal from the Amiga in this case). It seems that the mismatch in the clock frequencies resulted in the edge detection being late or early by one clock cycle, which eventually resulted in the flicker. The obvious (and simplest) solution was to use the Amiga system clock as the ATmega clock. The Amiga clock had to be divided by two since it is too fast for the ATmega. The clock division circuitry is why I had to add the second breadboard. Normally, a single 74HC78 (J-K flip-flop) would be sufficient, but I did not have any, so I had to use a D flip-flop and an inverter instead for testing.

At this time, I consider the video circuitry complete. There may be some additional work for supporting different NTSC/PAL modes, but I’ll leave that for later. I’ll start working on the keyboard MCU and circuitry as soon as I receive the parts I’ve ordered.

TFE+ Video WIP

Video Overlay on A500 (WIP)

Video Overlay Circuitry v1 on Breadboard

Video Overlay Circuitry v1 Partial Schematics

For the new TFE+, I’ve chosen the ATmega644 as the main MCU, as opposed to the ATmega32 that was TFE’s MCU. The reasons are twofold: The mega644 has interrupt-on-change capability on all input pins, and twice the RAM of the mega32. Both features will come in handy.

For the TFE+ Amiga version, I need to make two main changes to the circuitry. The first concerns video generation. It will need to be modified so that it will use the sync generated by the host, and that it will overlay its output on top of the analog RGB generated by the host. The second is for user input. The keyboard-to-host connection will pass through the TFE+ board. There will be an additional MCU (an ATtiny24 in this case) continuously monitoring the keyboard lines and looking for a special key combination that activates TFE+. Once the key combination is detected, the keyboard MCU will divert the keypresses to TFE+, until the user is done interacting with TFE+.

So, I have ordered the parts for the new TFE+, and while I am waiting for them to arrive, I’ve decided to experiment with some of the circuitry changes on the breadboard. The gallery shows some of the work I’ve been doing on video overlay. I’ve tapped into the digital CSYNC output and the analog red output on the Amiga video connector. The output stage is based on a few transistors as shown in the schematic. The CSYNC line goes into the ATmega. The PIX line carries the pixels, and comes from the output of the 74hc166 shift register (controlled by the ATmega). The VBL (Video Blank) line becomes low when there is video output from the PIX line. When VBL is high, the analog output basically becomes isolated from the host output. The function of resistor R3 is to dim the video from the host when VBL is low.

As the screenshot shows, the video overlay works, but not very well yet. The sync input somehow works, but is not correct vertically. Furthermore, it seems it is not enough simply to use just one of the analog lines, because it looks very ugly. At least, I can say that there is no visible loss of quality in the host video output (the photo may be misleading, due to the interaction of the plasma screen with the camera). Anyway, it would require too many transistors to control all three analog lines, so I’ll probably switch to an IC here for the output stage. It will probably result in sharper video output, too.

TFE+ Underway

Before my MF70 to CNC conversion, I had started working on UFE, the successor to TFE. It was intended to be a much more advanced version of TFE, with color touch screen interface, on-board SDRAM and USB host. However, a friend of mine recently gave me an idea for a new floppy emulator that seems much more interesting now.

Except for the lack of write support, TFE works fine, although it is not very practical in certain aspects. First of all, it has to sit outside the computer case, since it has joystick input and video output ports for the user interface (case modding is not something I am very fond of). For this reason, the floppy cable somehow needs to be brought outside the case (as can be seen from the photos on the TFE page). All of this creates a mess of devices and cabling. Furthermore, when you need to use it, you need to pick up TFE’s own joystick and switch the monitor input to TFE video output, etc. Similar problems exist with the other floppy emulators, which have switches on them for the user interface, or simple two-line character LCD displays that are too small to be practical, in my opinion.

So, the idea was to develop a new version of TFE that fixes all these problems. The TFE+ will sit inside the host computer case and it will utilize the host computer’s keyboard for user interaction. It will overlay its own video on top of the host video when the UI is activated. This way, the only external physical access required is for the SD card socket, which can be aligned with the floppy opening in the case to allow this. In addition to all that, I intend to implement write support. The downside to all this is that the user interface circuitry now becomes host system dependent. That is, the ability to control TFE+ using the host keyboard requires that the TFE+ has circuitry specifically tailored for hijacking the host keyboard when necessary. This would require system specific keyboard connectors on the TFE+ board, for example.

It seems to me that the advantages outweigh the disadvantages here, so I have started working on TFE+. My first target is the Amiga platform, and specifically the A500. TFE+ versions specific to other systems (e.g. CPC and ST) may come later. I’ll try to make the main firmware compatible between versions. Other systems may or may not benefit from the new features that TFE+ brings, and those for which I do not design a TFE+ can always use the original TFE (or any other floppy emulator, for that matter).

MF70 CNC Page Up!

I’ve put up a page that describes my Proxxon MF70 to CNC conversion. It contains photos (most of which were already on my blog here), schematics, drawings, board layouts, source code, etc. You can see it here.

Y and Z Axes Version 3

Y Axis Version 3

Z Axis Version 3

Here are the final versions of Y and Z axes of my CNC-converted MF70. The Z axis end-plate consists of two 5mm thick aluminum plates bolted back-to-back. One ball bearing is mounted in each plate, held in place together with the tightened nylon-insert nuts on the leadscrew. To clear the ball bearing on the bottom side I had to raise the end-plate using two nuts as spacers (not shown in the photo). I’ve also replaced the coupling with the new flexible one. It looks and performs considerably better than the previous version.

In the previous version, the Y axis leadscrew was supported at both ends. Instead, I decided to switch to a single side support scheme similar to the Z axis. This has the advantage that, on the other end, the carriage can move all the way to the Z axis column. I had to mill a new standoff for the end-plate in order to make room for the second ball bearing. This standoff is screwed to the lower table base to make it sit perfectly flat. To make sure that the single side support does not cause an issue, I’ve also built a new delrin nut that is a bit taller one one side than the original one, so that it tightly sits and slides on the lower aluminum base of the table, creating kind of an additional support. Overall, this new version of the Y axis is a very good performer and the travel has been extended to around 92mm, effectively doubling the stock MF70 travel.

For the moment, minor corrections and improvements aside, I consider the machine complete. In the future, perhaps I may switch to higher torque motors and more sophisticated drivers to improve on speed and smoothness. My intention now is to put together a project page to document the final state of the machine and provide some technical information, schematics, drawings, etc.

X Axis Version 3

X Axis v3 Front

X Axis v3 Back

Here is the third and hopefully final version of the X axis. In addition to installing the latest parts I’ve milled, I’ve also replaced the couplings with flexible ones from my previous post. There was not a big improvement speed-wise, but this new X axis is quite a bit more reliable and robust than the previous versions. Not to mention that it looks a lot better, too 🙂

Next, I’ll be working on the Y and Z axes. I haven’t yet made a version of the Z axis with ball bearings, and the Y axis could still use some improvements. There is still some work to do, but I think I am getting closer to completing this project.

Software is important

X axis v3 and flexible couplings

To the left of the photo above is the latest part I’ve milled using the MF70 CNC. It’s for the third version of the X axis, out of 10mm thick aluminum. It turned out very nice, but I’ve had to solve some problems before getting this result.

First, the X axis started missing steps randomly, then after a short while it stopped moving altogether. It was definitely not a mechanical problem, so after a little bit of debugging the drive circuitry I found out that one of the optocoupler chips on the breakout board had died. Replacing that chip solved that problem.

The next problem was even more critical that it actually ruined a couple of workpieces until I found about it. I was using a very popular piece of CNC software that runs under Windows XP. However, apparently, it was missing steps! I first noticed the problem when I saw that the two circles that form the bearing housing in the middle were not concentric. I did a test, by issuing a “goto to zero” command after milling the first circle. It was off by almost half a millimeter in both X and Y axes. This behaviour was reproducible and I did not think that it was mechanical. So, I installed EMC2 (together with Ubuntu) on the very same machine. Milling the same part with EMC2 gave the perfect results in the photo above. I suppose that the EMC2 installation coming with a Linux kernel patched with realtime extensions may have something to do with that.

I also found locally some good quality flexible couplings for a reasonable price. I’ll use those for replacing the (rather poor) rigid couplings I am using right now. They have a 6.35mm opening on one end with fits the motor shafts perfectly, and the other end is 4mm. So, I’ll need to machine the leadscrew ends to meet that diameter, but that’s not a problem.