X Multiply repair log #3

 PCB Repair Logs, Repair Logs  Comments Off on X Multiply repair log #3
Aug 112014

Yes, again.
During some playing of this recently repaired board the game froze up.
On reset I was greeted with this static screen.

Non booting boards are generally quite easy to fault find but due to the V30 I was having problems. This is when I came across a post on KLOV from some time ago with someone asking if an 8086 Fluke POD could be used to test a V30 based system. The general thinking was that it could but no one ever tried it, until now!
Im pleased to say it does work (excluding the RUN UUT function).

Very quickly I found that the main ROM’s could not be read properly. The correct signature was 6A03 and I was getting 6935.
Following my schematics I found that there is a 74LS373 at location IC51 that is used as the latch to address the ROM’s.

This input was confirmed good but there was a stuck bit on the output.
I replaced this and the game was back once again. Ive left this soak testing and hopefully it will be rock solid now.

So just to confirm. The 8086 pod for a Fluke 9010/9100 can be used to check V30 based systems.

Jul 262014

I recently sold this PCB but after a week I was told the board had developed a fault.
The fault showed up as “RAM NG 10” at boot-up and there was some issues with the sprites.

There is absolutely no logical meaning to the error message so using MAME I started corrupting different RAM values during it POST to see what RAM errors were flagged up during which memory writes.
Originally I couldn’t understand how the awful V30 CPU worked. Without knowing how it worked I was unable to use the MAME debugger effectively. Charles MacDonald came to my rescue and told me how the V30 addresses were set. Thanks very much to Charles.
You can see the outcome of that exercise in THIS previous post.

So now I knew for sure that the fault was with the sprite RAM. Now the next challenge, which RAM chip is the sprite RAM?
I originally tried shorting some address/data lines on RAM chips to see if any other errors were flagged but strangely it didn’t show anything else at all.
With nothing left to try I started making my own schematics up in the hope I could work out which RAM was responsible for the sprites.

Due to the complex nature of this board set, I was stuck for quite some time looking on the lower video PCB assuming (yes I know) that this is where the sprite RAM could be but was unable to find any problems at all.
Taking a step back I reversed the PAL chip XM_A-7D- into equations. Using these equations and the schematics I had drawn up I could take an educated guess as to what RAM chip was the sprite RAM.
Knowing that the sprite RAM lies at address 0xc0000, this means that address pins A19 & A18 would need to be active. Looking at the equations I could see that output pin 17 of the PAL chip would fit this address so I followed the signal which led to the /CE line of a 74LS245 of IC40 on the top CPU PCB.

The only chip that this chip goes to is a 2018 RAM chip at location IC52.
This was pretty good news. I removed the chip and it failed the tests so I replaced it and now all the POST tests pass.
The sprites are all back to how they should be too.

Ill be keeping hold of this board I think. It was one of the first games I ever bought since getting into this hobby so it will stay with me for good now.

X Multiply repair log #1

 PCB Repair Logs, Repair Logs  Comments Off on X Multiply repair log #1
Aug 012010

Started off as a physical problem with corroded legs on MASKROM’s giving corrupt graphics on sprites.

Three legs were corroded on MASKROM T44.00, which is an NEC 23C1000. After a little asking about, I was told the EPROM equivalent was a 27C301 (non JEDEC).
I obtained a 27C301 eprom and burned a T44.00 from MAME. Pretty much all the graphics were back but there were some white blocks around the ship sprite and certain enemy bullet sprites. Found a broken track from pin 20 (chip enable). Repaired this and the white boxes are now gone from the ship sprite. There were still white boxes around the projectiles. I have now confirmed that with an original ROM the game works fine.

I took a closer look at the pinouts from a 23C1000 MASK ROM and a 27C301 EPROM. MASKROM’s have less pins than their EPROM equivalent mainly due to not have programming pins but also this ones only has one enable pin (pin 20) and the EPROM has separate /OE and /CE pins. I lifted pin 2 and soldered a wire from this to pin 22 on the EPROM and fired the game up, all the graphics are now 100% working. I initially thought this corruption was down to the speed of the EPROM but now I know otherwise.

Graphics fault