keithWell, here’s where I’m at:
The external amiga floppy drive is now hooked directly to my SX microcontroller. The code within the microcontroller waits for a command. If it get’s a “B” command via USB, it turns the motor on the drive, stores the contents into FRAM, and then turns the motor off. It’s grabbing one track at a time. The SX then goes into command mode again. If my PC software sends it an “A” Command, then the SX dumps to contents of FRAM back to the PC, then the software proceeds to process the track by checking checksums, and ensuring everything is ok.
As far as speed: The motor is on for approximately 225ms. It takes roughly 83ms to transfer the track from SX to PC. So really only ~308ms per track. Now there will be PC processing time, and everything still has to be automated, but I’m pretty happy with the times.
Absolute minimum time would be 160 tracks @ 308ms per track, 49 seconds. But I really think the end result would be closer to 80 seconds(500ms per track). I guess that’s not bad for reading a whole disk straight into an .ADF file.
What’s left is automate everything, like the sending of the STEPS, change from one side of the disk to the other, etc.
Everything will be commands to the SX via USB, so the commands might be:
“C” – STEP forward
“D” – STEP backward
“E” – Switch to upper head
“F” – Switch to lower head
So a command string might be:
“EBA FBA C EBA FBA” and so on.
Using ‘U’ and ‘L’ for upper and lower sides, respectively, can probably be more descriptive, as well as, say, ‘F’ and ‘B’ for forward/backward stepping and ‘R’ and ‘D’ for reading/dumping, what do you think?
Sorry for the silly question…
I can easily read amiga floppies with a PC by just adding an extra PC floppy drive (very cheap)
and using the FDI software.
Is your solution better and in which respects?
If you are talking about disk2fdi, there is no Windows NT, 2000, or XP support. Most people have modern OS’s on their windows PC. DOS, or a frontend that supports 95/98/me isn’t so modern, or convenient.
Even if you boot your machine to DOS, you need another program just to get access to your NTFS partitions.
Although I haven’t used it, I’ve heard it can be slow and buggy.
But use whatever tickles your pickle, emuboy!
Tim Says: “Using ‘U’ and ‘L’ for upper and lower sides, respectively, can probably be more descriptive, as well as, say, ‘F’ and ‘B’ for forward/backward stepping and ‘R’ and ‘D’ for reading/dumping, what do you think?”
Yeah. More descriptive commands are better. It’s easy enough. Although this is down the road, I was thinking that Java might really be useful here. Since the FTDI USB chip supports Mac 8/9/OSX and Linux along with Windows, a Java implementation might do the trick nicely.
There’s no tricky programming in Java required. Simple serial commands are all that’s needed on the communication side of things. The goofy bit-manipulation functions would have to be worked out, just in case Java mixes up the order of operations, different byte sizes, etc.
Down the road, of course! 🙂
Naah, me myself, I don’t like Java. On the other hand, I don’t know Java at all. I know the idea behind it was quite romantic – write once, run everywhere – and has been mocked since then to ‘write once, debug everywhere’. What I definitely don’t like is Java being stuffed just about everywhere.
This is off topic anyway 🙂
I think using Java is a great idea. That would also of course mean that everybody can use it from the word go, and you would only have one code path to maintain.
I am not sure what you mean about “just in case Java mixes up the order of operations, different byte sizes, etc” though? Surely it would be the programmer mixing it up? 🙂 Obviously you need to be careful only having signed types, which is a annoying, but not normally a problem.
I am a professionally Java developer btw, if you need any Java bit-twiddling help, just let me know.
Robin,
Thanks for your input.
Heh, yeah, of course it would be ME screwing up! 🙂 Marco Veneri, whose code I’m basing this on, chose to leave the bits coming out of the drive stored in an unshifted fashion. They need to be shifted before use, so he implemented read routines where you specify byte number, and then a bit offset, and the routines return a properly shifted 16-bit word.
I don’t generally work at the bit-level in C (or java for that matter) so that stuff is foreign to me. Although I understand what the various operators DO, since we have different data sizes, the actual net effect of those operators isn’t clear to me. Ie, is it getting shifted past the end of the word, or only shifted higher into the word, etc.
Thanks for your offer — don’t be surprised if I take you up at some point.
I need to get things working initially in C. Java will be down the road.
Tim raised the issue where portable java should run on different platforms, but in reality has troubles. The code I’m using does nothing tricky, is command-line for right now, and the only “unique” features it uses is serial-port access.
Would you expect there to be trouble there?
Thanks.
Bit shifting in Java or C is relatively simple. In Java it is slightly more complicated because of the signed types as I said. For this reason, Java introduced a new operator ‘>>>’ which will shift everything including the sign bit by the specified amount. e.g. 0xFFFFFFFF >> 1 == 0xFFFFFFFF, and 0xFFFFFFFF >>> 1 == 0x7FFFFFFF. Using the normal operator ‘>>’ preserves the sign bit.
The other thing about working with the signed types in Java is that it is actually easier working with bytes using a larger type (so you do not need to worry about the sign bit). For example, using an ‘int’. So an operation that shifts bits left would also require an AND operation to size the result to the required amount. For example, shifting a byte value:
int b = 255;
b = (b > 7 | ((b
Oops, looks like my < brackets are getting screwed up. Trying again…
int b = 255;
b = (b << 1) & 0xff;
b would therefore be 254, not 510.
Signed types is one thing that annoys me about Java, but it is not such a big problem considering what you gain (huge industrial strength class library, dramatically decrease development cost, garbage collection, multi-platform, etc.)
Everything else is as you would expect. You can also do rotates fairly easily too. For example, a rotate left of 1 would be:
int b = 254;
b = b >> 7 | ((b << 1) & 0xff)
That is, shift bit 7 into position of bit 0 and OR with the rest shifted left.
Everything else is the same (AND=&, OR=|, XOR=^, COMPLEMENT=~).
I’m not sure Tim means about portability problems, perhaps he can give some more detail? The only reason you might get portability problems is using hooking into native code (obviously), or using platform-specific paths or environment variables. We have written many large Java systems here, and they have been moved between Linux, Solaris and Windows with no problem. We only use the Sun virtual machine, though others (such as the one by IBM) have a very good track record of compatibility since the VM spec is very complete, and there are huge compatibility suites used to test them.
The only thing I can imagine that has problems is something based on GNU Classpath, but that is probably more due to the fact that it is an rather incomplete implementation.
I can’t imagine you should have any troubles using Java – even with a nice looking GUI. Just make sure you use Sun’s Java version 1.5.
The standard javax.comm package allows accessing serial devices in Java. This does require bindings for the serial ports on each platform, but these exist for all the major platforms (certainly MacOS, Windows, Linux, Solaris that I know of).
Of course, you could just do it in C. But at least in Java it means you should only need to test it on one (two if you are worried about it) platforms.