Retrochallenge 2017/04

It is rumoured that Bill Gates said the Motorola MC6809 CPU was the best 8-bit CPU ever produced. This might have been the case until Hitachi came out with the HD6309. This CPU was thought to be a clone of the MC6809. However, in April of 1988, the Japanese “Oh!FM” magazine published an article that showed the HD6309 has hidden features! It wasn’t until a few years later that these features were discovered outside of Japan.

The HD6309 has additional registers, offers interruptible block transfers, executes some instructions faster and even includes a hardware 16×16 multiply operation! This then, must be, without a shadow of a doubt, for various degrees of doubt, YMMV, the ultimate 8-bit microprocessor ever made!


So naturally, I went on eBay an purchased a few of these processors. They should arrive in a few days — I hope.


When trying to get things done, nothing is better than a deadline! So I have entered the Retrochallenge 2017/04 contest to build a computer around the HD6309. The object of the challenge is to “do something interesting with retro hardware or software” and blog about it. It commences 1st April 2017 and runs until 30th April 2017.

Let the fun begin!


Using Forth for testing hardware – Part 1


In my day job, I develop electronic systems,  many of which have embedded microprocessors. The prototype or production systems need to be tested in both the prototype/development phase and during production at the manufacturing plant. These tests can be anything from “does this button work?” to “is the noise on this power rail below 50mV?”. In both cases, software on the system itself and an external PC is used to drive the tests. The external PC is the master controller and the system-under-test responds to command from the PC.

The commands sent from the PC are pretty simple: “pull this pin high/low” or “produce a sine wave on this DAC output”. So simple, in fact, that developing testing firmware for each product seems superfluous. There are, however, always specific tests unique to one product which means that, in practice, every product has its own testing firmware that has to be written an maintained.

In an attempt to reduce the workload of developing the testing firmware, I looked around for a more generic approach to writing testing software. I hope I’ve found a solution in Forth.

Wat is Forth?

Forth is a stack-based extensible programming language and virtual machine invented by Charles Moore. A complete Forth system also has an interpreter through which programs can be interactively created, much like the BASIC interpreter on early personal computers.

The advantage of Forth is that most of the Forth system is programmed in a small subset of Forth itself, making it largely self hosted. This means that a Forth system can be created with modest effort, even in assembly language. In fact, this was one of the primary goals of the system — to be able to get a system up and running quickly when no other compilers or languages are available.

Nowadays, C compilers are ubiquitous and it might seem that there is no need for systems like Forth. However, Forth has one big advantage over compiled code: it is interactive.

In an automated hardware test setup, the interactivity is used by the external PC to control the device under test (DUT). This way, the test engineer can create, add or change test procedures without having to change the software running on the DUT — at least, that’s the idea!

Forth stacks

The Forth system has two stacks: a data stack and a return stack. The data stack is by far the most important stack and is therefore referred to as the stack.

Forth commands, also called words, reside on the data stack. When a word is executed, the Forth virtual machine puts the next command’s address on the return stack. When the command has been executed, it pops the address from the return stack and continues executing the next command. The return stack is also used to store the parameters of do..while loops.

Say we want to add two numbers 123 and 456. In Forth this is achieved by entering:

123 456 +

The numbers 123 and 456 are pushed onto the stack first, followed by the forth word ‘+’. The virtual machine pops the first word off the stack, which is ‘+’ and executes it. In turn, the ‘+’ word pops two numbers from the stack, in this case 123 and 456, and adds them together, pushing the result onto the stack.

Forth words

A Forth system has a number of primitive words. The actions associated with these words have been hard-coded into the virtual machine. Some do simple data or return stack manipulation, while others perform arithmetic operations or print data to the console.

A Forth system is extensible by defining new words, each of which are made up of words that have already been defined. These new words are added to the Forth dictionary.

For hardware testing, it makes sense to have primitive words for low-level functions such as configuring pins, reading from and writing to memory addresses, and writing to a debug UART. More high-level functions will be defined interactively to give the test engineer maximum flexibility whilst keeping the development effort of the Forth system to a minimum.

<to be continued>


Extracting music from EMFINTRO

In October of 1991, a demo group called EMF released a small intro called ‘EMFINTRO’:

It was one of the first demos I remember seeing. This little gem featured excellent music by Purple Motion. The audio was generated through a DIY digital-to-analog converter made up of resistors connected to the parallel printer port of my PC. This crude music system was called a COVOX. At the time, it was a major step up from the beep-only speaker and I didn’t have a Soundblaster.

I always wanted to have the tracker module of the music but was never able to find it. Today I decided to try and extract the module from the executable.

First I downloaded and installed DOSBox and ran the intro. It worked and played the soundtrack through an emulated Soundblaster! Hoping for an easy score, I ran several module extractor programs on the executable. No luck there! The executable was compressed using PKLite, a popular exe-packer at the time.

Of course, this wasn’t a new problem. People developed tools to decompress the executables ever since PKLite was invented. Unfortunately, the EMF coders messed with the headers because none of the 7 tools I tried would unpack it. Some did nothing, some crashed DOSBox, still others didn’t recognise the PKLite version. So far for the easy way out…

It turns out that DOSBox has a version with a built-in debugger! So, I ran EMFINTRO and halted the simulated CPU by entering debug mode at the sound setup screen, hoping that the executable had decompressed itself completely in memory. Using the debugger, I dumped the entire 640K memory into a binary file and opened it up in a HEX viewer:


Succes! The executable has unpacked itself into memory. Now to search for the module..

Again, I ran module extraction software on the dumped binary file. No luck. It is either in a format that the tools don’t recognize, or it’s in a proprietary format. So I started searching for things that looked like a module; it’s surprising what you can find just by looking at the ASCII representation:


Bingo! There’s Purple Motion’s signature (PM) and a tracker name that I recognize: ScreamTracker. However, I’ve never seen this particular ‘!Scream!’ ID tag before. A bit of Googling revealed this to be a ScreamTracker 2 signature. I also found an example of a valid ScreamTracker 2 module (.STM) file and found out there should be 19 bytes containing the module name before the ‘!Scream!’ ID tag.

Knowing that module players generally don’t care how long the module file is; they’ll load only the bits they need, I had enough information to dump the tracker module.

Luckily there are still copies of ScreamTracker 2 on the internet! So, I downloaded it and installed it in DOSBox. Loading the dumped module into ST2 worked like a charm! It played it just like the intro itself!

To cut off the excess bytes of the original dump, I used ST2’s ‘save module’ to write the module to disk. Hey Presto! A 69Kb STM module appeared on my harddrive.

As a final test, I opened the module in OpenMPT, a modern module player. There are some differences in the way OpenMPT plays it. The channels are not panned correctly; something that is easy to fix. As an added bonus, I saved the module in ScreamTracker 3 format as this is more widely supported and has fewer playback bugs. Even good old WinAMP plays S3Ms more or less correctly but fails miserably playing the STM version.

I’ve submitted the STM and S3M versions to the Mod Archive. Or listen to it on SoundCloud.