Re: Nine track file marks, Burroughs
> I can't say that I've ever observed that, but then, I probably never > looked for it either. 80 bytes starting with HDRx, etc. is a pretty > good indicator of the nature of the block. I've seen lots of tapes > with 81-character records, however. (Univac 36 bit systems for > example). Drat. I was hoping you'd have this answer. ;) Looking for filemark-less transitions either way between 80-byte records with known label names, and other kinds of records, is what my detector script for this does. De
Re: Nine track file marks, Burroughs
On 1/9/21 4:23 PM, Jon Elson via cctalk wrote: > On 01/09/2021 04:59 PM, Dennis Boone via cctalk wrote: >> Jon, >> >> >> >> Yes, you could. The Burroughs doc seems to say the FM is supposed to be >> there between every group of labels and the preceding or following data, >> though. >> > Well, then the only thing you can do is Magna-See or one of the dry > magnetic viewers. I can't say that I've ever observed that, but then, I probably never looked for it either. 80 bytes starting with HDRx, etc. is a pretty good indicator of the nature of the block. I've seen lots of tapes with 81-character records, however. (Univac 36 bit systems for example). --Chuck
Re: PDP-11/34 /04 power knob anyone?
This might be a reasonable stand-in for now: https://www.millsupply.com/knob-fan-speed-grumman-olson-53777.php?p=324629 > On Jan 9, 2021, at 4:25 PM, Fritz Mueller wrote: > > >> On Jan 9, 2021, at 3:54 PM, Bill Degnan wrote: >> 3d-printable? > > It would seem so. I don’t have one to measure, though, and I haven’t seen > any 3d models online yet. I could probably eyeball it, but anybody have one > and care to measure? > > Does the original have a brass bushing? > >
Re: PDP-11/34 /04 power knob anyone?
> On Jan 9, 2021, at 3:54 PM, Bill Degnan wrote: > 3d-printable? It would seem so. I don’t have one to measure, though, and I haven’t seen any 3d models online yet. I could probably eyeball it, but anybody have one and care to measure? Does the original have a brass bushing?
Re: Nine track file marks, Burroughs
On 01/09/2021 04:59 PM, Dennis Boone via cctalk wrote: Jon, Yes, you could. The Burroughs doc seems to say the FM is supposed to be there between every group of labels and the preceding or following data, though. Well, then the only thing you can do is Magna-See or one of the dry magnetic viewers. Jon
Re: PDP-11/34 /04 power knob anyone?
3d-printable? I made an IMSAI paddle with my 3d printer. Works great. On Sat, Jan 9, 2021, 6:11 PM Fritz Mueller via cctalk wrote: > Hi folks, > > I’m working on an 11/34 at the moment, with the programmer’s console, and > it is missing its front panel power control knob. I think it is the same > one used on the 11/04? Anybody have a spare in their parts stock that > they’d be willing to part with? > > (I’m also missing the plastic half-panel for the front, but I do see those > go by on eBay from time to time.) > > cheers, > —FritzM. > > >
PDP-11/34 /04 power knob anyone?
Hi folks, I’m working on an 11/34 at the moment, with the programmer’s console, and it is missing its front panel power control knob. I think it is the same one used on the 11/04? Anybody have a spare in their parts stock that they’d be willing to part with? (I’m also missing the plastic half-panel for the front, but I do see those go by on eBay from time to time.) cheers, —FritzM.
Re: Nine track file marks, Burroughs
Jon, Thanks for your thoughts. > Your tape dump looks very much like a classic ANSI tape label format, > except for the missing file mark after the HDR2 record. Are ALL > those file marks after HDR2 missing, or just some of them? Right, and they're supposed to be ANSI69ish, though they are in EBCDIC. No, not all of them are missing, not even if one "compresses" out some of the "obvious" ones along the lines of your example. > I can see it being quite reasonable for there to be no file mark > after HDR2, if you were going to write your own format. That > specific FM is just not actually needed if you KNOW the first data > record follows HDR2. So, the format could be : Yes, you could. The Burroughs doc seems to say the FM is supposed to be there between every group of labels and the preceding or following data, though. De
Re: Nine track file marks, Burroughs
On 01/09/2021 03:20 PM, Dennis Boone via cctalk wrote: Folks, I've now seen two Burroughs tapes where some of the expected file marks between labels and file data were apparently missing. NRZI file marks are only a couple flux changes, drives that have squelch logic to suppress unstable read amps could easily miss them. PE file marks have preamble and postamble clock data, and it should be quite hard for them to just disappear. Now, one little detail is not all formatters followed the specs for interrecord gaps. The NRZI spec required insanely huge gaps, likely designed for very early capstan and pinch roller drives. The gaps were several times the size of common data records. Many later formatters cheated on this and used much smaller gaps. Some formatters might miss a file mark due to incompatibility of the gaps. But, that seems less likely at 1600 BPI, I think the required gap was reduced in the standard. Your tape dump looks very much like a classic ANSI tape label format, except for the missing file mark after the HDR2 record. Are ALL those file marks after HDR2 missing, or just some of them? I can see it being quite reasonable for there to be no file mark after HDR2, if you were going to write your own format. That specific FM is just not actually needed if you KNOW the first data record follows HDR2. So, the format could be : VOL1 HDR1 HDR2 data data FM HDR1 HDR2 data data FM etc. I can't say I have actually encountered such a tape before, but I wouldn't be surprised. But, of course, that would not be fully ANSI compatible. Jon
Re: Re: Got DSM-11 running, any manuals online?
ftp://ftp.intersystems.com/pub/msm/docs/msm43/users.pdf is another source for a manual. It's the version which Micronetics sold, of which I heard "Micronetics shamelessly copied DSM-11 practically line for line to the PC." So the manual is probably close enough to work. HTH,Dick
Re: cc:Mail Router for NT
Hi again everybody, Apparently the router program ignores the baud parameter when the `PBX' option is used (or maybe it is the phase of the moon), so I am specifying the serial port speed using the DOS `mode' command, before starting the router. Here is the output: | C:\CCMAIL\Router>C:\CCMAIL\Router\NTROUTER.EXE C:\CCDATA COM1 MODEM/PBX | cc:Mail NT ROUTER Version 6.10.00.4 | Copyright (c) 1986, 1997 by cc:Mail, Inc., a wholly owned subsidiary of | Lotus Development Corporation. All rights reserved. This software is subject | to the Lotus Software Agreement, Restricted Rights for U.S. government users, | and applicable export regulations. | | Press Esc to terminate cc:Mail ROUTER program. | Waiting to receive messages... | 9/1/21 21:10 Answering call... 2 4 7 ff 68 c4 | Packets enabled. | Handshake recvd. | Data connection not requested. | Bad Packet Summary -- Naks sent: 0 recv: 0 Retrans: 0 | 9/1/21 21:10 Ending connection. | Waiting to receive messages... | 9/1/21 21:10 Answering call... 2 4 7 ff 68 c4 | Packets enabled. | Handshake recvd. (roughly here, the Palmtop displays the message "could not connect") | Data connection not requested. | Bad Packet Summary -- Naks sent: 0 recv: 0 Retrans: 0 | 9/1/21 21:11 Ending connection. | Waiting to receive messages... What is it I am missing? Is there nobody here who remembers this stuff? It's only been twenty years. /Tomas On Wed, 23 Dec 2020 14:09:24 +0100, Tomas By via cctalk wrote: > Hi all, > > I'm using a HP 200LX to connect to a cc:Mail installation, with a null > modem cable. It has worked better before, but now I don't seem to be > able to connect at all. [...]
Nine track file marks, Burroughs
Folks, I've now seen two Burroughs tapes where some of the expected file marks between labels and file data were apparently missing. I think a reasonable description of these is "Burroughs/Unisys B6x00 'Library/Maintenance' tapes with ANSI-69 labels" Reading drive is a Cipher GCR Cachetape with SCSI interface The one I read yesterday read in streaming mode and reported no read errors. I tried re-reading it today, and it read in start-stop mode, but still didn't have the missing file marks. (It also encountered a few errors, and eventually ended up sticking to the head, this time. Guess that bake cycle was a one-shot, which isn't a surprise.) This tape is a "Burroughs Series 7 / 100% Tested / 3200 FCI" 1200 foot reel written at 1600 BPI in 1986. Here's the beginning of the tape: file 1 record 1 size 80 : e5 d6 d3 f1 f0 f3 f6 f1 f3 f0 40 d7 d9 d6 c7 d9 VOL1036130 PROGR 0010: c1 d4 40 40 40 40 40 40 40 40 40 40 f6 f5 f3 f0 AM 6530 0020: f3 f0 f5 f0 f3 40 40 40 40 40 40 40 40 40 40 40 30503 0030: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 0040: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 f1 1 file 1 record 2 size 80 : c8 c4 d9 f1 c6 c9 d3 c5 f0 f0 f0 40 40 40 40 40 HDR1FILE000 0010: 40 40 40 40 40 d7 d9 d6 c7 d9 c1 f0 f0 f0 f1 f0 PROGRA00010 0020: f0 f0 f1 f0 f0 f0 f1 f0 f0 40 f8 f6 f2 f0 f2 40 001000100 86202 0030: f8 f6 f2 f3 f2 40 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 86232 00 0040: f0 f0 f0 40 c1 f9 40 40 40 40 40 40 40 40 40 40 000 A9 file 1 record 3 size 80 : c8 c4 d9 f2 e4 f0 f1 f0 f2 f4 f0 f1 f0 f2 f4 f3 HDR2U01024010243 0010: f0 f1 f0 f1 f0 f0 f0 f0 f3 f0 f0 f0 f0 f0 f0 f0 01013000 0020: f0 f0 f0 f0 f0 f6 f4 f0 f0 f1 f3 40 f0 f0 f6 f4 0640013 0064 0030: 40 40 f0 f6 40 40 40 40 40 40 40 40 40 40 40 4006 0040: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 file 1 record 4 size 2070 : 40 00 00 00 00 01 00 00 00 00 00 00 12 03 03 04 ... ...etc. Is oddness with file marks something others have seen with Burroughs tapes? Something the Cipher drive is known for? Moon phase? Incorrect fifth digit of my SSN? I've not had this missing file mark problem with tapes written on other vendors systems - Prime, IBM, DEC. Cluebats appreciated. De
Re: Stride computers, was Re: Rod Coleman's personal history of founding, building & running SAGE
On 2021-01-03 05:18, Jos Dreesen via cctalk wrote: Hello Jos, I saw on a German web, that you're planing on a SAGE II remake? Still toying with it? Cheers
Re: Got DSM-11 running, any manuals online?
On Sat, Jan 9, 2021 at 12:08 PM David Gesswein via cctech < cct...@classiccmp.org> wrote: > To possibly be clearer the image of the disk was a raw dump of the disk > taken with the mfm emulator/reader board so it sees all the extra data the > controller puts on the disk and the bad sectors etc. As far as I know no > documentation exists of the low level format and revector table etc. For > RQDX3 the controller has extra information at the beginning of the disk so > mounting the raw image under SIMH doesn't work. The RQDX2 apperently puts > its > information at the end. Might be possible to reverse engineer the format > if we get sector dump from the host to compare to the raw disk dump. > Nobody > has decided to tackle that. > > For the dump of my RD53 on Vaxstation RQDX3 head 0 sectors 0-2 are normal, > 3-16 are funny format. Head 1 and 2 are all funny format. Head 3 sectors > 0-2 are funny format. Removing those didn't work for me if I got my > dd commands correct. > DEC standard 144 of any help? http://bitsavers.org/pdf/dec/standards/EL-00144_B_DEC_STD_144_Disk_Standard_for_Recording_and_Handling_Bad_Sectors_Nov76.pdf Warner On Fri, Jan 08, 2021 at 09:29:19PM -0500, Chris Zach wrote: > > If so, then that's probably what the RQDX1/2 format *was*: Just a big > bunch > > of 512 byte blocks, starting at zero and going up to the top. > > > > The controller had to know the geometry of the drive in order to move the > > heads, know how many cylinders there were, etc. One thing I did notice is > > the last cylinder of the disk is not formatted like the others and > throws a > > bunch of errors on the MFM_READ command on all tracks. It's possible that > > the controller checks there first, then consults the ROM based lookup > tables > > to get the proper disk geometry. Which explains why some controllers > > supported RD51,52 and later ones supported the 53 but none supported the > 54. > > > > On the RQDX3 formatted disks, the first few tracks are also in a weird > > format, it's possible that is where the controller stores the > > head/cyl/sector format information. Note that a RQDX3 disk image does not > > seem to be able to connect up to the RQ driver like the RQDX2 one. > > > > Interesting stuff. I'm guessing if you remove the first couple of tracks > > from the file one could then read the rest of the disk on SIMH (as the > rest > > is probably just a big pile of blocks and that's all that matters to > SIMH) > > unless there are remapped sectors in which case I have no idea how those > > would work. > > > > Fun stuff. > > C > > > > On 1/8/2021 8:54 PM, Eric Smith via cctalk wrote: > > > On Fri, Jan 8, 2021 at 6:16 PM Chris Zach > wrote: > > > > > > > True, however SIMH has to write things to a "real" file that emulates > > > > something of a disk. > > > > > > > > > > I thought the SIMH representation of an MSCP disk was just a linear > array > > > of 512-byte blocks, from block 0 to block n-1, in which case, it's > still > > > not at all surprising that any RQDXn, or any other MSCP disk with the > > > standard Unibus/Qbus MSCP port interface would "just work". > > > > > > If I'm wrong about how the disk is represented by SIMH, then maybe it > could > > > be more surprising. > > > > > > > > > -- >
Re: Got DSM-11 running, any manuals online?
To possibly be clearer the image of the disk was a raw dump of the disk taken with the mfm emulator/reader board so it sees all the extra data the controller puts on the disk and the bad sectors etc. As far as I know no documentation exists of the low level format and revector table etc. For RQDX3 the controller has extra information at the beginning of the disk so mounting the raw image under SIMH doesn't work. The RQDX2 apperently puts its information at the end. Might be possible to reverse engineer the format if we get sector dump from the host to compare to the raw disk dump. Nobody has decided to tackle that. For the dump of my RD53 on Vaxstation RQDX3 head 0 sectors 0-2 are normal, 3-16 are funny format. Head 1 and 2 are all funny format. Head 3 sectors 0-2 are funny format. Removing those didn't work for me if I got my dd commands correct. On Fri, Jan 08, 2021 at 09:29:19PM -0500, Chris Zach wrote: > If so, then that's probably what the RQDX1/2 format *was*: Just a big bunch > of 512 byte blocks, starting at zero and going up to the top. > > The controller had to know the geometry of the drive in order to move the > heads, know how many cylinders there were, etc. One thing I did notice is > the last cylinder of the disk is not formatted like the others and throws a > bunch of errors on the MFM_READ command on all tracks. It's possible that > the controller checks there first, then consults the ROM based lookup tables > to get the proper disk geometry. Which explains why some controllers > supported RD51,52 and later ones supported the 53 but none supported the 54. > > On the RQDX3 formatted disks, the first few tracks are also in a weird > format, it's possible that is where the controller stores the > head/cyl/sector format information. Note that a RQDX3 disk image does not > seem to be able to connect up to the RQ driver like the RQDX2 one. > > Interesting stuff. I'm guessing if you remove the first couple of tracks > from the file one could then read the rest of the disk on SIMH (as the rest > is probably just a big pile of blocks and that's all that matters to SIMH) > unless there are remapped sectors in which case I have no idea how those > would work. > > Fun stuff. > C > > On 1/8/2021 8:54 PM, Eric Smith via cctalk wrote: > > On Fri, Jan 8, 2021 at 6:16 PM Chris Zach wrote: > > > > > True, however SIMH has to write things to a "real" file that emulates > > > something of a disk. > > > > > > > I thought the SIMH representation of an MSCP disk was just a linear array > > of 512-byte blocks, from block 0 to block n-1, in which case, it's still > > not at all surprising that any RQDXn, or any other MSCP disk with the > > standard Unibus/Qbus MSCP port interface would "just work". > > > > If I'm wrong about how the disk is represented by SIMH, then maybe it could > > be more surprising. > > > > > --
Dilog SQ703 Manual anybody?
I'd like to get a Dilog SQ703 I have to work on my microvax, does anybody know where I can get a copy of the manual? 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
Re: Got DSM-11 running, any manuals online?
> On Jan 8, 2021, at 8:57 PM, Eric Smith via cctalk > wrote: > > On Fri, Jan 8, 2021 at 6:17 PM Paul Koning wrote: > >> Yes, but also to hide bad blocks. So the difference between a raw sector >> dump and a SIMH container file is, minimally, the spare sectors. What that >> looks like depends on the format; I have no idea what MSCP controllers did. >> > > MSCP controllers do the bad block mapping, so AFAIK the disk _always_ looks > to the host like a linear array 0..n-1 of 512-byte blocks. Yes. But perhaps I misunderstood; I thought the note to which I was replying described taking a raw dump of the disk itself, not a logical copy via the MSCP controller. paul
Re: ICL PERQ 2 T2 Micropolis 1303 spinning down.
Den lör 2 jan. 2021 kl 19:34 skrev David Gesswein via cctech < cct...@classiccmp.org>: > This is my info on RD53 sticking heads. Your symtoms match what I have seen > with this drive. > > If the heads are stuck to the rubber bumper the drive will spin back down > when it finds the heads won't move. It will also spin down if it can't > switch from the coarse speed control loop to using the head servo signal. > There is a narrow band where the heads are parked with the proper signal. > When the rubber has deteriorated the heads are no longer over it. Adding > shims > can fix that. I used a tent with RK05 filter but others have opened drives > in reasonably clean locations sucessfully. Best to keep the pets away. > The "shim" method worked fine. The drive spun up and I managed to dump it. Imade six dumps and the same five sectors were bad on every read I did. So now I have a nice dump of the PERQ 2 system. Wonder what it is on it? I see things like : - ! LoadDisk.Cmd ! Copyright (C) 1983, 1984 - Perq Systems Corporation. ! Abstract: ! Load version G.6 of POS onto the hard disk. so there is some PERQ stuff there at least. > > http://www.pdp8online.com/rd53/rd53.shtml > > Shim picture. > http://www.pdp8online.com/rd53/pics/lock.shtml?small > > > On Sat, Jan 02, 2021 at 02:05:11PM +0100, Mattis Lind wrote: > > Den l?r 2 jan. 2021 kl 11:48 skrev Rob Jarratt < > robert.jarr...@ntlworld.com > > >: > > > > > When that has happened to MFM disks of mine it has been because for one > > > reason or another the heads have not moved and found track 0. Why they > > > aren't moving could be more than one reason. They could be stuck, or > there > > > could be some other problem that is preventing them getting the power > > > needed to move. > > > > > > > Did you solve the problem? How? > > > > I have heard that Micropolis 1325 is prone to have a problem with a > rubber > > bumper that sticks to the head mechanism. Maybe it is the same for this > > Micropois drive? What resolutions are there to this type of problem? > > > > /Mattis > > > > > > > > > > Regards > > > > > > Rob > > > > > > > -Original Message- > > > > From: cctalk On Behalf Of Mattis > Lind > > > via > > > > cctalk > > > > Sent: 02 January 2021 08:59 > > > > To: General Discussion: On-Topic and Off-Topic Posts > > > > > > > > Subject: ICL PERQ 2 T2 Micropolis 1303 spinning down. > > > > > > > > I have a nice ICL PERQ 2 T2 that I am going to start working with > now. > > > > > > > > First thing was to try to image the hard drive. It is a Micropolis > 1303. > > > It spins > > > > up but when it reaches what I think the correct speed it immediately > > > spins > > > > down. Usually I think there would be a click and then the heads would > > > > recalibrate. But there is no click and no head movement. > > > > > > > > I really would like to make an image of the drive. What are your > > > thoughts? > > > > Are the heads sticking? > > > > Some kind of solenoid that is not releasing the heads? Not properly > up to > > > > speed? (but it sounds like the speed is right) > > > > > > > > /Mattis > > > > > > > > > > > > -- >
