By: ????????? Released: ????????? Display: Vertical (cocktail and upright modes) Pinout: Konami CPU: 2 x 6809 and 1 x Z80 Players: 2 (alternating play) Identifying Marks: ??????????? I had encountered this game only once in my lifetime, on a ferrie somewhere, I can't even remember where, it was so long ago. But I do remember that I was blown away by the graphics (at the time). I finally stumbled across a screenshot of TP84 a little while ago, and recognized it and said "Gotta have one!" and here it is :-) but... it turned out to be terminally broken in several ways. The problems and my progress on them are listed below. The game is darn close to working now, but something isn't quite right still. Continual Resets by Watchdog Timer To attack this problem, I got my hands on a schematic, and had a look at the watchdog generator. The idea is, the watchdog is set to a big number, then it counts down. When it hits 0, it resets the whole game. The catch is, the CPU must reset the watchdog FIRST, back to it's high number, so it must start over counting down. It should never reach 0 if the game is operating correctly. Most watchdogs also have an inhibit somewhere. Join two pads or flip a switch or something like that, and the watchdog can be ignored. That doesn't solve the real problem though, it just might be handy for tracking the problem, as you'll see shortly. The circuit for TP84 has two watchdog clears, one from each of the main CPU's. It appears that the sound CPU can be totally fucked and the game won't care. I used the watchdog inhibit and found that the SUB CPU (2nd one) was not generating any watchdog signals after the game crashed, while the main CPU continued to generate them. So - big clue. The sub CPU is not running code properly. I checked the address decoder. It was not functioning properly, and was replaced. Now I get a "Sub ROM Bad!" message, then the game resets and tries again. Sub ROM Bad! Message on startup Ok, which ROM is the SUB Rom?!?!? ug. There are about 10. I decided to boot up MAME and sequentially corrupt one ROM file at a time until I found the one which causes the same startup error in the emulator :-) It was 10D. I replaced the buffers and latches around it in an attempt to fix it and learned a valuable lesson: Stabbing in the dark gets you nowhere. I checked the address decoder - holy cow, it's dead. Two bad address decoders on this game. How strange. The game still didn't work, so there are more problems. I ohm's tested all the pins on the ROM for continuity. I found that 2 data pins were shorted somehow! I had to desolder all the work I'd done, and examine the bare board very carefully for the location at which those two traces were shorting. It turned out to be a location near one of the buffers where both traces went to the other side of the board through some solder-filled holes which were *very* close to eachother. They were bridged. DOH! Ok, fixed that and put all the chips back and now it will boot into the game properly (still missing sprites), but only when one of the buffers is REMOVED :-) If it's still present, the game reports a bad Sub ROM. I believe that two devices are attempting to use the bus simultanuously and causing the ROM to appear to have bad data, because this particular buffer connects the sub cpu's bus to the main cpu's bus. For now, I am leaving this alone and attacking other problems. Continual buzzing sound, no normal audio The Sound board appears to be a completely independent board (cpu and ram) and communicates with the main board through the use of 3 things: 1) The data bus from the main board is offered for the sound board to latch at the right time. (8 bits of data) 2) There is a signal to tell the sound board to remember (latch) that data on the bus because it's a command to the sound cpu (signal to the data bus latch) 3) There is a signal from the main board telling the sound board that data has been latched and is ready to be checked as soon as is convenient (interrupt signal to the CPU) Quickly checking the sound cpu I was able to figure out the address decoder chip was not selecting the ROM with the code in it, so it's highly unlikely that the cpu is executing anything of value. Oh my god - a third bad address decoder. I replaced it. I tested the remaining two address decoders on the boards, found one more dead one, and scratched my head as to why almost all of them were toast. That was wierd. Now, the cpu is accessing the ROM. Still a buzzing sound is heard. I checked the ram chips for /CS signals. they were ok. That's good, considering I just finished replacing that pesky address decoder! I checked those 3 signal sources I mentioned above. The game was providing information to the sound board. The sound board was simply not operating correctly. It was being informed of the presence of new data, but it was not going and collecting that data. I replaced the ram chips on a whim, and that cleared up the buzz. The board now appears to be working perfectly. Well, all except for the fact that there's *no* sound now. :-) But all the data above is operating correctly, and I can see the sound board notified of new data each time I press the fire button, for example. The sound chips are getting 0's written into them now, leading me to believe the sound cpu can not interpret the command and is therefor asking everything to be quiet. I suspect now that the sound command byte is being lost on its' way to the sound board because of that one missing buffer which allows the main and sub cpu's to share their data bus's. The path to the sound bus is on the sub-cpu's side, however, it appears that the main cpu generates the sound data. Flipped letters and background cells Finding the root of the flipped characters was interesting, it lead me in the direction of the pixel clocks and video generators. The game uses a chip which generates a counter from 0..255 for vertical resolution, and 0..511 for horizontal resolution (remember, the screen is rotated for this game though, which messes with your idea of horizontal and vertical). The numbers are then XOR'd with the FLIP signal for each axis. This has the effect of reversing the direction of count, and therefore the appearance of the image on the screen :-) So, my letters appeared backwards. This means one of the flip signals was probably dead. Sure enough, tracing one of them back to a latch resulted in me finding a dead latch. Sparkling letters and/or backgrounds - sparkles get worse over time The sparkling image would fade in as the power was applied for a length of time. As one of those chips warmed up, it would loose its' ability to switch cleanly or some such problem. I was able to find it by spraying chips with freon-like stuff that cools them to -50' in a flash. By hitting various chips, I was able to find the one which was sensitive to heat, and replaced it. This resulted in a perfect image :-) No Sprites no known fix yet. No Sound Effects no known fix yet.