New PDP-8 peripheral... interest?
van...@vsta.org
BTW, I have asked CJL about open sourcing his P?S/8 at some point. My guess
is that he's thinking about it, and (completely my own guess here) the energy
and time needed to pull it together into a solid form for general
distribution is as big a barrier as anything else.
Regards,
Andy Valencia
> Please ask around for people who would be interested in implementing a
> storage peripheral for the -8. Here is the gist of it:
>
> Instruction set is 12-bit console interface equivalent except of
> course two different device codes. Fully asynchronous in all
> directions. I have defined a protocol so that sending a "magic" value
> towards the serving end [which presumably has timed out all prior
> operations] realizes this is a new operation request. The protocol
> continues sending logical block information and word count
> information. The next depends on the transfer direction. Writes send
> 128x12-bit words times x where x=1 to 32 by prior arrangement. Reads
> the same thing except going in the opposite direction. IMO you need a
> dedicated micro to accomplish this, but am open to pure hardware
> solutions. Storage is to logical blocks linearly available on an up
> to 32GB flash drive. [I can dream, can't I. In any case flash
> drives that size are now available.] Most seem to want it started on
> green blocks to a legal positive buss peripheral, which can also work
> with a DW08B level convertor to a negative buss machine [straight-8]
> or KA8E to an Omnibus machine. Re-do to an Omnibus would be nice, but
> not the main mission. The actual buffer interface is 12-bits in and
> 12-bits out and the two done flags which are set and cleared in
> opposite directions. Totally asynchronous, so all you lose is
> performance, but forgives latency, etc. No interrupt structure really
> needed, but it would be welcome if it was also TTY:-line in terms of
> interrupts as well [meaning the done flags generate interrupts].
>
> I have already written the code for P?S/8 and OS/8 in minimum memory
> configurations [4K for P?S/8, 8K for OS/8] using the identical
> protocol. Removable flash drives means the data can be read on PCs,
> etc. with some home-grown utility programs there, etc.
>
> Please kick this around, and I'm sure parts of this seem like
> reinventing the wheel, but in point of fact the PDP-8 code already
> exists. [We built one of these between two -8s dual negative buss,
> years ago works fine. Most of the overhead was having daisy chained
> sockets for the 6 negative buss cables in and out and dual machines.
> Yes, 24 slots just for the cables! A positive buss machine would only
> need three in and three out for daisy chain. The logic is little more
> than IOT decoding and 24 total data flipflops. And then the thingie
> that has to do the work of being the data server that in turn supports
> the flash drive.
>
> cjl
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Johnny Billquist
fancy hardware at all? The only "special" being that it's 12 bits
parallel, plus some handshaking?
That will not be very good from a performance point of view, as well as
not being usable in any OS that is interrupt driven (well, usable, but
it will cause hiccups in user serviceablility while doing data transfers).
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
cjl
The whole point of the exercise is to make it easy to write handlers for the only operating systems that matter:
1) P?S/8 in 4K
2) OS/8 in 8K
Everything is totally irrelevant. The design is essentially a fully-symmetrical device 03/04 type interface except it is 12-bits wide.
As such it *IS* capable of being interrupt-driven for application-specific systems. The point is that if that all it did was what JB suggested, it wouldn't be USEFUL for any of that.
The beauty of a device like this is that it off-loads all the work to the "other" side which could be implemented in a variety of ways. The *existent* device is a dual-machine version. Either "end" can function as a "server" for the other end, the "client". I personally used this InterProcessorBuffer (IPB) so allow a LINC-8 to support DECtapes [on an -8/e] and for the -8/e to support LINCtapes; just reverse who has handlers and who has the same exact serving program.
The 12-bit data transfers mean the transfers are straight-forward with little cycles between the shoveled 12-bit words. A well-cached and buffered version of the device would literally be limited by how fast the data could be shoveled. Data transfers for dedicated routines such as are found in non-interrupt system handlers rivals the RK8E in terms of DMA rate equivalent.
More importantly, this device can be easily implemented for the negibus or the posibus with some clever level-converting interface adaptors. On the LINC-8 there literally is not even available a DMA channel as the LINC CPU "owns" it when running LINC-oriented programming. [The BREAK lamp on the front panel of machines usually running LAP-whatever is the first one to burn out.] The device is over an otder of magnitude faster than the LINCtapes, and the physicality of the storage could be both fast and also, relatively speaking, immense [by PDP-8 standards.]
Get past conventional short-sighted design illogic: If you need to have a real-time system, just design it so that the storage-device I/O is a background queue. Since all is asynchronous, there are no "hiccups* as erroneously suggested. If you use highly efficient coroutines to create a foreground task, then this can even be interrupt-driven with the LOWEST priority since it is often more important to not lose in the real-time sense, other data, while since this is all asynchronous, it would naturally be "forgiving" to occasional harmless derailment.
The basic idea is to initiate a pre-defined sequence to a waiting server program. Once what is negotiated is initiated, the data transfer occurs in very tight transfer loops. If the space is available, and speed is the only object, a data transfer can occur every other instruction if the device serving up the data can support a block-transfer mode. [Today's hardware can set the flag on every data word, but it can also be put into a flash-transfer mode so that every IOT instruction is a data transfer followed by a DCA I XR instruction.] For a straight PDP-8 that means data is moved twice as fast as an RK8E DMAs a transfer.]
For maximum asynchronousity, revert to the one-word-one-flag mode that is totally compatible with the notion of the console interface except 12-bits wide. Nothing gets lost, but admittedly the rate is now slightly slower because flags have to be tested. Such could could be background and not interrupt-enabled while interrupts are serviced for other devices. This is a common real-time mode for data acquisition; as long as the aggregate data transfer rate of the storage device exceeds the interrupt-driven data acquisition rate, all will work fine. [Note: I have had literally decades of experience making relatively high-speed PDP-8 data acquisition programs work. That this device would not use DMA is totally irrelevant.]
More importantly, in speaking with John Wilson, what is more important is that this can be practically implemented so that anyone who needs a really good peripheral storage unit for their PDP-8 can share in the cost to the point that it's a few bucks a head with reasonable cooperation. The target audience is anyone with a PDP-8 system that either has only say DECtape or LINCtape and wants a decent fast and large storage device, or more to the point, may just have a paper-tape system lacking the ability to run an O/S at all.
And even if 4K, P?S/8 can run on such a configuration; some machines it's hard to get 8K on the machine; if 8K or more is available, more choices exist, etc.
The handlers will not be compromised in any way that matters. The starting point on any of these designs is this: Can you write a system handler for it given the tight conventions of these systems and not resort to ugly kludges. [Admittedly the P?S/8 memory model is better than OS/8, but the best is always the one that doesn't require any "extra" memory.
Given the modern hardware approach to storage, formerly thought of as impossible storage can be easily achieved. So much so, that both P?S/8 and OS/8 are realistically too small to deal with it other than scratching the surface. This is part of why I am writing new software to take advantage of devices that are much larger than DEC ever produced; this is something that dwarfs the MDC8 SCSI project and that goes out to 64 MB.
OS/8 maxes a device at 1.0 MWord. That's 4096 records of 256 words each. It's also coincidentally the maxxed-out size of an RF08 system with 4 platters. But even an RK05 is larger than that so OS/8 has to divvy that up into two logical device handlers, each around 3/4 of the storage of the RF08 times four platters, etc.
Lets assume something likely true: 6-bit bytes are irrelevantly stored on the other end as 8-bit bytes. It can be easier to envision kilobytes, megabytes, gigabytes, terabytes, etc. Even in RX floppies, 12-bit mode is only using 12 out of 16 bits per word, etc.
Thus, a single maxxed-out OS/8 device is 2 MB. Because of OS/8's overhead of having handlers be needed for sundry things, the maximum of 15 I am cutting down to 8 to make comparisons easy.
Thus, the notion I will use is that OS/8 in any one build configuration maxxes out at 16 MB. [Note: On the MDC8, I have had P?S/8 and OS/8 co-exist on the same disk, and OS/8 having to have a gazillion BUILD.SV variants to configure the handlers to abandon some in favor of others to even gain access at all to parts of this "big" disk at 64 MB.
In classic bootable P?S/8, the system device is generally unit 0 of the handler and can address 4096 128-word blocks, 1/2 of what OS/8 can do, thus we will use 1 MB for each of them. However, the system handler addresses 8 logical units 0-7 so the scope of the handler is actually 8 MB. But we did say OS/8 would be double that, so so far, advantage OS/8 per se.
However, P?S/8 supports non-system handlers which are NOT call-compatible with the system handler. Various utilities already exist to access non-system handlers, and a large amount of code is being designed for the purpose of generalizing access through these handlers to more of what they can do.
The non-system handlers do address 128 word blocks, same as classic P?S/8. From a program design standpoint, this is far better: OS/8 requires everything to start from double-page buffers to read or write any device's logical record. The only valid sizes in terms of pages are 2 through 30, the even values only. The odd values cannot address the other "half" of the data, and 32 is disallowed due to the x7600-x7777 silly prohibition, etc. In P?S/8, all programs need only have a 128-word one page buffer at the entry level, and any and all increments to that are allowed up to and including 32 at a time if a field of memory is available to any program in terms of buffering.
This is why when P?S/8 BLKCPY detects there is 12K available, it copies one device to the other thus: read 32 blocks in, write 32 blocks out; read back the same blocks just written into another field of memory and compare the results. If they match, not only are there no handler errors, there are also no data compare errors because this is a verify-copy operation, etc. But in only 4K, it could work slower but at all even if all you have is a 1 page for in, 1 page for out, and one page for verify. Maybe those numbers can double, perhaps even triple in only 4K. Depends on the size of the calling program and the size of loaded non-system handlers to do it. But clearly, maximum flexibility is achieved when smaller entry levels and better granularity is available.
The block numbers in system handlers are single-precision thus getting the numbers above; however, the non-system handlers are double-precision. Thus, the scope of a single P?S/8 logical unit is 2048 times as large as the largest OS/8 device. And that's only one logical unit. Assuming a larger mapped storage device gets you 8 logical units, that makes that 16K times as big overall.
OK, we said use 8 such OS/8 handlers to cover a reasonable expectation of what OS/8 does in a "large" system. But P?S/8 has no magic limitation of only 15 devices. I think a good number should be 32 such handlers. If you do the math, we just got to 1 terabyte! 32 times 32 GB per handler group.
Now, I admit this is a theoretical upper limit. But we compared it to essentially the maximum OS/8 can deal with on any form of realistic basis. [Maybe I short-changed OS/8 by a factor of two, but this is MANY THOUSANDS of times larger. It's nice that any practical system only scratches the surface so to speak.]
So, getting back to the notion of only one such extended device. I think we are speaking to a nice size of modern storage hardware, backing store on a 32 GB flash drive. I think we are now talking about an interesting notion: Every PDP-8 with this device can likely hold the entire relevant history of the 12-bit computer past, present and future, including scanned-in manuals.]
Now, before you start calling me crazy, let's go a bit further. Assume the controller is also quite intelligent besides doing what we started with. How about the backing store is actually on a cheap PC? If a file system can store say an entire .JPG file, tell the controller by additional protocols to go display a file on its screen; PDP-8 overhead virtually nothing because I am speaking to extending the protocol to supporting the notion of complete file access and processing on that side of this handy-dandy peripheral. Poly Spacewar needs a music register to make cool audio effects when you fire the blasters. Why not emulate in through the interface. And how about something that while not a DMA device, still is somewhat "intelligent" in the style of the 338 buffered display. Imagine PDP-8 driven output on an external monitor [don't look at that little laptop toy inside of the cabinet!] [Note: This is not off-limits. The type 338 was a DMA-interfaced external graphics processor. It did all the work, and all the PDP-8 did was format out memory for the DMA to go do the display grunt work.]
So, to sum it up: A storage device that isn't imposing on PDP-8 conventions and traditions, embraces all the important operating systems, reasonable performance, and the cost is not all that much more than a cheap PC and an external monitor if you want to make it all look good. Likely the non-PDP-8 end of the intelligent controller looks like a USB 2.0 controller and the rest is support software to respond to IOT instructions in the PDP-8 based on the notion that the basic protocol is raw storage requests, but the sky's the limit on adding on frill features like playing PDP-8 videos once seen on Youtube. [And yes, this gets the PDP-8 onto the Internet if you are really clever.]
cjl