UMDK manufacturing, part 2: Software

[Montserrat]

Can you try grabbing four or five similar traces, to see if it fails in different places?

Also a trace from the game that gives a red screen? Streets of Rage was it?

This PAL-I machine is modded? What is the mod? Where does the mod connect to the circuit board?

I've aplied a switchless mod, i did the same way as for the pal-1 asian version, id added a PDF with the details next to the new traces:

About the traces, i've done 5 new sonic1 traces in a row whitout shutting down the console and got something interesting A and B did similar, C begin giving me "dots" slowly, but D and E, managed to reach the SEGA logo with the illegal error thing.

Also uploaded some other traces from Streets of rage 1 and 3, that gives me RED screen, an Alissia Dragoon, and mega turrican (black screen both)

https://mega.nz/#F!mdNkiAxR!5MGVKdBBcevM7nNDVgBvbw

The pal-i version was from UK, and its working correctly in all regions modes, yesterday was playing a master system game for a couple of hours. (Asterix s fk...hard)

[prophet36]

I've aplied a switchless mod, i did the same way as for the pal-1 asian version, id added a PDF with the details next to the new traces:

About the traces, i've done 5 new sonic1 traces in a row whitout shutting down the console and got something interesting A and B did similar, C begin giving me "dots" slowly, but D and E, managed to reach the SEGA logo with the illegal error thing.

OK, thanks for all that info. It'll take a while to analyze properly but it looks like the Sonic "C" file looks to be crashing in exactly the same way as the first trace you took. D and E look like the same problem as with the PAL-G machine, that (I think) we now understand. "A" appears to get a bad return address at the end of a subroutine, which feels similar to the problem with "C". I have not looked at B properly yet.

I think I need to spend time implementing the improved logic analyzer thing I was talking about before. That will give a much clearer picture of what's going on at the signal level, but it will need some careful triggering because there's not enough USB bandwidth to sample all the bus signals continuously (i.e we'll get a single block of samples, 85μs in duration).

[TestSubject06]

Just poking my head back in - I have all of the parts, but I'm still waiting on the boards.

Prophet - the unlabeled resistor at R11 in the BOM can be anything, right?

Also where can I get a 3-pin jumper cap?

[prophet36]

the unlabeled resistor at R11 in the BOM can be anything, right?

R7, R8, C30, R11 & R12 on the LX9 board are all unused by the UMDKv2 design and should be left unpopulated. Similarly for Q2 on the bridge-board. I think everything else on the BOM is described by the LX9 and bridge NOTES.txt files.

Also where can I get a 3-pin jumper cap?

Why would you need a 3-pin jumper cap? J4 allows you to select the source of the +5V rail - either from USB or from an EXTernal source (like the MegaDrive). You should never short all three pins; doing so would probably damage either your computer's USB port or your MegaDrive, or both.

[TestSubject06]

Why would you need a 3-pin jumper cap? J4 allows you to select the source of the +5V rail - either from USB or from an EXTernal source (like the MegaDrive). You should never short all three pins; doing so would probably damage either your computer's USB port or your MegaDrive, or both.

Oh, that makes so much more sense. I just saw 3-pin jumper and didn't think of it being a 2-option jumper.

[Montserrat]

For the forthcoming next i will told the manufacturer to include 4 jumpers, so cant be any confusion that can damage hardware, it shouldnt affect the price.

[Grind]

Finally got around to running the tests again. I seem to have a problem with the onboard flash tests I did not have last month when I first got the cart.

Code: Select all

$ cmp readback.bin random.bin 
readback.bin random.bin differ: byte 77590, line 299

It's a different line every time I run the test so maybe the connection has a problem. I have 30 MB/s speeds with the cable I'm using, and all other tests passed including the MD5 one.

Loading ROMs works fine just like before. Actually better, because I don't have to "time" it just after hitting the power switch

ddd working too. I think I forgot to format the SD card though.

Screenshot from 2016-01-02 16-47-11.png (37.74 KiB) Viewed 29930 times

[prophet36]

I seem to have a problem with the onboard flash tests I did not have last month when I first got the cart.

Code: Select all

$ cmp readback.bin random.bin
readback.bin random.bin differ: byte 77590, line 299

That looks like the flash readback test, which didn't exist last month.

If the cmp command returns an error like "readback.bin random.bin differ: byte 1234, line 123", then the test has failed. Try running the test again, this time returning a trace log:

Code: Select all

loader -w flashtest.bin:0 -x 2 -t trace.log:512

You can then grep the resulting trace log to see what values are actually written to the 0x400000-0x47FFFF range:

Code: Select all

logread trace.log | grep " WB 4" | less

Did you try that? Any insights?

[Grind]

If the cmp command returns an error like "readback.bin random.bin differ: byte 1234, line 123", then the test has failed. Try running the test again, this time returning a trace log:

Code: Select all

loader -w flashtest.bin:0 -x 2 -t trace.log:512

You can then grep the resulting trace log to see what values are actually written to the 0x400000-0x47FFFF range:

Code: Select all

logread trace.log | grep " WB 4" | less

Did you try that? Any insights?

The byte that failed is 77590, which in hex is 12F16 and half that 978B so I checked here

Code: Select all

            15027612 C WB 409788 ABF0
            15027750 C WB 40978A EE56
            15027900 C WB 40978C EEC9
            15028038 C WB 40978E 5B84

I ran the test a third and fourth time and the files were identical. Not sure what changed.

[prophet36]

The byte that failed is 77590, which in hex is 12F16 and half that 978B so I checked here

Code: Select all

            15027612 C WB 409788 ABF0
            15027750 C WB 40978A EE56
            15027900 C WB 40978C EEC9
            15028038 C WB 40978E 5B84

Fair enough, but what does random.bin look like near there? Try "od -tx1 -Ax -v random.bin". The leftmost column is the hex offset.

Silly question, but did you remember to wait a few seconds for the MegaDrive to actually run the test? It can read flash at ~3MiB/s and it's only reading 512KiB of data, so it's probably not the problem, but in theory if you read the data back from SDRAM too early you'll get a mismatch.

OTOH it could easily be an intermittent timing problem with NTSC machines like yours, which I'd obviously like to get fixed.

[prophet36]

The byte that failed is 77590, which in hex is 12F16 and half that 978B so I checked here

Oh, wait. Why halve it? If the byte that fails is 77590, you need to look at the write to 0x412F16 (0x400000 + 77590) in the trace.

[Grind]

Oh, wait. Why halve it? If the byte that fails is 77590, you need to look at the write to 0x412F16 (0x400000 + 77590) in the trace.

Whoops. I'll try a few more times, don't have the old trace/bin files.

[prophet36]

OK Montserrat, can you try this on your PAL-I and PAL-G machines? I need two logic analyzer traces, one from a crash (address error, illegal instruction or line 1111 emulator, etc) during the "Sega!" sample on the PAL-G machine, and another from a blank screen startup-fail on the PAL-I machine (change the location of sonic1.bin as needed):

Code: Select all

$ cd ${HOME}
$ wget -q https://dl.dropboxusercontent.com/u/80983693/umdkv2/test-20160103.tar.gz
$ tar zxf test-20160103.tar.gz
$ cd test-20160103
$ flcli -v 1d50:602b -p J:A7A0A3A1:fpga.xsvf
Attempting to open connection to FPGALink device 1d50:602b...
Connected to FPGALink device 1d50:602b (firmwareID: 0xFFFF, firmwareVersion: 0x20140311)
Programming device...
$
$ ./loader -w ~/sonic1.bin:0 -x 2 -t trace.log:4096
UMDKv2 Loader Copyright (C) 2014 Chris McClelland

Putting MD in reset...
Writing SDRAM...
Releasing MD from reset...
Dumping logic analyzer trace to trace.log:4096
.........................................
Finished!
$ bzip2 trace.log
$

[Montserrat]

OK Montserrat, can you try this on your PAL-I and PAL-G machines? I need two logic analyzer traces, one from a crash (address error, illegal instruction or line 1111 emulator, etc) during the "Sega!" sample on the PAL-G machine, and another from a blank screen startup-fail on the PAL-I machine.

Sure, here they are:

https://mega.nz/#F!KZUGxSxS!ehFy--vq1d6IJQppFfKiMQ

[prophet36]

Sure, here they are:

Great, thanks. Here's the problem with the PAL-G trace. As predicted, a spurious premature assert of /OE:



I'll need to add some protection logic in the FPGA to prevent this being interpreted as the start of a read operation that should not actually start until several cycles later, when the address is stable.

I'll look at the PAL-I trace tomorrow.