Re: [simh] RSTS processor identification
On 2021-03-08 15:40, Paul Koning wrote: On Mar 7, 2021, at 6:42 PM, Johnny Billquist wrote: On 2021-03-07 23:00, Paul Koning wrote: On Mar 5, 2021, at 9:02 PM, Johnny Billquist wrote: On 2021-03-06 02:33, Paul Koning wrote: ... Anyway, in RSX, when running DDCMP on the serial port, DECnet has its own device driver. So not talking through any terminal device driver, which have all kind of features and capabilities expected for a terminal line. Same with normal RSX, which is why you have to dedicate the whole controller to either DECnet or TT. You can't mix. That's probably more efficient. In RSTS I added the DDCMP support as an "auxiliary" function attached to the terminal driver, so the regular terminal driver does the device control and then diverts the data stream to/from the DDCMP driver. It's a bit like how Linux does these things, I forgot what term they use. In fact, it would be possible to add DDCMP support to Linux in the same way if someone wants to try that... :-) Definitely more efficient from a software point of view. Having two DHV11 in the machine, while only using 1 port on one of them, and couple on the other, might be considered less efficient from another point of view. ;-) You could, of course, have done it through the terminal driver in RSX, if you really wanted to. But I suspect they just felt the overhead wasn't attractive. I did SLIP in my TCP/IP going through the normal terminal driver. But with P/OS, you are not using the console port as such. That's all on the graphics side. But unless I'm confused, that's the same port. The printer port just can also be the console port, if you short pins 8-9, right? Except it won't fully work the same as the DL11, since interrupts work differently. But polled I/O will work the same. But I would expect the speed characteristics to be the same for the console as for the printer port. Correct, printer and console are actually the same thing. If you use the console cable (pin 8 connected to 9) then that materializes a DL11-like CSR set at 177560. Yes, with polled I/O such as the ODT microcode uses that works just like a real DL11, but for interrupts it's different. In RSTS, either way that port becomes a terminal port. RSTS does have support for the graphics module, in "glass TTY" mode within the initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode, and no bold in 132 column mode. Well, in P/OS you do have the option of also play graphics, and do different resolutions. But the "terminal" handling for it have similar limitations. I think blink isn't working the same as in a VT100, nor is reverse (if I remember correctly). And of course, smooth scrolling do not work you you don't scroll the whole screen, since the hardware isn't capable, and doing it in software would be way too slow. Right, I forgot about partial smooth scroll. Blink could be done fairly easily with EBO through the color lookup table; I haven't bothered doing that. Same for bold. Reverse wasn't a problem in my experience. That jogged my brain. It wasn't reverse that was a problem. Bold was where it could be a bit funny. Or possibly bold in combination with something (reverse?). The Pro would really have benefited from some hardware acceleration of the graphics. The PDP-11 wasn't exactly a speed daemon when it came to moving those pixels around... 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
Re: [simh] RSTS processor identification
> On Mar 5, 2021, at 9:02 PM, Johnny Billquist wrote: > > On 2021-03-06 02:33, Paul Koning wrote: > ... >> The explanation I heard for the slow J-11 clock is that the original J-11 >> spec called for it to operate at 20 MHz. When Harris failed to deliver and >> the max useable clock speed ended up to be 18 MHz, most designs had no >> trouble. But the Pro support chips were designed to run synchronous with >> the CPU clock and for various other reasons needed a clock frequency that's >> a multiple of 10 MHz, so when 20 MHz was ruled out that left 10 MHz as the >> only alternative. > > I do think it sounds weird that the support chips would require a clock that > is a multiple of 10 MHz. But I wouldn't know for sure. > Somewhere else I read/heard that they didn't work reliable above 10 MHz, but > for the F11 that was ok. When the -380 came, they just reused those support > chips. The 380 has an entirely different core design. Instead of lots of discrete support chips including a pile of screwball Intel chips, it uses a pair of gate arrays that incorporate all those functions. Or more precisely, the subset that the OS actually needs. This is really obvious when you compare the 350 and 380 documentation for the interrupt controllers -- the 350 uses Intel chips, the 380 only implements a tiny subset of what those chips do. I'm guessing here, but a possible reason for the 10 MHz issue is if the support chips use that clock, and use a synchronous design for the clock boundary crossing rather than an asynchronous design. It's entirely possible to design a chip that has an outside interface with an unrelated clock frequency, but it's harder to do and harder to get right. paul
Re: [simh] RSTS processor identification
> On Mar 5, 2021, at 9:15 PM, Chris Zach via cctalk > wrote: > >>> Can't run split I/D space on any version of P/OS. Neither does it support >>> supervisor mode. Also, the J11 on the Pro-380 is running a bit on the slow >>> side. Rather sad, but I guess they didn't want to improve the support chips >>> on the Pro, which limited speed, and they didn't want to start having Pro >>> software that didn't run on all models, which prevented the I/D space and >>> supervisor mode. > > That sucks. I sometimes wonder how hard it would be to code the hard disk > driver, if it doesn't do DMA it's probably simple as dirt to be honest. Any > idea if it worked like MCSP or was it totally off the wall? The Pro hard disk driver is indeed pretty simple. Nothing like DDCMP; it's more like an old style disk controller with CSRs to tell the device what to do. Basically, you convert linear sector number to cylinder/track/sector (which requires knowing the specific drive type), then load that into the CSRs along with a command. Then for a write operation you write the words of data, 256 of them, to the data buffer CSR. For a read, you wait for the data ready interrupt, then read the data one word at a time from that same CSR. Repeat for the next sector. The floppy is similar except that the transfer is byte-at-a-time, and the address mapping is more complicated because the software has to deal with the sector interleave, track skew, and funny cylinder numbering. An entirely different odd design is the Pro Ethernet card, which uses the evil 82568 Ethernet chip. That does DMA -- into a 64kW memory that's part of the DECNA card. So the OS would allocate Ethernet buffers to that memory space and can then do DMA. That's not too bad, and 64kW is a decent amount of memory. The real problem is that the 82568 is by far the worst DMA engine design ever created. It actually implements design errors that were well understood and well documented (and solved) 20 years earlier, but such considerations never stopped Intel. >> The most embarassing blunder with the Pro is that the bus supports DMA, but >> no I/O cards use it. Even though a bunch of them should have -- hard disk >> controller obviously, network adapter possibly as well. > > I think they used an intel chipset to handle the CTI bus, so the normal Q-Bus > DMA methods just doesn't work. Hm. Wonder if the problem is they just didn't > build the driver to support DMA, or if they found some problem that made DMA > just not work at all The documentation clearly describes DMA operation of the CT bus on both 350 and 380 (see the Technical Manual on Bitsavers). I don't know why it was never used, I never heard any rumors about it. I don't believe the bus control uses Intel chips. The interrupt controller does, yes, which is another bad design decision but one that can be worked around adequately. The Pro 380 implements only a subset of the full interrupt controller, the parts that aren't totally absurd. > The 380 *was* a mess, mine is a formidable bit of kit with DECNA and > everything, but without I/D space it's really not too very useful as more > than a really nice VT terminal. I/D space is just an OS issue; it works fine in the 380. As for a VT terminal, it's actually reasonably good at that but not great; the video can't quite do the full VT220 video. paul
Re: [simh] RSTS processor identification
> On Mar 7, 2021, at 6:42 PM, Johnny Billquist wrote: > > > > On 2021-03-07 23:00, Paul Koning wrote: >>> On Mar 5, 2021, at 9:02 PM, Johnny Billquist wrote: >>> >>> On 2021-03-06 02:33, Paul Koning wrote: > ... >>> I would have liked better comms. The USART has such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU. At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with reasonable FIFO. >>> >>> Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP >>> on HECnet for a while, and at 9600 bps. >> DDCMP runs fairly well on RSTS with the printer port at 9600, but I get some >> overruns. My guess is that the terminal driver (which is front ending the >> DDCMP machinery) isn't as lightweight as the equivalent on RSX. Or do you >> bypass the terminal driver and get a separate comms-specific driver for this >> case? > > I realized I might have spoken too soon. There is also a comm port, and now > I'm unsure if DECnet isn't running over that one actually. That would make a difference. The printer port is a 2661 on the Pro 350, or the gate array equivalent on the Pro 380. Either way, it's a UART without a FIFO. The comm port is an 8274, which has a 3 byte FIFO. So does the 2681 dual UART, which is what the 4 port comm card uses. In my tests, that FIFO makes the difference between running reliably at 9600 baud, and getting frequent overrun errors. > Anyway, in RSX, when running DDCMP on the serial port, DECnet has its own > device driver. So not talking through any terminal device driver, which have > all kind of features and capabilities expected for a terminal line. > > Same with normal RSX, which is why you have to dedicate the whole controller > to either DECnet or TT. You can't mix. That's probably more efficient. In RSTS I added the DDCMP support as an "auxiliary" function attached to the terminal driver, so the regular terminal driver does the device control and then diverts the data stream to/from the DDCMP driver. It's a bit like how Linux does these things, I forgot what term they use. In fact, it would be possible to add DDCMP support to Linux in the same way if someone wants to try that... :-) >>> But with P/OS, you are not using the console port as such. That's all on >>> the graphics side. >>> But unless I'm confused, that's the same port. The printer port just can >>> also be the console port, if you short pins 8-9, right? Except it won't >>> fully work the same as the DL11, since interrupts work differently. But >>> polled I/O will work the same. >>> But I would expect the speed characteristics to be the same for the console >>> as for the printer port. >> Correct, printer and console are actually the same thing. If you use the >> console cable (pin 8 connected to 9) then that materializes a DL11-like CSR >> set at 177560. Yes, with polled I/O such as the ODT microcode uses that >> works just like a real DL11, but for interrupts it's different. In RSTS, >> either way that port becomes a terminal port. >> RSTS does have support for the graphics module, in "glass TTY" mode within >> the initialization code and full VT220 emulation in RSTS proper. Well, >> except for blink mode, and no bold in 132 column mode. > > Well, in P/OS you do have the option of also play graphics, and do different > resolutions. But the "terminal" handling for it have similar limitations. I > think blink isn't working the same as in a VT100, nor is reverse (if I > remember correctly). And of course, smooth scrolling do not work you you > don't scroll the whole screen, since the hardware isn't capable, and doing it > in software would be way too slow. Right, I forgot about partial smooth scroll. Blink could be done fairly easily with EBO through the color lookup table; I haven't bothered doing that. Same for bold. Reverse wasn't a problem in my experience. paul
Re: [simh] RSTS processor identification
On 2021-03-07 23:00, Paul Koning wrote: On Mar 5, 2021, at 9:02 PM, Johnny Billquist wrote: On 2021-03-06 02:33, Paul Koning wrote: ... I would have liked better comms. The USART has such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU. At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with reasonable FIFO. Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP on HECnet for a while, and at 9600 bps. DDCMP runs fairly well on RSTS with the printer port at 9600, but I get some overruns. My guess is that the terminal driver (which is front ending the DDCMP machinery) isn't as lightweight as the equivalent on RSX. Or do you bypass the terminal driver and get a separate comms-specific driver for this case? I realized I might have spoken too soon. There is also a comm port, and now I'm unsure if DECnet isn't running over that one actually. Anyway, in RSX, when running DDCMP on the serial port, DECnet has its own device driver. So not talking through any terminal device driver, which have all kind of features and capabilities expected for a terminal line. Same with normal RSX, which is why you have to dedicate the whole controller to either DECnet or TT. You can't mix. But with P/OS, you are not using the console port as such. That's all on the graphics side. But unless I'm confused, that's the same port. The printer port just can also be the console port, if you short pins 8-9, right? Except it won't fully work the same as the DL11, since interrupts work differently. But polled I/O will work the same. But I would expect the speed characteristics to be the same for the console as for the printer port. Correct, printer and console are actually the same thing. If you use the console cable (pin 8 connected to 9) then that materializes a DL11-like CSR set at 177560. Yes, with polled I/O such as the ODT microcode uses that works just like a real DL11, but for interrupts it's different. In RSTS, either way that port becomes a terminal port. RSTS does have support for the graphics module, in "glass TTY" mode within the initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode, and no bold in 132 column mode. Well, in P/OS you do have the option of also play graphics, and do different resolutions. But the "terminal" handling for it have similar limitations. I think blink isn't working the same as in a VT100, nor is reverse (if I remember correctly). And of course, smooth scrolling do not work you you don't scroll the whole screen, since the hardware isn't capable, and doing it in software would be way too slow. There was even a window system available, which sortof reminds of Windows before 3.1. Played a little with it. It works, but it's a bit limited. But from the pure graphics point of view, it's nice. 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
Re: [simh] RSTS processor identification
> On Mar 5, 2021, at 9:02 PM, Johnny Billquist wrote: > > On 2021-03-06 02:33, Paul Koning wrote: >>> ... > >> I would have liked better comms. The USART has such a tiny FIFO that you >> can't run it at higher than 9600 bps even with the J-11 CPU. At least not >> with RSTS; perhaps a lighter weight OS can do better. The printer port is >> worse, that one can't run DDCMP reliably at more than 4800 bps. I normally >> run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual >> UART chips (2681?) with reasonable FIFO. > > Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP on > HECnet for a while, and at 9600 bps. DDCMP runs fairly well on RSTS with the printer port at 9600, but I get some overruns. My guess is that the terminal driver (which is front ending the DDCMP machinery) isn't as lightweight as the equivalent on RSX. Or do you bypass the terminal driver and get a separate comms-specific driver for this case? > But with P/OS, you are not using the console port as such. That's all on the > graphics side. > But unless I'm confused, that's the same port. The printer port just can also > be the console port, if you short pins 8-9, right? Except it won't fully work > the same as the DL11, since interrupts work differently. But polled I/O will > work the same. > But I would expect the speed characteristics to be the same for the console > as for the printer port. Correct, printer and console are actually the same thing. If you use the console cable (pin 8 connected to 9) then that materializes a DL11-like CSR set at 177560. Yes, with polled I/O such as the ODT microcode uses that works just like a real DL11, but for interrupts it's different. In RSTS, either way that port becomes a terminal port. RSTS does have support for the graphics module, in "glass TTY" mode within the initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode, and no bold in 132 column mode. paul
Re: [simh] RSTS processor identification
Johnny Billquist wrote: On 2021-03-06 02:33, Paul Koning wrote: The explanation I heard for the slow J-11 clock is that the original J-11 spec called for it to operate at 20 MHz. When Harris failed to deliver and the max useable clock speed ended up to be 18 MHz, most designs had no trouble. But the Pro support chips were designed to run synchronous with the CPU clock and for various other reasons needed a clock frequency that's a multiple of 10 MHz, so when 20 MHz was ruled out that left 10 MHz as the only alternative. I do think it sounds weird that the support chips would require a clock that is a multiple of 10 MHz. But I wouldn't know for sure. Somewhere else I read/heard that they didn't work reliable above 10 MHz, but for the F11 that was ok. When the -380 came, they just reused those support chips. The 6502 CPU in the BBC Micro operates at 2 MHz but periperals such as the 6522 Versatile Interface Adapters contain timers which only run at their expected speed when used with a 1 MHz clock. I wonder could it be that the Pro support chips would run ok at 18 MHz but there would have been difficulties with programming timers etc which are clocked at an odd speed? (The BBC Micro got around this problem by running the CPU at 2 MHz and stretching the clock cycle to 1 MHz when accessing the VIAs. The clock circuit is a real birds nest...) Regards, Peter Coghlan.
Re: [simh] RSTS processor identification
On Fri, Mar 5, 2021 at 7:05 PM Chris Zach via cctalk wrote: > > > There seem to be a great many models of Unibus and Qbus multi-port async > > serial boards, which present different register-level interfaces, e.g. for > > Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best", > > for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+? > > DHV11 is what you need for a lot of users: Bigger FIFO buffer for input, > DMA access to do a lot of characters in a few bus cycles, and oddly > enough intelligence to do things like automatically send XON and XOFF > without having to bother the CPU. Apparently you can send and receive on > all 8 channels at 9600 baud simultaneously which is pretty good. > And then isn't the M3107 DHQ11 slightly better than the M3104 DHV11? DHQ11 User Guide, EK-DHQ11-UG-002 The main application of the DHQ11 is for interactive terminal handling; it can also be used for data concentration and real-time processing. It has two programming modes, DHV11 and DHU11. The register sets in these modes are compatible with those of the DHV11 and DHU11 respectively. The preferred mode of operation is DHU11 mode. The main features of the DHQ11 are: For transmission: DMA transfers; or for each line, program transfers to a 1-character transmit buffer in DHV11 mode, or to a 64-character transmit FIFO in DHU11 mode. For receive: a 256-entry FIFO buffer for received characters, dataset status changes, and diagnostic information. (And also, the M3118 CXA16 and M3119 CXY08 are essentially equivalent to the M3107 DHQ11 from a software and performance point of view, but in S-handle card form factor?)
Re: [simh] RSTS processor identification
On 2021-03-06 03:22, Eric Smith wrote: On Fri, Mar 5, 2021 at 6:33 PM Paul Koning via cctalk mailto:cctalk@classiccmp.org>> wrote: I would have liked better comms. The USART has such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU. At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with reasonable FIFO. There seem to be a great many models of Unibus and Qbus multi-port async serial boards, which present different register-level interfaces, e.g. for Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best", for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+? In general, you should pick a controller that can do as much as possible with DMA. Which means DH11 or DHU11 for Unibus. Similar with Qbus: DHV11. 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
Re: [simh] RSTS processor identification
There seem to be a great many models of Unibus and Qbus multi-port async serial boards, which present different register-level interfaces, e.g. for Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best", for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+? Depends on your use case. The mighty DLV11 is nice, but it's interrupt driven so every time you shove a character out it takes bus cycles and every time a character comes in you have to drop what you're doing. The DLV11-J will run down your system if used for interactive users as it's 4 DLV11's. DZV is a step up, you at least have an incoming FIFO, can program the baud rates in software, and they can afford to buffer a bit. But a bunch of DZV11's can sink your bus as well, so you go to the DHV11. DHV11 is what you need for a lot of users: Bigger FIFO buffer for input, DMA access to do a lot of characters in a few bus cycles, and oddly enough intelligence to do things like automatically send XON and XOFF without having to bother the CPU. Apparently you can send and receive on all 8 channels at 9600 baud simultaneously which is pretty good. Going above this you start to get into the DMC11 type boards which have hardware support for DDCMP and the like. That's what you want if you're going to do DECNET Phase III over serial lines. You can do it with the other boards but the CPU is going to have to deal with the framing and whatnot. But by then you just do ethernet. C
Re: [simh] RSTS processor identification
On Fri, Mar 5, 2021 at 6:33 PM Paul Koning via cctalk wrote: > I would have liked better comms. The USART has such a tiny FIFO that you > can't run it at higher than 9600 bps even with the J-11 CPU. At least not > with RSTS; perhaps a lighter weight OS can do better. The printer port is > worse, that one can't run DDCMP reliably at more than 4800 bps. I normally > run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual > UART chips (2681?) with reasonable FIFO. > There seem to be a great many models of Unibus and Qbus multi-port async serial boards, which present different register-level interfaces, e.g. for Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best", for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+?
Re: [simh] RSTS processor identification
Can't run split I/D space on any version of P/OS. Neither does it support supervisor mode. Also, the J11 on the Pro-380 is running a bit on the slow side. Rather sad, but I guess they didn't want to improve the support chips on the Pro, which limited speed, and they didn't want to start having Pro software that didn't run on all models, which prevented the I/D space and supervisor mode. That sucks. I sometimes wonder how hard it would be to code the hard disk driver, if it doesn't do DMA it's probably simple as dirt to be honest. Any idea if it worked like MCSP or was it totally off the wall? The most embarassing blunder with the Pro is that the bus supports DMA, but no I/O cards use it. Even though a bunch of them should have -- hard disk controller obviously, network adapter possibly as well. I think they used an intel chipset to handle the CTI bus, so the normal Q-Bus DMA methods just doesn't work. Hm. Wonder if the problem is they just didn't build the driver to support DMA, or if they found some problem that made DMA just not work at all The 380 *was* a mess, mine is a formidable bit of kit with DECNA and everything, but without I/D space it's really not too very useful as more than a really nice VT terminal.
Re: [simh] RSTS processor identification
On 2021-03-06 02:33, Paul Koning wrote: On Mar 5, 2021, at 7:22 PM, Johnny Billquist via cctalk wrote: ... Maybe this weekend I'll hack that SSD floppy thingie and load up the P/OS 3.2 disks to see how that works. Can't run split I/D space on any version of P/OS. Neither does it support supervisor mode. Also, the J11 on the Pro-380 is running a bit on the slow side. Rather sad, but I guess they didn't want to improve the support chips on the Pro, which limited speed, and they didn't want to start having Pro software that didn't run on all models, which prevented the I/D space and supervisor mode. In the end I would probably just put it down to additional ways DEC themselves crippled the Pro, which otherwise could have been a much better machine. The most embarassing blunder with the Pro is that the bus supports DMA, but no I/O cards use it. Even though a bunch of them should have -- hard disk controller obviously, network adapter possibly as well. That's another good point about weird things about the Pro. I/D and supervisor mode work fine on RSTS. :-) Really? That's nice. I would have loved to try and build a version of the latest RSX for the Pro, but unfortunately the code for the disk controllers are missing for me. The handling of the screen and keyboard are still in the RSX sources. The explanation I heard for the slow J-11 clock is that the original J-11 spec called for it to operate at 20 MHz. When Harris failed to deliver and the max useable clock speed ended up to be 18 MHz, most designs had no trouble. But the Pro support chips were designed to run synchronous with the CPU clock and for various other reasons needed a clock frequency that's a multiple of 10 MHz, so when 20 MHz was ruled out that left 10 MHz as the only alternative. I do think it sounds weird that the support chips would require a clock that is a multiple of 10 MHz. But I wouldn't know for sure. Somewhere else I read/heard that they didn't work reliable above 10 MHz, but for the F11 that was ok. When the -380 came, they just reused those support chips. Also, no caches. The -380 could have been so much better... I would have liked better comms. The USART has such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU. At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with reasonable FIFO. Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP on HECnet for a while, and at 9600 bps. But with P/OS, you are not using the console port as such. That's all on the graphics side. But unless I'm confused, that's the same port. The printer port just can also be the console port, if you short pins 8-9, right? Except it won't fully work the same as the DL11, since interrupts work differently. But polled I/O will work the same. But I would expect the speed characteristics to be the same for the console as for the printer port. 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
Re: [simh] RSTS processor identification
> On Mar 5, 2021, at 7:22 PM, Johnny Billquist via cctalk > wrote: > > ... >> Maybe this weekend I'll hack that SSD floppy thingie and load up the P/OS >> 3.2 disks to see how that works. > > Can't run split I/D space on any version of P/OS. Neither does it support > supervisor mode. Also, the J11 on the Pro-380 is running a bit on the slow > side. Rather sad, but I guess they didn't want to improve the support chips > on the Pro, which limited speed, and they didn't want to start having Pro > software that didn't run on all models, which prevented the I/D space and > supervisor mode. > > In the end I would probably just put it down to additional ways DEC > themselves crippled the Pro, which otherwise could have been a much better > machine. The most embarassing blunder with the Pro is that the bus supports DMA, but no I/O cards use it. Even though a bunch of them should have -- hard disk controller obviously, network adapter possibly as well. I/D and supervisor mode work fine on RSTS. :-) The explanation I heard for the slow J-11 clock is that the original J-11 spec called for it to operate at 20 MHz. When Harris failed to deliver and the max useable clock speed ended up to be 18 MHz, most designs had no trouble. But the Pro support chips were designed to run synchronous with the CPU clock and for various other reasons needed a clock frequency that's a multiple of 10 MHz, so when 20 MHz was ruled out that left 10 MHz as the only alternative. I would have liked better comms. The USART has such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU. At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with reasonable FIFO. paul
Re: [simh] RSTS processor identification
On 2021-03-06 01:14, Chris Zach wrote: Ah ok. For some reason I always thought the 23 could only run M, which is still a fine platform. I'd be amazed if they got all the extra cool features like disk caching working without I/D. Officially, you need the 11/23+. The original 11/23 is not supported, since that only had 18-bit addressing. Disk caching and so on is not a problem. It takes some memory, but if you have 22-bit addressing, then it's just a question of grabbing some more of all that free memory you have. ;-) However, on machines without split I/D space, what you normally have problems with in M+ is that system pool is very small. You have to be rather careful what you do with the system. But that's the way it is. Both on the 11/23+ and the 11/24. But when I think about it, it makes sense: P/OS is basically M+ all the way and runs on the Pro/350. But P/OS 2.0 will not allow you to run split I/D applications on a 380 although you can compile them. Right. Maybe this weekend I'll hack that SSD floppy thingie and load up the P/OS 3.2 disks to see how that works. Can't run split I/D space on any version of P/OS. Neither does it support supervisor mode. Also, the J11 on the Pro-380 is running a bit on the slow side. Rather sad, but I guess they didn't want to improve the support chips on the Pro, which limited speed, and they didn't want to start having Pro software that didn't run on all models, which prevented the I/D space and supervisor mode. In the end I would probably just put it down to additional ways DEC themselves crippled the Pro, which otherwise could have been a much better machine. Johnny C On 3/5/2021 6:55 PM, Johnny Billquist wrote: The 11/23 is officially supported, and does indeed lack I/D space (also true of the 11/24). Which implies that split I/D space is not actually a requirement for RSX-11M-PLUS. That would also be clear by reading the SPD. However, officially, there is a requirement for 22-bit addressing. Which means that both 11/40 and 11/60 is not supported. However, it is possible to run RSX-11M-PLUS on those machines. But you need to enable unsupported builds in order to do a SYSGEN for those machines. Also, this means that actually the 11/45 is not officially supported, as opposed to the 11/24 which is... Johnny On 2021-03-06 00:11, Chris Zach wrote: How can you run m+ on an 11/23 or a 40? I thought it needed I/d space to run thus I can see it on a 45. On March 5, 2021 6:02:45 PM EST, Johnny Billquist via cctalk wrote: Nice writeup, Paul. And very interesting. Just in case anyone wonder about RSX, here is how it's done in M+: 1. Test if SYSID register exists If SYSID register exists: 2. Test if high bit of KISDR0 can be set and read back If high bit can be set and read back => 11/74 CPU If high bit cannot be set and read back => 11/70 CPU 3. Try MFPT instruction If that succeeds: If R0 == 1 => 11/44 CPU If R0 == 3: 4. Try to read maintenance register If register exists => XT CPU (Pro) 5. If register does not exist, try writing to SWR If fail to write => 11/23 CPU If succeed to write => 11/24 CPU If R0 is something else, it is a J11 CPU, see more below. 6. Execute OP-codes 076600,000400 If that succeeds => 11/60 CPU If that fails: 7. Execute OP-code 106700 If that succeeds => 11/34 CPU If that fails: 8. Try to read PIRQ register If that succeeds => 11/45 CPU If that fails: CPU is one of: 11-/04/05/10/15/20/40 M+ will just assume 11/40, since that is the only possible model that could possibly be running this code. => 11/40 CPU For J11 processors, after point 3, we get into a J11 probing. 9. If R0 <> 5, it is not a J11 processor after all. => Unknown CPU 10. Read maintenance register If fail => Unknown CPU 11. Check bits 4-7 of maintenance register: == 4: => 11/53 CPU == 3: => 11/73 CPU (not KDJ11) == 1: Write KISDR7+1 to KISDR7+1 Check if W bit in KISDR7 was set. If set => M11 CPU Try opcodes 076660,156227 If succeed => N11 CPU == 2: => 11/83 or 11/84 CPU (see step 12) == 5: => 11/93 or 11/94 CPU (see step 12) 12. Check if Unibus system based on maintenance register If Unibus system indicated, try read Unibus map register If Unibus map exist: => Unibus system. CPU 11/84 or 11/94 (see 11) 13. Qbus system. CPU 11/83 or 11/93 (see 11) Note: M11 processor is called 11/95 Note: N11 processor is called 11/97 That concludes how RSX-11M-PLUS decides what CPU you have at boot. There are then
Re: [simh] RSTS processor identification
Ah ok. For some reason I always thought the 23 could only run M, which is still a fine platform. I'd be amazed if they got all the extra cool features like disk caching working without I/D. But when I think about it, it makes sense: P/OS is basically M+ all the way and runs on the Pro/350. But P/OS 2.0 will not allow you to run split I/D applications on a 380 although you can compile them. Maybe this weekend I'll hack that SSD floppy thingie and load up the P/OS 3.2 disks to see how that works. C On 3/5/2021 6:55 PM, Johnny Billquist wrote: The 11/23 is officially supported, and does indeed lack I/D space (also true of the 11/24). Which implies that split I/D space is not actually a requirement for RSX-11M-PLUS. That would also be clear by reading the SPD. However, officially, there is a requirement for 22-bit addressing. Which means that both 11/40 and 11/60 is not supported. However, it is possible to run RSX-11M-PLUS on those machines. But you need to enable unsupported builds in order to do a SYSGEN for those machines. Also, this means that actually the 11/45 is not officially supported, as opposed to the 11/24 which is... Johnny On 2021-03-06 00:11, Chris Zach wrote: How can you run m+ on an 11/23 or a 40? I thought it needed I/d space to run thus I can see it on a 45. On March 5, 2021 6:02:45 PM EST, Johnny Billquist via cctalk wrote: Nice writeup, Paul. And very interesting. Just in case anyone wonder about RSX, here is how it's done in M+: 1. Test if SYSID register exists If SYSID register exists: 2. Test if high bit of KISDR0 can be set and read back If high bit can be set and read back => 11/74 CPU If high bit cannot be set and read back => 11/70 CPU 3. Try MFPT instruction If that succeeds: If R0 == 1 => 11/44 CPU If R0 == 3: 4. Try to read maintenance register If register exists => XT CPU (Pro) 5. If register does not exist, try writing to SWR If fail to write => 11/23 CPU If succeed to write => 11/24 CPU If R0 is something else, it is a J11 CPU, see more below. 6. Execute OP-codes 076600,000400 If that succeeds => 11/60 CPU If that fails: 7. Execute OP-code 106700 If that succeeds => 11/34 CPU If that fails: 8. Try to read PIRQ register If that succeeds => 11/45 CPU If that fails: CPU is one of: 11-/04/05/10/15/20/40 M+ will just assume 11/40, since that is the only possible model that could possibly be running this code. => 11/40 CPU For J11 processors, after point 3, we get into a J11 probing. 9. If R0 <> 5, it is not a J11 processor after all. => Unknown CPU 10. Read maintenance register If fail => Unknown CPU 11. Check bits 4-7 of maintenance register: == 4: => 11/53 CPU == 3: => 11/73 CPU (not KDJ11) == 1: Write KISDR7+1 to KISDR7+1 Check if W bit in KISDR7 was set. If set => M11 CPU Try opcodes 076660,156227 If succeed => N11 CPU == 2: => 11/83 or 11/84 CPU (see step 12) == 5: => 11/93 or 11/94 CPU (see step 12) 12. Check if Unibus system based on maintenance register If Unibus system indicated, try read Unibus map register If Unibus map exist: => Unibus system. CPU 11/84 or 11/94 (see 11) 13. Qbus system. CPU 11/83 or 11/93 (see 11) Note: M11 processor is called 11/95 Note: N11 processor is called 11/97 That concludes how RSX-11M-PLUS decides what CPU you have at boot. There are then probes for TOY, clock and memory, but that's a different story. If anyone wants more information, the code is in LB:[12,10]SAVSIZ.MAC, routine $STCPU. But I'm happy to also answer any questions. Also note that while doing these tests/probes, RSX is catching the illegal instruction trap, and just resumes execution but sets carry. So for some of these tests, the carry is cleared, and the instruction is attempted, and then there is a check if carry got set, as a way of seeing if it worked or not. The specific opcodes are for maintenance instructions that either are harmless on other models, or trap. And which do not affect the carry if executed on the assumed processor tested for. Non-existant memory is also trapped, and execution resumed with carry set. Same kind of idea... Johnny On 2021-03-05 19:38, Paul Koning wrote: I was just asked some questions about how RSTS identifies your processor type. Since that topic might be of broader interest I figured I'd do some code reading and summarize the logic. In the RSTS initialization code
Re: [simh] RSTS processor identification
The 11/23 is officially supported, and does indeed lack I/D space (also true of the 11/24). Which implies that split I/D space is not actually a requirement for RSX-11M-PLUS. That would also be clear by reading the SPD. However, officially, there is a requirement for 22-bit addressing. Which means that both 11/40 and 11/60 is not supported. However, it is possible to run RSX-11M-PLUS on those machines. But you need to enable unsupported builds in order to do a SYSGEN for those machines. Also, this means that actually the 11/45 is not officially supported, as opposed to the 11/24 which is... Johnny On 2021-03-06 00:11, Chris Zach wrote: How can you run m+ on an 11/23 or a 40? I thought it needed I/d space to run thus I can see it on a 45. On March 5, 2021 6:02:45 PM EST, Johnny Billquist via cctalk wrote: Nice writeup, Paul. And very interesting. Just in case anyone wonder about RSX, here is how it's done in M+: 1. Test if SYSID register exists If SYSID register exists: 2. Test if high bit of KISDR0 can be set and read back If high bit can be set and read back => 11/74 CPU If high bit cannot be set and read back => 11/70 CPU 3. Try MFPT instruction If that succeeds: If R0 == 1 => 11/44 CPU If R0 == 3: 4. Try to read maintenance register If register exists => XT CPU (Pro) 5. If register does not exist, try writing to SWR If fail to write => 11/23 CPU If succeed to write => 11/24 CPU If R0 is something else, it is a J11 CPU, see more below. 6. Execute OP-codes 076600,000400 If that succeeds => 11/60 CPU If that fails: 7. Execute OP-code 106700 If that succeeds => 11/34 CPU If that fails: 8. Try to read PIRQ register If that succeeds => 11/45 CPU If that fails: CPU is one of: 11-/04/05/10/15/20/40 M+ will just assume 11/40, since that is the only possible model that could possibly be running this code. => 11/40 CPU For J11 processors, after point 3, we get into a J11 probing. 9. If R0 <> 5, it is not a J11 processor after all. => Unknown CPU 10. Read maintenance register If fail => Unknown CPU 11. Check bits 4-7 of maintenance register: == 4: => 11/53 CPU == 3: => 11/73 CPU (not KDJ11) == 1: Write KISDR7+1 to KISDR7+1 Check if W bit in KISDR7 was set. If set => M11 CPU Try opcodes 076660,156227 If succeed => N11 CPU == 2: => 11/83 or 11/84 CPU (see step 12) == 5: => 11/93 or 11/94 CPU (see step 12) 12. Check if Unibus system based on maintenance register If Unibus system indicated, try read Unibus map register If Unibus map exist: => Unibus system. CPU 11/84 or 11/94 (see 11) 13. Qbus system. CPU 11/83 or 11/93 (see 11) Note: M11 processor is called 11/95 Note: N11 processor is called 11/97 That concludes how RSX-11M-PLUS decides what CPU you have at boot. There are then probes for TOY, clock and memory, but that's a different story. If anyone wants more information, the code is in LB:[12,10]SAVSIZ.MAC, routine $STCPU. But I'm happy to also answer any questions. Also note that while doing these tests/probes, RSX is catching the illegal instruction trap, and just resumes execution but sets carry. So for some of these tests, the carry is cleared, and the instruction is attempted, and then there is a check if carry got set, as a way of seeing if it worked or not. The specific opcodes are for maintenance instructions that either are harmless on other models, or trap. And which do not affect the carry if executed on the assumed processor tested for. Non-existant memory is also trapped, and execution resumed with carry set. Same kind of idea... Johnny On 2021-03-05 19:38, Paul Koning wrote: I was just asked some questions about how RSTS identifies your processor type. Since that topic might be of broader interest I figured I'd do some code reading and summarize the logic. In the RSTS initialization code (INIT.SYS), the first step is to identify what your hardware looks like. That is a combination of CPU type, bus type, memory layout, and peripheral configuration lookup. They aren't strictly separated into sequential blocks for those four activities, though naturally you'd want to know the bus type before you start looking for I/O devices on that bus. What I describe here is in RSTS/E V10.1. The general idea of scanning the hardware was introduced in V6B, and I believe is basically the same from that
Re: [simh] RSTS processor identification
How can you run m+ on an 11/23 or a 40? I thought it needed I/d space to run thus I can see it on a 45. On March 5, 2021 6:02:45 PM EST, Johnny Billquist via cctalk wrote: >Nice writeup, Paul. And very interesting. > >Just in case anyone wonder about RSX, here is how it's done in M+: > >1. Test if SYSID register exists >If SYSID register exists: >2. Test if high bit of KISDR0 can be set and read back > If high bit can be set and read back => 11/74 CPU > If high bit cannot be set and read back => 11/70 CPU >3. Try MFPT instruction >If that succeeds: > If R0 == 1 => 11/44 CPU > If R0 == 3: >4. Try to read maintenance register > If register exists => XT CPU (Pro) > 5. If register does not exist, try writing to SWR > If fail to write => 11/23 CPU > If succeed to write => 11/24 CPU > If R0 is something else, it is a J11 CPU, see more below. >6. Execute OP-codes 076600,000400 >If that succeeds => 11/60 CPU >If that fails: >7. Execute OP-code 106700 > If that succeeds => 11/34 CPU > If that fails: > 8. Try to read PIRQ register > If that succeeds => 11/45 CPU > If that fails: >CPU is one of: 11-/04/05/10/15/20/40 >M+ will just assume 11/40, since that is the only possible > model that could possibly be running this code. => 11/40 CPU > > >For J11 processors, after point 3, we get into a J11 probing. >9. If R0 <> 5, it is not a J11 processor after all. => Unknown CPU >10. Read maintenance register > If fail => Unknown CPU >11. Check bits 4-7 of maintenance register: > == 4: => 11/53 CPU > == 3: => 11/73 CPU (not KDJ11) > == 1: Write KISDR7+1 to KISDR7+1 > Check if W bit in KISDR7 was set. > If set => M11 CPU > Try opcodes 076660,156227 > If succeed => N11 CPU > == 2: => 11/83 or 11/84 CPU (see step 12) > == 5: => 11/93 or 11/94 CPU (see step 12) >12. Check if Unibus system based on maintenance register > If Unibus system indicated, try read Unibus map register > If Unibus map exist: => Unibus system. CPU 11/84 or 11/94 (see 11) >13. Qbus system. CPU 11/83 or 11/93 (see 11) > > >Note: M11 processor is called 11/95 >Note: N11 processor is called 11/97 > >That concludes how RSX-11M-PLUS decides what CPU you have at boot. > >There are then probes for TOY, clock and memory, but that's a different > >story. > >If anyone wants more information, the code is in LB:[12,10]SAVSIZ.MAC, >routine $STCPU. But I'm happy to also answer any questions. > >Also note that while doing these tests/probes, RSX is catching the >illegal instruction trap, and just resumes execution but sets carry. So > >for some of these tests, the carry is cleared, and the instruction is >attempted, and then there is a check if carry got set, as a way of >seeing if it worked or not. The specific opcodes are for maintenance >instructions that either are harmless on other models, or trap. And >which do not affect the carry if executed on the assumed processor >tested for. > >Non-existant memory is also trapped, and execution resumed with carry >set. Same kind of idea... > > Johnny > >On 2021-03-05 19:38, Paul Koning wrote: >> I was just asked some questions about how RSTS identifies your >processor type. Since that topic might be of broader interest I >figured I'd do some code reading and summarize the logic. >> >> In the RSTS initialization code (INIT.SYS), the first step is to >identify what your hardware looks like. That is a combination of CPU >type, bus type, memory layout, and peripheral configuration lookup. >They aren't strictly separated into sequential blocks for those four >activities, though naturally you'd want to know the bus type before you >start looking for I/O devices on that bus. >> >> What I describe here is in RSTS/E V10.1. The general idea of >scanning the hardware was introduced in V6B, and I believe is basically >the same from that time onward apart from the addition of support for >more hardware types. Prior to V6B, the assumption was that you had the >hardware you specified during SYSGEN, neither more nor less. >> >> Here is an outline (not all the details) of the hardware scan flow: >> >> 1. If word 0 of the boot block contains a zero, this is a Pro (CT >bus); otherwise it isn't. >> 2. Make sure the MMU exist; if not, halt. >> 3. Check the CPU type (MFPT instruction). If it's an F-11, see if >177570 exist. If yes, 11/24 (Unibus); if no, 11/23 (Qbus). If it's a >J-11, read the board type register at 177750 and use the bus type bit >to distinguish Qbus from Unibus. >> 4. Check that there is a clock, and if possible determine the power >line frequency. >> 5. Check if there is a CPU cache, and whether there is a cache error >address register. >> 6. If Qbus, check whether there is memory above the 18 bit range. >> 7. Check that there is at least 96kW of
Re: [simh] RSTS processor identification
Nice writeup, Paul. And very interesting. Just in case anyone wonder about RSX, here is how it's done in M+: 1. Test if SYSID register exists If SYSID register exists: 2. Test if high bit of KISDR0 can be set and read back If high bit can be set and read back => 11/74 CPU If high bit cannot be set and read back => 11/70 CPU 3. Try MFPT instruction If that succeeds: If R0 == 1 => 11/44 CPU If R0 == 3: 4. Try to read maintenance register If register exists => XT CPU (Pro) 5. If register does not exist, try writing to SWR If fail to write => 11/23 CPU If succeed to write => 11/24 CPU If R0 is something else, it is a J11 CPU, see more below. 6. Execute OP-codes 076600,000400 If that succeeds => 11/60 CPU If that fails: 7. Execute OP-code 106700 If that succeeds => 11/34 CPU If that fails: 8. Try to read PIRQ register If that succeeds => 11/45 CPU If that fails: CPU is one of: 11-/04/05/10/15/20/40 M+ will just assume 11/40, since that is the only possible model that could possibly be running this code. => 11/40 CPU For J11 processors, after point 3, we get into a J11 probing. 9. If R0 <> 5, it is not a J11 processor after all. => Unknown CPU 10. Read maintenance register If fail => Unknown CPU 11. Check bits 4-7 of maintenance register: == 4: => 11/53 CPU == 3: => 11/73 CPU (not KDJ11) == 1: Write KISDR7+1 to KISDR7+1 Check if W bit in KISDR7 was set. If set => M11 CPU Try opcodes 076660,156227 If succeed => N11 CPU == 2: => 11/83 or 11/84 CPU (see step 12) == 5: => 11/93 or 11/94 CPU (see step 12) 12. Check if Unibus system based on maintenance register If Unibus system indicated, try read Unibus map register If Unibus map exist: => Unibus system. CPU 11/84 or 11/94 (see 11) 13. Qbus system. CPU 11/83 or 11/93 (see 11) Note: M11 processor is called 11/95 Note: N11 processor is called 11/97 That concludes how RSX-11M-PLUS decides what CPU you have at boot. There are then probes for TOY, clock and memory, but that's a different story. If anyone wants more information, the code is in LB:[12,10]SAVSIZ.MAC, routine $STCPU. But I'm happy to also answer any questions. Also note that while doing these tests/probes, RSX is catching the illegal instruction trap, and just resumes execution but sets carry. So for some of these tests, the carry is cleared, and the instruction is attempted, and then there is a check if carry got set, as a way of seeing if it worked or not. The specific opcodes are for maintenance instructions that either are harmless on other models, or trap. And which do not affect the carry if executed on the assumed processor tested for. Non-existant memory is also trapped, and execution resumed with carry set. Same kind of idea... Johnny On 2021-03-05 19:38, Paul Koning wrote: I was just asked some questions about how RSTS identifies your processor type. Since that topic might be of broader interest I figured I'd do some code reading and summarize the logic. In the RSTS initialization code (INIT.SYS), the first step is to identify what your hardware looks like. That is a combination of CPU type, bus type, memory layout, and peripheral configuration lookup. They aren't strictly separated into sequential blocks for those four activities, though naturally you'd want to know the bus type before you start looking for I/O devices on that bus. What I describe here is in RSTS/E V10.1. The general idea of scanning the hardware was introduced in V6B, and I believe is basically the same from that time onward apart from the addition of support for more hardware types. Prior to V6B, the assumption was that you had the hardware you specified during SYSGEN, neither more nor less. Here is an outline (not all the details) of the hardware scan flow: 1. If word 0 of the boot block contains a zero, this is a Pro (CT bus); otherwise it isn't. 2. Make sure the MMU exist; if not, halt. 3. Check the CPU type (MFPT instruction). If it's an F-11, see if 177570 exist. If yes, 11/24 (Unibus); if no, 11/23 (Qbus). If it's a J-11, read the board type register at 177750 and use the bus type bit to distinguish Qbus from Unibus. 4. Check that there is a clock, and if possible determine the power line frequency. 5. Check if there is a CPU cache, and whether there is a cache error address register. 6. If Qbus, check whether there is memory above the 18 bit range. 7. Check that there is at least 96kW of memory (but the message says that 124kW is required -- the actual check value was apparently overlooked and not updated). 8. Check CPU features: EIS (required), FPP, FIS, switch register, display register, MED, two register sets, system ID register, CIS, Data space. 9. If Unibus, check for UMR. 10. Find where memory is. This is
