UMDK manufacturing, part 2: Software

[Burbruee]

Ok, I have some progress to report..



The way I got here is.. quite interesting. I was trying to write sonic2.bin to :0 and trace but was unsuccessful (blank screen) and I had read on the pier solar website that MD1 might need to push reset for their game to work. (though, that for Md1 without the TMSS..) Tried that, didn't help.

So here's what I did. I executed the loader command on my laptop RIGHT AS I TURN ON the MD1. (before the screen flashes for a split second) It then loaded up the menu program. NOT the sonic game I tried to send it. Also the TMSS text didn't show.

I played around just trying to put the MD1 into reset and releasing with the same method. (so just loader -x 1) and it didn't get to the menu. I need to supply a file to write into SRAM. (loader -w file.bin:0 -x 2) and do this right when I power it on. Then I see the menu.

I made a tracelog for this, have a look: http://dump.ettfyratre.se/umdk/sonic2trace.log

I'd try with a sd-card to see if I could boot a game but unfortunately the only sd-cards I found here that were 2 GB or less are both old and dead.

[Burbruee]

Ok, I did the method described above to get to the menu. From there i run loader normally and try to run sonic.

First up, sonic1.bin



I had this error pop up and freeze the md.

Sonic2.bin:



It worked fine loaded over usb to the umdk!

EDIT: rerunning sonic1,bin ot worked fine without errors, played until marble zone act 3 without issues.. but there seems to be some stability issues loading (some) games into SRAM. Tried Mega Turrican and it kept freezing or glitching out at different spots very early on. Sometimes after half the first stage, sometimes during the intro/titlescreen. It would freeze up at some point every time I loaded it.

[MintyTheCat]

Excellent, Burbruee.

May your UMDK experience take off from here on out.

[Burbruee]

gdb-bridge also confirmed working perfectly. Just tried out all the stuff from the videos Chris posted with ddd and it's working perfectly..

Now I have all the tools to make, test and debug games I write for MD!

This is still a workaround though. The umdk doesn't get to the menu (or allow you to boot a game with the loader) without using the loader program right as you power on the console Hopefully we'll be able to boot directly soon.

[Montserrat]

The fact that i can only do tracing in the pal-1 asian moded in JAP region, its getting me nervous. Seems all can do the test in his pal eu versions, it does not even work in the pal-i eu moded JAP region version, only in the asian one, is there any relation to this?

Cleaned the cart-slot and the UMDK, and did the insn-trace test, bu still having the DF003E issue.

About the A22 pin, wheres that pin? you mean the cart pins? i have some conductive glue may be usesful, once aplied it to a damaged cart and it worked.

Also the burbruee workarroud doesnt do for me.

[prophet36]

The problem is likely to be on the A21 line, not A22 (for the signals A[23:20], we're getting 1101 when we expect 1111, therefore A21 is stuck at zero). It comes from the cart slot on the bridge-board, into the buffer U1. The signal name is mdAddr21, highlighted in bright red here. It then continues in the 3.3V domain, from the corresponding pin on the other side of the buffer U1 to the LX9 edge-connector. The signal name is bufAddr21, highlighted in bright red here. It then continues onto the LX9 board, where I suspect the problem will be a solder-bridge to the adjacent signal A14. Check it with a magnifying glass.

I had a couple of ideas to make testing easier, which I'll try to implement in the next week or so (but if anyone else wants to have a go, please do!):

• Alter the trace logic to include a periodic heartbeat message, perhaps after 512 or 1024 cycles with no bus activity. This will mean we can reduce the timestamp counter from 30 bits down to 14 bits (thus reducing the sample record size from 9 bytes down to 7 bytes), and it will eliminate this annoying problem where if the CPU stalls, no trace data is returned. This will be great, because the information just prior to the stall is likely to be very useful for debugging why the stall happened.
• Provide an alternative "test-mode" boot ROM which forces the CPU to do the test Minty suggested: do alternate reads of 0x5555 stored at address 0x000000 and 0xAAAA stored at address 0x000002, as a continuous sequence of move.w 0(a0), d0; move.w 2(a0), d0 instructions, spanning all the cart address-space up to just below 0x800000, then do a few writes and reads from 0xFF0000. We should be able to trace that ROM executing, and verify every bus cycle against a "known-good" trace (ignoring timestamps, obviously) and thus test the integrity of every MD<->FPGA signal in the process.

[Grind]

Using Ubuntu 14.04.3 I was able to get to the same point as Burbruee. This is on an NTSC model 1 that has the copyright screen (I was told some model 1s don't).

Two small things I had to change in x64.txt: In the apt-get lines, remove "libtool-bin". That package doesn't exist in 14.04. Also add "p7zip-full" which contains 7za used to extract sgdk095.7z.

The problem on Parabola/Arch is that GCC is too new, building 4.3.4 with 5.2.0 isn't going to happen. Might try playing with a new version of crosstool-ng later, or just copy the already built 4.3.4 from Ubuntu. For now here is a line to automate installing the dependencies:

Code: Select all

sudo pacman -Sy --needed --noconfirm base-devel cvs python2-yaml python-yaml libusb p7zip xz readline zlib gperf openmotif ncurses libx11 libxext libxp libxmu

Don't know if a specific python version is needed.

[Montserrat]

Found it just where you said...



Before getting into fixing that, i've never did that into a so tiny scale, do you have some advice to give me?

i have a 30w electronics solder, 2,5mm desoldering braid and some flux.

[prophet36]

Found it just where you said...

Aha! Nice.

This is on the bridge-board, which is only two layers, so unless you have a burning desire to play with your soldering-iron, I recommend getting a razor-blade and using it to carefully cut the solder-bridge. Once you're done, use your multimeter to check that there is no short between those two pins.

In other news, I discovered that using "loader" to load a ROM over USB doesn't work very well if the flash-boot process doesn't work. It used to work completely independently of the boot process, but I remember now that I changed it in the last few weeks of development back in 2014, to be integrated with the boot process (and therefore rely on it completing successfully). Apologies for that - my only excuse is that it has been a long time since I looked at this code. So anyway, that explains some of the behaviour you're all seeing. I'll try to get to the point where the 0xAAAA/0x5555 test I mentioned before works on my console, with a wiped-clean flash. This can then be added as a verification step before writing fpga.bin and firmware.bin to the flash (i.e step 5 in the original instructions).

[prophet36]

OK, everyone should try this test. It will load a special FPGA design with the bootloader disabled and a couple of other changes, then it'll load entire lower 8MiB of the MegaDrive address space with a specific pattern of instructions. It then traces the execution of those instructions, and gets an MD5 hash of the results. This allows you to check whether your cart has any manufacturing faults.

Code: Select all

wget -q www.swaton.ukfsn.org/umdkv2/sigtest.xsvf
wget -q www.swaton.ukfsn.org/umdkv2/sigtest.bin.bz2
bunzip2 sigtest.bin.bz2 
flcli -v 1d50:602b -p J:A7A0A3A1:sigtest.xsvf
loader -w sigtest.bin:0 -x 2 -t trace.bin
logread sigtest.bin trace.bin | head -8388250 | awk '{print $2$3$4$5}' | md5sum

You should let the trace run for about ten seconds before hitting ctrl-C. By all means let it run longer, but don't stop it prematurely.

• If the last command responds with an MD5 of d5a670db486de8597e214c6849fdfacb, congratulations, your hardware is functioning correctly. You should try loading a few different game ROMs, e.g "loader -w sonic1.bin:0 -x 2". Don't be surprised if the gdb-bridge doesn't work in this mode though.
• If your "loader" command hangs and you get no dots, that means your test has failed and you most likely have a hardware problem like Montserrat's solder bridge between A21 and A14. You could get a magnifying glass and see if you can spot the problem, or you could just wait for me to implement the change to the trace logic that I mentioned yesterday, whereupon we'll be able to locate the hardware problem. Running a cart that has such a hardware problem may put extra stress on your MegaDrive, and could damage it. So if you're in this state, don't mess with it too much, just be patient, and we'll find out what's wrong.
• If the trace works, but the last command responds with an MD5 value other than the one given above, it may indicate you have a hardware problem, or it may simply mean your MegaDrive is a different model from mine, and exhibits a different sequence of bus cycles during the test. In this case, you'll need to upload the test results so I can look at them:
  

  Code: Select all

  logread sigtest.bin trace.bin | head -8388250 | awk '{print $2$3$4$5}' | bzip2 -c > result.txt.bz2

  You'll need to upload the result.txt.bz2 file. I expect it to be about 10MB in size.

[Burbruee]

Well. I'm getting a different md5 sum than yours, and I did the test a few times (5 so far) and was having a different md5 each time. I made sure to keep tracing for 20-30 seconds.

Using the loader to run a game after, works. But with inconsistent results. Like the image I posted on the last page running sonic1 I get an error message on the sega screen. But it's not always the same error. Another time it would just freeze there, and another it posted a message about illegal instruction. And then a 4th time it worked just fine. sonic2 however has worked every time so far. So it seems some games are having more issues. Like I posted the other night, Mega Turrican also freezes frequently, usually on the title screen. But I've tried maybe 5-6 games other than those and sonic1 and mega turrican are the ones that keep hanging. Other games work for 20 minutes without ever having issues.

Maybe a strange question, but about the flcli command and the xsvf file we program (sigtest) do these programs disappear after we turn off the console or are they supposed to stay? I'm not really understanding how this is written. I ask because if I turn off my console and try to run loader with sigtest.bin right away then the dots for the trace never appear. But if I program the xsvf before the loader command then the loader will work and keep working until the MD is turned off and on again.

Also I got my sdcard today (2 GB, FAT32) and tried to run the menu with the loader and some roms, but it would stay on loading files and nothing would appear. Not sure if there is a hardware problem or if it's related to software/bootloader stuff.


EDIT: Oh yeah, here are two result.txt files
http://dump.ettfyratre.se/umdk/result1.txt.bz2 [don't remember the md5 since I did many tests]
http://dump.ettfyratre.se/umdk/result2.txt.bz2 [1f8435a71d5ca4408269a9873caba72f]

[Montserrat]

Hi. i did cut the solder bridge, and now its working like burbruee one.

I can load games with the workarround, didnt played so much, i've tried streets of rage its working great even i can switch regions on the fly, i experienced a little artifact in the main tittle but i think is due to the "on the fly" region switching. Also tried sonic 1 & 2 all normal, its working even in the sega nomad.

About the test, same situation as burbruee, i've done several test and i get a diferent checksum every time, here is the file:

https://mega.nz/#!rN9HRYxY

Im gonna do some more extensive test on games to check if im getting any freeze or artifact.

EDIT: little update, i've tried several games with no problems at all, but noticed that at first i cant load the game rom menu in my asian moded pal-1.

Then loaded a euro drabon ball game via terminal, and then i suddenly can use the Chris's rom loader from sd-card.

I cant do that with the sega nomad, it stays at the reading sd-card... sing. Nomad is a genesis 2 miniaturized.


EDIT 2: DDD does not work, it resets the console and its unable to load any rom, also crashes.

[prophet36]

Burbruee:
Your result files show evidence that your PC is unable to keep up with the rate of trace data production. This is surprising because it only creates about 10MB/s, whilst FPGALink will easily sustain 40MB/s even on my crappy 10-year-old PC. Did you have anything else running at the time? What other USB peripherals do you have connected?

This bandwidth issue will only affect execution tracing, it should not affect normal debugging & data upload/download. Apart from the block of dropped frames, your test results look perfectly OK: there's no evidence of any shorts, dry joints or bad connections.

Try getting a trace of Sonic crashing, and see if you can find out why. Start by searching for "*" in the output of logread - that tells you the MD read a value from ROM that differs from the value actually at that offset in the ROM image. Also, Sonic is helpful because it tells you which exception occurred (Address Error, Line F Emulator, etc). Lookup the exception vector address in your 68000 manual, and search the trace for a read of that address, then follow the trace backwards from there to discover the cause. The "dis68" utility is helpful for disassembling small sections of ROM.

Montserrat:
Your link just pops up with "Enter decryption key", so I can't look at your test results. Also, apologies, I'm finding it very difficult to follow your behavioural descriptions. Please be explicit, tell me exactly what you did, what you expected to see, what you actually saw, and what you've already done to try to debug it.

[Montserrat]

Your link just pops up with "Enter decryption key", so I can't look at your test results. Also, apologies, I'm finding it very difficult to follow your behavioural descriptions. Please be explicit, tell me exactly what you did, what you expected to see, what you actually saw, and what you've already done to try to debug it.

Sorry i know my english is so weird...ill try to be more specific.

Link to test:

https://mega.nz/#!rN9HRYxY!VMb7Tc_u1xt4 ... zKn0-ODBig

Im in the same point as burbruee. but i did not experienced any errors or crashes loading games from terminal.

[prophet36]

Sorry i know my english is so weird...ill try to be more specific.

I don't particularly care what language you use, as long as you don't mind me replying in English. Besides, your English is fine; it's just that you can be a little bit vague sometimes. That's OK too, but if I only have a vague understanding of what's going on with your UMDK, I will only be able to offer you vague help.

Link to test:

Ah, that's better. Yes, you have the same bandwidth problems as Burbruee:

Code: Select all

$ diff ../sigtest/chris-result.txt montserrat-result.txt | grep -v \< | grep -v \>
1391049,1394219d1391048
1406735,1408823d1403563
1443868,1445515d1438607
2596947,2603922d2590038
3069502,3070374d3055617
5167982,5172203d5153224
5174934,5175751d5155954
5203059,5203444d5183261
6379907,6380392d6359723
7484265,7484269d7463595
7737085,7739543d7716410
7764575,7764973d7741441
8388213a8364682,8388213
$

All those "d" diffs represent sequences of bus cycles which were in my trace but not in yours, meaning your PC couldn't keep up. Otherwise, your test looks OK - I don't think you have any remaining hardware problems (shorts, dry joints, bad connections, etc).

Im in the same point as burbruee. but i did not experienced any errors or crashes loading games from terminal.

Great! Well, let me know if you need any more help.