Re: Spelunking the places where files are not
On Fri, Mar 5, 2021 at 7:41 AM John Foust via cctalk wrote: > > After thinking about disk imaging tools like Greaseweasel, > I started thinking about tools that would grab and examine the unused > portions of disks. > I've used this to recover a couple of Univation utilities from a disk that they had been deleted from... It's quite useful... It was a FAT filesystem, and the files were small and contiguous so it was easy... Warner > It's obviously file-system dependent. At one level we know of > "undelete" tools that could piece together recently deleted files > and restore them intact by using abandoned bits of block table info. > Of course some simple file systems can't even permit that. > > But very few systems would bother to zero out the released blocks > of erased or rewritten files and then blocks are left full of > old data. Text source code would be easy to spot. > > I have vague memories of bits of Amiga OS source code being unintentionally > released in unused blocks on OS binary disks that were sent out for > mass duplication and distribution. > > This situation makes me hesitant to release disk images from the past. > It's one thing to do it with disks that were mine and to take > responsibility > for my risk; it's another to release disks once owned and used by others. > Do the unused sectors contain their love letters from 1983? > > Or if I want to release disk images that contain known personal files, > how will I image, then remove specific files, then zero unused blocks > if I don't want to alter the original media? > > Obviously in some situations the relevant files can be pulled and > redistributed in a new filesystem like a Zip. > > The situation only gets worse with distributing larger images of > entire hard disks. Or with Windows, "quick format" doesn't zero blocks. > > In another case I encountered while digging through files on an old > RSTS backup tape, we had a program that logged usage data to a file > and for speed purposes it would preallocate a large file (as opposed > to extending the file, which was slower) and then write block records > to it. RSTS reused blocks without zeroing. In the unused blocks > of an extant file I found an email I'd sent in '82 as well as bits > from other users of the same timesharing system. > > Certainly the archivists out there have considered these questions. > How are they solved? > > Are there notable tools that focus on the files that aren't there? > > I don't mean modern forensic carving tools... but some concepts would > be similar. > > - John > >
Re: Tymshare PDP-10 tapes
Tony Aiuto wrote: >> What problem do you have with my tito tool? > > $ ./tito -x -f 169249.tape > fopen: Is a directory This appears to be because creating an output file was attempted, but there was already a directory there with the same name. I'm updating the program to print better error messages.
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: PIC programmers? More generic programmer? Port?
On Wed, 2021-03-03 at 17:15 -0500, Anders Nelson via cctalk wrote: > I was a field application engineer for Microchip from 2008-2011, > making > POCs for big name customers in the bay area using 8, 16 and 32-bit > PICs. > > You will likely find that Microchip support is awful, even if their > products are pretty neat. There was an Arduino port for PICs called > "ChipKit" but I don't know if that's still being developed. > > The PicKit 3 is decent, if pretty slow. The ICD3 and later versions > are > good. MPLAB X is excellent IMO. I should still hold a design partner > discount so if you want to get some tools, contact me offline and > I'll see > if I can save you some money. > > That all said, I'm a huge fan of the STM32 ARM devices and the > community is > nearly as good as Nordic, and what Atmel used to be before it was > acquired > by Microchip. > > -- > Anders Nelson Hmm. Well sounds like it might be better to disassemble the existing provided PIC blobs and re-code for something else. Looks like the board is basically MAX232 level shifters and then the PICs to change the keyboard encoding, so theoretically any MCU should work.
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: Tymshare PDP-10 tapes
On Fri, Mar 5, 2021 at 1:37 PM Lars Brinkhoff wrote: > Tony Aiuto wrote: > > that gets lots of files with names like 'dsk:[1,4]specdf525].mic' > > That just seems wrong. > > Correct, back10 does get some things wrong. It also puts some data at > the beginning of files which should be part of the file header. TITO > uses the "*FAILSAFE" magic number which fools back10 to think it's > FAILSAFE. > > What problem do you have with my tito tool? Which tape did you try? > I haven't tested all tapes, so maybe some of them has surprises. > Like I said before $ ./tito -x -f 169249.tape fopen: Is a directory $ bin/back10 -l -f 169249.tape | head 18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700202].ufd 18-Nov-1858 00:00:00 <754> dsk:[1,1][3,74].ufd 18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700220].ufd $ bin/back10 -x -f 169249.tape that gets lots of files with names like 'dsk:[1,4]specdf525].mic' > I'm not sure what to do with the file checksum yet. > That is useful to verify that we reassembled the pieces correctly. $ sha1sum 169249.tape 1230fb20086990a1ff777fce32591f2900425694 169249.tape This matches yours.
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
Re: Pdp10 and TOPS 10 stuff
On Mar 5, 2021, at 4:19 AM, Philipp Hachtmann via cctalk wrote: > > Hi, > I habe some pdp10 related docs which need to go away. > Anybody interested? Or should I dump it (and reuse the white folders foro > pdp8 stuff)? > > https://www.icloud.com/sharedalbum/#B0r5oqs3qGclUOi > > Kind regards > Philipp Hopefully someone in close by in Europe responds, I’m not sure I want to know what it would cost to ship this to the US. I have to agree with Rob, it would help to know what you have. Do you at least know what isn’t already on Bitsavers? I really hate to see the loss of any PDP-10 documentation at this point. Zane
Re: Spelunking the places where files are not
> On Mar 5, 2021, at 5:02 PM, Glen Slick via cctalk > wrote: > > On Fri, Mar 5, 2021 at 1:46 PM Paul Koning via cctalk > wrote: >> >> Yes, RT11 has contiguous files. That actually made it rather unusual. For >> example, while RSTS supports contiguous files that isn't the default and >> because of disk fragmentation wasn't commonly used. > > On VMS you can copy files with the /CONTIGUOUS switch to specify that > the output file must occupy contiguous physical disk blocks. Of course > the default is /NOCONTIGUOUS. > > I vaguely remember using the /CONTIGUOUS switch to copy MDM (MicroVAX > Diagnostic Monitor) diagnostic files from one bootable MDM disk to > another. I forget if that is necessary for proper operation of MDM. I like to make RSTS floppy files contiguous to avoid spending so much time going back to the directory to find the next set of file data pointers. In RSTS, a few files have to be contiguous: run time systems and shared libraries, swap files, the system error message file, and the DECtape directory buffer file. That's about it. In early versions, the monitor had to be contiguous as well, but as of V6B that is no longer true (not for INIT either). Strangely enough, in the RSTS file system there are always pointers to each file cluster, even if the file is contiguous. It didn't dawn on me until a few weeks ago that I should have changed that -- I could have done that back around 1982 or so. Oops. paul
Re: Spelunking the places where files are not
On Fri, Mar 5, 2021 at 1:46 PM Paul Koning via cctalk wrote: > > Yes, RT11 has contiguous files. That actually made it rather unusual. For > example, while RSTS supports contiguous files that isn't the default and > because of disk fragmentation wasn't commonly used. On VMS you can copy files with the /CONTIGUOUS switch to specify that the output file must occupy contiguous physical disk blocks. Of course the default is /NOCONTIGUOUS. I vaguely remember using the /CONTIGUOUS switch to copy MDM (MicroVAX Diagnostic Monitor) diagnostic files from one bootable MDM disk to another. I forget if that is necessary for proper operation of MDM.
Re: Spelunking the places where files are not
> On Mar 5, 2021, at 4:11 PM, Boris Gimbarzevsky via cctalk > wrote: > > Recovering data from disks was a lot easier 30 years ago when most > filesystems had contiguous files and it was just a matter of finding file > boundaries. Was very glad of this when accidentally wiped first 200 blocks > of an RT-11 RK05 and just had to write a FORTRAN program to copy blocks of > data and assign the files names. Yes, RT11 has contiguous files. That actually made it rather unusual. For example, while RSTS supports contiguous files that isn't the default and because of disk fragmentation wasn't commonly used. I was going to describe how you could do recovery on RSTS file systems, when I realized that it doesn't actually work at all. The file system is designed to allow you to piece it back together if some entries are corrupted. As an extreme example, in the new (RDS 1) file structure, you could wipe out the MFD -- the root directory of the file system -- and almost certainly put it back together by scanning the disk for the GFDs -- the second level directories, which are tagged with a magic number that allows them to be found easily. On the other hand, if you delete a file there is nothing left in the file system metadata to tell you about its previous existence. While the 8-word blocks that make up directory entries only need two leading 0 words to be considered "free", it turns out the file system code actually zeroes all the entries in their entirety when deleting a file. So you can try to reconstruct a file from free space, if you're lucky enough to be able to find its pieces and connect them in the right order, but there isn't anything left of the metadata (name, time stamps, etc.) Yes, that could have been left around, and I'm actually somewhat puzzled about why it was done that way; it looks like early versions (V4A at least) just zero the minimal 2 words which would leave you half a file name and other stuff, not to mention 6/7th of the file data pointers. paul
Re: Spelunking the places where files are not
Recovering data from disks was a lot easier 30 years ago when most filesystems had contiguous files and it was just a matter of finding file boundaries. Was very glad of this when accidentally wiped first 200 blocks of an RT-11 RK05 and just had to write a FORTRAN program to copy blocks of data and assign the files names. Also wrote a program to do a disk scan to look for specific file type and like to show people what jpeg files they've left behind on a disk they've "wiped". Finding images very easy as can display a list of many image icons on screen and quickly scroll through them if one is looking far a particular image. Of course, the longer a hard disk has been used and not defragmented, the lower the recovery percentage of files. Got paid for file recovery a few times but mainly use it to show people what really happens when they "wipe" a disk. Have convinced a lot of people that low level format on a disk they're giving away a good idea. After thinking about disk imaging tools like Greaseweasel, I started thinking about tools that would grab and examine the unused portions of disks. It's obviously file-system dependent. At one level we know of "undelete" tools that could piece together recently deleted files and restore them intact by using abandoned bits of block table info. Of course some simple file systems can't even permit that. But very few systems would bother to zero out the released blocks of erased or rewritten files and then blocks are left full of old data. Text source code would be easy to spot. I have vague memories of bits of Amiga OS source code being unintentionally released in unused blocks on OS binary disks that were sent out for mass duplication and distribution. This situation makes me hesitant to release disk images from the past. It's one thing to do it with disks that were mine and to take responsibility for my risk; it's another to release disks once owned and used by others. Do the unused sectors contain their love letters from 1983? Or if I want to release disk images that contain known personal files, how will I image, then remove specific files, then zero unused blocks if I don't want to alter the original media? Obviously in some situations the relevant files can be pulled and redistributed in a new filesystem like a Zip. The situation only gets worse with distributing larger images of entire hard disks. Or with Windows, "quick format" doesn't zero blocks. In another case I encountered while digging through files on an old RSTS backup tape, we had a program that logged usage data to a file and for speed purposes it would preallocate a large file (as opposed to extending the file, which was slower) and then write block records to it. RSTS reused blocks without zeroing. In the unused blocks of an extant file I found an email I'd sent in '82 as well as bits from other users of the same timesharing system. Certainly the archivists out there have considered these questions. How are they solved? Are there notable tools that focus on the files that aren't there? I don't mean modern forensic carving tools... but some concepts would be similar. - John
PDP 8/a for sale UK (Devon)
I'm moving soon and need to down-size a little, so selling off my PDP-8/a. It has 16KW core and is in full working order. It has the serial IO board which I think was standard in the 8/a anyway. It's a 3-card system plus the 2 x 8KW core boards. Also included is a Vincent Slyngstad memory/rtc expansion board - not built up, so full kit form that I've not been able to assemble yet. £1000 ono. https://unicorn.drogon.net/IMG_20210305_150415.jpg boards: https://unicorn.drogon.net/IMG_20180126_181135.jpg https://unicorn.drogon.net/IMG_20180126_181115.jpg https://unicorn.drogon.net/IMG_20180126_171659.jpg I'm based in Devon. Buyer collect (if you want to see it working) else I can make a short video and may be able to take it a little way up or down the A38/M5. Thanks, Gordon
Re: RSTS processor identification
very nice! thans!! better than reading all the manuals and trying to figure out the code!! Stay well Paul!! bob smith On Fri, Mar 5, 2021 at 1:38 PM Paul Koning via cctalk 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 done by looking at every 1kW address to > see if it answers. So unlike some other operating systems, RSTS will keep > looking if it finds a hole in memory. The kernel needs to be at 0 and > contiguous, but holes above that are not a problem. > 11. Scan the I/O bus for peripherals. This uses the fixed addresses and float > rules for Unibus/Qbus (either, the code doesn't care) or the slot use bits > and device type register codes for the Pro. > 12. Find the vectors, which for almost every device is done by making it > interrupt. > 13. Identify specific device models if we care, like RL01 vs. RL02, Massbus > disk type, DMC/DMR/DMP, etc. > 14. Find which of these devices we were booted from. > > That's about it. Once you get past that point the INIT prompt appears and > you can ask what INIT found with "HARDWARE LIST". > > Incidentally, RSTS doesn't try to identify the exact CPU type you have. > Instead, it cares about features or distinctions that affect the code. In a > number of cases it does report the type -- if MFPT works then "hardware list" > will report that information. But for older CPUs, it doesn't say explicitly, > though you can deduce it to some extent. If no type is given but there is > cache and more than 128 kW of memory, it's an 11/70. If MED is available, > it's an 11/60. If it has FIS, it can only be an 11/40. Etc... > > paul > >
Re: Spelunking the places where files are not
Three obvious possibilites for tools to help:
1) A program that makes a single large file out of all unallocated blocks,
for later study and breaak-up in an editor.
2) A prograam that makes a separate file out of each unallocated block,
for later study and appending in an editor.
3) An INTERACTIVE program that displays a block, with the option of
ignoring, or making a file out of it, and then, for each subsequent block
provides the option to Ignore, Append it to one of the existing files, or
Create a new file from it.
Ideally, it should have a clue about likely sequence of blocks, including
interleave and side patterns.
ALthough a variety of algorithms could ASSIST with whether a given block
is LIKELY to be a continuation of the previous block, few could work
stand-alone as well as a human operator.
Among the possibilities are seeing ASCII (or other) code at the end of one
block and the beginning of another ("looking for half a worm in the
apple")
The same tools are also useful when the DIRectory or other file system
information is destroyed, or completely unknown.
I had a client who was overjoyed when I gave him a few hundred files,
which he proceeded to printout and he and his staff manually sorted and
rearranged the printouts by looking at their content. We then looked at
the sequences of the file numbers and appended files accordingly.
--
Grumpy Ol' Fred ci...@xenosoft.com
On Fri, 5 Mar 2021, John Foust via cctalk wrote:
After thinking about disk imaging tools like Greaseweasel,
I started thinking about tools that would grab and examine the unused
portions of disks.
It's obviously file-system dependent. At one level we know of
"undelete" tools that could piece together recently deleted files
and restore them intact by using abandoned bits of block table info.
Of course some simple file systems can't even permit that.
But very few systems would bother to zero out the released blocks
of erased or rewritten files and then blocks are left full of
old data. Text source code would be easy to spot.
I have vague memories of bits of Amiga OS source code being unintentionally
released in unused blocks on OS binary disks that were sent out for
mass duplication and distribution.
This situation makes me hesitant to release disk images from the past.
It's one thing to do it with disks that were mine and to take responsibility
for my risk; it's another to release disks once owned and used by others.
Do the unused sectors contain their love letters from 1983?
Or if I want to release disk images that contain known personal files,
how will I image, then remove specific files, then zero unused blocks
if I don't want to alter the original media?
Obviously in some situations the relevant files can be pulled and
redistributed in a new filesystem like a Zip.
The situation only gets worse with distributing larger images of
entire hard disks. Or with Windows, "quick format" doesn't zero blocks.
In another case I encountered while digging through files on an old
RSTS backup tape, we had a program that logged usage data to a file
and for speed purposes it would preallocate a large file (as opposed
to extending the file, which was slower) and then write block records
to it. RSTS reused blocks without zeroing. In the unused blocks
of an extant file I found an email I'd sent in '82 as well as bits
from other users of the same timesharing system.
Certainly the archivists out there have considered these questions.
How are they solved?
Are there notable tools that focus on the files that aren't there?
I don't mean modern forensic carving tools... but some concepts would
be similar.
- John
RSTS processor identification
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 done by looking at every 1kW address to see if it answers. So unlike some other operating systems, RSTS will keep looking if it finds a hole in memory. The kernel needs to be at 0 and contiguous, but holes above that are not a problem. 11. Scan the I/O bus for peripherals. This uses the fixed addresses and float rules for Unibus/Qbus (either, the code doesn't care) or the slot use bits and device type register codes for the Pro. 12. Find the vectors, which for almost every device is done by making it interrupt. 13. Identify specific device models if we care, like RL01 vs. RL02, Massbus disk type, DMC/DMR/DMP, etc. 14. Find which of these devices we were booted from. That's about it. Once you get past that point the INIT prompt appears and you can ask what INIT found with "HARDWARE LIST". Incidentally, RSTS doesn't try to identify the exact CPU type you have. Instead, it cares about features or distinctions that affect the code. In a number of cases it does report the type -- if MFPT works then "hardware list" will report that information. But for older CPUs, it doesn't say explicitly, though you can deduce it to some extent. If no type is given but there is cache and more than 128 kW of memory, it's an 11/70. If MED is available, it's an 11/60. If it has FIS, it can only be an 11/40. Etc... paul
Re: Tymshare PDP-10 tapes
Tony Aiuto wrote: > that gets lots of files with names like 'dsk:[1,4]specdf525].mic' > That just seems wrong. Correct, back10 does get some things wrong. It also puts some data at the beginning of files which should be part of the file header. TITO uses the "*FAILSAFE" magic number which fools back10 to think it's FAILSAFE. What problem do you have with my tito tool? Which tape did you try? I haven't tested all tapes, so maybe some of them has surprises. I'm not sure what to do with the file checksum yet.
Re: Vax/pdp on ebay
FWIW, the plate on my 11/93 in BA123 cab just has "DIGITAL". De
Re: Vax/pdp on ebay
I need one for an 11/83 (if I can get my CPU board to run). It's on my "to do" list to try to 3-D model one for FMD or resin printing. -- John H. Reinhardt On 3/5/2021 10:51 AM, Nigel Johnson via cctalk wrote: Speaking of badges, I have a BA23 that doesn't have one. It was an 11/73 but that badge is gone, and I am trying to repair an 11/93 to go in there. Does anybody have a spare 11/73 badge for the BA23 that could be used as a model for a printed version that says 11/93? I don't believe there ever was one for the BA23 chassis! I have a BA123 micro VAX II badge going spare if anybody needs it, or to swap for an 11/73! Cheers, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.john...@ieee.org On 2021-03-05 11:46 a.m., Zane Healy via cctalk wrote: On Mar 4, 2021, at 1:55 PM, Wayne S via cctalk wrote: Is anyone from this list bidding on this. If so i’ll back out. Just don’t want it to be “recycled “ and i have room for it. https://www.ebay.com/itm/Digital-DEC-BA23-Lot-Micro-PDP-11-73-VAXstation-3200-x2-VT220-x2-Extras-Docs/224368924502?hash=item343d6e1756:g:zp8AAOSwvWNgO9qe I’m relieved it’s not closer to me, or I’d be sorely tempted to go for that. That’s a seriously nice pile of gear. Especially as they have the right badges on the pedestals. I’m more interested in downsizing than adding more, but that’s exactly the sort of thing that would tempt me. Zane
Re: Vax/pdp on ebay
Sheesh! and I have been on that site too! Now I just need a model for the back part and I can send it to my friend who does 3D printing! Thanks Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.john...@ieee.org On 2021-03-05 12:12 p.m., emanuel stiebler via cctalk wrote: > On 2021-03-05 11:57, Doc Shipley via cctalk wrote: >> On 3/5/21 10:51, Nigel Johnson via cctalk wrote: >>> Speaking of badges, I have a BA23 that doesn't have one. It was an 11/73 >>> but that badge is gone, and I am trying to repair an 11/93 to go in >>> there. >>> >>> Does anybody have a spare 11/73 badge for the BA23 that could be used as >>> a model for a printed version that says 11/93? I don't believe there >>> ever was one for the BA23 chassis! I have a BA123 micro VAX II badge >>> going spare if anybody needs it, or to swap for an 11/73! >> I once had a pair of 11/93s that originally lived in BA23 pedestals, >> and I'm fairly certain that they did have "MicroPDP 11/93" badges. >> >> I'll look and see if I have any photos. > That was pretty easy ;-) > > https://www.pdp-11.nl/pdp11-93startpage.html >
Re: Vax/pdp on ebay
On 2021-03-05 11:57, Doc Shipley via cctalk wrote: > On 3/5/21 10:51, Nigel Johnson via cctalk wrote: >> Speaking of badges, I have a BA23 that doesn't have one. It was an 11/73 >> but that badge is gone, and I am trying to repair an 11/93 to go in >> there. >> >> Does anybody have a spare 11/73 badge for the BA23 that could be used as >> a model for a printed version that says 11/93? I don't believe there >> ever was one for the BA23 chassis! I have a BA123 micro VAX II badge >> going spare if anybody needs it, or to swap for an 11/73! > > I once had a pair of 11/93s that originally lived in BA23 pedestals, > and I'm fairly certain that they did have "MicroPDP 11/93" badges. > > I'll look and see if I have any photos. That was pretty easy ;-) https://www.pdp-11.nl/pdp11-93startpage.html
Re: Vax/pdp on ebay
Thanks, Doc, I was under the impression that they always were shipped in the grey 'corporate cabinets'! cheers, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.john...@ieee.org On 2021-03-05 11:57 a.m., Doc Shipley via cctalk wrote: > On 3/5/21 10:51, Nigel Johnson via cctalk wrote: >> Speaking of badges, I have a BA23 that doesn't have one. It was an 11/73 >> but that badge is gone, and I am trying to repair an 11/93 to go in >> there. >> >> Does anybody have a spare 11/73 badge for the BA23 that could be used as >> a model for a printed version that says 11/93? I don't believe there >> ever was one for the BA23 chassis! I have a BA123 micro VAX II badge >> going spare if anybody needs it, or to swap for an 11/73! > > I once had a pair of 11/93s that originally lived in BA23 pedestals, > and I'm fairly certain that they did have "MicroPDP 11/93" badges. > > I'll look and see if I have any photos. > > > Doc
Re: Vax/pdp on ebay
On 3/5/21 10:51, Nigel Johnson via cctalk wrote: Speaking of badges, I have a BA23 that doesn't have one. It was an 11/73 but that badge is gone, and I am trying to repair an 11/93 to go in there. Does anybody have a spare 11/73 badge for the BA23 that could be used as a model for a printed version that says 11/93? I don't believe there ever was one for the BA23 chassis! I have a BA123 micro VAX II badge going spare if anybody needs it, or to swap for an 11/73! I once had a pair of 11/93s that originally lived in BA23 pedestals, and I'm fairly certain that they did have "MicroPDP 11/93" badges. I'll look and see if I have any photos. Doc
Re: Vax/pdp on ebay
Speaking of badges, I have a BA23 that doesn't have one. It was an 11/73 but that badge is gone, and I am trying to repair an 11/93 to go in there. Does anybody have a spare 11/73 badge for the BA23 that could be used as a model for a printed version that says 11/93? I don't believe there ever was one for the BA23 chassis! I have a BA123 micro VAX II badge going spare if anybody needs it, or to swap for an 11/73! Cheers, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.john...@ieee.org On 2021-03-05 11:46 a.m., Zane Healy via cctalk wrote: > >> On Mar 4, 2021, at 1:55 PM, Wayne S via cctalk wrote: >> >> Is anyone from this list bidding on this. >> If so i’ll back out. Just don’t want it to be “recycled “ and i have room >> for it. >> >> https://www.ebay.com/itm/Digital-DEC-BA23-Lot-Micro-PDP-11-73-VAXstation-3200-x2-VT220-x2-Extras-Docs/224368924502?hash=item343d6e1756:g:zp8AAOSwvWNgO9qe > I’m relieved it’s not closer to me, or I’d be sorely tempted to go for that. > That’s a seriously nice pile of gear. Especially as they have the right > badges on the pedestals. I’m more interested in downsizing than adding more, > but that’s exactly the sort of thing that would tempt me. > > Zane > > >
Re: Vax/pdp on ebay
I have a BA23 pedestal 11/83 and it's a really nice form factor for a pdp11. The CPU in that box can take PMI memory but it looks like it's configured with conventional memory based on the location of the processor board. On 3/5/2021 10:13 AM, John H. Reinhardt via cctalk wrote: On 3/5/2021 3:03 AM, Ed C. via cctalk wrote: Not me, but please ping me if you do and would like to part one of the 11/73. Regards. On Fri, Mar 5, 2021 at 8:25 AM Wayne S via cctalk wrote: Is anyone from this list bidding on this. If so i’ll back out. Just don’t want it to be “recycled “ and i have room for it. https://www.ebay.com/itm/Digital-DEC-BA23-Lot-Micro-PDP-11-73-VAXstation-3200-x2-VT220-x2-Extras-Docs/224368924502?hash=item343d6e1756:g:zp8AAOSwvWNgO9qe Sent from my iPhone That's a nice collection of DEC kit. The PDP-11/73 pedestal would be nice.
Re: Vax/pdp on ebay
> On Mar 4, 2021, at 1:55 PM, Wayne S via cctalk wrote: > > Is anyone from this list bidding on this. > If so i’ll back out. Just don’t want it to be “recycled “ and i have room for > it. > > https://www.ebay.com/itm/Digital-DEC-BA23-Lot-Micro-PDP-11-73-VAXstation-3200-x2-VT220-x2-Extras-Docs/224368924502?hash=item343d6e1756:g:zp8AAOSwvWNgO9qe I’m relieved it’s not closer to me, or I’d be sorely tempted to go for that. That’s a seriously nice pile of gear. Especially as they have the right badges on the pedestals. I’m more interested in downsizing than adding more, but that’s exactly the sort of thing that would tempt me. Zane
Re: Tymshare PDP-10 tapes
On Fri, Mar 5, 2021 at 4:55 AM Lars Brinkhoff via cctalk < cctalk@classiccmp.org> wrote: > Hello, > > Someone sent me these magtape images from Tymshare and said "they fell > off the back of a truck on route 62 in Hudson, MASS." I don't know > their provenance. > > Sorry, I don't have any good hosting. For now they are here: > https://gitlab.com/larsbrinkhoff/tymshare > > The download.sh script will retrieve individual files one by one rather > than cloning the repository; next use cat.sh to get the .tape.bz2 files. > > The tape format is close to not not quite FAILSAFE. With help from Joe > Smith, I made a tool to extract the files: > https://github.com/larsbrinkhoff/pdp10-its-disassembler/blob/master/tito.c I'm not having any luck with either back10 or tito. $ sha1sum 169249.tape 1230fb20086990a1ff777fce32591f2900425694 169249.tape (So that's good) $ ./tito -x -f 169249.tape fopen: Is a directory $ bin/back10 -l -f 169249.tape | head 18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700202].ufd 18-Nov-1858 00:00:00 <754> dsk:[1,1][3,74].ufd 18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700220].ufd $ bin/back10 -x -f 169249.tape ... that gets lots of files with names like 'dsk:[1,4]specdf525].mic' That just seems wrong.
Re: Vax/pdp on ebay
On 3/5/2021 3:03 AM, Ed C. via cctalk wrote: Not me, but please ping me if you do and would like to part one of the 11/73. Regards. On Fri, Mar 5, 2021 at 8:25 AM Wayne S via cctalk wrote: Is anyone from this list bidding on this. If so i’ll back out. Just don’t want it to be “recycled “ and i have room for it. https://www.ebay.com/itm/Digital-DEC-BA23-Lot-Micro-PDP-11-73-VAXstation-3200-x2-VT220-x2-Extras-Docs/224368924502?hash=item343d6e1756:g:zp8AAOSwvWNgO9qe Sent from my iPhone That's a nice collection of DEC kit. The PDP-11/73 pedestal would be nice. -- John H. Reinhardt
Re: digital group's Richard Bemis
On Fri, 5 Mar 2021 at 16:00, John H. Reinhardt via cctalk wrote: > > No, he means "The Digital Group". It was a microcomputer company in the > 1975-1979 time frame. > > http://bytecollector.com/the_digital_group.htm > > https://en.wikipedia.org/wiki/The_Digital_Group Thanks for the clarification! I see a few people are happily telling me I am wrong. It's fair, I _was_ wrong. I merely wanted to point out the ambiguity in the original message, though... -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: digital group's Richard Bemis
On 3/5/2021 8:30 AM, Liam Proven via cctalk wrote: On Thu, 4 Mar 2021 at 05:23, Brad H via cctalk wrote: Hi there, I am working on a 30 minute historical video about the digital group. [Spelling out my thought process] "the digital group" -- so he means Digital Equipment Corporation. Never heard them called a "group" but fine. when dg was still operational "dg"? Huh? He means DG? Data General? Well which _do_ you mean? Digital meant Digital Equipment Corporation meant DEC. DG meant Data General. Neither was anything "group". I don't know who you mean... No, he means "The Digital Group". It was a microcomputer company in the 1975-1979 time frame. http://bytecollector.com/the_digital_group.htm https://en.wikipedia.org/wiki/The_Digital_Group -- John H. Reinhardt
RE: Pdp10 and TOPS 10 stuff
I suppose some manual titles might help to determine what you have. Seems like quite a lot of manuals though! > -Original Message- > From: cctalk On Behalf Of Philipp > Hachtmann via cctalk > Sent: 05 March 2021 12:20 > To: cctalk@classiccmp.org > Subject: Pdp10 and TOPS 10 stuff > > Hi, > I habe some pdp10 related docs which need to go away. > Anybody interested? Or should I dump it (and reuse the white folders foro > pdp8 stuff)? > > https://www.icloud.com/sharedalbum/#B0r5oqs3qGclUOi > > Kind regards > Philipp > > -- > > Dipl.-Inf. (FH) Philipp Hachtmann > Buchdruck, Bleisatz, Spezialitäten > > Klus 16 > 31073 Delligsen > Mobil: 0171/2632239 > > UStdID DE 202668329=
Spelunking the places where files are not
After thinking about disk imaging tools like Greaseweasel, I started thinking about tools that would grab and examine the unused portions of disks. It's obviously file-system dependent. At one level we know of "undelete" tools that could piece together recently deleted files and restore them intact by using abandoned bits of block table info. Of course some simple file systems can't even permit that. But very few systems would bother to zero out the released blocks of erased or rewritten files and then blocks are left full of old data. Text source code would be easy to spot. I have vague memories of bits of Amiga OS source code being unintentionally released in unused blocks on OS binary disks that were sent out for mass duplication and distribution. This situation makes me hesitant to release disk images from the past. It's one thing to do it with disks that were mine and to take responsibility for my risk; it's another to release disks once owned and used by others. Do the unused sectors contain their love letters from 1983? Or if I want to release disk images that contain known personal files, how will I image, then remove specific files, then zero unused blocks if I don't want to alter the original media? Obviously in some situations the relevant files can be pulled and redistributed in a new filesystem like a Zip. The situation only gets worse with distributing larger images of entire hard disks. Or with Windows, "quick format" doesn't zero blocks. In another case I encountered while digging through files on an old RSTS backup tape, we had a program that logged usage data to a file and for speed purposes it would preallocate a large file (as opposed to extending the file, which was slower) and then write block records to it. RSTS reused blocks without zeroing. In the unused blocks of an extant file I found an email I'd sent in '82 as well as bits from other users of the same timesharing system. Certainly the archivists out there have considered these questions. How are they solved? Are there notable tools that focus on the files that aren't there? I don't mean modern forensic carving tools... but some concepts would be similar. - John
Re: digital group's Richard Bemis
On Thu, 4 Mar 2021 at 05:23, Brad H via cctalk wrote: > > Hi there, > > I am working on a 30 minute historical video about the digital group. [Spelling out my thought process] "the digital group" -- so he means Digital Equipment Corporation. Never heard them called a "group" but fine. > when dg was still operational "dg"? Huh? He means DG? Data General? Well which _do_ you mean? Digital meant Digital Equipment Corporation meant DEC. DG meant Data General. Neither was anything "group". I don't know who you mean... -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Pdp10 and TOPS 10 stuff
On 3/5/21 4:19 AM, Philipp Hachtmann via cctalk wrote: Hi, I habe some pdp10 related docs which need to go away. Anybody interested? Or should I dump it (and reuse the white folders foro pdp8 stuff)? I would think Lars Brinkhoff would want them
Pdp10 and TOPS 10 stuff
Hi, I habe some pdp10 related docs which need to go away. Anybody interested? Or should I dump it (and reuse the white folders foro pdp8 stuff)? https://www.icloud.com/sharedalbum/#B0r5oqs3qGclUOi Kind regards Philipp -- Dipl.-Inf. (FH) Philipp Hachtmann Buchdruck, Bleisatz, Spezialitäten Klus 16 31073 Delligsen Mobil: 0171/2632239 UStdID DE 202668329
Tymshare PDP-10 tapes
Hello, Someone sent me these magtape images from Tymshare and said "they fell off the back of a truck on route 62 in Hudson, MASS." I don't know their provenance. Sorry, I don't have any good hosting. For now they are here: https://gitlab.com/larsbrinkhoff/tymshare The download.sh script will retrieve individual files one by one rather than cloning the repository; next use cat.sh to get the .tape.bz2 files. The tape format is close to not not quite FAILSAFE. With help from Joe Smith, I made a tool to extract the files: https://github.com/larsbrinkhoff/pdp10-its-disassembler/blob/master/tito.c
Re: Vax/pdp on ebay
Not me, but please ping me if you do and would like to part one of the 11/73. Regards. On Fri, Mar 5, 2021 at 8:25 AM Wayne S via cctalk wrote: > Is anyone from this list bidding on this. > If so i’ll back out. Just don’t want it to be “recycled “ and i have room > for it. > > > https://www.ebay.com/itm/Digital-DEC-BA23-Lot-Micro-PDP-11-73-VAXstation-3200-x2-VT220-x2-Extras-Docs/224368924502?hash=item343d6e1756:g:zp8AAOSwvWNgO9qe > > > > > > > Sent from my iPhone >
