Page 2 of 17
Re: UMDK manufacturing, part 2: Software
Posted: Mon Nov 23, 2015 7:50 pm
by Montserrat
edited:continue reading
Re: UMDK manufacturing, part 2: Software
Posted: Mon Nov 23, 2015 8:09 pm
by prophet36
OK, here are a couple of things to try.
Firstly, let's see how the
gdb-bridge integration tests fare. Connect a USB cable between your PC & UMDK, plug it into your MegaDrive, turn it on, then:
Code: Select all
$ cd ${HOME}/20150315/makestuff/hdlmake/apps/makestuff/umdkv2/gdb-bridge
$ (make deps 2>&1) > build.log
Now upload
build.log somewhere (e.g dropbox, gdrive etc) and post a link here.
Secondly, let's try resetting the CPU with tracing enabled. Turn your MegaDrive off for a few seconds, then on again, then do this (note: hit ctrl-c after about 20s, by which time you should have received many "."s):
Code: Select all
$ cd ${HOME}
$ loader -t trace.bin -x 2
UMDKv2 Loader Copyright (C) 2014 Chris McClelland
Putting MD in reset...
Releasing MD from reset...
Dumping execution trace to trace.bin
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C..............................................................................................................................................................................................................................................................................................................
Caught SIGINT, quitting...
$ dd if=/dev/zero of=fubar.bin bs=1024 count=64
64+0 records in
64+0 records out
65536 bytes (66 kB) copied, 0.000408051 s, 161 MB/s
$ logread fubar.bin trace.bin | head -10000 > trace.log
Now upload
trace.log somewhere (e.g dropbox, gdrive, etc) and post a link here.
Re: UMDK manufacturing, part 2: Software
Posted: Mon Nov 23, 2015 8:20 pm
by prophet36
Montserrat wrote:um....was looking to TMSS license code...may be its something related to this.
Possibly. I'm no expert with this kind of thing. What I will say is that Minty has successfully tested his UMDK cart on a European MD1, and I've tested my carts with a European MD2. You could try commenting out the "move.l #0x53454741, 0xA14000" line and re-running the build steps to generate
firmware.bin, and then use
spi-talk.xsvf to write the updated firmware to the flash.
Re: UMDK manufacturing, part 2: Software
Posted: Tue Nov 24, 2015 12:14 am
by Burbruee
Here's my trace: (dns updating atm, should work in 1 hour or so from when I make this post..)
http://dump.ettfyrtatre.se/trace_bin.zip
Re: UMDK manufacturing, part 2: Software
Posted: Tue Nov 24, 2015 7:16 am
by prophet36
No, please upload build.log and trace.log, not trace.bin.
Re: UMDK manufacturing, part 2: Software
Posted: Tue Nov 24, 2015 8:12 am
by Burbruee
prophet36 wrote:
No, please upload build.log and trace.log, not trace.bin.
It's actually trace.log, I just named it wrong.
Re: UMDK manufacturing, part 2: Software
Posted: Tue Nov 24, 2015 5:00 pm
by Montserrat
Sorry i cant upload the logs at this moment, got a problem with lubuntu, im in a login loop, im trying to figure how to fix that...
Re: UMDK manufacturing, part 2: Software
Posted: Tue Nov 24, 2015 6:35 pm
by prophet36
Edit: Never mind. You had a typo in your link. It should have been
http://dump.ettfyratre.se/trace_bin.zip. It is the trace.bin though, not the trace.log.
Burbruee wrote:It's actually trace.log, I just named it wrong.
Fair enough. Next problem is:
Code: Select all
$ ping dump.ettfyrtatre.se
ping: unknown host dump.ettfyrtatre.se
Just use pastebin or similar, and don't zip the file. That way people can view it easily on tablets and smartphones, etc.
Re: UMDK manufacturing, part 2: Software
Posted: Tue Nov 24, 2015 7:43 pm
by prophet36
Burbruee wrote:Here's my trace
OK, here's a comparison between your (dysfunctional) trace and my (functional) trace:
Code: Select all
Prophet36: | Burbruee:
---------------------|---------------------
0 C RD 000000 00FF | 0 C RD 000000 0000
38 C RD 000002 FE00 | 38 C RD 000002 FE00
64 C RD 000004 0042 | 63 C RD 000004 0042
89 C RD 000006 0200 | 88 C RD 000006 0200
114 C RD 420200 46FC | 113 C RD 420200 0200
152 C RD 420202 2700 | 151 C RD 420202 2700
177 C RD 420204 4AB9 | 176 C RD 420204 4AB9
228 C RD 420204 4AB9 | 202 C RD 420206 00A1
253 C RD 420206 00A1 | 227 C RD 420208 00A1
278 C RD 420208 0008 | 252 C RD 42020A 6606
304 C RD 42020A 6606 | 361 C WB 00FDFE 020A
342 C RD A10008 0000 | 387 C WB 00FDFA 2714
367 C RD A1000A 0000 | 412 C WB 00FDFC 0042
379 C RD 42020C 4A79 | 437 C WB 00FDF8 4AB9
430 C RD 42020E 00A1 | 462 C WB 00FDF6 00A1
455 C RD 420210 000C | 488 C WB 00FDF2 4AB5
Notice that the timestamps are similar; your clock speed seems to be slightly faster than mine (remember that these timestamps are taken from the UMDK's 48MHz clock, meaning the time between the first and second reads is 38*1000/48 = 792ns), so I'm guessing you have an NTSC machine. Since the UMDK SDRAM controller is designed to work with the MD's fast DMA cycles, and since you ran through the SDRAM test successfully (you did,
right?), it's
highly unlikely that this is due to the SDRAM controller not keeping up. So my guess would be the 2nd-stage bootloader is not being read from flash correctly. I'll have a think about how to fix that.
In the meantime, please try the following. Connect the USB cable and power the MegaDrive off then on again. Now:
Code: Select all
cd ${HOME}
wget -q http://www.swaton.ukfsn.org/old-umdkv2/sonic2.bin
loader -x 0
loader -w sonic2.bin:0 -x 1 -t trace.bin
logread sonic2.bin trace.bin | head -10000 > trace.log
Again, hit ctrl-c after a few seconds when tracing. Upload
trace.log somewhere, post link here.
Did the game run correctly?
Re: UMDK manufacturing, part 2: Software
Posted: Tue Nov 24, 2015 9:04 pm
by mikejmoffitt
I can pull my Sega Genesis out of storage and give it a try. It can run in NTSC or PAL mode, so we can see if any issues lie there.
Re: UMDK manufacturing, part 2: Software
Posted: Wed Nov 25, 2015 1:14 am
by Burbruee
prophet36 wrote:Notice that the timestamps are similar; your clock speed seems to be slightly faster than mine (remember that these timestamps are taken from the UMDK's 48MHz clock, meaning the time between the first and second reads is 38*1000/48 = 792ns), so I'm guessing you have an NTSC machine. Since the UMDK SDRAM controller is designed to work with the MD's fast DMA cycles, and since you ran through the SDRAM test successfully (you did, right?), it's highly unlikely that this is due to the SDRAM controller not keeping up. So my guess would be the 2nd-stage bootloader is not being read from flash correctly. I'll have a think about how to fix that.
Oh, this is very strange that the clock speed would be different! It's not an NTSC-machine at all, it's a stock PAL MD1. And yes I did the SDRAM test and there was no difference when comparing the two files, I just re-ran all tests and it reads back fine.
The game did not run with loader. Here's the log.
http://pastebin.com/7LSVRcPX
Re: UMDK manufacturing, part 2: Software
Posted: Wed Nov 25, 2015 3:39 am
by Grind
Finally getting a chance to do this. Noticing a bit of a discrepancy in the last step: my firmware.bin is only 1280 bytes.
Code: Select all
$ gordon -v 1d50:602b -t indirect:1 -w firmware.bin:0x60000
Device: Micron/Numonyx/ST M25P40
Writing 0x00000500 bytes to address 0x00060000...
.....
$
Nothing mentioning the file in the install log either.
Code: Select all
$ grep firmware.bin ${HOME}/x64.log
$
I'll retry step 1 on Ubuntu and see if it is different.
Re: UMDK manufacturing, part 2: Software
Posted: Wed Nov 25, 2015 5:13 am
by Burbruee
Grind wrote:Finally getting a chance to do this. Noticing a bit of a discrepancy in the last step: my firmware.bin is only 1280 bytes.
Code: Select all
$ gordon -v 1d50:602b -t indirect:1 -w firmware.bin:0x60000
Device: Micron/Numonyx/ST M25P40
Writing 0x00000500 bytes to address 0x00060000...
.....
$
Nothing mentioning the file in the install log either.
Code: Select all
$ grep firmware.bin ${HOME}/x64.log
$
I'll retry step 1 on Ubuntu and see if it is different.
Yes, if I remember correctly you were also running Arch on your machine? I had the same problem also using arch, then I opened up the x64.txt file and found this line:
Code: Select all
cd ../../gdb-bridge/monitor/
make
cat monitor.bin ../../m68k/menu/menu.bin > $HOME/umdkv2-bin/firmware.bin
I had a look inside the menu/ folder and found that the menu.bin was nowhere to be found because it had failed to build, seems some of the cross-compiling tools were missing. Explaining the tiny size of firmware.bin
I already had a working toolchain installed in /opt/toolchains/sega/ and tried to build the menu program with that instead (using current sgdk version) and got it to build, re-ran the command to generate the firmware.bin. However this time it was way larger in size, larger than what prophet posted.
----
On my desktop computer I have a debian jessie installation, so I decided to start all over and use debian instead for messing with installing the software (since this is the recommended setup to use..)
Using debian everything built successfully this time and the firmware.bin ended up being C454 bytes this time which is correct.
Re: UMDK manufacturing, part 2: Software
Posted: Wed Nov 25, 2015 5:13 pm
by Montserrat
mmmHere is my build.log....something has gone terribly wrong for me its full of errors, trace didnt even worked.
https://mega.nz/#!rF8GEZwJ!uV-i50KIAIJk ... 1Ns7DjR1xA
Just in case, to make the build.log jumper config has to be J4 in EXT and the rest populated, cart in megadrive and conected via usb to pc?
Also what is suposed to happen after you plug the console? i put it on, hit enter to start the log, it works but i have shut down the console or it will never ends...
also trace log does not give me any "dots" and is generating an empty file...
I thing someting crashed my user config including paths and messed up all,...so... it is safe to start all over, i mean re-flashing the kit?
Re: UMDK manufacturing, part 2: Software
Posted: Wed Nov 25, 2015 6:46 pm
by prophet36
Montserrat wrote:my build.log...its full of errors
Don't worry too much about that, I didn't really expect it to work. I'm just gathering information.
Montserrat wrote:trace log does not give me any "dots" and is generating an empty file
That probably means the CPU is ending up trying to read from a region without auto-DTACK, or it's getting a double bus error, or it's ending up in an infinite loop in a region that does not generate any trace information (e.g the onboard RAM).
Again, don't worry too much. I suspect all five carts have probably been built correctly, it's just a matter of tracking down the bad assumptions made by the software and VHDL. It's only to be expected that the bad assumptions will manifest themselves in different behaviour for different carts. I think we're making good progress towards tracking down the problem.
It may be worthwhile checking the file lengths - see comments above from people with failed firmware.bin builds. The firmware.bin file should be 50260 bytes long.
Can you try tracing the sonic2.bin also, please?