techtravels.org

current code plus recent progress

Although its ugly, the new code is here.

This shows the entire ISR in assembly now. I do like it much better.

Tonight I happened to transfer a track that has a good sector. The sector header passed checksum, as did the data portion of it. I decoded the data portion (after modifying and combining marco’s code with floppy.c) and displayed it on screen, comparing it with the amiga. Everything was exactly correct, so I have one good complete sector. Now if only all of them could be like that.

For the most part, I appear to only be off in sector size by perhaps 10 bytes or so, although there is an occasional missed or skipped sector. I haven’t manually looked at these yet BUT I’m betting if the size is right the data will be right, and that’s good. Fix my size problem, and go home happy.

I’m going to try David’s idea of using only edge-based interrupts, but I’m not sure yet what indirect complications that might bring up. I’m going to put some thought into it.

keith

Amateur Electronics Design Engineer and Hacker

3 comments

Leave a Reply to Tim Cancel reply

  • Slight offtopic – could you please measure a typical STEP pulse width on your Amiga? I am now considering different ways of dealing with it, from interrupt-driven to polled.
    Thank you in advance.

  • The way I’m hooked up currently doesn’t appear its going to work to measure the STEP pulse.

    I have a cable running from the daisy-chain port(would be used to attach another drive) of the drive which obviously passes on the READ data and the WRITE data lines from the main port , plus a bunch of others — but I dont think STEP is one of them.

    When I put my scope on the STEP pin, I see a signal that appears to be influenced by the read data that I’m monitoring — I think this is just crosstalk.

    I don’t have the hardware setup to measure that pulse right now. I do plan to buy a cheap “data tap” which will let me get into the middle of a cable, I just haven’t bought it yet.

    If it helps, the docs I’ve seen show it as a low quick pulse of ~500ns, with 18ms worst case time before you should send the next one.

    This help?

  • Thanks, the figures are good start. At least I know I’d better be looking for the pulse’s front rather than for its low level which seems almost impossible to detect with polling technique in a tight but lengthy loop.