TANGLEWOOD vs. the AtGames Firecore Console

During the Kickstarter campaign for TANGLEWOOD, I made a very big promise – that TANGLEWOOD would run on just about every SEGA Mega Drive console, clone, emulator, and home arcade setup available. A golden rule I’ve been throwing around was “if it runs Sonic 2, it will run TANGLEWOOD” – no problem, since the game doesn’t perform any demo scene-style tricks or timing sensitive manoeuvres, nor does it rely on any hardware quirks or undocumented features of the various chips involved. It’s a big and ambitious game from a design perspective, but as far as pushing the hardware goes, I backed off a bit in order to uphold my promise of compatibility.

This proved quite a challenge, then, when once fateful afternoon the postman knocks on my door to deliver a box of goodies for our QA team to get busy with – some 6-button controllers from various third party manufacturers, a white label flash cartridge with SD slot, and an intriguing little black box with “At@Games” written on the front.

It was the first AtGames Mega Drive model that was sold en-mass here in the UK at our Argos stores – at its heart was AtGames’ Firecore technology. I’d had previous experience playing Streets of Rage on this thing in a noisy gaming cafe in Nottingham. The hustle and bustle of the venue did a good job of hiding the Trojan inside the little horse – its horrific audio. Just how bad was it? I didn’t believe the tales depicting it as the worst console ever released, since the Internet loves its hyperbole, but in this case everybody was right. All of the audio is pitched down, at differing values between FM and PSG, and there was some horrible screeching when some parts of soundtracks played.

TANGLEWOOD was shocking. It sounded like a horror game – dreary down-pitched FM, twisted PSG slides, and high pitched screeches where there should be PCM samples. I have a promise to keep, so I’m not taking this lying down.

The Investigation

Some quick searching around revealed that the menu ROM has already been dumped by a team of Russian hackers over at emu-land.net. The ROM seems to make use of 128kb VRAM mode, writes to ROM space, and pokes some addresses outside the usual Mega Drive range which crashes most emulators, but I’ve been working with megaEx (my fork of Mega by Lee Hammerton and Jake Turner) which happily executes broken code, instead logging to file anything it doesn’t understand. As expected, the graphics were garbled, but by pressing buttons I could hear the menu navigation sound in the background, so all was well.

Some modifications to the logging later, and I had a dump of unknown reads and writes when booting up the AtGames menu ROM:

Byte 0x00 written to cart address 0x00000000
Byte 0x0E written to cart address 0x00000001
Byte 0xFF written to unmapped address 0x00B01008
Byte 0x07 written to unmapped address 0x00B01009
Byte read from unmapped address 0x00B00010
Byte read from unmapped address 0x00B00011
Byte 0x00 written to unmapped address 0x00B00010
Byte 0x40 written to unmapped address 0x00B00011
Byte 0x53 written to unmapped address 0x00A14000
Byte 0x45 written to unmapped address 0x00A14001
Byte 0x47 written to unmapped address 0x00A14002
Byte 0x41 written to unmapped address 0x00A14003
Byte 0x00 written to cart address 0x00000000
Byte 0x0F written to cart address 0x00000001
Byte read from unmapped address 0x00B0001A
Byte read from unmapped address 0x00B0001B
...

Writing to address 0x0 seems a bit odd (it’s cartridge space), those in the range 0xB00000+ are not in any known Mega Drive space or any of its addons, and 0xA14000-0xA14003 are just the TMSS (the emulator hasn’t implemented it yet). This bit is particularly interesting:

Byte 0x30 written to unmapped address 0x00B01054
Byte 0x20 written to unmapped address 0x00B01055

From the Russian forum, although Google Translate makes a mess of it, you can make out that it changes the FM frequency, and the value 0x2820 is provided as an example. Writing this alone doesn’t work, it seems that those word writes to 0x0 are some sort of latch to tell the AtGames to pay attention to writes to 0xB00000+. Adding this to the top of my ROM seems to fix the FM frequency:

    move.w #0xFFFF, 0x00000000
    move.w #0x2620, 0x00B01054
    move.w #0xFFF7, 0x00000000

Simple enough. Latch 0x0, write 0x02620 to what seems to be the FM frequency register in the AtGames machine, un-latch 0x0. The example 0x2820 provided by the Russian folk didn’t seem to be quite in tune, 0x2620 sounded closer.

The PSG was still very out of tune, and there was still harsh screeching from some notes, so we needed more. I modified TANGLEWOOD’s sound test screen to include an address poker – an address (starting from 0xB00000) and its current value is shown on screen. Up and Down cycles the address, Left and Right cycles the value, and Start writes the new value.

After some experimentation I had a vague idea of what some of the registers were responsible for:

0x00B00000
Locks up the machine

0x00B00018
Affects PSG pitch, bingo!

0x00B01000
Cycles through various video modes

0x00B01002 - 0x00B0104
Various graphics output options, all resulting in a fuzzy, black and white display

0x00B01006
Possibly NTSC/PAL flag, but my TV has no OSD so can't tell for sure

0x00B01008
Seems to do a palette shift

0x00B01018
Screen Y offset in pixels

0x00B01016
Screen X offset in tiles

0x00B0101A
Changes screen to green/blue tints, possibly RGB order

0x00B01028
Slows audio down to a crawl, PSG glitches and screeches

0x00B0102A
Locks up the machine

0x00B01036
TV displays "no signal" but audio continues to play

0x00B01038
Adjusts VDP tile width

0x00B01054
Adjusts FM frequency - changed FM music pitch

0x00B01055
Adjusts FM and PSG clock - changed FM and PSG music tempo

So, with some trial and error, I managed to find the relevant addresses to change audio clocks:

• 0x00B00018 changes PSG frequency. The bottom 2 bits seem to be a fine tune setting (4 steps), whilst the rest of the byte seems to be a divider (for PSG, frequency*2 = one octave).
• 0x00B01054 changes FM music pitch, already known.
• 0x00B01055 changes FM and PSG clock, speeding up and slowing down the music tempo.

The Fix

Using the very scientific method of playing my game’s original soundtrack from a laptop, and listening to the AtGames sat next to it, I settled on the values 0x7A for the PSG freq, 0x26 for the FM freq, and 0x20 for the FM/PSG clock.

The code:

    ; AtGames audio fix
    move.w #0xFFFF, 0x00000000  ; Latch 0x0000
    move.b #0x78, 0x00B00018    ; Write new PSG frequency
    move.b #0x26, 0x00B01054    ; Write new FM frequency
    move.b #0x20, 0x00B01055    ; Write new FM clock
    move.w #0xFFF7, 0x00000000  ; Un-latch

Here’s the new and improved main menu theme tune:

It’s not 100% done yet. The next step is to fix the screeching sound from some of the instruments. After listening to some of the tracks, I’ve managed to determine that the affected notes all used the SSG-EG mode in their FM operators. It seems AtGames didn’t emulate this properly (if at all), and my only option – without adding more precious time to this – was to disable SSG-EG in all instruments as a test – which worked fine.

I’d like SSG-EG on the other consoles, so the plan is to disable SSG-EG on the fly in the audio engine if an AtGames is detected. I’ve yet to figure that part out, and so far it’s been easier said than done – reading from any of the AtGames’ config regs at 0xB00000+ hangs up a genuine Mega Drive, and reading from 0x0000 on the AtGames returns the first word of the stack vector rather than allowing us to read back the latch, which means we can’t verify that the latch was written/denied to check if it’s a port.

If I get time, I would like to investigate these registers further, and properly document the behaviour of all values written across the range. Perhaps we could fix other issues with this model, so homebrew and ROM hacks will be safe on the AtGames Firecore!

Matt