Cold Water

Amiga Debugging with Linux

A "zero modem" adapter between the serial-to-USB and DB9-to-DB25 adapters The AmigaOS offers a debug console as a simple way for debugging. Log data can be written via the linkable Debug.lib, which is also used by all kind of tools like MuForce, Mungwall, or PatchWork. AmigaOS provides a simple internal debugger called ROMWack (which has been replaced by the even simpler SAD in later versions). But also DiagROM is writing diagnostics data via the serial port, which comes in handy when a RAM chip or something in the video area is broken.

The log output is sent to the serial port and can be read by a terminal connected to it. Back in the good old days, not so many hobbyists could afford an actual terminal or a second computer for that, so we used tools like Sushi or Sashimi to redirect the debug output into a Shell window, which worked fine unless the system has crashed too hard.

Today, I assume that almost all of the Amiga owners also have a second computer at home, and if it's just a second Amiga. 😉 This blog article is about how to connect your Amiga to your Linux PC, and get the debug output.

On the hardware side, you will need a construction with a DB25 female port on the one end, and an USB connector on the other end. I use one of those USB-to-Serial converters that can be found on hardware shops for little money. They are often equipped with a DB9 male connector, and are supposed to be connected to peripheral devices (like modems). To connect them to a computer, a so-called zero modem (or null modem) is required, which is just a small adapter that enables to connect two computers directly together by crossing the transmit and receive lines. Finally, we need a DB9-to-DB25 connector with the correct genders, to connect the other end of the zero modem to the Amiga.

This hardware stack is connected to the Amiga's serial port on the one end, and to a USB port of the PC on the other end. Remember to turn off the Amiga before connecting something to the serial port. Unlike USB, the ports of old computers are not designed for connecting or disconnecting devices while the system is powered. It could actually damage the system to do so!

On the software side, we don't need to install drivers on the Amiga. The debug or diagnostics output is just sent to the serial port. On Linux, we can use any terminal emulator. The most prominent is certainly minicom.

The default serial port settings are 9600-8N1 (9,600 bps, 8 bits per character, no parity, 1 stop bit). However, the debug output is just directly sent to the serial port. If you changed the serial parameters on Amiga side, and used the serial.device for something else, the debug output will use the current settings. Handshake must be turned off in any case, though.

Maybe the easiest way is to create a file called ~/.minirc.amiga with the following content (change the pu port value to your actual TTY USB device):

pu port             /dev/ttyUSB0
pu baudrate         9600
pu bits             8
pu parity           N
pu stopbits         1
pu rtscts           No
pu xonxoff          No

On many Linux distributions, the user also needs to be added to the dialout group in order to access a serial device:

sudo usermod -aG dialout $(whoami)

After that, just start minicom with the amiga profile:

minicom amiga

Now you should see all the debug output generated by AmigaOS on your minicom screen. For interactive debuggers like ROMWack, you can also type commands into the console.

To leave minicom, press CTRL-A and then Q. 😉

Amiga 1200 Black Edition

When I found this Amiga 1200, I felt pity for it. The case and keyboard was very yellowed, but what was even worse was the screwed up attempt to fit a Gotek drive into the case. The previous owner obviously tried to open the floppy disk area with some kind of cutter pincers, essentially ruining the case.

The Amiga 1200 was very yellowed. The floppy drive was coarsely cut out, to make room for a Gotek drive.

My initial plan was to whiten the case and keyboard, clean the botched cut at the floppy drive with a rotary tool, and nicely close it again with a 3D-printed part. But then I got a better idea. 😁

The Mainboard

Let's have a look inside first. There is a Rev 1D.4 board in good optical condition. I replaced the electrolytic capacitors, and upgraded the ROMs to AmigaOS 3.2.1.

 The recapped mainboard.

On the bottom of the PCB, I found a copper wire for a so-called "floppy fix". When Escom was producing the final batch of Amiga 1200 systems, Amiga floppy drives were not available any more, and Escom had to find a way to use regular PC floppy drives instead. However, many games and demos with own trackloaders fail to load on machines with this modification.

The original floppy drive of this machine was not existing anymore, and Gotek drives can perfectly emulate Amiga floppy drives, so I decided to undo the floppy fix by removing the botch wire. To restore the original RDY signal, I instead put a wire from pin 34 of the internal floppy connector to pin 1 of the external connector.

The "floppy fix" cuts pin 34 from the original RDY line (not visible here), and instead connects it to the CHNG signal at pin 2. To undo the fix, remove the wire, and then connect pin 34 of the internal port with pin 1 of the external port, to restore the original RDY signal.

Since I was working on the bottom side of the PCB, I should also remove E123C and E125C, to enhance the stability of accelerator boards. However, on this machine these capacitors were not populated, so there was nothing to do.

It was finally time for a first thorough test run. Everything went fine, but then I noticed that the right mouse button was not working on both ports. I wrote a separate blog article about the cause and the fix, but to make a long story short, all I had to do was to replace four resistors with ferrites.

My work on the board was completed after that, and it passed all tests.

The Extras

As with my other refurbishments, I'm not only cleaning the machine, but I also futureproof it with some extras.

First of all: The yellowed case with the ugly cut. I was sure that even with a skillful repair attempt, the case would never look really beautiful again. Also I always wanted to have a black Amiga, so I decided to rehouse the machine into a brand new, black a1200.net replica case instead.

The floppy drive was missing, but instead of the Gotek drive that was there as replacement, I decided to use a Centuriontech GoEX drive. It uses an SD card instead of an USB stick, and comes with a dial encoder, which makes selection of a floppy image much easier. There is also a matching OLED display for it, but for my new Amiga I preferred to use a tiny display that is not that noticeable.

The display itself is one of those 0.91" OLEDs one can find in virtually every maker shop. However it is important to swap pin 1 and 2 when soldering wires to it, as the power pins are swapped on this display type compared to the original GoEX display module.

I then printed an A600 display module case, which luckily also fits on an A1200. I used hot glue to assemble the module, but in retrospect I should have used standard glue instead, since the hot glue softened the PLA of the print. The module is then just clipped into the cooling vents of the Amiga, no need for gluing.

The OLED display with new wiring. Pin 1 and 2 need to be swapped. The backside of the display module, before closing it. The display module put on the Amiga case.

To use this kind of OLED, a file called FF/FF.CFG needs to be created on the SD card, which contains this line:

display-type = oled-128x32

I also added an Indivision AGA MK3 for a pixel-perfect picture on modern TVs via HDMI. While doing so, I found out that the a1200.net replica case seems to have different measures than the original case, so I created a modified trapdoor and holder for this kind of case.

A black trapdoor for the HDMI connector. A holder keeps the HDMI board in place and prohibits that it pivots around the screw.

The computer came with a Marpet Developments M1207 RAM expansion in the expansion port. It got a fresh button cell, and now provides the machine with 4MB of additional Fast RAM, a 68882 FPU, and a RTC.

Assembling

What's missing? The black keycaps that are matching the black case! After many years of waiting they were finally available, and I got a set delivered right in time before Christmas.

The black replica keycaps look awesome! It took a while to replace the original caps with the new ones.

The black case does not include badges, but I found a nice black one from Badgeman.

After that, the Amiga was finally ready for the final assembly.

Everything is in place.

If Commodore had given the choice of the case color back in the 1990's, I would have chosen a black Amiga. And now here it is, an all black Amiga 1200 with a completely new outerior, and modernized interior.

The completed Amiga 1200 Black Edition. Power, floppy, and harddrive LEDs in custom colors. Of course the Amiga 1200 badge is black, too.

Amiga 1000 Restauration, Part 3

In the previous part, I refurbished the keyboard of the Amiga 1000. It was in a bad state, and truly deserved to get its own part. Now I will replace the floppy drive with a Centuriontech GOEX on pills floppy simulator, and then put everything back together.

Floppy LED

The floppy LED of the Amiga 1000 is not connected to the mainboard, but to the floppy drive. The GOEX drive does not provide a similar connector, so I had to come up with a solution. Fortunately, the Amiga made it faily easy.

On all Amiga models, the floppy LED represents the state of the drive motor. It lights up as long as the motor is powered. On the Amiga 1000, the motor of the internal drive is controlled by a /MTR0 signal on pin 16 of the floppy connector. If it is LOW, the motor is powered, and the floppy LED is supposed to light up. The 7438 buffer inside the Amiga has a maximum output current of 48mA, while the LED has a forward current of 30mA, so in theory the LED (and a 120Ω series resistor) could be connected directly to the /MTR0 line and +5V. But I wanted to be on the safe side, so I added an inverting switch using a standard PNP transistor and two resistors.

SVG Picture created as drive-led.svg date 2022/10/31 09:06:35Picture generated by Eeschema-SVG+5V+5V10K10K1M1MBC557BC557Drive LEDDrive LED120R120R~{MTR0}~{MTR0}161610K10KBC557BC557Drive LEDDrive LED120R120RSVG Picture created as drive-led.svg date 2022/10/31 09:06:35

I used a BC557, but any other standard switching PNP transistor will do as well. For the LED, I preferred to have a green floppy LED instead of the original red one. I used a Dialight 521-9266, which has the same dimensions as the original LED. There should be a pullup resistor on the /MTR0 line, but it's also working without, so on my system I left it out for space reasons.

On the GOEX board, +5V can be found on an unused pad next to the voltage regulator. GND can be found at an unused header for an optional encoder.

The base resistor is connected straight to pin 16 of the header. +5V can be taken from a pad next to the voltage regulator. GND is available at the unused encoder header. A bit of hot glue fixes the wires to the board. I replaced the original red floppy LED with a green one, just because I like it better. 😉

On Screen Display

The GOEX drive needs some kind of display, to show the floppy disk file that is currently selected, and other options. My first plan was to glue a tiny OLED display to the front of the case.

However, the "GOEX on pills" model comes with an OSD connector. It reads the CSYNC signal from the Amiga, and generates a pixel signal that is overlaid to the Amiga RGB signal. Depending on the color component the pixel signal is connected to, the OSD text is either red, green, or blue (with the corresponding complementary color as background).

The CSYNC signal can be taken from pin 12 of U6A. The pixel signal is connected to one of the 75Ω resistors: R25 (red), R24 (green), or R23 (blue). The wire must be soldered to that end of the resistor that is closer to the monitor connector, otherwise the OSD overlay will not be visible on white screens.

The CSYNC signal is taken from U6A pin 12. The RGB signal is connected to R24 for a green OSD color.

The other end of the two wires are connected to the respective CSYNC and RGB pins of the OSD header of the GOEX drive. It is also possible to control the GOEX drive with the Amiga keyboard, but I didn't want to do more hardware modifications, especially if it involves soldering wires directly to one of the CIAs. I prefer that I still have to touch the floppy slot for changing floppy disks, even if it's just virtually.

Reassembly

A trained technician should definitely overhaul the PSU, to avoid damage to the hardware or spectacular explosions of safety capacitors. @DingensCGN of the a1k.org forum did an excellent job there. He replaced all electrolytic capacitors, and did a full load test including checking the temperatures of the components with a thermographic camera. A big shout-out to him!

The PSU was overhauled by @DingensCGN at a1k.org. Result of the thermographic camera check: The load resistors are getting rather hot, but that's normal. The other components stay cool.

This Amiga has a separate piggyback board, which I had removed for cleaning and re-capping. It is connected to the mainboard by some headers at different places, which makes reseating it a bit tricky. It is crucial that all headers are properly connected.

The piggyback board must be carefully reconnected.

For the GOEX drive, I designed a 3D printed frame for the Amiga 1000. It holds the drive in its correct position, and also holds the original eject button so the hole in the front is closed. My intention is that the GOEX drive should be as invisible as possible, so the original look of the Amiga 1000 is maintained. I guess I managed that.

GOEX drive on the Amiga 1000 mounting frame. The best place I could find for the grounding. The GOEX drive inside the Amiga floppy frame.

And that's it. The system is fully assembled now.

The fully reassembled system.

I mounted the top shield, attached the front plate, closed the case, and connected the 256KB memory expansion to the front slot.

And then came the moment of truth. I flipped the power switch. The system started up. I expected the 230V PSU fan to be rather noisy, and was very surprised that it is almost inaudible, and could easily compete with modern ultra-silent 12V fans of the same size.

Then the famous Kickstart screen appeared, together with the FlashFloppy OSD.

The famous Kickstart screen, with the magenta OSD from the GOEX drive.

I loaded the Kickstart ADB file from the GOEX drive, and after that I changed to the first disk of the famous Red Sector Megademo. The Amiga just dutifully loaded it.

Red Sector Megademo is loading, here with green OSD because of the dark background.

Everything ran smoothly! The green color of the OSD certainly adds a lot to the 1980s retro feeling of that machine. It looks quite like those OSDs on old TVs or VCRs. 😆

Configuring FlashFloppy

There were two things that were bugging me. The first was that I'd like to run a cold start of the machine as simple as possible, so the GOEX drive should always select the Kickstart ADF first when the system is powered up. The second was that the OSD was shown on the screen for much too long. It should disappear a few seconds after disk inactivity.

Both is easily configured. First, a directory called FF needs to be created on the SD card. Then a FF/FF.CFG file needs to be created, having this content:

image-on-startup = static
display-off-secs = 5

A second file called FF/IMAGE_A.CFG contains the file name of the Kickstart ADF file on the SD card.

Welcome!

And that's it! I am, and have always been, a big fan of the Amiga. I learned a lot on my Amigas, and they were the foundation of my career as professional software developer.

The fully restaured Amiga 1000.

I always considered the Amiga 1000 to be the pearl of my Amiga collection, and I am happy and proud that I got the chance to own such a beautiful machine now.

Amiga 1200 Mouse Button Fix

While I was restauring an Amiga 1200, I noticed that on that machine, the right and middle mouse buttons did not react on both ports. Checking it further, it turned out that it was working with an original Amiga mouse, but failed with my YAMI mouse interface. The mouse interface could not be the cause though, as it is actually working reliably for decades on all kind of Amigas, including an Amiga 1200.

The problem is already known to the community, and also seems to affect other mouse interfaces. The mitigation options I could find so far were:

  • Just use the original Amiga mouse. 😉
  • Modify the mouse interface. There is a "fixed" version available for some of them.
  • Use a "FixRMB" tool. This tool needs to be started first though, so it won't work for reaching the boot menu or in games. It also requires a mouse interface with internal pull-up resistors. (YAMI does not have those, for example.)
  • Some said they were lucky with replacing the Paula chip, but it requires experience in soldering.

None of these options is really appealing to me. I want this Amiga to work like all the others. So I tried to figure out what is the actual problem here, and how to fix it properly.

The middle and right mouse buttons are connected to the POT pins of Paula. These inputs are actually made for analog joysticks, and provide a very simple ADC. The analog joystick charges a capacitor, while a counter inside Paula is taking the time. As soon as the voltage of the capacitor reaches a certain level, the timer is stopped. The position of the joystick can be evaluated by the time it needed to charge the capacitor.

But there is also a digital mode, which is used for mouse buttons. If enabled, a resistor inside Paula pulls up the POT line. If the mouse button is pressed, the mouse switch pulls the line to LOW, which can then be read from the Paula registers.

When an original mouse was connected, the POT line was pulled to 0.9V while the button was depressed. However, when the mouse interface was connected, the line was only pulled to 1.1V. It seems like a tiny difference, but for this Paula chip, it already makes the difference between "button pressed" and "button released".

The affected Paula with "4193" date code. Only a certain batch of Paula chips seems to be affected. This is the reason why this problem does not occur on all Amiga 1200, but presumably only on some 1D.4 boards. This is also the reason why replacing the Paula chip is fixing that issue. On my board, a "CSG 8364R7PL" with date code 4193 is used. I also heard of one more case with a Paula chip of the same production week.

Next question: Why only Amiga 1200 models seem to be affected by this issue, although it is likely that the affected Paula batch was also used in Amiga 4000 production? When comparing the schematics of both machines, there is a notable difference. This is a simplified extract of the joystick or mouse port:

SVG Picture created as paula-pot.svg date 2022/10/10 11:01:53Picture generated by Eeschema-SVG112233445566778899POTYPOTYPOTXPOTXSVG Picture created as paula-pot.svg date 2022/10/10 11:01:53

The difference is in the parts marked with a red circle. They are used as EMI filter. For the Amiga 4000, Commodore has used ferrites there. It is basically just a wire inside a ferrite bead, giving a resistance of 0Ω at low frequencies. In the Amiga 1200 (and Amiga 600) though, Commodore used standard 68Ω resistors, presumably to cut costs.

Together with the pull-up resistor inside Paula, this resistor works as a voltage divider. The switch inside a classic Amiga mouse pulls this divider to ground, giving 0.9V at the POT input, just enough to get detected as LOW.

SVG Picture created as paula-pot.svg date 2022/10/10 19:43:20Picture generated by Eeschema-SVGMouse Button68ΩPOTPaula Pullup0.9V5V0V68ΩMouse ButtonPOTPaula PullupSVG Picture created as paula-pot.svg date 2022/10/10 19:43:20

The mouse interface does not have a real switch though, but a logical output. For example, the PIC16F84 that is used in the YAMI interface provides a LOW voltage of 0.6V. Now the voltage divider gives 1.1V at the POT input, which is interpreted as HIGH by Paula.

SVG Picture created as paula-pot.svg date 2022/10/10 19:43:20Picture generated by Eeschema-SVGMouse InterfacePaula PullupPOT68Ω5V0.6V1.1VPaula PullupPOT68ΩMouse InterfaceSVG Picture created as paula-pot.svg date 2022/10/10 19:43:20

I could not find out if the pull-up resistor inside Paula has a lower resistance in that batch, or if there is a different threshold for detecting LOW levels. Both would be possible.

To fix the problem on my Amiga 1200, I replaced the 68Ω resistors E353R, E354R, E363R, and E364R with the SMD 1206 ferrites that are used in the Amiga 4000. They are a bit bigger than the 0804 resistors, but can still be soldered straight to the pads.

The position of the replacement ferrites at the bottom side of an Amiga 1200 board.

This is just a minor change to the hardware that could be done even by soldering novices (at least rather than unsoldering a PLCC chip). After that change, the mouse interface was working too.

Make sure to replace the resistors with ferrites, not the capacitors next to them!

PS: If you found this article because your Amiga is also having the problem, please send me the date code of your Paula chip. Maybe we can find a pattern of "bad" date codes. Thank you!

PPS: Commodore did the same trick on Amiga 600 machines, so if you have trouble with the right mousebutton on your A600, it's worth a try to replace E353R, E354R, E363R, and E364R.