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