keithToday is the first day in months that I’ve made what I consider good progress.
I am now able to read any track(so far) off of any disk with 100% success including checking and relying on the checksums.
I read track 43 off of “Amiga Appetizer Program Disk” (c) 1989 successfully, not to mention my test disks that work perfectly.
I’m getting 100% good data through my hardware.
This is exciting. Next steps:
Currently, there are separate programs and processes in order to read one track. First, we have two different SX programs, one to record the track, and one to transmit the stored track to the PC via USB. I need to combine those into one. It will take turns reading+storing a track, then transmitting, reading+storing, then transmitting, etc. This will involve some magic because the ISR has a much different setup.
Second, I have one program that decodes and analyzes a single track. This is the program based on Marco’s source code. I also run RealTerm which is the capture software. This capture software has to get integrated into the main program.
Third, I am controlling the floppy drive via the amiga right now via DiskMonTools. This means that I press a button to read a track, and I sniff off of the daisy chain port. This will have to change. Eventually, the floppy drive will be attached ONLY to the SX and the SX will step the heads, turn the motor on off, etc etc. Now I’m not sure if that will be commanded by the PC for a simple lead change or if the SX will have the intelligence.
So as you can see, there is a fair bit of work to go.
The real key here is that the central idea behind the project WORKS. It’s really just a matter of integrating everything, and automating what is now a manual process. And that’s not to say that there’s not a lot of work —- but I’m headed in the right direction FINALLY.
I’m out of the debugging stage and now onto write more code that needs debugged.
Wow, congratulations! Your success impresses, as well as all the work you have done in both speculating (or thinking out loud) and probing things with your fingertips. (I’d confess I like the ‘brainstorming’ part most)
Do you think you could use some simple protocol between the PC and your SX hardware to read one track a time? Like you send ‘R14’ and SX starts reading track 14 responding ‘OK’ when done, then you send ‘L’ and get lots of hex data.
Controlling FDD is not hard at all. You’ll need to allocate a few lines on your SX for SELECT, DIR and STEP, and play with timings a bit.
Out of curiosity, what was exactly the problem with CRC not matching?
Thanks. I’m happy to be making progress.
I’ve already been thinking about the protocol you describe. It will be similar to what you describe. Here’s what I’ve come up with so far :
There will basically be two modes the SX will be in. Either 1> command mode, where it waits for a command or 2> reading from the floppy and storing into FRAM
These things require two completely different ISR codesets, so this has to be an either/or thing. This is mainly because USB is soooo slow, even at 1mbps, the SX has 50+ cycles of just waiting around — I can’t do this without interrupt functionality, and merging the ISRs to both work simultaneous would be way too hard.
Although I would really like to have a “read track 14” command, I think I’m going to make the PC maintain state, and have the SX be stateless. So the PC is responsible for maintaining current track numbers, etc etc. I’m going to push as much out to the SX as possible, with the full understanding that the PC has “time and memory to burn”
There are other reasons for having the PC do it too — like for instance, time between stepping is long, so I’d need a timer for that etc etc. Whereas I can delay within the PC, or just the inherent delays with a normal windows C program can give me the couple hundred milliseconds etc if I need.
So the interaction would be like this:
[sx in command mode]
[PC says READ current track]
[sx in read/store mode]
…..
[finishes the read/store]
[sx in command mode]
[PC says XFER data]
[SX reads FRAM and xfers via USB]
[SX in command mode]
[PC says STEP]
[sx steps…]
[SX in command mode]
[PC says READ current track]
etc.
My plan is to have the SX automate wherever easy and possible. PC does everything else…
Regarding the problem, if you read the earlier posts, you can get the detail. But the problem was the fact that I modified a function, which worked in all cases but one. There was another function that depended on the now modified function, that broke as a result of the changes. That was my fault.
Here’s the crazy thing: I think my hardware has worked for MONTHS, but since the software sometimes failed the checksums, I thought it was the hardware. DUMB software lied to me! 🙂