Apr 232017
 


Its hard for me to believe that i’ve been maintaining this program since 2011.
I’ve added to this as I needed extra functionality and for the last 12 months or so its been untouched but for the last few weeks I’ve been rewriting some parts I wasn’t happy with and changing a few things around.
Its now got to the point where I think its pretty much complete (although i’ve said that before) so though it was about time I did a proper post on some of the things it does and how to use it.
I wont go into everything as I dont think I need to but let me know.

What does it do?
Back when I started this program I wanted a quick, easy and no fuss way of quickly interleaving, deinterleaving and byte swapping files. That’s exactly what it did but that’s all it did.
Take a look

What it does now:

  • Create a new files filled with recurring byte or word values
  • Analyse a file (8 bit or 16 bit) – check for stuck bits, upper and lower halfs matching, etc
  • Bit manipulation – simulate stuck bits in a file & swap bit order of address and/or data bus
  • Byte swap
  • Deinterleave
  • Invert the whole file
  • Reverse the file
  • Split the file in to smaller files
  • Swap the upper and lower half of the file
  • Concatenate up to 4 files at once
  • Interleave in 16 bit or 32 bit format
  • Compare 2 files – checks how many bytes match
  • Display CRC32, SHA1 and MD5 hash values

Creating a new file
Click the ‘Single File’ menu and select ‘Create a new file’
You should see this

You can fill the new file with a byte pattern or a word pattern.
To fill with a specified byte pattern you can enter something like this

This will fill each byte with a value of 0x55
To fill with a word pattern you will enter

This will fill the file with the word value 0x55AA

If the slot is empty you can also load a file by double clicking on the slot.
You can overwrite any loaded file by dragging and dropping a new file onto the slot.

Analysing a file
Analysing a file check for a few things.
First you will need to select from the menu whether the binary file you loaded is from an 8 bit or 16 bit source.
The output from the analysis will be displayed in the Log window.
In this example I have created a new file filled with 0x0

As you can see it has flagged up all the bits (8 bit) as being stuck LOW. This means that throughout the file non of the bits changed from logic state 0.
It also shows that the upper and lower half of the file are filled with 0x0. If the file (or half the file) was filled with 0xFF then this would be flagged instead.
Finally, we have flagged up that the upper half of the file is identical to the lower half of the file.

Viewing the file contents
There is a basic HEX viewer built in to the program. Just double click on any of the loaded slots to view it.

Checksums
There are 3 different checksums that the program can show you.
The default is CRC32 but by clicking on the “CRC32” box you can cycle between CRC32, SHA-1 and MD5.

Compare files
If any loaded file is the same as another file that is already loaded you will get an instant notification in the Log window that is matches

If however the files are not a match, its sometimes nice to see how much of the file actually does match. For example, if you have a a new revision ROM dump of a game you might want to see how much has actually changed. If its just 1 byte different then it could be bit rot or a region code change.

I think the rest of the functionality is self explanatory so wont go into it.
The program is in the software section now.
Please do let me know if you find this program useful, find any bugs or maybe want to see something added or changed (no guarantees though).

 Posted by at 2:21 pm
Apr 152017
 

I’ve decided to do this in two parts, the reason for this is that the faults to this board are so extensive. I am convinced that this board was hit by a bolt of lightning.

Symptoms – game booting to a screen full of zeros and watchdog barking. Z80s reset pin was also asserting but the sequence was incorrect ( just a hi flashing signal on the logic probe with no low ). There was also a perpetual low frequency sound with a higher pitched sound superimposed on top of that.

Did the usual troubleshooting. +5.15v voltage at the edge and 4.5v at the chips. Thought this was a little low. Something is dragging it down, I decide not to panic too much.

A previous repair was attempted so I decided to check all the socketed chips out of circuit first before proceeding with my own troubleshooting. Brand new components H16,E12,G17,G18 and the 74LS245 at H17 tested good. All EPROMs on the top board checked out fine with romident.

The owner of the board mentioned that the board was activating the coin meter on its own, then that eventually stopped. I take a stab at the 74LS08 at A2 which seems to drive COIN 2. My logic probe registers dead outputs on the chip and it tests bad out of circuit too. Of course changing it made no difference to how the game runs. I would soon discover that the 74ls08 seems to be a high failure Fujitsu component in this board.

Troubleshooting the z80 reset

I wanted to check out what was going on with the strange reset behavior of the Z80 reset line first.I remove D18 and test it out of circuit, sure enough it tests bad so I replace it. This fixes the reset signal and it’s now going from low to high as expected. Half the pins on the z80 are floating and the data lines aren’t toggling so I remove it and install a replacement from a parts board. The new z80 is alive although not for long before the CPU crashes and the data lines get stuck again.

At some point in the repair the Z80’s data lines stopped toggling again from an initial reset. I traced this to stuck enables on the LS138 at C18 which tested fine out of circuit but the 74LS08 at C9 feeding /G2A on C18 actually failed. Replacing C9 fixed it again. I still had stuck /OEs on both sound EPROMs but I would look at this issue later.

For some reason A16 on the bottom board caught my attention, of course this was a Fujitsu branded 74LS08 as well. I had a brand new one in my hand so I thought “what the hell” and piggy backed the new one on top of it. This seems to have cleared the screen with the initial junk. I also found another bad 74LS08 at H2 which changed nothing after replacing it.

I also found 4 additional bad chips @  F13, E15,C12 & C14 and replaced those with no obvious change.

Troubleshooting the Konami1 – watchdog / reset issue

With pin 19 barking furiously I decided to trace it’s origin thinking that perhaps there was a problem with the watchdog. Both /E and /Q  clock frequencies were correct on the CPU ( 1.53Mhz ) .

I found a bad resistor at r43 ( measured 2kohms instead of 1kohm ) so I replaced it, no change.The reset signal actually originates from the bottom board .I traced and tested every chip in it’s path starting from the Konami1. ( top board [D18, B2 then the CR13 connector], bottom board [A1,G2,C4, 504 ].  G2 ( Another Fujitsu 74LS08 ) tested bad, replacing it didn’t change anything after testing. I was starting to lose confidence at this point.

I started to probe the /OE enables to the game EPROMs and saw that every single output was stuck high right from reset. Pins 4 and 5 ( /G2A and /G2B ) of the LS138 @ H16 were floating. For y0-y7 output to go active low, the two above mentioned inputs must be low. Since pins 4 & 5 are tied together I traced this back to pin 28 output of the Konami1. I replaced the CPU temporarily with mine from my Gyruss PCB and now I was getting a screen full of Hs, This meant that the CPU was actually executing code from ROM.

I installed the original CPU back into the PCB and measured around 1v on the inputs of pins 4 & 5 of the LS138. I would soon discover that the CPU was faulty on this line only. This CPU actually works fine in my Gyruss board [ Gyruss does not use the output of pin 28 of the Konami1 ]. So I added a 1kohm pull down resistor between pins 4,5 and ground on the LS138. This pulled the 1v down to more acceptable TTL levels and I finally got this CPU to boot to the screen full of Hs just as you see above with the good CPU. The sprite colours now seem to be showing incorrectly with red streaks compared with the last screenshot.

I installed my testrom into G15 which showed that the main RAM at G2 was bad.

I removed the RAM, socketed the board but the RAM tested good in my TopMax. I probed the RAM with my logic probe and saw no write enable active at all. That would do it! It seems there was a broken trace right near pin 8 of H11 when removing the chip, this was the write enable output to the main RAM. Reconnecting this line fixed the RAM error. The game was finally able to boot with the typical HS issues.

 

Revisiting the stuck /OE on the sound EPROMs

This ended up being bad 2114s on the top board ( C16 & C17 ). After replacing these I now had sound but unfortunately speech isn’t working. The data lines on the chip are all floating and there seems to be no clock at all. At this point it looks like a bad VLM5030 chip which I’ll have to look at later when I can get a spare.

Video issues

Replacing all four 2114s on the bottom board fixed the flickering but the colour issue still remained. I removed all bipolar PROMs and they all had the wrong checksums. So I’m going to order some and hope to fix the that also.

I’ve also decided to start using my LCD instead of the CRT which seems to have some issues displaying colours at the correct position near the edges of the screen.

After replacing the 2114 rams the Hs look a little wonky and there are some still random sprites. I’m hoping this is normal though. I’m guessing it is since the game code hasn’t had the chance to clear the object and scroll ram so it probably takes on some random values causing the wonkyness and random sprites before proper initialization takes place.

Re-working the Hypersports testrom.

My Hypersports testrom has not been that useful at this point with the text wrapping around the screen and I should have never released it in the first place without testing it myself on real hardware. The 2114 rams on the bottom board are actually banked and occupy the same address by enabling and disabling hardware interrupts ( IRQ ). I had some trouble clearing the scroll and object RAM and it turns out I was only clearing H8 & H9. By enabling interrupts and modifying my code I was able to clear J8 & J9. I confirmed this after looking at the schematics [ the IRQ input to H2 and one of its outputs /OBJSEL  ]

I wrote some code to test this and I was able to clear the screen correctly after setting up and enabling the IRQ, then writing 0s from 0x1000 – 0x13ff within the interrupt routine. The results are more than I could have hoped for.

Now all I have to do is implement the checks on J8 & J9 within my IRQ routine. Once that’s done and the necessary changes added then our runner should appear across the screen just like in T&F 🙂

Namco System 1 CPU board repair log #1

 General, PCB Repair Logs  Comments Off on Namco System 1 CPU board repair log #1
Jan 042017
 

Got this Namco System 1 CPU board from my friend (and member here) Corrado:

He told me the board developed a color issue, the GREEN was missing at all.He troubleshooted it and was sure that it was due a faulty custom ‘C116’ which generates the RGB video output:

but he had no spare of it so decided to send me the board.Once received I could see myself the issue trying the board with a Galaga88 ROM board:

Besides the missing GREEN color, the board behaved strangely.You could not coin-up with both players but only with the SERVICE button but, once started a game, a “TEST PROGRAM INITIALIZE ERROR” message was displayed.I probed the outputs of this custom ‘C116’ and all the ones related to the GREEN color were stuck low:

I removed the faulty one:

The spare was taken from a Point Blank donor board (this custom is present also on Namco System 2 hardware)

I carefully soldered the IC on the faulty PCB:

Powered up the boardset and :

No more issues!Board 100% fixed.

 Posted by at 3:23 pm
Nov 132016
 

Recently a user on the UKVAC forums released his home made tester known as the AR81 upon the world.
http://www.arcadetester.co.uk
Original forum thread can be found HERE

It has many uses and more are being added regularly. The most interesting to me was the ability to check TTL in circuit.
20161016_163945

It accomplishes this by storing states of known good chips and then taking a snapshot of all the pins at a given time then comparing the snapshot against its own database of stored states.
I’ve had pretty good results using this feature so far and found it useful enough to devote some time towards expanding its databases.

I currently have some concerns about how users of this will go about sharing their state map files. There is a github that has these files on which I believe is considered ‘official’ but what if I have a drastically different set of states stored in my file when I come to upload it, what happens to the states that might have been stored in the github version if I don’t have them in mine? Now its worth mentioning I dont really understand github and although I am aware of diff files I don’t know how they work or what their limitations are. It may well be the case that it can handle this scenario without problems. If it does then great, that’s one of my concerns dealt with.
My other concern is who’s checking these files? What if someone has uploaded a new set of states that is just wrong or flawed in some way? It could go unnoticed for quite some time.
With that in mind I set to work creating some tools to let me deal with both of these problems.
I know have 3 different program made.
The second two I made are closely related so ill deal with those first.
One of them can be used to merge two files together but will exclude any entries that are duplicates. It can also be used for checking an existing file does not contain duplicates or any other strangeness like incorrect formatting of the unused pins or the GND pin not being defined as 0 etc. Its final use is to display individual state maps on screen in a more user friendly format so they can be manually confirmed for correctness (or not). If not then they can be removed easily.
adtcheck

So far I have successfully used it to remove a few errors I have found among various files and I am currently in the process of putting a set of files together that I believe are functionally correct. If they aren’t in some way then at least the blame can be accounted to me and not someone else.

The third program I made is in early development but has been a massive time saver.
Take for example a 74LS245 chip. The total number of valid state combinations is 512. Now that’s excluding any states that occur while the /OE is HIGH. I personally don’t feel those should be included as the chip should be in high impedance mode. Others may completely disagree with me but that’s fine, I can see both sides of the argument. There is a new version of the software on its way that allows the user to specify and output enable pin and state so any test results will be ignored if not in the correct state.
Anyway, finding and saving all these states from a working chip in circuit is going to be a massive task. Given the relatively simple operation of the 245 it was easy enough to procedurally generate all 512 valid logic states which is what this program does.
I will add more chips as I get around to it but doing this procedurally gives me a ‘complete’ state map for a particular device.

Now, back to my first program. As anyone that visits this site will know I’m heavily into PAL chip dumping. Due to the way we ‘dump’ these PAL chips I end up with a binary files of all possible logic states for any given address. Using this binary file I can now create a state map for the tester so any compatible 20 pin PAL/GAL/PLS chip can be tested in circuit. Adding to the functionality of that it now also supports the 82S123 PROM. More devices will be supported as I get around to them as well.

I’ve spent a lot of time recently working on these files, much more time than i’ve spent actually troubleshooting with it but I think the end result will be worth it and hopefully everyone that uses one of these can benefit from it.
The files I create will be available from the relevant area in the downloads section once it has been created.

 Posted by at 2:14 pm
Sep 022016
 

Some time ago Caius made a post regarding a cheap alternative to the very expensive curve tracer equipment called ‘Octopus’.
I’ve always meant too build one of these myself but never did get around to it.
Recently I came across this website where a guy called Jason Jones has designed a USB powered curve tracer circuit.
All the files required to build one yourself have been released on github here
20160902_163336
20160902_163343

Its easy enough to put together. I used a Pickit 3 to program the PIC in circuit which was painless enough once I had the .hex file sent to me by Jason as I couldnt work my way around the new MPLAB software. The header allows the Pickit 3 to plug straight on. I did have to power the circuit via USB as well while programming as my Pickit complained the voltage was too low if I used the Pickit itself to power it.

Jason has also made PC software in Python to remove the need to have an oscilloscope which works well enough but you can easily use a scope and works very well using my Rigol DS1054 scope.
20160824_183647
20160824_183754
20160824_184035
curve_gui1
curve_gui2

Im very happy to have this in my ever growing collection of test equipment.
Thanks very much to Jason Jones for the project and for the help with the firmware.

 Posted by at 4:54 pm