Mar 11

java client preview

I’ve put up a preview of the java client in action. It’s a 2 minute video with narration.
You’ll need a DivX codec installed in order to view it.

I probably could have messed with compressing this further, so I apologize for the size of it. 16 megs! Bandwidth is pretty fast and cheap these days, so have at it. Note my web server has TONS of bandwidth, it took me less than 10 seconds to download it across my 15mbps FIOS service.
Right-click here and do a save-as.

So far, I’ve got sort of the bulk of the application working. It will step through the floppy drive, reading the disk, decoding the MFM, and storing the disk data into an array. I will write this whole array out to disk once it’s finished. There are alot of little details that need to be worked out, but they are relatively minor things. I’ve got to get the options dialog fully working, the STOP button, go to track0, etc etc. I should be ready to spit out an .ADF any time now.

I’m excited about the progress I’ve made over the last few days, and things are really moving forward.

I’m always happy to hear what people think, suggestions, and so on.

Mar 10

java software progress

This morning I added MFM decoding, header and data checksumming and checking to the java client.  I was somewhat worried about doing the MFM decoding, but it was all worry for nothing.

Once you wrap your head around how the Amiga does MFM, it’s really not too bad.  I wrote the MFM decoding routines myself.  The splitting of ODD and EVEN bits across a sector is goofy.  And I’ve read about the reasoning behind it, and understand them, but in 2007 it’s hard to appreciate it.  Memory, speed, storage, etc is just so plentiful these days, that you don’t have to jump through hoops to do basic tasks.
Right now, I’m just doing a single sector, but a loop can make that a track, and another loop can make that a disk.

I’ve got to put the “read disk” code into some other portion of the code because it’s sitting in “main()” right now.  And I’ve got to create an object?/structure?/class? for a track.  And perhaps for the whole disk.  I’ve really got to brush up on my Java skills.

Jan 25

new isr thoughts

While this new ISR is indeed easier to understand and much more simple, I can’t help but remember what else my ISR used to do for me.

The four things I really lose are:

1> Any type of double 1′s protection

2> Idle mode (don’t store long runs of high ’0′s.) which is related to

3> No more than three consecutive zeros (longest data group is 1-0-0-0) and

4> A falling edge to start each group of bits.

The idle mode is easy enough to deal with, I’ve just set it up to wait 500ms after turning the motor on, and then wait for the first high->low falling edge. Then I start storing bits. Otherwise, without that, I’d capture a bunch of 0′s. I now have a falling edge to start the capture, but not on each group.

As far as the double-1′s and no more than (3) 0′s, I’d like to think that everything is working fine, so as long as the data is good on the disk, it should come out of the drive and into the SX properly. I think those things sort of hid problems I had, so I’m glad to just get the raw data.

The other benefit is that getting raw data might actually come in handy, later, if I ever deal with the issue of copy protection, etc, where the data pattern isn’t strictly MFM.

I’m happy I’ve simplified things, and it’s going to stay this way for the time being.

Jan 16


These are all 2us per division on the scope.  Top trace is the actual MFM, bottom trace is the entering and exiting of my ISR.  You should see an entry into the ISR for every falling edge, and every ~2us afterwards.

1k, 680, and 490 in order.

1k pullup

680 ohm pullup

490 ohm pullup

Jan 16

mid-january status

So here’s where I’m at:

I know my memory read and write routines are good.  I calculate a checksum as I’m writing the data, and on the output of that data to the PC, I also calculate the checksum.  They match, no problems there.

I know my USB to PC routines are good.  I calculate a different byte-based checksum (8-bit checksum)  from the data I get from the FRAM, and then I have the PC software calculate it.  They always match and I’m using Parallax’s UART for the time being.  Mainly for reliability.

I’m using a new basic ISR routine, which I posted a post or two back.  It’s simple, it doesn’t force any particular type of encoding.  What comes off the drive goes into the memory.  There are some drawbacks, for instance, I don’t support any type of idling.  For the initial data, I wait to see a transition, and then I turn on interrupts and start recording.  I don’t check double 1′s now, and I don’t check more than (3) 0′s.  The data SHOULD be coming out of the drive correct, and force fitting it into correct form just doesn’t work, and while it does fix SOME situations, I *REALLY* have to get to the bottom of why this happens.

My MFMSanityCheck software is telling me .3% of the data is bad, which I think 99.7% still isn’t anything to complain about, but I really have to find the source of the problems.

All .3% of at least one sample file is a double 1′s situation.  And I’ve seen this before.  And its NEVER triple one’s, and it’s NEVER too many zeros.  Just double 1′s.  Two 1′s back to back.

So now that I’ve tested my memory, the problem is either the drive is REALLY spitting out two 1′s (and I have no clue how to fix that problem), or my ISR is triggering twice on the same edge.

I’m leaning towards the second choice but I really have to figure out how that is happening.

Jan 13

simplified ISR

It looks as if I spoke too soon.

I’m still having reading problems.  The data used to be forced into an MFM mold, but all that’s done in some cases, is to further corrupt the corrupt data.

I rewrote my ISR to simplify it.

‘ ————————————————————————-
‘ ————————————————————————-


SETB rb.1            ‘debug pin(inside interrupt)



‘these next two instructions retrieve the edge-pending register and clear it in the event an edge triggered it

MODE $09
MOV !RB,#%00000000
mov myres, w

‘next 5 lines store the bit in the fram
CLRB SCK        ‘make sure clock is low to start with

MOVB SI, myres.0    ‘send bit to fram

SETB SCK        ‘raise clock notifying chip to read the data

‘COUNT THE Bit stored
IJNZ lobyte, goback
IJNZ hibyte, goback
inc superhibyte


CLRB rb.1            ‘debug pin
MOV W, #-101     ‘wait 101 cycles(101/50 = 2.02 us) to fire next timed interrupt


Once again, I’m seeing duplicate 1′s.  Either there really are two edges close together, or my SX is detecting the same edge twice.

Jan 09

correctly reading an entire track reliably from PC drive

OK Great news.  As I stumbled on in the last post:

I’ve fixed my reading issues, and I’m now reliably reading, in one shot, an entire amiga track from the unmodified standard PC drive!!

When seeing double 1′s earlier, I had the extra second 1 basically thrown out.  I didn’t process anything, but just ignored it.  Because I assumed I was simply detecting the 1 TWICE, I thought this made sense.  However, this detection of back to back ones MUST HAVE BEEN a “10″ detected as “11″.  I changed the code to write a “10″ when it sees a “11″ and now it reads every track perfectly!!

This is really an exception issue and if you recall, I was getting like a small percentage of bad bytes.  I just re-ran the new track data through the MFMSanityCheck program I wrote and I get 0 bad bytes!!  This means everything is perfect MFM!!

Jan 04

interesting results

OK, I’ve applied the “double 1′s” fix that I talked about earlier today.

This definitely helped things. I think my results are quite possibly the best I’ve seen them yet.

Now, my SX enforces both the back-to-back one MFM rule, and the no-more-than-3-consecutive-zeros rule. So despite what the drive puts out, the SX only sends back compliant MFM.

I think I was detecting the same transition twice somehow. While I’m not super happy about the way I’ve gone about fixing it, this patch seems to have worked.

I can still read the all 0xFF’s and all 0×00′s disk ok, so at least I haven’t gone backwards.

I sometimes get mixed results no matter the disk. Sometimes when I read the track I get certain sectors right, for example maybe 1-7 but no 8,9,10. Other times I get 8,9,10 right, along with 1-5, but then 6 and 7 are corrupt. It’s very wierd. And remember I’m reading exactly the same spot on the disk. So depending on the, I don’t know, order of the data, changes the validity of it????
Also, I’m running into exactly the same problem in some cases I had before. While the data looks PERFECT, the checksum isn’t coming out correctly in all cases. Header checksum matches. Data checksum does not, but the data is fine.

Maybe my data checksum in the header is getting corrupted? So that’s why it doesn’t match?

I thought for a half-second about just making multiple passes over the data, get the good sectors from each of the batches until I have all 11. :)

Im getting closer…………………..

Jan 02


While I’m hesitant to post this at all, this is a quick and dirty application I threw together, and I do mean threw, that will check for valid MFM bytes.

See the previous post for the link to the actual bytes.

It also ignores 0xFF — which is in fact an illegal byte, but I use it as a delimiter. This means a good delimited file from my SX project should only register one bad byte, and that’s the last byte, the checksum.

This program simply displays the number of valid bytes, followed by the number of illegal bytes, and calculates the percentage of them. My good read from earlier read .007%, which is like exactly one byte out of 13,824 wrong. So good answers should be very low.

I made this as a quick utility to check the output from my SX instead of fooling around with my full MFM decoding software.

Note it has a hard limit at 15,000 bytes, and is designed to take exactly one raw commodore amiga mfm track as an input file.

While I’m sure this is virus free, it’s ALWAYS a good idea to check executables before running them. I have no clue on the requirements works on XP SP2.