The usual visitors to this site will have noticed that it has been offline for a few days.
Basically the site had grown too big for for our hosting and I made the decision to move.
Obviously this comes at a cost and for a time I thought I was going to have to make some compromises.
Luckily, for this year at least, I had a cash injection from Banjo Guy Ollie & Caius which has allowed me to pay for what was needed.
I am contemplating setting up a Patreon or something in order to help pay for this cost going forward.
We will see how it goes.
Massive thanks to Banjo Guy Ollie & Caius for the contributions.
One small bug fix with the byte sum not clearing when reset.
The analysis routine has been updated to check if alternate bytes are stuck high, low or are all the same.
I think that’s all. There may be other things too but its been a while and I’ve forgotten what they might be.
I’ve since started using source control for my projects so will be able to keep better track of things
I’m not dead!
Some time ago I scored a great deal on eBay for a Data I/O 29A setup with a load of modules and manuals.
Pretty much everything worked great apart from the display was really dim.
It doesn’t look too bad in the picture but it looked much worse in real life
Schematics are readily available for the unit so fault finding was fairly quick.
With the display being dim my initial though was a voltage issue and the schematics have conveniently labelled the area up as “FILAMENT SUPPLY GENERATOR”.
Using the scope I could see straight away the CD4049 hex inverter at U14 was not inverting at all.
Simply replacing this fixed the fault
PCB Repair LogsComments Off on Scramble (bootleg) repair log
Apr092019
Hammy sent me a couple of boxes of PCB’s recently. Among them was this Scramble bootleg PCB.
I’m still not sure if this pinout is unique but I had to figure this one out for myself.
Finding the VCC and GND pins is easy enough and just a matter of checking continuity from a know IC.
Once I had the power pins hooked up I fired it up and used the scope to probe for video signals. As long as the board boots the RGB should be easy to identify and as long as sync is being generated we should be able to find a 15khz signal somewhere.
Fortunately for me that is exactly what I found so I hooked them up and got this
I already knew this game didn’t match anything in MAME but I pulled all the ROM’s anyway and dumped them.
The Z80 is socketed on this PCB so I plugged the Fluke 9010 in and carried out the ROM tests. All the ROM’s could be read without a problem.
Next on to the RAM.
I originally looked at the wrong MAME source for this board. I looked at galaxian.cpp but I should have been referring to galaxold.cpp. Because of this error I ended up wasting a bit of time looking for a fault that didnt exist.
One this PCB the work RAM is between addresses $4000 – $47ff.
On the riser PCB I could see 2 x 2114 RAM’s which are a 4 bit memory but this would only give me 1024 (0x3ff)bytes on RAM and I was expecting double that. Removing the riser board revealed the second set of 2114 chips.
Running the RAM check on the Fluke gave me RAM errors in the upper half of the range which I determined was on the riser PCB. I removed both of them to be sure and found one was giving errors on 2 address pins
Replacing this gave me this
Error 3 doesn’t exactly give me much to work with so I just went round the other RAM ranges. There is some screen RAM at address range $5000 – $50ff. This failed.
This RAM in 2 x 2101 and as luck would have it it is already socketed.
I removed both and tested them and both failed
I have plenty of these spare due to my dealings with early Nintendo boards so swapped them right out.
We have success and with the audio hooked up we get this.
The riser board on this thing seems to be for the control inputs
Here is the pinouts I got for the PCB. There is likely a few things missing like coin counter but I’m not bothered about that.
Some time last year I attended an arcade meet of UKVAC user ‘Bonehead’. It was here that I met up with Virtvic who brought along a couple of boards that needed repair. Among them was this Arkanoid 2 which has had a few attempts of repair by a few different people. Because of this it also came with a list of suspected bad components.
Among the list of suspected dead parts was the Z80 Sub CPU. I tested this and it was indeed dead.
After a quick visual inspection I fired it up and got a “SECURITY ERROR” on screen.
The security error is generated from the sub CPU and is all to do with the MCU which is part of the sub CPU section.
I pulled the ROM and it failed in the programmer with an “OVER CURRENT” error. At this point I was getting suspicious and set about checking other chips on the same busses. Everything on the same bus as the sub cpu was dead. The list includes:
Z80
PAL
RAM
ROM
Y2203
MCU
uPD4701
I desoldered and removed them all but I was worried now as the MCU is currently undumped and I wasn’t even sure the game would work even if I replaced all of this.
I fitted a new Z80, RAM, ROM and PAL as I had them on hand. I then set about patching both the main and sub ROM’s in order to bypass security checks and to verify the game worked. It did so I attached the Fluke 9010 to the sub CPU socket and simulated various coin and button presses by writing expected values to the shared RAM.
It was a good start and now I was assured the game would actually work I set about thinking of ways to get around the MCU being dead.
My options were:
-Replace the MCU with a modern one programmed to act similar
-Program my own 8741 from scratch
-Create a PCB to fit in the socket to make necessary connections and bypass certain checks in ROM
I started off attempting to replace it with a more modern ATMEGA MCU. I made up a small adapter PCB which would match the pinout of the 8042.
This didn’t work well at all as the ATMEGA doesn’t have dedicated chip selected lines or any of the other control lines I needed. As a result i scrapped the attempt and decided to start learning 8741 assembly.
I spent quite some time learning the ropes on this one dealing with all its limitations and pouring over the MAME source which simulates this MCU. It really was a great experience for me and I enjoyed it a lot.
Phil Bennett gave me some assistance in setting up a MAME environment to use a real MCU file rather than the simulation and I finally ended up with something that seemed to allow me to boot the game.
I went to test my first attempt but realised that I would need some kind of debounce routine for the coin up processing.
I continued working on the MCU features in the background and started to look at getting hold of the missing chips.
I needed a new Y2203. Without this I have no sound and the game also boots straight into test mode as the Y2203 also processes the DIP’s. For now I was patching this check out too.
Getting the Y2203 was fairly easy and I found one on a scrap board.
I eventually got some 8741 MCU’s for a decent price from eBay and was about ready to test for the first time
Success! Coin up was implemented and buttons were implemented too.
The sticking point was the NEC uPD4701. This handles the spinner inputs and I couldn’t find one anywhere.
Hammy was going to send me one with the next batch of things to dump but Caius came to my rescue sooner and sent me one from a Cabal PCB (thank you Caius and Hammy).
I don’t have any spinners to test controls so I hooked up an Arduino to simulate left and right movement.
From my point of view that’s this PCB fully working. Its taken me months to get to this point but its also been one of the most satisfying things I’ve done in this hobby.
There are some ‘features’ missing from my MCU replacement but I don’t think its anything disastrous. The game no longer caps at 9 credits and the tilt signal doesn’t work within the test mode. There is probably other stuff too but I can work on those if they become a problem. Once it has been tested then I will release it.
