Minimalistic switcher

21.02.2007 11:38

Taking a bit of a break from old computers...

Here's an interesting step-down switching power supply I found in a car charger for one of the older Ericsson mobile phones.

It really has a bare minimum of components. If you take out the dual op-amp, which is there only for enhancing user experience (it changes the color of the LED if the charger is in use), you end up only with two transistors, a simple shunt regulator AN1431, a coil and a couple of other passive elements.

AN1431 is used as a comparator here. When the voltage between the REF and A pins drops below 2.5V, no current flows into K and IC1 switch is open. If on the other hand voltage on REF raises above 2.5V, this chip acts as a short circuit and IC1 closes.

So basically the output voltage is determined with the voltage divider R7, R8, R9 and R10 (8.4V in this case). R6 and R5 form a positive feed-back that gives some hysteresis to this comparator so that the switching frequency doesn't get too high.

Posted by Tomaž | Categories: Analog | Comments »

Galaksija: Spaghetti

18.02.2007 1:42

Over-optimization does terrible things to the code...

So far I've disassembled and annotated two large chunks of Galaksija's ROM - the video interrupt handler and cassette loading and saving routines. I had to do that to find out how the original hardware worked. Fortunately these two parts were simple to figure out compared to some other parts of the code that resides in that tiny 4K EPROM.

Some parts are written in a way that I would never otherwise consider possible: you probably heard about parts of code that are also used as ASCII strings, but how about jumps that are no not aligned with opcode boundaries? Apart from a handful of documented ROM functions there is almost no structure in the code. A single RET instruction for example can be used as an exit point for tens of separate functions.

To give you some idea of the complexity involved, here are some call graphs. Each box represents a chunk of machine code. Thin black arrows show jumps and loops, thick black arrows show neighboring blocks of code (where execution goes from one block to the other without a jump), red arrows show function calls and blue arrows show calls by RST instructions.

Circular boxes are entry points (two interrupt vectors and a reset vector), rectangular boxes are code in the first 256 bytes of the ROM that can be accessed by RST instructions. Other boxes represent other parts of the code.

This graph is only approximate of course. Various tricks in the code make it impossible to do an accurate static analysis (especially with my 175 line Perl script). Dynamic jumps and jumps not aligned with opcodes for example are not shown or are shown wrong.

Galaksija ROM call graph

Galaksija ROM call graph (detail)

Galaksija ROM call graph (detail)

Here's the original Postscript file I used to create images above. Make sure you have plenty of swap space and a good Postscript interpreter before you open it.

Posted by Tomaž | Categories: Code | Comments »

Comparing Galaksija and Spectrum tapes

13.02.2007 14:23

Both Sinclair Spectrum and Galaksija use ordinary audio cassettes for program storage. They do however use different modulation techniques to store digital data on the audio-frequency range analog signal that gets recorded to the tape.

Here's how a short program hears like: Galaksija and Spectrum.

First thing you can notice is that on Spectrum, there are two distinct block of data (there's a pause in the middle of the recording). That's because Spectrum puts a separate header in front of each chunk of data it saves. This header contains the name of the block that follows, where in memory it should be located and similar meta-data. Galaksija on the other hand uses a similar header, but saves it in the same block that also contains the data itself.

On both systems, each block of data is preceded by a leader signal. This signal carries no information. It serves only as a kind of reference signal which the software can easily recognize - it tells the computer that a block of data will follow immediately after it. It also helps the software (which is of course running asynchronously to the signal) to synchronize with it. On a Spectrum tape you can hear this leader tone as a pure tone at 800 Hz (the beeeeep in beeeeep-bop). Galaksija's leader is harder to make out. If you listen carefully you can hear that the beginning of the recording is a bit more regular than the other part. That's because Galaksija simply uses some 100 "0" bytes as a leader - there's no specialized tone or frequency dedicated to it.

Two bytes on Galaksija tape

Two bytes on Sinclair Spectrum tape

(These are idealized waveforms of course - in reality the square signals get rounded because of the limited bandwidth of the tape and recording equipment.)

Spectrum uses frequency shift keying modulation to store its data, while Galaksija uses a modulation I can't really place anywhere. The main difference is that while Spectrum uses tones of different frequencies to store 1s and 0s on the tape Galaksija uses short impulses - two impulses for 1s and one impulse for 0s. This means that much of Galaksija signal's energy is in high frequencies (impulses in theory include all frequencies from 0 Hz to infinity).

That is also the reason why Spectrum tapes are much nicer to hear - they mostly include frequencies that are close to human voice (between 800 Hz and 4000 kHz). Galaksija tapes on the other hand hear closer to white noise than a legible signal because white noise also includes all frequency components.

In the end I would say that Spectrum has a much better and more robust modulation scheme than Galaksija. Old magnetic tapes tend to loose higher frequencies much faster than lower ones so I would guess that Galaksija tapes would lose their integrity faster (unfortunately I don't have here any old Galaksija tapes to test this, but I've heard that it can be quite hard today to salvage old Galaksija programs from tape).

It's interesting why Galaksija was designed with this simple modulation scheme instead of imitating Spectrum (I'm sure Spectrum's ROM routines were available to Galaksija authors). The hardware is almost identical in both machines so that couldn't be a reason. One of the articles about Galaksija mentions that a slower baud rate was chosen to improve reliability. However they could have lowered the baud rate while retaining Spectrum's proven modulation scheme. It would certainly be more reliable than making their own. Perhaps it was the limited ROM space.

Posted by Tomaž | Categories: Digital | Comments »

Training a new generation of Windows users

11.02.2007 0:34

Today I saw this advertisement for Microsoft in the newspaper:

It says that the high school I used to attend switched completely from a "heterogeneous system" that used Linux and OpenOffice to a "rich and stable environment" of Windows Vista.

That's sad. When I left that school five years ago things looked like they were slowly moving away from a Microsoft monoculture (at that time that meant Windows95 and friends). School's mail and web servers were already running on some flavor of Unix and publicly accessible computers in the library had Red Hat installed on them. In fact I had my first experience with Free software while attending that school.

Posted by Tomaž | Categories: Life | Comments »

Galaksija: Screencast

06.02.2007 14:37

Here's the screencast I promised. It gives a basic demonstration of Galaksija's graphics capabilities with one BASIC and one machine code program.

The video is encoded with XVid and is around 20 MB in size. It's unedited since I don't have enough patience to deal with open source video editing software (feel free to use the Fast Forward feature of your player to skip the boring parts).

I know this is really badly encoded (on the original recording the picture is sharp). However this is the best I could manage with five tries with transcode.

Update: At some point I realized that hosting video files was a bad idea, so the link above doesn't work anymore. I managed to find the screencast in an old backup. You can now watch it on YouTube.

Posted by Tomaž | Categories: Digital | Comments »

Galaksija: Fine tuning

05.02.2007 21:19

I've been having a lot of fun recently with Galaksija in the past few days (mostly playing Galaksija's version of Jumping Jack, a simple and addictive game I used to play on Spectrum)

Anyway, here's some details about hardware problems I've had with my redesigned board:


My initial tests of the video part (I tested it separately, with the CPU and other integrated circuits removed from the board) showed that switching transistors that were mixing the video signal with the sync impulses weren't able to switch on and off fast enough to show a clear picture and provide good sync pulses.

My original plans were to use BC547 transistors. These are designed for audio-frequency operation, however SPICE simulations showed that they should be more than fast enough to be used in this way. Unfortunately it turned out that SPICE was awfully wrong this time. I'm not exactly sure why. It could be that either SPICE doesn't take into account base charge storage time in it's bipolar transistor models (unlikely) or that SPICE model parameters for BC547 I got from the manufacturer's web site didn't include this information (i.e. who would be stupid enough to use these transistors in an application where switching times are important).

So the mixing stage now uses 2N2222 switching transistors which work perfectly.


The digital part of the circuit had something like 5 wrong connections. They were mostly because of my sloppiness (three times for example I connected an "active-low" reset signal to the ground instead of Vcc). Fortunately these errors were pretty easy to find with my equipment - a wrong connection in the address decoder for example would be much harder locate without a good digital oscilloscope.


After I fixed these things a picture appeared on the TV screen for the first time. Blurred and flipped, but a picture nonetheless :).

The characters were flipped either because the data lines of the character generator ROM were connected to the shift register in the wrong order or there was a bug in the character generator ROM contents. Since I'm a hardware guy and I tend to blame the software for bad things I would say the second reason is more correct :).

Seriously, the scans of the original Galaksija schematics were a bit ambiguous about how the character ROM is connected to the shift. I assumed that MSB on the ROM gets connected to MSB on the shift register. I should have checked if the ROM contents agree with this assumption, but once I got them I already forgot about this problem. In the end it turned out that the original ROM was programmed to be connected the other way around. Since I didn't want to make a new PCB just because of such a trivial mistake I only reprogrammed the ROM with the bit order reversed.

From the software point of view this fix doesn't break any compatibility with the original Galaksija. The character generator ROM isn't directly accessible to the CPU and the reversed bit order of the ROM contents perfectly compensates for the error on the circuit board. The only problem is that a character ROM from an original Galaksija won't work in my version.


After getting the display to work I focused on the only other peripheral device - the audio cassette interface. The output was working correctly on the first test. The input however had a small problem. The original schematics had an RC high-pass filter on the audio input which I directly copied to my design with any checking. Now it turned out that I should have also double-checked this part of the circuit. The original filter was blocking signals with frequencies lower than around 16kHz which meant that it was blocking practically everything that came from the recorder. A quick replacement of one resistor and one capacitor fixed this.

The audio input still requires a relatively high amplitude of the input signal (something like 2 Vpp from my experience) to work reliably. If I knew that before I would add a small audio amplifier to the board - some devices (for example my laptop) won't produce such high levels on their audio outputs.


I also spent quite some time tinkering with the common-collector video amplifier. The blurry picture on the TV made me think that it didn't have enough bandwidth (although SPICE again showed that the high-frequency limit should be well into 10 MHz range - but I wasn't going to be deceived twice). After spending two nights on figuring this out I finally connected Galaksija to a TV that cost more than 20€... And the picture was crystal clear. It turned out that the fantastic TV I bought on the sale had bandwidth problems, not my video amplifier.


The final thing (which I'm still working on) is the little switched-capacitor voltage inverter that provides a low-noise -5V supply for the video amplifier. I obviously miscalculated something when designing it because its transistors are overheating. So far nothing blew out, but transistors are clearly working outside their safe temperature range. I'm certainly not prepared to unleash another unreliable overheating power supply to the wild (although on the second thought, unreliable overheating power supplies seem to be present in all computers I really like - remember TR4 in spectrum?)

Posted by Tomaž | Categories: Digital | Comments »