furrtek
patreon
Bonus Round: Konami 007452
🕑 Added 2021-04-13 15:27:11 +0000 UTCToday's schematics release of the Konami 007452 chip comes with a "funny" story.
The main reason I started working on the 007121 video chip is because the rolling mines in Jotego's Contra core and MAME followed incorrect trajectories. That along some configuration bits marked as unknown in MAME's source code made us believe that the 007121 still held a few secrets.
Unfortunately, inspection of the 007121's schematics didn't explain why the mines were all going to the edges of the screen instead of spreading out from the center. The chip simply draws sprites where the CPU tells it to, there's no special animation or math functions.
A few days later, Jotego told me that he noticed that right before the mines appeared on screen, the CPU accessed currently unmapped locations at addresses 10, 11, 12 and 13.
MAME didn't implement those registers either and was just returning zero's. Changing the returned values made the mines trajectory change !
However it was now clear that the 007121 had nothing to do with those registers. It didn't "listen" to them, so something else on the board had to be mapped there.
Following the CPU's address lines on Contra's schematics (to which I hadn't paid much attention before), made me wonder what that small "007452 VRC&DMP" chip was doing apart from switching ROM banks. It was connected to enough address lines to decode accesses to 10, 11, 12 and 13, so it was a good candidate.
Looking for eventual info about the chip led to MAME's source code again, where it's qualified as a "security chip" performing 8 * 8 bit multiplications in W.E.C. Le Mans.
This game however only uses two registers: 0 and 1. It writes operand A in register 0, writes operand B in register 1, waits for a bit, and reads back the A*B result from register 0.
Cool ! Maybe the higher registers Contra uses are for a wider multiplier ? Maybe a decap and trace aren't worth it for such a simple function ?
Bad luck: manually entering the results of the multiplication with MAME's debugger didn't bring any improvement. Some mines now even went oustide of the screen...
It's at that point I realized that I had already decapped the 007452 months ago, when my Konami tree gave a few delicious dead boards from which to pull custom chips from.
It's a small Fujitsu gate array. Much smaller than the 007121, and with much more compact cells. I didn't feel like spending time trying to blindly guess what it was doing, and I expected it to be quick, so I traced it. For once my estimation wasn't too far off, it only took 4 nights.
One thing was clear from the start: the chip had 3 parts. One for bankswitching, one using regiters 0 and 1, and one using registers 2,3,4,5 (which are mapped to 10,11,12,13 in Contra).
Contra doesn't use regiters 0 and 1, but I still wanted to make sure a multiplier was there.
It actually took me more time to understand how shift-and-add multiplier optimizations worked, than to trace the die. A detail was bothering me: simulating the chip with all possible values for operands A and B gave correct results only if A was under 127.
Some head scratches and lots of schematic and die checks later, I came to the conclusion that it's just how it works: it's a 7 * 8 bit multiplier, giving a 15 bit result.
Setting the topmost bit of operand A causes it to give wrong results.
- An implementation mistake ? Probably not. I'd expect Konami engineers to know how to design a multiplier chip.
- A deliberate "mistake" to confuse bootleggers (and me by the way) ? Maybe. But W.E.C. Le Mans doesn't even set that topmost bit to see if the result is correct or not. So if would-be bootleggers implemented a simple 8*8 bit multiplier, it would work.
- A last-minute trim to fit the logic in a given die area ? Probably. Gate arrays are made from a range of master slices of pre-defined sizes. Since the 007452 uses almost all of the available cells, one could imagine that Konami removed the few gates needed for that 8th bit to make the design fit in a cheaper slice.
Now that's nice and all, but it doesn't reveal anything specially interesting. Registers 4, 5, 6, 7 are where it's at.
Those registers were wired to an arrangement that was very similar to the multiplier, except wider, as expected. The sequencer also counted 16 steps instead of 8 for the multiplier, so I knew that it was also a sequential operation, and that it took longer.
Just to see if the die trace was correct, I took the values Contra was writing to the registers, gave them to the chip's verilog simulation, and gave back the results to the game. The mines still went all over the place. F***.
The structure looked like a multiplier, but it clearly wasn't. The results weren't A*B, and the circuit had some differences that didn't make sense to me at first.
It took me way too long to realize that binary division could be done almost like multiplication: instead of shift-and-add, it's shift-and-subtract.
The whole darn thing was a simple 16 by 16 bit divider with 16 bit quotient and remainder. Basically the same operation performed by a 68000's DIVU instruction.
I certainly could have guessed that from the simulation results, but I had made a typo that caused the circuit's feedback value to be improperly selected at each step of the division operation, giving obviously totally wrong results...
Adding that simple function to MAME finally made the mines follow the right paths.
So at the end of this little adventure:
-The original culprit, the 007121, had nothing to do with the mines.
-The problem was caused by the "security" / simple math accelerator 007452.
-I could have been wiser.
-One last question remains: What the heck does "VRC&DMP" mean ? None of the other Konami chips have such names. Is it for "Very Repulsive Circuit & Dubious Mathematics Purpose" ?
Even if this is a free bonus post, I'd like to once again thank everyone who supports my work, be it financially or with comments (those are very appreciated !), the work of others in similar fields, and the work of emulator devs :)
The next post will be NeoGeo-related, with something soldering iron wielders might appreciate.
Comments
VRC- Virtual ROM Controller. DMP - Division Multiplication Processor ?
Nice find! Your work as a digital archeologist is amazingly important to the preservation effort.
