I wouldn't normally post a fix log for something that in essence is actually a trivial fix but this is more a lesson in not always believing the manual and using your gut instincts - and the internet.
The offender: One Rally-X PCB suddenly refusing to start showing ROM OK and RAM 5H followed by a reboot.
Remembering that Namco/Midway manuals try to be helpful on this I consulted the online version and discovered from the printed table that 5H relates to a 2114 @ 6F on the lower board where the CPU and ROMs are.
Fortunately all the RAMs are socketed on this board already - so I swap out the RAM and boot up - same thing.
Uh oh i'm thinking this can't be the RAM then, it must be addressing logic to get to it - out with the scope, all the pins look active as they should, /CS changing, /WE changing, address and data all look good.
Plug in the Fluke 9010 and interrogate everything - firstly all the ROMs look good, i'm just going through the motions for thoroughness, go through the RAM locations and hit upon a problem in the $9800-9FFF region, specifically the fluke says:
Never seen this one so the manual explains this is an address line problem, I do some tracing on the schematic and some hex to binary and work out that 9C00 is looked after by 6E and 6N so I write a single value to $9C00 of 55 and read it back - 55!
Hmmmmm, confused, RAM test says there's a problem but I can write and read from the location quite happily.
I pull the 6N out and immediately see 0F when reading the location, all the lower 4 bits are held high because there's no device on the end of it.
Change out the 6E same in reverse, F0 and I can write to the location and get F5 for example after wiring 55.
(for those not really sure what i'm talking about, imagine a C64 with the code loaded to memory and you hit reset, i'm doing POKE $9C00,$55 followed by PEEK $9C00)
So I spend an hour or so running around the memory chain with the logic comparator and piggybacking a few chips to see if any change happens - nothing found to be bad.
I've decided to give up at this point shelve the board for another time and do something else when I figure i'll take a swing at this on the search engines.
Search: "RALLY X RAM 5H ERROR"
Yields me this interesting document:
http://pdf.textfiles.com/manuals/ARCADE/SMALLFILENAME/midwaysvcnotes2.pdf
I dig through and embedded within it is a service note for Rally X on page 12 stating that:
D'OH!!!!!
On the following page there's the accurate table telling me that 5H relates to 6E not 6F.
Replace 6E with a working 2114 and the game boots up.
I have to say that I felt like I was reading a very important piece of history, this bulletin goes on for 91 pages and talks about different ROM sets and all sorts of things I hadn't looked at. A sad loss of an era where companies actually tried to help users.
For good measure I asked the Fluke to re-verify the 9C00-9FFF block now that it has a good RAM in there and it says its ok - so the MAME memory map and tech notes on the net for this board do match up, just the manual doesn't.
Repair done, game booting and working again - lesson learned - trust your instincts that you're looking in the right location when the manual tells you otherwise.
RGP2015-05-12 23:12:04
The offender: One Rally-X PCB suddenly refusing to start showing ROM OK and RAM 5H followed by a reboot.
Remembering that Namco/Midway manuals try to be helpful on this I consulted the online version and discovered from the printed table that 5H relates to a 2114 @ 6F on the lower board where the CPU and ROMs are.
Fortunately all the RAMs are socketed on this board already - so I swap out the RAM and boot up - same thing.
Uh oh i'm thinking this can't be the RAM then, it must be addressing logic to get to it - out with the scope, all the pins look active as they should, /CS changing, /WE changing, address and data all look good.
Plug in the Fluke 9010 and interrogate everything - firstly all the ROMs look good, i'm just going through the motions for thoroughness, go through the RAM locations and hit upon a problem in the $9800-9FFF region, specifically the fluke says:
Code:
RAM DCD ERROR @ 9C00 BIT 4 - LOOP?Never seen this one so the manual explains this is an address line problem, I do some tracing on the schematic and some hex to binary and work out that 9C00 is looked after by 6E and 6N so I write a single value to $9C00 of 55 and read it back - 55!
Hmmmmm, confused, RAM test says there's a problem but I can write and read from the location quite happily.
I pull the 6N out and immediately see 0F when reading the location, all the lower 4 bits are held high because there's no device on the end of it.
Change out the 6E same in reverse, F0 and I can write to the location and get F5 for example after wiring 55.
(for those not really sure what i'm talking about, imagine a C64 with the code loaded to memory and you hit reset, i'm doing POKE $9C00,$55 followed by PEEK $9C00)
So I spend an hour or so running around the memory chain with the logic comparator and piggybacking a few chips to see if any change happens - nothing found to be bad.
I've decided to give up at this point shelve the board for another time and do something else when I figure i'll take a swing at this on the search engines.
Search: "RALLY X RAM 5H ERROR"
Yields me this interesting document:
http://pdf.textfiles.com/manuals/ARCADE/SMALLFILENAME/midwaysvcnotes2.pdf
I dig through and embedded within it is a service note for Rally X on page 12 stating that:
D'OH!!!!!
On the following page there's the accurate table telling me that 5H relates to 6E not 6F.
Replace 6E with a working 2114 and the game boots up.
I have to say that I felt like I was reading a very important piece of history, this bulletin goes on for 91 pages and talks about different ROM sets and all sorts of things I hadn't looked at. A sad loss of an era where companies actually tried to help users.
For good measure I asked the Fluke to re-verify the 9C00-9FFF block now that it has a good RAM in there and it says its ok - so the MAME memory map and tech notes on the net for this board do match up, just the manual doesn't.
Repair done, game booting and working again - lesson learned - trust your instincts that you're looking in the right location when the manual tells you otherwise.
RGP2015-05-12 23:12:04
