SerialDisk Fun and a question.

[BitWiz]

I've been having some fun with my Serial Disk Raspberry Pi.

I modified the software to use 3 GPIOs for an RGB LED.

Here is a video of my Serial Disk Tardis with LEDs.

Blue = Waiting for Commands (2Hz, 50% duty cycle)
Green = Sending data to the PDP-8
Red = Receiving data from the PDP-8.

Google Drive: Sign-in

Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

drive.google.com

You will be able to see it live at the VCF Midwest Fair next month.

And now for the question.

I know that currently serial disk used RK05 images to be compatible with SIMH and several utilities to create those images.

However, the RK05 is only about 3/4 of what OS/8 can handle on a single volume. Each 1/2 RK05 (one OS/8 device) is 3,232 sectors (256 words).

However OS/8 can handle 4096 sectors (256 words). That means that we could add 864 more sectors to our image. That's 221,184 Words (331.776 bytes). Since Serial Disk allows for 8 images this could add 1,768,472 more words (2,654,208 bytes) of online storage.

I am suggesting that we add support for this as an option to Serial Disk.

Modifying the C code is simple enough for me to do. However, I really don't understand how the OS/8 device drivers are structured.

I presume that modifying the utilities to build the images would not be all that difficult to modify once i understand how OS/8 Device Drivers and Drive Formats are structured.

What do you guys think, is this worth the effort?

How difficult would it be to modify the OS/8 drivers and the image building utilities?

Thanks,

Mike

 

[vrs42]

I am suggesting that we add support for this as an option to Serial Disk.

Console Serial Disk implements full size disks. It also implements various other (RK05, TU56) size devices, so you can attach legacy images. (I think you get only one volume of each legacy size, currently.)

I think the original intent with SerialDisk was to provide access to existing content, so making the volumes look like RK05 volumes made sense. Most of the extant volumes were/are RK05 images.

There are a number of OS/8 utilities that know volume sizes and are moderately hard to tweak for larger devices.

The Perl scripts for manipulating images aren't too hard to tweak. The rules for determining what you are looking at get much harder with more choices, though. (Already the tools can get it wrong because SIMH frequently undersizes images it writes.)

 

[antiquekid3]

I think the original intent with SerialDisk was to provide access to existing content, so making the volumes look like RK05 volumes made sense. Most of the extant volumes were/are RK05 images.

Vince is correct. In my normal usage, I've never wanted for more space on a single disk image. I just load another disk image and use that. But sure, the handler would be easy to modify to support more per volume if you wish—this is, of course, left as an exercise to the reader. No, seriously, learning the inside of OS/8 is very rewarding, and Doug has written a delightful document detailing device drivers. If you have not already read it, I encourage you to execute 7402 and give it a read.

 

[BitWiz]

I was thinking of different OS/8 Drivers for different RK05 or Full size volumes if a single driver can't handle 2 sizes.

I believe that OS/8 does everything by absolute sector starting with the header, then the directory and then the files. I don't know if different size volumes have different size directories.

 

[BitWiz]

Vince is correct. In my normal usage, I've never wanted for more space on a single disk image. I just load another disk image and use that. But sure, the handler would be easy to modify to support more per volume if you wish—this is, of course, left as an exercise to the reader. No, seriously, learning the inside of OS/8 is very rewarding, and Doug has written a delightful document detailing device drivers. If you have not already read it, I encourage you to execute 7402 and give it a read.

Where can I find Doug's incredible documents?

 

[antiquekid3]

He linked it in one of your previous threads here: https://forum.vcfed.org/index.php?threads/serial-disk-questions.1244104/post-1329431

 

[DougIngraham]

However OS/8 can handle 4096 sectors (256 words). That means that we could add 864 more sectors to our image. That's 221,184 Words (331.776 bytes). Since Serial Disk allows for 8 images this could add 1,768,472 more words (2,654,208 bytes) of online storage.

Actually OS/8 can't do 4096, it can only do 4095 and this number is documented in a couple of places. With some effort they could have allowed a size of 0 to represent 4096 but that would have required extra effort and I really don't fault the devs for this limitation.

What do you guys think, is this worth the effort?

I guess I thought it was worth the effort since I did this for console serial disk.

How difficult would it be to modify the OS/8 drivers and the image building utilities?

The only thing that I found that needed any patching was PIP. And it is documented how to do this in the OS/8 stuff.

Where can I find Doug's incredible documents?

I've posted a link several times. It is a pointer to the google docs document. Feel free to export in your preferred format although it is still a work in progress.

OS/8 handler info

This is all the stuff I wanted to know back in the summer of 1975 when I wrote a handler. Hopefully it is easier to understand than the DEC documentation and it is all in one place with a table of contents.

The Console serial disk currently on github (v1.1) supports two devices in the system handler. SYS: which is also known as CSD0: and CSD1: while the non system handler supports CSD0:, CSD1:, CSD2:, CSD3:, RKA:, RKB:, and DTA:. The RKA, RKB, and DTA names were chosen so that they don't conflict with the real device names in case you happen to actually have those devices on your machine. It is trivial in the server to add more CSD devices but I felt four were enough as this is a lot of space. There is little point in mounting more than one of each kind of virtual image so just one RK05 (or regular serial disk) and DECtape image are allowed. BUILD has limitations on the number of handlers and OS/8 has limits on how much stuff you can have loaded so you kind of have to self police or you will have a real mess. I will be adding support for RX01 and RX02 images and for RL01 and RL02 to the non-sys handler at some point. I will also add TTY: to the handler since it is a natural addition. Vince or Kyle asked about adding linctape support and that should also be possible. Its should be easier than DECtape.