What's new

Truxton/Tatsujin Sprite/BG priority issue

Sumez

Student
Joined
Jan 16, 2020
Messages
34
Reaction score
21
Location
Denmark
I'm back to shamelessly leech on the knowledge of this forum with another PCB problem, hoping that someone around here knows enough about Toaplan hardware to recommend where to begin looking.
This is my third Toaplan PCB with an issue (out of six) - what an unfortunate statistic ;( I've actually had it for over ten years, and never spent much time with it, so I never noticed the issue before. But it might have been there all along, since it's easy to assume it's meant to behave like this until you run into one of the situations where sprites just block obvious things like the scoreboard on the screenshot below.

lhXOrpn.jpg
VP2ptWU.jpg
CnQoIHy.jpg

Basically, it seems every sprite in the game is displayed over the background layer used for the topmost overlay graphics like score characters and the gameover label.
Going by MAME, only a few sprites are supposed to display on top of these layers, such as the ships flying up on the title screen, and this priority is indicated by a few bits in the sprite memory and an similarly for BG tiles. Doubt it's a RAM problem, as only the bytes controlling priority are affected - Everything else in the game looks and plays completely fine.

The PCB looks nice and clean (except from the single scratch which I've confirmed doesn't break any traces), so at least there's nothing obvious at a glance, that visibly could be causing trouble.


EDIT: Actually the game has one other issue I forgot. The Coin A switch is constantly activated, so you can't coin up the game that way. Coin B still works though, so it's not a terrible issue, just annoying. I'm not measuring any connection for the switch when the board is turned off, so not sure what's causing it. And I doubt it's related to the sprite issue, but who knows. :)
 
Last edited:
That looks like a sprite priority issue, which seems to be controled by the Bi-Polar ROMs (BPROMs) for most Toaplan gen 1 games according to MAME
 
That looks like a sprite priority issue, which seems to be controled by the Bi-Polar ROMs (BPROMs) for most Toaplan gen 1 games according to MAME

All I could read from the mame source was that whoever wrote it had no idea an are just guessing. The BPROMs don't seem to actually do anything in MAME, even though they are a part of the rom set.
I took a logic probe to both BPROMs, and a few data pins show no activity on each, as well as one of the address pins on 13. Looking at the ROM data though, that makes sense most of the way (13 only has data on the lower half, and 12 doesn't use the upper three data bits on any byte).
However, data 2, 3, and 4 seem to be constantly low on ROM13. I don't know if that's my issue, or if I'm looking as a false negative here, and it's just expected behavior for whatever reason. Anything clever I can do to test?

EDIT: tried bridging one of the "silent" pins on ROM13 with one of the ones showing activity just to see the result, and some some combinations would straight up hide all sprites, so it's definitely not unlikely it has something to do with masking sprites.
 
Last edited:
What model are the PROMs? it couldn't hurt to make a replacement to test or piggy-back (if it's soldered in place)
 
What model are the PROMs? it couldn't hurt to make a replacement to test or piggy-back (if it's soldered in place)
I was thinking that. It's a "N82S123AN". As far as I can tell "AM27S19PC" is a drop-in replacement, which I can source at a surmountable price, but I'm not sure how to write to one. I only have a TL866II, and if it's supported by its software I don't know what to identify it as.

It's soldered in, otherwise it would probably be easy to check. I don't want to start desoldering stuff if I'm not sure it's the culprit. :)
Maybe if someone else has a Tatsujin/Truxton board, they can check if pins O2, O3, and O4 on ROM14 have activity (during the attract mode).
 
programmers that support BPROMs seem to be pretty uncommon as are replacement chips

for other stuff I've used these: https://www.etsy.com/au/listing/250251059/4-x-82s123-bipolar-prom-to-w27c512

it kinda sucks for replacement since you end up with a big ugly adapter sticking out of your PCB, but it should be good enough to test and confirm and that turns out to be the culprit then souce some old-stock chips and someone who can burn a proper sized replacement.
 
To me that adapter sounds like a band-aid solution moreso than a method to test for the source of the problem (the price, waiting for shipment, etc.). I'll keep it in mind though if it ends up becoming relevant. Hopefully someone has a good idea for anything else I could try testing on my PCB.
 
To me that adapter sounds like a band-aid solution moreso than a method to test for the source of the problem (the price, waiting for shipment, etc.). I'll keep it in mind though if it ends up becoming relevant. Hopefully someone has a good idea for anything else I could try testing on my PCB.
Here’s a video showing how you can test for faulty PROM using EPROM and breadboard.
 
To me that adapter sounds like a band-aid solution moreso than a method to test for the source of the problem
you can also use that adapter to dump BRPOMs on a programmer that doesn't support them. So you could dump the chips you have and compare source to MAME.

I agree that it's not the best solution for a one time fix, but I bought a handful of those adapter PCBs and they've come in handy for dumping and testing on a number of different PCBs.
 
Here’s a video showing how you can test for faulty PROM using EPROM and breadboard.
That's a pretty cool idea. I think I can make up something similar just using probe clips for the 5 address pins and the three data ones that I'm suspecting.
Is it possible to piggyback a hack solution like that on to the suspected failing IC when the legs are constantly reading low, or would the original pins have to be floating?

Sorry for asking newbie questions.
 
Ok as I was half expecting, I've been chasing a red herring. The PROMs work fine.


IMG_20220208_110323_resized_20220208_110533751.jpg

Just to verify, I wrote the contents to an EEPROM I had lying around, and connected it to the same address pins as the one on the PCB. Testing all the output pins, I'm getting the exact same reads as on the PCB PROM, with the same lines reading a constant low.


Any other good ideas for the potential culprit? :)
 
did you do the obvious and press down on big surface-mount chips?
 
Back
Top