UMDK manufacturing, part 2: Software

[prophet36]

I am referring to binaries of the firmware that will go on the UMDK.

Good idea. Yes, we can certainly do that.

I am having trouble building the software on Debian Stretch x86_64

I think the right thing to do is to update the cross-compiler to a newer version, because 4.3.4 is a bit old now, and the probability of build problems increases as the version number of the native toolchain diverges from that of the desired cross-compiler. Your existing gcc-68k toolchain, what version is it? How did you build that?

[Burbruee]

Code: Select all

loader -t boot-trace.log

I tried it, but sadly I'm unable to trace anything this way. No dots are appearing in the terminal if I use loader like that, or adding the -x 2 flag. I only get the dots to appear if I load up a rom file as well. (which gives me the makestuff splashscreen)

Tried many times, and I can't think it's a connectivity problem because every time I give the loader -w rom.bin:0 the trace works fine and fills up with dots, and every time I don't give it a rom file then he won't give me any dots. Just stops at "Dumping execution trace to boot-trace.log" and I have to press CTRL+Z instead of CTRL+C. Every time the trace ends up at 572 kB no matter how long I wait for the CTRL+Z but yes it's not complete since no dots start to appear without adding the rom.

[Montserrat]

So, please do this. Take your SD card out of your UMDK, and then plug your UMDK into your MD1. Set the region-switch to EU. Power the MD on, and very quickly afterwards (as if you were doing the Burbruee workaround), do this:

I'm sorry it didnt worked. Extracted the SD-CARD ,Switched to EU, shut off. Power ON, started the tracing. No "dots" recieved, its not tracing, i got a 585 kb file.

Fail-trace log download

What i did next is to make the workarround trace. Loaded a rom and traced it, worked. It showed me the "makestuff USB...reading SD-card", since there no SD-card in it got stuck in there.

Code: Select all

loader -w sor.bin:0 -x 1 -t boot-2-trace.log

NO SD-card + rom TRACE

Also did a trace with SD-card inserted, may be its usesful.

SD-card + rom TRACE

[prophet36]

I tried it, but sadly I'm unable to trace anything this way. No dots are appearing in the terminal

Thanks for trying. Don't worry. See below.

I'm sorry it didnt worked. Extracted the SD-CARD ,Switched to EU, shut off. Power ON, started the tracing. No "dots" recieved, its not tracing, i got a 585 kb file.

Actually, that small file does contain useful trace-data. It tells me that the boot process works well right up to the point where the menu program itself starts running. There's just one thing I need to confirm, for which I need a copy of your firmware.bin. Can you upload it for me please?

To find out why you get the blank-screen on boot, I will need to add the "heartbeat" logic I mentioned in a previous post. Unfortunately I won't have time to do that until the weekend, but I will definitely do it.

Edit: BTW, one more thing that would be useful is a trace from your Nomad failing to read the SD-card. So SD-card installed, UMDK in the Nomad, power on and "loader -w sor.bin:0 -x 1 -t boot-2-trace.log". Five or six seconds of tracing while the Nomad shows the MakeStuff splash screen should be OK.

[Burbruee]

Since I have the same problem with not reading from SD-card I uploaded a trace reaching the menu (running in PAL mode)

http://dump.ettfyratre.se/umdk/boot-trace.log.bz2 (39 MB)

And also, here is my firmware.bin:
http://dump.ettfyratre.se/umdk/firmware.bin.bz2
-----------
EDIT Unrelated, but I also uploaded two different traces for when Sonic 1 crashes over USB.
The first one, comes up with a message on SEGA screen saying "Line 1111 Emulator $00071FCA"
http://dump.ettfyratre.se/umdk/sonic-tr ... CA.log.bz2 (33 MB)

And here the second one, it shows "Address Error $00071FC6$010041D5" on the same SEGA screen.
http://dump.ettfyratre.se/umdk/sonic-tr ... D5.log.bz2 (33 MB)

At this point, I figured I'd try to read the rom back from memory using loader -r sonic-error.bin:0:0x80000 and load it up in an emulator - and it worked fine. Next thing, I did "cmp sonic1.bin sonic-error.bin" and it showed nothing.. so there was no error when transferring it, yet it showed an error and froze on the actual hardware.

EDIT: Well, I guess Sonic doesn't freeze, I just assumed so since it stays on the SEGA screen. If I press start after the exception the game runs normally. This is at least true for the address error, haven't had the emulator one happen again yet. Still though, it shouldn't give that message and maybe it's related to other games freezing..

Well it doesn't happen every time, the first time I ran it while tracing I got the emulator error, then reloaded it maybe 10 times where it ran fine before I got the address error. But some other games like Alien Soldier or Mega Turrican freeze completely every time I try them after anything from half a minute to a few minute of gameplay.

[Montserrat]

There's just one thing I need to confirm, for which I need a copy of your firmware.bin. Can you upload it for me please?

Edit: BTW, one more thing that would be useful is a trace from your Nomad failing to read the SD-card.

Here are the files, also got lucky again and managed to trace the nomad reaching the loader menu once, so extra bits of info.

Firmware.bin file

NOMAD unable to read the SD

and

NOMAD able to read the SD, and to reach the menu

[Montserrat]

Unrelated, but I also uploaded two different traces for when Sonic 1 crashes over USB.
The first one, comes up with a message on SEGA screen saying "Line 1111 Emulator $00071FCA"

And here the second one, it shows "Address Error $00071FC6$010041D5" on the same SEGA screen.

Sounds like a dirty cart slot and/or lack of tension on the cart slot pins. Do you have another megadrive to test on? if not, theres some cleaning procedures you can try, they're on google.

[Burbruee]

Unrelated, but I also uploaded two different traces for when Sonic 1 crashes over USB.
The first one, comes up with a message on SEGA screen saying "Line 1111 Emulator $00071FCA"

And here the second one, it shows "Address Error $00071FC6$010041D5" on the same SEGA screen.

Sounds like a dirty cart slot and/or lack of tension on the cart slot pins. Do you have another megadrive to test on? if not, theres some cleaning procedures you can try, they're on google.

It might be. But if anything I think it's the contacts on the bridge board. It happens on both megadrives and I've never had an issue with a retail cart ever. Also it really likes to freeze on Turrican. Tried maybe 20 times in a row and froze every time, then, without restarting the console I loaded up Mickey Mouse Great Circus and played through the entire game and left it in attract mode over night and was still running when I woke up and probably when I come home tonight as well..

[Montserrat]

mmm then seems its nothing related to the cart slot... why you dont shoot a some very high resolution pictures to all parts of both boards?, may be i can help you searching for hardware faults comparing with mine.

i Suggest you using a good camera and ilumination also some magnifier for the 0,5mm pins.

[prophet36]

OK Montserrat, I added the heartbeat which should allow us to get useful trace data even if the MegaDrive crashes. I made some changes to several other things too, so I'm going to try giving you the binaries I built on my computer. Distributing Linux binaries is often problematic, so don't be too surprised if it doesn't work. Here goes:

Code: Select all

cd ${HOME}
mv umdkv2-bin umdkv2-old  # save your files
wget -qO- https://dl.dropboxusercontent.com/u/80983693/umdkv2/umdkv2-bin.tar.gz | tar zxf -
cd umdkv2-bin
flcli -v 1d50:602b -p J:A7A0A3A1:spi-talk.xsvf
gordon -v 1d50:602b -t indirect:1 -w fpga.bin:0
gordon -v 1d50:602b -t indirect:1 -w firmware.bin:0x60000

Then turn your MD off then on again, and quickly (as if you were doing the Burbruee workaround) do this:

Code: Select all

loader -t trace.log

If the MD crashes, the dots will come at a much slower rate than if it's running normally, because a crashed MD will produce only heartbeat messages, so the trace log will grow at a slower rate. Let it run for a while, then hit ctrl-c. Compress the trace.log as before, and upload it for me to look at.

[prophet36]

BTW, hopefully I have also fixed the problem reading the SD-card on the Nomad (actually any NTSC machine). This problem was originally discovered (and fixed) by fixel (one of the first people to build a UMDK cart apart from me) but he/she disappeared from SpritesMind during the subsequent discussion.

From studying the trace from Montserrat's Nomad, it looks like the problem is in the SD-card initialization, which is done with the SPI clock at 400kHz. That's pretty slow, so I have a delay counter in the code, to work out when it's safe to send the next initialization byte to the SD-card. That counter was being initialized to 7, resulting in a delay of ~19,500ns between bytes on NTSC machines. Unfortunately, at 400kHz, each byte is 20,000ns (i.e 20μs) long. So the MegaDrive was writing to the SPI hardware before it had finished clocking out the current byte.

The fix was simple: increase the delay counter to 8.

[prophet36]

Sadly, in the process of adding heartbeating, I've somehow broken the flag that allows DMA vs CPU reads to be distinguished in the trace log. Here's the equivalent sequence from Sonic's sampled-sound playback that I described here:

Code: Select all

56488582 C RD FFFB70 0000
56488596 C RD FFFB72 0000
56488611 C RD FFFB74 0000
56488625 C RD FFFB76 0000
56488639 C RD FFFB78 0000
56488654 C RD FFFB7A 0000
56488668 C RD FFFB7C 0000
56488683 C RD FFFB7E 0000
56488706 C RD 0010B0 4BF9
56488744 C RD 0010D4 4BF9
56488769 C RD 0010D6 00C0
56488795 C RD 0010D8 0004
56488820 C RD 0010DA 2ABC
56488845 C RD 0010DC 9401
56488870 C RD 0010DE 9340
56488896 C RD 0010E0 2ABC
56488929 C WB C00004 9401
56488954 C WB C00006 9340
56488971 C RD 0010E2 96FC
56488997 C RD 0010E4 9500
56489022 C RD 0010E6 3ABC
56489056 C WB C00004 96FC
56489081 C WB C00006 9500
56489098 C RD 0010E8 977F
56489123 C RD 0010EA 3ABC
56489157 C WB C00004 977F
56489173 C RD 0010EC 7800
56489199 C RD 0010EE 31FC
56489232 C WB C00004 7800
56489249 C RD 0010F0 0083
56489275 C RD 0010F2 F640
56489300 C RD 0010F4 3AB8
56489333 C WB FFF640 0083
56489350 C RD 0010F6 F640
56489376 C RD 0010F8 4BF9
56489434 C WB C00004 0083
56489510 C RD FFF800 0000
56489528 C RD FFF802 0000
56489546 C RD FFF804 0000
56489562 C RD FFF806 0000
56489580 C RD FFF808 0000
56489617 C RD FFF80A 0000
56489646 C RD FFF80C 0000
56489675 C RD FFF80E 0000
56489690 C RD FFF80E FFFF
56489704 C RD FFF80E 0000

Notice that the reads and writes are the same, but column 2 shows everything as CPU reads, when actually many of them should be shown as DMA reads. It would be helpful if someone else could get a trace of Sonic 1, up to the point where the "SEGA" sampled sound finishes.

[prophet36]

OK, fixed the DMA/CPU thing, and uploaded a replacement tarball. It was a stupid bug in logread.

[prophet36]

OK Burbruee, I looked at your Sonic traces, and the only thing I can think of that might cause this behaviour is a bad connection on the /OE signal somewhere. Get a magnifying glass (or if you have one of those USB microscopes, use that) and a needle. Then, using the needle, very carefully see if you can move any of the pins on the /OE signal: this goes from about half-way along the MegaDrive cart connector, into the middle buffer chip, then out the other side, across the 80W connector to the LX9 board and into the FPGA. This will not be as easy to spot as Montserrat's solder-bridge, because in this case, the pin is not soldered down properly, and is only touching the PCB. Be very careful because these SMD pins bend very easily, and if you snap one off, it's unlikely you'll be able to repair it (unless you're much better at such things than I am).

[Montserrat]

Hi! Here's the heartbeat trace file, it traced slowly as you said.

Heartbeat Trace

On the other side the nomad fix worked flawlesly, good job! now the nomad behaviour is like any other megadrive (workarround needed) ...my work nightwatch gonna turn so interesting now lol.