UMDK manufacturing, part 2: Software

Hosted forum for UMDK related questions

Moderators: BigEvilCorporation, prophet36

Montserrat
Very interested
Posts: 115
Joined: Fri Sep 18, 2015 2:56 pm

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Wed Dec 30, 2015 7:11 pm

prophet36 wrote:
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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Wed Dec 30, 2015 8:48 pm

Montserrat wrote: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
Interested
Posts: 15
Joined: Sun Dec 13, 2015 7:20 pm

Re: UMDK manufacturing, part 2: Software

Post by TestSubject06 » Wed Dec 30, 2015 9:04 pm

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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Thu Dec 31, 2015 2:25 pm

TestSubject06 wrote: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.
TestSubject06 wrote: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
Interested
Posts: 15
Joined: Sun Dec 13, 2015 7:20 pm

Re: UMDK manufacturing, part 2: Software

Post by TestSubject06 » Thu Dec 31, 2015 8:29 pm

prophet36 wrote: 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. :oops:

Montserrat
Very interested
Posts: 115
Joined: Fri Sep 18, 2015 2:56 pm

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Sat Jan 02, 2016 11:28 am

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
Very interested
Posts: 69
Joined: Fri Jun 13, 2014 1:26 pm
Location: US
Contact:

Re: UMDK manufacturing, part 2: Software

Post by Grind » Sat Jan 02, 2016 9:49 pm

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 :mrgreen:

ddd working too. I think I forgot to format the SD card though.
Screenshot from 2016-01-02 16-47-11.png
Screenshot from 2016-01-02 16-47-11.png (37.74 KiB) Viewed 30154 times

prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Sat Jan 02, 2016 10:32 pm

Grind wrote: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.
The Wiki wrote: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
Very interested
Posts: 69
Joined: Fri Jun 13, 2014 1:26 pm
Location: US
Contact:

Re: UMDK manufacturing, part 2: Software

Post by Grind » Sat Jan 02, 2016 11:17 pm

prophet36 wrote:
The Wiki wrote: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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Sat Jan 02, 2016 11:38 pm

Grind wrote: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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Sat Jan 02, 2016 11:43 pm

Grind wrote: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
Very interested
Posts: 69
Joined: Fri Jun 13, 2014 1:26 pm
Location: US
Contact:

Re: UMDK manufacturing, part 2: Software

Post by Grind » Sun Jan 03, 2016 2:05 am

prophet36 wrote: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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Sun Jan 03, 2016 6:21 pm

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
Very interested
Posts: 115
Joined: Fri Sep 18, 2015 2:56 pm

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Sun Jan 03, 2016 10:38 pm

prophet36 wrote: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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Mon Jan 04, 2016 12:21 am

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

Image

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.

Post Reply