Some impressions of the Christmas Garden 2022 at Pillnitz Castle in Dresden. I was lucky on my visit there, because the snow that was falling the day before nicely contributed to the mystical atmosphere of the place.
Continue reading...
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 CD32
Unlike other Amiga models, the CD32 has no dedicated RS-232 port. Instead of that, it provides a simple serial interface at the Aux port that is connected to Paula's UART pins internally.
To build an adapter, you need a PS/2 cable (e.g. from an extension cord or an old PS/2 input device) and a MAX3232 based TTL-to-DB9 level converter. These converters can be found at online marketplaces for a few Euro.
Cut one end of the cable and connect the wires to the converter like that:
- Pin 2: TXD
- Pin 3 (and the shield): GND
- Pin 4: VCC
- Pin 6: RXD
Leave the remaining two wires unconnected, and check for correct polarity before connecting the wires to the converter!
The CD32 does not provide any control and handshake signals, but fortunately they are not needed for debugging and diagnostics purposes.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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 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!
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.
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.
And that's it. The system is fully assembled now.
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.
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.
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.
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.
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".
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:
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.
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.
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.
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.