Problem

Bad colours and sound issues.

Not right.

Still not right.

Diagnosis

Thanks to the schematics, you can see Badlands is a simple system. There’s 2 graphics layers – ‘playfield’ (background/text – almost everything) and ‘motion objects’ (the tiny sprites). If you ever want to see how to draw tiles on a screen,  this is the schematics to study – there’s not even any scrolling hardware and it’s all discrete logic (unlike sprites that have a basic custom IC)

Anyway, sprites looked fine, backgrounds not. At first I thought it was just some of the background, but it’s actually the whole lot.

The background tiles look graphically correct, it’s just the colours. Like many games, the graphics ROMs store colour ‘codes’ rather than actual colours. It’s only at the later colour mixer stage that these become RGB values (via the palette hardware). This saves space and can allow alternative colour palettes for the tiles if desired.

I tried to draw it below. The CPU puts the background tile selection into the playfield RAM and when it comes to draw the screen, the draw counters cycle through it. The RAM will select ROM addresses and these will send out palette codes for each tile (4 bits per pixel). The palette RAM takes the codes (and alternatively the same input from the sprite hardware) and turns it into RGB values for each pixel.

First thing – read the ROMs (the game can’t test them). They were OK.

The colour fault is unlikely to be in the palette RAM as sprites are OK. Plus the colours are consistently wrong, rather than randomly fluttering. I swapped the RAM as a test to be sure.

So it’s likely either the tile RAM, the palette code or the output of the ROMs.

A pair of 74LS374s latch the  ROM output:

A quick scope showed all lines in and out of the ICs were active, but after running out of other things to look at, I got the logic analyser out and the IC datasheet. It was fairly clear that while the outputs (5,4,7 on trace) were all toggling with the output enable pin, one of them (5 on trace) wasn’t paying any attention to the input (4 on trace).

Change the IC (can’t remember which one of the two it was) and all was good…..

…until I realised the sound was wrong.

Effects and music were stopping after about 1 second and there were audible clicks. A scope showed the sound CPU was being reset once a second. Tracing back, this was coming out of a PAL, which was being addressed by the main CPU. So this suggested it was a deliberate reset command from the main CPU.
This led me to think there was some issue with the cross-comms. A bit of buggering around in MAME managed to achieve the same effect (sticking crap in the cross-comms memory addresses. Not a lot goes between processors – the CPU picks a sound to play (out of a pretty limited range – look at the sound test) and the sound CPU sends some sort of ready or acknowledge.

Schematics show (another) two 74LS374 latches handling the cross-comms. I did try the analyser, but issues weren’t so apparent due to data going in and out at totally different times (you can clock in data to a register, but choose to enable the output pins much later). So I did the dirty piggy back and the sound worked.

New IC at 15F and 100% working.

John Bennett

Not Phil