• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Requests for new software?

Dog Cow

Well-known member
I think first I'd like to try writing a disk transfer utility that will read a 400K floppy and stream it out the serial port. And maybe a function that does the reverse too.
I now have a working application that does this. I wrote it in assembly. It can send either an entire floppy, or a selected file from the floppy. Next I'll add Disk Copy 4.2 format for sending whole disks, and MacBinary encoding for sending files.

Hope to have this application released closer to summer, but the basics as I said are working now.

 

Dog Cow

Well-known member
What does the receiving machine need?
Just some way to receive the data and store it to disk. I'm using goSerial on OS X. It has a logging option to save all received data to a file. When I send a complete disk, it gets logged in the file. I change the file extension to .img, then I can mount it in mini vMac. It's not a Disk Copy 4.2 image, but it still works in mini vMac because all the essential disk data is still there.

I was thinking more about how to transmit a disk in Disk Copy 4.2 format this morning. At first I thought it would be a piece of cake, because I could capture all the tag bytes in a 9,600 byte buffer on the Mac, and then transmit them following the disk data. But then I remembered that there is a data and tag checksum at the head of the Disk Copy 4.2 file... so that's going to be troublesome. I can't compute the checksums until I have read the entire disk.

Probably I will have to send Disk Copy 4.2 images with no checksum. After transfer, you could run a small utility on the receiving machine to generate and insert the checksum. The sending Mac can compute the checksum too, and display it on screen, so you could enter it manually if desired.

Going the opposite way, receiving a Disk Copy 4.2 image and writing it to disk, should be somewhat easier.

 
Last edited by a moderator:

LaPorta

Well-known member
You know, sounds like a dumb question, but...what exactly is the checksum and how is it generated?

 

Dog Cow

Well-known member
what exactly is the checksum and how is it generated?
It's a way to validate the data. In it's a simplest form, it's merely a summation of all data bytes. If you run a checksum on the data, and it doesn't match the checksum that was provided to you, then there may be an error in the data. 

The checksum algorithm is to start at 0, add the next 2 bytes of disk data, then rotate the 32 bit result right by 1 bit. Repeat until finished.

 

Dog Cow

Well-known member
Will you release the source? I'd be very interested to look at it.
I don't know yet. I'm not happy with how the code is presently designed, and I plan to refactor it at some point. There are other issues to resolve too. One is that I'm presently using the ROM serial driver, but I should probably switch to using the RAM serial driver at some point, because there are some bugs in the 64K ROM.

Another decision to make is whether I should support non-Macintosh disks. Right now, the application will transmit any disk that the Sony driver can read. This includes Apple Lisa formatted disks and Apple IIgs ProDOS disks. But if I limit the application just to Macintosh disks, I can greatly simplify some parts of the code. It will make sending and receiving Disk Copy 4.2 format images easier too.

If I get too carried away, I could easily end up reinventing the entire Disk Copy 4.2 application, with an added feature of sending and receiving disk images over the serial port. 8-o

(By the way, Disk Copy installs a custom version of the Sony Disk Driver. This driver is in ROM in the Macintosh IIci and newer machines. If I end up writing my own disk driver, then I know I've gone too far!!!!)

 
Last edited by a moderator:
Top