UMDK manufacturing, part 2: Software

[prophet36]

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.

My mistake, I wasn't reading the timestamps properly - they actually correlate quite closely.

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.

Great, thanks for confirming.

Here's the log.

OK, here's the comparison, the same ROM running on my setup:

Code: Select all

Prophet36:           | Burbruee:
---------------------|---------------------
  0 C RD 000000 FFFF |   0 C RD 000000 0000
 38 C RD 000002 FE00 |  38 C RD 000002 FE00
 64 C RD 000004 0000 |  64 C RD 000004 0000
 89 C RD 000006 0206 |  89 C RD 000006 0206
114 C RD 000206 4AB9 | 114 C RD 000206 0206
152 C RD 000208 00A1 | 152 C RD 000208 4AB9
177 C RD 00020A 0008 | 177 C RD 00020A 0008
203 C RD 00020C 6606 | 202 C RD 00020C 6606
241 C RD A10008 0000 | 261 C WB 00FDFE 020A

Notice that the timestamps are identical for the first seven lines. Notice also that most of the discrepancies in the word being read from memory are cases where the word from bus cycle N-1 is being given in response to bus cycle N: so 0206 is supplied twice, 4AB9 is delayed by one bus-cycle, 00A1 is not supplied at all, and then things get back in sync with 0008 and 6606. The discrepancy in the last line is due to the fact that the CPU has been getting different instructions, so from that point things diverge. The discrepancy in the first line is harder to explain though.

Since this ROM was written over USB, we can eliminate the possibility that it's a flash problem. And I stand by my previous statement about it being unlikely the SDRAM isn't fast enough.

But the SDRAM controller is rather unlike the asynchronous ROMs found in MegaDrive cartridges. It needs to be triggered, on a single 48MHz cycle, with a command (read, write, refresh, etc) an address and (for writes) some data. It then goes away and does stuff for 12 (IIRC) 48MHz cycles, during which time it cannot accept more commands.

One of the biggest design challenges with UMDK was reliably detecting the assertion of /OE on the cart slot, signalling when it's safe to begin an SDRAM read, but doing it quickly enough to ensure data is ready on time during one of the fast DMA read cycles.

I suspect what's happening here is that the rising edge of the /OE signal on the cart slot is slow, and that happens to manifest itself as noise on the signal seen by the FPGA, fooling it into thinking the MegaDrive is beginning read N+1, when it's actually ending read N. The solution is to modify the VHDL to ignore the state of /OE for four or five cycles after it deasserts for the first time at the end of a read. I'll have a look into doing that, and sending you a new .xsvf file to try.

[Montserrat]

i've installed debian, and started all over again. Same problems. Firmware.bin is 50260 bytes long.

So ill wait for next step.

Thanks for your help Chris.

[prophet36]

OK, here's a quick verification step, to make sure we can trace execution of code read from a small ROM in the FPGA, bypassing the SDRAM controller altogether. Connect USB cable, turn your MegaDrive off then on again, then do this:

Code: Select all

cd ${HOME}
wget http://www.swaton.ukfsn.org/umdkv2/insn-trace.xsvf
wget http://www.swaton.ukfsn.org/umdkv2/looper.bin
flcli -v 1d50:602b -p J:A7A0A3A1:insn-trace.xsvf
loader -v 1d50:602b -x 2 -t insn-trace.bin

Hit ctrl-c after a few seconds, then:

Code: Select all

logread looper.bin insn-trace.bin | head -1000 > insn-trace.log

Now upload insn-trace.log somewhere so I can have a look at it.

Assuming this works as expected, the next step will be for me to modify the trace logic to act as a crude logic analyzer, to sample the lower 5 bits of the address-bus, /UDSW, /LDSW and /OE on every 48MHz clock. This will hopefully identify the problem you're all seeing when reading from SDRAM.

[prophet36]

OK, now for the logic analyzer. Again, connect the USB cable, turn off your MD, then back on again, then:

Code: Select all

cd ${HOME}
wget http://www.swaton.ukfsn.org/umdkv2/la.xsvf
flcli -v 1d50:602b -p J:A7A0A3A1:la.xsvf
loader -v 1d50:602b -x 2 -t la.bin

Hit ctrl-c after a few seconds, then:

Code: Select all

bzip2 la.bin

You will now have a file called la.bin.bz2. Upload it somewhere so I can have a look at it.

Note that in this case the trace will produce data much faster than before, so get ready to hit that ctrl-c when you start to see the "....."s appearing, otherwise you'll be uploading a big file.

If you have different model consoles (MD1, MD2, PAL, NTSC, Nomad etc), please try this and the previous step (involving insn-trace.xsvf) on all of them. Please rename your files appropriately so I'll know which is which (e.g nomad-insn-trace.log, nomad-la.bin.bz2, md1-ntsc-insn-trace.log, md1-ntsc-la.bin.bz2, md2-pal-insn-trace.log, md2-pal-la.bin.bz2 etc).

[Montserrat]

Hi!, got same results as the other loader commands, Seems to not work at all (i never get the ....), if i press Ctrl+C to interrupt its does nothing but typing ^C, i have to use Ctrl+\, to end the process, (or shut down the megadrive).

Then i get an empty .bin file.

Code: Select all

fran@debian:~$ loader -v 1d50:602b -x 2 -t insn-trace.bin
UMDKv2 Loader Copyright (C) 2014 Chris McClelland

Putting MD in reset...
Releasing MD from reset...
Dumping execution trace to insn-trace.bin
^C
^\Abandona
fran@debian:~$ 

Seems i'm the only one stuck in this commands, i am doing something wrong or my umdk is faulty¿

I stepped back to the gdb-bridge test, that also did not work, thats the content of my build.log

Code: Select all

make BRANCH=20150315
make[1]: Entering directory '/home/fran/20150315/makestuff/hdlmake/apps/makestuff/umdkv2/gdb-bridge'
make[2]: Entering directory '/home/fran/20150315/makestuff/hdlmake/apps/makestuff/umdkv2/gdb-bridge/tests'
lin.x64/dbg/tests
/home/fran/20150315/makestuff/common/top.mk:471: recipe for target 'dbg' failed
make[2]: *** [dbg] Interrupción
/home/fran/20150315/makestuff/common/top.mk:427: recipe for target 'all' failed
make[1]: *** [all] Interrupción
/home/fran/20150315/makestuff/common/top.mk:440: recipe for target 'deps' failed
make: *** [deps] Interrupción

Any ideas?

[prophet36]

Seems to not work at all (i never get the ....)

Try with la.xsvf.

[Montserrat]

OK, just used la.xsvf, works, here is the compresed output:

https://mega.nz/#!qQ13VaYZ!QRTD2tz3CjKC ... xJ_kpUaTMc

[prophet36]

OK, just used la.xsvf

Now this is interesting. The actual code in the modified 1st-stage bootloader (in the FPGA's ROM) is this:

Code: Select all

                            .text
                            .org    0x000000
0000 00FF CAFE       test:  dc.l    0xFFCAFE       /* Initial SSP */
0004 0000 0008              dc.l    0x000008       /* Initial PC */
0008 41F9 00FF 0000         lea     0xFF0000, a0
000e 7000                   moveq   #0, d0         /* Initialize D0 to zero */
0010 3140 003E       1:     move.w  d0, 0x3e(a0)   /* Save D0 to addr 0xFF003E */
0014 2200                   move.l  d0, d1         /* Run inner loop D0+1 times */
0016 4E71            2:     nop
0018 51C9 FFFC              dbra    d1, 2b
001c 5240                   addq.w  #1, d0         /* Increment D0 */
001e 60F0                   bra.s   1b             /* Repeat outer loop */
0020 F00D                   dc.w    0xF00D         /* This word gets prefetched */

Note that it's not intended to do anything useful, its purpose is merely to keep the CPU busy with easily-predictable code so we can see what's going on in the trace.

So, your logic analyzer trace looks like this (you'll need to magnify the image in your browser because it's very wide, and use the scrollbars to view it). It looks like the CPU executes perfectly, right up to the point where it does the first write to onboard RAM (a word-write to address 0xFF003E, to be precise). The write completes (i.e /LDSW and /UDSW deassert), but from that point the CPU just stops fetching instructions from memory, as if the CPU clock had been stopped. This explains why the instruction trace was hanging: it works in discrete blocks of trace data, so it expects a continuous stream of bus activity; it will wait indefinitely for each of these discrete blocks to be filled up with bus activity data.

Here's my theory. On my PAL MD2, I get away with doing TMSS in the 2nd-stage bootloader, which is loaded from flash into internal RAM. But on your console, the TMSS appears to be implemented more aggressively than on mine: merely writing to internal RAM before doing TMSS causes the CPU to lock up.

Later today I'll try adding the TMSS code to the 1st-stage bootloader and you can try again.

[Montserrat]

OK, ill try then, gonna try to get output this into diferent consoles and region modes, may be theres some more clues on that.

[Burbruee]

I have two consoles - both PAL and MD1. One is modded with a 50/60 Hz switch. One is pure stock without any mods. Both have the TMSS text on bootup.

I made the tests on the modded console running at 60 Hz, and on the stock PAL console.
The .log and .bin.bz2 can be found here: http://dump.ettfyratre.se/umdk/

[prophet36]

Montserrat: please try again with this updated logic analyzer. I added the TMSS code to the hacked 1st-stage bootloader. I need the resulting la2.bin.bz2 file.

Burbruee: your traces make no sense at all. Can you check all your connections, make sure your consoles still actually work(!), clean the contacts of the cart-slot and the mating edge-connector on the bridge-board (using something like methylated spirit), and try again? Bear in mind that the insn-trace.log should look at least something like a 68000 starting up (i.e read from address 0, 2, 4 then 8, then start executing code from the address formed by the latter two reads). The fact that you were getting something close to sane a day or two ago but now you're getting garbage suggests dirty contacts.

[Burbruee]

Burbruee: your traces make no sense at all.

Must have been a bad connection or something.. I did it again and it looks better. (reading from 000000, 000002, 000004 etc..)

http://dump.ettfyratre.se/umdk/md1-pal-insn-trace.log
http://dump.ettfyratre.se/umdk/md1-pal-la.bin.bz2

[Montserrat]

Ok i did some tests of la1 file on all my consoles:

Pal-1 asian, all regions
Pal-G EU
Pal-I all regions
Ntsc - US - Nomad

Also did a single test of la2, for pal-1 asian EU region.

I've created a folder so you can get all files classified:

https://mega.nz/#F!rYcmibgJ!LSoq-rsXDk-nu5pDiM6iew

Think all consoles have a same behaviour, i dont have a megadrive 2 btw.

[prophet36]

I did it again and it looks better

Yes, the insn-trace.log looks perfect! Unfortunately your logic-analyzer trace is still FUBAR:



It should start by reading from address 0x00, not writing to 0x3E. We need to focus on fixing this because there's no way I can fix the SDRAM controller until I know precisely what's happening on the bus (i.e /OE timing, etc). I suspect you just have a poor connection somewhere, and something needs a good clean. I don't know whether the bridge PCB you have has a gold-plated edge-connector, but if not it may have become tarnished. If cleaning with methylated spirit doesn't work, you could try cleaning it with some kind of metal polish, being very careful not to get polish on the component legs. Personally, rather than using metal-polish, I use a PCB scrub-block for cleaning these contacts.

You can reproduce the above waveform in full like this:

Code: Select all

wget -qO wavedrom.c 'http://pastebin.com/raw.php?i=GNJ8HGgE'
gcc -Wall -Wextra -std=c99 -o wavedrom wavedrom.c
wget -qO- http://dump.ettfyratre.se/umdk/md1-pal-la.bin.bz2 | bunzip2 -c | head -c 2048 > md1-pal-la.bin
./wavedrom md1-pal-la.bin

That will produce a blob of JSON which you can copy & paste into the WaveDrom Editor. Obviously you can re-run it with newly-gathered la.bin files.

Another thing to try (now that you've cleaned your cart slot, etc) is to go back and try loading sonic2.bin over USB again.

[prophet36]

Ok i did some tests of la1

The la-Pal-1-JP.bin file looks good (see process for viewing it with WaveDrom in my last post), so you should concentrate on that. Try loading a game ROM over USB, starting from a freshly-powered console.

Also did a single test of la2

In this case, the read from 0xA10001 never terminates, as if that region does not have auto-DTACK. I'm well outside my comfort-zone with the TMSS stuff, so we may have to ask someone with a bit more knowledge of it. The bootloader code in la2.xsvf looks like this:

Code: Select all

                   .text
                   .org    0x000000
0000 00FF CAFE     dc.l    0xFFCAFE               /* Initial SSP */
0004 0000 0008     dc.l    0x000008               /* Initial PC */
0008 1039 00A1     move.b  0xA10001, d0
     0001
000e 0200 000F     andi.b  #15, d0
0012 670A          beq.s   1f
0014 23FC 5345     move.l  #0x53454741, 0xA14000  /* Write "SEGA" to TMSS register */
     4741 00A1 
     4000 
001e 41F9 00FF  1: lea     0xFF0000, a0
     0000 
0024 7000          moveq   #0, d0
0026 3140 003C  2: move.w  d0, 0x3c(a0)           /* Save D0 to addr 0xFF003E */
002a 2200          move.l  d0, d1
002c 4E71       3: nop
002e 51C9 FFFC     dbra    d1, 3b
0032 5240          addq.w  #1, d0
0034 60F0          bra.s   2b
0036 F00D          dc.w    0xF00D                 /* This word gets prefetched */