keithhttps://www.techtravels.org/wp-content/uploads/pefiles/floppy55asmoptwithframver2.SXB
Here’s a current version of the code. I cleaned up my code tonight, added a bunch of comments, and tried to explain and document what I’m doing and the logic behind it.
The current code is so much better than older versions, the time spent in the ISR is tiny in comparison to what it used to be. I think I’m roughly under 600ns — which I’m happy about. I’m too tired to fire up the scope and double check this value, but I’m almost positive its 580ns or something.
The main gain in terms of processing speeds comes from the fact that I’m not messing with any ugly bit-shifters. I simply detect either the pin change or a rollover condition, and immediately write this bit to the FRAM.
I have separate code that xfers the FRAM contents to the PC via USB, which I’ll put up if there’s interest. It’s easy enough and uses the same SENDFRAM and RECVFRAM routines that I wrote that are used in the main program. I want to eventually integrate this separate xfer code into the main program, but this will involve two different modes, ie a “receive from floppy drive” mode and a “transfer to PC” mode. I say two different modes because each uses the ISR for something different. I use the ISR to xfer stuff to the PC to make sure I’m respecting the ASYNC baud rate requirements…..
I’m also using some terminal software ala hyperterminal to store the raw mfm data into a file to be processed by the PC software. I should be able to integrate this read right into the processing software. It just needs to grab bytes and throw them into an array.
comments are welcome.
When you get this to a usable (your happy with) state, are planning on making the code open source and post the hardware details (with maybe step by step instructions) ? Is the hardware already defined and people could already be building their own ?
Yes, absolutely. This is really designed to be a community project(hence the blog with progress reports). I’d love to give back to the amiga community. Yeah obviously the online documentation etc would have to change drastically to provide a cleaner, easier instructions for people to build it. There are some barriers to entry, namely you have to have an SX-KEY programmer(and some cheap eval board), and the FRAM is(was?) hard to get in low quantities and surface mount.
The first barrier could be avoided by me providing a cheap “SX burn service” ie you send me a chip and $5 and I burn the latest firmware for you. Obviously, there will be lots of changes in the beginning, so this might not be a great idea.
FRAM could be bought in a larger qty and then pieced out to individuals, and perhaps digikey etc has picked them up full time — I haven’t looked.
There are a couple companies interested in it, as they’ve already contacted me. I won’t rule out 100% that some company might offer a “kit” or a completely built one, which alot of people would consider a good service worth paying for. As for me, I have no intention of manually assembling tons of kits to sell. It just wouldn’t make sense…..
The hardware is already defined, and people could assemble what I already have done —- but I really wouldn’t suggest it quite yet. I haven’t made that final “big step” in the prototype yet. I haven’t put the necessary time in lately to get past the latest hurdle. Once that happens, I could use the debugging/beta help…..