J189B is the RSX20F V14-17 AUX dectape J190C is the V14-45 system tape J331A is the the V12-40 AUX tape.
All of these are Files-11 format (16-bit).DCZBA decodes to a KA/KI diagnostic, but it turns out to be the 'basic peripheral diagnostic'; it probably wasn't renamed for the KL. According to the label on bitsavers (http://bitsavers.trailing-edge.com/bits/DEC/pdp10/dectape/diag/MAINDEC-10-DCZBA-C-UB_4-73.dta.txt), this is a 16-bit formatted tape containing 11-based KL10 diagnostics. So the filename may be wrong...
In any case, you don't have any -10 format DECtape images.I have some physical 10-format tapes, but not the means to transcribe them. They're not of general interest; personal files.
I vaguely remember that someone has captured real 36-bit DECtapes, but the details escape me. Al Kossow may remember...
A previous note pointed you to the OS/8 doc on how to configure for different hardware.
This communication may not represent my employer's views, if any, on the matters discussed. On 28-Mar-13 07:45, Bob Supnik wrote:
I think you've got it, Tim. Here's what I've found: 05/13/2004 02:29 PM 295,936 J189B.DTA 05/13/2004 02:29 PM 295,936 J190C.DTA 05/13/2004 02:29 PM 295,936 J331A.DTA 06/24/2006 05:21 PM 295,936 MAINDEC-10-DCZBA-C-UB_4-73.dta The last is the image Tim provided.Still have to debug PIP10; it would be easier with an OS/8 system generated for the TC08./Bob On 3/28/2013 6:43 AM, Timothe Litt wrote:Bob,It might be useful to know exactly which images you tested. A number of the 'PDP-10 DECtape images' that turned up on a quick Google search are actually for the PDP-11 front-end of a KL1090/1090. These are in fact 16-bit tapes: the file format would be Files-11 for RSX20F tapes; I think the KLAD DECtapes were DOS-11 format, but it's been a while. The KLAD tapes were accessed by the -11 and loaded into the -10 via the DTE20. This is distinct from 10-side DECtape diagnostics, which also exist. Google 'AA-JS16A-TC' for some Files-11 format information; I'd have to think a bit on the DOS-11 format.Knowing which images you're working with would let the custodians of the images indicate their source, and perhaps from that we can work back to the people/method/tools used to create them.Also, if the data that you're working with is in fact truncated saves of 36-bit data, the directory block should still be recognizable. Filenames are in sixbit, and the block numbers in links fit in 16 bits. So the data should make sense, even if it is incomplete. I posted the key format information for TOPS-10 DECtapes a while back in this string. PDP-11 filenames were encoded in (PDP-11) Raxdix50.I could look at an image file if you need help untangling the data.On the pip10 /z, pip10 seems to use a private DTA service routine; it's in the sources that I pointed you to earlier.This communication may not represent my employer's views, if any, on the matters discussed. On 27-Mar-13 22:08, Bob Supnik wrote:I believe the PDP-10 DECtape images that are floating around the web may not be accurate transcriptions.All the images are 289KB long. An 18b (36b) DECtape consists of 18b words in a 32b container (a 36b word in a 72b container). Thus, each 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. Therefore, the unage length, in KB, should equal the number of blocks, which is 578. And in fact, all extent 18b PDP DECtape images are 578KB long.A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the image length, in KB, should equal half the number of blocks, or 578 / 2 = 289. And that's what we have.This is confirmed by the fact that if you let the simulator "autosize" the 289KB images, it comes up with PDP-11 format.I verified, by patching the simulator, that there is data in both halves of each 32b word in the image. This too points to a PDP-11 image.Even if the PDP-10 DECtape were packed with no padding, it should be 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images were transcribed on a TC11 and are missing 2b in every 18b.This is not to say that the TD8E simulator is correct. I cannot get it to zero (initialize) a fresh 18b DECtape through PIP10, so something is broken. However, the TD8E is so arcane that it will take a considerable period of time to figure out what the software is trying to do and why the simulator is responding incorrectly./Bob _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
