Sonic 1 Bus-Cycle Tracing Example
Posted: Thu Jun 26, 2014 8:57 pm
As some of you are aware, thanks to KanedaFr, the USB MegaDrive DevKit now has its own forum here on SpritesMind!
I thought I'd post here an example of the UMDK bus-cycle trace, gathered from running Sonic 1 for a little over 18 seconds, from reset. I could sample all day without filling up my hard disk, but I'm guessing not many of you will want to download a 2TB trace-log, so I hit ctrl-C after a few seconds.
Here's a small snippet which is from the bit where the sampled "Sega!" sound is being played.
Column 1: Timestamp. There's a counter in the FPGA that increments on every 48MHz clock. The last line in the file is timestamped 885,508,468, which if divided by the 48,000,000 cycles in one second gives 18.448s of sample-time.
Column 2: Type. C=CPU, D=DMA.
Column 3: Direction. RD=Read, WH=Write High Byte, WL=Write Low Byte, WB=Write Both Bytes.
Column 4: The address read or written.
Column 5: The data read or written.
Column 6: The data at that address in the original ROM file. In practice this will always agree with column 5 for addresses within the cart ROM. It's useful to see where the cart data has been altered (e.g due to the debugger setting a breakpoint) and it was also useful to me whilst debugging my memory arbitration.
You can see the DMA cycles due to samples being read from ROM followed by the execution of a bit of code (presumably to initiate a new DMA?), followed by some more DMA. The actual code being executed looks like this:
The full 18.5s file is big (~100MB) so I split off the first 100,000 bus cycles into a smaller (~400KB) file if you're not sure you want to download the whole thing. The full file includes the first 100,000 lines too:
https://dl.dropboxusercontent.com/u/809 ... ad.txt.bz2
https://dl.dropboxusercontent.com/u/809 ... c1.txt.bz2
I'll be interested to see what uses people can put this to. If anyone wants me to get a trace-log of some of their homebrew code, I'd be more than happy. Just be aware that the logs grow pretty quickly: here we have 100MB of compressed data from 18.5s of sample-time.
Have fun!
Chris
I thought I'd post here an example of the UMDK bus-cycle trace, gathered from running Sonic 1 for a little over 18 seconds, from reset. I could sample all day without filling up my hard disk, but I'm guessing not many of you will want to download a 2TB trace-log, so I hit ctrl-C after a few seconds.
Here's a small snippet which is from the bit where the sampled "Sega!" sound is being played.
Code: Select all
49883792 D RD FFFB70 0000 XXXX
49883807 D RD FFFB72 0000 XXXX
49883821 D RD FFFB74 0000 XXXX
49883836 D RD FFFB76 0000 XXXX
49883850 D RD FFFB78 0000 XXXX
49883865 D RD FFFB7A 0000 XXXX
49883879 D RD FFFB7C 0000 XXXX
49883893 D RD FFFB7E 0000 XXXX
49883915 C RD 0010B0 4BF9 4BF9
49883953 C RD 0010D4 4BF9 4BF9
49883978 C RD 0010D6 00C0 00C0
49884003 C RD 0010D8 0004 0004
49884029 C RD 0010DA 2ABC 2ABC
49884054 C RD 0010DC 9401 9401
49884079 C RD 0010DE 9340 9340
49884104 C RD 0010E0 2ABC 2ABC
49884138 C WB C00004 9401 XXXX
49884163 C WB C00006 9340 XXXX
49884180 C RD 0010E2 96FC 96FC
49884205 C RD 0010E4 9500 9500
49884231 C RD 0010E6 3ABC 3ABC
49884264 C WB C00004 96FC XXXX
49884290 C WB C00006 9500 XXXX
49884307 C RD 0010E8 977F 977F
49884332 C RD 0010EA 3ABC 3ABC
49884365 C WB C00004 977F XXXX
49884382 C RD 0010EC 7800 7800
49884408 C RD 0010EE 31FC 31FC
49884441 C WB C00004 7800 XXXX
49884458 C RD 0010F0 0083 0083
49884483 C RD 0010F2 F640 F640
49884509 C RD 0010F4 3AB8 3AB8
49884542 C WB FFF640 0083 XXXX
49884559 C RD 0010F6 F640 F640
49884584 C RD 0010F8 4BF9 4BF9
49884643 C WB C00004 0083 XXXX
49884706 D RD FFF800 0000 XXXX
49884724 D RD FFF802 0000 XXXX
49884742 D RD FFF804 0000 XXXX
49884759 D RD FFF806 0000 XXXX
49884777 D RD FFF808 0000 XXXX
49884813 D RD FFF80A 0000 XXXX
49884843 D RD FFF80C 0000 XXXX
49884872 D RD FFF80E 7E7E XXXX
49884886 D RD FFF80E FFFF XXXX
49884900 D RD FFF80E 0000 XXXX
Column 2: Type. C=CPU, D=DMA.
Column 3: Direction. RD=Read, WH=Write High Byte, WL=Write Low Byte, WB=Write Both Bytes.
Column 4: The address read or written.
Column 5: The data read or written.
Column 6: The data at that address in the original ROM file. In practice this will always agree with column 5 for addresses within the cart ROM. It's useful to see where the cart data has been altered (e.g due to the debugger setting a breakpoint) and it was also useful to me whilst debugging my memory arbitration.
You can see the DMA cycles due to samples being read from ROM followed by the execution of a bit of code (presumably to initiate a new DMA?), followed by some more DMA. The actual code being executed looks like this:
Code: Select all
0x0010D4 lea 0xC00004, a5
0x0010DA move.l #0x93019340, (a5)
0x0010E0 move.l #0x96FC9500, (a5)
0x0010E6 move.w #0x977F, (a5)
0x0010EA move.w #0x7800, (a5)
0x0010EE move.w #0x0083, 0xFFFFF640
0x0010F4 move.w 0xFFFFF640, (a5)
0x0010F8 lea 0xC00004, a5
https://dl.dropboxusercontent.com/u/809 ... ad.txt.bz2
https://dl.dropboxusercontent.com/u/809 ... c1.txt.bz2
I'll be interested to see what uses people can put this to. If anyone wants me to get a trace-log of some of their homebrew code, I'd be more than happy. Just be aware that the logs grow pretty quickly: here we have 100MB of compressed data from 18.5s of sample-time.
Have fun!
Chris