For attaching images, there's the "Attach Files/ Choose File" button at the bottom of the editing screen for new posts.
To make the image show up inline, you use exclamation points around the attached filename. So <!>mypicture.png<!> without the angle brackets.
I realized that I will probably never get this done if I try to do everything up-front, PCB design included, so I just ordered a basic SD-card breakout board from Sparkfun: https://www.sparkfun.com/products/11403
I can drop that in with my existing AVR work and wire up the sd card code.
The control panel part obviously doesn't work, so you can't select the baud rate. It loads at boot and is always active. Every couple seconds it'll try to look for a server and attach if one is found.
The only real changes to this are:
1) All references to StripAddress (instruction 0xA055) in the INIT and DRVR resource were changed to NOP (instruction 0x4E71) using a hex editor.
2) The file type was changed from 'cdev' to 'INIT' since pre-system6 doesn't know much about 'cdev' files.
The most difficult part was finding a working serial cable. I had tried the Imagewriter cable since the Apple KB on the cable says tx and rx are connected. However, trying both an official Apple cable from the era and this cable, I found the tx line is connected as per the KB, but the rx line is not. That didn't make it terribly useful.
However, once a suitable cable was located, all was well with the above INIT.
It occurs to me the main reason why 57.6kbps is safe on these older machines is the communication is synchronous (as in, the server will not send any data unless the host mac has asked for it, and then it will only have 1 outstanding request at a time), and there is not much going on while requests are outstanding.
In light of this, it might be reasonable to up the data rate on faster machines. It is my understanding that there is no driver call to enable faster data rates on machines before the AV macs, because it requires selecting not just a different clock divisor, but using an entirely different clock. I suspect if we open the driver, then bang on the SCC directly to setup the clock and data rate, the OS driver will work with the current setup.
This project is really cool. Is the protocol still as documented on page 1?
Let me explain my interest: I maintain the Mac drivers for MESS. We strictly emulate the actual chips in the actual machines as a philosophy. While this allows us to do fun things that would kill Basilisk like running 7.6.1 with virtual memory cranking or plugging 4 different video cards and an ethernet card into an emulated Mac IIx, it has the downside that our HDD images need to be complete volume images with the Apple partition map and disk driver and stuff. (Because we emulate the actual 5380 and 5394/96 SCSI chips and simulate a generic SCSI HDD at the other end of the SCSI bus). Most images you find around the Internet are bare HFS partitions because vMac and Basilisk patch out the .Sony driver (and in the case of Basilisk, everything else - I think by the time they're done patching you could run on an Amiga). We don't have that option because we have working IWM emulation.
Thus, if I optionally simulated that server it would give me the capability to mount those images without disturbing any of my actual h/w emulation.
Welcome, and I'm glad this can be useful to you.
The protocol should be the same as documented with an addition.
Command 4 is "eject". The current server exits when it gets this command, although that shouldn't really be necessary. After sending the eject command, the driver will go into a disconnected state and will poll the serial port for a server again using command 1 (Get Image Size). So if the server doesn't exit, it'll probably just remount the image.
FWIW, the server is super bare bones. You could probably pretty easily adapt it for your purposes.
I could be entirely out in left field with this, But can we make the serial disk put in ROM so we can boot from it? albeit slow, but it may work especially for machines like the duo without floppy drives, and dead HDDs.
Now of course, that would mean the ROM chips would have to be replaced and new ones hacked into place (SMD).
I fear though that it would require expansion of the protocol so the MAC could request a specific image to be mounted. such as "system.hfx". if not found/not blessed then dismount, unload the serial driver, and move on. or instead of system.hfx, make it a particular machine name. so before writing ROM, system.hfx could be changed to macse30.hfx or pbduo280.hfx or whatever. So multiple boots could technically be on the same SD card. I chose the hfx file becuase apple disk image IMG file i dont think are raw and i dont feel like handling the image header/etc in the AVR. id rather have a raw binary file. like a hardfile.