Mac68k Forums

In theory, yes it can be placed in ROM. I spent some time attempting to do so a while back, and had some trouble. It's a little complicated since it chains off the serial drivers, which are loaded later in the boot process than most other drivers. That just needed some rearrangement of the code (I took the SERD driver loading, moved it into the disabled RAM test area, added the load of the serial disk driver afterwards, and then returned). The driver its self would probably need some minor changes as well. Currently the driver uses a VBL task to poll for a disk image periodically, and then mount it when found. For booting, the server and disk image would need to be found synchronously in order to ensure it is ready to go by the time the system boots. So it's a slightly different operating model.

In regards to overclocking the serial port: somewhere around here I have a few of the Farallon Localtalk-Ethernet adapters that do this. Would analyzing them help at all?

landonf, do you think your AVR code could be ported to the *duino platform as a library without too much effort? There are shields available for SD cards and adding a serial interface would be fairly straightforward. It might make obtaining the HW a little more accessible.

I've got the serial disk driver integrated into the IIsi ROM, and can boot from it. It's not a floppy or a slot or a SCSI device, so it can't be selected as a default boot device, which essentially means if you have a boot device set in PRAM, the serial disk will never be booted. If there is no boot device set in PRAM, the system just traverses the drive queue looking for a bootable disk, so it's entirely dependent on the order of drives in the drive queue. The driver is still kicking off the requests to the server asynchronously, so it's a bit non-deterministic when the server is found and the drive is responsive. What this means is, if you have the serial server up and running so it can be found immediately, the serial disk will boot if you've got no SCSI drive, or if your SCSI drive is slow at spinning up.

The serial disk driver is placed where the .ATBOOT driver lives, and the .ATBOOT driver has been renamed .SerDsk. To get the driver loaded and opened, I relocated the code that populates the WarmStart global variable, added the following code, and replaced the WarmStart with a jsr to the relocated/added code. The new code is added after the added color happymac code in what used to be the memory test routine.

dc.w $21FC
dc.w $574C
dc.w $5343
dc.w $0CFC
sub #$32, a7 ; allocate a parameter block on the stack
move.l a7, a0
clr.b $1b(a0) ; clear out IOPermssn
lea serdiskname, a1
move.l a1, $12(a0) ; load the ioFileName
dc.w $A000  ; _Open
cmp #0, d0
beq done      ; If _Open failed, stay here, for debugging purposes
loop:
bra loop
done:
add #$32, a7 ; deallocate parameter block
rts
 
serdiskname:
dc.b $07
dc.b ".SerDsk"

Here is the ROM image. It includes the rom disk for 8MB rom simms, color happy mac, and all the other goodies.

Remember, with this ROM, the modem port will always be in use by the serial disk. If you attach a serial cable and serial server at any time after boot, it should pop up with the serial disk after a couple seconds.

I was going to use serialdisk just for storage anyway. its a really dirt cheap and albeit slow way to access an SD card at least

would be kind of handy to have a serial ethernet driver. lol. Well, i know they make serial based WiFi devices, such as the RN171 wiFly module, etc... which is wifi over serial, you can establish DHCP, UDP and TCPIP links directly in the module and open a socket inside the module, from there, the datapath is serial, its up to the client to parse the data comming from the port, which would be raw HTTP or FTP or etc.

Yeah, at the moment I think everyone is connecting to modern systems for the server side. For cabling, I've mostly been using existing cables, like modem cables. One little hiccup is for the earlier macs with the DE9 serial ports, the ImageWriter I cable looks like it'll work, but most of those cables don't have tx hooked up, since the communication to the ImageWriter I was unidirectional.

The main thing that's preventing this project from being generally useful IMO, is there's no checksumming of the data, so things can go sideways fairly easily. Adding it has been on my todo for a while now...
The other thing I wanted to do was separate the disk driver from the serial protocol, and have a serial muxing driver that allowed more than just disk accesses over the serial protocol. Being able to have multiple logical endpoints over the serial link, and have both disk and ethernet (for instance) over the serial port would be pretty useful I think. Especially when connected to a raspberry pi or something you can just slap on the back of the machine.