- test-drb@ccmp.vtda.org - classiccmp.org

by supervinx＠libero.it

Hi! All the work is done! The printer's gone, but the unit is fully functional. I built a bus terminator and today I found a disk controller able to write FM/SD (the first disk track is always formatted that way) togethet my repaired Siemens FDD200P. I had two disk images (utils and diags) from the Stuttgart Museum, but the utils one appears to be in German language. Do you have an english image of the util disk or other 5120 related software? Thanks!

11 years, 2 months

2
4
0 0

Does anyone here have any information/docs on the Tahoe aka Power 6/32 aka Harris HCX-7/9?

by jnc＠mercury.lcs.mit.edu

> From: Al Kossow > a fairly long article in the Dec 8, 1986 Computerworld Sorry, which page? I looked in that issue for the article using the 'Search' function, but couldn't find it? Noel

11 years, 2 months

3
2
0 0

Altair Turnkey and some DEC stuff cheap

by jnc＠mercury.lcs.mit.edu

> From: Roe Peterson > There is a product, can't remember the name. It's basically dental > floss for dentures, and comes in individual strings about 3 inches long > with a cleaning tip at one end. I found something that sounds like this; it's called "Superfloss" (OralB product); they are about 10" long, with a 6" section in the middle that looks like a miniature pipe cleaner. Speaking of pipe cleaners, I also tried using them. They were a bit too big to get through the space, but there's something called "Chenille Stems" (Fibre Craft product), available in craft stores, which is like a light gauge pipe cleaner, but with longer 'pile'. It won't go through as it, but if you trim the pile, it will go through most slots (there is component variation, and for some blocks, the gap between the block and the PCB is much smaller). > From: Tothwolf > Could you use an aquarium pump and a long airstone / bubbler to help > clean the boards using aeration? I'm not sure that would get off the impacted dirt. (At least, more so than a long soak, and then water jet.) > Or, maybe get in there with a Waterpik? I did try and find a small pressure washer type thing, but the smallest I could find was ... still pretty big. Maybe a Waterpik would be more the backplane's size.. Noel

11 years, 2 months

3
2
0 0

Wanted: ASM-48 for Intellec MDS-2

by fulivi＠tiscali.it

Hi everyone, I'm looking for a dump (or the real floppy!) of the ASM-48 assembler that ran on Intel MDS-2 systems. It seems that it is very rare (maybe it didn't sell too well back in its days). After a few days of googling I still have no idea of the Intel part-number for it. Other assemblers (e.g. ASM80) are much more common. The reason I'm looking for it is to re-implement the firmware in the PIO processor (a 8041A) of the MDS-2 emulator I'm writing for MESS. I thought it would be a nice idea to write the firmware by using the system itself: it is a development system after all! I think I've no hope of finding an image of the original firmware. The original PIO is a masked ROM version that Intel produced for itself. The only way to dump it, I guess, is by decapping and photographing the die. By the way, if you are interested, check my preliminary version of the emulator (imds2 in 0.160 release of MESS): it's not complete (PIO it's not there, for example) but it can run all ISIS-II sw I could find. I hope I'm not "offending" anyone in this forum by mentioning an emulator, it looks like you are mostly focused on real (vintage) hardware.. Just out of curiosity: is there anyone among you who owns a MDS-2 system? Thanks! -- F.Ulivi

11 years, 2 months

6
12
0 0

Does anyone here have any information/docs on the Tahoe aka Power 6/32 aka Harris HCX-7/9?

by krfkeith＠gmail.com

I've checked Bitsavers, but no dice. There didn't appear to be a section for Computer Consoles Inc, the original manufacturer, and there's nothing in either the Harris or the ICL sections (both of which sold rebadged machines). Anyone information you guys might have on this machine would be much appreciated. I'm especially looking for a programming guide, or anything which might provide information on the ISA. I've heard of it being describing as somewhat VAXoid, but I haven't ever seen any reliable information as to what its instruction set actually looked like. The machine is of historical interest for being the first architecture, IIRC, that BSD4.3 was supported on. Otherwise, it seems to be rather obscure. I've searched everywhere, and no one seems to have much on it. But I figured if anyone did, it would be you guys. Thanks for reading!

11 years, 2 months

3
3
0 0

DEC Professional 350 - video issue

by commodorejohn＠gmail.com

Back in November I dropped in on a list member's moving giveaway and came away with some DEC stuff, among which was a DEC Professional 350 with keyboard and monitor. As the previous owner informed me, the video isn't working; there's no picture on the monitor, but there's visible sync lines, and the diagnostic lights on the back of the unit indicate an error with the bitmap graphics card. I'm pretty sure it's an issue with the card and not the slot, since the error moves with the card when I install it in one of the other slots, but I'm not sure what to look for on the card itself - nothing is socketed, so it's not chip creep, and the card connector looks to be in good shape. Does anybody have any advice for diagnosing and repairing this? I'd really like to get it working. Failing that, does anybody have a spare for the video card? (It's DEC part number 54-15138.) I've got a Rainbow I'd be willing to trade for a working one (base unit only - I don't have the facilities to test it, but according to the owner it was in working condition.)

11 years, 2 months

4
6
0 0

More Dilog and Emulex

by useddec＠gmail.com

DILOG DQ130 DQ686 Emulex CS09 SC01 SC03 SU21 hex TU11 TU121 TU131 UD33 hex QD01 QD21 QD241 QT131 MDB -DWO 40040270 Simpact/ Industrial Networking Inc TBM-15 token bus modem Anyone use MTI boards? I have several here. Thanks, Paul

11 years, 2 months

1
0
0 0

Available: VAX-11/750, DEC7000, DEC5500 and more!

by pontus＠update.uu.se

Hi A computer club in northern Sweden (Lule?) is clearing out some storage rooms. I'm not the owner and not directly responsible for this (although I'm involved). Shipping will _not_ be possible, but things that people have interest in can be stored for "a while". Here is a list of things heading for the scrapper: Unibus- and BI-bus boards (I'm will try to save these) 1/2"-tapes 2x DEC7000 RX01-floppies DEC5500 (labled ellen.lnt.dec.com) Vax 4000/300 A few RA90 MV3900+RA82+RL02 Sun-mice and Sun-SCSI-cables (lots) Annex3 Terminal Server VAXserver 3100 VAXstation 3100 Vax 4000/90 2x VAXstation 3100/76 Vax 4000/60 Infoserver 100 Sun CD-drive Mikrovax 3800 CI-cable 2x RF215 (disk towers) Mikrovax? 640QR? Vax 4000/500 HSC90 TU81+RA82 11/750 no PSU SDI cables 2 st Hawk-drives (ND511). Boards for Nord-100. Teleray terminal 2 Nord-10 CPU-boxes? There is also a VAX 8354 with RA72 that I'm going try and save myself, but I can't fit the cabinet in my garage. So if anyone seriously wants this, I'll let it go. There is also two RP07 that might get a new home locally, but it's not decided yet. The list might grow or shrink depending on what people claim or not. Here are some images: http://brain.brokenbrain.se/skrot_dh1/ Regards, Pontus.

11 years, 2 months

14
20
0 0

This may be the most impressive demo I've ever seen.

by lproven＠gmail.com

http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/ This is a demo for the original 4.77MHz 8088 IBM PC with CGA. No sound card, no hard disk, but 640kB of RAM. It's astounding, from the music to the 256-colour graphics. An amazing piece of work. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

11 years, 2 months

5
4
0 0

Huge IBM 1800 find (and need some help)

by jnc＠mercury.lcs.mit.edu

> From: Roe Peterson > There are very likely lead bars in the bottom rear of the rack I recall finding one in some machine (don't remember what, now); they are so the thing won't fall over when something is extended/swung out. Noel

11 years, 2 months

10
26
0 0

Kalok Octagon Seriels Modell 330 Hardisk Service Manual?

by holm＠freibergnet.de

Hi all, Is a SM ior Schematics for an Kalok Octagon Series RLL Harddisks out there? ..don't think that such a thing exists but I would have asked. That are the loud 30MB RLL 3,5" full height Harddisks. I have one that spins up, steps hardly against the internal stopper for a while and spins down again. Lookedwith a scope to the stepper phases and they aren't looking normal at all. The Drivers are 4 IRFR110 driven from 7406's... Would use that disk in a CP/M System with an OMTI5520 Controller. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

11 years, 2 months

1
0
0 0

Weekly Classic Computer Trivia Question (20150410)

by dpi＠dustyoldcomputers.com

True or False: The ZFS file system wastes more space on an average file allocation than the ram in a typical PDP-8. At the very least this question might give someone a reason to learn a little bit about ZFS. -- Doug Ingraham PDP-8 SN 1175

11 years, 2 months

3
3
0 0

Color codes for DEC power supply terminals?

by go＠ao-cs.com

I'm trying to determine if DEC used any standards when choosing colors for the terminal connections on their power supply systems. I have a non DEC 'DECTape' drive I'm in the process of bringing back from the dead and am troubled by the manufacturers use of colors on their terminals. Some make sense: 'black', 'white', 'green' for primary color, although there is a block of 'red' used as an alternate connection to the 'black' (USA: 'hot' leg) of the primary (115VAC) connection. Others include 'blue', 'yellow' and 'orange'. I'm familiar with DEC's use of 'red' for +5, and 'orange' for +15 (or perhaps it was +12) but these do not seem to be the choices here. I've consulted my list of 'small computer handbooks' and 'interfacing' DEC books but haven't found anything useful. Also search google with many many permutations. Any ideas? Perhaps the manufacturer just pulled some out of their hat. Thanks, Gary

11 years, 2 months

2
1
0 0

VCF SE 3.0 T-shirts

by kylevowen＠gmail.com

The Atlanta Historical Computing Society is selling t-shirts for our show on May 2nd and 3rd. They're available on Kickstarter, but if you would prefer, send me an email and we can work out alternate payment options. https://www.kickstarter.com/projects/20859909/help-fund-the-vintage-compute… Right now, our speakers include Jason Scott, Robert Uiterwyk, Malcolm Macleod, and several podcasts. Our theme this year is celebrating the big birthdays, including the PDP-8, the Altair 8800, and the Amiga 1000. Also, if anyone's interested in exhibiting, let me know. More info about the show at vintage.org. Thanks, Kyle

11 years, 2 months

1
0
0 0

Color codes for DEC power supply terminals?

by go＠aerodesic.com

I'm trying to determine if DEC used any standards when choosing colors for the power terminal connections on their power supply systems. I have a non DEC 'DECTape' drive I'm in the process of bringing back from the dead and am troubled by the manufacturers use of colors on their terminals. Some make sense: 'black', 'white', 'green' for primary color, although there is a block of 'red' used as an alternate connection to the 'black' (USA: 'hot' leg) of the primary (115VAC) connection. Others include 'blue', 'yellow' and 'orange'. I'm familiar with DEC's use of 'red' for +5, and 'orange' for +15 (or perhaps it was +12) but these do not seem to be the choices here. I've consulted my list of 'small computer handbooks' and 'interfacing' DEC books but haven't found anything useful. Also search google with many many permutations. Any ideas? Perhaps the manufacturer just pulled some out of their hat. Thanks, Gary

11 years, 2 months

1
0
0 0

Hand-wired core for ROM?

by marvin＠west.net

The PDP16 had a constants card circa 1972 or so. The constants card was basically cores with hand threaded wire done by the customer, and acted like a ROM. I don't remember the capacity, but IIRC it was about 16 bytes. > Did the PDP14 (or any machine of that era) ever use hand-threaded (by the > end user) core boards as ROM? > > tnx. > > g.

11 years, 2 months

2
1
0 0

Altair Turnkey and some DEC stuff cheap

by jnc＠mercury.lcs.mit.edu

>> On Thu, 9 Apr 2015, Noel Chiappa wrote: >> The real problem is that there's 'grup' (a Dave Clark neologism) in >> the thin space between the plastic contact pin housing blocks and the >> PCB. Needless to say, one can't take the PCB off to get in there... >> >> So my plan of action is to stick them in water for a couple of days, >> and then use a water jet to try and get down in the thin gap between >> the contact blocks and the PCB, to clean it out. Hi, all, thanks for all the suggestions: alas, they won't really help with this part of the problem, since the gap between the PCB and the pin contact housing blocks is only about 1mm (less in some cases) and there's no way I know of to get any kind of effective brush into a gap that small. Maybe something akin to dental floss, but that would be about it. (String might be a good idea, it has a rougher surface and might be better at removing impacted grime, plus it's wider, so will do more width on each pass.) The Simple Green might be something useful to add to the bath, though. I generally use compressed air to dry boards (although I've heard rumours of possible static problems from this, I've never had a problem), which is easy for me since I have a 5HP compressor in the basement. It mostly blows the water (along with any dissolved minerals, although I usually try and finish with a douse of distilled) right off the board. > From: Tothwolf > There /is/ actually a source for replacement gold fingers (and copper > trace material), but that sort of stuff can get expensive if you need > to replace a lot of them. Actually, I wouldn't try and replace the traces; I'd just use wire, and solder the ends onto the remains. (I'm more into functionality than cosmetics. If anyone is really intense about the cosmetics, please let me know, I'd be interesting in hiring you to fix the two boards... :-) The gold contact fingers are another matter, and for them I thank you for your very useful pointer: > You might try contacting http://circuitmedic.com/ and see if they have > any replacement gold fingers the correct width. I have yet to look into this, but I'm sure they'll have something that will serve. The standard DEC contact fingers are 2.2mm wide, but some off-brand boards use fingers as narrow as 1.6mm, so I expect they'll have _something_ I can use. Noel

11 years, 2 months

3
2
0 0

UK PDP11 wanted

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist >> Remember the jumpers I found on the 11/84 backplane? They can turn the >> PMI section (AFAICT) into a real QBUS. > I don't remember any jumpers. http://www.classiccmp.org/pipermail/cctalk/2015-February/003756.html >> For QBUS _memory_, it should 'just work', in the same way that you can >> plug an M8190 into a Q/CD backplane with some QBUS memory, and it will 'just >> work'. (I.e. the M8190 will automatically do QBUS memory cycles if >> that's the kind of memory that's out there.) > I'll believe that when you plug the Qbus memory *before* the CPU in a > Q/CD backplane. But the QBUS part of _any_ QBUS backplane is not 'directional' in the same way the CD part of the backplane in an ordinary Q/CD backplane is. (Note that the 11/84 backplane's CD section is _not_ 'directional' the way a normal Q/CD backplane's CD section is. See: http://www.classiccmp.org/pipermail/cctalk/2015-February/003757.html for more.) So for plain QBUS memory, it doesn't matter where it is in the QBUS backplane, in relation to the CPU. Noel

11 years, 2 months

2
1
0 0

UK PDP11 wanted

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist >> a _system_ with an M8190, a KTJ11 (M8191), and no PMI memory, only >> regular QBUS memory? (Not sure if this will work... but it should, >> I'll try it soon and see. > Should not work, as far as I know. The CPU bus on an 11/84 is always > PMI. We had a prior discussion about this. Remember the jumpers I found on the 11/84 backplane? They can turn the PMI section (AFAICT) into a real QBUS. But that's if one wanted to use a QBUS _device_ in an 11/84 backplane (in the PMI part, of course). For QBUS _memory_, it should 'just work', in the same way that you can plug an M8190 into a Q/CD backplane with some QBUS memory, and it will 'just work'. (I.e. the M8190 will automatically do QBUS memory cycles if that's the kind of memory that's out there.) Now, whether the _KTJ11_ will work properly with QBUS memory instead of PMI - no idea on that one! :-) Noel

11 years, 2 months

2
1
0 0

UK PDP11 wanted

by jnc＠mercury.lcs.mit.edu

> From: Pete Turnbull > Are you confusing it with a KDJ11-A ... But this is a KDJ11-B Nope. Have several of both (IYWR, it was my looking at my various M8190's that led me to the conclusion that all M8190's, no matter the version, can do PMI). > Basically what makes the difference is whether it's using PMI memory or > QBus memory. ... If you change the config to not use PMI, an 11/83 > becomes an 11/73. After thinking about this for a while, the terminology does now make sense to me, if it's applied to _systems_, not _boards_. An 11/73 is a _system_ with no PMI memory usage (one can of course plug PMI memory into a system with an M8192, but that won't make it use it, i.e. become an 11/83). An 11/83 is a _system_ with PMI memory in use (an M8190, plus PMI memory). But I still think of the _cards_ as either an '11/73 CPU' (M8192) or '11/83-84 CPU' (M8190). The '11-83/84' part does lead to an interesting question: what do we call a _system_ with an M8190, a KTJ11 (M8191), and no PMI memory, only regular QBUS memory? (Not sure if this will work... but it should, I'll try it soon and see. Also, this part is for fun, not serious!) Analogizing to the 73/83 distinction, one might say that it's not an 84, but a '74'... but that number is already taken! :-) Noel

11 years, 2 months

2
1
0 0

Hand-wired core for ROM?

by geneb＠deltasoft.com

Did the PDP14 (or any machine of that era) ever use hand-threaded (by the end user) core boards as ROM? tnx. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!

11 years, 2 months

14
28
0 0

Amiga 1000 system boards

by jules.richardson99＠gmail.com

Any Amiga geeks out there? I picked up a pair of Amiga A1000 systems a couple of weeks ago. Both are Revision 6 boards (going by IC dates, one was likely built in October of '85, the other in January of '86). However, bigbookofamigahardware.com claims that rev. 6 boards had copper traces and the later rev A board were tin - but in this case the earlier of my two boards is tin (while the later one is indeed copper). Just wondering if I have a bit of an anomaly (and the above site's correct), of if the reality is that rev. 6 boards routinely appear in both copper and tin? s/n on the early system is 6000146, the later one is 1165109; I have no idea what production numbers were like (anyone?) but I'm assuming that there's some form of plant number involved in the leading digit(s). cheers Jules

11 years, 2 months

1
0
0 0

Looking for: Moniterm Viking 2400

by derschjo＠gmail.com

OK, long shot. I gave one of these away years ago and I wish I hadn't; anyone have a Moniterm Viking 2400 monitor they'd part with? This is a large (24") B&W monitor from the late 80s. I still have the Mac Nubus card to drive it... Thanks as always, Josh

11 years, 2 months

4
3
0 0

Looking for: Moniterm Viking 2400

by ethan.dicks＠gmail.com

On Wed, Apr 1, 2015 at 2:54 PM, John Foust <jfoust at threedee.com> wrote: > At 11:48 PM 3/31/2015, Josh Dersch wrote: >>OK, long shot. I gave one of these away years ago and I wish I hadn't; anyone have a Moniterm Viking 2400 monitor they'd part with? This is a large (24") B&W monitor from the late 80s. I still have the Mac Nubus card to drive it... > > They were used in the Amiga and Atari markets, too, weren't they, > with specialized video cards? Or was that only their 19" monitors? I have the 19" Viking greyscale monitor with the corresponding Amiga card (1008 x 1008 w/quarter-screen panelized refresh) It was great for writing code. I don't remember anything larger from the day. -ethan

11 years, 2 months

2
1
0 0

Brian Kernighan @ VCF East

by jnc＠mercury.lcs.mit.edu

> From: John Wilson > Is there a reason why people don't wear name tags at VCF-E? ... no one > seems to have them on and I'd feel like a tool bringing my own and > being the only one. Bring yours - it won't be the only one! I was planning on bringing one of my old IETF ones in case there weren't 'official' VCFE ones. Everyone else, please bring one! (And maybe someone could bring a spool of those stick-on temporary ones, for those without.) Without them, you'll never know if you just walked past someone you know well online.... Noel

11 years, 2 months

1
0
0 0

Brian Kernighan @ VCF East

by evan＠snarc.net

Big announcement! Wes Clark is unable to attend VCF East due to health. Naturally I hit the panic button. Wes, after all, was already our Plan B after Ted Nelson backed out, also due to personal matters. But we scrambled really hard in the past two days and landed K. :)

11 years, 2 months

4
8
0 0

Living Computer Museum in Seattle

by jplist2008＠kiwigeek.com

I thought I'd drop a note after visiting the LCM on Saturday. I cannot endorse this museum enough, I had a complete blast. I latched onto a tour with a new docent by the name of Aaron who was truly the nicest chap - so much so we ended up BS'ing for 40 minutes after the tour. In a manner in which the other person isn't trying to get away, no less, which is probably novel for most of us. To be able to monkey about with a multi-rack 8, or a Nova was very cool. To stand next to a running Sigma9 or in front of a 13-rack KI10... I highly, highly recommend it to anyone who visits the area. Also, Rich, I see you: http://kiwigeek.com/misc/LCM2015/IMG_20150404_150503257.jpg - JP

11 years, 2 months

12
12
0 0

MSV11-L switch settings

by roeapeterson＠gmail.com

It shouldn't be too difficult to figure out the switches. Does the card work at all with all the switches in the open position? It would help if you could provide decent pics of both sides of the board. Hoping to help...

11 years, 2 months

1
0
0 0

Altair Turnkey and some DEC stuff cheap

by jnc＠mercury.lcs.mit.edu

> From: Bill Degnan > These are best for someone who has experience cleaning a "barn find" > ... > * items contains/contained a rodent nest. Those who missed out on this deal may find this sequel comforting. There was one aspect of this (which Bill alluded to somewhat eliptically - perhaps out of delicacy, or perhaps he assumed that anyone who'd done one of these would already realize the full implications :-), but which didn't really impress itself upon me until I started the ride home - at which point I started to get olfactory clues. Yep, some of you know what I'm talking about. Animal urine. Of the three boxes, one (the '11/44' - it was actually just a BA11-K) was totally sodden inside (those nests are basically giant sponges), and one of the 11/34's was half-sodden. The thing about animal urine that's really a problem is not the smell, or the mess - it's that it's _incredibly_ corrosive. >From the condition of a couple of the cards which had gotten the worst, I think there was actually some galvanic activity between the copper traces, and something else - maybe the iron in the chassis? Traces were quite literally eaten right off the cards. You can see the trace heading towards one of the gold-plated contact fingers, and then - poof! - it disappears. Dozens of traces on those two cards have big gaps in them. Although now that I think about it, it couldn't have been galvanic activity which dissolved the copper in the traces; if I remember my inorganic chem correctly, iron is above copper on the galvanic activity scale. But anyway, Also, totally amazingly, quite a few of the gold-plated contact fingers also have damage! One is quite bad - although luckily I think there's a patch left where the contact would be, so that can probably be saved. Whatever was going on must have eaten the copper out from underneath, and then the gold just washed away. So I think all those traces can be repaired, if there's ever a use for that interface (an RH11). Just a lot of wires to solder in.... The other problem is the backplanes. DEC boxes put the backplanes at the bottom, so these nests were resting on the backplanes. Having cleaned them off (well, stage 1 cleaning), I _think_ that, amazingly enough, the contact pins are OK. (Now that I think about it, they are tin-plated - so there's the other end of the galvanic activity. Ah, well, better to eat the traces than the contact pins - those would be almost _impossible_ to repair.) The real problem is that there's 'grup' (a Dave Clark neologism) in the thin space between the plastic contact pin housing blocks and the PCB. Needless to say, one can't take the PCB off to get in there... So my plan of action is to stick them in water for a couple of days, and then use a water jet to try and get down in the thin gap between the contact blocks and the PCB, to clean it out. Does this sound OK? I can't think of a reason why immersing a backplane in fresh water for a couple of days would do it any harm, but maybe I'm missing something? I just think it's critical to recovering these to get as much out of that area as I possibly can. If an open develops somehow, well, that can easily be fixed with a wire. But a short.... you're screwed. Moral of the story: if you're going to store your antique computers in a barn - make sure to keep the rodents out! Noel

11 years, 2 months

8
7
0 0

UK PDP11 wanted

by jnc＠mercury.lcs.mit.edu

> From: Pete Turnbull >> Technically, that's an 11/83 CPU... > Nope, it's only 15MHz ... and the MSV11-Q memory isn't PMI, so it's an > 11/73. A discussion as to whether the addition of second board can change a first board from an A to a B would I suspect be non-productive, so I will pass over that point. :-) One thing that I am curious about is the 15MHz aspect: what did DEC (if you recall) call a 15MHz M8190 paired with PMI memory? (Recalling our prior discussion, which I am too lazy to look up and give a pointer to, about how all the M8190's can apparently do PMI.) Did they (or would they) have regarded that as an 11/83, or did only the 18MHz version get the 11/83 moniker? (Too many different configurations - 15/18, PMI/non-PMI - and not enough names!) Noel

11 years, 2 months

4
3
0 0

settings for DEC M7506 (MSV11-M)

by jnc＠mercury.lcs.mit.edu

> From: Pete Turnbull > Does anyone have a description of the switch settings for a QBus > MSV11-M (aka MSV1M) memory card (M7506)? > .. I can't find the manual ... or any useful notes anywhere. How odd. I've looked through every plausible DEC QBUS document I've got, and none mention the MSV11-M! They all jump straight from the MSV11-L to the MSV11-P. E.g. the "Microcomputer Products Handbook" from 1985 has the MSV11-L, then the MSV11-P, then the MSV11-Q. (Although it doesn't have the MSV11-J either, though - although my MSV11-J manual says the first version was '85.) I wonder why? Was the MSV11-M a later card? (Well, it must have been...) There's a Micro-Note (#28) from June '85 which mentions the MSV11-M, so it's not _that_ late. However, e.g. the "Supermicrosystems Handbook", from 1986, mentions the MSV11-J, then the MSV11-Q, then the MSV11-P! I wonder why they left it out? It provides up to 1MB on a dual card, whereas the MSV11-P only does 512KB on a quad card? So it's not as if it were already obsolete by 1986 - it's clearly better than something they _did_ include! Very odd. Noel

11 years, 2 months

2
1
0 0

VAX 8354

by pontus＠Update.UU.SE

Hi I'm trying to save a MicroVAX 8350. Seen to the left here: http://brain.brokenbrain.se/skrot_dh1/20150407_100417.jpg It's in a DEC half-rack which I sadly don't have room for. So I will ask to have the CPU module only and any specific rackheaders (for ethernet and other things, if any). Is there anything else about that rack specific to the 8350 ? I have RA72 disks already. And other DEC racks to mount it in. /P

11 years, 2 months

1
0
0 0

TRS-80 Model 1 Monitor

by robert.jarratt＠ntlworld.com

I have finally managed to get my hands on a TRS-80 Model 1. Trouble is, it came without a monitor. I have been doing some searching to see if I can find out what kind of monitor it is and I am left unsure. All I have found so far is a statement which says it is a TV without a tuner. I am not sure what that means. I still have a CRT TV, can that be made to work, or have I bought something that I can't use? Thanks Rob

11 years, 2 months

5
5
0 0

RL02-USB Controller Status/Problem

by christopher.parish＠parishcomputers.com

Progress is good on the RL02-USB controller. I've gotten complete operation working as expected with the usual tools for disk access (badblocks, dd, etc.), and SIMH can access the real packs via the controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those with identified bad blocks from the factory) are another story. The issue is most obvious when backing up and restoring disk images. Suppose I backup a pack with 1 bad sector. I have two choices of what to do with the bad sector (specifically if it's a bad header), I could skip the sector (reporting an IO error), or I could report all zeros for the sector. Skipping the sector is a bad idea because the logical address of all sectors after it will shift down by one. This will make the disk image not work correctly with SIMH, or anything else for that matter, because most filesystems address things by physical block (Please correct me if I'm wrong here). Remember, we're at the device level (/dev/sda) not the partition level (/dev/sda1). Returning all zeros for bad sectors will preserve the block numbers of following sectors and work correctly with SIMH, but trying to restore the resulting image to another physical pack will probably be impossible given the destination disk pack has bad sectors of its own in different spots. The usual trick of having the controller re-map the bad sectors will not work because the platters in the RL02 are removable. Writing some mapping index on the disk pack or holding back sectors in reserve will break compatibility with the original systems (PDP8s/11s/VAXes) and all their software (an unacceptable solution). I think I've come to the following conclusions given the restrictions above: - Creating and Restoring images with EF packs is unrestricted - SIMH operation with EF packs (online and images) will work perfectly - Creating images of DC packs will work with SIMH if I return zeros for the bad blocks - Online use of DC packs work with SIMH assuming no new bad blocks have formed since the bad block index was written - If new bad blocks have formed in a pack, SIMH will have to be modified so its RL(V)11 can receive error information from the drive, otherwise it will incorrectly handle the recovery - Restoring images on DC packs will require special software that can move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*) - Using a modern filesystem on EF/DC packs is unrestricted (because they can identify and manage bad blocks on their own) First, does all of this seem reasonable? I vaguely remember reading about a program on RT-11 you would run (before?) backing up the filesystem. What was this program? How did it work? Did it make the data position independent? Christopher

11 years, 2 months

8
31
0 0

UK PDP11 wanted

by jnc＠mercury.lcs.mit.edu

> From: Robert Jarratt > Have you seen this: > http://www.ebay.co.uk/itm/Digital-DEC-PDP-1173-1MEG-QBUS-cards-backplane-fr… Technically, that's an 11/83 CPU... Too bad the seller doesn't ship internationally, that 23+ he's selling is an awesome deal (at the moment). Noel

11 years, 2 months

2
1
0 0

PDP-11 Menu

by ben＠bensinclair.com

I recently received a new BDV11 and booted it up on my 11/23 with whatever ROM it has on board. It displays the following menu, and I was curious if anyone recognizes it. Just for fun, I'd just like to find out what sort of system this board lived in previously. Thanks! <[2J[6;1H PRIMITIVE MENU (V-01) 1. MCR MODE 2. UIS MODE 3. LSI DIAGS ENTER MENU NUMBER: _ -- Ben Sinclair ben at bensinclair.com

11 years, 2 months

1
0
0 0

VAX-11/750 power supplies

by mattislind＠gmail.com

I am working on the H7104 power supplies for the VAX-11/750 now. The 5V had a short circuit main switch transistor and a output rectifier diode that also was a short circuit. Now it works fine into a 0.5 ohm dummy load. Then when checking the 2.5V supply it had two out of three output rectifiers short circuited. So what is it with these rectifiers? They are Unitrode USD5096F but unfortunately I cannot find any data sheet for them. I asked in another forum and someone even checked the Unitrode data book for 84-85 but didn't find the part! However looking in the print set the diode is listed as 1114197-00 with the remark "60 AMP POWER SCHOTTKY DIODE" Is the Unitrode USD5096F a 60 Amp diode? This link tells me it is a 35A diode: http://www.electronicsurplus.com/unitrode-usd5096f-diode-35amp-35v-piv and so does this link: http://www.ebay.com/itm/35-Amp-35-Volt-Stud-Mounted-Diode-with-Wire-and-Lug… Is there anyone that can enlighten me here? Is USD509F a 35 Amp part and then why have DEC used parts that is not as specified in the print set? /Mattis

11 years, 2 months

4
5
0 0

UK PDP11 wanted

by ed＠ryer.ru

Hi there I am based in the UK (Edinburgh) and have been seeking the last couple of years a working/non-working MicroPDP 11/23, 73 or 93 in preferably a BA-23, but anything definitely considered. These rarely come up on eBay (although I am tempted to by a working MicroPDP 11/73 in a BA-23 from eBay US for $1200, but shipping and taxes would make this at least 50% more). Any advice on sources of hardware in the UK/EU would be much appreciated. I really don't want to wait many more years simply because the rarity may mean I never get one. Also looking for a VAXStation 3100/9x model. Again hard to find in the UK. Many thanks Ed On Tue, Apr 7, 2015 at 6:00 PM, <cctalk-request at classiccmp.org> wrote: > Send cctalk mailing list submissions to > cctalk at classiccmp.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.classiccmp.org/mailman/listinfo/cctalk > or, via email, send a message with subject or body 'help' to > cctalk-request at classiccmp.org > > You can reach the person managing the list at > cctalk-owner at classiccmp.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cctalk digest..." > > > Today's Topics: > > 1. Re: BA23 Chassis available in Lexington KY - Taken > (keith at saracom.com) > 2. Re: BA23 Chassis available in Lexington KY - Taken (Paul Anderson) > 3. Looking for.... (Jay West) > 4. RL02-USB Controller Status/Problem (Christopher Parish) > 5. Seeking H7861 Power Supply (PDP 11/23+) (Cory Heisterkamp) > 6. Re: Seeking H7861 Power Supply (PDP 11/23+) (Noel Chiappa) > 7. Re: Seeking H7861 Power Supply (PDP 11/23+) (Jacob Ritorto) > 8. Re: RL02-USB Controller Status/Problem (Eric Smith) > 9. Re: RL02-USB Controller Status/Problem (Eric Smith) > 10. Re: RL02-USB Controller Status/Problem (Don North) > 11. Re: RL02-USB Controller Status/Problem (Don North) > 12. Re: RD54 Stopped Spinning (shadoooo) > 13. Re: RL02-USB Controller Status/Problem (Johnny Billquist) > 14. RE: RL02-USB Controller Status/Problem (Christopher Parish) > 15. Re: RL02-USB Controller Status/Problem (Pete Turnbull) > 16. Re: RL02-USB Controller Status/Problem (Pete Turnbull) > 17. Re: RL02-USB Controller Status/Problem (Pete Turnbull) > 18. Re: RL02-USB Controller Status/Problem (Pete Turnbull) > 19. Re: RL02-USB Controller Status/Problem (Paul Koning) > 20. Re: RL02-USB Controller Status/Problem (Johnny Billquist) > 21. Re: RL02-USB Controller Status/Problem (Johnny Billquist) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 06 Apr 2015 13:20:22 -0400 > From: keith at saracom.com > To: cctech at classiccmp.org > Subject: Re: BA23 Chassis available in Lexington KY - Taken > Message-ID: <74a272e1cd6f7dc12ff7f3a803b3c822 at saracom.com> > Content-Type: text/plain > > > > OK, I think all of them have been claimed now. If not I will report. Now > to see what else is in the shed. > > thanks > > ------------------------------ Message: 16 Date: Mon, 6 Apr 2015 > 11:06:31 -0400 From: Jacob Ritorto <jacob.ritorto at gmail.com> To: > "General Discussion: On-Topic Posts" <cctech at classiccmp.org> Subject: > Re: BA23 Chassis available in Lexington KY Message-ID: > <CAHYQbfBp7WuiR5qSfeR39tDMBQKGHvg2Vk8vw5FGgewSOjBzug at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 Hey Max, I'll take a couple. > You're a six-hour's drive from me, so it'll take me a sec to figure out > when. How's Friday for you? On Sun, Apr 5, 2015 at 6:47 PM, > <keith at saracom.com> wrote: > > >> Hello, I am in the process of moving and need to pare down my spare > parts collection. I have several BA23 chassis with power supplies. I do not > know the condition as they have been stored in my shed for years. They do > not include modules or outer shells. If you pickup in Lexington KY, they > are free. Thanks Max > > ************************************ > > > ------------------------------ > > Message: 2 > Date: Mon, 6 Apr 2015 16:23:42 -0500 > From: Paul Anderson <useddec at gmail.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Subject: Re: BA23 Chassis available in Lexington KY - Taken > Message-ID: > <CACwhfuMTOfs_Q0bQgE5= > o11LvsLG3hdkh858H0JNvmswy4ggQg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > If anyone needs any boards for them, feel free to contact me off list. > > Thanks, Paul > > On Mon, Apr 6, 2015 at 12:20 PM, <keith at saracom.com> wrote: > > > > > > > OK, I think all of them have been claimed now. If not I will report. Now > > to see what else is in the shed. > > > > thanks > > > > ------------------------------ Message: 16 Date: Mon, 6 Apr 2015 > > 11:06:31 -0400 From: Jacob Ritorto <jacob.ritorto at gmail.com> To: > > "General Discussion: On-Topic Posts" <cctech at classiccmp.org> Subject: > > Re: BA23 Chassis available in Lexington KY Message-ID: > > <CAHYQbfBp7WuiR5qSfeR39tDMBQKGHvg2Vk8vw5FGgewSOjBzug at mail.gmail.com> > > Content-Type: text/plain; charset=UTF-8 Hey Max, I'll take a couple. > > You're a six-hour's drive from me, so it'll take me a sec to figure out > > when. How's Friday for you? On Sun, Apr 5, 2015 at 6:47 PM, > > <keith at saracom.com> wrote: > > > > >> Hello, I am in the process of moving and need to pare down my spare > > parts collection. I have several BA23 chassis with power supplies. I do > not > > know the condition as they have been stored in my shed for years. They do > > not include modules or outer shells. If you pickup in Lexington KY, they > > are free. Thanks Max > > > ************************************ > > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 6 Apr 2015 19:37:24 -0500 > From: "Jay West" <jwest at classiccmp.org> > To: <cctalk at classiccmp.org> > Subject: Looking for.... > Message-ID: <000d01d070cb$04a0bf60$0de23e20$(a)classiccmp.org> > Content-Type: text/plain; charset="us-ascii" > > I need another operational HP 7970E mag tape controller (13183 - 2 board > set). It appears that the spare board sets I have are 13181 which I believe > is only for the 7970A/B. All my drives are 7970E, so is there any chance > someone has a 7970A/B but has a 13183 and would like to swap my 13181 for > it? J Or if anyone has a spare 13183 they want to sell/trade... > > > > Best, > > > > J > > > > ------------------------------ > > Message: 4 > Date: Mon, 6 Apr 2015 22:54:39 +0000 > From: Christopher Parish <christopher.parish at parishcomputers.com> > To: General Discussion: On-Topic Posts ?[cctech at classiccmp.org]? > <cctech at classiccmp.org> > Subject: RL02-USB Controller Status/Problem > Message-ID: > > <639FFF5F324E6D409F42CF2B2F3BB56AB0FF00DB at MBX022-E1-NJ-4.exch022.domain.local > > > > Content-Type: text/plain; charset="windows-1256" > > Progress is good on the RL02-USB controller. I've gotten complete > operation working as expected with the usual tools for disk access > (badblocks, dd, etc.), and SIMH can access the real packs via the > controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is > only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those > with identified bad blocks from the factory) are another story. > > > The issue is most obvious when backing up and restoring disk images. > Suppose I backup a pack with 1 bad sector. I have two choices of what to do > with the bad sector (specifically if it's a bad header), I could skip the > sector (reporting an IO error), or I could report all zeros for the sector. > > > Skipping the sector is a bad idea because the logical address of all > sectors after it will shift down by one. This will make the disk image not > work correctly with SIMH, or anything else for that matter, because most > filesystems address things by physical block (Please correct me if I'm > wrong here). Remember, we're at the device level (/dev/sda) not the > partition level (/dev/sda1). > > > Returning all zeros for bad sectors will preserve the block numbers of > following sectors and work correctly with SIMH, but trying to restore the > resulting image to another physical pack will probably be impossible given > the destination disk pack has bad sectors of its own in different spots. > > > The usual trick of having the controller re-map the bad sectors will not > work because the platters in the RL02 are removable. Writing some mapping > index on the disk pack or holding back sectors in reserve will break > compatibility with the original systems (PDP8s/11s/VAXes) and all their > software (an unacceptable solution). > > > I think I've come to the following conclusions given the restrictions > above: > > > - Creating and Restoring images with EF packs is unrestricted > > - SIMH operation with EF packs (online and images) will work perfectly > > - Creating images of DC packs will work with SIMH if I return zeros for > the bad blocks > > - Online use of DC packs work with SIMH assuming no new bad blocks have > formed since the bad block index was written > > - If new bad blocks have formed in a pack, SIMH will have to be modified > so its RL(V)11 can receive error information from the drive, otherwise it > will incorrectly handle the recovery > > - Restoring images on DC packs will require special software that can move > data around the bad-blocks (or a linux RT-11 filesystem driver *wink*) > > - Using a modern filesystem on EF/DC packs is unrestricted (because they > can identify and manage bad blocks on their own) > > > First, does all of this seem reasonable? > > > I vaguely remember reading about a program on RT-11 you would run > (before?) backing up the filesystem. What was this program? How did it > work? Did it make the data position independent? > > > Christopher > > > ------------------------------ > > Message: 5 > Date: Mon, 6 Apr 2015 20:06:43 -0500 > From: Cory Heisterkamp <coryheisterkamp at gmail.com> > To: "General Discussion: On-Topic Posts" <cctech at classiccmp.org> > Subject: Seeking H7861 Power Supply (PDP 11/23+) > Message-ID: <2747195F-0DE1-46FF-86A0-8342435A3C63 at gmail.com> > Content-Type: text/plain; charset=us-ascii > > I have a PDP 11/23+ I'm attempting to bring up and discovered why I wasn't > getting anywhere- a metal screw had gotten into the supply shorting > *something* on the supply PCB. I'm new to DEC equipment and I'm afraid this > supply is beyond me. If someone has one for sale (this one marked H7861), > please let me know. It looks serviceable and is likely repairable by an > expert so that could be an option, too. > > Thanks, > Cory > > > > > ------------------------------ > > Message: 6 > Date: Tue, 7 Apr 2015 00:21:32 -0400 (EDT) > From: jnc at mercury.lcs.mit.edu (Noel Chiappa) > To: cctalk at classiccmp.org > Cc: jnc at mercury.lcs.mit.edu > Subject: Re: Seeking H7861 Power Supply (PDP 11/23+) > Message-ID: <20150407042132.A7EF618C0FB at mercury.lcs.mit.edu> > > > From: Cory Heisterkamp > > > If someone has one for sale (this one marked H7861), please let me > > know. > > Someone on eBay is selling one: > > http://www.ebay.com/itm/150947900783 > > They are asking $125, which is not wholly ridiculous, and will probably > take > slightly less. I've bought several from this seller, and they are in good > shape. > > Also, at a pinch, I'm pretty sure (as in, I have looked at both closely, > and > verified that they have the same interfaces and physical dimensions, etc, > so I > think this will work, but I have yet to actually try it) an H786 would also > work in that system. The only difference I know of is that the H7861 puts > out > a few more amps of +5V. No reasonably priced H786's on eBay at the moment, > though. > > > It looks serviceable and is likely repairable by an expert so that > > could be an option, too. > > I'd interested in buying the dead one from you (which should help offset > the > cost if you go for the eBay one) - please contact me off line if > interested. > > Noel > > > ------------------------------ > > Message: 7 > Date: Tue, 7 Apr 2015 00:32:20 -0400 > From: Jacob Ritorto <jacob.ritorto at gmail.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Subject: Re: Seeking H7861 Power Supply (PDP 11/23+) > Message-ID: > < > CAHYQbfA336fXz8Ee_kThmGZKCz3r9wn8Je-rNg0-wP0TjfQtfQ at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > coupla questions as an aside on this subject: > > 1) Which PS is more available on commodity market? > > 2) Assuming H7681, do you know how to wire a chassis that expects H768 to > work with H7681? Or vice versa? > > 3) How can we make what we have on hand work for a long time? > > Bonus 4) Is there a commodity setup available to replace this analog kit > entirely with new stuff? (probably a new thread) > > > On Tue, Apr 7, 2015 at 12:21 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> > wrote: > > > > From: Cory Heisterkamp > > > > > If someone has one for sale (this one marked H7861), please let me > > > know. > > > > Someone on eBay is selling one: > > > > http://www.ebay.com/itm/150947900783 > > > > They are asking $125, which is not wholly ridiculous, and will probably > > take > > slightly less. I've bought several from this seller, and they are in good > > shape. > > > > Also, at a pinch, I'm pretty sure (as in, I have looked at both closely, > > and > > verified that they have the same interfaces and physical dimensions, etc, > > so I > > think this will work, but I have yet to actually try it) an H786 would > also > > work in that system. The only difference I know of is that the H7861 puts > > out > > a few more amps of +5V. No reasonably priced H786's on eBay at the > moment, > > though. > > > > > It looks serviceable and is likely repairable by an expert so that > > > could be an option, too. > > > > I'd interested in buying the dead one from you (which should help offset > > the > > cost if you go for the eBay one) - please contact me off line if > > interested. > > > > Noel > > > > > ------------------------------ > > Message: 8 > Date: Mon, 6 Apr 2015 23:41:48 -0600 > From: Eric Smith <spacewar at gmail.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Cc: General Discussion: On-Topic Posts ?[cctech at classiccmp.org]? > <cctech at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: > <CAFrGgTT+A25OBEuz3DzLaj3d= > O5G2eYfgENNNWyhJwGH+D2c9g at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Apr 6, 2015 at 4:54 PM, Christopher Parish > <christopher.parish at parishcomputers.com> wrote: > > - Using a modern filesystem on EF/DC packs is unrestricted (because they > can identify and manage bad blocks on their own) > > I'm not sure which filesystems you have in mind as "modern", but > filesystem-level support for bad blocks has largely faded away in > recent decades, because for many years now all disk drives have > implemented bad block replacement internally. > > > ------------------------------ > > Message: 9 > Date: Mon, 6 Apr 2015 23:41:48 -0600 > From: Eric Smith <spacewar at gmail.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Cc: General Discussion: On-Topic Posts ?[cctech at classiccmp.org]? > <cctech at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: > <CAFrGgTT+A25OBEuz3DzLaj3d= > O5G2eYfgENNNWyhJwGH+D2c9g at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Apr 6, 2015 at 4:54 PM, Christopher Parish > <christopher.parish at parishcomputers.com> wrote: > > - Using a modern filesystem on EF/DC packs is unrestricted (because they > can identify and manage bad blocks on their own) > > I'm not sure which filesystems you have in mind as "modern", but > filesystem-level support for bad blocks has largely faded away in > recent decades, because for many years now all disk drives have > implemented bad block replacement internally. > > > ------------------------------ > > Message: 10 > Date: Mon, 06 Apr 2015 22:53:59 -0700 > From: Don North <north at alum.mit.edu> > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org>, "General Discussion: On-Topic Posts > ?[cctech at classiccmp.org]?" <cctech at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <552370F7.5050500 at alum.mit.edu> > Content-Type: text/plain; charset=windows-1256; format=flowed > > Shouldn't the controller be using the DEC STD 144 bad sector replacement > table > in the last sector to transparently remap bad sectors such that, to the > user, > the -DC packs appear error free? If this were done each RL02 image should > appear > error-free in logical block address space as the hidden remapping of bad > sectors > on -DC drives would not be seen by the user (or O/S). > > All the other proposed ways of handling -DC bad sectors have serious > compatibility issues. > > Don > > On 4/6/2015 3:54 PM, Christopher Parish wrote: > > Progress is good on the RL02-USB controller. I've gotten complete > operation working as expected with the usual tools for disk access > (badblocks, dd, etc.), and SIMH can access the real packs via the > controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is > only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those > with identified bad blocks from the factory) are another story. > > > > > > The issue is most obvious when backing up and restoring disk images. > Suppose I backup a pack with 1 bad sector. I have two choices of what to do > with the bad sector (specifically if it's a bad header), I could skip the > sector (reporting an IO error), or I could report all zeros for the sector. > > > > > > Skipping the sector is a bad idea because the logical address of all > sectors after it will shift down by one. This will make the disk image not > work correctly with SIMH, or anything else for that matter, because most > filesystems address things by physical block (Please correct me if I'm > wrong here). Remember, we're at the device level (/dev/sda) not the > partition level (/dev/sda1). > > > > > > Returning all zeros for bad sectors will preserve the block numbers of > following sectors and work correctly with SIMH, but trying to restore the > resulting image to another physical pack will probably be impossible given > the destination disk pack has bad sectors of its own in different spots. > > > > > > The usual trick of having the controller re-map the bad sectors will not > work because the platters in the RL02 are removable. Writing some mapping > index on the disk pack or holding back sectors in reserve will break > compatibility with the original systems (PDP8s/11s/VAXes) and all their > software (an unacceptable solution). > > > > > > I think I've come to the following conclusions given the restrictions > above: > > > > > > - Creating and Restoring images with EF packs is unrestricted > > > > - SIMH operation with EF packs (online and images) will work perfectly > > > > - Creating images of DC packs will work with SIMH if I return zeros for > the bad blocks > > > > - Online use of DC packs work with SIMH assuming no new bad blocks have > formed since the bad block index was written > > > > - If new bad blocks have formed in a pack, SIMH will have to be modified > so its RL(V)11 can receive error information from the drive, otherwise it > will incorrectly handle the recovery > > > > - Restoring images on DC packs will require special software that can > move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*) > > > > - Using a modern filesystem on EF/DC packs is unrestricted (because they > can identify and manage bad blocks on their own) > > > > > > First, does all of this seem reasonable? > > > > > > I vaguely remember reading about a program on RT-11 you would run > (before?) backing up the filesystem. What was this program? How did it > work? Did it make the data position independent? > > > > > > Christopher > > > > > > ------------------------------ > > Message: 11 > Date: Mon, 06 Apr 2015 22:53:59 -0700 > From: Don North <north at alum.mit.edu> > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org>, "General Discussion: On-Topic Posts > ?[cctech at classiccmp.org]?" <cctech at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <552370F7.5050500 at alum.mit.edu> > Content-Type: text/plain; charset=windows-1256; format=flowed > > Shouldn't the controller be using the DEC STD 144 bad sector replacement > table > in the last sector to transparently remap bad sectors such that, to the > user, > the -DC packs appear error free? If this were done each RL02 image should > appear > error-free in logical block address space as the hidden remapping of bad > sectors > on -DC drives would not be seen by the user (or O/S). > > All the other proposed ways of handling -DC bad sectors have serious > compatibility issues. > > Don > > On 4/6/2015 3:54 PM, Christopher Parish wrote: > > Progress is good on the RL02-USB controller. I've gotten complete > operation working as expected with the usual tools for disk access > (badblocks, dd, etc.), and SIMH can access the real packs via the > controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is > only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those > with identified bad blocks from the factory) are another story. > > > > > > The issue is most obvious when backing up and restoring disk images. > Suppose I backup a pack with 1 bad sector. I have two choices of what to do > with the bad sector (specifically if it's a bad header), I could skip the > sector (reporting an IO error), or I could report all zeros for the sector. > > > > > > Skipping the sector is a bad idea because the logical address of all > sectors after it will shift down by one. This will make the disk image not > work correctly with SIMH, or anything else for that matter, because most > filesystems address things by physical block (Please correct me if I'm > wrong here). Remember, we're at the device level (/dev/sda) not the > partition level (/dev/sda1). > > > > > > Returning all zeros for bad sectors will preserve the block numbers of > following sectors and work correctly with SIMH, but trying to restore the > resulting image to another physical pack will probably be impossible given > the destination disk pack has bad sectors of its own in different spots. > > > > > > The usual trick of having the controller re-map the bad sectors will not > work because the platters in the RL02 are removable. Writing some mapping > index on the disk pack or holding back sectors in reserve will break > compatibility with the original systems (PDP8s/11s/VAXes) and all their > software (an unacceptable solution). > > > > > > I think I've come to the following conclusions given the restrictions > above: > > > > > > - Creating and Restoring images with EF packs is unrestricted > > > > - SIMH operation with EF packs (online and images) will work perfectly > > > > - Creating images of DC packs will work with SIMH if I return zeros for > the bad blocks > > > > - Online use of DC packs work with SIMH assuming no new bad blocks have > formed since the bad block index was written > > > > - If new bad blocks have formed in a pack, SIMH will have to be modified > so its RL(V)11 can receive error information from the drive, otherwise it > will incorrectly handle the recovery > > > > - Restoring images on DC packs will require special software that can > move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*) > > > > - Using a modern filesystem on EF/DC packs is unrestricted (because they > can identify and manage bad blocks on their own) > > > > > > First, does all of this seem reasonable? > > > > > > I vaguely remember reading about a program on RT-11 you would run > (before?) backing up the filesystem. What was this program? How did it > work? Did it make the data position independent? > > > > > > Christopher > > > > > > ------------------------------ > > Message: 12 > Date: Tue, 7 Apr 2015 08:20:27 +0200 > From: shadoooo <shadoooo at gmail.com> > To: cctech at classiccmp.org > Subject: Re: RD54 Stopped Spinning > Message-ID: > <CAM4zSsX243N0PpBgD5-XUU=OhoXo3bDWRDTScKi= > c79czUk71Q at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello, > apart from the transistors, I would check for some bad capacitor. > The analog part with the sensors needs quite clean supply to work good, > while the motor itself is a big source of spikes and pulses. > Possibly there could be some supply filter, with electrolytic capacitors > not working as expected due to age... or with excessive current leakage. > > Andrea > > > ------------------------------ > > Message: 13 > Date: Tue, 07 Apr 2015 12:21:31 +0200 > From: Johnny Billquist <bqt at update.uu.se> > To: cctalk at classiccmp.org > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <5523AFAB.5080509 at update.uu.se> > Content-Type: text/plain; charset=utf-8; format=flowed > > This might become a long answer. > > First of all, back when the RL drives were made, hardware handled bad > block management wasn't yet popular in that neck of the woods. So bad > blocks were/are visible to the software. In order to have some > management of this, DEC had a standard - DEC STD144, which described how > you kept track of, and managed, bad blocks. > If you ever wondered where the Unix program bad144 got its name from, > now you know (and the ultimate stupidness is NetBSD, where they decided > that only the x86 platform would have bad144, leaving the VAX - the only > hardware platform who actually had disks following the bad144 standard, > not having the bad144 program). > > The STD144 reserves the last track of the device for pack information. > In there you have the pack serial number, and also the manufacturer bad > block list, and also the user bad block list. When/if new blocks are > detected after the pack is manufactured, they would be placed in the > user bad block list. > > So, a EF pack would simply be a pack with no bad blocks from the > manufacturer. The manufacturer bad block list would contain no bad > blocks. This does not mean that the pack could not develop bad blocks > later. > > Now, a total imaging of one RL disk to another is not something you > should do. That would replace the pack serial number, in addition to the > issues with the bad block lists. Not to mention that different packs > have bad blocks in different places. > > Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped > away, or faked. The drive and controller can detect bad blocks, and when > you try to read one, you'll get an error back. Drivers try a few times, > and then give up, giving an error back to the user program. > You should not try anything different. > > Now moving over to how software deals with this, essentially all DEC > OSes have some way or other to mark the known bad sectors as bad when > the filesystem in created, and then no software will try to use them. > I have some rough idea on how this is done in RT-11 and RSTS/E, but to > give details, I'll describe how RSX does it. > RSX have a program that scans disks for bad blocks. It is called BAD. > BAD will update the last track with any new bad blocks found. > A different program is used to create a file system on a disks - INI. > INI will read the last track of the device, to get the manufacturer and > user bad block list. INI will then create the file system on the disk, > and allocate all the bad blocks on the disk to a special file - > BADBLK.SYS. That way, those blocks are already marked as used, and other > files created cannot accidentally include those bad blocks. > > Copying RL disks with a block by block copy is not something you'd do. > You'd mount the disk and copy the contents. > > So, all disk blocks are numbered just as you would expect. Bad blocks > are not hidden, or mapped away, or returns zeroes. Doing anything like > that will break existing software. > > Johnny > > On 2015-04-07 00:54, Christopher Parish wrote: > > Progress is good on the RL02-USB controller. I've gotten complete > operation working as expected with the usual tools for disk access > (badblocks, dd, etc.), and SIMH can access the real packs via the > controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is > only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those > with identified bad blocks from the factory) are another story. > > > > > > The issue is most obvious when backing up and restoring disk images. > Suppose I backup a pack with 1 bad sector. I have two choices of what to do > with the bad sector (specifically if it's a bad header), I could skip the > sector (reporting an IO error), or I could report all zeros for the sector. > > > > > > Skipping the sector is a bad idea because the logical address of all > sectors after it will shift down by one. This will make the disk image not > work correctly with SIMH, or anything else for that matter, because most > filesystems address things by physical block (Please correct me if I'm > wrong here). Remember, we're at the device level (/dev/sda) not the > partition level (/dev/sda1). > > > > > > Returning all zeros for bad sectors will preserve the block numbers of > following sectors and work correctly with SIMH, but trying to restore the > resulting image to another physical pack will probably be impossible given > the destination disk pack has bad sectors of its own in different spots. > > > > > > The usual trick of having the controller re-map the bad sectors will not > work because the platters in the RL02 are removable. Writing some mapping > index on the disk pack or holding back sectors in reserve will break > compatibility with the original systems (PDP8s/11s/VAXes) and all their > software (an unacceptable solution). > > > > > > I think I've come to the following conclusions given the restrictions > above: > > > > > > - Creating and Restoring images with EF packs is unrestricted > > > > - SIMH operation with EF packs (online and images) will work perfectly > > > > - Creating images of DC packs will work with SIMH if I return zeros for > the bad blocks > > > > - Online use of DC packs work with SIMH assuming no new bad blocks have > formed since the bad block index was written > > > > - If new bad blocks have formed in a pack, SIMH will have to be modified > so its RL(V)11 can receive error information from the drive, otherwise it > will incorrectly handle the recovery > > > > - Restoring images on DC packs will require special software that can > move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*) > > > > - Using a modern filesystem on EF/DC packs is unrestricted (because they > can identify and manage bad blocks on their own) > > > > > > First, does all of this seem reasonable? > > > > > > I vaguely remember reading about a program on RT-11 you would run > (before?) backing up the filesystem. What was this program? How did it > work? Did it make the data position independent? > > > > > > Christopher > > > > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: bqt at softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > > > ------------------------------ > > Message: 14 > Date: Tue, 7 Apr 2015 12:13:47 +0000 > From: Christopher Parish <christopher.parish at parishcomputers.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Subject: RE: RL02-USB Controller Status/Problem > Message-ID: > > <639FFF5F324E6D409F42CF2B2F3BB56AB0FF0132 at MBX022-E1-NJ-4.exch022.domain.local > > > > Content-Type: text/plain; charset="us-ascii" > > > [...] > > Now, a total imaging of one RL disk to another is not something you > > should do. That would replace the pack serial number, in addition to the > > issues with the bad block lists. Not to mention that different packs > > have bad blocks in different places. > > I agree. You're right that the best way to copy a pack is to load up the > appropriate OS in the simulator and instruct it to do the work. Because it > has knowledge of the filesystem, it will copy around bad blocks, identify > new ones, etc. without stomping on the serial number and factory recorded > bad block data. > > > Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped > > away, or faked. The drive and controller can detect bad blocks, and when > > you try to read one, you'll get an error back. Drivers try a few times, > > and then give up, giving an error back to the user program. > > You should not try anything different. > > [...] > > Johnny > > I will have to patch SIMH to support this paradigm because right now it > expects the backing store for its virtual RL02s to be readable at all > times. IO errors trying to access the underlying "file" halt the > simulator. Additionally, there is no way to report what type of error > occurred via USB mass storage, only that fewer blocks were returned than > expected. > > I think I'll need to have two completely different modes of operation. > > A USB Mass storage mode would use the pack like a modern hard disk. The > controller would hide and internally use the last track for bad block > identification and not expose it to the PC. Also, the controller would > hold some number of sectors in reserve, presenting a flat, error free > ~9.8MB disk to the PC. This would work for modern filesystems but be > completely useless for SIMH and physical computer compatibility. > > The other mode will need to be a non mass storage interface like bulk or > CDC mode specifically for use with SIMH and any custom diagnostics. SIMH > (after modification) would then be able to access all the raw data on the > pack and have access to any errors that occur, handling them however it > wants. Copying packs would need to be done just like it is now, except in > the simulator. You either mount or image and mount the first disk, load > your favorite OS in SIMH attached to the physical drive, and instruct it to > copy disk 1 to disk 2, letting it copy around bad blocks in the manner it > always has (preserving compatibility). > > Christopher > > > > ------------------------------ > > Message: 15 > Date: Tue, 07 Apr 2015 13:41:08 +0100 > From: Pete Turnbull <pete at dunnington.plus.com> > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <5523D064.3040305 at dunnington.plus.com> > Content-Type: text/plain; charset=windows-1256; format=flowed > > On 06/04/2015 23:54, Christopher Parish wrote: > > Progress is good on the RL02-USB controller. I've gotten complete > > operation working as expected with the usual tools for disk access > > (badblocks, dd, etc.), and SIMH can access the real packs via the > > controller's block device (i.e. attach rl0 /dev/sdX). > > Very good! I want one :-) > > > The issue is most obvious when backing up and restoring disk images. > > Suppose I backup a pack with 1 bad sector. I have two choices of what > > to do with the bad sector (specifically if it's a bad header), I > > could skip the sector (reporting an IO error), or I could report all > > zeros for the sector. > > > The usual trick of having the controller re-map the bad sectors will > > not work because the platters in the RL02 are removable. > > DEC does it by having the driver software remap sectors. > > > Writing some > > mapping index on the disk pack or holding back sectors in reserve > > will break compatibility with the original systems (PDP8s/11s/VAXes) > > and all their software (an unacceptable solution). > > Eh? Use the existing bad block table which is on an RL01 or RL02, as on > many other DEC disks. > > Return an error. Unless it's a block that's already in the bad block > table at the end of the disk, in which case return the content of the > remapped block, of course. If you don't do that, you'll break things in > DEC OSs. > > > I vaguely remember reading about a program on RT-11 you would run > > (before?) backing up the filesystem. What was this program? How did > > it work? Did it make the data position independent? > > There are several ways to detect or handle bad blocks in RT-11. I > suspect you're thinking of INIT/BAD or more likely DIR/BAD, or possibly > BACKUP or FORMAT. > > INIT is is the monitor command to create an RT-11 filesystem on a disk; > the /BAD option (full name BADBLOCKS, can be shortened to as little as > /BA) tells it to scan the disk and report any bad blocks it finds. With > no other options, it creates directory entries for files called FILE.BAD > covering those blocks. INIT/BAD:RETAIN keeps any FILE.BAD it finds, and > in most versions doesn't actually scan. This is really meant for > devices that don't have a DEC standard bad block table (like floppies). > > Alternatively INIT/BAD/REPLACE doesn't write FILE.BAD but instead > updates the bad block table at the end of the disk; /REPLACE overwrites > the table, whereas REPLACE:RETAIN adds to it. Note that the DL(X) > drivers in RT-11, as in other DEC OSs, know about the bad block table. > > But of course you wouldn't use INIT just before making a backup ;-) > And it wouldn't work if your controller lies and returns zeros for bad > blocks; that would be a very bad idea and will cause things to fail badly. > > The SQUEEZE command compresses a disk by shuffling up all the files > (except FILE.BAD) to be contiguous (RT-11 always writes individual files > as contiguous blocks on disk but gaps between files can arise as things > are deleted or rewritten). It honours the bad block table (and/or > FILE.BAD), as do other disk utilities, because the drivers do that. If > your driver doesn't, it'll fail. > > If you just want to quickly scan a disk for errors, a common way is to > do COPY/DEV/IGN DLx: NL: which does a block for block copy of the entire > disk to the NULL device, reporting errors but not stopping on them > (/COPY/DEVICE/IGNORE). It's common to do that just after formatting a > disk, but before INIT, for example if you're working with a non-RT-11 > filesystem. BTW, for other COPY operations, it ignores FILE.BAD files, > for obvious reasons, unless you specifically include them. > > You were probably thinking of the DIR command. /BAD is also an option > to DIR; it can tell also you which files are affected by bad blocks. It > scans the entire disk for bad blocks, and even works on non-RT-11 disks. > If it finds any, it will report the block number in octal and decimal, > and tell you if it's "Replaced" or "Replaceable" - ie if it's already in > the bad block table - but it won't change the table for you. The full > syntax is DIRECTORY/BADBLOCKS[/FILES][/START:n][/END:n]. /FILES will > tell you what files are affected, assuming it's an RT-11 filesystem; > /START and /END allow you specify a range rather than the whole disk. > There's also a /WAIT option that pauses to let you change disks before > scanning. > > BACKUP (or BUP) scans the target disk for bad blocks before copying a > saveset to it (and stops if it finds any). > > You can't FORMAT an RL01 or RL02, but you can FORMAT/VERIFY:ONLY one. > That writes patterns over the surface to test it, much more thoroughly > than DIR/BAD, INIT/BAD, COPY/DEV or BACKUP. > > -- > Pete > > Pete Turnbull > > > ------------------------------ > > Message: 16 > Date: Tue, 07 Apr 2015 14:14:18 +0100 > From: Pete Turnbull <pete at dunnington.plus.com> > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <5523D82A.7080804 at dunnington.plus.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 07/04/2015 11:21, Johnny Billquist wrote: > > Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped > > away, or faked. The drive and controller can detect bad blocks, and when > > you try to read one, you'll get an error back. Drivers try a few times, > > and then give up, giving an error back to the user program. > > You should not try anything different. > > Absolutely. > > > Copying RL disks with a block by block copy is not something you'd do. > > You'd mount the disk and copy the contents. > > Actually COPY/DEV under RT-11 is commonly used, especially for non-RT-11 > packs. I can't remember what RSX does, but RT-11 /does/ deal with the > bad block table, by not copying the last track, and copying remapped > blocks. But in general, under other OSs, yes, not a good idea. It > would be like using dd in Unix to copy an entire device, including the > disk label, rather than the partitions. > > -- > Pete > > Pete Turnbull > > > ------------------------------ > > Message: 17 > Date: Tue, 07 Apr 2015 14:24:30 +0100 > From: Pete Turnbull <pete at dunnington.plus.com> > To: "Discussion at classiccmp.org:On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <5523DA8E.9030908 at dunnington.plus.com> > Content-Type: text/plain; charset=windows-1256; format=flowed > > On 07/04/2015 13:41, Pete Turnbull wrote: > > The SQUEEZE command [...] honours the bad block table (and/or > > FILE.BAD), as do other disk utilities, because the drivers do that. > > Actually, thinking about it, SQUEEZE probably does it itself, and the > drivers probably just do error reporting. I think. > > -- > Pete > > Pete Turnbull > > > ------------------------------ > > Message: 18 > Date: Tue, 07 Apr 2015 15:58:36 +0100 > From: Pete Turnbull <pete at dunnington.plus.com> > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <5523F09C.5000900 at dunnington.plus.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 07/04/2015 11:21, Johnny Billquist wrote: > > > The STD144 reserves the last track of the device for pack information. > > In there you have the pack serial number, and also the manufacturer bad > > block list, and also the user bad block list. > > While looking for something quite unrelated, I noticed that the RT-11 > Device Handlers Manual says slightly differently. The user list is > stored, merged with the manufacturing list, in the home block (track 0 > sector 1) of RL01/02 and RK06/07 volumes, beginning at offset 6 > (HB.BAD). The actual replacement blocks are reserved space on the > second last track (or tracks 0,1 of the last cylinder on RK06/7). > > The symbol names for the values in HB.BAD are defined in the .BBRDF > macro in the distributed file SYSTEM.MLB. > Offset Name Meaning > 0 BBR.BD Bad block number. > 2 BBR.GD Replacement block number. > BBR.SZ Entry size. > > RSX-11 may not be the same? > > -- > Pete > > Pete Turnbull > > > ------------------------------ > > Message: 19 > Date: Tue, 7 Apr 2015 11:25:03 -0400 > From: Paul Koning <paulkoning at comcast.net> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <BC740651-507D-4C80-891E-38A3726B2641 at comcast.net> > Content-Type: text/plain; charset=utf-8 > > > > On Apr 7, 2015, at 8:41 AM, Pete Turnbull <pete at dunnington.plus.com> > wrote: > > > > On 06/04/2015 23:54, Christopher Parish wrote: > >> Progress is good on the RL02-USB controller. I've gotten complete > >> operation working as expected with the usual tools for disk access > >> (badblocks, dd, etc.), and SIMH can access the real packs via the > >> controller's block device (i.e. attach rl0 /dev/sdX). > > > > Very good! I want one :-) > > > >> The issue is most obvious when backing up and restoring disk images. > >> Suppose I backup a pack with 1 bad sector. I have two choices of what > >> to do with the bad sector (specifically if it's a bad header), I > >> could skip the sector (reporting an IO error), or I could report all > >> zeros for the sector. > > > > > The usual trick of having the controller re-map the bad sectors will > > > not work because the platters in the RL02 are removable. > > > > DEC does it by having the driver software remap sectors. > > No, DEC does not do that. At least not in RSX, as Johnny described, nor > in RSTS. > > In RSTS, creating a file system on a pack is done with the ?dskint? > utility. One of its functions is to perform a drive scan, writing and > verifying all sectors with several data patterns. If a sector is found to > be bad, it is handled simply by allocating it to the reserved file > [0,1]badb.sys. This scheme works for all drive types, including those that > predate DEC Std 144. On packs that have a bad block table, the blocks > listed in that table are includes in the bad block list that dskint > determines (I don?t remember if they are checked anyway, or bypassed in the > check). > > I also don?t remember if there was a way to handle blocks going bad > later. In principle, yes; they could be allocated to badb.sys also. If > so, a file system check (?onlcln?) would find a double allocated block and > let you delete the file that was affected. > > The first drive type I know of that had anything resembling remapping is > the RM80, with the ?skip sector? feature, where each track had an extra > sector, and a flag in the sector header could be used to mark that sector > as ?skip me and use the spare sector instead?. The first real remapping > appeared in MSCP, which makes sense because that is the first time that DEC > drives used logical addressing instead of hard cylinder/track/head > addressing. At first (UDA50), remapping was done largely in the driver, > requiring a quantity of code way larger than any other disk driver. In > subsequent MSCP controllers, it moved entirely into the controller and the > host simply saw an error free logical block space. > > Given all this, an image copy of a disk is not valid, unless the > destination disk is error free. (Early packs usually were, which is why > early PDP11 backup programs like ROLLIN did use image copy.) If the > destination disk has errors, the copying has to be at the file system > level, either by just copying all files one by one, or by doing an image > copy that works around destination flaws. The RSTS standalone backup > program SAVRES is an example of the latter. > > paul > > > > ------------------------------ > > Message: 20 > Date: Tue, 07 Apr 2015 17:56:34 +0200 > From: Johnny Billquist <bqt at update.uu.se> > To: cctalk at classiccmp.org > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <5523FE32.5010600 at update.uu.se> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 2015-04-07 15:14, Pete Turnbull wrote: > > On 07/04/2015 11:21, Johnny Billquist wrote: > >> Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped > >> away, or faked. The drive and controller can detect bad blocks, and when > >> you try to read one, you'll get an error back. Drivers try a few times, > >> and then give up, giving an error back to the user program. > >> You should not try anything different. > > > > Absolutely. > > > >> Copying RL disks with a block by block copy is not something you'd do. > >> You'd mount the disk and copy the contents. > > > > Actually COPY/DEV under RT-11 is commonly used, especially for non-RT-11 > > packs. I can't remember what RSX does, but RT-11 /does/ deal with the > > bad block table, by not copying the last track, and copying remapped > > blocks. > > But that don't make sense. You cannot just move one block somewhere else > because it is bad on the target device. Or just ignore a block because > it is bad on the source device. > > And "remapped" must be something very local to RT-11. RSX do not remap > any blocks. A block that is bad, is bad. It is still there. No other > block is substituted for the bad block. And where would those > substitution blocks come from? There are no hidden extra blocks on an RL > pack. > > RSX simply deals with bad blocks on an RL pack by making sure no file > accidentally gets them, by putting all the bad blocks into a specific > file on the file system, intended to hold bad blocks. > > > But in general, under other OSs, yes, not a good idea. It > > would be like using dd in Unix to copy an entire device, including the > > disk label, rather than the partitions. > > Yes. > > Johnny > > > > ------------------------------ > > Message: 21 > Date: Tue, 07 Apr 2015 17:59:04 +0200 > From: Johnny Billquist <bqt at update.uu.se> > To: cctalk at classiccmp.org > Subject: Re: RL02-USB Controller Status/Problem > Message-ID: <5523FEC8.2070308 at update.uu.se> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 2015-04-07 16:58, Pete Turnbull wrote: > > On 07/04/2015 11:21, Johnny Billquist wrote: > > > >> The STD144 reserves the last track of the device for pack information. > >> In there you have the pack serial number, and also the manufacturer bad > >> block list, and also the user bad block list. > > > > While looking for something quite unrelated, I noticed that the RT-11 > > Device Handlers Manual says slightly differently. The user list is > > stored, merged with the manufacturing list, in the home block (track 0 > > sector 1) of RL01/02 and RK06/07 volumes, beginning at offset 6 > > (HB.BAD). The actual replacement blocks are reserved space on the > > second last track (or tracks 0,1 of the last cylinder on RK06/7). > > > > The symbol names for the values in HB.BAD are defined in the .BBRDF > > macro in the distributed file SYSTEM.MLB. > > Offset Name Meaning > > 0 BBR.BD Bad block number. > > 2 BBR.GD Replacement block number. > > BBR.SZ Entry size. > > > > RSX-11 may not be the same? > > You are thinking of/referring to how the file system works. The bad > block list on the last track is not directly used by the system, since > this is different from one device to the next. > RL drives have bad block information on the last track. It is not OS > dependent. > > Johnny > > > > End of cctalk Digest, Vol 6, Issue 7 > ************************************ > -- Edward Austin/?? ????? 109147, ??????, ??????, ??. ????????????, ?. 3 gsm: +44 (0)7726 05 0000 (UK) gsm: +7 925 871 94 11 (Moscow) ed at ryer.ru

11 years, 2 months

2
1
0 0

UK PDP11 wanted

by jnc＠mercury.lcs.mit.edu

> From: Edward Austin > I am tempted to by a working MicroPDP 11/73 in a BA-23 from eBay US for > $1200, but shipping and taxes would make this at least 50% more See if you can buy the chassis in the UK/EU, that's the heavy part (i.e. costs the most to ship). You could then buy cards in the US, and have them sent to you trans-Atlantic; being light, they won't cost much to send. (I will help, if a seller won't ship internationally - I can also test the cards to make sure they are working before dispatching them.) 11/73 CPU cards come up regularly for not too much (I just bought one for $46), and memory, etc can also be had for not too much. What do you want to do about mass storage? That's going to be the hard part, IMO. Noel~h

11 years, 2 months

1
0
0 0

ISO Compaq ISA EGA card and monitor

by aek＠bitsavers.org

A situation came up where CHM wanted to film a Compaq Deskpro 386, but we didn't have one, so I've been trying to put a first generation system together (circa 1987), but I'm having trouble locating a Deskpro 386 keyboard, and Compaq EGA card and monitor. Does anyone have this kicking around?

11 years, 2 months

1
0
0 0

Siemens FDD200 configuration

by supervinx＠libero.it

Hi! Got two FDD200, 8" drives. I revised their config with the manual handy. They seem OK for my needs (reading soft sectored IBM disks) except for a thing. They are configured for radial selection but with dedicated SELECT lines for heads/side. The first disk responds to SELECT lines 0 and 2, respectively for HEAD 0 and 1. The second disk responds to SELECT lines 1 and 3, for HEAD 0 and 1. This can easily be reverted moving a soldered wire jumper. I'd like to know why they were configured that way. I'll use the FDADAP adapter, BTW. Thanks!

11 years, 2 months

2
1
0 0

Seeking H7861 Power Supply (PDP 11/23+)

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > 2) Assuming H7681, do you know how to wire a chassis that expects H768 > to work with H7681? Or vice versa? AFAIK, there is nothing to it. The backplane normally used with the H786, the H9273, has exactly the same kind of power connector as the one used with the H7861, the H9276 - a terminal block. The pinout is, IIRC, identical. There's also a duPont connector on a flat cable (10 or 12 pin, don't recall off the top of my head), which carries BPOK and things like that, and that also is has an identical pinout. And finally they are the exact same size and shape, with the same fasteners in the same locations. Hence my prior assertion that "have looked at both closely, and verified that they have the same interfaces and physical dimensions, etc, so I think this will work, but I have yet to actually try it [to absolutely verify it]". Although I've just noticed that the BA11-N (the H786/H9273) has an H403-A AC control box, and the BA11-S (the H7861/H9276) has an H403-B. I don't know what the difference is between the two: higher current rating, would be my guess, since the H786 puts out 15A of +5V, whereas the H7861 can do 36A. But no, the BA11-N says its max input is 12A at 120 VAC - although that includes powering an auxilliary AC outlet. The H756 P/S alone draws 5.5A; the H7561 is the exact same. (Wow, double the efficiency...) So the auxiliary outlet must be the difference - sure enough, the BA11-S doesn't have one. So I still think you're good to go! :-) Noel

11 years, 2 months

1
0
0 0

settings for DEC M7506 (MSV11-M)

by pete＠dunnington.plus.com

Does anyone have a description of the switch settings for a QBus MSV11-M (aka MSV1M) memory card (M7506)? I have one that doesn't want to play, and I can't find the manual (EK-MSV1M-UG) or any useful notes anywhere. -- Pete Pete Turnbull

11 years, 2 months

1
0
0 0

HP 2640B badge?

by isking＠uw.edu

Hi all, I recently picked up an HP 2640B (thanks, Josh!) and I'm restoring it. The keyboard cable was cut - but the mainframe end was thrown away - but I found a printer cable that uses the same connector, and I don't have a printer adapter for it. It has bad screen mold, but I have A Plan - I'm going to try soaking the face of the CRT face-down in acetone, to see if it will dissolve/loosen the offending adhesive. It's also missing the badge plate: that part behind the keyboard and below the screen that has the HP logo and the terminal name. Is there a chance anyone out there has a parts-beast 2640B and would part with that badge plate? In the alternative, maybe take some really good photos so I can have one of my friends with a 3D printer make the badge bits, which I can fasten to something Close Enough for Folk Music? I plan to hook this up to my HP-1000 - I also picked up a HP-IB cable so I can connect the -1000 to a (real) floppy or (emulated) hard disk. Fun stuff! -- Ian PS: I'll be at VCF/e next week. -- Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <http://ischool.uw.edu> Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org> Value Sensitive Design Research Lab <http://vsdesign.org> University of Washington There is an old Vulcan saying: "Only Nixon could go to China."

11 years, 2 months

2
2
0 0

BA23 Chassis available in Lexington KY

by keith＠saracom.com

Hello, I am in the process of moving and need to pare down my spare parts collection. I have several BA23 chassis with power supplies. I do not know the condition as they have been stored in my shed for years. They do not include modules or outer shells. If you pickup in Lexington KY, they are free. Thanks Max

11 years, 2 months

5
4
0 0

RD54 Stopped Spinning

by shadoooo＠gmail.com

Hello, apart from the transistors, I would check for some bad capacitor. The analog part with the sensors needs quite clean supply to work good, while the motor itself is a big source of spikes and pulses. Possibly there could be some supply filter, with electrolytic capacitors not working as expected due to age... or with excessive current leakage. Andrea

11 years, 2 months

2
1
0 0

Sun 19" Monochrome Monitor (Model M / M01)

by pete＠hollobon.co.uk

Hi, I have a Sun 19" monochrome Model M monitor to give away. I have no idea if it works - it made a fizzing noise upon applying briefly applying power so probably needs at least some work. I used to use it on a 3/60 which I no longer have. Made in USA SvCd: M01 Part#: 365-1014-01 Model: M Ser: 848F1051 Date: 29-nov-88 ElecRatings: 100-120/200-240ACV 50/60Hz 1.6/1.0A I have a couple of photos if anyone's interested. Free of charge. Collection only, from Sutton, south-west London, UK. It'll be off to the dump on Saturday if no interest by then. Pete.

11 years, 2 months

1
0
0 0

Seeking H7861 Power Supply (PDP 11/23+)

by jnc＠mercury.lcs.mit.edu

> From: Cory Heisterkamp > If someone has one for sale (this one marked H7861), please let me > know. Someone on eBay is selling one: http://www.ebay.com/itm/150947900783 They are asking $125, which is not wholly ridiculous, and will probably take slightly less. I've bought several from this seller, and they are in good shape. Also, at a pinch, I'm pretty sure (as in, I have looked at both closely, and verified that they have the same interfaces and physical dimensions, etc, so I think this will work, but I have yet to actually try it) an H786 would also work in that system. The only difference I know of is that the H7861 puts out a few more amps of +5V. No reasonably priced H786's on eBay at the moment, though. > It looks serviceable and is likely repairable by an expert so that > could be an option, too. I'd interested in buying the dead one from you (which should help offset the cost if you go for the eBay one) - please contact me off line if interested. Noel

11 years, 2 months

2
1
0 0

Looking for....

by jwest＠classiccmp.org

I need another operational HP 7970E mag tape controller (13183 - 2 board set). It appears that the spare board sets I have are 13181 which I believe is only for the 7970A/B. All my drives are 7970E, so is there any chance someone has a 7970A/B but has a 13183 and would like to swap my 13181 for it? J Or if anyone has a spare 13183 they want to sell/trade... Best, J

11 years, 2 months

1
0
0 0

BA23 Chassis available in Lexington KY - Taken

by keith＠saracom.com

OK, I think all of them have been claimed now. If not I will report. Now to see what else is in the shed. thanks ------------------------------ Message: 16 Date: Mon, 6 Apr 2015 11:06:31 -0400 From: Jacob Ritorto <jacob.ritorto at gmail.com> To: "General Discussion: On-Topic Posts" <cctech at classiccmp.org> Subject: Re: BA23 Chassis available in Lexington KY Message-ID: <CAHYQbfBp7WuiR5qSfeR39tDMBQKGHvg2Vk8vw5FGgewSOjBzug at mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hey Max, I'll take a couple. You're a six-hour's drive from me, so it'll take me a sec to figure out when. How's Friday for you? On Sun, Apr 5, 2015 at 6:47 PM, <keith at saracom.com> wrote: >> Hello, I am in the process of moving and need to pare down my spare parts collection. I have several BA23 chassis with power supplies. I do not know the condition as they have been stored in my shed for years. They do not include modules or outer shells. If you pickup in Lexington KY, they are free. Thanks Max > ************************************

11 years, 2 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb