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/editAre 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.
