Shoestring

My name is Samuel. I have a Computer Science background with an interest in digital electronics and guitar/music. My interest and hobby in arcade games started after purchasing a non working Galaga board, one of my favourite arcade games. There was a lot of motivation & passion to get that game working so I put a lot of effort into fixing it. I soon realised that Galaga isn't the wisest choice for a beginner to learn PCB repairs on. With some practice and help along the way on various other dead boards, I gained more knowledge in troubleshooting and repair with the hunger to learn more. I also develop test rom/diagnostic software in assembler to aid in troubleshooting.

Jan 262017
 

This is part two of my C64 repair which documents the replacement of the bad character generator rom using a standard 27c64 EPROM. My local electronics hobby store did not have anything else on hand; I was hoping for a 27c32 because that’s what most folks on the internet seem to be using to get this repair done. I didn’t want to wait, so I settled on the 27c64.

The first step was downloading a c64 character rom ( 901225-01 ) with a checksum of $F7F8 from the internet. There are plenty of sources for these.

After downloading the 4kb binary I ran the following command under Windows to fill up the entire 8kb of address space of the 27c64 ( upper and lower 4kb have the same data ). I couldn’t quite remember which half I needed to burn the contents to so this was a quick and fail safe solution.

copy /b 901225-01.bin+901225-01.bin 901225-01-doubled.bin

I take the 8kb binary ( 901225-01-doubled.bin ) and burn the image to my 27c64 EPROM.

 

I bend the following pins outward on the 27c64 and cover the window with a sticker once the data is written.

1,2,20,23,27 & 28 ( bent out ).

I made an adapter using a machined pin socket. This is the diagram I used to re-wire the chip which I found on this German site.

http://forum.classic-computing.de/index.php?page=Thread&threadID=4694

 

2532 pin 18 -> 27c64 pin 23 ( A11 )

2532 pin 21 -> is not connected ( VPP )

27c64 pin 20 -> 27c64 pin 22 ( /CE & /OE tied )

27c64 pin 1,2,26,27 & 28 ( VPP,A12,NC,/PGM & VCC all tied ).

Once I finished wiring it was time to double check my work. I then select a 2532 device on Max Loader, load the original downloaded character generator rom into the buffer; this has a checksum of F7F8 which will be used for verification purposes.

With the wiring complete I’m now ready to verify it’s contents. I will read the device as a 2532 EPROM and if all goes well it should report a checksum of F7F8

With the re-worked EPROM inserted into the ChipMax I hit verify. F7F8 was what I was after.

With that result I was so confident it was going to work that I trimmed the protruding pins and inserted the device into the C64 to produce the results I expected.

Dec 182016
 

This c64 gave me the following screen on power-up. Flickering characters with artifacts and a vertical line through the middle of each character. After going through the symptoms on Ray Carlsen’s site, I thought this may be bad colour ram. Swapping out the 2114 didn’t make any difference and colours associated with the characters looked good anyway, so I don’t know what I was thinking there.

After thinking about this for awhile & looking at the pattern closely, I had an idea that this may be a bad character generator ROM at U5. To prove this theory, I could type in a short basic program to copy the entire character set from the ROM into RAM, then tell the VIC 2 chip to use the character set in ram and reprogram one of the characters to one of my choice. The Commodore 64 has great features such as programmable characters which is very useful for games.

Luckily I don’t have to think too much as there’s already an example at the link below.  So I begin typing some basic commands. The problem is my typing has to be super accurate because I can’t see what I’m doing and any typo will screw the troubleshooting up. It took me 3 or 4 goes before I finally got it right.

http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/Chapter_3/page_109.html

After typing in “POKE 53272,(PEEK(53272)AND240)+1” as shown above, the flickering stopped although the artifacts obscuring the characters were still there, which was to be expected because we’ve just copied corrupt data. The computer was now getting the character set from RAM instead of from ROM. Now to change the letter T to a smilie face. I enter the following program and run it.

10 FOR I=12448 TO 12455: READ A:POKE I,A:NEXT
20 DATA 60, 66, 165, 129, 165, 153, 66, 60

Pressing a T shows a smilie face which looks complete without artifacts or a line through the middle of it. So I know that the VIC 2 chip is OK.

I remove the old mask rom and install a socket. My EPROM programmer is currently out of action so I don’t have the ability to verify the character rom or program another EPROM in its place.

But for now I can extract a known working EPROM from my own C64 into this one for troubleshooting purposes . After powering up, the character set shows up perfectly. Now all I have to do is program another EPROM when I get around to it and this c64 can go back to its owner.

Dec 102016
 

This Atari 800xl has definitely seen much better days. A work colleague picked this 800xl off eBay plus a battle worn 65xe and some power supplies and other junk. Initially we had some issues troubleshooting but the symptoms were typical of a faulty power supply and bad DRAMs after re-testing with a reliable power source.

image

One of the power supplies had the Atari logo with a foreign AC plug. These are absolutely useless to me because they’re sealed with epoxy and could not be repaired. The other two types were also sealed with epoxy, the connectors with the 7 pin din plug would later be salvaged for an alternative source of +5v DC using a basic switching adapter for usb hubs / routers. I read that they fail spectacularly when they do with over voltage. DRAMs don’t like voltages far above the normal voltage levels and will fail very quickly. I’ve also read that the sealed epoxy types are very reliable and when they fail, they supply low voltages due to bad caps which aren’t harmful to the Atari. Regardless of what the truth actually is, these power supplies are well used and it’s likely that they’ve already failed or due. The other common cause of a dead Atari is a “Commodore 64 attack”,  the c64 has the same 7 pin din power supply connector and was often intentionally or accidentally plugged into the back of an Atari causing instant death to DRAMs & anything CMOS. The Atari only accepts +5vdc, Commodore decided to use 9vac in addition to the +5vdc.

The XL and XE series have a really neat diagnostic tool built into the OS ROM. When the option key is held in during power up, it triggers the software to boot into the diagnostic mode however, when bad ram is detected it automatically boots into the memory test as shown.

image

 

The red squares indicates that the ram test has failed. Normally, 48 green squares should be present but unfortunately most of those are red. Each square represents 1kb; would that mean it only have 48kb of ram? Well not really. The 800XL has 64kb of ram but the built in diagnostics only tests 48kb of that. It’s a very simple test. Perhaps the lower chunk of 16kb of ram is used to store variables and make use of the stack for the diagnostic software. That explains the machine’s refusal to boot into anything if the ram is a total loss.  I learned very quickly that whilst developing my RAM test routines for my Gyruss diagnostic software, to not to use the stack ( push,pop, call, ret instructions .. etc) until the entire ram was verified first.

Each DRAM represents 65535 words x 1 bit, so you need 8 of these to make up 1 byte of ram per address. Some of the later models use 2 x 4464 DRAMs in the XE series.

Unfortunately this is a revision D motherboard which means only half the chips are socketed ( cost savings ). So we need to remove our DRAMs and test them outside of the circuit.

image

I could also troubleshoot by piggy backing to identify a bad chip but that won’t work if a chip is shorted. The board has previously been worked on and a new DRAM was already installed, this replacement could have occurred years ago. We have at least 1 additional dram fail and we don’t know the history of the machine and when this failure took place. It would be wise to replace the entire 8 devices as it’s very likely we will see another DRAM fail. Besides, this brand of DRAMs are known to be unreliable even when they were new and they were also used in the C64. It’s also very less likely that we have one or both of the 2 74LS258 DRAM address muxes fail.

So I remove each DRAM one at a time, install an IC socket and test them out of circuit with my trusty Micromaster LV48 EPROM device programmer. I tested the previously replaced DRAM and it passed the test however I only found 1 bad DRAM and it was the first one at U9 ( clearly marked X with my screwdriver ) so I don’t mix it up with the remaining working devices.

image

I don’t have any spare 64×1 DRAMs on hand. But I do have some in a ram expansion board which was installed to expand the 600xl’s internal memory from 16kb to 64kb. I finally convince myself to salvage the DRAMs to fix the 800xl since I already have some spare TI 64x4s which I can put in my 600xl and use it to troubleshoot the dead 65e, it would require a modification but it’s a very simple mod which many have done. Besides the ram board is totally unnecessary as pointed out by people on Atariage who made jokes about it as I tried to identify its origin.  I was also expecting to receive my Antonia 4Mb upgrade board from Poland to install in the 600xl so I wasn’t really needing the 64×1 DRAMs anyway.

The disgraced ram board.

image

Installing sockets and replacing the entire stack of DRAMs seems to have cleared the ram error but I intend to load up several games that use up the entire 64kb to make sure and test the machine over a few hours. I also tested each DRAM in my device programmer to verify them before installing them in the 800xl.

image

Whilst I’m working on this I’m also giving the Atari 800xl case some whitening treatment using a simple solution of laundry booster and water. I submerged the parts in this milky solution and left it in the sun for several hours over the weekend. This is a very effective and cheap alternative to some of the other solutions out there. The sticker had come off, so I had no problems submerging the bottom half of the case. I would later glue the sticker back on once the case was dried.

image

I like the results. Some keys are still slightly yellowed but I don’t mind.

image

 

A few hours go by playing my favourite game on the Atari, Dropzone. Now I have a bunch of 4164 DRAMs which I’ll use for troubleshooting purposes.

image

RAM test shows no problems but I had an issue with the TEAC television set shown previously and l had to replace it with this piece of junk. That’s two sets gone in two months with no desire to repair them.

image

With that done. It was time to give the machine back to it’s owner and start working on the 600xl which I’ll use to troubleshoot the 65xe ( I’ll cover that in my next post ) by substituting in parts until the 600xl breaks.

These are the instructions I followed and results.  3 wires, bend up some pins ,some soldering and you’re done. I had to reinstall the 2 x 74LS138, 74LS375 from the RAM board to the machine. There was also a 74LS32 missing which isn’t really needed depending on the variation of the mod you’re performing but I managed to scrounge one from an arcade parts board.

http://www.mathyvannisselroy.nl/xl600k64.htm

 

600xlupgrade

2 x TMS4464 DRAMs installed. Much better than the expansion board!

Sep 112016
 

I recently picked up an Apple //e enhanced computer to repair and to relive some memories. Due to the machine’s age ( especially because of the power supply )  I was mindful not to power up the machine and risk damage to the logic board.

I disassembled the power supply and wasn’t at all surprised at what I saw based on what I’ve read, there was no way I was powering this thing on and taking any chances although this was a very high quality power supply compared to power supplies of the same era. This is an astec AA11042C, this version is rated 240v and there were actually two different types available in the Apple ii line. I checked the fuse which looked fine and tested OK with my DMM.

I then removed all electrolytic capacitors and recapped the entire board including the two Rifa filter caps which can fail spectacularly and spill brown coloured goo everywhere. Some capacitors revealed scorch marks on the PCB after removal. The 47uf 250v capacitors from the high voltage side looked fine but were way off spec.

2 bad electrolytic capacitors pulled from the low voltage/output side

image13

 

A Rifa filter cap. ( Note the cracks! )

Apparently moisture gets inside the cracks and the cap explodes. Not taking any chances, it has to go.

image12

Astec rebuilt with brand new electrolytics & filter caps.

I ended up installing two filter caps made by Suntan, this brand doesn’t have the best reputation in the world but I can swap those for higher quality caps once I get the unit functioning. These were all I could find ( the yellow rectangular looking things near the inductor) and I was so desperate.

 

image4

I tested the power supply but quickly found out that like all switching supplies, nothing will happen without a proper load or with a short. With the power supply connected to the Apple, nothing happened which was good in a way because I didn’t see any smoke. If I were taking my chances in the same way with an Atari or Commodore power supply then things might have turned out a little different 🙂

There were no voltages present on the logic board of the Apple //e. This prompted me to look deeper. The bridge rectifier ( @ DB1 ) looked a little cooked or oxidized even though it tested good with my DMM, the issue wasn’t there but I replaced it anyway.

Scorched or oxidized bridge rectifier ?

image5

I then started reading a comprehensive troubleshooting guide in the following PDF document.

http://www.applefritter.com/files/Apple2e_Repair_SAMS1985.pdf

I ended up removing a bunch of small transistors, the large power transistor,diodes and re-installed them after they checked out fine. I replaced the SCR ( silicon controlled rectifier ) at scr1 as I have no means to test it. The scr1 shutdown transistor at Q4 tested good. This area is also known as the crowbar circuit which disables the power supply if there’s an over-voltage or a surge, this protects any downstream components like the sensitive stuff in your computer from damage.

I was stumped at this point as none of the above actions solved my problem.

I took another closer look at the PCB and found this burn mark circled in yellow. I removed the 2w resistor which still measured 27 ohms out of the circuit. I re-installed it as it was good.

image15

The above link to the document also mentions to check the windings on transformer T2 and T3 ( PWM control isolator )  for continuity. I remove the smaller transformer ( pictured above, adjacent to the astec silkscreen logo on the pcb ) thinking that I’m wasting my time with this but check for continuity anyway.

There are 6 pins on the bottom of the T3 which are soldered to the PCB. There appears to be 3 separate sets of windings but 1 set of windings had no continuity between two of its associated pins. I found a small break in the winding at the bottom of the transformer ( circled in red ) and soldered it to its corresponding pin. If the break was anywhere else then there would be no way of repairing it, I just got lucky I guess.

I re-assemble the power supply and apply power to the computer and presto. The internal speaker beeps at me and the kb power led illuminates. Failures within transformers are relatively rare but I have just proven to myself that its more likely to happen than I originally thought.

image1

 

Taking some measurements ( -12v, -5v, 5v & 12v ).

4.97 volts DC, looks good to me!

image2

The red led on the logic board is busted, so I replace it with the only one I have on hand and it’s green.

image7

 

I also accidentally broke off one of the terminals on the a/c switch due to too much tinkering so I replaced it with one that illuminates. I like it better than the old one.

image8

A backup CRT TV hooked up.

image11

 

Passes self diagnostic tests

system-ok

That’s pretty much the end of this repair. I do have some issues with the keyboard which are fairly trivial and I’ll address that later when time permits.

 

References:

1. Apple 2e 6502 Computer Repair Information – SAMS COMPUTERFACTS

http://www.applefritter.com/files/Apple2e_Repair_SAMS1985.pdf

Feb 172016
 

What this article is about: This isn’t a conversion “how-to”, there is too much missing information for this to be used as such. It won’t teach you how to make a conversion since this is Strider specific.

This is more aimed at providing some technical info on cps1 and documents the process & tools used to fix a poorly converted game.


 

A rather interesting post came up from system11 on The Dumping-Union. Binaries were included of the images dumped from the EPROMs on the boardset pictured below.

This came from someone non-technical and with good reputation who worked
at Capcom US arcade section (proveable), he bought it from Capcom directly
(claimed but I see no reason to disbelieve) and seemed shocked when I
complained about it being converted.  We’ve got a GAL on there which I
can’t read, a bunch of chip matches in wrong locations and an unknown code
ROM.  No jumpers have been moved.  Clearly converted from a SF2 variant.

No idea why this exists.

So what we have below is a 90629B-3 B board populated to run Strider on a 90632C-1 C board with the CPS-B-17 PPU. The only CPS1 game to use this specific PPU was Street Fighter II: The World Warrior however, being a popular game Capcom used many different variations of this PPU.

strider_capcomus

What makes this particular conversion interesting is that according to system11, the PCB was purchased from a Capcom source who purchased it in-house.

It was bought from xxxxxxxxxxx:

He bought it when the Capcom arcade unit in the same building was winding down as I understand it.  He claimed not to know it was a conversion when I received it, and honestly given his background I do believe him. Probably a half finished tech project by one of the engineers.

Nobody can claim that this is an official “Strider” system, at best it could be described as an “in-house” conversion, poorly done but the engineers who worked on this obviously had better and more important things to do with their time.

There are several code related issues which prevents the game from running properly especially after you die at certain checkpoints and also some other issues which I discovered myself.

So now it turns out that the game doesn’t actually work properly if you die in stage 2, does anyone have any ideas what I can do with this boardset?

Looks like it was a World Warrior to begin with – CPS-B-17, so I’m leaning towards ‘throw it away and sell the A board’.

Having a shitty month so far.

I decide I want to help out and fix the game. This makes for an interesting project as I have done several conversions in the past for myself & friends but I no longer own a complete CPS1 system. Testing would be difficult however, thanks to MAME I can do most of it via the debugger. I would send the new versions to system11 and he would test the changes on his PCB and report back.

The first step was to reproduce the problem in MAME. I’m using a very old & hacked up version of MAME (v1.50) which is fine for what I’m doing.

To do this I make some code changes to the cps1.c driver & cps1.c found in video. Changes are highlighted in red.

Note I am modifying the Japan resale version of the driver, the choice was arbitrary. You can see that I have run the USA version of the ROMs in this driver in the past 🙂

mame setup 1

After re-compiling the code and running the game for the first time it was evident that their was a problem. Nothing showed up on the screen until the game entered the attract mode. Normally the post shows some text related to the power up tests. Since the screen is black until attract mode is entered there is nothing to show here.

To see what is going on, I decide to disassemble the code via dasm in MAME which generates a 20Mb text file containing 68k code. A decent amount if you like reading through tonnes of code and have nothing else better to do.

dasm 1.

I also fire up the US Strider (USA, B-Board 89624B-2) and disassemble the code. The hack is based off this U.S version.

Combining both files side by side using WinMerge allows me to see the changes the hackers made to the original. There are a total of 52 differences. But even that wasn’t enough!

WinMerge

I need to create a small table which represents the difference between cps_b_17 & cps_b_01 registers. I also need to describe what each address register is for ( layer control, priority mask..etc ) These move between different PPUs. So why did Capcom do this ? Perhaps for security to stop operators from easily converting games who look to avoid purchasing conversion kits, sounds plausible.

cpsbtech

According to MAME, cpsb registers start at a base address of 0x800140 and end at 0x80017f, this is true for all cpsb PPU variants. But the actual addresses for each register changes between PPUs.

cpsbtech2

For cpsb17, to get the address for the layer control I simply add 0x14 to the base address of 0x800140 which gives me 0x800154. 0x14 is taken directly from the table above in src\video\cps1.c.To get the first priority mask I add 0x12 to the base address of 0x800140. I go on until I have completed the column on the left. Similarly, I do the same for the cpsb_01 column until the table is complete.

I can check the existing work and have something to guide me a long the way by using this table. I normally write all of these details on a white board.

Since the original game uses the CPS_B_01 PPU I have put them both side by side in the table above. So if I need to change the palette control I substitute 0x800170 (cpsb01 ) for 0x80014a (cpsb17).

I now have what I need to start working on the code but to make editing simple I dump the two rom regions and combine them into one file using the MAME debugger and edit the driver to accept the single binary file. I do this to make editing and testing the binary straight forward.

Changes in red are made by adding comments to the two lines and adding the line in green.

Later I’ll split the single binary into two files once I’m happy with the results so that they can be burned to the EPROMs.

mame setup 2

Using the cpsb table I begin by searching for $800170 in the right hand column of WinMerge, I repeat this process for each register in the table. This is just my process of checking existing work. Note that there are no differences at 0x074CC4, $800170 is the palette control register used by the cpsb01 PPU but the hackers missed that. It should be $80014a for the new PPU.

fix1

Cross referencing the table, I change 170 to 14a in strider17.bin using a hex editor. This fixed the post and the power up tests are now visible.

post

The game also had an issue with the sky not showing up at all, this was only reproduced in MAME & not on the real PCB. I try to find out why.

no stars

The bits for the layer enables are written to address 0xFF0C74 ( 0xFF8000 – 0x738C ) in DRAM before being written to the layer control ( 0x800154 ). The value written here is the old value for the cpsb01 chip. 0x138e is coming from a location in ROM pointed at by A1 ( 0xB616 ).

stars fix 1

Here is the location in ROM that needs to be changed to 0x139a.

stars fix 2

Changing it fixed my sky. Although the old value still worked on system11’s PCB, it still wasn’t correct. My changes never broke the sky on the PCB, so I’m happy with the change although it made no difference.

stars fix 3

The sky is still missing in stage 1 & during the intro after you press start. But it’s not related to the problem found above.

stars fix 5

To get the sky to show up correctly I had to tweak the enable masks in MAME.  Street Fighter II: World Warrior is the only game that uses the CPS_B_17 PPU and not all the layer enables are used in the game, hence MAME only defines some of them which explains our missing sky in this instance. I could have left it alone as none of my changes require any alterations on the game EPROMs. It’s just nice to prove that missing stars has nothing to do with the PCB itself.

I create a new CPS_B_17 entry just for Strider as I don’t want to break Street Fighter. I then change the 4th layer enable mask from 0x00 to 0x04. I tried other values at first but 0x4 worked correctly. I also modify the config table to use the above new entry.

stars fix 6

Recompiling MAME and running the game brings the stary sky back. So now I can move on to more important stuff.

stars fixed

One of the complaints regarding bugs reported by system11 suggests that if you die at a certain checkpoint in stage 2 then the entire background disappears.  I reproduce this issue by playing the game.

stage 2 bug

I know from looking at the screen that this is a layer enable problem.  First I create a small table with the old enables for the cpsb01 board on the left and the cpsb17 masks on the right. The hackers have already done most of the work for me so I just go through all the differences for the layer enables which I found in WinMerge and make a note of them on my whiteboard to create the table below.

enable bits

I then create a bunch of watch points which are invoked when specific layer enable bits are written to the DRAM address 0xFF0C74. The value stored here is used later on and written to the layer control register at 0x800154.

stage 2 bug d

I play the game until I die and the debugger is invoked when the data written to 0xFF0C74 equals 0x138e. This needs to change to 0x139a to bring back the correct background.

The value 0x138e is read from A1 ( 0xb5e4 ) and that is the offset where I need to make the permanent change to the file.

stage 2 fix 1

But first, I want to see if overwriting 0xFF0C74 with 0x139a via MAME will bring back the correct background temporarily ( until I die at the same checkpoint of course ).

The changes worked as you can see below. So I’m definitely on the right track here.

stage 2 fix 2

Here is another issue in Stage 2, the background completely disappears after dying ( next screenshot ).  The debugger is invoked when it writes 0x138c to our DRAM address. This value comes from A1 which is hard coded at offset 0xB66C in the rom, i’ll change that value to 0x1392  later.

stage 2 wolves fix

And here is the result if I resume program execution.

stage 2 wolves

And the temporary fix by writing 0x1392 to DRAM: 0xFF0C74 which is later written to the layer control.

stage 2 wolves fix 2

Continuing on in stage 2 brings me close to the end of the level where I head up towards the large airship. Dying triggers the debugger on watch-point 3 as the layer enable value of 0x138C is written. This value will later be changed to 0x1392 at offset 0xB6B2 in the rom.

stage 2 airship

If I resume execution you can clearly see that the background is missing as Hiryu appears to be magically hovering in the sky.

stage 2 airship 2

Fixed temporarily by writing 0x1392 to DRAM: 0xFF0C74.

stage 2 airship 3

Finally this brings us to the large airship at the end of level. Dying triggers the debugger as the layer enable value of 0x138e is written. This value will later be changed to 0x139a at offset 0xB6F8.

stage 2 largeairship

Resuming execution shows a stary sky instead of the correct background.

stage 2 largeairship 2

Fixed temporarily by writing 0x139a to DRAM: 0xFF0C74.

stage 2 largeairship 3

This concludes the fix as far as stage 2 goes, I couldn’t see anymore problems in this stage.

I still want to fix the issues in attract mode. So let us take a look at the two issues I found. First issue was the missing dinosaur, it only showed up briefly before it explodes. The second issue was the missing satellite.

With my watchpoints set the debugger pops up when the layer enable bits equals 0x12ce. This needs to change to 0x12da, this is done at file offset 0xB81A which is held by A1 in the debug window.

dinosaur fix 1

I’m quite confident at this stage that my temporary changes will work so I don’t bother with those, I edit the binary, restart the game and our dinosaur appears behind Hiryu in the attract mode.

dinosaur fix 2

The other issue is the missing satellite. The fix needs the value 0xb5a instead of 0xb4e at offset 0xb9aa.

sat fix 1

Editing the binary at the said location fixes the issue.

sat fix 2

I still need to play through stages 3,4 & 5 to make sure there are no more surprises. Having my watch-points set and dying as often as I can will ensure that I cover all the bases ( hopefully ). There’s no difference to the process as documented above so I’ll just leave it at that.

I could have used a more shotgun approach and used a search and replace tool but then I run the risk of changing something I shouldn’t and breaking the game.

Once I’m happy with the changes the binary is split into two 512kb, word swapped and sent to system11 for testing on his PCB.