(This is part four of the chronicle of my 2014 Retrochallenge Winter Warmup submission. The mediocrity starts here.)
And Back Again.
Last weekend I was successful in transferring a physical floppy diskette to a .DSK disk image file on the USB thumb drive mounted to the A2MP3 card in my Apple II. To complete the challenge, I also wanted to make the return trip work, too. That is, to transfer a .DSK disk image file found on the USB thumb drive to a physical floppy diskette.
If you would’ve asked me, I would’ve bet good wages that I’d have this working in a day or so. However, most of the week has been instead spent butting my head against the wall fighting silly mistakes.
The French and Endian War
When reading the disk image data and comparing it to what was being written to the floppy, I became convinced the VMusic2 MP3 encoder was sending the bytes as Big Endian 16-Bit words and I needed to swap the byte order to restore it to a stream of single bytes.
1) when peeking at the USB-sourced disk image data being read in the Apple II’s memory, it looked like this:
<START>$44 $01 $a5 $27 $c9 $09 $d0 $18 $a5 ...
2) when examining a disk image file under Linux, the first few bytes looked like this:
$ hexdump -x A2MP3XFR.DSK | head 0000000 a501 c927 d009 a518 ...
So besides the spurious ‘D’ ($44) at the beginning of the stream in the Apple II’s memory, I concluded the Apple II program was receiving bytes from the VMusic2 controller in a slightly jumbled order. And I spent days fighting this.
Then yesterday, in an act as desperate as a trapped miner banging a pipe, I happened to run this command:
$ echo "ABCDE" | hexdump -xc 0000000 4241 4443 0a45 0000000 A B C D E n
What the what? This shows the hexdump command was the one guilty of transposing bytes.
Hold on. I need to compose a letter….
Dear hexdump authors,
I hate you.
Spurious D and the Pick of Destiny
Now that the byte order problem had been un-solved, next was to get rid of that 0x44 appearing at the head of the data streamed from the VMusic2 controller. I won’t go through all the failed solutions, but I eventually found a way to skip the D. And I had my first successful USB to physical floppy transfer – and life was grand.
In my moment of elation, I went through all the functions that the program currently performs: A) this week’s Transferring from USB to floppy, Yea!, B) this week’s Formatting a blank floppy, Yea!, C) last week’s Transferring from floppy to USB, What? (From observing the blinking lights, activity was normal about 1/6th of the transfer and then the little flicker normally seen when a file is being closed. Then USB activity ceased).
In my focus on getting the USB to floppy feature working, I had not tested the floppy to USB function in many days. What had I done to break it? I had made so many changes for the red-herring byte transposing.
In the end, it was indeed the changes regarding the Spurious D that was causing the new problems. An option (SKIPREAD) was added so that, when needed, a command sent to the VMusic2 controller would not always jump immediately to the code that read the VMusic2’s response.
Stick a Fork in It
So, now that the program is able to successfully transfer disk images to and from physical floppies, I am happy with its current state and declare “Success!”.
A video to follow.