Supermodel Forum

The good news is that my Daytona 2 board does appear to work. Attract mode is running. The bad news is that there is a surprising graphics glitch that affects only the 3D graphics. My guess is that it is a problem with the texture memory or processor because the artifacts appear locked to geometry but I need to get better video (I don't have a capture card, sadly, so iPhone videos it'll have to be). I'll upload some tonight or tomorrow but in the meantime, this still image of the spinning AM2 logo illustrates the problem well.



Finding a step 2.0 (is there such a thing as a Step 2.1 video board?) video board on the cheap is going to be tough. For now, this isn't going to hurt anything. It will be a while before I can try to write any code for this board and the tilemap generator is just fine. But it would be nice to fix. I'll have a go at opening the enclosure tomorrow and dusting off the boards. Maybe I can take a look at the video board but I doubt a naked eye inspection will find anything.

Any suggestions would be helpful though Re-selling this thing is going to be hard. I wouldn't feel comfortable listing it without describing the glitch, even though the seller had no such scruples.

What do the self-tests show? Any texture fails? The self-test probably won't show any obvious fails. But you can check JTAG status in the service menu and read through this guide:
https://docs.google.com/document/d/1fJk ... PH0VQ/edit

Are the glitches on immediately adjacent scanlines, or are they spaced on odd/even only? That could narrow it down. Also it looks like my suspicion of 2 span pixels per clock might be right.
I have an extra video board but it also has more severe issues.

As these boards get older probably will be less and less working ones.
But corruption aside is it still good enough for testing with?

I think I can probably still do stuff with it but I have to return to California for a month next week so it'll have to wait until October. Never enough time

The seller has offered to refund it and take it back or give me a discount to keep it. I'm leaning toward keeping it because finding a network-based Step 2.x game is hard. Sega Rally 2 is available but for much more and apparently without the enclosure, fans, and filter board.

model3man wrote:What do the self-tests show? Any texture fails? The self-test probably won't show any obvious fails. But you can check JTAG status in the service menu and read through this guide:
https://docs.google.com/document/d/1fJk ... PH0VQ/edit

Are the glitches on immediately adjacent scanlines, or are they spaced on odd/even only? That could narrow it down. Also it looks like my suspicion of 2 span pixels per clock might be right.
I have an extra video board but it also has more severe issues.

I will check this tonight. I don't have any input wired up but I can use some jumper wires to get into the menus

This is an extremely interesting document. Did you produce it? Understanding how to map the software JTAG bit patterns to the actual chips would be very valuable for emulation purposes. Supermodel includes JTAG emulation code but I emulate it at the JTAG state machine level. I don't know what any of the data passing through means, other than that I have to listen for particular instruction patterns and return particular chip IDs. JTAG is not just used for diagnostics. Some of the chips are configured using it. For example, to get code running on my VF3 board, I actually had to duplicate some of the JTAG patterns being sent by the game otherwise 2D video would not come up properly. Unfortunately, looking at the code now, there may well be an off-by-one mismatch between how the emulation interprets bit patterns and how I encoded them in my Model 3 test app.

Ian and Harry Tuttle discovered that the Real3D shading logic might be configurable via JTAG. If you look at Src/Model3/JTAG.cpp and Src/Model3/Real3D.cpp, you will notice that we intercept a particular instruction that appears to affect how the shading calculation is clamped. We may have interpreted it incorrectly but it is definitely clear that this specific bit pattern gets written (and nothing else!) prior to scenes that look correct when rendered with the shading calculation modified appropriately.

Do you think it would be possible to map what is happening in JTAG.cpp to this list of pins and figure out what exactly that command is poking?

EDIT: Supermodel's bit positions are not in agreement with the document. We assume that the JTAG instruction register is 46 bits and that the data register is 197 bits, whereas you've found it has 2565 bits, evidently. I need to review the protocol but I thought it consisted of shifting in an instruction and then shifting in data, and that the instruction could be used to address which shift register was being loaded. Still, you've identified ICs that take 262 bits. I wonder how we can explain the discrepancy. I must have implemented the protocol incorrectly (I can't see how, it's straightforward) or have misinterpreted what I'm seeing.

EDIT2: I just counted the bits shifted in and out and in fact, I see 2605 data bits during the boundary scan. That's 40 more than listed in this guide. Indeed the Daytona boundary scan test reports errors up to bit position 2565 in Supermodel.

Hooked up a Sega pad to get into the service menu and sure enough, the texture RAM is bad (see attached). Boundary scan succeeded with 0 errors. The video memory test was a bit odd -- the first screen said "testing" or something to that effect, then the texture RAM error popped up. After I dismissed it, it went back to a blank video memory test screen and simply said to press Test to continue. There was no indication that other video RAM chips were okay (screenshot attached). Is this the expected behavior?

Later this week I can try to take apart the board and examine the suspect ICs but I imagine that they are internally damaged and it isn't something as simple as a bad solder joint. I can perhaps try to replace them if parts can be sourced but I've never done any SMT soldering and this is quite a board to start with!

Here is the behavior of the test mode in a functional game. (DU2PE)

https://drive.google.com/file/d/1HSWAZEzCyG74nPz6cZ3zF8YXhcfT4XSG/view?usp=sharing

These PCB are difficult to repair, and problematic over time.

Thank you! This looks like what I am seeing except for the texture RAM error. I will take a look at those ICs at some point this week. I don't have experience with SMT parts but maybe there will be some obvious defect like a bad joint. If not, then I guess at some point I will need to learn how to remove and solder new parts on Hopefully the chips are still available somewhere.

I can't take credit for the repair guide, that's done by crackedMagnet : https://www.aussiearcade.com/forum/arca ... pair-guide

So it looks like your MARS 00's ram has a fault. That could be any one of the 8 CDRAMs attached to it.
It could be a single failed ram, or even a couple.

Probably if it were my board I would hot air that part of the board (the lower right MARS ram near the empty vga connectors) not to the point of melting solder, but much hotter then normal. Then quickly put the board stack back together and run the test. If that works you could try heating each indivuidual RAM.


The other option is to source at least several of these chips (They are a bit less easy to find than the 3dram) and swap out the chips one by one until you see a change in test behavior. Then you can verify the rams you already swapped out as still good, and just leave the new ones on where the are.


I can easily swap out the chips and test in my boardstack (done hundreds if not thousands of chip reworks and proto assembly) but sourcing the chips might be the hardest part. If you can get them I can probably fix your board.


It may be possilbe to find more detailed information about which exact chip fails based on the JTAG chain, which I unfortunately know very little about, apart from using to configure FPGAs.

I've found a donor graphics card with the necessary CDRAM for $75, if the chips can't be sourced from China. Edit: The CDRAMs used on various 90s workstations graphics are all 16megabit sizes - the M5M4V16169. They are also the faster speed rated versions.
No datasheets are available for it. But, checking the datasheet for the smaller 4Mbit one used on Sega's board, the DRAM column access is restricted to 32 entries with 3 address bits masked off. So my thinking is that, based on what I know from conventional SDRAM, the larger CDRAM probaly just has more column width mapped into another 2 bits to provide the 4x capacity. The issue is that the row/column addressing is multiplexed and changes every cycle. If these unused bits are hardwired to either 0 or 1 (doesn't matter) then the larger CDRAM part will work fine, since the accesses will be restricted only to the relevant part of its column addressing.

However, the original part is known to work.
The part number if you want to go looking is
M5M4V4169CTP-15
The important searchable bit is M5M4V4169, the other numbers may change according to production batch or exact variant which I don't think is important