logic analyzer on Amiga 500 Paula chip

So I’ve attached my Intronix LA1034 to the Paula chip, the 16-bit wide data bus, and the DMA Request line. I triggered the logic analyzer on 0x4489, of course.

Here’s the results:

(click for a full size version)

So I’ve spent most of my time sort watching it come out of a floppy drive, but never from Paula’s perspective. It’s always before Commodore’s custom LSI floppy controller Paula could get ahold of it. So notice that the data is still RAW MFM, and not processed in any way, because Paula doesn’t perform this function. The MFM decoding is done in the trackdisk.device, with the help of the bit blitter.(part of Agnus)

So the normal floppy sync pattern is 0xAAAA 0xAAAA 0x4489 0x4489, but why do we see 0x2AAA ??

So, 0x2AAA is 0010 1010 1010 1010. right? We’re missing the first bit. It turns out there was a bug in the MFM encoding routine. It was fixed March 16th 1990 at 1:08am in the morning, in revision 32.5 of the trackdisk.device.

Also, most times, the sync word used was 0x4489 — which is exactly what I use to find sync in the firmware I wrote for the microcontroller.

Oh and here’s Paula with the great EZ hooks on her leads

(click for full size)


Amateur Electronics Design Engineer and Hacker


  • Oh so I was using Timing Mode on my logic analyzer, and sampling between 20 and 50mhz. The more I thought about things, though, is that Paula does everything using either C1 (color clock) or C3 (color clock shifted 45 degrees), so it would make more sense to use state mode, and attach the LA to the color clock.

    Much more interesting results. While I can’t sample the disk read signal (because it’s not sync’d to the clock), the data on the bus along with the DMAL lead have more significance. In between actual Paula changes, some of the data on the bus was invalid/not useful. Because who know how Paula goes about modifying the data on the bus prior to indicating to agnus that the data is ready. I still don’t understand how DMA works on the amiga. It seems like a certain time after the last DMAL pulse, the correct data should be on the bus. I need to look into this further.

    Incidentally, I also sampled the disk lead in timing mode, and I found the input bits that match the output from Paula. It looks like things are delayed to the bus by only maybe a byte. I swear I read somewhere that Paula has a 3-byte register for temporary storage, but it looks like the data is put on this bus +/- one bytes worth of RAW MFM.

    Very interesting this stuff, but time to go to sleep.