All Konami TMNT video chips traced ! (Patreon)

This is it, the second-to-last post about Konami's TMNT hardware.

There are a few things I want to address in this paid post:

1) The results !

The schematics an svg trace for each chip are on Github, they're not 100% cleaned up (could be presented in better way, some nets still have to be named) but they don't have any ERC errors. They'll get updated progressively as I translate them to verilog.

Tilemap address gen: https://github.com/furrtek/VGChips/tree/master/Konami/052109
Tilemap serializer: https://github.com/furrtek/VGChips/tree/master/Konami/051962

Sprite address gen: https://github.com/furrtek/VGChips/tree/master/Konami/051960
Sprite line buffer/serializer: https://github.com/furrtek/VGChips/tree/master/Konami/051937

PCM sounchip, which was done in 2021: https://github.com/furrtek/VGChips/tree/master/Konami/007232

2) Technical note about sprites

It's (almost) common knowledge in the retro community that the NeoGeo has a rather brute-force approach at putting things on the screen. I like to compare it to a bulldozer, it does a simple thing (render sprites) but in a fast and efficient way. In this regard I started realizing that many other 2D systems were "smarter", even if their pixel bandwidth was much lower.

The TMNT hardware is an example: it can only have 128 concurrent sprites (vs. 381 for the NeoGeo), which can have sizes up to 64x64 pixels (vs. 512x512), both have shrinking capabilities. The rendering rate may be the same as the NeoGeo (1536px/line) or half of that, I'm not sure yet.

However, the way the 051960 chip handles the scanline match check is much smarter than what the NeoGeo does. This check is performed by line buffer-based hardware to form a list of sprites that will need to be rendered on the next line. The raster counter is compared to the sprite's vertical position + its height, if it falls in the range then a row from that sprite will have to be copied from ROM to the line buffer.

On the NeoGeo, a sprite height is defined as a number of 16x16 tiles. The sprite chip uses that rather coarse value as a "window" to match the sprites and in which to render the scaled (or not) graphics.
If the scaled sprite is smaller than the window, then there will be many useless transparent rows copied, taking up rendering time for nothing (counting in 1536 pixels max per line limit).
ADK's engineer(s) probably thought that it wasn't going to be a big loss compared to the VRAM space and silicon area savings brought by simpler logic. If the game engine is advanced enough to update the height depending on the shrinking value, then 15 rows of 16 pixels worth of render time would be wasted at most.

The 051960 actually uses the vertical shrinking value itself to perform the match check. It does so by using a clever method of successive additions and checking the carry output at each stage, which gives per-line row matching (never any waste !) at the cost of slower sprite processing.

In at least this part of the logic, I think that the TMNT hardware outsmarts the NeoGeo.

3) What's next

Those chips were already understood at a high-level well enough by MAME authors to already provide very good emulation of the systems using them. Some undocummented register bits may solve a few inaccuracies, but overall there weren't really any mysteries.

Since repros of the chips won't be possible anytime soon because of the usual reasons (5V compatiliby with 3.3V parts, physical size, manufacturing cost vs. price of the whole game PCB...), I'd like to provide something a bit more meaningful than shematics, under the form of a MiSTer core :)

Work towards achieving this has begun, and I'm hoping to have at least TMNT working for March or April of this year.

Aliens, Block Hole, Cue Brick, Gang Busters, Gradius 3, Missing in Action, Punk Shot, and Super Contra all share the same chips (apart from the CPU) so those may come in quick succession once the TMNT core is fully debugged.

4) About Patreon and benefits

If it isn't already obvious, I'm very bad at the community-building and personnal-branding stuff.

Because of my weird brain, one of the only ways I'm able to work is to put stuff out there, and accept $ if people find some use in it. It may sound stupid to some as it's a door open to abuse, but it's very hard for me to handle the pressure of expectations for a given date, or a given amont of work.

I've recently discovered that Patreon had an "exit survey" page for creators, which is the main reason I wanted to write something about this. Some of you had written lenghty explanations as to why they chose to delete their pledge in favor of more important/urgent things: please don't ! You don't have to justify your choice, I'm fully aware that there are many more important things in life than preserving old videogames !

Most of the other specified reasons were about the lack of frequent posts and content shared exclusively on Patreon, which I also fully understand. Because of the way both websites are designed, I tend to actually post more updates on Twitter than on Patreon because I actually rarely have much to say apart from a few words and a picture.

If some of you have any suggestions about a better fitting platform (short posts, more one-shot donations oriented) could be used, please let me know.

Once again, even if there hasn't been much patron-exclusive content as rewards (I don't really like that artist<->fans system for non-artistic work tbh), I'd like to thank every single one of you who pledged or helped in any other kind of way. I was recently able to upgrade my imaging setup thanks to all of you, meaning that I will soon be able to publish many exploitable chip images for others to give silicon reverse-engineering a shot :)

By the way, here's a web viewer for the 051937 on John McMaster's siliconpr0n.org: https://siliconpr0n.org/map/konami/051937/mz/