From: Timothy Stark Subject: Disk format specs need Newsgroups: alt.sys.pdp10 User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16 (i686)) Lines: 20 Message-ID: NNTP-Posting-Date: Fri, 11 Aug 2000 21:25:39 CDT Organization: Giganews.Com - Premium News Outsourcing X-Trace: sv2-NiY7I6DYFeSdeYQkfv66jdXN4jvcePoqc/ZVfk7ScaWbcBN+YOzA/hcvNB5Qy8blugt2nRTT/3+WJE5!7jKD/BLP6qALjq8xJOh0MhQbOqY= X-Complaints-To: abuse@GigaNews.Com X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly Date: Sat, 12 Aug 2000 02:25:39 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.seicom.net!news.ruhr-uni-bochum.de!news.tmr.net!news.vew-telnet.net!do.de.uu.net!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!diablo.theplanet.net!newsfeed.skycache.com!Cidera!portc01.blue.aol.com!nntp2.giganews.com!nntp3.giganews.com!news6.giganews.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:20 Hello Folks: I learned that disk image had not formatted but contains just all zeros. That cause big problems because TOPS-10 is trying to initialize disk. Ok, I am looking for disk format specifications like disk map, etc. I do not have DDRPI to format a disk image. :-( No, I do not have ONCDSK.MAC that contains information like fsck. Only I have ONCMOD.MAC in TOPS-10 v7.04. Thank you! -- Tim Stark -- Timothy Stark <>< Inet: sword7@speakeasy.org, sword7@firesword7.net -------------------------------------------------------------------------- "For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. Amen." -- John 3:16 (King James Version Bible) ###### From: skywriter@my-deja.com Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: Sat, 12 Aug 2000 03:13:02 GMT Organization: Deja.com - Before you buy. Lines: 12 Message-ID: <8n2fbs$m15$1@nnrp1.deja.com> References: NNTP-Posting-Host: 216.126.162.238 X-Article-Creation-Date: Sat Aug 12 03:13:02 2000 GMT X-Http-User-Agent: Mozilla/4.7C-SGI [en] (X11; I; IRIX 6.5 IP20) X-Http-Proxy: 1.0 x63.deja.com:80 (Squid/1.1.22) for client 216.126.162.238 X-MyDeja-Info: XMYDJUIDskywriter Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!erix.ericsson.se!uab.ericsson.se!newsfeed1.telenordia.se!algonet!newspeer.highwayone.net!newspeer.clara.net!news.clara.net!feed2.onemain.com!feed1.onemain.com!xfer13.netnews.com!xfe11.netnews.com!netnews.com!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2 In article , Timothy Stark wrote: > I do not have DDRPI to format a disk image. :-( mmm I haven't heard DDPRI in 22 years... mmm gooood... OH, to run 10 and 11 based 10 diagnostics again! And sit on a H760 on a cold monday morning... Sent via Deja.com http://www.deja.com/ Before you buy. ###### From: Pat Barron Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: 12 Aug 2000 00:06:08 -0400 Organization: Posted via Supernews, http://www.supernews.com Lines: 28 Sender: barron@frogger.telerama.com Message-ID: References: X-Complaints-To: newsabuse@supernews.com X-Newsreader: Gnus v5.3/Emacs 19.34 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.seicom.net!news.ruhr-uni-bochum.de!news.tmr.net!news.vew-telnet.net!do.de.uu.net!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-01!supernews.com!sn-inject-01!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:36 Timothy Stark writes: > I learned that disk image had not formatted but contains just all zeros. > That cause big problems because TOPS-10 is trying to initialize disk. > > Ok, I am looking for disk format specifications like disk map, etc. > I do not have DDRPI to format a disk image. :-( No, I do not have > ONCDSK.MAC that contains information like fsck. Only I have ONCMOD.MAC > in TOPS-10 v7.04. There is something called "FORM" in Tim Shoppa's archive, with a description indicating that it's a KS10 disk formatter. Would this help? In the KSHACK; directory in ITS, there is a program called NSALV that you might want to look at (specifically, the "MARK" routine in that program). This lays down the tracks and sectors for a pack formatted for ITS. I don't know if the DEC format is the same, but it should at least give you an idea of what you need to do. Are you keeping track of sector headers in your RP0x emulation? I don't know if anything in TOPS-10 ever issues a "Read/Write Headers and Data", and if it does, I don't know how TOPS-10 deals with the header format differences between RP0x disks and RMxx disks. I'm not sure what the DEC formatter wants to write in the sector headers (other that the cylinder and sector number, and the FMT22 bit). --Pat. ###### From: "Carl R. Friend" Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: Sat, 12 Aug 2000 10:08:13 -0400 Organization: as little as possible! Lines: 71 Message-ID: <39955A4D.E11A0AD5@prescienttech.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: hhFMAQYN8ylN8C1zw9BG1w70v1/5oAx6E/2+8YXwhO8= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 12 Aug 2000 14:08:15 GMT X-Accept-Language: en X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.29 i586) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:15 G'day gentle people! Tim is looking for format information for his emulator (Good job, there, Tim!) so he can solve his software problems. I'm looking for information about whether any of the -10 OSes ever used the two "Key" words (16-bit) in the headers of each sector. In any event, the RP06 header format (at a physical level) looks like this [1]: 39 octets of zeroes 1 octet of sync (10011000) 2 octets of "desired cylinder address" and the format bit 2 octets of "desired sector/track address" 2 octets of "Key Field #1" 2 octets of "Key Field #2" 2 octets of header CRC 11 octets of zeroes 1 octet of sync (10011000) The data field - this is either 512 octets (for 16-bit format) or 576 octets (for 18-bit format) 4 octets of data CRC 2 octets of zeroes a gap leading up 'til the next sector pulse The manual states that Key Fields 1 and 2 are available for the programmer to use, provided that the Read/Write Format commands are used. This, of course, implies that reformatting was possible at the sector level, on the fly. My question is, in short: "Do any of the -10-based (or -11-based OSes, for that matter) make use of these "Key Fields"? An ancillary question to that is: "How do the bits in RHXKON and RPXKON get called?" I don't see any direct calls to things like RPXWTF, RPXRED, and the like. Oh, yes, and another, lust to make me look like a fool: "How does this fragment assemble, and where does it end up?: TRNE T4,CS.NXD ;NON-EX DRIVE? JRST [MOVEI T1,CS.CLR ;YES MUST CLEAR CONTROLLER WRIOB T1,.DOCS2(P1) JRST .+1] ;GIVE INTERRUPT TO FILSER HRLI T2,(T4) My current guess is that the stuff in the brackets gets stuffed off someplace else then returns to the HRLI instruction allowing the TRNE to skip the pile.... (My thanks to the chap who wrote this bit.... ;-) ) [1] Source: "RP05/06 device control logic maintenance manual" Part nr. EK-RP056-MM-001 (C) 1975 Digital -- +------------------------------------------------+---------------------+ | Carl Richard Friend (UNIX Sysadmin) | West Boylston | | Minicomputer Collector / Enthusiast | Massachusetts, USA | | mailto:crfriend@ma.ultranet.com +---------------------+ | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | +------------------------------------------------+---------------------+ ###### From: Timothy Stark Subject: Re: Disk format specs need Newsgroups: alt.sys.pdp10 References: User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16 (i686)) Lines: 33 Message-ID: <_1dl5.26001$wX5.410671@news5.giganews.com> NNTP-Posting-Date: Sat, 12 Aug 2000 09:19:38 CDT Organization: Giganews.Com - Premium News Outsourcing X-Trace: sv2-BvRb+zvxaVPlbz+d5LyR31srS6YUgdAWTdI02EyMrOWweu4aCciyJe2XZ5u2sV/K/HEEKGB4DliQyvg!E5ANmitwcGMlooJmRcGZ5+3jIV0= X-Complaints-To: abuse@GigaNews.Com X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly Date: Sat, 12 Aug 2000 14:19:38 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!newsfeed.direct.ca!look.ca!novia!nntp2.giganews.com!nntp3.giganews.com!news5.giganews.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:22 Pat Barron wrote: > There is something called "FORM" in Tim Shoppa's archive, with a > description indicating that it's a KS10 disk formatter. Would this > help? Yes, I have it but I have a problem with backup software. On Linux platform, I tried to list or extract tpc file but... I looked into its content but it looks like RM10B loader format. > In the KSHACK; directory in ITS, there is a program called NSALV > that you might want to look at (specifically, the "MARK" routine > in that program). This lays down the tracks and sectors for a > pack formatted for ITS. I don't know if the DEC format is the same, > but it should at least give you an idea of what you need to do. > Are you keeping track of sector headers in your RP0x emulation? > I don't know if anything in TOPS-10 ever issues a "Read/Write > Headers and Data", and if it does, I don't know how TOPS-10 > deals with the header format differences between RP0x disks > and RMxx disks. I'm not sure what the DEC formatter wants to > write in the sector headers (other that the cylinder and sector > number, and the FMT22 bit). Thank you for information. I will look into that. -- Tim Stark -- Timothy Stark <>< Inet: sword7@speakeasy.org, sword7@firesword7.net -------------------------------------------------------------------------- "For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. Amen." -- John 3:16 (King James Version Bible) ###### Newsgroups: alt.sys.pdp10 From: Daniel Seagraves Subject: Re: Disk format specs need In-Reply-To: <39955A4D.E11A0AD5@prescienttech.com> Message-ID: References: <39955A4D.E11A0AD5@prescienttech.com> Approved: Why bother? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Lines: 75 Date: Sat, 12 Aug 2000 10:43:58 -0500 NNTP-Posting-Host: 198.199.189.6 X-Trace: newsfeed.slurp.net 966094286 198.199.189.6 (Sat, 12 Aug 2000 10:31:26 CDT) NNTP-Posting-Date: Sat, 12 Aug 2000 10:31:26 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.slurp.net!bony.umtec.com!root Xref: chonsp.franklin.ch alt.sys.pdp10:37 On Sat, 12 Aug 2000, Carl R. Friend wrote: > Tim is looking for format information for his emulator (Good job, > there, Tim!) so he can solve his software problems. > > I'm looking for information about whether any of the -10 OSes ever > used the two "Key" words (16-bit) in the headers of each sector. ITS does, it writes to them during the MARK: subtroutine of SALV/NSALV. > 39 octets of zeroes > 1 octet of sync (10011000) > 2 octets of "desired cylinder address" and the format bit > 2 octets of "desired sector/track address" > 2 octets of "Key Field #1" > 2 octets of "Key Field #2" > 2 octets of header CRC > 11 octets of zeroes > 1 octet of sync (10011000) > The data field - this is either 512 octets (for 16-bit format) > or 576 octets (for 18-bit format) > 4 octets of data CRC > 2 octets of zeroes > a gap leading up 'til the next sector pulse This sounds the same (layout at least) to an RP04, which I have some maintenenance manuals for. Don't quote me on that, I'm probably wrong. > The manual states that Key Fields 1 and 2 are available for the > programmer to use, provided that the Read/Write Format commands > are used. This, of course, implies that reformatting was possible > at the sector level, on the fly. No - The RP04 manuals says that if you format a track you have to do the whole track in one shot, or it will screw up the adjacent sectors to the one you format. (IIRC. I may have to go home and check this...) Also, I dunno if WRITE FORMAT will rewrite the sync pulses/etc, can anyone say? > My question is, in short: "Do any of the -10-based (or -11-based > OSes, for that matter) make use of these "Key Fields"? ITS formats them... Dunno if it uses them for anything tho. > An ancillary question to that is: "How do the bits in RHXKON and > RPXKON get called?" I don't see any direct calls to things like > RPXWTF, RPXRED, and the like. I have no idea. > Oh, yes, and another, lust to make me look like a fool: "How > does this fragment assemble, and where does it end up?: > > TRNE T4,CS.NXD ;NON-EX DRIVE? > JRST [MOVEI T1,CS.CLR ;YES MUST CLEAR CONTROLLER > WRIOB T1,.DOCS2(P1) > JRST .+1] ;GIVE INTERRUPT TO FILSER > HRLI T2,(T4) > > My current guess is that the stuff in the brackets gets stuffed > off someplace else then returns to the HRLI instruction allowing > the TRNE to skip the pile.... (My thanks to the chap who wrote > this bit.... ;-) ) That's how I'd guess, at least. "Confuse, annoy, and DEE-STROY!" -- Jet Wolf | "Nothing Happens." -- ADVENT "You'd be surprised what you can live through..." -- Anonymous "...A man can pass his family and his name down through his sons, but it's his honour that gets passed through his daughters. He can see the best and worst of life in his girls. A daughter is something far too precious, and he'll do anything to protect her." -- Reichsfuehrer Siegfried Koenig, _Matrose_Mond_, David Oliver ###### From: Sean Case Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: Sun, 13 Aug 2000 08:08:13 +1000 Organization: Marginal Lines: 51 Message-ID: References: <39955A4D.E11A0AD5@prescienttech.com> NNTP-Posting-Host: cartman4.zip.com.au X-Trace: nina.pacific.net.au 966118134 27364 61.8.20.132 (12 Aug 2000 22:08:54 GMT) X-Complaints-To: abuse@pacific.net.au NNTP-Posting-Date: Sat, 12 Aug 2000 22:08:54 +0000 (UTC) User-Agent: MT-NewsWatcher/3.0 (PPC) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!nyc-news-feed1.bbnplanet.com!news.gtei.net!colt.net!newspeer.clara.net!news.clara.net!newsfeed1.swip.net!swipnet!newsfeed.zip.com.au!news.syd.pacific.net.au!gsc Xref: chonsp.franklin.ch alt.sys.pdp10:51 In article <39955A4D.E11A0AD5@prescienttech.com>, "Carl R. Friend" wrote: > [...] lust to make me look like a fool: [I know this is a typo, but it's just such a beautiful phrase...] > "How > does this fragment assemble, and where does it end up?: > TRNE T4,CS.NXD ;NON-EX DRIVE? > JRST [MOVEI T1,CS.CLR ;YES MUST CLEAR CONTROLLER > WRIOB T1,.DOCS2(P1) > JRST .+1] ;GIVE INTERRUPT TO FILSER > HRLI T2,(T4) > My current guess is that the stuff in the brackets gets stuffed > off someplace else then returns to the HRLI instruction allowing > the TRNE to skip the pile.... (My thanks to the chap who wrote > this bit.... ;-) ) Zigackly. Square brackets introduce a "literal"; the contents are assembled elsewhere, and the value of the literal expression is the address of where the contents wound up. It's handy for constants that do not fit into the original instruction; instead of MOVEI A,some constant you can do MOVE A,[some constant] in case the constant is more than 18 bits. But because a literal can be several lines, it's also handy for inserting the odd quick routine like the one above, where several instructions need to be controlled by a single skip instruction (or skip return). I seem to recall it was a common pattern for handling error returns from TOPS-10 UUOs. Note that while the literal is being assembled, "." still has the value from the outer level, so you can jump back as shown in your example above. Sean Case -- Sean Case gsc@zipworld.com.au Code is an illusion. Only assertions are real. ###### From: inwap@best.com (Joe Smith) Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: 13 Aug 2000 08:41:15 GMT Organization: Chez Inwap Lines: 109 Message-ID: <8n5mvb$14n3$1@nntp1.ba.best.com> References: <39955A4D.E11A0AD5@prescienttech.com> NNTP-Posting-Host: shell3.ba.best.com X-Trace: nntp1.ba.best.com 966156075 37603 206.184.139.134 (13 Aug 2000 08:41:15 GMT) X-Complaints-To: abuse@best.com NNTP-Posting-Date: 13 Aug 2000 08:41:15 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.seicom.net!news.ruhr-uni-bochum.de!news.tmr.net!news.vew-telnet.net!do.de.uu.net!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xfer13.netnews.com!xfe11.netnews.com!netnews.com!newshub2.rdc1.sfba.home.com!news.home.com!news2.best.com!nntp1.ba.best.com!inwap Xref: chonsp.franklin.ch alt.sys.pdp10:45 In article <39955A4D.E11A0AD5@prescienttech.com>, Carl R. Friend wrote: > G'day gentle people! > > Tim is looking for format information for his emulator (Good job, >there, Tim!) so he can solve his software problems. Yes, I agree, Tim deserves a lot of "atta boy!"s for all his work. I don't believe that Tim should be emulating an RP06 at the raw bit level. That would be a waste. What TOPS-10 wants to see is a perfect RP06 (or at least one with a reasonable number of bad blocks (unreadable sectors)). Possible emulations: 815 cylinders, each with 19 heads and 22 sectors. Requires explicit selection of cylinder, then head and finally sector. 815 cylinders of 418 sectors each. Requires explicit seek command to change cylinder; once positioned on cylinder, can select any head and any sector on that track. Implies that doing I/O on consecutive sectors can switch heads automatically, and continue to the end of the current cylinder. 15485 tracks with 22 sectors per track. Cylinder and head are selected together, then requested sector(s) can be transfered. Implies that I/O cannot go past the end of track. 340670 sectors (logical block addressing, ignoring cylinder boundaries) Similar to SCSI disk block addressing. This is the logical model you want if the disk controller is capable of performing transfers that cross cylinder boundaries. > I'm looking for information about whether any of the -10 OSes ever >used the two "Key" words (16-bit) in the headers of each sector. > > In any event, the RP06 header format (at a physical level) looks >like this [1]: > >39 octets of zeroes >1 octet of sync (10011000) >2 octets of "desired cylinder address" and the format bit >2 octets of "desired sector/track address" >2 octets of "Key Field #1" >2 octets of "Key Field #2" >2 octets of header CRC >11 octets of zeroes >1 octet of sync (10011000) > The data field - this is either 512 octets (for 16-bit format) > or 576 octets (for 18-bit format) >4 octets of data CRC >2 octets of zeroes > a gap leading up 'til the next sector pulse > > The manual states that Key Fields 1 and 2 are available for the >programmer to use, provided that the Read/Write Format commands >are used. This, of course, implies that reformatting was possible >at the sector level, on the fly. That is at the physical level, and I sincerely hope that Tim is not attempting to emulate the bits on a disk track at the physical level. Carl, the Write Format command starts at the index mark (a pulse sent out once per revolution) and continues until the next index mark. That is, it rewrites the entire track. [Side comment: The Amiga used this mode of operation. If you wanted to write out one disk block to floppy, it would read in the entire track (if it was not in the trackdisk cache already) modify the 512 bytes in memory, then write out the entire track (with no inter-record gaps). This allowed 11 blocks per track when other disk formats were getting 8 or 9 per track.] > My question is, in short: "Do any of the -10-based (or -11-based >OSes, for that matter) make use of these "Key Fields"? I believe that only IBM's original ISAM for S/360 ever used the Key fields. Instead of telling the disk controller which particular sector you wanted, you told it "find the sector on this track that has a Key value greater than or equal to this particular 16-bit value". The technique of letting the disk controller do database record searching had a short live; it was quickly replace by VSAM. DEC's COBOL had a thing called ISAM, but it really was the TOPS-10 implementation of VSAM. > Oh, yes, and another, lust to make me look like a fool: "How >does this fragment assemble, and where does it end up?: > > TRNE T4,CS.NXD ;NON-EX DRIVE? > JRST [MOVEI T1,CS.CLR ;YES MUST CLEAR CONTROLLER > WRIOB T1,.DOCS2(P1) > JRST .+1] ;GIVE INTERRUPT TO FILSER > HRLI T2,(T4) > > My current guess is that the stuff in the brackets gets stuffed >off someplace else then returns to the HRLI instruction allowing >the TRNE to skip the pile.... (My thanks to the chap who wrote >this bit.... ;-) ) Yep. Literals were stored in the literal pool, an unspecified location that the assembler kept track of. The literal pool was dumped when the assembler hit the END statement or the LIT statement. This assigned addresses to the saved words (which would show up in the CREF listing). While building a literal, "." refered to the location counter where the literal definition was started, therefore ".+1" is the word after the first JRST above. Interesting note: Words were entered into the literal pool only if there was not a matching entry there already. Therefore if you had 10 lines in the form MOVE T1,[1,,2] you'd end up with 10 references to a single word containing 000001000002. -Joe -- See http://www.inwap.com/ for PDP-10 and "ReBoot" pages. ###### From: "Carl R. Friend" Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: Sun, 13 Aug 2000 08:51:27 -0400 Organization: as little as possible! Lines: 92 Message-ID: <399699CF.448C6B8F@prescienttech.com> References: <39955A4D.E11A0AD5@prescienttech.com> <8n5mvb$14n3$1@nntp1.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: Rl0kqMNK9kon3lE3OXX04p1JuNDf6rOmE7j6OgqkdXo= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 13 Aug 2000 12:51:29 GMT X-Accept-Language: en X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.29 i586) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:49 Joe Smith wrote: > > I don't believe that Tim should be emulating an RP06 at the raw bit > level. That would be a waste. Tim absolutely should _not_ be emulating a disk at a physical level; it makes no sense at all. However, I'm chasing something a bit different. > What TOPS-10 wants to see is a perfect RP06 (or at least one with a > reasonable number of bad blocks (unreadable sectors)). Since the "disk" in any known emulator will be on a disk which is controlled by an underlying OS (with its own error-correction, &c.) the odds of "bad sectors" approach zero, which is a "good thing" (with apologies to Martha Stewart). Of course, one can simulate bad blocks if desired, but that's merely an exercise. > Possible emulations: > 815 cylinders, each with 19 heads and 22 sectors. > Requires explicit selection of cylinder, then head and finally > sector. 815 cylinders of 418 sectors each. > Requires explicit seek command to change cylinder; once positioned > on cylinder, can select any head and any sector on that track. This is not the model that the DCL on the Massbus uses. I can provide details and cites if anybody is interested. > Similar to SCSI disk block addressing. This is the logical model > you want if the disk controller is capable of performing transfers > that cross cylinder boundaries. This is also not the Massbus "way" of doing things. The Massbus runs on a C/H/S notion and allows both implied seeks and mid-transfer seeks. > Carl, the Write Format command starts at the index mark (a pulse sent > out once per revolution) and continues until the next index mark. > That is, it rewrites the entire track. I'll re-check my doco, but in the books I have the sector pulse is generated by counting di-bits on the servo track (once the index pulse establishes _absolute_ physical location) and the DCL doesn't lose track of it over seeks. That sounds like a "perfect world" scenario, I know, but the manual indicates that it's possible to to rewrite the Key Fields (which implies rewriting the header - i.e. the format) a sector at a time. If this is the case, it's going to have a profound impact on the project I'm working on. > I believe that only IBM's original ISAM for S/360 ever used the Key > fields. Instead of telling the disk controller which particular > sector you wanted, you told it "find the sector on this track that > has a Key value greater than or equal to this particular 16-bit > value". Now _that's_ interesting, and would fit within the model of the Memorex drive being an IBM-compatible device! Dan Seagraves mentions that ITS used the Keys. Can anybody corroborate? If I can dispense with this annoyance, I'd be happy. > The technique of letting the disk controller do database record > searching had a short live; it was quickly replace by VSAM. DEC's > COBOL had a thing called ISAM, but it really was the TOPS-10 > implementation of VSAM. Interestingly, the notion of hardware-based file scanning was reintroduced by Intergraph for their CADD systems. Files had to be contiguously organised to use it, but here's how the thing would work: 1) Identify the beginning of the file (if first look through the file) 2) Identify the extents (CADD design space) in which you want to look for elements (or what type of element you're looking for) 3) Start the File Processor's scanner and wait for it to come back with an element matching your criteria. Of course, you can be doing other things during the wait. Thanks, by the way, for the tips on how literals work! It'll save a lot of confusion the next time I need to dissect code. -- +------------------------------------------------+---------------------+ | Carl Richard Friend (UNIX Sysadmin) | West Boylston | | Minicomputer Collector / Enthusiast | Massachusetts, USA | | mailto:crfriend@ma.ultranet.com +---------------------+ | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | +------------------------------------------------+---------------------+ ###### From: inwap@best.com (Joe Smith) Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: 15 Aug 2000 19:42:09 GMT Organization: Chez Inwap Lines: 17 Message-ID: <8nc6eh$1s24$1@nntp1.ba.best.com> References: <39955A4D.E11A0AD5@prescienttech.com> <8n5mvb$14n3$1@nntp1.ba.best.com> <399699CF.448C6B8F@prescienttech.com> NNTP-Posting-Host: shell3.ba.best.com X-Trace: nntp1.ba.best.com 966368529 61508 206.184.139.134 (15 Aug 2000 19:42:09 GMT) X-Complaints-To: abuse@best.com NNTP-Posting-Date: 15 Aug 2000 19:42:09 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!newsfeed00.sul.t-online.de!t-online.de!newscore.gigabell.net!feeder.via.net!newshub2.rdc1.sfba.home.com!news.home.com!news2.best.com!nntp1.ba.best.com!inwap Xref: chonsp.franklin.ch alt.sys.pdp10:68 In article <399699CF.448C6B8F@prescienttech.com>, Carl R. Friend wrote: > > Tim absolutely should _not_ be emulating a disk at a physical > This is not the model that the DCL on the Massbus uses. I can >provide details and cites if anybody is interested. I should point out that some of my comments were based on working with IBM disks connected to a string controller connected to a disk channel controller connected to an SA-10 connected to a KL. The DCL accomplished the same results in a different manner, but I had very little experience with its internals. Carl knows more about this than I do. -Joe -- See http://www.inwap.com/ for PDP-10 and "ReBoot" pages. ###### From: "Carl R. Friend" Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: Wed, 16 Aug 2000 20:24:29 -0400 Organization: as little as possible! Lines: 28 Message-ID: <399B30BD.BE8FB5DB@prescienttech.com> References: <39955A4D.E11A0AD5@prescienttech.com> <8n5mvb$14n3$1@nntp1.ba.best.com> <399699CF.448C6B8F@prescienttech.com> <8nc6eh$1s24$1@nntp1.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: D5fRZMwjO98n/BtWBiXWH/KCsRSlghonQgqgXdN59vw= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 17 Aug 2000 00:24:30 GMT X-Accept-Language: en X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.29 i586) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.seicom.net!news.ruhr-uni-bochum.de!news.tmr.net!news.vew-telnet.net!do.de.uu.net!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:78 Joe Smith wrote: > > The DCL accomplished the same results in a different manner, but I > had very little experience with its internals. Carl knows more about > this than I do. Thanks for the "vote of confidence"! :-) I was merely asking whether any of DEC's OSes ever used the Key Field information in their operations. Given the IBM heritage, seemingly, I'd sort of doubt it, but one cannot be too careful. Can I rephrase for the moment and ask, "Did TOPS-10 (I dislike that marketing moniker) use the Keys for any purpose, or did the monitor ever make use of the read-format or write-format capabilities of the DLC?" DEC's DCL, and indeed their entire Massbus scheme, was quite the piece of work - remarkable "intelligent" for their time. The whole notion of implied positioning and the ability to do dual formats (sometimes on a single pack!) were amazing things for those days. -- +------------------------------------------------+---------------------+ | Carl Richard Friend (UNIX Sysadmin) | West Boylston | | Minicomputer Collector / Enthusiast | Massachusetts, USA | | mailto:crfriend@ma.ultranet.com +---------------------+ | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | +------------------------------------------------+---------------------+ ###### From: "Carl R. Friend" Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: Sun, 20 Aug 2000 11:06:00 -0400 Organization: as little as possible! Lines: 53 Message-ID: <399FF3D8.51F4A1D4@prescienttech.com> References: <39955A4D.E11A0AD5@prescienttech.com> <8n5mvb$14n3$1@nntp1.ba.best.com> <399699CF.448C6B8F@prescienttech.com> <8nod92$q6t$2@bob.news.rcn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: uxxKCq/TIfO1JJkLuOxNLAybOkN6ujiwCkFYqSMwk8g= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 20 Aug 2000 15:06:02 GMT X-Accept-Language: en X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.29 i586) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:118 jmfbahciv@aol.com wrote: > > But the layout of files on a disk under TOPS10 was not physically > contiguous (I don't know much about this area so if I'm wrong > jump on me, guys). The data of a file (and that includes the > MFD, I think) was laid out so that the geometry of the disk > did NOT impact performance. When the RP04/06 was getting > developed the system contention at that time was disk I/O so > TW made sure that the revolutions during the seeks would be > optimal. This was one area which surprised me greatly - a whole pile of effort went into getting the rotational bits _just_perfect_ and rescheduling other activity if the disk wasn't in the proper angular place. The Massbus drives do a nice bit of magic in this regard using the RPLA (RP Look-Ahead) register in the Massbus adapter (RH-10, RH-20, or RH-11) by reporting the current location in a track down to 1/4 of a sector. That said, my opinion is that it's not going to be too important in an emulator because facilities like that aren't going to be available on most of the OSes the emulator will run on - there's just no way for the process to get that "close" to the iron. Too, most disks these days are LBN (Logical Block Number) addressed rather than C/S/H (Cylinder/Sector/Head) as they were in the bad old days, and may have different numbers of sectors per track. For disks, what one is going to essentially wind up with is a "random" seek time and "rotational delays" that will wander all over the map for any number of reasons (spindle "busyness", OS load, &c.), so all that ingeniousness will be for naught in the -10 monitor as it's running on the emulator. > Heh, I keep forgetting that you guys (including Tim) haven't grown > up using this stuff like I have. It's sorta like breathing to me :-). But we're trying. ;-) How many of the OS programmers remember enough of the minutiae involved to really help out with stuff like this? Sure, the source exists, but do the creators (those that are still with us) remember all the little details of their creation? Surely this loss is rather significant; hopefully some of the design notes (including the failures - "TW in RH-20 Land" springs to mind as a classic example of such things) survive in some archive.... -- +------------------------------------------------+---------------------+ | Carl Richard Friend (UNIX Sysadmin) | West Boylston | | Minicomputer Collector / Enthusiast | Massachusetts, USA | | mailto:crfriend@ma.ultranet.com +---------------------+ | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | +------------------------------------------------+---------------------+ ###### Newsgroups: alt.sys.pdp10 From: mbg@world.std.com (Megan) Subject: Re: Disk format specs need Message-ID: Date: Sun, 20 Aug 2000 22:26:25 GMT References: <39955A4D.E11A0AD5@prescienttech.com> <8n5mvb$14n3$1@nntp1.ba.best.com> <399699CF.448C6B8F@prescienttech.com> <8nod92$q6t$2@bob.news.rcn.net> <399FF3D8.51F4A1D4@prescienttech.com> Organization: The World Public Access UNIX, Brookline, MA Lines: 263 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!209.249.123.233.MISMATCH!xfer10.netnews.com!netnews.com!news.maxwell.syr.edu!korova.insync.net!uunet!ffx.uu.net!world!mbg Xref: chonsp.franklin.ch alt.sys.pdp10:122 "Carl R. Friend" writes: >significant; hopefully some of the design notes (including the >failures - "TW in RH-20 Land" springs to mind as a classic example >of such things) survive in some archive.... Last time I saw it, I grabbed it.. Here is is again... Xref: world alt.sys.pdp10:7078 Path: world!blanket.mitre.org!newsfeed.berkeley.edu!news2.best.com!news3.best.com!nntp1.ba.best.com!not-for-mail Newsgroups: alt.sys.pdp10 Subject: Re: Update again, this one's a good one! References: Organization: Chez Inwap From: inwap@best.com (Joe Smith) Date: 03 Oct 1999 10:50:37 GMT Lines: 245 Message-ID: <37f734fd$0$205@nntp1.ba.best.com> NNTP-Posting-Host: shell3.ba.best.com X-Trace: nntp1.ba.best.com 938947837 205 inwap@206.184.139.134 In article , Daniel Seagraves wrote: >I had to turn off FTRH20 in BOOTM for it to work. It seems on >RH20-equipped systems the EPT is at 777000 for some reason. Did the RH20 >put it up there? BOOTM didn't tell the pager the EPT was 777000, so I >guess it's a default, can anyone shed any light on this? Oh, you've been fighting with the Channel Logout Areas, have you? The first 40 words of the EPT are not adequately documented anywhere. Allow me to re-repost this old article. -Joe Reposted by Rich Alderson on 26-Aug-97. ~From: Mark Crispin ~Newsgroups: alt.sys.pdp10 ~Date: Thu, 8 Jun 1995 18:10:47 -0700 Organization: Networks & Distributed Computing ~References: <3qrnmv$67f@overload.lbl.gov> <3quukm$2cm@infinity.ccsi.com> NNTP-Posting-Host: tomobiki-cho.cac.washington.edu On 8 Jun 1995, Paul Repacholi wrote: >In article powell@pgh.nauticom.net >(Reed Powell) writes: >>problems with channel logout areas, etc. Have you ever read "Tony in RH20 >>Land" by any chance? If so, you should understand the problems you >No, where can I get a copy? hint, hint ;-) You asked for it. See below. -- Mark -- DoD #0105, R90/6 pilot, FAX: (206) 685-4045 ICBM: N 47 39'35" W 122 18'39" Science does not emerge from voting, party politics, or public debate. Tony in RH20 Land - or - I Should Have Listened When Mother Told Me There Was A Great Future In Encyclopedia Sales by Anthony Wachs who once said, "Answer that, it may be the phone." Act 1 - Scene 1 As the scene opens we see our here poring over his brand new copy of the RH20 specification. Even a quick perusal of same shows that there are some quirks in the design. "Golly gee" he explains, "I wonder why they designed it like that?" Among the more obvious problems which spring quickly to the eye are: 1. The channel control words look nothing like the channel control words he has known and loved for so long. Where the DF10 wants -wrdcnt,,address-1 for a transfer of n words into address, the RH20 want flags+wrdcnt,,address. Where the DF10 wants 0,,address to indicate that its next IOWD is from address, when the RH20 sees a construct like that it will stop! The RH20 wants to see 200000,,adr for a goto word - a construct that the DF10 will interpret as "read a whole bunch of words into adr+1". It does appear that the RH20 was designed for a new operating system, one that doesn't have to support old-style hardware. 2. You get an error bit if you try to read or write other than an integral multiple of 200 words in one transfer. Curiouser and curioser - it seems that the device was intended only to work with systems that transfer one page at a time. Oh well, I can ignore that error bit. 3. You can't run the damn thing without turning on paging! There are some wired-down locations that the RH20 wants to talk to, which are the same as the acs if paging isn't on, but strangely enough even though the address is the same as an ac it really isn't an ac - you really have to turn on paging and map the hardwired locations somewhere else. I sure do which they'd let the programming staff know when they are going to have a design review (or did they design this thing without a review?) 4. The attention CONI bit lights if some drive interrupts even though you aren't enabled for attention interrupts. A minor problem, but I remember talking to the RH10 designers for a long time about this point, and we did conclude that it was lots easier to program if the bit would only come up when we were looking for attention interrupts. Sure wish they had talked to the RH10 people before designing this thing. 5. The CONI bits can lie! The CONI can say there were no errors in the last transfer even though there were errors. All isn't lost, however. You can find out that the RH20 has been untruthful by checking somewhere else. That's what we need, schizophrenic hardware! Oh well, with lots of work the existing code can be reworked to add support for this thing. Score: RH20 1; Good Guys 0 Act 1 - Scene 2 Some later point in time, after much cursing and rearranging, our hero has some code which he hopes will come close to working on the shiny new RH20 out on the machine room floor. And so to debuggging.... Oops! After typing in the date and time the monitor crashes with some strange pc. After much fiddling around we discover that the interrupt vector location, very carefully set up at once-only time isn't there anymore. Some judicious experimentation shows that a processor-clear zeros that word in the RH20 logic, and that the following interrupt will take its new-pc value from location 0. Not even ac 0, but the shadow ac location 0 (remember that location which you can only get to by turning on paging?). Score: RH20 2; Good Guys 0 Act 1 - Scene 3 Work out the minor logic bugs, and the thing appears to work! That wasn't so bad. Type "GET SYS:DDT" at the monitor and the machine hangs. Guess I spoke too soon. Remember that error bit which would come on if I tried to read less than 200 words from the RH20? Well, it isn't as clear cut as that - try to read 176 or 177 words from the RH20 and the damn thing hangs forever, never says that it finished. Trying the well loved approach of doing a CONO to clear busy and set done doesn't work. What's that you say? Master RESET of the processor will clear the problem? Wonderful!!! Any other solutions? Yes, don't do it. LCEG comes down with their scopes and other good stuff and analyzes the problem - yes, it certainly does hang the machine solid. "We'll fix the problem when we re-layout that board. No retrofit ECO will be generated". Program around it. Score: RH20 3; Good Guys 0 Act 1 - Scene 4 Well, now that our hero has programmed around that one things seem to be going well. Son of a bitch, there it goes again! Look look, the RH20 is bringing up an error bit, we're trying to clear it, and the bit won't clear. How about that, doing a perfectly legal sequence of instructions to the RH20 causes an unclearable error. Again the LCEG boys come down with their scopes, and after much trial and tribulation they manage to find the badness I'm doing to the RH20. Again, "when we re-layout that board". Solution - don't do it that way. Score: RH20 4; Good Guys 0 Act 2 - Scene 1 The software has now been in the field for a while, all seems well. Our hero even has the nerve to take a well-earned vacation. When he returns he finds out that there was a problem, discovered at sites in the field - the spec implies that the RH20 will always store a particular flavor of termination sequence, and that from this sequence it is easy to find out the last control-word which the RH20 exectued. Well, that's almost true. Except for the case where you have an ecc-correctable error in the middle of a transfer. There there arises the possibility of different stuff in the logout area. Fix it, give a patch to the site, they seem to be happy. Act 2 - Scene 3 (2 weeks later) Spoke too soon again, they have that same loop again! After fiddling around for a while we see that the RH20 can store still another set of numbers in the logout area on ECC errors. Oh well, back to the drawing board. Possibly (but I wouldn't bet on it) all the various flavors of stuff in the logout area has been found and allowed for in the code. Score: RH20 6; Good Guys 0 Act 3 - Scene 1 The RH20 code has been running well for a while, and everyone is beginning to breath easier. The only RP04 on an RH10 on the software development KL is DSKN, the disk used for bootstrapping the monitor. Full of confidence our here proceeds to change the monitor pack to an RH20. It works just fine! Then they fiddle around with the configuration, adding drives to one RH20 and substracting drives from the other. Son of a bitch, here we go again! No only won't the bootstrap read the monitor, but the RH20 is hung again. This time it gets hung up so badly that the only way to clear it is to power down the processor. Clever design isn't it? After fiddling around with this one for a while it is discovered (thanks to LCEG and "don't do it that way") that trying to start data-transfer on a non-existent drive (because it saved code, that's why I did it) confuses the hell out of the RH20. Score: RH20 7; Good Guys 0 Act 4 - Scene 1 Our here has by this time realize that this code is never going to work correctly and that the RH20 will always come up with some wierd method of doing something, so he is prepared when the code which looks at logout areas in order to do something clever stops working. In a rather resigned manner he goes down to hardware engineering to complain. The engineers have an out though. They pull out a memo dated March 1975 which has buried in the middle of the third paragraph the sentence: "Under these conditions the RH20 will ....." Sure enough, it did! It is probably unreasonable of our hero to expect that the documentation he can get fails to mention the problem. Score: RH20 8; Good Guys 0 Act 4 - Scene 2 Someone read the documentation and decided that a good bit to test would be "channel error", which is described as a bit which, if on, says that the M-BOX blew it. Suddenly, mag tapes on RH20's stop working. Our hero heads down to hardware engineering, where they are overjoyed to see him and listen to his problem. After a brief description of the problem they haul out the good old document which describes the device. Way in the back, among the prints of the logic there is a table which describes what error bits come on under which circumstances. Amazingly enough, the bit which is describes as only indicating an M-BOX error is shown to come up under a bewildering array of possible errors, and some conditions which aren't really errors. Oh shit, back to the drawing board! Score: RH20 9; Good Guys 0 (And anyone who believes that this is the last of the problems also believes in virgins, fairies, and inside straights!) ###### From: hmv@port.ac.uk (Mike Meredith at home) Newsgroups: alt.sys.pdp10 Subject: Re: Disk format specs need Date: Mon, 21 Aug 2000 21:34:14 -0700 Organization: Customer of Energis Squared Lines: 27 Sender: mike@port.ac.uk Message-ID: <6svsn8.kc9.ln@lucifer> References: <39955A4D.E11A0AD5@prescienttech.com> <8n5mvb$14n3$1@nntp1.ba.best.com> <399699CF.448C6B8F@prescienttech.com> <8nod92$q6t$2@bob.news.rcn.net> <399FF3D8.51F4A1D4@prescienttech.com> NNTP-Posting-Host: modem-36.aranruth.dialup.pol.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: newsg4.svr.pol.co.uk 967046637 25189 62.136.119.164 (23 Aug 2000 16:03:57 GMT) NNTP-Posting-Date: 23 Aug 2000 16:03:57 GMT X-Complaints-To: abuse@theplanet.net X-Newsreader: knews 1.0b.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!newsfeed.icl.net!diablo.theplanet.net!news.theplanet.net!newspost.theplanet.net!lucifer!nobody Xref: chonsp.franklin.ch alt.sys.pdp10:184 In article <399FF3D8.51F4A1D4@prescienttech.com>, "Carl R. Friend" writes: > This was one area which surprised me greatly - a whole pile of > effort went into getting the rotational bits _just_perfect_ and > rescheduling other activity if the disk wasn't in the proper > angular place. Given how important disk performance is to a proper operating system, it made sense to spend a huge amount of time optimising disk speed. It was probably one of the most important things that seperated a responsive system from a sluggish one. It may be that the same amount of work is still done today, but has moved to a different place ... > most disks these days are LBN (Logical Block Number) addressed > rather than C/S/H (Cylinder/Sector/Head) as they were in the bad > old days, and may have different numbers of sectors per track. A "disk" could be too "intelligent" for the old optimisation techniques to work --- certainly something like only laying down bits when the head is in the right place won't work. Not only do some disks (most?) lie about their geometry (to suit a certain machine firmware's misconceptions about how disks look, or because the geometry is too complex to describe in simple C/S/H terms), but some "disks" may be a box of memory, or a RAID box with dozens of disks and umpteen Mbytes of cache.