Tag - paula

status updates
logic analyzer on Amiga 500 Paula chip
quick memory check
how the amiga reads floppies

status updates

I’ve been more active on the project than the posts have illustrated. I’ve been working on a few different things :

Been trying different PLL solutions, examining how Paula does it, and actually analyzing my read data with Matlab to get a graphical view of the “problem.”  Most of my solutions, while they technically work (ie they have the desired behavior), they don’t actually solve the problem at hand.  I have to get a better hand on what “bad data” looks like, and then try to invent solutions that address the specific problems I’ve seen. I’m also using Paula as one metric of “goodness.”  In my mind, my controller should be better — should read disks that the amiga is not able to.

I don’t think I fully understand the problem.  I know what the SYMPTOMS are — flux transitions are read sometimes as being “in the middle.”, 5us between pulses where 4us=’10’ and 6us=’100′. What the heck does 5us mean?  How do we bias this towards the right direction?  Many of the controllers use some sort of PLL — but I see values one after another that span the acceptable range of values.  You can’t track something that doesn’t trend!

I also want to get a better handle on how Paula works.  I’ve got it hooked back up to the logic analyzer, and been trading messages on English Amiga Board about disk DMA and the like.  I’d like to do automatic comparisons between the output of Paula and my project and see when Paula gets it right, but I get it wrong!

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)

quick memory check

So on bootup, I now have the hardware do a memory check.  I basically take and write out a bunch of values to the memory, and then read them back and make sure they read back properly.  The values written are based on the 16-bit memory address…….If it succeeds it writes, “MEM-OK” to the serial port, a “MEM-FAIL” is a pretty bad error and the program refuses to run.  No sense in continuing on if the memory is bad.

Quick dirty code, but it does the trick.  I can’t really cause a failure without screwing w/ the hardware…. I guess I could momentarily touch the data pin to ground or something that should cause it to read/write a misplaced 0…..

The more I test hardware for a living, the more test cases I can come up with to put this thing through its paces.

Last night, until 2:30am, I had my Amiga 500 hooked up to my logic analyzer.  Can’t figure out when Paula is dma’ing the 16-bit words to memory, I’ve got to look at clocks etc.  I think the DMAL pin should be pulsing at some point.  When I get more time to work on it, I’m going to take a look.  I’ve got to order more of those xgrabbers or whatever the heck they are called.  Mini probes basically….

More later………..

how the amiga reads floppies

So I’ve forever wondered, at the hardware level, how the amiga reads floppy disks.  I’ve gotten bits and pieces over the years, but I’ve never really understood the bulk of it.

So there are four main chips involved in the floppy controller — the functions are not grouped together like they would be on a NEC765 or similar controller.

The four chips involved are:

1. 8520 Complex Interface Adapter (CIA), the ODD one, U7 on the schematics.  This is a generic I/O chip that handles a bunch of things — but specifically the control OUTPUTS from the drive to the amiga.  Commodore calls this the “disk sensing” functions.

2. 8520 Complex Interface Adapter (CIA), the EVEN one, U8 on the schematics.  Same as above, but this one handles the control INPUTS from the amiga to the drive.  Selection, control, and stepping.

3. Gary handles the state of the MOTOR of the floppy drive, and takes what write data/gates from PAULA, does some magic stuff (still working on what Gary actually does), runs it through a NAND gate configured as an INVERTER, and then pipes it to the drive.  Gary handles just disk writes, so controller to drive output.

4. Paula handles processing the incoming read data from the drive, handles the DMA including firing off interrupts to the 68K when the SYNCWORD is found, or when the DMA is complete.  Paula has the real job of doing the data separation and has a digital PLL circuit in hardware.  Note that it appears that Paula doesn’t select, turn the motor on, select sides, etc etc whatsoever.  The programmer/OS has to handle all that stuff.  Paula just brings the bits in, DMA’s them into memory, and lets the rest of the processes handle everything else.

All the MFM stuff is handled inside the trackdisk.device stored in the Kickstart ROM.  I’d like to at least partially disassemble the ROM code since thanks to emulators, the ROM files are everywhere.  Maybe I’ll let IDA have a crack at it.

I would _really_ like to see the dpll circuit setup inside Paula to see exactly how Commodore implemented it on the Amiga.  The paper I recommended a couple posts back talked specifically about design decisions surrounding DPLL and I’d love to know what methods the original engineers used.

Originally I thought the controller was almost entirely in software (and actually, the majority of it is, in fact software) — but Paula has some disk controller hardware too.  You always need to have some hardware components for turning leads off and on — but I’m not too surprised that there is some custom hardware there.

I’m ordering a A500 service manual — which I think I already have a foreign copy of — I’d like as much info as possible.