Re: [Simh] Write sector headers to disk
Rob Doyle wrote: > One thought that should help: SIMH stores 36-bit data inside a 64-bit > data word. There is plenty of unused whitespace inside the existing disk > image. There is no reason for an incompatible change. Of course! Thank you. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
Johnny Billquist wrote: > The fourth option is to treat this as a normal write. Essentially, > unless I remember wrong, that is pretty much the end result on real > hardware. Agreed. If SIMH was updated to do this, I think SALV would be 99% happy. > I've played with a few disks back in the day that could write the > headers as well as read them, but there were no ability to store > arbitrary data there, so what would be returned on a read headers > could be computed when needed. I'm using the term "key field" as documented here: http://www.bitsavers.org/www.computer.museum.uq.edu.au/pdf/EK-RP04-MM-001%20RP04%20Device%20Control%20Logic%20Maintenance%20Manual.pdf See e.g. page 2-37. The header consists of five 16-bit words: cylinder and format, sector and track, key field #1, key field #2, and CRC. The key fields are arbitrary data under software control. I don't know if this applies to the RP06. SALV does write information to the key fields, but it seems the data isn't very important. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Interconnect Task Force
> RC25 ... Thanks, but I was more interested in the details of LESI if they are available. LESI was another mass storage "bus" that supported both disk and tape (albeit with exactly one example of each). RC25s never worked which, if you had an 11/725, was sad :( Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Rolm 1602
My mistake entirely, I had no idea that such a thing existed but it certainly did and played some very important roles. I mistakenly assumed when Bob said that there was no documentation that it could have been a failed experiment. -Henry On Tue, Jun 25, 2019, 20:54 Al Kossow wrote: > > > On 6/25/19 5:49 PM, Henry Bent wrote: > > > Was it actually used in production > > yes > > https://en.wikipedia.org/wiki/ROLM > > we have one > > https://www.computerhistory.org/collections/catalog/102717964 > > there are youTube videos of it > > https://www.youtube.com/watch?v=XvUpfUj7pzA > > and there was a 1603 > > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Rolm 1602
On 6/25/19 5:49 PM, Henry Bent wrote: > Was it actually used in production yes https://en.wikipedia.org/wiki/ROLM we have one https://www.computerhistory.org/collections/catalog/102717964 there are youTube videos of it https://www.youtube.com/watch?v=XvUpfUj7pzA and there was a 1603 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Rolm 1602
On Tue, 25 Jun 2019 at 20:41, Bob Supnik wrote: > Rolm & Haas made a militarized Nova-compatible minicomputer called the > 1602 - a follow on to their 1601 Ruggednova system. It had an extended > instruction set. I know this because I found the listings for the PDP10 > based 1602 simulator in my attic tonight. I've never seen any other > documentation. > > I'm not sure this system adds anything to Nova lore, but if people are > interested, I can try to compile a "feature set" from the PDP10 > simulator code. > > /Bob > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh Was it actually used in production, or did it just exist in a simulator form? I can easily imagine a simulator for such a thing being written but not surviving past a failed bid process, so no hardware. -Henry ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Rolm 1602
Rolm & Haas made a militarized Nova-compatible minicomputer called the 1602 - a follow on to their 1601 Ruggednova system. It had an extended instruction set. I know this because I found the listings for the PDP10 based 1602 simulator in my attic tonight. I've never seen any other documentation. I'm not sure this system adds anything to Nova lore, but if people are interested, I can try to compile a "feature set" from the PDP10 simulator code. /Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Interconnect Task Force
> On Jun 25, 2019, at 7:42 PM, Bob Supnik wrote: > > The RC25 (code named Aztec) got started as I was leaving Storage Engineering. > ... > > The RC25 was pretty much a disaster, technically and financially, and the end > of the line for DEC's removable disk program. It was quite ugly, because you had two drives on one spindle. RSTS was told to support an RC25-only config, apparently for use in Royal Navy submarines (space constrained, obviously). The trouble is that removing the removable pack meant spinning down the system unit (boot drive). RSTS was never designed for that and would get very unhappy. We hacked this by basically putting a system freeze feature in that would let you freeze everything while the drive was off. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Read/write header in RP drives
I like Johnny's suggestion. 1. On write header, "eat" the two header words and then write normal data. 2. On read header, synthesize the two standard header words and then read the pack data. 3. On write check header, skip the first two (header) words and then do a normal write check. This is what the DECtape simulators do with Read All and Write All. This solution would work on the PDP11/VAX RPs as well. I also agree that the "white space" could be used to record the header information for 36b drives, but it would be safer to leave those bits as zeroes. If the upper 28b of simulated PDP10 memory ever held non-zero data, the CPU simulator would go off the rails, badly. And the solution would be unique to the PDP10 implementation. /Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Interconnect Task Force
The RC25 (code named Aztec) got started as I was leaving Storage Engineering. Mike Riggle, VP of Storage Advanced Development (and later Storage Engineering), recognized early on that to improve seek and rotational performance, disk diameters (14" for the RA8X series) had to shrink; 8" or 9" would be the next target. Mike wanted to do only sealed (Winchester) disks, but there was significant marketing pressure for a low-end removable disk to succeed the RK11, RK611, and RL11. Hence Aztec, later the RC25. LESI was, I believe, an attempt to cost-reduce the RA8X's radial disk interconnect while maintaining performance. The RC25 was pretty much a disaster, technically and financially, and the end of the line for DEC's removable disk program. Low end systems went with ST504-compatible 5.25" sealed disks (the RDXX family), while the high-end went with 8" or 9" RA9X series, which used the RA8X radial interconnect. ST504 was eventually replaced by SCSI (and later its clusterable proprietary variant, DSSI). /Bob On 6/25/2019 7:22 PM, Robert Armstrong wrote: Bob Supnik [b...@supnik.org] wrote: Ah, yes, the Interconnect Task Force. 1980, perhaps? Can you say anything about LESI, "Low End Storage Interconnect"? It was used by the RC25 and the TU81+ and, AFAIK, that's it. It never really went anywhere and there's basically no documentation on it that I've ever seen. I always wondered about the story behind that. Thanks, Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Interconnect Task Force (was: Origins of MSCP)
> Bob Supnik [b...@supnik.org] wrote: >Ah, yes, the Interconnect Task Force. 1980, perhaps? > Can you say anything about LESI, "Low End Storage Interconnect"? It was used by the RC25 and the TU81+ and, AFAIK, that's it. It never really went anywhere and there's basically no documentation on it that I've ever seen. I always wondered about the story behind that. Thanks, Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] The Interconnect Task Force (was: Origins of MSCP)
Ah, yes, the Interconnect Task Force. 1980, perhaps? All my engineering notebooks are entombed at the Computer History Museum now. CI - computer interconnect - realized in the passive "star coupler" and the CIxxx family of interfaces. BI - backplane interconnect - realized in the BIIC chips - used as the memory and IO bus in the 8200 and the IO bus in several further systems. Superseded by the XMI, which was the memory and IO bus of the VAX 6000 family and was later used as an IO bus. NI - network interconnect - Ethernet. Success! DI - device interconnect - intended as a low cost interconnect to devices - basically async serial. Really only used in the DECtape II implementation with its own simplified form of MSCP (Radial Serial Protocol). II - interchip interconnect. This went nowhere at the time. The Semi Group standardized much later on the CVAX pin bus as a defacto "II" and created a family of pin-compatible chips. The CVAX pin bus morphed from a memory-and-IO bus in CVAX to an IO-only bus in later chips. Chips in the "CVAX pin bus family" included the memory controller (CMCTL), the console chip (CSSC), the second-generation Ethernet control (SGEC), the DSSI controller (SHAC), and the Qbus interface (CQBIC). The last three were used across multiple generations; the CMCTL and CSSC were only used in CVAX systems. Superseded, in most senses, by PCI in the 1990s. About the only thing that was consistent in DEC's interconnect strategy was that one generation's memory and IO backplane interconnect became a pure IO backplane interconnect later. This was true of the Unibus, Qbus, BI, and XMI. Memory cards were easy to design and replace; IO controllers tended to live much longer. /Bob On 6/25/2019 1:33 PM, Paul Koning wrote: On Jun 25, 2019, at 11:43 AM, Bob Supnik wrote: True. My first assignment at DEC was managing the "New Disk Subsystem" (NDS) advanced development project, which led eventually to both the HSC50 and the UDA50. Among the goals of the project were 1. To move ECC correction off the host and into the disk subsystem, so that much more powerful and complex ECC codes could be used. 2. To move bad block replacement off the host and into the disk subsystem. 3. To provide a uniform software interface for radically different disk drives. 4. To abstract away all device geometry information. 5. To implement command queuing and to perform all performance optimization, particularly seek optimization, in the disk subsystem. #2 was only partially true in the UDA50 -- I remember an amazingly large body of code in RSTS for bad block replacement for the RA80 that's about 2000 lines of code -- roughly the same size as the rest of the MSCP driver. I remember MSCP as part of the larger "Interconnect Architecture" effort, which produced a range of "interconnects" some of which seemed to become real and some less so. There was the new peripheral bus (BI), the cluter interconnect (CI, computer interconnect) and one or two others. I vaguely remember II (Interchip Interconnect) -- did that become I2C, or something else, or nothing? And DI (device interconnect) ??? Also NI, which became Ethernet. And XI? I think we used that term in the networking group for the next generation high speed network. Gigaswitch? FDDI? Not sure. Part of the impression I had was that there was some overall concept unifying all this, but whether that was actually realistic is not clear. One place it showed up was in the Jupiter mainframe (which didn't happen), supposedly built around CI and NI as its connections to the outside world. There's also XMI, but that was a generation later as I recall. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
> 3. Store header words out of band somehow. Last in the image file? > In another file? Perhaps the same name as the disk file with a . (dot) in front for the header words. Ala Mac resource forks or NTFS alternate data streams. Since Unix has no structure to its files, so you have to use the file system hierarchy to represent that. I dislike hidden files in general, but I doubt much in SIMH would suffer if the .header file were to get left behind. It seems pretty ephemeral, except perhaps during a sequence of diagnostics. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov > On 25 Jun 2019, at 2:13:18 PM, simh-requ...@trailing-edge.com wrote: > > I'm wondering what your opinions are reagarding this? I see some options: > > 1. Do not change SIMH. Patch SALV to skip the verification. Obviously > this is quite quick and painless, but leaves me with a slightly > dissatisfied feeling. Some historical software isn't running properly. > > 2. Add header words to the disk image file. An incompatible change, but > should of course be optional. > > 3. Store header words out of band somehow. Last in the image file? > In another file? smime.p7s Description: S/MIME cryptographic signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Origins of MSCP
Thanks for that insight, Bob. I wasn't anywhere near DEC when this happened, but it do match my perceptions of the whole thing very well. MSCP was definitely an improvement on Massbus in pretty much every way. Possibly with the exception of if you wanted to throw together some small piece of code to just control the drive. MSCP always requires a bit more plumbing. But it is nice that I can still throw new drives onto my "old" RSX system, and with MSCP it just works, and I can use all the capacity of that new drive... Noone probably even dreamed of 8G drives on a PDP-11 back then... But it works fine. No changes to anything needed. Johnny On 2019-06-25 17:43, Bob Supnik wrote: True. My first assignment at DEC was managing the "New Disk Subsystem" (NDS) advanced development project, which led eventually to both the HSC50 and the UDA50. Among the goals of the project were 1. To move ECC correction off the host and into the disk subsystem, so that much more powerful and complex ECC codes could be used. 2. To move bad block replacement off the host and into the disk subsystem. 3. To provide a uniform software interface for radically different disk drives. 4. To abstract away all device geometry information. 5. To implement command queuing and to perform all performance optimization, particularly seek optimization, in the disk subsystem. From my recollection, the Massbus was actually regarded as the counterexample. First, the Massbus cables were massive and unwieldy; the radial drive interconnect for the RA-class drives were a direct reaction. Second, the Massbus exposed drive geometries, which made it impossible to implement a new disk type without a driver update; with MSCP, the subsystem reported capacities, and the operating system could set up a file structure accordingly... sometimes. What the two protocols had in common was standardizing the format of the software [register (Massbus) / packet (MSCP)] interface. All Massbus disks used the same register sets... except when they didn't (the RP/RM divergence). All MSCP disks used the same packet formats... except for errors. But it was a lot better than the "every disk is unique" nonsense. DG had a standardized disk interface from the get-go. /Bob On 6/25/2019 8:10 AM, simh-requ...@trailing-edge.com wrote: Message: 8 Date: Tue, 25 Jun 2019 08:10:08 -0400 From: Paul Koning To: Timothe Litt Cc: SIMH Subject: Re: [Simh] Limits on MSCP controllers Message-ID:<81262a49-f410-432c-8c00-4aa9ac585...@comcast.net> Content-Type: text/plain; charset=us-ascii On Jun 24, 2019, at 5:27 PM, Timothe Litt wrote: As is often the case, things turn out to be complicated. Here's a more detailed version. In an off-list note, Bob pointed out that MSCP originated in a project he managed that was to develop the "next generation" disk controller - a forerunner of the UDA. ... However the similarities came to pass, I found viewing DSA as an evolved Massbus to be a useful model, with a lot of support for that perspective in the specifications. MSCP contains the high-level protocol of Massbus drivers (and much more) through the drive control logic/formatter. SI replaces the DCL/formatter to drive "bus" of Massbus -- SI is serial, ruggedized and capable of quite long runs. But it carries much the same low level drive commands. (Note that there's a long history of serializing parallel buses as technology evolves, e.g. PCI -> PCIe -> CSI, a.k.a. quickPath). The host ports (UQSSP,KLIPA,etc) replace the registers and DMA channels. Command and function names from Massbus spec & drivers often appear in the MSCP spec versions that I used... Very interesting. I never thought of MSCP as a descendant of earlier DEC storage architectures. Perhaps because all I really saw was what the UDA50 exposes, which from the programmer's point of view is radically different from, say, the RP04 or RK05. On the host ports and message based I/O, that same approach appears earlier in the KMC11 and its derivatives such as the DMC11 network controller. Were those an influence on the message based host port design? paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
On 2019-06-25 13:07, Lars Brinkhoff wrote: David Brownlee wrote: How about storing them only in memory - still an incomplete implementation, but should be enough to pass the SALV tests... I should clarify that to pass the tests, only the sector data needs to be written. Rather than ignored as now. SALV *also* uses the two key fields in the header words. Those are not part of the verification phase. I'm not yet sure to what extent the key fields are necessary or not. On a real disk, they are vital. The information there is used by the hardware to verify that the heads are on the right tracks, and the rotation is at the right sector before a transfer starts. But for a simulation, they are pretty much irrelevant. (Unless you want to start trying to emulate the physics and mechanical stuff of a disk drive.) 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
On 2019-06-25 10:32, Lars Brinkhoff wrote: Mark Pizzolato wrote: Is the data that is written in the headers by SALV predictable? It writes the sensible sector geometry information, so that's not a problem. It also writes the drive serial number to the first key field, and a user-specified pack number to the second key field. The pack number is entered before the pack is formatted. So essentially DEC144 format packs. Sounds good. Seems there is nothing except predictable information in the headers, so that part can actually be ignored. The operation just should write the normal data part as any other write, and be happy, and I believe things would be good. 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
On 2019-06-25 08:31, Lars Brinkhoff wrote: Hello, Some of DEC's disks allow reading and writing the sector headers. ITS' disk formatting program, SALV (the Salvager), uses this to make a new file structure on a pack, and to verify its integrity. This isn't fully supported by SIMH. The file PDP10/pdp10_rp.c has the comment "23-Aug-01 RMS Added read/write header stubs for ITS", and the stub is in "case FNC_WRITEH" in rp_svc. It's a no-op that just sets the DONE flag. What is supposed to happen is that SALV wants to write two header words with geometry information and then the sector data with a particular bit pattern. The verification phase reads back and checks the bit pattern. Since those bits aren't written, the verification fails. This isn't so bad since SALV offers to skip the verification. But now this has come up again using Rich Cornwell's upcoming KA10 addition to SIMH. The KA10 version of SALV does the same with an RP04 disk, but does not have the option to skip the verification. SALV also writes some information to the key fields in the headers, which is later read back. I'm wondering what your opinions are reagarding this? I see some options: 1. Do not change SIMH. Patch SALV to skip the verification. Obviously this is quite quick and painless, but leaves me with a slightly dissatisfied feeling. Some historical software isn't running properly. 2. Add header words to the disk image file. An incompatible change, but should of course be optional. 3. Store header words out of band somehow. Last in the image file? In another file? I understand the case for making changes to SIMH is quite weak if running SALV is the one and only use case. Are there any other programs that reads or writes the headers? The fourth option is to treat this as a normal write. Essentially, unless I remember wrong, that is pretty much the end result on real hardware. Yes, you rewrite the headers, but the headers are pretty much forced to look a certain way, and is not something software normally tries to read. But the headers have to be correct for the disk to be usable. Not all disks can even write down the headers in the field. But a write with headers also do a normal write, in addition to rewriteing/refreshing the headers. And I suspect all software beyond that point only expects that the written patterns in the data area are as expected after the write. Reading the headers out would essentially just become a question of verifying that the hardware works. I've played with a few disks back in the day that could write the headers as well as read them, but there were no ability to store arbitrary data there, so what would be returned on a read headers could be computed when needed. But maybe you are playing with some special disk that actually can store some amount of arbitrary data in the header? (The ones I think I looked at/played with are the RK05, RP06 and RP07.) 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Origins of MSCP
> On Jun 25, 2019, at 11:43 AM, Bob Supnik wrote: > > True. My first assignment at DEC was managing the "New Disk Subsystem" (NDS) > advanced development project, which led eventually to both the HSC50 and the > UDA50. Among the goals of the project were > > 1. To move ECC correction off the host and into the disk subsystem, so that > much more powerful and complex ECC codes could be used. > 2. To move bad block replacement off the host and into the disk subsystem. > 3. To provide a uniform software interface for radically different disk > drives. > 4. To abstract away all device geometry information. > 5. To implement command queuing and to perform all performance optimization, > particularly seek optimization, in the disk subsystem. #2 was only partially true in the UDA50 -- I remember an amazingly large body of code in RSTS for bad block replacement for the RA80 that's about 2000 lines of code -- roughly the same size as the rest of the MSCP driver. I remember MSCP as part of the larger "Interconnect Architecture" effort, which produced a range of "interconnects" some of which seemed to become real and some less so. There was the new peripheral bus (BI), the cluter interconnect (CI, computer interconnect) and one or two others. I vaguely remember II (Interchip Interconnect) -- did that become I2C, or something else, or nothing? And DI (device interconnect) ??? Also NI, which became Ethernet. And XI? I think we used that term in the networking group for the next generation high speed network. Gigaswitch? FDDI? Not sure. Part of the impression I had was that there was some overall concept unifying all this, but whether that was actually realistic is not clear. One place it showed up was in the Jupiter mainframe (which didn't happen), supposedly built around CI and NI as its connections to the outside world. There's also XMI, but that was a generation later as I recall. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
On 6/24/2019 11:31 PM, Lars Brinkhoff wrote: Hello, Some of DEC's disks allow reading and writing the sector headers. ITS' disk formatting program, SALV (the Salvager), uses this to make a new file structure on a pack, and to verify its integrity. This isn't fully supported by SIMH. The file PDP10/pdp10_rp.c has the comment "23-Aug-01 RMS Added read/write header stubs for ITS", and the stub is in "case FNC_WRITEH" in rp_svc. It's a no-op that just sets the DONE flag. What is supposed to happen is that SALV wants to write two header words with geometry information and then the sector data with a particular bit pattern. The verification phase reads back and checks the bit pattern. Since those bits aren't written, the verification fails. This isn't so bad since SALV offers to skip the verification. But now this has come up again using Rich Cornwell's upcoming KA10 addition to SIMH. The KA10 version of SALV does the same with an RP04 disk, but does not have the option to skip the verification. SALV also writes some information to the key fields in the headers, which is later read back. I'm wondering what your opinions are reagarding this? I see some options: 1. Do not change SIMH. Patch SALV to skip the verification. Obviously this is quite quick and painless, but leaves me with a slightly dissatisfied feeling. Some historical software isn't running properly. 2. Add header words to the disk image file. An incompatible change, but should of course be optional. 3. Store header words out of band somehow. Last in the image file? In another file? I understand the case for making changes to SIMH is quite weak if running SALV is the one and only use case. Are there any other programs that reads or writes the headers? I dealt this that issue a bit when I was writing the RP06 disk drive controller and disk emulator for the KS10 FPGA: a number of the RP06 diagnostics fail because they attempt to read/write to the sector header. One thought that should help: SIMH stores 36-bit data inside a 64-bit data word. There is plenty of unused whitespace inside the existing disk image. There is no reason for an incompatible change. In the end, I just used a (volatile) RAM buffer to store the sector header in the FPGA and that was good enough for the DSRPA diagnostic. Obviously, the contents of the sector header is not portable between disk types. In fact, the RP06 has a different sector header depending if the disk is formatted for 16-bit (PDP11) or 18-bits (PDP10). The other source of diagnostic failures involved the testing of the disk drive's Error Correcting Code (ECC) hardware. Funny enough, I picked a book (published by MIT Press in 1960) out of the trash at work a couple of months ago that fully described the "Fire Code" ECC of these disk drives. Maybe that will get revisited. Rob Doyle ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Origins of MSCP
True. My first assignment at DEC was managing the "New Disk Subsystem" (NDS) advanced development project, which led eventually to both the HSC50 and the UDA50. Among the goals of the project were 1. To move ECC correction off the host and into the disk subsystem, so that much more powerful and complex ECC codes could be used. 2. To move bad block replacement off the host and into the disk subsystem. 3. To provide a uniform software interface for radically different disk drives. 4. To abstract away all device geometry information. 5. To implement command queuing and to perform all performance optimization, particularly seek optimization, in the disk subsystem. From my recollection, the Massbus was actually regarded as the counterexample. First, the Massbus cables were massive and unwieldy; the radial drive interconnect for the RA-class drives were a direct reaction. Second, the Massbus exposed drive geometries, which made it impossible to implement a new disk type without a driver update; with MSCP, the subsystem reported capacities, and the operating system could set up a file structure accordingly... sometimes. What the two protocols had in common was standardizing the format of the software [register (Massbus) / packet (MSCP)] interface. All Massbus disks used the same register sets... except when they didn't (the RP/RM divergence). All MSCP disks used the same packet formats... except for errors. But it was a lot better than the "every disk is unique" nonsense. DG had a standardized disk interface from the get-go. /Bob On 6/25/2019 8:10 AM, simh-requ...@trailing-edge.com wrote: Message: 8 Date: Tue, 25 Jun 2019 08:10:08 -0400 From: Paul Koning To: Timothe Litt Cc: SIMH Subject: Re: [Simh] Limits on MSCP controllers Message-ID:<81262a49-f410-432c-8c00-4aa9ac585...@comcast.net> Content-Type: text/plain; charset=us-ascii On Jun 24, 2019, at 5:27 PM, Timothe Litt wrote: As is often the case, things turn out to be complicated. Here's a more detailed version. In an off-list note, Bob pointed out that MSCP originated in a project he managed that was to develop the "next generation" disk controller - a forerunner of the UDA. ... However the similarities came to pass, I found viewing DSA as an evolved Massbus to be a useful model, with a lot of support for that perspective in the specifications. MSCP contains the high-level protocol of Massbus drivers (and much more) through the drive control logic/formatter. SI replaces the DCL/formatter to drive "bus" of Massbus -- SI is serial, ruggedized and capable of quite long runs. But it carries much the same low level drive commands. (Note that there's a long history of serializing parallel buses as technology evolves, e.g. PCI -> PCIe -> CSI, a.k.a. quickPath). The host ports (UQSSP,KLIPA,etc) replace the registers and DMA channels. Command and function names from Massbus spec & drivers often appear in the MSCP spec versions that I used... Very interesting. I never thought of MSCP as a descendant of earlier DEC storage architectures. Perhaps because all I really saw was what the UDA50 exposes, which from the programmer's point of view is radically different from, say, the RP04 or RK05. On the host ports and message based I/O, that same approach appears earlier in the KMC11 and its derivatives such as the DMC11 network controller. Were those an influence on the message based host port design? paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
> On Jun 24, 2019, at 5:27 PM, Timothe Litt wrote: >> > As is often the case, things turn out to be complicated. Here's a more > detailed version. In an off-list note, Bob pointed out that MSCP originated > in a project he managed that was to develop the "next generation" disk > controller - a forerunner of the UDA. ... > However the similarities came to pass, I found viewing DSA as an evolved > Massbus to be a useful model, with a lot of support for that perspective in > the specifications. MSCP contains the high-level protocol of Massbus drivers > (and much more) through the drive control logic/formatter. SI replaces the > DCL/formatter to drive "bus" of Massbus -- SI is serial, ruggedized and > capable of quite long runs. But it carries much the same low level drive > commands. (Note that there's a long history of serializing parallel buses as > technology evolves, e.g. PCI -> PCIe -> CSI, a.k.a. quickPath). The host > ports (UQSSP,KLIPA,etc) replace the registers and DMA channels. Command and > function names from Massbus spec & drivers often appear in the MSCP spec > versions that I used... Very interesting. I never thought of MSCP as a descendant of earlier DEC storage architectures. Perhaps because all I really saw was what the UDA50 exposes, which from the programmer's point of view is radically different from, say, the RP04 or RK05. On the host ports and message based I/O, that same approach appears earlier in the KMC11 and its derivatives such as the DMC11 network controller. Were those an influence on the message based host port design? paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
David Brownlee wrote: > How about storing them only in memory - still an incomplete > implementation, but should be enough to pass the SALV tests... I should clarify that to pass the tests, only the sector data needs to be written. Rather than ignored as now. SALV *also* uses the two key fields in the header words. Those are not part of the verification phase. I'm not yet sure to what extent the key fields are necessary or not. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
On Tue, 25 Jun 2019 at 07:31, Lars Brinkhoff wrote: > > Hello, > > Some of DEC's disks allow reading and writing the sector headers. ITS' > disk formatting program, SALV (the Salvager), uses this to make a new > file structure on a pack, and to verify its integrity. > > This isn't fully supported by SIMH. The file PDP10/pdp10_rp.c has the > comment "23-Aug-01 RMS Added read/write header stubs for ITS", and the > stub is in "case FNC_WRITEH" in rp_svc. It's a no-op that just sets the > DONE flag. > > What is supposed to happen is that SALV wants to write two header words > with geometry information and then the sector data with a particular bit > pattern. The verification phase reads back and checks the bit pattern. > Since those bits aren't written, the verification fails. > > This isn't so bad since SALV offers to skip the verification. But now > this has come up again using Rich Cornwell's upcoming KA10 addition to > SIMH. The KA10 version of SALV does the same with an RP04 disk, but > does not have the option to skip the verification. SALV also writes > some information to the key fields in the headers, which is later read > back. > > I'm wondering what your opinions are reagarding this? I see some options: > > 1. Do not change SIMH. Patch SALV to skip the verification. Obviously > this is quite quick and painless, but leaves me with a slightly > dissatisfied feeling. Some historical software isn't running properly. > > 2. Add header words to the disk image file. An incompatible change, but > should of course be optional. > > 3. Store header words out of band somehow. Last in the image file? > In another file? > > I understand the case for making changes to SIMH is quite weak if > running SALV is the one and only use case. Are there any other programs > that reads or writes the headers? How about storing them only in memory - still an incomplete implementation, but should be enough to pass the SALV tests... Could always be extended to persist them later David ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Write sector headers to disk
Mark Pizzolato wrote: > Is the data that is written in the headers by SALV predictable? It writes the sensible sector geometry information, so that's not a problem. It also writes the drive serial number to the first key field, and a user-specified pack number to the second key field. The pack number is entered before the pack is formatted. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] [simh] Scrambled text in VAXStation 3100m38 GPX graphics screen
On 22/06/2019 20:21, paulhar...@btinternet.com wrote: > My suspicion is that it is memory trampling in the font caching > implementation in the emulated VCB02 device in SimH. The VCB02 device > uses the same memory planes for font caches as for screen bitmaps - > the manual says: > 1.6.1.1 Font Storage and Access Fonts are stored in an undisplayed portion of > the bitmap. Ordinarily, a font is stored only in one plane and is transmitted > from that plane to itself and > others when a character is written. Fonts are normally stored in the > off-screen portion of the VCB02 bitmap. > > Calling Matt Burke - can you spot anything odd in your implementation of this > aspect of the VCB02? > When I released the VCB02 I mentioned that there were known problems with VWS and UWS. Although DECwindows appeared OK with my testing it's not surprising that it's also affected. I hope to fix this eventually but it might not happen for a while as experience tells me it will take many hours to track this one down. Basically you have to enable debugging so that every drawing operating is logged then wait for the screen to get corrupted. You then need to count the exact pixel offset and size of the corrupted area. Next the debug log file (which is likely several gigabytes by this point) is searched to try and find the exact drawing operation that caused the corruption. Then the manual needs to be consulted to find out what subtle functionality was missed from the implementation. A change is made, which usually breaks something else and the cycle continues :) Matt ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Write sector headers to disk
Hello, Some of DEC's disks allow reading and writing the sector headers. ITS' disk formatting program, SALV (the Salvager), uses this to make a new file structure on a pack, and to verify its integrity. This isn't fully supported by SIMH. The file PDP10/pdp10_rp.c has the comment "23-Aug-01 RMS Added read/write header stubs for ITS", and the stub is in "case FNC_WRITEH" in rp_svc. It's a no-op that just sets the DONE flag. What is supposed to happen is that SALV wants to write two header words with geometry information and then the sector data with a particular bit pattern. The verification phase reads back and checks the bit pattern. Since those bits aren't written, the verification fails. This isn't so bad since SALV offers to skip the verification. But now this has come up again using Rich Cornwell's upcoming KA10 addition to SIMH. The KA10 version of SALV does the same with an RP04 disk, but does not have the option to skip the verification. SALV also writes some information to the key fields in the headers, which is later read back. I'm wondering what your opinions are reagarding this? I see some options: 1. Do not change SIMH. Patch SALV to skip the verification. Obviously this is quite quick and painless, but leaves me with a slightly dissatisfied feeling. Some historical software isn't running properly. 2. Add header words to the disk image file. An incompatible change, but should of course be optional. 3. Store header words out of band somehow. Last in the image file? In another file? I understand the case for making changes to SIMH is quite weak if running SALV is the one and only use case. Are there any other programs that reads or writes the headers? ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
