I forwarded this RL02 vs OS/8 question to Charles Lasner, his response follows the original question. [snip] [snip] ********** I can't guarantee this is the problem, but I do see a potential driver head count problem here: Let's start with the weirdness that is OS/8 RL support in the RL01: To support the RL01, there is a controller card jumper to set. I never found out EXACTLY what it does, but I can describe that constrained to the only rational answers. The RL02 has twice as many tracks to manually seek over [! Wonderful for real-time, since it doesn't interrupt! Ask the -11 people about creating RL seek-check tasks.] Thus, on the RL01 [which I suspect cannot be supported on the DECmate I's obscure RL278 spec'd for RL02 generally] you have to make sure that the proper bits get to the controller, which apparently can stupidly step an RL01 into never-never land if you let it. The programming is such that you create the signed difference between where you apparently are and where you want to be and send out a step the head over the direction indicated and number of steps. Thus, the arithmetic high-order bit has to become ignored. Thus, what the jumper does is obviously one of the following: 1) Ignore it; you only see the rest of the bits in the drive. I think this is least likely. 2) Set the bit to the same value as the one immediately to the right regardless of what the instruction says to do. This is a signed quantity because it could be a seek to lesser or further out as required, etc. In any case, this is an RL02 question, so we can table that factoid; I just want to know because it does mean that software could be then written to work with mixed situations of RL01 and RL02 on the same controller the way the -11 does it. Obviously they were told to make the bit being ignored/adjusted the correct value from the beginning; I think many knew the RL02 was not that far in the future when the RL01 was released, so their software designs were cognizant of the then future, etc. Unfortunately, it is a known quantity that much of the RL software is sloppy and can be counted upon to not be counted upon regardless of what the correct thing to do is, thus this stupid compatibility jumper, etc. [I never wrote a P?S/8 handler for it, thus I don't know. Moreover, OS/8's handlers are probably the most compromised for R-L devices; any actual correct performance with the switch off for RL01 would be a happy accident; no effort was expended to get it right; the jumper was known the exist. In P?S/8, I don't have the handler limitations, thus could get that right as well as a whole lot of other things; OS/8 is an awful kludge and incompatible with all other usages of RL01 and RL02, etc.] All that said, here is how you get it to work: First of all, not only do you have to perform a general formatting diagnostic that then builds a collection of bad block tables. [I believe there is a "factory" master table to never erase, and then some newer table to add in found-in-the-field more bad spots, etc.] All of that is done in an 8-bit orientation. To my knowledge, it is difficult at best to access this data in byte mode in one pass, so clearly 2:1 interleave is part of the design discussion regardless. In any case, it is the case of OS/8 using 12-bit mode. OS/8 cannot access the real bad block tables. Thus, there is an OS/8 crutch secondary program. The RL01 is divvied up into "wedges" of unequal size. Two larger ones and another one 1/2 the size of the other two. I have no idea how they account for this; in OS/8 PIP there is supposed to be a table where by internal logical device number you patch in the device size for directory zeroing purposes, etc. Thus, I guess the small wedgie is considered a different logical device despite it possibly being part of a same or similar non-system handler set [system handler too tight] with the same general I/O code just handling a different wedge of the disk, etc. They got something that is viable, but I am not sure; it could be examined assuming you have a system where PIP knows what to do certainly, etc. The wedges and the little wedgie are each evaluated. As a logical set of sectors in order to handle itself, there is a restriction that is pretty stupid: They insist that the very highest sector of the entire wedge/wedgie is error-free else OS/8 cannot use the pack! However, only the inner-most tracks are guaranteed error free from the factory because that's where the *REAL* bad block table[s] is/are. Expecting a block to actually be good when it is potentially in the main table[s] marked bad is preposterous, And I have heard of packs hand-picked to allow OS/8 family versions to like it because you must relegate it to something else that knows how to play with the bad blocks the way the big boys do, etc. So, assuming that risky situation is somehow OK, that becomes a twelve-bit-oriented record of the bad blocks in the format of which logical sectors of that wedge/wedgie are known bad. This little table is written in the highest logical record of the wedge/wedgie. No handler is maximum size because the table is reserving that last one assuming all are error-free. I would also suspect that there is no way to support it unless a few of the first of them [again, in this logical order of where in the wedge/wedgie they are, etc.] are known good. Certainly applies to the bootable system device one[s]. The handler proceeds to calculate the sector the caller is accessing. For all entries in the table prior to that desired logical record, the record that is ultimately used is bumped by one to "straddle" the bad spot. Thus, we now have the corrected logical record in the wedge/wedgie we want. Notice that this process has to be repeated for any sector in the call since your neighbor could be on the other side of the sinkhole so to speak. [I can see that physically adjacent sectors could all be bad, even with a 2:1 interleave; physically 3 or 4 in a row for example.] Then the handler converts that to the physicality of actual track/head/sector and does the intended read or write operation, etc. Go back and repeat all of the above as necessary from the original caller's marching orders, etc. The ordering of the sectors is through a 2:1 interleave obviously, but remember, all the wedges/wedgie that you don't "own" are in the way in the rotational latency sense. One revolution traverses all physical sectors, but you only get at best 1/2 wedge's forward progress [or worse, one half wedgie, again I mean the one that is 1/2 the size of the two larger ones.] Thus, the overall overhead is gross as the throughput is far less than implied by 2:1 interleave. [Historical note: Instead of playing with this crap when it was released, I was using the DSD-240/Western Dynex drive. 5 MB cartridges removable looking like RL disks superficially, but not servo-driven, rather a better mechanism than an RK05 that admittedly needed alignment but held it quite well. More importantly, it was over another 5.0 MB fixed disk. Thus, with some "Tower of Hanoi" juggling, you can completely back up everything on two 5 MB packs and it is damn fast. DMA with 1:1 interleave, all sectors addressed truly in physical order, a smart controller, no bad blocks whatsoever, smaller logical sectors so each transfer was one or more PDP-8-sized page blocks so completely at home in either P?S/8 or OS/8 with elegant and easy to write handlers for both systems. The command as well as the data are initiated by DMA and then it just does it automatically with a done and error status after-the-fact so low interrupt overhead, etc. In short, absolutely no problems whatsoever. [Note: Part of the concepts that implemented the DSD-240 were incorporated in the MDC8 guaranteed to be error free and delivering the promise; what a comparison between elegance and DEC's awful crap; this was well on the way more than merely the begiinning of the end; it was already part of the accelerating slide to eventual oblivion.] So much for the RL01. Note that gets you three handlers for the entirety of one disk with one handler's range 1/2 the size of the other two. That gets you three handler entries in BUILD if this is an RL01. But what of the RL02? Well, the wedgie is still smaller than the other two, but it doubles in size to be the equivalent on the RL02 of a wedge on an RL01. However, the RL02 wedges are twice the size that OS/8 can handle. Thus, an analogy to the RK8E/RK05 can be drawn. Each pack cannot be addressed with one handler; you need two of them each about 2/3-3/4 of the maxed-out OS/8 size. In this case we are talking about a superwedge that has to be logical cut in half as well, back to the equivalent of one RL01 wedge each. Thus, the RL02 gets you FIVE handlers all each addressing the same amount of physical space. would appear that there is potential anomaly there. The source code for the handler will reveal what BUILD is told about the device. Clearly that problem of logical device for PIP directory zeroing purposes goes away as they are all know the same logical size, just that there are more of them, thus there needs to be 5 build-oriented entries in these handlers as opposed to three as in the RL01 case. I suspect the confusion comes from there. Maybe you have some mixed RL01 and RL02 handlers confusing things, etc. P?S/8 has nearly NINE pages of code to handle system devices, as opposed to OS/8's only two where the first if a system handler is also not really a complete page with regard to code for the device as opposed to reserved locations "around" the handler code, etc. That concept applies pretty equally to both systems [but I think P?S/8 is slightly tighter.] The second page is actually not completely available either as the field 2 code reserves the last 4 words for OS/8 BATCH. [Come on, folks! The DS/8 people created what they called "HASP". Two attaboys to anyone who can explain the historical meaning of the name from an older non-DEC world. Houston, do we have a problem?] In any case, it got you a batch in 8K, so no reserved words and no 12K requirement at all, etc. And for those who may not have heard, P?S/8 BATCH is based on the original R-L Monitor System; both run BATCH in 4K!] But P?S/8 system handlers get EIGHT complete additional pages for their purposes alone. Clearly there is room to read the REAL bad-block tables and massage them as needed to allow sane bad-block handling. No wedge crutches, no dependency on iffy sectors, etc. As these packs age, I suspect OS/8-worthy ones will become less and less available physically. If you can honor the real tables, you can tolerate the true intended counts. In OS/8, I think each wedge/wedgie is limited to something like 16 total errors there, etc. In time, they will not be usable for the OS/8 kludge [admittedly eventually perhaps not usable at all!] ********** Hopefully some of this helps. I have a couple of RL02 drives that I'd like to try with my PDP-8/E one of these days. (Assuming that I can get an "-8"-formatted pack.) Bob