SpritesMind.Net

We've hit a weird problem with one of Montserrat's consoles over on the UMDK forum:

viewtopic.php?f=20&t=2239&start=195#p28406

This is a EURO PAL-i 1601-05 VA6 with a switchless mod by matt at dforce3000, failing to start Sonic 1. The SGDK-based UMDK menu program works fine, and the UMDK basic signal test passes, so it's not a dirty cart-slot problem. The same UMDK cart works on Montserrat's three(!) other consoles, one of which has the same switchless mod. Several other people have tested UMDK carts from the same manufacturing run, and none of them have shown similar problems. On this one particular console, it seems like the 68000 just stops fetching instructions, as if its clock has just stopped or the bus arbiter is permanently suppressing the 68000. There are some traces from UMDK's built-in logic analyzer in the post above, and there's an (older) analysis of a UMDK instruction trace in this post:

viewtopic.php?f=20&t=2239&start=180#p28339

Suggestions welcome!

Is !DTACK stuck high or such ?

TmEE co.(TM) wrote:Is !DTACK stuck high or such ?

It's not my console that's doing it so I can't check, but I asked Montserrat to look at various 68000 signals like /DTACK, /BG, /BGACK, /BR, /BERR and CLK. That said, I'm pretty sure the 68000 ignores the state of /DTACK unless /OE, /LDSW or /UDSW are asserted, and you can see from the logic analyzer traces that they all end up deasserted. My guess is that this is just a very old console which is in need of replacement PSU capacitors, and it's misbehaving as a result: the logic analyzer trace shows the tri-stated address bus picking up a lot of noise from somewhere.

It would be nice if there was also log of what data was actually read, to confirm that all stuff read normaly.

r57shell wrote:It would be nice if there was also log of what data was actually read, to confirm that all stuff read normaly.

With the UMDK's logic analyzer in trace mode, the fetch-sequence looked like this.