Notices by Vertigo (vertigo@mastodon.social), page 17

@Shamar I figured 9P would make a good intermediate protocol. It gives the remote device the option of exposing a raw block I/O end-point, a filesystem end-point, or perhaps both if it wanted.

What I haven't quite figured out yet is how to query for the number of concurrently open file references. I can foresee some external storage devices being implemented with Arduino-class hardware, for example, which has only limited amounts of RAM.

I'm perhaps getting ahead of myself.

@Shamar Cool. I am looking to port a clean subset (just exec and dos libraries) of AmigaOS to my home-brew computer to start with, but once I get memory management hardware implemented, I'd like to look into getting Plan 9 running on it. Was looking to port Harvey.

To make this easier, I'm explicitly not going to support native SD protocols anymore. Instead, like the Commodore machines, I want all my peripherals to be intelligent. UNLIKE Commodore, I don't want them to be too intelligent.

@Shamar For most tasks, you can also send commands via the filename to open as well:

OPEN 15,8,15,"S0:DeleteMe,S"

but this is an optimization. Normally, you use the filename with non-command channels to specify which file you want to read or write.

@Shamar Also, this existed at a time when most computers had a flat namespace, so the only hierarchy you had was, "Is file foo on device 8, 9, 10, or 11?" (GPIB devices were identified by physically assigned numbers.)

Otherwise, everything was message-passed.

OPEN 15,8,15 ' opens command channel to drive
PRINT #15, "S0:DeleteMe,S" ' delete the SEQ-uential file DeleteMe
INPUT #15, A, B$, C, D ' get disk status; blocks until it has data.
CLOSE 15

etc

@Shamar I think 1541 had a 4-file limitation (IIRC), while 1571 and 1581 had something closer to 16. Granted, with only 64KB of memory on-hand at any given time, this was (to my knowledge) virtually never actually a limitation in practice. But, if trying to encapsulate this architecture in a Unix-ish facade, it can very quickly become a limit as soon as you try to use your first shell pipeline.

@Shamar Other than the fact that nobody at Commodore realized what they actually had on their hands, and the C64 serial bus was horrifically slow, I can't think of any serious design side-effects.

Probably the biggest effect was dealing with limitations of multiple DOS versions at once. For instance, if you had a 1541 and 1571 disk drive attached to the computer, each drive ran a different version of Commodore DOS, so each could have a different number of concurrent files open, etc.

@Shamar I see, so instead of a simple non-zero = success return result, you return the timestamp of the object removed. I'm guessing this also requires a change to the 9P protocol to support that extra field as well?

@Shamar Curious -- why "delete" a file to get the current time, etc.? Why not just read a special file?

@Shamar Free-thinking here; but this reminds me of the old Commodore 8-bit computers, which relied on intelligent peripherals (e.g., where DOS runs on the peripheral, not on the host computer). Everything was done with message passing. On 8-bit Commodore machines, "everything is a GPIB device", which has only four system calls: open, close, read, and write. Even file creation, deletion, copying, etc. were all done with just those four primitives.

@Shamar Thanks.

In Plan 9, everything is a file as well; how does Jehanne differ in this interpretation?