![\"\"](\"https:\/\/blog.system11.org\/wp-content\/uploads\/2017\/04\/nova_fix1.jpg\")
<\/a><\/p>\nSo this is what I was faced with – the game would try to boot and then reset halfway through, the only way I managed to get a photo of the error itself was by making a video and stepping through it frame by frame.<\/p>\n
You can see that the CRLRAM bank allegedly has a fault, which could mean a RAM chip or it could just as easily be some logic between the RAM and CPU (in this case a Z80) testing it.\u00a0 The biggest problem though is that we don’t actually know which RAM chips to look at on the board.\u00a0 I’d already checked all of them with a logic probe to see if there was anything obviously wrong, but nothing stuck out as being faulty.\u00a0 When faced with this kind of problem on a booting game we can try various methods of disrupting the RAM to try to isolate which bank is at fault, but this is not possible when you’re stuck with a rapidly looping test mode.<\/p>\n This is where MAME can be really useful, since the functional memory areas are mapped out even if they may not quite match the labelling or usage on the actual PCB.\u00a0 The error screen above appears after the four code ROMs have been checked, and the names would imply that a foreground and background layer have been checked successfully.\u00a0 This is from the comments of the Nova 2001 MAME driver:<\/p>\n I was willing to bet that the first two RAM banks were the foreground and scrolling playfield layers, so it would be a fair bet that the sprite RAM would be checked next.\u00a0 While the error message stated CRLRAM, on a working board or testing in MAME the success message would normally say CELRAM which could also hint at it being the sprite memory.<\/p>\n The next step was to run the game in MAME and use the debugger to set a watch point on the sprite RAM memory address at $B000. In the following pictures I also set a breakpoint at $16AC, which happens to be a jump at the end of the message display code – I was able to find this by carefully stepping through the program.\u00a0 We can see that the first interesting write is 47 into $B000, and MAME pauses here due to the watchpoint.<\/p>\n RAM tests are usually performed by writing into the RAM and then reading it back to see if it matches, and using the debugger memory viewer we can actually change that data mid program.\u00a0 After replacing the value with 00, I set it running again.\u00a0 We can see a very familiar error message now, and due to the breakpoints I set at the end of the message display routine, it doesn’t immediately vanish before it can be read.\u00a0 This confirms that the RAM area at $B000 is definitely the area of RAM that the game is struggling with.<\/p>\n This is all very interesting, but it still doesn’t tell us which chips we need to be looking at on the PCB, but MAME hasn’t finished helping us yet.\u00a0 When we first looked at the watchpoint, there was an area of code highlighted on the right which is responsible for actually writing the test data.\u00a0 What if we modified that code so it just kept writing indefinitely?<\/p>\n It’s difficult to make meaningful changes right in the middle of code, but far less difficult if you just want to make a change to some data without changing the length of it.\u00a0 In the screenshot below the highlighted code is going to cause the CPU to jump to address $1693, and 1693 is just a two byte piece of data.<\/p>\n We want the program to go back to $14E1 right at the top which is the entry point for the RAM test.\u00a0 Time to open ROM 1 in a hex editor and find the code at $14F7 (C3 93 16):<\/p>\n You can see that the two bites of the address are reversed so we replace 93 16 with E1 14 ($14E1).<\/p>\n I’d already extracted the MAME set to a folder, so saved and overwrote the original file, let’s see what happens in MAME now with the same watchpoint and breakpoint as before.<\/p>\n Unfortunately since the game checks the integrity of the code ROMs at boot we’ve created a version that resets even quicker.\u00a0 Since I couldn’t easily find where this check takes place, I decided to modify other data in the ROM to restore the checksum.\u00a0 Fortunately right at the top this one are nearly 32 bytes which appear to be of little importance (FF\/00),\u00a0 so I adjusted them a little to compensate.<\/p>\n I worked on calculating the difference between the data originally in the file and what I had changed it to, and adjusted two bytes by the same amount.\u00a0 The first time I tried this it worked perfectly but the second time (after I corrected the jump address) it didn’t.\u00a0 There’s a hole in my guesswork somewhere and I’m not sure what it is, but it only took a couple of attempts to readjust it and fool the boot time ROM check.<\/p>\n Now we have a version of the program code which just sits there trying to check the sprite RAM for all eternity…<\/p>\n There is one final problem though.\u00a0 The PCB has watchdog hardware and if it notices the CPU appears to have stalled, it resets it (MAME emulates this too).\u00a0 Testing the new code on the PCB did however prove that it was lingering slightly longer in the RAM test before the watchdog kicked in.\u00a0 This is what the relevant parts of the watchdog and reset circuit look like:<\/p>\n The red line is the actual reset line, this is normally high and driven by the 74LS08 at position 4B.\u00a0 The LS 08 is an AND device, if inputs A and B are both high then the output is high, else the output is low.\u00a0 The inputs in this case are the power-on reset circuit in blue which is essentially just a capacitor on the 5v line, and in green a feed from part of the watchdog circuit (the 74LS161).\u00a0 To disable the watchdog what we have to do is either cut one of the chip legs or the track to disconnect input A and then join that to input B so that the power-on is driving both inputs.\u00a0 There are pros and cons to both methods, you could even remove one of the chips, fit a socket and leave one of the legs hanging out.\u00a0 In this case I opted for using a scalpel on the track directly below the 161.\u00a0 It was a very small transition track and very easy to rejoin later.<\/p>\n Sure enough the game booted up and immediately got stuck looping the sprite RAM test, and using a logic probe it was very easy to work out which RAM was being accessed – one of the three surface mount 6116 chips.\u00a0 It’s not possible to get chips of the exact same size any more as these were early surface mount RAM, but ones that fit the pad layout are easily available.<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n