From nico at farumdata.dk Fri Feb 1 02:20:19 2019 From: nico at farumdata.dk (Nico de Jong) Date: Fri, 1 Feb 2019 09:20:19 +0100 Subject: DEC TKZ10 Tapes In-Reply-To: References: Message-ID: <008f0194-19c2-7951-df83-5471d840db57@farumdata.dk> Hi *Bill I have 3x Bull 3215 tapes if you are willing to pay the postage from Denmark. I can erase them on a Tandberg drive, if you want. Nico On 31-01-2019 22:33, Bill Gunshannon via cctalk wrote: > Does anyone have any DC6525 tape cartridges they would be willing > to part with? One of the Expansion boxes on my VAX has a TKZ10 > but none of the older QIC tapes I have can handle the format from > this drive. > > bill From bill.gunshannon at hotmail.com Fri Feb 1 09:48:04 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Fri, 1 Feb 2019 15:48:04 +0000 Subject: DEC TKZ10 Tapes In-Reply-To: <008f0194-19c2-7951-df83-5471d840db57@farumdata.dk> References: <008f0194-19c2-7951-df83-5471d840db57@farumdata.dk> Message-ID: On 2/1/19 3:20 AM, Nico de Jong via cctalk wrote: > Hi *Bill > > I have 3x Bull 3215 tapes if you are willing to pay the postage from > Denmark. I can erase them on a Tandberg drive, if you want. > > Nico > > > On 31-01-2019 22:33, Bill Gunshannon via cctalk wrote: >> Does anyone have any DC6525 tape cartridges they would be willing >> to part with?? One of the Expansion boxes on my VAX has a TKZ10 >> but none of the older QIC tapes I have can handle the format from >> this drive. >> >> bill > Thanks for the offer but I have had some offers from this side of the pond. bill From binarydinosaurs at gmail.com Fri Feb 1 17:28:16 2019 From: binarydinosaurs at gmail.com (Adrian Graham) Date: Fri, 1 Feb 2019 23:28:16 +0000 Subject: tape transport drive belts Message-ID: <9A968B59-232C-4EB6-8A75-21397AABECCF@gmail.com> Evening folks, I?m bringing a Sharp MZ80B back to life and have so far fixed a horizontal collapse problem on the video board meaning I can see what it?s prompting for at boot. I remember when I first got this machine back in 2003-ish I dismantled it and discovered some of the tape transport had melted and gummed up the automatic head mechanism. Fast forward* 15 years and I have the transport in bits again on the bench and I can see that one belt has melted and another is on the way to collapse. Did we ever find a reasonable source of replacement belts? I know a couple of collector friends with 3D printers have printed replacements but this is new tech and I need old tech :) Cheers! *sorry, pun intended -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk From djg at pdp8online.com Fri Feb 1 19:37:48 2019 From: djg at pdp8online.com (David Gesswein) Date: Fri, 1 Feb 2019 20:37:48 -0500 Subject: More facets of hard disk recovery (SA1000, RD53) and emulation Message-ID: <20190202013748.GA12124@hugin2.pdp8online.com> I have made a SA1000 adapter board for my MFM reader emulator. I did a small run which seems to work so if you are interested email me to get in on the next order. Prices may get a little better if I get enough orders. http://www.pdp8online.com/mfm/ http://www.pdp8online.com/mfm/sa1000/sa1000_usage.shtml I have used it for reading Shugart SA1004 and Quantum Q2040 drives. Another has used it to replace drive in a TRS-80 Model II 8 Meg drive unit. Some other items that may be of interest: Dealing with stuck head problem with Quantum Q2040 drives http://www.pdp8online.com/q2040/q2040.shtml Using a DAC to pull the head servo to recover otherwise unreadable data from DEC RD53 drive. Also procedure tried for Q2040 but data had been erased so not successful. http://www.pdp8online.com/mfm/head_servo/ From mbbrutman at brutman.com Sat Feb 2 09:05:49 2019 From: mbbrutman at brutman.com (Michael Brutman) Date: Sat, 2 Feb 2019 07:05:49 -0800 Subject: Last call: Exhibitors for VCF PNW 2019 Message-ID: If you were thinking of joining us for VCF PNW 2019 in Seattle then now is the time to let me know! The event is March 23-24th (Saturday and Sunday) with setup the day before. We still have room for some more exhibits if you are interested in joining us. If you are going to join us I need to know by Friday, February 8th. If you have told me you were coming but did not complete the registration form, well, now is the time ... A description of the event can be found at http://vcfed.org/vcf-pnw . General information for exhibitors including pictures from last year, a link to the registration form, and a FAQ can be found at http://vcfed.org/wp/vcf-pnw-exhibitor-registration/ . Also, yell at me directly if you have questions Thanks, Mike mbbrutman at brutman.com or michael at vcfed.org PS: Not exhibiting at the event but interested in unloading some tonnage? We're doing a consignment area again, and that's open to everybody. Now is a good time to start cleaning and testing things that you might want to sell. From cube1 at charter.net Sat Feb 2 07:43:16 2019 From: cube1 at charter.net (Jay Jaeger) Date: Sat, 2 Feb 2019 07:43:16 -0600 Subject: More facets of hard disk recovery (SA1000, RD53) and emulation In-Reply-To: <20190202013748.GA12124@hugin2.pdp8online.com> References: <20190202013748.GA12124@hugin2.pdp8online.com> Message-ID: <289cbad2-1d5b-dbd0-7e8c-0d394e1c6f64@charter.net> Are these bare boards you would sell, or populated? (I would guess the former, yes?) Price (for both the MFM reader and the SA1000 adapter)? JRJ On 2/1/2019 7:37 PM, David Gesswein via cctech wrote: > I have made a SA1000 adapter board for my MFM reader emulator. I did a > small run which seems to work so if you are interested email me to get > in on the next order. Prices may get a little better if I get enough > orders. > > http://www.pdp8online.com/mfm/ > http://www.pdp8online.com/mfm/sa1000/sa1000_usage.shtml > > I have used it for reading Shugart SA1004 and Quantum Q2040 drives. > Another has used it to replace drive in a TRS-80 Model II 8 Meg drive unit. > > Some other items that may be of interest: > > Dealing with stuck head problem with Quantum Q2040 drives > http://www.pdp8online.com/q2040/q2040.shtml > > Using a DAC to pull the head servo to recover otherwise unreadable data > from DEC RD53 drive. Also procedure tried for Q2040 but data had been erased > so not successful. > http://www.pdp8online.com/mfm/head_servo/ > > From jfoust at threedee.com Sat Feb 2 11:24:33 2019 From: jfoust at threedee.com (John Foust) Date: Sat, 02 Feb 2019 11:24:33 -0600 Subject: More facets of hard disk recovery (SA1000, RD53) and emulation In-Reply-To: <289cbad2-1d5b-dbd0-7e8c-0d394e1c6f64@charter.net> References: <20190202013748.GA12124@hugin2.pdp8online.com> <289cbad2-1d5b-dbd0-7e8c-0d394e1c6f64@charter.net> Message-ID: <20190202172446.02858274CF@mx1.ezwind.net> At 07:43 AM 2/2/2019, you wrote: >Are these bare boards you would sell, or populated? (I would guess the >former, yes?) > >Price (for both the MFM reader and the SA1000 adapter)? I think that's all at http://www.pdp8online.com/mfm/ . - John From robert at irrelevant.com Sat Feb 2 17:34:05 2019 From: robert at irrelevant.com (Rob) Date: Sat, 2 Feb 2019 23:34:05 +0000 Subject: Vax sw: Computex Plus Message-ID: Hi. Has anybody got a copy of this? It's a viewdata host program. https://www.cbronline.com/news/applied_telematics_adds_minitel_access_from_uk_to_its_viewdata_software/ Even better would be an installed database.. Ta. Rob. -- Sent from a mobile device. Please excuse brevity or spoiling mistooks. From bill.gunshannon at hotmail.com Sun Feb 3 13:13:21 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sun, 3 Feb 2019 19:13:21 +0000 Subject: TU-58 support under Unix Message-ID: Here's a question for someone who has been around long enough to remember. Why did none of the available PDP-11 Unixes support the TU-58? I have looked at Ultrix-11, V7M and BSD 2.11 (didn't try 2.9 but I suspect if it isn't in 2.11 it wasn't in 2.9) and none of them had support for the TU-58. Seems to me it would have been a rather simple device to handle as it ran over a serial line. bill From jnc at mercury.lcs.mit.edu Sun Feb 3 14:21:01 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 3 Feb 2019 15:21:01 -0500 (EST) Subject: TU-58 support under Unix Message-ID: <20190203202101.BA8F618C07A@mercury.lcs.mit.edu> > From: Bill Gunshannon > Why did none of the available PDP-11 Unixes support the TU-58? > I have looked at Ultrix-11, V7M and BSD 2.11 The 'TUHS' list might be more likely turn up the reasoning? Noel From aaron at aaronsplace.co.uk Sun Feb 3 14:41:51 2019 From: aaron at aaronsplace.co.uk (Aaron Jackson) Date: Sun, 03 Feb 2019 20:41:51 +0000 Subject: TU-58 support under Unix In-Reply-To: References: Message-ID: <87ftt4zjsg.fsf@walrus.rhwyd.co.uk> TU-58 support wouldn't need to be in the kernel, it could easily run in user space. Perhaps someone had written an application in user-space to dump TU-58 tapes. Aaron. Bill Gunshannon via cctalk writes: > Here's a question for someone who has been around long enough to > remember. > > Why did none of the available PDP-11 Unixes support the TU-58? > I have looked at Ultrix-11, V7M and BSD 2.11 (didn't try 2.9 > but I suspect if it isn't in 2.11 it wasn't in 2.9) and none > of them had support for the TU-58. Seems to me it would have > been a rather simple device to handle as it ran over a serial > line. > > bill -- Aaron Jackson - M6PIU http://aaronsplace.co.uk/ From pontus at Update.UU.SE Sun Feb 3 15:22:42 2019 From: pontus at Update.UU.SE (Pontus Pihlgren) Date: Sun, 3 Feb 2019 22:22:42 +0100 Subject: Looking for Limited Function Board Message-ID: <20190203212242.GF24947@Update.UU.SE> Hi I'm restoring a PDP-8/a with the help of some friends. The CPU is now passing the MAINDECs I've thrown at it. The memory is a modern semiconductor board my friend Anders Sandahl made. This machine is pieced together from several others and the limited function panel I got does not match the backplane I have. My theory is the DEC simplified the design of the boardto cut costs and simpler design is not compatible. Mine is labeled (on the PCB): "LIMITED FUNCTION BD. 5411507 5011506C-P2" And the one I need is: "LIMITED FUNCTION 5411165 5011167" However, the picture I have of the other is not so good. I may have read the numbera wrong. I would very much like to buy one to finish this project. /P From bill.gunshannon at hotmail.com Sun Feb 3 15:33:27 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sun, 3 Feb 2019 21:33:27 +0000 Subject: TU-58 support under Unix In-Reply-To: <87ftt4zjsg.fsf@walrus.rhwyd.co.uk> References: <87ftt4zjsg.fsf@walrus.rhwyd.co.uk> Message-ID: On 2/3/19 3:41 PM, Aaron Jackson wrote: > TU-58 support wouldn't need to be in the kernel, it could easily run in > user space. Perhaps someone had written an application in user-space to > dump TU-58 tapes. I was looking for a device driver and when I didn't find it I looked at SPD's and release notes, No mention of the TU-58 at all. And this just as I am about to build a real TU-58 emulator. :-) bill From markwgreen at rogers.com Sun Feb 3 16:13:02 2019 From: markwgreen at rogers.com (GREEN) Date: Sun, 3 Feb 2019 17:13:02 -0500 Subject: TU-58 support under Unix In-Reply-To: References: <87ftt4zjsg.fsf@walrus.rhwyd.co.uk> Message-ID: I built support under V6 all in user space. That would be in the early 1980s and I don?t recall it being very difficult. I suspect others did that as well. Have you tried looking in the USENIX tapes? Sent from my iPhone > On Feb 3, 2019, at 4:33 PM, Bill Gunshannon via cctalk wrote: > >> On 2/3/19 3:41 PM, Aaron Jackson wrote: >> TU-58 support wouldn't need to be in the kernel, it could easily run in >> user space. Perhaps someone had written an application in user-space to >> dump TU-58 tapes. > > I was looking for a device driver and when I didn't find it I > looked at SPD's and release notes, No mention of the TU-58 at > all. And this just as I am about to build a real TU-58 emulator. > :-) > > bill > From bill.gunshannon at hotmail.com Sun Feb 3 19:06:46 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 4 Feb 2019 01:06:46 +0000 Subject: TU-58 support under Unix In-Reply-To: References: <87ftt4zjsg.fsf@walrus.rhwyd.co.uk> Message-ID: On 2/3/19 5:13 PM, GREEN wrote: > I built support under V6 all in user space. That would be in the early 1980s and I don?t recall it being very difficult. I suspect others did that as well. Have you tried looking in the USENIX tapes? > I will probably look at writing a driver once I have some systems running them again. Have any of the USENIX Tapes survived? My recollection is they weren't very good about preserving things. bill From jsw at ieee.org Sun Feb 3 20:51:56 2019 From: jsw at ieee.org (Jerry Weiss) Date: Sun, 3 Feb 2019 20:51:56 -0600 Subject: TU-58 support under Unix In-Reply-To: References: Message-ID: My speculation would be that TU58 did not add anything of value or convenience to these systems. I used Ultrix-11, V7M, Venix in this era.? My recollection is that in most cases to build these systems and patch them, you needed regular access? to 800/1600 BPI tape. Given this relatively standard media, the addition of a smaller, slower, proprietary secondary tape media would at best be a low priority.??? Throw in the raise of floppy media, then Ethernet, it becomes even less so.? Also this was a fixed block type device, so any use between different OS's would have required additional utilities and/or OS support to transfer files. We had TU58's in our VAX 11/750? and few computerized medical systems.? Only on the later did we ever use them to move data on a regular basis.? This was for research purposes as vendor had not made any other arrangements for data offloading.? The TU58's were in a small semi-portable cabinet.? Thus they could be added and removed quickly w/o altering the qualification of the medical device. ?Jerry On 2/3/19 1:13 PM, Bill Gunshannon via cctalk wrote: > Here's a question for someone who has been around long enough to > remember. > > Why did none of the available PDP-11 Unixes support the TU-58? > I have looked at Ultrix-11, V7M and BSD 2.11 (didn't try 2.9 > but I suspect if it isn't in 2.11 it wasn't in 2.9) and none > of them had support for the TU-58. Seems to me it would have > been a rather simple device to handle as it ran over a serial > line. > > bill From jnc at mercury.lcs.mit.edu Mon Feb 4 04:28:08 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Feb 2019 05:28:08 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> So I've been helping Fritz look into his -11/45 problem, and things have gotten to a point where I'd like to reach out for help, more eyes, etc. I have to say, I spent almost a decade at the start of my career working on PDP-11 hardware ('new build' DMA devices, as well as fixing broken stuff), and software, and this is, I think, the most confusing and difficult problem I have _ever_ seen on one. Hence the above... What's _particularly_ confusing and difficult is that it seems like _three_ separate, un-related things all go wrong at exactly (2 of 3) or close to (the other) the same time. And the machine now passes all the diagnostics that have been thrown at it, particularly the KT11 and RK11 diagnostics (why this is important will become clear). So here's what we've found to date. The failure we're looking at is that an attempt to execute the 'ls' command under Unix V6 fails; it gets a memory mangement fault, and dumps core. AFAICT, the shell successfully forks, and its attempt to do an exec() of 'ls' sort of works (more below), but a few instructions in, we get the MM fault - but there's even more wrong when that happens (details toward the end below). I've been looking at the core dump produced by the process, which gives me the registers at the time of the trap, the user's stack, etc - but not a copy of the binary code - the 'ls' command is a so-called 'pure text', i.e. the binary is segregated into separate, potentially shared, read-only 'segment(s)' (only 1 in this case) of the PDP-11's User mode address space, and is not included in the process dump. (I use the term 'segment', which is actually what DEC called them in the first version of the PDP-11/45 processor handbook, because that's what they are, not pages, as pages are on most systems. I assume they changed to 'page' for marketing reasons. And please, can we hold debate about this and focus on the problem? Thanks! :-) I do have the ability to look at the binary that it _should_ be executing, by examining the command in its file. Also, Fritz has worked out that he can patch the MM trap vector (before trying to do the 'ls') to halt the machine when it happens, so he can read out all the KT11 registers, look at the actual program in main memory, etc. First oddity - the problem is dependent on the location of the command in main memory! If Fritz says "sleep 360 &", to run a trivial command in the background, and _then_ says 'ls' - it works (so we know the binary of 'ls' on disk is OK)! We _think_ this is because the process executing the 'sleep' takes up a chunk of main memory, and thus changes the location of the process executing the 'ls'. The problem is that I'm reluctant to try and change anything (e.g. to have the OS print out anything) because that will change the location of things, and we may (likely?) will not get the problem. With nothing changed, it _reliably_ fails - I've looked at two different core dumps, and all the essential data (registers, user stack etc) are identical. The KT11 registers all seems to be the same, too. So, on to details. I'm pretty sure the command only gets a few instructions in before it blows up. Here are the process' registers, and the _entire_ contents of the user mode stack: R0 177770 R1 0 R2 0 R3 0 R4 34 R5 444 SP 177760 PC 010210 060: 000000 000020 000001 177770 177774 177777 071554 000000 010210 turns out to be the first word in 'csv', which is an internal routine which PDP-11 C uses to build a stack frame - _every_ C routine starts with a "JSR R5, CSV" instruction as the first thing it does. So looking at the stack (which looks good; it contains a valid 'argc' and 'argv' that the process would be started with), and the registers, I'm pretty sure it does these starting instuctions OK: start: setd mov sp,r0 mov (r0),-(sp) tst (r0)+ mov r0,2(sp) jsr pc,_main _main: jsr r5,csv and then blows up on: csv: mov r5,r0 So it's the 8th instruction in that blows up (*): but not only is what's in memory at that location _not_ 'mov r5,r0', it also gets an MM trap that makes no sense. (*: In user mode: if you don't have an FPP, the first one will trap, which UNIX ignores.) Fritz has looked at the KT11 register when the trap happens, and the PARs and PDRs all look good. The SSRs contain: > SSR's: 040143 000000 010210 000000 SSR2 gives the PC at the time of the fault (again 010210); SSR0 shows: Abort - segment (page) length error User mode Segment (Page) 1 which is the first thing that's wrong - neither the instruction that's _supposed_ to be there (next), nor the one that's _actually_ there, contains any reference to segment 1! The _actual_ code it's trying to execute is: > 171600: 016162 004767 000224 000414 006700 006152 006702 006144 (Per UISA0, text base is 0161400, plus a PC of 010210, gives us 0171610, which is right in the middle there.) That does not, alas, look anything _at all_ like what's _supposed_ to be there, which is: 010200: 110024 10400 mov r4,r0 167 jmp 10226 (cret) 16 PC-> 10500 mov r5,r0 (start of CSV) 10605 mov sp,r5 10446 mov r4,-(sp) 10346 mov r3,-(sp) So somehow the command (at least, this part of it - Fritz is going to check on the first few instructions, but I'm pretty sure they will be OK) has gotten read in wrong - but that's the least of our problems! 06700 is 'SXT R0', and neither that nor 'MOV R5, R0' can _possibly_ cause an MM violation - least of all one on segment 1 (this code is in segment 0)! I could see there having been an error reading in the command binary (e.g. maybe the RK11 has an issue), but WTF is happening here? Just to make things triply confusing, R5 contains trash! The 'JSR R5, CSV' _should have put the old PC in R5; but that call to CSV is at 030, so R5 _should_ contain 034, not 0444. Needless to say, this is a real head-scratcher. What's confusing the heck out of me are the three separate issues, all happening together - R5 contains junk, the spurious (?) MM trap, etc. The bad command binary in main memory could be caused by any number of things: to get it, Unix reads file system blocks off the disk into buffers in low memory, and then writes them out to the user's memory with MTPI. So an RK11 glitch could be doing it, but also a KT11 problem, etc. I'm having a hard time seeing a common thread here - maybe a KT11 issue? But how would that cause R5 to contain trash? That should only involve the KB11. And the JSR R5, CSV must have been executed more-or-less OK, otherwise how did it wind up at CSV? I was wondering if some noise could be causing it - some sort of pattern sensitiity - but how is it bashing R5 _and_ causing a spurious MM trap? That's some glitch! Most of the data above (e.g. SSR contents at trap time) has been re-checked, and Fritz is going to check the rest (e.g. actual main memory contents for the start of the code, and the user's stack - to check that the process' core dump worked OK - although given the consistent stack contents, I'm expecting those to be good). I suggested to him that the time had come to apply the logic analyzer; I'd love to see (from the IR in the CPU) the instruction that faults, and where it came from. And also what the bus cycle is that's causing the fault; is it the instruction fetch (possibly) or something that instruction is trying to do? Does anyone have any comments/insight that could help work out what's going on here? Or suggestions on things to look at? If so, thanks! Noel From elson at pico-systems.com Mon Feb 4 10:20:49 2019 From: elson at pico-systems.com (Jon Elson) Date: Mon, 04 Feb 2019 10:20:49 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> Message-ID: <5C586661.5000906@pico-systems.com> On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote: > > First oddity - the problem is dependent on the location of the command in main > memory! If Fritz says "sleep 360 &", to run a trivial command in the > background, and _then_ says 'ls' - it works (so we know the binary of 'ls' on > disk is OK)! We _think_ this is because the process executing the 'sleep' > takes up a chunk of main memory, and thus changes the location of the process > executing the 'ls'. > > OK, the classic Heisenbug. Is this truly a fault given by the memory management system, or some other kind of fault (Unibus timeout or memory parity error)? If really related to MMU, then maybe there is a bad bit in the MMU that is causing it to reference the wrong segment entry or somehow thinking the setting of that segment entry is invalid. Does the MMU classify what the error condition was, or just assume the trap handler can figure it out be looking at the registers? Anyway, is it possible to borrow an MMU from somebody else? I can easily imagine that the diags can't test every possible bit combination while the diags are ALSO running in memory. So, a somewhat cryptic bug could go undetected. If this fault could be caused by memory, then it may be a pattern-sensitive error, and ls is just the perfect pattern to trip it up. Jon From elson at pico-systems.com Mon Feb 4 10:24:29 2019 From: elson at pico-systems.com (Jon Elson) Date: Mon, 04 Feb 2019 10:24:29 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> Message-ID: <5C58673D.3010506@pico-systems.com> On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote: > So I've been helping Fritz look into his -11/45 problem, and things have > gotten to a point where I'd like to reach out for help, more eyes, etc. > > OH, does this machine have a cache? We had a /45, and got a cache module for it. It DRAMATICALLY speeded up the system, BUT, it caused extremely weird and irreproducible results, so we had to take it out. I never understood the problem, but I think it might have been that the cache did not snoop DMA transfers. It ran a single user fine all day, when a second user started doing things, both users got crashes and garbled data. This was on RSX-11M. Jon From cube1 at charter.net Mon Feb 4 11:13:32 2019 From: cube1 at charter.net (Jay Jaeger) Date: Mon, 4 Feb 2019 11:13:32 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <5C586661.5000906@pico-systems.com> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> Message-ID: On 2/4/2019 10:20 AM, Jon Elson via cctalk wrote: > On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote: >> >> First oddity - the problem is dependent on the location of the command >> in main >> memory! If Fritz says "sleep 360 &", to run a trivial command in the >> background, and _then_ says 'ls' - it works (so we know the binary of >> 'ls' on >> disk is OK)! We _think_ this is because the process executing the 'sleep' >> takes up a chunk of main memory, and thus changes the location of the >> process >> executing the 'ls'. >> >> > OK, the classic Heisenbug.? Is this truly a fault given by the memory > management system, or some other kind of fault (Unibus timeout or memory > parity error)?? If really related to MMU, then maybe there is a bad bit > in the MMU that is causing it to reference the wrong segment entry or > somehow thinking the setting of that segment entry is invalid.? Does the > MMU classify what the error condition was, or just assume the trap > handler can figure it out be looking at the registers? > > Anyway, is it possible to borrow an MMU from somebody else?? I can > easily imagine that the diags can't test every possible bit combination > while the diags are ALSO running in memory. > So, a somewhat cryptic bug could go undetected. > > If this fault could be caused by memory, then it may be a > pattern-sensitive error, and ls is just the perfect pattern to trip it up. > > Jon > If he hasn't already, if Fritz has more than one memory board, he might try swapping them to see if that changes anything. The issue I'd see with the MMU swapout idea would be finding one that would be ECO-compatible with the rest of the processor. This sort of situation, where DEC diagnostics run OK but UNIX has issues was reported to be not all that uncommon - to the point where the urban legend was that some DEC FE's would fire up Unix V6 as a sort of system exerciser. Other things I might be tempted to try in order to coax more information out of the situation: 1. Run the DEC system exerciser, if that has not already been done. 2. Make a copy of ls, and see if the copy also fails (different location on disk would mess with timing just a bit). 3. Use SimH to build a pack image with an instance of ls that is not pure text (no -n or -i flag) 4. Use SimH to build an ls that does/does not start the data segment for ls at 0 (has / does not have the -i flag) [I have not looked to see how ls would normally be built.] 5. Use SimH to gen a pack image with a kernel that is a not split I/D JRJ From bobsmithofd at gmail.com Mon Feb 4 11:18:57 2019 From: bobsmithofd at gmail.com (Bob Smith) Date: Mon, 4 Feb 2019 12:18:57 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> Message-ID: I keep wondering about the psu. I just recall the /45 in my lab was always a little flakey. We suspected everything in the machine, and it was ak to chasing a sea bat in the dark. Our environment in ML 1-2 was not the best, the floor actually moved, we were right at the mid building elevator. We finally had the cpu backplane replaced and the problem went away. On Mon, Feb 4, 2019 at 12:13 PM Jay Jaeger via cctalk wrote: > > On 2/4/2019 10:20 AM, Jon Elson via cctalk wrote: > > On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote: > >> > >> First oddity - the problem is dependent on the location of the command > >> in main > >> memory! If Fritz says "sleep 360 &", to run a trivial command in the > >> background, and _then_ says 'ls' - it works (so we know the binary of > >> 'ls' on > >> disk is OK)! We _think_ this is because the process executing the 'sleep' > >> takes up a chunk of main memory, and thus changes the location of the > >> process > >> executing the 'ls'. > >> > >> > > OK, the classic Heisenbug. Is this truly a fault given by the memory > > management system, or some other kind of fault (Unibus timeout or memory > > parity error)? If really related to MMU, then maybe there is a bad bit > > in the MMU that is causing it to reference the wrong segment entry or > > somehow thinking the setting of that segment entry is invalid. Does the > > MMU classify what the error condition was, or just assume the trap > > handler can figure it out be looking at the registers? > > > > Anyway, is it possible to borrow an MMU from somebody else? I can > > easily imagine that the diags can't test every possible bit combination > > while the diags are ALSO running in memory. > > So, a somewhat cryptic bug could go undetected. > > > > If this fault could be caused by memory, then it may be a > > pattern-sensitive error, and ls is just the perfect pattern to trip it up. > > > > Jon > > > > If he hasn't already, if Fritz has more than one memory board, he might > try swapping them to see if that changes anything. > > The issue I'd see with the MMU swapout idea would be finding one that > would be ECO-compatible with the rest of the processor. > > This sort of situation, where DEC diagnostics run OK but UNIX has issues > was reported to be not all that uncommon - to the point where the urban > legend was that some DEC FE's would fire up Unix V6 as a sort of system > exerciser. > > Other things I might be tempted to try in order to coax more information > out of the situation: > > 1. Run the DEC system exerciser, if that has not already been done. > 2. Make a copy of ls, and see if the copy also fails > (different location on disk would mess with timing just a bit). > 3. Use SimH to build a pack image with an instance of ls that is not > pure text (no -n or -i flag) > 4. Use SimH to build an ls that does/does not start the data segment > for ls at 0 (has / does not have the -i flag) [I have not looked to > see how ls would normally be built.] > 5. Use SimH to gen a pack image with a kernel that is a not split I/D > > JRJ From fritzm at fritzm.org Mon Feb 4 11:20:43 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 4 Feb 2019 09:20:43 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <5C58673D.3010506@pico-systems.com> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C58673D.3010506@pico-systems.com> Message-ID: <8242DE16-75E4-4224-BFFE-15A6E420BDAB@fritzm.org> Hi all; thanks for the write-up on the issue, Noel! > On Feb 4, 2019, at 8:24 AM, Jon Elson via cctalk wrote: > Is this truly a fault given by the memory management system, or some other kind of fault (Unibus timeout or memory parity error)? Trap 250, which is explicitly memory management. > Does the MMU classify what the error condition was, or just assume the trap handler can figure it out be looking at the registers? The MMU classifies the error in register SR0; this decodes to a segment length error (access within the segment beyond configured bound). As Noel notes, however, this is not consistent with the instructions we see at the point of fault. > Anyway, is it possible to borrow an MMU from somebody else? Potentially... It is a two board option; I do have a spare for both of the boards, but these spares each are in need of other repairs at the moment. One slightly complicating factor is that I have a *very* early 11/45. Most of my boards (including the MMU boards), as well as my backplane, pre-date the currently available schematics on bitsavers, etc., and there are no records regarding which ECOs have been applied on my hardware. Thus my interest in tracking down ECOs/FCOs... I've been picking my way through the list that Jay recently posted, verifying by looking at the greenwires which FCO's I have applied and which not. Its a bit painstaking. > I can easily imagine that the diags can't test every possible bit combination while the diags are ALSO running in memory. The "KT11-C Exerciser" diag is a pretty mean beast. It relocates itself around memory, and is pretty thorough. It takes about 45 mins to work its way through testing access to all memory from all segments in all processor modes. It uses the line clock and terminal interface as a source of interrupts to check fault behavior wrt. interrupts, etc. etc. This, and all the other KT11 diagnostics, pass cleanly on the machine. > OH, does this machine have a cache? Nope, no cache. One other thing of note, per the genesis of this thread, RSTS/E also has a consistent failure at boot. As far as we got looking into that before jumping tracks to V6 Unix, the symptoms there looked similar. Paul thought the wreckage indicated a bad binary, but an image of the disk we were trying to boot works fine under SIMH. RT-11, being much more of a honey badger, just works :-) --FritzM. From fritzm at fritzm.org Mon Feb 4 11:34:47 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 4 Feb 2019 09:34:47 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> Message-ID: > On Feb 4, 2019, at 9:13 AM, Jay Jaeger wrote: > > If he hasn't already, if Fritz has more than one memory board, he might > try swapping them to see if that changes anything. I only have an 128kw MS11-L here to work with, unfortunately. Its been through a bunch of recent troubleshooting (tracking down and replacing failed DRAMs). I *think* its pretty solid at this point (also passing some of the hairier DEC diagnostics) but... I'd be happy to try out a different memory board if anybody was interested in sending out a loaner? (I'm in the SF Bay area). > The issue I'd see with the MMU swapout idea would be finding one that > would be ECO-compatible with the rest of the processor. Yes; per previous email. > Other things I might be tempted to try in order to coax more information > out of the situation: > > 1. Run the DEC system exerciser, if that has not already been done. Done; passes consistently. > 2. Make a copy of ls, and see if the copy also fails > (different location on disk would mess with timing just a bit). Also done; the copy appears to behave identically to the original. > 3. Use SimH to build a pack image with an instance of ls that is not > pure text (no -n or -i flag) > 4. Use SimH to build an ls that does/does not start the data segment > for ls at 0 (has / does not have the -i flag) [I have not looked to > see how ls would normally be built.] These may yet be interesting experiments. > 5. Use SimH to gen a pack image with a kernel that is a not split I/D The image I'm using is a /40-compatible one, built from the distro tape, the one that you get before going on to rebuild for /45. So, as Noel has reminded me, no split I/D. But we could try the opposite experiment (build a pack customized for /45) and see if that's different? The pain with that is that it takes me almost three hours to image a pack with PDP11GUI over my DL11, and I have a very limited set of packs with which to work (others on this list have graciously offered to help there; I need to send y'all some shipping boxes!) cheers, --FritzM. From jnc at mercury.lcs.mit.edu Mon Feb 4 12:24:40 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Feb 2019 13:24:40 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190204182440.89B4C18C082@mercury.lcs.mit.edu> > From: Jon Elson > Does the MMU classify what the error condition was Yes, there are a series of bits in SSR0 to indicate the particular error: 'non-resident', 'length', 'read-only', etc (and also the segment number the error's from). As my message mentioned, we're seeing the 'length' error bit on, and for segment 1 (which the instruction isn't using). > is it possible to borrow an MMU from somebody else? Fritz does have a spare board, but it has known errors. We haven't thought about borrowing one yet, it may come to that. > If this fault could be caused by memory Well, _some_ of it could. E.g. if the 'jsr r5, csv' is read as 'jsr r4, csv', dropping the '1' bit in the register number, that would explain the wonky R5 content - R4 does contain the 034 that should be in R5, I have just noticed. But that doesn't explain the bogus MM trap. Although I suppose there could be several different problems, all at the same time. > does this machine have a cache? Nope. Noel From paulkoning at comcast.net Mon Feb 4 12:34:59 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 4 Feb 2019 13:34:59 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> Message-ID: <2BE1E8D6-E280-475F-A99C-EF5543C4E1C0@comcast.net> > On Feb 4, 2019, at 12:18 PM, Bob Smith via cctalk wrote: > > I keep wondering about the psu. I just recall the /45 in my lab was > always a little flakey. > We suspected everything in the machine, and it was ak to chasing a sea > bat in the dark. Good theory. In RSTS development we once ran into DMC-11s not working reliably. The field service tech knew exactly what to look for, and started checking all the supply voltages. The spec says allowed tolerances are +/- 5%. He knew the reality for correct operation was -0%, +5%, so he tweaked all the supplies to read a hair above nominal. Is there any way to attach a logic analyzer to various data paths on this machine? paul From fritzm at fritzm.org Mon Feb 4 12:51:30 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 4 Feb 2019 10:51:30 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <2BE1E8D6-E280-475F-A99C-EF5543C4E1C0@comcast.net> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> <2BE1E8D6-E280-475F-A99C-EF5543C4E1C0@comcast.net> Message-ID: <3D536D69-AE94-41C8-BB42-73B8315426A8@fritzm.org> > On Feb 4, 2019, at 10:34 AM, Paul Koning via cctalk wrote: > >> On Feb 4, 2019, at 12:18 PM, Bob Smith via cctalk wrote: >> >> I keep wondering about the psu. > > Good theory. I'll give these a double-check... > Is there any way to attach a logic analyzer to various data paths on this machine? Yes; the caveat is that it's really only practical to have one card out on extenders at a time (and I have only one hex extender in any case). So you have to be a little choosy about what you want to capture/see. Some things can be plucked from the backplane, but I like to avoid sliding too many probe connectors onto the backplane pins unless I really have to, in order to avoid perturbing the 45-year-old wraps. --FritzM. From imp at bsdimp.com Mon Feb 4 13:06:17 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Feb 2019 12:06:17 -0700 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <2BE1E8D6-E280-475F-A99C-EF5543C4E1C0@comcast.net> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> <2BE1E8D6-E280-475F-A99C-EF5543C4E1C0@comcast.net> Message-ID: On Mon, Feb 4, 2019 at 11:35 AM Paul Koning via cctalk < cctalk at classiccmp.org> wrote: > The spec says allowed tolerances are +/- 5%. He knew the reality for > correct operation was -0%, +5%, so he tweaked all the supplies to read a > hair above nominal. > Ah, the good old days... I recall our PDP-11 tech tweaking +5V from 5.05V to 4.95V and back again to demonstrate that tiny differences matter a lot on one of the cranky 11/23+''s we had after I made a particularly unhelpful teenage smart ass remark... The 11/23+ wouldn't boot at the slightly lower than full voltage. It as cranky for a couple of years. Before that unit was retired, the 5V and 12V rails had been tweek up to 5.2V and 12.5V in an effort to keep the system alive long enough to transition customers from it to a new Vax installed to deal with the growth in demand... In the end, we put that 11/23+ back in service for developers with a different disk controller and it was happy back at +5.05V / +12.1V... Warner From jnc at mercury.lcs.mit.edu Mon Feb 4 13:24:19 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Feb 2019 14:24:19 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190204192419.D4A1018C082@mercury.lcs.mit.edu> > From: Jay Jaeger > This sort of situation, where DEC diagnostics run OK but UNIX has issues > was reported to be not all that uncommon - to the point where the urban > legend was that some DEC FE's would fire up Unix V6 as a sort of system > exerciser. Amusing! Never heard that; our -11's were never under maintenance, so DEC FE's never worked on them. > Make a copy of ls, and see if the copy also fails It acts just like the original; fails when run by itself, runs OK when 'sleep' is also running (in the background). > From: Bob Smith > We finally had the cpu backplane replaced Ow. Not an option for Fritz, I expect. (I dunno - anyone have a spare /45 backplane?) > From: Paul Koning > Is there any way to attach a logic analyzer to various data paths on > this machine? I had suggested to Fritz that the symptoms led me to believe that it was time to deploy a LA, especially since the MM trap only occurs once between him typing 'ls' and the process failing - i.e. easy to trigger on. He offered me the options of look at the IR or at the UNIBUS - I opted for the IR so we can see _exactly_ what the machine _thinks_ it is doing! No report back yet, though. Noel From anders at abc80.net Mon Feb 4 12:51:05 2019 From: anders at abc80.net (Anders Sandahl) Date: Mon, 4 Feb 2019 19:51:05 +0100 Subject: Looking for Limited Function Board In-Reply-To: References: Message-ID: > Date: Sun, 3 Feb 2019 22:22:42 +0100 > From: Pontus Pihlgren > To: "General Discussion: On-Topic and Off-Topic Posts" > > Subject: Looking for Limited Function Board > Message-ID: <20190203212242.GF24947 at Update.UU.SE> > Content-Type: text/plain; charset=us-ascii > > Hi > > I'm restoring a PDP-8/a with the help of some > friends. The CPU is now passing the MAINDECs I've > thrown at it. The memory is a modern semiconductor > board my friend Anders Sandahl made. > > This machine is pieced together from several others > and the limited function panel I got does not match > the backplane I have. > > My theory is the DEC simplified the design of the > boardto cut costs and simpler design is not > compatible. Mine is labeled (on the PCB): > > "LIMITED FUNCTION BD. > 5411507 > 5011506C-P2" > > And the one I need is: > > "LIMITED FUNCTION > 5411165 > 5011167" > > However, the picture I have of the other is not so > good. I may have read the numbera wrong. > > I would very much like to buy one to finish this > project. > > /P F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r det ju att ?terst?lla... /A From jnc at mercury.lcs.mit.edu Mon Feb 4 14:43:09 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Feb 2019 15:43:09 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> > From: Wayne S > it might be a wonky filesystem. ... > The corruption probably came because the entire disk was going bad. This theory is contradicted by the fact (mentioned several times, including in the message you were replying to) that doing a plain 'ls' bombs, but 'sleep 300 &; ls' works fine. Noel From cclist at sydex.com Mon Feb 4 15:05:36 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 4 Feb 2019 13:05:36 -0800 Subject: Raspberry Pi floppy interface. In-Reply-To: References: Message-ID: On 1/18/19 7:40 AM, geneb via cctalk wrote: > This looks like a project with a ton of potential for archviving media > without having to deal with the asshattery of the kryoflux people. > > https://github.com/picosonic/bbc-fdc Yes, you can do this, as I've said many times before, with just about any semi-modern MCU that has sufficient memory. I've got a couple of prototypes from years back, that, for example, use AVR (Mega162 and Mega256) to do this. The 162 version had write buffers also, so it could emulate a floppy quite nicely. An Orange Pi Zero with appropriate buffers could also do this and would essentially be a $10 sledgehammer. ----------------- Based on my conversations with clients, the problem is not the equipment, but rather the lack of an open, vetted and documented file format. As an example, customers of mine insist on a "forensic" image file of type E01 (Encase format), which has been endorsed by the Library of Congress and several law enforcement agencies as a valid "forensic" format. As insane as it sounds, I've had to provide floppy images as E01 files. The insanity stems from the loss of information that would enable one to recreate the original (e.g. sector headers, modulation, data rate, track spacing, etc.). But one does what one does to keep customers happy. --Chuck From paulkoning at comcast.net Mon Feb 4 15:15:18 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 4 Feb 2019 16:15:18 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> References: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> Message-ID: > On Feb 4, 2019, at 3:43 PM, Noel Chiappa via cctalk wrote: > >> From: Wayne S > >> it might be a wonky filesystem. ... >> The corruption probably came because the entire disk was going bad. > > This theory is contradicted by the fact (mentioned several times, including in > the message you were replying to) that doing a plain 'ls' bombs, but 'sleep > 300 &; ls' works fine. That translates into "the problem depends on the physical address of the code being executed". The obvious answer is bad memory. Another possibility occurs to me: bad bits in the MMU (UISAR0 register if I remember correctly). Bad memory is likely to show up with a few bits wrong; if UISAR0 has a stuck bit so the "plain" case maps incorrectly you'd expect to come up with execution that looks nothing at all like what was intended. paul From paulkoning at comcast.net Mon Feb 4 15:17:21 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 4 Feb 2019 16:17:21 -0500 Subject: Raspberry Pi floppy interface. In-Reply-To: References: Message-ID: > On Feb 4, 2019, at 4:05 PM, Chuck Guzis via cctalk wrote: > > ... > Based on my conversations with clients, the problem is not the > equipment, but rather the lack of an open, vetted and documented file > format. > > As an example, customers of mine insist on a "forensic" image file of > type E01 (Encase format), which has been endorsed by the Library of > Congress and several law enforcement agencies as a valid "forensic" format. > > As insane as it sounds, I've had to provide floppy images as E01 files. > The insanity stems from the loss of information that would enable one to > recreate the original (e.g. sector headers, modulation, data rate, track > spacing, etc.). > > But one does what one does to keep customers happy. > > --Chuck Yes, but if the current format is wrong for the job, and people who should know better do not realize this, it would be a good idea (as a separate activity) to educate them and propose a better answer. paul From cclist at sydex.com Mon Feb 4 15:53:08 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 4 Feb 2019 13:53:08 -0800 Subject: Raspberry Pi floppy interface. In-Reply-To: References: Message-ID: <76f70a21-c5ae-4940-6c29-02c4d14d88f0@sydex.com> On 2/4/19 1:17 PM, Paul Koning wrote: > Yes, but if the current format is wrong for the job, and people who should know better do not realize this, it would be a good idea (as a separate activity) to educate them and propose a better answer. Yes, I know, and I've tried and written volumes about the subject when E01 for floppies requested. To no avail. I'll make E01 files and then toss in the IMD file as a freebie The simple fact is that archivists in general seem to have a "don't rock the boat" mentality. --Chuck From cube1 at charter.net Mon Feb 4 16:20:19 2019 From: cube1 at charter.net (Jay Jaeger) Date: Mon, 4 Feb 2019 16:20:19 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> Message-ID: <5a6026d1-a6f1-4e26-b010-e8d5ef0bdc71@charter.net> On 2/4/2019 11:34 AM, Fritz Mueller via cctech wrote: > >> On Feb 4, 2019, at 9:13 AM, Jay Jaeger wrote: >> >> If he hasn't already, if Fritz has more than one memory board, he might >> try swapping them to see if that changes anything. > > I only have an 128kw MS11-L here to work with, unfortunately. Its been through a bunch of recent troubleshooting (tracking down and replacing failed DRAMs). I *think* its pretty solid at this point (also passing some of the hairier DEC diagnostics) but... > > I'd be happy to try out a different memory board if anybody was interested in sending out a loaner? (I'm in the SF Bay area). > Well it turns out I have a couple of spares, but maybe someone closer would be easier (Madison, WI 53711) I have an MS11-LB, 64Kw, M7891-BB and two MS11-LD, 128Kw, M7891-DB and an M7891-D? So, two of these are newer revisions (rather than M7891-xA) - I have no idea what the difference is. On that last one I probably didn't record where it was D, DB or DA I also have quite a few RK05 packs and would be willing to sell one (and I have boxes to ship boards and packs in). The ones I am most willing to part with would need their open/close springs removed, as they are broken and dangerous to the platter in their current condition, but are otherwise fine. I would just remove the spring. $20 for a pack is what I usually price them at, plus shipping. (PayPal, preferably) The board would be a loan (with compensation for time spent if it is bad *and* gets fixed) ;). Let me know - might take me a couple of days to hunt the board down and remove the spring and re-test the pack and pack everything up and ship it. (in my 11/34 which runs @rkunix V6 just fine. ;)) JRJ From cube1 at charter.net Mon Feb 4 16:20:19 2019 From: cube1 at charter.net (Jay Jaeger) Date: Mon, 4 Feb 2019 16:20:19 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> Message-ID: <5a6026d1-a6f1-4e26-b010-e8d5ef0bdc71@charter.net> On 2/4/2019 11:34 AM, Fritz Mueller via cctech wrote: > >> On Feb 4, 2019, at 9:13 AM, Jay Jaeger wrote: >> >> If he hasn't already, if Fritz has more than one memory board, he might >> try swapping them to see if that changes anything. > > I only have an 128kw MS11-L here to work with, unfortunately. Its been through a bunch of recent troubleshooting (tracking down and replacing failed DRAMs). I *think* its pretty solid at this point (also passing some of the hairier DEC diagnostics) but... > > I'd be happy to try out a different memory board if anybody was interested in sending out a loaner? (I'm in the SF Bay area). > Well it turns out I have a couple of spares, but maybe someone closer would be easier (Madison, WI 53711) I have an MS11-LB, 64Kw, M7891-BB and two MS11-LD, 128Kw, M7891-DB and an M7891-D? So, two of these are newer revisions (rather than M7891-xA) - I have no idea what the difference is. On that last one I probably didn't record where it was D, DB or DA I also have quite a few RK05 packs and would be willing to sell one (and I have boxes to ship boards and packs in). The ones I am most willing to part with would need their open/close springs removed, as they are broken and dangerous to the platter in their current condition, but are otherwise fine. I would just remove the spring. $20 for a pack is what I usually price them at, plus shipping. (PayPal, preferably) The board would be a loan (with compensation for time spent if it is bad *and* gets fixed) ;). Let me know - might take me a couple of days to hunt the board down and remove the spring and re-test the pack and pack everything up and ship it. (in my 11/34 which runs @rkunix V6 just fine. ;)) JRJ From ethan.dicks at gmail.com Mon Feb 4 16:47:02 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 4 Feb 2019 16:47:02 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> Message-ID: On Mon, Feb 4, 2019 at 3:15 PM Paul Koning via cctalk wrote: > > On Feb 4, 2019, at 3:43 PM, Noel Chiappa via cctalk wrote: > That translates into "the problem depends on the physical address of the code being executed". > > The obvious answer is bad memory. At the board level, yes. Deeper, it could be bad memory bits or bad memory decode. A simple ones-and-zeros test can identify bad DRAMs. It's not as likely to find bad decoding, which could result in the same chips tested more than once and other chips not tested at all. I've found both problems in real MS11-L boards I have for my stack of 11/04 and 11/34s I'm testing. ISTR in the DEC world, they were good about that. I have multiple papertapes for the PDP-8, that I think were literally called "ones and zeros" and "memory address" tests. I would think XXDP has something similar in terms of progressive tests that expect the previous stage passed. -ethan From cisin at xenosoft.com Mon Feb 4 16:49:47 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 4 Feb 2019 14:49:47 -0800 (PST) Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: References: Message-ID: On Mon, 4 Feb 2019, Chuck Guzis via cctalk wrote: > Based on my conversations with clients, the problem is not the > equipment, but rather the lack of an open, vetted and documented file > format. > > As an example, customers of mine insist on a "forensic" image file of > type E01 (Encase format), which has been endorsed by the Library of > Congress and several law enforcement agencies as a valid "forensic" format. > > As insane as it sounds, I've had to provide floppy images as E01 files. > The insanity stems from the loss of information that would enable one to > recreate the original (e.g. sector headers, modulation, data rate, track > spacing, etc.). > > But one does what one does to keep customers happy. Well, conversion between E01 and IMD or teledisk formats looks straightforward. http://www.forensicsware.com/blog/e01-file-format.html Is there a better description handy? eg: What is the structure of the "Header Case Information" block? The E01 would be adequate (barely), if accompanied by an additional "metadata" file that describes the physical format. (In much more detail than just "IBM PC 360K", etc.) For MOST situations, OS, encoding, bytes per sector, sectors per track, interleave, side pattern, size of index and inter-sector gaps, etc. might do. That would still be far from PERFECT, because it would fail to catch several obvious ways to hide additional data on a disk; eg. different physical interleaves that would still read the same on "normal" reading, or RSA encrypted data with the key stored in intersector gaps. Or, a small amount of data stored as locations of deliberate disk errors. Think about ProLock. And, of course, a lossy compression, such as MP4 leaves room for an enormous amount of steganographic data, with documants and data hidden in porn. (MANY different MP4 files will still play the same movie) -- Grumpy Ol' Fred cisin at xenosoft.com From paulkoning at comcast.net Mon Feb 4 17:18:53 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 4 Feb 2019 18:18:53 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> Message-ID: > On Feb 4, 2019, at 5:47 PM, Ethan Dicks wrote: > > On Mon, Feb 4, 2019 at 3:15 PM Paul Koning via cctalk > wrote: >>> On Feb 4, 2019, at 3:43 PM, Noel Chiappa via cctalk wrote: >> That translates into "the problem depends on the physical address of the code being executed". >> >> The obvious answer is bad memory. > > At the board level, yes. Deeper, it could be bad memory bits or bad > memory decode. > > A simple ones-and-zeros test can identify bad DRAMs. It's not as > likely to find bad decoding, which could result in the same chips > tested more than once and other chips not tested at all. I've found > both problems in real MS11-L boards I have for my stack of 11/04 and > 11/34s I'm testing. > > ISTR in the DEC world, they were good about that. I have multiple > papertapes for the PDP-8, that I think were literally called "ones and > zeros" and "memory address" tests. I would think XXDP has something > similar in terms of progressive tests that expect the previous stage > passed. Yes, one of the standard early PDP-11 memory tests is the "no duplicate address test". paul From jfoust at threedee.com Mon Feb 4 17:22:34 2019 From: jfoust at threedee.com (John Foust) Date: Mon, 04 Feb 2019 17:22:34 -0600 Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: References: Message-ID: <20190204232249.1710B4E64B@mx2.ezwind.net> At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote: >And, of course, a lossy compression, such as MP4 leaves room for an enormous amount of steganographic data, with documants and data hidden in porn. (MANY different MP4 files will still play the same movie) That would be a very sneaky criminal if they were still using floppies. - John From fritzm at fritzm.org Mon Feb 4 17:23:38 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 4 Feb 2019 15:23:38 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> Message-ID: > On Feb 4, 2019, at 2:28 AM, Noel Chiappa via cctalk wrote: > > I'm pretty sure the command only gets a few instructions in before it blows > up. Here are the process' registers, and the _entire_ contents of the user > mode stack: > > R0 177770 > R1 0 > R2 0 > R3 0 > R4 34 > R5 444 > SP 177760 > PC 010210 > > 060: 000000 000020 000001 177770 177774 177777 071554 000000 Okay, I've had a bit of time in front of the machine to repro this and take a look. What I actually see is: R0 177770 R1 0 R2 0 R3 0 R4 0 R5 34 R6 141774 PC 000254 (remember, for the last, this will have been after taking a trap to 250, where I have the usual "BR .+2; HALT" catcher installed) Also, memory at 060 (PA:164060) is all zeros as far as the eye can see... I have a bit of water on the basement floor right now after the recent rains here, which is complicating setup of the LA. There's a big puddle where I normally place it... From fritzm at fritzm.org Mon Feb 4 17:27:48 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 4 Feb 2019 15:27:48 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> Message-ID: <1DBA06C1-F9DA-4458-8552-D656D21BCC99@fritzm.org> >>> The obvious answer is bad memory. >> >> At the board level, yes. Deeper, it could be bad memory bits or bad >> memory decode. > > Yes, one of the standard early PDP-11 memory tests is the "no duplicate address test". I should say that the memory board is not _completely_ whack -- it is passing the rather thorough MAINDEC ZQMC, a 0-124k exerciser with multiple pattern/sequence tests which also kicks around the KT11. That doesn't rule out the possibility that there is a lurker in there not covered by the DEC diags. But if there is, its something subtle... From cclist at sydex.com Mon Feb 4 17:32:24 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 4 Feb 2019 15:32:24 -0800 Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: References: Message-ID: <91d19e13-5ced-5dd8-0d9a-00687e107d4b@sydex.com> On 2/4/19 2:49 PM, Fred Cisin via cctalk wrote: > Well, conversion between E01 and IMD or teledisk formats looks > straightforward. > > http://www.forensicsware.com/blog/e01-file-format.html > Is there a better description handy? > > eg: What is the structure of the "Header Case Information" block? > > The E01 would be adequate (barely), if accompanied by an additional > "metadata" file that describes the physical format.? (In much more > detail than just "IBM PC 360K", etc.)? For MOST situations, OS, > encoding, bytes per sector, sectors per track, interleave, side pattern, > size of index and inter-sector gaps, etc. might do.? That would still be > far from PERFECT, because it would fail to catch several obvious ways to > hide additional data on a disk;? eg. different physical interleaves that > would still read the same on "normal" reading, or RSA encrypted data > with the key stored in intersector gaps. Or, a small amount of data > stored as locations of deliberate disk errors.? Think about ProLock. Somewhere on the LOC website, there is a bit more detail--and source for Linux tools under "ewf-tools" is also available. The header information for E01 files is fairly rigid in structure. But a text description of, say, a Victor 9000 floppy is kind of hard to put into 50 words or less. There seems to be a notion that "an image used for forensic purposes" is job-guarantee. In fact, when the term "forensic" is used, it has to do with crime detection and use as evidence in a legal proceeding. That is, the point of forensic examination is to prove or disprove something--completeness isn't necessary in all cases. For example, if examining DNA evidence is used to tie or eliminate a suspect, it isn't necessary that the whole genome be sequenced; presence or absence of a certain number of "markers' will do the job. (I spent some years (1987-2000) providing products and training for law enforcement forensics and am a life member of IACIS.) So, when an archivist talks about forensic data image, I scratch my head in bewilderment. I try to put things in terms that they might understand; to wit, "If you had temporary custody of an extremely rare book, would you be content with just the text of the book, or would you want photographic images of every page?" But I'm sure that Fred is well acquainted with the "This is what they told us was the Right Thing to Do, so that's what we want." phenomenon. --Chuck From cclist at sydex.com Mon Feb 4 17:36:44 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 4 Feb 2019 15:36:44 -0800 Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: <20190204232249.1710B4E64B@mx2.ezwind.net> References: <20190204232249.1710B4E64B@mx2.ezwind.net> Message-ID: <1ec83b33-ba14-67a4-313c-12c5aed48790@sydex.com> On 2/4/19 3:22 PM, John Foust via cctalk wrote: > At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote: >> And, of course, a lossy compression, such as MP4 leaves room for an enormous amount of steganographic data, with documants and data hidden in porn. (MANY different MP4 files will still play the same movie) > > That would be a very sneaky criminal if they were still using floppies. As opposed to, say DECtape? From jim.manley at gmail.com Mon Feb 4 17:40:03 2019 From: jim.manley at gmail.com (Jim Manley) Date: Mon, 4 Feb 2019 16:40:03 -0700 Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: <1ec83b33-ba14-67a4-313c-12c5aed48790@sydex.com> References: <20190204232249.1710B4E64B@mx2.ezwind.net> <1ec83b33-ba14-67a4-313c-12c5aed48790@sydex.com> Message-ID: Did someone say "punched cards ... with steganographic bits in chads that are only attached along a couple of edges"? On Mon, Feb 4, 2019 at 4:36 PM Chuck Guzis via cctalk wrote: > On 2/4/19 3:22 PM, John Foust via cctalk wrote: > > At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote: > >> And, of course, a lossy compression, such as MP4 leaves room for an > enormous amount of steganographic data, with documants and data hidden in > porn. (MANY different MP4 files will still play the same movie) > > > > That would be a very sneaky criminal if they were still using floppies. > > As opposed to, say DECtape? > > From cclist at sydex.com Mon Feb 4 18:11:10 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 4 Feb 2019 16:11:10 -0800 Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: References: <20190204232249.1710B4E64B@mx2.ezwind.net> <1ec83b33-ba14-67a4-313c-12c5aed48790@sydex.com> Message-ID: On 2/4/19 3:40 PM, Jim Manley via cctalk wrote: > Did someone say "punched cards ... with steganographic bits in chads that > are only attached along a couple of edges"? NCR CRAM? From jnc at mercury.lcs.mit.edu Mon Feb 4 18:25:37 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Feb 2019 19:25:37 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190205002537.830C418C080@mercury.lcs.mit.edu> > From: Fritz Mueller > I've had a bit of time in front of the machine to repro this and take a > look. What I actually see is: > R0 177770 > R1 0 > R2 0 > R3 0 > R4 0 > R5 34 > R6 141774 > PC 000254 Argh. (Very red face!) I worked out the trap stack layout by looking at m40.s and trap.c, and totally forgot about the return PC (that's the 0444) from the call to trap(): 0001740 000013 141756 022050 000013 000000 000000 000000 000034 0001760 000444 000031 177760 000000 030351 177770 010210 170010 I clearly should have looked at core(V) in the V6 manual! The R6 you have recorded is correct for just after the trap; that's the kernel mode SP, which points to the top of the kernel stack, in segment 6 (in the swappable per-process kernel area, which runs from 140000-1776). So there is no R5 mystery, I was just confused. Back to the other two! Noel From cisin at xenosoft.com Mon Feb 4 18:53:46 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 4 Feb 2019 16:53:46 -0800 (PST) Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: <20190204232249.1710B4E64B@mx2.ezwind.net> References: <20190204232249.1710B4E64B@mx2.ezwind.net> Message-ID: >> And, of course, a lossy compression, such as MP4 leaves room for an >> enormous amount of steganographic data, with documants and data hidden >> in porn. (MANY different MP4 files will still play the same movie) On Mon, 4 Feb 2019, John Foust via cctalk wrote: > That would be a very sneaky criminal if they were still using floppies. "Hey, Captain! Does anybody know what this 8 inch square thing is, and whether it goes with a computer?" That paragraph was not specifically about floppies, but about the entire concept of hidden data. From cisin at xenosoft.com Mon Feb 4 19:13:54 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 4 Feb 2019 17:13:54 -0800 (PST) Subject: E01 (Was: Raspberry Pi floppy interface. In-Reply-To: <91d19e13-5ced-5dd8-0d9a-00687e107d4b@sydex.com> References: <91d19e13-5ced-5dd8-0d9a-00687e107d4b@sydex.com> Message-ID: >> eg: What is the structure of the "Header Case Information" block? >> The E01 would be adequate (barely), if accompanied by an additional >> "metadata" file that describes the physical format.? (In much more >> detail than just "IBM PC 360K", etc.)? For MOST situations, OS, >> encoding, bytes per sector, sectors per track, interleave, side pattern, >> size of index and inter-sector gaps, etc. might do.? That would still be >> far from PERFECT, because it would fail to catch . . . On Mon, 4 Feb 2019, Chuck Guzis via cctalk wrote: > Somewhere on the LOC website, there is a bit more detail--and source for > Linux tools under "ewf-tools" is also available. > > The header information for E01 files is fairly rigid in structure. But > a text description of, say, a Victor 9000 floppy is kind of hard to put > into 50 words or less. not even 64 bit ones. With a lot more space, you could write a reasonably usable description. But it would have to be an extensible variable length field to permit identifying various exceptions and oddities. Therefore, the media physical format description would have to be a separate file from the E01 "data from the disk". > So, when an archivist talks about forensic data image, I scratch my head > in bewilderment. I try to put things in terms that they might > understand; to wit, "If you had temporary custody of an extremely rare > book, would you be content with just the text of the book, or would you > want photographic images of every page?" An excellent analogy. I guess that they would not be interested in a separate file of a photographic image of every page to accompany the file of the text of the book. > But I'm sure that Fred is well acquainted with the "This is what they > told us was the Right Thing to Do, so that's what we want." phenomenon. BTDT. In addition to Xenosoft (concurrently!), I was a community college professor, dealing with college administrators for 35 years. Sometimes you can not get past the Misplaced Authority Syndrome to explain reality. -- Grumpy Ol' Fred cisin at xenosoft.com From elson at pico-systems.com Mon Feb 4 20:59:52 2019 From: elson at pico-systems.com (Jon Elson) Date: Mon, 04 Feb 2019 20:59:52 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <8242DE16-75E4-4224-BFFE-15A6E420BDAB@fritzm.org> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C58673D.3010506@pico-systems.com> <8242DE16-75E4-4224-BFFE-15A6E420BDAB@fritzm.org> Message-ID: <5C58FC28.5080000@pico-systems.com> On 02/04/2019 11:20 AM, Fritz Mueller via cctalk wrote: > > The MMU classifies the error in register SR0; this decodes to a segment length error (access within the segment beyond configured bound). As Noel notes, however, this is not consistent with the instructions we see at the point of fault. OK, so the CPU presents an address that is within the segment bound, but the MMU declares it to be OUTSIDE the bounds of the segment. That could be a CPU problem, but likely would be the same with the MMU on or off, so the diags SHOULD catch that. But, if the CPU is sending a good address, then it has to be the MMU is failing on the addition/comparison with the segment size. >> Anyway, is it possible to borrow an MMU from somebody else? > Potentially... It is a two board option; I do have a spare for both of the boards, but these spares each are in need of other repairs at the moment. > > One slightly complicating factor is that I have a *very* early 11/45. Most of my boards (including the MMU boards), as well as my backplane, pre-date the currently available schematics on bitsavers, etc., and there are no records regarding which ECOs have been applied on my hardware. Thus my interest in tracking down ECOs/FCOs... I've been picking my way through the list that Jay recently posted, verifying by looking at the greenwires which FCO's I have applied and which not. Its a bit painstaking. > > This could be messy, but DEC was FAIRLY good at making updates backwards compatible where possible. So, it MAY be true that a later MMU will still work in this CPU. Jon From elson at pico-systems.com Mon Feb 4 21:09:16 2019 From: elson at pico-systems.com (Jon Elson) Date: Mon, 04 Feb 2019 21:09:16 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> Message-ID: <5C58FE5C.2020802@pico-systems.com> On 02/04/2019 11:34 AM, Fritz Mueller via cctalk wrote: > >> 2. Make a copy of ls, and see if the copy also fails >> (different location on disk would mess with timing just a bit). > Also done; the copy appears to behave identically to the original. > > OK, here's a really complicated thing to try. If you know the physical memory address of ls when it has the problem, write a machine language program that loads a copy of ls into that location and then tries to read it back. You might be able to do this in Unix, having it start with the exact code of ls, but then has the tester above that and the entry point is for the test program. This would detect a pattern sensitivity in the memory. If ls, when actually running reads an instruction wrong, it could then try to read a bad address, and cause the MMU trap. Jon From wayne.sudol at hotmail.com Mon Feb 4 14:17:03 2019 From: wayne.sudol at hotmail.com (Wayne S) Date: Mon, 4 Feb 2019 20:17:03 +0000 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190204192419.D4A1018C082@mercury.lcs.mit.edu> References: <20190204192419.D4A1018C082@mercury.lcs.mit.edu> Message-ID: Noel, it might be a wonky filesystem. I?ve had ls -l seg fault because of bad attribute data on a file in a directory on Solaris. Interestingly, ls (without the -l) worked okay. Maybe fsck or the equivalent command may show something. It was a Solaris system with many concurrent users so I couldn?t take it down to run fsck so I ended up writing a quick Perl program to just list file names and then modified it to get the attributes. It seg faulted when it came to the bad file name. I used Perl unlink to kill it and everything was okay. The corruption probably came because the entire disk was going bad. Just a thought. Sent from Mail for Windows 10 ________________________________ From: cctalk on behalf of Noel Chiappa via cctalk Sent: Monday, February 4, 2019 11:24:19 AM To: cctalk at classiccmp.org Cc: jnc at mercury.lcs.mit.edu Subject: Re: PDP-11/45 RSTS/E boot problem > From: Jay Jaeger > This sort of situation, where DEC diagnostics run OK but UNIX has issues > was reported to be not all that uncommon - to the point where the urban > legend was that some DEC FE's would fire up Unix V6 as a sort of system > exerciser. Amusing! Never heard that; our -11's were never under maintenance, so DEC FE's never worked on them. > Make a copy of ls, and see if the copy also fails It acts just like the original; fails when run by itself, runs OK when 'sleep' is also running (in the background). > From: Bob Smith > We finally had the cpu backplane replaced Ow. Not an option for Fritz, I expect. (I dunno - anyone have a spare /45 backplane?) > From: Paul Koning > Is there any way to attach a logic analyzer to various data paths on > this machine? I had suggested to Fritz that the symptoms led me to believe that it was time to deploy a LA, especially since the MM trap only occurs once between him typing 'ls' and the process failing - i.e. easy to trigger on. He offered me the options of look at the IR or at the UNIBUS - I opted for the IR so we can see _exactly_ what the machine _thinks_ it is doing! No report back yet, though. Noel From wayne.sudol at hotmail.com Mon Feb 4 15:03:46 2019 From: wayne.sudol at hotmail.com (Wayne S) Date: Mon, 4 Feb 2019 21:03:46 +0000 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> References: <20190204204309.DFFE418C082@mercury.lcs.mit.edu> Message-ID: Yep, I noticed that, but thought it was a idea you might want to explore and it?s simple enough to do. Without the full output from the ls command and how it was executed I was just throwing it out there. For instance, was the default dir where ls was run, the same dir as when the backgrounded one was run. That would make a difference if the filesystem was corrupt. In previous threads, there was an issue getting the proper image onto the disk, there is the potential for corruption. There is the assumption, since boards were being worked on, that the problem for a software is probably due to said hardware, even though diags pass. With that assumption, shouldn?t you try to eliminate different hardware pieces? I would try running something that uses memory and doesn?t use disk to narrow the problem down. Anyway, Take care and good luck, Wayne Sent from Mail for Windows 10 ________________________________ From: Noel Chiappa Sent: Monday, February 4, 2019 12:43:09 PM To: cctalk at classiccmp.org Cc: jnc at mercury.lcs.mit.edu Subject: RE: PDP-11/45 RSTS/E boot problem > From: Wayne S > it might be a wonky filesystem. ... > The corruption probably came because the entire disk was going bad. This theory is contradicted by the fact (mentioned several times, including in the message you were replying to) that doing a plain 'ls' bombs, but 'sleep 300 &; ls' works fine. Noel From harper at secureoutcomes-hq.com Mon Feb 4 17:40:38 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Mon, 04 Feb 2019 16:40:38 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive Message-ID: <20190204234042.6D1EB2736F@mx1.ezwind.net> Greetings to the List - I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to a 19" rack. The screw holes that mate to the standard spaced holes on the right side of the drive after you open the case are visible and obvious. However, the holes on the left are hidden under the heavy die-cast(?) frame of the drive. Anyone know how to get to those three screw holes with a horrible disassembly. There has to be a trick to this that I don't see (so what else is new? :) Best, Jack ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From useddec at gmail.com Mon Feb 4 21:41:29 2019 From: useddec at gmail.com (Paul Anderson) Date: Mon, 4 Feb 2019 21:41:29 -0600 Subject: Looking for Limited Function Board In-Reply-To: References: Message-ID: I have a few of the limited function and programmers panels. I do not recall either of them being dependent on particular backplane. I'll try to pull a few a few later and check the part number on them. Remember, a 54-XXXXX number can become a 70-XXXXX with the addition of a cable or something simple. Paul On Mon, Feb 4, 2019 at 12:51 PM Anders Sandahl via cctech < cctech at classiccmp.org> wrote: > > Date: Sun, 3 Feb 2019 22:22:42 +0100 > > From: Pontus Pihlgren > > To: "General Discussion: On-Topic and Off-Topic Posts" > > > > Subject: Looking for Limited Function Board > > Message-ID: <20190203212242.GF24947 at Update.UU.SE> > > Content-Type: text/plain; charset=us-ascii > > > > Hi > > > > I'm restoring a PDP-8/a with the help of some > > friends. The CPU is now passing the MAINDECs I've > > thrown at it. The memory is a modern semiconductor > > board my friend Anders Sandahl made. > > > > This machine is pieced together from several others > > and the limited function panel I got does not match > > the backplane I have. > > > > My theory is the DEC simplified the design of the > > boardto cut costs and simpler design is not > > compatible. Mine is labeled (on the PCB): > > > > "LIMITED FUNCTION BD. > > 5411507 > > 5011506C-P2" > > > > And the one I need is: > > > > "LIMITED FUNCTION > > 5411165 > > 5011167" > > > > However, the picture I have of the other is not so > > good. I may have read the numbera wrong. > > > > I would very much like to buy one to finish this > > project. > > > > /P > > F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att > flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett > originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r > det ju att ?terst?lla... > > /A > > From cclist at sydex.com Tue Feb 5 00:25:31 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 4 Feb 2019 22:25:31 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190204234042.6D1EB2736F@mx1.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> Message-ID: <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> On 2/4/19 3:40 PM, Jack Harper via cctalk wrote: > > > Greetings to the List - > > I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to > a 19" rack. > > The screw holes that mate to the standard spaced holes on the right side > of the drive after you open the case are visible and obvious. > > However, the holes on the left are hidden under the heavy die-cast(?) > frame of the drive. > > Anyone know how to get to those three screw holes with a horrible > disassembly. > > There has to be a trick to this that I don't see (so what else is new? :) > There's a mounting kit for this as described here; http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/tape/7970/07970-90383_7970B_7970C_Operating_and_Service_Manual_upd_Feb76/07970-90383_7970B_7970C_Operating_and_Service_Manual_Section_1.pdf Page 2-1, section 2-8, installation. Whatever you do, be sure that your rack has an "anti-tip" foot (most full-size 19" HP racks do. When you open the drive, the entire assembly but for the card cages and the power supply swing out. It's more than enough to tip a rack over. --Chuck From bhilpert at shaw.ca Tue Feb 5 00:28:19 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Mon, 4 Feb 2019 22:28:19 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190204234042.6D1EB2736F@mx1.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> Message-ID: <581A9C47-B67E-46CE-8182-5673EA99057C@shaw.ca> On 2019-Feb-04, at 3:40 PM, Jack Harper via cctalk wrote: > > I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to a 19" rack. > > The screw holes that mate to the standard spaced holes on the right side of the drive after you open the case are visible and obvious. > > However, the holes on the left are hidden under the heavy die-cast(?) frame of the drive. > > Anyone know how to get to those three screw holes with a horrible disassembly. > > There has to be a trick to this that I don't see (so what else is new? :) If, or presuming, it's the same as the 7970A: The left-side mount is actually a vertical right-angle bracket screwed to the drive proper. 1. Open the drive and unscrew that bracket from the inside. 2. Mount the bracket to the left side of the rack. 3. Lift the drive into place. The mounted bracket has a short right angle bend at the bottom (and top) that provides a lip on which to rest some of the weight of the drive and guide it in. 4. Screw the right side of the drive to the rack. 5. Replace the screws removed in step 1, reattaching the drive to the bracket. The right side of the drive (should) have little pieces of 1/8" thick aluminum glued at the back of the rack-mount holes to match the thickness of the left-side bracket, to make the drive seat parallel to the face of the rack. In my (limited) experience those can have a tendency to fall off and may be lost when the drive is unmounted due to dried glue. From gerardcjat at free.fr Tue Feb 5 00:46:41 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Tue, 5 Feb 2019 07:46:41 +0100 Subject: HP 1000 L series, parts available, anyone ?? Message-ID: <788CE44BA2894DF3830297191ACF6CE1@medion> I own a HP 1000 L series 200 Cards are badly corroded at connectors level BUT some other parts are in very good shape. I can offer, HP "special SoS" processors : 1AA6-60004, 1AC5, 1AB5, 1AF5 ( - 60001 ) The set of (3) Eprom .... I cannot image them, but I am willing to send them to someone that will do it. Al. may be ? The power supply seems in pristine state. Just have to check more closely if needed. Other parts ? .... just ask. "fee" : Eprom, free Processors : shipping cost Power supply : shipping cost + a little more for packing material and my time. I am in France, close to Paris. From gerardcjat at free.fr Tue Feb 5 00:46:41 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Tue, 5 Feb 2019 07:46:41 +0100 Subject: HP 1000 L series, parts available, anyone ?? Message-ID: <788CE44BA2894DF3830297191ACF6CE1@medion> I own a HP 1000 L series 200 Cards are badly corroded at connectors level BUT some other parts are in very good shape. I can offer, HP "special SoS" processors : 1AA6-60004, 1AC5, 1AB5, 1AF5 ( - 60001 ) The set of (3) Eprom .... I cannot image them, but I am willing to send them to someone that will do it. Al. may be ? The power supply seems in pristine state. Just have to check more closely if needed. Other parts ? .... just ask. "fee" : Eprom, free Processors : shipping cost Power supply : shipping cost + a little more for packing material and my time. I am in France, close to Paris. From gerardcjat at free.fr Tue Feb 5 01:05:47 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Tue, 5 Feb 2019 08:05:47 +0100 Subject: WTB : CTL, CTuL 9956 ?? Message-ID: <0EF9317862174A638561B1E01CD6215B@medion> This is a (very ) long shoot ! I am looking for ( Fairchild ? ) CTL / CTuL 9956 chips. Anyone ? Thanks. From gerardcjat at free.fr Tue Feb 5 01:05:47 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Tue, 5 Feb 2019 08:05:47 +0100 Subject: WTB : CTL, CTuL 9956 ?? Message-ID: <0EF9317862174A638561B1E01CD6215B@medion> This is a (very ) long shoot ! I am looking for ( Fairchild ? ) CTL / CTuL 9956 chips. Anyone ? Thanks. From gerardcjat at free.fr Tue Feb 5 01:09:08 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Tue, 5 Feb 2019 08:09:08 +0100 Subject: WTB : Card extender for HP 21xx ( Fit from 2116 to 21MX ) Message-ID: <437B9C79008D4C899A7A2F7045D5E5B3@medion> All is in the title. An other very long shoot, isn't it ? ;-) From gerardcjat at free.fr Tue Feb 5 01:09:08 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Tue, 5 Feb 2019 08:09:08 +0100 Subject: WTB : Card extender for HP 21xx ( Fit from 2116 to 21MX ) Message-ID: <437B9C79008D4C899A7A2F7045D5E5B3@medion> All is in the title. An other very long shoot, isn't it ? ;-) From jwest at classiccmp.org Tue Feb 5 07:24:33 2019 From: jwest at classiccmp.org (Jay West) Date: Tue, 5 Feb 2019 07:24:33 -0600 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <581A9C47-B67E-46CE-8182-5673EA99057C@shaw.ca> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <581A9C47-B67E-46CE-8182-5673EA99057C@shaw.ca> Message-ID: <004b01d4bd56$22607190$672154b0$@classiccmp.org> I'm sure there is a post in the archives about this... There is a special custom HP bracket on the left. It is a heavy piece of steel - and it MUST be, due to the weight and movement (swing out) of the unit. I'm used to finding ways for one person to do a two man job when mounting things in racks, but just don't do it with the 7970 - you will get hurt. I had to get someone to help mainly because it's not just sliding in on some kind of rails. You have to literally hold the unit in place in mid air in the rack while getting to bolts and holes to align that you can't even get to from your side of the swingout. ISTR it's around 150# or so. Even with two people, there was a lot of huffing and straining - and that is with the special bracket that is designed to sort of hold it in place (it doesn't really) while you bolt it in. I've probably had around ten 7970's go through my shop, and only one of them ever came with that bracket. It is almost always lost. So... I had a friend of mine that owns a machine shop fabricate a new mounting bracket for the 7970. I think I had him make around 8 or so, and I sent them off to other collectors for the cost of having them made or shipping or smth. These brackets are 100% identical to the originals and made from steel that is at least as strong as the original, probably more. I think I may have an extra one of those brackets that was made, will check. J From jnc at mercury.lcs.mit.edu Tue Feb 5 07:36:05 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Feb 2019 08:36:05 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> > From: Paul Koning > Another possibility occurs to me: bad bits in the MMU (UISAR0 register > ... if UISAR0 has a stuck bit so the "plain" case maps incorrectly > you'd expect to come up with execution that looks nothing at all like > what was intended. One would hope that the DEC KT11 diagnostic would check for this... but just to be thorough, we have in fact written a short diagnostic which stores every possible value in each UISA register and checks that it's correct. So unless there is some sort of pattern sensitivity (e.g. when A is in UISAm and B is in UISAn), that's not it. Also, and perhaps more significantly, when checked after the trap happens, all the UISA registers and all the KISA registers contain correct data. So, unless it's something where _sometimes_ one reads UISAn and gets X when it actually contains Y, I'm not sure the SARs (PARs) are involved. > From: Jon Elson > OK, here's a really complicated thing to try. If you know the physical > memory address of ls when it has the problem We do (see above), and we've also looked at what's in memory at that location, and the low part of the text segment seems to be correct, but there was junk at the top, around the target of the JSR (i.e. at 'csv'). Not just one word, but everything around that location was wrong, which would suggest to me that the cause is not a simple memory failure there. I've suggested to Fritz that we look at that again, to see if what was recorded before is accurate (i.e. if we see the same wrong contents), to make sure we didn't make a mistake somehow. > write a machine language program that loads a copy of ls into that > location and then tries to read it back. Yeah, it may come to that. One issue we've been having is doing specialized test programmes; trying to run the C compiler fails. I don't know about the assembler, though. And as Fritz mentioned, it takes hours to load a new disk image. I think we've come up with a way around that, though; produce binary of stand-alone tests elsewhere (I've often/always got a v6 running on Ersatz-11 here), and load them into the /45's main memory with PDP11GUI. Noel From jwest at classiccmp.org Tue Feb 5 07:43:32 2019 From: jwest at classiccmp.org (Jay West) Date: Tue, 5 Feb 2019 07:43:32 -0600 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <581A9C47-B67E-46CE-8182-5673EA99057C@shaw.ca> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <581A9C47-B67E-46CE-8182-5673EA99057C@shaw.ca> Message-ID: <005801d4bd58$c920f8e0$5b62eaa0$@classiccmp.org> Brent wrote... --------------------------- The right side of the drive (should) have little pieces of 1/8" thick aluminum glued at the back of the rack-mount holes to match the thickness of the left-side bracket, to make the drive seat parallel to the face of the rack. In my (limited) experience those can have a tendency to fall off and may be lost when the drive is unmounted due to dried glue. --------------------------- The brackets I just posted about... I didn't just have the brackets made. I had the complete mounting kit (including the little shims that brent mentions above, and including all necessary nuts and bolts, and even the HP mounting instructions that came with it) replicated. The bolts are actually kind of critical for the right fit, due to the bevel of the bolt holes in the bracket, as well as the depth of the bolts going in to the particular confines of the mounting holes built into the rack. Long story short, it is a complete mounting kit. If you search the archives for the mounting kit part number you'll probably find the previous thread on this. J From cube1 at charter.net Tue Feb 5 08:20:26 2019 From: cube1 at charter.net (Jay Jaeger) Date: Tue, 5 Feb 2019 08:20:26 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> Message-ID: > > Yeah, it may come to that. One issue we've been having is doing specialized > test programmes; trying to run the C compiler fails. I don't know about the > assembler, though. And as Fritz mentioned, it takes hours to load a new disk > image. I think we've come up with a way around that, though; produce binary > of stand-alone tests elsewhere (I've often/always got a v6 running on > Ersatz-11 here), and load them into the /45's main memory with PDP11GUI. > > Noel Perhaps compile it under SimH and do a block-level diff of the image with what is currently in use, and transfer just those blocks? (Presumably would be the superblock, bitmap, directory and actual program blocks). For my setup I use a DR11 to transfer data, using an Arduino with Ethernet as a go-between my PC and the PDP-11. From mattislind at gmail.com Tue Feb 5 09:21:10 2019 From: mattislind at gmail.com (Mattis Lind) Date: Tue, 5 Feb 2019 16:21:10 +0100 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> Message-ID: Den tis 5 feb. 2019 kl 00:23 skrev Fritz Mueller via cctalk < cctalk at classiccmp.org>: > > > On Feb 4, 2019, at 2:28 AM, Noel Chiappa via cctalk < > cctalk at classiccmp.org> wrote: > > > > I'm pretty sure the command only gets a few instructions in before it > blows > > up. Here are the process' registers, and the _entire_ contents of the > user > > mode stack: > > > > R0 177770 > > R1 0 > > R2 0 > > R3 0 > > R4 34 > > R5 444 > > SP 177760 > > PC 010210 > > > > 060: 000000 000020 000001 177770 177774 177777 071554 000000 > > Okay, I've had a bit of time in front of the machine to repro this and > take a look. What I actually see is: > > R0 177770 > R1 0 > R2 0 > R3 0 > R4 0 > R5 34 > R6 141774 > PC 000254 > > (remember, for the last, this will have been after taking a trap to 250, > where I have the usual "BR .+2; HALT" catcher installed) > > Also, memory at 060 (PA:164060) is all zeros as far as the eye can see... > Would it be any difference if you run the machine at full speed or lower speed or even single step past this instruction? With the KM11 installed you could even single step the 5 minor states in each micro instruction. Would it be possible to insert a breakpoint or halt and run the program, insert original instruction and single step? The TIG module has a separate non crystal controlled oscillator which one could tune for marginal checking. Would it be possible to isolate the test case outside the UNIX environment? /Mattis > > I have a bit of water on the basement floor right now after the recent > rains here, which is complicating setup of the LA. There's a big puddle > where I normally place it... > > > From wrcooke at wrcooke.net Tue Feb 5 08:13:38 2019 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Tue, 5 Feb 2019 09:13:38 -0500 (EST) Subject: Epson PX8 disk emulator Message-ID: <587076222.202107.1549376018437@email.ionos.com> Hello all, I have built an emulator that uses an Arduino and SD card to provide four "floppy drives" for an Epson PX8.? It may also be usable with a PX4, but I have no way of trying it. If you would like to build one yourself, or just read about it, the details are here:?http://wrcooke.net/projects/pfbdk/pfbdk.html Any feedback is appreciated (I already know the page is crummy.)? Especially if you build it I would like to know good or bad experience. Thanks, Will "He may look dumb but that's just a disguise."? -- Charlie Daniels "The names of global variables should start with? ? // "? --?https://isocpp.org From dkelvey at hotmail.com Tue Feb 5 09:41:56 2019 From: dkelvey at hotmail.com (dwight) Date: Tue, 5 Feb 2019 15:41:56 +0000 Subject: WTB : CTL, CTuL 9956 ?? In-Reply-To: <0EF9317862174A638561B1E01CD6215B@medion> References: <0EF9317862174A638561B1E01CD6215B@medion> Message-ID: I'm curious as to what the 9956 is for? One might be able to hack something together with a NPN transistor and a TTL and gate. This looks to be one of the oddball chips that Fairchild made in the early days, before most settled down to TTL being the more common. Dwight ________________________________ From: cctalk on behalf of GerardCJAT via cctalk Sent: Monday, February 4, 2019 11:05 PM To: cctech at classiccmp.org; cctalk at classiccmp.org Subject: WTB : CTL, CTuL 9956 ?? This is a (very ) long shoot ! I am looking for ( Fairchild ? ) CTL / CTuL 9956 chips. Anyone ? Thanks. From aek at bitsavers.org Tue Feb 5 10:43:40 2019 From: aek at bitsavers.org (Al Kossow) Date: Tue, 5 Feb 2019 08:43:40 -0800 Subject: WTB : Card extender for HP 21xx ( Fit from 2116 to 21MX ) In-Reply-To: <437B9C79008D4C899A7A2F7045D5E5B3@medion> References: <437B9C79008D4C899A7A2F7045D5E5B3@medion> Message-ID: <532a7ca8-3cf4-b6c0-3c09-4f035689f11b@bitsavers.org> I have several. Make a serious offer. On 2/4/19 11:09 PM, GerardCJAT via cctalk wrote: > All is in the title. > An other very long shoot, isn't it ? ;-) > From aek at bitsavers.org Tue Feb 5 10:45:03 2019 From: aek at bitsavers.org (Al Kossow) Date: Tue, 5 Feb 2019 08:45:03 -0800 Subject: WTB : CTL, CTuL 9956 ?? In-Reply-To: References: <0EF9317862174A638561B1E01CD6215B@medion> Message-ID: <615f9caa-589d-d811-0b71-8891bb3a433d@bitsavers.org> On 2/5/19 7:41 AM, dwight via cctalk wrote: > I'm curious as to what the 9956 is for? HP used uCTL as the bus interface in the 21xx From elson at pico-systems.com Tue Feb 5 10:45:46 2019 From: elson at pico-systems.com (Jon Elson) Date: Tue, 05 Feb 2019 10:45:46 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> Message-ID: <5C59BDBA.6090409@pico-systems.com> On 02/05/2019 07:36 AM, Noel Chiappa via cctalk wrote: > One would hope that the DEC KT11 diagnostic would check for this... but just > to be thorough, we have in fact written a short diagnostic which stores every > possible value in each UISA register and checks that it's correct. So unless > there is some sort of pattern sensitivity (e.g. when A is in UISAm and B is in > UISAn), that's not it. The MMU has to have some adders in it. One adds the offset for the segment's beginning physical address to the supplied address from the CPU. The other compares the requested address against the limit (size) of the segment, to make sure it doesn't exceed the segment size. Either this adder or the comparator could be faulty. I'd guess the diagnostic tries a few patterns to test for gross failure of this circuitry, but since it involves memory on a system running a program, it may not be able to exhaustively test these adders and comparators. Jon From sales at elecplus.com Tue Feb 5 10:54:45 2019 From: sales at elecplus.com (Electronics Plus) Date: Tue, 5 Feb 2019 10:54:45 -0600 Subject: test Message-ID: <000601d4bd73$7fe6d530$7fb47f90$@com> I changed email providers, and received no emails for a week. If you tried to contact me, please ask again! Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From glen.slick at gmail.com Tue Feb 5 11:13:12 2019 From: glen.slick at gmail.com (Glen Slick) Date: Tue, 5 Feb 2019 09:13:12 -0800 Subject: HP 1000 L series, parts available, anyone ?? In-Reply-To: <788CE44BA2894DF3830297191ACF6CE1@medion> References: <788CE44BA2894DF3830297191ACF6CE1@medion> Message-ID: On Mon, Feb 4, 2019 at 10:46 PM GerardCJAT via cctalk wrote: > > I own a HP 1000 L series 200 > Cards are badly corroded at connectors level BUT some other parts are in very good shape. > > I can offer, > > HP "special SoS" processors : 1AA6-60004, 1AC5, 1AB5, 1AF5 ( - 60001 ) > > The set of (3) Eprom .... > I cannot image them, but I am willing to send them to someone that will do it. Too bad this wasn't 3 months ago. I passed on picking up a 12001 L-series CPU board that appeared to be in excellent condition except it was missing the 1AB5 chip and I assumed that finding one of those to replace the missing one would not be possible for a very long time. What are the part numbers on the EPROMs you have? On a 12001 L-series CPU board there should be two 2732 EPROMs with part numbers such as 12001-8000x on the labels. What are the other EPROMs you have, are they from different boards? From fritzm at fritzm.org Tue Feb 5 12:03:14 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 5 Feb 2019 10:03:14 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> Message-ID: <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> > Perhaps compile [test programs] under SimH and do a block-level diff of the image with what is currently in use, and transfer just those blocks? I did experiment with this a little way back. I wrote a small standalone code that dumps a CRC of every sector over the console; I can run this both under SIMH and on the real machine, then diff to find the changed sectors. Unfortunately, when I tried to apply this, it seemed that SIMH's write single sector wasn't working correctly for me (though "write all sectors to end" seemed to work okay). It ended up being much more tedious than I had thought to do it this way; in the end I concluded I'd be better off writing some different software specifically for this purpose, but I haven't gotten back to it yet. FWIW, I maintain a Windows VM (on a MacOS X host) for the sole purpose of running PDP11GUI, and I use an USA19H USB serial dongle connected through to the VM as a serial interface. I don't know if something about this setup is particularly detrimental to PDP11GUI transfer performance? It takes me >3hrs to write a 2.5mb pack this way (at 9600 baud), or a little over 1hr to read one back. Do others see similar throughput with these tools? --FritzM. From fritzm at fritzm.org Tue Feb 5 12:15:24 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 5 Feb 2019 10:15:24 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <5C59BDBA.6090409@pico-systems.com> References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> <5C59BDBA.6090409@pico-systems.com> Message-ID: > On Feb 5, 2019, at 8:45 AM, Jon Elson via cctalk wrote: > > I'd guess the diagnostic tries a few patterns to test for gross failure of this circuitry, but since it involves memory on a system running a program, it may not be able to exhaustively test these adders and comparators. In fact, the DEC diagnostics relocate themselves around memory, so they can and do "paint the whole floor". The tests are fairly exhaustive, testing relocations, access range and privilege mechanisms, activity and statistics flags, and fault and interrupt behaviors. (It takes my machine about 45 minutes running full bore to work its way through a single pass!) Again, not to say that there's not a bug lurking in the KT11 (it remains in fact a prime suspect!) But with the ground gone over so far we have managed to pretty thoroughly check and ruled out a lot of things like any sort of consistent failure of the relocation adder. I really appreciate the time people are taking to offer help and suggestions -- please keep them coming! thanks, --FritzM. From fritzm at fritzm.org Tue Feb 5 12:22:37 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 5 Feb 2019 10:22:37 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> Message-ID: <4204D4B6-19DD-4874-96B3-B81DC0698E4D@fritzm.org> > Would it be any difference if you run the machine at full speed or lower speed... Ah, yes -- this I haven't tried yet! I have a KM11 replica, so this is easy enough to do; I'll give that a go when I next get back to the machine (possibly this evening). > ...or even single step past this instruction? With the KM11 installed you could even single step the 5 minor states in each micro instruction. Would it be possible to insert a breakpoint or halt and run the program, insert original instruction and single step? We're not *quite* sure yet of the exact offending instruction; memory around the purported fault location doesn't look like what we expect (particularly, its hard to see how the instruction which should have executed last could possibly result in the particular fault taken; thus Noel's request for an IR trace.) I think the breakpoint-and-step approach is likely to be fruitful, but we need to clear up some muddiness around the exact instruction sequence/location first. --FritzM. From gerardcjat at free.fr Tue Feb 5 12:24:25 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Tue, 5 Feb 2019 19:24:25 +0100 Subject: WTB : Card extender for HP 21xx ( Fit from 2116 to 21MX ) Message-ID: Hi Al. $ 60, plus shipping ? I live close to Paris, France. Zip Code : 77310 ( Payment through Paypal seems the only way ?? ) On an other subject, did you see my previous cctalk post on imaging HP 1000 L series Eprom ? Any interest ? Best regards Gerard From jnc at mercury.lcs.mit.edu Tue Feb 5 12:27:57 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Feb 2019 13:27:57 -0500 (EST) Subject: Not a test (Was: test) Message-ID: <20190205182757.1C94418C07B@mercury.lcs.mit.edu> > From: Cindy Croxton > I changed email providers, and received no emails for a week. If you > tried to contact me, please ask again! Perhaps 'test' was not an optimal Subject: line - a lot of people think that flags a message they can ignore, and not even look at - which was not what you wanted! :-) Noel From fritzm at fritzm.org Tue Feb 5 12:29:11 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 5 Feb 2019 10:29:11 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <3D536D69-AE94-41C8-BB42-73B8315426A8@fritzm.org> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <5C586661.5000906@pico-systems.com> <2BE1E8D6-E280-475F-A99C-EF5543C4E1C0@comcast.net> <3D536D69-AE94-41C8-BB42-73B8315426A8@fritzm.org> Message-ID: <168A4AB6-DAF7-4131-BC1C-CA6794FE793B@fritzm.org> >>> I keep wondering about the psu. >> >> Good theory. > > I'll give these a double-check... I did give these a look yesterday. Indeed, the +5 regulator in position "C" (which includes supply to the KT11) was running a little low (4.9 and change). I trimmed it up, and checked the rest of the regulators while I was at it (they were all fine.) This did clear up some small strangenesses I was seeing at the console in address translation mode, but "ls" still fails in exactly the same way. --FritzM. From fritzm at fritzm.org Tue Feb 5 12:52:08 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 5 Feb 2019 10:52:08 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> Message-ID: > On Feb 5, 2019, at 10:03 AM, Fritz Mueller wrote: > > Unfortunately, when I tried to apply this, it seemed that SIMH's write single sector wasn't working correctly for me... Correction to above: "PDP11GUI's write single sector". Apologies! --FritzM. From sales at elecplus.com Tue Feb 5 13:12:01 2019 From: sales at elecplus.com (Electronics Plus) Date: Tue, 5 Feb 2019 13:12:01 -0600 Subject: IBM M122 keyboards in Quebec Message-ID: <00bd01d4bd86$ac98cf30$05ca6d90$@com> Daniel Fecteau 6025 Arthur sauv? Mirabel, Quebec J7N 2W4 TEL: 450-969-1616 ext 101 Mail: save at savesysteme.com He has a variety of Model M 122 key keyboards. Contact him if you are interested. Not affiliated with seller, etc. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From jnc at mercury.lcs.mit.edu Tue Feb 5 13:12:31 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Feb 2019 14:12:31 -0500 (EST) Subject: DZ11 H3006 8-line EIA distribution panels Message-ID: <20190205191231.A489A18C07B@mercury.lcs.mit.edu> If anyone out there needs an EIA distribution panel to go with their DZ11, here: https://www.ebay.com/itm/321225351590 are some of the 8-line ones (as used in the later modular back panel system). The seller (Efi) is good people. Noel From sales at elecplus.com Tue Feb 5 14:07:25 2019 From: sales at elecplus.com (Electronics Plus) Date: Tue, 5 Feb 2019 14:07:25 -0600 Subject: Penn Computer is out of biz Message-ID: <011801d4bd8e$69bc97c0$3d35c740$@com> Unfortunately, they have already scrapped everything! They were distributors of old HP and IBM hardware. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From harper at secureoutcomes-hq.com Tue Feb 5 14:19:51 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Tue, 05 Feb 2019 13:19:51 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> Message-ID: <20190205201958.2AB9227377@mx1.ezwind.net> Greetings to the List - My very sincere THANKS for the enlightening responses from Chuck Guzis, Brent Hilpert and Jay West on mounting the HP 7970 tape drive Beasts. I am out of town on business for a couple days and will inspect things when I return. Chuck is, of course, 100% correct on the Tipping Factor. I learned that very quickly - If you open the front of the Drive and swing out the door with the electronics, drive motors etc, it is definitely heavy enough to tip a rack. I bolted the destination 19" rack down to the concrete floor with 3/8" bolts. It will not, I hope, soon go anywhere. Jay makes a very valid point - these things are heavy at 130-pounds each and are real Beasts to deal with especially by yourself. I got both drives into the rack this past weekend and I am an old guy (67) - I carefully stared at the thing before I started and finally figured out that I could, in fact, lift the drive from a waist high cart for a few seconds, but definitely could not lift it or lower it vertically with my arms - no way - and I would have one shot at getting the drives into the rack on the rails. I used heavy and very wide aluminum angle stock for the rails and very carefully measured everything so that I got the rails installed correctly at the right height inside the rack so the screw holes on the front of the drives would mate to the rack and the drives would not overlap or gap and so as to be level. In addition, I slathered a bit of Orange Oil onto the rails to reduce friction when sliding in as there is a lot of friction - 130-pounds of steel on aluminum. Anyway, I finally figured out after staring at it for a few minutes that I should be able to step up carrying the Beast onto a step that I built out of scrap wood - I needed about eight inches in additional height after picking up the thing - so, I took a deep gulp and did that - picked up the drive Beast and stepped up on the step with my left foot - got my left knee under the front of the Beast to raise it a bit and was able to slide the rear of the Beast onto the rails - once I had support on the back of the drive, I was able to then lift the front and slide the thing in. The #2 drive Beast went into the lower part of the rack similarly except that I had the exact opposite problem - I could not possibly pick up the drive and lower it vertically with my arms to align it with the bottom bay - I finally figured out to use a wooden ammunition box (strong with dove tail joints) of the correct matching height on end - I was able to lower the Beast to sit on that in front of the rack - and then slide the thing in. That worked! Hooray! I actually got the things in without hurting myself - DOUBLE HOORAY! I celebrated with a shot of nice Cognac :) Jay is also 100% correct - these things are real bears to deal with - do NOT try it on your own - I was lucky! Anyway, I somehow managed to get everything aligned correctly to within 1/32" or so - the drives look great! :) Remaining tasks: Figure out how to get the mounting screws into the left sides of the drives (the right screws are in); mount a fan on the bottom rear of the rack - I think that should blow in through a filter for positive pressure - is that correct? - and make the rack at least almost air tight to keep the dust out. See http://frobenius.com/190203%20Tape%20Drive1.jpg http://frobenius.com/190203%20Tape%20Drive2.jpg http://frobenius.com/190203%20Tape%20Drive3.jpg for a couple of snapshots. I thought about a photo of me partially soused with my celebratory shot of Cognac, but decided otherwise :) Best, Jack (Hello from the Rockies - we have two-feet of snow forecast overnight :) t 11:25 PM 2/4/2019, you wrote: >On 2/4/19 3:40 PM, Jack Harper via cctalk wrote: > > > > > > Greetings to the List - > > > > I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to > > a 19" rack. > > > > The screw holes that mate to the standard spaced holes on the right side > > of the drive after you open the case are visible and obvious. > > > > However, the holes on the left are hidden under the heavy die-cast(?) > > frame of the drive. > > > > Anyone know how to get to those three screw holes with a horrible > > disassembly. > > > > There has to be a trick to this that I don't see (so what else is new? :) > > > >There's a mounting kit for this as described here; > >http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/tape/7970/07970-90383_7970B_7970C_Operating_and_Service_Manual_upd_Feb76/07970-90383_7970B_7970C_Operating_and_Service_Manual_Section_1.pdf > >Page 2-1, section 2-8, installation. > >Whatever you do, be sure that your rack has an "anti-tip" foot (most >full-size 19" HP racks do. When you open the drive, the entire assembly >but for the card cages and the power supply swing out. It's more than >enough to tip a rack over. > >--Chuck ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From sales at elecplus.com Tue Feb 5 14:54:50 2019 From: sales at elecplus.com (Electronics Plus) Date: Tue, 5 Feb 2019 14:54:50 -0600 Subject: Another dealer going under Message-ID: <015f01d4bd95$09bdafb0$1d390f10$@com> I don't get replies from here yet, so I have seen no replies to my posts, nor the posts themselves. There is a shop that has been in biz for over 25 years that is closing in California. I asked for anything old Apple, Sun, HP, IBM, and any old keyboards. She will call me back tomorrow. She never dealt with the off brands, just major maintenance contracts. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From cctalk at ibm51xx.net Tue Feb 5 14:56:52 2019 From: cctalk at ibm51xx.net (Ali) Date: Tue, 5 Feb 2019 12:56:52 -0800 Subject: Another dealer going under In-Reply-To: <015f01d4bd95$09bdafb0$1d390f10$@com> References: <015f01d4bd95$09bdafb0$1d390f10$@com> Message-ID: <005101d4bd95$52f7b810$f8e72830$@net> > I don't get replies from here yet, so I have seen no replies to my > posts, > nor the posts themselves. > > There is a shop that has been in biz for over 25 years that is closing > in > California. > Cindy, Where in CA? It's a big state :) -Ali From cclist at sydex.com Tue Feb 5 14:59:21 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 5 Feb 2019 12:59:21 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190205201958.2AB9227377@mx1.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> Message-ID: <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> On 2/5/19 12:19 PM, Jack Harper via cctalk wrote: > > > Greetings to the List - > > My very sincere THANKS for the enlightening responses from Chuck Guzis, > Brent Hilpert and Jay West on mounting the HP 7970 tape drive Beasts. > > I am out of town on business for a couple days and will inspect things > when I return. > > > Chuck is, of course, 100% correct on the Tipping Factor. > > I learned that very quickly - If you open the front of the Drive and > swing out the door with the electronics, drive motors etc, it is > definitely heavy enough to tip a rack. > > I bolted the destination 19" rack down to the concrete floor with 3/8" > bolts.? It will not, I hope, soon go anywhere. After struggling years earlier with getting a Fujitsu drive into a rack by my lonesome, I was determined not to repeat the process. The rack, VTW, is from an old HP Storage Array, which has a nice anti-tip pullout on the bottom. I constructed a dolly for the HP drive that allows me to roll it around where I need it. It's low enough that it can slip under a table. I should have done the same for the Fuji drive, now that i think about it. I leave the heavy lifting to the young bucks like yourself. When you break one of the retention levers (they get brittle with age), drop me a line. I have some 3D printed up from nylon that work just fine. --Chuck From cube1 at charter.net Tue Feb 5 16:22:50 2019 From: cube1 at charter.net (Jay Jaeger) Date: Tue, 5 Feb 2019 16:22:50 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> Message-ID: <934366bf-e9a8-fac9-3ebb-4294ced7e61f@charter.net> On 2/5/2019 12:03 PM, Fritz Mueller via cctalk wrote: >> Perhaps compile [test programs] under SimH and do a block-level diff of the image with what is currently in use, and transfer just those blocks? > > I did experiment with this a little way back. I wrote a small standalone code that dumps a CRC of every sector over the console; I can run this both under SIMH and on the real machine, then diff to find the changed sectors. > > Unfortunately, when I tried to apply this, it seemed that SIMH's write single sector wasn't working correctly for me (though "write all sectors to end" seemed to work okay). It ended up being much more tedious than I had thought to do it this way; in the end I concluded I'd be better off writing some different software specifically for this purpose, but I haven't gotten back to it yet. > > FWIW, I maintain a Windows VM (on a MacOS X host) for the sole purpose of running PDP11GUI, and I use an USA19H USB serial dongle connected through to the VM as a serial interface. I don't know if something about this setup is particularly detrimental to PDP11GUI transfer performance? It takes me >3hrs to write a 2.5mb pack this way (at 9600 baud), or a little over 1hr to read one back. Do others see similar throughput with these tools? > > --FritzM. > > At 9600 bps, and allowing for 10 bit characters (8 data bits, 1 start, 1 stop), that is 960 cps, and 2.5MB RK05 should take under an hour (2400 s). Round that up to an hour, say, for handshaking overhead, etc. That is consistent with your read time. To get to three hours we would need a pause for each write of: 7200 = 200 (tracks) x 12 (sectors/trk) x 2 (sides) x n seconds/block And n would be 1.5 seconds / sector for the write time. That seems excessive. Perhaps it is doing read after write verify for each block written? If so, can you turn that verify off? (When I do my transfers over a DR11, I run a separate checksum step afterwards, and the transfer programs also report their checksums). From derschjo at gmail.com Tue Feb 5 16:48:07 2019 From: derschjo at gmail.com (Josh Dersch) Date: Tue, 5 Feb 2019 14:48:07 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> Message-ID: On Tue, Feb 5, 2019 at 10:03 AM Fritz Mueller via cctalk < cctalk at classiccmp.org> wrote: > > > FWIW, I maintain a Windows VM (on a MacOS X host) for the sole purpose of > running PDP11GUI, and I use an USA19H USB serial dongle connected through > to the VM as a serial interface. I don't know if something about this > setup is particularly detrimental to PDP11GUI transfer performance? It > takes me >3hrs to write a 2.5mb pack this way (at 9600 baud), or a little > over 1hr to read one back. Do others see similar throughput with these > tools? > Yes. PDP11GUI is a great tool but it is extremely slow for dumping disks. It's not your setup. I restored an RL02 pack this way once (at 9600bps) and it took a very long time (I didn't time it but it was well over 6 hours). Compare this with restoring an RK05 pack on my PDP-8 using dumprest, which takes just about an hour... - Josh > > --FritzM. > > From paulkoning at comcast.net Tue Feb 5 18:25:48 2019 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 5 Feb 2019 19:25:48 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> Message-ID: On the logic analyzer suggestion: I remember seeing a logic analyzer hooked to a PDP-11 at DEC, for software debugging. As I recall, it was connected at the console front panel, which seems reasonable since several key CPU data paths are exposed there. paul From pete at dunnington.plus.com Tue Feb 5 19:53:25 2019 From: pete at dunnington.plus.com (Pete Turnbull) Date: Wed, 6 Feb 2019 01:53:25 +0000 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> Message-ID: <5897aa4a-164f-dc77-61ec-945d0692290c@dunnington.plus.com> On 05/02/2019 20:59, Chuck Guzis via cctalk wrote: > On 2/5/19 12:19 PM, Jack Harper via cctalk wrote: >> I learned that very quickly - If you open the front of the Drive and >> swing out the door with the electronics, drive motors etc, it is >> definitely heavy enough to tip a rack. >> >> I bolted the destination 19" rack down to the concrete floor with 3/8" >> bolts.? It will not, I hope, soon go anywhere. > > After struggling years earlier with getting a Fujitsu drive into a rack > by my lonesome, I was determined not to repeat the process. The rack, > VTW, is from an old HP Storage Array, which has a nice anti-tip pullout > on the bottom. > > I constructed a dolly for the HP drive that allows me to roll it around > where I need it. It's low enough that it can slip under a table. Some years ago, Jay recommended a Genie Load Lifter to me (thank you!), and I was fortunate enough to get two of them as "new old stock" for about half price. They're relatively inexpensive and absolutely invaluable. Put a 200lb unit into the top of a full height rack? No problem. Shame I had to leave both behind when I left that employment (especially since they bought a third one but never used it)! -- Pete Pete Turnbull From useddec at gmail.com Tue Feb 5 19:54:39 2019 From: useddec at gmail.com (Paul Anderson) Date: Tue, 5 Feb 2019 19:54:39 -0600 Subject: Looking for Limited Function Board In-Reply-To: References: Message-ID: Hi Pontus, I looked at my limited function front panels, and they were 54-11507s. I have not looked at any prints. Where did you find the 54-11165 number? Could it be for a Q-bus system? The 50-XXXXX is the etched PCB. DEC usually added a 1 to that number to make it complete board. Thanks, Paul On Mon, Feb 4, 2019 at 9:41 PM Paul Anderson wrote: > I have a few of the limited function and programmers panels. I do not > recall either of them being dependent on particular backplane. I'll try to > pull a few a few later and check the part number on them. > > Remember, a 54-XXXXX number can become a 70-XXXXX with the addition of a > cable or something simple. > > Paul > > On Mon, Feb 4, 2019 at 12:51 PM Anders Sandahl via cctech < > cctech at classiccmp.org> wrote: > >> > Date: Sun, 3 Feb 2019 22:22:42 +0100 >> > From: Pontus Pihlgren >> > To: "General Discussion: On-Topic and Off-Topic Posts" >> > >> > Subject: Looking for Limited Function Board >> > Message-ID: <20190203212242.GF24947 at Update.UU.SE> >> > Content-Type: text/plain; charset=us-ascii >> > >> > Hi >> > >> > I'm restoring a PDP-8/a with the help of some >> > friends. The CPU is now passing the MAINDECs I've >> > thrown at it. The memory is a modern semiconductor >> > board my friend Anders Sandahl made. >> > >> > This machine is pieced together from several others >> > and the limited function panel I got does not match >> > the backplane I have. >> > >> > My theory is the DEC simplified the design of the >> > boardto cut costs and simpler design is not >> > compatible. Mine is labeled (on the PCB): >> > >> > "LIMITED FUNCTION BD. >> > 5411507 >> > 5011506C-P2" >> > >> > And the one I need is: >> > >> > "LIMITED FUNCTION >> > 5411165 >> > 5011167" >> > >> > However, the picture I have of the other is not so >> > good. I may have read the numbera wrong. >> > >> > I would very much like to buy one to finish this >> > project. >> > >> > /P >> >> F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att >> flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett >> originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r >> det ju att ?terst?lla... >> >> /A >> >> From fritzm at fritzm.org Wed Feb 6 00:40:54 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 5 Feb 2019 22:40:54 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <4204D4B6-19DD-4874-96B3-B81DC0698E4D@fritzm.org> References: <20190204102808.9F5CA18C07A@mercury.lcs.mit.edu> <4204D4B6-19DD-4874-96B3-B81DC0698E4D@fritzm.org> Message-ID: <2250BC05-5BEF-48B8-B6F9-AF4B1302E3CD@fritzm.org> >> Would it be any difference if you run the machine at full speed or lower speed... > > Ah, yes -- this I haven't tried yet! I have a KM11 replica, so this is easy enough to do; I'll give that a go when I next get back to the machine (possibly this evening). Ran the machine on the maintenance clock via the KM11 at a variety of speeds, and the behavior remains the same. So not too timing sensitive... At least its consistent! --FritzM. From fritzm at fritzm.org Wed Feb 6 00:45:24 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 5 Feb 2019 22:45:24 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190205133605.13E2C18C07B@mercury.lcs.mit.edu> <1E7D795F-819C-450A-95AF-A1153C09DD39@fritzm.org> Message-ID: <67DBBE86-4BB2-46A4-83BC-5970393618E7@fritzm.org> > On the logic analyzer suggestion: I remember seeing a logic analyzer hooked to a PDP-11 at DEC, for software debugging. As I recall, it was connected at the console front panel, which seems reasonable since several key CPU data paths are exposed there. Ooh, I like that suggestion! It might be worth making up some inline cables for the LA just for this purpose, so it could be a quick hookup whenever needed. --FritzM. From pontus at Update.UU.SE Wed Feb 6 02:42:08 2019 From: pontus at Update.UU.SE (Pontus Pihlgren) Date: Wed, 6 Feb 2019 09:42:08 +0100 Subject: Looking for Limited Function Board In-Reply-To: References: Message-ID: <20190206084208.GG24947@Update.UU.SE> Hi Paul I have put pictures of the boards here: http://pdp8.se/slask/LFB have.jpg is the board I have and want.jpg is the one I'm looking for. The identifying numbers are in aproximately the same place. But you can clearly see that the "want" board is much simplified and if I interpret the documentation correctly they are not compatible. I'm happy to be proven wrong, maybe I should just try it. /P On Tue, Feb 05, 2019 at 07:54:39PM -0600, Paul Anderson via cctalk wrote: > Hi Pontus, > > I looked at my limited function front panels, and they were 54-11507s. I > have not looked at any prints. Where did you find the 54-11165 number? > Could it be for a Q-bus system? > > The 50-XXXXX is the etched PCB. DEC usually added a 1 to that number to > make it complete board. > > Thanks, Paul > > > > On Mon, Feb 4, 2019 at 9:41 PM Paul Anderson wrote: > > > I have a few of the limited function and programmers panels. I do not > > recall either of them being dependent on particular backplane. I'll try to > > pull a few a few later and check the part number on them. > > > > Remember, a 54-XXXXX number can become a 70-XXXXX with the addition of a > > cable or something simple. > > > > Paul > > > > On Mon, Feb 4, 2019 at 12:51 PM Anders Sandahl via cctech < > > cctech at classiccmp.org> wrote: > > > >> > Date: Sun, 3 Feb 2019 22:22:42 +0100 > >> > From: Pontus Pihlgren > >> > To: "General Discussion: On-Topic and Off-Topic Posts" > >> > > >> > Subject: Looking for Limited Function Board > >> > Message-ID: <20190203212242.GF24947 at Update.UU.SE> > >> > Content-Type: text/plain; charset=us-ascii > >> > > >> > Hi > >> > > >> > I'm restoring a PDP-8/a with the help of some > >> > friends. The CPU is now passing the MAINDECs I've > >> > thrown at it. The memory is a modern semiconductor > >> > board my friend Anders Sandahl made. > >> > > >> > This machine is pieced together from several others > >> > and the limited function panel I got does not match > >> > the backplane I have. > >> > > >> > My theory is the DEC simplified the design of the > >> > boardto cut costs and simpler design is not > >> > compatible. Mine is labeled (on the PCB): > >> > > >> > "LIMITED FUNCTION BD. > >> > 5411507 > >> > 5011506C-P2" > >> > > >> > And the one I need is: > >> > > >> > "LIMITED FUNCTION > >> > 5411165 > >> > 5011167" > >> > > >> > However, the picture I have of the other is not so > >> > good. I may have read the numbera wrong. > >> > > >> > I would very much like to buy one to finish this > >> > project. > >> > > >> > /P > >> > >> F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att > >> flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett > >> originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r > >> det ju att ?terst?lla... > >> > >> /A > >> > >> From pontus at Update.UU.SE Wed Feb 6 02:42:08 2019 From: pontus at Update.UU.SE (Pontus Pihlgren) Date: Wed, 6 Feb 2019 09:42:08 +0100 Subject: Looking for Limited Function Board In-Reply-To: References: Message-ID: <20190206084208.GG24947@Update.UU.SE> Hi Paul I have put pictures of the boards here: http://pdp8.se/slask/LFB have.jpg is the board I have and want.jpg is the one I'm looking for. The identifying numbers are in aproximately the same place. But you can clearly see that the "want" board is much simplified and if I interpret the documentation correctly they are not compatible. I'm happy to be proven wrong, maybe I should just try it. /P On Tue, Feb 05, 2019 at 07:54:39PM -0600, Paul Anderson via cctalk wrote: > Hi Pontus, > > I looked at my limited function front panels, and they were 54-11507s. I > have not looked at any prints. Where did you find the 54-11165 number? > Could it be for a Q-bus system? > > The 50-XXXXX is the etched PCB. DEC usually added a 1 to that number to > make it complete board. > > Thanks, Paul > > > > On Mon, Feb 4, 2019 at 9:41 PM Paul Anderson wrote: > > > I have a few of the limited function and programmers panels. I do not > > recall either of them being dependent on particular backplane. I'll try to > > pull a few a few later and check the part number on them. > > > > Remember, a 54-XXXXX number can become a 70-XXXXX with the addition of a > > cable or something simple. > > > > Paul > > > > On Mon, Feb 4, 2019 at 12:51 PM Anders Sandahl via cctech < > > cctech at classiccmp.org> wrote: > > > >> > Date: Sun, 3 Feb 2019 22:22:42 +0100 > >> > From: Pontus Pihlgren > >> > To: "General Discussion: On-Topic and Off-Topic Posts" > >> > > >> > Subject: Looking for Limited Function Board > >> > Message-ID: <20190203212242.GF24947 at Update.UU.SE> > >> > Content-Type: text/plain; charset=us-ascii > >> > > >> > Hi > >> > > >> > I'm restoring a PDP-8/a with the help of some > >> > friends. The CPU is now passing the MAINDECs I've > >> > thrown at it. The memory is a modern semiconductor > >> > board my friend Anders Sandahl made. > >> > > >> > This machine is pieced together from several others > >> > and the limited function panel I got does not match > >> > the backplane I have. > >> > > >> > My theory is the DEC simplified the design of the > >> > boardto cut costs and simpler design is not > >> > compatible. Mine is labeled (on the PCB): > >> > > >> > "LIMITED FUNCTION BD. > >> > 5411507 > >> > 5011506C-P2" > >> > > >> > And the one I need is: > >> > > >> > "LIMITED FUNCTION > >> > 5411165 > >> > 5011167" > >> > > >> > However, the picture I have of the other is not so > >> > good. I may have read the numbera wrong. > >> > > >> > I would very much like to buy one to finish this > >> > project. > >> > > >> > /P > >> > >> F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att > >> flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett > >> originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r > >> det ju att ?terst?lla... > >> > >> /A > >> > >> From anders at abc80.net Wed Feb 6 03:41:41 2019 From: anders at abc80.net (Anders Sandahl) Date: Wed, 6 Feb 2019 10:41:41 +0100 Subject: Looking for Limited Function Board In-Reply-To: <20190206084208.GG24947@Update.UU.SE> References: <20190206084208.GG24947@Update.UU.SE> Message-ID: <6fc0d950e983738619671ae38c182229.squirrel@webmail.sadata.se> Hi, I have looked into my PDP-8/a computers now. The small one have the limited function board that you want. That is the machine that should be identical to yours. In my big PDP-8a/420 I have the same board as you have "have.jpg" but in another revision (no IDC header connector, just the DIL connector). The big machine is a core memory machine. I had a quick look at the schematics, they are not compatible. /Anders > Hi Paul > > I have put pictures of the boards here: > > http://pdp8.se/slask/LFB > > have.jpg is the board I have and want.jpg is the one > I'm looking for. > > The identifying numbers are in aproximately the same > place. But you can clearly see that the "want" board > is much simplified and if I interpret the > documentation correctly they are not compatible. > > I'm happy to be proven wrong, maybe I should just try > it. > > /P > > > On Tue, Feb 05, 2019 at 07:54:39PM -0600, Paul Anderson via cctalk wrote: >> Hi Pontus, >> >> I looked at my limited function front panels, and they were 54-11507s. I >> have not looked at any prints. Where did you find the 54-11165 number? >> Could it be for a Q-bus system? >> >> The 50-XXXXX is the etched PCB. DEC usually added a 1 to that number to >> make it complete board. >> >> Thanks, Paul >> >> >> >> On Mon, Feb 4, 2019 at 9:41 PM Paul Anderson wrote: >> >> > I have a few of the limited function and programmers panels. I do not >> > recall either of them being dependent on particular backplane. I'll >> try to >> > pull a few a few later and check the part number on them. >> > >> > Remember, a 54-XXXXX number can become a 70-XXXXX with the addition of >> a >> > cable or something simple. >> > >> > Paul >> > >> > On Mon, Feb 4, 2019 at 12:51 PM Anders Sandahl via cctech < >> > cctech at classiccmp.org> wrote: >> > >> >> > Date: Sun, 3 Feb 2019 22:22:42 +0100 >> >> > From: Pontus Pihlgren >> >> > To: "General Discussion: On-Topic and Off-Topic Posts" >> >> > >> >> > Subject: Looking for Limited Function Board >> >> > Message-ID: <20190203212242.GF24947 at Update.UU.SE> >> >> > Content-Type: text/plain; charset=us-ascii >> >> > >> >> > Hi >> >> > >> >> > I'm restoring a PDP-8/a with the help of some >> >> > friends. The CPU is now passing the MAINDECs I've >> >> > thrown at it. The memory is a modern semiconductor >> >> > board my friend Anders Sandahl made. >> >> > >> >> > This machine is pieced together from several others >> >> > and the limited function panel I got does not match >> >> > the backplane I have. >> >> > >> >> > My theory is the DEC simplified the design of the >> >> > boardto cut costs and simpler design is not >> >> > compatible. Mine is labeled (on the PCB): >> >> > >> >> > "LIMITED FUNCTION BD. >> >> > 5411507 >> >> > 5011506C-P2" >> >> > >> >> > And the one I need is: >> >> > >> >> > "LIMITED FUNCTION >> >> > 5411165 >> >> > 5011167" >> >> > >> >> > However, the picture I have of the other is not so >> >> > good. I may have read the numbera wrong. >> >> > >> >> > I would very much like to buy one to finish this >> >> > project. >> >> > >> >> > /P >> >> >> >> F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? >> att >> >> flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett >> >> originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det >> s? g?r >> >> det ju att ?terst?lla... >> >> >> >> /A >> >> >> >> > From anders at abc80.net Wed Feb 6 03:41:41 2019 From: anders at abc80.net (Anders Sandahl) Date: Wed, 6 Feb 2019 10:41:41 +0100 Subject: Looking for Limited Function Board In-Reply-To: <20190206084208.GG24947@Update.UU.SE> References: <20190206084208.GG24947@Update.UU.SE> Message-ID: <6fc0d950e983738619671ae38c182229.squirrel@webmail.sadata.se> Hi, I have looked into my PDP-8/a computers now. The small one have the limited function board that you want. That is the machine that should be identical to yours. In my big PDP-8a/420 I have the same board as you have "have.jpg" but in another revision (no IDC header connector, just the DIL connector). The big machine is a core memory machine. I had a quick look at the schematics, they are not compatible. /Anders > Hi Paul > > I have put pictures of the boards here: > > http://pdp8.se/slask/LFB > > have.jpg is the board I have and want.jpg is the one > I'm looking for. > > The identifying numbers are in aproximately the same > place. But you can clearly see that the "want" board > is much simplified and if I interpret the > documentation correctly they are not compatible. > > I'm happy to be proven wrong, maybe I should just try > it. > > /P > > > On Tue, Feb 05, 2019 at 07:54:39PM -0600, Paul Anderson via cctalk wrote: >> Hi Pontus, >> >> I looked at my limited function front panels, and they were 54-11507s. I >> have not looked at any prints. Where did you find the 54-11165 number? >> Could it be for a Q-bus system? >> >> The 50-XXXXX is the etched PCB. DEC usually added a 1 to that number to >> make it complete board. >> >> Thanks, Paul >> >> >> >> On Mon, Feb 4, 2019 at 9:41 PM Paul Anderson wrote: >> >> > I have a few of the limited function and programmers panels. I do not >> > recall either of them being dependent on particular backplane. I'll >> try to >> > pull a few a few later and check the part number on them. >> > >> > Remember, a 54-XXXXX number can become a 70-XXXXX with the addition of >> a >> > cable or something simple. >> > >> > Paul >> > >> > On Mon, Feb 4, 2019 at 12:51 PM Anders Sandahl via cctech < >> > cctech at classiccmp.org> wrote: >> > >> >> > Date: Sun, 3 Feb 2019 22:22:42 +0100 >> >> > From: Pontus Pihlgren >> >> > To: "General Discussion: On-Topic and Off-Topic Posts" >> >> > >> >> > Subject: Looking for Limited Function Board >> >> > Message-ID: <20190203212242.GF24947 at Update.UU.SE> >> >> > Content-Type: text/plain; charset=us-ascii >> >> > >> >> > Hi >> >> > >> >> > I'm restoring a PDP-8/a with the help of some >> >> > friends. The CPU is now passing the MAINDECs I've >> >> > thrown at it. The memory is a modern semiconductor >> >> > board my friend Anders Sandahl made. >> >> > >> >> > This machine is pieced together from several others >> >> > and the limited function panel I got does not match >> >> > the backplane I have. >> >> > >> >> > My theory is the DEC simplified the design of the >> >> > boardto cut costs and simpler design is not >> >> > compatible. Mine is labeled (on the PCB): >> >> > >> >> > "LIMITED FUNCTION BD. >> >> > 5411507 >> >> > 5011506C-P2" >> >> > >> >> > And the one I need is: >> >> > >> >> > "LIMITED FUNCTION >> >> > 5411165 >> >> > 5011167" >> >> > >> >> > However, the picture I have of the other is not so >> >> > good. I may have read the numbera wrong. >> >> > >> >> > I would very much like to buy one to finish this >> >> > project. >> >> > >> >> > /P >> >> >> >> F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? >> att >> >> flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett >> >> originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det >> s? g?r >> >> det ju att ?terst?lla... >> >> >> >> /A >> >> >> >> > From classiccmp at philpem.me.uk Wed Feb 6 09:08:14 2019 From: classiccmp at philpem.me.uk (Phil Pemberton) Date: Wed, 6 Feb 2019 15:08:14 +0000 (GMT) Subject: Looking for: 68000 C compilers Message-ID: Hi, I'm (still) trying to reverse-engineer a ton of M68K ROM code which was apparently compiled with a circa-1990 C compiler. Does anyone have copies of any of the following -- or any other C compilers for the 68K which were around at that time? * Sierra Systems 68000 C compiler (was part of some Sega Genesis developer kits) * HP 68000 C compiler (either the HP 64000 or MSDOS versions) (I believe this was sold as the "HP B3640 Motorola 68000 Family C Cross Compiler) * Lattice C * Anything not on this list ;) My game plan is to take the compiled standard libraries from these compilers and build up some patterns/"fingerprints" to try and make a better guess at what the code is up to. I figure if I can at least pin down the stdlib and floating-point code, I have a better chance at figuring out what the main code does. I've seen the HP cross compiler manual on Bitsavers, but the compiler itself doesn't seem to be on bitsavers/bits. Thanks. -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/ From emu at e-bbes.com Wed Feb 6 09:22:35 2019 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 6 Feb 2019 10:22:35 -0500 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: <95bce187-6b9a-7125-0e11-76f255760e83@e-bbes.com> On 2019-02-06 10:08, Phil Pemberton via cctalk wrote: > Hi, > > I'm (still) trying to reverse-engineer a ton of M68K ROM code which was > apparently compiled with a circa-1990 C compiler. > AT&T B1 UNIX? And, we did at this time a lot on the OS/9 on microware. But I shink there is still a copyright on it ... Cheers From rtomek at ceti.pl Wed Feb 6 10:21:44 2019 From: rtomek at ceti.pl (Tomasz Rola) Date: Wed, 6 Feb 2019 17:21:44 +0100 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: <20190206162144.GA27182@tau1.ceti.pl> On Wed, Feb 06, 2019 at 03:08:14PM +0000, Phil Pemberton via cctalk wrote: > Hi, > > I'm (still) trying to reverse-engineer a ton of M68K ROM code which > was apparently compiled with a circa-1990 C compiler. > > Does anyone have copies of any of the following -- or any other C > compilers for the 68K which were around at that time? [...] > > * Lattice C > > * Anything not on this list ;) Aztec C, by Manx Software (by now probably defunct). The Official Aztec C Online Museum: http://www.aztecmuseum.ca/index.htm stuff (those guys did a lot of them): http://www.aztecmuseum.ca/compilers.htm -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From ethan.dicks at gmail.com Wed Feb 6 10:27:08 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Wed, 6 Feb 2019 10:27:08 -0600 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: On Wed, Feb 6, 2019 at 9:08 AM Phil Pemberton via cctalk wrote: > I'm (still) trying to reverse-engineer a ton of M68K ROM code which was > apparently compiled with a circa-1990 C compiler. I used to do a lot of m68k ROM code development c. 1985-1993... > Does anyone have copies of any of the following -- or any other C > compilers for the 68K which were around at that time? > * Lattice C Yes. For AmigaDOS... > * Anything not on this list ;) We rolled our own m68k cross assembler that ran on VMS, twice - one was a very simple, unsophisticated assembler that just took blocks of code and banged out a monolithic OBJ, and later, a fancier one with relocatable blocks and multiple sections that produced more of a "loader format" for linking multiple entities together. I have the source for these but they are definitely K&R C and may have some file routines that would have to be lightly massaged out of VMS-isms. -ethan From cctalk at ibm51xx.net Wed Feb 6 11:07:07 2019 From: cctalk at ibm51xx.net (Ali) Date: Wed, 6 Feb 2019 09:07:07 -0800 Subject: Another dealer going under In-Reply-To: <030001d4be3c$e0688b50$a139a1f0$@com> References: <015f01d4bd95$09bdafb0$1d390f10$@com> <005101d4bd95$52f7b810$f8e72830$@net> <030001d4be3c$e0688b50$a139a1f0$@com> Message-ID: <00c701d4be3e$64feffb0$2efcff10$@net> > Calabasas, CA Well for a change it is someone just next door so I can definitely take a look. I wonder if they have anything available. Do you have contact info/address? -Ali > > -----Original Message----- > From: Ali [mailto:cctalk at ibm51xx.net] > Sent: Tuesday, February 05, 2019 2:57 PM > To: 'Electronics Plus'; 'General Discussion: On-Topic and Off-Topic > Posts' > Subject: RE: Another dealer going under > > > > I don't get replies from here yet, so I have seen no replies to my > > posts, > > nor the posts themselves. > > > > There is a shop that has been in biz for over 25 years that is > closing > > in > > California. > > > > Cindy, > > Where in CA? It's a big state :) > > -Ali From harper at secureoutcomes-hq.com Wed Feb 6 11:23:38 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Wed, 06 Feb 2019 10:23:38 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <5897aa4a-164f-dc77-61ec-945d0692290c@dunnington.plus.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <5897aa4a-164f-dc77-61ec-945d0692290c@dunnington.plus.com> Message-ID: <20190206172343.C43E1274CD@mx1.ezwind.net> At 06:53 PM 2/5/2019, you wrote: >Some years ago, Jay recommended a Genie Load Lifter to me (thank >you!), and I was fortunate enough to get two of them as "new old >stock" for about half price. They're relatively inexpensive and >absolutely invaluable. Put a 200lb unit into the top of a full >height rack? No problem. Shame I had to leave both behind when I >left that employment (especially since they bought a third one but >never used it)! > >Pete >Pete Turnbull Pete - That Genie Load Lifter gizmo looks great - and I wish I had one on Sunday when I was horsing those HP drives around. They are not cheap - a used one on eBay for $600. But, what is a back worth? Best, Jack in the Rocky Mountains. ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From sales at elecplus.com Wed Feb 6 11:24:59 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 6 Feb 2019 11:24:59 -0600 Subject: Another dealer going under In-Reply-To: <00c701d4be3e$64feffb0$2efcff10$@net> References: <015f01d4bd95$09bdafb0$1d390f10$@com> <005101d4bd95$52f7b810$f8e72830$@net> <030001d4be3c$e0688b50$a139a1f0$@com> <00c701d4be3e$64feffb0$2efcff10$@net> Message-ID: <036f01d4be40$e393b6c0$aabb2440$@com> A Plus Computer Products 5115 N. Douglas Fir Road Suite N Calabasas, CA 91302 Leslie Foumberg, Owner Leslie Foumberg [leslie at apluscp.com] You might try emailing her directly. I have sent her an email letting her know she might start getting some oddball requests. Also requested a spreadsheet of inventory, or lots of pics on a shared link, and then you can email her your interest. Sorry, but I have a sick husband right now, and no time to play intermediary. Cindy --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From harper at secureoutcomes-hq.com Wed Feb 6 11:26:25 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Wed, 06 Feb 2019 10:26:25 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> Message-ID: <20190206172631.40756273FB@mx1.ezwind.net> At 01:59 PM 2/5/2019, you wrote: >by my lonesome, I was determined not to repeat the process. The rack, >VTW, is from an old HP Storage Array, which has a nice anti-tip pullout >on the bottom. > >I constructed a dolly for the HP drive that allows me to roll it around >where I need it. It's low enough that it can slip under a table. > >I should have done the same for the Fuji drive, now that i think about it. > >I leave the heavy lifting to the young bucks like yourself. > >When you break one of the retention levers (they get brittle with age), >drop me a line. I have some 3D printed up from nylon that work just fine. > >--Chuck Thank You Chuck - You are correct - I would never try that again. I appreciate the offer on the retension levers on the HP 7970. Best, Jack in the Rocky Mountains (cold and snowy day here at a forecast -2F :) ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From dave.g4ugm at gmail.com Wed Feb 6 11:39:04 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Wed, 6 Feb 2019 17:39:04 -0000 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: <01db01d4be42$db5de5f0$9219b1d0$@gmail.com> Phil I doubt if its relevant but I think I have Sozobon C for the Atari. There was also a Mark Williams "C" .... https://en.wikipedia.org/wiki/Mark_Williams_Company http://www.atari-forum.com/viewtopic.php?t=25148 and of course various GNU ports. Dave > -----Original Message----- > From: cctalk On Behalf Of Phil Pemberton > via cctalk > Sent: 06 February 2019 15:08 > To: cctalk at classiccmp.org > Subject: Looking for: 68000 C compilers > > Hi, > > I'm (still) trying to reverse-engineer a ton of M68K ROM code which was > apparently compiled with a circa-1990 C compiler. > > Does anyone have copies of any of the following -- or any other C compilers > for the 68K which were around at that time? > > * Sierra Systems 68000 C compiler (was part of some Sega Genesis > developer kits) > > * HP 68000 C compiler (either the HP 64000 or MSDOS versions) > (I believe this was sold as the "HP B3640 Motorola 68000 Family C > Cross Compiler) > > * Lattice C > > * Anything not on this list ;) > > My game plan is to take the compiled standard libraries from these compilers > and build up some patterns/"fingerprints" to try and make a better guess at > what the code is up to. > I figure if I can at least pin down the stdlib and floating-point code, I have a > better chance at figuring out what the main code does. > > I've seen the HP cross compiler manual on Bitsavers, but the compiler itself > doesn't seem to be on bitsavers/bits. > > Thanks. > -- > Phil. > philpem at philpem.me.uk > http://www.philpem.me.uk/ From sales at elecplus.com Wed Feb 6 12:05:46 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 6 Feb 2019 12:05:46 -0600 Subject: 360Tech is gone Message-ID: <03b301d4be46$96219b40$c264d1c0$@com> Last May Steve auctioned off the assets, and and printer/plotter co bought the name and website. Steve retired to Hawaii. All is gone L Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From jwest at classiccmp.org Wed Feb 6 12:09:07 2019 From: jwest at classiccmp.org (Jay West) Date: Wed, 6 Feb 2019 12:09:07 -0600 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190206172631.40756273FB@mx1.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> Message-ID: <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> Chuck's retension levers.... any chance this is on thingiverse or would you be willing to send me the .stl file so I can 3dprint my own? :) I have not looked at my 7970's in quite some time, but I had thought the previous discussion was for mounting the 7970's in an HP rack. Not all later HP racks, but the 2 or 3 series that were predominant around the time of the 7970's, had a very specific build related to positioning of the holes (which were actually a few sliding metal bars with tapped holes, not just holes all up and down the rack). The 7970 mounting bracket was designed for that 'odd' HP-way the racks were built at that time (they changed later). I do not think that an HP rack called a "storage array" (obviously much later production) would have the same hole (and more importantly, the channels around the bars) pattern. Long story short, I am not positive that mounting the 7970 in a non-HP or HP but non-period rack would work 100% as originally intended. It may stay in the rack, but there could be some positional/operational issues. Specifically what I'm wondering, without the bracket and in a "non-hp" hp rack ;)... how did you bolt it on the left hand side? And are you sure that with it mounted that way, the speed bolt on the front right inside the door allows you to swing the unit all the way open without hitting the flush surface on the left of the casting? I need to go look at mine and see if I'm just remembering this all wrong... lol J From ethan.dicks at gmail.com Wed Feb 6 12:26:24 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Wed, 6 Feb 2019 12:26:24 -0600 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: On Wed, Feb 6, 2019 at 10:27 AM Ethan Dicks wrote: > On Wed, Feb 6, 2019 at 9:08 AM Phil Pemberton via cctalk > wrote: > > I'm (still) trying to reverse-engineer a ton of M68K ROM code which was > > apparently compiled with a circa-1990 C compiler. > > > Does anyone have copies of any of the following -- or any other C > > compilers for the 68K which were around at that time? > > * Anything not on this list ;) > > We rolled our own m68k cross assembler... I'm also remembering that the cost of a C compiler that ran on VMS but emitted m68k code was insanely expensive in the late 1980s (many thousands of dollars) so for one project, we purchased a Perkin Elmer 7350 workstation and it was both the software development environment for the team _and_ we used its C compiler to generate m68k assembler, which we then fed to our home-grown cross-assembler because we needed our binary format, not a.out. It really was the cheapest way to do that 30 years ago. OTOH, at home, I'd had an Amiga since 1986 and used a variety of native tools (Lattice C later SAS/C, and various assemblers either commercial or from a Fish Disk). -ethan From sales at elecplus.com Wed Feb 6 12:49:49 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 6 Feb 2019 12:49:49 -0600 Subject: old barcode and scanner equip Message-ID: <045001d4be4c$bd475e70$37d61b50$@com> Preowned Barcode Ltd John Gallant Halifax NS Canada PH (902) 468 8210 Cell (902)719 6031 Email: sales at preownedbarcode.com This gent has stuff from the 80s and 90s in the barcode and scanner departments. Not affiliated with seller, etc. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From cclist at sydex.com Wed Feb 6 12:52:51 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 6 Feb 2019 10:52:51 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> Message-ID: <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> On 2/6/19 10:09 AM, Jay West wrote: > I have not looked at my 7970's in quite some time, but I had thought the > previous discussion was for mounting the 7970's in an HP rack. Not all later > HP racks, but the 2 or 3 series that were predominant around the time of the > 7970's, had a very specific build related to positioning of the holes (which > were actually a few sliding metal bars with tapped holes, not just holes all > up and down the rack). The 7970 mounting bracket was designed for that 'odd' > HP-way the racks were built at that time (they changed later). I do not > think that an HP rack called a "storage array" (obviously much later > production) would have the same hole (and more importantly, the channels > around the bars) pattern. Long story short, I am not positive that mounting > the 7970 in a non-HP or HP but non-period rack would work 100% as > originally intended. It may stay in the rack, but there could be some > positional/operational issues. The HP disk array rack is a pretty standard 19" EIA rack, with some extra slots for mounting the disk drive slides. Looking at the 7970, without the mounting kit, it's a standard 19" wide. The right side flange has holes for mounting; the left side (the side with the support hinges for the works) has a similar flange, but without holes. Since mounting holes on an 19" rack are 18" apart, I could see where just boring a couple of holes in the hinge-side flange and countersinking them for flathead bolts would work to secure the drive. On the DA cabinet, however, the side "skins" project about an inch forward of the mounting rails, so you'd probably have to remove one to get clearance to open the drive up for servicing. On the other hand, a "naked" rack would probably work just fine. My Fujitsu drive was new when I got it and so came with its own mounting slides. Still is a heavy bugger, though. --Chuck From jnc at mercury.lcs.mit.edu Wed Feb 6 12:53:46 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Feb 2019 13:53:46 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190206185347.00D7E18C07B@mercury.lcs.mit.edu> > From: Mattis Lind >> we've also looked at what's in memory at that location, and the low >> part of the text segment seems to be correct, but there was junk at >> the top, around the target of the JSR (i.e. at 'csv'). Not just one >> word, but everything around that location was wrong, which would >> suggest to me that the cause is not a simple memory failure there. >> I've suggested to Fritz that we look at that again, to see if what was >> recorded before is accurate > Would it be possible to insert a breakpoint or halt and run the > program, insert original instruction and single step? I'm not sure that's going to tell us much: the latest development is that Fritz looked at the actual memory contents again, and it is once again trash; _almost_ identical to what was there before: PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144 but with some extra 010000 bits: PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 (It's not clear if this represents a real difference, or if that front panel issue Fritz mentioned caused the contents to be displayed incorrectly.) The exciting thing is that if the latter really is what's in main memory, that '16700 16152' at the PC of the MM trap could indeed generate the MM trap we're seeing: it's "MOV 26364, R0", and that address is in segment (page) 1, which is only 03500 long.... If so, i) we're down to one problem (good news), and our problem turns into finding out how that section of the code got trashed (bad news). Which is not going to be simple, alas, I suspect. I don't think it's the RK11, because Unix reads the program image into system buffers in low memory, and that's clearly working OK in the 'sleep;ls' case. (It may not use the exact same buffers, though...) It then copies it out to the memory where it's going to execute from, using an MTPI loop. So maybe the memory still has issues, or maybe the MTPI isn't working with some main memory locations or or or... Noel From jwest at classiccmp.org Wed Feb 6 13:25:42 2019 From: jwest at classiccmp.org (Jay West) Date: Wed, 6 Feb 2019 13:25:42 -0600 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> Message-ID: <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> Chuck wrote... ---------- The HP disk array rack is a pretty standard 19" EIA rack, with some extra slots for mounting the disk drive slides. Looking at the 7970, without the mounting kit, it's a standard 19" wide. The right side flange has holes for mounting; the left side (the side with the support hinges for the works) has a similar flange, but without holes. Since mounting holes on an 19" rack are 18" apart, I could see where just boring a couple of holes in the hinge-side flange and countersinking them for flathead bolts would work to secure the drive. On the DA cabinet, however, the side "skins" project about an inch forward of the mounting rails, so you'd probably have to remove one to get clearance to open the drive up for servicing. On the other hand, a "naked" rack would probably work just fine. --------- Yes, it's all "standard 19 inch" but..... the HP gear and mounting kits of that time expected certain things to be present in the rack design/construction well beyond just the space between the vertical posts. As I recall, on the left, the flange (where mounting holes are - on the right) does not have mounting holes. And drilling and tapping would be difficult because a 2 inch thick piece of solid metal from the side of the casting covers those. You would only be able to screw them in from the back, and in many racks that wouldn't be possible. Not to mention that part of that solid metal casting cantilevers when the unit is in the service position, so drilling all the way through (or anchoring the casting) is going to disallow getting to stuff you want to get to. And if you can't use the internal access door as-mounted, I'd bet the chance of injury or damage goes up exponentially every time you need to pull it out of the rack so you can get to stuff. There ARE bolt holes for attaching on the left, but they are not on the flange as they are on the right side. They are on the left side of the aluminum housing, about 7 inches back from the front, in a vertical line. You're not going to find a rack that has attach points there, and those are the PRIMARY attach points for the entire left hand side (and they are in aluminum housing, so absolutely depend on the steel bracket on the left for weight support). I'm wondering if connecting the tape unit by using bolts along the outer flanges (assuming they were present on left and right - which they weren't) may not be sufficient given the weight of the unit. That is why the special HP mounting bracket has an L-angle on the bottom, to take much of the weight of the unit. Without it (ie. in a non-(hp-period)standard rack) I wonder if the flanges really aren't designed to hold that kind of weight. So... I'm curious how they were actually mounted on the left in that particular rack. The only method I've ever seen that mostly works is using L-brackets under the unit. But that still doesn't attach the left side. Some may be ok with that I'm sure. I myself have visions of 150# of mostly cast aluminum and steel coming off those L brackets and they would bend the right racksupport severely (or the tape unit) for sure. I'm not at all saying it can't be done and done sufficiently. I'm just curious how :) I've been blessed with the right brackets and racks, so never had to mess with it. And like I said, haven't laid eyes on my 7970s in over a year, so my memory is prolly foggy :) J From jnc at mercury.lcs.mit.edu Wed Feb 6 13:28:39 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Feb 2019 14:28:39 -0500 (EST) Subject: Looking for: 68000 C compilers Message-ID: <20190206192839.C0C7618C07B@mercury.lcs.mit.edu> > From: Phil Pemberton > * Anything not on this list ;) The TRIX project at MIT-LCS did a 68K compiler very early on (soon after the first 68K wa released)x, using Steve Johnson's Portable C Compiler as a base. Noel From jfoust at threedee.com Wed Feb 6 13:22:39 2019 From: jfoust at threedee.com (John Foust) Date: Wed, 06 Feb 2019 13:22:39 -0600 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: <20190206192952.42F194E75F@mx2.ezwind.net> At 12:26 PM 2/6/2019, Ethan Dicks via cctalk wrote: >OTOH, at home, I'd had an Amiga since 1986 and used a variety of >native tools (Lattice C later SAS/C, and various assemblers either >commercial or from a Fish Disk). Somewhere I have the DOS-hosted C compiler for the Amiga that was part of the first developer kits. I think they were Sage-hosted for a while, too. - John From sales at elecplus.com Wed Feb 6 13:45:12 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 6 Feb 2019 13:45:12 -0600 Subject: NIB 1986 phones and used USR modems Message-ID: <04cb01d4be54$79d9bc70$6d8d3550$@com> Pics of equipment on request . Hi, we occasionally get some. For example, we have the following: 2x Phones ROLM 61000 in boxes (see photos) ('86 year of manufacture); Bunch of (see photos): FAX-MODEM USRobotics 33.6K Model 0459 PN: 00083907 FAX-MODEM USRobotics 56K Model 0701 PN: USR5686D FAX-MODEM USRobotics 56K V.92 PN: 5686 Let me know what you think. I'll keep you posted on any antique equipment we will be receiving. Nick Makarovskiy, nick at ictcompany.com Office: +1-781-912-1717 x 710 Direct:+1-781-912-1710 Cell/WhatsApp: +1-617-309-8705 400 Tradecenter, Ste 5900 Woburn MA 01801 Not affiliated with seller, etc. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Wed Feb 6 14:12:44 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 6 Feb 2019 14:12:44 -0600 Subject: Unused Sun keyboard and accessories Message-ID: <04fa01d4be58$52fe3d20$f8fab760$@com> 1 keyboard PN 3201072-01 still in plastic and foam (Type 5) 1 metallic type mousepad, never used 1 mouse 370-1170-01, used 1 cable 530-1594-01 used 1 cable 530-1662-01 new 1 cable 530-1442-02 used 1 battery holder that is plugged into the 530-1594-01, used, no battery installed These are in my stock. All fits in one box. Make offer. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From cclist at sydex.com Wed Feb 6 14:24:43 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 6 Feb 2019 12:24:43 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> Message-ID: On 2/6/19 11:25 AM, Jay West wrote: > Yes, it's all "standard 19 inch" but..... the HP gear and mounting > kits of that time expected certain things to be present in the rack > design/construction well beyond just the space between the vertical > posts. > > As I recall, on the left, the flange (where mounting holes are - on > the right) does not have mounting holes. And drilling and tapping > would be difficult because a 2 inch thick piece of solid metal from > the side of the casting covers those... Okay, here's what I'm talking about. Take a look at PDF page 6 from this document: http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/tape/7970/07970-90383_7970B_7970C_Operating_and_Service_Manual_upd_Feb76/07970-90383_7970B_7970C_Operating_and_Service_Manual_Section_1.pdf This shows very clearly the naked "box" without the transport works. Said box is aluminum, with 1/8" or so thick flanges on each side. Note that the right side has 3 mounting slots (and the transport has 3 "notches" to make room for bolt heads and washers. Now look at the right side of the drive box. Note that the hinges for the transport are secured to a similar flange, but without any mounting holes. I propose that drilling a couple of mounting holes to match rack spacing and countersinking said holes so that they don't interfere with the transport body would do the trick. My rack uses cage nuts on the rails, so there would be no fiddling with nuts and bolts. I'd probably also feel better if the rear of the drive were secured to the rack also, but I haven't worked that one out yet--nor am I likely too, as my current setup works just fine without the danger of hernia. --Chuck From commodorejohn at gmail.com Wed Feb 6 14:46:41 2019 From: commodorejohn at gmail.com (John Ames) Date: Wed, 6 Feb 2019 12:46:41 -0800 Subject: Looking for: 68000 C compilers Message-ID: I know there's an old (I think) official Sega Genesis devkit that's, erm, "around" on various console homebrew sites. No idea which exact C compiler is included, but it's not too difficult to find. From bhilpert at shaw.ca Wed Feb 6 14:54:14 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 12:54:14 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190206185347.00D7E18C07B@mercury.lcs.mit.edu> References: <20190206185347.00D7E18C07B@mercury.lcs.mit.edu> Message-ID: <65A0EDFD-D37B-4EF1-8595-8F24E2E150A2@shaw.ca> On 2019-Feb-06, at 10:53 AM, Noel Chiappa via cctalk wrote: > > I'm not sure that's going to tell us much: the latest development is that > Fritz looked at the actual memory contents again, and it is once again > trash; _almost_ identical to what was there before: > > PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144 > > but with some extra 010000 bits: > > PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 > > (It's not clear if this represents a real difference, or if that > front panel issue Fritz mentioned caused the contents to be displayed > incorrectly.) > > The exciting thing is that if the latter really is what's in main memory, > that '16700 16152' at the PC of the MM trap could indeed generate the MM trap > we're seeing: it's "MOV 26364, R0", and that address is in segment (page) 1, > which is only 03500 long.... > > If so, i) we're down to one problem (good news), and our problem turns into > finding out how that section of the code got trashed (bad news). Which is not > going to be simple, alas, I suspect. I don't think it's the RK11, because > Unix reads the program image into system buffers in low memory, and that's > clearly working OK in the 'sleep;ls' case. (It may not use the exact same > buffers, though...) It then copies it out to the memory where it's going to > execute from, using an MTPI loop. So maybe the memory still has issues, or > maybe the MTPI isn't working with some main memory locations or or or... I haven't followed this in detail enough to know what the configuration and memory board at play are so maybe this can be ruled out from your end, but for consideration, what about the refresh circuitry of the memory board? Mem diagnostics, unless they explicitly account for it, may not show up problems with memory refresh if the loop times are short enough to effectively substitute as refresh cycles, while they could show up later in real-world use with arbitrary time between accesses. Refresh on some early boards/systems was asynchronously timed by monostables or onboard oscillators which can drift or fail on the margin/slope. (I don't know what DEC's design policy was for DRAM refresh). It might also explain why a number of 4116s were (apparently) failing earlier in the efforts (if I recall the discussion correctly), replacing them might have just replaced them with 'slightly better' chips, i.e. with a slightly longer refresh tolerance. From sales at elecplus.com Wed Feb 6 14:57:54 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 6 Feb 2019 14:57:54 -0600 Subject: another dealer going under Message-ID: <052901d4be5e$a2050bf0$e60f23d0$@com> Leslie is preparing a list. She has also contacted another friend who is quitting the biz, to see if they want to get rid of equip. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From goetz at hoffart.de Wed Feb 6 11:44:27 2019 From: goetz at hoffart.de (=?utf-8?Q?G=C3=B6tz_Hoffart?=) Date: Wed, 6 Feb 2019 18:44:27 +0100 Subject: Looking for: 68000 C compilers In-Reply-To: <20190206162144.GA27182@tau1.ceti.pl> References: <20190206162144.GA27182@tau1.ceti.pl> Message-ID: <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> Hi, I could offer Lattice C 3 and 5 for 68k / Atari ST. Regards G?tz ... auf dem Sprung ... > Am 06.02.2019 um 17:21 schrieb Tomasz Rola via cctalk : > >> On Wed, Feb 06, 2019 at 03:08:14PM +0000, Phil Pemberton via cctalk wrote: >> Hi, >> >> I'm (still) trying to reverse-engineer a ton of M68K ROM code which >> was apparently compiled with a circa-1990 C compiler. >> >> Does anyone have copies of any of the following -- or any other C >> compilers for the 68K which were around at that time? > [...] >> >> * Lattice C >> >> * Anything not on this list ;) > > Aztec C, by Manx Software (by now probably defunct). > > The Official Aztec C Online Museum: > > http://www.aztecmuseum.ca/index.htm > > stuff (those guys did a lot of them): > > http://www.aztecmuseum.ca/compilers.htm > > -- > Regards, > Tomasz Rola > > -- > ** A C programmer asked whether computer had Buddha's nature. ** > ** As the answer, master did "rm -rif" on the programmer's home ** > ** directory. And then the C programmer became enlightened... ** > ** ** > ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From tom at figureeightbrewing.com Wed Feb 6 13:45:57 2019 From: tom at figureeightbrewing.com (Tom Uban) Date: Wed, 6 Feb 2019 13:45:57 -0600 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: <9f4b0cd1-3b68-76c0-437d-53f9f2506a2b@figureeightbrewing.com> I have a copy of the source for a set of 68k tools (compiler, assembler, loader, etc) which was based on work done by Chris Terman at MIT. This work was done back in the mid 80s, so some work is likely needed to compile with modern tools. Let me know if you would like a copy. On 2/6/19 10:27 AM, Ethan Dicks via cctalk wrote: > On Wed, Feb 6, 2019 at 9:08 AM Phil Pemberton via cctalk > wrote: >> I'm (still) trying to reverse-engineer a ton of M68K ROM code which was >> apparently compiled with a circa-1990 C compiler. > I used to do a lot of m68k ROM code development c. 1985-1993... > >> Does anyone have copies of any of the following -- or any other C >> compilers for the 68K which were around at that time? >> * Lattice C > Yes. For AmigaDOS... > >> * Anything not on this list ;) > We rolled our own m68k cross assembler that ran on VMS, twice - one > was a very simple, unsophisticated assembler that just took blocks of > code and banged out a monolithic OBJ, and later, a fancier one with > relocatable blocks and multiple sections that produced more of a > "loader format" for linking multiple entities together. I have the > source for these but they are definitely K&R C and may have some file > routines that would have to be lightly massaged out of VMS-isms. > > -ethan > From rtomek at ceti.pl Wed Feb 6 15:13:57 2019 From: rtomek at ceti.pl (Tomasz Rola) Date: Wed, 6 Feb 2019 22:13:57 +0100 Subject: Looking for: 68000 C compilers In-Reply-To: <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> Message-ID: <20190206211357.GB27182@tau1.ceti.pl> On Wed, Feb 06, 2019 at 06:44:27PM +0100, G?tz Hoffart wrote: > Hi, > > I could offer Lattice C 3 and 5 for 68k / Atari ST. > > Regards > G?tz Lattice was the thing, back when I had Amiga. Too bad I could not afford a harddisk :-). BTW, I just recalled the Aminet is still there and seems to be quite active, although I guess activity nowadays mostly revolves around PPC-based models with Workbench 4(++).x(++), but they have /dev section and quite a few compilers in there: http://aminet.net/tree?path=dev After all, who said it was a C compiler? Most probably, it was C compiler, yes. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From jnc at mercury.lcs.mit.edu Wed Feb 6 15:21:42 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Feb 2019 16:21:42 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> > From: Brent Hilpert > what about the refresh circuitry of the memory board? > ... > It might also explain why a number of 4116s were (apparently) failing > earlier in the efforts ... replacing them might have just replaced them > with 'slightly better' chips, i.e. with a slightly longer refresh tolerance. Ooh, excellent idea! Noel From rtomek at ceti.pl Wed Feb 6 15:23:24 2019 From: rtomek at ceti.pl (Tomasz Rola) Date: Wed, 6 Feb 2019 22:23:24 +0100 Subject: Looking for: 68000 C compilers In-Reply-To: <20190206211357.GB27182@tau1.ceti.pl> References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> <20190206211357.GB27182@tau1.ceti.pl> Message-ID: <20190206212324.GC27182@tau1.ceti.pl> On Wed, Feb 06, 2019 at 10:13:57PM +0100, Tomasz Rola via cctalk wrote: [...] > quite a few compilers in there: > > http://aminet.net/tree?path=dev And on page 1 of 5 in /dev/asm section I have spotted at least two disassemblers, there might be more. Caution: never used any. http://aminet.net/dev/asm ADisV1_3.lha - 'Intelligent' Disassembler (incl.source) Bin2Asm.lha - Binary to assembler source converter etc. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From cclist at sydex.com Wed Feb 6 15:47:24 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 6 Feb 2019 13:47:24 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: <20190206212324.GC27182@tau1.ceti.pl> References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> <20190206211357.GB27182@tau1.ceti.pl> <20190206212324.GC27182@tau1.ceti.pl> Message-ID: <1197a155-4339-3744-00cf-06240d297d60@sydex.com> On 2/6/19 1:23 PM, Tomasz Rola via cctalk wrote: > On Wed, Feb 06, 2019 at 10:13:57PM +0100, Tomasz Rola via cctalk > wrote: [...] >> quite a few compilers in there: >> >> http://aminet.net/tree?path=dev > > And on page 1 of 5 in /dev/asm section I have spotted at least two > disassemblers, there might be more. Caution: never used any. > > http://aminet.net/dev/asm > > ADisV1_3.lha - 'Intelligent' Disassembler (incl.source) Bin2Asm.lha - > Binary to assembler source converter I used Mark WIlliams C on the Atari ST. --Chuck From sales at elecplus.com Wed Feb 6 16:00:36 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 6 Feb 2019 16:00:36 -0600 Subject: Unused Sun keybaord and accessories Message-ID: <059301d4be67$6468b680$2d3a2380$@com> This keyboard has now been sold! Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From rdawson16 at hotmail.com Wed Feb 6 16:21:36 2019 From: rdawson16 at hotmail.com (Randy Dawson) Date: Wed, 6 Feb 2019 22:21:36 +0000 Subject: Another dealer going under In-Reply-To: <00c701d4be3e$64feffb0$2efcff10$@net> References: <015f01d4bd95$09bdafb0$1d390f10$@com> <005101d4bd95$52f7b810$f8e72830$@net> <030001d4be3c$e0688b50$a139a1f0$@com>,<00c701d4be3e$64feffb0$2efcff10$@net> Message-ID: I an next door, give us the address please... Thanks, Randy ________________________________ From: cctalk on behalf of Ali via cctalk Sent: Wednesday, February 6, 2019 9:07 AM To: 'General Discussion: On-Topic and Off-Topic Posts' Cc: 'Electronics Plus' Subject: RE: Another dealer going under > Calabasas, CA Well for a change it is someone just next door so I can definitely take a look. I wonder if they have anything available. Do you have contact info/address? -Ali > > -----Original Message----- > From: Ali [mailto:cctalk at ibm51xx.net] > Sent: Tuesday, February 05, 2019 2:57 PM > To: 'Electronics Plus'; 'General Discussion: On-Topic and Off-Topic > Posts' > Subject: RE: Another dealer going under > > > > I don't get replies from here yet, so I have seen no replies to my > > posts, > > nor the posts themselves. > > > > There is a shop that has been in biz for over 25 years that is > closing > > in > > California. > > > > Cindy, > > Where in CA? It's a big state :) > > -Ali From bhilpert at shaw.ca Wed Feb 6 16:24:41 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 14:24:41 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> Message-ID: <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> On 2019-Feb-06, at 1:21 PM, Noel Chiappa via cctalk wrote: >> From: Brent Hilpert > >> what about the refresh circuitry of the memory board? >> ... >> It might also explain why a number of 4116s were (apparently) failing >> earlier in the efforts ... replacing them might have just replaced them >> with 'slightly better' chips, i.e. with a slightly longer refresh tolerance. > > Ooh, excellent idea! Is the schematic available for the memory board at-issue? Curious myself to see what approach for refresh DEC used. From bhilpert at shaw.ca Wed Feb 6 16:29:00 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 14:29:00 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> Message-ID: <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> On 2019-Feb-06, at 12:24 PM, Chuck Guzis via cctalk wrote: > On 2/6/19 11:25 AM, Jay West wrote: > >> Yes, it's all "standard 19 inch" but..... the HP gear and mounting >> kits of that time expected certain things to be present in the rack >> design/construction well beyond just the space between the vertical >> posts. >> >> As I recall, on the left, the flange (where mounting holes are - on >> the right) does not have mounting holes. And drilling and tapping >> would be difficult because a 2 inch thick piece of solid metal from >> the side of the casting covers those... > > Okay, here's what I'm talking about. Take a look at PDF page 6 from > this document: > > http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/tape/7970/07970-90383_7970B_7970C_Operating_and_Service_Manual_upd_Feb76/07970-90383_7970B_7970C_Operating_and_Service_Manual_Section_1.pdf > > This shows very clearly the naked "box" without the transport works. > Said box is aluminum, with 1/8" or so thick flanges on each side. > > Note that the right side has 3 mounting slots (and the transport has 3 > "notches" to make room for bolt heads and washers. > > Now look at the right side of the drive box. (I take it you mean "now look at the -left- side".) If you drill holes in the left-side flange for rack mounting, you have to be able to access them at mount time, which is not possible with the drive fully assembled. However, looking at my 7970A, it appears you could separate the cast-Al transport frame from the chassis box by unscrewing the 4 exterior left-side hinge screws, as well as detaching all the cabling between them involving a wire harness and a dozen-or-so plugs. This would have the benefit of splitting up the weight involved in the mounting process. Holding the transport frame and aligning it with the hinges during reattachment while trying to get the screws in place might nonetheless require two people. In a slightly-alternate design, HP might have made the left-side bezel over the manual controls removable, giving access to the left-side flange without detaching the transport frame, but that would also require a slight modification to the casting near the screw holes for clearance for the screws. For loading concerns raised by Jay, in both cases (designed-for steel bracket vs drilled flange) the weight of the drive ends up being borne by 4 rack-screws on the left and 3 on the right. The difference would be steel vs Al bearing down on the 4 screws on the left, and some altered bending moments on the left side of the Al chassis box around the flange, offhand I wouldn't think it would matter. > Note that the hinges for > the transport are secured to a similar flange, but without any mounting > holes. I propose that drilling a couple of mounting holes to match > rack spacing and countersinking said holes so that they don't interfere > with the transport body would do the trick. My rack uses cage nuts on > the rails, so there would be no fiddling with nuts and bolts. I'd > probably also feel better if the rear of the drive were secured to the > rack also, but I haven't worked that one out yet--nor am I likely too, > as my current setup works just fine without the danger of hernia. From fritzm at fritzm.org Wed Feb 6 17:39:03 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 6 Feb 2019 15:39:03 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> Message-ID: <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> > On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk wrote: > > Is the schematic available for the memory board at-issue? > Curious myself to see what approach for refresh DEC used. Yes, here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf There is also a technical manual adjacent, with circuit descriptions. I will scope this up tonight and take a look! --FritzM. From flash688 at flying-disk.com Wed Feb 6 17:43:38 2019 From: flash688 at flying-disk.com (Alan Frisbie) Date: Wed, 06 Feb 2019 15:43:38 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: References: Message-ID: <5C5B712A.5020806@flying-disk.com> Jack Harper wrote: > I got both drives into the rack this past weekend and I am an old guy > (67) - I carefully stared at the thing before I started and finally > figured out that I could, in fact, lift the drive from a waist high > cart for a few seconds, but definitely could not lift it or lower it > vertically with my arms - no way - and I would have one shot at > getting the drives into the rack on the rails. Harbor Freight sells a nice hydraulic lift table for under $200 that I have found very useful for that sort of thing. It doesn't go up very high (like for the top of a rack), but I used it with some wood blocks to lift a DEC ES45 Alpha system into a rack by myself. 500 pound capacity, 28.5" lift height, $170 https://www.harborfreight.com/500-lbs-capacity-hydraulic-table-cart-61405.html 1000 pound capacity, 34.5" lift height, $260 https://www.harborfreight.com/1000-lbs-capacity-hydraulic-table-cart-69148.html Alan Frisbie From cclist at sydex.com Wed Feb 6 18:19:55 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 6 Feb 2019 16:19:55 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> Message-ID: <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> On 2/6/19 2:29 PM, Brent Hilpert via cctalk wrote: > (I take it you mean "now look at the -left- side".) Well, you know, my *other* right... :) > However, looking at my 7970A, it appears you could separate the cast-Al transport frame from the chassis box > by unscrewing the 4 exterior left-side hinge screws, as well as detaching all the cabling between them involving > a wire harness and a dozen-or-so plugs. Swing the drive assembly out from the back cover--you'll note that the pivot points on the two hinges are about 1" away from the cover flange. You've got plenty of room to drill your mounting holes from the *rear* of that flange. You might even have enough clearance for a countersink--but that may not be necessary--the frame casting only extends in from the left about a half-inch--you may even clear some oval-headed screws or get away with some truss-head screws. Alternatively, could mill a slight relief in the casting to clear the heads. I think it's doable without removing the drive from the cover. > For loading concerns raised by Jay, in both cases (designed-for steel > bracket vs drilled flange) the weight of the drive ends up being > borne by 4 rack-screws on the left and 3 on the right. The difference > would be steel vs Al bearing down on the 4 screws on the left, and > some altered bending moments on the left side of the Al chassis box > around the flange, offhand I wouldn't think it would matter. I tend to agree--the force is mostly downward on the front of the drive. I suppose that you could reinforce the aluminum housing with some steel bar backing up the mounting flanges, but that seems like overkill to me. --Chuck From fritzm at fritzm.org Wed Feb 6 19:11:05 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 6 Feb 2019 17:11:05 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> Message-ID: >> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk wrote: >> >> Is the schematic available for the memory board at-issue? >> Curious myself to see what approach for refresh DEC used. > > Yes, here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf For completeness, from the technical manual: "The refresh logic, shown in sheet 6 of the print set, generates REF CLK H and the refresh address. Sig- nal REF CLK H is derived from a 555 timer (E5) which is set up as a free running oscillator, powered by the + IS V / + 12 V module input (V-555). The REF CLK H signal oscillates with a period of 14.5us and has a positive pulse width of 6us during each period." From bhilpert at shaw.ca Wed Feb 6 19:25:51 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 17:25:51 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> Message-ID: <33F2721B-B10A-435C-9596-1C216D08A185@shaw.ca> On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote: >>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk wrote: >>> >>> Is the schematic available for the memory board at-issue? >>> Curious myself to see what approach for refresh DEC used. >> >> Yes, here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf > > For completeness, from the technical manual: > > "The refresh logic, shown in sheet 6 of the print set, generates REF CLK H and the refresh address. Sig- nal REF CLK H is derived from a 555 timer (E5) which is set up as a free running oscillator, powered by the + IS V / + 12 V module input (V-555). The REF CLK H signal oscillates with a period of 14.5us and has a positive pulse width of 6us during each period." So I could have saved myself some fun if I had read the manual rather than just looking at the schematic. Not that they're way out of whack, but the mild disparity between the manual's 14.5uS and my calculated 11.7uS is curious (the calculation being based on the schematic RC values and the 555 equations). From paulkoning at comcast.net Wed Feb 6 19:29:29 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 6 Feb 2019 20:29:29 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <33F2721B-B10A-435C-9596-1C216D08A185@shaw.ca> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> <33F2721B-B10A-435C-9596-1C216D08A185@shaw.ca> Message-ID: > On Feb 6, 2019, at 8:25 PM, Brent Hilpert via cctalk wrote: > > On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote: >>>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk wrote: >>>> >>>> Is the schematic available for the memory board at-issue? >>>> Curious myself to see what approach for refresh DEC used. >>> >>> Yes, here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf >> >> For completeness, from the technical manual: >> >> "The refresh logic, shown in sheet 6 of the print set, generates REF CLK H and the refresh address. Sig- nal REF CLK H is derived from a 555 timer (E5) which is set up as a free running oscillator, powered by the + IS V / + 12 V module input (V-555). The REF CLK H signal oscillates with a period of 14.5us and has a positive pulse width of 6us during each period." > > So I could have saved myself some fun if I had read the manual rather than just looking at the schematic. > Not that they're way out of whack, but the mild disparity between the manual's 14.5uS and my calculated 11.7uS is curious > (the calculation being based on the schematic RC values and the 555 equations). Perhaps the period was changed in a schematic rev or ECO, and the manual wasn't updated to reflect it. It would be interesting to check the data sheet for the RAM chip to see what it likes for refresh cycle. And given that this is an RC oscillator your theory about out of tolerance timing definitely deserves checking. paul From bhilpert at shaw.ca Wed Feb 6 19:34:29 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 17:34:29 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> Message-ID: On 2019-Feb-06, at 3:39 PM, Fritz Mueller wrote: >> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk wrote: >> >> Is the schematic available for the memory board at-issue? >> Curious myself to see what approach for refresh DEC used. > > Yes, here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf > > There is also a technical manual adjacent, with circuit descriptions. > > I will scope this up tonight and take a look! Mixed up To: fields. The following was intended to go to the list and was originally sent a moment before I saw Fritz's message mentioning the 555: Ha!, simple free-running 555 oscillator generating the refresh cycles (pdf.pg27). I suspect there is a mistake in the schematic there: V-555 more likely connects on the other side of R4 (E5.4-C1-R4, rather than E5.7-R4-R5) to make it into the standard 555 astable circuit. Based on that, calculations indicate that the output from E5 (TP18) should be around 85 KHz, cycling 6.4 uS high, 5.3 uS low. So it's generating a refresh cycle every 11.8 uS. With 7 bits used from counter E43 (128 rows) for full refresh, that's a cell refresh every 1.5mS which (without having checked the 4116 specs) sounds sensible for a DRAM from that period. Note the 555 (E5) is running on +12 or +15V, with a R voltage divider on the output before driving into TTL. From bhilpert at shaw.ca Wed Feb 6 19:59:48 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 17:59:48 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> <33F2721B-B10A-435C-9596-1C216D08A185@shaw.ca> Message-ID: <6FA1D0C8-E6BC-4EA2-A64A-09C8783993F0@shaw.ca> On 2019-Feb-06, at 5:29 PM, Paul Koning wrote: >> On Feb 6, 2019, at 8:25 PM, Brent Hilpert via cctalk wrote: >> On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote: >>>>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk wrote: >>>>> >>>>> Is the schematic available for the memory board at-issue? >>>>> Curious myself to see what approach for refresh DEC used. >>>> >>>> Yes, here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf >>> >>> For completeness, from the technical manual: >>> >>> "The refresh logic, shown in sheet 6 of the print set, generates REF CLK H and the refresh address. Sig- nal REF CLK H is derived from a 555 timer (E5) which is set up as a free running oscillator, powered by the + IS V / + 12 V module input (V-555). The REF CLK H signal oscillates with a period of 14.5us and has a positive pulse width of 6us during each period." >> >> So I could have saved myself some fun if I had read the manual rather than just looking at the schematic. >> Not that they're way out of whack, but the mild disparity between the manual's 14.5uS and my calculated 11.7uS is curious >> (the calculation being based on the schematic RC values and the 555 equations). > > Perhaps the period was changed in a schematic rev or ECO, and the manual wasn't updated to reflect it. It would be interesting to check the data sheet for the RAM chip to see what it likes for refresh cycle. And given that this is an RC oscillator your theory about out of tolerance timing definitely deserves checking. Checking further.. 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 14.5uS from the manual would give 1.86 mS, 7% shy of 2. The schematic specs 1% resistors, and the parts list does appear to spec a high-tolerance "1%200PPM" cap. Although there are the internal voltage divider Rs in the 555 which are also critical for the timing and everything is 40+ years old. Idle speculation at my distance, we'll see what Fritz observes. Could be other problems in the refresh circuitry too, like failed outputs from the row counter, etc. From elson at pico-systems.com Wed Feb 6 20:25:20 2019 From: elson at pico-systems.com (Jon Elson) Date: Wed, 06 Feb 2019 20:25:20 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190206185347.00D7E18C07B@mercury.lcs.mit.edu> References: <20190206185347.00D7E18C07B@mercury.lcs.mit.edu> Message-ID: <5C5B9710.40405@pico-systems.com> On 02/06/2019 12:53 PM, Noel Chiappa via cctalk wrote: > > > If so, i) we're down to one problem (good news), and our problem turns into > finding out how that section of the code got trashed (bad news). I'm thinking it is bad memory. It seems unlikely bus problems could alter only ONE BIT per word, so I think it is just a bad memory chip, and finding multiple words where the 010000 bit is now turned on sure looks like that kind of problem. It could, of course, be a bad driver or receiver on the memory board. Might also check the other voltage in the memory array (+12 or whatever was used internally in the particular memory) and also look for degraded caps on the board. Jon From elson at pico-systems.com Wed Feb 6 20:29:30 2019 From: elson at pico-systems.com (Jon Elson) Date: Wed, 06 Feb 2019 20:29:30 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> Message-ID: <5C5B980A.6000208@pico-systems.com> On 02/06/2019 04:24 PM, Brent Hilpert via cctalk wrote: > On 2019-Feb-06, at 1:21 PM, Noel Chiappa via cctalk wrote: >>> From: Brent Hilpert >>> what about the refresh circuitry of the memory board? >>> ... >>> It might also explain why a number of 4116s were (apparently) failing >>> earlier in the efforts ... replacing them might have just replaced them >>> with 'slightly better' chips, i.e. with a slightly longer refresh tolerance. >> Ooh, excellent idea! > > Is the schematic available for the memory board at-issue? > Curious myself to see what approach for refresh DEC used. > > Hmm, yes, if the refresh is done by one-shots and RC timing, a failed cap could silently kill the refresh trigger. An easy way to check is put something in a few locations and halt the CPU for some time (seconds to minutes). If the content is now gone, then the refresh is very likely not being done. Jon From elson at pico-systems.com Wed Feb 6 20:32:30 2019 From: elson at pico-systems.com (Jon Elson) Date: Wed, 06 Feb 2019 20:32:30 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> Message-ID: <5C5B98BE.6070407@pico-systems.com> On 02/06/2019 05:39 PM, Fritz Mueller via cctalk wrote: >> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk wrote: >> >> Is the schematic available for the memory board at-issue? >> Curious myself to see what approach for refresh DEC used. > Yes, here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf > > There is also a technical manual adjacent, with circuit descriptions. > > I will scope this up tonight and take a look! Yup, page 6, a 555 RC refresh timer! Jon From bhilpert at shaw.ca Wed Feb 6 20:33:57 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 18:33:57 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> Message-ID: <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> On 2019-Feb-06, at 4:19 PM, Chuck Guzis via cctalk wrote: > On 2/6/19 2:29 PM, Brent Hilpert via cctalk wrote: > >> (I take it you mean "now look at the -left- side".) > > Well, you know, my *other* right... :) > >> However, looking at my 7970A, it appears you could separate the cast-Al transport frame from the chassis box >> by unscrewing the 4 exterior left-side hinge screws, as well as detaching all the cabling between them involving >> a wire harness and a dozen-or-so plugs. > > Swing the drive assembly out from the back cover--you'll note that the > pivot points on the two hinges are about 1" away from the cover flange. > You've got plenty of room to drill your mounting holes from the *rear* > of that flange. You might even have enough clearance for a > countersink--but that may not be necessary--the frame casting only > extends in from the left about a half-inch--you may even clear some > oval-headed screws or get away with some truss-head screws. > Alternatively, could mill a slight relief in the casting to clear the heads. > > I think it's doable without removing the drive from the cover. Granted you could drill the holes from the rear of the flange, however from what I can see the hinge design doesn't look like it will allow the transport frame to swing far enough to clear access for the screwdriver shaft to tighten the screws from the front (might swing to around 110deg, but not to 170-180). The 2-1/2" thick transport frame pivots near the middle of it's thickness, at 90deg half the thickness is still well across the flange. You'd need a ~ < 1" clearance right angle screwdriver to fit between the flange and the transport frame, or bolt head screws and box wrench which then necessitates the milling of clearance for the heads out of the cast frame. I might consider the transport removal approach next time I have to mount mine - even though I have the proper mounting bracket - just to split the weight up. I did once do a one-person free-lift mount of the thing, but that was about 20 years ago. >> For loading concerns raised by Jay, in both cases (designed-for steel >> bracket vs drilled flange) the weight of the drive ends up being >> borne by 4 rack-screws on the left and 3 on the right. The difference >> would be steel vs Al bearing down on the 4 screws on the left, and >> some altered bending moments on the left side of the Al chassis box >> around the flange, offhand I wouldn't think it would matter. > > I tend to agree--the force is mostly downward on the front of the drive. > I suppose that you could reinforce the aluminum housing with some steel > bar backing up the mounting flanges, but that seems like overkill to me. From fritzm at fritzm.org Wed Feb 6 20:55:45 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 6 Feb 2019 18:55:45 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <5C5B9710.40405@pico-systems.com> References: <20190206185347.00D7E18C07B@mercury.lcs.mit.edu> <5C5B9710.40405@pico-systems.com> Message-ID: <0ded722e-ca4e-b6aa-391d-03e9f870c928@fritzm.org> On 2/6/19 6:25 PM, Jon Elson via cctalk wrote: > I'm thinking it is bad memory.? It seems unlikely bus problems could > alter only ONE BIT per word, so I think it is just a bad memory chip, > and finding multiple words where the 010000 bit is now turned on sure > looks like that kind of problem. So, there was an issue specifically relating to bit 12 on the front panel (d'oh!), which I have now cleared up. Furthermore, the "authoritative" sequence of 16 words obtained from the front panel last night, after addressing this issue, is: PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 PA:171620: 004767 000206 000405 012404 012467 016124 000167 177346 ...and, as it turns out, this exact sequence also occurs within the ls binary, on disk (per "od"): 0004220 016162 004767 000224 000414 016700 016152 016702 016144 0004240 004767 000206 000405 012404 012467 016124 000167 177346 So, the memory there _seems_ fine with the latest info at our disposal. It looks like the question boils down to either "how did that part of the binary get to that part of memory?", or "how did we end up executing out of that part of memory?" Could still be a memory issue _elsewhere_ that lands us there, of course... Could also be a translation error lurking in the KT11, or a CPU bug not found by any of the DEC diagnostic suites. I will scope the refresh clock when I get home tonight, and I'm planning on hauling out the logic analyzer for an IR trace this weekend... --FritzM. P.S. One idea that popped into my head recently, after a suggestion here to check the KT11 address translation adders, and my response "but the diagnostics!"... A bug in one of the carry lookahead generators used between the bit slices of that adder could cause a mistranslation on only a fairly selective subset of virtual addresses, and this might conceivably be missed by the KT11 diagnostics? *IF* that's the case and we can chase the IR trace upstream to the place of an unlucky mistranslation, it will be pretty easy to track down then in the hw and fix. From jnc at mercury.lcs.mit.edu Wed Feb 6 21:11:29 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Feb 2019 22:11:29 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190207031129.87F1C18C077@mercury.lcs.mit.edu> > From: Jon Elson > I'm thinking it is bad memory. ... I think it is just a bad memory chip Nothing so simple, I'm afraid! The memory actually contains: PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 and it's _supposed_ to be holding: PA:171600: 110024 010400 000167 000016 010500 010605 010446 010346 This together with Fritz's discovery of that first 'bad memory' pattern _elsewhere_ in the binary for the command makes it look pretty likely that some sort of other error has wound up with stuff being put in the wrong location. Noel From pat at vax11.net Wed Feb 6 21:25:47 2019 From: pat at vax11.net (Patrick Finnegan) Date: Wed, 6 Feb 2019 22:25:47 -0500 Subject: GSX-80 software Message-ID: I'm wondering if anyone knows of any CP/M software using GSX-80, which could be an interesting demo, or game. I have found Kasekastchen ( http://atariage.com/forums/topic/244781-kaesekaestchen-a-new-gsx-based-game-for-pcw-cpc-and-other-cpm-machines/) (misspelled without accents to make the mailman happy), but it mostly just freezes after loading GSX-80 on my TS-803 so far (under the 'remote processor' version of the OS at least). Thanks, Pat From jnc at mercury.lcs.mit.edu Wed Feb 6 21:27:50 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Feb 2019 22:27:50 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190207032750.A8A8118C077@mercury.lcs.mit.edu> > From: Fritz Mueller > It looks like the question boils down to either "how did that part of > the binary get to that part of memory?", or "how did we end up > executing out of that part of memory?" More the former, I think. UISA0 contains 001614, and physical memory at 0161400 does contain the first few instructions of the command's binary, so that 01614 is probably correct for the base address of segment (page) 0, which contains all the code for the command. (Without looking through the OS's guts, I can't confirm, from interal data structures, that that's where it decided to put the command's binary.) The PC at fault time is 010210, which is correct for the frame setup function, CSV; and looking at the contents of the stack, registers etc makes it pretty certain it had just done the "JSR R5, CSV" to get there. And 0161400 + 010210 = 0171610, which contains something completely different from what's in the command binary at 010210! > Could still be a memory issue _elsewhere_ that lands us there, of > course... Could also be a translation error lurking in the KT11, or a > CPU bug not found by any of the DEC diagnostic suites. Yup. Like I said, good news is we're down to one problem; bad news is it's a Duesie! Noel From fritzm at fritzm.org Wed Feb 6 21:35:11 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 6 Feb 2019 19:35:11 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190207032750.A8A8118C077@mercury.lcs.mit.edu> References: <20190207032750.A8A8118C077@mercury.lcs.mit.edu> Message-ID: >> It looks like the question boils down to either "how did that part of >> the binary get to that part of memory?", or "how did we end up >> executing out of that part of memory?" > > More the former, I think... Noel, is it possible for you deduce where Unix _should_ be placing these "bad" bits (from file offset octal 4220)? Maybe a comparison of addresses where the bits should be, with addresses where the "bad" copy ends up, could point us at some particular failure modes to check in the KT11, CPU, or RK11... --FritzM. From cclist at sydex.com Wed Feb 6 21:48:03 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 6 Feb 2019 19:48:03 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> Message-ID: On 2/6/19 6:33 PM, Brent Hilpert via cctalk wrote: > Granted you could drill the holes from the rear of the flange, > however from what I can see the hinge design doesn't look like it > will allow the transport frame to swing far enough to clear access > for the screwdriver shaft to tighten the screws from the front (might > swing to around 110deg, but not to 170-180). The 2-1/2" thick > transport frame pivots near the middle of it's thickness, at 90deg > half the thickness is still well across the flange. You'd need a ~ < > 1" clearance right angle screwdriver to fit between the flange and > the transport frame, or bolt head screws and box wrench which then > necessitates the milling of clearance for the heads out of the cast > frame. Nah, there's plenty of room to get a screwdriver in there. I've had much tighter spots. --Chuck From fritzm at fritzm.org Thu Feb 7 00:37:54 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 6 Feb 2019 22:37:54 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <6FA1D0C8-E6BC-4EA2-A64A-09C8783993F0@shaw.ca> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> <33F2721B-B10A-435C-9596-1C216D08A185@shaw.ca> <6FA1D0C8-E6BC-4EA2-A64A-09C8783993F0@shaw.ca> Message-ID: > 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 14.5uS from the manual would give 1.86 mS, 7% shy of 2. > The schematic specs 1% resistors, and the parts list does appear to spec a high-tolerance "1%200PPM" cap. > > Although there are the internal voltage divider Rs in the 555 which are also critical for the timing and everything is 40+ years old. > > Idle speculation at my distance, we'll see what Fritz observes. Brent: 11.8us, 6.4us position Manual: 14.5us, 6.0us positive Actual: 15.2us, 8.5us positive So yeah, a little pokey there... From bhilpert at shaw.ca Thu Feb 7 00:42:27 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 22:42:27 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> Message-ID: <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> On 2019-Feb-06, at 7:48 PM, Chuck Guzis via cctalk wrote: > On 2/6/19 6:33 PM, Brent Hilpert via cctalk wrote: > >> Granted you could drill the holes from the rear of the flange, >> however from what I can see the hinge design doesn't look like it >> will allow the transport frame to swing far enough to clear access >> for the screwdriver shaft to tighten the screws from the front (might >> swing to around 110deg, but not to 170-180). The 2-1/2" thick >> transport frame pivots near the middle of it's thickness, at 90deg >> half the thickness is still well across the flange. You'd need a ~ < >> 1" clearance right angle screwdriver to fit between the flange and >> the transport frame, or bolt head screws and box wrench which then >> necessitates the milling of clearance for the heads out of the cast >> frame. > > > Nah, there's plenty of room to get a screwdriver in there. I've had > much tighter spots. Well, maybe they changed the hinge design slightly for the model you're looking at. Here are some pics of the 7970A with the transport open at 90 deg: http://madrona.ca/tmp/HP7970A/hingeTop.jpg http://madrona.ca/tmp/HP7970A/hingeInt.jpg http://madrona.ca/tmp/HP7970A/hingeExt.jpg That's about 1-1/4" between the flange and the cast frame. There's no way you're angling a regular shafted screwdriver in there to adequately tighten screws. One could undo the catch that limits the angle of swing, but I still don't expect it's going to swing far enough to get the frame out of the way, let alone the PCBs and motors still in the way. (The black part next to the Al flange is the 'proper' steel mounting bracket.) Flat-head hex bolts with a shortened allen-key could do it, as long as the tensional strength of the screw-heads was adequate. From bhilpert at shaw.ca Thu Feb 7 01:06:53 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Wed, 6 Feb 2019 23:06:53 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> <33F2721B-B10A-435C-9596-1C216D08A185@shaw.ca> <6FA1D0C8-E6BC-4EA2-A64A-09C8783993F0@shaw.ca> Message-ID: <3E42AB16-8D59-4235-8890-1E9F11762040@shaw.ca> On 2019-Feb-06, at 10:37 PM, Fritz Mueller via cctalk wrote: >> 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 14.5uS from the manual would give 1.86 mS, 7% shy of 2. >> The schematic specs 1% resistors, and the parts list does appear to spec a high-tolerance "1%200PPM" cap. >> >> Although there are the internal voltage divider Rs in the 555 which are also critical for the timing and everything is 40+ years old. >> >> Idle speculation at my distance, we'll see what Fritz observes. > > Brent: 11.8us, 6.4us position > Manual: 14.5us, 6.0us positive > Actual: 15.2us, 8.5us positive > > So yeah, a little pokey there... 15.2uS gives a 1.95mS refresh, so it's awfully close to the 2mS spec, but still within. The datasheet I was looking at doesn't seem to give any spec for tolerance on the refresh so one would guess there's a safety margin built into the 2mS spec. Seems a little less-likely to be the problem, given(?) as well that you have fairly consistent (is deterministic overstating it?) behaviour. If you wanted to test it by experiment, without having to remove the installed Rs, you could test-clip another R in parallel with the 38.4K, probably something around 200K, to shorten the 555 period. From fritzm at fritzm.org Thu Feb 7 01:18:02 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 6 Feb 2019 23:18:02 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <3E42AB16-8D59-4235-8890-1E9F11762040@shaw.ca> References: <20190206212142.5F02D18C07B@mercury.lcs.mit.edu> <62F9B65B-06A0-4BB0-B562-841AEECEB382@shaw.ca> <8BA3B078-8EE0-4E42-9211-3321F92803FA@fritzm.org> <33F2721B-B10A-435C-9596-1C216D08A185@shaw.ca> <6FA1D0C8-E6BC-4EA2-A64A-09C8783993F0@shaw.ca> <3E42AB16-8D59-4235-8890-1E9F11762040@shaw.ca> Message-ID: <2FED3E8A-6D94-4E58-BB1E-5D90A0DDAAA4@fritzm.org> > Seems a little less-likely to be the problem, given(?) as well that you have fairly consistent (is deterministic overstating it?) behaviour. Yeah. We've gotten to the point now where enough layered problems have been cleared away that the remaining behavior is quite deterministic. > If you wanted to test it by experiment, without having to remove the installed Rs, you could test-clip another R in parallel with the 38.4K, probably something around 200K, to shorten the 555 period. Yes; and I think a quick solder tack for that would even be easier to manage than clips in there. Will give that a go this weekend. cheers, --FritzM. From cclist at sydex.com Thu Feb 7 01:18:10 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 6 Feb 2019 23:18:10 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> Message-ID: <1e90127b-0226-c11a-ce5f-cd62820c7593@sydex.com> On 2/6/19 10:42 PM, Brent Hilpert via cctalk wrote: > Well, maybe they changed the hinge design slightly for the model you're looking at. > Here are some pics of the 7970A with the transport open at 90 deg: > http://madrona.ca/tmp/HP7970A/hingeTop.jpg > http://madrona.ca/tmp/HP7970A/hingeInt.jpg > http://madrona.ca/tmp/HP7970A/hingeExt.jpg > > That's about 1-1/4" between the flange and the cast frame. > There's no way you're angling a regular shafted screwdriver in there to adequately tighten screws. > One could undo the catch that limits the angle of swing, but I still don't expect it's going to swing far > enough to get the frame out of the way, let alone the PCBs and motors still in the way. > > (The black part next to the Al flange is the 'proper' steel mounting bracket.) > > Flat-head hex bolts with a shortened allen-key could do it, as long as the tensional strength of the screw-heads was adequate. Looking at it, it may be easier to do with a regular screwdriver if the drive is opened at 45 degrees rather than 90. Ratchet right-angle screwdrivers are also an option, as are ball-end allen wrenches or offset-head screwdrivers. None are particularly dear. In any case, as I've said, I'm not about to hoist my 7970 into a rack. I lost enough skin just getting it out of the truck into the shop. I may, however, go prowling for a lowboy EIA rack... --Chuck From classiccmp at philpem.me.uk Thu Feb 7 03:49:44 2019 From: classiccmp at philpem.me.uk (Phil Pemberton) Date: Thu, 7 Feb 2019 09:49:44 +0000 (GMT) Subject: Looking for: 68000 C compilers In-Reply-To: <20190206162144.GA27182@tau1.ceti.pl> References: <20190206162144.GA27182@tau1.ceti.pl> Message-ID: On Wed, 6 Feb 2019, Tomasz Rola wrote: > On Wed, Feb 06, 2019 at 03:08:14PM +0000, Phil Pemberton via cctalk wrote: >> Hi, >> >> I'm (still) trying to reverse-engineer a ton of M68K ROM code which >> was apparently compiled with a circa-1990 C compiler. >> >> Does anyone have copies of any of the following -- or any other C >> compilers for the 68K which were around at that time? > [...] >> >> * Lattice C >> >> * Anything not on this list ;) > > Aztec C, by Manx Software (by now probably defunct). > > The Official Aztec C Online Museum: > > http://www.aztecmuseum.ca/index.htm > > stuff (those guys did a lot of them): > > http://www.aztecmuseum.ca/compilers.htm Hi Tomasz, Thanks for the link to Aztec -- I'm well aware of it, and it's on my list of compilers to examine more closely :) It certainly meets the criteria of time, platform and so on. Thanks, -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/ From philpem at philpem.me.uk Thu Feb 7 06:21:59 2019 From: philpem at philpem.me.uk (Phil Pemberton) Date: Thu, 7 Feb 2019 12:21:59 +0000 (GMT) Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: On Wed, 6 Feb 2019, John Ames wrote: > I know there's an old (I think) official Sega Genesis devkit that's, > erm, "around" on various console homebrew sites. No idea which exact C > compiler is included, but it's not too difficult to find. Thanks for that, John - I think I've just found the devkit in question... Apparently they called it "Sega Channel". It's the Sierra 68K C compiler. -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/ From bill.gunshannon at hotmail.com Thu Feb 7 07:45:23 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Thu, 7 Feb 2019 13:45:23 +0000 Subject: Looking for: 68000 C compilers In-Reply-To: References: <20190206162144.GA27182@tau1.ceti.pl> Message-ID: On 2/7/19 4:49 AM, Phil Pemberton via cctalk wrote: > On Wed, 6 Feb 2019, Tomasz Rola wrote: > >> On Wed, Feb 06, 2019 at 03:08:14PM +0000, Phil Pemberton via cctalk >> wrote: >>> Hi, >>> >>> I'm (still) trying to reverse-engineer a ton of M68K ROM code which >>> was apparently compiled with a circa-1990 C compiler. >>> >>> Does anyone have copies of any of the following -- or any other C >>> compilers for the 68K which were around at that time? >> [...] >>> >>> ? * Lattice C >>> >>> ? * Anything not on this list ;) >> >> Aztec C, by Manx Software (by now probably defunct). >> >> The Official Aztec C Online Museum: >> >> http://www.aztecmuseum.ca/index.htm >> >> stuff (those guys did a lot of them): >> >> http://www.aztecmuseum.ca/compilers.htm > > > Hi Tomasz, > > Thanks for the link to Aztec -- I'm well aware of it, and it's on my > list of compilers to examine more closely :) > > It certainly meets the criteria of time, platform and so on. > > Thanks, What about all the cross compilers that ran on PDP-11's? Little or no chance of ever getting one of those but a lot of cross development was done i n that environment. VAX/VMS as well. But all that stuff has been lost. bill From jwest at classiccmp.org Thu Feb 7 07:52:55 2019 From: jwest at classiccmp.org (Jay West) Date: Thu, 7 Feb 2019 07:52:55 -0600 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> Message-ID: <008801d4beec$6d3b2920$47b17b60$@classiccmp.org> Brent wrote... There's no way you're angling a regular shafted screwdriver in there to adequately tighten screws. One could undo the catch that limits the angle of swing, but I still don't expect it's going to swing far enough to get the frame out of the way, let alone the PCBs and motors still in the way. ----- See? It's impossible to mount it without severe danger! In an effort to promote public safety, just send all your 7970E's to me and I will keep them somewhere that no one can get hurt on them! ;) J From ethan.dicks at gmail.com Thu Feb 7 08:48:41 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Thu, 7 Feb 2019 08:48:41 -0600 Subject: Looking for: 68000 C compilers In-Reply-To: References: <20190206162144.GA27182@tau1.ceti.pl> Message-ID: On Thu, Feb 7, 2019 at 3:50 AM Phil Pemberton via cctalk wrote: > On Wed, 6 Feb 2019, Tomasz Rola wrote: > > > On Wed, Feb 06, 2019 at 03:08:14PM +0000, Phil Pemberton via cctalk wrote: > >> I'm (still) trying to reverse-engineer a ton of M68K ROM code which > >> was apparently compiled with a circa-1990 C compiler. > >> > >> Does anyone have copies of any of the following... > >> * Lattice C > > > > Aztec C, by Manx Software (by now probably defunct). > > http://www.aztecmuseum.ca/index.htm I've been working on a project this month and I'm using FS-UAE to emulate the Amiga and running SAS/C 6.58. One distinct advantage is it writes Amiga files to the underlying UNIX filesystem so getting data in and out of the emulated environment is utterly trivial (making it easy to get and install tools and to export the results. The same technique would work with Aztec C. Local Makefiles running under AmigaDOS, your choice of editing files inside or outside the emulator... My target environment is actually AmigaDOS so it was an obvious choice, but if your target is binary objects, there they are on your platform's filesystem, ready to burn into ROMs or do whatever with. Of course, I spent a lot of time on the Amiga so I have no problems with that being my working environment. YMMV. -ethan From jfoust at threedee.com Thu Feb 7 09:06:03 2019 From: jfoust at threedee.com (John Foust) Date: Thu, 07 Feb 2019 09:06:03 -0600 Subject: Looking for: 68000 C compilers In-Reply-To: <20190206211357.GB27182@tau1.ceti.pl> References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> <20190206211357.GB27182@tau1.ceti.pl> Message-ID: <20190207151631.D41CD4E83A@mx2.ezwind.net> At 03:13 PM 2/6/2019, Tomasz Rola via cctalk wrote: >Lattice was the thing, back when I had Amiga. Too bad I could not >afford a harddisk :-). As I related here back in 2005 and 2007: I believe I stuck with Manx Aztec C throughout my entire era of Amiga development. I liked it because it was more Unix-like. I got to know one of its developers, Jim Goodnow. I was supposed to have an article in one of first issues of Amigaworld, reviewing the Lattice C compiler. Because it wasn't positive enough, though, and a major advertiser (not a compiler developer, though) somehow saw the article and complained that it might not attract developers to the platform, it was canned and not published. Development on a floppy-based Amiga was incredibly painful. Date: Fri, 06 May 2005 07:39:08 -0500 To: From: John Foust In-Reply-To: References: <20050505204522.U22923 at shell.lmi.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: XT 5160 X-BeenThere: cctalk at classiccmp.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "General Discussion: On-Topic and Off-Topic Posts" List-Id: "General Discussion: On-Topic and Off-Topic Posts" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cctalk-bounces at classiccmp.org Errors-To: cctalk-bounces at classiccmp.org Status: At 04:15 AM 5/6/2005, Fred N. van Kempen wrote: >I remember using a very much UNIX-like C environment for DOS, >called "Manx C". It was small, has the usual "make-cc-as-ld-ar" >setup, and produced nice code. What happened to them? This was >around ~84 or so.. Nitpick: Manx Software was the company, "Aztec C" was the product, but it often became "Manx C" in conversation. I think they closed up shop in the mid 90s. At 05:56 AM 5/6/2005, Ethan Dicks wrote: >I remember them in the 1986-1990 timeframe with their Amiga product. >They were competing with Lattice (later SAS) C. I personally went >with Lattice for several reasons, none of which I can recall right >now. I do remember that Manx did embedded assembly just different >enough from Lattice that it was not trivial to port from one to the >other. Makefiles were different, too. Back in the Amiga days, both Lattice and Manx were small enough that the guys who wrote the compilers would hang out at the developer conferences, so we all knew Jim Goodnow, the main brains behind their C compiler. Same for the original guys at Lattice and the later SAS team at Lattice. They were always showing off their latest features in order to entice developers to switch. Many developers owned Lattice because it was the first officially supported compiler. Jim was quick to come up with many features that outpaced Lattice. I remember Jim explaining how they got started with cross-compilation on a PDP-11, moving into the 6502 market with Apple II, and Z-80 undr CP/M, then to the 68000 market with Mac, Atari and Amiga, as well as a PC version. The first developer kits for Amiga included the Lattice PC-hosted cross compiler. Inside Amiga, there were also Sun and Stride hosted systems, too. I remember editing and compiling on a Compaq luggable, then sending my executables over the serial port. Compilation on one- or two-floppy Amiga systems was a real pain. - John From jnc at mercury.lcs.mit.edu Thu Feb 7 10:05:05 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 7 Feb 2019 11:05:05 -0500 (EST) Subject: Looking for: 68000 C compilers Message-ID: <20190207160505.37FA618C075@mercury.lcs.mit.edu> > From: Bill Gunshannon > What about all the cross compilers that ran on PDP-11's? Good point; by coincidence, I just found the stuff about the 68K cross-compiler from Alcyon (in San Diego) which we used at Proteon; it ran on an -11/73 running Ultrix. According to the ad sheet, it also ran on VAXen, HP9000s, Textronix 8560s, etc; OS's were various Unix flavours, VMS, VersaDOS, and Regulus. I have the man pages for it, the assembler and linker, the c.out format it produced, etc if those are any use/interest. Noel From amp1ron at gmail.com Thu Feb 7 10:34:27 2019 From: amp1ron at gmail.com (Ron Pool) Date: Thu, 7 Feb 2019 11:34:27 -0500 Subject: Looking for: 68000 C compilers In-Reply-To: <20190207160505.37FA618C075@mercury.lcs.mit.edu> References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> Message-ID: <003a01d4bf02$fec8cf80$fc5a6e80$@gmail.com> The CP/M-68K 1.0x source distribution at http://www.uxpro.com/cpm/www.cpm.z80.de/source.html includes a VAX/VMS distribution of Digital Research's 68K cross development software for VAX/VMS. After unpacking the source distribution, look in v102/cross for that distribution. Excerpt from v102/cross/install.doc: This document describes the installation and execution procedures for the Digital Research 68000 cross development software for VAX/VMS. This software includes the C compiler, assembler, linker, archiver, symbol table print utility, object module size utility, and S-Record conversion utility. These tools execute in much the same fashion as they do under CP/M-68K, as documented in the CP/M-68K Programmer's Guide. -- Ron From elson at pico-systems.com Thu Feb 7 10:58:51 2019 From: elson at pico-systems.com (Jon Elson) Date: Thu, 07 Feb 2019 10:58:51 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190207031129.87F1C18C077@mercury.lcs.mit.edu> References: <20190207031129.87F1C18C077@mercury.lcs.mit.edu> Message-ID: <5C5C63CB.2010809@pico-systems.com> On 02/06/2019 09:11 PM, Noel Chiappa via cctalk wrote: > > From: Jon Elson > > > I'm thinking it is bad memory. ... I think it is just a bad memory chip > > Nothing so simple, I'm afraid! The memory actually contains: > > PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 > > and it's _supposed_ to be holding: > > PA:171600: 110024 010400 000167 000016 010500 010605 010446 010346 > > This together with Fritz's discovery of that first 'bad memory' pattern _elsewhere_ > in the binary for the command makes it look pretty likely that some sort of other > error has wound up with stuff being put in the wrong location. > OK, now it is starting to look like an address problem. That could actually be several things. Possibly something going wrong in DMA, and the disk data is being written into the wrong place in memory. If the two places the same data show up are related by some simple binary transposition, maybe under some cases a write to memory gets written simultaneously into two banks of the memory. A memory interference test OUGHT to pick up something like that. It could also be a bus problem, or something going haywire in the MMU. And, one other possibility is that the duplicate data is a disk buffer or cache that was then copied to the location to be executed. Jon From mtapley at swri.edu Thu Feb 7 11:00:34 2019 From: mtapley at swri.edu (Tapley, Mark) Date: Thu, 7 Feb 2019 17:00:34 +0000 Subject: GSX-80 software In-Reply-To: References: Message-ID: <3A7FDFE4-3407-4AA2-AE9A-9331542D072A@swri.edu> Pat, DEC Rainbows used GSX-86, presumably related, running on CPM-80/86. I think that?s not what you are looking for, but let me know if you want more info on that. - Mark 210-522-6025 office 210-379-4635 cell > On Feb 6, 2019, at 9:25 PM, Patrick Finnegan via cctalk wrote: > > I'm wondering if anyone knows of any CP/M software using GSX-80, which > could be an interesting demo, or game. I have found Kasekastchen ( > http://atariage.com/forums/topic/244781-kaesekaestchen-a-new-gsx-based-game-for-pcw-cpc-and-other-cpm-machines/) > (misspelled without accents to make the mailman happy), but it mostly just > freezes after loading GSX-80 on my TS-803 so far (under the 'remote > processor' version of the OS at least). > > Thanks, > Pat > > CAUTION: This email originated from outside SwRI and it may contain attachments and/or links. Do not open attachments or click on links unless you recognize the sender and know the content is safe. From harper at secureoutcomes-hq.com Thu Feb 7 11:16:25 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Thu, 07 Feb 2019 10:16:25 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> Message-ID: <20190207171648.A9A9A4E754@mx2.ezwind.net> At 11:09 AM 2/6/2019, Jay West wrote: >Chuck's retension levers.... any chance this is on thingiverse or would you >be willing to send me the .stl file so I can 3dprint my own? :) > >I have not looked at my 7970's in quite some time, but I had thought the >previous discussion was for mounting the 7970's in an HP rack. Not all later >HP racks, but the 2 or 3 series that were predominant around the time of the >7970's, had a very specific build related to positioning of the holes (which >were actually a few sliding metal bars with tapped holes, not just holes all >up and down the rack). The 7970 mounting bracket was designed for that 'odd' >HP-way the racks were built at that time (they changed later). I do not >think that an HP rack called a "storage array" (obviously much later >production) would have the same hole (and more importantly, the channels >around the bars) pattern. Long story short, I am not positive that mounting >the 7970 in a non-HP or HP but non-period rack would work 100% as >originally intended. It may stay in the rack, but there could be some >positional/operational issues. > >Specifically what I'm wondering, without the bracket and in a "non-hp" hp >rack ;)... how did you bolt it on the left hand side? And are you sure that >with it mounted that way, the speed bolt on the front right inside the door >allows you to swing the unit all the way open without hitting the flush >surface on the left of the casting? > >I need to go look at mine and see if I'm just remembering this all wrong... >lol > >J Hello Jay and Greetings to the List - I mounted the two HP7970 Drives in a non-HP rack - just a standard six-foot 19" rack that I found a few years ago. I installed two heavy aluminum rails (1/8" thick and perhaps 2" on the two sides - angle stock) for each Drive to support the 130-pound weight of each. I checked carefully and both Drives are, in fact, resting on the rails 100% from front to back - those rails are supporting almost all it not all of the weight of each Drive. Yes, I got the three #10 (I think) screws through the holes on the right side of each Drive into the mating threaded holes on the right side of the 19" rack without difficulty. However, there is no obvious place for the screws to go through the Drive on the left side. I am still traveling on business and have not yet had a chance to read in detail the e-mail traffic on this - and will do so this weekend to see what's what. The Drives are not going to go anywhere, however I did notice that I could push the left side of the Drive from the rear out perhaps a quarter of an inch - and I need to correct that somehow. ...and Yes, the Drive fronts swing open to the left fine with no clearance issues. I was, of course, concerned about that and finally convinced myself that the fronts would swing open before I mounted the Beasts. See http://frobenius.com/190203%20Tape%20Drive4.jpg for exciting photo of one of the support rails. You can also see in the photo at the bottom of the rack on the floor part of the 3/4" thick plywood base that I built and anchored to the concrete floor to prevent rack tipping. The 19" rack is, of course, bolted to the plywood base. Best, Jack in the Rocky Mountains. ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From sales at elecplus.com Thu Feb 7 11:26:37 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 7 Feb 2019 11:26:37 -0600 Subject: HP 1000, 9000, AS/400, Sun, etc. Message-ID: <025401d4bf0a$48014d10$d803e730$@com> Hi Cindy, Thanks for the email. We have a large inventory of HP gear in Minneapolis. I have a lot of older HP stuff too from the 1980's and 1990's to current. I don't know what you are looking for HP1000's? old workstations and servers? Here is our store but I only listed a very small amount of our stock..... https://store.flagshiptech.com/ Brad Ziton HP Product Manager SKYPE: bradz at flagshiptech.com Trillian: BradZFTI bradz at flagshiptech.com 3939 County Road 116 Hamel, Minnesota 55340 (800) 416.8900 t: 763.516.1346 f: 763.516.1310 c: 612.708.3960 RS/6000 pSeries ? AS/400 iSeries ? Sun Microsystems ? HP9000 ? HP Proliant ? Cisco ? Dell Not affiliated with seller, etc. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From harper at secureoutcomes-hq.com Thu Feb 7 11:27:51 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Thu, 07 Feb 2019 10:27:51 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <5C5B712A.5020806@flying-disk.com> References: <5C5B712A.5020806@flying-disk.com> Message-ID: <20190207172757.5247B27386@mx1.ezwind.net> Great information Alan - I appreciate it. Regards to the List, Jack in the Rocky Mountains At 04:43 PM 2/6/2019, Alan Frisbie via cctalk wrote: >Jack Harper wrote: > >>I got both drives into the rack this past weekend and I am an old guy >>(67) - I carefully stared at the thing before I started and finally >>figured out that I could, in fact, lift the drive from a waist high >>cart for a few seconds, but definitely could not lift it or lower it >>vertically with my arms - no way - and I would have one shot at >>getting the drives into the rack on the rails. > >Harbor Freight sells a nice hydraulic lift table for under $200 that >I have found very useful for that sort of thing. It doesn't go up >very high (like for the top of a rack), but I used it with some wood >blocks to lift a DEC ES45 Alpha system into a rack by myself. > >500 pound capacity, 28.5" lift height, $170 >https://www.harborfreight.com/500-lbs-capacity-hydraulic-table-cart-61405.html > >1000 pound capacity, 34.5" lift height, $260 >https://www.harborfreight.com/1000-lbs-capacity-hydraulic-table-cart-69148.html > >Alan Frisbie ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From jnc at mercury.lcs.mit.edu Thu Feb 7 11:47:32 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 7 Feb 2019 12:47:32 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190207174732.D89E518C075@mercury.lcs.mit.edu> > From: Fritz Mueller > is it possible for you deduce where Unix _should_ be placing these "bad" > bits (from file offset octal 4220)? Yes, it's quite simple: just add the virtual address in the code to the physical address of the bottom of the text segment (given in UISA0). The VA is actually 04200, though: the 04220 includes 020 to hold the a.out header at the start of the command file. So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600, I think. And it wound up at PA:171600 - off by 04000 (higher) - which is obviously an interesting number. > Maybe a comparison of addresses where the bits should be, with > addresses where the "bad" copy ends up, could point us at some particular > failure modes to check in the KT11, CPU, or RK11... Here's where it gets 'interesting'. Executing a command with pure text on V6 is a very complicated process. The shells fork()s a copy of itself, and does an exec() system call to overlay the entire memory in the new process with a copy of the command (which sounds fairly simple, at a high level) - but the code path to do the exec() with a pure text is incredibly hairy, in detail. In particular, for a variety of reasons, the memory of the process can get swapped in and out several times during that. I apparently used to understand how this all worked, see this message: https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html but it's so complicated it's going to take a while to really comprehend it again. (The little grey cells are aging too, sigh...) The interesting point is that when V6 first copies the text in from the file holding the command (using readi(), Lions 6221 for anyone who's masochistic enough to try and actually follow this :-), it reads it in starting from the bottom, one disk block at a time (since in V6, files are not stored contiguously). So, if it starts from the bottom, and copies the wrong thing from low in the file _up_ to VA:010200, when it later gets to VA:010200 in the file contents, that _should_ over-write the stuff that got put there in the wrong place _earlier_. Unless there's _another_ problem which causes that later write to _also_ go somewhere wrong... So, I'm not sure when this trashage is happening, but because of the above, my _guess_ is that it's in one of the two swap operations on the text (out, and then back in). (Although it might be interesting to look at PA:165600 and see what's actually _there_.) Unix does swapping of pure texts in a single, multi-block transfer (although not always as an integral number of blocks, as we found out the hard way with the QSIC :-). So my suspicions have now switched back to the RK11... One way to proceed would be to stop the system after the pure text is first read in (say around Lions 4465), and look to see what the text looks like in main memory at _that_ point. (This will require looking at KT11 registers to see where it's holding the text segment, first.) If that all looks good, we'll have to figure out how to stop the system after the pure text is read back in (which does not happen in exec(), it's done by the normal system operation to swap in the text and data of a process which is ready to run). We could also stop the system after the text is swapped out, and key in a short (~ a dozen words) program to read the text back in from the swap device, and examine it - although we'd have to grub around in the system a bit to figure out where it got written to. (It might be just easier to stop it at, say, Lions 5196 and look at the arguments on the kernel stack.) > a suggestion here to check the KT11 address translation adders ... A > bug in one of the carry lookahead generators used between the bit > slices of that adder could cause a mistranslation on only a fairly > selective subset of virtual addresses This could be happening, but from the reasoning above about the order that the blocks of the text are read in, something would have to interfere with the later read of the higher memory blocks, too, no? So I'd discount the KT11 _for the moment_. > *IF* that's the case and we can chase the IR trace upstream to the > place of an unlucky mistranslation, it will be pretty easy to track > down then in the hw and fix. It'll be interesting to look at the text after it's read in (i.e. before it's swapped out). If it's OK there, that's pretty conclusive that it _can't_ be the KT11 - because from then on, the kernel doesn't _do anything_ to that binary, except swap it out and in with the RK11. And since those are both single I/O operations (with swapping on the RK11, at least, which can do multi-block transfers), _and_ the bottom of the text segment comes in OK (so the RK11 is being set up with correct disk and main memory addresses for both the out and in), I can't think of a fault _elsewhere_ in the system that could cause that 'stuff winds up in the wrong place' error. I know this is complicated, but look at the bright side: we started with three apparently un-connected problems: * R5 trashage * an 'impossible' MM fault * bad text data The first one turned out to be non-existent (my fault in interpreting the kernel stack in the process core dump), the second was also not really there (although a hardware fault in the console gave us bad data, so there really was a hardware issue there), and now we're down to one - albeit a tricky one. So we were dealing with two un-related hardware problems - now we're down to one, and hopefully soon will have it isolated to a single sub-system! (And thanks to whoever gave us the voltage tip, that fixed the first one.) Noel From emu at e-bbes.com Thu Feb 7 12:19:48 2019 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 7 Feb 2019 13:19:48 -0500 Subject: Looking for: 68000 C compilers In-Reply-To: <003a01d4bf02$fec8cf80$fc5a6e80$@gmail.com> References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> <003a01d4bf02$fec8cf80$fc5a6e80$@gmail.com> Message-ID: <490a53c9-f477-caf8-df8c-9f784b56be93@e-bbes.com> On 2019-02-07 11:34, Ron Pool via cctalk wrote: > The CP/M-68K 1.0x source distribution at > http://www.uxpro.com/cpm/www.cpm.z80.de/source.html includes a VAX/VMS > distribution of Digital Research's 68K cross development software for > VAX/VMS. After unpacking the source distribution, look in v102/cross for > that distribution. Excerpt from v102/cross/install.doc: > > This document describes the installation and execution > procedures for the Digital Research 68000 cross development Anybody out here tried it? I like to set up a cpm68k system, and doing that on a VAX would be much more fun ;-) Cheers! From fritzm at fritzm.org Thu Feb 7 12:37:26 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Thu, 7 Feb 2019 10:37:26 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190207174732.D89E518C075@mercury.lcs.mit.edu> References: <20190207174732.D89E518C075@mercury.lcs.mit.edu> Message-ID: <609EB87D-6B16-4038-B73C-95EEBF692B71@fritzm.org> > On Feb 7, 2019, at 9:47 AM, Noel Chiappa via cctalk wrote: > > So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600, > I think. And it wound up at PA:171600 - off by 04000 (higher) - which is > obviously an interesting number. Thanks, Noel. > ...it might be interesting to look at PA:165600 and see what's actually _there_ A sea of zeros, as it turns out. I'm thinking it might be worth obtaining a full memory dump of the text segment at the point of fault (I can do this with a small toggle-in program to dump it over the serial console), , and then compare that to the complete text section in the ls binary. That would give us more of a clue about whether blocks of memory are duplicated or swapped, what the size, alignment, and stride of the corrupted blocks is, how many there are, etc. I'll get an IR trace out this weekend. Another thing I _could_ do with the LA is an IO command trace on the RK11 (though that's a lot of probes to hook up to get disk address, count, and memory address). --FritzM. From cclist at sydex.com Thu Feb 7 12:39:08 2019 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 7 Feb 2019 10:39:08 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190207171648.A9A9A4E754@mx2.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> Message-ID: On 2/7/19 9:16 AM, Jack Harper via cctalk wrote: > I mounted the two HP7970 Drives in a non-HP rack - just a standard > six-foot 19" rack that I found a few years ago. > > I installed two heavy aluminum rails (1/8" thick and perhaps 2" on the > two sides - angle stock) for each Drive to support the 130-pound weight > of each. That makes a lot of sense and doesn't look too difficult to fab up from stock. Or if you're not handy with metalworking, these would do the same job: https://www.hammfg.com/dci/products/accessories/raab That way, the right-side bolts serve to keep the thing in the rack. The Fujitsu drive that I use weighs more than the HP and doesn't even have "ears" to mount to the rack rails--it uses a sliding arrangement like many large disk drives. Fasten one part of the slides to the rack and the other to the drive and just slide the drive in--there are bolts to secure the slide position once the drive is in place. --Chuck From paulkoning at comcast.net Thu Feb 7 12:42:23 2019 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 7 Feb 2019 13:42:23 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <609EB87D-6B16-4038-B73C-95EEBF692B71@fritzm.org> References: <20190207174732.D89E518C075@mercury.lcs.mit.edu> <609EB87D-6B16-4038-B73C-95EEBF692B71@fritzm.org> Message-ID: > On Feb 7, 2019, at 1:37 PM, Fritz Mueller via cctalk wrote: > > >> On Feb 7, 2019, at 9:47 AM, Noel Chiappa via cctalk wrote: >> >> So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600, >> I think. And it wound up at PA:171600 - off by 04000 (higher) - which is >> obviously an interesting number. > > Thanks, Noel. > >> ...it might be interesting to look at PA:165600 and see what's actually _there_ > > A sea of zeros, as it turns out. > > I'm thinking it might be worth obtaining a full memory dump of the text segment at the point of fault (I can do this with a small toggle-in program to dump it over the serial console), , and then compare that to the complete text section in the ls binary. That would give us more of a clue about whether blocks of memory are duplicated or swapped, what the size, alignment, and stride of the corrupted blocks is, how many there are, etc. > > I'll get an IR trace out this weekend. Another thing I _could_ do with the LA is an IO command trace on the RK11 (though that's a lot of probes to hook up to get disk address, count, and memory address). How about a Unibus trace? That would give you the RK11 commands as well as the data it sends in response. paul From fritzm at fritzm.org Thu Feb 7 12:57:27 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Thu, 7 Feb 2019 10:57:27 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190207174732.D89E518C075@mercury.lcs.mit.edu> <609EB87D-6B16-4038-B73C-95EEBF692B71@fritzm.org> Message-ID: > How about a Unibus trace? That would give you the RK11 commands as well as the data it sends in response. I don't think my sad little HP LA has enough buffer for that... --FritzM. From mattislind at gmail.com Thu Feb 7 13:47:19 2019 From: mattislind at gmail.com (Mattis Lind) Date: Thu, 7 Feb 2019 20:47:19 +0100 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190207174732.D89E518C075@mercury.lcs.mit.edu> <609EB87D-6B16-4038-B73C-95EEBF692B71@fritzm.org> Message-ID: torsdag 7 februari 2019 skrev Fritz Mueller via cctalk < cctalk at classiccmp.org>: > > > How about a Unibus trace? That would give you the RK11 commands as well > as the data it sends in response. > > I don't think my sad little HP LA has enough buffer for that... You could use triggers in innovative ways. Maybe trigger on that particular data on that particular address. What takes place just before this? Is it DMA or is it the CPU moving the data. Is it just reading out bad or is it written bad? That should be possible to figure out. You will probably get quite far with only 16 data and 16 address bits (if you have the smallest analyzer). Of course more is better... /Mattis > > --FritzM. From ethan.dicks at gmail.com Thu Feb 7 14:17:22 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Thu, 7 Feb 2019 14:17:22 -0600 Subject: Looking for: 68000 C compilers In-Reply-To: <490a53c9-f477-caf8-df8c-9f784b56be93@e-bbes.com> References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> <003a01d4bf02$fec8cf80$fc5a6e80$@gmail.com> <490a53c9-f477-caf8-df8c-9f784b56be93@e-bbes.com> Message-ID: On Thu, Feb 7, 2019 at 1:35 PM emanuel stiebler via cctalk wrote: > On 2019-02-07 11:34, Ron Pool via cctalk wrote: > > The CP/M-68K 1.0x source distribution at > > http://www.uxpro.com/cpm/www.cpm.z80.de/source.html includes a VAX/VMS > > distribution of Digital Research's 68K cross development software for > > VAX/VMS. > > Anybody out here tried it? I haven't (yet). I just learned about it and am still exploring the files. > I like to set up a cpm68k system, and doing that on a VAX would be much > more fun ;-) Looks like there are a couple hundred .COM files in the source archive... # cat ./v101/c/preproc/make.com $ set noon $ set def [steve.cpm68k.c.preproc] $ copy machine.68k machine.h $ cc68 cexpr $ cc68 lex $ cc68 macro $ cc68 main $ cc68 preproc $ cc68 util $ @reload Definitely DCL, definitely VMS. -ethan From rtomek at ceti.pl Thu Feb 7 15:32:57 2019 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 7 Feb 2019 22:32:57 +0100 Subject: Amiga, AtariST, soft repos [was: Re: Looking for: 68000 C compilers] In-Reply-To: <20190207151631.D41CD4E83A@mx2.ezwind.net> References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> <20190206211357.GB27182@tau1.ceti.pl> <20190207151631.D41CD4E83A@mx2.ezwind.net> Message-ID: <20190207213256.GA12998@tau1.ceti.pl> On Thu, Feb 07, 2019 at 09:06:03AM -0600, John Foust via cctalk wrote: > At 03:13 PM 2/6/2019, Tomasz Rola via cctalk wrote: > >Lattice was the thing, back when I had Amiga. Too bad I could not > >afford a harddisk :-). > > As I related here back in 2005 and 2007: > > I believe I stuck with Manx Aztec C throughout my entire era of Amiga > development. I liked it because it was more Unix-like. I got to know > one of its developers, Jim Goodnow. > > I was supposed to have an article in one of first issues of Amigaworld, > reviewing the Lattice C compiler. [...] > it was canned and not published. I guess you could have a revenge now and publish it on a web? > Development on a floppy-based Amiga was incredibly painful. tl;dr: Is there a software repository for AtariST comparable to Aminet? Yeah... It was a bit less painful if one had Amiga 2000 or higher (I had 2000c... or b?) since there was a lot of place inside. I had two floppy stations and second half of my ownership was blessed with ram extension (giving me total of 3 megabytes). I used Aztec C (it had proper linker (ln), make for makefiles and ar for *.a archive management, IIRC). Managed to squeeze full dev environment into ramdisk (I remember I had to delete some unused files to make place, and probably used some small AmigaDOS batch file to automate things). And the ramdisk was rebootable, and could be booted from, which was so cool (because Guru Meditation plagued me a bit)! On the other hand, later on I witnessed coming of relatively cheap PC-compatible harddrives for Amiga 500, which were unusable in my case (there were too few Amiga 2/3/4xxx users to care, and I believe around this time the inept C= managers decided to eject everything and /-I guess-/ pay themselves a bonus, so the ice under users' feet was definitely shrinking). I have also learnt to hate MS-made Basic (included on Workbench floppies) while trying to use it. Overally, it was a good experience. It helped me to grasp and appreciate modern aspects of computing, and so I swallowed the Unix bug in a second, while it took fellow students weeks or infinity (especially if they started with MS DOS, as I observed). OTOH, in retrospect, I wonder if I would spent the money wiser by choosing AtariST or going straight to 286 (not the same experience, I know, but cheap and easier to sell away). Or, if I wanted it really cheap, C128 was able to give me 80x24 terminal in one gfx mode, but I could not find any floppy drive for it capable of r/w PC floppies, so that option is probably out. I have a kind of very-very low priority project to investigate AtariST side of things, especially that nowadays I can run a very nice community-written TOS on emulator, but it seems there is no software repository similar to Aminet, am I right? I am interested in utility software, mostly compilers and editors and other such things. Multimedia and games, not so much. Actually, the project is spelled somewhat like "assume that buying Amiga 2000 was bad idea, was there something that could have prepared me for embracing Unix (and later, Linux), while giving me PC compatible floppy, good text terminal (i.e. 80x24) and maybe even hard drive? (gaming not required, as I really had almost no time for this)". So that John Titor could drop me a postcard (also, assume he is subscribed here). So far, one of AtariST or Amiga 500. But I cannot get price listings from old Polish computer press - my own papers lay buried deep below new papers, no access, and I am yet to find proper incantation for goog. So the "project" is on temporary hold. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From ethan at 757.org Thu Feb 7 15:46:49 2019 From: ethan at 757.org (Ethan O'Toole) Date: Thu, 7 Feb 2019 16:46:49 -0500 (EST) Subject: Amiga, AtariST, soft repos [was: Re: Looking for: 68000 C compilers] In-Reply-To: <20190207213256.GA12998@tau1.ceti.pl> References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> <20190206211357.GB27182@tau1.ceti.pl> <20190207151631.D41CD4E83A@mx2.ezwind.net> <20190207213256.GA12998@tau1.ceti.pl> Message-ID: > (especially if they started with MS DOS, as I observed). OTOH, in > retrospect, I wonder if I would spent the money wiser by choosing > AtariST or going straight to 286 (not the same experience, I know, but > cheap and easier to sell away). Or, if I wanted it really cheap, C128 I grew up Atari 8bit then MS-DOS but watched Amiga and Atari ST. I now dabble with both machines. To me the Amiga seems better in most ways. The hard drive interfaces were probably just as expensive then. ASCI or whatever their custom SCSI implementation is on the Atari. The colors are better on the Amiga. The sound seems mostly better on the Amiga (skipping the midi factor of the Atari ST since that requires buying expensive synths or tone modules or samplers. No standard here.) The community hacking of the Amiga seems larger, and the accessory market seems way bigger on the Amiga. The Atari high res mono monitor is better than the Amigas headache inducing stuff but you had to forgo color to get that. A friend growing up was an Atari ST guy and I think he fairly recently picked up both a Falcon 030 and an Amiga 1200 and made some sort comment about how the experience made him sad that he realizes the Amiga was pretty much better in every way. If you DO get an Atari ST, I recommend the UltraSatan dual SD card emulator for a hard drive. Still having a bit of a time trying to bulk transfer software games and apps onto the Atari ST. And need a C-Lab Notator Dongle for the Atari ST. YMMV -- : Ethan O'Toole From aek at bitsavers.org Thu Feb 7 16:03:23 2019 From: aek at bitsavers.org (Al Kossow) Date: Thu, 7 Feb 2019 14:03:23 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> <003a01d4bf02$fec8cf80$fc5a6e80$@gmail.com> <490a53c9-f477-caf8-df8c-9f784b56be93@e-bbes.com> Message-ID: <78ba4cd7-a8c6-fa96-9f9a-0f5fdc91e9e7@bitsavers.org> On 2/7/19 12:17 PM, Ethan Dicks via cctalk wrote: > $ set def [steve.cpm68k.c.preproc] 'steve' == Steve Williams this is the Alcyon C cross-compiler From cisin at xenosoft.com Thu Feb 7 16:01:50 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 7 Feb 2019 14:01:50 -0800 (PST) Subject: Tight clearance bit holder (was: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <1e90127b-0226-c11a-ce5f-cd62820c7593@sydex.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> <1e90127b-0226-c11a-ce5f-cd62820c7593@sydex.com> Message-ID: On Wed, 6 Feb 2019, Chuck Guzis via cctalk wrote: > Ratchet right-angle screwdrivers are also an option, as are ball-end > allen wrenches or offset-head screwdrivers. None are particularly dear. After half a century of using the cheap crap, first the stamped chrome ones, and then the black ones from Hazard Fraught, I have found one that I like: https://www.amazon.com/Victorinox-Ratchet-Swisstool-Spirit-Multi-Tool/dp/B00LFKZ374 It's much smaller, sleeker and works well. You need to flip it over to reverse. Made by Victorinox (Swiss army knife). About five times the price of Hazard Fraught. I have NOT yet seen how it withstands abuse, such as hitting with a hammer, or putting a pipe on the end to exceed its torque range. Since bit fits through it, bit length is the limit of where it will fit, plus a finger or screw driver blade to apply pressure to keep Phillips from camming out. There is an extension available, that can also be stuck in the back end for more torque: https://www.amazon.com/Victorinox-Extension-Swisstool-Spirit-Multi-Tool/dp/B004UON5JU/ and a non-ratheting bit turner and a plastic bit storage that clips to either the ratchet or non-ratchet: https://www.amazon.com/Victorinox-Bits-Wrench-Pouch-Nylon/dp/B001CDKT7I/ -- Grumpy Ol' Fred cisin at xenosoft.com From cclist at sydex.com Thu Feb 7 16:47:30 2019 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 7 Feb 2019 14:47:30 -0800 Subject: Tight clearance bit holder In-Reply-To: References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> <1e90127b-0226-c11a-ce5f-cd62820c7593@sydex.com> Message-ID: <15db00b1-5d2f-33f0-f60a-e154912a0e51@sydex.com> On 2/7/19 2:01 PM, Fred Cisin via cctalk wrote: > On Wed, 6 Feb 2019, Chuck Guzis via cctalk wrote: >> Ratchet right-angle screwdrivers are also an option, as are ball-end >> allen wrenches or offset-head screwdrivers.? None are particularly dear. > > After half a century of using the cheap crap, first the stamped chrome > ones, and then the black ones from Hazard Fraught, I have found one that > I like: > https://www.amazon.com/Victorinox-Ratchet-Swisstool-Spirit-Multi-Tool/dp/B00LFKZ374 > > > It's much smaller, sleeker and works well.? You need to flip it over to > reverse.???? Made by Victorinox (Swiss army knife). About five times the > price of Hazard Fraught. > I have NOT yet seen how it withstands abuse, such as hitting with a > hammer, or putting a pipe on the end to exceed its torque range. In a pinch, I've used one of my made-in-China 1/4" ratchet wrench and a screwdriver bit. It's about as slim as they come. My set (from 1983 is real Chinese--"Laughing Swan" brand or some such. Looks something like this: https://www.amazon.com/Apollo-Tools-DT1212-Ratcheting-5-Piece/dp/B002OHDXYM/ But I like the idea of just supporting the thing from the bottom. Can't get better than that from a mechanical standpoint. --Chuck From imp at bsdimp.com Thu Feb 7 22:50:55 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 7 Feb 2019 23:50:55 -0500 Subject: Tight clearance bit holder In-Reply-To: <15db00b1-5d2f-33f0-f60a-e154912a0e51@sydex.com> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <0726926f-5950-fa63-0724-1b75b6eda078@sydex.com> <001101d4be51$c00fb3f0$402f1bd0$@classiccmp.org> <2C3068BC-2674-4E3E-BE3E-DB9AF7E3DB1B@shaw.ca> <14e4d0fb-3f3c-dc90-a4f6-8328dca534b4@sydex.com> <5EFC68B2-3E32-496E-A84C-4E15F36D7492@shaw.ca> <369E0CE0-4724-4360-8417-47DD343EB8C6@shaw.ca> <1e90127b-0226-c11a-ce5f-cd62820c7593@sydex.com> <15db00b1-5d2f-33f0-f60a-e154912a0e51@sydex.com> Message-ID: On Thu, Feb 7, 2019, 5:47 PM Chuck Guzis via cctalk On 2/7/19 2:01 PM, Fred Cisin via cctalk wrote: > > On Wed, 6 Feb 2019, Chuck Guzis via cctalk wrote: > >> Ratchet right-angle screwdrivers are also an option, as are ball-end > >> allen wrenches or offset-head screwdrivers. None are particularly dear. > > > > After half a century of using the cheap crap, first the stamped chrome > > ones, and then the black ones from Hazard Fraught, I have found one that > > I like: > > > https://www.amazon.com/Victorinox-Ratchet-Swisstool-Spirit-Multi-Tool/dp/B00LFKZ374 > > > > > > It's much smaller, sleeker and works well. You need to flip it over to > > reverse. Made by Victorinox (Swiss army knife). About five times the > > price of Hazard Fraught. > > I have NOT yet seen how it withstands abuse, such as hitting with a > > hammer, or putting a pipe on the end to exceed its torque range. > > In a pinch, I've used one of my made-in-China 1/4" ratchet wrench and a > screwdriver bit. It's about as slim as they come. My set (from 1983 is > real Chinese--"Laughing Swan" brand or some such. > > Looks something like this: > > > https://www.amazon.com/Apollo-Tools-DT1212-Ratcheting-5-Piece/dp/B002OHDXYM/ > > But I like the idea of just supporting the thing from the bottom. Can't > get better than that from a mechanical standpoint. > Years ago I loved the idea of rack mount since you just needed the ears. But now all my rack mount gear winds up living on L brackets mounted in the rack to act as shelves... at least for hobbyist use. It is easier and simpler to get angle iron and cut it to length and bolt it in place than deal with heavy or awkward gear on rails... but I've admittedly never had a 200 lbs tape drive to deal with... Warner > From doug at blinkenlights.com Fri Feb 8 00:09:52 2019 From: doug at blinkenlights.com (Doug Salot) Date: Thu, 7 Feb 2019 22:09:52 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: <78ba4cd7-a8c6-fa96-9f9a-0f5fdc91e9e7@bitsavers.org> References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> <003a01d4bf02$fec8cf80$fc5a6e80$@gmail.com> <490a53c9-f477-caf8-df8c-9f784b56be93@e-bbes.com> <78ba4cd7-a8c6-fa96-9f9a-0f5fdc91e9e7@bitsavers.org> Message-ID: Alcyon as in Regulus? Pretty sure they got it from Green Hills. And Green Hills is still around. On Thu, Feb 7, 2019 at 2:02 PM Al Kossow via cctalk wrote: > > > On 2/7/19 12:17 PM, Ethan Dicks via cctalk wrote: > > > $ set def [steve.cpm68k.c.preproc] > > 'steve' == Steve Williams > > this is the Alcyon C cross-compiler > > > From barythrin at gmail.com Fri Feb 8 01:14:37 2019 From: barythrin at gmail.com (Sam O'nella) Date: Fri, 8 Feb 2019 01:14:37 -0600 Subject: Amiga, AtariST, soft repos [was: Re: Looking for: 68000 C compilers] In-Reply-To: <20190207213256.GA12998@tau1.ceti.pl> References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> <20190206211357.GB27182@tau1.ceti.pl> <20190207151631.D41CD4E83A@mx2.ezwind.net> <20190207213256.GA12998@tau1.ceti.pl> Message-ID: > > tl;dr: Is there a software repository for AtariST comparable to Aminet? > > I don't follow it much, so I can't really say for sure what systems or software are in the archive. But there was an effort for collecting "all" games and software for many systems called TOSEC. Unfortunately, it's not an authorized collection so copyright folks may frown on obtaining those files. From cube1 at charter.net Fri Feb 8 07:37:04 2019 From: cube1 at charter.net (Jay Jaeger) Date: Fri, 8 Feb 2019 07:37:04 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190207174732.D89E518C075@mercury.lcs.mit.edu> References: <20190207174732.D89E518C075@mercury.lcs.mit.edu> Message-ID: <7267dfbc-8ffe-9a4e-e003-f3067c337d89@charter.net> On 2/7/2019 11:47 AM, Noel Chiappa via cctalk wrote: > > The interesting point is that when V6 first copies the text in from the file > holding the command (using readi(), Lions 6221 for anyone who's masochistic > enough to try and actually follow this :-), it reads it in starting from the > bottom, one disk block at a time (since in V6, files are not stored > contiguously). > I remember when Lions first showed up. I have a copy of a copy made back in the day. JRJ From jnc at mercury.lcs.mit.edu Fri Feb 8 11:00:57 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 8 Feb 2019 12:00:57 -0500 (EST) Subject: VAX-11/780 print set on eBait Message-ID: <20190208170057.8755818C075@mercury.lcs.mit.edu> For those who are intrigued by the VAX-11/780, here: https://www.ebay.com/itm/321399703349 If you can't have a real 780, at least you can have the prints! :-) Noel From gerardcjat at free.fr Fri Feb 8 13:09:49 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Fri, 8 Feb 2019 20:09:49 +0100 Subject: HP 1000 M-series KEY PANEL BOARDS ( with Keys ;-) ) EBAY Message-ID: <5D0E27FB927F4C66AB37E975C6816BF3@medion> Did you see it ?? Someone interested ?? LOT of 6 units Qty 6 !!! Seller asking $200 or OFFER https://www.ebay.com/itm/323685640463?ul_noapp=true Not affiliated .... etc etc From gerardcjat at free.fr Fri Feb 8 13:09:49 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Fri, 8 Feb 2019 20:09:49 +0100 Subject: HP 1000 M-series KEY PANEL BOARDS ( with Keys ;-) ) EBAY Message-ID: <5D0E27FB927F4C66AB37E975C6816BF3@medion> Did you see it ?? Someone interested ?? LOT of 6 units Qty 6 !!! Seller asking $200 or OFFER https://www.ebay.com/itm/323685640463?ul_noapp=true Not affiliated .... etc etc From technoid6502 at gmail.com Fri Feb 8 19:28:35 2019 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Fri, 08 Feb 2019 20:28:35 -0500 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: <04a47fcc084e537271dbc7762c0910ea54b6c6d1.camel@gmail.com> On Fri, 2019-02-08 at 12:00 -0600, cctalk-request at classiccmp.org wrote: > Re: Looking for: 68000 C compilers There is a GNU OS for the Atari 68k-based ST, TT, and Falcon computers which might be fun to play with. It is called MiNT. FreeMiNT and SpareMiNT are two distros. They are available. Aranym/Afros are current projects. Of course tools are available within. Best regards, Jeff From fritzm at fritzm.org Fri Feb 8 20:38:31 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Fri, 8 Feb 2019 18:38:31 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190207174732.D89E518C075@mercury.lcs.mit.edu> <609EB87D-6B16-4038-B73C-95EEBF692B71@fritzm.org> Message-ID: <41354071-4389-4CE2-9A7C-12AD5A359143@fritzm.org> >>> How about a Unibus trace? >> >> I don't think my sad little HP LA has enough buffer for that... > > You could use triggers in innovative ways. Ah, quite right, gentlemen. This seems the best place to start with the LA this weekend then. --FritzM. From aek at bitsavers.org Sat Feb 9 10:44:25 2019 From: aek at bitsavers.org (Al Kossow) Date: Sat, 9 Feb 2019 08:44:25 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> <003a01d4bf02$fec8cf80$fc5a6e80$@gmail.com> <490a53c9-f477-caf8-df8c-9f784b56be93@e-bbes.com> <78ba4cd7-a8c6-fa96-9f9a-0f5fdc91e9e7@bitsavers.org> Message-ID: <358f4328-13fc-d1ca-e37e-c62abea9cb78@bitsavers.org> On 2/7/19 10:09 PM, Doug Salot wrote: > Alcyon as in Regulus?? ?Pretty sure they got it from Green Hills. Copyright 1982 Alcyon Corporation 8716 Production Ave. San Diego, Ca. 92121 @(#)optab.c 2.3 11/15/84 From jnc at mercury.lcs.mit.edu Sat Feb 9 10:45:07 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 9 Feb 2019 11:45:07 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190209164507.2F6E618C075@mercury.lcs.mit.edu> > From: Fritz Mueller > This seems the best place to start with the LA this weekend then. I'm going to respectfully semi-disagree! I think that at this point there's a good chance we can localize to within a gate or two before we start applying test instuments. My thinking starts with two pieces of data; i) your discovery that when the MM trap happens, the end of the pure text segment contains a fragment of code from 04000 lower in the text, and ii) the data that the location in main memory where that _should_ have been is full of zeros - i.e. never been written into. The latter is, I think, due to the fact that Unix clears all of main memory on startup; I think it's just chance that that memory hasn't been used yet for something else, and is still 0's. (Unix does clear main memory in a few places during regular operation - e.g. when expanding the stack, the newly added area is 0'd - but in general, e.g. when swapping in a pure text, it doesn't seem to bother, which makes sense since it's all about to be over-written anyway.) Anyway, those two, together with my previous analysis that this was unlikely to have happened when the text was first being read in from the file, block by block, lead me to believe that the likely cause is that the BAR on the RK11 skipped up a whole bunch (setting the 04000 bit at some point) when it was reading the pure text back in from the swap, and skipped writing into that zero-filled block of main memory, putting the stuff that should have gone there up 04000, instead. (Why it's swapping the text back in is too complicated to be worth explaining here; anyone who _really_ wants to know should look here: http://gunkies.org/wiki/Unix_V6_internals in the last section, "exec() and pure-text images".) It's easy to confirm all these suppositions/deductions fairly easily, without having to connect up, configure, etc the LA: we can just stop the machine after the text is first read in (in xalloc()) from the file-system, and confirm that the text looks good there; if so, either the swap-out (albeit unlikely, since that doesn't account for the 0's) or subsequent swap-in had an issue. The latter would be easy to confirm: just halt the machine after the text is swapped in, and see what the RK registers contain. At that point, as I said, we'll know to within a few gates where the issue is, and then it'll be time to bring out the LA. Actually, a plain oscilloscope would do; it's interesting to recollect that these machines were designed and maintained without benefit of a LA, purely with an oscilloscope! We're so spoiled now! :-) Noel From aek at bitsavers.org Sat Feb 9 12:35:50 2019 From: aek at bitsavers.org (Al Kossow) Date: Sat, 9 Feb 2019 10:35:50 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: <20190207160505.37FA618C075@mercury.lcs.mit.edu> References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> Message-ID: <8a4a3639-b21b-3b23-e7a0-9a21e2bc861c@bitsavers.org> On 2/7/19 8:05 AM, Noel Chiappa via cctalk wrote: > I have the man pages for it, the assembler and linker, the c.out format it > produced, etc if those are any use/interest. I have a source tape. I'm trying to figure out why modern tar doesn't understand it. From aek at bitsavers.org Sat Feb 9 12:39:22 2019 From: aek at bitsavers.org (Al Kossow) Date: Sat, 9 Feb 2019 10:39:22 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: <9f4b0cd1-3b68-76c0-437d-53f9f2506a2b@figureeightbrewing.com> References: <9f4b0cd1-3b68-76c0-437d-53f9f2506a2b@figureeightbrewing.com> Message-ID: On 2/6/19 11:45 AM, Tom Uban via cctalk wrote: > I have a copy of the source for a set of 68k tools (compiler, assembler, loader, etc) > which was based on work done by Chris Terman at MIT. This work was done back in > the mid 80s, so some work is likely needed to compile with modern tools. Let me > know if you would like a copy. I dug up my copy of the Stanford V System, which also used a version of the Trix compiler (as did many others). http://bitsavers.org/bits/Stanford/VSystem_6.0 This was also the starting point for the Stanford SUMACC Macintosh compiler. I've just found the binaries so far, I thought I had the sources somewhere. There is also an MIT compiler tape around with a bunch of different PCC ports including the Brooklyn Poly x86 compiler. From fritzm at fritzm.org Sat Feb 9 12:41:07 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Sat, 9 Feb 2019 10:41:07 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190209164507.2F6E618C075@mercury.lcs.mit.edu> References: <20190209164507.2F6E618C075@mercury.lcs.mit.edu> Message-ID: <581C7F55-F820-4BB0-9D3A-FD4685B50057@fritzm.org> >> This seems the best place to start with the LA this weekend then. > > I'm going to respectfully semi-disagree! I think that at this point there's a > good chance we can localize to within a gate or two before we start applying > test instruments. Oh, I agree completely, Noel. I should have more precisely said "when/if we get to the LA this weekend, this seems the place to start." If, as you are suspecting, we find damning evidence pointing specifically to the RK11, I'm going to want to watch it going about its business; the LA will be a good tool for that. And yes, one of the beautiful things about these machines is how far you can get with just a set of extenders, a KM11, the front panel, and a 'scope. --FritzM. From kylevowen at gmail.com Sat Feb 9 12:52:53 2019 From: kylevowen at gmail.com (Kyle Owen) Date: Sat, 9 Feb 2019 12:52:53 -0600 Subject: SGI Personal Iris 4D/35 Message-ID: I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've got vertical lines appearing on the screen, but not everywhere on the screen; that seems to hint at an issue with one buffer having bad memory. It was especially evident in the flight simulator demo, where alternating frames flashed with and without lines. The ever helpful self test says, "ERROR: Failure detected in the Electronics Module (graphics). press to continue". The system is equipped with the ZB3 and BP4 on a GR1.2. How can I better diagnose this issue? There are so many RAM chips soldered on these three boards. Tracking it down to a single chip sure would be nice. Thanks! Kyle From aek at bitsavers.org Sat Feb 9 12:56:10 2019 From: aek at bitsavers.org (Al Kossow) Date: Sat, 9 Feb 2019 10:56:10 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: References: <9f4b0cd1-3b68-76c0-437d-53f9f2506a2b@figureeightbrewing.com> Message-ID: <18a7c903-20db-8602-1c4b-f924f1f9d2b1@bitsavers.org> On 2/9/19 10:39 AM, Al Kossow via cctalk wrote: > There is also an MIT compiler tape around with a bunch of different PCC ports > including the Brooklyn Poly x86 compiler. http://bitsavers.org/bits/MIT/trix/MIT_Compiler_Tape was mistaken about the x86 compiler origins there are a lot more versions on there than I remembered. the Trix compiler also has a lot more assembler in it that I thought it probably doesn't belong under 'trix' but I don't actually know where this collection came from. From aek at bitsavers.org Sat Feb 9 12:58:49 2019 From: aek at bitsavers.org (Al Kossow) Date: Sat, 9 Feb 2019 10:58:49 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: <8a4a3639-b21b-3b23-e7a0-9a21e2bc861c@bitsavers.org> References: <20190207160505.37FA618C075@mercury.lcs.mit.edu> <8a4a3639-b21b-3b23-e7a0-9a21e2bc861c@bitsavers.org> Message-ID: On 2/9/19 10:35 AM, Al Kossow via cctalk wrote: > > > On 2/7/19 8:05 AM, Noel Chiappa via cctalk wrote: > >> I have the man pages for it, the assembler and linker, the c.out format it >> produced, etc if those are any use/interest. > > I have a source tape. I'm trying to figure out why modern tar doesn't understand it. > > I must have found the problem a while ago. It's already up under bits/Alcyon From jnc at mercury.lcs.mit.edu Sat Feb 9 13:02:38 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 9 Feb 2019 14:02:38 -0500 (EST) Subject: Looking for: 68000 C compilers Message-ID: <20190209190238.EDCDE18C074@mercury.lcs.mit.edu> > From: Al Kossow > I have a source tape. I'm trying to figure out why modern tar doesn't > understand it. I had an issue reading some TAR's of Unix V7 stuff; I brought up an older version of TAR under Windoze and they read fine with it. I don't recall if I figured out what the problem was, or if I just wanted the bits, and as soon as I had them, dropped it. Noel From nw at retrocomputingtasmania.com Sat Feb 9 22:20:15 2019 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Sun, 10 Feb 2019 15:20:15 +1100 Subject: various scans Message-ID: Been catching up on a backlog of scanning, grab what you like. Manuals indicated with an asterisk are available for cost of packing+shipping if you want something printed. This offer will expire in about a week so please indicate interest early. Burroughs [1] * B2000_B3000_B4000 Work Flow Language Reference Manual Oct-1980 * B4000_B3000_B2000 Series BPL Reference Manual Jul-1978 * B4000_B3000_B2000 Series Data Management System II Users Manual Mar-1979 * B4000_B3000_B2000 Series DMS II DASDL Reference Manual May-1979 * B4000_B3000_B2000 Series DMS II Host Language Reference Manual May-1979 BJ-8-B8500 System Reference Manual May 1967 Various B6700 manufacturing documents Burroughs TD700 manuals [2] TD700 Central Control Schematic TD700 Display Assembly (Head Unit) A2 TD700 Keyboard Assembly A1 TD700 Logic and Power Supply Assembly TD700 Power Supply schematic TD700 PW Board Assembly driver (interim) TD700 Unit Travel Log Misc [3] * Freedom 220 USERS MANUAL Preliminary Edition * Microsoft utility software package reference manual for 8080 microprocessors 8102-343-04 * The COPS Programming Manual National Semiconductor Feb 1985 [2] * Users Manual for the VG-920 Terminal (Tentative) * CPL is a First Aid Kit by Dr AA Grainger UTAS CC [1] https://drive.google.com/drive/folders/1GXEU_kWWKo4btixnrQLRa5qFjZm9uqCM [2] https://drive.google.com/open?id=1iihVNRfkd_zX_PwV30gKQTNLzLcnMEvm [3] https://drive.google.com/drive/folders/1VEiZs1j11VPBYaZrNUaDxSpKWiZasfCC From kylevowen at gmail.com Sun Feb 10 13:26:01 2019 From: kylevowen at gmail.com (Kyle Owen) Date: Sun, 10 Feb 2019 14:26:01 -0500 Subject: Bellmac 8 Tutor on ebay In-Reply-To: References: <2050040007.18068243.1547440514556.ref@mail.yahoo.com> <2050040007.18068243.1547440514556@mail.yahoo.com> Message-ID: Bringing up a bit of an old thread here, as I just picked up one of these yesterday. Typed in some example programs, which took far too long thanks to a bouncy keypad. But hey, at least it works! Were there any real applications for the MAC-8? Haven't been able to find much. Thanks, Kyle From couryhouse at aol.com Sun Feb 10 13:49:25 2019 From: couryhouse at aol.com (ED SHARPE) Date: Sun, 10 Feb 2019 19:49:25 +0000 (UTC) Subject: Bellmac 8 Tutor on ebay References: <402414340.1284107.1549828165284.ref@mail.yahoo.com> Message-ID: <402414340.1284107.1549828165284@mail.yahoo.com> telephone? gear? ed# In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes: Bringing up a bit of an old thread here, as I just picked up one of these yesterday. Typed in some example programs, which took far too long thanks to a bouncy keypad. But hey, at least it works! Were there any real applications for the MAC-8? Haven't been able to find much. Thanks, Kyle From kylevowen at gmail.com Sun Feb 10 15:33:13 2019 From: kylevowen at gmail.com (Kyle Owen) Date: Sun, 10 Feb 2019 16:33:13 -0500 Subject: SGI Personal Iris 4D/35 In-Reply-To: References: Message-ID: Here's some pictures of the system: http://imgur.com/a/NNA2xYq Thanks, Kyle From kylevowen at gmail.com Sun Feb 10 17:37:33 2019 From: kylevowen at gmail.com (Kyle Owen) Date: Sun, 10 Feb 2019 18:37:33 -0500 Subject: Hickok MEM-70 Core Memory Trainer Message-ID: Picked up this core memory trainer yesterday. Seems pretty obscure. http://imgur.com/a/TIOvt7r Has anyone seen one before? Would love to find some documents someday. Thanks, Kyle From cclist at sydex.com Sun Feb 10 18:00:42 2019 From: cclist at sydex.com (Chuck Guzis) Date: Sun, 10 Feb 2019 16:00:42 -0800 Subject: Hickok MEM-70 Core Memory Trainer In-Reply-To: References: Message-ID: <2bfd42f6-d623-9e34-fab4-3cee204744a9@sydex.com> On 2/10/19 3:37 PM, Kyle Owen via cctalk wrote: > Picked up this core memory trainer yesterday. Seems pretty obscure. > > http://imgur.com/a/TIOvt7r > > Has anyone seen one before? Would love to find some documents someday. > > Thanks, Looks interesting--I wonder if this is the same Hickock that made test equipment. --Chuck From rtomek at ceti.pl Sun Feb 10 19:53:09 2019 From: rtomek at ceti.pl (Tomasz Rola) Date: Mon, 11 Feb 2019 02:53:09 +0100 Subject: Amiga, AtariST, soft repos [was: Re: Looking for: 68000 C compilers] In-Reply-To: References: <20190206162144.GA27182@tau1.ceti.pl> <0BE31D04-C0B9-4178-9B42-BCDC01461369@hoffart.de> <20190206211357.GB27182@tau1.ceti.pl> <20190207151631.D41CD4E83A@mx2.ezwind.net> <20190207213256.GA12998@tau1.ceti.pl> Message-ID: <20190211015309.GA22853@tau1.ceti.pl> Guys, Thanks for the tips and info. Wrt: - C-Lab Notator - I do not think I will need this, as it seems to be musician's stuff. - Amiga vs Atari quality - I have never had any hands on experience with AtariST, so I will stick to other people's opinions for a while... - TOSEC - I have checked and they are mentioned in Wikipedia: https://en.wikipedia.org/wiki/TOSEC : "The Old School Emulation Center (TOSEC) is a retrocomputing initiative founded in February 2000 initially for the renaming and cataloging of software files intended for use in emulators" and their website works - cool. The verdict for me, so far, is that in short term I will stick to trying some AtariST emulator and see how far it takes me. Long term, the chance I go back to Amiga seems a bit higher now. I have no intention to play games (well, maybe some) and want to see how useful such emulators can be for playing with Forth or MK68 assembler. At least such is wishful thinking because I cannot divert too much time yet and besides I remember a post from alt.sysadmin.recovery decades ago where a guy played with virtual machine at work, then came home to play with IIRC mac emulation on windows emulation on something and he sounded a bit insane (kind of "have I woke up from the simulation or I am in upper level simulation" syndrome, only perhaps he thought he was a computer)... So I got to thread gently, I guess? Anyway, this small project is far away & stuck in a fifo right now. I am just collecting threads to connect them later. Thanks for help. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From jnc at mercury.lcs.mit.edu Mon Feb 11 07:04:29 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Feb 2019 08:04:29 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190211130429.D7EF318C08C@mercury.lcs.mit.edu> > From: Fritz Mueller > If, as you are suspecting, we find damning evidence pointing > specifically to the RK11 I got an update from Fritz. As you all will recall, the problem seemed to be a corrupted 'pure text'. So the question was 'when was it damaged, and how'. After some confusion caused by different OS images (the 'Ritchie' and 'Wellsch' distros), he managed to get a look at the text in main memory after it was first read in from the file system, and before it was swapped out (it was showing up damaged after a swap out/in cycle); it looked good at that point. The copy written out to the swap disk however, not so good. A look at the RK11 registers after the swap-out showed an anomaly; something about the extended memory address bits? (Maybe a multi-block transfer than crosses a 64KB boundary? That would explain the address sensitivity we were seeing.) Hopefully he'll track it to its lair shortly. We also need to characterize exactly what the fault is, because the DEC RK11 diagnostics weren't finding it, so it seems the diagnostic suite could use an enhancement.... Noel From gerardcjat at free.fr Mon Feb 11 09:32:54 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Mon, 11 Feb 2019 16:32:54 +0100 Subject: HP1000 L series, FULL LIST ( UPDATED ) Message-ID: <7435E1DB29D24BCF9A356EC1D6C1814F@medion> All boards are corroded. May be some can be saved ? I am offering : 12002 B XL Ctrl 512 Kb 51x0-013 x = ? Pictures available 12001 C CPU 12001-80001 Has the 1AB5-6001 "HP SoS processor" with Two EPROM ( 12001-80006 and 80007 ) Any interest in imaging these ? BUT, ** I ** cannot do it ! A ser Qty TWO 12005-60010 Has the 1AF5-6001 "HP SoS processor" HP_IB 12009-6x00 x=? with 1AA6-6004 and 1AC5-6001 12021A Cntrl R 12021-60001 has the 3 Eprom and Nec P16175-12 / Intel D8291A / ? FD1791A Eprom : 2116, white ceramic, labeled : 5180 - 0144, 0137, 0136 ( U43, U53, U63 ) Any interest in imaging these ? BUT, ** I ** cannot do it ! Backplane 2 column, 4 row .... a slight scrubbing may be enough Card Cage, if needed : Fine Power supply seems in great condition. Will check more closely, if needed. Battery board !!!!! Only the relays and buzzer can be saved ! Case ?? Who would like a case ?? ;-) TERMS : Remember : I live in France ( shipping ..... ) Small item ... free Medium items ( cards ) ..... shipping cost Large items .... shipping cost plus a fee for packing material and my time. Will wait a full week, to see if BOARDS are asked for, before making PARTS available. From gerardcjat at free.fr Mon Feb 11 09:32:54 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Mon, 11 Feb 2019 16:32:54 +0100 Subject: HP1000 L series, FULL LIST ( UPDATED ) Message-ID: <7435E1DB29D24BCF9A356EC1D6C1814F@medion> All boards are corroded. May be some can be saved ? I am offering : 12002 B XL Ctrl 512 Kb 51x0-013 x = ? Pictures available 12001 C CPU 12001-80001 Has the 1AB5-6001 "HP SoS processor" with Two EPROM ( 12001-80006 and 80007 ) Any interest in imaging these ? BUT, ** I ** cannot do it ! A ser Qty TWO 12005-60010 Has the 1AF5-6001 "HP SoS processor" HP_IB 12009-6x00 x=? with 1AA6-6004 and 1AC5-6001 12021A Cntrl R 12021-60001 has the 3 Eprom and Nec P16175-12 / Intel D8291A / ? FD1791A Eprom : 2116, white ceramic, labeled : 5180 - 0144, 0137, 0136 ( U43, U53, U63 ) Any interest in imaging these ? BUT, ** I ** cannot do it ! Backplane 2 column, 4 row .... a slight scrubbing may be enough Card Cage, if needed : Fine Power supply seems in great condition. Will check more closely, if needed. Battery board !!!!! Only the relays and buzzer can be saved ! Case ?? Who would like a case ?? ;-) TERMS : Remember : I live in France ( shipping ..... ) Small item ... free Medium items ( cards ) ..... shipping cost Large items .... shipping cost plus a fee for packing material and my time. Will wait a full week, to see if BOARDS are asked for, before making PARTS available. From elson at pico-systems.com Mon Feb 11 10:12:57 2019 From: elson at pico-systems.com (Jon Elson) Date: Mon, 11 Feb 2019 10:12:57 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190211130429.D7EF318C08C@mercury.lcs.mit.edu> References: <20190211130429.D7EF318C08C@mercury.lcs.mit.edu> Message-ID: <5C619F09.7080905@pico-systems.com> On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote: > A look at the RK11 registers after the swap-out showed an anomaly; something > about the extended memory address bits? (Maybe a multi-block transfer than > crosses a 64KB boundary? That would explain the address sensitivity we were > seeing.) Hopefully he'll track it to its lair shortly. > > OH, BOY! I think you may have found it. Likely some disk controllers did NOT SUPPORT crossing 64K boundaries! The diags would not detect that, as it was likely expected behavior. I would suspect the driver would need to break up these operations. Jon From harper at secureoutcomes-hq.com Mon Feb 11 10:42:33 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Mon, 11 Feb 2019 09:42:33 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> Message-ID: <20190211164238.6E9934E6D6@mx2.ezwind.net> At 11:39 AM 2/7/2019, Chuck Guzis via cctalk wrote: >On 2/7/19 9:16 AM, Jack Harper via cctalk wrote: > > > I mounted the two HP7970 Drives in a non-HP rack - just a standard > > six-foot 19" rack that I found a few years ago. > > > > I installed two heavy aluminum rails (1/8" thick and perhaps 2" on the > > two sides - angle stock) for each Drive to support the 130-pound weight > > of each. > >That makes a lot of sense and doesn't look too difficult to fab up from >stock. Or if you're not handy with metalworking, these would do the >same job: > >https://www.hammfg.com/dci/products/accessories/raab > >That way, the right-side bolts serve to keep the thing in the rack. > >The Fujitsu drive that I use weighs more than the HP and doesn't even >have "ears" to mount to the rack rails--it uses a sliding arrangement >like many large disk drives. Fasten one part of the slides to the rack >and the other to the drive and just slide the drive in--there are bolts >to secure the slide position once the drive is in place. > >--Chuck Hello Chuck - I like the idea of those sliding rails - and they appear by the link to be good to 200-pounds. However, with the HP7970 Drives, I would worry about the moment pressure exerted on the rack with the unit slid all the way out. In addition, the HP7970 front is hinged and opens completely to expose all of the electronics, drive motors etc. The 19" rack that I have is actually fairly flimsy and I worried about the thing flexing with the stop/start (15ms stop) of the two Tape Drives. Last thing I want is for the tape rack to start wandering about the room with tape action like some of the early disk drives (I remember reading that the original "large" UNIVAC Fastrand drum units laying horizontal would turn circles by gyroscopic action as the Earth rotated :) However, I do not expect that to be a problem as I think/hope that the two drives mounted in the rack will stiffen it sufficiently - we shall see. I plan to put sheet metal on the back of the rack ground to top to protect from dust and with a fan to create positive pressure - sort of a monocoque structure like old airplanes, which are quite strong. Best to the List - Jack in the Rocky Mountains ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From cisin at xenosoft.com Mon Feb 11 11:16:35 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 11 Feb 2019 09:16:35 -0800 (PST) Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190211164238.6E9934E6D6@mx2.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> <20190211164238.6E9934E6D6@mx2.ezwind.net> Message-ID: On Mon, 11 Feb 2019, Jack Harper via cctalk wrote: > Hello Chuck - > I like the idea of those sliding rails - and they appear by the link to be > good to 200-pounds. > However, with the HP7970 Drives, I would worry about the moment pressure > exerted on the rack with the unit slid all the way out. > . . . > The 19" rack that I have is actually fairly flimsy and I worried about the > thing flexing with the stop/start (15ms stop) of the two Tape Drives. > > Last thing I want is for the tape rack to start wandering about the room with > tape action like some of the early disk drives (I remember reading that the > original "large" UNIVAC Fastrand drum units laying horizontal would turn > circles by gyroscopic action as the Earth rotated :) A few hundred pounds slid all the way out will topple it. If the center of gravity is NOT within the perimeter of the base, . . . Need to bolt the rear to the floor, or something SOLID, and extend the "footprint" of the front to include where the center of gravity is when fully extended. And a bit more, so that setting a tool or elbow on it doesn't topple it. From ard.p850ug1 at gmail.com Mon Feb 11 11:34:11 2019 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Mon, 11 Feb 2019 17:34:11 +0000 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <5C619F09.7080905@pico-systems.com> References: <20190211130429.D7EF318C08C@mercury.lcs.mit.edu> <5C619F09.7080905@pico-systems.com> Message-ID: On Mon, Feb 11, 2019 at 4:13 PM Jon Elson via cctalk wrote: > > On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote: > > A look at the RK11 registers after the swap-out showed an anomaly; something > > about the extended memory address bits? (Maybe a multi-block transfer than > > crosses a 64KB boundary? That would explain the address sensitivity we were > > seeing.) Hopefully he'll track it to its lair shortly. > > > > > OH, BOY! I think you may have found it. Likely some disk > controllers did NOT SUPPORT crossing 64K boundaries! The > diags would not detect that, as it was likely expected > behavior. I would suspect the driver would need to break up > these operations. I _think_ the RK11-C should cross a 64K boundary correctly. There's an output from the low 16 bits bus address module (M795) on pin BP2 'D15 RKBA=ALL 1 L' (page 27 of the schematic on Bitsavers) that goes to the counter that holds the 2 extended bits, pin C1 of the M239 in slot A17 (page 13 of the same .pdf) [I am working from 'RK11-C_schemFeb1971.pdf' from bitsavers] Of course if there is a fault in this area then it will not correctly increment the top 2 bits, but that might give you somewhere to check. -tony From paulkoning at comcast.net Mon Feb 11 11:50:56 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Feb 2019 12:50:56 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <5C619F09.7080905@pico-systems.com> References: <20190211130429.D7EF318C08C@mercury.lcs.mit.edu> <5C619F09.7080905@pico-systems.com> Message-ID: <661B3126-6240-4FE8-8377-504274BC0425@comcast.net> > On Feb 11, 2019, at 11:12 AM, Jon Elson via cctalk wrote: > > On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote: >> A look at the RK11 registers after the swap-out showed an anomaly; something >> about the extended memory address bits? (Maybe a multi-block transfer than >> crosses a 64KB boundary? That would explain the address sensitivity we were >> seeing.) Hopefully he'll track it to its lair shortly. >> >> > OH, BOY! I think you may have found it. Likely some disk controllers did NOT SUPPORT crossing 64K boundaries! The diags would not detect that, as it was likely expected behavior. I would suspect the driver would need to break up these operations. You may be thinking about PC controllers like the floppy controller. I can't remember ANY DEC DMA device controller that had boundary crossing limits of any kind. It certainly isn't a restriction in the RK11. paul From jnc at mercury.lcs.mit.edu Mon Feb 11 12:03:02 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Feb 2019 13:03:02 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190211180302.6F59C18C08F@mercury.lcs.mit.edu> > From: Jon Elson > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries! No; the RK11 spec says "[the two extended memory bits] make up a two-bit counter that increments each time the RKBA overflows". The actual error turns out to be slightly different to my guess; there's a spurious overflow from the low 16-bit register to these bits at 0170000. I can see how the diags didn't catch that one! Unless you try a multi-block xfer that walks across the boundary.... A perfect example of Vonada #12. Noel From spacewar at gmail.com Mon Feb 11 12:01:25 2019 From: spacewar at gmail.com (Eric Smith) Date: Mon, 11 Feb 2019 11:01:25 -0700 Subject: sun 88780 on ebay In-Reply-To: References: Message-ID: On Mon, Jan 28, 2019 at 6:03 PM Al Kossow via cctalk wrote: > https://www.ebay.com/itm/132933407806 > It was packaged improperly by the seller and destroyed in transit. From ard.p850ug1 at gmail.com Mon Feb 11 12:07:32 2019 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Mon, 11 Feb 2019 18:07:32 +0000 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190211180302.6F59C18C08F@mercury.lcs.mit.edu> References: <20190211180302.6F59C18C08F@mercury.lcs.mit.edu> Message-ID: On Mon, Feb 11, 2019 at 6:03 PM Noel Chiappa via cctalk wrote: > > > From: Jon Elson > > > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries! > > No; the RK11 spec says "[the two extended memory bits] make up a two-bit > counter that increments each time the RKBA overflows". > > The actual error turns out to be slightly different to my guess; there's > a spurious overflow from the low 16-bit register to these bits at 0170000. Maybe a problem with E29 or E34 on the M795 module? -tony From fritzm at fritzm.org Mon Feb 11 12:08:16 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Mon, 11 Feb 2019 10:08:16 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190211180302.6F59C18C08F@mercury.lcs.mit.edu> References: <20190211180302.6F59C18C08F@mercury.lcs.mit.edu> Message-ID: Yup; specifically, the symptoms are consistent with 'D15 RKBA=ALL 1 L' being incorrectly generated at BA 167777, causing an increment to EX.MEM, causing a skip in the DMA. So it looks like problem with bit 12 in that carry logic; I'll check E28 and E34 when I get back to it tonight, but I have to move the machine around so I can climb inside :-) --FritzM. From cclist at sydex.com Mon Feb 11 12:08:38 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 11 Feb 2019 10:08:38 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> <20190211164238.6E9934E6D6@mx2.ezwind.net> Message-ID: <088b3e8a-4543-9340-d4ee-5901f599bc69@sydex.com> On 2/11/19 9:16 AM, Fred Cisin via cctalk wrote: > A few hundred pounds slid all the way out will topple it. > If the center of gravity is NOT within the perimeter of the base, . . . > Need to bolt the rear to the floor, or something SOLID, and extend the > "footprint" of the front to include where the center of gravity is when > fully extended.? And a bit more, so that setting a tool or elbow on it > doesn't topple it. That's one of the reasons that a lot of computer racks have an "anti-tip" slideout on the bottom. It should be pretty simple to fabricate one, if you're handy with a welder. Basically, just some square tube stock fashioned into a "T". It'd let you keep the casters on the bottom of the rack. --Chuck From cclist at sydex.com Mon Feb 11 12:11:52 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 11 Feb 2019 10:11:52 -0800 Subject: sun 88780 on ebay In-Reply-To: References: Message-ID: <60f932fe-170f-3ccc-4c90-41f47c0356fe@sydex.com> On 2/11/19 10:01 AM, Eric Smith via cctalk wrote: > On Mon, Jan 28, 2019 at 6:03 PM Al Kossow via cctalk > wrote: > >> https://www.ebay.com/itm/132933407806 >> > > It was packaged improperly by the seller and destroyed in transit. Happens all too often. Palletizing is probably the safest, but try and get a seller to do that. --Chuck From jnc at mercury.lcs.mit.edu Mon Feb 11 12:12:45 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Feb 2019 13:12:45 -0500 (EST) Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive Message-ID: <20190211181245.BFBC318C092@mercury.lcs.mit.edu> > From: Alan Frisbie > Harbor Freight sells a nice hydraulic lift table for under $200 that I > have found very useful for that sort of thing. It doesn't go up very high > (like for the top of a rack), but I used it with some wood blocks Thanks for the tip! I got one on sale for about US$140; it's _very_ sturdy. And the top is just large enough to hold two milk crates (available at Home Depot, BTW), so it's guite easy to build up a stack as high as one needs to reach the top of a 6' rack. Noel From jsw at ieee.org Mon Feb 11 12:13:09 2019 From: jsw at ieee.org (Jerry Weiss) Date: Mon, 11 Feb 2019 12:13:09 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <661B3126-6240-4FE8-8377-504274BC0425@comcast.net> References: <20190211130429.D7EF318C08C@mercury.lcs.mit.edu> <5C619F09.7080905@pico-systems.com> <661B3126-6240-4FE8-8377-504274BC0425@comcast.net> Message-ID: On 2/11/19 11:50 AM, Paul Koning via cctalk wrote: >> On Feb 11, 2019, at 11:12 AM, Jon Elson via cctalk wrote: >> >> On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote: >>> A look at the RK11 registers after the swap-out showed an anomaly; something >>> about the extended memory address bits? (Maybe a multi-block transfer than >>> crosses a 64KB boundary? That would explain the address sensitivity we were >>> seeing.) Hopefully he'll track it to its lair shortly. >>> >>> >> OH, BOY! I think you may have found it. Likely some disk controllers did NOT SUPPORT crossing 64K boundaries! The diags would not detect that, as it was likely expected behavior. I would suspect the driver would need to break up these operations. > You may be thinking about PC controllers like the floppy controller. I can't remember ANY DEC DMA device controller that had boundary crossing limits of any kind. It certainly isn't a restriction in the RK11. > > paul > Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K boundaries. I did however via a single chip "dead bug" modification, modify one to accomplish this. ??? Jerry From aek at bitsavers.org Mon Feb 11 12:18:52 2019 From: aek at bitsavers.org (Al Kossow) Date: Mon, 11 Feb 2019 10:18:52 -0800 Subject: sun 88780 on ebay In-Reply-To: References: Message-ID: <1c0977a8-2456-ec01-8666-3dc1361def23@bitsavers.org> Does it have the 800 bpi option board? On 2/11/19 10:01 AM, Eric Smith wrote: > On Mon, Jan 28, 2019 at 6:03 PM Al Kossow via cctalk > wrote: > > https://www.ebay.com/itm/132933407806 > > > It was packaged improperly by the seller and destroyed in transit. > From harper at secureoutcomes-hq.com Mon Feb 11 12:24:01 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Mon, 11 Feb 2019 11:24:01 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> <20190211164238.6E9934E6D6@mx2.ezwind.net> Message-ID: <20190211182408.637EC4E73A@mx2.ezwind.net> At 10:16 AM 2/11/2019, Fred Cisin via cctalk wrote: >On Mon, 11 Feb 2019, Jack Harper via cctalk wrote: >>Hello Chuck - >>I like the idea of those sliding rails - and they appear by the >>link to be good to 200-pounds. >>However, with the HP7970 Drives, I would worry about the moment >>pressure exerted on the rack with the unit slid all the way out. >>. . . The 19" rack that I have is actually fairly flimsy and I >>worried about the thing flexing with the stop/start (15ms stop) of >>the two Tape Drives. >>Last thing I want is for the tape rack to start wandering about the >>room with tape action like some of the early disk drives (I >>remember reading that the original "large" UNIVAC Fastrand drum >>units laying horizontal would turn circles by gyroscopic action as >>the Earth rotated :) > >A few hundred pounds slid all the way out will topple it. >If the center of gravity is NOT within the perimeter of the base, . . . >Need to bolt the rear to the floor, or something SOLID, and extend >the "footprint" of the front to include where the center of gravity >is when fully extended. And a bit more, so that setting a tool or >elbow on it doesn't topple it. I agree 100% Fred... ...and once 300+ pounds of heavy ancient computer iron begins to topple, life becomes more exciting :) I bolted the 19" rack with the two HP7970 drives down to a 3/4" thick plywood base about 36" square or so and then anchored that to the concrete floor - before I installed the drives. See http://frobenius.com/190203%20Tape%20Drive5.jpg for yet another exciting photo :) Best to the List - Jack in the Rocky Mountains. ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From paulkoning at comcast.net Mon Feb 11 12:29:48 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Feb 2019 13:29:48 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <20190211130429.D7EF318C08C@mercury.lcs.mit.edu> <5C619F09.7080905@pico-systems.com> <661B3126-6240-4FE8-8377-504274BC0425@comcast.net> Message-ID: <185893A0-49C9-4144-826E-D6CCBD83324E@comcast.net> > On Feb 11, 2019, at 1:13 PM, Jerry Weiss wrote: > > On 2/11/19 11:50 AM, Paul Koning via cctalk wrote: >>> ... >> You may be thinking about PC controllers like the floppy controller. I can't remember ANY DEC DMA device controller that had boundary crossing limits of any kind. It certainly isn't a restriction in the RK11. >> >> paul >> > Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K boundaries. > > I did however via a single chip "dead bug" modification, modify one to accomplish this. > > Jerry That's rather shocking. I meant my comment to apply to every DMA controller, not just disks. I never used the DR11-B, though. Perhaps there are other obscure devices that get this wrong. But, for example, even devices like DMC-11 and TS-11 got it right. There are of course Q-bus devices that only do a partial address space, but my point is that whatever the number of address bits implemented, address arithmetic is as a matter of normal design done across all of them, not across a subset. paul From jnc at mercury.lcs.mit.edu Mon Feb 11 12:31:50 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Feb 2019 13:31:50 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190211183150.05FDD18C092@mercury.lcs.mit.edu> > From: Jerry Weiss > Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K > boundaries. Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219) from the RC11 controller, and that _can_ cross moby boundaries, so clearly it has the right overflow output; someone just decided not to implement it - the DR11-B sets ERROR instead on an address overflow. Wierd. Anyway, it will be interesting to see if RSTS operates correctly once this problem is fixed... Noel From mtapley at swri.edu Mon Feb 11 12:48:59 2019 From: mtapley at swri.edu (Tapley, Mark) Date: Mon, 11 Feb 2019 18:48:59 +0000 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190211182408.637EC4E73A@mx2.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> <20190211164238.6E9934E6D6@mx2.ezwind.net> <20190211182408.637EC4E73A@mx2.ezwind.net> Message-ID: <49DB86C3-3116-4E40-86D8-C03AAD751A6C@swri.edu> > On Feb 11, 2019, at 12:24 PM, Jack Harper via cctalk wrote: > > At 10:16 AM 2/11/2019, Fred Cisin via cctalk wrote: >> ...Need to bolt the rear to the floor, or something SOLID, and extend the "footprint" of the front to include where the center of gravity is when fully extended. And a bit more, so that setting a tool or elbow on it doesn't topple it. > > I bolted the 19" rack with the two HP7970 drives down to a 3/4" thick plywood base about 36" square or so and then anchored that to the concrete floor - before I installed the drives. > > See http://frobenius.com/190203%20Tape%20Drive5.jpg for yet another exciting photo :) > > > Best to the List - > > Jack in the Rocky Mountains. Jack, this looks like a pretty good idea in the short term. But, every piece of concrete I have ever been associated with has been off-gassing water at a slow rate. I have stored wood face-down on concrete enough times that I should know better, and it has always been ruined - rotted - by constant exposure to that water off-gassing. The wood traps the water (which would normally have no problem evaporating, because it is a very slow rate) which then rots the wood. Now whenever I store wood flat, I put bricks or something between it and the concrete so there is an air-gap. Unless there is a pretty impermeable water barrier between the plywood and the concrete, I would say that solution is not trustable for more than about 6 months of service at the outside. Even if there is, I would check pretty often around the bolt holes, because I think the bolts penetrated the barrier and the wood around the bolts will be rotten soon. Comments and corrections most welcome from anyone who has more experience, of course; YMMV and I Am Not a Carpenter? - Mark From harper at secureoutcomes-hq.com Mon Feb 11 13:14:19 2019 From: harper at secureoutcomes-hq.com (Jack Harper) Date: Mon, 11 Feb 2019 12:14:19 -0700 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <49DB86C3-3116-4E40-86D8-C03AAD751A6C@swri.edu> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> <20190211164238.6E9934E6D6@mx2.ezwind.net> <20190211182408.637EC4E73A@mx2.ezwind.net> <49DB86C3-3116-4E40-86D8-C03AAD751A6C@swri.edu> Message-ID: <20190211191425.5C1AD27421@mx1.ezwind.net> At 11:48 AM 2/11/2019, Tapley, Mark wrote: > > On Feb 11, 2019, at 12:24 PM, Jack Harper via > cctalk wrote: > > > > At 10:16 AM 2/11/2019, Fred Cisin via cctalk wrote: > >> ...Need to bolt the rear to the floor, or > something SOLID, and extend the "footprint" of > the front to include where the center of > gravity is when fully extended. And a bit > more, so that setting a tool or elbow on it doesn't topple it. > > > > I bolted the 19" rack with the two HP7970 > drives down to a 3/4" thick plywood base about > 36" square or so and then anchored that to the > concrete floor - before I installed the drives. > > > > See > http://frobenius.com/190203%20Tape%20Drive5.jpg > for yet another exciting photo :) > > > > > > Best to the List - > > > > Jack in the Rocky Mountains. > >Jack, this looks like a pretty good idea in the >short term. But, every piece of concrete I have >ever been associated with has been off-gassing >water at a slow rate. I have stored wood >face-down on concrete enough times that I should >know better, and it has always been ruined - >rotted - by constant exposure to that water >off-gassing. The wood traps the water (which >would normally have no problem evaporating, >because it is a very slow rate) which then rots >the wood. Now whenever I store wood flat, I put >bricks or something between it and the concrete so there is an air-gap. > >Unless there is a pretty impermeable water >barrier between the plywood and the concrete, I >would say that solution is not trustable for >more than about 6 months of service at the >outside. Even if there is, I would check pretty >often around the bolt holes, because I think the >bolts penetrated the barrier and the wood around the bolts will be rotten soon. > >Comments and corrections most welcome from >anyone who has more experience, of course; YMMV and I Am Not a Carpenter > - Mark Well, amazing indeed Mark - I can see the headline now: "Local Computer Nerd Squished and Killed Instantly by Collapsing Rack of Ancient Electronics of Unknown Purpose. Body Mangled Horribly beyond Recognition. Nerd asked to be Buried with Ashes of Cat and Thumb Drive of what appears to be Software from the 1970's". I did not know that about concrete and wood. I will definitely keep an eye on the thing. The Good News is that it is extremely dry with very low humidity here at 8,000-feet (2,300 meters) elevation. Best to the List - Jack in the Rocky Mountains. ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info. From paulkoning at comcast.net Mon Feb 11 13:40:08 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 11 Feb 2019 14:40:08 -0500 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <20190211191425.5C1AD27421@mx1.ezwind.net> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> <20190211164238.6E9934E6D6@mx2.ezwind.net> <20190211182408.637EC4E73A@mx2.ezwind.net> <49DB86C3-3116-4E40-86D8-C03AAD751A6C@swri.edu> <20190211191425.5C1AD27421@mx1.ezwind.net> Message-ID: <5A476ECF-21F3-417D-85EE-D51C302EB129@comcast.net> > On Feb 11, 2019, at 2:14 PM, Jack Harper via cctalk wrote: > > At 11:48 AM 2/11/2019, Tapley, Mark wrote: >> ... >> Jack, this looks like a pretty good idea in the short term. But, every piece of concrete I have ever been associated with has been off-gassing water at a slow rate. That sounds right. Concrete is known for retaining water. This is the basis of the Ufer ground -- a ground wire encased in concrete, used in bad soil where plain ground rods do not work adequately. paul From cclist at sydex.com Mon Feb 11 13:42:11 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 11 Feb 2019 11:42:11 -0800 Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive In-Reply-To: <49DB86C3-3116-4E40-86D8-C03AAD751A6C@swri.edu> References: <20190204234042.6D1EB2736F@mx1.ezwind.net> <100b9857-8395-81b8-065c-02922ea4e3dd@sydex.com> <20190205201958.2AB9227377@mx1.ezwind.net> <0fedb476-6dc2-36b0-6f04-d3984e6bb48e@sydex.com> <20190206172631.40756273FB@mx1.ezwind.net> <001401d4be47$0d9f0db0$28dd2910$@classiccmp.org> <20190207171648.A9A9A4E754@mx2.ezwind.net> <20190211164238.6E9934E6D6@mx2.ezwind.net> <20190211182408.637EC4E73A@mx2.ezwind.net> <49DB86C3-3116-4E40-86D8-C03AAD751A6C@swri.edu> Message-ID: On 2/11/19 10:48 AM, Tapley, Mark via cctalk wrote: > Jack, this looks like a pretty good idea in the short term. But, every piece of concrete I have ever been associated with has been off-gassing water at a slow rate. I have stored wood face-down on concrete enough times that I should know better, and it has always been ruined - rotted - by constant exposure to that water off-gassing. The wood traps the water (which would normally have no problem evaporating, because it is a very slow rate) which then rots the wood. Now whenever I store wood flat, I put bricks or something between it and the concrete so there is an air-gap. > > Unless there is a pretty impermeable water barrier between the plywood and the concrete, I would say that solution is not trustable for more than about 6 months of service at the outside. Even if there is, I would check pretty often around the bolt holes, because I think the bolts penetrated the barrier and the wood around the bolts will be rotten soon. > > Comments and corrections most welcome from anyone who has more experience, of course; YMMV and I Am Not a Carpenter? Yup, the first thing done to the concrete floor of my shop was to apply a sealer, then a layer of mastic and vinyl tile. (tile, not sheet goods, as it's simple to replace a damaged tile). It's held up well for almost 30 years, with no trace of moisture damage here in the soggy Pacific Northwest. The concrete walls were similarly isolated with a layer of 30 lb. roofing telt, with an insulated stud wall and sheetrock over it. --Chuck From jsw at ieee.org Mon Feb 11 14:22:31 2019 From: jsw at ieee.org (Jerry Weiss) Date: Mon, 11 Feb 2019 14:22:31 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190211183150.05FDD18C092@mercury.lcs.mit.edu> References: <20190211183150.05FDD18C092@mercury.lcs.mit.edu> Message-ID: On 2/11/19 12:31 PM, Noel Chiappa via cctalk wrote: > > From: Jerry Weiss > > > Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K > > boundaries. > > Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219) > from the RC11 controller, and that _can_ cross moby boundaries, so clearly it > has the right overflow output; someone just decided not to implement it - the > DR11-B sets ERROR instead on an address overflow. Wierd. ??? Yes the overflow sets error and halts the transfer.? There are registers for the extended bits in the DR11B, just missing a few gates to increment. ? My recollection is that my simple mod wouldn't allow the read back of the incremented extended bits, but in my use case this was never a problem. > Anyway, it will be interesting to see if RSTS operates correctly once this > problem is fixed... > > Noel > Yes if turns out the increment was not functional for one or both extended address bits, it is impressive that UNIX booted successfully without tripping over a boundary. ????????? Jerry From wdonzelli at gmail.com Mon Feb 11 14:25:02 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Mon, 11 Feb 2019 15:25:02 -0500 Subject: Wirewrap DIP sockets - any interest? Message-ID: Does anyone here still actively wire wrap circuits? I am thinking about dumping my inventory of nice machine pin wirewrap sockets. Lately they have been selling like lead balloons. Contact me off list. -- Will, in the Hudson Valley From spacewar at gmail.com Mon Feb 11 14:24:47 2019 From: spacewar at gmail.com (Eric Smith) Date: Mon, 11 Feb 2019 13:24:47 -0700 Subject: sun 88780 on ebay In-Reply-To: <1c0977a8-2456-ec01-8666-3dc1361def23@bitsavers.org> References: <1c0977a8-2456-ec01-8666-3dc1361def23@bitsavers.org> Message-ID: On Mon, Feb 11, 2019 at 11:18 AM Al Kossow wrote: > Does it have the 800 bpi option board? > I haven't yet unboxed it. I took photos of the outside of the destroyed box to send to the shipper. The front bottom left corner of the 88780 is visible through a hole in the box, and is visibly mangled. I'll take more photos as I unbox it tonight. Based on the service manual, it appears that option 800 requires: * buffer PCA 07980-6xx14 (512K) or 07980-6xx34 (1M) * read/write/formatter PCA 07980-6xx31 Were there any other hardware changes for option 800? If not, one wonders why HP documentation is adamant that it cannot be field-upgraded to option 800. From bill.gunshannon at hotmail.com Mon Feb 11 14:29:21 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 11 Feb 2019 20:29:21 +0000 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: Message-ID: On 2/11/19 3:25 PM, William Donzelli via cctalk wrote: > Does anyone here still actively wire wrap circuits? I am thinking > about dumping my inventory of nice machine pin wirewrap sockets. > Lately they have been selling like lead balloons. > > Contact me off list. > > -- > Will, in the Hudson Valley > I don't do it often, but I do still wire wrap. What do you have and what are you looking to get for them? I am not too far away, over the border in PA. Used to live in The Hudson Valley and still make fairly often trips to West Point. bill From bill.gunshannon at hotmail.com Mon Feb 11 14:30:49 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 11 Feb 2019 20:30:49 +0000 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: Message-ID: On 2/11/19 3:29 PM, Bill Gunshannon via cctalk wrote: > On 2/11/19 3:25 PM, William Donzelli via cctalk wrote: >> Does anyone here still actively wire wrap circuits? I am thinking >> about dumping my inventory of nice machine pin wirewrap sockets. >> Lately they have been selling like lead balloons. >> >> Contact me off list. >> >> -- >> Will, in the Hudson Valley >> > > I don't do it often, but I do still wire wrap. What do you > have and what are you looking to get for them? > > I am not too far away, over the border in PA. Used to live > in The Hudson Valley and still make fairly often trips to > West Point. > > bill > Sorry, I wanted this to go private but I guess the mailer had its own opinion. bill From wdonzelli at gmail.com Mon Feb 11 14:37:24 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Mon, 11 Feb 2019 15:37:24 -0500 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: Message-ID: I will start to gather them up. Basically, 25 cents for little guys (14s, 16s, etc), 50 cents for big guys (24s, 28s, 40s), and a buck for 28s and 40s with full gold plate. Obviously all DIPs. -- Will On Mon, Feb 11, 2019 at 3:29 PM Bill Gunshannon via cctalk wrote: > > On 2/11/19 3:25 PM, William Donzelli via cctalk wrote: > > Does anyone here still actively wire wrap circuits? I am thinking > > about dumping my inventory of nice machine pin wirewrap sockets. > > Lately they have been selling like lead balloons. > > > > Contact me off list. > > > > -- > > Will, in the Hudson Valley > > > > I don't do it often, but I do still wire wrap. What do you > have and what are you looking to get for them? > > I am not too far away, over the border in PA. Used to live > in The Hudson Valley and still make fairly often trips to > West Point. > > bill > From jnc at mercury.lcs.mit.edu Mon Feb 11 15:17:18 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Feb 2019 16:17:18 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190211211718.6678218C091@mercury.lcs.mit.edu> > From: Jerry Weiss > it is impressive that UNIX booted successfully without tripping over a > boundary. Well, V6 is (or can be configured to be) extraordinarily small, so I'm not surprised it booted OK without going over the 0170000 mark. I have this persistent memory that the -11/40 in the CSR group at MIT had only 3 banks of MM-L (@16KB each) when I first got there! Which is plausible; the smallest V6 config would have about 22KB of core text, and about 2KB of initialized data. If you cut all the parameters to the bone (minimal number of disk buffers, etc) you could probably get away with say 6KB of un-initialized data. That would leave you 18KB for user programs on such a system, a bit less than their recommendation of 24KB minimum for users, but probably minimally useable. We quickly added more memory, I'm sure, but I don't now remember how/what! Later on it was converted to an -11/45, and then we got an Able ENABLE, but that would have been a couple of years later. Noel From m.zahorik at sbcglobal.net Mon Feb 11 15:40:07 2019 From: m.zahorik at sbcglobal.net (mike) Date: Mon, 11 Feb 2019 15:40:07 -0600 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: Message-ID: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> Will I would be interested in some. Mike Zahorik (414) 254-6768 -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of William Donzelli via cctalk Sent: Monday, February 11, 2019 02:37 PM To: Bill Gunshannon; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Wirewrap DIP sockets - any interest? I will start to gather them up. Basically, 25 cents for little guys (14s, 16s, etc), 50 cents for big guys (24s, 28s, 40s), and a buck for 28s and 40s with full gold plate. Obviously all DIPs. -- Will On Mon, Feb 11, 2019 at 3:29 PM Bill Gunshannon via cctalk wrote: > > On 2/11/19 3:25 PM, William Donzelli via cctalk wrote: > > Does anyone here still actively wire wrap circuits? I am thinking > > about dumping my inventory of nice machine pin wirewrap sockets. > > Lately they have been selling like lead balloons. > > > > Contact me off list. > > > > -- > > Will, in the Hudson Valley > > > > I don't do it often, but I do still wire wrap. What do you > have and what are you looking to get for them? > > I am not too far away, over the border in PA. Used to live > in The Hudson Valley and still make fairly often trips to > West Point. > > bill > From ball.of.john at gmail.com Mon Feb 11 19:02:35 2019 From: ball.of.john at gmail.com (John Ball) Date: Mon, 11 Feb 2019 17:02:35 -0800 Subject: SGI Personal Iris 4D/35 In-Reply-To: Message-ID: Hey Kyle. You can narrow things down a bit by removing the optional Z-buffer and additional bitplane memory (ZB3 and BP4). While that removes those two masses of memory out of the equation that still leaves the still massive amount of ZIPP base video memory. for the later Onyx systems I've only seen pinstriping when the video memory or supporting glue has been allowed to overheat. I can't recall if it tests the graphics as well but have you tried running the ide diagnostics in case that refines the error a little? -John >I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've >got vertical lines appearing on the screen, but not everywhere on the >screen; that seems to hint at an issue with one buffer having bad memory. >It was especially evident in the flight simulator demo, where alternating >frames flashed with and without lines. > >The ever helpful self test says, "ERROR: Failure detected in the >Electronics Module (graphics). press to continue". > >The system is equipped with the ZB3 and BP4 on a GR1.2. > >How can I better diagnose this issue? There are so many RAM chips soldered >on these three boards. Tracking it down to a single chip sure would be >nice. > >Thanks! > >Kyle From kevin.bowling at kev009.com Mon Feb 11 19:23:30 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 11 Feb 2019 18:23:30 -0700 Subject: sun 88780 on ebay In-Reply-To: References: <1c0977a8-2456-ec01-8666-3dc1361def23@bitsavers.org> Message-ID: I am in the market for this option as well, after Al is taken care of if he needs it. On Mon, Feb 11, 2019 at 1:27 PM Eric Smith via cctalk wrote: > On Mon, Feb 11, 2019 at 11:18 AM Al Kossow wrote: > > > Does it have the 800 bpi option board? > > > > I haven't yet unboxed it. I took photos of the outside of the destroyed box > to send to the shipper. The front bottom left corner of the 88780 is > visible through a hole in the box, and is visibly mangled. > > I'll take more photos as I unbox it tonight. > > Based on the service manual, it appears that option 800 requires: > * buffer PCA 07980-6xx14 (512K) or 07980-6xx34 (1M) > * read/write/formatter PCA 07980-6xx31 > > Were there any other hardware changes for option 800? If not, one wonders > why HP documentation is adamant that it cannot be field-upgraded to option > 800. > From couryhouse at aol.com Mon Feb 11 21:04:37 2019 From: couryhouse at aol.com (ED SHARPE) Date: Tue, 12 Feb 2019 03:04:37 +0000 (UTC) Subject: Bellmac 8 Tutor on ebay References: <447266768.2089849.1549940677762.ref@mail.yahoo.com> Message-ID: <447266768.2089849.1549940677762@mail.yahoo.com> although? ?I? think? ?most? production? ? for? switch gear? ?was? ?done? ?with the later? ?32? bit? ?unit Ed# In a message dated 2/10/2019 12:49:36 PM US Mountain Standard Time, cctalk at classiccmp.org writes: telephone? gear? ed# In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes:Bringing up a bit of an old thread here, as I just picked up one of theseyesterday. Typed in some example programs, which took far too long thanksto a bouncy keypad. But hey, at least it works! Were there any real applications for the MAC-8? Haven't been able to findmuch. Thanks, Kyle From kylevowen at gmail.com Mon Feb 11 21:53:47 2019 From: kylevowen at gmail.com (Kyle Owen) Date: Mon, 11 Feb 2019 21:53:47 -0600 Subject: SGI Personal Iris 4D/35 In-Reply-To: References: Message-ID: On Mon, Feb 11, 2019, 19:02 John Ball via cctalk Hey Kyle. > You can narrow things down a bit by removing the optional Z-buffer and > additional bitplane memory (ZB3 and BP4). While that removes those two > masses of memory out of the equation that still leaves the still massive > amount of ZIPP base video memory. for the later Onyx systems I've only seen > pinstriping when the video memory or supporting glue has been allowed to > overheat. I can't recall if it tests the graphics as well but have you > tried > running the ide diagnostics in case that refines the error a little? > > -John > Thanks John. I'll give it a try with the extra memory removed. I noticed some jumpers on the main graphics board. Will those need to change with the removal of the extra memory? Is the IDE the PROM diagnostics? If so, I didn't find it very interactive. It probably ran for close to 30 minutes without doing much until the error. Photos of the error are in the album. If there's another suite of tests other than the confidence tests I can run, please let me know. Is there a source listing for the PROM monitor? Maybe reviewing the graphics test code would help me understand how to patch a more useful error message when the graphics test fails. Thanks, Kyle > From billdegnan at gmail.com Mon Feb 11 18:25:24 2019 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 11 Feb 2019 19:25:24 -0500 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> References: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> Message-ID: What is the gold value? On Mon, Feb 11, 2019, 6:11 PM mike via cctech wrote: > Will I would be interested in some. > > Mike Zahorik > (414) 254-6768 > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of William > Donzelli via cctalk > Sent: Monday, February 11, 2019 02:37 PM > To: Bill Gunshannon; General Discussion: On-Topic and Off-Topic Posts > Subject: Re: Wirewrap DIP sockets - any interest? > > I will start to gather them up. Basically, 25 cents for little guys > (14s, 16s, etc), 50 cents for big guys (24s, 28s, 40s), and a buck for > 28s and 40s with full gold plate. > > Obviously all DIPs. > > -- > Will > > On Mon, Feb 11, 2019 at 3:29 PM Bill Gunshannon via cctalk > wrote: > > > > On 2/11/19 3:25 PM, William Donzelli via cctalk wrote: > > > Does anyone here still actively wire wrap circuits? I am thinking > > > about dumping my inventory of nice machine pin wirewrap sockets. > > > Lately they have been selling like lead balloons. > > > > > > Contact me off list. > > > > > > -- > > > Will, in the Hudson Valley > > > > > > > I don't do it often, but I do still wire wrap. What do you > > have and what are you looking to get for them? > > > > I am not too far away, over the border in PA. Used to live > > in The Hudson Valley and still make fairly often trips to > > West Point. > > > > bill > > > > From wdonzelli at gmail.com Mon Feb 11 18:36:57 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Mon, 11 Feb 2019 19:36:57 -0500 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> Message-ID: I might think that the 40s with full plate on the pins might be a buck or so each. -- Will On Mon, Feb 11, 2019 at 7:25 PM Bill Degnan via cctech wrote: > > What is the gold value? > > On Mon, Feb 11, 2019, 6:11 PM mike via cctech wrote: > > > Will I would be interested in some. > > > > Mike Zahorik > > (414) 254-6768 > > -----Original Message----- > > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of William > > Donzelli via cctalk > > Sent: Monday, February 11, 2019 02:37 PM > > To: Bill Gunshannon; General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: Wirewrap DIP sockets - any interest? > > > > I will start to gather them up. Basically, 25 cents for little guys > > (14s, 16s, etc), 50 cents for big guys (24s, 28s, 40s), and a buck for > > 28s and 40s with full gold plate. > > > > Obviously all DIPs. > > > > -- > > Will > > > > On Mon, Feb 11, 2019 at 3:29 PM Bill Gunshannon via cctalk > > wrote: > > > > > > On 2/11/19 3:25 PM, William Donzelli via cctalk wrote: > > > > Does anyone here still actively wire wrap circuits? I am thinking > > > > about dumping my inventory of nice machine pin wirewrap sockets. > > > > Lately they have been selling like lead balloons. > > > > > > > > Contact me off list. > > > > > > > > -- > > > > Will, in the Hudson Valley > > > > > > > > > > I don't do it often, but I do still wire wrap. What do you > > > have and what are you looking to get for them? > > > > > > I am not too far away, over the border in PA. Used to live > > > in The Hudson Valley and still make fairly often trips to > > > West Point. > > > > > > bill > > > > > > > From jlw at jlw.com Tue Feb 12 03:16:28 2019 From: jlw at jlw.com (Jeff Woolsey) Date: Tue, 12 Feb 2019 01:16:28 -0800 Subject: sun 88780 on ebay Message-ID: *Eric Smith *writes: > On Mon, Feb 11, 2019 at 11:18 AM Al Kossow > wrote: > > >/Does it have the 800 bpi option board? />// > I haven't yet unboxed it. I took photos of the outside of the destroyed box > to send to the shipper. The front bottom left corner of the 88780 is > visible through a hole in the box, and is visibly mangled. > I acquired mine as a piece of decommissioned hardware where I worked.? It came home with me in my car. Some time later (mid 90s) I loaned it to a friend for some contract work at .? I drove it up there and delivered it on a cart.? The stars, however, did not align for getting it back to me the same way so they shipped it to me where I worked.? There was some damage to the plastic front cover and control panel mounts.? I was able to repair or work around most of it, and the unit still works fine to this day. (Well, the plastic take-up reel is loose...) Pretty much everything I have that could go in a rack I fetched myself rather than having it shipped to me.? While one can't always do that, I recently carted home an HP 3455A multimeter from Los Angeles, some 400 miles.? I was already in the area, otherwise I don't think I'd've made the round trip just for it. > Based on the service manual, it appears that option 800 requires: > * buffer PCA 07980-6xx14 (512K) or 07980-6xx34 (1M) > * read/write/formatter PCA 07980-6xx31 > Mine has the 800 bpi option.? Not by inspection, but by operation. -- Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com Nature abhors straight antennas, clean lenses, and empty storage. "Delete! Delete! OK!" -Dr. Bronner on disk space management Card-sorting, Joel. -Crow on solitaire From cym224 at gmail.com Tue Feb 12 08:39:01 2019 From: cym224 at gmail.com (Nemo) Date: Tue, 12 Feb 2019 09:39:01 -0500 Subject: sun 88780 on ebay In-Reply-To: References: <1c0977a8-2456-ec01-8666-3dc1361def23@bitsavers.org> Message-ID: On 11/02/2019, Eric Smith via cctalk wrote (in part): > I haven't yet unboxed it. I took photos of the outside of the destroyed box > to send to the shipper. The front bottom left corner of the 88780 is > visible through a hole in the box, and is visibly mangled. Who was the seller? (The ebay link did not list the seller.) N. From elson at pico-systems.com Tue Feb 12 10:30:13 2019 From: elson at pico-systems.com (Jon Elson) Date: Tue, 12 Feb 2019 10:30:13 -0600 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> Message-ID: <5C62F495.2080904@pico-systems.com> On 02/11/2019 06:25 PM, Bill Degnan via cctalk wrote: > What is the gold value? > > ARRgh! Not more than a few milligrams per the usual DIP sockets. Likely not worth the trouble of grinding them up to extract the gold from all that base metal. Jon From wdonzelli at gmail.com Tue Feb 12 10:43:50 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Tue, 12 Feb 2019 11:43:50 -0500 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: <5C62F495.2080904@pico-systems.com> References: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> <5C62F495.2080904@pico-systems.com> Message-ID: > ARRgh! Not more than a few milligrams per the usual DIP > sockets. Likely not worth the trouble of grinding them up to > extract the gold from all that base metal. A lot of precious metal scrappers have wildly differing opinions on that. -- Will From cclist at sydex.com Tue Feb 12 10:56:48 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 12 Feb 2019 08:56:48 -0800 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: <5C62F495.2080904@pico-systems.com> References: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> <5C62F495.2080904@pico-systems.com> Message-ID: <3c1b6a3d-44c4-c7df-2a98-12c5e924db31@sydex.com> On 2/12/19 8:30 AM, Jon Elson via cctalk wrote: > On 02/11/2019 06:25 PM, Bill Degnan via cctalk wrote: >> What is the gold value? >> >> > ARRgh!? Not more than a few milligrams per the usual DIP sockets. Likely > not worth the trouble of grinding them up to extract the gold from all > that base metal. Of late (the last 20 years or so), I've turned to drilling single-sided PCB for socket patterns and using the push-in ww pins. Makes for a much neater project with a good ground plane. --Chuck From paulkoning at comcast.net Tue Feb 12 11:03:03 2019 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 12 Feb 2019 12:03:03 -0500 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: <3c1b6a3d-44c4-c7df-2a98-12c5e924db31@sydex.com> References: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> <5C62F495.2080904@pico-systems.com> <3c1b6a3d-44c4-c7df-2a98-12c5e924db31@sydex.com> Message-ID: > On Feb 12, 2019, at 11:56 AM, Chuck Guzis via cctalk wrote: > > On 2/12/19 8:30 AM, Jon Elson via cctalk wrote: >> On 02/11/2019 06:25 PM, Bill Degnan via cctalk wrote: >>> What is the gold value? >>> >>> >> ARRgh! Not more than a few milligrams per the usual DIP sockets. Likely >> not worth the trouble of grinding them up to extract the gold from all >> that base metal. > > Of late (the last 20 years or so), I've turned to drilling single-sided > PCB for socket patterns and using the push-in ww pins. Makes for a much > neater project with a good ground plane. And people would make WW panels that way. I have a small one that's just rows of push-in pins like that (with pins 7 and 14 bused to power buses). From Augat, I think. paul From aek at bitsavers.org Tue Feb 12 11:23:01 2019 From: aek at bitsavers.org (Al Kossow) Date: Tue, 12 Feb 2019 09:23:01 -0800 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: <4EEA865578034777BB95E532D6A3221F@Dumbbunny64> <5C62F495.2080904@pico-systems.com> Message-ID: <793c99d9-868e-a862-e7aa-438dfa7bdea8@bitsavers.org> On 2/12/19 8:43 AM, William Donzelli via cctalk wrote: > A lot of precious metal scrappers have wildly differing opinions on that. > And there are a lot of dreamers out there too I had 1.8 lbs of 1970's bell labs wire wrap pins up on ebay for a while, someone in texas assayed a few and claimed there was only $200 worth of gold in them I also could only get maybe $200 for 9u wire-wrap panels with over 3000 pins on them From wdonzelli at gmail.com Tue Feb 12 14:44:06 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Tue, 12 Feb 2019 15:44:06 -0500 Subject: Wirewrap DIP sockets - any interest? In-Reply-To: References: Message-ID: So I received many requests for WW sockets - more than I thought I would - so I am going to pick two people at random to deal with. If you do not hear from me, do not despair - if either of the two I originally picked flakes out or something, you may get reselected! Anyway, the sockets are likely not going to the scrap! -- Will On Mon, Feb 11, 2019 at 3:25 PM William Donzelli wrote: > > Does anyone here still actively wire wrap circuits? I am thinking > about dumping my inventory of nice machine pin wirewrap sockets. > Lately they have been selling like lead balloons. > > Contact me off list. > > -- > Will, in the Hudson Valley From ethan.dicks at gmail.com Tue Feb 12 15:55:06 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Tue, 12 Feb 2019 16:55:06 -0500 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: On Wed, Feb 6, 2019 at 10:08 AM Phil Pemberton via cctalk wrote: > Does anyone have copies of any of the following -- or any other C > compilers for the 68K which were around at that time? > > * Lattice C Entirely randomly, I just opened a box I received today. Expected in the box was the DEC Rainbow. Unexpected was an original box of Lattice C 2.15 for 8086 - docs and original floppies plus safety backups. Also a surprise - it's all in a Lifeboat Associates binder. -ethan From imp at bsdimp.com Tue Feb 12 16:16:13 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 12 Feb 2019 15:16:13 -0700 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: On Tue, Feb 12, 2019 at 2:55 PM Ethan Dicks via cctalk < cctalk at classiccmp.org> wrote: > On Wed, Feb 6, 2019 at 10:08 AM Phil Pemberton via cctalk > wrote: > > Does anyone have copies of any of the following -- or any other C > > compilers for the 68K which were around at that time? > > > > * Lattice C > > Entirely randomly, I just opened a box I received today. Expected in > the box was the DEC Rainbow. Unexpected was an original box of > Lattice C 2.15 for 8086 - docs and original floppies plus safety > backups. Also a surprise - it's all in a Lifeboat Associates binder. > Cool beans. Is it copy protected? Sometimes I think it would be cool to have an archive of early commercial s/w for the Rainbow somewhere... Warner From ethan.dicks at gmail.com Tue Feb 12 16:33:27 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Tue, 12 Feb 2019 17:33:27 -0500 Subject: DEC Rainbow software (was Re: Looking for: 68000 C compilers) In-Reply-To: References: Message-ID: On Tue, Feb 12, 2019 at 5:16 PM Warner Losh wrote: >> > Does anyone have copies of any of the following... >> > * Lattice C >> >> Entirely randomly, I just opened a box I received today. Expected in >> the box was the DEC Rainbow. Unexpected was an original box of >> Lattice C 2.15 for 8086 - docs and original floppies plus safety >> backups. Also a surprise - it's all in a Lifeboat Associates binder. > > Cool beans. Is it copy protected? I don't think so. The box had backup floppies and I don't think this was one of the "make a single copy for archive purposes" nonsense that hit early MS-DOS titles. > Sometimes I think it would be cool to have an archive of early commercial s/w for the Rainbow somewhere... There isn't one? Well... I haven't been big on the Rainbow in the past but I see in this box: Rainbow 100 MS-DOS Operating System Version 2.05 AUTOSORT-86 for Rainbow 100 Microsoft Multiplan-86 Spreadsheet for Rainbow 100 Rainbow CP/M-86/80 Operating System Version 2.0 Lattice C 2.15 Microsoft MBasic-86 BASIC Interpreter for Rainbow 100 and from another source, I have an original Infocom title for Rainbow (presumably runs under DOS not CP/M). Infocom game files are not difficult to source but a disk image of one for a Rainbow would be uncommon. At the moment, I haven't finished building my "media imaging box", a long-standing project that I really ought to kick into the priority lane. -ethan From fmc at reanimators.org Tue Feb 12 18:06:24 2019 From: fmc at reanimators.org (Frank McConnell) Date: Tue, 12 Feb 2019 16:06:24 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: References: Message-ID: <9E870597-A3F8-48E0-AFB4-199276B03F22@reanimators.org> On Feb 12, 2019, at 14:16, Warner Losh via cctalk wrote: > > On Tue, Feb 12, 2019 at 2:55 PM Ethan Dicks via cctalk < > cctalk at classiccmp.org> wrote: > >> On Wed, Feb 6, 2019 at 10:08 AM Phil Pemberton via cctalk >> wrote: >>> Does anyone have copies of any of the following -- or any other C >>> compilers for the 68K which were around at that time? >>> >>> * Lattice C >> >> Entirely randomly, I just opened a box I received today. Expected in >> the box was the DEC Rainbow. Unexpected was an original box of >> Lattice C 2.15 for 8086 - docs and original floppies plus safety >> backups. Also a surprise - it's all in a Lifeboat Associates binder. >> > > Cool beans. Is it copy protected? Sometimes I think it would be cool to > have an archive of early commercial s/w for the Rainbow somewhere... I remember moving Lattice C v2 from IBM PC diskettes to an HP 150. It was MS-DOS applications and compiler and linker worked on the 150. No copy protection. -Frank McConnell From cclist at sydex.com Tue Feb 12 18:22:39 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 12 Feb 2019 16:22:39 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: <9E870597-A3F8-48E0-AFB4-199276B03F22@reanimators.org> References: <9E870597-A3F8-48E0-AFB4-199276B03F22@reanimators.org> Message-ID: Is Lattice C 2.whatever for 8086 uncommon? I have a copy on a couple of floppies. --Chuck From cclist at sydex.com Tue Feb 12 20:55:52 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 12 Feb 2019 18:55:52 -0800 Subject: Looking for: 68000 C compilers In-Reply-To: <9E870597-A3F8-48E0-AFB4-199276B03F22@reanimators.org> References: <9E870597-A3F8-48E0-AFB4-199276B03F22@reanimators.org> Message-ID: <4bc43989-b3e7-5ee1-4160-b0cd1bc2c68c@sydex.com> On 2/12/19 4:06 PM, Frank McConnell via cctalk wrote: > I remember moving Lattice C v2 from IBM PC diskettes to an HP 150. It was MS-DOS applications and compiler and linker worked on the 150. No copy protection. Lattice C was recommended by Microsoft to OEMs in the DOS 1.-2. days. Two-step compilation process LC1, LC2, then link for executable. Microsoft didn't yet have their own C. --Chuck From cisin at xenosoft.com Tue Feb 12 21:09:54 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 12 Feb 2019 19:09:54 -0800 (PST) Subject: Looking for: 68000 C compilers In-Reply-To: <4bc43989-b3e7-5ee1-4160-b0cd1bc2c68c@sydex.com> References: <9E870597-A3F8-48E0-AFB4-199276B03F22@reanimators.org> <4bc43989-b3e7-5ee1-4160-b0cd1bc2c68c@sydex.com> Message-ID: On Tue, 12 Feb 2019, Chuck Guzis via cctalk wrote: > Lattice C was recommended by Microsoft to OEMs in the DOS 1.-2. days. > Two-step compilation process LC1, LC2, then link for executable. > Microsoft didn't yet have their own C. Microsoft C 1.0 WAS Lattice C. 1983? (so, after recommending it, they eventually cut a deal to sell it) IIRC, C 3.0 was the first one developed at Microsoft. 1985? From frisbie at flying-disk.com Tue Feb 12 14:37:01 2019 From: frisbie at flying-disk.com (Alan Frisbie) Date: Tue, 12 Feb 2019 12:37:01 -0800 (PST) Subject: Mounting HP7970e 9-Trk 1/2" Tape Drive Message-ID: <19021212370183_448@slug.flying-disk.com> jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Alan Frisbie > > > Harbor Freight sells a nice hydraulic lift table for under $200 that I > > have found very useful for that sort of thing. It doesn't go up very high > > (like for the top of a rack), but I used it with some wood blocks > > Thanks for the tip! I got one on sale for about US$140; it's _very_ sturdy. > And the top is just large enough to hold two milk crates (available at > Home Depot, BTW), so it's guite easy to build up a stack as high as one > needs to reach the top of a 6' rack. Thank you very much for the feedback -- it makes me happy when I know that someone finds my suggestions useful. I've used the milk crate technique myself, with a piece of sheet metal on top to make it easier to slide the load off. I hope you secure such a stack tightly. :-) I used some of the inexpensive 1" wide Harbor Freight cargo straps. Alan "You can't have too many clamps or straps" Frisbie From frisbie at flying-disk.com Tue Feb 12 14:51:11 2019 From: frisbie at flying-disk.com (Alan Frisbie) Date: Tue, 12 Feb 2019 12:51:11 -0800 (PST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <19021212511185_448@slug.flying-disk.com> > > > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries! > > > > No; the RK11 spec says "[the two extended memory bits] make up a two-bit > > counter that increments each time the RKBA overflows". > > > > The actual error turns out to be slightly different to my guess; there's > > a spurious overflow from the low 16-bit register to these bits at 0170000. > > Maybe a problem with E29 or E34 on the M795 module? I am finding this entire discussion extremely fascinating! Every day I look forward to reading the latest twists in the plot. The ideas, hunches, tests, dead ends, and results are an excellent example of the debugging process. I am awaiting the exciting Perry Mason style conclusion, where the guilty chip stands up and confesses on the stand. :-) Alan "Where were you on the night of the crime?" Frisbie From fritzm at fritzm.org Wed Feb 13 01:43:23 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Tue, 12 Feb 2019 23:43:23 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <19021212511185_448@slug.flying-disk.com> References: <19021212511185_448@slug.flying-disk.com> Message-ID: SUCCESS!! Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced, and off she goes! I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk. *THAT* was a really fun and rewarding hunt :-) First message in the thread was back on Dec 30, 2018. Lots of debugging and failed DRAM repairs, then the final long assault to this single, failed gate... Thanks to all here for the help and resources, and particular shout-outs for Noel and Paul who gave generously of their time and attention working through the densest bits, both on and off the list. I predict a long happy weekend and a big power bill at the end of the month :-) cheers, --FritzM. From paulkoning at comcast.net Wed Feb 13 07:34:37 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 13 Feb 2019 08:34:37 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <19021212511185_448@slug.flying-disk.com> Message-ID: > On Feb 13, 2019, at 2:43 AM, Fritz Mueller via cctalk wrote: > > SUCCESS!! > > Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced, and off she goes! > > I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk. Congratulations. You have successfully performed a repair of the type done at customer sites by highly trained DEC field service personnel. They were the ones who traveled with an oscilloscope, a tool case including soldering iron, and a case full of replacement chips. One difference is that the diagnostics didn't point to the problem, which in my experience is rather an unusual situation. Nicely done. paul From jnc at mercury.lcs.mit.edu Wed Feb 13 08:36:42 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Feb 2019 09:36:42 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190213143642.7A48018C09C@mercury.lcs.mit.edu> > From: Alan Frisbie > I am finding this entire discussion extremely fascinating! Every day I > look forward to reading the latest twists in the plot. :-) > The ideas, hunches, tests, dead ends, and results are an excellent > example of the debugging process. Yeah, and it was a Duesie of a problem, too. Although once we got clear of the bad data from the console and my confusion about R5, and it became clear that in the Unix failure, the pure text was being damaged, from that point it was pretty straightforward to track it down (albeit one that needed detailed understanding of how V6 handled pure texts - and luckily I'd come to understand that part of the system a bit while getting the QSIC running). Fritz's lucky discovery, early on, that it was location dependent was also a big help. Noel From cclist at sydex.com Wed Feb 13 09:54:00 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 13 Feb 2019 07:54:00 -0800 Subject: JPL Auction Message-ID: <6ec2c139-ff11-0f0b-eadd-7629c5d76a7b@sydex.com> Those of you in So. Cal. may be interested. Lots of Sun stuff: https://gsaauctions.gov/ATTACHMENT/REGN9/91QSCI19501806/806ListingofAvailableItems.pdf -- --Chuck Sent from my digital computer From elson at pico-systems.com Wed Feb 13 09:56:44 2019 From: elson at pico-systems.com (Jon Elson) Date: Wed, 13 Feb 2019 09:56:44 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <19021212511185_448@slug.flying-disk.com> Message-ID: <5C643E3C.9030406@pico-systems.com> On 02/13/2019 01:43 AM, Fritz Mueller via cctalk wrote: > SUCCESS!! > > Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced, and off she goes! > > WOW! Good detective work, that certainly was a WEIRD problem, and not where I thought it was going to be. Glad you got it solved! Jon From jnc at mercury.lcs.mit.edu Wed Feb 13 10:40:33 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Feb 2019 11:40:33 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190213164033.086FA18C09C@mercury.lcs.mit.edu> > From: Alan Frisbie > I am finding this entire discussion extremely fascinating! Every day I > look forward to reading the latest twists in the plot. I forgot to mention the most amazing part of the whole story: he first acquired the machine while he was a student (I think?) at CMU, decades ago, and has been dragging it around the country with him ever since! He's also had to do a tremendous amount of work on it to get it running, starting with building an entire new power harness. He's also had to find and fix a long list of failures, all over the machine; there were bad chips on almost every board in it. Fritz has written most of the whole adventure up: http://fritzm.github.io/category/pdp-11.html it's an incredible story. Noel From cctalk at ibm51xx.net Wed Feb 13 10:49:32 2019 From: cctalk at ibm51xx.net (Ali) Date: Wed, 13 Feb 2019 08:49:32 -0800 Subject: JPL Auction In-Reply-To: <6ec2c139-ff11-0f0b-eadd-7629c5d76a7b@sydex.com> References: <6ec2c139-ff11-0f0b-eadd-7629c5d76a7b@sydex.com> Message-ID: <009901d4c3bc$18e759f0$4ab60dd0$@net> > Those of you in So. Cal. may be interested. Lots of Sun stuff: > > https://gsaauctions.gov/ATTACHMENT/REGN9/91QSCI19501806/806ListingofAva > ilableItems.pdf > To clarify this is not at JPL proper in Pasadena. It is actually in Ontario: https://gsaauctions.gov/gsaauctions/aucitsrh/?sl=91QSCI19501806 -Ali From cube1 at charter.net Wed Feb 13 12:20:09 2019 From: cube1 at charter.net (Jay Jaeger) Date: Wed, 13 Feb 2019 12:20:09 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <19021212511185_448@slug.flying-disk.com> Message-ID: <14a04c0c-c578-3af5-f6fb-0997ae34cc6b@charter.net> On 2/13/2019 1:43 AM, Fritz Mueller via cctalk wrote: > SUCCESS!! > > Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced, and off she goes! > > I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk. > > *THAT* was a really fun and rewarding hunt :-) First message in the thread was back on Dec 30, 2018. Lots of debugging and failed DRAM repairs, then the final long assault to this single, failed gate... > > Thanks to all here for the help and resources, and particular shout-outs for Noel and Paul who gave generously of their time and attention working through the densest bits, both on and off the list. > > I predict a long happy weekend and a big power bill at the end of the month :-) > > cheers, > --FritzM. > > Congratulations. As another poster mentioned, it has been fascinating to watch and learn, day by day, as you worked on the problem with Noel and Paul's help. And I learned a little bit more about my 11/45 (that it indeed had had a processor field upgrade), which I had not looked at very closely before. Maybe that story about FE's using Unix as a test to confirm operation even when diagnostics said the machine was OK was not so much just a legend? From paulkoning at comcast.net Wed Feb 13 14:03:41 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 13 Feb 2019 15:03:41 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <14a04c0c-c578-3af5-f6fb-0997ae34cc6b@charter.net> References: <19021212511185_448@slug.flying-disk.com> <14a04c0c-c578-3af5-f6fb-0997ae34cc6b@charter.net> Message-ID: > On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk wrote: > > ... > Maybe that story about FE's using Unix as a test to confirm operation > even when diagnostics said the machine was OK was not so much just a > legend? It still fels like a legend. My experience with DEC field service engineers is that they used the diagnostics. In the PDP-11 era, Unix knowledge around DEC was pretty sparse, especially early on when it could be found only in the Telephone Products Group (Armando Stettner). RSTS would be more plausible, but I never saw that in the hads of FS engineers either. By and large diagnostics would find problems. I've seen a number in the 1970s, including a messy data path failure in the 11/45 MMU where we (college students) did the initial diagnosis while the FS engineer was on his way. My suspicion is that things not solved by diagnostics would be escalated to the "wizard from Maynard". And they'd probably start replacing whole subsystems. I've seen that once, when our college RSTS-11 system (11/20, 16 DL-11 lines) was crashing on average once a day for months. DEC brought in several of those "wizards". The "fix" was to replace the 11/20 by a "spare part" -- an 11/45 with more memory, a DH11, and RSTS/E. Decades later I was told that the wizards actually pinned the blame on the college FM broadcast transmitter, about 200 feet down the hall from the computer center. That may well be, though I didn't heard that at the time. RSTS did get used in manufacturing, at Final Assembly & Test sites like Westminster MA and Salem NH, where PDP-11 systems large enough to run RSTS/E were subjected to a load test of exerciser programs running under that OS. The way it was explained to us is that a system that would be happy with such a test would also be happy with any customer application. It's not clear if that was because RSTS would load things more than most, or was more finicky about hardware glitches than most, but it certainly was the practice for quite some time. Of course, not all PDP-11 configurations could be tested that way. paul From ethan.dicks at gmail.com Wed Feb 13 14:54:24 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Wed, 13 Feb 2019 15:54:24 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <19021212511185_448@slug.flying-disk.com> Message-ID: On Wed, Feb 13, 2019 at 2:43 AM Fritz Mueller via cctalk wrote: > > SUCCESS!! Outstanding! > Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced, and off she goes! > > I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk. Nice. I have had an RK11-C for a long time that I've never tried to power up (I got an RKV11-D and used that on Qbus machines instead). The saga has been interesting for me as I contemplate getting mine working in the next couple of years. I had to look up the M795. I had forgotten there was one dual-height module in the entire controller. It's interesting that it was a bad 7430 in yours. I find that for equipment of that vintage, my usual suspects are failed 7474s and failed 7440s, probably 80% of the total. Behind that, it goes 7420s and then maybe 7430s. -ethan From paulkoning at comcast.net Wed Feb 13 15:02:29 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 13 Feb 2019 16:02:29 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <19021212511185_448@slug.flying-disk.com> Message-ID: <917FA45D-0B79-4210-AF53-2A67B2D380C5@comcast.net> > On Feb 13, 2019, at 3:54 PM, Ethan Dicks via cctalk wrote: > > ... > It's interesting that it was a bad 7430 in yours. I find that for > equipment of that vintage, my usual suspects are failed 7474s and > failed 7440s, probably 80% of the total. Behind that, it goes 7420s > and then maybe 7430s. When our 11/45 failed in the MMU in 1975, my classmate Josh Rosen traced the failing path on the schematics. When Jim Newport the field service engineer showed up, Josh described the diagnostics result that pointed at the failed path, and added "This is the failed chip" (pointing to one particular chip. Jim asked "Why that one?" Josh answered "because that is the most expensive chip". It turned out he was right. paul From cmhanson at eschatologist.net Wed Feb 13 18:39:05 2019 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 13 Feb 2019 16:39:05 -0800 Subject: Intel PC-BUBBLE Card documentation? Message-ID: Does anyone have documentation stashed away for the Intel PC-BUBBLE Card? The PC-BUBBLE is an 8-bit ISA card that Intel produced for prototyping bubble memory applications in the mid-1980s, the ROM on mine is v3.0 and says it?s copyright 1986. I don?t want to insert this into a system until I?m sure all the (many) jumpers are configured reasonably, and I?m sure that the empty 40-pin socket at U5 isn?t something that?s critical to its operation? -- Chris From paulkoning at comcast.net Wed Feb 13 18:44:19 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 13 Feb 2019 19:44:19 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <19021212511185_448@slug.flying-disk.com> <14a04c0c-c578-3af5-f6fb-0997ae34cc6b@charter.net> Message-ID: > On Feb 13, 2019, at 3:03 PM, Paul Koning wrote: > > ... > My suspicion is that things not solved by diagnostics would be escalated to the "wizard from Maynard". And they'd probably start replacing whole subsystems. This says that Fritz actually was a new "Wizard from Maynard" in solving this problem. Only more so -- because he didn't have the luxury of just swapping out whole sections of the machine with new kits, or a backup team of subsystem experts at the home office to call on. That confirms it's really a very impressive performance. paul From jsw at ieee.org Wed Feb 13 19:20:14 2019 From: jsw at ieee.org (Jerry Weiss) Date: Wed, 13 Feb 2019 19:20:14 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <19021212511185_448@slug.flying-disk.com> Message-ID: <265d43c5-8f35-369b-06f2-e7f6fe6ea95d@ieee.org> On 2/13/19 1:43 AM, Fritz Mueller via cctalk wrote: > SUCCESS!! > > Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced, and off she goes! > > I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk. > > *THAT* was a really fun and rewarding hunt :-) First message in the thread was back on Dec 30, 2018. Lots of debugging and failed DRAM repairs, then the final long assault to this single, failed gate... > > Thanks to all here for the help and resources, and particular shout-outs for Noel and Paul who gave generously of their time and attention working through the densest bits, both on and off the list. > > I predict a long happy weekend and a big power bill at the end of the month :-) > > cheers, > --FritzM. > > Congratulations.? Well Done. I am trying to understand how the diagnostics didn't reveal this defect.? I see in the source for the diagnostic DZRKH-F there are tests for address in the 28K-32K range and also for the 32K boundary. I'm trying to make sense of the M795 to get a better understanding. Any addition data on how the 7430 failed (input bad, output bad, etc ?) ? Jerry From elson at pico-systems.com Wed Feb 13 20:01:22 2019 From: elson at pico-systems.com (Jon Elson) Date: Wed, 13 Feb 2019 20:01:22 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190213164033.086FA18C09C@mercury.lcs.mit.edu> References: <20190213164033.086FA18C09C@mercury.lcs.mit.edu> Message-ID: <5C64CBF2.4040704@pico-systems.com> On 02/13/2019 10:40 AM, Noel Chiappa via cctalk wrote: > He's also had to do a tremendous amount of work on it to get it running, > starting with building an entire new power harness. Yes, the 5V power harness between the regulators and the backplane were a real mess on the 11/45 we got second hand. I probably SHOULD have rebuilt the entire harness and replaced all the Mate-n-Lock connectors on the regulators, too, but we were always just wanting to get the machine running again. Jon From fritzm at fritzm.org Wed Feb 13 20:18:02 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 13 Feb 2019 18:18:02 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <265d43c5-8f35-369b-06f2-e7f6fe6ea95d@ieee.org> References: <19021212511185_448@slug.flying-disk.com> <265d43c5-8f35-369b-06f2-e7f6fe6ea95d@ieee.org> Message-ID: On 2/13/19 5:20 PM, Jerry Weiss wrote: > I am trying to understand how the diagnostics didn't reveal this > defect.? I see in the source for the diagnostic DZRKH-F there are tests > for address in the 28K-32K range and also for the 32K boundary. So, to catch this defect the diagnostic would have to have a test or tests which crossed _specifically_ the 30K boundary within a transfer. The detailed symptom was a false overflow into the ex.mem bits on the 30K boundary, causing a skip forward in bus addresses during the transfer. The detailed fail on the 7430 (E34 on the M795) was that it acted as if input pin 11 was always H. Now, all this said, I don't think I have ever run ZRKH! I *did* run and pass the earlier ZRKA, ZRKB, and ZRKC, but somehow missed ZRKH... I'm wondering now how different it is from ZRKC? Will have to take a look... --FritzM. From fritzm at fritzm.org Thu Feb 14 01:06:03 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Wed, 13 Feb 2019 23:06:03 -0800 Subject: PDP-11/45 RSTS/E boot problem References: <0354a381-fa2c-04b5-4fbd-44a45d3cc86a@fritzm.org> Message-ID: <98467493-82F7-49B5-A661-DE04CA080128@fritzm.org> [oops, accidentally replied directly instead of to the list] On 2/13/19 12:54 PM, Ethan Dicks wrote: > It's interesting that it was a bad 7430 in [your RK11-C]. I find that for equipment of that vintage, my usual suspects are failed 7474s and failed 7440s, probably 80% of the total. Behind that, it goes 7420s and then maybe 7430s. Looking back over my repair log, my totals just within the RK11-C were: 2x 7430 (M119, M795) 1x 7420 (M141) 1x 7401 (M149) 1x 7400 (M203) From jnc at mercury.lcs.mit.edu Thu Feb 14 09:17:26 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 14 Feb 2019 10:17:26 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190214151726.CDAE118C0AB@mercury.lcs.mit.edu> > From: Jerry Weiss > I am trying to understand how the diagnostics didn't reveal this defect. Vondada #12: "Diagnostics are highly efficient in finding solved problems." :-) Noel From sales at elecplus.com Thu Feb 14 11:19:59 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 11:19:59 -0600 Subject: IBM terminals with keyboards, 3174 controllers, 4700 controllers Message-ID: <073d01d4c489$83bbbeb0$8b333c10$@com> Previously I have posted some vendors who have old hardware they are willing to sell. Earlier this week I was in San Antonio, and I stopped by an old friend to say hello. He has several 3174 controllers, and every imaginable add-on available for them. Pallets of them! Also IBM 4700 banking controllers, and 1 monitor. No keyboards. 8" floppy drives. IBM terminals, most models available, $85 tested and working with matching keyboard, no severe screen burn. Contact bfloyd at southtexasproducts dot com. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From wdonzelli at gmail.com Thu Feb 14 11:22:36 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Thu, 14 Feb 2019 12:22:36 -0500 Subject: IBM terminals with keyboards, 3174 controllers, 4700 controllers In-Reply-To: <073d01d4c489$83bbbeb0$8b333c10$@com> References: <073d01d4c489$83bbbeb0$8b333c10$@com> Message-ID: Any pics available? -- Will On Thu, Feb 14, 2019 at 12:20 PM Electronics Plus via cctalk wrote: > > Previously I have posted some vendors who have old hardware they are willing > to sell. > > Earlier this week I was in San Antonio, and I stopped by an old friend to > say hello. > > He has several 3174 controllers, and every imaginable add-on available for > them. Pallets of them! > > Also IBM 4700 banking controllers, and 1 monitor. No keyboards. > > 8" floppy drives. > > IBM terminals, most models available, $85 tested and working with matching > keyboard, no severe screen burn. > > > > Contact bfloyd at southtexasproducts dot com. > > > > Cindy Croxton > > Electronics Plus > > 1613 Water Street > > Kerrville, TX 78028 > > 830-370-3239 cell > > sales at elecplus.com > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 11:26:53 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 11:26:53 -0600 Subject: IBM terminals with keyboards, 3174 controllers, 4700 controllers In-Reply-To: References: <073d01d4c489$83bbbeb0$8b333c10$@com> Message-ID: <075f01d4c48a$7a638360$6f2a8a20$@com> I have asked him for pics. Cindy -----Original Message----- From: William Donzelli [mailto:wdonzelli at gmail.com] Sent: Thursday, February 14, 2019 11:23 AM To: Electronics Plus; General Discussion: On-Topic and Off-Topic Posts Subject: Re: IBM terminals with keyboards, 3174 controllers, 4700 controllers Any pics available? -- Will On Thu, Feb 14, 2019 at 12:20 PM Electronics Plus via cctalk wrote: > > Previously I have posted some vendors who have old hardware they are willing > to sell. > > Earlier this week I was in San Antonio, and I stopped by an old friend to > say hello. > > He has several 3174 controllers, and every imaginable add-on available for > them. Pallets of them! > > Also IBM 4700 banking controllers, and 1 monitor. No keyboards. > > 8" floppy drives. > > IBM terminals, most models available, $85 tested and working with matching > keyboard, no severe screen burn. > > > > Contact bfloyd at southtexasproducts dot com. > > > > Cindy Croxton > > Electronics Plus > > 1613 Water Street > > Kerrville, TX 78028 > > 830-370-3239 cell > > sales at elecplus.com > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus From spacewar at gmail.com Thu Feb 14 11:36:48 2019 From: spacewar at gmail.com (Eric Smith) Date: Thu, 14 Feb 2019 10:36:48 -0700 Subject: Intel PC-BUBBLE Card documentation? In-Reply-To: References: Message-ID: On Wed, Feb 13, 2019 at 5:39 PM Chris Hanson via cctalk < cctalk at classiccmp.org> wrote: > Does anyone have documentation stashed away for the Intel PC-BUBBLE Card? > The PC-BUBBLE is an 8-bit ISA card that Intel produced for prototyping > bubble memory applications in the mid-1980s, the ROM on mine is v3.0 and > says it?s copyright 1986. > > I don?t want to insert this into a system until I?m sure all the (many) > jumpers are configured reasonably, and I?m sure that the empty 40-pin > socket at U5 isn?t something that?s critical to its operation? > Is there a 40-pin chip elsewhere? There should be one 40-pin chip, which is the Bubble Memory Controller (BMC). That's a D7220 for 1Mbit bubble devices (7110), or a D7225 for 4Mbit bubble devices (7114). From cctalk at ibm51xx.net Thu Feb 14 12:01:24 2019 From: cctalk at ibm51xx.net (Ali) Date: Thu, 14 Feb 2019 10:01:24 -0800 Subject: Another dealer going under In-Reply-To: <036f01d4be40$e393b6c0$aabb2440$@com> References: <015f01d4bd95$09bdafb0$1d390f10$@com> <005101d4bd95$52f7b810$f8e72830$@net> <030001d4be3c$e0688b50$a139a1f0$@com> <00c701d4be3e$64feffb0$2efcff10$@net> <036f01d4be40$e393b6c0$aabb2440$@com> Message-ID: <001d01d4c48f$4deb7130$e9c25390$@net> Cindy, Did Leslie ever get you a list of stuff she has? Thanks. Ali > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of > Electronics Plus via cctalk > Sent: Wednesday, February 06, 2019 9:25 AM > To: 'General Discussion: On-Topic and Off-Topic Posts' > Subject: RE: Another dealer going under > > A Plus Computer Products > 5115 N. Douglas Fir Road > Suite N > Calabasas, CA 91302 > Leslie Foumberg, Owner > Leslie Foumberg [leslie at apluscp.com] > > You might try emailing her directly. > > I have sent her an email letting her know she might start getting some > oddball requests. Also requested a spreadsheet of inventory, or lots of > pics > on a shared link, and then you can email her your interest. Sorry, but > I > have a sick husband right now, and no time to play intermediary. > > Cindy > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus From jstefanikcctalk at gmail.com Thu Feb 14 12:17:00 2019 From: jstefanikcctalk at gmail.com (Jim Stefanik) Date: Thu, 14 Feb 2019 12:17:00 -0600 Subject: IBM terminals with keyboards, 3174 controllers, 4700 controllers In-Reply-To: Message-ID: Yeah, pics would be good.? I'd be interested in a channel attached 3174. ________________________________ From: William Donzelli via cctalk Sent: Thursday, 14 February 2019 11:22 To: Electronics Plus; General Discussion: On-Topic and Off-Topic Posts Subject: Re: IBM terminals with keyboards, 3174 controllers, 4700 controllers Any pics available? -- Will On Thu, Feb 14, 2019 at 12:20 PM Electronics Plus via cctalk wrote: > > Previously I have posted some vendors who have old hardware they are willing > to sell. > > Earlier this week I was in San Antonio, and I stopped by an old friend to > say hello. > > He has several 3174 controllers, and every imaginable add-on available for > them. Pallets of them! > > Also IBM 4700 banking controllers, and 1 monitor. No keyboards. > > 8" floppy drives. > > IBM terminals, most models available, $85 tested and working with matching > keyboard, no severe screen burn. > > > > Contact bfloyd at southtexasproducts dot com. > > > > Cindy Croxton > > Electronics Plus > > 1613 Water Street > > Kerrville, TX 78028 > > 830-370-3239 cell > > sales at elecplus.com > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 12:37:49 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 12:37:49 -0600 Subject: Vendor turned into recycler Message-ID: <07a901d4c494$63780180$2a680480$@com> Just outside Dallas is a very large warehouse. I have been there before, and have posted about it before. It has been acquired by a recycling company, sort of. The old man who owns the stuff thinks of the equip as his children. A week from Sat I will be going to the warehouse with 2 or 3 guys from San Antonio. We will arrive about noon, and hire a truck to bring stuff home before it turns into mincemeat. He will not sell to the public, but I have a license. If you want to attend, I can buy stuff for you. The address is 9525 Skillman St, Dallas, TX 75243 Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 13:06:28 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 13:06:28 -0600 Subject: mainframes and other stuff In-Reply-To: <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> References: <014201d004f9$4e79d740$eb6d85c0$@com> <0F9C8643-122D-46DC-A8E6-91591D158888@mojovapes.net> <016701d004fb$3f8ef420$beacdc60$@com> <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> Message-ID: <080b01d4c498$63e5e1b0$2bb1a510$@com> This post is being brought back to life. A fellow in Utica, NY has some T5140s. He is getting a list together for me. Local pickup available, or he will ship. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter Sent: Thursday, November 20, 2014 3:37 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: mainframes and other stuff I would be looking for the following for Sun, ill have to double check on the IBM machines. Sun Fire T1000 Sun Fire T2000 Sun Fire T5140 Sun Fire T5240 Sun Fire T5440 Sun Enterprise 10000 Sun Fire E25K Sun Fire V490 Sun Fire V890 Sun Fire V1280 Sun Fire V245 Sun Fire V215 > On Nov 20, 2014, at 2:50 PM, Electronics Plus wrote: > > > > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter > Sent: Thursday, November 20, 2014 1:42 PM > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: mainframes and other stuff > > I would have an interest in any larger Sun or IBM machines that aren?t x86. How many of these machines do they keep around? > > None at the moment. > > Not x86 is not specific enough. RS6000 series, or RS6000 model xxxx-xxx would work. > Sun pizza box won't work, but Sparc Station 2, 3, 4, these will; do you see what I mean? > > > Cindy > >> On Nov 20, 2014, at 2:36 PM, Electronics Plus wrote: >> >> Mainframes and other stuff >> >> >> >> Recycle center in NC is willing to save out "stuff" for people. >> >> No, no one can go in the back and scrounge. >> >> No, he does not want a lot of emails from people. >> >> Yes, he gets big blue and orange and beige 6 foot tall OLD mainframes >> in all the time. They squash them at the moment. >> >> Yes, he will package small orders, and will properly palletize larger >> orders. >> >> Local pick up will be available after the new year. >> >> >> >> So, if u can send me a picture with description and some part numbers, >> along with what you want to pay, I will consolidate things and make arrangements. >> >> Please don't ask for specific boards from DEC; they don't want to go >> into that much detail. >> >> QBUS will mean nothing to him. >> >> Big orange cabinet that says xxxxx is much more likely to get saved. >> >> >> >> They are moving to new warehouse 1st of the month, so all this will >> start happening after the 1st of the year. >> >> >> >> Cindy Croxton >> >> Electronics Plus >> >> 1613 Water Street >> >> Kerrville, TX 78028 >> >> 830-792-3400 phone >> >> 830-792-3404 fax >> >> sales at elecplus.com >> >> AOL IM elcpls >> >> >> > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 > > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 13:08:36 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 13:08:36 -0600 Subject: mainframes and other stuff In-Reply-To: <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> References: <014201d004f9$4e79d740$eb6d85c0$@com> <0F9C8643-122D-46DC-A8E6-91591D158888@mojovapes.net> <016701d004fb$3f8ef420$beacdc60$@com> <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> Message-ID: <081101d4c498$b06c07d0$11441770$@com> This post is being brought back to life. A fellow in Utica, NY has some T5140s. He is getting a list together for me. Local pickup available, or he will ship. Apparently the email for Alex is no longer viable. Getting emails from other dealers also, wanting to know if complete systems are wanted, or base machines? Price point? -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter Sent: Thursday, November 20, 2014 3:37 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: mainframes and other stuff I would be looking for the following for Sun, ill have to double check on the IBM machines. Sun Fire T1000 Sun Fire T2000 Sun Fire T5140 Sun Fire T5240 Sun Fire T5440 Sun Enterprise 10000 Sun Fire E25K Sun Fire V490 Sun Fire V890 Sun Fire V1280 Sun Fire V245 Sun Fire V215 > On Nov 20, 2014, at 2:50 PM, Electronics Plus wrote: > > > > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter > Sent: Thursday, November 20, 2014 1:42 PM > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: mainframes and other stuff > > I would have an interest in any larger Sun or IBM machines that aren?t x86. How many of these machines do they keep around? > > None at the moment. > > Not x86 is not specific enough. RS6000 series, or RS6000 model xxxx-xxx would work. > Sun pizza box won't work, but Sparc Station 2, 3, 4, these will; do you see what I mean? > > > Cindy > >> On Nov 20, 2014, at 2:36 PM, Electronics Plus wrote: >> >> Mainframes and other stuff >> >> >> >> Recycle center in NC is willing to save out "stuff" for people. >> >> No, no one can go in the back and scrounge. >> >> No, he does not want a lot of emails from people. >> >> Yes, he gets big blue and orange and beige 6 foot tall OLD mainframes >> in all the time. They squash them at the moment. >> >> Yes, he will package small orders, and will properly palletize larger >> orders. >> >> Local pick up will be available after the new year. >> >> >> >> So, if u can send me a picture with description and some part numbers, >> along with what you want to pay, I will consolidate things and make arrangements. >> >> Please don't ask for specific boards from DEC; they don't want to go >> into that much detail. >> >> QBUS will mean nothing to him. >> >> Big orange cabinet that says xxxxx is much more likely to get saved. >> >> >> >> They are moving to new warehouse 1st of the month, so all this will >> start happening after the 1st of the year. >> >> >> >> Cindy Croxton >> >> Electronics Plus >> >> 1613 Water Street >> >> Kerrville, TX 78028 >> >> 830-792-3400 phone >> >> 830-792-3404 fax >> >> sales at elecplus.com >> >> AOL IM elcpls >> >> >> > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 > > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 13:11:13 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 13:11:13 -0600 Subject: mainframes and other stuff In-Reply-To: <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> References: <014201d004f9$4e79d740$eb6d85c0$@com> <0F9C8643-122D-46DC-A8E6-91591D158888@mojovapes.net> <016701d004fb$3f8ef420$beacdc60$@com> <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> Message-ID: <081201d4c499$0dffb810$29ff2830$@com> Memory Ten in California has Sun Fire T1000 Sun Fire T2000 Sun Fire T5240 V490 V245 and more. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter Sent: Thursday, November 20, 2014 3:37 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: mainframes and other stuff I would be looking for the following for Sun, ill have to double check on the IBM machines. Sun Fire T1000 Sun Fire T2000 Sun Fire T5140 Sun Fire T5240 Sun Fire T5440 Sun Enterprise 10000 Sun Fire E25K Sun Fire V490 Sun Fire V890 Sun Fire V1280 Sun Fire V245 Sun Fire V215 > On Nov 20, 2014, at 2:50 PM, Electronics Plus wrote: > > > > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter > Sent: Thursday, November 20, 2014 1:42 PM > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: mainframes and other stuff > > I would have an interest in any larger Sun or IBM machines that aren?t x86. How many of these machines do they keep around? > > None at the moment. > > Not x86 is not specific enough. RS6000 series, or RS6000 model xxxx-xxx would work. > Sun pizza box won't work, but Sparc Station 2, 3, 4, these will; do you see what I mean? > > > Cindy > >> On Nov 20, 2014, at 2:36 PM, Electronics Plus wrote: >> >> Mainframes and other stuff >> >> >> >> Recycle center in NC is willing to save out "stuff" for people. >> >> No, no one can go in the back and scrounge. >> >> No, he does not want a lot of emails from people. >> >> Yes, he gets big blue and orange and beige 6 foot tall OLD mainframes >> in all the time. They squash them at the moment. >> >> Yes, he will package small orders, and will properly palletize larger >> orders. >> >> Local pick up will be available after the new year. >> >> >> >> So, if u can send me a picture with description and some part numbers, >> along with what you want to pay, I will consolidate things and make arrangements. >> >> Please don't ask for specific boards from DEC; they don't want to go >> into that much detail. >> >> QBUS will mean nothing to him. >> >> Big orange cabinet that says xxxxx is much more likely to get saved. >> >> >> >> They are moving to new warehouse 1st of the month, so all this will >> start happening after the 1st of the year. >> >> >> >> Cindy Croxton >> >> Electronics Plus >> >> 1613 Water Street >> >> Kerrville, TX 78028 >> >> 830-792-3400 phone >> >> 830-792-3404 fax >> >> sales at elecplus.com >> >> AOL IM elcpls >> >> >> > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 > > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 13:14:15 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 13:14:15 -0600 Subject: mainframes and other stuff In-Reply-To: <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> References: <014201d004f9$4e79d740$eb6d85c0$@com> <0F9C8643-122D-46DC-A8E6-91591D158888@mojovapes.net> <016701d004fb$3f8ef420$beacdc60$@com> <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> Message-ID: <081401d4c499$7a784610$6f68d230$@com> David Beinstein / Sr. Account Executive Vibrant Technologies 6533 Flying Cloud Drive, Suite 1200, Eden Prairie, MN 55344 dbeinstein at vibrant.com | 952-653-1749 (O) | 203-913-6967 (C) SKYPE Vibrant DBeinstein TRILLIAN VibrantDavid Old DEC and Sun servers and other things. Please email him directly. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter Sent: Thursday, November 20, 2014 3:37 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: mainframes and other stuff I would be looking for the following for Sun, ill have to double check on the IBM machines. Sun Fire T1000 Sun Fire T2000 Sun Fire T5140 Sun Fire T5240 Sun Fire T5440 Sun Enterprise 10000 Sun Fire E25K Sun Fire V490 Sun Fire V890 Sun Fire V1280 Sun Fire V245 Sun Fire V215 > On Nov 20, 2014, at 2:50 PM, Electronics Plus wrote: > > > > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter > Sent: Thursday, November 20, 2014 1:42 PM > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: mainframes and other stuff > > I would have an interest in any larger Sun or IBM machines that aren?t x86. How many of these machines do they keep around? > > None at the moment. > > Not x86 is not specific enough. RS6000 series, or RS6000 model xxxx-xxx would work. > Sun pizza box won't work, but Sparc Station 2, 3, 4, these will; do you see what I mean? > > > Cindy > >> On Nov 20, 2014, at 2:36 PM, Electronics Plus wrote: >> >> Mainframes and other stuff >> >> >> >> Recycle center in NC is willing to save out "stuff" for people. >> >> No, no one can go in the back and scrounge. >> >> No, he does not want a lot of emails from people. >> >> Yes, he gets big blue and orange and beige 6 foot tall OLD mainframes >> in all the time. They squash them at the moment. >> >> Yes, he will package small orders, and will properly palletize larger >> orders. >> >> Local pick up will be available after the new year. >> >> >> >> So, if u can send me a picture with description and some part numbers, >> along with what you want to pay, I will consolidate things and make arrangements. >> >> Please don't ask for specific boards from DEC; they don't want to go >> into that much detail. >> >> QBUS will mean nothing to him. >> >> Big orange cabinet that says xxxxx is much more likely to get saved. >> >> >> >> They are moving to new warehouse 1st of the month, so all this will >> start happening after the 1st of the year. >> >> >> >> Cindy Croxton >> >> Electronics Plus >> >> 1613 Water Street >> >> Kerrville, TX 78028 >> >> 830-792-3400 phone >> >> 830-792-3404 fax >> >> sales at elecplus.com >> >> AOL IM elcpls >> >> >> > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 > > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 13:28:45 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 13:28:45 -0600 Subject: mainframes and other stuff In-Reply-To: <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> References: <014201d004f9$4e79d740$eb6d85c0$@com> <0F9C8643-122D-46DC-A8E6-91591D158888@mojovapes.net> <016701d004fb$3f8ef420$beacdc60$@com> <71D9E8F8-2808-41F1-B2F0-50E30C30FE26@mojovapes.net> Message-ID: <082a01d4c49b$8100df40$83029dc0$@com> Fred Dikeman Data Instruments, Inc O 1-770-919-2400 Atlanta GA area. Old Sun, DEC, Dell, mostly all vintage stuff. No IBM stuff. Pallets of old Cisco comm. equip. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter Sent: Thursday, November 20, 2014 3:37 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: mainframes and other stuff I would be looking for the following for Sun, ill have to double check on the IBM machines. Sun Fire T1000 Sun Fire T2000 Sun Fire T5140 Sun Fire T5240 Sun Fire T5440 Sun Enterprise 10000 Sun Fire E25K Sun Fire V490 Sun Fire V890 Sun Fire V1280 Sun Fire V245 Sun Fire V215 > On Nov 20, 2014, at 2:50 PM, Electronics Plus wrote: > > > > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alex McWhirter > Sent: Thursday, November 20, 2014 1:42 PM > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: mainframes and other stuff > > I would have an interest in any larger Sun or IBM machines that aren?t x86. How many of these machines do they keep around? > > None at the moment. > > Not x86 is not specific enough. RS6000 series, or RS6000 model xxxx-xxx would work. > Sun pizza box won't work, but Sparc Station 2, 3, 4, these will; do you see what I mean? > > > Cindy > >> On Nov 20, 2014, at 2:36 PM, Electronics Plus wrote: >> >> Mainframes and other stuff >> >> >> >> Recycle center in NC is willing to save out "stuff" for people. >> >> No, no one can go in the back and scrounge. >> >> No, he does not want a lot of emails from people. >> >> Yes, he gets big blue and orange and beige 6 foot tall OLD mainframes >> in all the time. They squash them at the moment. >> >> Yes, he will package small orders, and will properly palletize larger >> orders. >> >> Local pick up will be available after the new year. >> >> >> >> So, if u can send me a picture with description and some part numbers, >> along with what you want to pay, I will consolidate things and make arrangements. >> >> Please don't ask for specific boards from DEC; they don't want to go >> into that much detail. >> >> QBUS will mean nothing to him. >> >> Big orange cabinet that says xxxxx is much more likely to get saved. >> >> >> >> They are moving to new warehouse 1st of the month, so all this will >> start happening after the 1st of the year. >> >> >> >> Cindy Croxton >> >> Electronics Plus >> >> 1613 Water Street >> >> Kerrville, TX 78028 >> >> 830-792-3400 phone >> >> 830-792-3404 fax >> >> sales at elecplus.com >> >> AOL IM elcpls >> >> >> > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 > > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4794 / Virus Database: 4189/8600 - Release Date: 11/20/14 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 13:36:23 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 13:36:23 -0600 Subject: Sun T5440 servers, configured Message-ID: <083a01d4c49c$91a8fb60$b4faf220$@com> Hello Cindy. I did have some of the Sun T5440's in stock. I can cover at least 4 units that would be configured. The config and cost is listed below. Let me know if you need the config adjusted in any way. Thank you. (qty-4) T5440/4x1.4ghz/128gb/2x300gbhd/DVD: $525 each BEN WILLIAMS SUN - ORACLE BROKER REP P: 315-732-1420 EXT.304 F: 315-732-1502 SKYPE: BEN at ADIRONDACKNETWORKS.NET TRILLIAN: BENANET Please contact him directly to purchase. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 14:17:24 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 14:17:24 -0600 Subject: Sun stuff in Canada Message-ID: <087a01d4c4a2$4cb08590$e61190b0$@com> WTS sun T5220, USED, qty 10, CALL, We have a huge qty of sun available interested let me know sun equip available now: 1X STORAGETEK 3510 FC 1X x4100 m2 1X sparc t520 3 x enterprise 250 1X SUN SPARC 220r 2 X SUNFIRE V210 4 X ENTERPRISE T5120 1X ENTERPRISE M4000 1X SUNFIRE V4440 1X sunfire V880 3X X SUNFIRE 240 2X SUNFIRE V245 5 X SUNFIRE V490 1X SUNFIRE 280R 3 X SUNFIRE 440 1X SUNFIRE 4200 1X SUNFIRE 4100 1X SUNFIRE X4100 M2 5X SUNFIRE V120 25 X BLADE T6340 1X BLADE T6240 10 X BLADE CHASSIS 6000 2 X BLADE X6220 1X BLADE T6320 10 X BLADE T6300 Daniel Fecteau 6025 Arthur sauv? Mirabel, Quebec J7N 2W4 TEL: 450-969-1616 ext 101 Mail: save at savesysteme.com Does not have to be sold as a lot, you can pick and choose. Please contact Daniel directly if interested. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From sales at elecplus.com Thu Feb 14 14:18:32 2019 From: sales at elecplus.com (Electronics Plus) Date: Thu, 14 Feb 2019 14:18:32 -0600 Subject: Sun dealer in CA Message-ID: <088501d4c4a2$756c60d0$60452270$@com> Ken Bush - IT Solutions Specialist Parallel Technology, LLC 23510 Telo Ave #7 Torrance, CA 90505 310-320-8477 x1 Trillian "kenbush4sun" Lots of old Sun gear, will configure as requested. Please contact him directly. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From saburwulf at gmail.com Thu Feb 14 10:50:15 2019 From: saburwulf at gmail.com (Josh) Date: Thu, 14 Feb 2019 08:50:15 -0800 Subject: Intel PC-BUBBLE Card documentation? In-Reply-To: References: Message-ID: The empty 40-pin should be an Intel 7224 if the card is using 7114 bubble modules, and the 7220 if it's the 7110 bubble modules. For the card in question, I'm pretty sure it's the 7114 module. The IC is required as that's the bubble memory controller itself. On Wed, Feb 13, 2019 at 4:39 PM Chris Hanson via cctalk < cctalk at classiccmp.org> wrote: > Does anyone have documentation stashed away for the Intel PC-BUBBLE Card? > The PC-BUBBLE is an 8-bit ISA card that Intel produced for prototyping > bubble memory applications in the mid-1980s, the ROM on mine is v3.0 and > says it?s copyright 1986. > > I don?t want to insert this into a system until I?m sure all the (many) > jumpers are configured reasonably, and I?m sure that the empty 40-pin > socket at U5 isn?t something that?s critical to its operation? > > -- Chris > > From frisbie at flying-disk.com Thu Feb 14 12:24:36 2019 From: frisbie at flying-disk.com (Alan Frisbie) Date: Thu, 14 Feb 2019 10:24:36 -0800 (PST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <19021410243597_448@slug.flying-disk.com> Ethan Dicks wrote: > I have had an RK11-C for a long time that I've never tried to > power up (I got an RKV11-D and used that on Qbus machines > instead). Wow, someone else with an RKV11-D! I thought I was the only person who had one. I modified mine (using the dead bug technique) to add 18-bit addressing instead of just 16, and ran it successfully with RT-11 and RSX-11M on my 11/73 system. I have had DEC people visit my place, look at the RKV11-D, and say "DEC never made anything like that!". :-) Alan "and I don't exist either" Frisbie From jnc at mercury.lcs.mit.edu Thu Feb 14 17:46:53 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 14 Feb 2019 18:46:53 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190214234653.4416118C0AA@mercury.lcs.mit.edu> > From: Paul Koning > or a backup team of subsystem experts at the home office to call on. Actually, the actual hardware problem wasn't too hard for Fritz to find, I gather, once we knew exactly was failing (the RK11), and how (at 0170000, the XM incremented). It's not like it was a comes-and-goes kind of problem (it was quite solid and repeatable), or anything like that, so I'm not sure a 'team of experts' would really have helped. And the exact details on the failure were also pretty easy to find, once we got past a lot of other distractions! Once it became clear that the pure text was getting trashed, it was pretty easy (modulo some confusion caused by the differing OS images in the 'Ritchie' and 'Wellsch' distros :-) to stop the machine once it had a) assembled the pure text in main memory, and b) swapped it out. Looking at the copy in main memory verified it was good _before_ it was swapped, looking at the arguments on the stack gave us the disk block it was written to, and looking at the actual contents of the RK (which PDP11GUI has a mode to do) showed us the first 02400 bytes were good, and then it was trash. Bingo! Then, looking at the RK registers after the transfer had completed showed something had gone wrong in the hardware - the address left showing afterward was not the start_address+size - the XM had incremented inappropriately! And since the start address for the transfer in physical memory was 0165400, and 0165400+2400 = 0170000, that sounded pretty suspicious! So, that all happened pretty quickly. Really, the part that took the longest was getting past all the confusing noise: my confusion about R5, the malfunctioning front panel, the different versions of the OS, etc, etc. Noel From spacewar at gmail.com Thu Feb 14 18:25:27 2019 From: spacewar at gmail.com (Eric Smith) Date: Thu, 14 Feb 2019 17:25:27 -0700 Subject: Intel PC-BUBBLE Card documentation? In-Reply-To: References: Message-ID: On Thu, Feb 14, 2019 at 2:53 PM Josh via cctalk wrote: > The empty 40-pin should be an Intel 7224 if the card is using 7114 bubble > modules, and the 7220 if it's the 7110 bubble modules. > Although there is a datasheet for the 7224, I don't think it went into volume production. It looks like they made the 7225 instead. I'm not sure what, if any, differences there are between the 7224 and 7225; it might just be a part number change. For the 7220 used with Intel 1Mbit bubble devices (7110), one has to be sure that it's an _Intel_ 7220, usually D7220-1. The NEC ?PD7220 is a graphics chip (equivalent to Intel 82720). From fritzm at fritzm.org Thu Feb 14 18:39:30 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Thu, 14 Feb 2019 16:39:30 -0800 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <20190214234653.4416118C0AA@mercury.lcs.mit.edu> References: <20190214234653.4416118C0AA@mercury.lcs.mit.edu> Message-ID: <750A3018-ACBB-4840-9359-3B5D05569C07@fritzm.org> That's right -- I wasn't without an army, it was just a very small and quite dedicated army! :-) I think I'd have gone down many blind alleys without help and perspective provided by others here, and in particular a lot guidance provided by Noel over the past couple weeks in private correspondence enabling the use of V6 as a test case and investigative tool. For this I am very grateful. As those of you who have worked on these machines know, they are just so damn serviceable, by design. It's very empowering! --FritzM. From Kevin at RawFedDogs.net Thu Feb 14 21:28:38 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Thu, 14 Feb 2019 21:28:38 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? Message-ID: <20190215032837.GA2556@RawFedDogs.net> Classic Computer Fans, I posted this to the IBM-Legacy-Hercules mailing list. I just realized it probably wouldn't hurt to post it here too. I'm finally in possession of a box that hopefully is capable or can be made capable of connecting a real terminal to Hercules. It's a 3174 11L. It was retired last year where I work. I finally got the okay to save it from being sent to a scrapper. I love the build quality of older IBM gear, except when I'm trying to move such gear. Between the 3174 and a 9406-520 I also acquired, I pulled or strained something in my left arm moving them into place. It's currently wired to run on 220v. I think I've seen mentioned somewhere that it can be changed to run on 110v. If that's the case, does anyone have a pointer to documentation on what's involved? It has dual floppy drives. At least one drive is a 2.4MB drive. But, all the microcode disks I have are at level B 4.6. Does anyone know where I can get a set of C 6.4 control and control extension disks. From what I've heard those are what's needed to enable an attached terminal to connect to other systems via telnet. It has a token ring card. I will probably be able to get the MAU it was connected to, and possibly the router that acted as a token ring to Ethernet bridge. I'm not sure how much memory it has. Does anyone have any tips on determining the amount of memory it has, and/or identifying its boards? These are the numbers on its boards: 9210 9351 9052 z2 9053 9501 Plus the boards for coax connections. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. ------------------------------------ Posted by: Kevin Monceaux ------------------------------------ ------------------------------------ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/ibm-legacy-hercules/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/ibm-legacy-hercules/join (Yahoo! ID required) <*> To change settings via email: ibm-legacy-hercules-digest at yahoogroups.com ibm-legacy-hercules-fullfeatured at yahoogroups.com <*> To unsubscribe from this group, send an email to: ibm-legacy-hercules-unsubscribe at yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/ -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From technoid6502 at gmail.com Thu Feb 14 21:34:27 2019 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Thu, 14 Feb 2019 22:34:27 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: Message-ID: I got a laugh out of this anecdote. Of course, folks heard me chuckle and I tried to share the joke but.... Way too geeky for public consumption. Back in 2000-ish, I was upgrading my DG MV4000/dc to 8mb so as to be able to run the snazzy AOS/VS II tapes I'd got along with the 9 track drive I hacked onto the machine... The install would start and then bomb at a certain point every time. I decided to work the machine hard and then pull the board and give a good SNIFF. This is a 15x15 inch board populated with 256kx1 drams. The time in the machine got the board cooking nicely, and when I smelled a certain charred smell in the vicinity of a 74ls04, I knew it was that magic black smoke. I pulled a 74HCT04 from a known-good isa card, socketed the spot and viola! Working 8mb board. It isn't ALLWAYS the most expensive chip, thank God, and sometimes even us not- as-bright guys come off with a win. I really enjoy reading this list even though I don't contribute all that often or anything of much value. It is a pleasure to watch you guys work. Jeff On Thu, 2019-02-14 at 12:00 -0600, cctalk-request at classiccmp.org wrote: > Re: PDP-11/45 RSTS/E boot problem > When our 11/45 failed in the MMU in 1975, my classmate Josh Rosen traced the failing path on the schematics. When Jim Newport the field service engineer showed up, Josh described the diagnostics result that pointed at the failed path, and added "This is the failed chip" (pointing to one particular chip. Jim asked "Why that one?" Josh answered "because that is the most expensive chip". It turned out he was right. paul From cctalk at gtaylor.tnetconsulting.net Thu Feb 14 21:52:25 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Thu, 14 Feb 2019 20:52:25 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215032837.GA2556@RawFedDogs.net> References: <20190215032837.GA2556@RawFedDogs.net> Message-ID: On 2/14/19 8:28 PM, Kevin Monceaux via cctalk wrote: > I'm finally in possession of a box that hopefully is capable or can be > made capable of connecting a real terminal to Hercules. It's a 3174 11L. > It was retired last year where I work. I finally got the okay to save > it from being sent to a scrapper. I love the build quality of older > IBM gear, except when I'm trying to move such gear. Between the 3174 > and a 9406-520 I also acquired, I pulled or strained something in my > left arm moving them into place. Nice haul. > It has a token ring card. I will probably be able to get the MAU it > was connected to, and possibly the router that acted as a token ring to > Ethernet bridge. I'm quite interested in the network configuration. You mentioned telnet, which largely implies TCP/IP, which in combination with Token Ring means specific things. Things which I question about how much of a "bridge" the device was as much as a gateway. Or, if it's telnet like, but not actually telnet ~> TCP/IP, then it could be other things, but I think they are more problematic to "bridge" to Ethernet. -- Grant. . . . unix || die From pechter at gmail.com Thu Feb 14 22:16:01 2019 From: pechter at gmail.com (William Pechter) Date: Thu, 14 Feb 2019 23:16:01 -0500 Subject: PDP-11/45 RSTS/E boot problem Message-ID: <6e193035-d89c-1a7b-004c-53b1eecf328b@gmail.com> > Message: 2 > Date: Wed, 13 Feb 2019 15:03:41 -0500 > From: Paul Koning > To: Jay Jaeger , "General Discussion: On-Topic and > ??? Off-Topic Posts" > Subject: Re: PDP-11/45 RSTS/E boot problem > Message-ID: > Content-Type: text/plain;??? charset=us-ascii > > > > On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk > wrote: > > > > ... > > Maybe that story about FE's using Unix as a test to confirm operation > > even when diagnostics said the machine was OK was not so much just a > > legend? > > It still fels like a legend.? My experience with DEC field service > engineers is that they used the diagnostics.? In the PDP-11 era, Unix > knowledge around DEC was pretty sparse, especially early on when it > could be found only in the Telephone Products Group (Armando > Stettner).? RSTS would be more plausible, but I never saw that in the > hads of FS engineers either. > By and large diagnostics would find problems. I've seen a number in > the 1970s, including a messy data path failure in the 11/45 MMU where > we (college students) did the initial diagnosis while the FS engineer > was on his way. My suspicion is that things not solved by diagnostics > would be escalated to the "wizard from Maynard". And they'd probably > start replacing whole subsystems. I've seen that once, when our > college RSTS-11 system (11/20, 16 DL-11 lines) was crashing on average > once a day for months. DEC brought in several of those "wizards". The > "fix" was to replace the 11/20 by a "spare part" -- an 11/45 with more > memory, a DH11, and RSTS/E. Decades later I was told that the wizards > actually pinned the blame on the college FM broadcast transmitter, > about 200 feet down the hall from the computer center. That may well > be, though I didn't heard that at the time. RSTS did get used in > manufacturing, at Final Assembly & Test sites like Westminster MA and > Salem NH, where PDP-11 systems large enough to run RSTS/E were > subjected to a load test of exerciser programs running under that OS. > The way it was explained to us is that a system that would be happy > with such a test would also be happy with any customer application. > It's not clear if that was because RSTS would load things more than > most, or was more finicky about hardware glitches than most, but it > certainly was the practice for quite some time. Of course, not all > PDP-11 configurations could be tested that way. paul I guess the experience in NJ was a bit different since AT&T had two dedicated Field Service offices who handled their sites including Bell Labs. I was on the Commercial/Government side from 81-86 and we didn't get to play with RSTS on customer sites at all (but sometimes we got to play in the in-house machines in Princeton or on our own hardware). It was a bit different in the Vax side since many diags were run under VAX/VMS and as a brand new hire I was doing Vax installs -- including installing the VMS 2.x and 3.x on 11/780's and 11/750's at install time. If they had paid for software installation -- the software guys would wipe and reinstall. If not we left the pack and prayed the customer wouldn't wipe the diags that we installed on the disk when we build the VMS pack.? Realistically the only thing the customer needed to do after we got done was tweak the systen parameters, check the swap etc. and lay on the layered products like languages. Things got much more interesting when the VMS3.x and 4.x got CI780's and HSC50's.? That was more involved than the easy VMS 2.x-3.x install. As far as the 11/70's -- I'm building a pidp1170... My last 11/70 install was around 84 or so when I put in a late DECDatasystem 570 blue 11/70 with the FCC Cabinets at AT&T in Freehold. As far as the Wizard from Maynard -- one story from my branch support guy (rumored to be about his brother on the 11/70 line in (I think in Westminster MA... not Salem or other NH plants) had an intermittant 11/70 that would crash every couple of days and they could run all the diags and DEC X11 with no issues.? They called over their in-house wizard who ran toggle-in programs from the front panel -- playing the switches like piano keys with both hands.?? After about a half hour his comment was "Clean the terminator fingers." Machine ran like a SOB once the gold fingers were cleaned. Weirdest 11/70 mess I had was after I left DEC to work for a third party maintenance group.? Their regional support was in Dallas.? I was in NJ.? They couldn't find their support guy so they rushed me on a plane to Chicago to work with two techs who were babysitting a mess they had no clue on. The site was WW Granger in Skokie and I arrived at 3AM...? They had a 5 or 6 story warehouse which was a totally robotic automated site picking water heaters and other industrial equipment from what looked like an over-sized 6 floor tape library.? Two 11/34's running RSX11 ran the picker.? One was down for weeks.? Their 11/70 was half disassembled with two techs working on it.? They were VAX trained at a third party school but they weren't PDP11 techs.? An RM03 on the 11/34's was down as well. The 11/70 was a RSTS/E box doing all the billing and inventory for Granger at the site. I walked in at 3AM with my Digital truckers cap on and found they couldn't boot XXDP+ from tape. The OS wouldn't come up either. The customer gave me a pile of error logs dating back over six months -- (I think Sept through March) and they all showed memory management error aborts and retries. The techs who thought they were changing memory never found the MOS memory box... they were swapping cache boards thinking they were memory. Went to 10000 and deposited 014747 and ran it... It either failed on addresses ending in 0 or 4 or 2 or 6. The MOS on the 11/70 had two controllers and interleaved the memory.? Pulled one of the interleave controllers -- ran the toggle in and it worked.? Aha... bad memory controller. Booted diags and sent for the board spare. Decided the RM03 would be a bitch to work on without the tester or tools and the management found a spare locally at a used DEC joint in the area.? Swapped the drive once we carried the new one up the stairs. The 11/34 had a problem... the machine wouldn't boot and the run light (IIRC) was on all the time. The machine had two full unibus dd11-dk boxes even though it didn't need them all. Terminated at the CPU backplane and did toggle-ins.? OK.? Worked... jumpered out the next UNUSED segment of the Unibus backplane with a Unibus ribbon cable and the problem was gone. The guys had been there over two weeks digging themselves a hole.? Third party service on DEC stuff varied with the person.? Some were ex-DEC genius types who were consultant level experts on the hardware.? Some just knew to swap the board with the Red Led lit. Another time I ran into an engineer who told me (chip info here faked -- don't pull the prints...too many years to have kept TE16/TM03 prints). A call comes in to dispatch with the following information: "The TE16 at Naval Air Propulsion, Trenton is down.? It doesn't come on line.? The light is lit but the system doesn't see it.? I put the board on an They supposedly changed memory on the 11/70 -- but wextender and U34 pin 12 is low and doesn't go high. I need someone to come out and change the chip." I call the site back.? I'm in Princeton 15-20 minutes away.? I get the customer on line and tell him I'll be there in 3 weeks or so.? DECservice 2 hour response won't cover the call since he wants a chip changed in 1985 and we don't stock them -- so it will be a special source issue for logistics and we'll get back to him.? Or... I can swap the M8916 Logic And Write board in about15 minutes.? Does he want it fixed or does he want to prove he called the correct chip... Bill From jstefanikcctalk at gmail.com Thu Feb 14 22:23:30 2019 From: jstefanikcctalk at gmail.com (Jim Stefanik) Date: Thu, 14 Feb 2019 22:23:30 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215032837.GA2556@RawFedDogs.net> Message-ID: Simon Systems should be able to get you the microcode diskettes. I think they charged me around $35 USD when I bought in Nov. 2017.? Send them an email and let them know what you need. https://simonsys.com/ On a side note, I may need to ping you off list...I've got an 11R and I'm curious if it can be converted to an 11L, since I'd prefer to channel attach it to my machine instead of use ethernet. -Jim ________________________________ From: Kevin Monceaux via cctalk Sent: Thursday, 14 February 2019 21:28 To: General Discussion: On-Topic and Off-Topic Posts Subject: IBM 3174 C 6.4 Microcode Disks? Classic Computer Fans, I posted this to the IBM-Legacy-Hercules mailing list.? I just realized it probably wouldn't hurt to post it here too. I'm finally in possession of a box that hopefully is capable or can be made capable of connecting a real terminal to Hercules.? It's a 3174 11L.? It was retired last year where I work.? I finally got the okay to save it from being sent to a scrapper.? I love the build quality of older IBM gear, except when I'm trying to move such gear.? Between the 3174 and a 9406-520 I also acquired, I pulled or strained something in my left arm moving them into place. It's currently wired to run on 220v.? I think I've seen mentioned somewhere that it can be changed to run on 110v.? If that's the case, does anyone have a pointer to documentation on what's involved? It has dual floppy drives.? At least one drive is a 2.4MB drive.? But, all the microcode disks I have are at level B 4.6.? Does anyone know where I can get a set of C 6.4 control and control extension disks.? From what I've heard those are what's needed to enable an attached terminal to connect to other systems via telnet. It has a token ring card.? I will probably be able to get the MAU it was connected to, and possibly the router that acted as a token ring to Ethernet bridge. I'm not sure how much memory it has.? Does anyone have any tips on determining the amount of memory it has, and/or identifying its boards? These are the numbers on its boards: ??? 9210 ??? 9351 ??? 9052 z2 ??? 9053 ??? 9501 Plus the boards for coax connections. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. ------------------------------------ Posted by: Kevin Monceaux ------------------------------------ ------------------------------------ Yahoo Groups Links <*> To visit your group on the web, go to: ??? http://groups.yahoo.com/group/ibm-legacy-hercules/ <*> Your email settings: ??? Individual Email | Traditional <*> To change settings online go to: ??? http://groups.yahoo.com/group/ibm-legacy-hercules/join ??? (Yahoo! ID required) <*> To change settings via email: ??? ibm-legacy-hercules-digest at yahoogroups.com ??? ibm-legacy-hercules-fullfeatured at yahoogroups.com <*> To unsubscribe from this group, send an email to: ??? ibm-legacy-hercules-unsubscribe at yahoogroups.com <*> Your use of Yahoo Groups is subject to: ??? https://info.yahoo.com/legal/us/yahoo/utos/terms/ -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From Kevin at RawFedDogs.net Thu Feb 14 23:03:09 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Thu, 14 Feb 2019 23:03:09 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215032837.GA2556@RawFedDogs.net> Message-ID: <20190215050309.GA26741@RawFedDogs.net> Grant, On Thu, Feb 14, 2019 at 08:52:25PM -0700, Grant Taylor via cctalk wrote: > Nice haul. I also acquired an RS/6000 7012-340, its 7208 8mm tape drive, and a couple of 9121 voice servers. It used to run DirectTalk/6000. > You mentioned telnet, which largely implies TCP/IP, which in combination > with Token Ring means specific things. Things which I question about > how much of a "bridge" the device was as much as a gateway. I might have the terminology wrong. I not very familiar with the token ring side of things. By the time I got into mainframe operations about twenty years ago we only had a few token ring devices left. The RS/6000 mentioned above was only connected to the token ring side of our network. It connected to the 3174 via token ring to screen scrape emulated 3270 sessions. Before the RS/6000 was shut down, I was able to telnet to it from my PC, which was on the Ethernet side of the network. The router in is the Cisco 2500 series, perhaps a 2513. I found this photo on the net, which looks like the router in question, if I remember correctly: https://kyozoufs.blob.core.windows.net/filestoragetcdb/Pictures/_30/29886/29885389.jpg As for using telnet on the 3174, I'm going by what I've seen posted on Hercules mailing lists about how others have connected real terminals to the Hercules mainframe emulator. A few pictures of such terminals connected to Hercules can be found at: http://CoreStore.org/emuterm.htm The posts I've seen say one either needs a router to act as a token ring to Ethernet bridge, or a PC with both token ring and Ethernet cards in it to act as a bridge. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From Kevin at RawFedDogs.net Thu Feb 14 23:07:22 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Thu, 14 Feb 2019 23:07:22 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215032837.GA2556@RawFedDogs.net> Message-ID: <20190215050722.GB26741@RawFedDogs.net> Jim, On Thu, Feb 14, 2019 at 10:23:30PM -0600, Jim Stefanik via cctalk wrote: > Simon Systems should be able to get you the microcode diskettes. I think > they charged me around $35 USD when I bought in Nov. 2017.? Send them an > email and let them know what you need. Thanks!! I'll check with them. > On a side note, I may need to ping you off list...I've got an 11R and I'm > curious if it can be converted to an 11L, since I'd prefer to channel > attach it to my machine instead of use ethernet. Now I'm curious, as others on the list might also be. What machine do you have with bus and tag channels to connect an 11L to? Unfortunately I know nothing about converting an 11R to an 11L, or if it's even possible. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From jstefanikcctalk at gmail.com Thu Feb 14 23:37:34 2019 From: jstefanikcctalk at gmail.com (Jim Stefanik) Date: Thu, 14 Feb 2019 23:37:34 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215050722.GB26741@RawFedDogs.net> Message-ID: <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> Kevin, No problem in the link. As for my system, I've got a z800 (a 2066-0A1 to be exact). It's got ESCON, so I've got an Optica converter box of which the model number escapes me; but it's the replacement/alternative to the IBM Pacer boxes. That allows bus and tag gear to connect up to ESCON channels. As for converting R to L, I'll play around with stuff. Worst case, I'll just buy an 11L and use the 11R for spares or for messing around. --- Jim Stefanik Dallas Vintage Computing Center ________________________________ From: Kevin Monceaux via cctalk Sent: Thursday, 14 February 2019 23:07 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: IBM 3174 C 6.4 Microcode Disks? Jim, On Thu, Feb 14, 2019 at 10:23:30PM -0600, Jim Stefanik via cctalk wrote: > Simon Systems should be able to get you the microcode diskettes. I think > they charged me around $35 USD when I bought in Nov. 2017.? Send them an > email and let them know what you need. Thanks!!? I'll check with them. > On a side note, I may need to ping you off list...I've got an 11R and I'm > curious if it can be converted to an 11L, since I'd prefer to channel > attach it to my machine instead of use ethernet. Now I'm curious, as others on the list might also be.? What machine do you have with bus and tag channels to connect an 11L to? Unfortunately I know nothing about converting an 11R to an 11L, or if it's even possible. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From rdawson16 at hotmail.com Fri Feb 15 01:17:44 2019 From: rdawson16 at hotmail.com (Randy Dawson) Date: Fri, 15 Feb 2019 07:17:44 +0000 Subject: a timer for the PC - screen tme for the kids Message-ID: Before I develop this, I thought it may already exist, and the classiccmp mail list might be the place to ask. What we have, is the screen time problem with the kids. If we are not there hounding and policing them, they will be on for hours. All the medical community says, we need to limit their screen time, as it contributes to their AD disorder and schoolwork, homework failures. My idea was initially do this in hardware, with a timer, and a solid state relay to gate the AC to the PC. On further thought, I should be able to do this in software, with a timer that lets the PC run for an hour, and then shuts the PC down until the next 24 hour cycle. (Installs itself on windows startup) Has anybody seen this, before I re-invent the wheel? Randy From jim.manley at gmail.com Fri Feb 15 05:02:32 2019 From: jim.manley at gmail.com (Jim Manley) Date: Fri, 15 Feb 2019 04:02:32 -0700 Subject: a timer for the PC - screen tme for the kids In-Reply-To: References: Message-ID: Hi Randy, Here?s how to do it in Windows 10 (and probably 8): https://www.laptopmag.com/articles/set-time-limits-windows-10 For Windows 7: https://www.tech-recipes.com/rx/6900/windows-7-how-to-set-time-limits-for-a-child/ All the Best, Jim On Fri, Feb 15, 2019 at 00:17 Randy Dawson via cctalk wrote: > Before I develop this, I thought it may already exist, and the classiccmp > mail list might be the place to ask. > > What we have, is the screen time problem with the kids. If we are not > there hounding and policing them, they will be on for hours. > > All the medical community says, we need to limit their screen time, as it > contributes to their AD disorder and schoolwork, homework failures. > > My idea was initially do this in hardware, with a timer, and a solid state > relay to gate the AC to the PC. > > On further thought, I should be able to do this in software, with a timer > that lets the PC run for an hour, and then shuts the PC down until the next > 24 hour cycle. > (Installs itself on windows startup) > > Has anybody seen this, before I re-invent the wheel? > > Randy > From dave.g4ugm at gmail.com Fri Feb 15 05:04:17 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Fri, 15 Feb 2019 11:04:17 -0000 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215032837.GA2556@RawFedDogs.net> References: <20190215032837.GA2556@RawFedDogs.net> Message-ID: <0ea201d4c51e$321e14f0$965a3ed0$@gmail.com> 1) If it has a token ring card then it does not matter that it also has Bus+Tag channel card. It will still talk TCP/IP and other machines. 2) https://www.argecy.com/2389 have microcode. Al says he got some from them recently. I can copy the latest version but I am short of 2.4MB disks (and in th uk) 3) Boot up the diagnostics and utility disk. It will show the memory. There is a list of card numbers in the Maintenance Manual http://bitsavers.org/pdf/ibm/3174/SY27-2572-4_3174_1L_1R_2R_3R_11L_11R_12R_1 3R_Maintenance_May89.pdf 4) You need 2 x 2.4 or 1 x 2.4 and a hard disk for config C6. The smaller 3174's have a movable link for the PSU. No idea about the model 11.... Dave (also some info on old Lordsnet site via archive.org http://web.archive.org/web/20080820002806/http://www.lordsnet.com/UsedIBM317 4Summ.htm Dave > -----Original Message----- > From: cctalk On Behalf Of Kevin Monceaux > via cctalk > Sent: 15 February 2019 03:29 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: IBM 3174 C 6.4 Microcode Disks? > > Classic Computer Fans, > > I posted this to the IBM-Legacy-Hercules mailing list. I just realized it > probably wouldn't hurt to post it here too. > > I'm finally in possession of a box that hopefully is capable or can be made > capable of connecting a real terminal to Hercules. It's a 3174 11L. It was > retired last year where I work. I finally got the okay to save it from being sent > to a scrapper. I love the build quality of older IBM gear, except when I'm > trying to move such gear. Between the 3174 and a 9406-520 I also acquired, I > pulled or strained something in my left arm moving them into place. > > It's currently wired to run on 220v. I think I've seen mentioned somewhere > that it can be changed to run on 110v. If that's the case, does anyone have a > pointer to documentation on what's involved? > > It has dual floppy drives. At least one drive is a 2.4MB drive. But, all the > microcode disks I have are at level B 4.6. Does anyone know where I can get > a set of C 6.4 control and control extension disks. From what I've heard those > are what's needed to enable an attached terminal to connect to other > systems via telnet. > > It has a token ring card. I will probably be able to get the MAU it was > connected to, and possibly the router that acted as a token ring to Ethernet > bridge. > > I'm not sure how much memory it has. Does anyone have any tips on > determining the amount of memory it has, and/or identifying its boards? > These are the numbers on its boards: > > 9210 > 9351 > 9052 z2 > 9053 > 9501 > > Plus the boards for coax connections. > > > > -- > > Kevin > http://www.RawFedDogs.net > http://www.Lassie.xyz > http://www.WacoAgilityGroup.org > Bruceville, TX > > What's the definition of a legacy system? One that works! > Errare humanum est, ignoscere caninum. > > > ------------------------------------ > Posted by: Kevin Monceaux > ------------------------------------ > > > ------------------------------------ > > Yahoo Groups Links > > <*> To visit your group on the web, go to: > http://groups.yahoo.com/group/ibm-legacy-hercules/ > > <*> Your email settings: > Individual Email | Traditional > > <*> To change settings online go to: > http://groups.yahoo.com/group/ibm-legacy-hercules/join > (Yahoo! ID required) > > <*> To change settings via email: > ibm-legacy-hercules-digest at yahoogroups.com > ibm-legacy-hercules-fullfeatured at yahoogroups.com > > <*> To unsubscribe from this group, send an email to: > ibm-legacy-hercules-unsubscribe at yahoogroups.com > > <*> Your use of Yahoo Groups is subject to: > https://info.yahoo.com/legal/us/yahoo/utos/terms/ > > > > -- > > Kevin > http://www.RawFedDogs.net > http://www.Lassie.xyz > http://www.WacoAgilityGroup.org > Bruceville, TX > > What's the definition of a legacy system? One that works! > Errare humanum est, ignoscere caninum. From lproven at gmail.com Fri Feb 15 05:06:24 2019 From: lproven at gmail.com (Liam Proven) Date: Fri, 15 Feb 2019 12:06:24 +0100 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: Message-ID: On Fri, 15 Feb 2019 at 04:34, Jeffrey S. Worley via cctalk wrote: > > The install would start and then bomb at a certain point every time. I > decided to work the machine hard and then pull the board and give a > good SNIFF. Got a nose for a hardware fault, eh? ;-) And some of my younger colleagues thought it was strange that I could predict hard disk failures from the running noises they made, and later than that, whether WinNT's bus-mastering DMA-mode disk controller device driver was installed from the sound of the disk accesses while the machine booted. BTW, Jeff, Gmail bottom-quotes just fine. I'm using the web interface right now. Just hit Ctrl-A, trim as needed and move the cursor. Yes, it's a pain on mobile, so I try not to answer on mobiles! -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From edcross at gmail.com Fri Feb 15 05:07:55 2019 From: edcross at gmail.com (Ed C.) Date: Fri, 15 Feb 2019 12:07:55 +0100 Subject: a timer for the PC - screen tme for the kids In-Reply-To: References: Message-ID: I happen to be the CEO of Qustodio, we have a free version of the service that works on Windows computers and there's also Mac and mobile devices support, let me know if I can help anyhow. Regards. On Fri, Feb 15, 2019 at 12:02 PM Jim Manley via cctalk < cctalk at classiccmp.org> wrote: > Hi Randy, > > Here?s how to do it in Windows 10 (and probably 8): > > https://www.laptopmag.com/articles/set-time-limits-windows-10 > > > For Windows 7: > > > https://www.tech-recipes.com/rx/6900/windows-7-how-to-set-time-limits-for-a-child/ > > > All the Best, > Jim > > > On Fri, Feb 15, 2019 at 00:17 Randy Dawson via cctalk < > cctalk at classiccmp.org> > wrote: > > > Before I develop this, I thought it may already exist, and the classiccmp > > mail list might be the place to ask. > > > > What we have, is the screen time problem with the kids. If we are not > > there hounding and policing them, they will be on for hours. > > > > All the medical community says, we need to limit their screen time, as it > > contributes to their AD disorder and schoolwork, homework failures. > > > > My idea was initially do this in hardware, with a timer, and a solid > state > > relay to gate the AC to the PC. > > > > On further thought, I should be able to do this in software, with a timer > > that lets the PC run for an hour, and then shuts the PC down until the > next > > 24 hour cycle. > > (Installs itself on windows startup) > > > > Has anybody seen this, before I re-invent the wheel? > > > > Randy > > > From cctalk at beyondthepale.ie Fri Feb 15 06:46:15 2019 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Fri, 15 Feb 2019 12:46:15 +0000 (WET) Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <750A3018-ACBB-4840-9359-3B5D05569C07@fritzm.org> References: <20190214234653.4416118C0AA@mercury.lcs.mit.edu> Message-ID: <01R38TI6VLG88WXLWI@beyondthepale.ie> Fritz Mueller wrote: > > That's right -- I wasn't without an army, it was just a very small and > quite dedicated army! :-) > > I think I'd have gone down many blind alleys without help and perspective > provided by others here, and in particular a lot guidance provided by Noel > over the past couple weeks in private correspondence enabling the use of > V6 as a test case and investigative tool. For this I am very grateful. > I very much enjoyed following the story of tracking down this fault. Thanks for sharing it. > > As those of you who have worked on these machines know, they are just so > damn serviceable, by design. It's very empowering! > I wish that this was also the case with several DEC Alphas I have with cache failures that are not nearly so serviceable or empowering :-( Regards, Peter Coghlan. > > --FritzM. > From paulkoning at comcast.net Fri Feb 15 07:59:37 2019 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 15 Feb 2019 08:59:37 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: Message-ID: <529590FC-83E1-485D-B3B7-6FB5FD40CFF9@comcast.net> > On Feb 15, 2019, at 6:06 AM, Liam Proven via cctalk wrote: > > On Fri, 15 Feb 2019 at 04:34, Jeffrey S. Worley via cctalk > wrote: >> >> The install would start and then bomb at a certain point every time. I >> decided to work the machine hard and then pull the board and give a >> good SNIFF. > > Got a nose for a hardware fault, eh? ;-) > > And some of my younger colleagues thought it was strange that I could > predict hard disk failures from the running noises they made, and > later than that, whether WinNT's bus-mastering DMA-mode disk > controller device driver was installed from the sound of the disk > accesses while the machine booted. Speaking of sounds made by machines, there is a famous security paper from a few years ago in which researchers read the encryption keys out of smartphones by listening to the sounds made by the device while it was execution the crypto algorithms. These hardware wizard stories remind me of a legendary repair wizard, non-computer industrial devices I think. He was called in to fix a tricky problem at the customer site. Studied it for a while, took out a small hammer, whacked the device at some spot, and reported "fixed". He then sent in a bill for $500. Customer challenged that with a demand to itemize the work. The itemized bill came back like this: 1. Applying impact to the device: $5 2. Knowing where and how to apply the impact: $495 paul From Kevin at RawFedDogs.net Fri Feb 15 09:03:17 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Fri, 15 Feb 2019 09:03:17 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> References: <20190215050722.GB26741@RawFedDogs.net> <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> Message-ID: <20190215150317.GA4463@RawFedDogs.net> Jim, On Thu, Feb 14, 2019 at 11:37:34PM -0600, Jim Stefanik via cctalk wrote: > As for my system, I've got a z800 (a 2066-0A1 to be exact). Nice!! > It's got ESCON, so I've got an Optica converter box of which the model > number escapes me; but it's the replacement/alternative to the IBM Pacer > boxes. That allows bus and tag gear to connect up to ESCON channels. My 3174 was last attached to a z890, 2086-A04, via a similar ESCON converter box. Actually, they might be the same. The name Optica sounds familiar. We have five or six of them under the floor. I haven't pulled them yet, but they're on my list. Since we've downgraded to an AS/400 based platform, the powers that be want "all that old mainframe stuff" out of our computer room. Fortunately I managed to get permission to haul off as much as I can myself before they get recyclers involved. Now if I could only fit a z890 in my minivan. :-) I know, they're not called AS/400s any more. We're on a POWER 8 box, an 8286-41A. But until IBM comes up with a new name that's an improvement over AS/400, we're sticking with that name. Apple was already using the letter i, and giving the platform a single letter name makes searching for online information about the platform a challenge. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From jfoust at threedee.com Fri Feb 15 09:16:06 2019 From: jfoust at threedee.com (John Foust) Date: Fri, 15 Feb 2019 09:16:06 -0600 Subject: a timer for the PC - screen tme for the kids In-Reply-To: References: Message-ID: <20190215151703.4FAE42740C@mx1.ezwind.net> At 01:17 AM 2/15/2019, Randy Dawson via cctalk wrote: >What we have, is the screen time problem with the kids. If we are not there hounding and policing them, they will be on for hours. There are also consumer firewall/routers that have time-based limits. When I've had clients ask about this, or also ask for content filtering, it's such a difficult world these days. The kids don't have tablets or phones or iPods that do WiFi and can get the Internets from cellular connections or the neighbor's WiFi? Kids rapidly figure out solutions to bypass limits. High schools have WiFi, block social media, the kids install VPNs on their phones. - John From lproven at gmail.com Fri Feb 15 09:29:20 2019 From: lproven at gmail.com (Liam Proven) Date: Fri, 15 Feb 2019 16:29:20 +0100 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <529590FC-83E1-485D-B3B7-6FB5FD40CFF9@comcast.net> References: <529590FC-83E1-485D-B3B7-6FB5FD40CFF9@comcast.net> Message-ID: On Fri, 15 Feb 2019 at 14:59, Paul Koning wrote: > > Speaking of sounds made by machines, there is a famous security paper from a few years ago in which researchers read the encryption keys out of smartphones by listening to the sounds made by the device while it was execution the crypto algorithms. ... wow. > These hardware wizard stories remind me of a legendary repair wizard, non-computer industrial devices I think. He was called in to fix a tricky problem at the customer site. Studied it for a while, took out a small hammer, whacked the device at some spot, and reported "fixed". He then sent in a bill for $500. > > Customer challenged that with a demand to itemize the work. The itemized bill came back like this: > > 1. Applying impact to the device: $5 > 2. Knowing where and how to apply the impact: $495 110 years old, and still apt. https://quoteinvestigator.com/2017/03/06/tap/ I first encountered it in the form of one of the AI Koans. I guess these are probably familiar to all here, but in case: http://people.cs.uchicago.edu/~wiseman/humor/ai-koans.html -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Fri Feb 15 09:31:38 2019 From: lproven at gmail.com (Liam Proven) Date: Fri, 15 Feb 2019 16:31:38 +0100 Subject: a timer for the PC - screen tme for the kids In-Reply-To: References: Message-ID: On Fri, 15 Feb 2019 at 08:17, Randy Dawson via cctalk wrote: > My idea was initially do this in hardware, with a timer, and a solid state relay to gate the AC to the PC. Sounds like a good way for a regularly-trashed boot disk filesystem to me, TBH. > Has anybody seen this, before I re-invent the wheel? I believe something like it is a built-in feature of Win10. But of course that almost certainly means there are well-documented hacks and workarounds. Getting built-in is the reason that $DAYJOB-3 killed its kid-monitoring-and-restricting product line. -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From dave.g4ugm at gmail.com Fri Feb 15 09:46:20 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Fri, 15 Feb 2019 15:46:20 -0000 Subject: a timer for the PC - screen tme for the kids In-Reply-To: <20190215151703.4FAE42740C@mx1.ezwind.net> References: <20190215151703.4FAE42740C@mx1.ezwind.net> Message-ID: <118601d4c545$99221530$cb663f90$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of John Foust via > cctalk > Sent: 15 February 2019 15:16 > To: cctalk at classiccmp.org > Subject: Re: a timer for the PC - screen tme for the kids > > At 01:17 AM 2/15/2019, Randy Dawson via cctalk wrote: > >What we have, is the screen time problem with the kids. If we are not > there hounding and policing them, they will be on for hours. > When my kids were kids, I used to install VNC and say I would be watching what they were doing so they had better behave. I seldom did. I doubt you could get away with that these days. You say "PC" so I assume MS Windows. It has a pretty good task scheduler that do all sorts of nasty things. (at the last place I worked someone who left because they said he wasn't skilled enough to promote scheduled a task on a server to send a salacious e-mail a month after he left) The "simplest" is to create a logon event that's does "shutdown /t nnnnnn /s" where "nnnnn" is the number of seconds of play time. You can set it up as a scheduled task that runs as administrator at logon and make them restricted users so they can't cancel the shutdown... ... but they can always switch on again, so you would need more logic to check the time at logon and log them off its outside permitted hours.... > There are also consumer firewall/routers that have time-based limits. > > When I've had clients ask about this, or also ask for content filtering, it's such > a difficult world these days. The kids don't have tablets or phones or iPods > that do WiFi and can get the Internets from cellular connections or the > neighbor's WiFi? > > Kids rapidly figure out solutions to bypass limits. High schools have WiFi, > block social media, the kids install VPNs on their phones. > > - John Dave From lproven at gmail.com Fri Feb 15 10:01:11 2019 From: lproven at gmail.com (Liam Proven) Date: Fri, 15 Feb 2019 17:01:11 +0100 Subject: a timer for the PC - screen tme for the kids In-Reply-To: <118601d4c545$99221530$cb663f90$@gmail.com> References: <20190215151703.4FAE42740C@mx1.ezwind.net> <118601d4c545$99221530$cb663f90$@gmail.com> Message-ID: On Fri, 15 Feb 2019 at 16:46, Dave Wade via cctalk wrote: > > The "simplest" is to create a logon event that's does "shutdown /t nnnnnn > /s" where "nnnnn" is the number of seconds of play time. No, honestly, there are much easier ways. https://www.laptopmag.com/articles/set-time-limits-windows-10 -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From cube1 at charter.net Fri Feb 15 10:22:13 2019 From: cube1 at charter.net (Jay Jaeger) Date: Fri, 15 Feb 2019 10:22:13 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215032837.GA2556@RawFedDogs.net> References: <20190215032837.GA2556@RawFedDogs.net> Message-ID: On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote: > Classic Computer Fans, > > I posted this to the IBM-Legacy-Hercules mailing list. I just realized it > probably wouldn't hurt to post it here too. > > I'm finally in possession of a box that hopefully is capable or can be made > capable of connecting a real terminal to Hercules. It's a 3174 11L. It was > retired last year where I work. I finally got the okay to save it from > being sent to a scrapper. I love the build quality of older IBM gear, > except when I'm trying to move such gear. Between the 3174 and a 9406-520 I > also acquired, I pulled or strained something in my left arm moving them > into place. > > It's currently wired to run on 220v. I think I've seen mentioned somewhere > that it can be changed to run on 110v. If that's the case, does anyone have > a pointer to documentation on what's involved? > > It has dual floppy drives. At least one drive is a 2.4MB drive. But, all > the microcode disks I have are at level B 4.6. Does anyone know where I can > get a set of C 6.4 control and control extension disks. From what I've > heard those are what's needed to enable an attached terminal to connect to > other systems via telnet. > > It has a token ring card. I will probably be able to get the MAU it was > connected to, and possibly the router that acted as a token ring to Ethernet > bridge. > > I'm not sure how much memory it has. Does anyone have any tips on > determining the amount of memory it has, and/or identifying its boards? > These are the numbers on its boards: > > 9210 > 9351 > 9052 z2 > 9053 > 9501 > > Plus the boards for coax connections. > > > I have some 3174 floppy disks, but I don't know what - they are not in my inventory. I will put it on my queue to look at them - but it may be a couple of weeks. I don't hold out much hope, but I will look. From cctalk at gtaylor.tnetconsulting.net Fri Feb 15 10:45:59 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 15 Feb 2019 09:45:59 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215150317.GA4463@RawFedDogs.net> References: <20190215050722.GB26741@RawFedDogs.net> <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> <20190215150317.GA4463@RawFedDogs.net> Message-ID: <46e29293-c483-27f1-0131-e215627998bb@spamtrap.tnetconsulting.net> On 02/15/2019 08:03 AM, Kevin Monceaux via cctalk wrote: > I know, they're not called AS/400s any more. We're on a POWER 8 box, > an 8286-41A. But until IBM comes up with a new name that's an improvement > over AS/400, we're sticking with that name. Apple was already using the > letter i, and giving the platform a single letter name makes searching > for online information about the platform a challenge. I think the ""proper (yes, with (air)quotes) name is "IBM i". So it's not a single letter. But it is a collision ala "A. Pope" from National Treasure. (Yes, that scene blew my mind. Hence it's the canonical example that I use.) -- Grant. . . . unix || die From jnc at mercury.lcs.mit.edu Fri Feb 15 10:56:47 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 15 Feb 2019 11:56:47 -0500 (EST) Subject: PDP-11/45 RSTS/E boot problem Message-ID: <20190215165647.25C0B18C07E@mercury.lcs.mit.edu> > From: Paul Koning > Studied it for a while, took out a small hammer, whacked the device at > some spot, and reported "fixed". That reminds me of an amusing story from the first time I went to see 'Star Wars; I went with a group of people from Tech Sq. It has that scene where they're about to make the jump to hyperspace in the 'Falcon', and it won't go; so one of them (I think Solo) jumps up and whacks a particular spot on the bulkhead with his fist, and away she goes. We all found this terribly amusing, since one of the DEC time-sharing systems on the 9th floor had a sticky relay in the power controller, and when you'd try to power it on or off from the front panel, the relay would stick, and nothing would happen. So the procedure was to go around the back, open a particular door, reach in, and whack the power controller behind it in a particular spot with the side of your fist, and away it went! Noel From wdonzelli at gmail.com Fri Feb 15 11:15:37 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Fri, 15 Feb 2019 12:15:37 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215150317.GA4463@RawFedDogs.net> References: <20190215050722.GB26741@RawFedDogs.net> <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> <20190215150317.GA4463@RawFedDogs.net> Message-ID: > I know, they're not called AS/400s any more. We're on a POWER 8 box, > an 8286-41A. But until IBM comes up with a new name that's an improvement > over AS/400, we're sticking with that name. Just like approximately everyone else. I have even heard IBMers involved with the machines stick to AS/400, although I am sure there have been reams of internal memos printed that command them otherwise. The change to z stuck, but the change to i was a bit of a disaster. -- Will, with 3272 From dave.g4ugm at gmail.com Fri Feb 15 11:18:10 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Fri, 15 Feb 2019 17:18:10 -0000 Subject: a timer for the PC - screen tme for the kids In-Reply-To: References: <20190215151703.4FAE42740C@mx1.ezwind.net> <118601d4c545$99221530$cb663f90$@gmail.com> Message-ID: <13f701d4c552$6d721450$48563cf0$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of Liam Proven via > cctalk > Sent: 15 February 2019 16:01 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: a timer for the PC - screen tme for the kids > > On Fri, 15 Feb 2019 at 16:46, Dave Wade via cctalk > wrote: > > > > The "simplest" is to create a logon event that's does "shutdown /t > > nnnnnn /s" where "nnnnn" is the number of seconds of play time. > > No, honestly, there are much easier ways. > > https://www.laptopmag.com/articles/set-time-limits-windows-10 > > It doesn't work!. Been a niggle with many managers for years. Well using the "net" command bit. It stops you logging in, but does not force a logoff.... https://superuser.com/questions/950660/how-to-setup-login-time-limits-a-k-a-parental-controls-if-you-dont-want-to so useless to keep kids off after a certain time, which is why I didn't mention it... ... you can set a policy as in the above link, BUT ONLY IF YOU HAVE PRO OR ABOVE. Windows/10 home does not have the gpedit.msc snap in... Dave > -- > Liam Proven - Profile: https://about.me/liamproven > Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com > Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven > UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From phb.hfx at gmail.com Fri Feb 15 12:27:36 2019 From: phb.hfx at gmail.com (Paul Berger) Date: Fri, 15 Feb 2019 14:27:36 -0400 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <46e29293-c483-27f1-0131-e215627998bb@spamtrap.tnetconsulting.net> References: <20190215050722.GB26741@RawFedDogs.net> <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> <20190215150317.GA4463@RawFedDogs.net> <46e29293-c483-27f1-0131-e215627998bb@spamtrap.tnetconsulting.net> Message-ID: <0c604f68-6e81-b907-35e9-bc81d72a2d3f@gmail.com> On 2019-02-15 12:45 p.m., Grant Taylor via cctalk wrote: > On 02/15/2019 08:03 AM, Kevin Monceaux via cctalk wrote: >> I know, they're not called AS/400s any more.? We're on a POWER 8 box, >> an 8286-41A.? But until IBM comes up with a new name that's an >> improvement over AS/400, we're sticking with that name.? Apple was >> already using the letter i, and giving the platform a single letter >> name makes searching for online information about the platform a >> challenge. > > I think the ""proper (yes, with (air)quotes) name is "IBM i".? So it's > not a single letter.? But it is a collision ala "A. Pope" from > National Treasure.? (Yes, that scene blew my mind.? Hence it's the > canonical example that I use.) > > > Knowledge Center refers to it as IBM i, but it is not the name of a system it is just the name of another OS that runs on IBM Power systems and can even be vitalized on a system with other OSes. Paul. From cclist at sydex.com Fri Feb 15 13:23:32 2019 From: cclist at sydex.com (Chuck Guzis) Date: Fri, 15 Feb 2019 11:23:32 -0800 Subject: a timer for the PC - screen tme for the kids In-Reply-To: References: Message-ID: <480ca7d0-ce86-a7e4-840e-99cc04eae509@sydex.com> On 2/14/19 11:17 PM, Randy Dawson via cctalk wrote: > Before I develop this, I thought it may already exist, and the classiccmp mail list might be the place to ask. > > What we have, is the screen time problem with the kids. If we are not there hounding and policing them, they will be on for hours. > > All the medical community says, we need to limit their screen time, as it contributes to their AD disorder and schoolwork, homework failures. > > My idea was initially do this in hardware, with a timer, and a solid state relay to gate the AC to the PC. > > On further thought, I should be able to do this in software, with a timer that lets the PC run for an hour, and then shuts the PC down until the next 24 hour cycle. > (Installs itself on windows startup) > > Has anybody seen this, before I re-invent the wheel? Dunno, but a good reason for the kids to learn Linux... :) Does Windows still have a "safe mode" startup? --Chuck From cisin at xenosoft.com Fri Feb 15 13:31:51 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Fri, 15 Feb 2019 11:31:51 -0800 (PST) Subject: a timer for the PC - screen tme for the kids In-Reply-To: <20190215151703.4FAE42740C@mx1.ezwind.net> References: <20190215151703.4FAE42740C@mx1.ezwind.net> Message-ID: On Fri, 15 Feb 2019, John Foust via cctalk wrote: > Kids rapidly figure out solutions to bypass limits. In these discouraging times, that brings hope for the next generation. They will learn programming skills, network management, how to work with others, or project management. Some might learn entrepreneurship and business management. Apple was built on a legacy of blue boxes. In my generation, before marijuana was legalized, that was where kids learned the metric system, commerce, and business management. From lproven at gmail.com Fri Feb 15 14:04:10 2019 From: lproven at gmail.com (Liam Proven) Date: Fri, 15 Feb 2019 21:04:10 +0100 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <0c604f68-6e81-b907-35e9-bc81d72a2d3f@gmail.com> References: <20190215050722.GB26741@RawFedDogs.net> <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> <20190215150317.GA4463@RawFedDogs.net> <46e29293-c483-27f1-0131-e215627998bb@spamtrap.tnetconsulting.net> <0c604f68-6e81-b907-35e9-bc81d72a2d3f@gmail.com> Message-ID: On Fri, 15 Feb 2019 at 19:27, Paul Berger via cctalk wrote: > Knowledge Center refers to it as IBM i, but it is not the name of a > system it is just the name of another OS that runs on IBM Power systems > and can even be vitalized on a system with other OSes. IBM moved the AS/400 onto POWER processors. The TIMI (sp?) firmware made this doable and binaries were portable from the old hardware. The OS was renamed i5/OS. Later they replaced the proprietary POWER hardware with generic POWER servers, and they renamed the OS to IBM i. IBM supports 3 OSes on POWER servers now: AIX, Linux and IBM i. Silly name, though. -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Fri Feb 15 14:07:00 2019 From: lproven at gmail.com (Liam Proven) Date: Fri, 15 Feb 2019 21:07:00 +0100 Subject: a timer for the PC - screen tme for the kids In-Reply-To: References: <20190215151703.4FAE42740C@mx1.ezwind.net> Message-ID: On Fri, 15 Feb 2019 at 20:31, Fred Cisin via cctalk wrote: > > In these discouraging times, that brings hope for the next generation. > > They will learn programming skills, On that note, this non-retro little computer really pleases me. https://basicengine.org/ It's a modern version of a 1980s home micro. $10 if you build it from one-off bits. Less in bulk. 32-bit RISC chip -- actually a wifi controller -- with a super fast BASIC interpreter, complete with structured programming and sprite commands and so on. The display is a DRAM chip that happens to be able to generate an analog monitor signal. Amazing little gadget. I have a PCB and plan to try to build one. -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From spectre at floodgap.com Fri Feb 15 15:43:59 2019 From: spectre at floodgap.com (Cameron Kaiser) Date: Fri, 15 Feb 2019 13:43:59 -0800 (PST) Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <0c604f68-6e81-b907-35e9-bc81d72a2d3f@gmail.com> from Paul Berger via cctalk at "Feb 15, 19 02:27:36 pm" Message-ID: <201902152143.x1FLhxHv22937604@floodgap.com> > Knowledge Center refers to it as IBM i, but it is not the name of a > system it is just the name of another OS that runs on IBM Power systems > and can even be vitalized on a system with other OSes. On *some* Power Systems machines. IBM really hates it if you try running it on Power hardware it's not licensed for, even if you can get it working (ditto for AIX). -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- TRUE HEADLINE: Morning-After Pill Decision Delayed ------------------------- From wilson at dbit.com Fri Feb 15 15:57:25 2019 From: wilson at dbit.com (John Wilson) Date: Fri, 15 Feb 2019 16:57:25 -0500 Subject: Paging Eric Smith, or current owner of DECSYSTEM-2065 from RCS/RI In-Reply-To: References: Message-ID: <20190215215725.GA21763@dbit.dbit.com> No luck with direct email (to either spacewar or brouhaha) or LinkedIn PM. I've been cleaning out my old garage and in the process, discovered some sheet metal (a pair of back doors for a double-wide cab, and one of the four white separator shims that goes between the three cabs) which belonged to the KL10 system that I donated to RCS/RI eons ago (and which they apparently sold rather than keep). Even though it's just cosmetic, and minor at that, I'd love to reunite this stuff with the rest of the system, wherever it wound up. I don't have the heart to scrap it (which is how I ended up with an 1100 sq ft garage full of antique computers in the first place, obviously). John Wilson Monson, MA From aek at bitsavers.org Fri Feb 15 16:59:58 2019 From: aek at bitsavers.org (Al Kossow) Date: Fri, 15 Feb 2019 14:59:58 -0800 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <0ea201d4c51e$321e14f0$965a3ed0$@gmail.com> References: <20190215032837.GA2556@RawFedDogs.net> <0ea201d4c51e$321e14f0$965a3ed0$@gmail.com> Message-ID: <7df16a49-bd77-f837-7ebc-fff3879b3876@bitsavers.org> On 2/15/19 3:04 AM, Dave Wade via cctalk wrote: > 2) https://www.argecy.com/2389 have microcode. Al says he got some from them > recently. I can copy the latest version but I am short of 2.4MB disks > (and in th uk) They have many revs of the firmware. I bought two, the last for the hard-disk supported 3174, and a set for an early 81R 2.4mb floppy media is unobtainium. I did ask if they had any. I bought a 91R to experiment with figuring out more about running the drives in ED mode, but have been busy with dealing with media recovery. From cctalk at gtaylor.tnetconsulting.net Fri Feb 15 17:27:04 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 15 Feb 2019 16:27:04 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <201902152143.x1FLhxHv22937604@floodgap.com> References: <201902152143.x1FLhxHv22937604@floodgap.com> Message-ID: <62fad68d-ac9a-6e69-6e07-615fd617f856@spamtrap.tnetconsulting.net> On 02/15/2019 02:43 PM, Cameron Kaiser via cctalk wrote: > On *some* Power Systems machines. IBM really hates it if you try running > it on Power hardware it's not licensed for, even if you can get it working > (ditto for AIX). I think Linux will run on any contemporary IBM POWER system. You need entitlement codes to enable AIX and / or IBM i. It's possible to run all three on one box. -- Grant. . . . unix || die From cctalk at beyondthepale.ie Fri Feb 15 17:23:28 2019 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Fri, 15 Feb 2019 23:23:28 +0000 (WET) Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: Message-ID: <01R39GBAJ3O88WXLWI@beyondthepale.ie> Jeffrey S. Worley wrote: > > Back in 2000-ish, I was upgrading my DG MV4000/dc to 8mb so as to be > able to run the snazzy AOS/VS II tapes I'd got along with the 9 track > drive I hacked onto the machine... > > The install would start and then bomb at a certain point every time. I > decided to work the machine hard and then pull the board and give a > good SNIFF. This is a 15x15 inch board populated with 256kx1 drams. > The time in the machine got the board cooking nicely, and when I > smelled a certain charred smell in the vicinity of a 74ls04, I knew it > was that magic black smoke. I pulled a 74HCT04 from a known-good isa > card, socketed the spot and viola! Working 8mb board. It isn't > ALLWAYS the most expensive chip, thank God, and sometimes even us not- > as-bright guys come off with a win. > About 20 years earlier than that, one of my friends at school asked me to fix his Jupiter Ace which had stopped working. I told him I didn't hold out much hope for success because I didn't have the vaguest idea how his little machine worked at that time but I agreed to wave my multimeter in the general direction of it's power supply. I opened it up and quickly found that the voltages seemed very reasonable and I prodded around the board rather aimlessly looking for some part that looked guilty. I soon noticed that one of the eight identical chips in a row at the bottom of the board was getting hot enough to burn my finger while the others remained cool and calm. I can't remember where I got a replacement 4116 or 4164 or whatever it was - I probably had to get it mail order but once it was soldered in with fingers crossed that nothing else was wrong, the machine came right back to life. Sometimes you just get lucky. I wish I could be that lucky with some of my own stuff now. Regards, Peter Coghlan. From cctalk at beyondthepale.ie Fri Feb 15 18:00:44 2019 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Sat, 16 Feb 2019 00:00:44 +0000 (WET) Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: Message-ID: <01R39I59B7C68WXLWI@beyondthepale.ie> Liam Proven wrote: > > And some of my younger colleagues thought it was strange that I could > predict hard disk failures from the running noises they made, and > later than that, whether WinNT's bus-mastering DMA-mode disk > controller device driver was installed from the sound of the disk > accesses while the machine booted. > The little 8GB SCA system disk in my Alphaserver 800 started making awful bloodcurdling clattering noises a few years ago. The first time I heard it, I was convinced that the works were splattered all over the inside of the HDA casing and the machine was only continuing to run because of what was left in the disk cache or something like that. I started running a backup in case I might be able to salvage some part of the contents. Despite several more heartstopping clunks and clatters while the backup was running, it ran to completion, with no errors logged to my complete surprise. I ran an ANALYZE /DISK /READ which attempts to read all blocks on the disk that are allocated to files. Again, several more awful clanks and clatters but it completed with no errors. I lined up a replacement disk for it but I was curious to see how exactly it was going to fail so I decided to keep on using it for a while to see what happens. Days turned into weeks, weeks into months and months into years. It continued to occasionally make the same ghastly noises that never should be heard coming from a hard disk but with absolutely no sign of any errors being logged or damage to data whatsoever. The noises seem to be associated with seek activity because I have never heard them when the disk is just spinning but otherwise idle. I eventually retired it and replaced it with a much larger one, purely because I ran out of space on it. Any thoughts on what might be happening with it? Regards, Peter Coghlan. From phb.hfx at gmail.com Fri Feb 15 20:01:50 2019 From: phb.hfx at gmail.com (Paul Berger) Date: Fri, 15 Feb 2019 22:01:50 -0400 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215050722.GB26741@RawFedDogs.net> <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> <20190215150317.GA4463@RawFedDogs.net> <46e29293-c483-27f1-0131-e215627998bb@spamtrap.tnetconsulting.net> <0c604f68-6e81-b907-35e9-bc81d72a2d3f@gmail.com> Message-ID: <3905ecc5-04a1-8803-7f56-96b8a130907f@gmail.com> On 2019-02-15 4:04 p.m., Liam Proven via cctalk wrote: > On Fri, 15 Feb 2019 at 19:27, Paul Berger via cctalk > wrote: > >> Knowledge Center refers to it as IBM i, but it is not the name of a >> system it is just the name of another OS that runs on IBM Power systems >> and can even be vitalized on a system with other OSes. > IBM moved the AS/400 onto POWER processors. The TIMI (sp?) firmware > made this doable and binaries were portable from the old hardware. The > OS was renamed i5/OS. > > Later they replaced the proprietary POWER hardware with generic POWER > servers, and they renamed the OS to IBM i. > > IBM supports 3 OSes on POWER servers now: AIX, Linux and IBM i. > > Silly name, though. Only the very first RISC based AS/400s where really different hardware, by the turn of the century when the second generation of RS64 / Power3 systems where coming along there was already a lot of common hardware between AS/400or iSeries and RS/6000 or pSeries? only by Power5 time the hardware was all the same except iSeries was still clinging to the IOP but even that went away with Power 6 and even the support for Twinax WSC is gone now? since the last ones where PCI. Paul. From kevin.bowling at kev009.com Fri Feb 15 23:03:24 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 15 Feb 2019 22:03:24 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <3905ecc5-04a1-8803-7f56-96b8a130907f@gmail.com> References: <20190215050722.GB26741@RawFedDogs.net> <4kqplit9kug1o6bgvstjtlrk.1550208519452@email.android.com> <20190215150317.GA4463@RawFedDogs.net> <46e29293-c483-27f1-0131-e215627998bb@spamtrap.tnetconsulting.net> <0c604f68-6e81-b907-35e9-bc81d72a2d3f@gmail.com> <3905ecc5-04a1-8803-7f56-96b8a130907f@gmail.com> Message-ID: There was quite a bit of difference up until POWER6 although each generation came closer and closer together. It wasn?t just the IOPs, the systems had different management controllers, cases, expansion enclosures, etc as late as POWER5 and only ran AIX in LPARs or PASE. The early PowerPC 400s were PowerPC-AS chips designed in Rochester, MN whereas most other POWER and PowerPC work was an Austin, TX creation. Rochester did the RS64 family of processors which were very nice low power chips that also introduced ?hyperthreading? and other advanced technologies but these were offered in RS/6000s as well for commercial workloads (DB, web services). https://en.wikipedia.org/wiki/IBM_RS64 On Fri, Feb 15, 2019 at 7:02 PM Paul Berger via cctalk < cctalk at classiccmp.org> wrote: > > On 2019-02-15 4:04 p.m., Liam Proven via cctalk wrote: > > On Fri, 15 Feb 2019 at 19:27, Paul Berger via cctalk > > wrote: > > > >> Knowledge Center refers to it as IBM i, but it is not the name of a > >> system it is just the name of another OS that runs on IBM Power systems > >> and can even be vitalized on a system with other OSes. > > IBM moved the AS/400 onto POWER processors. The TIMI (sp?) firmware > > made this doable and binaries were portable from the old hardware. The > > OS was renamed i5/OS. > > > > Later they replaced the proprietary POWER hardware with generic POWER > > servers, and they renamed the OS to IBM i. > > > > IBM supports 3 OSes on POWER servers now: AIX, Linux and IBM i. > > > > Silly name, though. > > Only the very first RISC based AS/400s where really different hardware, > by the turn of the century when the second generation of RS64 / Power3 > systems where coming along there was already a lot of common hardware > between AS/400or iSeries and RS/6000 or pSeries only by Power5 time the > hardware was all the same except iSeries was still clinging to the IOP > but even that went away with Power 6 and even the support for Twinax WSC > is gone now since the last ones where PCI. > > Paul. > > > From andrewsofbg at gmail.com Sat Feb 16 02:13:38 2019 From: andrewsofbg at gmail.com (craig andrews) Date: Sat, 16 Feb 2019 00:13:38 -0800 Subject: Zenith Z-90 startup Message-ID: <89C7BE89-983B-4FBA-A76A-4E49918311B4@gmail.com> Hello, I am reading through message archives and came across your post. Did you get your h90 sorted out? Craig From andrewsofbg at gmail.com Sat Feb 16 02:20:38 2019 From: andrewsofbg at gmail.com (craig andrews) Date: Sat, 16 Feb 2019 00:20:38 -0800 Subject: Intel Universal Prom Programmer UPP 103 documentation Message-ID: <3383CB88-EF93-4D57-B1D5-E5742B5CC838@gmail.com> Hello, I need to do some work on my intel UPP-833 personality card in my UPP and am looking for documentation This document: 9800133F_Universal_PROM_Programmer_Reference_Manual_1977 has schematics for personality cards available in ?77 but does not include the UPP-833 I am having trouble with my UPP-833 and could use some documentation. Documentation on the UPP-832 would probably be helpful if nothing on the 833 There may be a newer version of 102448-001 I do not know about. There are two Documents that should have the information are: 102448-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966 123832-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966 Can anyone help? Regards Craig From ljw-cctech at ljw.me.uk Sat Feb 16 02:34:30 2019 From: ljw-cctech at ljw.me.uk (Lawrence Wilkinson) Date: Sat, 16 Feb 2019 09:34:30 +0100 Subject: Fwd: Latest Batch of Items from Sellam's VWoCW In-Reply-To: References: Message-ID: Sorry, moderation fail. Forwarding to cctalk: -------- Forwarded Message -------- Subject: Latest Batch of Items from Sellam's VWoCW Date: Fri, 15 Feb 2019 20:27:12 -0800 From: Sellam Ismail via cctech Reply-To: Sellam Ismail , General Discussion: On-Topic Posts To: General Discussion: On-Topic and Off-Topic Posts Hello Folks! I've put together another batch of items as I continue to wade through my warehouse and winnow out the wonders: HP 2116C System Manual #1 HP 2116C System Manual #2 HP 2116C System Manual #3 HP 2116C Power Cord Using the HP 3000: An Introduction to Interactive Programming Tandy WP-2 Portable Word Processor M7859 KY11-LB Console Interface Kraft 3-button PC Mouse Mouse Systems 3-button PC Mouse Zenith Z-Box External ISA Expansion Chassis Novell IBM NIC ShareNet Board Epson External 5.25" Floppy Drive SuperMac Technology DataFrame DF20 20MB external hard disk ClubMac C104 External SCSI CD-ROM Drive Midiman Mini MacMan Macintosh MIDI Interface Passport MIDI Interface for Macintosh Neutronics Hexadigit S-100 Bus Monitor Gimix Ghost 32K RAM Compaq SLT/286 portable VTech The Equalizer Laptop IBM Model M Keyboard IBM Model M Keyboard IBM Model M Keyboard IBM Model M Keyboard The main index for these and other fine items is here: https://docs.google.com/spreadsheets/d/1I53wxarLHlNmlPVf_HJ5oMKuab4zrApI_hiX0pNmy48/edit?pli=1#gid=949372371&range=A1 I've put some work into the index and improved it so that links keep properly updated as new items are added or sold items are removed (whereas before the index links in the New Arrivals Niche would get hopelessly out of sync). However, I believe there might have been some problems with the links before so if you saw an item you liked and the link did not lead to it and you assumed it was sold, please check again. From this point going forward, all links (above the notice in the sheet) should stay in sync. I've been preoccupied for the last few months with personal business and haven't been able to put a lot of time into curating the collection for sales but I am trying to catch up. There are a couple people that are waiting on me and I haven't forgotten about you. I will get caught up shortly and I thank you for your patience. As always, please contact me directly by e-mail via to make an order or an offer. Thanks! Sellam From bill.gunshannon at hotmail.com Sat Feb 16 07:55:10 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sat, 16 Feb 2019 13:55:10 +0000 Subject: PDP-11 disk image question Message-ID: So, I used SIMH to do an install of a complete OS on an RA81 disk. I would like to move this to a real disk and try it on a real PDP-11. Is there a way to do this using dd on a BSD machine? I tried but it created a non bootable system. Well, actually, it starts to boot but then fails very early in the startup process. I used "dd if=filename of=raw-device bs=1024". Could it be that the block size needs to be something else? I know that VTServer and PDPGUI can move disk images but it would take a week at 9600 baud and I think very little likelihood of it ever completing successfully. bill From dkelvey at hotmail.com Sat Feb 16 08:58:02 2019 From: dkelvey at hotmail.com (dwight) Date: Sat, 16 Feb 2019 14:58:02 +0000 Subject: Intel Universal Prom Programmer UPP 103 documentation In-Reply-To: <3383CB88-EF93-4D57-B1D5-E5742B5CC838@gmail.com> References: <3383CB88-EF93-4D57-B1D5-E5742B5CC838@gmail.com> Message-ID: Not sure how much this will help but the EPROM programmer boards were an evolutionary thing. The UPP-816 would be quite similar to the UPP-833, except for extra stuff for voltage control and added addresses. What is the issue you are having with the board? Dwight ________________________________ From: cctalk on behalf of craig andrews via cctalk Sent: Saturday, February 16, 2019 12:20 AM To: cctech at classiccmp.org Subject: Intel Universal Prom Programmer UPP 103 documentation Hello, I need to do some work on my intel UPP-833 personality card in my UPP and am looking for documentation This document: 9800133F_Universal_PROM_Programmer_Reference_Manual_1977 has schematics for personality cards available in ?77 but does not include the UPP-833 I am having trouble with my UPP-833 and could use some documentation. Documentation on the UPP-832 would probably be helpful if nothing on the 833 There may be a newer version of 102448-001 I do not know about. There are two Documents that should have the information are: 102448-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966 123832-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966 Can anyone help? Regards Craig From lbickley at bickleywest.com Sat Feb 16 11:10:23 2019 From: lbickley at bickleywest.com (Lyle Bickley) Date: Sat, 16 Feb 2019 09:10:23 -0800 Subject: PDP-11 disk image question In-Reply-To: References: Message-ID: <20190216091023.4c7c0894@asrock> Bill, On Sat, 16 Feb 2019 13:55:10 +0000 Bill Gunshannon via cctalk wrote: > So, I used SIMH to do an install of a complete OS on > an RA81 disk. I would like to move this to a real disk > and try it on a real PDP-11. Is there a way to do this > using dd on a BSD machine? I tried but it created a > non bootable system. Well, actually, it starts to boot > but then fails very early in the startup process. I used > "dd if=filename of=raw-device bs=1024". Could it be that > the block size needs to be something else? > > I know that VTServer and PDPGUI can move disk images but > it would take a week at 9600 baud and I think very little > likelihood of it ever completing successfully. > > bill In order to do this easily, I have SCSI controllers (and disks) on my two primary PDP-11 systems (11/34 and 11/83). 1. I copy the image file I want on a "native" drive using a PC w/SCSI and Linux to a SCSI disk (or removable media) using "dd". 2. I move that drive/media to the SCSI "chain" on a PDP-11. 3. I use RT-11 to move the image from the SCSI drive/media to the "native" HDD. Its a bit cumbersome, but I used this method for years and it hasn't failed me yet ;) Cheers, Lyle -- 73 NM6Y Bickley Consulting West Inc. http://bickleywest.com "Black holes are where God is dividing by zero" From andrewsofbg at gmail.com Sat Feb 16 10:31:07 2019 From: andrewsofbg at gmail.com (craig andrews) Date: Sat, 16 Feb 2019 08:31:07 -0800 Subject: Intel Universal Prom Programmer UPP 103 documentation In-Reply-To: References: <3383CB88-EF93-4D57-B1D5-E5742B5CC838@gmail.com> Message-ID: Dwight Thanks for the suggestion. The problem just showed up late last night so I haven?t really started diagnostics yet. Fortunately, it reads OK but is just failing to program so the problem is very limited in scope and probably going to be fairly easy to track down. This problem aside, it would be nice to have the documentation for when it really gives up the ghost. Craig > On Feb 16, 2019, at 6:58 AM, dwight wrote: > > Not sure how much this will help but the EPROM programmer boards were an evolutionary thing. The UPP-816 would be quite similar to the UPP-833, except for extra stuff for voltage control and added addresses. What is the issue you are having with the board? > Dwight > > From: cctalk on behalf of craig andrews via cctalk > Sent: Saturday, February 16, 2019 12:20 AM > To: cctech at classiccmp.org > Subject: Intel Universal Prom Programmer UPP 103 documentation > > Hello, I need to do some work on my intel UPP-833 personality card in my UPP and am looking for documentation > > This document: > > 9800133F_Universal_PROM_Programmer_Reference_Manual_1977 > > has schematics for personality cards available in ?77 but does not include the UPP-833 > I am having trouble with my UPP-833 and could use some documentation. Documentation on the UPP-832 would probably be helpful if nothing on the 833 > > There may be a newer version of 102448-001 I do not know about. There are two Documents that should have the information are: > > 102448-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966 > > 123832-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966 > > Can anyone help? > > Regards > > Craig > From healyzh at avanthar.com Sat Feb 16 11:35:18 2019 From: healyzh at avanthar.com (Zane Healy) Date: Sat, 16 Feb 2019 09:35:18 -0800 Subject: PDP-11 disk image question In-Reply-To: <20190216091023.4c7c0894@asrock> References: <20190216091023.4c7c0894@asrock> Message-ID: > On Feb 16, 2019, at 9:10 AM, Lyle Bickley via cctalk wrote: > > Bill, > > On Sat, 16 Feb 2019 13:55:10 +0000 > Bill Gunshannon via cctalk wrote: > >> So, I used SIMH to do an install of a complete OS on >> an RA81 disk. I would like to move this to a real disk >> and try it on a real PDP-11. Is there a way to do this >> using dd on a BSD machine? I tried but it created a >> non bootable system. Well, actually, it starts to boot >> but then fails very early in the startup process. I used >> "dd if=filename of=raw-device bs=1024". Could it be that >> the block size needs to be something else? >> >> I know that VTServer and PDPGUI can move disk images but >> it would take a week at 9600 baud and I think very little >> likelihood of it ever completing successfully. >> >> bill > > In order to do this easily, I have SCSI controllers (and disks) on my > two primary PDP-11 systems (11/34 and 11/83). > > 1. I copy the image file I want on a "native" drive using a PC w/SCSI > and Linux to a SCSI disk (or removable media) using "dd". > > 2. I move that drive/media to the SCSI "chain" on a PDP-11. > > 3. I use RT-11 to move the image from the SCSI drive/media to the > "native" HDD. > > Its a bit cumbersome, but I used this method for years and it hasn't > failed me yet ;) Like Lyle I have SCSI controllers on my PDP-11/73, and my PDP-11/44. I?ve actually installed RT-11 and RSX-11M+ from CD-R. There is another option, and I?ve used this with RL01?s and RL02?s. With those, I?ve used a MicroVAX II or MicroVAX 3 and VAX/VMS. I used to have a dedicated MicroVAX 3 setup with RA73 drives for this. I still have the hardware, but it hasn?t been used since 2000. If you have a way to hook the RA81 up to a VAX, I think that would be an option as well. Zane From jsw at ieee.org Sat Feb 16 11:58:26 2019 From: jsw at ieee.org (Jerry Weiss) Date: Sat, 16 Feb 2019 11:58:26 -0600 Subject: PDP-11 disk image question In-Reply-To: References: Message-ID: <889aea1b-f428-2cfd-69ca-b95492b33bcc@ieee.org> On 2/16/19 7:55 AM, Bill Gunshannon via cctalk wrote: > So, I used SIMH to do an install of a complete OS on > an RA81 disk. I would like to move this to a real disk > and try it on a real PDP-11. Is there a way to do this > using dd on a BSD machine? I tried but it created a > non bootable system. Well, actually, it starts to boot > but then fails very early in the startup process. I used > "dd if=filename of=raw-device bs=1024". Could it be that > the block size needs to be something else? > > I know that VTServer and PDPGUI can move disk images but > it would take a week at 9600 baud and I think very little > likelihood of it ever completing successfully. > > bill As long as the media is presented as "Error Free", you should be able to to change the block size.?? Since a RA81 (MSCP) remaps error blocks automatically and invisibly, it should work.? Is the media type the same on SIMH and Real PDP11? ? If all else fails try bs=512. For drives that have OS visible media defects, you should make sure the block size matches the same on the media and also use the option "conv=noerror,sync".? Otherwise dd will actually reorders the blocks(!), good first then zero fill the ones it cannot read. ? ? Jerry From bill.gunshannon at hotmail.com Sat Feb 16 12:04:05 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sat, 16 Feb 2019 18:04:05 +0000 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> Message-ID: On 2/16/19 12:35 PM, Zane Healy via cctalk wrote: > >> On Feb 16, 2019, at 9:10 AM, Lyle Bickley via cctalk wrote: >> >> Bill, >> >> On Sat, 16 Feb 2019 13:55:10 +0000 >> Bill Gunshannon via cctalk wrote: >> >>> So, I used SIMH to do an install of a complete OS on >>> an RA81 disk. I would like to move this to a real disk >>> and try it on a real PDP-11. Is there a way to do this >>> using dd on a BSD machine? I tried but it created a >>> non bootable system. Well, actually, it starts to boot >>> but then fails very early in the startup process. I used >>> "dd if=filename of=raw-device bs=1024". Could it be that >>> the block size needs to be something else? >>> >>> I know that VTServer and PDPGUI can move disk images but >>> it would take a week at 9600 baud and I think very little >>> likelihood of it ever completing successfully. >>> >>> bill >> >> In order to do this easily, I have SCSI controllers (and disks) on my >> two primary PDP-11 systems (11/34 and 11/83). >> >> 1. I copy the image file I want on a "native" drive using a PC w/SCSI >> and Linux to a SCSI disk (or removable media) using "dd". >> >> 2. I move that drive/media to the SCSI "chain" on a PDP-11. >> >> 3. I use RT-11 to move the image from the SCSI drive/media to the >> "native" HDD. >> >> Its a bit cumbersome, but I used this method for years and it hasn't >> failed me yet ;) > > Like Lyle I have SCSI controllers on my PDP-11/73, and my PDP-11/44. I?ve actually installed RT-11 and RSX-11M+ from CD-R. There is another option, and I?ve used this with RL01?s and RL02?s. With those, I?ve used a MicroVAX II or MicroVAX 3 and VAX/VMS. I used to have a dedicated MicroVAX 3 setup with RA73 drives for this. I still have the hardware, but it hasn?t been used since 2000. If you have a way to hook the RA81 up to a VAX, I think that would be an option as well. > OK, as usual, I hac caused confusion and didn't get my point across. let's try with a detailed explanation of what I did that didn't seem to work. First, my hardware. I have a PDP-11/93 with a CMD SCSI Module and a BA350 with 6 2GB hard drives. The Module is set up to present RA81 disks and the first 3 disks have 4 partitions each which should work out to 12 RA81 disks. (But that last part is unimportant right now!) I used SIMH to build RSTS V9.6 on a simulated RA81 disk. I wrote the disk as a file to a CDR in CD9660 format. I moved the BA350 and the CD to a VS3100 running OpenBSD. I was able to mount the CD under OpenBSD and see the file containing the disk image. I used dd with the command given in my original message (and repeated above) to try to write the image to a real SCSI disk. When I try to boot it I get the RSTS Message "INIT.SYS not found". The disk was completely blank to start so the RSTS info must have been copied but apparently not copied correctly. Any more suggestions? bill From anders.k.nelson at gmail.com Sat Feb 16 12:51:51 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sat, 16 Feb 2019 13:51:51 -0500 Subject: Kemners Surplus - Real time walkthrough Message-ID: Hi everyone, I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay them a visit. I'm taking pictures of as much vintage computing gear as I can as we speak. I'll be here until they close today at 5pm EST, so if you see something you like feel free to give them a call and I'll help them navigate. Photos updated as I walk through, here: https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 If you see something you like it'd be great if you could check if I'm interested first until I'm finished today. ;] Hope this helps someone, they shut down soon! From charles.unix.pro at gmail.com Sat Feb 16 12:53:16 2019 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sat, 16 Feb 2019 10:53:16 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> Message-ID: On Sat, Feb 16, 2019 at 10:04 AM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: > > > I used SIMH to build RSTS V9.6 on a simulated RA81 disk. I wrote the > disk as a file to a CDR in CD9660 format. I moved the BA350 and the > CD to a VS3100 running OpenBSD. I was able to mount the CD under > OpenBSD and see the file containing the disk image. I used dd with > the command given in my original message (and repeated above) to try > to write the image to a real SCSI disk. When I try to boot it I get > the RSTS Message "INIT.SYS not found". The disk was completely blank > to start so the RSTS info must have been copied but apparently not > copied correctly. > > Any more suggestions? > My wild speculation would be disk geometry. I don't know the specific geometry of the RA81 disk, but it is possible that SIMH is writing a sparse disk image. As an arbitrary example, suppose that there were seven sectors per track, and the RA81 accepts a 3 bit sector number. If SIMH is treating the sector number as a 0-7, then the blocks would be written to the image file as: (track/sector) 0/0 0/1 0/2 0/3 0/4 0/5 0/6 unused 1/0 1/1 ..... When the image file is copied to the drive, the "unused" block is written to 1/0 on the drive, and 1/0 is written to 1/1. etc. This could match the observed behavior; the data in the first track is call correct, allowing RSTS to start, but the directory blocks containing INIT.SYS are on the wrong locations, causing the 'can't find' failure. I don't know if SIMH is doing this; one test would be to run something on the SIMH RSTS that filled the disk with data (ensuring that the last sectors are written to, and compare the size of the image file with the size of the actual disk; if the image file is bigger, then it is probably sparsely written. -- Charles From anders.k.nelson at gmail.com Sat Feb 16 12:58:07 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sat, 16 Feb 2019 13:58:07 -0500 Subject: 8-Update In-Reply-To: <042c01d496b9$b103cf00$130b6d00$@gmail.com> References: <5B449A770E1A3823@rgout06.bt.lon5.cpcloud.co.uk> <16411FE1-8520-4841-8A7E-E958BAF611D1@avanthar.com> <5c18c105.1c69fb81.5b7fa.3e0cSMTPIN_ADDED_BROKEN@mx.google.com> <042c01d496b9$b103cf00$130b6d00$@gmail.com> Message-ID: Oh boy, how did I miss that someone has created a front panel PCB layout for a PDP-8/e? Can you ask Vince to share that design please? On Tue, Dec 18, 2018, 6:08 PM Paul Birkel via cctalk >I have an .slt for the PDP-8/e lever > >Rod > > Please publish/share? > > paul > > From wdonzelli at gmail.com Sat Feb 16 13:11:24 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Sat, 16 Feb 2019 14:11:24 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: Probably the biggest question everyone has is if the prices are reasonable for a place about to go under. -- Will On Sat, Feb 16, 2019 at 1:52 PM Anders Nelson via cctalk wrote: > > Hi everyone, > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay > them a visit. I'm taking pictures of as much vintage computing gear as I > can as we speak. I'll be here until they close today at 5pm EST, so if you > see something you like feel free to give them a call and I'll help them > navigate. > > Photos updated as I walk through, here: > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > If you see something you like it'd be great if you could check if I'm > interested first until I'm finished today. ;] > > Hope this helps someone, they shut down soon! From cctalk at gtaylor.tnetconsulting.net Sat Feb 16 13:15:31 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 16 Feb 2019 12:15:31 -0700 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: <36c7bd47-f23e-b2db-8974-bd19481ceb54@spamtrap.tnetconsulting.net> I cross posted this / what you're doing to Usenet (PS/2 people) and tweeted about it. On 2/16/19 11:51 AM, Anders Nelson via cctalk wrote: > Hi everyone, > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay > them a visit. I'm taking pictures of as much vintage computing gear as I > can as we speak. I'll be here until they close today at 5pm EST, so if you > see something you like feel free to give them a call and I'll help them > navigate. > > Photos updated as I walk through, here: > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > If you see something you like it'd be great if you could check if I'm > interested first until I'm finished today. ;] > > Hope this helps someone, they shut down soon! -- Grant. . . . unix || die From anders.k.nelson at gmail.com Sat Feb 16 13:16:13 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sat, 16 Feb 2019 14:16:13 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: The last there was proactive about saying prices are negotiable, and you could expect "up to 50%" off. I'm not about to pay up to $1K for one of those corroded disk packs, so... On Sat, Feb 16, 2019, 2:11 PM William Donzelli Probably the biggest question everyone has is if the prices are > reasonable for a place about to go under. > > -- > Will > > On Sat, Feb 16, 2019 at 1:52 PM Anders Nelson via cctalk > wrote: > > > > Hi everyone, > > > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to > pay > > them a visit. I'm taking pictures of as much vintage computing gear as I > > can as we speak. I'll be here until they close today at 5pm EST, so if > you > > see something you like feel free to give them a call and I'll help them > > navigate. > > > > Photos updated as I walk through, here: > > > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > > > If you see something you like it'd be great if you could check if I'm > > interested first until I'm finished today. ;] > > > > Hope this helps someone, they shut down soon! > From cctalk at gtaylor.tnetconsulting.net Sat Feb 16 13:29:53 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 16 Feb 2019 12:29:53 -0700 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: <0622ebf9-d2d2-bdb1-b826-94de1c70ec42@spamtrap.tnetconsulting.net> On 2/16/19 12:16 PM, Anders Nelson via cctalk wrote: > The last there was proactive about saying prices are negotiable, and you > could expect "up to 50%" off. Hum. I feel like that's not sufficient to peak my interest in some of the things. I'm particularly interested in the IBM PS/2 stuff, but there's not enough information / details to speculate on short notice from afar with unknown prices and shipping. :-/ I do think that's the biggest collection of Model 80s that I've seen in one place in quite a while. I'd be really curious what cards are in them. Thank you for the pictures and the heads up Anders. > I'm not about to pay up to $1K for one of those corroded disk packs, so... Ya. Some of the equipment looked fairly rough. I suspect a good cleaning will help. But it's difficult to tell what condition and if it's just surface dirt or if the problems run deeper. -- Grant. . . . unix || die From sales at elecplus.com Sat Feb 16 14:33:28 2019 From: sales at elecplus.com (Electronics Plus) Date: Sat, 16 Feb 2019 14:33:28 -0600 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: <045601d4c636$e03c5150$a0b4f3f0$@com> Really high prices! If he is going under, it will cost him up to $20 each to have those CRTs recycled. The printers and scanners will be 2-6 cents per pound as scrap. Maybe he will make some last minute good deals. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Anders Nelson via cctalk Sent: Saturday, February 16, 2019 12:52 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Kemners Surplus - Real time walkthrough Hi everyone, I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay them a visit. I'm taking pictures of as much vintage computing gear as I can as we speak. I'll be here until they close today at 5pm EST, so if you see something you like feel free to give them a call and I'll help them navigate. Photos updated as I walk through, here: https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 If you see something you like it'd be great if you could check if I'm interested first until I'm finished today. ;] Hope this helps someone, they shut down soon! --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From anders.k.nelson at gmail.com Sat Feb 16 14:53:48 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sat, 16 Feb 2019 15:53:48 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: <0622ebf9-d2d2-bdb1-b826-94de1c70ec42@spamtrap.tnetconsulting.net> References: <0622ebf9-d2d2-bdb1-b826-94de1c70ec42@spamtrap.tnetconsulting.net> Message-ID: They have probably 25 boxes of 10, 8" DSDD floppies each that are still in their sealed packaging if that's of interest! On Sat, Feb 16, 2019, 2:29 PM Grant Taylor via cctalk On 2/16/19 12:16 PM, Anders Nelson via cctalk wrote: > > The last there was proactive about saying prices are negotiable, and you > > could expect "up to 50%" off. > > Hum. > > I feel like that's not sufficient to peak my interest in some of the > things. > > I'm particularly interested in the IBM PS/2 stuff, but there's not > enough information / details to speculate on short notice from afar with > unknown prices and shipping. :-/ > > I do think that's the biggest collection of Model 80s that I've seen in > one place in quite a while. > > I'd be really curious what cards are in them. > > Thank you for the pictures and the heads up Anders. > > > I'm not about to pay up to $1K for one of those corroded disk packs, > so... > > Ya. Some of the equipment looked fairly rough. I suspect a good > cleaning will help. But it's difficult to tell what condition and if > it's just surface dirt or if the problems run deeper. > > > > -- > Grant. . . . > unix || die > From healyzh at avanthar.com Sat Feb 16 14:57:35 2019 From: healyzh at avanthar.com (Zane Healy) Date: Sat, 16 Feb 2019 12:57:35 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> Message-ID: <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> > On Feb 16, 2019, at 10:04 AM, Bill Gunshannon via cctalk wrote: > > OK, as usual, I hac caused confusion and didn't get my point across. > > let's try with a detailed explanation of what I did that didn't seem > to work. > > First, my hardware. I have a PDP-11/93 with a CMD SCSI Module and > a BA350 with 6 2GB hard drives. The Module is set up to present RA81 > disks and the first 3 disks have 4 partitions each which should work > out to 12 RA81 disks. (But that last part is unimportant right now!) > > I used SIMH to build RSTS V9.6 on a simulated RA81 disk. I wrote the > disk as a file to a CDR in CD9660 format. I moved the BA350 and the > CD to a VS3100 running OpenBSD. I was able to mount the CD under > OpenBSD and see the file containing the disk image. I used dd with > the command given in my original message (and repeated above) to try > to write the image to a real SCSI disk. When I try to boot it I get > the RSTS Message "INIT.SYS not found". The disk was completely blank > to start so the RSTS info must have been copied but apparently not > copied correctly. > > Any more suggestions? That?s a really nice setup. I?ve had a theory for a while now, but never had cause to actually put it to the test. RSTS/E would probably be why I would put it to the test. First some background. I?m far being skilled from RSTS/E, but I have managed to get RSTS/E 10.1 and DECnet/E installed and running on my PDP-11/73, on a SCSI drive. While I?ve been able to install RT-11 and RSX-11M+ from CD-R, I wasn?t able to figure out how to do that with RSTS/E. With RT-11 or RSX I boot from the CD-R, and do the install. The next option I have is a TLZ06 drive, and I write the tapes with my Compaq XP1000/667 running OpenVMS. As I recall, that worked fine for installing RSTS/E, but it wouldn?t work for DECnet/E, for DECnet/E I had to actually install from a TK50 tape. Now for the theory? What if you do a ?dd? of the drive you want to install it to. Then copy that image over to where you?re running SIMH, and use a copy as your disk image for SIMH. Install RSTS/E, and write it back to the simulated RA81 using dd. I do not know if this will work, but it?s something I?ve wanted to try for a long time. Another possibility is that you could be running into some sort of problem with the RA81 simulation with the controller. Do you have the manual for the Controller? If so what OS?s and versions does it say it supports? Out of curiosity, which SCSI board are you using? I didn?t realize this was a feature that the CMD controllers have. Will it simulate any other drives? Zane From cctalk at gtaylor.tnetconsulting.net Sat Feb 16 15:05:28 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 16 Feb 2019 14:05:28 -0700 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: <0622ebf9-d2d2-bdb1-b826-94de1c70ec42@spamtrap.tnetconsulting.net> Message-ID: <34d72681-9555-3b1f-1440-e044bac20020@spamtrap.tnetconsulting.net> On 2/16/19 1:53 PM, Anders Nelson wrote: > They have probably 25 boxes of 10, 8" DSDD floppies each that are still > in their sealed packaging if that's of interest! I'm personally not interested. But I've seen a lot of chatter recently about disks that IBM used in older equipment like the 3174 terminal controller (recently discussed). I have no idea if they are the same disks or not. If they are, I suspect there are some interested parties on this (and other) list. -- Grant. . . . unix || die From anders.k.nelson at gmail.com Sat Feb 16 15:19:41 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sat, 16 Feb 2019 16:19:41 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: More photos posted to the album with some NIB DEC boards, look like a motherboard and CRT board, two of each. On Sat, Feb 16, 2019, 1:51 PM Anders Nelson Hi everyone, > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to > pay them a visit. I'm taking pictures of as much vintage computing gear as > I can as we speak. I'll be here until they close today at 5pm EST, so if > you see something you like feel free to give them a call and I'll help them > navigate. > > Photos updated as I walk through, here: > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > If you see something you like it'd be great if you could check if I'm > interested first until I'm finished today. ;] > > Hope this helps someone, they shut down soon! > From bill.gunshannon at hotmail.com Sat Feb 16 15:20:13 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Sat, 16 Feb 2019 21:20:13 +0000 Subject: PDP-11 disk image question In-Reply-To: <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> Message-ID: On 2/16/19 3:57 PM, Zane Healy wrote: > >> On Feb 16, 2019, at 10:04 AM, Bill Gunshannon via cctalk wrote: >> >> OK, as usual, I hac caused confusion and didn't get my point across. >> >> let's try with a detailed explanation of what I did that didn't seem >> to work. >> >> First, my hardware. I have a PDP-11/93 with a CMD SCSI Module and >> a BA350 with 6 2GB hard drives. The Module is set up to present RA81 >> disks and the first 3 disks have 4 partitions each which should work >> out to 12 RA81 disks. (But that last part is unimportant right now!) >> >> I used SIMH to build RSTS V9.6 on a simulated RA81 disk. I wrote the >> disk as a file to a CDR in CD9660 format. I moved the BA350 and the >> CD to a VS3100 running OpenBSD. I was able to mount the CD under >> OpenBSD and see the file containing the disk image. I used dd with >> the command given in my original message (and repeated above) to try >> to write the image to a real SCSI disk. When I try to boot it I get >> the RSTS Message "INIT.SYS not found". The disk was completely blank >> to start so the RSTS info must have been copied but apparently not >> copied correctly. >> >> Any more suggestions? > > That?s a really nice setup. > > I?ve had a theory for a while now, but never had cause to actually put it to the test. RSTS/E would probably be why I would put it to the test. > > First some background. I?m far being skilled from RSTS/E, but I have managed to get RSTS/E 10.1 and DECnet/E installed and running on my PDP-11/73, on a SCSI drive. While I?ve been able to install RT-11 and RSX-11M+ from CD-R, I wasn?t able to figure out how to do that with RSTS/E. With RT-11 or RSX I boot from the CD-R, and do the install. The next option I have is a TLZ06 drive, and I write the tapes with my Compaq XP1000/667 running OpenVMS. As I recall, that worked fine for installing RSTS/E, but it wouldn?t work for DECnet/E, for DECnet/E I had to actually install from a TK50 tape. > I guess I don't understand where you are getting bootable CDROM install media for any PDP-11 OS. I am not aware of any PDP-11 that supported CDROM as a boot device either. > Now for the theory? What if you do a ?dd? of the drive you want to install it to. Then copy that image over to where you?re running SIMH, and use a copy as your disk image for SIMH. Install RSTS/E, and write it back to the simulated RA81 using dd. I do not know if this will work, but it?s something I?ve wanted to try for a long time. Might be interesting to try. > > Another possibility is that you could be running into some sort of problem with the RA81 simulation with the controller. Do you have the manual for the Controller? If so what OS?s and versions does it say it supports? Out of curiosity, which SCSI board are you using? I didn?t realize this was a feature that the CMD controllers have. Will it simulate any other drives? I have the manual. I only chose RA81 as it was the biggest size disk supported by all the PDP-11 OSes. I would love to use bigger but you have to pick one in the configuration of the controller. You can choose to not emulate anything but I expect most PDP-11 OSes would have a problem installing to a very large, unspecified type, disk. I have a CQD=220A/MT configured for 6 disks and one tape. As for disk types, you can toggle RA ON or OFF on each drive. You can specify one RA type that will be in effect for any disk with RA ON. Types are: RA70, RA80, RA81, RA82, RA90 and RA92. OSes supported are VMS, Ultrix, Unix/Berkeley, RSX-11M, RSX-11M-Plus, RSTS/E, RT-11, DSM-11, ISM-11, TSX+, VAXELN and AT&T UNIX. Most recent versions of all of them. Or so it claims. The only OS I have ever had running on one of these cards was RT-11. I am just now getting around to trying to play with other OSes to see if they actually work. But, getting the OS onto the machine is a challenge all in itself, bill From wdonzelli at gmail.com Sat Feb 16 15:23:58 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Sat, 16 Feb 2019 16:23:58 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: Also, can you find out when they plan to close their doors and/or call the scrapper? A timetable? Thank you for your effort so far. -- Will On Sat, Feb 16, 2019 at 4:20 PM Anders Nelson via cctalk wrote: > > More photos posted to the album with some NIB DEC boards, look like a > motherboard and CRT board, two of each. > > On Sat, Feb 16, 2019, 1:51 PM Anders Nelson wrote: > > > Hi everyone, > > > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to > > pay them a visit. I'm taking pictures of as much vintage computing gear as > > I can as we speak. I'll be here until they close today at 5pm EST, so if > > you see something you like feel free to give them a call and I'll help them > > navigate. > > > > Photos updated as I walk through, here: > > > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > > > If you see something you like it'd be great if you could check if I'm > > interested first until I'm finished today. ;] > > > > Hope this helps someone, they shut down soon! > > From anders.k.nelson at gmail.com Sat Feb 16 15:43:30 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sat, 16 Feb 2019 16:43:30 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: They have until the end of June 2019. On Sat, Feb 16, 2019, 4:24 PM William Donzelli Also, can you find out when they plan to close their doors and/or call > the scrapper? A timetable? > > Thank you for your effort so far. > > -- > Will > > On Sat, Feb 16, 2019 at 4:20 PM Anders Nelson via cctalk > wrote: > > > > More photos posted to the album with some NIB DEC boards, look like a > > motherboard and CRT board, two of each. > > > > On Sat, Feb 16, 2019, 1:51 PM Anders Nelson > wrote: > > > > > Hi everyone, > > > > > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to > > > pay them a visit. I'm taking pictures of as much vintage computing > gear as > > > I can as we speak. I'll be here until they close today at 5pm EST, so > if > > > you see something you like feel free to give them a call and I'll help > them > > > navigate. > > > > > > Photos updated as I walk through, here: > > > > > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > > > > > If you see something you like it'd be great if you could check if I'm > > > interested first until I'm finished today. ;] > > > > > > Hope this helps someone, they shut down soon! > > > > From technoid6502 at gmail.com Sat Feb 16 15:52:28 2019 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Sat, 16 Feb 2019 16:52:28 -0500 Subject: Speaking of sounds made by machines In-Reply-To: References: Message-ID: <118f47201c517a4979bd4212c9b9ef64b16fbce6.camel@gmail.com> Of all machines I've used, the beloved Atari 8-bit is most vocal. It has the feature of 'i/o noise' by default. It can be disabled with a Poke, but every kind of io has distinctive sounds and actually represents the data being sent/received. If you disable it and crank the volume on your TV, you can STILL hear it, but very muted. I think this feature was created to conceal this fact... It isn't just the Atari8 that has this 'feature' in its muted version, all of the RF-TV-type machines from the 80's produce it. In theory, I think you could snoop the actual data, Tempest-like, using some radio gear. One gets very attuned to the noise and can tell the type of data being sent, (Text, vs Binary, for example) by ear. Of course, tracking noises from floppies and hard disks are also very useful indicators. In the 90's I got the hpfs386 driver out of a warp server pack and hung it on my warp 4 client. I LOVED hearing it hit the drive at boot. Boy howdy what a performance increase that gave. Best regards, Jeff On Fri, 2019-02-15 at 12:00 -0600, cctalk-request at classiccmp.org wrote: > Speaking of sounds made by machines From pete at pski.net Sat Feb 16 15:56:34 2019 From: pete at pski.net (Peter Cetinski) Date: Sat, 16 Feb 2019 16:56:34 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: > On Feb 16, 2019, at 4:43 PM, Anders Nelson via cctalk wrote: > > They have until the end of June 2019. >> Just my $0.02. When I was there last year they said the same thing. And prices were eBay level. If prices aren?t coming down a lot I suspect they may get their lease ?extended?. From technoid6502 at gmail.com Sat Feb 16 15:58:23 2019 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Sat, 16 Feb 2019 16:58:23 -0500 Subject: Shock and vibration are legitimate diagnostic tools. In-Reply-To: References: Message-ID: <1a2be198703431af842f6d00512f19eef5f04474.camel@gmail.com> > > On Fri, 2019-02-15 at 12:00 -0600, cctalk-request at classiccmp.org wrote:> > as These hardware wizard stories remind me of a legendary repair wizard, > non-computer industrial devices I think. He was called in to fix a > tricky problem at the customer site. Studied it for a while, took > out a small hammer, whacked the device at some spot, and reported > "fixed". He then sent in a bill for $500 That has been my line any time I've needed to know if a machine had a 'flaky'. Sometimes, on the phone, ask a customer to give the machine a kick. They always balk, but I tell them "Shock and vibration are legitimate diagnostic tools", and that usually convinces them. In situations I suspect the problem is a flaky, it often results in a 'working' system and the customer says "oh wow! you Fixed it!". To which I say NO NO NO. It is not Fixed, only the problem is now revealed. I'll be over shortly to actually bolt down what needs bolting or otherwise make the machine immune to shock and vibration..... Best, Jeff From anders.k.nelson at gmail.com Sat Feb 16 16:37:03 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sat, 16 Feb 2019 17:37:03 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: Well, I got outta there with: - IBM 6360, $45 - IBM 4868-002, $20 - 10 pack DSDD soft sector 8" floppies, $10 - Life magazine from 1941 with pretty lady on the cover, $5 Did I get swindled or is this par for the course? On Sat, Feb 16, 2019, 4:56 PM Peter Cetinski > > On Feb 16, 2019, at 4:43 PM, Anders Nelson via cctalk < > cctalk at classiccmp.org> wrote: > > > > They have until the end of June 2019. > >> > > Just my $0.02. When I was there last year they said the same thing. And > prices were eBay level. If prices aren?t coming down a lot I suspect they > may get their lease ?extended?. From wdonzelli at gmail.com Sat Feb 16 16:44:32 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Sat, 16 Feb 2019 17:44:32 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: No steals, but does seem quite reasonable. Well, depending on just HOW pretty the girl is. -- Will On Sat, Feb 16, 2019 at 5:37 PM Anders Nelson via cctalk wrote: > > Well, I got outta there with: > > - IBM 6360, $45 > - IBM 4868-002, $20 > - 10 pack DSDD soft sector 8" floppies, $10 > - Life magazine from 1941 with pretty lady on the cover, $5 > > Did I get swindled or is this par for the course? > > On Sat, Feb 16, 2019, 4:56 PM Peter Cetinski > > > > > On Feb 16, 2019, at 4:43 PM, Anders Nelson via cctalk < > > cctalk at classiccmp.org> wrote: > > > > > > They have until the end of June 2019. > > >> > > > > Just my $0.02. When I was there last year they said the same thing. And > > prices were eBay level. If prices aren?t coming down a lot I suspect they > > may get their lease ?extended?. From cctalk at gtaylor.tnetconsulting.net Sat Feb 16 17:04:13 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 16 Feb 2019 16:04:13 -0700 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: <52ca358a-bac0-8fc0-74a3-8d2dff1b0ecd@spamtrap.tnetconsulting.net> On 2/16/19 3:37 PM, Anders Nelson via cctalk wrote: > Well, I got outta there with: > > - IBM 6360, $45 > - IBM 4868-002, $20 > - 10 pack DSDD soft sector 8" floppies, $10 > - Life magazine from 1941 with pretty lady on the cover, $5 Okay. > Did I get swindled or is this par for the course? From my naive point of view, those prices look reasonable. I would not feel bad if I left a swap meet having spent what you did. Are they a steal? I don't think so. Is it anything worth getting upset about, I doubt it. Can you do better, maybe. Is it worth arguing, probably not. -- Grant. . . . unix || die From bandit1921 at conbuilder.com Sat Feb 16 12:43:47 2019 From: bandit1921 at conbuilder.com (bandit1921 conbuilder.com) Date: Sat, 16 Feb 2019 18:43:47 +0000 Subject: corvus mirror Message-ID: Anybody know where I can find a working Corvus Mirror? I have several h89/90 and 2 h8's, most still work. From cctalk at gtaylor.tnetconsulting.net Sat Feb 16 20:36:11 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 16 Feb 2019 19:36:11 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190215050309.GA26741@RawFedDogs.net> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> Message-ID: On 2/14/19 10:03 PM, Kevin Monceaux via cctalk wrote: > I also acquired an RS/6000 7012-340, its 7208 8mm tape drive, and a > couple of 9121 voice servers. It used to run DirectTalk/6000. I'm running into collisions with IBM 9121 and mainframe components. Even that is vague. I'm not having nearly the luck I usually do looking up IBM four digit model numbers. > I might have the terminology wrong. I not very familiar with the token > ring side of things. By the time I got into mainframe operations about > twenty years ago we only had a few token ring devices left. The RS/6000 > mentioned above was only connected to the token ring side of our network. > It connected to the 3174 via token ring to screen scrape emulated 3270 > sessions. Before the RS/6000 was shut down, I was able to telnet to it > from my PC, which was on the Ethernet side of the network. So you had IP connectivity from Ethernet to Token Ring. That's trivial to do. The Cisco 2513 would be a very good candidate router to do that. Many things can /route/ between Ethernet and Token Ring. There are only a few things (that I'm aware of) that can /bridge/ between Ethernet and Token Ring. Even then, the union of the type of traffic that works on both Ethernet and Token Ring is considerably smaller than either side. TCP/IP inside of 802.2 SNAP frames will work. But exceptionally little on the Ethernet side can, much less does, uses that for TCP/IP. It's possible, but not likely. I think it's far more likely that the 2513 was routing. It may have also been doing some sort of NAT / port forwarding (which is largely modifying the packet before it's routed). > The router in is the Cisco 2500 series, perhaps a 2513. I found this > photo on the net, which looks like the router in question, if I remember > correctly: > > https://kyozoufs.blob.core.windows.net/filestoragetcdb/Pictures/_30/29886/29885389.jpg Yep. That's a quintessential Ethernet & Token Ring router. > As for using telnet on the 3174, I'm going by what I've seen posted on > Hercules mailing lists about how others have connected real terminals > to the Hercules mainframe emulator. A few pictures of such terminals > connected to Hercules can be found at: > > http://CoreStore.org/emuterm.htm I should look for more details. It sounds like some 3174's, with proper firmware, can actually function in both directions. Coax connected 3270 terminals using the 3174 as a gateway to connect to something across the network (Token Ring or maybe Ethernet) via telnet. I suspect this is what a number of Hercules systems are doing. I think it's also possible to have (Token Ring or Ethernet) network connected clients telnet to and use the 3174 as a gateway to connect to ESCON / Bus and Tag machines. > The posts I've seen say one either needs a router to act as a token ring > to Ethernet bridge, or a PC with both token ring and Ethernet cards in > it to act as a bridge. I tend to agree. My only qualm / uncertanty is "bridge" vs "route". But this is likely the pedantic part of me that knows enough details to think "Wait, tab A doesn't directly fit in slot B, what gives?" in this situation. If the 2513 you have is the one that was used for this, I'd love to see the config, if it's still on there. That would very likely settle things for my curiosity. But that's likely not going to happen. 1) The config should have been wiped before leaving a business, and 2) you shouldn't show it to a stranger even if #1 didn't happen. -- Grant. . . . unix || die From charles.unix.pro at gmail.com Sat Feb 16 21:17:17 2019 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sat, 16 Feb 2019 19:17:17 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> Message-ID: On Sat, Feb 16, 2019 at 10:53 AM Charles Anthony wrote: > > > On Sat, Feb 16, 2019 at 10:04 AM Bill Gunshannon via cctalk < > cctalk at classiccmp.org> wrote: > >> >> >> I used SIMH to build RSTS V9.6 on a simulated RA81 disk. I wrote the >> disk as a file to a CDR in CD9660 format. I moved the BA350 and the >> CD to a VS3100 running OpenBSD. I was able to mount the CD under >> OpenBSD and see the file containing the disk image. I used dd with >> the command given in my original message (and repeated above) to try >> to write the image to a real SCSI disk. When I try to boot it I get >> the RSTS Message "INIT.SYS not found". The disk was completely blank >> to start so the RSTS info must have been copied but apparently not >> copied correctly. >> >> Any more suggestions? >> > > My wild speculation would be disk geometry. I don't know the specific > geometry of the RA81 disk, but it is possible that SIMH is writing a sparse > disk image. > > Did some reading up on the RA81 and looked at the relevant SIMH code; it looks like the MSCP protocol is using Logical Block Addressing, which would tend to disprove my sparse disk speculation. -- Charles From Kevin at RawFedDogs.net Sat Feb 16 22:49:33 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Sat, 16 Feb 2019 22:49:33 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> Message-ID: <20190217044932.GA24159@RawFedDogs.net> Grant, On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote: > I'm running into collisions with IBM 9121 and mainframe components. > Even that is vague. I'm not having nearly the luck I usually do looking > up IBM four digit model numbers. The 9121 voice server connected a T1 line to the RS/6000 for use by DT/6000. DT/6000 was used to create interactive phone menu systems. > So you had IP connectivity from Ethernet to Token Ring. That's trivial > to do. The Cisco 2513 would be a very good candidate router to do that. I suspect wherever I saw the term "bridge" used, it was used in the sense of providing IP connectivity from token ring to Ethernet, in the same sense that a physical bridge provides connectivity between two banks of a river. > I think it's also possible to have (Token Ring or Ethernet) network > connected clients telnet to and use the 3174 as a gateway to connect to > ESCON / Bus and Tag machines. Yes, that's what our RS/6000 was doing. It connected via token ring to the 3174 and screen scraped 3270 sessions to move data between its phone menu system and our mainframe. You might find this interesting: http://www.bitsavers.org/pdf/ibm/lan/ZZ78-0355-0_IBM_Token-Ring_Gateways_and_Bridges_Comparisons_and_Recommendations_Nov89.pdf > If the 2513 you have is the one that was used for this, I'd love to see > the config, if it's still on there. I don't have it yet. If I'm able to get it with its config intact, I'll share what I can, minus any company specific details. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From cctalk at gtaylor.tnetconsulting.net Sun Feb 17 00:05:23 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 16 Feb 2019 23:05:23 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190217044932.GA24159@RawFedDogs.net> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <20190217044932.GA24159@RawFedDogs.net> Message-ID: <20a75d18-2d80-a4d9-6ea0-46ea6548949e@spamtrap.tnetconsulting.net> On 2/16/19 9:49 PM, Kevin Monceaux via cctalk wrote: > The 9121 voice server connected a T1 line to the RS/6000 for use by > DT/6000. DT/6000 was used to create interactive phone menu systems. Is that by chance a 9291? Looks like a white / bage box with a grey strip on the front with lights or buttons and a serial port and ""phone (PSTN) network jack on the back? > I suspect wherever I saw the term "bridge" used, it was used in the sense > of providing IP connectivity from token ring to Ethernet, in the same > sense that a physical bridge provides connectivity between two banks of > a river. ACK > Yes, that's what our RS/6000 was doing. It connected via token ring > to the 3174 and screen scraped 3270 sessions to move data between its > phone menu system and our mainframe. You might find this interesting: > > http://www.bitsavers.org/pdf/ibm/lan/ZZ78-0355-0_IBM_Token-Ring_Gateways_and_Bridges_Comparisons_and_Recommendations_Nov89.pdf Probably more show than is health in this day and age. I counter you with this: https://www.argecy.com/3174 > I don't have it yet. If I'm able to get it with its config intact, > I'll share what I can, minus any company specific details. Cool! Based on the Argecy link above, I'm guessing that it's likely routed TCP/IP. That would be the simplest option. -- Grant. . . . unix || die From v.slyngstad at frontier.com Sun Feb 17 00:46:12 2019 From: v.slyngstad at frontier.com (Vincent Slyngstad) Date: Sat, 16 Feb 2019 22:46:12 -0800 Subject: 8-Update In-Reply-To: References: <5B449A770E1A3823@rgout06.bt.lon5.cpcloud.co.uk> <16411FE1-8520-4841-8A7E-E958BAF611D1@avanthar.com> <5c18c105.1c69fb81.5b7fa.3e0cSMTPIN_ADDED_BROKEN@mx.google.com> <042c01d496b9$b103cf00$130b6d00$@gmail.com> Message-ID: From: Anders Nelson via cctalk: Saturday, February 16, 2019 10:58 AM > Oh boy, how did I miss that someone has created a front panel PCB layout > for a PDP-8/e? > > Can you ask Vince to share that design please? Took me a bit of hunting to see how my name came up, as the thread is from a while back, and I had forgotten about it :-). I gather you are responding to: From: Rod G8DGR via cctalk: Saturday, December 15, 2018 11:36 PM > A friend has been able to 3D print toggle switch leavers that fit and work. > Vince Sylngstat has done a console board PCB layout. (Slyngstad) In which case, switch handles can be found here: http://www.so-much-stuff.com/pdp8/cad/3d.php (The FP end is facing you, so you may not instantly recognize it.) and the PCB can be found here: http://svn.so-much-stuff.com/svn/trunk/Eagle/projects/DEC/8ePanel/ or by searching for "8/e front panel" on http://www.so-much-stuff.com/pdp8/cad/boards.php and those have been out there for quite a while. Enjoy! Vince From jdbryan at acm.org Sat Feb 16 19:24:28 2019 From: jdbryan at acm.org (J. David Bryan) Date: Sat, 16 Feb 2019 20:24:28 -0500 Subject: PDP-11 disk image question In-Reply-To: <889aea1b-f428-2cfd-69ca-b95492b33bcc@ieee.org> References: , <889aea1b-f428-2cfd-69ca-b95492b33bcc@ieee.org> Message-ID: On 2/16/19 7:55 AM, Bill Gunshannon via cctalk wrote: > So, I used SIMH to do an install of a complete OS on an RA81 disk. I > would like to move this to a real disk and try it on a real PDP-11. Note that SIMH always writes disc images in little-endian format, regardless of host platform. If your real PDP-11 expects to see big-endian 16-bit words coming from the drive, you'll need to byte-swap the disc image before writing it to a real disc. (This is necessary, e.g., when copying an HP 1000 disc image generated by SIMH to a real HP disc drive.) -- Dave From dave.g4ugm at gmail.com Sun Feb 17 03:23:30 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Sun, 17 Feb 2019 09:23:30 -0000 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> Message-ID: <202a01d4c6a2$72e440b0$58acc210$@gmail.com> > > I should look for more details. It sounds like some 3174's, with proper > firmware, can actually function in both directions. > > Coax connected 3270 terminals using the 3174 as a gateway to connect to > something across the network (Token Ring or maybe Ethernet) via telnet. > I suspect this is what a number of Hercules systems are doing. > I would say the 3174 is acting more as a Terminal Server rather than a gateway. So 3270 CO-AX terminals which are directly attached to the 3174 can connect via TN3270 to another host. Often this is Hercules where Hercules provides a a TN3270 server which is presented to the host as a channel attached 3174... A 3174 can have either a Token Ring or Ethernet interface but not both. (it can also have hdlc/sdlc/bi-sync and bus+tag) > I think it's also possible to have (Token Ring or Ethernet) network connected > clients telnet to and use the 3174 as a gateway to connect to ESCON / Bus > and Tag machines. > The 3174 never acts as a telnet server but......... A channel attached 3174 can be used to pass TCPIP into the mainframe and there are products that run on the mainframe that act as Telnet/TN3270 servers. So in effect it acts as a channel attached network interface for the mainframe. Some 3174s have RS232 ports, so locally attached serial terminals can connect to the mainframe. This can be via Channels or via remote network connectivity, SNA token ring, X.25, SNA over Ethernet. > > The posts I've seen say one either needs a router to act as a token > > ring to Ethernet bridge, or a PC with both token ring and Ethernet > > cards in it to act as a bridge. > > I tend to agree. My only qualm / uncertanty is "bridge" vs "route". > It depends on what is at the other end. If you are going TCPIP/TN3270 then normally you use a router. However if you are going SNA over LAN into the mainframe, from what I remember SNA LAN protocols are non-soutable so you need a bridge/gateway. If you run Hercules on a PC with a Token Ring card then you don't need anything. > But this is likely the pedantic part of me that knows enough details to think > "Wait, tab A doesn't directly fit in slot B, what gives?" in this situation. > > If the 2513 you have is the one that was used for this, I'd love to see the > config, if it's still on there. That would very likely settle things for my > curiosity. But that's likely not going to happen. 1) The config should have > been wiped before leaving a business, and 2) you shouldn't show it to a > stranger even if #1 didn't happen. > Do a search on "CISCO SNA Token Ring Bridging". Lots of papers on there. Last time I fired this lot up I used the CISCO as an IP router and then used NAT In the CISCO hide the token ring from main network. Now I have a 3174 with An Ethernet card and a P390 with a bigger selction of Oss I have lots of options... ... but I am currently distracted by a pile of VAXen > > > -- > Grant. . . . > unix || die Dave From kylevowen at gmail.com Sun Feb 17 09:57:46 2019 From: kylevowen at gmail.com (Kyle Owen) Date: Sun, 17 Feb 2019 09:57:46 -0600 Subject: Dumping contents from MC68701 Message-ID: Has anyone been successful in dumping the EPROM contents from an MC68701? As I understand it, this MCU requires executing a particular program from external memory to access the internal EPROM, both for programming and reading. I will write a utility to dump the contents if necessary, but I am happy to refrain from reinventing the wheel if a solution already exists. Thanks! Kyle From anders.k.nelson at gmail.com Sun Feb 17 10:18:09 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Sun, 17 Feb 2019 11:18:09 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: One final note: I didn't get pictures of these, but Kemners has probably 20-25 IBM external 5 1/4" floppy drives, about half of them are 360K and half are 1.2MB. Two of the 360K drives are NIB, wrapped in their original plastic. =] On Sat, Feb 16, 2019, 5:37 PM Anders Nelson Well, I got outta there with: > > - IBM 6360, $45 > - IBM 4868-002, $20 > - 10 pack DSDD soft sector 8" floppies, $10 > - Life magazine from 1941 with pretty lady on the cover, $5 > > Did I get swindled or is this par for the course? > > On Sat, Feb 16, 2019, 4:56 PM Peter Cetinski >> >> > On Feb 16, 2019, at 4:43 PM, Anders Nelson via cctalk < >> cctalk at classiccmp.org> wrote: >> > >> > They have until the end of June 2019. >> >> >> >> Just my $0.02. When I was there last year they said the same thing. And >> prices were eBay level. If prices aren?t coming down a lot I suspect they >> may get their lease ?extended?. > > From aek at bitsavers.org Sun Feb 17 10:26:11 2019 From: aek at bitsavers.org (Al Kossow) Date: Sun, 17 Feb 2019 08:26:11 -0800 Subject: Dumping contents from MC68701 In-Reply-To: References: Message-ID: it depends on the version of 68701 P3 has no protection P5 does a P3 can be read with a Data I/O Unisite http://matthieu.benoit.free.fr/pdf/MC68705P5_Bootstrap_ROM_Listing.pdf The P5 is more involved. You put it into factory test mode, feed it a NOP instruction and it will output the rom data on the I/O pins. A variation of that will work on other parts in the series. On 2/17/19 7:57 AM, Kyle Owen via cctalk wrote: > Has anyone been successful in dumping the EPROM contents from an MC68701? > As I understand it, this MCU requires executing a particular program from > external memory to access the internal EPROM, both for programming and > reading. From aek at bitsavers.org Sun Feb 17 10:29:09 2019 From: aek at bitsavers.org (Al Kossow) Date: Sun, 17 Feb 2019 08:29:09 -0800 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> Message-ID: <8ff4e328-a442-c49c-e5d5-fde592838576@bitsavers.org> On 2/16/19 6:36 PM, Grant Taylor via cctalk wrote: >> As for using telnet on the 3174, I'm going by what I've seen posted on Hercules mailing lists about how others have >> connected real terminals to the Hercules mainframe emulator.? A few pictures of such terminals connected to Hercules >> can be found at: >> >> http://CoreStore.org/emuterm.htm > > I should look for more details.? It sounds like some 3174's, with proper firmware, can actually function in both > directions. > > Coax connected 3270 terminals using the 3174 as a gateway to connect to something across the network (Token Ring or > maybe Ethernet) via telnet. I suspect this is what a number of Hercules systems are doing. > Guy has this running with a 3174 and ethernet interface. Jay has it working with token ring. I have all the parts to put this together, just no time to work on it right now. From paulkoning at comcast.net Sun Feb 17 10:40:38 2019 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 17 Feb 2019 11:40:38 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> Message-ID: <309EF6A3-EE80-4C50-9579-5402AF5E36C2@comcast.net> > On Feb 16, 2019, at 1:04 PM, Bill Gunshannon via cctalk wrote: > > ... > let's try with a detailed explanation of what I did that didn't seem > to work. > > First, my hardware. I have a PDP-11/93 with a CMD SCSI Module and > a BA350 with 6 2GB hard drives. The Module is set up to present RA81 > disks and the first 3 disks have 4 partitions each which should work > out to 12 RA81 disks. (But that last part is unimportant right now!) > > I used SIMH to build RSTS V9.6 on a simulated RA81 disk. I wrote the > disk as a file to a CDR in CD9660 format. I moved the BA350 and the > CD to a VS3100 running OpenBSD. I was able to mount the CD under > OpenBSD and see the file containing the disk image. I used dd with > the command given in my original message (and repeated above) to try > to write the image to a real SCSI disk. When I try to boot it I get > the RSTS Message "INIT.SYS not found". The disk was completely blank > to start so the RSTS info must have been copied but apparently not > copied correctly. That message is from the first stage in INIT.SYS. It means the boot loader loaded INIT successfully, because you got into that code and it executed disk drivers and file system code in an attempt to look up the INIT.SYS file. That operation failed. The most likely cause is that your disk is the wrong size. If the system was built on a simulated disk of size x, and is booted on a disk where the controller reports size y, that may work. But if the two sizes rounded up to the next power of two are different, RSTS will not recognize the file system. For example, if x is 500 GB and y is 600 GB, that will be the case. This is because RSTS has a file system parameters "device cluster size" which is device size in blocks / 65535 rounded up to a power of 2. And that number affects the file system layout. The boot loader uses simple LBA addressing so it is unaffected by this, which explains why INIT.SYS was properly loaded by the boot loader. paul From dave.g4ugm at gmail.com Sun Feb 17 11:23:49 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Sun, 17 Feb 2019 17:23:49 -0000 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <8ff4e328-a442-c49c-e5d5-fde592838576@bitsavers.org> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <8ff4e328-a442-c49c-e5d5-fde592838576@bitsavers.org> Message-ID: <233c01d4c6e5$8c22ac40$a46804c0$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of Al Kossow via > cctalk > Sent: 17 February 2019 16:29 > To: cctalk at classiccmp.org > Subject: Re: IBM 3174 C 6.4 Microcode Disks? > > > > On 2/16/19 6:36 PM, Grant Taylor via cctalk wrote: > > >> As for using telnet on the 3174, I'm going by what I've seen posted > >> on Hercules mailing lists about how others have connected real > >> terminals to the Hercules mainframe emulator. A few pictures of such > terminals connected to Hercules can be found at: > >> > >> http://CoreStore.org/emuterm.htm > > > > I should look for more details. It sounds like some 3174's, with > > proper firmware, can actually function in both directions. > > > > Coax connected 3270 terminals using the 3174 as a gateway to connect > > to something across the network (Token Ring or maybe Ethernet) via > telnet. I suspect this is what a number of Hercules systems are doing. > > > > Guy has this running with a 3174 and ethernet interface. > Jay has it working with token ring. > > I have all the parts to put this together, just no time to work on it right now. > Mine isn't up at the moment, but I have had it running via Token Ring.... Dave From paulkoning at comcast.net Sun Feb 17 13:32:46 2019 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 17 Feb 2019 14:32:46 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> Message-ID: <9419C76C-77EC-4243-89F2-56483697D8E3@comcast.net> > On Feb 16, 2019, at 1:04 PM, Bill Gunshannon via cctalk wrote: > > ... > First, my hardware. I have a PDP-11/93 with a CMD SCSI Module and > a BA350 with 6 2GB hard drives. The Module is set up to present RA81 > disks and the first 3 disks have 4 partitions each which should work > out to 12 RA81 disks. (But that last part is unimportant right now!) A real RA81 has 891072 blocks, i.e., it's 445 MB. If your partitions are indeed 1/4th of a 2 GB disk they may be just over 512 MB. If so, your RA81 image is not valid for those partitions. Try shrinking the partitions to be the actual RA81 size, or slightly larger. By the way, another possible issue: the free space bitmap in file SATT.SYS is created at pack format time to be large enough for the number of clusters on the disk. If you move the image to a bigger disk, even one with the same device cluster size, it may be that the number of pack clusters now exceeds what SATT.SYS describes. That too is an invalid file system. I would expect that to give a more explicit error message, but it may be that this doesn't happen in INIT, or not at this stage. Either way, the short answer is: RSTS will object to file systems moved to a smaller destination, or to one that is too much larger. What is "too much" depends on a number of details. paul From kylevowen at gmail.com Sun Feb 17 18:11:45 2019 From: kylevowen at gmail.com (Kyle Owen) Date: Sun, 17 Feb 2019 18:11:45 -0600 Subject: Dumping contents from MC68701 In-Reply-To: References: Message-ID: On Sun, Feb 17, 2019, 15:52 Al Kossow via cctalk it depends on the version of 68701 > > P3 has no protection P5 does > > a P3 can be read with a Data I/O Unisite > > http://matthieu.benoit.free.fr/pdf/MC68705P5_Bootstrap_ROM_Listing.pdf > > The P5 is more involved. You put it into factory test mode, feed it a NOP > instruction > and it will output the rom data on the I/O pins. > > A variation of that will work on other parts in the series. > Thanks for the info! Pardon the na?ve question, but will this procedure work for the 701? Not sure the differences between in and the 705. Kyle > From web at loomcom.com Sun Feb 17 19:41:07 2019 From: web at loomcom.com (Seth J. Morabito) Date: Sun, 17 Feb 2019 17:41:07 -0800 Subject: 3B2 Simulator Ethernet - Looking for Testers Message-ID: <87k1hx27rg.fsf@loomcom.com> Hi folks, I think the NI Ethernet device is ready for some real world beta testing. I have put up a page here with details about how to build SIMH and how to install the "NI" ethernet drivers and TCP/IP software here: https://loomcom.com/3b2/networking.html If you're interested in helping out, you can build the current "3b2-ni" feature branch from GitHub and give it a test. If you run into any problems, I'll walk you through how to do some debugging and get logs for me to look at. If you have any questions or need any additional help, please don't hesitate to email me! Best Wishes, -Seth -- Seth Morabito Poulsbo, WA, USA web at loomcom.com From guykd at optusnet.com.au Sun Feb 17 21:29:00 2019 From: guykd at optusnet.com.au (Guy Dunphy) Date: Mon, 18 Feb 2019 14:29:00 +1100 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: Message-ID: <3.0.6.32.20190218142900.011974e0@mail.optusnet.com.au> At 01:51 PM 16/02/2019 -0500, you wrote: >Hi everyone, > >I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay >them a visit. I'm taking pictures of as much vintage computing gear as I >can as we speak. I'll be here until they close today at 5pm EST, so if you >see something you like feel free to give them a call and I'll help them >navigate. > >Photos updated as I walk through, here: > >https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 That's a lot of visual fun, thanks for the photos. There is NO SUCH THING in Australia. There were still a small number when I was a child (1960-70s), all long gone now. >If you see something you like it'd be great if you could check if I'm >interested first until I'm finished today. ;] > >Hope this helps someone, they shut down soon! I see 4 Boxes of punch cards. All blank? https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHbb-beU6Jf4oNqEABuPoVWamYFUtg/photo/AF1QipP1COpYtcSYKVmiBAZskOJL5yujK8d2561Fepk?key=MmhXdXRtVkhoZkNGODBleGFNeGYza2xvV1BkbjV3 Too bad he wants $25 a box. And it's on the East coast, not West coast near my LA reshipper (to Australia.) And I'm near broke again, after this: http://www.eevblog.com/forum/testgear/hp-8594e-spectrum-analyzer-at-last-i-own-a-decent-spec-an/ http://www.eevblog.com/forum/repair/hp-8594e-spectrum-analyzer-repair-%28i-hope%29/ Guy From cctalk at gtaylor.tnetconsulting.net Sun Feb 17 21:45:36 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sun, 17 Feb 2019 20:45:36 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <202a01d4c6a2$72e440b0$58acc210$@gmail.com> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <202a01d4c6a2$72e440b0$58acc210$@gmail.com> Message-ID: <767b6871-3f32-0658-48eb-41cd2625168b@spamtrap.tnetconsulting.net> On 2/17/19 2:23 AM, Dave Wade wrote: > I would say the 3174 is acting more as a Terminal Server rather than > a gateway. So 3270 CO-AX terminals which are directly attached to the > 3174 can connect via TN3270 to another host. Often this is Hercules where > Hercules provides a a TN3270 server which is presented to the host as > a channel attached 3174... I think we should clarify what "Terminal Server" and "Gateway" mean in this context. I was using "Gateway" to mean going between two different types of networks, SNA / 3270 on one side and TCP/IP / Telnet on the other side. I'm not sure how to define "terminal server". I would think that a terminal server does what is needed to connect a terminal and drive a terminal. I think there's a significant overlap in those two terms and their associated definitions. Please correct me as you see fit. > A 3174 can have either a Token Ring or Ethernet interface but not both. > (it can also have hdlc/sdlc/bi-sync and bus+tag) The reading that I did last night agrees with that. But I don't see how that's germane to this discussion. > The 3174 never acts as a telnet server but......... > > A channel attached 3174 can be used to pass TCPIP into the mainframe and > there are products that run on the mainframe that act as Telnet/TN3270 > servers. So in effect it acts as a channel attached network interface > for the mainframe. Okay. Maybe I'm supplementing a poor understanding of what a 3174 is with what I /think/ a Cisco router with a Channel Interface Processor is. Namely that the Cisco terminates the TCP/IP connection and generates a new 3270 based terminal connection into the mainframe. Note how there is no TCP/IP passing through the Cisco + CIP into the mainframe. > Some 3174s have RS232 ports, so locally attached serial terminals can > connect to the mainframe. This can be via Channels or via remote network > connectivity, SNA token ring, X.25, SNA over Ethernet. ACK It's my understanding that 3174s that connect to channels / ESCON / FICON (via adaptation) are "Local" 3174s. They can have network (Token-Ring / Ethernet / RS-232 / other) interfaces that are used to talk to other "Remote" 3174s. The "Remote" 3174s then connect and drive local 3270 terminals which communicate across the network. > It depends on what is at the other end. If you are going TCPIP/TN3270 then > normally you use a router. However if you are going SNA over LAN into > the mainframe, from what I remember SNA LAN protocols are non-soutable > so you need a bridge/gateway. I think we just fell off the end of the continental shelf into the ocean. - But IMHO this is fun. This is how we (I) learn new things. :-D After having skimmed the PDF that Kevin linked to, I've mostly settled on the following: The 3174s speak TCP/IP on the downstream (grey) (Token Ring / Ethernet) LAN / side. (I'm ignoring the protocols across the other circuits that the 3174 supports between 3174s.) There are two frame types that are supported on Token Ring, 802.2 Logical Link Control and 802.2 LLC with SubNetwork Access Protocol. TCP/IP on Token Ring traditionally uses SNAP. Conversely, there are four frame types that are supported on Ethernet; LLC, SNAP, Ethernet v2, and 802.3 "Raw". TCP/IP on Ethernet traditionally used Ethernet v2. So, we have a discrepancy between the frame types that traditionally carry TCP/IP on Token Ring and Ethernet. The easiest way to deal with this is to use a router that uses the proper frame type for the underlying network. But that's /routing/, and not bridging. Hence why my qualm / uncertanty was "routing" vs "bridging". I think it may be possible to have a piece of software / hardware actually /bridge/ the IP packet or TCP datagram between SNAP and Ethernet v2 (and vice versa). But I've /rarely/ heard of that being done. Especially when you have MTU differences between Token Ring and Ethernet that are difficult to deal with transparently. I concede that data is being connected between the two networks much like a bridge allows cars to connect between islands. So, back to your statement. "TCPIP/TN3270 then normally you use a router." Where does the TCP/IP connection that is the TN3270 traffic terminate? Is it on the router? Or is it on the mainframe? Please elaborate on what you mean by "SNA over LAN". What protocols would that be seen as on the LAN client? NetBIOS? Something other than TN3270 over TCP/IP? Are you referring to DLC? It's my understanding that DLC is a point-to-point protocol and not usable on a LAN. I ask because I did not see any reference to anything other than TCP/IP in conjunction with the 3174 LAN interface. I agree that NetBIOS is not routable. > If you run Hercules on a PC with a Token Ring card then you don't need > anything. How is the 3174 going to connect a 3270 terminal to Hercules running on a PC via Token Ring if not TN3270? Or is that the difference in terms that I was commenting about above. Also, I would expect a 3174 with Ethernet to similarly be able to connect a 3270 terminal to Hercules running on a PC via Ethernet. > Do a search on "CISCO SNA Token Ring Bridging". Lots of papers on there. Yep. As with all things mainframe related, it's complex and there are a lot of options. The trick is finding the options that will work in the various constraints. > Last time I fired this lot up I used the CISCO as an IP router and then > used NAT In the CISCO hide the token ring from main network. NAT on the 2500 series Cisco is decidedly routing and not bridging. > Now I have a 3174 with An Ethernet card and a P390 with a bigger selction > of Oss I have lots of options... :-) > ... but I am currently distracted by a pile of VAXen ~chuckle~ -- Grant. . . . unix || die From john.h.blake at gmail.com Sun Feb 17 18:57:22 2019 From: john.h.blake at gmail.com (John Blake) Date: Mon, 18 Feb 2019 09:57:22 +0900 Subject: Kemners Surplus - Real time walkthrough Message-ID: Any idea what that blue Data General machine was?? Some kind of terminal server? From dave.g4ugm at gmail.com Mon Feb 18 02:20:08 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Mon, 18 Feb 2019 08:20:08 -0000 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <767b6871-3f32-0658-48eb-41cd2625168b@spamtrap.tnetconsulting.net> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <202a01d4c6a2$72e440b0$58acc210$@gmail.com> <767b6871-3f32-0658-48eb-41cd2625168b@spamtrap.tnetconsulting.net> Message-ID: <002a01d4c762$c31a2520$494e6f60$@gmail.com> I will apologise at the top as this is slightly rambling... > -----Original Message----- > From: cctalk On Behalf Of Grant Taylor via > cctalk > Sent: 18 February 2019 03:46 > To: cctalk at classiccmp.org > Subject: Re: IBM 3174 C 6.4 Microcode Disks? > > On 2/17/19 2:23 AM, Dave Wade wrote: > > I would say the 3174 is acting more as a Terminal Server rather than a > > gateway. So 3270 CO-AX terminals which are directly attached to the > > 3174 can connect via TN3270 to another host. Often this is Hercules > > where Hercules provides a a TN3270 server which is presented to the > > host as a channel attached 3174... > > I think we should clarify what "Terminal Server" and "Gateway" mean in this > context. > > I was using "Gateway" to mean going between two different types of > networks, SNA / 3270 on one side and TCP/IP / Telnet on the other side. > So the 3174 does not do this. 3270 terminals don't talk SNA/3270 to the 3174 as defined in the IBM 3270 data streams. They are usually pretty dumb and from what I can gather all keystrokes go to the 3174 just as for an ASCII terminal. It only becomes a 3270 protocol when it exits the 3174. You get dumb terminals, either ASCII or 3270 Screens in, and at the other side you connect 3270 over SNA/SDLC, SNA/Token Ring, BiSync, X.25 or whatever. > I'm not sure how to define "terminal server". I would think that a terminal > server does what is needed to connect a terminal and drive a terminal. > That?s exactly what a 3174 does. IBM calls it a Terminal Controller. > I think there's a significant overlap in those two terms and their associated > definitions. > > Please correct me as you see fit. I think there is, but to me a gateway has LAN protocols on both sides. > > > A 3174 can have either a Token Ring or Ethernet interface but not both. > > (it can also have hdlc/sdlc/bi-sync and bus+tag) > > The reading that I did last night agrees with that. But I don't see how that's > germane to this discussion. > > > The 3174 never acts as a telnet server but......... > > > > A channel attached 3174 can be used to pass TCPIP into the mainframe > > and there are products that run on the mainframe that act as > > Telnet/TN3270 servers. So in effect it acts as a channel attached > > network interface for the mainframe. > > Okay. > > Maybe I'm supplementing a poor understanding of what a 3174 is with what I > /think/ a Cisco router with a Channel Interface Processor is. Namely that the > Cisco terminates the TCP/IP connection and generates a new 3270 based > terminal connection into the mainframe. Note how there is no TCP/IP > passing through the Cisco + CIP into the mainframe. > The 3174 NEVER accepts any sort of incoming connections. Just physical terminals. When used to connect network traffic to a mainframe the 3174 does not terminate the TCPIP connection., it passes the frames across to the channel. I may be wrong its been a long time since I did this and I don't want to go delving into the VTAM documentation. > > Some 3174s have RS232 ports, so locally attached serial terminals can > > connect to the mainframe. This can be via Channels or via remote > > network connectivity, SNA token ring, X.25, SNA over Ethernet. > > ACK > > It's my understanding that 3174s that connect to channels / ESCON / FICON > (via adaptation) are "Local" 3174s. They can have network (Token-Ring / > Ethernet / RS-232 / other) interfaces that are used to talk to other "Remote" > 3174s. The "Remote" 3174s then connect and drive local 3270 terminals > which communicate across the network. > Its kind of odd. RS232 (so X.25/SDLC/HDLC/Bi-Sync) connections can only be used to connect to a Mainframe, not another 3174. The Token Ring or Ethernet interface can be used to connect traffic to the mainframe But from what I remember the 3174 isn't too involved at this level it is acting as a network router/bridge. Just to confuse things this is an IBM manual where IBM does use it as a "gateway"... http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/lan/GG24-3366-0_3174_Remote_Token-Ring_Gateway_Feb89.pdf so using the Token Ring interface on a remote 3174 to connect SNA traffic to the host via SDLC.... ... again no TCPIP, working at the frame level, and the host end cannot be a 3174... > > It depends on what is at the other end. If you are going TCPIP/TN3270 > > then normally you use a router. However if you are going SNA over LAN > > into the mainframe, from what I remember SNA LAN protocols are > > non-soutable so you need a bridge/gateway. > > I think we just fell off the end of the continental shelf into the ocean. - But > IMHO this is fun. This is how we (I) learn new things. :-D > > After having skimmed the PDF that Kevin linked to, I've mostly settled on the > following: > That really muddies the waters because it uses the term "3270" connection in two senses. It uses it to refer to the co-ax type connection from a work station (CUT or DFT) with with 3270 over Channel/SNA as defined in the 3270 data streams manual and these really are different protocols. > The 3174s speak TCP/IP on the downstream (grey) (Token Ring / Ethernet) > LAN / side. (I'm ignoring the protocols across the other circuits that the 3174 > supports between 3174s.) > That?s where you are going wrong. The protocols that the 3174 supports between other 3174s are IBM SNA protocols. The "other 3174s" do not need to be 3174s and can be any SNA device. Where does it say that?. In particular on page 39 it says.. IEEE 802.2 ? PU 2/LU 2 ? PU 2.1/LU 6.2 (in migration mode) In the sort of use Kevin is talking about for connecting to Mainframe channels there is generally no TCPIP on the 3174. In effect it looks like a Mainframe NIC... > There are two frame types that are supported on Token Ring, 802.2 Logical > Link Control and 802.2 LLC with SubNetwork Access Protocol. > TCP/IP on Token Ring traditionally uses SNAP. > > Conversely, there are four frame types that are supported on Ethernet; LLC, > SNAP, Ethernet v2, and 802.3 "Raw". TCP/IP on Ethernet traditionally used > Ethernet v2. > > So, we have a discrepancy between the frame types that traditionally carry > TCP/IP on Token Ring and Ethernet. The easiest way to deal with this is to > use a router that uses the proper frame type for the underlying network. > But that's /routing/, and not bridging. Hence why my qualm / uncertanty was > "routing" vs "bridging". > But the 3174 generally doesn't use TCPIP on the ring... > I think it may be possible to have a piece of software / hardware actually > /bridge/ the IP packet or TCP datagram between SNAP and Ethernet v2 (and > vice versa). But I've /rarely/ heard of that being done. Especially when you > have MTU differences between Token Ring and Ethernet that are difficult to > deal with transparently. > > I concede that data is being connected between the two networks much like > a bridge allows cars to connect between islands. > > So, back to your statement. "TCPIP/TN3270 then normally you use a router." > Where does the TCP/IP connection that is the TN3270 traffic terminate? Is it > on the router? Or is it on the mainframe? > The TN3270 traffic originates from the 3174 and terminates on the Mainframe. TN3270 (and normal Telnet) traffic NEVER terminates on the 3174... > Please elaborate on what you mean by "SNA over LAN". What protocols > would that be seen as on the LAN client? NetBIOS? Something other than > TN3270 over TCP/IP? Are you referring to DLC? It's my understanding that > DLC is a point-to-point protocol and not usable on a LAN. > IBM describes it as LU6.2..... > I ask because I did not see any reference to anything other than TCP/IP in > conjunction with the 3174 LAN interface. > See above.... > I agree that NetBIOS is not routable. > > > If you run Hercules on a PC with a Token Ring card then you don't need > > anything. > > How is the 3174 going to connect a 3270 terminal to Hercules running on a PC > via Token Ring if not TN3270? > That?s how it connects, but this is not the normal operating mode of a 3174. > Or is that the difference in terms that I was commenting about above. > > Also, I would expect a 3174 with Ethernet to similarly be able to connect a > 3270 terminal to Hercules running on a PC via Ethernet. > Yes, but a 3270 terminal does not talk 3270 protocol to the 3174.... > > Do a search on "CISCO SNA Token Ring Bridging". Lots of papers on there. > > Yep. As with all things mainframe related, it's complex and there are a lot of > options. The trick is finding the options that will work in the various > constraints. > Yes and the waters get muddied because the 3174 has had extra features added along the way that allow it to be used in odd ways.... > > Last time I fired this lot up I used the CISCO as an IP router and > > then used NAT In the CISCO hide the token ring from main network. > > NAT on the 2500 series Cisco is decidedly routing and not bridging. > > > Now I have a 3174 with An Ethernet card and a P390 with a bigger > > selction of Oss I have lots of options... > > :-) > > > ... but I am currently distracted by a pile of VAXen > > ~chuckle~ > > > > -- > Grant. . . . > unix || die Dave From lproven at gmail.com Mon Feb 18 06:19:52 2019 From: lproven at gmail.com (Liam Proven) Date: Mon, 18 Feb 2019 13:19:52 +0100 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <01R39I59B7C68WXLWI@beyondthepale.ie> References: <01R39I59B7C68WXLWI@beyondthepale.ie> Message-ID: On Sat, 16 Feb 2019 at 01:43, Peter Coghlan via cctalk wrote: > Days turned into weeks, weeks into months and months into > years. It continued to occasionally make the same ghastly noises that > never should be heard coming from a hard disk but with absolutely no sign > of any errors being logged or damage to data whatsoever. The noises seem > to be associated with seek activity because I have never heard them when > the disk is just spinning but otherwise idle. I eventually retired it > and replaced it with a much larger one, purely because I ran out of > space on it. Any thoughts on what might be happening with it? Ha! Well that is the thing, of course. I had that with one old IDE disk, too. It made a terrible ear-piercing high whine that I associate with a failing disk... but it passed every diagnostic I could throw at it, so I used it for non-critical stuff and in testbed machines. For about 4 or 5 *years*. It was one reason to run machines with the case covers on, to muffle the noise. But it ran faultlessly for years. I think in the end I sold it on to someone, with a warning of course. That's how I dispose of all kit -- pass it on to a new owner. I try never to scrap or recycle anything at all. That's the problem with rule-of-thumb diagnoses. Sometimes they fail. But more often, things fail with no warning, so it's still useful. This is why I disregard everyone's accounts of hard disk brands they won't touch. I did PC tech support for ~25 years. I've seen every make of hard drive ever fail randomly, and I've seen every make of hard drive ever work flawlessly for years even when vilely abused. My experience is extensive enough that _anyone's_ justifications of why they won't use Brand X disks get ignored, because if I took them, I would not use _any_brand of disk. Everyone who's been around a bit has a horror story and the intersection in the Venn diagram, while small, excludes all vendors ever. I've never seen any one make that is significantly worse than any other. -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Mon Feb 18 06:26:21 2019 From: lproven at gmail.com (Liam Proven) Date: Mon, 18 Feb 2019 13:26:21 +0100 Subject: Speaking of sounds made by machines In-Reply-To: <118f47201c517a4979bd4212c9b9ef64b16fbce6.camel@gmail.com> References: <118f47201c517a4979bd4212c9b9ef64b16fbce6.camel@gmail.com> Message-ID: On Sat, 16 Feb 2019 at 22:53, Jeffrey S. Worley via cctalk wrote: > > Of all machines I've used, the beloved Atari 8-bit is most vocal. It > has the feature of 'i/o noise' by default. It can be disabled with a > Poke, but every kind of io has distinctive sounds and actually > represents the data being sent/received. If you disable it and crank > the volume on your TV, you can STILL hear it, but very muted. I think > this feature was created to conceal this fact... > > It isn't just the Atari8 that has this 'feature' in its muted version, > all of the RF-TV-type machines from the 80's produce it. Interesting, yes. I noticed that with my ZX Spectrum machines and yes, it was interesting and occasionally useful for debugging. "No, it's not crashed, it's deep in a loop, and hang on, I can hear that every few seconds it's briefly going through the outer loop, so it's still working... give it time..." > In theory, I > think you could snoop the actual data, Tempest-like, using some radio > gear. I think it's been done. > In the 90's I got the hpfs386 driver out of a warp server pack and hung > it on my warp 4 client. I LOVED hearing it hit the drive at boot. Boy > howdy what a performance increase that gave. Yes, exactly! :-D There were busmastering drivers for both Win95/98 and for NT4. On Win9x they made no particular difference, because the "kernel" was single-threaded and so couldn't overlap anything else with disk I/O. You got a very small benefit from DMA being a smidgen faster than PIO and that was it. But on NT, even on a uniprocessor, when it offloaded disk I/O onto the Intel Triton 84230 PIIX disk controller, the kernel could get on with doing other stuff while waiting for disk accesses to complete. Boot up got tens of seconds quicker, and more to the point, the machine remained responsive when under heavy disk load. E.g. even if it was thrashing you had a chance of killing the offending process, which you didn't without the DMA drivers. But no system builder installed them by default. Possibly because then the disk wouldn't boot on different IDE hardware -- bear in mind this was before Windows activation, so an install could just be duped onto another machine. But if the other machine didn't have Triton chipset, it wouldn't boot. -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From wdonzelli at gmail.com Mon Feb 18 08:10:43 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Mon, 18 Feb 2019 09:10:43 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: <3.0.6.32.20190218142900.011974e0@mail.optusnet.com.au> References: <3.0.6.32.20190218142900.011974e0@mail.optusnet.com.au> Message-ID: > I see 4 Boxes of punch cards. All blank? > > https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHbb-beU6Jf4oNqEABuPoVWamYFUtg/photo/AF1QipP1COpYtcSYKVmiBAZskOJL5yujK8d2561Fepk?key=MmhXdXRtVkhoZkNGODBleGFNeGYza2xvV1BkbjV3 > > Too bad he wants $25 a box. 25 dollars for a full box of blank cards is actually a really good price - but those cards are probably too far gone. Jam city. -- Will From paulkoning at comcast.net Mon Feb 18 08:16:54 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 18 Feb 2019 09:16:54 -0500 Subject: PDP-11 disk image question In-Reply-To: <9419C76C-77EC-4243-89F2-56483697D8E3@comcast.net> References: <20190216091023.4c7c0894@asrock> <9419C76C-77EC-4243-89F2-56483697D8E3@comcast.net> Message-ID: <05D56A14-FC64-4F4A-9EDB-E8AF20B46581@comcast.net> > On Feb 17, 2019, at 2:32 PM, Paul Koning via cctalk wrote: > > > >> On Feb 16, 2019, at 1:04 PM, Bill Gunshannon via cctalk wrote: >> >> ... >> First, my hardware. I have a PDP-11/93 with a CMD SCSI Module and >> a BA350 with 6 2GB hard drives. The Module is set up to present RA81 >> disks and the first 3 disks have 4 partitions each which should work >> out to 12 RA81 disks. (But that last part is unimportant right now!) > > A real RA81 has 891072 blocks, i.e., it's 445 MB. If your partitions are indeed 1/4th of a 2 GB disk they may be just over 512 MB. If so, your RA81 image is not valid for those partitions. > > Try shrinking the partitions to be the actual RA81 size, or slightly larger. Alternatively, in SIMH define your disk to match the size of the actual device, and transfer your system to that disk. It should be just a matter of copying everything (which in V9.0 or later is easily done with the BACKUP command) and you then probably have to use the HOOK utility to write the boot block. paul From billdegnan at gmail.com Mon Feb 18 10:10:38 2019 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 18 Feb 2019 11:10:38 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: Of the items in https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 This photo depicts a Raytheon VT302, I did not see the keyboard in the photo, hoping it is not lost: https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHbb-beU6Jf4oNqEABuPoVWamYFUtg/photo/AF1QipOzaTLOK_RE9-qpb9i-3_qcoRrQXL7idfoAHsk?key=MmhXdXRtVkhoZkNGODBleGFNeGYza2xvV1BkbjV3 ...but I can say this is apparently a very rare or historic computer, not many known to exist other than this one (unless the one I once owned found its way to this surplus shop, I know don't remember who bought it from me, but it was in this same general geographic location and may have found its way here eventually. So, someone might want to grab it. Here are some photos I took of mine. Yes I got rid of mine, not interested in this class of computer and space is limited. I only know it's "historic" because I have been contacted a few times about this machine, to my surprise, people writing about them or industry research https://vintagecomputer.net/raytheon/VT302/ Bill On Sat, Feb 16, 2019 at 1:52 PM Anders Nelson via cctalk < cctalk at classiccmp.org> wrote: > Hi everyone, > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay > them a visit. I'm taking pictures of as much vintage computing gear as I > can as we speak. I'll be here until they close today at 5pm EST, so if you > see something you like feel free to give them a call and I'll help them > navigate. > > Photos updated as I walk through, here: > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > If you see something you like it'd be great if you could check if I'm > interested first until I'm finished today. ;] > > Hope this helps someone, they shut down soon! > From dkelvey at hotmail.com Mon Feb 18 10:47:20 2019 From: dkelvey at hotmail.com (dwight) Date: Mon, 18 Feb 2019 16:47:20 +0000 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: There were a couple hp XY plotters that had the mylar plate delaminating. I've reworked these with model airplane mono coat. I'd be interested in one of these if they'd not been to far away. If you do a search, there is also a youtube video of a more extended walk through. The fellow was also a collector of 16mm films. He has racks and racks of them. He has a lot of tubes and a few old radios. The fellow doing the video was not to interested in these things. Dwight ________________________________ From: cctalk on behalf of John Blake via cctalk Sent: Sunday, February 17, 2019 4:57 PM To: cctalk at classiccmp.org Subject: Re: Kemners Surplus - Real time walkthrough Any idea what that blue Data General machine was? Some kind of terminal server? From anders.k.nelson at gmail.com Mon Feb 18 10:50:49 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Mon, 18 Feb 2019 11:50:49 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: True, there were large reels on a rack, most were educational films. There was a room dedicated to tube radios, most were in very rough shape aesthetically. Also a room with reel-to-reel audio decks from AKAI, Teac and other brands that looked nice. Phonographs of varying decade, a bunch of camcorders and film cameras of various format. -- Anders Nelson +1 (517) 775-6129 www.erogear.com On Mon, Feb 18, 2019 at 11:47 AM dwight via cctalk wrote: > There were a couple hp XY plotters that had the mylar plate delaminating. > I've reworked these with model airplane mono coat. I'd be interested in one > of these if they'd not been to far away. > If you do a search, there is also a youtube video of a more extended walk > through. The fellow was also a collector of 16mm films. He has racks and > racks of them. He has a lot of tubes and a few old radios. The fellow doing > the video was not to interested in these things. > Dwight > > ________________________________ > From: cctalk on behalf of John Blake via > cctalk > Sent: Sunday, February 17, 2019 4:57 PM > To: cctalk at classiccmp.org > Subject: Re: Kemners Surplus - Real time walkthrough > > Any idea what that blue Data General machine was? Some kind of terminal > server? > > From cclist at sydex.com Mon Feb 18 11:23:43 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 18 Feb 2019 09:23:43 -0800 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: On 2/18/19 8:10 AM, Bill Degnan via cctalk wrote: > Of the items in > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > This photo depicts a Raytheon VT302, I did not see the keyboard in the > photo, hoping it is not lost: > > https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHbb-beU6Jf4oNqEABuPoVWamYFUtg/photo/AF1QipOzaTLOK_RE9-qpb9i-3_qcoRrQXL7idfoAHsk?key=MmhXdXRtVkhoZkNGODBleGFNeGYza2xvV1BkbjV3 > > ...but I can say this is apparently a very rare or historic computer, not > many known to exist other than this one (unless the one I once owned found > its way to this surplus shop, I know don't remember who bought it from me, > but it was in this same general geographic location and may have found its > way here eventually. So, someone might want to grab it. > I probably have at least one sample of a Lexitron floppy in my stash; I don't think they were particularly rare back in the day. The problem today is that nobody (or almost nobody) collects old word processors, due to their limited application and appeal. As an example, where I worked in 1977, we had at least two Artec word processing systems. Basically Diablo Hitypes hooked to large floor-standing units with 8" diskette drives and using a one-line LCD mounted on the Hitype. After the IBM PC and similar machines debuted, the word processor market collapsed quickly. Artec was purchased by Pitney-Bowes and merged into Dictaphone, another acquisition. By 1983, P-B had abandoned the WP business entirely. How many people have heard of, much less collect, smart typewriters made by Exxon Qyx, for example. Or old Harris/Lanier word processors? --Chuck From karbak at gmail.com Mon Feb 18 11:26:41 2019 From: karbak at gmail.com (K. Arun) Date: Mon, 18 Feb 2019 11:26:41 -0600 Subject: Free: 2x DEC Alpha workstations - 164LX and XP1000 Message-ID: Hello, I have a couple of Alpha workstations that were last used 5-6 years ago with some version of Tru64 on them. They haven't been turned on since, and may need some work to get running again. They're free to anyone who thinks they can use them, and can pick them up from the 78722 zip code (near UT Austin). Please contact me off-list to co-ordinate pickup. Thanks, Arun From healyzh at avanthar.com Mon Feb 18 11:32:43 2019 From: healyzh at avanthar.com (Zane Healy) Date: Mon, 18 Feb 2019 09:32:43 -0800 Subject: Free: 2x DEC Alpha workstations - 164LX and XP1000 In-Reply-To: References: Message-ID: <0B7FF5D7-204D-4280-A4E6-A6BF8CE1DEA7@avanthar.com> For anyone that isn?t familiar with the XP1000, it?s seriously worth rescuing. It?s a Compaq system with an Alpha 21264 CPU in it. Basically it is something like a DEC PWS 433au/500au/600au. Good for both OpenVMS and Tru64. I know they made at least a 500Mhz and 667Mhz version (I have both). These have the added advantage of not needing custom RAM. I use RAM for PC servers in mine. Zane > On Feb 18, 2019, at 9:26 AM, K. Arun via cctalk wrote: > > Hello, > > I have a couple of Alpha workstations that were last used 5-6 years ago > with some version of Tru64 on them. They haven't been turned on since, and > may need some work to get running again. They're free to anyone who thinks > they can use them, and can pick them up from the 78722 zip code (near UT > Austin). Please contact me off-list to co-ordinate pickup. > > Thanks, > > Arun From cclist at sydex.com Mon Feb 18 11:35:11 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 18 Feb 2019 09:35:11 -0800 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: I'll add a postscript to my bit on Wupro disinterest. Exxon went into the WP business briefly by purchasing Vydec along with Qyx. Nobody seems to remember those either. Who collects old FAX machines, for example? FWIW, on eBay, there's an Exxon Verbex voice recognition box that seems to have garnered little interest. Lear Siegler licensed the technology, but I don't know what they did with it. Bottom line is that you'll very often find these business-related bits of hardware in old warehouse detritus. It seems that unless someone used a system while in school or can play games with it, there's no interest, no matter how groundbreaking the technology. --Chuck From Kevin at RawFedDogs.net Mon Feb 18 11:46:06 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Mon, 18 Feb 2019 11:46:06 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20a75d18-2d80-a4d9-6ea0-46ea6548949e@spamtrap.tnetconsulting.net> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <20190217044932.GA24159@RawFedDogs.net> <20a75d18-2d80-a4d9-6ea0-46ea6548949e@spamtrap.tnetconsulting.net> Message-ID: <20190218174606.GA28678@RawFedDogs.net> Grant, On Sat, Feb 16, 2019 at 11:05:23PM -0700, Grant Taylor via cctalk wrote: > Is that by chance a 9291? Looks like a white / bage box with a grey > strip on the front with lights or buttons and a serial port and ""phone > (PSTN) network jack on the back? Checking our hardware list it looks like I made a typo. It is a 9291. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From guykd at optusnet.com.au Mon Feb 18 11:41:38 2019 From: guykd at optusnet.com.au (Guy Dunphy) Date: Tue, 19 Feb 2019 04:41:38 +1100 Subject: Kemners Surplus - Real time walkthrough Message-ID: <3.0.6.32.20190219044138.01041058@mail.optusnet.com.au> Oops, this was meant to go to the list _and_ William. Sorry for duplicate Will. At 09:10 AM 18/02/2019 -0500, Will wrote: >> I see 4 Boxes of punch cards. All blank? >> >> https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHbb-beU6Jf4oNqEABuPoVWamYFUtg/photo/AF1QipP1COpYtcSYKVmiBAZskOJL5yujK8d2561Fepk?key=MmhXdXRtVkhoZkNGODBleGFNeGYza2xvV1BkbjV3 >> >> Too bad he wants $25 a box. > >25 dollars for a full box of blank cards is actually a really good >price - but those cards are probably too far gone. Jam city. Maybe, maybe not. And there they are, as opposed to being mythical, somewhere else. Anyway, if someone was to go to Kemners and offer $10 a box for all 4, arguing that "they are pretty far gone, jam city, dusty, in a mess, maybe some blocks are OK, etc." Then I'd pay for them and pack & postage to my US reshipper in CA. At this address: Guy Dunphy 3503 Jack Northrop Ave Ste J8637 Hawthorne, CA 90250 USA And then be facing the postage to Australia too. Hence my low offer. Reason: As part of the Australian Computer Museum Society equipment dispersal, I have an IBM 028 and three IBM 026 card punches to restore. Eventually. Plus that Documation TM200 card reader. Which I'm still seeking a manual for btw. Guy From bill.gunshannon at hotmail.com Mon Feb 18 14:46:05 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 18 Feb 2019 20:46:05 +0000 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> Message-ID: SO, to start a wrap up on this topic. I had heard of people copying images made on SIMH to real disks and using them. It now seems there are some serious strings attached to that idea. I know it works for small disks as I have done it with RL02 and RX/Ry disks. I have one more thing to try but in the long run it isn't very practical. I am going to try using VTServer to move the image. Not practical as it will take several days to do this and every minute increases the likelihood of it just failing. Too bad there is not some form of Standalone Backup like VMS has. I am open to any suggestions about how one can get RSTS installed on real hardware when no usable tape drive is available. I don't suppose that hidden deep in the bowels of RSTS is a procedure for making Installation Kits on various media like Ultrix-11 has. bill From cisin at xenosoft.com Mon Feb 18 15:16:02 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 18 Feb 2019 13:16:02 -0800 (PST) Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <01R39I59B7C68WXLWI@beyondthepale.ie> Message-ID: On Mon, 18 Feb 2019, Liam Proven via cctalk wrote: > Well that is the thing, of course. I had that with one old IDE disk, > too. It made a terrible ear-piercing high whine that I associate with > a failing disk... but it passed every diagnostic I could throw at it, > so I used it for non-critical stuff and in testbed machines. One of the moxt common causes of a terrible ear-piercing high whine is the spindle contact. Many old drives had a springy piece that rubbed against the end of the spindle. Over time, it would wear a divot, polish that, and start to squeal. A very light pressure on it would test that hypothesis. Not enough pressure to muffle the sound, and certaianly not enough pressure to slow the spindle! Or, pulling up on it, away from the spindle. Some people claimed that you could just rip it off. Don't. Best is to twist it very slightly sideways, so that it can start wearing a new divot. > My experience is extensive enough that _anyone's_ justifications of > why they won't use Brand X disks get ignored, Well, there don't seem to be many 350 RAMAC disks still running. (I'm trying to decide what to use as a base to make a patio table out of a [crashed] RAMAC 24" platter) -- Grumpy Ol' Fred cisin at xenosoft.com From paulkoning at comcast.net Mon Feb 18 15:35:18 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 18 Feb 2019 16:35:18 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> Message-ID: <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> > On Feb 18, 2019, at 3:46 PM, Bill Gunshannon via cctalk wrote: > > > > SO, to start a wrap up on this topic. I had heard of people > copying images made on SIMH to real disks and using them. It > now seems there are some serious strings attached to that idea. > I know it works for small disks as I have done it with RL02 > and RX/Ry disks. I'm not sure which comments you're replying to. For the case of RSTS, small or large is not a consideration. What matters, as I mentioned, is that RSTS has a file system layout that is dependent on the device size. So (unlike some other file systems like FAT32) is isn't always valid to do an image copy from one device to a larger device. If the input and output devices are the same size, and error free, image copy is always valid. MSCP devices are error free; some older devices are also normally error free (like RK05 or RP03). It would be interesting if you can post the exact sizes in blocks of the SIMH image, and the real disk you copied it to. That would help confirm my guess that it's a size issue. If that's not the answer, it would be possible to use INIT ODT to catch the error and analyze what specifically it's unhappy about, but that's not straightforward. If you do have a size mismatch, fixing thatbefore you retry would be a good thing. > Too bad there is not some form of Standalone Backup like > VMS has. I am open to any suggestions about how one can > get RSTS installed on real hardware when no usable tape > drive is available. I don't suppose that hidden deep > in the bowels of RSTS is a procedure for making Installation > Kits on various media like Ultrix-11 has. RSTS doesn't have any released mechanisms for creating installation kits. Those scripts existed on the RSTS development systems. Possibly they can be found in source kits (which are rare). In the early days, RSTS came with a standalone image backup program: ROLLIN. Around V6 that was replaced by a file system aware standalone backup program: the SAVRES option in INIT. That was retired in V9 when the new fast BACKUP program was released. The reasoning here is that standalone backup isn't a feature -- instead, the feature is a way to do a full system restore starting from a dead system. RSTS does this by copying a few minimal features from the installation device: INIT.SYS, a monitor (such as SYSGEN.SIL), DCL, BACKUP, and perhaps one or two other files. Then you start that minimal system and issue a RESTORE command to restore everything from your backup. So there is no need for the maintenance headache of a "standalone" backup tool. SAVRES had a pile of hairy bugs and major maintenance headaches, and making a standalone PDP11 tool do streaming tape support was just way too painful. That's why V9 went the route of doing everything with BACKUP, since that's where the streaming support was added. The steps for bare metal restore go roughly like this: 1. Boot a kit 2. Use the DSKINT option to initialize the output disk 3. Use the COPY option to copy the minimal files to the output disk, which is then booted. 4. Start that minimal system on the output disk. 5. Use RESTORE to copy everything from your backup. I don't remember if there is a documented procedure for creating a minimal kit. For disk based ones, it's pretty simple: a. Initialize the kit device as read-only. b. Mount it, overriding the read-only setting. c. Copy the minimal files. d. Hook INIT.SYS. e. To test it, boot the kit; it should boot correctly and act as a kit (by offering to copy to the output device rather than by going to the usual INIT prompt). You can do this for any RSTS disk that's big enough, and for which INIT still has a boot loader. For example, even in V10.1 you can boot an RK05, so you can make an RK05 kit. If the device isn't big enough for all the minimal files, it gets a bit tricky but it still can be done; the Micro-RSTS RX50 based kit is an example. I don't have the details at my fingertips but I can dig them out if needed. paul From paulkoning at comcast.net Mon Feb 18 15:38:20 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 18 Feb 2019 16:38:20 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <01R39I59B7C68WXLWI@beyondthepale.ie> Message-ID: <50036086-BE4C-440D-A830-90F817A023C3@comcast.net> > On Feb 18, 2019, at 4:16 PM, Fred Cisin via cctalk wrote: > > On Mon, 18 Feb 2019, Liam Proven via cctalk wrote: >> Well that is the thing, of course. I had that with one old IDE disk, >> too. It made a terrible ear-piercing high whine that I associate with >> a failing disk... but it passed every diagnostic I could throw at it, >> so I used it for non-critical stuff and in testbed machines. > > One of the moxt common causes of a terrible ear-piercing high whine is the spindle contact. Many old drives had a springy piece that rubbed against the end of the spindle. Then again, I remember our college RS64 (drive for the RC11) which developed a bad motor bearing. Since the platter is mounted directly on the motor spindle that was a problem. And it was not under contract, so replacing the motor would have set back the department a substantial sum. So the DEC FS engineer removed the motor and carried it to Appleton Electric Motor Co., which pulled the old bearing, pressed on a replacement, and handed it back. Jim reinstalled the motor, all was well. Didn't even lose any data bits. paul From cube1 at charter.net Mon Feb 18 15:47:23 2019 From: cube1 at charter.net (Jay Jaeger) Date: Mon, 18 Feb 2019 15:47:23 -0600 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: <50036086-BE4C-440D-A830-90F817A023C3@comcast.net> References: <01R39I59B7C68WXLWI@beyondthepale.ie> <50036086-BE4C-440D-A830-90F817A023C3@comcast.net> Message-ID: On 2/18/2019 3:38 PM, Paul Koning via cctalk wrote: > > >> On Feb 18, 2019, at 4:16 PM, Fred Cisin via cctalk wrote: >> >> On Mon, 18 Feb 2019, Liam Proven via cctalk wrote: >>> Well that is the thing, of course. I had that with one old IDE disk, >>> too. It made a terrible ear-piercing high whine that I associate with >>> a failing disk... but it passed every diagnostic I could throw at it, >>> so I used it for non-critical stuff and in testbed machines. >> >> One of the moxt common causes of a terrible ear-piercing high whine is the spindle contact. Many old drives had a springy piece that rubbed against the end of the spindle. > > Then again, I remember our college RS64 (drive for the RC11) which developed a bad motor bearing. Since the platter is mounted directly on the motor spindle that was a problem. And it was not under contract, so replacing the motor would have set back the department a substantial sum. So the DEC FS engineer removed the motor and carried it to Appleton Electric Motor Co., which pulled the old bearing, pressed on a replacement, and handed it back. Jim reinstalled the motor, all was well. Didn't even lose any data bits. > > paul > Nice of the FE to do that. The Univ. of Wisconsin CS Department had one of those, but the platter went bad. They just flipped the platter upside down and got more use out of it. The Univ. of Wisconsin ECE Department also had one - the two machines were nearly twins. I *have* *that* one - and it still ran when I tried it a year or so ago. From paulkoning at comcast.net Mon Feb 18 15:59:45 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 18 Feb 2019 16:59:45 -0500 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <01R39I59B7C68WXLWI@beyondthepale.ie> <50036086-BE4C-440D-A830-90F817A023C3@comcast.net> Message-ID: <177375D6-8032-4800-A3B5-5822FFE1947A@comcast.net> > On Feb 18, 2019, at 4:47 PM, Jay Jaeger via cctalk wrote: > > On 2/18/2019 3:38 PM, Paul Koning via cctalk wrote: >> >> ... >> Then again, I remember our college RS64 (drive for the RC11) which developed a bad motor bearing. ... >> > > Nice of the FE to do that. > > The Univ. of Wisconsin CS Department had one of those, but the platter > went bad. They just flipped the platter upside down and got more use > out of it. Yes, that was a feature. You had to reformat it, which required getting the timing track writer box from Maynard. I have seen that done on an RS11 (RF11) drive on our RSTS system; it crashed some heads and was rebuilt completely (new heads, new platter, new motor). > The Univ. of Wisconsin ECE Department also had one - the two machines > were nearly twins. I *have* *that* one - and it still ran when I tried > it a year or so ago. Neat. You can run RT11 on it if you add the boot loader and driver, at least old versions. DOS V4 also supports it. And older versions of RSTS can use it as a swap disk. paul From mtapley at swri.edu Mon Feb 18 16:16:41 2019 From: mtapley at swri.edu (Tapley, Mark) Date: Mon, 18 Feb 2019 22:16:41 +0000 Subject: Free: 2x DEC Alpha workstations - 164LX and XP1000 In-Reply-To: References: Message-ID: Arun, If you don?t find other homes for these systems, please let me know. I probably have more machines than I need right now, but I think I can add these to the herd. But, if you get another offer, please put that first priority. - Mark 210-522-6025 office 210-379-4635 cell > On Feb 18, 2019, at 11:26 AM, K. Arun via cctalk wrote: > > Hello, > > I have a couple of Alpha workstations that were last used 5-6 years ago > with some version of Tru64 on them. They haven't been turned on since, and > may need some work to get running again. They're free to anyone who thinks > they can use them, and can pick them up from the 78722 zip code (near UT > Austin). Please contact me off-list to co-ordinate pickup. > > Thanks, > > Arun > > CAUTION: This email originated from outside SwRI and it may contain attachments and/or links. Do not open attachments or click on links unless you recognize the sender and know the content is safe. From aperry at snowmoose.com Mon Feb 18 11:49:30 2019 From: aperry at snowmoose.com (Alan Perry) Date: Mon, 18 Feb 2019 09:49:30 -0800 Subject: RS/6000 7043-140 boot floppies Message-ID: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Is there some trick to making boot floppies for the RS/6000 7043-140 (a mid-90s PReP architecture machine)? I initially tried to install Solaris 2.5.1 on it and created the boot floppy by dd'ing the image using a SPARCstation (running NetBSD). I dd'ed the image over, dd'ed it back and verified the SPARCstation could read back what it had written to the floppy. The RS/6000 loads what is on the floppy, but hangs transferring control to what it loaded. The 7043-140 does not appear on the list of supported systems in the Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the 7043-140 is a PReP machine, maybe they aren't compatible, so I tried NetBSD. The 7043-140 is listed as a supported system. The NetBSD boot floppy images are confusing to me. The files are too large to fit on a 1.44M floppy. I didn't see instructions on how to make boot floppies out of the .fs files one can download in the install instructions. I went ahead and tried to dd the part that fits onto a 1.44M floppy and try to boot that and of course that failed. I have e-mailed the NetBSD prep mailing list and no response from that. The system does boot the AIX install on one of its hard disks, but this is a recycled system and I don't have usernames/passwords for that install. Does anyone here have a suggestion on how to proceed? alan From cruff at ruffspot.net Mon Feb 18 12:37:11 2019 From: cruff at ruffspot.net (Craig Ruff) Date: Mon, 18 Feb 2019 11:37:11 -0700 Subject: Q: Plotter bed repair with MonoKote? In-Reply-To: References: Message-ID: > On Feb 18, 2019, at 11:00 AM, dwight wrote: > > There were a couple hp XY plotters that had the mylar plate delaminating. I've reworked these with model airplane mono coat. Are you referring to MonoKote (www.monokote.com )? That looks perfect for repairing the gouged bed of one of my 9872C plotters. Is a hot air supply suitable for applying the film, or did you use their heating iron? I'm guessing a bit of pressure to adhere the film is necessary? From pat at vax11.net Mon Feb 18 12:42:58 2019 From: pat at vax11.net (Patrick Finnegan) Date: Mon, 18 Feb 2019 13:42:58 -0500 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: On Mon, Feb 18, 2019 at 12:49 PM Alan Perry via cctech < cctech at classiccmp.org> wrote: > > Is there some trick to making boot floppies for the RS/6000 7043-140 (a > mid-90s PReP architecture machine)? > > The NetBSD boot floppy images are confusing to me. The files are too > large to fit on a 1.44M floppy. I didn't see instructions on how to make > boot floppies out of the .fs files one can download in the install > instructions. I went ahead and tried to dd the part that fits onto a > 1.44M floppy and try to boot that and of course that failed. I have > e-mailed the NetBSD prep mailing list and no response from that. > I'd strongly suggest setting up a netboot server. You'll need dhcp/bootp and tftp, but it's way better than trying to deal with floppy disks and floppy booting. I've used it succesfully for NetBSD and Linux on a '140. I never tried Solaris, because I have no interest in Solaris, but it should work the same there. Pat From aperry at snowmoose.com Mon Feb 18 13:24:27 2019 From: aperry at snowmoose.com (Alan Perry) Date: Mon, 18 Feb 2019 11:24:27 -0800 Subject: RS/6000 7043-140 boot floppies In-Reply-To: References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: <1367de3c-d987-be38-4352-7d147ca13cef@snowmoose.com> On 2/18/19 10:42 AM, Patrick Finnegan wrote: > On Mon, Feb 18, 2019 at 12:49 PM Alan Perry via cctech > > wrote: > > > Is there some trick to making boot floppies for the RS/6000 > 7043-140 (a > mid-90s PReP architecture machine)? > > The NetBSD boot floppy images are confusing to me. The files are too > large to fit on a 1.44M floppy. I didn't see instructions on how > to make > boot floppies out of the .fs files one can download in the install > instructions. I went ahead and tried to dd the part that fits onto a > 1.44M floppy and try to boot that and of course that failed. I have > e-mailed the NetBSD prep mailing list and no response from that. > > > I'd strongly suggest setting up a netboot server. You'll need > dhcp/bootp?and tftp, but it's way better than trying to deal with > floppy disks and floppy booting.? I've used it succesfully for NetBSD > and Linux on a '140. > > I never tried Solaris, because I have no interest in Solaris, but it > should work the same there. Thanks. I prefer floppy because I am usually putting systems back together away from a network connection. But, if that is what it takes to get an usable OS onto the system, I guess I will cobble together the pieces to do that. But now I am more inclined to install Solaris on it :) alan > > Pat From bear at typewritten.org Mon Feb 18 14:20:02 2019 From: bear at typewritten.org (r.stricklin) Date: Mon, 18 Feb 2019 12:20:02 -0800 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: On Feb 18, 2019, at 9:49 AM, Alan Perry via cctech wrote: > The 7043-140 does not appear on the list of supported systems in the Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the 7043-140 is a PReP machine, maybe they aren't compatible they aren't. solaris doesn't support the 7043 at all. in fact, it doesn't support the 604e at all. if you upgrade the 604 in the 7248 (a supported machine) to a 604e (an official upgrade) solaris stops working. ok bear. -- until further notice From rtomek at ceti.pl Mon Feb 18 14:40:28 2019 From: rtomek at ceti.pl (Tomasz Rola) Date: Mon, 18 Feb 2019 21:40:28 +0100 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: <20190218204028.GA20907@tau1.ceti.pl> On Mon, Feb 18, 2019 at 09:49:30AM -0800, Alan Perry via cctech wrote: > > Is there some trick to making boot floppies for the RS/6000 7043-140 > (a mid-90s PReP architecture machine)? > [...] > The NetBSD boot floppy images are confusing to me. The files are too > large to fit on a 1.44M floppy. I didn't see instructions on how to > make boot floppies out of the .fs files one can download in the > install instructions. I went ahead and tried to dd the part that > fits onto a 1.44M floppy and try to boot that and of course that > failed. I have e-mailed the NetBSD prep mailing list and no response > from that. > > The system does boot the AIX install on one of its hard disks, but > this is a recycled system and I don't have usernames/passwords for > that install. > > Does anyone here have a suggestion on how to proceed? I have not much of idea about RS6000 but had a peek around netbsd.org and they have page about running NetBSD on emulators of various kind. So you may want to experiment with prep emulator, which seems to be GXemul: http://www.NetBSD.org/ports/emulators.html http://www.NetBSD.org/ports/emulators.html#gxemul and, for example, see if said floppy images boot at all. A casual check of generic.fs gives me this: => (591 12): curl -O 'https://cdn.NetBSD.org/pub/NetBSD/NetBSD-8.0/prep/installation/floppy/generic.fs' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2597k 100 2597k 0 0 3251k 0 --:--:-- --:--:-- --:--:-- 3588k => (591 13): file generic.fs generic.fs: x86 boot sector; partition 1: ID=0x41, active, starthead 0, startsector 0, 2879 sectors, code offset 0x0 You have new mail in /var/mail/tomek => (591 14): fdisk -l generic.fs Disk generic.fs: 2 MB, 2659840 bytes 2 heads, 18 sectors/track, 144 cylinders, total 5195 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System generic.fs1 * 0 2878 1439+ 41 PPC PReP Boot -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From cube1 at charter.net Mon Feb 18 15:48:50 2019 From: cube1 at charter.net (Jay Jaeger) Date: Mon, 18 Feb 2019 15:48:50 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215032837.GA2556@RawFedDogs.net> Message-ID: On 2/15/2019 10:22 AM, Jay Jaeger via cctech wrote: > On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote: >> Classic Computer Fans, >> >> I posted this to the IBM-Legacy-Hercules mailing list. I just realized it >> probably wouldn't hurt to post it here too. >> >> I'm finally in possession of a box that hopefully is capable or can be made >> capable of connecting a real terminal to Hercules. It's a 3174 11L. It was >> retired last year where I work. I finally got the okay to save it from >> being sent to a scrapper. I love the build quality of older IBM gear, >> except when I'm trying to move such gear. Between the 3174 and a 9406-520 I >> also acquired, I pulled or strained something in my left arm moving them >> into place. >> >> It's currently wired to run on 220v. I think I've seen mentioned somewhere >> that it can be changed to run on 110v. If that's the case, does anyone have >> a pointer to documentation on what's involved? >> >> It has dual floppy drives. At least one drive is a 2.4MB drive. But, all >> the microcode disks I have are at level B 4.6. Does anyone know where I can >> get a set of C 6.4 control and control extension disks. From what I've >> heard those are what's needed to enable an attached terminal to connect to >> other systems via telnet. >> >> It has a token ring card. I will probably be able to get the MAU it was >> connected to, and possibly the router that acted as a token ring to Ethernet >> bridge. >> >> I'm not sure how much memory it has. Does anyone have any tips on >> determining the amount of memory it has, and/or identifying its boards? >> These are the numbers on its boards: >> >> 9210 >> 9351 >> 9052 z2 >> 9053 >> 9501 >> >> Plus the boards for coax connections. >> >> >> > > I have some 3174 floppy disks, but I don't know what - they are not in > my inventory. I will put it on my queue to look at them - but it may be > a couple of weeks. I don't hold out much hope, but I will look. > Well, it turns out my floppies are for *3274* rather than 3174. But, that said, if anyone needs any of them, let me know: just shipping cost. Here is a sample: 3274 Disks IBM Diskette 2 256 Bytes/Sector Date Name 8/09/83 A13 FEAT DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 6/18/84 A22 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A12 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/01/84 A22 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/01/84 A12 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/12/84 A23 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/12/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/18/84 A23 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 6/11/85 B22 18.33 LANGUAGE DISKETTE FOR CONFIG D AT REL 64.0 OR HIGHER 6/11/85 A12 21.30 SYSTEM - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/18/85 A12 19.40 FEATURE - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/24/86 B23 17.17 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.08 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.05 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER ------- KYB DEF UTILILTY REL G FOR LOAD 3290 D41.00, 3179-G D25.00 OR HIGHER (And about 150 more, in a similar date range) From mtapley at swri.edu Mon Feb 18 15:55:01 2019 From: mtapley at swri.edu (Tapley, Mark) Date: Mon, 18 Feb 2019 21:55:01 +0000 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: > On Feb 18, 2019, at 11:49 AM, Alan Perry via cctech wrote: > > > Is there some trick to making boot floppies for the RS/6000 7043-140 (a mid-90s PReP architecture machine)? > > I initially tried to install Solaris 2.5.1 on it and created the boot floppy by dd'ing the image using a SPARCstation (running NetBSD). I dd'ed the image over, dd'ed it back and verified the SPARCstation could read back what it had written to the floppy. The RS/6000 loads what is on the floppy, but hangs transferring control to what it loaded. > > The 7043-140 does not appear on the list of supported systems in the Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the 7043-140 is a PReP machine, maybe they aren't compatible, so I tried NetBSD. The 7043-140 is listed as a supported system. > > The NetBSD boot floppy images are confusing to me. The files are too large to fit on a 1.44M floppy. I didn't see instructions on how to make boot floppies out of the .fs files one can download in the install instructions. I went ahead and tried to dd the part that fits onto a 1.44M floppy and try to boot that and of course that failed. I have e-mailed the NetBSD prep mailing list and no response from that. > > The system does boot the AIX install on one of its hard disks, but this is a recycled system and I don't have usernames/passwords for that install. > > Does anyone here have a suggestion on how to proceed? > > alan > > CAUTION: This email originated from outside SwRI and it may contain attachments and/or links. Do not open attachments or click on links unless you recognize the sender and know the content is safe. Alan, does the machine also have a CD drive? I got a *lot* of help fast from this list last year while resetting root and user passwords on one of those machines by using the first CD of the AIX install set. I guess that won?t help toward solaris but at least you could run AIX. - Mark From aperry at snowmoose.com Mon Feb 18 16:13:00 2019 From: aperry at snowmoose.com (Alan Perry) Date: Mon, 18 Feb 2019 14:13:00 -0800 Subject: RS/6000 7043-140 boot floppies In-Reply-To: References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: <16024438-790c-3bfc-0ab2-50ab87c87f9b@snowmoose.com> On 2/18/19 12:20 PM, r.stricklin wrote: > On Feb 18, 2019, at 9:49 AM, Alan Perry via cctech wrote: > >> The 7043-140 does not appear on the list of supported systems in the Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the 7043-140 is a PReP machine, maybe they aren't compatible > they aren't. solaris doesn't support the 7043 at all. in fact, it doesn't support the 604e at all. if you upgrade the 604 in the 7248 (a supported machine) to a 604e (an official upgrade) solaris stops working. Interesting. How did you learn this? I don't doubt it. Was this announced or determined experimentally? alan > > ok > bear. > From davidkcollins2 at gmail.com Mon Feb 18 16:15:17 2019 From: davidkcollins2 at gmail.com (David Collins) Date: Tue, 19 Feb 2019 09:15:17 +1100 Subject: Q: Plotter bed repair with MonoKote? In-Reply-To: References: Message-ID: Also very interested in the use of Monokote to repair plotter beds...any more info/experience/tips/traps would be much appreciated. David Collins HP Computer Museum > On 19 Feb 2019, at 5:37 am, Craig Ruff via cctech wrote: > > >> On Feb 18, 2019, at 11:00 AM, dwight wrote: >> >> There were a couple hp XY plotters that had the mylar plate delaminating. I've reworked these with model airplane mono coat. > > Are you referring to MonoKote (www.monokote.com )? That looks perfect for repairing the gouged bed of one of my 9872C plotters. Is a hot air supply suitable for applying the film, or did you use their heating iron? I'm guessing a bit of pressure to adhere the film is necessary? From bill.gunshannon at hotmail.com Mon Feb 18 16:24:21 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 18 Feb 2019 22:24:21 +0000 Subject: PDP-11 disk image question In-Reply-To: <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> Message-ID: On 2/18/19 4:35 PM, Paul Koning wrote: > > >> On Feb 18, 2019, at 3:46 PM, Bill Gunshannon via cctalk wrote: >> >> >> >> SO, to start a wrap up on this topic. I had heard of people >> copying images made on SIMH to real disks and using them. It >> now seems there are some serious strings attached to that idea. >> I know it works for small disks as I have done it with RL02 >> and RX/Ry disks. > > I'm not sure which comments you're replying to. Pretty much all of them. :-) > > For the case of RSTS, small or large is not a consideration. What matters, as I mentioned, is that RSTS has a file system layout that is dependent on the device size. So (unlike some other file systems like FAT32) is isn't always valid to do an image copy from one device to a larger device. My reference to small vs. large had to do with moving images from SIMH virtual disks to real physical disks. I have done it with small disks which means the physical format of the virtual disk in SIMH does, in fact, match the format of a\real equivalents. At least for smaller disks. I am fairly certain I have heard of people doing it with RQ disks as well. This was my first foray into trying to do it with something the size of an RA disk. Theoretically, the SIMH emulated RA81 and the CMD emulated real disk RA81 should be the same size because they are both supposed to be RA81's. > > If the input and output devices are the same size, and error free, image copy is always valid. MSCP devices are error free; All of this sounds good on paper, but so far I have had no luck actually accomplishing it. I have tried copying with different block sizes, copying from different media used to move the image. The results are always the same. > some older devices are also normally error free (like RK05 or RP03). > > It would be interesting if you can post the exact sizes in blocks of the SIMH image, and the real disk you copied it to. That would help confirm my guess that it's a size issue. If it's a size issue then one of them is doing it wrong because the size of an RA81 constant. > If that's not the answer, it would be possible to use INIT ODT to catch the error and analyze what specifically it's unhappy about, but that's not straightforward. > > If you do have a size mismatch, fixing thatbefore you retry would be a good thing. > >> Too bad there is not some form of Standalone Backup like >> VMS has. I am open to any suggestions about how one can >> get RSTS installed on real hardware when no usable tape >> drive is available. I don't suppose that hidden deep >> in the bowels of RSTS is a procedure for making Installation >> Kits on various media like Ultrix-11 has. > > RSTS doesn't have any released mechanisms for creating installation kits. Those scripts existed on the RSTS development systems. Possibly they can be found in source kits (which are rare). > > In the early days, RSTS came with a standalone image backup program: ROLLIN. Around V6 that was replaced by a file system aware standalone backup program: the SAVRES option in INIT. That was retired in V9 when the new fast BACKUP program was released. > > The reasoning here is that standalone backup isn't a feature -- instead, the feature is a way to do a full system restore starting from a dead system. RSTS does this by copying a few minimal features from the installation device: INIT.SYS, a monitor (such as SYSGEN.SIL), DCL, BACKUP, and perhaps one or two other files. Then you start that minimal system and issue a RESTORE command to restore everything from your backup. So there is no need for the maintenance headache of a "standalone" backup tool. SAVRES had a pile of hairy bugs and major maintenance headaches, and making a standalone PDP11 tool do streaming tape support was just way too painful. That's why V9 went the route of doing everything with BACKUP, since that's where the streaming support was added. > > The steps for bare metal restore go roughly like this: > > 1. Boot a kit And there is the problem. If I had a kitI would just do a clean install on the 11/93. :-) > 2. Use the DSKINT option to initialize the output disk > 3. Use the COPY option to copy the minimal files to the output disk, which is then booted. > 4. Start that minimal system on the output disk. > 5. Use RESTORE to copy everything from your backup. > > I don't remember if there is a documented procedure for creating a minimal kit. For disk based ones, it's pretty simple: > > a. Initialize the kit device as read-only. > b. Mount it, overriding the read-only setting. > c. Copy the minimal files. > d. Hook INIT.SYS. > e. To test it, boot the kit; it should boot correctly and act as a kit (by offering to copy to the output device rather than by going to the usual INIT prompt). > > You can do this for any RSTS disk that's big enough, and for which INIT still has a boot loader. For example, even in V10.1 you can boot an RK05, so you can make an RK05 kit. > > If the device isn't big enough for all the minimal files, it gets a bit tricky but it still can be done; the Micro-RSTS RX50 based kit is an example. I don't have the details at my fingertips but I can dig them out if needed. Well, this sounds like the most interesting and possible way. If it cold be done on RX50's it should be doable on other media. Maybe RX33 or maybe even TU58. (Emulated, of course!) I haven't given up yet but it is turniong out to be a lot more of a challenge than I expected. I wonder what the chances are I could get something like an RD31 or RD33 to work and use it as an intermediate for the big disk setup? Good thing it's only a hobby cause I certainly can't see anyone paying me to do this kind of stuff. bill From teoz at neo.rr.com Mon Feb 18 16:31:50 2019 From: teoz at neo.rr.com (TeoZ) Date: Mon, 18 Feb 2019 17:31:50 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: I passed on mint complete word processors at a recyclers ages ago because I had no use for them. I almost picked up a huge IBM typewriter but changed my mind. Everybody has limited space so we try not to fill it with things way outside of our normal collecting. If anything I regret not grabbing some terminals when I had the chance. I guess if you are in the business of reading old word processing floppies with proprietary formats then snagging a few machines might be worth it. -----Original Message----- From: Chuck Guzis via cctalk Sent: Monday, February 18, 2019 12:23 PM To: Bill Degnan via cctalk Subject: Re: Kemners Surplus - Real time walkthrough On 2/18/19 8:10 AM, Bill Degnan via cctalk wrote: > Of the items in > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > This photo depicts a Raytheon VT302, I did not see the keyboard in the > photo, hoping it is not lost: > > https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHbb-beU6Jf4oNqEABuPoVWamYFUtg/photo/AF1QipOzaTLOK_RE9-qpb9i-3_qcoRrQXL7idfoAHsk?key=MmhXdXRtVkhoZkNGODBleGFNeGYza2xvV1BkbjV3 > > ...but I can say this is apparently a very rare or historic computer, not > many known to exist other than this one (unless the one I once owned found > its way to this surplus shop, I know don't remember who bought it from me, > but it was in this same general geographic location and may have found its > way here eventually. So, someone might want to grab it. > I probably have at least one sample of a Lexitron floppy in my stash; I don't think they were particularly rare back in the day. The problem today is that nobody (or almost nobody) collects old word processors, due to their limited application and appeal. As an example, where I worked in 1977, we had at least two Artec word processing systems. Basically Diablo Hitypes hooked to large floor-standing units with 8" diskette drives and using a one-line LCD mounted on the Hitype. After the IBM PC and similar machines debuted, the word processor market collapsed quickly. Artec was purchased by Pitney-Bowes and merged into Dictaphone, another acquisition. By 1983, P-B had abandoned the WP business entirely. How many people have heard of, much less collect, smart typewriters made by Exxon Qyx, for example. Or old Harris/Lanier word processors? --Chuck --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From cclist at sydex.com Mon Feb 18 17:11:11 2019 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 18 Feb 2019 15:11:11 -0800 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: <475a73c6-d5a9-dccb-893d-66bc152ee470@sydex.com> On 2/18/19 2:31 PM, TeoZ wrote: > I passed on mint complete word processors at a recyclers ages ago > because I had no use for them. I almost picked up a huge IBM typewriter > but changed my mind. > Everybody has limited space so we try not to fill it with things way > outside of our normal collecting. If anything I regret not grabbing some > terminals when I had the chance. > > I guess if you are in the business of reading old word processing > floppies with proprietary formats then snagging a few machines might be > worth it. WuPros are interesting from the standpoint that their reign was comparatively brief, barely more than a decade. After the IBM PC arrived, they were pretty much history--but even before that, the 8-bit personal systems could meet perhaps 90% of a company's word processing workload. By the time that graphic-interface operating systems were available (e.g. MacOS, Windows), WPs were a quaint throwback. The very low-end word processors (most notably Brother) hung on for awhile longer, aimed to the computer-phobic crowd--or those who wanted a little more than a smart typewriter. By about 1995, anyone with a moderately powerful personal system could out-perform an expensive document preparation package on a high-end workstation. You too, could have beautiful typefaces and formatting, complete with grammar and spelling errors. I can remember sitting in discussions about "killer apps" (they may have not been called that), but word processing, spreadsheet and the basic accounting (AP, AR, GL, Payroll and Inventory) suite were essentially the way you sold a business computer. --Chuck From teoz at neo.rr.com Mon Feb 18 17:29:13 2019 From: teoz at neo.rr.com (TeoZ) Date: Mon, 18 Feb 2019 18:29:13 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: <475a73c6-d5a9-dccb-893d-66bc152ee470@sydex.com> References: <475a73c6-d5a9-dccb-893d-66bc152ee470@sydex.com> Message-ID: <8BCE8F70D10A481C8E88D07B9119A68F@teoPC> Simple databases were also a killer app. I still recall a small stamp/coin shop firing up a C64 to look for inventory in the early/mid 80's. I hated using a typewriter for school reports so when I purchased a C64 in the 80's I used that for reports. The only thing an electronic word processor had over a C64 was a very nice display (monochrome) compared to a TV for the C64. I forget if the printers on those things were dot matrix or actual characters. -----Original Message----- From: Chuck Guzis via cctalk Sent: Monday, February 18, 2019 6:11 PM To: CCtalk Subject: Re: Kemners Surplus - Real time walkthrough I can remember sitting in discussions about "killer apps" (they may have not been called that), but word processing, spreadsheet and the basic accounting (AP, AR, GL, Payroll and Inventory) suite were essentially the way you sold a business computer. --Chuck --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From cisin at xenosoft.com Mon Feb 18 17:48:24 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 18 Feb 2019 15:48:24 -0800 (PST) Subject: Kemners Surplus - Real time walkthrough In-Reply-To: <8BCE8F70D10A481C8E88D07B9119A68F@teoPC> References: <475a73c6-d5a9-dccb-893d-66bc152ee470@sydex.com> <8BCE8F70D10A481C8E88D07B9119A68F@teoPC> Message-ID: On Mon, 18 Feb 2019, TeoZ via cctalk wrote: > I hated using a typewriter for school reports so when I purchased a C64 in > the 80's I used that for reports. The only thing an electronic word processor > had over a C64 was a very nice display (monochrome) compared to a TV for the > C64. I forget if the printers on those things were dot matrix or actual > characters. Which ones? There were word processors with Selectric I/O, Daisy wheels, and some dot matrix (for people who didn't need "letter quality"). Laser Printers came into existence in the mid 1970s. But, the first mass-market one was the HP laserjet in 1984, followed by the Apple LaserWriter (Postscript!) in 1985. Both of those were Canon CX engine. Then lots more in subsequent years. HP Deskjet in 1988 was probably the first 300DPI for less than $1000 Hardly no C64 users had laser printers or inkjets until much later. From paulkoning at comcast.net Mon Feb 18 18:39:18 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 18 Feb 2019 19:39:18 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> Message-ID: <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> > On Feb 18, 2019, at 5:24 PM, Bill Gunshannon via cctalk wrote: > > On 2/18/19 4:35 PM, Paul Koning wrote: >> >> ... >> For the case of RSTS, small or large is not a consideration. What matters, as I mentioned, is that RSTS has a file system layout that is dependent on the device size. So (unlike some other file systems like FAT32) is isn't always valid to do an image copy from one device to a larger device. > > My reference to small vs. large had to do with moving images from > SIMH virtual disks to real physical disks. I have done it with > small disks which means the physical format of the virtual disk > in SIMH does, in fact, match the format of a\real equivalents. > At least for smaller disks. I am fairly certain I have heard of > people doing it with RQ disks as well. This was my first foray > into trying to do it with something the size of an RA disk. > > Theoretically, the SIMH emulated RA81 and the CMD emulated real > disk RA81 should be the same size because they are both supposed > to be RA81's. Yes, but you said 4 partitions on a 2 GB disk, which is rather different from the actual RA81 size. >> If the input and output devices are the same size, and error free, image copy is always valid. MSCP devices are error free; > > All of this sounds good on paper, but so far I have had no luck > actually accomplishing it. I have tried copying with different block > sizes, copying from different media used to move the image. The results > are always the same. You could read back the copy and compare it with the original. But I can tell you that a properly executed image copy WILL work. I suppose one question is whether dd is actually such a program. >> some older devices are also normally error free (like RK05 or RP03). >> >> It would be interesting if you can post the exact sizes in blocks of the SIMH image, and the real disk you copied it to. That would help confirm my guess that it's a size issue. > > If it's a size issue then one of them is doing it wrong because the > size of an RA81 constant. If you change the transfer address in the boot block by +2, you'll be dropped into ODT immediately after INIT is loaded by the boot loader. You can then proceed from the break and ODT will be called again if a fatal error occurs (such as the "init not found" message). You can then look at the disk size table. Use PATCH on your SIMH copy of the system to find the address of DU$SZL and DU$SZM, those are the tables of low and high 16 bits of the device size for each DU unit (indexed by unit number). The number there will tell you what INIT heard from the controller. >> ... >> The steps for bare metal restore go roughly like this: >> >> 1. Boot a kit > > And there is the problem. If I had a kitI would just do a clean > install on the 11/93. :-) What kit device do you need? >> 2. Use the DSKINT option to initialize the output disk >> 3. Use the COPY option to copy the minimal files to the output disk, which is then booted. >> 4. Start that minimal system on the output disk. >> 5. Use RESTORE to copy everything from your backup. >> >> I don't remember if there is a documented procedure for creating a minimal kit. For disk based ones, it's pretty simple: >> >> a. Initialize the kit device as read-only. >> b. Mount it, overriding the read-only setting. >> c. Copy the minimal files. >> d. Hook INIT.SYS. >> e. To test it, boot the kit; it should boot correctly and act as a kit (by offering to copy to the output device rather than by going to the usual INIT prompt). >> >> You can do this for any RSTS disk that's big enough, and for which INIT still has a boot loader. For example, even in V10.1 you can boot an RK05, so you can make an RK05 kit. >> >> If the device isn't big enough for all the minimal files, it gets a bit tricky but it still can be done; the Micro-RSTS RX50 based kit is an example. I don't have the details at my fingertips but I can dig them out if needed. > > Well, this sounds like the most interesting and possible way. > If it cold be done on RX50's it should be doable on other > media. Maybe RX33 or maybe even TU58. (Emulated, of course!) TU58, no -- that's not a file structured device on RSTS. RX33 is an RX50 in a different physical package if I remember -- 800 block MSCP device. That works fine, subject to the necessary tricks to get the files on the floppies and do the switching. Checking... The way it's done is that INIT.SYS has to be on the first floppy, of course, which is what you boot. Then the other needed files can be spread over other floppies as needed to fit (whole files per floppy). All but the last floppy contain a name.EOV file where "name" is the pack label of the next floppy to use. The content of the file is printed on the console as a prompt; it's a null terminated string. > I haven't given up yet but it is turniong out to be a lot more > of a challenge than I expected. I wonder what the chances are > I could get something like an RD31 or RD33 to work and use it as > an intermediate for the big disk setup? Good thing it's only > a hobby cause I certainly can't see anyone paying me to do this > kind of stuff. > > bill You mean build an initial system on a small disk, and then load the rest onto a big disk some other way? Sure, that should work fine. paul From bill.gunshannon at hotmail.com Mon Feb 18 19:18:38 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Tue, 19 Feb 2019 01:18:38 +0000 Subject: PDP-11 disk image question In-Reply-To: <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On 2/18/19 7:39 PM, Paul Koning wrote: > > >> On Feb 18, 2019, at 5:24 PM, Bill Gunshannon via cctalk wrote: >> >> On 2/18/19 4:35 PM, Paul Koning wrote: >>> >>> ... >>> For the case of RSTS, small or large is not a consideration. What matters, as I mentioned, is that RSTS has a file system layout that is dependent on the device size. So (unlike some other file systems like FAT32) is isn't always valid to do an image copy from one device to a larger device. >> >> My reference to small vs. large had to do with moving images from >> SIMH virtual disks to real physical disks. I have done it with >> small disks which means the physical format of the virtual disk >> in SIMH does, in fact, match the format of a\real equivalents. >> At least for smaller disks. I am fairly certain I have heard of >> people doing it with RQ disks as well. This was my first foray >> into trying to do it with something the size of an RA disk. >> >> Theoretically, the SIMH emulated RA81 and the CMD emulated real >> disk RA81 should be the same size because they are both supposed >> to be RA81's. > > Yes, but you said 4 partitions on a 2 GB disk, which is rather different from the actual RA81 size. According to the manual the first three will be RA81 and the last partition whatever is left over. So the part I was using is supposed to be the same as a real RA81. > >>> If the input and output devices are the same size, and error free, image copy is always valid. MSCP devices are error free; >> >> All of this sounds good on paper, but so far I have had no luck >> actually accomplishing it. I have tried copying with different block >> sizes, copying from different media used to move the image. The results >> are always the same. > > You could read back the copy and compare it with the original. But I can tell you that a properly executed image copy WILL work. I suppose one question is whether dd is actually such a program. When I said I have seen others claim to do it, they usually claim to have done it with dd. I do know that VTServer worked for RL02 and RX/RY disks because I have done it myself. But the idea of doing this with a 400MB disk at 9600 baud seems rather futile. :-) > >>> some older devices are also normally error free (like RK05 or RP03). >>> >>> It would be interesting if you can post the exact sizes in blocks of the SIMH image, and the real disk you copied it to. That would help confirm my guess that it's a size issue. >> >> If it's a size issue then one of them is doing it wrong because the >> size of an RA81 constant. > > If you change the transfer address in the boot block by +2, you'll be dropped into ODT immediately after INIT is loaded by the boot loader. You can then proceed from the break and ODT will be called again if a fatal error occurs (such as the "init not found" message). > > You can then look at the disk size table. Use PATCH on your SIMH copy of the system to find the address of DU$SZL and DU$SZM, those are the tables of low and high 16 bits of the device size for each DU unit (indexed by unit number). The number there will tell you what INIT heard from the controller. > Interesting. Not sure I am ready to go that far into it at this point. Still just looking for some way to move the data. I am thinking more and more that an RD31 or RD33 might be a good stepping stone. >>> ... >>> The steps for bare metal restore go roughly like this: >>> >>> 1. Boot a kit >> >> And there is the problem. If I had a kitI would just do a clean >> install on the 11/93. :-) > > What kit device do you need? Well, all I really have are CQD module which does MSCP and TMSCP over SCSI. I have other controllers that might be coaxed into doing RX50 or RX33 but I haven't used one of them in ages, either. And, as I said earlier TU58 in emulation. On a PC right now but I have all the parts to build a hardware emulator. > >>> 2. Use the DSKINT option to initialize the output disk >>> 3. Use the COPY option to copy the minimal files to the output disk, which is then booted. >>> 4. Start that minimal system on the output disk. >>> 5. Use RESTORE to copy everything from your backup. >>> >>> I don't remember if there is a documented procedure for creating a minimal kit. For disk based ones, it's pretty simple: >>> >>> a. Initialize the kit device as read-only. >>> b. Mount it, overriding the read-only setting. >>> c. Copy the minimal files. >>> d. Hook INIT.SYS. >>> e. To test it, boot the kit; it should boot correctly and act as a kit (by offering to copy to the output device rather than by going to the usual INIT prompt). >>> >>> You can do this for any RSTS disk that's big enough, and for which INIT still has a boot loader. For example, even in V10.1 you can boot an RK05, so you can make an RK05 kit. >>> >>> If the device isn't big enough for all the minimal files, it gets a bit tricky but it still can be done; the Micro-RSTS RX50 based kit is an example. I don't have the details at my fingertips but I can dig them out if needed. >> >> Well, this sounds like the most interesting and possible way. >> If it cold be done on RX50's it should be doable on other >> media. Maybe RX33 or maybe even TU58. (Emulated, of course!) > > TU58, no -- that's not a file structured device on RSTS. RX33 is an RX50 in a different physical package if I remember -- 800 block MSCP device. That works fine, subject to the necessary tricks to get the files on the floppies and do the switching. No, RX50 was a strange DEC format. RX33 is a 1.2M floppy. > > Checking... The way it's done is that INIT.SYS has to be on the first floppy, of course, which is what you boot. Then the other needed files can be spread over other floppies as needed to fit (whole files per floppy). All but the last floppy contain a name.EOV file where "name" is the pack label of the next floppy to use. The content of the file is printed on the console as a prompt; it's a null terminated string. That's going to be fun to try whether I find another solution or not. > >> I haven't given up yet but it is turniong out to be a lot more >> of a challenge than I expected. I wonder what the chances are >> I could get something like an RD31 or RD33 to work and use it as >> an intermediate for the big disk setup? Good thing it's only >> a hobby cause I certainly can't see anyone paying me to do this >> kind of stuff. >> >> bill > > You mean build an initial system on a small disk, and then load the rest onto a big disk some other way? Sure, that should work fine. I was thinking build a minimal system on a smaller disk and and then use it and backup to move the RA81 system to real hardware and then use that for playing with. bill From rar at syssrc.com Mon Feb 18 19:20:58 2019 From: rar at syssrc.com (rar) Date: Tue, 19 Feb 2019 01:20:58 +0000 Subject: [EXTERNAL] corvus mirror In-Reply-To: References: Message-ID: <48e1821cb0404125b52732249169d5d0@Exch13MB.syssrcad.syssrc.com> Are you talking about the a Corvus Hard Drive, along with the video tape backup system? https://en.wikipedia.org/wiki/Corvus_Systems I have a mirror card and several Corvus Hard Drives. Cosmetically good, and probably work, but I'm not sure! Bob Roswell https://Museum.syssrc.com -----Original Message----- From: cctalk On Behalf Of bandit1921 conbuilder.com via cctalk Sent: Saturday, February 16, 2019 1:44 PM To: cctalk at classiccmp.org Subject: [EXTERNAL] corvus mirror Anybody know where I can find a working Corvus Mirror? I have several h89/90 and 2 h8's, most still work. From paulkoning at comcast.net Mon Feb 18 20:02:21 2019 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 18 Feb 2019 21:02:21 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: <0AF0B2D8-7D0C-49EB-B0BC-8DC63E33B9B8@comcast.net> > On Feb 18, 2019, at 8:18 PM, Bill Gunshannon via cctalk wrote: > > On 2/18/19 7:39 PM, Paul Koning wrote: >> >> ... >> TU58, no -- that's not a file structured device on RSTS. RX33 is an RX50 in a different physical package if I remember -- 800 block MSCP device. That works fine, subject to the necessary tricks to get the files on the floppies and do the switching. > > No, RX50 was a strange DEC format. RX33 is a 1.2M floppy. Ok. That's may be big enough without volume switching, but in any case, if it speaks MSCP, RSTS will support it. (Well -- more precisely, if it speaks MSCP and have fewer than 2^23 blocks.) >> ... >> You mean build an initial system on a small disk, and then load the rest onto a big disk some other way? Sure, that should work fine. > > I was thinking build a minimal system on a smaller disk and > and then use it and backup to move the RA81 system to real > hardware and then use that for playing with. Yes, that will be fine. If the disk is RL02-ish in size it will be ample for this purpose. Even something as small as an RK05 can probably be made to do a basic job. paul From bill.gunshannon at hotmail.com Mon Feb 18 20:35:49 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Tue, 19 Feb 2019 02:35:49 +0000 Subject: PDP-11 disk image question In-Reply-To: <0AF0B2D8-7D0C-49EB-B0BC-8DC63E33B9B8@comcast.net> References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> <0AF0B2D8-7D0C-49EB-B0BC-8DC63E33B9B8@comcast.net> Message-ID: On 2/18/19 9:02 PM, Paul Koning wrote: > > >> On Feb 18, 2019, at 8:18 PM, Bill Gunshannon via cctalk wrote: >> >> On 2/18/19 7:39 PM, Paul Koning wrote: >>> >>> ... >>> TU58, no -- that's not a file structured device on RSTS. RX33 is an RX50 in a different physical package if I remember -- 800 block MSCP device. That works fine, subject to the necessary tricks to get the files on the floppies and do the switching. >> >> No, RX50 was a strange DEC format. RX33 is a 1.2M floppy. > > Ok. That's may be big enough without volume switching, but in any case, if it speaks MSCP, RSTS will support it. (Well -- more precisely, if it speaks MSCP and have fewer than 2^23 blocks.) Works off of an RQDX3 or one of my Andromeda cards. Both MSCP. > >>> ... >>> You mean build an initial system on a small disk, and then load the rest onto a big disk some other way? Sure, that should work fine. >> >> I was thinking build a minimal system on a smaller disk and >> and then use it and backup to move the RA81 system to real >> hardware and then use that for playing with. > > Yes, that will be fine. If the disk is RL02-ish in size it will be ample for this purpose. Even something as small as an RK05 can probably be made to do a basic job. I have a couple of RD31's. They are 20M. I have one RD33 which is 71M. Only possible problem is the Micronotes claim it was never released by DEC so I may find it is not supported. But I will likely try the RD31 and see what happens. bill From imp at bsdimp.com Mon Feb 18 21:29:59 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 18 Feb 2019 20:29:59 -0700 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On Mon, Feb 18, 2019 at 6:18 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: > On 2/18/19 7:39 PM, Paul Koning wrote: > > TU58, no -- that's not a file structured device on RSTS. RX33 is an > RX50 in a different physical package if I remember -- 800 block MSCP > device. That works fine, subject to the necessary tricks to get the files > on the floppies and do the switching. > > No, RX50 was a strange DEC format. RX33 is a 1.2M floppy. > The RX50 was a single sided 800 block floppy. The first two tracks had no interleave. The rest has 2:1 interleave, though sometimes physical and other times logical. Strange in some ways, kinda standard in others. But it's still a floppy, and other than size, much like the RX33 with 1/3 the number of blocks. Warner From glen.slick at gmail.com Mon Feb 18 21:59:48 2019 From: glen.slick at gmail.com (Glen Slick) Date: Mon, 18 Feb 2019 19:59:48 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On Mon, Feb 18, 2019 at 5:18 PM Bill Gunshannon via cctalk wrote: > > Well, all I really have are CQD module which does MSCP and TMSCP > over SCSI. Do you have any SCSI tape drives? I have successfully installed RSTS/E 10.1 from install tapes on real PDP-11 hardware using an Exabyte EXB-8200 8mm tape drive attached to a CMD CQD-220/TM. The target hard drive for the installation was also attached to the CMD CQD-220/TM. That is always one route you could try. My guess is that the other posts about disk sizes being different is likely the issue. When I want to use a physical drive attached to Q-Bus SCSI controller to be the target of a copying a simulated disk, I usually try to verify that the MSCP block count for the physical drive is actually what I expect it to be. If I can attach the Q-Bus SCSI controller and drive to a MicroVAX system I can boot VMS and mount /foreign the drive and show dev /full the drive to get the block count. Or if the the Q-Bus SCSI controller and drive are attached to an 11/53, /73, /83 (or /93 if I had one of those) I can boot the 2.11BSD install tape and run the standalone disklabel program to display the reported MSCP geometry of the drive. The must be several other ways to display the MSCP reported geometry of a drive, those are just two that I have used myself in the past. From charles.unix.pro at gmail.com Mon Feb 18 22:22:30 2019 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Mon, 18 Feb 2019 20:22:30 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> Message-ID: On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: > On 2/18/19 4:35 PM, Paul Koning wrote: > > > It would be interesting if you can post the exact sizes in blocks of the > SIMH image, and the real disk you copied it to. That would help confirm my > guess that it's a size issue. > > If it's a size issue then one of them is doing it wrong because the > size of an RA81 constant. > > Looking at the SIMH code: /* type sec surf cyl tpg gpc RCT LBNs RA81 51(+1) 14 1258 14 1 2856 891072 */ #define RA81_SECT 51 /* +1 spare/track */ #define RA81_SURF 14 #define RA81_CYL 1258 /* 0-1247 user */ #define RA81_TPG RA81_SURF #define RA81_GPC 1 #define RA81_XBN 2436 /* cyl 1252-1254? */ #define RA81_DBN 2436 /* cyl 1255-1256? */ #define RA81_LBN 891072 /* 51*14*1248 */ #define RA81_RCTS 2856 /* cyl 1248-1251? */ #define RA81_RCTC 1 #define RA81_RBN 17472 /* 1 *14*1248 */ I am presuming that (without actually checking) that these are the numbers returned to RSTS when it queries the disk; if these numbers are different then the h/w, then that could be an issue. I am a bit curious about "+1 spare/track" - I wonder if the h/w reports 51 or 52? -- Charles From aperry at snowmoose.com Mon Feb 18 16:42:27 2019 From: aperry at snowmoose.com (Alan Perry) Date: Mon, 18 Feb 2019 14:42:27 -0800 Subject: RS/6000 7043-140 boot floppies In-Reply-To: References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: <62cd5d21-d821-60a8-b856-57ebd4f7eab2@snowmoose.com> On 2/18/19 1:55 PM, Tapley, Mark wrote: >> On Feb 18, 2019, at 11:49 AM, Alan Perry via cctech wrote: >> >> >> Is there some trick to making boot floppies for the RS/6000 7043-140 (a mid-90s PReP architecture machine)? >> >> I initially tried to install Solaris 2.5.1 on it and created the boot floppy by dd'ing the image using a SPARCstation (running NetBSD). I dd'ed the image over, dd'ed it back and verified the SPARCstation could read back what it had written to the floppy. The RS/6000 loads what is on the floppy, but hangs transferring control to what it loaded. >> >> The 7043-140 does not appear on the list of supported systems in the Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the 7043-140 is a PReP machine, maybe they aren't compatible, so I tried NetBSD. The 7043-140 is listed as a supported system. >> >> The NetBSD boot floppy images are confusing to me. The files are too large to fit on a 1.44M floppy. I didn't see instructions on how to make boot floppies out of the .fs files one can download in the install instructions. I went ahead and tried to dd the part that fits onto a 1.44M floppy and try to boot that and of course that failed. I have e-mailed the NetBSD prep mailing list and no response from that. >> >> The system does boot the AIX install on one of its hard disks, but this is a recycled system and I don't have usernames/passwords for that install. >> >> Does anyone here have a suggestion on how to proceed? >> >> alan >> >> CAUTION: This email originated from outside SwRI and it may contain attachments and/or links. Do not open attachments or click on links unless you recognize the sender and know the content is safe. > Alan, > does the machine also have a CD drive? I got a *lot* of help fast from this list last year while resetting root and user passwords on one of those machines by using the first CD of the AIX install set. I guess that won?t help toward solaris but at least you could run AIX. > - Mark > Yes, it has a CD drive. Do you recall what month the discussion was so I know where to start looking in the list archive? It sounds as if Solaris doesn't run on the 604e in the 43p/7043 (I will never understand IBM model designations); I just want to make the system usable at this point. alan From mtapley at swri.edu Mon Feb 18 18:03:47 2019 From: mtapley at swri.edu (Tapley, Mark) Date: Tue, 19 Feb 2019 00:03:47 +0000 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <62cd5d21-d821-60a8-b856-57ebd4f7eab2@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> <62cd5d21-d821-60a8-b856-57ebd4f7eab2@snowmoose.com> Message-ID: <893B273C-0855-4D61-99FC-46802480AF85@swri.edu> > On Feb 18, 2019, at 4:42 PM, Alan Perry wrote: > ? > Yes, it has a CD drive. Do you recall what month the discussion was so I know where to start looking in the list archive? > > It sounds as if Solaris doesn't run on the 604e in the 43p/7043 (I will never understand IBM model designations); I just want to make the system usable at this point. > > alan Alan, it was February last year (2018), probably Feb 1 - Feb. 3. The short story for how to do this is presented at: http://www-01.ibm.com/support/docview.wss?uid=isg3T1000366 I did need to obtain an IBMid to read the web page completely, and I started with a CD labelled ?AIX V4.2.1 for 5765-C34?. As you will see if you read the thread, subject "Password reset for ~1998 AIX on RS/6000??, other alternatives exist, but this was all I needed. Hope this helps! Let me know if you need any other pointers. - Mark From dkelvey at hotmail.com Mon Feb 18 22:00:53 2019 From: dkelvey at hotmail.com (dwight) Date: Tue, 19 Feb 2019 04:00:53 +0000 Subject: Q: Plotter bed repair with MonoKote? In-Reply-To: References: , Message-ID: I find that it is too much pre-stretched I carefully remove some of the stretch with a heat gun and a frame to hold it. You'd need to experiment some. It has to have a little stretch left to shrink. Dwight ________________________________ From: cctech on behalf of David Collins via cctech Sent: Monday, February 18, 2019 2:15 PM To: Craig Ruff; General Discussion: On-Topic Posts Subject: Re: Q: Plotter bed repair with MonoKote? Also very interested in the use of Monokote to repair plotter beds...any more info/experience/tips/traps would be much appreciated. David Collins HP Computer Museum > On 19 Feb 2019, at 5:37 am, Craig Ruff via cctech wrote: > > >> On Feb 18, 2019, at 11:00 AM, dwight wrote: >> >> There were a couple hp XY plotters that had the mylar plate delaminating. I've reworked these with model airplane mono coat. > > Are you referring to MonoKote (www.monokote.com )? That looks perfect for repairing the gouged bed of one of my 9872C plotters. Is a hot air supply suitable for applying the film, or did you use their heating iron? I'm guessing a bit of pressure to adhere the film is necessary? From tdk.knight at gmail.com Tue Feb 19 02:23:31 2019 From: tdk.knight at gmail.com (Adrian Stoness) Date: Tue, 19 Feb 2019 02:23:31 -0600 Subject: tracometer model 6a Message-ID: anyone ever herd of one? mines searial number 002 says national research councle of canada made by eda electronics https://imagizer.imageshack.com/img923/5723/Bnz2VF.jpg https://imagizer.imageshack.com/img924/6783/nHesKB.jpg https://imagizer.imageshack.com/img922/5776/wimiv2.jpg From lproven at gmail.com Tue Feb 19 05:10:58 2019 From: lproven at gmail.com (Liam Proven) Date: Tue, 19 Feb 2019 12:10:58 +0100 Subject: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <01R39I59B7C68WXLWI@beyondthepale.ie> Message-ID: On Mon, 18 Feb 2019 at 22:16, Fred Cisin via cctalk wrote: > > One of the moxt common causes of a terrible ear-piercing high whine is the > spindle contact. Many old drives had a springy piece that rubbed against > the end of the spindle. Over time, it would wear a divot, polish that, > and start to squeal. A very light pressure on it would test that > hypothesis. Not enough pressure to muffle the sound, and certaianly not > enough pressure to slow the spindle! Or, pulling up on it, away from the > spindle. Some people claimed that you could just rip it off. Don't. > Best is to twist it very slightly sideways, so that it can start wearing a > new divot. It was a 3?" EIDE drive. 8GB one, I think, but might have been smaller. I didn't want to open it to do that, although there was a time when custom PC builders "de-lidded" hard disks and fitted them with little acrylic windows so you could see the head move. Not sure I'd want to trust my data to that... > Well, there don't seem to be many 350 RAMAC disks still running. > > (I'm trying to decide what to use as a base to make a patio table out of a > [crashed] RAMAC 24" platter) Conceded. And thank you for the reminder that I'm not old yet. My first machine with a hard disk was my work PC in my first job: an IBM PC-AT, with a 20 MB FS/FH 5?" ST-506 drive, probably a Seagate ST-4026. I added a second drive to the machine, a 15 MB one, and put Xenix/286 on it. A few years ago I bought a surplus 2?" 1 TB drive from a chap who'd bought a new notebook and put an SSD in it before use. So, 2nd hand but unused. It cost me CzK 1000, about ?30 at the time. ?30 for a terabyte. I was in a state of shock. It was so tiny, too. I found an online capacity comparator thing. You'd need a pile of those Seagate drives the size of a _space shuttle_ to hold a terabyte. https://liam-on-linux.livejournal.com/53353.html -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From rp at servium.ch Tue Feb 19 05:09:26 2019 From: rp at servium.ch (Rico Pajarola) Date: Tue, 19 Feb 2019 12:09:26 +0100 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: On Mon, Feb 18, 2019 at 6:49 PM Alan Perry via cctech wrote: > > Is there some trick to making boot floppies for the RS/6000 7043-140 (a > mid-90s PReP architecture machine)? > > I initially tried to install Solaris 2.5.1 on it and created the boot > #wrong43p Solaris 2.5.1 PPC doesn't work on that machine. I can't find the HCL doc, but according to the files present on the CD it runs on: IBM 6040 (ThinkPad 820) IBM 6042 (ThinkPad 850) IBM 6015 (PowerSeries 440, 7020-40P) IBM 6050 (PowerSeries 830, 7248-43P) IBM 6070 (PowerSeries 850, 7248-43P) IBM 7248 (43P-100, 43P-120, 43P-132) Motorola PowerStack Series DT/E/MT The 7248-43P is substantially different from a 7043-140 "43P". I have it running on a PowerStack Series E. Did anyone ever unearth the Sun compiler for that? floppy by dd'ing the image using a SPARCstation (running NetBSD). I > dd'ed the image over, dd'ed it back and verified the SPARCstation could > read back what it had written to the floppy. The RS/6000 loads what is > on the floppy, but hangs transferring control to what it loaded. > > The 7043-140 does not appear on the list of supported systems in the > Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the > 7043-140 is a PReP machine, maybe they aren't compatible, so I tried > NetBSD. The 7043-140 is listed as a supported system. > > The NetBSD boot floppy images are confusing to me. The files are too > large to fit on a 1.44M floppy. I didn't see instructions on how to make > boot floppies out of the .fs files one can download in the install > instructions. I went ahead and tried to dd the part that fits onto a > 1.44M floppy and try to boot that and of course that failed. I have > e-mailed the NetBSD prep mailing list and no response from that. > > The system does boot the AIX install on one of its hard disks, but this > is a recycled system and I don't have usernames/passwords for that install. > > Does anyone here have a suggestion on how to proceed? > > alan > > From bill.gunshannon at hotmail.com Tue Feb 19 07:39:10 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Tue, 19 Feb 2019 13:39:10 +0000 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On 2/18/19 10:59 PM, Glen Slick via cctalk wrote: > On Mon, Feb 18, 2019 at 5:18 PM Bill Gunshannon via cctalk > wrote: >> >> Well, all I really have are CQD module which does MSCP and TMSCP >> over SCSI. > > Do you have any SCSI tape drives? Sure. I have a SCSI 9-track and a 1.4" QIC (TKZ-10) and even a SCSI TK50 if I ever get it fixed (but then we know how likely it is that any of the physical TK50 drives will actually work at this point in time!!) But all of these require TMSCP media and the only one I have ever seen (and actually have in my possession) is TK50. > I have successfully installed RSTS/E > 10.1 from install tapes on real PDP-11 hardware using an Exabyte > EXB-8200 8mm tape drive attached to a CMD CQD-220/TM. The target hard > drive for the installation was also attached to the CMD CQD-220/TM. > That is always one route you could try. Yes, if I could get a TMSCP Install Kit on a 9-track tape. :-) > > My guess is that the other posts about disk sizes being different is > likely the issue. When I want to use a physical drive attached to > Q-Bus SCSI controller to be the target of a copying a simulated disk, > I usually try to verify that the MSCP block count for the physical > drive is actually what I expect it to be. I guess I was naive. I used to work with real RA drives in the past and figured the emulations were at least accurate enough to know how big the disk was. It wasn't a secret. > > If I can attach the Q-Bus SCSI controller and drive to a MicroVAX > system I can boot VMS and mount /foreign the drive and show dev /full > the drive to get the block count. Or if the the Q-Bus SCSI controller > and drive are attached to an 11/53, /73, /83 (or /93 if I had one of > those) I can boot the 2.11BSD install tape and run the standalone > disklabel program to display the reported MSCP geometry of the drive. > The must be several other ways to display the MSCP reported geometry > of a drive, those are just two that I have used myself in the past. > All sounds like fun, but if the two emulations don't do RA81 correctly the information doesn't really do me much good. I certainly can't change the CQD's idea of what an RA81 is. I am sure once I successfully leap this hurdle the system will run RSTS nicely (I only wish I had the CIS option for one of my machines). Like I said earlier, good thing this is only a hobby. bill From paulkoning at comcast.net Tue Feb 19 08:24:02 2019 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 19 Feb 2019 09:24:02 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: > On Feb 18, 2019, at 10:29 PM, Warner Losh via cctalk wrote: > > On Mon, Feb 18, 2019 at 6:18 PM Bill Gunshannon via cctalk < > cctalk at classiccmp.org> wrote: > >> ... >> No, RX50 was a strange DEC format. RX33 is a 1.2M floppy. > > The RX50 was a single sided 800 block floppy. The first two tracks had no > interleave. The rest has 2:1 interleave, though sometimes physical and > other times logical. Strange in some ways, kinda standard in others. But > it's still a floppy, and other than size, much like the RX33 with 1/3 the > number of blocks. > > Warner That's not correct. RX50 is 80 track, single sided, 10 sectors per track (not the PC-standard 9 per track). All tracks are 2:1 interleaved. There is a 3 sector skew from track to track. And logical track 0 is physical track 1 (physical track 0 is logical track 79). The MSCP controller does this; on a Pro it's done in the driver. I've done it for RSTS, but it's easy to confirm by reading the source code of DEC drivers such as the one in RT-11. paul From paulkoning at comcast.net Tue Feb 19 08:27:53 2019 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 19 Feb 2019 09:27:53 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> Message-ID: <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> > On Feb 18, 2019, at 11:22 PM, Charles Anthony via cctalk wrote: > >> ... > Looking at the SIMH code: > > /* > type sec surf cyl tpg gpc RCT LBNs > RA81 51(+1) 14 1258 14 1 2856 891072 > */ > > #define RA81_SECT 51 /* +1 spare/track */ > #define RA81_SURF 14 > #define RA81_CYL 1258 /* 0-1247 user */ > #define RA81_TPG RA81_SURF > #define RA81_GPC 1 > #define RA81_XBN 2436 /* cyl 1252-1254? */ > #define RA81_DBN 2436 /* cyl 1255-1256? */ > #define RA81_LBN 891072 /* 51*14*1248 */ > #define RA81_RCTS 2856 /* cyl 1248-1251? */ > #define RA81_RCTC 1 > #define RA81_RBN 17472 /* 1 *14*1248 */ > > I am presuming that (without actually checking) that these are the numbers > returned to RSTS when it queries the disk; if these numbers are different > then the h/w, then that could be an issue. I am a bit curious about "+1 > spare/track" - I wonder if the h/w reports 51 or 52? > > -- Charles RSTS doesn't care about geometry, though MSCP does return something it calls geometry, for optimization purposes. All RSTS wants to know is the device size, in 512-byte blocks. Whatever the controller returns is what it uses. This is why in SIMH you can use "RAUSER" devices with MSCP, any size you like up to 8 megablocks. RSTS doesn't limit you to the sizes of the DEC MSCP products, and in fact you won't find any list of those model codes or any of their attributes in the RSTS sources. paul From imp at bsdimp.com Tue Feb 19 08:33:58 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 19 Feb 2019 07:33:58 -0700 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On Tue, Feb 19, 2019, 7:24 AM Paul Koning > > > On Feb 18, 2019, at 10:29 PM, Warner Losh via cctalk < > cctalk at classiccmp.org> wrote: > > > > On Mon, Feb 18, 2019 at 6:18 PM Bill Gunshannon via cctalk < > > cctalk at classiccmp.org> wrote: > > > >> ... > >> No, RX50 was a strange DEC format. RX33 is a 1.2M floppy. > > > > The RX50 was a single sided 800 block floppy. The first two tracks had no > > interleave. The rest has 2:1 interleave, though sometimes physical and > > other times logical. Strange in some ways, kinda standard in others. But > > it's still a floppy, and other than size, much like the RX33 with 1/3 the > > number of blocks. > > > > Warner > > That's not correct. > > RX50 is 80 track, single sided, 10 sectors per track (not the PC-standard > 9 per track). All tracks are 2:1 interleaved. There is a 3 sector skew > from track to track. And logical track 0 is physical track 1 (physical > track 0 is logical track 79). > The interleave is logical on the Rainbow. The drive is formatted to 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, however after track 2 they are logically interlaved by the drivers in Venix, Dos and CP/M. There is no skew there, except for Venix... And on the Rainbow, tracks are purely sequential... Guess that lead me astray for the pdp-11 users... The MSCP controller does this; on a Pro it's done in the driver. I've done > it for RSTS, but it's easy to confirm by reading the source code of DEC > drivers such as the one in RT-11. > I stand corrected. Yet another odd quirk of this quirky media. I recall from back in the day there are other DECmate quirks... Warner > From derek.newland at gmail.com Tue Feb 19 09:04:54 2019 From: derek.newland at gmail.com (Derek Newland) Date: Tue, 19 Feb 2019 10:04:54 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: There are many pictures on their Facebook page . Of particular interest, is this one of an IBM System/34 chassis: https://www.facebook.com/KemnerEnterprises/photos/a.1770653292985604/1768376576546609/ On Sat, Feb 16, 2019 at 1:52 PM Anders Nelson via cctalk < cctalk at classiccmp.org> wrote: > Hi everyone, > > I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay > them a visit. I'm taking pictures of as much vintage computing gear as I > can as we speak. I'll be here until they close today at 5pm EST, so if you > see something you like feel free to give them a call and I'll help them > navigate. > > Photos updated as I walk through, here: > > https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 > > If you see something you like it'd be great if you could check if I'm > interested first until I'm finished today. ;] > > Hope this helps someone, they shut down soon! > -- *Derek Newland* | (828) 234-4731 | derek.newland at gmail.com From jfoust at threedee.com Tue Feb 19 09:58:00 2019 From: jfoust at threedee.com (John Foust) Date: Tue, 19 Feb 2019 09:58:00 -0600 Subject: OT: Phone museum seeks new owner In-Reply-To: References: Message-ID: <20190219155812.7DE92274C3@mx1.ezwind.net> Old tech, but not computers: https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html - John From anders.k.nelson at gmail.com Tue Feb 19 10:01:01 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Tue, 19 Feb 2019 11:01:01 -0500 Subject: Kemners Surplus - Real time walkthrough In-Reply-To: References: Message-ID: Gone, I'm sorry to report! -- Anders Nelson +1 (517) 775-6129 www.erogear.com On Tue, Feb 19, 2019 at 10:05 AM Derek Newland wrote: > There are many pictures on their Facebook page > . Of particular > interest, is this one of an IBM System/34 chassis: > > https://www.facebook.com/KemnerEnterprises/photos/a.1770653292985604/1768376576546609/ > > On Sat, Feb 16, 2019 at 1:52 PM Anders Nelson via cctalk < > cctalk at classiccmp.org> wrote: > >> Hi everyone, >> >> I heard Kemners Surplus in Pottstown, PA was going away so I decided to >> pay >> them a visit. I'm taking pictures of as much vintage computing gear as I >> can as we speak. I'll be here until they close today at 5pm EST, so if you >> see something you like feel free to give them a call and I'll help them >> navigate. >> >> Photos updated as I walk through, here: >> >> https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8 >> >> If you see something you like it'd be great if you could check if I'm >> interested first until I'm finished today. ;] >> >> Hope this helps someone, they shut down soon! >> > > > -- > *Derek Newland* | (828) 234-4731 | derek.newland at gmail.com > From anders.k.nelson at gmail.com Tue Feb 19 10:48:54 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Tue, 19 Feb 2019 11:48:54 -0500 Subject: IBM 6360 - Filesystem(ish) info? Message-ID: Hi friends, Now that I have my glorious disk toaster (2D model I think, says "2D" on the drive levers), I want to build a controller for it. I found pinouts and some description of the media organization here: http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241-6248-3_Displaywriter_6360_6580_Product_Support_Manual_Feb1983.pdf I'd like to actually store data to these disks in the same manner the original systems did, and I'm proficient in hardware/firmware. Has anyone made a controller for this already? How about emulating the filesystem? Any help is appreciated, and I'd open-source whatever I make (PCBs, firmware, etc.). Thanks! -- Anders Nelson +1 (517) 775-6129 www.erogear.com From charles.unix.pro at gmail.com Tue Feb 19 10:51:28 2019 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Tue, 19 Feb 2019 08:51:28 -0800 Subject: PDP-11 disk image question In-Reply-To: <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> Message-ID: On Tue, Feb 19, 2019 at 6:27 AM Paul Koning wrote: > > > > On Feb 18, 2019, at 11:22 PM, Charles Anthony via cctalk < > cctalk at classiccmp.org> wrote: > > > >> ... > > Looking at the SIMH code: > > > > /* > > type sec surf cyl tpg gpc RCT LBNs > > RA81 51(+1) 14 1258 14 1 2856 891072 > > */ > > > > #define RA81_SECT 51 /* +1 > spare/track */ > > #define RA81_SURF 14 > > #define RA81_CYL 1258 /* 0-1247 user */ > > #define RA81_TPG RA81_SURF > > #define RA81_GPC 1 > > #define RA81_XBN 2436 /* cyl > 1252-1254? */ > > #define RA81_DBN 2436 /* cyl > 1255-1256? */ > > #define RA81_LBN 891072 /* 51*14*1248 */ > > #define RA81_RCTS 2856 /* cyl > 1248-1251? */ > > #define RA81_RCTC 1 > > #define RA81_RBN 17472 /* 1 *14*1248 */ > > > > I am presuming that (without actually checking) that these are the > numbers > > returned to RSTS when it queries the disk; if these numbers are different > > then the h/w, then that could be an issue. I am a bit curious about "+1 > > spare/track" - I wonder if the h/w reports 51 or 52? > > > > -- Charles > > RSTS doesn't care about geometry, though MSCP does return something it > calls geometry, for optimization purposes. All RSTS wants to know is the > device size, in 512-byte blocks. Whatever the controller returns is what > it uses. > > Presumably SIMH is returning RA81_LBN (891072) as the device size; this is calculated based on the 51 sectors/track. If the h/w is returning a size based on 52, then there is a mismatch which could be the source of the problem. It has been hypothesised that the original problem is related to SIMH misreporting the disk size; I was trying to point out a possible source of error; does anyone know what size the h/w reports? -- Charles From cctalk at beyondthepale.ie Tue Feb 19 09:59:50 2019 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Tue, 19 Feb 2019 16:59:50 +0100 (WET-DST) Subject: OT: Phone museum seeks new owner In-Reply-To: <20190219155812.7DE92274C3@mx1.ezwind.net> References: Message-ID: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> > > Old tech, but not computers: > > https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html > 451: Unavailable due to legal reasons We recognize you are attempting to access this website from a country belonging to the European Economic Area (EEA) including the EU which enforces the General Data Protection Regulation (GDPR) and therefore access cannot be granted at this time. For any issues, contact hostmaster at madison.com or call 800-362-8333. :-( Regards, Peter Coghlan. > > - John > From couryhouse at aol.com Tue Feb 19 11:16:38 2019 From: couryhouse at aol.com (ED SHARPE) Date: Tue, 19 Feb 2019 17:16:38 +0000 (UTC) Subject: OT: Phone museum seeks new owner References: <1349270734.1731392.1550596598185.ref@mail.yahoo.com> Message-ID: <1349270734.1731392.1550596598185@mail.yahoo.com> this guy? ?is? amazing....? ? In a message dated 2/19/2019 10:03:23 AM US Mountain Standard Time, cctalk at classiccmp.org writes: > Old tech, but not computers: > > https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html > From geneb at deltasoft.com Tue Feb 19 11:18:25 2019 From: geneb at deltasoft.com (geneb) Date: Tue, 19 Feb 2019 09:18:25 -0800 (PST) Subject: OT: Phone museum seeks new owner In-Reply-To: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> Message-ID: On Tue, 19 Feb 2019, Peter Coghlan via cctalk wrote: >> >> Old tech, but not computers: >> >> https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html >> > > 451: Unavailable due to legal reasons > We recognize you are attempting to access this website from a country belonging > to the European Economic Area (EEA) including the EU which enforces the General > Data Protection Regulation (GDPR) and therefore access cannot be granted at > this time. For any issues, contact hostmaster at madison.com or call 800-362-8333. > So basically, they're blocking EU users from a website due to a law that has no effect in the US? Amazing. 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_! From coryheisterkamp at gmail.com Tue Feb 19 11:20:37 2019 From: coryheisterkamp at gmail.com (Cory Heisterkamp) Date: Tue, 19 Feb 2019 11:20:37 -0600 Subject: OT: Phone museum seeks new owner In-Reply-To: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> References: <20190219155812.7DE92274C3@mx1.ezwind.net> <01R3ENAM0D4K8WVZAF@beyondthepale.ie> Message-ID: On Tue, Feb 19, 2019 at 11:03 AM Peter Coghlan via cctalk < cctalk at classiccmp.org> wrote: > > > > Old tech, but not computers: > > > > > https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html > > > > > Definitely something funky with the website. I ended up doing a quick select-all, copy to get the story before the page regenerated to 'lost connection' status. I bought some equipment from PhoneCo in person back in the 90s when antique phones were still holding their value and even then the experience was, to put it politely, a real mess. Crumbling buildings, piles upon piles of dusty, busted up surplus phones. Truckloads of equipment sitting out in the elements. Finding a buyer today will be a challenge, to say the least. -C From glen.slick at gmail.com Tue Feb 19 11:37:30 2019 From: glen.slick at gmail.com (Glen Slick) Date: Tue, 19 Feb 2019 09:37:30 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On Tue, Feb 19, 2019 at 5:39 AM Bill Gunshannon via cctalk wrote: > > All sounds like fun, but if the two emulations don't do RA81 > correctly the information doesn't really do me much good. I > certainly can't change the CQD's idea of what an RA81 is. > I have mostly used CMD CQD-220/TM controllers. As far as I remember they do not have an RA drive emulation option. I also have some of the newer CMD CQD-220A/E controllers (the 220A/E being Either MSCP or TMSCP but not both at the same time, while the 220A/TM can be both MSCP and TMSCP at the same time). I'll see if I can find some time today to take a look at the RA drive emulation option using a CMD CQD-220A/E controller, and see exactly what it reports for MSCP drive geometry. From paulkoning at comcast.net Tue Feb 19 12:14:18 2019 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 19 Feb 2019 13:14:18 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> Message-ID: <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> > On Feb 19, 2019, at 11:51 AM, Charles Anthony wrote: > > ... > Presumably SIMH is returning RA81_LBN (891072) as the device size; this is calculated based on the 51 sectors/track. If the h/w is returning a size based on 52, then there is a mismatch which could be the source of the problem. It has been hypothesised that the original problem is related to SIMH misreporting the disk size; I was trying to point out a possible source of error; does anyone know what size the h/w reports? > > -- Charles Some people here probably have an actual drive and can double check. Meanwhile, I found the "RA60, RA80, and RA81 disk drives" brochure (DEC, August 1982) on Archive.org. It has the details in the back. Page 36 shows "User data capacity" and says 51 sectors, 14 tracks, 1248 cylinders -- that works out to 891072 sectors which is the number SIMH uses. So indeed the correct sector count is 51 (the other one is a spare, a technique used by DEC as far back as the RM80). paul From anders.k.nelson at gmail.com Tue Feb 19 12:24:38 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Tue, 19 Feb 2019 13:24:38 -0500 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: <007601d4c87f$701c6d60$50554820$@net> References: <007601d4c87f$701c6d60$50554820$@net> Message-ID: Hi Ali, I'm planning on a USB controller, but I've seen ISA projects that are also microcontroller based so I think it wouldn't be awfully difficult to replace the USB data pipe with an ISA one. Zooming out, I have a list of USB controllers to build: - Kennedy 9800 tape drive - IBM 6360 8" floppy drive - IBM 5 1/4" floppy drive My friends think it's silly, and they're probably right. =P On Tue, Feb 19, 2019, 1:18 PM Ali > > > Now that I have my glorious disk toaster (2D model I think, says "2D" > > on > > the drive levers), I want to build a controller for it. I found pinouts > > and > > some description of the media organization here: > > > > http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241- > > 6248-3_Displaywriter_6360_6580_Product_Support_Manual_Feb1983.pdf > > Congratulations! Those are nice looking drives. The problem of course is > they don't work with anything "standard". > > > I'd like to actually store data to these disks in the same manner the > > original systems did, and I'm proficient in hardware/firmware. Has > > anyone > > made a controller for this already? How about emulating the filesystem? > > Wow. That is going to be big endeavor.... A question what is your target > system (i.e. are you planning on implementing this on a controller > connected to a modern system w/ USB or are you planning on a nice ISA card > so these drives can be used on older systems?) I wish I could help you > technically but my background is far removed from engineering... However, I > will follow with great interest specially if you go the ISA route... > > -Ali > > From spacewar at gmail.com Tue Feb 19 12:26:16 2019 From: spacewar at gmail.com (Eric Smith) Date: Tue, 19 Feb 2019 11:26:16 -0700 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: >From a rather cursory examination of the manual, it looks like they put the controller in the diskette unit itself ("Diskette Signal Cable", figure 8-22), so you should be able to hook it up to just about any microcontroller. It's probably a 765/8272 style controller. From anders.k.nelson at gmail.com Tue Feb 19 12:34:43 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Tue, 19 Feb 2019 13:34:43 -0500 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: Ok, are there command/response listings for these controllers, or one for this exact unit? On Tue, Feb 19, 2019, 1:29 PM Eric Smith From a rather cursory examination of the manual, it looks like they put > the controller in the diskette unit itself ("Diskette Signal Cable", figure > 8-22), so you should be able to hook it up to just about any > microcontroller. It's probably a 765/8272 style controller. > From cctalk at ibm51xx.net Tue Feb 19 12:49:32 2019 From: cctalk at ibm51xx.net (Ali) Date: Tue, 19 Feb 2019 10:49:32 -0800 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> Message-ID: <007d01d4c883$dad26700$90773500$@net> > I'm planning on a USB controller, but I've seen ISA projects that are > also > microcontroller based so I think it wouldn't be awfully difficult to > replace the USB data pipe with an ISA one. Well just because you don't have enough to do please plan on an ISA version as well ;) I think it really is time someone did a super floppy controller bringing together a number of older technology on to one easy to use card (e.g. 8" drive support, copy protection bypass, GCR reading) - all of this was available as separate products in the past... > My friends think it's silly, and they're probably right. =P Hey silly things can lead to great discoveries: https://gizmodo.com/scientists-produce-rigorous-study-of-why-grapes-spark-i-1832660386 -Ali > > On Tue, Feb 19, 2019, 1:18 PM Ali > > > > > > Now that I have my glorious disk toaster (2D model I think, says > "2D" > > > on > > > the drive levers), I want to build a controller for it. I found > pinouts > > > and > > > some description of the media organization here: > > > > > > http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241- > > > 6248-3_Displaywriter_6360_6580_Product_Support_Manual_Feb1983.pdf > > > > Congratulations! Those are nice looking drives. The problem of course > is > > they don't work with anything "standard". > > > > > I'd like to actually store data to these disks in the same manner > the > > > original systems did, and I'm proficient in hardware/firmware. Has > > > anyone > > > made a controller for this already? How about emulating the > filesystem? > > > > Wow. That is going to be big endeavor.... A question what is your > target > > system (i.e. are you planning on implementing this on a controller > > connected to a modern system w/ USB or are you planning on a nice ISA > card > > so these drives can be used on older systems?) I wish I could help > you > > technically but my background is far removed from engineering... > However, I > > will follow with great interest specially if you go the ISA route... > > > > -Ali > > > > From cclist at sydex.com Tue Feb 19 12:54:23 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 19 Feb 2019 10:54:23 -0800 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: On 2/19/19 8:48 AM, Anders Nelson via cctalk wrote: > Hi friends, > > Now that I have my glorious disk toaster (2D model I think, says "2D" on > the drive levers), I want to build a controller for it. I found pinouts and > some description of the media organization here: > > http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241-6248-3_Displaywriter_6360_6580_Product_Support_Manual_Feb1983.pdf > > I'd like to actually store data to these disks in the same manner the > original systems did, and I'm proficient in hardware/firmware. Has anyone > made a controller for this already? How about emulating the filesystem? > > Any help is appreciated, and I'd open-source whatever I make (PCBs, > firmware, etc.). Are you talking about the disk unit for the Displaywriter (6580)? Those don't use what you'd call a general-purpose filesystem in their native mode (although there was a version of CP/M 86). The DW filesystem is very specific to that word-processing application and probably not useful for general-purpose applications. And, of course, the character code used is EBCDIC. --Chuck From anders.k.nelson at gmail.com Tue Feb 19 13:11:06 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Tue, 19 Feb 2019 14:11:06 -0500 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: Ali - you bet I will! =P Chuck - thanks for the notes. I have no idea what it actually came from but I imagine it did come with a Display writer system. No problem with the format in which the data is stored, I can always present a more reasonable storage interface to the user via FTP or something. EBCDIC conversion or simply writing arbitrary bits is fine with me. On Tue, Feb 19, 2019, 1:54 PM Chuck Guzis via cctalk On 2/19/19 8:48 AM, Anders Nelson via cctalk wrote: > > Hi friends, > > > > Now that I have my glorious disk toaster (2D model I think, says "2D" on > > the drive levers), I want to build a controller for it. I found pinouts > and > > some description of the media organization here: > > > > > http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241-6248-3_Displaywriter_6360_6580_Product_Support_Manual_Feb1983.pdf > > > > I'd like to actually store data to these disks in the same manner the > > original systems did, and I'm proficient in hardware/firmware. Has anyone > > made a controller for this already? How about emulating the filesystem? > > > > Any help is appreciated, and I'd open-source whatever I make (PCBs, > > firmware, etc.). > > Are you talking about the disk unit for the Displaywriter (6580)? > > Those don't use what you'd call a general-purpose filesystem in their > native mode (although there was a version of CP/M 86). The DW > filesystem is very specific to that word-processing application and > probably not useful for general-purpose applications. And, of course, > the character code used is EBCDIC. > > --Chuck > > > From anders.k.nelson at gmail.com Tue Feb 19 13:12:03 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Tue, 19 Feb 2019 14:12:03 -0500 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: Hi again, Is there a description of the DW filesystem somewhere I can look at? On Tue, Feb 19, 2019, 2:11 PM Anders Nelson Ali - you bet I will! =P > > Chuck - thanks for the notes. I have no idea what it actually came from > but I imagine it did come with a Display writer system. No problem with the > format in which the data is stored, I can always present a more reasonable > storage interface to the user via FTP or something. EBCDIC conversion or > simply writing arbitrary bits is fine with me. > > > On Tue, Feb 19, 2019, 1:54 PM Chuck Guzis via cctalk < > cctalk at classiccmp.org wrote: > >> On 2/19/19 8:48 AM, Anders Nelson via cctalk wrote: >> > Hi friends, >> > >> > Now that I have my glorious disk toaster (2D model I think, says "2D" on >> > the drive levers), I want to build a controller for it. I found pinouts >> and >> > some description of the media organization here: >> > >> > >> http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241-6248-3_Displaywriter_6360_6580_Product_Support_Manual_Feb1983.pdf >> > >> > I'd like to actually store data to these disks in the same manner the >> > original systems did, and I'm proficient in hardware/firmware. Has >> anyone >> > made a controller for this already? How about emulating the filesystem? >> > >> > Any help is appreciated, and I'd open-source whatever I make (PCBs, >> > firmware, etc.). >> >> Are you talking about the disk unit for the Displaywriter (6580)? >> >> Those don't use what you'd call a general-purpose filesystem in their >> native mode (although there was a version of CP/M 86). The DW >> filesystem is very specific to that word-processing application and >> probably not useful for general-purpose applications. And, of course, >> the character code used is EBCDIC. >> >> --Chuck >> >> >> From bill.gunshannon at hotmail.com Tue Feb 19 13:22:13 2019 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Tue, 19 Feb 2019 19:22:13 +0000 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On 2/19/19 12:37 PM, Glen Slick via cctalk wrote: > On Tue, Feb 19, 2019 at 5:39 AM Bill Gunshannon via cctalk > wrote: >> >> All sounds like fun, but if the two emulations don't do RA81 >> correctly the information doesn't really do me much good. I >> certainly can't change the CQD's idea of what an RA81 is. >> > > I have mostly used CMD CQD-220/TM controllers. As far as I remember > they do not have an RA drive emulation option. I have a 220A/TM and it certainly does. Pages 4-10 thru 4-15 of the manual, particularly Configuration Options "A" and "1". > > I also have some of the newer CMD CQD-220A/E controllers (the 220A/E > being Either MSCP or TMSCP but not both at the same time, while the > 220A/TM can be both MSCP and TMSCP at the same time). I'll see if I > can find some time today to take a look at the RA drive emulation > option using a CMD CQD-220A/E controller, and see exactly what it > reports for MSCP drive geometry. > Not familiar with the 220A/E it's not mentioned in my manual. Probably a much newer version. bill From cctalk at gtaylor.tnetconsulting.net Tue Feb 19 13:42:18 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 19 Feb 2019 12:42:18 -0700 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> Message-ID: <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> On 02/19/2019 10:18 AM, geneb via cctalk wrote: > So basically, they're blocking EU users from a website due to a law that > has no effect in the US?? Amazing. I thought I had heard from a number of people that GDPR could still bite people in other countries. I don't remember the how, just that it could be done. -- Grant. . . . unix || die From anders.k.nelson at gmail.com Tue Feb 19 14:05:56 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Tue, 19 Feb 2019 15:05:56 -0500 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: <4da25297-f430-550b-5b58-61e9a5a96dde@sydex.com> References: <4da25297-f430-550b-5b58-61e9a5a96dde@sydex.com> Message-ID: Ah, cool thanks! I'm interested in storing arbitrary files in the manner close to the original as possible. Sounds like the extent list and allocation map would be useful for this; not so much the document content format. -- Anders Nelson +1 (517) 775-6129 www.erogear.com On Tue, Feb 19, 2019 at 2:44 PM Chuck Guzis wrote: > On 2/19/19 11:12 AM, Anders Nelson wrote: > > Hi again, > > > > Is there a description of the DW filesystem somewhere I can look at? > > Hi Anders, > > Not that I'm aware of, unless Al has some document squirreled away that > we don't know about. > > What I know is from a lot of examining DW floppies and trying to > reverse-engineer it--and what little I could find on the web. > > The DW filesystem is basically a linked-list sort of structure. There's > a volume header block that contains an extent list and allocation map, > from which documents are treed from. Each document, in turn, links to > other entries that describe various properties of each document. For > example, the dates of the document, its name, the list of positions of > lines within the document, the document text, the formatting information > for the text, and so on. It's pretty complicated. > > One aside is that even though the DW is an 8086 system, numeric > quantities are big-endian. > > --Chuck > > From Kevin at RawFedDogs.net Tue Feb 19 14:07:51 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Tue, 19 Feb 2019 14:07:51 -0600 Subject: OT: Phone museum seeks new owner In-Reply-To: <20190219155812.7DE92274C3@mx1.ezwind.net> References: <20190219155812.7DE92274C3@mx1.ezwind.net> Message-ID: <20190219200751.GA20267@RawFedDogs.net> On Tue, Feb 19, 2019 at 09:58:00AM -0600, John Foust via cctalk wrote: > Old tech, but not computers: > > https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html Interesting, but what does it have to do with Kemners Surplus? -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From geneb at deltasoft.com Tue Feb 19 14:17:22 2019 From: geneb at deltasoft.com (geneb) Date: Tue, 19 Feb 2019 12:17:22 -0800 (PST) Subject: OT: Phone museum seeks new owner In-Reply-To: <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> Message-ID: On Tue, 19 Feb 2019, Grant Taylor via cctalk wrote: > On 02/19/2019 10:18 AM, geneb via cctalk wrote: >> So basically, they're blocking EU users from a website due to a law that >> has no effect in the US?? Amazing. > > I thought I had heard from a number of people that GDPR could still bite > people in other countries. I don't remember the how, just that it could be > done. I'd be very interested in how that would be possible. 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_! From cclist at sydex.com Tue Feb 19 14:18:12 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 19 Feb 2019 12:18:12 -0800 Subject: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <4da25297-f430-550b-5b58-61e9a5a96dde@sydex.com> Message-ID: <97f72268-3265-2818-b586-38a060e47ede@sydex.com> On 2/19/19 12:05 PM, Anders Nelson via cctalk wrote: > Ah, cool thanks! > > I'm interested in storing arbitrary files in the manner close to the > original as possible. Sounds like the extent list and allocation map would > be useful for this; not so much the document content format. > -- > Anders Nelson Hi Anders, No, it's more complicated than that--there are a lot of structures involved. I'm certain that the 6580 had a way to store executable files, for example, but I've never run into a sample. You may be better off adapting the CP/M-86 code form the 6580. --Chuck From robert626001 at gmail.com Tue Feb 19 14:36:58 2019 From: robert626001 at gmail.com (Robert) Date: Tue, 19 Feb 2019 14:36:58 -0600 Subject: Free: 2x DEC Alpha workstations - 164LX and XP1000 In-Reply-To: References: Message-ID: Hi Arun If the DEC Alpha workstations are still available I may be able to take them, thanks. I live in Amarillo but have a brother in law who lives in San Marcos and works in Austin - I'm sure that he's be willing to pick them up for me and hold them until I'm next down that way. Let me know, please. Thanks Robert On Mon, Feb 18, 2019 at 11:27 AM K. Arun via cctalk wrote: > > Hello, > > I have a couple of Alpha workstations that were last used 5-6 years ago > with some version of Tru64 on them. They haven't been turned on since, and > may need some work to get running again. They're free to anyone who thinks > they can use them, and can pick them up from the 78722 zip code (near UT > Austin). Please contact me off-list to co-ordinate pickup. > > Thanks, > > Arun From Kevin at RawFedDogs.net Tue Feb 19 14:57:18 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Tue, 19 Feb 2019 14:57:18 -0600 Subject: OT: Phone museum seeks new owner In-Reply-To: <20190219155812.7DE92274C3@mx1.ezwind.net> References: <20190219155812.7DE92274C3@mx1.ezwind.net> Message-ID: <20190219205718.GA10806@RawFedDogs.net> On Tue, Feb 19, 2019 at 09:58:00AM -0600, John Foust via cctalk wrote: > Old tech, but not computers: I have a fondness for old rotary dial phones, especially ones like they used in movies and TV shows set in the '40s and '50s. I've never managed to acquire one. I'd love to have a few of them, but not that many. :-) -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From cisin at xenosoft.com Tue Feb 19 15:00:19 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 13:00:19 -0800 (PST) Subject: HDDs (Was: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <01R39I59B7C68WXLWI@beyondthepale.ie> Message-ID: >> One of the moxt common causes of a terrible ear-piercing high whine is the >> spindle contact. Many old drives had a springy piece that rubbed against >> the end of the spindle. Over time, it would wear a divot, polish that, >> and start to squeal. A very light pressure on it would test that >> hypothesis. Not enough pressure to muffle the sound, and certaianly not >> enough pressure to slow the spindle! Or, pulling up on it, away from the >> spindle. Some people claimed that you could just rip it off. Don't. >> Best is to twist it very slightly sideways, so that it can start wearing a >> new divot. On Tue, 19 Feb 2019, Liam Proven via cctalk wrote: > It was a 3?" EIDE drive. 8GB one, I think, but might have been > smaller. I didn't want to open it to do that, although there was a > time when custom PC builders "de-lidded" hard disks and fitted them > with little acrylic windows so you could see the head move. Not sure > I'd want to trust my data to that... Yes. I was thinking in terms of slightly older drives than that, particularly 5.25" Getting at the slider on newer drives wouldn't be practical. >> Well, there don't seem to be many 350 RAMAC disks still running. >> (I'm trying to decide what to use as a base to make a patio table out of a >> [crashed] RAMAC 24" platter) > Conceded. > And thank you for the reminder that I'm not old yet. The RAMAC came out in 1956? The platters are 24" diameter. Each platter was almost 100K! But, with 50 platters, it maxed out at almost 5MB. When Nikita Khruschev made a peace mission to USA, they took him on a tour of the RAMAC facility. But, they wouldn't let him go to DisneyLand! (THAT had repercussions in the Cuban missile crisis) > My first machine with a hard disk was my work PC in my first job: an > IBM PC-AT, with a 20 MB FS/FH 5?" ST-506 drive, probably a Seagate > ST-4026. I added a second drive to the machine, a 15 MB one, and put > Xenix/286 on it. You could run Xenix on an XT! The stock IBM XT HDD controller (Xebec) had physical solder pads for drive type, and supported 5MB, 10MB, 15MB, and 25MB drives. The 25 was, of course, best (if you could get one) and would permit a 10MB DOS partition dual booting with 15MB Xenix. Was that the first "dual boot" in the PC world? (or was there a CP/M-86 dual boot option once they added HDD support?) > A few years ago I bought a surplus 2?" 1 TB drive from a chap who'd > bought a new notebook and put an SSD in it before use. So, 2nd hand > but unused. > It cost me CzK 1000, about ?30 at the time. > ?30 for a terabyte. I was in a state of shock. It was so tiny, too. > I found an online capacity comparator thing. I used a lot of ST4096 drives. Needed a second AT power supply for the second one. > You'd need a pile of those Seagate drives the size of a _space > shuttle_ to hold a terabyte. > https://liam-on-linux.livejournal.com/53353.html I use 2TB 2.5" 7.5mm Seagate/Samsung drives for MP4s of movies in laptops and with a Seagate GoFlex-TV (media streamer with SATA slot) But, I finally filled 2TB Currently, that is the largest 7.5mm 2.5" drive available. But SSDs are now available in 2TB, so when that price comes down, . . . Heard about the NSA Utah Data Center? https://nsa.gov1.info/utah-data-center/ That's a LottaBytes! -- Grumpy Ol' Fred cisin at xenosoft.com From cisin at xenosoft.com Tue Feb 19 15:11:12 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 13:11:12 -0800 (PST) Subject: OT: Phone museum seeks new owner In-Reply-To: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> Message-ID: >> Old tech, but not computers: >> https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html On Tue, 19 Feb 2019, Peter Coghlan via cctalk wrote: > 451: Unavailable due to legal reasons > We recognize you are attempting to access this website from a country We must prevent advanced rotary dial technology from falling into the wrong hands! From geneb at deltasoft.com Tue Feb 19 15:14:14 2019 From: geneb at deltasoft.com (geneb) Date: Tue, 19 Feb 2019 13:14:14 -0800 (PST) Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> Message-ID: On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote: >>> Old tech, but not computers: >>> https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html > > On Tue, 19 Feb 2019, Peter Coghlan via cctalk wrote: >> 451: Unavailable due to legal reasons >> We recognize you are attempting to access this website from a country > > We must prevent advanced rotary dial technology from falling into the wrong > hands! This message brought to you by the Totalitarian Touch Tone Terrorists(tm). 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_! From glen.slick at gmail.com Tue Feb 19 15:14:04 2019 From: glen.slick at gmail.com (Glen Slick) Date: Tue, 19 Feb 2019 13:14:04 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <41FE2B84-62EB-4704-B957-16B2B304DFFE@comcast.net> Message-ID: On Tue, Feb 19, 2019 at 11:22 AM Bill Gunshannon via cctalk wrote: > > > I have mostly used CMD CQD-220/TM controllers. As far as I remember > > they do not have an RA drive emulation option. > > I have a 220A/TM and it certainly does. Pages 4-10 thru 4-15 > of the manual, particularly Configuration Options "A" and "1". > Not familiar with the 220A/E it's not mentioned in my manual. > Probably a much newer version. What version of the CQD-220A manual do you have? Do you only have a hard copy, or do you have a scan of the manual? If you have a scan of the manual it would be great to get a copy of it. Currently there isn't any version of a CQD-220A manual on Bitsavers. I have a scan of the MAN-00220A-000, Rev. 1.1, December 17, 1993 version of the CQD-220A/223A manual. The RA drive emulation option must be newer than 1993 as I don't see it in the version of the manual I have. Also, there are two main versions of the CQD-220, the original CQD-220, and the newer redesigned CQD-220A version. The 'A' suffix is an important difference. Each main version has minor versions, which are are PAL and firmware differences. The original CQD-220 has 220/M (MSCP only), 220/T (TMSCP only), and 220/TM (both MSCP and TMSCP at the same time) versions. The 220/M and 220/T versions can be converted into a 220/TM version by replacing the CSR decode PAL and the firmware EPROMs. I know this can be done because I have done it several times myself. This original version is all through hole, except for the 53C90A SCSI controller in a PLCC package. The firmware is contained in two 27C256 EPROMs. The newer CQD-220A has 220A/TM (both MSCP and TMSCP at the same time) and 220A/M/T (either MSCP or TMSCP, but not both at the same time) versions. The boards that I have with CQD-220A/E stickers on them must be the same thing as a CQD-220A/M/T. This newer redesigned version is roughly half through hole, and half surface mount, including a large CMD ASIC. The firmware is contained in two 27C512 EPROMs. I just looked at the CQD-220/TM firmware images that I have. I must have the B2A 06/24/94 version installed on my boards. In that version I don't see any RA strings in the firmware image. In the B3 09/23/94 version I do see RA strings. CQD-220/TM B3 Firmware 09/23/94: "List of all supported device media type 0. Default value 1. RA 70 2. RA 80 3. RA 81 4. RA 82 5. RA 90 6. RA 92 7. RC 25" I'll have to try the B3 Firmware 09/23/94 version on my CQD-220/TM boards. Anyway, I'll still try to find time to see exactly what MSCP drive geometry a CQD-220A reports when configured for RA drive emulation. From Kevin at RawFedDogs.net Tue Feb 19 15:47:36 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Tue, 19 Feb 2019 15:47:36 -0600 Subject: Free: 2x DEC Alpha workstations - 164LX and XP1000 In-Reply-To: References: Message-ID: <20190219214736.GA3256@RawFedDogs.net> Arun, On Mon, Feb 18, 2019 at 11:26:41AM -0600, K. Arun via cctalk wrote: > I have a couple of Alpha workstations that were last used 5-6 years ago > with some version of Tru64 on them. They haven't been turned on since, and > may need some work to get running again. They're free to anyone who thinks > they can use them, and can pick them up from the 78722 zip code (near UT > Austin). Please contact me off-list to co-ordinate pickup. I sent you an off-list reply, but thought I'd mention it here in case the off-list reply doesn't reach you. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From cisin at xenosoft.com Tue Feb 19 16:02:22 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 14:02:22 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: <007d01d4c883$dad26700$90773500$@net> References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> Message-ID: >> I'm planning on a USB controller, but I've seen ISA projects that are >> also microcontroller based so I think it wouldn't be awfully difficult >> to replace the USB data pipe with an ISA one. On Tue, 19 Feb 2019, Ali via cctalk wrote: > Well just because you don't have enough to do please plan on an ISA > version as well ;) I think it really is time someone did a super floppy > controller bringing together a number of older technology on to one easy > to use card (e.g. 8" drive support, copy protection bypass, GCR reading) > - all of this was available as separate products in the past... What I would like to see, coming at it from a high level software viewpoint, would be: Complete and accurate emulation of 765. Including ROM or being loadable into RAM (TSR) and repoint the Int13h vector. That would permit it to fully replace the stock 765. Include a switchable "quirks" mode for full compatability with 765 "features", such as "flash blindness" after index pulse, switchable inability to handle 128 byte sectors, etc. 8" and FM and 128 byte sector support (obviously) 125kbps (5.25" FM), 250Kbps, 500Kbps, 1000Kbps (2.8M) Ability to read MFM data with FM headers (RX50) Added commands accessible through the [replacement] Int13h: Track read, modeled after the WD track read (that could also provide access to Amiga, with additional code for sectors and filesystem) RAW track read (flux transition), with and without data/clock synchronization. Hard sector, GCR, copy protection cloning, etc. could be handled by other code that calls that function in the [replacement] Int13h. Optionally: drivers for "modern" OS, inverted data reversal, EBCDIC/ASCII conversion Installable File System (IFS) to permit mounting alien disks, including: Apple2 ProDos/SOS Apple CP/M Apple P-System Mac 400K/800K Commodore Sirius/Victor 9000 CP/M (partial list available at http://www.xenosoft.com/fmts.html) P-System Amiga Northstar N-DOS TRS-DOS and derivatives (list available on request) Coco-DOS Microsoft Stand-Alone BASIC (NEC, Oki, etc.) Unix/Linux file systems If it also does HDDs, . . . >> My friends think it's silly, and they're probably right. =P -- Grumpy Ol' Fred cisin at xenosoft.com From dkelvey at hotmail.com Tue Feb 19 16:31:28 2019 From: dkelvey at hotmail.com (dwight) Date: Tue, 19 Feb 2019 22:31:28 +0000 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net>, Message-ID: Actually, I'd like to see it just read/write flux changes + index marks onto a SD card for later analysis. Building all the smarts into the controller means that some formats will get missed. One can later write translation code for what ever format one has. Make this information open source, much of it is already in bits and pieces. Make sure it can read and buffer an entire track of data in RAM ( Gotek can't ). We no longer need proprietary hardware. There are a number of off the shelf controller boards capable of handing this. It would only need cables to match the drive. Dwight ________________________________ From: cctalk on behalf of Fred Cisin via cctalk Sent: Tuesday, February 19, 2019 2:02 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? >> I'm planning on a USB controller, but I've seen ISA projects that are >> also microcontroller based so I think it wouldn't be awfully difficult >> to replace the USB data pipe with an ISA one. On Tue, 19 Feb 2019, Ali via cctalk wrote: > Well just because you don't have enough to do please plan on an ISA > version as well ;) I think it really is time someone did a super floppy > controller bringing together a number of older technology on to one easy > to use card (e.g. 8" drive support, copy protection bypass, GCR reading) > - all of this was available as separate products in the past... What I would like to see, coming at it from a high level software viewpoint, would be: Complete and accurate emulation of 765. Including ROM or being loadable into RAM (TSR) and repoint the Int13h vector. That would permit it to fully replace the stock 765. Include a switchable "quirks" mode for full compatability with 765 "features", such as "flash blindness" after index pulse, switchable inability to handle 128 byte sectors, etc. 8" and FM and 128 byte sector support (obviously) 125kbps (5.25" FM), 250Kbps, 500Kbps, 1000Kbps (2.8M) Ability to read MFM data with FM headers (RX50) Added commands accessible through the [replacement] Int13h: Track read, modeled after the WD track read (that could also provide access to Amiga, with additional code for sectors and filesystem) RAW track read (flux transition), with and without data/clock synchronization. Hard sector, GCR, copy protection cloning, etc. could be handled by other code that calls that function in the [replacement] Int13h. Optionally: drivers for "modern" OS, inverted data reversal, EBCDIC/ASCII conversion Installable File System (IFS) to permit mounting alien disks, including: Apple2 ProDos/SOS Apple CP/M Apple P-System Mac 400K/800K Commodore Sirius/Victor 9000 CP/M (partial list available at http://www.xenosoft.com/fmts.html) P-System Amiga Northstar N-DOS TRS-DOS and derivatives (list available on request) Coco-DOS Microsoft Stand-Alone BASIC (NEC, Oki, etc.) Unix/Linux file systems If it also does HDDs, . . . >> My friends think it's silly, and they're probably right. =P -- Grumpy Ol' Fred cisin at xenosoft.com From cclist at sydex.com Tue Feb 19 16:38:38 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 19 Feb 2019 14:38:38 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> Message-ID: <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote: > Ability to read MFM data with FM headers (RX50) It's not that simple. There's the matter of "DEC MFM" which encodes a few bit patterns differently to avoid collision with FM headers. --Chuck From cctalk at ibm51xx.net Tue Feb 19 17:09:45 2019 From: cctalk at ibm51xx.net (Ali) Date: Tue, 19 Feb 2019 15:09:45 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? Message-ID: Fred, Are we being a little sarcastic or serious? :)Honestly, a sw implementation would be interesting but would it work on vintage hw? Or are you suggesting for use only with a modern system??For example here is my dilemma: my stinkers, whom you have met, are getting old enough to want to mess with my stuff. *shudder* i mean cool! but I really don't want them ruining my one actual original disk for any programs I own. So what I do is make backup copies just like in the old days. And before someone suggests emulators, it is just not the same. I mean if we wanted to emulate everything why bother even preserving hardware?Problem is when we have copy protection, as many games or old SW do, then you need a Copy II PC board. I have one and they are fairly common but ridiculously expensive now a days. So it would be nice if the functions could be duplicated in an easy to use manner. Kyro Flux is powerful but not for everyone. I want an FDC that would cover 90% of the vintage hobby (i.e. Apple II, Mac, and IBM). An FDC that combines a CompatiCard IV with a copy ii pc deluxe and a Match Point card would cover all of the above plus then some.Just a thought.... ;D From cctalk at gtaylor.tnetconsulting.net Tue Feb 19 17:26:12 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 19 Feb 2019 16:26:12 -0700 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> Message-ID: <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> On 02/19/2019 01:17 PM, geneb via cctalk wrote: > I'd be very interested in how that would be possible. I don't know. But I do know that there are a lot of companies here in the US that are filtering their website like this. -- Grant. . . . unix || die From wh.sudbrink at verizon.net Tue Feb 19 17:40:10 2019 From: wh.sudbrink at verizon.net (William Sudbrink) Date: Tue, 19 Feb 2019 18:40:10 -0500 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> A design that can manage Ohio Scientific as well would be nice. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From cctalk at ibm51xx.net Tue Feb 19 17:44:18 2019 From: cctalk at ibm51xx.net (Ali) Date: Tue, 19 Feb 2019 15:44:18 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net>, Message-ID: <009001d4c8ad$084ba6a0$18e2f3e0$@net> > Actually, I'd like to see it just read/write flux changes + index > marks onto a SD card for later analysis ... > We no longer need proprietary hardware. Well some of us might not and then there is the rest of us who just need a tool that kind of works. I guess the question is "who is your audience"? If your audience is the general vintage hobbyist (i.e. someone who used IBM or Apples 20 years ago and wants to mess with the same equipment) then they are not developing their own HW, cables, or writing ASM routines (BTW I count myself in this group). Don't get me wrong I would love to be able to do so but realistically I will never have the raw knowledgebase and the experience required to do something like that. For someone like me I need a tool that works with some fuss i.e. it is not polished and needs tweaking, handholding, and prayer to work but does not need me to also learn Sumerian or assembler (same difference ;) to make a backup copy of a disk. That maybe asking too much though given that this is a hobby.... From cisin at xenosoft.com Tue Feb 19 17:56:26 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 15:56:26 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> Message-ID: >> Ability to read MFM data with FM headers (RX50) On Tue, 19 Feb 2019, Chuck Guzis via cctalk wrote: > It's not that simple. There's the matter of "DEC MFM" which encodes a > few bit patterns differently to avoid collision with FM headers. Which is presumably a matter of appropriate code for analysis of the raw flux transition data. From aek at bitsavers.org Tue Feb 19 18:12:23 2019 From: aek at bitsavers.org (Al Kossow) Date: Tue, 19 Feb 2019 16:12:23 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> Message-ID: <6db0eb36-0cf4-3c5f-d552-5f884b25a9c1@bitsavers.org> On 2/19/19 2:31 PM, dwight via cctalk wrote: > Actually, I'd like to see it just read/write flux changes + index marks onto a SD card for later analysis. You want to do the analysis at the time of capture, in case you need to re-read the media, or wiggle the head to try to push off a bit of gunk, or micro step it for off-track errors. ie. you need to know if what you capture is meaningful. From cisin at xenosoft.com Tue Feb 19 18:25:08 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 16:25:08 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net>, Message-ID: On Tue, 19 Feb 2019, dwight wrote: > Actually, I'd like to see it just read/write flux changes + index marks > onto a SD card for later analysis. Building all the smarts into the > controller means that some formats will get missed. One can later write > translation code for what ever format one has. Make this information > open source, much of it is already in bits and pieces. Make sure it can > read and buffer an entire track of data in RAM ( Gotek can't ). As I see it, flux transition hardware COULD be all that is needed for hardware. Emulation of FDC could be done in software with flux transition hardware. First stage would be with minimal software, to save the track flux transitions in a file. Next stage, If and when a 765 FDC can be emulated. THEN, make the FDC emulation code loadable into RAM, and repoint the Int13h vector to it. (TSR) THEN, make new version that adds TRACK-READ (ala WD, NOT the multi-sector read in the 765) Then fine details, such as whether or not to implement (switchable) index pulse "flash blindness", inability to handle 128 byte sectors, etc. OR, that much could be done without full flux transition functions. But, if you DO retain full access to the flux transition data, THEN, add GCR decoding, and add that into the FDC emulation (so that Int13h/fn2 could read GCR sectors, etc.) THEN, add hard sector handling THEN create IFS (Installable File System), which is totally not connected with any of this, except when needed for non 765 compatible physical formats. That is what XenoCopy would have eventually become, IFF I were to have been able to continue. (Uniform did implement most of an installable file system for CP/M formats) The end-user wants to load their Epson QX-10 documents and Kaypro CP/M documents into Word. They don't want to know how it is done, nor go through the essential steps of reading alien sectors, processing alien file system to select appropriate sectors, AND convert word processor formatting codes from one word processor to another. Do you think that you could teach them how? XenoCopy transferred FILES; but left the content alone. So, YES, I did get people telling me that XenoCopy had "trashed the last letter of every word in the Wordstar files" I drew the line between transferring files V modification of the content of the files. You are drawing the line between flux transition data V sectors/file system/files/content -- Grumpy Ol' Fred cisin at xenosoft.com From guykd at optusnet.com.au Tue Feb 19 18:31:27 2019 From: guykd at optusnet.com.au (Guy Dunphy) Date: Wed, 20 Feb 2019 11:31:27 +1100 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <01R3ENAM0D4K8WVZAF@beyondthepale.ie> Message-ID: <3.0.6.32.20190220113127.011c9e58@mail.optusnet.com.au> At 01:11 PM 19/02/2019 -0800, you wrote: >>> Old tech, but not computers: >>> https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html > >On Tue, 19 Feb 2019, Peter Coghlan via cctalk wrote: >> 451: Unavailable due to legal reasons >> We recognize you are attempting to access this website from a country > >We must prevent advanced rotary dial technology from falling into the >wrong hands! Amusing, but that isn't anything close to what it's about. >451: Unavailable due to legal reasons >We recognize you are attempting to access this website from a country belonging >to the European Economic Area (EEA) including the EU which enforces the General >Data Protection Regulation (GDPR) and therefore access cannot be granted at >this time. For any issues, contact hostmaster at madison.com or call 800-362-8333. The EU's GDPR is supposed to be about 'protecting personal data privacy', but seems more like another Globalist attempt to cripple the Internet by imposing unreasonable and near-impossible to comply with regulations. Guy From cclist at sydex.com Tue Feb 19 18:39:08 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 19 Feb 2019 16:39:08 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> References: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> Message-ID: On 2/19/19 3:40 PM, William Sudbrink via cctalk wrote: > A design that can manage Ohio Scientific as well would be nice. Might as well add Victor 9000... --Chuck From paulkoning at comcast.net Tue Feb 19 18:40:21 2019 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 19 Feb 2019 19:40:21 -0500 Subject: OT: Phone museum seeks new owner In-Reply-To: <3.0.6.32.20190220113127.011c9e58@mail.optusnet.com.au> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <3.0.6.32.20190220113127.011c9e58@mail.optusnet.com.au> Message-ID: <22D877A3-81A8-447E-A42D-38D504987500@comcast.net> > On Feb 19, 2019, at 7:31 PM, Guy Dunphy via cctalk wrote: > > At 01:11 PM 19/02/2019 -0800, you wrote: >>>> Old tech, but not computers: >>>> https://madison.com/business/galesville-antique-phone-dealers-looking-to-offload-vast-collection/article_b1845009-c861-50ff-82c8-60a15866fc6d.html >> >> On Tue, 19 Feb 2019, Peter Coghlan via cctalk wrote: >>> 451: Unavailable due to legal reasons >>> We recognize you are attempting to access this website from a country >> >> We must prevent advanced rotary dial technology from falling into the >> wrong hands! > > > Amusing, but that isn't anything close to what it's about. > >> 451: Unavailable due to legal reasons >> We recognize you are attempting to access this website from a country belonging >> to the European Economic Area (EEA) including the EU which enforces the General >> Data Protection Regulation (GDPR) and therefore access cannot be granted at >> this time. For any issues, contact hostmaster at madison.com or call 800-362-8333. > > The EU's GDPR is supposed to be about 'protecting personal data privacy', but seems > more like another Globalist attempt to cripple the Internet by imposing unreasonable > and near-impossible to comply with regulations. > > Guy This and many other examples of Internet censorship can be avoided by using TOR -- which is a nice browser for any number of other reasons too. paul From cisin at xenosoft.com Tue Feb 19 18:42:48 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 16:42:48 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: On Tue, 19 Feb 2019, Ali wrote: > Are we being a little sarcastic or serious? :) A lot of BOTH I would like to see software for flux transition hardware that would extract sectors. THEN, I would like to see that software as a subroutine, with an interface similar to INT13h. THEN, I would like to see that ROMable, either on a physical ROM, or loaded into RAM, with the INT13h vestor repointed to it. > Honestly, a sw implementation would be interesting but would it work on > vintage hw? Or are you suggesting for use only with a modern > system? My preference would be REAL MODE (DOS). But, for marketability, it would have to be WIN11 > For example here is my dilemma: my stinkers, whom you have met, > are getting old enough to want to mess with my stuff. *shudder* i mean > cool! but I really don't want them ruining my one actual original disk > for any programs I own. So what I do is make backup copies just like in > the old days. And before someone suggests emulators, it is just not the > same. I mean if we wanted to emulate everything why bother even > preserving hardware?Problem is when we have copy protection, as many > games or old SW do, then you need a Copy II PC board. I have one and > they are fairly common but ridiculously expensive now a days. So it > would be nice if the functions could be duplicated in an easy to use > manner. Kyro Flux is powerful but not for everyone. I want an FDC that > would cover 90% of the vintage hobby (i.e. Apple II, Mac, and IBM). An > FDC that combines a CompatiCard IV with a copy ii pc deluxe and a Match > Point card would cover all of the above plus then some.Just a > thought.... ;D Match Point could be implemented in software on the Central Point board. I discussed Mac disks with Brown of Central Point, and told him that I didn't think that the regular option board could handle an adequate range of data transfer rates. Hence, he came out with the Deluxe, including some Macintosh disk software. CompatiCard was just an ordinary FDC, without the crippling corners cut. There were a few others that could do comparable things. SO, you are asking for FDC plus flux transition, but better integrated, rather than flux transition hardware interrupting the drive cable. A lot of copy protected software can be duplicated using flux transition. That was Centraal Point's target market for the Option Board. There are a few exceptions, such as Pro-lock. But, in quite a few cases, people have disassembled (now illegal under DMCA!), found the vulnerabilities and simply disabled the copy protection. Often, it is as simple as replacing a conditional JMP with an unconditional JMP or a NOP. The trick is knowing WHERE :-) Such "unlocked" programs are what you ideally want. From cisin at xenosoft.com Tue Feb 19 18:44:20 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 16:44:20 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> Message-ID: >> A design that can manage Ohio Scientific as well would be nice. On Tue, 19 Feb 2019, Chuck Guzis via cctalk wrote: > Might as well add Victor 9000... It was in my original list :-) From jnc at mercury.lcs.mit.edu Tue Feb 19 18:54:47 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 19 Feb 2019 19:54:47 -0500 (EST) Subject: OT: Phone museum seeks new owner Message-ID: <20190220005447.E4B5318C087@mercury.lcs.mit.edu> > From: Grant Taylor > I do know that there are a lot of companies here in the US that are > filtering their website like this. It does go both ways; a while back, a vintage rail site I read regularly ('Weekend Rails') moved to a new hosting service, and that service filtered out and refused attempts from the US to read any of the sites they hosted (it wasn't at the site owner's request; I asked). So I had to use a European-based proxy for a while to get to it. Noel From cisin at xenosoft.com Tue Feb 19 19:00:26 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 17:00:26 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net>, Message-ID: On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote: > As I see it, flux transition hardware COULD be all that is needed for > hardware. Emulation of FDC could be done in software with flux > transition hardware. That should read flux transition plus appropriate control signals for the drive. Seeking tracks, turn on the drives R/W circuitry, etc. Flux transition ITSELF is just making sense out of the pulses on the track. From paulkoning at comcast.net Tue Feb 19 19:10:22 2019 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 19 Feb 2019 20:10:22 -0500 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> Message-ID: > On Feb 19, 2019, at 8:00 PM, Fred Cisin via cctalk wrote: > > On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote: >> As I see it, flux transition hardware COULD be all that is needed for hardware. Emulation of FDC could be done in software with flux transition hardware. > > That should read flux transition plus appropriate control signals for the drive. Seeking tracks, turn on the drives R/W circuitry, etc. > Flux transition ITSELF is just making sense out of the pulses on the track. Rather than flux transitions, flux levels would seem even better. If the flux levels are sliced and reduced to square waves, you've lost a bunch of information that could have helped recover marginal data. I' reminded of the Bordynuik tape reading machine that uses an MR head. Capturing analog flux levels at, say, 10x the nominal flux change density means all the rest is simply digital signal processing. That can be done in real time if you must, but much more easily in post processing using whatever tools and languages you like. paul From cisin at xenosoft.com Tue Feb 19 19:31:46 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 17:31:46 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> Message-ID: On Tue, 19 Feb 2019, Paul Koning wrote: > I' reminded of the Bordynuik tape reading machine that uses an MR head. > Capturing analog flux levels at, say, 10x the nominal flux change > density means all the rest is simply digital signal processing. That > can be done in real time if you must, but much more easily in post > processing using whatever tools and languages you like. As Al pointed out, at least an initial stage of analysis should be done real-time, or close to that, to determine whether the read seemed to have been successful. 'Course, that doesn't preclude later stages from also requesting a new attempt, if the data doesn't look good on further analysis. And, of course, using multiple machines, or just multiple processes, one system could begin processing, while another is reading more tracks. The reliability encountered would determine how much testing should be done before moving on, either to the next track? or the next disk? If errors are RARE, then there would be no cause to hesitate and hand off processing while moving on to the next JOB. If errors are FREQUENT (Al, Chuck, and I dealt with some that required dozens of attempts to get a successful read of a track), then that would caall for MORE processing before stepping to the next track or disk. FDC does a CRC "real time", and compares that with the value stored in the sector header. From couryhouse at aol.com Tue Feb 19 19:46:15 2019 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 20 Feb 2019 01:46:15 +0000 (UTC) Subject: OT: Phone museum seeks new owner References: <1970449179.2029208.1550627175080.ref@mail.yahoo.com> Message-ID: <1970449179.2029208.1550627175080@mail.yahoo.com> go? to? garage? sales? ?' thy? turn up there. In a message dated 2/19/2019 1:57:35 PM US Mountain Standard Time, cctalk at classiccmp.org writes: On Tue, Feb 19, 2019 at 09:58:00AM -0600, John Foust via cctalk wrote: > Old tech, but not computers: I have a fondness for old rotary dial phones, especially ones like they used in movies and TV shows set in the '40s and '50s.? I've never managed to acquire one.? I'd love to have a few of them, but not that many.? :-) -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From cctalk at ibm51xx.net Tue Feb 19 20:06:55 2019 From: cctalk at ibm51xx.net (Ali) Date: Tue, 19 Feb 2019 18:06:55 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? Message-ID: Fred,> Are we being a little sarcastic or serious? >:)>>A lot of BOTHJust making sure. ;)>I would like to see software for flux >transition hardware that would >extract sectors.>THEN, I would like to see that software as >a >subroutine, with an interface similar to >INT13h.>THEN, I would like to see that ROMable, >either on a physical ROM, or >loaded into RAM, with the INT13h vestor >repointed to it.That would make for a very powerful tool but as you pointed out yourself how many users would learn to use it? Unless it is a simple driver that gets loaded and the user has to simply put in a couple of generic parameters, e.g. "device=c:\drives\emudsk.sys APPLE", and it is up and running most users won't be able to make use of it.>My preference would be REAL MODE (DOS).As would mine but would a 286 be able to do it? And if you have a machine that runs real mode DOS why not make use of the HW that is there?>Match Point could be implemented in >software on the Central Point board.Great. Then if the DOB HW is duplicated then that part can be SW and no need to have Match Point HW duplicated. I am surprised the Copy II PC DOB card did not handle Apple II disks along with Mac disks.?>CompatiCard was just an ordinary FDC, >without the crippling corners cut.True, but if you are building the ultimate FDC then you don't want crippling corners cut. So something functionally equivalent.>SO, you are asking for FDC plus flux >transition, but better integrated, >rather than flux transition hardware >interrupting the drive cable.Yes! All on one card. Throw in FDADAP functionality to properly write 8" disks and you have a controller that handles most if not all IBM, Apple II, and Mac disks. As I understand it, in my limited way, having both FM and MFM should allow for many CP/M formats including SD. Will some formats be left out? Sure. Will it be as powerful as a Kyro Flux for archiving? Heck no. But will it let me pop in my original 123 disk and copy it for use with out too much hassle and work? Of course.?>There are a few exceptions, such as Pro-lock.Well then you had the ENHANCED Deluxe Board. :)>But, in quite a few cases, people have >disassembled (now illegal under >DMCA!), found the vulnerabilities and >simply disabled the copy protection.?Yes but that is harder and harder to find. They were never public but each city had multiple BBSes offering such altered programs. And of course the other problems w/ this method is you are confined to the one altered version? (even if you own a later version). Also there is no guarantee the alterations will not cause a bug that will crop up later due to a lack of total testing.-Ali From billdegnan at gmail.com Tue Feb 19 20:14:22 2019 From: billdegnan at gmail.com (Bill Degnan) Date: Tue, 19 Feb 2019 21:14:22 -0500 Subject: OT: Phone museum seeks new owner In-Reply-To: <1970449179.2029208.1550627175080@mail.yahoo.com> References: <1970449179.2029208.1550627175080.ref@mail.yahoo.com> <1970449179.2029208.1550627175080@mail.yahoo.com> Message-ID: I think it's useful to have one or two for exhibits of old modems and period systems that would have used a phone coupler. For that reason, a nice 1965 model would be good to have On Tue, Feb 19, 2019 at 8:46 PM ED SHARPE via cctalk wrote: > go to garage sales ' > thy turn up there. > In a message dated 2/19/2019 1:57:35 PM US Mountain Standard Time, > cctalk at classiccmp.org writes: > On Tue, Feb 19, 2019 at 09:58:00AM -0600, John Foust via cctalk wrote: > > > Old tech, but not computers: > > I have a fondness for old rotary dial phones, especially ones like they > used > in movies and TV shows set in the '40s and '50s. I've never managed to > acquire one. I'd love to have a few of them, but not that many. :-) > > > > > -- > > Kevin > http://www.RawFedDogs.net > http://www.Lassie.xyz > http://www.WacoAgilityGroup.org > Bruceville, TX > > What's the definition of a legacy system? One that works! > Errare humanum est, ignoscere caninum. > From couryhouse at aol.com Tue Feb 19 20:29:33 2019 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 20 Feb 2019 02:29:33 +0000 (UTC) Subject: A History of Engineering & Science in the Bell System TRANSMISSION TECHNOLOGY and ELECTRONICS TECHNOLOGY References: <1022274855.2032323.1550629773954.ref@mail.yahoo.com> Message-ID: <1022274855.2032323.1550629773954@mail.yahoo.com> A History of Engineering & Science in the Bell System TRANSMISSION TECHNOLOGY and ELECTRONICS TECHNOLOGY A History of Engineering & Science in the Bell System TRANSMISSION TECHNOLOGY and A History of Engineering & Science in the Bell System ELECTRONICS TECHNOLOGY? ( the? transistor? and devices? etc...) 60 for the? Pair? plus? 16.95? priority? mailing? insured? tracked and? signature? confirmation? payment to be? made? via? pay? pal? friends and? family...only? after? we? ok? who? gets them . both? ?tight? beauty? copies? with? ?great? jackets on them! Let me? ?know? asap? ?if? you? want. extra? copies? help re-roof museum buildings!Thanks? Ed# From elson at pico-systems.com Tue Feb 19 20:59:17 2019 From: elson at pico-systems.com (Jon Elson) Date: Tue, 19 Feb 2019 20:59:17 -0600 Subject: tracometer model 6a In-Reply-To: References: Message-ID: <5C6CC285.3080109@pico-systems.com> On 02/19/2019 02:23 AM, Adrian Stoness via cctalk wrote: > anyone ever herd of one? mines searial number 002 > says national research councle of canada made by eda electronics > > https://imagizer.imageshack.com/img923/5723/Bnz2VF.jpg > https://imagizer.imageshack.com/img924/6783/nHesKB.jpg > https://imagizer.imageshack.com/img922/5776/wimiv2.jpg > I'd guess it is a multichannel data logger that writes the data onto cassettes. Jon From cisin at xenosoft.com Tue Feb 19 21:01:07 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 19:01:07 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: On Tue, 19 Feb 2019, Ali wrote: > That would make for a very powerful tool but as you pointed out yourself > how many users would learn to use it? Unless it is a simple driver that > gets loaded and the user has to simply put in a couple of generic > parameters, e.g. "device=c:\drives\emudsk.sys APPLE", and it is up and > running most users won't be able to make use of it. By the time that I got out (for other reasons), XenoCopy had not been profitable for a while. THAT handled files, but the user still had to deal in other ways with modifications that they needed to the content of the files. Sure, a Wordstar file could be made into a generic text file by stripping the high bit. But converting WordPervert format codes into Weird format codes would have required another career. > > My preference would be REAL MODE (DOS). > As would mine but would a 286 be able to do it? And if you have a > machine that runs real mode DOS why not make use of the HW that is > there? For your 286 machine(s) wouldn't you like a combination of Compaticard, CatFerret, and option board, to use instead of the existing FDC board? If this were USB, then it could add floppy back onto some more "modern" machines. If USB, with appropriate "modern" drivers, no reason why this couldn't be used for MOST machines. > > Match Point could be implemented in software on the Central Point > > board. > Great. Then if the DOB HW is duplicated then that part can be SW > and no need to have Match Point HW duplicated. I am surprised the Copy > II PC DOB card did not handle Apple II disks along with Mac > disks. It could have. But Brown? (not sure whether I remember his name right) correctly realized that he could make money doing Mac, but there wasn't enough additional money with Apple2 to even necessarily reimburse him to hire those programmers. > > CompatiCard was just an ordinary FDC, without the crippling corners > > cut. > True, but if you are building the ultimate FDC then you don't want > crippling corners cut. So something functionally equivalent. Exactly. But, I want to make it clear that there is nothing SPECIAL about Compaticard; it's simply one of the best, but not unique. > > SO, you are asking for FDC plus flux transition, but better > > integrated, rather than flux transition hardware interrupting the > > drive cable. By the time DOB came out, 286 normally had FDC combined with HDD, so my suggestion to integrate FDC with OB wasn't applicable. > Yes! All on one card. Throw in FDADAP functionality to properly write 8" > disks and you have a controller that handles most if not all IBM, Apple > II, and Mac disks. FDADAP is a cabling adapter, plus generating the TG43 signal, which would be trivial to do with a conventional FDC. For READING (I hardly never WROTE), I cabled my 8 inch drives to 34 pin. > As I understand it, in my limited way, having both FM > and MFM should allow for many CP/M formats including SD. Yes. FM adds 8" SSSD "Standard", TRS80 model 1 (although still problems writing some address marks), and a handful of others. > Will some formats be left out? Sure. GCR, hard sector, etc. My (and I think Chuck's) favorite example for weird is Sirius/Victor 9000. (80 track GCR, although with its own versions of CP/M-86 and MS-DOS!) > Will it be as powerful as a Kyro > Flux for archiving? Heck no. But will it let me pop in my original 123 > disk and copy it for use with out too much hassle and work? Of > course.? > There are a few exceptions, such as Pro-lock.Well then you had > the ENHANCED Deluxe Board. :) Not necessarily. MANY versions of Pro-lock used the same identical check code, so one "crack" beat a lot of them. But some of the better ones rewrote their own subroutine. Pro-Lock relied on a physical defect on the disk. Both in terms of getting an read error trying to read that track, but sometimes even confirming that WRITING to that track also failed. They called it a "laser fingerprint", because "a sweatshop where they scratch disks with a paperclip" doesn't sound as impressive. Similarly, my Prius has a "LASER CUT key". Yeah. Right. The one that I'm using right now was cut with a tiny side-mill bit and a pantograph. > > But, in quite a few cases, people have disassembled (now illegal under > > >DMCA!), found the vulnerabilities and > >simply disabled the copy protection.? > Yes but that is harder and harder to find. They were never public but > each city had multiple BBSes offering such altered programs. And of > course the other problems w/ this method is you are confined to the one > altered version?? (even if you own a later version). Also there is no > guarantee the alterations will not cause a bug that will crop up later > due to a lack of total testing. I removed the copy-protection from my [legitimate] copy of 123. So that I could install it onto machines with different drives. Sorry, I don't remember where the patch is. But, is it really that hard to find the patches for the major programs? I don't doubt your statement; I'm just surprised. In the mid 1980s, when I had a publisher, they copy protected Xeno-Copy! It used to be, that if I Googled XenoCopy, many of the hits were for a patch to remove the copy protection from those early versions. Still are! I set up my publication of XenoCopy to be unprotected once it was "installed" (putting user name on title page. Prior to the name going on, I used a ridiculously simple protection to protect from copying of unpersonalized copies (just using an inconvenient "feature" of MS-DOS) Even XenoCopy would freely copy those disks! But DISKCOPY wouldn't. Although I never had reason to EVER use it, I designed a trivial copy protection that was copyable to a usable copy with DISKCOPY, but the original disk could not be read by the Option Board (It relied too much on index pulse). Once Option Board was stopped, it could have had something else added to make it inconvenient to copy. -- Grumpy Ol' Fred cisin at xenosoft.com From cisin at xenosoft.com Tue Feb 19 21:08:52 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 19:08:52 -0800 (PST) Subject: OT: Phone museum seeks new owner In-Reply-To: References: <1970449179.2029208.1550627175080.ref@mail.yahoo.com> <1970449179.2029208.1550627175080@mail.yahoo.com> Message-ID: On Tue, 19 Feb 2019, Bill Degnan via cctalk wrote: > I think it's useful to have one or two for exhibits of old modems and > period systems that would have used a phone coupler. For that reason, a > nice 1965 model would be good to have Well, you do need a classic handset for any acoustic coupler. Although W.E. "Celebrity" novelty handset will work. https://www.ebay.com/itm/233136060428 > > > I have a fondness for old rotary dial phones, especially ones like > > > they used in movies and TV shows set in the '40s and '50s. I've > > > never managed to acquire one. I'd love to have a few of them, but > > > not that many. :-) > > go to garage sales ' > > thy turn up there. There are a few on eBay. From charles.unix.pro at gmail.com Tue Feb 19 21:26:56 2019 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Tue, 19 Feb 2019 19:26:56 -0800 Subject: PDP-11 disk image question In-Reply-To: <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> Message-ID: On Tue, Feb 19, 2019 at 10:14 AM Paul Koning wrote: > > > > On Feb 19, 2019, at 11:51 AM, Charles Anthony < > charles.unix.pro at gmail.com> wrote: > > > > ... > > Presumably SIMH is returning RA81_LBN (891072) as the device size; this > is calculated based on the 51 sectors/track. If the h/w is returning a size > based on 52, then there is a mismatch which could be the source of the > problem. It has been hypothesised that the original problem is related to > SIMH misreporting the disk size; I was trying to point out a possible > source of error; does anyone know what size the h/w reports? > > > > -- Charles > > Some people here probably have an actual drive and can double check. > > Meanwhile, I found the "RA60, RA80, and RA81 disk drives" brochure (DEC, > August 1982) on Archive.org. It has the details in the back. Page 36 > shows "User data capacity" and says 51 sectors, 14 tracks, 1248 cylinders > -- that works out to 891072 sectors which is the number SIMH uses. > > So indeed the correct sector count is 51 (the other one is a spare, a > technique used by DEC as far back as the RM80). > > I am concerned that the spare is the issue. If the track has 52 sectors, and one is reserved as a spare, is that spare included in the LBA calculation? If it is, then SIMH is wrong; the first sector of the second track written in the spare sector, throwing all of the remaining data out of alignment, with the symptom of RSTS booting but not being able to find INIT.SYS. If the spare sector exists and SIMH is not allocation space for it, then the disk image will not copy correctly with 'dd'. (However, dd might be coereced into doing the right thing with 'dd if=... of=... ibs=26112 obs=26624'; reading 512*51 byte records (a SIMH track) and writing 512*52 byte records (a RA81 h/w track)). -- Charles From alan at alanlee.org Tue Feb 19 21:29:03 2019 From: alan at alanlee.org (alan at alanlee.org) Date: Tue, 19 Feb 2019 22:29:03 -0500 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net>, Message-ID: <945d09f7d033b4e2acce6c29040cda58@alanlee.org> Doesn't SuperCard Pro already do this? The hardware isn't open source, but the USB control protocol to read and write flux transitions on an entire track is open and well documented. And there are already several tools to exercise the protocol. Sure, one could replicate the hardware work for kicks, but that isn't the real heavy lift. Advanced tools for manipulating the flux images for low level encoding, high level format, and file system is the prize. The Amiga ADF disk tools project is a really good start... (supports dozens of formats beyond Amiga). -Alan On 2019-02-19 17:31, dwight via cctalk wrote: > Actually, I'd like to see it just read/write flux changes + index > marks onto a SD card for later analysis. Building all the smarts into > the controller means that some formats will get missed. One can later > write translation code for what ever format one has. Make this > information open source, much of it is already in bits and pieces. > Make sure it can read and buffer an entire track of data in RAM ( > Gotek can't ). > We no longer need proprietary hardware. There are a number of off the > shelf controller boards capable of handing this. It would only need > cables to match the drive. > Dwight From alan at alanlee.org Tue Feb 19 21:30:20 2019 From: alan at alanlee.org (alan at alanlee.org) Date: Tue, 19 Feb 2019 22:30:20 -0500 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: <147094b5b938ada059cda5eb98a792aa@alanlee.org> On 2019-02-19 19:42, Fred Cisin via cctalk wrote: > On Tue, 19 Feb 2019, Ali wrote: >> Are we being a little sarcastic or serious? :) > > A lot of BOTH > > I would like to see software for flux transition hardware that would > extract sectors. > THEN, I would like to see that software as a subroutine, with an > interface similar to INT13h. > THEN, I would like to see that ROMable, either on a physical ROM, or > loaded into RAM, with the INT13h vestor repointed to it. What's stopping you from writing it? -Alan From cisin at xenosoft.com Tue Feb 19 21:39:26 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 19 Feb 2019 19:39:26 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: <147094b5b938ada059cda5eb98a792aa@alanlee.org> References: <147094b5b938ada059cda5eb98a792aa@alanlee.org> Message-ID: >> I would like to see software for . . . >> THEN, I would like to see that software as . . . >> THEN, I would like to see that . . . > On Tue, 19 Feb 2019, alan--- via cctalk wrote: > What's stopping you from writing it? It's in the queue! Which is longer than my expected remaining lifespan. There are several aspects that I need to learn a lot more about. Alas, a few other things have greater urgency/priority, than completing what XenoCopy coulda/shoulda/woulda been. From cclist at sydex.com Tue Feb 19 21:42:20 2019 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 19 Feb 2019 19:42:20 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: <6dc74622-c572-b99a-6b7e-71cf9560f3e3@sydex.com> With all deference to the real collectors, I don't see the objective here. The thing should be NEC 765 compatible? Why? What about non-NEC-based sytems (e.g. the bulk of CP/M and countless other systems that don't use an LSI controller)? Or those systems that permanently already have a controller installed? And you know--not all systems used disks with standard-length (i.e. power of 2) sectors. (e.g. Zilog MCZ) or oddball addressing schemes? How about those old Apple II floppy protection that manipulated the positioner current to land the head *between* tracks? And other than *reading* the things once, why are we trying to fool with decaying doughnuts of rusty dust? Sample the rusty rings, stash the data away for use by analysis. If amenable to emulation, write a floppy *drive* emulator to match. Otherwise, you've got the data. My take on this subject only--but then, I'm mostly concerned about *reading* dusty rust and preserving the information for future reference, not recreating the original scenario. A NEC 765 is pretty limited in what it can do, in the firmament of floppy formats--I don't even know how to tell it to deal with, say, 132-byte sectors. Thanks for allowing me to spout my nonsense. --Chuck From glen.slick at gmail.com Tue Feb 19 22:55:09 2019 From: glen.slick at gmail.com (Glen Slick) Date: Tue, 19 Feb 2019 20:55:09 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> Message-ID: On Sat, Feb 16, 2019 at 1:20 PM Bill Gunshannon via cctalk wrote: > > I have a CQD=220A/MT configured for 6 disks and one tape. > As for disk types, you can toggle RA ON or OFF on each drive. > You can specify one RA type that will be in effect for any > disk with RA ON. Types are: RA70, RA80, RA81, RA82, RA90 and RA92. Looking at this further, I don't believe the CMD CQD RA type option does what you think it does. I don't believe it has any effect on the reported geometry of the MSCP unit, I believe it only changes the reported type name of the MSCP unit. I need to change the firmware on one of my CMD CQD controllers to a version of the firmware which has both the RA type specification option and RA type toggle per unit option to verify the actual behavior myself. I tried firmware version REV. B3A-00 on a CQD-220/TM which has an "A = Report specific media type" option, but not a "1 = Toggle device RA" option. With that firmware specifying an particular RA type had no effect on the reported unit geometry. I have firmware version REV. B2L-00 I can try on a CQD-420/TM which has both "A = Set the RA number" and "1 = Toggle device RA" options. I currently have firmware version REV. B2C-00 on my CQD-420/TM which has neither of those two option. Regardless of that, there are a couple of options you can try: (1) Find out the exact unit size that is being reported in your configuration with your CMD controller and hard drive, and configure the emulated hard drive unit size to match that. -or- (2) Reconfigure the SCSI hard drive independent of the CMD controller to match the exact unit size of the emulated hard drive. Then use the SCSI hard drive as a single unit without partitions on the CMD controller and it should yield the desired result. To reconfigure the SCSI hard drive you can use sg_format from the sg3_utils to soft resize the reported capacity of a SCSI hard drive down to a lower limit. I have done that several times, for example to resize a 9GB drive down to 1GB in capacity for systems while can't handle drives larger than 1GB. The sg_format command with the -resize option doesn't actually format the drive, it just uses some mode page commands to change the reported drive capacity. From ce.murillosanchez at gmail.com Tue Feb 19 09:15:26 2019 From: ce.murillosanchez at gmail.com (Carlos E Murillo-Sanchez) Date: Tue, 19 Feb 2019 10:15:26 -0500 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: <2561e6bb-ae2a-86e7-1e2e-874b8cadc40d@gmail.com> Alan Perry via cctech wrote: > The system does boot the AIX install on one of its hard disks, but > this is a recycled system and I don't have usernames/passwords for > that install. > > Does anyone here have a suggestion on how to proceed? > > alan Last year I started working on a 7012-320H that I've had for some time; it would not boot AIX, but it would stall during boot up before bringing up the console. People in this list and elsewhere made many useful suggestions. I made? the proper serial cabling, no console.? Finally, I was able to boot in system maintenance mode from boot AIX 3.2.5 diskettes that? I found on the net, and got a console.? I then discovered that the hard drive had 3.1.005 in it; still, managed to replace the /etc/security/passwd file (using just cat? and cp, there's no ls or ed in the maintenance shell) with a version that had the root password removed.? The system booted now, except that it would not mount /usr, because there wasn't an /etc/mount binary. After examining an image of the hard drive, I noticed that the binary for /etc/unmount had error messages for mounting operations, had this hunch that /etc/mount was the same binary as /etc/unmount, copied the latter to the former, and voila, I had a booting system.? You should be able to do the same if you can boot from a CD. Since then I added a second hard drive (the original was just 400mb), and I have been trying to build a toolchain and numeric processing programs.? I was able to build gcc-2.7.2 after building an early gmake with the system's cc even though the assembler in 3.1.005 has a known bug, then I built binutils-2.9.1 (the last version that will build ld on AIX 3.1.005), and then I succesfully built gcc-2.95.3 configured to use binutils and not the system's ld and as.? The last version of gcc supported on 3.1.005 is 3.3.6, but the build process fails early on at the dreaded gengtype stage with the usual "running out of memory" error (this is something that also happens under SunOS 4.1.4; my IPXs are at 2.95.3 too). So, I'm stuck at 2.95.3, but I've managed to build at least some things with it; right now I have: autoconf-2.59, bash-2.05b, binutils-2.9.1, bison-1.50, bpmpd-2.30, bvi-1.3.2, bzip2-1.0.2, fftw-3.3.7, flex-2.5.4, glpk-4.45, glpk-4.65, gawk-3.0.4, gmp-4.2.4, gnuplot-4.4.4, gperf-2.7.2, groff-1.10, gsl-2.1, gzip-1.3.12, jpeg-8d, lapack-3.1.1, libgd-2.0.33, libpng-1.4.22, m4-1.4.1, make-3.81, mpfr-3.1.6, ncurses-5.2, patch-2.5.9, pcre-6.7, perl-5.6.2, qhull-2009, qrupdate-1.1.2, readline-4.2, rx-1.5, screen-4.0.3, sed-3.0.2, texinfo-4.0, tiff-3.9.7, vim-5.8, zlib-1.2.3. I had to modify the source in most of them.? I have built a python-2.2.3 executable but right now it fails when importing modules, and I have been trying to build several versions of octave without success.? Most issues have to do with ancient system libs, ancient c++ grammar in gcc-2.95.3, a nonstandard dynamic loading mechanism, lack of UNIX98 features, and general senescence in this system.? But I like it anyway.? I wish I had a network card.? Sometime in the future I will configure a SLIP server with an old linux box or a raspberry and try to network the thing. carlos. From aperry at snowmoose.com Tue Feb 19 10:50:15 2019 From: aperry at snowmoose.com (Alan Perry) Date: Tue, 19 Feb 2019 08:50:15 -0800 Subject: RS/6000 7043-140 boot floppies In-Reply-To: References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: <5289809A-33E1-4231-BEB3-52B1567DBCD0@snowmoose.com> Thanks. It has been reported that Solaris 2.5.1 does work with the 604e, which the 7043-140 has, so I will be looking for another box to run 2.5.1 PPC on. I worked for Sun on Solaris back when the PPC port was done (and work for Oracle now on Solaris). I asked among Solaris folks (current and former) about PPC compilers and ?possibly gcc 2.95 otherwise cross compiling? was suggested. alan > On Feb 19, 2019, at 3:09 AM, Rico Pajarola wrote: > >> On Mon, Feb 18, 2019 at 6:49 PM Alan Perry via cctech wrote: > >> >> Is there some trick to making boot floppies for the RS/6000 7043-140 (a >> mid-90s PReP architecture machine)? >> >> I initially tried to install Solaris 2.5.1 on it and created the boot > #wrong43p > > Solaris 2.5.1 PPC doesn't work on that machine. > > I can't find the HCL doc, but according to the files present on the CD it runs on: > > IBM 6040 (ThinkPad 820) > IBM 6042 (ThinkPad 850) > IBM 6015 (PowerSeries 440, 7020-40P) > IBM 6050 (PowerSeries 830, 7248-43P) > IBM 6070 (PowerSeries 850, 7248-43P) > IBM 7248 (43P-100, 43P-120, 43P-132) > Motorola PowerStack Series DT/E/MT > > The 7248-43P is substantially different from a 7043-140 "43P". I have it running on a PowerStack Series E. > > Did anyone ever unearth the Sun compiler for that? > > >> floppy by dd'ing the image using a SPARCstation (running NetBSD). I >> dd'ed the image over, dd'ed it back and verified the SPARCstation could >> read back what it had written to the floppy. The RS/6000 loads what is >> on the floppy, but hangs transferring control to what it loaded. >> >> The 7043-140 does not appear on the list of supported systems in the >> Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the >> 7043-140 is a PReP machine, maybe they aren't compatible, so I tried >> NetBSD. The 7043-140 is listed as a supported system. >> >> The NetBSD boot floppy images are confusing to me. The files are too >> large to fit on a 1.44M floppy. I didn't see instructions on how to make >> boot floppies out of the .fs files one can download in the install >> instructions. I went ahead and tried to dd the part that fits onto a >> 1.44M floppy and try to boot that and of course that failed. I have >> e-mailed the NetBSD prep mailing list and no response from that. >> >> The system does boot the AIX install on one of its hard disks, but this >> is a recycled system and I don't have usernames/passwords for that install. >> >> Does anyone here have a suggestion on how to proceed? >> >> alan >> From peter at vanpeborgh.eu Tue Feb 19 10:50:40 2019 From: peter at vanpeborgh.eu (Peter Van Peborgh) Date: Tue, 19 Feb 2019 16:50:40 -0000 Subject: CDC modules Message-ID: <012101d4c873$3fc84230$bf58c690$@eu> Guys, I am wanting to determine which CDC (or possibly other) computer some of my modules came from. If you were a CDC employee around the time of CDC 6xxx computers, let me know where I could send my photos for identification of these items. Many thanks, peter || | | | | | | | | Peter Van Peborgh 62 St Mary's Rise Writhlington Radstock Somerset BA3 3PD UK 01761 439 234 || | | | | | | | | From billdegnan at gmail.com Tue Feb 19 13:24:09 2019 From: billdegnan at gmail.com (Bill Degnan) Date: Tue, 19 Feb 2019 14:24:09 -0500 Subject: CDC modules In-Reply-To: <012101d4c873$3fc84230$bf58c690$@eu> References: <012101d4c873$3fc84230$bf58c690$@eu> Message-ID: why not post a few pics? On Tue, Feb 19, 2019 at 11:50 AM Peter Van Peborgh via cctech < cctech at classiccmp.org> wrote: > Guys, > > I am wanting to determine which CDC (or possibly other) computer some of my > modules came from. If you were a CDC employee around the time of CDC 6xxx > computers, let me know where I could send my photos for identification of > these items. > Many thanks, > peter > > || | | | | | | | | > Peter Van Peborgh > 62 St Mary's Rise > Writhlington Radstock > Somerset BA3 3PD > UK > 01761 439 234 > || | | | | | | | | > > > From jules.richardson99 at gmail.com Tue Feb 19 15:31:53 2019 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Tue, 19 Feb 2019 15:31:53 -0600 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> Message-ID: <6b7146c0-03f9-600f-f8ae-39f83a6e3613@gmail.com> On 2/18/19 11:49 AM, Alan Perry via cctech wrote: > The system does boot the AIX install on one of its hard disks, but this is > a recycled system and I don't have usernames/passwords for that install. > > Does anyone here have a suggestion on how to proceed? If you've got another Unix-a-like (e.g. Linux works fine) machine kicking around with SCSI, it's possible to hack up some shell script to 'dd' blocks from the AIX machine's drive one by one, looking for stuff that looks like part of the password file. Then you can save them, edit them to make the data appear like a normal Unix passwd file (IBM being IBM, AIX in those days did things a little differently), and run one of the various password crackers on the result (e.g. JtR). That process worked for my 7043-140, anyway. I don't think that the filesystem for AIX that old is directly supported on anything, so you can't just mount it like I believe you can more modern releases. Of course if you have install media, then as someone else mentioned I believe there are ways of resetting it that way which are (probably) far easier :-) cheers Jules From aperry at snowmoose.com Tue Feb 19 15:58:34 2019 From: aperry at snowmoose.com (Alan Perry) Date: Tue, 19 Feb 2019 13:58:34 -0800 Subject: RS/6000 7043-140 boot floppies In-Reply-To: <6b7146c0-03f9-600f-f8ae-39f83a6e3613@gmail.com> References: <04b022c7-d83d-6eb2-593a-efdb27878976@snowmoose.com> <6b7146c0-03f9-600f-f8ae-39f83a6e3613@gmail.com> Message-ID: <52c8ffb5-aee9-615e-6c1d-96a459c32cc1@snowmoose.com> On 2/19/19 1:31 PM, Jules Richardson via cctech wrote: > On 2/18/19 11:49 AM, Alan Perry via cctech wrote: >> The system does boot the AIX install on one of its hard disks, but >> this is a recycled system and I don't have usernames/passwords for >> that install. >> >> Does anyone here have a suggestion on how to proceed? > > If you've got another Unix-a-like (e.g. Linux works fine) machine > kicking around with SCSI, it's possible to hack up some shell script > to 'dd' blocks from the AIX machine's drive one by one, looking for > stuff that looks like part of the password file. Then you can save > them, edit them to make the data appear like a normal Unix passwd file > (IBM being IBM, AIX in those days did things a little differently), > and run one of the various password crackers on the result (e.g. JtR). > > That process worked for my 7043-140, anyway. I don't think that the > filesystem for AIX that old is directly supported on anything, so you > can't just mount it like I believe you can more modern releases. Of > course if you have install media, then as someone else mentioned I > believe there are ways of resetting it that way which are (probably) > far easier :-) Thanks. I am all set now. I got a pointer to AIX 4.3.3 iso images and have been able to do a fresh install on the system. I also have a Model 150 that I need to go through and I think the AIX iso images will work for that as well. I haven't touched AIX in decades, so it did kinda hurt trying to wrap my brain around it again. alan > > cheers > > Jules > From karbak at pobox.com Tue Feb 19 16:16:48 2019 From: karbak at pobox.com (K. Arun) Date: Tue, 19 Feb 2019 16:16:48 -0600 Subject: Free: 2x DEC Alpha workstations - 164LX and XP1000 In-Reply-To: <20190219214736.GA3256@RawFedDogs.net> References: <20190219214736.GA3256@RawFedDogs.net> Message-ID: Hello, Thanks for the replies - I have takers for the XP1000 and 164LX. If it falls through, I'll reach out directly. Arun On Tue, Feb 19, 2019 at 3:47 PM Kevin Monceaux via cctalk < cctalk at classiccmp.org> wrote: > Arun, > > On Mon, Feb 18, 2019 at 11:26:41AM -0600, K. Arun via cctalk wrote: > > > I have a couple of Alpha workstations that were last used 5-6 years ago > > with some version of Tru64 on them. They haven't been turned on since, > and > > may need some work to get running again. They're free to anyone who > thinks > > they can use them, and can pick them up from the 78722 zip code (near UT > > Austin). Please contact me off-list to co-ordinate pickup. > > I sent you an off-list reply, but thought I'd mention it here in case the > off-list reply doesn't reach you. > > > > -- > > Kevin > http://www.RawFedDogs.net > http://www.Lassie.xyz > http://www.WacoAgilityGroup.org > Bruceville, TX > > What's the definition of a legacy system? One that works! > Errare humanum est, ignoscere caninum. > From jstefanikcctalk at gmail.com Tue Feb 19 21:39:36 2019 From: jstefanikcctalk at gmail.com (Jim Stefanik) Date: Tue, 19 Feb 2019 21:39:36 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: Message-ID: OK, so this thread pushed my to pursue playing with DT/6000.? If anyone has documentation on how exactly everything fits together, please let me know...if someone miraculously has a copy of DT/6000 in their archive, I could use a copy. Feel free to ping me off list to keep the noise here down. --- Jim Stefanik Dallas Vintage Computing Center ________________________________ From: Jay Jaeger via cctech Sent: Monday, 18 February 2019 15:48 To: cctech at classiccmp.org Subject: Re: IBM 3174 C 6.4 Microcode Disks? On 2/15/2019 10:22 AM, Jay Jaeger via cctech wrote: > On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote: >> Classic Computer Fans, >> >> I posted this to the IBM-Legacy-Hercules mailing list.? I just realized it >> probably wouldn't hurt to post it here too. >> >> I'm finally in possession of a box that hopefully is capable or can be made >> capable of connecting a real terminal to Hercules.? It's a 3174 11L.? It was >> retired last year where I work.? I finally got the okay to save it from >> being sent to a scrapper.? I love the build quality of older IBM gear, >> except when I'm trying to move such gear.? Between the 3174 and a 9406-520 I >> also acquired, I pulled or strained something in my left arm moving them >> into place. >> >> It's currently wired to run on 220v.? I think I've seen mentioned somewhere >> that it can be changed to run on 110v.? If that's the case, does anyone have >> a pointer to documentation on what's involved? >> >> It has dual floppy drives.? At least one drive is a 2.4MB drive.? But, all >> the microcode disks I have are at level B 4.6.? Does anyone know where I can >> get a set of C 6.4 control and control extension disks.? From what I've >> heard those are what's needed to enable an attached terminal to connect to >> other systems via telnet. >> >> It has a token ring card.? I will probably be able to get the MAU it was >> connected to, and possibly the router that acted as a token ring to Ethernet >> bridge. >> >> I'm not sure how much memory it has.? Does anyone have any tips on >> determining the amount of memory it has, and/or identifying its boards? >> These are the numbers on its boards: >> >>???? 9210 >>???? 9351 >>???? 9052 z2 >>???? 9053 >>???? 9501 >> >> Plus the boards for coax connections. >> >> >> > > I have some 3174 floppy disks, but I don't know what - they are not in > my inventory.? I will put it on my queue to look at them - but it may be > a couple of weeks.? I don't hold out much hope, but I will look. > Well, it turns out my floppies are for *3274* rather than 3174.? But, that said, if anyone needs any of them, let me know: just shipping cost. Here is a sample: 3274 Disks IBM Diskette 2 256 Bytes/Sector Date Name 8/09/83 A13 FEAT DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 6/18/84 A22 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A12 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/01/84 A22 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/01/84 A12 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/12/84 A23 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/12/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/18/84 A23 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 6/11/85 B22 18.33 LANGUAGE DISKETTE FOR CONFIG D AT REL 64.0 OR HIGHER 6/11/85 A12 21.30 SYSTEM - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/18/85 A12 19.40 FEATURE - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/24/86 B23 17.17 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.08 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.05 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER ------- KYB DEF UTILILTY REL G FOR LOAD 3290 D41.00, 3179-G D25.00 OR HIGHER (And about 150 more, in a similar date range) From cctalk at ibm51xx.net Wed Feb 20 02:15:05 2019 From: cctalk at ibm51xx.net (Ali) Date: Wed, 20 Feb 2019 00:15:05 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: Message-ID: <009901d4c8f4$63b26c80$2b174580$@net> > By the time that I got out (for other reasons), XenoCopy had not been > profitable for a while. THAT handled files, but the user still had to > deal in other ways with modifications that they needed to the content > of > the files. True, but at that point that is the user's problem. The idea is simply to make it easy to get the file or make backups. What someone would do with it after is their prerogative. > For your 286 machine(s) wouldn't you like a combination of Compaticard, > CatFerret, and option board, to use instead of the existing FDC board? Yes. Which is what I keep hoping someone would make. :) As opposed to a floppy emulating TSR. > If this were USB, then it could add floppy back onto some more "modern" > machines. If USB, with appropriate "modern" drivers, no reason why > this > couldn't be used for MOST machines. True, but you need one hell of a SW driver. Also can you even install unsigned drivers on Win10? > It could have. But Brown? (not sure whether I remember his name right) > correctly realized that he could make money doing Mac, but there wasn't > enough additional money with Apple2 to even necessarily reimburse him > to > hire those programmers. If I recall correctly the DOB came out in 1987 so the Apple II market was still pretty strong. I have an older (don't recall how old) but probably first series DOB board and on the box they really don't emphasize the Mac disk aspect. That seemed to come later with the white boxes w/ the rainbow logo. I had always heard it was because the IBM copy protection market had fizzled out i.e. the new 5.25" HD disks and the 3.5" disks did not have disk based copy protection. The Mac thing was a marketing ploy to keep sales going. Interestingly according to Wikipedia the DOB could read both Mac and Apple disks. I don't recall that personally and I am not sure even if true if that applied to Apple II 5.25" disks. > FDADAP is a cabling adapter, plus generating the TG43 signal, which > would > be trivial to do with a conventional FDC. For READING (I hardly never > WROTE), I cabled my 8 inch drives to 34 pin. True. I have the same setup. However, most FDCs don't provide this (I am not counting proprietary FDCs like the Flagstaff cards). Even the XT-FDC project chose not to include the TG43 signal generation on their card. I can't imagine it would have added that much to the cost of the card and could have been simply optional components (i.e. only put on if you wanted/needed write capability). I am not sure if there is a technical reason for it or not but the Ultimate FDC should not only read but write 8" drives out of the box.... > Yes. FM adds 8" SSSD "Standard", TRS80 model 1 (although still > problems > writing some address marks), and a handful of others. Exactly! I mean I know the Vector 9K will be left out but one must make sacrifices. Seriously though the card I propose would cover 95% of most people's needs (archivist and preservationist aside). If the card could be made to work with Amiga and/or Atari Disks you would almost have nirvana for 99.999% of the users. Yes, a guy like Chuck who needs to recover some obscure format off of some obscure scientific machine will probably need something better/more powerful/and more customizable but a plebe like me? I would be perfectly happy and I wouldn't have to give up two or more slots in my PC to do it. > Pro-Lock relied on a physical defect on the disk. Both in terms of > getting an read error trying to read that track, but sometimes even > confirming that WRITING to that track also failed. I have never owned and Enhanced DOB board but my understanding was that it defeated Pro-Lock by reading a disk and saving information as to the bad sector/location. Then when you wanted to run the Pro-Locked disk it would simply load that info into the Enhanced DOB's memory and it would be served up when requested by the program. > But, is it really that hard to find the patches for the major programs? > I don't doubt your statement; I'm just surprised. What used to be Major programs are now relics of long gone time. > It used to be, that if I Googled XenoCopy, many of the hits were for a > patch to remove the copy protection from those early versions. Still > are! I just did this - first two hits are your site. Next two are for un-protection routines. I am not sure if the second one is legit but the first one is. However, it suffers from what I had described earlier. It is specific to version 1.09. So I would either have to have version 1.09 or somehow find it... Maybe I could write the author and ask for a copy ;) Frankly, at this point I am less interested in hunting down the one version that works, or crack that is not a virus or a crack being hosted on some seedy site with malware galore, or... you get the idea. I like having the old SW with the manuals and all so that I can actually figure things out and have something to refer to. That was one of the beauties of SW back in the day. There was though and effort put into making a manual that taught you something (aside from using F1 to go online and search the online manual). If I go to the trouble of finding a copy of something on eBay and buying it I'd like an easy way to back it up. The DOB board does great for me but I think most people don't have a DOB and with the ridiculous eBay pricing on them they will stay a rare commodity... If the function can be built into an FDC why not? -Ali From binarydinosaurs at gmail.com Wed Feb 20 03:34:43 2019 From: binarydinosaurs at gmail.com (Adrian Graham) Date: Wed, 20 Feb 2019 09:34:43 +0000 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> References: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> Message-ID: Hello folks, I'm coming into this a bit late but a bloke called David Given is working on such a floppy controller right now, it's called Fluxengine and is based around a Cypress microcontroller that connects directly to a floppy drive and is driven by USB. Early days as yet in that it supports IBM formats plus Acorn BBC DFS/ADFS but since all the decoding is done in software pretty much any format can be added and David is looking for examples of eg C1541 floppies from the C64 as well as others. https://github.com/davidgiven/fluxengine -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk On Tue, 19 Feb 2019 at 23:40, William Sudbrink via cctalk < cctalk at classiccmp.org> wrote: > A design that can manage Ohio Scientific as well would be nice. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > From lproven at gmail.com Wed Feb 20 06:49:23 2019 From: lproven at gmail.com (Liam Proven) Date: Wed, 20 Feb 2019 13:49:23 +0100 Subject: HDDs (Was: PDP-11/45 RSTS/E boot problem In-Reply-To: References: <01R39I59B7C68WXLWI@beyondthepale.ie> Message-ID: On Tue, 19 Feb 2019 at 22:00, Fred Cisin via cctalk wrote: > > Yes. > I was thinking in terms of slightly older drives than that, particularly > 5.25" > Getting at the slider on newer drives wouldn't be practical. Probably not. I suspect that ITRO 90+ % of the people I work with have never seen a 5?" hard disk. CD-R or DVD, yes, but they're possibly unaware that HDs used to come in that formfactor. I've had arguments with people over the meaning of "full height" and "half height" before, because to them, the physically biggest drive they've ever seen, in ancient kit (to them), is a CD drive. So logically that _must_ mean "full height" because nothing is bigger, therefore they redefined all the terms in their heads... > The RAMAC came out in 1956? The platters are 24" diameter. Each platter > was almost 100K! But, with 50 platters, it maxed out at almost 5MB. > When Nikita Khruschev made a peace mission to USA, they took him on a tour > of the RAMAC facility. But, they wouldn't let him go to DisneyLand! (THAT > had repercussions in the Cuban missile crisis) 11 years before I came out, then. I've seen and played a bit with some machines with 8" floppies, but I think that's the biggest. I never saw the VAX 11-780 I learned Fortran on. > You could run Xenix on an XT! True, but I think it wasn't a lot of use for commercial multiuser accounts systems. They were the main market for Xenix for my employers, early in my career. My 1st job sold Tetra, mainly TetraPlan. Checks... huh, later bought by Sage: https://www.theregister.co.uk/1999/03/08/accounting_for_sages_move/ Later, I worked for places that sold other things, like SystemsUnion. Happily a market I left long ago and have forgotten about. > The stock IBM XT HDD controller (Xebec) had physical solder pads for drive > type, and supported 5MB, 10MB, 15MB, and 25MB drives. The 25 was, of > course, best (if you could get one) and would permit a 10MB DOS partition > dual booting with 15MB Xenix. Was that the first "dual boot" in the > PC world? (or was there a CP/M-86 dual boot option once they added HDD > support?) DOS+ could dual-boot with PC DOS, as I recall. I think CDOS could too. So, probably. I'm quite glad the XT was fading away as I got into the PC business. They were weird and constrained. Still, not knowing about them means people working on PCs now don't know where it came from... > I used a lot of ST4096 drives. Needed a second AT power supply for the > second one. Ha! Yes, I can believe that. IBM did under-spec the PSUs, though. > I use 2TB 2.5" 7.5mm Seagate/Samsung drives for MP4s of movies in > laptops and with a Seagate GoFlex-TV (media streamer with SATA slot) > But, I finally filled 2TB > Currently, that is the largest 7.5mm 2.5" drive available. But SSDs are > now available in 2TB, so when that price comes down, . . . > > > Heard about the NSA Utah Data Center? > https://nsa.gov1.info/utah-data-center/ > That's a LottaBytes! O_o Reminds me... I should buy a few more tibs, consolidate and rearrange some stuff. I wonder why megs and gigs caught on, but there's no common shorthand for terabytes? -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From paulkoning at comcast.net Wed Feb 20 07:38:48 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Feb 2019 08:38:48 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> Message-ID: > On Feb 19, 2019, at 10:26 PM, Charles Anthony wrote: > > > > On Tue, Feb 19, 2019 at 10:14 AM Paul Koning wrote: > > ... >> So indeed the correct sector count is 51 (the other one is a spare, a technique used by DEC as far back as the RM80). >> > > I am concerned that the spare is the issue. If the track has 52 sectors, and one is reserved as a spare, is that spare included in the LBA calculation? If it is, then SIMH is wrong; the first sector of the second track written in the spare sector, throwing all of the remaining data out of alignment, with the symptom of RSTS booting but not being able to find INIT.SYS. > > If the spare sector exists and SIMH is not allocation space for it, then the disk image will not copy correctly with 'dd'. (However, dd might be coereced into doing the right thing with 'dd if=... of=... ibs=26112 obs=26624'; reading 512*51 byte records (a SIMH track) and writing 512*52 byte records (a RA81 h/w track)). > > -- Charles You're misinterpreting "spare". MSCP exposes the user address space as contiguous LBAs, for which it uses 51 sectors per track. The spare sector is used to do bad sector replacement. That is invisible to users, it doesn't affect the LBA addressing. dd, like any other host-resident code, sees the user address space. It will copy MSCP devices correctly. paul From paulkoning at comcast.net Wed Feb 20 07:52:56 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Feb 2019 08:52:56 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> Message-ID: > On Feb 19, 2019, at 11:55 PM, Glen Slick via cctalk wrote: > > On Sat, Feb 16, 2019 at 1:20 PM Bill Gunshannon via cctalk > wrote: >> >> I have a CQD=220A/MT configured for 6 disks and one tape. >> As for disk types, you can toggle RA ON or OFF on each drive. >> You can specify one RA type that will be in effect for any >> disk with RA ON. Types are: RA70, RA80, RA81, RA82, RA90 and RA92. > > Looking at this further, I don't believe the CMD CQD RA type option > does what you think it does. I don't believe it has any effect on the > reported geometry of the MSCP unit, I believe it only changes the > reported type name of the MSCP unit. So this might be relevant. If the reported size is sufficiently different, things will break. For MSCP, RSTS cares about the device size (LBA count). It pays no attention to reported "geometry". It displays the reported device type string (in INIT "Hardware List" option) but it doesn't care about what those are. If a gigabyte disk claims it's an RX50 (or an RX98), RSTS will happily display that string without any objections. paul From geneb at deltasoft.com Wed Feb 20 08:39:37 2019 From: geneb at deltasoft.com (geneb) Date: Wed, 20 Feb 2019 06:39:37 -0800 (PST) Subject: OT: Phone museum seeks new owner In-Reply-To: <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> Message-ID: On Tue, 19 Feb 2019, Grant Taylor via cctalk wrote: > On 02/19/2019 01:17 PM, geneb via cctalk wrote: >> I'd be very interested in how that would be possible. > > I don't know. > > But I do know that there are a lot of companies here in the US that are > filtering their website like this. They may have a physical presence in the EU, which would cause the GDPR to apply to them. However, for companies with no physical presense in the EU, I don't see how the law could apply. 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_! From cctalk at gtaylor.tnetconsulting.net Wed Feb 20 09:53:19 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 20 Feb 2019 08:53:19 -0700 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> Message-ID: <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net> On 2/20/19 7:39 AM, geneb wrote: > They may have a physical presence in the EU, which would cause the GDPR > to apply to them.? However, for companies with no physical presense in > the EU, I don't see how the law could apply. I agree with your logic. However your valid logic is contrary to my understanding. I've seen reference to too many entities that don't have a presence in the EU that are doing things like blocking EU access to websites specifically because of GDPR. I don't have details on /how/ GDPR applies or /why/ people in the US are running scared of it. But I've seen many references to people doing exactly that. -- Grant. . . . unix || die From paulkoning at comcast.net Wed Feb 20 10:04:23 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Feb 2019 11:04:23 -0500 Subject: OT: Phone museum seeks new owner In-Reply-To: <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net> Message-ID: <7D204270-8206-4B3A-8F73-09C1830FA5D7@comcast.net> > On Feb 20, 2019, at 10:53 AM, Grant Taylor via cctalk wrote: > > On 2/20/19 7:39 AM, geneb wrote: >> They may have a physical presence in the EU, which would cause the GDPR to apply to them. However, for companies with no physical presense in the EU, I don't see how the law could apply. > > I agree with your logic. > > However your valid logic is contrary to my understanding. > > I've seen reference to too many entities that don't have a presence in the EU that are doing things like blocking EU access to websites specifically because of GDPR. There is ample precedent for small companies staying away from stuff because of fear of regulations or other legal hassles (like certain software licenses). Those fears aren't necessarily based on solid foundations. But when the possible downside is major legal hassles and bad publicity, and even investigating the potential threat is expensive (paying specialized lawyers in various countries) it makes sense simply to stay away and incur no risk. paul From geneb at deltasoft.com Wed Feb 20 10:15:58 2019 From: geneb at deltasoft.com (geneb) Date: Wed, 20 Feb 2019 08:15:58 -0800 (PST) Subject: OT: Phone museum seeks new owner In-Reply-To: <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net> Message-ID: On Wed, 20 Feb 2019, Grant Taylor via cctalk wrote: > On 2/20/19 7:39 AM, geneb wrote: >> They may have a physical presence in the EU, which would cause the GDPR to >> apply to them.? However, for companies with no physical presense in the EU, >> I don't see how the law could apply. > > I agree with your logic. > > However your valid logic is contrary to my understanding. > > I've seen reference to too many entities that don't have a presence in the EU > that are doing things like blocking EU access to websites specifically > because of GDPR. > > I don't have details on /how/ GDPR applies or /why/ people in the US are > running scared of it. But I've seen many references to people doing exactly > that. Based on what I've read, the only possible way the GDPR could apply to a US company (with no EU physical presence) is if you're selling or marketing directly to EU citizens. For the sites and "services" I provide, the EU is invited to see Figure One. ;) 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_! From w2hx at w2hx.com Wed Feb 20 10:51:38 2019 From: w2hx at w2hx.com (W2HX) Date: Wed, 20 Feb 2019 16:51:38 +0000 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net>, Message-ID: <1550681498814.33051@w2hx.com> I found this link from forbes on this issue. Apologies in advance as this site has lots of ads on it, but it is forbes.com https://www.forbes.com/sites/forbestechcouncil/2017/12/04/yes-the-gdpr-will-affect-your-u-s-based-business/#4fb0c03d6ff2 ________________________________________ From: cctalk on behalf of geneb via cctalk Sent: Wednesday, February 20, 2019 11:15 AM To: Grant Taylor; General Discussion: On-Topic and Off-Topic Posts Subject: Re: OT: Phone museum seeks new owner On Wed, 20 Feb 2019, Grant Taylor via cctalk wrote: > On 2/20/19 7:39 AM, geneb wrote: >> They may have a physical presence in the EU, which would cause the GDPR to >> apply to them. However, for companies with no physical presense in the EU, >> I don't see how the law could apply. > > I agree with your logic. > > However your valid logic is contrary to my understanding. > > I've seen reference to too many entities that don't have a presence in the EU > that are doing things like blocking EU access to websites specifically > because of GDPR. > > I don't have details on /how/ GDPR applies or /why/ people in the US are > running scared of it. But I've seen many references to people doing exactly > that. Based on what I've read, the only possible way the GDPR could apply to a US company (with no EU physical presence) is if you're selling or marketing directly to EU citizens. For the sites and "services" I provide, the EU is invited to see Figure One. ;) 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_! From charles.unix.pro at gmail.com Wed Feb 20 10:57:10 2019 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Wed, 20 Feb 2019 08:57:10 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> Message-ID: On Wed, Feb 20, 2019 at 5:38 AM Paul Koning wrote: > > > You're misinterpreting "spare". MSCP exposes the user address space as > contiguous LBAs, for which it uses 51 sectors per track. The spare sector > is used to do bad sector replacement. That is invisible to users, it > doesn't affect the LBA addressing. dd, like any other host-resident code, > sees the user address space. It will copy MSCP devices correctly. > > Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the disk through MSCP in the case of the *hardware*. However, in the original posters case, the SIMH disk image is being copied to the RA81 drive without the benefit of the MSCP controller (if I understand correctly). This would lead to track misalignment and could result in the observed behavior. The SIMH MSCP emulation is not doing the spare sector correctly; it is not including the spare sectors on the RA81 disk image. -- Charles From korpela at ssl.berkeley.edu Wed Feb 20 11:07:22 2019 From: korpela at ssl.berkeley.edu (Eric Korpela) Date: Wed, 20 Feb 2019 09:07:22 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> Message-ID: On Tue, Feb 19, 2019 at 4:39 PM Chuck Guzis via cctalk < cctalk at classiccmp.org> wrote: > On 2/19/19 3:40 PM, William Sudbrink via cctalk wrote: > > A design that can manage Ohio Scientific as well would be nice. > > Might as well add Victor 9000... > Don't forget hard sector CompuColor II, GCR, and variable speed GCR. :) -- Eric Korpela korpela at ssl.berkeley.edu AST:7731^29u18e3 From glen.slick at gmail.com Wed Feb 20 11:21:02 2019 From: glen.slick at gmail.com (Glen Slick) Date: Wed, 20 Feb 2019 09:21:02 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> Message-ID: On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk wrote: > > However, in the original posters case, the SIMH disk image is being copied > to the RA81 drive without the benefit of the MSCP controller (if I > understand correctly). This would lead to track misalignment and could > result in the observed behavior. How could you possibly write to a real RA81 drive without going through a real KDA50 or UDA50 MSCP controller? Nothing like that is happening in the original post. Just the disk size was chosen to be that of an RA81, and the issue is to exactly match the emulated disk size to that configured by the hardware, which is an MSCP SCSI controller and drive in this case. From lproven at gmail.com Wed Feb 20 11:33:13 2019 From: lproven at gmail.com (Liam Proven) Date: Wed, 20 Feb 2019 18:33:13 +0100 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net> Message-ID: On Wed, 20 Feb 2019 at 17:16, geneb via cctalk wrote: > Based on what I've read, the only possible way the GDPR could apply to a > US company (with no EU physical presence) is if you're selling or > marketing directly to EU citizens. This could be but it's quite a widespread problem. E.g. If I go to: https://www.nydailynews.com/ or I get: https://www.tribpub.com/gdpr/nydailynews.com/ ? Unfortunately, our website is currently unavailable in most European countries. We are engaged on the issue and committed to looking at options that support our full range of digital offerings to the EU market. We continue to identify technical compliance solutions that will provide all readers with our award-winning journalism. ? See: https://www.theregister.co.uk/2018/05/25/tronc_chicago_tribune_la_times_gdpr_lock_out_eu_users/ TBH mostly I neither know nor care. Occasionally I click a link and get a blanket "sorry, no" message. Also applies to lots of Youtube videos: I just get a "video unavailable" message. -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Wed Feb 20 11:33:43 2019 From: lproven at gmail.com (Liam Proven) Date: Wed, 20 Feb 2019 18:33:43 +0100 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> <092450d7-1589-77da-50e7-2135737385f9@spamtrap.tnetconsulting.net> <16c1ab62-c3fb-9d1c-36a9-fa689730b12f@spamtrap.tnetconsulting.net> Message-ID: That was meant to say... Or: https://www.chicagotribune.com/ -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Wed Feb 20 11:36:56 2019 From: lproven at gmail.com (Liam Proven) Date: Wed, 20 Feb 2019 18:36:56 +0100 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <1eac01d4c8ac$74921d90$5db658b0$@verizon.net> Message-ID: On Wed, 20 Feb 2019 at 18:08, Eric Korpela via cctalk wrote: > > Don't forget hard sector CompuColor II, GCR, and variable speed GCR. :) Well, yes, OK, but one step at a time. Step 1: a generic USB floppy controller that allows 5?" and 8" (and other standard Shugart-interface) FDDs to be attached to USB and seen by the OS on the system as floppy drives. That seems to be either coming or here. Step 2: some smart driver software for the above to enable weird disk formats that a standard WD FDD controller could read. Step 3: something very smart that enables weird non-WDD-disk-controller disks (e.g. Mac 400/800 kB and Amiga disks) that were written in fairly standard drives. Step 4 is when you get to all the non-hard-sectored drives and so on... -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From jnc at mercury.lcs.mit.edu Wed Feb 20 11:55:42 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 20 Feb 2019 12:55:42 -0500 (EST) Subject: OT: Phone museum seeks new owner Message-ID: <20190220175542.971F618C087@mercury.lcs.mit.edu> > From: Grant Taylor > I agree with your logic. > However your valid logic Anyone who thinks logic starting from common sense has anything to do with the workings of legal systems is likely in for a rude awakening at some point. Noel From paulkoning at comcast.net Wed Feb 20 12:10:45 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Feb 2019 13:10:45 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> Message-ID: > On Feb 20, 2019, at 11:57 AM, Charles Anthony wrote: > > > > On Wed, Feb 20, 2019 at 5:38 AM Paul Koning wrote: > > > You're misinterpreting "spare". MSCP exposes the user address space as contiguous LBAs, for which it uses 51 sectors per track. The spare sector is used to do bad sector replacement. That is invisible to users, it doesn't affect the LBA addressing. dd, like any other host-resident code, sees the user address space. It will copy MSCP devices correctly. > > > > Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the disk through MSCP in the case of the *hardware*. > > However, in the original posters case, the SIMH disk image is being copied to the RA81 drive without the benefit of the MSCP controller (if I understand correctly). This would lead to track misalignment and could result in the observed behavior. No. The original case isn't an actual RA81 at all, it's a non-DEC device that emulates an RA81. Emulation means acting like an RA81 from the program point of view, which means as seen via MSCP. There is no such thing as an RA81 "without... MSCP controller". > The SIMH MSCP emulation is not doing the spare sector correctly; it is not including the spare sectors on the RA81 disk image. It operates correctly because SIMH emulates the program point of view, so it exposes the user LBA space, not the internal structure. For the same reason, it doesn't emulate sector headers, ECC codes, or servo fields. None of that is visible to the software. paul From korpela at ssl.berkeley.edu Wed Feb 20 12:18:55 2019 From: korpela at ssl.berkeley.edu (Eric Korpela) Date: Wed, 20 Feb 2019 10:18:55 -0800 Subject: OT: Phone museum seeks new owner In-Reply-To: <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> Message-ID: If a company (or its owners if not shielded from liability) has any assets in the EU they can be seized (up to 4% of the company's total value) for violating GDPR. Apparently, Lee Enterprises has assets in Europe, and doesn't want to spend the non-trivial time, effort and expense (or lost revenue) to achieve compliance. On Tue, Feb 19, 2019 at 11:42 AM Grant Taylor via cctalk < cctalk at classiccmp.org> wrote: > On 02/19/2019 10:18 AM, geneb via cctalk wrote: > > So basically, they're blocking EU users from a website due to a law that > > has no effect in the US? Amazing. > > I thought I had heard from a number of people that GDPR could still bite > people in other countries. I don't remember the how, just that it could > be done. > > > > -- > Grant. . . . > unix || die > -- Eric Korpela korpela at ssl.berkeley.edu AST:7731^29u18e3 From wdonzelli at gmail.com Wed Feb 20 12:26:02 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Wed, 20 Feb 2019 13:26:02 -0500 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> <6f558e2e-2ccc-9f06-cb9d-fa748e3010d9@spamtrap.tnetconsulting.net> Message-ID: So...how 'bout them phones? (hint, hint) Does anyone know if they have any CO stuff? (only a tiny, tiny fraction of telephone collectors care, even a tiny bit, about CO stuff) -- Will From aek at bitsavers.org Wed Feb 20 12:42:26 2019 From: aek at bitsavers.org (Al Kossow) Date: Wed, 20 Feb 2019 10:42:26 -0800 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: Message-ID: On 2/19/19 7:39 PM, Jim Stefanik via cctalk wrote: > Well, it turns out my floppies are for *3274* rather than 3174.? But, > that said, if anyone needs any of them, let me know: just shipping cost. I can use them. I ended up with one w/o media From charles.unix.pro at gmail.com Wed Feb 20 12:43:31 2019 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Wed, 20 Feb 2019 10:43:31 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> Message-ID: On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk wrote: > On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk > wrote: > > > > However, in the original posters case, the SIMH disk image is being > copied > > to the RA81 drive without the benefit of the MSCP controller (if I > > understand correctly). This would lead to track misalignment and could > > result in the observed behavior. > > How could you possibly write to a real RA81 drive without going > through a real KDA50 or UDA50 MSCP controller? Nothing like that is > happening in the original post. Just the disk size was chosen to be > that of an RA81, and the issue is to exactly match the emulated disk > size to that configured by the hardware, which is an MSCP SCSI > controller and drive in this case. > Re-reading the original post, it it not clear to me how the disk write was accomplished; I am not familiar with the mentioned hardware. If the data was written to the RA81 with a controller that correctly did the spare sector mapping, then my spare sector hypothesis is wrong. The reported symptoms sound like a disk geometry issue; the data passes through several systems on the way to RSTS, and it seems likely to me that one of the steps is damaging the data. As I lack experience with or access to the specific hardware, I am speculating about the exact failure mode. I do however believe that it is highly likely that disk geometry is the root of the problem. Having no no further specific ideas about the failure mode, I will shut up now. -- Charles From couryhouse at aol.com Wed Feb 20 12:52:59 2019 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 20 Feb 2019 18:52:59 +0000 (UTC) Subject: OT: Phone museum seeks new owner References: <389034643.2480268.1550688779492.ref@mail.yahoo.com> Message-ID: <389034643.2480268.1550688779492@mail.yahoo.com> lots? of? piles? of? phones... some? areas? a? real? mess... this? guy? gets the hoarder? award? for? ?wooden? phone? cascaras back? when? the payphone? biz? went? privatized and legal? also? ?that? way? ?Ron had? conversion kits...? he? did? well in the? ? ?make? your? kitchen into a? country? kitchen? craze....? sold? lots? of? cobbled? to? ?work? ? oak? phones? ?for? ? the? kitchen.? there? was a? good? market? back in the? 70s? ?not? much? now? though? the old? people that remember the 'LASSIE"? ?wood? phone in? their? house as? kids? are? dying off? now... really interesting? ?guy....? ? ?very? odd business model.... ed# In a message dated 2/20/2019 11:26:20 AM US Mountain Standard Time, cctalk at classiccmp.org writes: So...how 'bout them phones? (hint, hint) Does anyone know if they have any CO stuff? (only a tiny, tiny fraction of telephone collectors care, even a tiny bit, about CO stuff) -- Will From paulkoning at comcast.net Wed Feb 20 13:09:00 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Feb 2019 14:09:00 -0500 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> Message-ID: <17C04BD0-497B-4E6D-9F25-74B5FCCD18FC@comcast.net> > On Feb 20, 2019, at 1:43 PM, Charles Anthony via cctalk wrote: > > On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk > wrote: > >> On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk >> wrote: >>> >>> However, in the original posters case, the SIMH disk image is being >> copied >>> to the RA81 drive without the benefit of the MSCP controller (if I >>> understand correctly). This would lead to track misalignment and could >>> result in the observed behavior. >> >> How could you possibly write to a real RA81 drive without going >> through a real KDA50 or UDA50 MSCP controller? Nothing like that is >> happening in the original post. Just the disk size was chosen to be >> that of an RA81, and the issue is to exactly match the emulated disk >> size to that configured by the hardware, which is an MSCP SCSI >> controller and drive in this case. >> > > > Re-reading the original post, it it not clear to me how the disk write was > accomplished; I am not familiar with the mentioned hardware. If the data > was written to the RA81 with a controller that correctly did the spare > sector mapping, then my spare sector hypothesis is wrong. Your confusion stems from the fact you think of "spare sector" as something that is visible. It is not. Programs can only deal with program-visible properties of devices. For MSCP disks, which is what we have here, the only program visible addressing is LBA addressing. There IS no geometry from the program point of view. "spare sectors" are an internal detail in the MSCP controller that allows it to deliver an error-free device. It has no relevance to programmers and it probably shouldn't have been mentioned in the documentation in the first place. > The reported symptoms sound like a disk geometry issue; the data passes > through several systems on the way to RSTS, and it seems likely to me that > one of the steps is damaging the data. No, that's not what the symptoms say. If you were dealing with geometry confusion, you'd fail much earlier. For example, if you were to take a RSTS system built on an RP06, and image-copied it to an RM05, it would fit fine (the RM05 is much bigger). And since the "device cluster size" is 9 for both, the file system would even be basically valid (apart probably from a too-small storage bitmap, but that wouldn't prevent reading data). However, the RM05 wouldn't boot at all, because the boot loader has been told it's on an RP06 and it would use the RP06 numbers for converting LBA to cylinder, track, sector values. Since the sectors/track differs (22 vs. 32) all the boot loader reads would go to the wrong place. It would be loading utter nonsense into memory. In the original problem, the boot loader worked fine. It loaded all of INIT successfully (because INIT got far enough to discover the disks and attempt to find INIT.SYS, and it did so without crashing). You wouldn't get anywhere close to that point if you had a geometry issue. paul From seefriek at gmail.com Wed Feb 20 13:13:50 2019 From: seefriek at gmail.com (Ken Seefried) Date: Wed, 20 Feb 2019 14:13:50 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: Message-ID: re: Cisco and IBM protocols If you're really interested, all of this is exhaustively documented under the umbrella of Cisco's "IBM Feature Set". There's a *lot* here under the hood, but the last time I looked (admittedly, a while) a number of folks had web sites that documented the correct incantations for Hercules and common hardware. You can bridge between TR (and FDDI) and ethernet on a Cisco, generally for non-routable protocols (e.g. NetBIOS); see: 'translational bridging'. If you're trying to get these protocols across an intermediary 'alien' network (like the corp FDDI backbone, or the Internet), there are things like DLSw. If you're trying to get TCP/IP from TR to ethernet and vice versa, routing generally works better/is simpler (IME), but Cisco has all sorts of bizarre encapsulation/translation features for different use cases should you need them. You can also make the router look like an SNA concentrator (PU?). KJ From paulkoning at comcast.net Wed Feb 20 13:14:12 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Feb 2019 14:14:12 -0500 Subject: PDP-11 disk image question In-Reply-To: <17C04BD0-497B-4E6D-9F25-74B5FCCD18FC@comcast.net> References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> <24712634-AFB3-4E3A-B99D-7880D7D6C5F7@comcast.net> <06600A1F-0F73-4833-BFC0-3EA37B885E71@comcast.net> <17C04BD0-497B-4E6D-9F25-74B5FCCD18FC@comcast.net> Message-ID: > On Feb 20, 2019, at 2:09 PM, Paul Koning via cctalk wrote: > > ... > No, that's not what the symptoms say. If you were dealing with geometry confusion, you'd fail much earlier. For example, if you were to take a RSTS system built on an RP06, and image-copied it to an RM05, it would fit fine (the RM05 is much bigger). And since the "device cluster size" is 9 for both, Typo. 8, not 9. DCS is a power of 2, the smallest value such that device size / DCS is < 65536. paul From paulkoning at comcast.net Wed Feb 20 13:23:52 2019 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 20 Feb 2019 14:23:52 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: Message-ID: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> > On Feb 20, 2019, at 2:13 PM, Ken Seefried via cctalk wrote: > > ... > You can bridge between TR (and FDDI) and ethernet on a Cisco, > generally for non-routable protocols (e.g. NetBIOS); see: > 'translational bridging'. If you're trying to get these protocols > across an intermediary 'alien' network (like the corp FDDI backbone, > or the Internet), there are things like DLSw. Please note that among LANs, there is Token Ring (802.5) and there is everything else. FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) it doesn't have proper multicast addresses, and (b) for some reason IBM invented source-routed bridging and tied that to Token Ring. FDDI is in no way at all like Token Ring. The only thing the two have in common is "token" and "ring". The MAC protocol is utterly different; the closest relative is 802.4 Token Bus. And as far as addressing is concerned, FDDI is like 802.4 and Ethernet, with real multicast and general use of normal transparent bridges. The only complication with FDDI (and 802.4, if you could find it) is that it only has 802.2 frames, not classic-Ethernet (with 16 bit protocol types). So an FDDI to Ethernet bridge has to translate Ethernet frames to an 802.2 based encapsulation. That is done by converting them to SNAP frames, as described in RFC 1042. Bridges like the DECbridge 500 and DECbridge 900 will do that; I assume Cisco does likewise. FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while it was out there it made a fine backbone for Ethernet-based LANs. paul From glen.slick at gmail.com Wed Feb 20 13:25:28 2019 From: glen.slick at gmail.com (Glen Slick) Date: Wed, 20 Feb 2019 11:25:28 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> Message-ID: On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk wrote: > > Theoretically, the SIMH emulated RA81 and the CMD emulated real > disk RA81 should be the same size because they are both supposed > to be RA81's. I spent the time to get set up and verified that this assumption is not correct. The CMD CQD MSCP SCSI controller firmware RA device type feature appears to only change the reported MSCP media name string, and has no effect on the reported MSCP size and geometry information. I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00). As far as I know the CQD-420 and the CQD-220A (but not the original CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive. I used sg3-utils / sg_format to soft resize the drive to exactly 2GB in capacity, 2,147,483,648 bytes, 4,194,304 blocks. After using the "Z = Reset Controller" configuration option to reset the CQD-420/TM firmware to its default state this was the configuration reported by the firmware: SCANNING SCSI DEVICES ATTACHED ... DEV0: DU0 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV1: DU1 SCSI ID 1 LUN 0 OFFLINE Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV2: DU2 SCSI ID 2 LUN 0 OFFLINE Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV3: DU3 SCSI ID 3 LUN 0 OFFLINE Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV4: MU0 SCSI ID 4 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV5: MU1 SCSI ID 5 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV6: MU2 SCSI ID 6 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV7 SCSI ID 7 HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF, Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA dev= DEF, Rsv/Rls Option ON,MSCP credit = 16,sync rate = 04 MB/sec, RSX FP OFF,Sel Timeout = 250 ms (PMR=Prevent Medium Removal WWV=Write W/Verify) Then a KA660 VAX console sees the device like this: >>>SHOW DEV UQSSP Disk Controller 0 (772150) -DUA0 (RA90) UQSSP Tape Controller 0 (774500) Then VMS booted on the KA660 VAX sees the device like this: $ MOUNT /FOREIGN BA215$DUA0: %MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0: $ SHOW DEVICE /FULL BA215$DUA0: Disk BA215$DUA0:, device type RA90, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 4194302 Sectors per track 217 Total cylinders 1933 Tracks per cylinder 10 Volume label "OVMSVAXSYS" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. One question here is why does VMS see 4194302 blocks when a SCSI Read Capacity command of the drive reports 4194304 blocks? Is the CMD CQD-420/TM firmware reserving a block or two? Anyway, I then tried to recreate the configuration of the original post as I understand it, partitioning the one physical SCSI drive into four logical MSCP device units, and turning on the RA81 type feature for those four MSCP device units. Note that now DEV0: DU0 through DEV3: DU3 all map the the same SCSI ID 0, they all have the RA feature set to ON, and the RA dev type is set to 81. SCANNING SCSI DEVICES ATTACHED ... DEV0: DU0 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV1: DU1 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV2: DU2 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV3: DU3 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV4: MU0 SCSI ID 4 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV5: MU1 SCSI ID 5 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV6: MU2 SCSI ID 6 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV7 SCSI ID 7 HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF, Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA dev=81, Rsv/Rls Option ON,MSCP credit = 16,sync rate = 04 MB/sec, RSX FP OFF,Sel Timeout = 250 ms (PMR=Prevent Medium Removal WWV=Write W/Verify) Now the KA660 VAX console sees the devices like this. The MSCP media name string has changed from RA90 to RA81. >>>SHOW DEV UQSSP Disk Controller 0 (772150) -DUA0 (RA81) -DUA1 (RA81) -DUA2 (RA81) -DUA3 (RA81) UQSSP Tape Controller 0 (774500) Now VMS running on the KA660 VAX sees the devices like this. It has simply divided the previous total block size of 4194302 into four equal block sizes of 1048575. It hasn't done anything to try to present the drives as the same total block size as a real hardware RA81 drive. $ MOUNT /FOREIGN BA215$DUA0: %MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0: $ MOUNT /FOREIGN BA215$DUA1: %MOUNT-I-MOUNTED, mounted on _BA215$DUA1: $ MOUNT /FOREIGN BA215$DUA2: %MOUNT-I-MOUNTED, mounted on _BA215$DUA2: $ MOUNT /FOREIGN BA215$DUA3: %MOUNT-I-MOUNTED, mounted on _BA215$DUA3: $ $ SHOW DEVICE /FULL BA215$DUA0: Disk BA215$DUA0:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "OVMSVAXSYS" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. $ SHOW DEVICE /FULL BA215$DUA1: Disk BA215$DUA1:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. $ SHOW DEVICE /FULL BA215$DUA2: Disk BA215$DUA2:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. $ SHOW DEVICE /FULL BA215$DUA3: Disk BA215$DUA3:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. From jsw at ieee.org Wed Feb 20 15:07:43 2019 From: jsw at ieee.org (Jerry Weiss) Date: Wed, 20 Feb 2019 15:07:43 -0600 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> Message-ID: On 2/20/19 1:25 PM, Glen Slick via cctalk wrote: > On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk > wrote: >> Theoretically, the SIMH emulated RA81 and the CMD emulated real >> disk RA81 should be the same size because they are both supposed >> to be RA81's. > I spent the time to get set up and verified that this assumption is > not correct. The CMD CQD MSCP SCSI controller firmware RA device type > feature appears to only change the reported MSCP media name string, > and has no effect on the reported MSCP size and geometry information. > > I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00). > As far as I know the CQD-420 and the CQD-220A (but not the original > CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive > with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive. > I used sg3-utils / sg_format to soft resize the drive to exactly 2GB > in capacity, 2,147,483,648 bytes, 4,194,304 blocks. > > ...... Paul K's explanation and Glen's example matches my own experience in this area. I don't have a CMD controller, but I move images between SIMH and both Emulex UC07 and Dilog SQ706A MSCP/SCSI Controllers. I've used RT11, XXDP, RSX11M+ and VAX VMS on both physical hard drives and SCSI2SD emulated disks. The physical SCSI drives I use have SCSI reassign capability. This allows the controller/drive to manage media defects.? This is transparent to any of the OS'es. The controller presents the disk simply as a continuous logical disk of disk blocks and the geometry has no effect. ?? Space reserved for bad block replacement is not visible to the OS. I make sure the number of logical blocks is maintained exactly as I move the images back and forth between SIMH and physical Machines. The disk type RA90, RA81, etc never makes a difference.? The MSCP controllers read the media size directly and report the disk logical capacity to VMS Drivers. If I move an VMS ODS-2 SIMH disk image to a larger SCSI disk drive then problems will occur.? For ODS type volumes, my understanding is that bitmap.sys file won't have room to manage the extra space.?? I also try to avoid edge cases for disk sizing that involve powers of two - e.g. 2**32.?? In my general experience, I have found boundary check problems in different situations (especially non-Digital). Disk NASTY$DKA100:, device type DEC RA92, is online, mounted, file-oriented ??? device, shareable, error logging is enabled. ??? Error count??????????????????? 0??? Operations completed?????????????? 2653 ??? Owner process???????????????? ""??? Owner UIC????????????????????? [SYSTEM] ??? Owner process ID??????? 00000000??? Dev Prot S:RWPL,O:RWPL,G:R,W ??? Reference count?????????????? 48??? Default buffer size???????????????? 512 ??? Total blocks???????????? 7603200??? Sectors per track??????????????????? 63 ??? Total cylinders????????????? 474??? Tracks per cylinder???????????????? 255 ??? Volume label????????? "VAXVMS73"??? Relative volume number??????????????? 0 ??? Cluster size?????????????????? 9??? Transaction count?????????????????? 155 ??? Free blocks????????????? 3072564??? Maximum files allowed??????????? 419336 ??? Extend quantity??????????????? 5??? Mount count?????????????????????????? 1 ??? Mount status????????????? System??? Cache name "_NASTY$DKA100:XQPCACHE" ??? Extent cache size???????????? 64??? Maximum blocks in extent cache?? 307256 ??? File ID cache size??????????? 64??? Blocks currently in extent cache 307161 ??? Quota cache size?????????????? 0??? Maximum buffers in FCP cache??????? 557 ??? Volume owner UIC??????? [SYSTEM]??? Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD ? Volume Status:? ODS-2, subject to mount verification, protected subsystems ????? enabled, file high-water marking, write-through caching enabled. I don't see a discrepancy on SCSI2SD V5 cards between configuration size and VMS reported block,? The size used is recorded on the SCSI2SD V5 card.? The SCSI2SD V6 adapters store the drive configuration on the last block of the microSD and I believe reported capacity is reduced by 1. ? Perhaps the CMD is doing similar to allow the media to be interchanged between controllers. ? Jerry From seefriek at gmail.com Wed Feb 20 15:09:46 2019 From: seefriek at gmail.com (Ken Seefried) Date: Wed, 20 Feb 2019 16:09:46 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> Message-ID: On Wed, Feb 20, 2019 at 2:23 PM Paul Koning wrote: > > > > > On Feb 20, 2019, at 2:13 PM, Ken Seefried via cctalk wrote: > > > > ... > > You can bridge between TR (and FDDI) and ethernet on a Cisco, > > generally for non-routable protocols (e.g. NetBIOS); see: > > 'translational bridging'. If you're trying to get these protocols > > across an intermediary 'alien' network (like the corp FDDI backbone, > > or the Internet), there are things like DLSw. > > Please note that among LANs, there is Token Ring (802.5) and there is everything else. FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) it doesn't have proper multicast addresses, and (b) for some reason IBM invented source-routed bridging and tied that to Token Ring. > > FDDI is in no way at all like Token Ring. The only thing the two have in common is "token" and "ring". The MAC protocol is utterly different; the closest relative is 802.4 Token Bus. And as far as addressing is concerned, FDDI is like 802.4 and Ethernet, with real multicast and general use of normal transparent bridges. > I didn't say TR was like FDDI. I said you could bridge FDDI to Ethernet using translation bridging. From wdonzelli at gmail.com Wed Feb 20 15:45:24 2019 From: wdonzelli at gmail.com (William Donzelli) Date: Wed, 20 Feb 2019 16:45:24 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> Message-ID: > FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while it was out there it made a fine backbone for Ethernet-based LANs. And a good sized chunk of the Internet ran over it for a good long while. Also pretty bullet proof. -- Will From bfranchuk at jetnet.ab.ca Wed Feb 20 16:59:16 2019 From: bfranchuk at jetnet.ab.ca (ben) Date: Wed, 20 Feb 2019 15:59:16 -0700 Subject: OT: Phone museum seeks new owner In-Reply-To: References: <01R3ENAM0D4K8WVZAF@beyondthepale.ie> Message-ID: <434d2295-5b59-d840-0901-3a196def73f2@jetnet.ab.ca> On 2/19/2019 2:14 PM, geneb via cctalk wrote: > This message brought to you by the Totalitarian Touch Tone Terrorists(tm). > g. > How ever SMART PHONES have taken OVER. AI's rule the world. Evil computer laugh! From Kevin at RawFedDogs.net Wed Feb 20 17:24:09 2019 From: Kevin at RawFedDogs.net (Kevin Monceaux) Date: Wed, 20 Feb 2019 17:24:09 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> Message-ID: <20190220232409.GA14113@RawFedDogs.net> Grant, On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote: > If the 2513 you have is the one that was used for this, I'd love to see > the config, if it's still on there. That would very likely settle > things for my curiosity. I have the 2513 now. I'm new to Cisco router commands and configuration. If you could give me a crash course on the commands that would display the parts of the configuration that would settle things for your curiosity, I'll see what it has. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. From imp at bsdimp.com Wed Feb 20 17:40:07 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 20 Feb 2019 16:40:07 -0700 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> Message-ID: On Tue, Feb 19, 2019 at 3:38 PM Chuck Guzis via cctalk < cctalk at classiccmp.org> wrote: > On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote: > > > Ability to read MFM data with FM headers (RX50) > > It's not that simple. There's the matter of "DEC MFM" which encodes a > few bit patterns differently to avoid collision with FM headers. > The RX50's are MFM encoded. There's no FM anything on it, unless it's that way on all MFM diskettes. Other DEC diskettes may have done this, but RX50's are just higher track density, but old pre IBM-AT data encoding rate diskettes. At least on the Rainbow the floppy chip is kept in MFM mode all the time, unless you've written something to hack it to read alien disks. Warner From spc at conman.org Wed Feb 20 17:42:22 2019 From: spc at conman.org (Sean Conner) Date: Wed, 20 Feb 2019 18:42:22 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190220232409.GA14113@RawFedDogs.net> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <20190220232409.GA14113@RawFedDogs.net> Message-ID: <20190220234222.GA6135@brevard.conman.org> It was thus said that the Great Kevin Monceaux via cctalk once stated: > Grant, > > On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote: > > > If the 2513 you have is the one that was used for this, I'd love to see > > the config, if it's still on there. That would very likely settle > > things for my curiosity. > > I have the 2513 now. I'm new to Cisco router commands and configuration. > If you could give me a crash course on the commands that would display the > parts of the configuration that would settle things for your curiosity, I'll > see what it has. The Cisco "command line" is quite nice and will always show you what it's expecting next when you press '?' at any point. If I recall correctly, "show config" will show the current saved configuration to the screen, and "show running-config" will show the currently running configuration (it will be different if you've made changes without saving them). You don't even need to type out the whole thing---just enough to disambiguate the command (I think 'sh conf" is enough, maybe even "sh c"). -spc From aek at bitsavers.org Wed Feb 20 17:47:08 2019 From: aek at bitsavers.org (Al Kossow) Date: Wed, 20 Feb 2019 15:47:08 -0800 Subject: TI Explorer Lisp machine tapes Message-ID: http://bitsavers.org/bits/TI/Explorer/cartridge_tapes the 2.6.0 diag 6.0 bootable and 6.0 patches are probably the most interesting has there been ANY posts about the Explorer simulator in the last decade? I've also not verified any of them are what the label says I ran into a couple that were overwritten. Some I know are correct, because there were multiple copies. From silent700 at gmail.com Wed Feb 20 17:56:21 2019 From: silent700 at gmail.com (Jason T) Date: Wed, 20 Feb 2019 17:56:21 -0600 Subject: VCF Midwest 14: Date Announcement Message-ID: Hello everyone - since people have already been asking (we even had someone call the hotel to try to register - that's some refreshing pro-activeness), we can confirm the date of this year's Vintage Computer Festival Midwest will be: September 14-15, 2019 2019 will bring a NEW LOCATION which will be announced in the coming weeks. So don't call the old hotel - they're already sad that they lost us*. Updates will be posted first to our site at http://vcfmw.org, as well as our mailing list, which you can join there. Thanks to all who have attended in the past and are considering it this year. This one will be something special**, for sure. -jht * Nothing wrong with the old place - we just outgrew it! ** Note that that is a measure of magnitude, not direction. From cclist at sydex.com Wed Feb 20 19:00:05 2019 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 20 Feb 2019 17:00:05 -0800 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> Message-ID: <1a33032b-6f94-0aa8-45ac-dd25a44d90bf@sydex.com> On 2/20/19 3:40 PM, Warner Losh wrote: > The RX50's are MFM encoded. There's no FM anything on it, unless it's > that way on all MFM diskettes. > > Other DEC diskettes may have done this, but RX50's are just higher track > density, but old pre IBM-AT data encoding rate diskettes. > > At least on the Rainbow the floppy chip is kept in MFM mode all the > time, unless you've written something to hack it to read alien disks. You're quite correct--I didn't notice the "RX50" until I'd posted. No, I was thinking (as probably was the OP) of RX02 double-density. --Chuck From cisin at xenosoft.com Wed Feb 20 19:08:15 2019 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 20 Feb 2019 17:08:15 -0800 (PST) Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: <1a33032b-6f94-0aa8-45ac-dd25a44d90bf@sydex.com> References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> <1a33032b-6f94-0aa8-45ac-dd25a44d90bf@sydex.com> Message-ID: > > Ability to read MFM data with FM headers (RX50) > On 2/20/19 3:40 PM, Warner Losh wrote: >> The RX50's are MFM encoded. There's no FM anything on it, unless it's >> that way on all MFM diskettes. >> Other DEC diskettes may have done this, but RX50's are just higher track >> density, but old pre IBM-AT data encoding rate diskettes. >> At least on the Rainbow the floppy chip is kept in MFM mode all the >> time, unless you've written something to hack it to read alien disks. On Wed, 20 Feb 2019, Chuck Guzis via cctalk wrote: > You're quite correct--I didn't notice the "RX50" until I'd posted. No, > I was thinking (as probably was the OP) of RX02 double-density. That was my mistake. I wrote RX50, but I meant RX02. And, as Chuck pointed out, the MFM data within the sectors is not quite the same as the MFM encoding used by others. Sorry about that. From cctalk at gtaylor.tnetconsulting.net Wed Feb 20 22:12:47 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 20 Feb 2019 21:12:47 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <002a01d4c762$c31a2520$494e6f60$@gmail.com> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <202a01d4c6a2$72e440b0$58acc210$@gmail.com> <767b6871-3f32-0658-48eb-41cd2625168b@spamtrap.tnetconsulting.net> <002a01d4c762$c31a2520$494e6f60$@gmail.com> Message-ID: <466ed327-9d27-a861-c702-66767733d766@spamtrap.tnetconsulting.net> On 2/18/19 1:20 AM, Dave Wade via cctalk wrote: > So the 3174 does not do this. 3270 terminals don't talk SNA/3270 to the > 3174 as defined in the IBM 3270 data streams. They are usually pretty dumb > and from what I can gather all keystrokes go to the 3174 just as for an > ASCII terminal. It only becomes a 3270 protocol when it exits the 3174. Okay. So I misunderstood ~> misspoke about the protocol on the coax side of the 3174. > You get dumb terminals, either ASCII or 3270 Screens in, and at the > other side you connect 3270 over SNA/SDLC, SNA/Token Ring, BiSync, > X.25 or whatever. But it sounds like the 3174 is functioning as an application layer gateway in some capacity in that it translates from one thing / protocol to another. > That?s exactly what a 3174 does. IBM calls it a Terminal Controller. ACK > I think there is, but to me a gateway has LAN protocols on both sides. Ah. To me, a "gateway" can be network layer, application layer, or do other things. I'll give you that a "gateway", as in a network layer gateway or router, does have network protocols that it routes / bridges between. (They may be on a single interface, a la one-armed-router.) > The 3174 NEVER accepts any sort of incoming connections. Just physical > terminals. Um ? what do you consider the connections from remote 3174s (physically / logically) connecting to a local 3174 via Token Ring / Ethernet / SDLC to be if not connections to the local 3174? I'm using IBM's definition for "local" and "remote" in this context. I can see some wiggle room for the connections from the remote 3174 being to the mainframe via the local 3174 and not actually to the local 3174. That being said I still think that the 3270 connection from the RS/6000 are addressed /to/ the local 3174's Token Ring (MAC) address. Or is this the above wiggle room too? > When used to connect network traffic to a mainframe the 3174 does not > terminate the TCPIP connection., it passes the frames across to the > channel. I may be wrong its been a long time since I did this and I > don't want to go delving into the VTAM documentation. The reading that I've done since the start of this thread makes me think that the connections from the RS/6000 would be SNA over Token Ring. As I understand it, this means that they are 802.2 LLC SNAP frames carrying something other than TCP/IP. Perhaps the 3174 is receiving those frames and passing them on to the mainframe via some form of routing or bridging. Or perhaps the 3174 is extracting the SNA data off of the Token Ring frames and passing just the SNA application layer data to the mainframe. I suspect that VTAM documentation is in my future if I truly want to understand this. Or maybe I'll get lucky and someone can answer my pointed questions. > Its kind of odd. RS232 (so X.25/SDLC/HDLC/Bi-Sync) connections can only > be used to connect to a Mainframe, not another 3174. That's contrary to what I have been reading this week. Based on the reading that I've done (I can dig for sources if you want me to), a remote 3174 can connect to a local 3174 via Token Ring / Ethernet / SDLC. This implies that the remote 3174 is connecting to another 3174. (See additional comments below.) > The Token Ring or Ethernet interface can be used to connect traffic to > the mainframe But from what I remember the 3174 isn't too involved at > this level it is acting as a network router/bridge. "too involved" is critical. > Just to confuse things this is an IBM manual where IBM does use it as a > "gateway"... ~chuckle~ Very little about IBM is simple. > http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/lan/GG24-3366-0_3174_Remote_Token-Ring_Gateway_Feb89.pdf I have seen virtually identical diagrams to the one on page 15 where the NCP was a local 3174 instead of the 3720 / 3725 / 3745. Notice how the listed 3174 sub models are all the remote variety. Take a look at page 54 of the following pdf. http://www.bitsavers.org/pdf/ibm/3174/GG24-4172-0_Using_3174_in_TCP_IP_Networks_Jun94.pdf The downstream 3174-13R can talk to either the upstream 3174-11L or the 3172. Figure 244 on page 259 shows the same. > so using the Token Ring interface on a remote 3174 to connect SNA traffic > to the host via SDLC.... ... again no TCPIP, working at the frame level, > and the host end cannot be a 3174... Figure 244 on page 259 tends to refute that. This document seems to be from 94 verses the document you linked to seeming to be from 89. Maybe things changed in the intervening years. > That really muddies the waters because it uses the term "3270" connection > in two senses. It uses it to refer to the co-ax type connection from > a work station (CUT or DFT) with with 3270 over Channel/SNA as defined > in the 3270 data streams manual and these really are different protocols. I agree to your prior comment that this traffic between the terminals and the 3174 terminal controller is not 3270. > That?s where you are going wrong. The protocols that the 3174 supports > between other 3174s are IBM SNA protocols. The "other 3174s" do not > need to be 3174s and can be any SNA device. Some of the documents that I've looked at this week have explicitly shown a routed TCP/IP network between the upstream / host 3174 and the downstream 3174. > Where does it say that?. In particular on page 39 it says.. I've lost track of what document you're referencing. I don't see anything like the following on (file) page 39 and page (number) 39 is a source code listing. > IEEE 802.2 > ? PU 2/LU 2 > ? PU 2.1/LU 6.2 (in migration mode) > > In the sort of use Kevin is talking about for connecting to Mainframe > channels there is generally no TCPIP on the 3174. In effect it looks > like a Mainframe NIC... > > But the 3174 generally doesn't use TCPIP on the ring... I'll agree that the RS/6000 may be using SNA on 802.2 LLC SNAP frames directly and not using TCP/IP. > The TN3270 traffic originates from the 3174 and terminates on the > Mainframe. Hum.... > TN3270 (and normal Telnet) traffic NEVER terminates on the 3174... Normal telnet traffic most certainly does terminate on the 3174 when it's being used as a gateway for 3270 / CUT terminals to Telnet sessions on other systems, like the RS/6000. But that's not what we've been discussing. > IBM describes it as LU6.2..... LU6.2 doesn't translate to what a network sniffer would show things as, which is what I'm trying to determine. I've gathered that it's 802.2 LLC SNAP frames. Which work perfectly fine on both Ethernet and Token Ring. As such, they can also be bridged between the two. > See above.... > > That?s how it connects, but this is not the normal operating mode of > a 3174. I get the impression that "normal" is highly subjective. Especially with later firmware on 3174s. > Yes, but a 3270 terminal does not talk 3270 protocol to the 3174.... ACK > Yes and the waters get muddied because the 3174 has had extra features > added along the way that allow it to be used in odd ways.... Agreed. I think I'm talking about things on the odder end of the spectrum. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Wed Feb 20 22:17:21 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 20 Feb 2019 21:17:21 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <20190220232409.GA14113@RawFedDogs.net> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <20190220232409.GA14113@RawFedDogs.net> Message-ID: On 2/20/19 4:24 PM, Kevin Monceaux via cctalk wrote: > I have the 2513 now. I'm new to Cisco router commands and configuration. > If you could give me a crash course on the commands that would display the > parts of the configuration that would settle things for your curiosity, > I'll see what it has. Cool. I've replied directly. I have no idea how complex this will get, especially if we have to bypass the password, and don't want to get even further into the weeds. I look forward to seeing what we can find out. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Wed Feb 20 22:26:01 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 20 Feb 2019 21:26:01 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: Message-ID: On 2/20/19 12:13 PM, Ken Seefried via cctalk wrote: > re: Cisco and IBM protocols > > If you're really interested, all of this is exhaustively documented > under the umbrella of Cisco's "IBM Feature Set". Thank you Ken. That's the type of information I'm wanting to figure out. > There's a *lot* here under the hood, but the last time I looked > (admittedly, a while) a number of folks had web sites that documented > the correct incantations for Hercules and common hardware. > > You can bridge between TR (and FDDI) and ethernet on a Cisco, generally > for non-routable protocols (e.g. NetBIOS); see: 'translational bridging'. That meshes with what I think I've managed to figure out. Both SNA and NetBIOS use 802.2 LLC frames with SNAP headers. Token Ring and Ethernet are able to carry that without any problem. Hence why they can be relatively bridged bridged without extensively modifying the frames. > If you're trying to get these protocols across an intermediary 'alien' > network (like the corp FDDI backbone, or the Internet), there are things > like DLSw. I learned that while reading this week. Now I want to see if DLSw can be used to connect two Windows machines using NetBIOS across an intermediary 'alien' network running TCP/IP. }:-) > If you're trying to get TCP/IP from TR to ethernet and vice versa, > routing generally works better/is simpler (IME), ACK Bridging between TCP/IP on 802.2 LLC frames with SNAP on Token Ring to Ethernet II frames on Ethernet is not nearly as simple. Especially when routing inherently handles it. Even Proxy ARP is a form of routing. > but Cisco has all sorts of bizarre encapsulation/translation features > for different use cases should you need them. *nod* I'm sure I'll find more information than is healthy for me to learn. > You can also make the router look like an SNA concentrator (PU?). ~whimper~ I don't need to think about that. I'd love to get a pair of mainframe (VMs?) running in a (non-Parallel) sysplex between a couple of Hercules instances. The idea of using a router as an SNA PU is ? intriguing. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Wed Feb 20 22:31:21 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 20 Feb 2019 21:31:21 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> Message-ID: <4447ff00-8e63-832c-1e23-912318985807@spamtrap.tnetconsulting.net> On 2/20/19 12:23 PM, Paul Koning via cctalk wrote: > Please note that among LANs, there is Token Ring (802.5) and there is > everything else. I think it really depends on how you look at them. From a frame formatting point of view, Ethernet is the odd ball when looking at how TCP/IP is carried. Everything other than Ethernet (802.3) uses 802.2 or a medium specific varient of 802.2. Then there's Ethernet which predominantly uses either Ethernet II for TCP/IP or 802.3 (a.k.a. "Raw") Ethernet frames for IPX. > FDDI is like Ethernet and like 802.4. Token Ring is the oddball because > (a) it doesn't have proper multicast addresses, and (b) for some reason > IBM invented source-routed bridging and tied that to Token Ring. Does it actually need a broadcast address like Ethernet when the ring passes through all the stations? Or is that functionally comparable to a multicast? > FDDI is in no way at all like Token Ring. The only thing the two have > in common is "token" and "ring". The MAC protocol is utterly different; > the closest relative is 802.4 Token Bus. And as far as addressing is > concerned, FDDI is like 802.4 and Ethernet, with real multicast and > general use of normal transparent bridges. > > The only complication with FDDI (and 802.4, if you could find it) > is that it only has 802.2 frames, not classic-Ethernet (with 16 bit > protocol types). So an FDDI to Ethernet bridge has to translate Ethernet > frames to an 802.2 based encapsulation. That is done by converting them > to SNAP frames, as described in RFC 1042. Intriguing. $ReadingList++ > Bridges like the DECbridge 500 and DECbridge 900 will do that; I assume > Cisco does likewise. > > FDDI didn't live all that long because 100 Mb Ethernet replaced it, but > while it was out there it made a fine backbone for Ethernet-based LANs. :-) -- Grant. . . . unix || die From glen.slick at gmail.com Wed Feb 20 22:32:30 2019 From: glen.slick at gmail.com (Glen Slick) Date: Wed, 20 Feb 2019 20:32:30 -0800 Subject: PDP-11 disk image question In-Reply-To: References: <20190216091023.4c7c0894@asrock> <6593EA2B-6E76-4012-A2C1-62B98DB7E701@avanthar.com> <70D8A27D-6E3E-4C7F-BEBE-51DE9CF383EC@comcast.net> Message-ID: After spending way to much time on this today, I verified that at least on the CMD CQD Q-Bus SCSI controller versions that I have if I wanted the CMD CQD controller to report an MSCP disk size of exactly 891072 blocks to match the SIMH emulated RA81 disk size, I had to soft resize the capacity of the SCSI hard drive to be 2 blocks larger, i.e. a capacity of 891074 blocks. This is with the CMD CQD controller reset to the default configuration with the 'Z' configuration option. The behavior of Q-Bus SCSI controllers from other vendors will be different. After doing that I verified that VMS on a VAX CPU, and also the 2.11BSD standalone disklabel on a PDP-11 CPU saw an MSCP disk size of 891072 blocks with the SCSI disk size of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller. I then installed RSTS/E 10.1 on a SIMH RA81 and then did the equivalent of a dd from the SIMH RA81 disk image file of size 456,228,352 bytes to the SCSI hard drive of capacity 891074 blocks. Then the PDP-11 CPU booted RSTS/E 10.1 from SCSI hard drive attached to the CMD CQD Q-Bus SCSI controller. Sorry for the extra long message. Gory details below. If I don't add the details now I'll forget all the details myself tomorrow. Resizing the 9GB SCSI hard drive down to a capacity of 891074 blocks on a Windows PC using sg3_utils-1.37 (I seem to recall that previously I tried this with a newer version of sg3_utils and something didn't work right): C:\sg3_utils-1.37>sg_scan PD0 [C] HDS728040PLAT20 PF1OA21B PD1 IBM DDRS-39130D DC1B CDROM0 [Z] TEAC CD-224E 1.7A C:\sg3_utils-1.37>sg_inq pd1 standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=1 Sync=1 Linked=1 [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=164 (0xa4) Peripheral device type: disk Vendor identification: IBM Product identification: DDRS-39130D Product revision level: DC1B Unit serial number: RE1X3474 C:\sg3_utils-1.37>sg_readcap pd1 Read Capacity results: Last logical block address=17849999 (0x1105e8f), Number of blocks=17850000 Logical block length=512 bytes Hence: Device size: 9139200000 bytes, 8715.82 MiB, 9.1392 GB C:\sg3_utils-1.37>sg_format --count=891074 --resize --verbose pd1 inquiry cdb: 12 00 00 00 24 00 IBM DDRS-39130D DC1B peripheral_type: disk [0x0] PROTECT=0 mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00 mode sense (10): pass-through requested 252 bytes but got 28 bytes Mode Sense (block descriptor) data, prior to changes: Number of blocks=17850000 [0x1105e90] Block size=512 [0x200] mode select (10) cdb: 55 11 00 00 00 00 00 00 1c 00 Resize operation seems to have been successful C:\sg3_utils-1.37>sg_readcap pd1 Read Capacity results: Last logical block address=891073 (0xd98c1), Number of blocks=891074 Logical block length=512 bytes Hence: Device size: 456229888 bytes, 435.095 MiB, 0.45623 GB Verifying that the SCSI hard drive with a capacity of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller is seen as a drive with a capacity of 891072 blocks on VMS on a VAX CPU: $ MOUNT /FOREIGN BA215$DUA0: %MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0: $ SHOW DEVICE /FULL BA215$DUA0: Disk BA215$DUA0:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 891072 Sectors per track 217 Total cylinders 411 Tracks per cylinder 10 Volume label "OVMSVAXSYS" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. Verifying that the SCSI hard drive with a capacity of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller is seen as a drive with a capacity of 891072 blocks on the 2.11BSD standalone disklabel on a PDP-11 CPU (ignore the "45Boot" which is a 2.11BSD bug that is fixed in a newer patch to correctly report "53Boot" on an 11/53 CPU). 9 8 7 6 5 4 3 2 1 Commands are Help, Boot, List, Map, Test and Wrap. Type a command then press the RETURN key: BOOT MU0 MU0 45Boot from tms(0,0,0) at 0174500 : tms(0,1) Boot: bootdev=06001 bootcsr=0174500 disklabel Disk? ra(0,0) 'ra(0,0)' is unlabeled or the label is corrupt. Proceed? [y/n] y d(isplay) D(efault) m(odify) w(rite) q(uit)? D d(isplay) D(efault) m(odify) w(rite) q(uit)? d type: MSCP disk: RA81 label: DEFAULT flags: bytes/sector: 512 sectors/track: 217 tracks/cylinder: 10 sectors/cylinder: 2170 cylinders: 410 rpm: 3600 drivedata: 0 0 0 0 0 1 partitions: # size offset fstype [fsize bsize] a: 891072 0 2.11BSD 1024 1024 # (Cyl. 0 - 410*) d(isplay) D(efault) m(odify) w(rite) q(uit)? q Label changed. Discard changes [y/n]? y 45Boot from tms(0,0,1) at 0174500 : Booting RSTS/E 10.1 from the SCSI hard drive with a capacity of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller after the SIMH emulated RA81 disk image file with the RSTS/E 10.1 was dd to the SCSI hard drive: 9 8 7 6 5 4 3 2 1 Commands are Help, Boot, List, Map, Test and Wrap. Type a command then press the RETURN key: BOOT DU0 DU0 RSTS V10.1-L RSTS (DU0) INIT V10.1-0L Today's date? 20-FEB-19 Current time? 19:46 Start timesharing? RSTS V10.1-L 20-Feb-19 07:46 PM User: 1,2 Password: Jobs detached under this account: Job What Size State Run-time RTS 1 ERRCPY 5K SR 13.6 ...RSX 3 OMS 9K SL 1.6 ...RSX 4 PBS... 19K SL 1.6 ...RSX Job number to attach to? Last interactive login on 20-Feb-19, 07:46 PM at KB0: Last non-interactive login on 20-Feb-19, 07:46 PM 3 other users are logged in under this account $ SHOW DISK Disk Structure: Dsk Open Size Free Clu Err Name Level Comments DU0 22 891072 837824 94% 16 0 RSTS10 1.2 Pub, DLW From ard.p850ug1 at gmail.com Wed Feb 20 23:00:20 2019 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Thu, 21 Feb 2019 05:00:20 +0000 Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? In-Reply-To: References: <007601d4c87f$701c6d60$50554820$@net> <007d01d4c883$dad26700$90773500$@net> <4725c626-1f00-8914-68e3-b6bf4f55f3db@sydex.com> Message-ID: On Wed, Feb 20, 2019 at 11:40 PM Warner Losh via cctalk wrote: > At least on the Rainbow the floppy chip is kept in MFM mode all the time, > unless you've written something to hack it to read alien disks. And modified the hardware. On the Rainbow the 'Dden/' pin of the floppy controller chip is tied to ground forcing said chip into MFM mode. -tony From rtomek at ceti.pl Thu Feb 21 00:59:33 2019 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 21 Feb 2019 07:59:33 +0100 Subject: TI Explorer Lisp machine tapes In-Reply-To: References: Message-ID: <20190221065932.GC13862@tau1.ceti.pl> On Wed, Feb 20, 2019 at 03:47:08PM -0800, Al Kossow via cctalk wrote: > > http://bitsavers.org/bits/TI/Explorer/cartridge_tapes > > the 2.6.0 diag 6.0 bootable and 6.0 patches are probably the most interesting > > has there been ANY posts about the Explorer simulator in the last decade? Now there is one, just found it, but does it work? - I will have a look later, hopefully. I have unhealthy fascination towards (or "about"?) Lisp Machines. http://unlambda.com/lispm/ " The Explorer III Project The E3 Project aims to develop a portable software emulator of the TI Explorer II Lisp machine. " -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From dave.g4ugm at gmail.com Thu Feb 21 05:02:54 2019 From: dave.g4ugm at gmail.com (Dave Wade) Date: Thu, 21 Feb 2019 11:02:54 -0000 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <466ed327-9d27-a861-c702-66767733d766@spamtrap.tnetconsulting.net> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <202a01d4c6a2$72e440b0$58acc210$@gmail.com> <767b6871-3f32-0658-48eb-41cd2625168b@spamtrap.tnetconsulting.net> <002a01d4c762$c31a2520$494e6f60$@gmail.com> <466ed327-9d27-a861-c702-66767733d766@spamtrap.tnetconsulting.net> Message-ID: <006001d4c9d4$ff96a720$fec3f560$@gmail.com> > > I'll give you that a "gateway", as in a network layer gateway or router, does > have network protocols that it routes / bridges between. (They may be on a > single interface, a la one-armed-router.) > > > The 3174 NEVER accepts any sort of incoming connections. Just physical > > terminals. > > Um ? what do you consider the connections from remote 3174s (physically / > logically) connecting to a local 3174 via Token Ring / Ethernet / SDLC to be if > not connections to the local 3174? > I think we have a layer disconnect here. There is a PHYSICAL connection, but logically the SNA traffic just passes through the box. You define the MAC addresses of the end points in the 3174 but it knows nothing of the traffic passing through. As far as the end points are concerned its just a router like the one in my wardrobe that links to the VDSL that?s passing my traffic TCPIP traffic through Except that my router has to do NAT. These are all in the same SNA Domain and have unique SNA addresses. When doing SNA the terminal on the remote 3174 connects the VTAM... > I'm using IBM's definition for "local" and "remote" in this context. > > I can see some wiggle room for the connections from the remote 3174 being > to the mainframe via the local 3174 and not actually to the local 3174. > > That being said I still think that the 3270 connection from the RS/6000 are > addressed /to/ the local 3174's Token Ring (MAC) address. Or is this the > above wiggle room too? > That?s just like IP routing. If we are doing SNA then each terminal has an SNA address that?s defined on the host. Its kind of like IP routing. My workstation knows that to route IP traffic to a specified non-local IP address it has to send it to my router. Same with SNA. The SNA connection is between the terminal and the mainframe. The 3174 simply routes traffic.... > > When used to connect network traffic to a mainframe the 3174 does not > > terminate the TCPIP connection., it passes the frames across to the > > channel. I may be wrong its been a long time since I did this and I > > don't want to go delving into the VTAM documentation. > > The reading that I've done since the start of this thread makes me think that > the connections from the RS/6000 would be SNA over Token Ring. As I > understand it, this means that they are 802.2 LLC SNAP frames carrying > something other than TCP/IP. > > Perhaps the 3174 is receiving those frames and passing them on to the > mainframe via some form of routing or bridging. > Yes, precisely. SNA is a layered protocol just like TCPIP. SNA connections Sit on top of other protocols. > Or perhaps the 3174 is extracting the SNA data off of the Token Ring frames > and passing just the SNA application layer data to the mainframe. > Theoretically VTAM has application layers. In practice it?s a mess... > I suspect that VTAM documentation is in my future if I truly want to > understand this. Or maybe I'll get lucky and someone can answer my > pointed questions. > Yes, the VTAM documentation is a good place to start (well perhaps not). But basically VTAM (used to, I haven't looked for a while) have huge tables that list every device on the network. So if you want to use 10 SNA 3270 terminals concurrently on an RS6000 There must be a VTAM/SNA node defined for the RS6000, and 10 VTAM/SNA nodes for the terminals. This lead to PC type gate products like Microsoft SNA server where you had TN3270 sessions to SNA server then connected via SDLC/Token Ring/X.25 to SNA on the host. If you wanted 20 concurrent session, you defined 20 nodes in VTAM and SNA server. SNA Server would assign in bound TN3270 sessions SNA addresses from its pool and associate them with the terminal... Now I have remembered something nasty. There are SNA management sessions, so if he is feeling nasty, the VTAM operator can disable any terminal on any 3174, or any 3174 ..... ... so yes there may be SNA sessions between 3174s for management purposes. I also haven't considered LU6.2 but LU6.2 is SNA app to SNA app so I can't see and SNA LU6.2 session terminating within a 3174. > > Its kind of odd. RS232 (so X.25/SDLC/HDLC/Bi-Sync) connections can > > only be used to connect to a Mainframe, not another 3174. > > That's contrary to what I have been reading this week. > > Based on the reading that I've done (I can dig for sources if you want me to), > a remote 3174 can connect to a local 3174 via Token Ring / Ethernet / SDLC. > > This implies that the remote 3174 is connecting to another 3174. (See > additional comments below.) > Token/Ring and Ethernet yes. I don't know of a way to have SDLC <-> to SDLC. But again its not an SNA end point to end point. The 3174 is merely routing SNA Frames. > > The Token Ring or Ethernet interface can be used to connect traffic to > > the mainframe But from what I remember the 3174 isn't too involved at > > this level it is acting as a network router/bridge. > > "too involved" is critical. > > > Just to confuse things this is an IBM manual where IBM does use it as > > a "gateway"... > > ~chuckle~ Very little about IBM is simple. > > > http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/lan/GG24-3366-0_3 > > 174_Remote_Token-Ring_Gateway_Feb89.pdf > > I have seen virtually identical diagrams to the one on page 15 where the NCP > was a local 3174 instead of the 3720 / 3725 / 3745. > > Notice how the listed 3174 sub models are all the remote variety. > > Take a look at page 54 of the following pdf. > > http://www.bitsavers.org/pdf/ibm/3174/GG24-4172- > 0_Using_3174_in_TCP_IP_Networks_Jun94.pdf > > The downstream 3174-13R can talk to either the upstream 3174-11L or the > 3172. > I believe here it means "route SNA traffic". I guess that there may also be SNA management sessions. I see that 3174's also support SNMP so there might be SNMP sessions... > Figure 244 on page 259 shows the same. > > > so using the Token Ring interface on a remote 3174 to connect SNA > > traffic to the host via SDLC.... ... again no TCPIP, working at the > > frame level, and the host end cannot be a 3174... > > Figure 244 on page 259 tends to refute that. > > This document seems to be from 94 verses the document you linked to > seeming to be from 89. Maybe things changed in the intervening years. > TCP/IP support improved over the years, yes... > > That really muddies the waters because it uses the term "3270" > > connection in two senses. It uses it to refer to the co-ax type > > connection from a work station (CUT or DFT) with with 3270 over > > Channel/SNA as defined in the 3270 data streams manual and these really > are different protocols. > > I agree to your prior comment that this traffic between the terminals and the > 3174 terminal controller is not 3270. > > > That?s where you are going wrong. The protocols that the 3174 supports > > between other 3174s are IBM SNA protocols. The "other 3174s" do not > > need to be 3174s and can be any SNA device. > > Some of the documents that I've looked at this week have explicitly shown a > routed TCP/IP network between the upstream / host 3174 and the > downstream 3174. > > > Where does it say that?. In particular on page 39 it says.. > > I've lost track of what document you're referencing. I don't see anything like > the following on (file) page 39 and page (number) 39 is a source code listing. > > > IEEE 802.2 > > ? PU 2/LU 2 > > ? PU 2.1/LU 6.2 (in migration mode) > > > > In the sort of use Kevin is talking about for connecting to Mainframe > > channels there is generally no TCPIP on the 3174. In effect it looks > > like a Mainframe NIC... > > > > But the 3174 generally doesn't use TCPIP on the ring... > > I'll agree that the RS/6000 may be using SNA on 802.2 LLC SNAP frames > directly and not using TCP/IP. > > > The TN3270 traffic originates from the 3174 and terminates on the > > Mainframe. > > Hum.... > > > TN3270 (and normal Telnet) traffic NEVER terminates on the 3174... > > Normal telnet traffic most certainly does terminate on the 3174 when it's > being used as a gateway for 3270 / CUT terminals to Telnet sessions on other > systems, like the RS/6000. Sorry the 3174 ORIGINATES connections. It does not accept connections. > > But that's not what we've been discussing. > > > IBM describes it as LU6.2..... > > LU6.2 doesn't translate to what a network sniffer would show things as, > which is what I'm trying to determine. > If its application aware LU6.2 would show up. That?s like saying a network sniffer can't see TCP/IP... > I've gathered that it's 802.2 LLC SNAP frames. Which work perfectly fine on > both Ethernet and Token Ring. As such, they can also be bridged between > the two. > > > See above.... > > > > That?s how it connects, but this is not the normal operating mode of a > > 3174. > > I get the impression that "normal" is highly subjective. Especially with later > firmware on 3174s. > I would say 99% of 3174's had 3270 screens and connected them to the Mainframe. That?s just bread and butter operation so any mainframe programmer can set on up in his sleep... ... so there isn't much info on it, so it looks like its not the way things are done.... I guess that a good proportion also had Token Ring or LAN interfaces that allowed the mainframe to talk LAN protocols. That was cheaper than 37xx box.... > > Yes, but a 3270 terminal does not talk 3270 protocol to the 3174.... > > ACK > > > Yes and the waters get muddied because the 3174 has had extra features > > added along the way that allow it to be used in odd ways.... > > Agreed. I think I'm talking about things on the odder end of the spectrum. > Not really. One good thing about the 3174 was that it was in IBM terms cheap... > > > -- > Grant. . . . > unix || die Dave From paulkoning at comcast.net Thu Feb 21 08:43:46 2019 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 21 Feb 2019 09:43:46 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <4447ff00-8e63-832c-1e23-912318985807@spamtrap.tnetconsulting.net> References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> <4447ff00-8e63-832c-1e23-912318985807@spamtrap.tnetconsulting.net> Message-ID: > On Feb 20, 2019, at 11:31 PM, Grant Taylor via cctalk wrote: > > On 2/20/19 12:23 PM, Paul Koning via cctalk wrote: >> Please note that among LANs, there is Token Ring (802.5) and there is everything else. > > I think it really depends on how you look at them. > > From a frame formatting point of view, Ethernet is the odd ball when looking at how TCP/IP is carried. > > Everything other than Ethernet (802.3) uses 802.2 or a medium specific varient of 802.2. Then there's Ethernet which predominantly uses either Ethernet II for TCP/IP or 802.3 (a.k.a. "Raw") Ethernet frames for IPX. "raw 802.3" is a bug, caused by a programmer not understanding how the specs work. The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need that mapping. >> FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) it doesn't have proper multicast addresses, and (b) for some reason IBM invented source-routed bridging and tied that to Token Ring. > > Does it actually need a broadcast address like Ethernet when the ring passes through all the stations? Or is that functionally comparable to a multicast? Broadcast is just a special case of multicast. My point was that 802.5, at least as IBM thinks of it, doesn't have proper multicast addresses (low bit set plus 47 bits to say what the address is). Instead, it has "functional addresses" which have a fixed beginning plus one of 32 bits that is set. So instead of 2^47 possible values, you have 32. I don't know why this was done. Perhaps their chip designers thought hash or CAM address matching was too hard? So if you have a protocol that uses multicast, like DECnet, you have to translate the real multicast address to the corresponding "functional" address in an Ethernet-802.5 bridge. And you have to make up a functional address, since the address space of 32 values is too small to have globally assigned multicast addresses as you do with other LANs. The ring passes through all stations of a LAN segment, just as the Ethernet bus (in the original version) passes through all stations of the segment. The point of multicast is that it recognized by multiple stations, not just one. But multicast matters to bridges because they have to forward it differently than individual addresses: individual is forwarded according to the address database entry if there is one, while multicast is not learned and always flooded along the spanning tree. >> FDDI is in no way at all like Token Ring. The only thing the two have in common is "token" and "ring". The MAC protocol is utterly different; the closest relative is 802.4 Token Bus. One example of this is the behavior under high load. At one time, token ring marketeers claimed it was better because it wouldn't "collapse" under load "like Ethernet". That is actually false, but in any event, 802.5 worst case latency is incredibly large for large rings. 802.4 and FDDI with their "timed token protocol" have far lower worst case latency. paul From aek at bitsavers.org Thu Feb 21 10:03:55 2019 From: aek at bitsavers.org (Al Kossow) Date: Thu, 21 Feb 2019 08:03:55 -0800 Subject: TI Explorer Lisp machine tapes In-Reply-To: <20190221065932.GC13862@tau1.ceti.pl> References: <20190221065932.GC13862@tau1.ceti.pl> Message-ID: On 2/20/19 10:59 PM, Tomasz Rola via cctalk wrote: > On Wed, Feb 20, 2019 at 03:47:08PM -0800, Al Kossow via cctalk wrote: >> >> http://bitsavers.org/bits/TI/Explorer/cartridge_tapes >> >> the 2.6.0 diag 6.0 bootable and 6.0 patches are probably the most interesting >> >> has there been ANY posts about the Explorer simulator in the last decade? > > Now there is one, just found it there are three, actually. http://unlambda.com/ the unlambda mailing list has been dead for a long time though. even the list archive is broken From dseagrav at lunar-tokyo.net Fri Feb 22 09:27:45 2019 From: dseagrav at lunar-tokyo.net (Daniel Seagraves) Date: Fri, 22 Feb 2019 09:27:45 -0600 Subject: TI Explorer Lisp machine tapes In-Reply-To: References: Message-ID: <0AD32EC5-262C-4C23-A9E6-58E7B9E410C5@lunar-tokyo.net> > On Feb 20, 2019, at 5:47 PM, Al Kossow via cctalk wrote: > > has there been ANY posts about the Explorer simulator in the last decade? > I haven?t posted about mine; When I left off, it was at a dead end. TI lost GENASYS, so there is no way to generate a new system, and no complete systems were available. Meroko never worked to an acceptable degree and other stuff came along. The LMI stuff is more promising long-term and I?m busy with that; If someone else wants to take this stuff and make Meroko do something useful with it, be my guest. From cctalk at gtaylor.tnetconsulting.net Fri Feb 22 17:02:33 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 22 Feb 2019 16:02:33 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <006001d4c9d4$ff96a720$fec3f560$@gmail.com> References: <20190215032837.GA2556@RawFedDogs.net> <20190215050309.GA26741@RawFedDogs.net> <202a01d4c6a2$72e440b0$58acc210$@gmail.com> <767b6871-3f32-0658-48eb-41cd2625168b@spamtrap.tnetconsulting.net> <002a01d4c762$c31a2520$494e6f60$@gmail.com> <466ed327-9d27-a861-c702-66767733d766@spamtrap.tnetconsulting.net> <006001d4c9d4$ff96a720$fec3f560$@gmail.com> Message-ID: <0d5515a0-cb5c-b0c2-17c3-1e8ca6b61655@spamtrap.tnetconsulting.net> On 02/21/2019 04:02 AM, Dave Wade wrote: > I think we have a layer disconnect here. There is a PHYSICAL connection, > but logically the SNA traffic just passes through the box. You define > the MAC addresses of the end points in the 3174 but it knows nothing of > the traffic passing through. As far as the end points are concerned its > just a router like the one in my wardrobe that links to the VDSL that?s > passing my traffic TCPIP traffic through Except that my router has to do > NAT. These are all in the same SNA Domain and have unique SNA addresses. > When doing SNA the terminal on the remote 3174 connects the VTAM... Okay. I'll have to ponder this. > That?s just like IP routing. If we are doing SNA then each terminal has > an SNA address that?s defined on the host. Its kind of like IP routing. > My workstation knows that to route IP traffic to a specified non-local > IP address it has to send it to my router. Same with SNA. The SNA > connection is between the terminal and the mainframe. The 3174 simply > routes traffic.... Okay. I'm starting to see a pattern as I re-read your email, pontificate, and reply. > Yes, precisely. SNA is a layered protocol just like TCPIP. SNA connections > Sit on top of other protocols. ACK Admittedly I had not thought about SNA being a layered protocol, much less what that means. But it does make perfect sense. My limited understanding has come from very few discussions about SNA over the years (prior to this and related threads) with people who treated it like a black box. > Theoretically VTAM has application layers. In practice it?s a mess... ~chuckle~ > Yes, the VTAM documentation is a good place to start (well perhaps not). ;-) > But basically VTAM (used to, I haven't looked for a while) have huge > tables that list every device on the network. I'm starting to get the impression that the tables are even larger than I might have originally suspected. > So if you want to use 10 SNA 3270 terminals concurrently on an RS6000 > There must be a VTAM/SNA node defined for the RS6000, and 10 VTAM/SNA > nodes for the terminals. Why do there need to be 10 VTAM/SNA nodes defined for the RS/6000? Wouldn't it be one node unto itself, much like a 3174, with the 10 VTAM/SNA nodes for the terminals behind it? > This lead to PC type gate products like Microsoft SNA server where you > had TN3270 sessions to SNA server then connected via SDLC/Token Ring/X.25 > to SNA on the host. So would Microsoft's SNA server (or the likes) have it's own VTAM node definition (terminology?) and a VTAM node definition for each (virtual) terminal that that was behind it? Where each virtual terminal was quite literally a logical representation of a state machine for the terminal and the TN3270 traffic would be the communications between the virtual terminal and the TN3270 terminal emulator running on the down stream IP client(s). Would VTAM still see the (virtual) terminals instantiated by SNA server, even when downstream clients were disconnected? Thus ultimately would timeout and logout / disconnect clients from ""idle terminals. Am I in the correct ball park? > If you wanted 20 concurrent session, you defined 20 nodes in VTAM > and SNA server. SNA Server would assign in bound TN3270 sessions SNA > addresses from its pool and associate them with the terminal... Sort of like old school modem pools, you got the first one that's available (assuming one was available), and it would have it's hardwired / defined node configuration in VTAM. Thus you could get different terminal IDs depending on which virtual terminal you got out of the pool. > Now I have remembered something nasty. There are SNA management sessions, > so if he is feeling nasty, the VTAM operator can disable any terminal > on any 3174, or any 3174 ..... ... so yes there may be SNA sessions > between 3174s for management purposes. Would s/he be disabling something on the 3174 itself? Or the logical VTAM entity (LU?) in the mainframe, thus disabling anything on the downstream end. Sort of like putting a phone call on hold at the receiving end functionally renders the phone at the calling end unusable. > I also haven't considered LU6.2 but LU6.2 is SNA app to SNA app so I > can't see and SNA LU6.2 session terminating within a 3174. I know of LU type 6.2, but not much else about them. > Token/Ring and Ethernet yes. I don't know of a way to have SDLC <-> > to SDLC. But again its not an SNA end point to end point. The 3174 is > merely routing SNA Frames. It sounds like the 3174 is conceptually routing or perhaps actually switching SNA frames between connections based on endpoints the 3174's portion of the big table of who's connected where. Everything has a path in the tree back to the host. > I believe here it means "route SNA traffic". I guess that there may > also be SNA management sessions. I see that 3174's also support SNMP > so there might be SNMP sessions... > > > TCP/IP support improved over the years, yes... > > > Sorry the 3174 ORIGINATES connections. It does not accept connections. I think we're having semantical differences. The 3174 is one of the endpoints of the established TCP connection. Bidirectional traffic for an established TN3270 session going from the 3174 terminates on the RS/6000 and traffic going from the RS/6000 terminates on the 3174. > If its application aware LU6.2 would show up. That?s like saying a > network sniffer can't see TCP/IP... > > > I would say 99% of 3174's had 3270 screens and connected them to the > Mainframe. That?s just bread and butter operation so any mainframe > programmer can set on up in his sleep... ... so there isn't much info > on it, so it looks like its not the way things are done.... > > I guess that a good proportion also had Token Ring or LAN interfaces > that allowed the mainframe to talk LAN protocols. That was cheaper than > 37xx box.... ACK > Not really. One good thing about the 3174 was that it was in IBM terms > cheap... IMHO "cheap" and "IBM" don't belong in the same phrase. Thank you for your input Dave. -- Grant. . . . unix || die From cctalk at gtaylor.tnetconsulting.net Fri Feb 22 17:21:42 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 22 Feb 2019 16:21:42 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> <4447ff00-8e63-832c-1e23-912318985807@spamtrap.tnetconsulting.net> Message-ID: <0970e59a-8afc-c160-8f62-75e594d7afef@spamtrap.tnetconsulting.net> On 02/21/2019 07:43 AM, Paul Koning via cctalk wrote: > "raw 802.3" is a bug, caused by a programmer not understanding how the > specs work. I thought people started using 802.3 /before/ the 802.2 specification was finished. Thus it's hard to follow what doesn't exit. Or at least that's what I've read multiple places. > The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need > that mapping. I'm still pontificating how trivial the mapping between Ethernet II and 802.2 SNAP is. I guess as long as you translate the Ethernet Frame Type to the SNAP Protocol ID (and vice versa) and the Ethernet frame payload would fit in the upper layer data area, things would be okay. There might be some payloads that would fit in an Ethernet II frame that wouldn't fit in an 802.2 SNAP frame on Ethernet. Fortunately Token Ring had bigger MTUs. You would probably only be going between Ethernet II and 802.2 SNAP if you were going from Ethernet (802.3) to a different 802 network. Which means that other things on that non-Ethernet 802 network would already understand the same protocol(s) in 802.2 SNAP frames. The idea of using a mixture of Ethernet II and 802.2 SNAP on an Ethernet seems odd. (en0 vs et0 interfaces in AIX come to mind.) > Broadcast is just a special case of multicast. My point was that 802.5, > at least as IBM thinks of it, doesn't have proper multicast addresses > (low bit set plus 47 bits to say what the address is). Instead, it > has "functional addresses" which have a fixed beginning plus one of > 32 bits that is set. So instead of 2^47 possible values, you have 32. Interesting. Thank you for explaining it. > I don't know why this was done. Perhaps their chip designers thought > hash or CAM address matching was too hard? ?\_(?)_/? > So if you have a protocol that uses multicast, like DECnet, you have to > translate the real multicast address to the corresponding "functional" > address in an Ethernet-802.5 bridge. And you have to make up a functional > address, since the address space of 32 values is too small to have > globally assigned multicast addresses as you do with other LANs. Was one functional address used in lieu of the broadcast? Meaning that all stations would receive it, look at it, and decide if they needed to act on it or not. Much like traditional 10Base5 / 10Base2 / hubs? > The ring passes through all stations of a LAN segment, just as the > Ethernet bus (in the original version) passes through all stations of > the segment. I think there's a minutia difference. I don't know if it's germane or not. To me, Ethernet (10Base5 / 10Base2 / Hubs) are functionally a broadcast that every station hears without any action on other stations behalf. Conversely, Token Ring each frame is actively passed station to station by each station. It's also my understanding that the station will not pass the frame on to the next station in the ring if the incoming frame was destined to the local station. Thus, not all stations would necessarily hear every frame like they would on Ethernet. > The point of multicast is that it recognized by multiple stations, > not just one. But multicast matters to bridges because they have to > forward it differently than individual addresses: individual is forwarded > according to the address database entry if there is one, while multicast > is not learned and always flooded along the spanning tree. ACK > One example of this is the behavior under high load. At one time, token > ring marketeers claimed it was better because it wouldn't "collapse" > under load "like Ethernet". That is actually false, but in any event, Please elaborate on why it's false. I've heard of stations locking up and breaking the ring. But I suspect that you're talking about something else. > 802.5 worst case latency is incredibly large for large rings. Ya, I can see that. > 802.4 and FDDI with their "timed token protocol" have far lower worst > case latency. I effectively don't know anything about 802.4 or FDDI. -- Grant. . . . unix || die From paulkoning at comcast.net Fri Feb 22 19:15:53 2019 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 22 Feb 2019 20:15:53 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <0970e59a-8afc-c160-8f62-75e594d7afef@spamtrap.tnetconsulting.net> References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> <4447ff00-8e63-832c-1e23-912318985807@spamtrap.tnetconsulting.net> <0970e59a-8afc-c160-8f62-75e594d7afef@spamtrap.tnetconsulting.net> Message-ID: > On Feb 22, 2019, at 6:21 PM, Grant Taylor via cctalk wrote: > > On 02/21/2019 07:43 AM, Paul Koning via cctalk wrote: > ... >> The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need that mapping. > > I'm still pontificating how trivial the mapping between Ethernet II and 802.2 SNAP is. I guess as long as you translate the Ethernet Frame Type to the SNAP Protocol ID (and vice versa) and the Ethernet frame payload would fit in the upper layer data area, things would be okay. There might be some payloads that would fit in an Ethernet II frame that wouldn't fit in an 802.2 SNAP frame on Ethernet. Fortunately Token Ring had bigger MTUs. > > You would probably only be going between Ethernet II and 802.2 SNAP if you were going from Ethernet (802.3) to a different 802 network. Which means that other things on that non-Ethernet 802 network would already understand the same protocol(s) in 802.2 SNAP frames. SNAP as a way of encoding bridged Ethernet II frames applies only to non-Ethernet LANs, all of which have larger MTU. > The idea of using a mixture of Ethernet II and 802.2 SNAP on an Ethernet seems odd. (en0 vs et0 interfaces in AIX come to mind.) SNAP covers more than encoding bridged Ethernet II. It was intended as a way to carry protocols in 802 format for which you couldn't get a SSAP/DSAP code point (such as private protocols). DEC did this in various places, it's perfectly straightforward. Perhaps some implementations make it hard to support both simultaneously, but there is no technical reason to make such a mistake. > >> Broadcast is just a special case of multicast. ... > Was one functional address used in lieu of the broadcast? Meaning that all stations would receive it, look at it, and decide if they needed to act on it or not. Much like traditional 10Base5 / 10Base2 / hubs? The pretense that broadcast is different from multicast is just a confusion. The description says that it is used for traffic that every station wants to get. If you take that literally, no protocol should use broadcast, because there isn't any protocol that every station on every LAN wants to see. For example, ARP should have used multicast for the same reason DECnet does: it is traffic that is interesting to stations which speak that protocol, and only to those stations. >> The ring passes through all stations of a LAN segment, just as the Ethernet bus (in the original version) passes through all stations of the segment. > > I think there's a minutia difference. I don't know if it's germane or not. > > To me, Ethernet (10Base5 / 10Base2 / Hubs) are functionally a broadcast that every station hears without any action on other stations behalf. Conversely, Token Ring each frame is actively passed station to station by each station. It's also my understanding that the station will not pass the frame on to the next station in the ring if the incoming frame was destined to the local station. Thus, not all stations would necessarily hear every frame like they would on Ethernet. I think that's right. For 802.5, that is. In FDDI the frames are "stripped" by the sending station, which allows things like network monitors in promiscuous mode to work just like on Ethernet > ... >> One example of this is the behavior under high load. At one time, token ring marketeers claimed it was better because it wouldn't "collapse" under load "like Ethernet". That is actually false, but in any event, > > Please elaborate on why it's false. The claim of collapse under load -- meaning throughput goes down beyond a certain load level -- is valid for ALOHA and similar networks, but not on Ethernet because it uses carrier sense and collision detect. Under overload it runs at close to full utilization. >> 802.5 worst case latency is incredibly large for large rings. > > Ya, I can see that. > >> 802.4 and FDDI with their "timed token protocol" have far lower worst case latency. > > I effectively don't know anything about 802.4 or FDDI. I'm trying to reconstruct what exactly the difference is, but I never knew 802.5 well and my FDDI brain cells are all from around 1986... paul From cctalk at gtaylor.tnetconsulting.net Sat Feb 23 02:01:51 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 23 Feb 2019 01:01:51 -0700 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> <4447ff00-8e63-832c-1e23-912318985807@spamtrap.tnetconsulting.net> <0970e59a-8afc-c160-8f62-75e594d7afef@spamtrap.tnetconsulting.net> Message-ID: <8442b247-f01e-c2d7-eb5f-45a55a1e6d39@spamtrap.tnetconsulting.net> On 2/22/19 6:15 PM, Paul Koning via cctalk wrote: > SNAP as a way of encoding bridged Ethernet II frames applies only to > non-Ethernet LANs, all of which have larger MTU. Nope. I'm quite sure that NetBIOS used SNAP on Ethernet. I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP. IPX could run over SNAP on Ethernet if you wanted to. > SNAP covers more than encoding bridged Ethernet II. It was intended > as a way to carry protocols in 802 format for which you couldn't get > a SSAP/DSAP code point (such as private protocols). DEC did this in > various places, it's perfectly straightforward. *nod* > Perhaps some implementations make it hard to support both simultaneously, > but there is no technical reason to make such a mistake. I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most OSs will not know how to work with TCP in a SNAP frame as they will be expecting Ethernet II frames. I don't know that there's a technical reason per say. I do think that there is a market reason. > The pretense that broadcast is different from multicast is just a > confusion. The description says that it is used for traffic that every > station wants to get. If you take that literally, no protocol should > use broadcast, because there isn't any protocol that every station on > every LAN wants to see. For example, ARP should have used multicast > for the same reason DECnet does: it is traffic that is interesting to > stations which speak that protocol, and only to those stations. Flip things on their head. I think it's that the sender wants every receiving station to see. > I think that's right. For 802.5, that is. ACK > In FDDI the frames are "stripped" by the sending station, which allows > things like network monitors in promiscuous mode to work just like > on Ethernet Intriguing. > The claim of collapse under load -- meaning throughput goes down beyond > a certain load level -- is valid for ALOHA and similar networks, but > not on Ethernet because it uses carrier sense and collision detect. > Under overload it runs at close to full utilization. Okay. So you weren't saying that Token Ring had problems as much as you were saying that Ethernet can work at close to capacity. I remember seeing references to Ethernet would start to have problems with increasing backouts as the number of stations wanting to transmit at the same time would grow. Though that may be that the average throughput of a given station may go down while the network segment itself is closer to saturation. > I'm trying to reconstruct what exactly the difference is, but I never > knew 802.5 well and my FDDI brain cells are all from around 1986... Fair. -- Grant. . . . unix || die From cramcram at gmail.com Fri Feb 22 22:10:04 2019 From: cramcram at gmail.com (Marc Howard) Date: Fri, 22 Feb 2019 20:10:04 -0800 Subject: VT52 stand Message-ID: Does anyone on the list have or have seen the stand that DEC sold with the VT52? I'm just curious; does the stand screw into holes on the monitor or does it just sit on top? >From what I've seen before it just looks like an office chair base with a top that is the correct size. Thanks, Marc From iamvirtual at gmail.com Fri Feb 22 22:21:33 2019 From: iamvirtual at gmail.com (B M) Date: Fri, 22 Feb 2019 21:21:33 -0700 Subject: VT52 stand In-Reply-To: References: Message-ID: My VT-50 just sits on the stand. There is a small lip (about 1/4") around the sides that the terminal sits in. --barrym On Fri, Feb 22, 2019, 21:11 Marc Howard via cctech, wrote: > Does anyone on the list have or have seen the stand that DEC sold with the > VT52? I'm just curious; does the stand screw into holes on the monitor or > does it just sit on top? > > From what I've seen before it just looks like an office chair base with a > top that is the correct size. > > Thanks, > > Marc > From steven at malikoff.com Fri Feb 22 23:28:11 2019 From: steven at malikoff.com (steven at malikoff.com) Date: Sat, 23 Feb 2019 15:28:11 +1000 Subject: VT52 stand In-Reply-To: References: Message-ID: <29758d2056cb7947f1c415cb4259f040.squirrel@webmail04.register.com> Marc said > Does anyone on the list have or have seen the stand that DEC sold with the > VT52? I'm just curious; does the stand screw into holes on the monitor or > does it just sit on top? > > From what I've seen before it just looks like an office chair base with a > top that is the correct size. > > Thanks, > > Marc >From the DEC Sales Catalog Fall 1978 http://www.surfacezero.com/g503/data/500/DEC_VT52_stand.jpg Steve. From henk.gooijen at hotmail.com Sat Feb 23 01:44:15 2019 From: henk.gooijen at hotmail.com (Henk Gooijen) Date: Sat, 23 Feb 2019 07:44:15 +0000 Subject: VT52 stand In-Reply-To: References: Message-ID: Marc, The bottom side has _5_ feet with casters. On the top side is a metal plate attached, but it is not flat. It is sort of curved to the center to make the plate sturdy. The VT52 is mounted on that plate with (IIRC) 8 screws. The screws go into the base of the VT52. The screws are located at the 4 corners and in the middle of each side. Henk, PA8PDP ________________________________ Van: cctech namens Marc Howard via cctech Verzonden: Saturday, February 23, 2019 5:10:04 AM Aan: General Discussion: On-Topic Posts Only Onderwerp: VT52 stand Does anyone on the list have or have seen the stand that DEC sold with the VT52? I'm just curious; does the stand screw into holes on the monitor or does it just sit on top? >From what I've seen before it just looks like an office chair base with a top that is the correct size. Thanks, Marc From cube1 at charter.net Sat Feb 23 08:31:54 2019 From: cube1 at charter.net (Jay Jaeger) Date: Sat, 23 Feb 2019 08:31:54 -0600 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: References: Message-ID: <478b9019-a0ce-7a14-932e-7ddeb37094d3@charter.net> Al, that was actually a quote from a message I wrote - I am the one with the 3274 floppies. Let me know what you are looking for. I am not at all familiar with what makes a "set", though I suppose I could just send the latest version I can find with each of the different sorts (SYST - which I took to be System, FEAT which I could to be Feature, and LANGUAGE that match your model. I found this in the IBM announcement letter: "One Feature Diskette and two System Diskettes are shipped with each 3274. For Models 31A, 31C, 31D, or 51C that are upgraded to Configuration Support D, a Language Diskette is also shipped. " If your 3274 does not have configuration support D, these might not work? Or maybe it was just a matter of needing to install the right Configuration support for the attached devices? I dunno (shrugs shoulders). Looking at the manuals on bitsavers, none of them mention this higher level of configuration support. I did find mention of it in an IBM announcement letter online, at https://www.argecy.com/3274 And it says this: "Configuration Support D (#9124): (Models 31A, 31C, 31D, 51C) Provides support for all 3270 functions included in Configuration Support C plus support for:" And "Configuration Support: The Configuration support required for the 3274 must be determined before ordering special features or attaching certain terminals. Refer to the 3274 Control Storage Requirements Tables under "Special Feature" Extended Function Store (EFS) for a detailed listing of the functions supports by each option. Field Installation: Yes. (Configuration Support D #9124 is field installation only for Models 31A, 31C, and 31D.) Customer Setup: Yes. Limitations: Certain functions require host software support in order to be utilized. Refer to host programming support descriptions to determine the levels of software required." So, unless yours is a 31A, 31C, 31D or 51C maybe these won't work? Let me know. JRJ On 2/20/2019 12:42 PM, Al Kossow via cctalk wrote: > > > On 2/19/19 7:39 PM, Jim Stefanik via cctalk wrote: > >> Well, it turns out my floppies are for *3274* rather than 3174.? But, >> that said, if anyone needs any of them, let me know: just shipping cost. > > I can use them. I ended up with one w/o media > > > From fritzm at fritzm.org Sat Feb 23 17:16:29 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Sat, 23 Feb 2019 15:16:29 -0800 Subject: PDP-11 LDA BFD backend for gnu binutils Message-ID: <6B7C3FA3-CAE1-4162-94A9-314FF76F0936@fritzm.org> I've been thinking it might be nice to have an LDA BFD backend for gnu binutils, so gas, ld, objdump etc. could deal with LDA's directly without having to use separate conversion utilities. Before jumping in on that, though, I thought I'd ask here to see if anybody might have already started or done this? I've noticed several of the folks here also have contributions on some of the binutils lists. thanks, --FritzM. From cctalk at ibm51xx.net Sat Feb 23 17:16:48 2019 From: cctalk at ibm51xx.net (Ali) Date: Sat, 23 Feb 2019 15:16:48 -0800 Subject: Compaq 9000 Rack Thumb Screw Message-ID: <005301d4cbcd$dc63a8c0$952afa40$@net> Slightly off topic for list although the rack and equipment are almost 20 years old now.... I got me a hand me down Compaq Proliant StorageWorks UE Rack. Basically it is a rack case that can hold 14 drives. The case is secured to the cabinet with two thumb screws (see attached pictures). These are like standard thumb screws except there is a spring component to them as well (I assume to give wiggle so it is easier to match screw to cage nut). You can see pictures of the screws in this VCF post: www.vcfed.org/forum/showthread.php?68556-Compaq-Rack-Thumb-Screws&p=559354#p ost559354 On my hand me down the one on the left is missing. I have looked and there doesn't seem to be a Compaq part number (I think the screws are press fitted into the metal frame so not really user replaceable). I don't think there is anything special about the screw and I can always use a standard M6 screw for the missing side. However, I'd like to try and match/restore the original. I have tried googling for theses screws but I am not coming up with the right item. I am guessing I am not using the right terms or names for the screws. So does anyone have some broken/parts Compaq rack equipment where I can have the screws? Or can point me to a source online to get a replacement? TIA! -Ali From cctalk at gtaylor.tnetconsulting.net Sat Feb 23 18:52:19 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 23 Feb 2019 17:52:19 -0700 Subject: Compaq 9000 Rack Thumb Screw In-Reply-To: <005301d4cbcd$dc63a8c0$952afa40$@net> References: <005301d4cbcd$dc63a8c0$952afa40$@net> Message-ID: On 2/23/19 4:16 PM, Ali via cctalk wrote: > (I assume to give wiggle so it is easier to match screw to cage nut). I think that thee thumb screws actually mate to the outer rail (shelf) that the StorageWorks units slide into. I don't think they actually mate to cage nuts. > (I think the screws are press fitted into the metal frame so not really > user replaceable). Agreed. > I don't think there is anything special about the screw and I can > always use a standard M6 screw for the missing side. However, I'd like > to try and match/restore the original. I don't know if they are M5 or M6 threads. The spring is nice. The tapered nose to make alignment and starting the threads nicer than a flat faced screw. But that's just nice to have and not necessary. > I have tried googling for theses screws but I am not coming up with the > right item. I am guessing I am not using the right terms or names for > the screws. So does anyone have some broken/parts Compaq rack equipment > where I can have the screws? Or can point me to a source online to get > a replacement? TIA! I don't think I've ever seen the screws separate. I've always seen the the metal face plate with thee screws sold as a unit. Try looking for that on the usual haunts. -- Grant. . . . unix || die From cctalk at ibm51xx.net Sat Feb 23 19:22:35 2019 From: cctalk at ibm51xx.net (Ali) Date: Sat, 23 Feb 2019 17:22:35 -0800 Subject: Compaq 9000 Rack Thumb Screw In-Reply-To: References: <005301d4cbcd$dc63a8c0$952afa40$@net> Message-ID: <007601d4cbdf$6d127a20$47376e60$@net> Grant, > I think that thee thumb screws actually mate to the outer rail (shelf) > that the StorageWorks units slide into. I don't think they actually > mate to cage nuts. Some of them do. These ones don't. You need to install a cage nut behind the screw. I have to do the same thing for the actual Proliant 3000 Server. > I don't know if they are M5 or M6 threads. The cage nuts I use are M6 threaded and the thumb screw fits perfectly. > The spring is nice. > > The tapered nose to make alignment and starting the threads nicer than > a > flat faced screw. But that's just nice to have and not necessary. Agreed. > I don't think I've ever seen the screws separate. I've always seen the > the metal face plate with thee screws sold as a unit. Try looking for > that on the usual haunts. I hate to have the ruin a good part to get the screw off (which is why I was asking if anyone has anything lying around) but I agree that may be the only way to get a replacement. Thanks! -Ali From carlclaunch51 at gmail.com Sat Feb 23 12:18:02 2019 From: carlclaunch51 at gmail.com (Carl Claunch) Date: Sat, 23 Feb 2019 10:18:02 -0800 Subject: Anyone have spare DipStik sockets? Message-ID: In the early 1970s a socket to hold multiple DIP chips was being sold under the brand name DipStik. Up to six chips were inserted in a trough in the socket, a top screwed on with thumbscrews on the ends. It had solder lugs on the top and bottom for each of the chip pins. We are restoring an old electronic device that was built in part with these, but due to some corrosion we could use replacement DipStik units if anyone has them. Carl From cctalk at gtaylor.tnetconsulting.net Sat Feb 23 12:29:42 2019 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Sat, 23 Feb 2019 11:29:42 -0700 Subject: Anyone have spare DipStik sockets? In-Reply-To: References: Message-ID: <52383b82-8d73-e1b7-f3ce-26d820beaae8@spamtrap.tnetconsulting.net> On 2/23/19 11:18 AM, Carl Claunch via cctech wrote: > In the early 1970s a socket to hold multiple DIP chips was being sold > under the brand name DipStik. Up to six chips were inserted in a trough > in the socket, a top screwed on with thumbscrews on the ends. It had > solder lugs on the top and bottom for each of the chip pins. > > We are restoring an old electronic device that was built in part with > these, but due to some corrosion we could use replacement DipStik units > if anyone has them. I don't have an answer for you. But I do think I know where I have seen what you're talking about. Curious Marc and compatriots?one of whom is named Carl?are restoring an Apollo Guidance Computer, and an external Rope Memory (?) emulator that has what I believe are the DipStiks that you're talking about. The DipStiks do seem like an interesting thing. I thought there was the possibility of soldering on both the outside bottom of the trough and the top plate that holds DIPs in place. Sorry, I don't have links to specific videos, much less time stamps handy at the moment. If you're curious to see what I think are DipStiks and / or the Apollo Guidance Computer, go check out Curious Marc's videos. I think they are great. I have found all of Curios Marc's and compatriots projects entertaining and enlightening. -- Grant. . . . unix || die From cclist at sydex.com Sat Feb 23 13:17:54 2019 From: cclist at sydex.com (Chuck Guzis) Date: Sat, 23 Feb 2019 11:17:54 -0800 Subject: Anyone have spare DipStik sockets? In-Reply-To: References: Message-ID: <31520a73-5471-62c7-fedd-b221e325a916@sydex.com> On 2/23/19 10:18 AM, Carl Claunch via cctech wrote: > In the early 1970s a socket to hold multiple DIP chips was being sold under > the brand name DipStik. Up to six chips were inserted in a trough in the > socket, a top screwed on with thumbscrews on the ends. It had solder lugs > on the top and bottom for each of the chip pins. > > We are restoring an old electronic device that was built in part with > these, but due to some corrosion we could use replacement DipStik units if > anyone has them. I assume that you've already contacted these folks: http://www.tzsupplies.com/5-integrated-circuit-prototype-sockets-i1877924/ --Chuck From gerardcjat at free.fr Sun Feb 24 04:03:45 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Sun, 24 Feb 2019 11:03:45 +0100 Subject: BASIC for HP 1000, 21xx series Message-ID: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. Is there some copy still around ?? I had a look in Google, Bitsavers, HPmuseum, with NO success. Thank for help and/or advise. From gerardcjat at free.fr Sun Feb 24 04:03:45 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Sun, 24 Feb 2019 11:03:45 +0100 Subject: BASIC for HP 1000, 21xx series Message-ID: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. Is there some copy still around ?? I had a look in Google, Bitsavers, HPmuseum, with NO success. Thank for help and/or advise. From paulkoning at comcast.net Sun Feb 24 10:51:40 2019 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 24 Feb 2019 11:51:40 -0500 Subject: IBM 3174 C 6.4 Microcode Disks? In-Reply-To: <8442b247-f01e-c2d7-eb5f-45a55a1e6d39@spamtrap.tnetconsulting.net> References: <0BC41A43-8653-4AC1-98CB-88402CE44DAF@comcast.net> <4447ff00-8e63-832c-1e23-912318985807@spamtrap.tnetconsulting.net> <0970e59a-8afc-c160-8f62-75e594d7afef@spamtrap.tnetconsulting.net> <8442b247-f01e-c2d7-eb5f-45a55a1e6d39@spamtrap.tnetconsulting.net> Message-ID: > On Feb 23, 2019, at 3:01 AM, Grant Taylor via cctalk wrote: > > On 2/22/19 6:15 PM, Paul Koning via cctalk wrote: >> SNAP as a way of encoding bridged Ethernet II frames applies only to non-Ethernet LANs, all of which have larger MTU. > > Nope. I'm quite sure that NetBIOS used SNAP on Ethernet. > > I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP. > > IPX could run over SNAP on Ethernet if you wanted to. Yes, but that's not what I was trying to say, apparently not very clearly. There is a translation of Ethernet 2 frames into SNAP (by using an OUI of 00-00-00 or 00-00-F8 followed by the Ethentype). Those particular SNAP values are meant to be used only on LANs different from Ethernet, and bridges connecting those to Ethernet would look for those SNAP values and convert to the corresponding Ethernet 2 format. >> SNAP covers more than encoding bridged Ethernet II. It was intended as a way to carry protocols in 802 format for which you couldn't get a SSAP/DSAP code point (such as private protocols). DEC did this in various places, it's perfectly straightforward. > > *nod* > >> Perhaps some implementations make it hard to support both simultaneously, but there is no technical reason to make such a mistake. > > I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most OSs will not know how to work with TCP in a SNAP frame as they will be expecting Ethernet II frames. > > I don't know that there's a technical reason per say. I do think that there is a market reason. A specific case of the general point above: on Ethernet you'd use 08-00 and 08-06; on non-Ethernet you'd apply RFC 1042 which gives the SNAP equivalents using the 00-00-00 prefix. >> The pretense that broadcast is different from multicast is just a confusion. The description says that it is used for traffic that every station wants to get. If you take that literally, no protocol should use broadcast, because there isn't any protocol that every station on every LAN wants to see. For example, ARP should have used multicast for the same reason DECnet does: it is traffic that is interesting to stations which speak that protocol, and only to those stations. > > Flip things on their head. I think it's that the sender wants every receiving station to see. Yes, but no sender and no protocol has a valid expectation that this is the right thing. >> I think that's right. For 802.5, that is. > > ACK > >> In FDDI the frames are "stripped" by the sending station, which allows things like network monitors in promiscuous mode to work just like on Ethernet > > Intriguing. > >> The claim of collapse under load -- meaning throughput goes down beyond a certain load level -- is valid for ALOHA and similar networks, but not on Ethernet because it uses carrier sense and collision detect. Under overload it runs at close to full utilization. > > Okay. So you weren't saying that Token Ring had problems as much as you were saying that Ethernet can work at close to capacity. > > I remember seeing references to Ethernet would start to have problems with increasing backouts as the number of stations wanting to transmit at the same time would grow. > > Though that may be that the average throughput of a given station may go down while the network segment itself is closer to saturation. That's necessarily true for any sharing system. If you're not sharing you can get up to 100%, give or take how well the scheduling works. Two equal clients each get 50%, and so on. The merit of a sharing system is in how well it approaches 100% total throughput, and how well it delivers the desired split of service among the competing clients. Ethernet and 802.5 and FDDI all do it differently, and all do it pretty well. IBM once put out a marketing document full of FUD about Ethernet, and DEC, Intel, and 3Com (I think) put out a joint rebuttal going point by point (I participated in that effort). I have it in stored away somewhere; should look for it next time I'm in the right spot. paul From paulkoning at comcast.net Sun Feb 24 12:16:31 2019 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 24 Feb 2019 13:16:31 -0500 Subject: PDP-11 LDA BFD backend for gnu binutils In-Reply-To: <6B7C3FA3-CAE1-4162-94A9-314FF76F0936@fritzm.org> References: <6B7C3FA3-CAE1-4162-94A9-314FF76F0936@fritzm.org> Message-ID: > On Feb 23, 2019, at 6:16 PM, Fritz Mueller via cctalk wrote: > > I've been thinking it might be nice to have an LDA BFD backend for gnu binutils, so gas, ld, objdump etc. could deal with LDA's directly without having to use separate conversion utilities. > > Before jumping in on that, though, I thought I'd ask here to see if anybody might have already started or done this? I've noticed several of the folks here also have contributions on some of the binutils lists. > > thanks, > --FritzM. What LDA do you have in mind? Absolute loader binary, for bare metal execution? DOS-11 binary? :-) Part of the issue is that there are a number of different executable forats for PDP-11 -- RSX TSK files (possibly several, if -D and -M differ which I don't know, SAV for RT-11 (and also REL), not to mention the variant wrapper RSTS uses (SIL). paul From bhilpert at shaw.ca Sun Feb 24 12:18:15 2019 From: bhilpert at shaw.ca (Brent Hilpert) Date: Sun, 24 Feb 2019 10:18:15 -0800 Subject: BASIC for HP 1000, 21xx series In-Reply-To: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: On 2019-Feb-24, at 2:03 AM, GerardCJAT via cctalk wrote: > Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. > > Is there some copy still around ?? > > I had a look in Google, Bitsavers, HPmuseum, with NO success. > > Thank for help and/or advise. This is my own writeup about it, including assembler source and loader files, but as noted there it's Guy Sotomayor (list member) that deserves the thanks for keeping it around and making it available: http://madrona.ca/e/HP21xx/software/hpbasic/index.html The source files are also available on bitsavers, link included on above page. From fritzm at fritzm.org Sun Feb 24 12:41:04 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Sun, 24 Feb 2019 10:41:04 -0800 Subject: PDP-11 LDA BFD backend for gnu binutils In-Reply-To: References: <6B7C3FA3-CAE1-4162-94A9-314FF76F0936@fritzm.org> Message-ID: <2A83EF99-CFF0-4CBC-AA79-F64A22AB3329@fritzm.org> > On Feb 24, 2019, at 10:16 AM, Paul Koning wrote: > What LDA do you have in mind? Absolute loader binary, for bare metal execution? I had in mind absolute loader binary for bare metal as a starting point. Most of the coding I?ve had to do on my restoration adventure has been standalone tests and utilities. To date I?ve been using the RT-11 tool chain under SIMH, and copying things in and out via the simulated paper tape reader/punch, but that?s a little cumbersome. I?m now contemplating developing a few more significant standalone utilities that will have both PDP-11 server components and modern PC client components, and it would be nice to be able to build all the parts together in one place using the conventional gnu tooling. I am mostly interested in assembly development for my purposes, but it looks like others have been having pretty good luck with recent gcc on the pdp11-aout target as well. I think I?m most interested in this level of development because it?s what is needed to repair and troubleshoot the machines. After they are up and running, it?s way more fun to do self-hosted development using the real thing (though it does run up the power bill, and I wish I had a better editor under V6 :-)) Cheers, ?FritzM. From couryhouse at aol.com Sun Feb 24 12:47:01 2019 From: couryhouse at aol.com (ED SHARPE) Date: Sun, 24 Feb 2019 18:47:01 +0000 (UTC) Subject: BASIC for HP 1000, 21xx series References: <960434590.4432532.1551034021953.ref@mail.yahoo.com> Message-ID: <960434590.4432532.1551034021953@mail.yahoo.com> DID YOU CHECK? HP MUSEUM DOWN UNDER?? THEY HAVE A FAB? ONLINE COLLECTION OF? SOFTWARE... In a message dated 2/24/2019 3:04:03 AM US Mountain Standard Time, cctalk at classiccmp.org writes: Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. Is there some copy still around ?? I had a look in Google, Bitsavers, HPmuseum, with NO success. Thank for help and/or advise. From couryhouse at aol.com Sun Feb 24 12:47:01 2019 From: couryhouse at aol.com (ED SHARPE) Date: Sun, 24 Feb 2019 18:47:01 +0000 (UTC) Subject: BASIC for HP 1000, 21xx series References: <960434590.4432532.1551034021953.ref@mail.yahoo.com> Message-ID: <960434590.4432532.1551034021953@mail.yahoo.com> DID YOU CHECK? HP MUSEUM DOWN UNDER?? THEY HAVE A FAB? ONLINE COLLECTION OF? SOFTWARE... In a message dated 2/24/2019 3:04:03 AM US Mountain Standard Time, cctalk at classiccmp.org writes: Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. Is there some copy still around ?? I had a look in Google, Bitsavers, HPmuseum, with NO success. Thank for help and/or advise. From couryhouse at aol.com Sun Feb 24 12:51:36 2019 From: couryhouse at aol.com (ED SHARPE) Date: Sun, 24 Feb 2019 18:51:36 +0000 (UTC) Subject: BASIC for HP 1000, 21xx series In-Reply-To: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: <111018453.4407873.1551034296398@mail.yahoo.com> opps? ? ?seem? ?you? checked? HP museum? already? ?.. sorry typed? to? quickly I? seen? to? remember? a? core? resident? ? version of? basic? from paper? tape? but? ?do not? seem to have seen it in? years? ?.... may? be? warehoused? if? ?we? still have? one YES!? it? ?would? be? fin? to play? with! In a message dated 2/24/2019 3:04:03 AM US Mountain Standard Time, cctalk at classiccmp.org writes: Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. Is there some copy still around ?? I had a look in Google, Bitsavers, HPmuseum, with NO success. Thank for help and/or advise. From couryhouse at aol.com Sun Feb 24 12:51:36 2019 From: couryhouse at aol.com (ED SHARPE) Date: Sun, 24 Feb 2019 18:51:36 +0000 (UTC) Subject: BASIC for HP 1000, 21xx series In-Reply-To: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: <111018453.4407873.1551034296398@mail.yahoo.com> opps? ? ?seem? ?you? checked? HP museum? already? ?.. sorry typed? to? quickly I? seen? to? remember? a? core? resident? ? version of? basic? from paper? tape? but? ?do not? seem to have seen it in? years? ?.... may? be? warehoused? if? ?we? still have? one YES!? it? ?would? be? fin? to play? with! In a message dated 2/24/2019 3:04:03 AM US Mountain Standard Time, cctalk at classiccmp.org writes: Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. Is there some copy still around ?? I had a look in Google, Bitsavers, HPmuseum, with NO success. Thank for help and/or advise. From billdegnan at gmail.com Sun Feb 24 15:15:00 2019 From: billdegnan at gmail.com (Bill Degnan) Date: Sun, 24 Feb 2019 16:15:00 -0500 Subject: BASIC for HP 1000, 21xx series In-Reply-To: References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: I have this pocket guide. Probably more that I have not scanned. http://www.vintagecomputer.net/hp/2000A/index.html Bill On Sun, Feb 24, 2019 at 1:18 PM Brent Hilpert via cctalk < cctalk at classiccmp.org> wrote: > On 2019-Feb-24, at 2:03 AM, GerardCJAT via cctalk wrote: > > > Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing > ) on 2116B, 2100A, just for FUN. > > > > Is there some copy still around ?? > > > > I had a look in Google, Bitsavers, HPmuseum, with NO success. > > > > Thank for help and/or advise. > > > This is my own writeup about it, including assembler source and loader > files, but as noted there it's Guy Sotomayor (list member) > that deserves the thanks for keeping it around and making it available: > > http://madrona.ca/e/HP21xx/software/hpbasic/index.html > > The source files are also available on bitsavers, link included on above > page. > > From paulkoning at comcast.net Sun Feb 24 20:04:36 2019 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 24 Feb 2019 21:04:36 -0500 Subject: PDP-11 LDA BFD backend for gnu binutils In-Reply-To: <2A83EF99-CFF0-4CBC-AA79-F64A22AB3329@fritzm.org> References: <6B7C3FA3-CAE1-4162-94A9-314FF76F0936@fritzm.org> <2A83EF99-CFF0-4CBC-AA79-F64A22AB3329@fritzm.org> Message-ID: > On Feb 24, 2019, at 1:41 PM, Fritz Mueller via cctalk wrote: > > >> On Feb 24, 2019, at 10:16 AM, Paul Koning wrote: >> What LDA do you have in mind? Absolute loader binary, for bare metal execution? > > I had in mind absolute loader binary for bare metal as a starting point. That sounds straightforward. > ... > I am mostly interested in assembly development for my purposes, but it looks like others have been having pretty good luck with recent gcc on the pdp11-aout target as well. For the purpose of running the execution tests in the gcc test suite I use a small Python program to convert a.out to a bare metal load tape. It's a bit clunky and it would be cleaner if bfd knew how to do this. So I'd have a use for what you're proposing. I probably wouldn't use it for assembly work, though; the gas assembler is too strange for one trained on DEC tools. paul From cube1 at charter.net Sun Feb 24 23:11:47 2019 From: cube1 at charter.net (Jay Jaeger) Date: Sun, 24 Feb 2019 23:11:47 -0600 Subject: BASIC for HP 1000, 21xx series In-Reply-To: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: I have a set of actual HP paper tapes I acquired with my HP 2114B a number of year ago, including BASIC, FORTRAN and ALGOL. I'd have to look at the manuals to find out if/which required DOS. I have not run any of these images except for some of the diagnostics. I seem to recall that at least one of the tapes had problems, but I don't remember which one. I'll have to look at my notes / files tomorrow. I found what I *think* are the files and also some from Jeff Moffat (http://rikers.org/hp2100/jeff/) - those I'd prefer you got from him. Here are mine, and I will upload them tomorrow. JRJ KIND ID MACHINE CONTENTS COMMENT Checksum Checksum 2 FILENAME MFG SERIAL TRAY DATE AVAILABILI ERRORS PREVIOUS_C PT HP 2114B Diagnostic Config HP HP6 PT 20000-60001 HP 2114B Input Output Control Rev. A HP HP1 PT 20002-60001 HP 2114B BCS Debug Routine Rev. B HP HP1 PT 20005-60001 HP 2114B BCS Tape Reader Drvr D.01 Rev. A HP HP1 PT 20017-60001 HP 2114B BCS TTY Drvr D.00 Rev. B HP HP1 PT 20018-60001 HP 2114B BCS Relocating Loader Rev. E HP HP1 PT 20021-60001 HP 2114B Prepare Control System Rev. B HP HP1 PT 20100-60001 HP 2114B Symbolic Editor Rev. B HP HP1 PT 20306-60001 HP 2114B 8K SIO Tape Rdr Drvr Rev. A HP HP1 PT 20313-60001 HP 2114B 8K SIO Sys Dump Rev. B HP HP2 PT 20392-60001 HP 2114B BASIC Rev. A HP HP2 PT 20392-60002 HP 2114B Prepare BASIC System Rev. A HP HP2 PT 20512-60001 HP 2114B 2115/14 High Mem Checkbd Test Rev. A HP HP2 PT 20524-60001 HP 2114B 2114B DMA Gen. Diag. Rev. A HP HP2 PT 20548-60001 HP 2114B FTN Compiler Pass 1 Rev. A HP HP2 PT 20548-60002 HP 2114B FTN Compiler Pass 2 Rev. A HP HP2 PT 20985-60001 HP 2114B DOS TTY Drvr (DVROO) Rev A HP HP2 PT 20987-60001 HP 2114B DOS PUN Tape Rdr Drvr (DVR01) Rev A HP HP3 PT 24031-60001 HP 2114B EXT. Assembler Non Eau Rev. A HP HP3 PT 24044-60001 HP 2114B ALGOL Compiler Rev. A HP HP3 PT 24109-60001 HP 2114B Cross-Ref Symb Table Gen Rev. A HP HP3 PT 24125-60001 HP 2114B 8K SIO TTY Drvr (LP-Compat) Rev A HP HP3 PT 24146-60001 HP 2114B BCS Relocatable Library (Non-EAU) Rev A HP HP3 PT 24149-60001 HP 2114B BCS FORTRAN IV Library Rev A HP HP3 PT 24150-60001 HP 2114B RTE/DOS Reloc. Library (Non EAU) Rev B HP HP4 PT 24152-60001 HP 2114B RTE/DOS FORTRAN IV Library Rev A HP HP4 PT 24153-60001 HP 2114B RTE/DOS HP FORTRAN Formatter Rev A HP HP4 PT 24154-60001 HP 2114B DOS-M (2870 DISC) System Generator Rev A HP HP4 PT 24154-60002 HP 2114B DOS-M (2870 DISC) Core-Resident Sys. R A HP HP4 PT 24154-60003 HP 2114B DOS-M (2870 DISC) EXEC Modules Rev A HP HP4 PT 24154-60004 HP 2114B DOS-M (2870 DISC) JOB Processor Rev A HP HP4 PT 24155-60001 HP 2114B DOS-M Relocating Loader Rev. A HP HP5 PT 24156-60001 HP 2114B DOS-M 2870 DISC Drvr Rev. A HP HP6 PT 24157-60001 HP 2114B DOS-M System TTY Drvr (DRV05) Rev A HP HP4 PT 24158-60001 HP 2114B DOS-M Assembler Main Control Rev. A HP HP5 PT 24158-60002 HP 2114B DOS-M Assembler Segment D Rev. A HP HP5 PT 24158-60003 HP 2114B DOS-M Assembler Segment 1 Rev. A HP HP5 PT 24158-60004 HP 2114B DOS-M Assembler Segment 2 Rev. A HP HP5 PT 24158-60005 HP 2114B DOS-M Assembler Segment 3 Rev. A HP HP5 PT 24158-60006 HP 2114B DOS-M Assembler Segment 4 Rev. A HP HP5 PT 24158-60007 HP 2114B DOS-M Assembler Segment 5 Rev. A HP HP5 PT 24159-60001 HP 2114B DOS-M FORTRAN Main Control Rev A HP HP6 PT 24159-60002 HP 2114B DOS-M FORTRAN Pass 1 HP HP6 PT 24159-60003 HP 2114B DOS-M FORTRAN Pass 2 HP HP6 PT 24159-60004 HP 2114B DOS-M FORTRAN Pass 3 HP HP6 PT 24159-60005 HP 2114B DOS-M FORTRAN Pass 4 HP HP6 PT 24225-60001 HP 2114B DOS-M System Generator Binary Rev F HP HP6 PT 24390-16001 HP 2114B Long Diagnostic I HP PT 24396-12001 HP 2114B Multiple CPU Memory Diagnostics #1 Bin HP PT 24396-12002 HP 2114B Multiple CPU Memory Diagnostics #2 Bin HP PT 24396-12003 HP 2114B Multiple CPU Memory Diagnostics #3 Bin HP On 2/24/2019 4:03 AM, GerardCJAT via cctalk wrote: > Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. > > Is there some copy still around ?? > > I had a look in Google, Bitsavers, HPmuseum, with NO success. > > Thank for help and/or advise. > > > From cube1 at charter.net Sun Feb 24 23:11:47 2019 From: cube1 at charter.net (Jay Jaeger) Date: Sun, 24 Feb 2019 23:11:47 -0600 Subject: BASIC for HP 1000, 21xx series In-Reply-To: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: I have a set of actual HP paper tapes I acquired with my HP 2114B a number of year ago, including BASIC, FORTRAN and ALGOL. I'd have to look at the manuals to find out if/which required DOS. I have not run any of these images except for some of the diagnostics. I seem to recall that at least one of the tapes had problems, but I don't remember which one. I'll have to look at my notes / files tomorrow. I found what I *think* are the files and also some from Jeff Moffat (http://rikers.org/hp2100/jeff/) - those I'd prefer you got from him. Here are mine, and I will upload them tomorrow. JRJ KIND ID MACHINE CONTENTS COMMENT Checksum Checksum 2 FILENAME MFG SERIAL TRAY DATE AVAILABILI ERRORS PREVIOUS_C PT HP 2114B Diagnostic Config HP HP6 PT 20000-60001 HP 2114B Input Output Control Rev. A HP HP1 PT 20002-60001 HP 2114B BCS Debug Routine Rev. B HP HP1 PT 20005-60001 HP 2114B BCS Tape Reader Drvr D.01 Rev. A HP HP1 PT 20017-60001 HP 2114B BCS TTY Drvr D.00 Rev. B HP HP1 PT 20018-60001 HP 2114B BCS Relocating Loader Rev. E HP HP1 PT 20021-60001 HP 2114B Prepare Control System Rev. B HP HP1 PT 20100-60001 HP 2114B Symbolic Editor Rev. B HP HP1 PT 20306-60001 HP 2114B 8K SIO Tape Rdr Drvr Rev. A HP HP1 PT 20313-60001 HP 2114B 8K SIO Sys Dump Rev. B HP HP2 PT 20392-60001 HP 2114B BASIC Rev. A HP HP2 PT 20392-60002 HP 2114B Prepare BASIC System Rev. A HP HP2 PT 20512-60001 HP 2114B 2115/14 High Mem Checkbd Test Rev. A HP HP2 PT 20524-60001 HP 2114B 2114B DMA Gen. Diag. Rev. A HP HP2 PT 20548-60001 HP 2114B FTN Compiler Pass 1 Rev. A HP HP2 PT 20548-60002 HP 2114B FTN Compiler Pass 2 Rev. A HP HP2 PT 20985-60001 HP 2114B DOS TTY Drvr (DVROO) Rev A HP HP2 PT 20987-60001 HP 2114B DOS PUN Tape Rdr Drvr (DVR01) Rev A HP HP3 PT 24031-60001 HP 2114B EXT. Assembler Non Eau Rev. A HP HP3 PT 24044-60001 HP 2114B ALGOL Compiler Rev. A HP HP3 PT 24109-60001 HP 2114B Cross-Ref Symb Table Gen Rev. A HP HP3 PT 24125-60001 HP 2114B 8K SIO TTY Drvr (LP-Compat) Rev A HP HP3 PT 24146-60001 HP 2114B BCS Relocatable Library (Non-EAU) Rev A HP HP3 PT 24149-60001 HP 2114B BCS FORTRAN IV Library Rev A HP HP3 PT 24150-60001 HP 2114B RTE/DOS Reloc. Library (Non EAU) Rev B HP HP4 PT 24152-60001 HP 2114B RTE/DOS FORTRAN IV Library Rev A HP HP4 PT 24153-60001 HP 2114B RTE/DOS HP FORTRAN Formatter Rev A HP HP4 PT 24154-60001 HP 2114B DOS-M (2870 DISC) System Generator Rev A HP HP4 PT 24154-60002 HP 2114B DOS-M (2870 DISC) Core-Resident Sys. R A HP HP4 PT 24154-60003 HP 2114B DOS-M (2870 DISC) EXEC Modules Rev A HP HP4 PT 24154-60004 HP 2114B DOS-M (2870 DISC) JOB Processor Rev A HP HP4 PT 24155-60001 HP 2114B DOS-M Relocating Loader Rev. A HP HP5 PT 24156-60001 HP 2114B DOS-M 2870 DISC Drvr Rev. A HP HP6 PT 24157-60001 HP 2114B DOS-M System TTY Drvr (DRV05) Rev A HP HP4 PT 24158-60001 HP 2114B DOS-M Assembler Main Control Rev. A HP HP5 PT 24158-60002 HP 2114B DOS-M Assembler Segment D Rev. A HP HP5 PT 24158-60003 HP 2114B DOS-M Assembler Segment 1 Rev. A HP HP5 PT 24158-60004 HP 2114B DOS-M Assembler Segment 2 Rev. A HP HP5 PT 24158-60005 HP 2114B DOS-M Assembler Segment 3 Rev. A HP HP5 PT 24158-60006 HP 2114B DOS-M Assembler Segment 4 Rev. A HP HP5 PT 24158-60007 HP 2114B DOS-M Assembler Segment 5 Rev. A HP HP5 PT 24159-60001 HP 2114B DOS-M FORTRAN Main Control Rev A HP HP6 PT 24159-60002 HP 2114B DOS-M FORTRAN Pass 1 HP HP6 PT 24159-60003 HP 2114B DOS-M FORTRAN Pass 2 HP HP6 PT 24159-60004 HP 2114B DOS-M FORTRAN Pass 3 HP HP6 PT 24159-60005 HP 2114B DOS-M FORTRAN Pass 4 HP HP6 PT 24225-60001 HP 2114B DOS-M System Generator Binary Rev F HP HP6 PT 24390-16001 HP 2114B Long Diagnostic I HP PT 24396-12001 HP 2114B Multiple CPU Memory Diagnostics #1 Bin HP PT 24396-12002 HP 2114B Multiple CPU Memory Diagnostics #2 Bin HP PT 24396-12003 HP 2114B Multiple CPU Memory Diagnostics #3 Bin HP On 2/24/2019 4:03 AM, GerardCJAT via cctalk wrote: > Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. > > Is there some copy still around ?? > > I had a look in Google, Bitsavers, HPmuseum, with NO success. > > Thank for help and/or advise. > > > From ggs at shiresoft.com Sun Feb 24 23:38:33 2019 From: ggs at shiresoft.com (Guy Sotomayor Jr) Date: Sun, 24 Feb 2019 21:38:33 -0800 Subject: BASIC for HP 1000, 21xx series In-Reply-To: References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: I?m glad I had kept it around. I purchased a copy of the listing directly from HP while I was in High School so that I could study how it worked and ?hack? on it to make some changes. I had kept the listing in a special binder. After college I had misplaced the binder and thought it was lost. During one of my moves (around 2006(or so) I discovered that I still had it. I lent it to James Markevitch (another list member) sometime after that who scanned it and OCR?d it and made it available to the community. The binder containing the source listing sits prominently on one of the shelves in my office. It is also loaded into the core of my 2116C that I run from time to time. ;-) TTFN - Guy > On Feb 24, 2019, at 10:18 AM, Brent Hilpert via cctalk wrote: > > On 2019-Feb-24, at 2:03 AM, GerardCJAT via cctalk wrote: > >> Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. >> >> Is there some copy still around ?? >> >> I had a look in Google, Bitsavers, HPmuseum, with NO success. >> >> Thank for help and/or advise. > > > This is my own writeup about it, including assembler source and loader files, but as noted there it's Guy Sotomayor (list member) > that deserves the thanks for keeping it around and making it available: > > http://madrona.ca/e/HP21xx/software/hpbasic/index.html > > The source files are also available on bitsavers, link included on above page. > From gerardcjat at free.fr Mon Feb 25 01:18:26 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Mon, 25 Feb 2019 08:18:26 +0100 Subject: Fw: BASIC for HP 1000, 21xx series Message-ID: Thanks Guys, You are amazing. I got more informations than I can use over the next four weeks ! THANKS. From gerardcjat at free.fr Mon Feb 25 01:18:26 2019 From: gerardcjat at free.fr (GerardCJAT) Date: Mon, 25 Feb 2019 08:18:26 +0100 Subject: Fw: BASIC for HP 1000, 21xx series Message-ID: Thanks Guys, You are amazing. I got more informations than I can use over the next four weeks ! THANKS. From binarydinosaurs at gmail.com Mon Feb 25 07:04:38 2019 From: binarydinosaurs at gmail.com (Adrian Graham) Date: Mon, 25 Feb 2019 13:04:38 +0000 Subject: DECserver 700 PSU fix, H7881-AA Message-ID: Hi folks, My trusty DECserver has bitten the dust in a silent and non-violent way with the fuse still intact so has anyone got tips on troubleshooting? I know it's the PSU because I 'borrowed' another PSU from work and the unit is running again. It's an ASTEC unit under the hood, and in my experience of fixing the older types like the AC8151 (Memotech, TRS80 II/III, Osborne etc) the chief culprits on an utterly dead PSU are the input caps and/or the small 220uF or 330uF startup cap in the feedback circuit. I haven't checked bitsavers etc for a schematic yet, does such a thing exist? Helpfully the ASTEC board doesn't have a model number on it. Cheers -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk From cc at informatik.uni-stuttgart.de Mon Feb 25 10:23:18 2019 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Mon, 25 Feb 2019 17:23:18 +0100 (CET) Subject: HP 85 tapes Message-ID: Hi, what is the recommended way to image HP 85 tape cartridges? The best would be including headers and whatsoever, and to be able to recreate tapes from the images and have a 1:1 duplicate from the original cartridge. I'm almost done with rebelting and imaging our 264x cartridges and would like to continue with the other tapes (85 and 9845). Christian From w9gb at icloud.com Mon Feb 25 12:47:30 2019 From: w9gb at icloud.com (Gregory Beat) Date: Mon, 25 Feb 2019 12:47:30 -0600 Subject: DECserver 700 PSU fix, H7881-AA Message-ID: <6FDB858A-AEBD-4E35-9DC4-EFB39B17BC1D@icloud.com> Adrian - ASTEC is now owned by Emerson Power (UK address below). Emerson Power Catalog (find the 57 watt models): https://www.mouser.com/catalog/supplier/library/pdf/Emersonpower_catalog.pdf PowerClinic in Dallas/Fort Worth area services a large number of Switch-Mode power supplies. http://portal.powerclinicinc.com/web/services Power Clinic Inc. 3732 Arapaho Rd Addison, TX 75001 USA == H7881-AA (Refurbished), $177.00 USD https://www.tamayatech.com/parts.php?g=H7881AA H7881-AA Power Supply, 57 watt , $450.00 USD https://www.ipsystemsinc.com/shopping/pgm-more_information.php?id=630 ASTEC - Europe (UK) Waterfront Business Park Merry Hill, Dudley West Midlands, DY5 1LX United Kingdom Telephone: +44 (0) 1384 842 211 Facsimile: +44 (0) 1384 843 355 == From: Adrian Graham To: "General Discussion: On-Topic and Off-Topic Posts" Subject: DECserver 700 PSU fix, H7881-AA Hi folks, My trusty DECserver has bitten the dust in a silent and non-violent way with the fuse still intact so has anyone got tips on troubleshooting? I know it's the PSU because I 'borrowed' another PSU from work and the unit is running again. It's an ASTEC unit under the hood, and in my experience of fixing the older types like the AC8151 (Memotech, TRS80 II/III, Osborne etc) the chief culprits on an utterly dead PSU are the input caps and/or the small 220uF or 330uF startup cap in the feedback circuit. I haven't checked bitsavers etc for a schematic yet, does such a thing exist? Hopefully the ASTEC board has a model number on it. Cheers -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk From aek at bitsavers.org Mon Feb 25 14:41:47 2019 From: aek at bitsavers.org (Al Kossow) Date: Mon, 25 Feb 2019 12:41:47 -0800 Subject: looking for a couple of alpha micro things Message-ID: CHM has a 1072 with a AM-100L 68000 processor and a scsi interface. one of the boot proms has gone bad, has anyone imaged these? I'm also trying to locate the hardware manual for the AM-620 QIC cartridge tape interface. From curiousmarc3 at gmail.com Mon Feb 25 19:33:57 2019 From: curiousmarc3 at gmail.com (Curious Marc) Date: Mon, 25 Feb 2019 17:33:57 -0800 Subject: HP 85 tapes In-Reply-To: References: Message-ID: The way I have been doing it is to copy the tape files to a LIF floppy disk file (real or just emulated with HPDRIVE), then archive that - either just the HPDRIVE file or a ImageDisk archive of the real disk. Recreating the tape is the inverse process of copying the virtual or real disk to the tape. Marc > On Feb 25, 2019, at 8:23 AM, Christian Corti via cctalk wrote: > > Hi, > > what is the recommended way to image HP 85 tape cartridges? The best would be including headers and whatsoever, and to be able to recreate tapes from the images and have a 1:1 duplicate from the original cartridge. > > I'm almost done with rebelting and imaging our 264x cartridges and would like to continue with the other tapes (85 and 9845). > > Christian From cube1 at charter.net Mon Feb 25 21:05:52 2019 From: cube1 at charter.net (Jay Jaeger) Date: Mon, 25 Feb 2019 21:05:52 -0600 Subject: BASIC for HP 1000, 21xx series In-Reply-To: References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: I have completed my survey of my HP tapes. There is quite a lot of overlap with Jeff Moffat, but some of mine appear to be different than any up on bitsavers. In general, the paper tapes for these systems on bitsavers can be found at: http://bitsavers.org/bits/HP/paperTapes/ MY tapes are *** NOT *** there (at least not yet - unless/until Al decides to copy them up now. ;)) Mine (along with a PDF describing what they are) can be found at: https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU under: bits/HP/paperTapes/JayJ As I mentioned yesterday, I have not tried any of these tapes, aside from few diagnostics - not even under SimH. But they were imaged from HP original tapes I got when I procured my HP 2114, and I am guessing fit the descriptions in "A Pocket Guide to Hewlett-Packard Computers" which I bought for a course (U. Wisc. CS 436) that used an HP 2114 paper tape system back in the day. Today I translated a couple of C programs that I had written back in 1996 to check my images (absolute binary and relocatable) and verified these images with a perl version of those programs. The following manual, on bitsavers, should be pretty close, but I didn't see, for example, the assembler operating instructions in there. http://bitsavers.org/pdf/hp/21xx/5951-4423_A_Pocket_Guide_To_The_2100_Computer_Sep72.pdf I have software (and hardware) manuals for my system, but have not scanned them in. Maybe someday, but probably not soon. The operating procedures for BASIC are likely to be as described in my pocket handbook: 0. Make sure the binary loader is loaded starting at address 017700. These systems have a way to protect that loader, which is really nice. 1. Place the BASIC binary tape in the tape reader 2. Set the switch register to 017700 3. Load Address 4. Set Loader switch to Enabled (HP 2114 Loader Enable to On) 5. PRESET 6. RUN 7. At halt, the T Register should contain 202077 7b. Set the loader swich to PROTECTED (HP 2114 Loader enable to NORMAL) 8. Set the Switch register to the startin address: 000100 9. Load Address 10. Run It should respond with "READY". On 2/24/2019 11:11 PM, Jay Jaeger via cctech wrote: > I have a set of actual HP paper tapes I acquired with my HP 2114B a > number of year ago, including BASIC, FORTRAN and ALGOL. I'd have to > look at the manuals to find out if/which required DOS. I have not run > any of these images except for some of the diagnostics. > > I seem to recall that at least one of the tapes had problems, but I > don't remember which one. I'll have to look at my notes / files tomorrow. > > I found what I *think* are the files and also some from Jeff Moffat > (http://rikers.org/hp2100/jeff/) - those I'd prefer you got from him. > > Here are mine, and I will upload them tomorrow. > > JRJ > > > KIND ID MACHINE CONTENTS COMMENT Checksum Checksum 2 FILENAME MFG > SERIAL TRAY DATE AVAILABILI ERRORS PREVIOUS_C > > PT HP 2114B Diagnostic Config HP HP6 > > PT 20000-60001 HP 2114B Input Output Control Rev. A HP HP1 > > PT 20002-60001 HP 2114B BCS Debug Routine Rev. B HP HP1 > > PT 20005-60001 HP 2114B BCS Tape Reader Drvr D.01 Rev. A HP HP1 > > PT 20017-60001 HP 2114B BCS TTY Drvr D.00 Rev. B HP HP1 > > PT 20018-60001 HP 2114B BCS Relocating Loader Rev. E HP HP1 > > PT 20021-60001 HP 2114B Prepare Control System Rev. B HP HP1 > > PT 20100-60001 HP 2114B Symbolic Editor Rev. B HP HP1 > > PT 20306-60001 HP 2114B 8K SIO Tape Rdr Drvr Rev. A HP HP1 > > PT 20313-60001 HP 2114B 8K SIO Sys Dump Rev. B HP HP2 > > PT 20392-60001 HP 2114B BASIC Rev. A HP HP2 > > PT 20392-60002 HP 2114B Prepare BASIC System Rev. A HP HP2 > > PT 20512-60001 HP 2114B 2115/14 High Mem Checkbd Test Rev. A HP HP2 > > PT 20524-60001 HP 2114B 2114B DMA Gen. Diag. Rev. A HP HP2 > > PT 20548-60001 HP 2114B FTN Compiler Pass 1 Rev. A HP HP2 > > PT 20548-60002 HP 2114B FTN Compiler Pass 2 Rev. A HP HP2 > > PT 20985-60001 HP 2114B DOS TTY Drvr (DVROO) Rev A HP HP2 > > PT 20987-60001 HP 2114B DOS PUN Tape Rdr Drvr (DVR01) Rev A HP HP3 > > PT 24031-60001 HP 2114B EXT. Assembler Non Eau Rev. A HP HP3 > > PT 24044-60001 HP 2114B ALGOL Compiler Rev. A HP HP3 > > PT 24109-60001 HP 2114B Cross-Ref Symb Table Gen Rev. A HP HP3 > > PT 24125-60001 HP 2114B 8K SIO TTY Drvr (LP-Compat) Rev A HP HP3 > > PT 24146-60001 HP 2114B BCS Relocatable Library > (Non-EAU) Rev A HP HP3 > > PT 24149-60001 HP 2114B BCS FORTRAN IV Library Rev A HP HP3 > > PT 24150-60001 HP 2114B RTE/DOS Reloc. Library (Non > EAU) Rev B HP HP4 > > PT 24152-60001 HP 2114B RTE/DOS FORTRAN IV Library Rev A HP HP4 > > PT 24153-60001 HP 2114B RTE/DOS HP FORTRAN Formatter Rev A HP HP4 > > PT 24154-60001 HP 2114B DOS-M (2870 DISC) System > Generator Rev A HP HP4 > > PT 24154-60002 HP 2114B DOS-M (2870 DISC) Core-Resident > Sys. R A HP HP4 > > PT 24154-60003 HP 2114B DOS-M (2870 DISC) EXEC Modules Rev A HP HP4 > > PT 24154-60004 HP 2114B DOS-M (2870 DISC) JOB > Processor Rev A HP HP4 > > PT 24155-60001 HP 2114B DOS-M Relocating Loader Rev. A HP HP5 > > PT 24156-60001 HP 2114B DOS-M 2870 DISC Drvr Rev. A HP HP6 > > PT 24157-60001 HP 2114B DOS-M System TTY Drvr (DRV05) Rev A HP HP4 > > PT 24158-60001 HP 2114B DOS-M Assembler Main Control Rev. A HP HP5 > > PT 24158-60002 HP 2114B DOS-M Assembler Segment D Rev. A HP HP5 > > PT 24158-60003 HP 2114B DOS-M Assembler Segment 1 Rev. A HP HP5 > > PT 24158-60004 HP 2114B DOS-M Assembler Segment 2 Rev. A HP HP5 > > PT 24158-60005 HP 2114B DOS-M Assembler Segment 3 Rev. A HP HP5 > > PT 24158-60006 HP 2114B DOS-M Assembler Segment 4 Rev. A HP HP5 > > PT 24158-60007 HP 2114B DOS-M Assembler Segment 5 Rev. A HP HP5 > > PT 24159-60001 HP 2114B DOS-M FORTRAN Main Control Rev A HP HP6 > > PT 24159-60002 HP 2114B DOS-M FORTRAN Pass 1 HP HP6 > > PT 24159-60003 HP 2114B DOS-M FORTRAN Pass 2 HP HP6 > > PT 24159-60004 HP 2114B DOS-M FORTRAN Pass 3 HP HP6 > > PT 24159-60005 HP 2114B DOS-M FORTRAN Pass 4 HP HP6 > > PT 24225-60001 HP 2114B DOS-M System Generator Binary Rev F HP HP6 > > PT 24390-16001 HP 2114B Long Diagnostic I HP > > PT 24396-12001 HP 2114B Multiple CPU Memory Diagnostics #1 Bin HP > > PT 24396-12002 HP 2114B Multiple CPU Memory Diagnostics #2 Bin HP > > PT 24396-12003 HP 2114B Multiple CPU Memory Diagnostics #3 Bin HP > > > On 2/24/2019 4:03 AM, GerardCJAT via cctalk wrote: >> Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. >> >> Is there some copy still around ?? >> >> I had a look in Google, Bitsavers, HPmuseum, with NO success. >> >> Thank for help and/or advise. >> >> >> > From cc at informatik.uni-stuttgart.de Tue Feb 26 02:40:45 2019 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Tue, 26 Feb 2019 09:40:45 +0100 (CET) Subject: HP 85 tapes In-Reply-To: References: Message-ID: On Mon, 25 Feb 2019, it was written > The way I have been doing it is to copy the tape files to a LIF floppy > disk file (real or just emulated with HPDRIVE), then archive that - > either just the HPDRIVE file or a ImageDisk archive of the real disk. > Recreating the tape is the inverse process of copying the virtual or > real disk to the tape. And what about SECUREd files? I'm thinking of a binary program that ideally dumps the cartridge to e.g a single floppy disk file. I've done something similarly for the IBM 5110, but I'm no HP 85 expert at all. There's quite a large HP community, I can't imagine that nobody has attempted that before. Christian From cc at informatik.uni-stuttgart.de Tue Feb 26 02:59:46 2019 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Tue, 26 Feb 2019 09:59:46 +0100 (CET) Subject: BASIC for HP 1000, 21xx series In-Reply-To: References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: On Mon, 25 Feb 2019, Jay Jaeger wrote: > The operating procedures for BASIC are likely to be as described in my > pocket handbook: It's also described in the HP 2116 Operator's Guide: ftp://computermuseum.informatik.uni-stuttgart.de/hp/21xx/docs/02116-9057_OperatorsGuide_Dec1970.pdf Christian From cc at informatik.uni-stuttgart.de Tue Feb 26 07:07:02 2019 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Tue, 26 Feb 2019 14:07:02 +0100 (CET) Subject: HP 85 tapes In-Reply-To: References: Message-ID: On Tue, 26 Feb 2019, Christian Corti wrote: > And what about SECUREd files? I'm thinking of a binary program that ideally > dumps the cartridge to e.g a single floppy disk file. I've done something > similarly for the IBM 5110, but I'm no HP 85 expert at all. > There's quite a large HP community, I can't imagine that nobody has attempted > that before. Meanwhile, I've found this: http://www.biblewitness.org/technical/HP_Series-80/HP-85/ASSM/TAPDUPS.TXT But I have no idea what it does. It sounds interesting, though. Any HP 85 experts here who can comment on this program? Christian From drlegendre at gmail.com Tue Feb 26 10:23:21 2019 From: drlegendre at gmail.com (drlegendre) Date: Tue, 26 Feb 2019 10:23:21 -0600 Subject: Seeking 4067 DRAM ICs Message-ID: Howdy friends, In need of 8 pcs. MT4067-15 or equiv. to fill out the RAM board in a Tandy 1000 EX. These are 64k x 4bit I believe. Just checking to see if a group member might have some stashed away? From curiousmarc3 at gmail.com Tue Feb 26 12:30:05 2019 From: curiousmarc3 at gmail.com (Curious Marc) Date: Tue, 26 Feb 2019 10:30:05 -0800 Subject: HP 85 tapes In-Reply-To: References: Message-ID: Christian, This I don?t know. You should join the hp 80 group on groups.io and ask there: https://groups.io/g/hpseries80 Some of the original engineers for the 85 are on there, they know every detail, and are incredibly helpful. Marc > On Feb 26, 2019, at 12:40 AM, Christian Corti via cctalk wrote: > > On Mon, 25 Feb 2019, it was written >> The way I have been doing it is to copy the tape files to a LIF floppy disk file (real or just emulated with HPDRIVE), then archive that - either just the HPDRIVE file or a ImageDisk archive of the real disk. Recreating the tape is the inverse process of copying the virtual or real disk to the tape. > > And what about SECUREd files? I'm thinking of a binary program that ideally dumps the cartridge to e.g a single floppy disk file. I've done something similarly for the IBM 5110, but I'm no HP 85 expert at all. > There's quite a large HP community, I can't imagine that nobody has attempted that before. > > Christian From spacewar at gmail.com Tue Feb 26 13:10:24 2019 From: spacewar at gmail.com (Eric Smith) Date: Tue, 26 Feb 2019 12:10:24 -0700 Subject: Seeking 4067 DRAM ICs In-Reply-To: References: Message-ID: On Tue, Feb 26, 2019 at 9:23 AM drlegendre via cctalk wrote: > In need of 8 pcs. MT4067-15 or equiv. to fill out the RAM board in a Tandy > 1000 EX. These are 64k x 4bit I believe. > You should be able to use the 4464, which are much easier to find. From phb.hfx at gmail.com Tue Feb 26 20:22:51 2019 From: phb.hfx at gmail.com (Paul Berger) Date: Tue, 26 Feb 2019 22:22:51 -0400 Subject: HP 85 tapes In-Reply-To: References: Message-ID: <61f56c68-ed5a-0396-6e60-75aa638d8115@gmail.com> On 2019-02-26 9:07 a.m., Christian Corti via cctalk wrote: > On Tue, 26 Feb 2019, Christian Corti wrote: >> And what about SECUREd files? I'm thinking of a binary program that >> ideally dumps the cartridge to e.g a single floppy disk file. I've >> done something similarly for the IBM 5110, but I'm no HP 85 expert at >> all. >> There's quite a large HP community, I can't imagine that nobody has >> attempted that before. > > Meanwhile, I've found this: > http://www.biblewitness.org/technical/HP_Series-80/HP-85/ASSM/TAPDUPS.TXT > > But I have no idea what it does. It sounds interesting, though. Any HP > 85 experts here who can comment on this program? > > Christian Well a quick google and I found this http://vintagecomputers.site90.net/hp85/hp9915_eprom.htm it would seem that this was one of the tools used to build images of programs to burn into EPROMs for? 9915 which is a version of the 85 designed to be used as an embedded controller. Paul. From aek at bitsavers.org Tue Feb 26 21:07:36 2019 From: aek at bitsavers.org (Al Kossow) Date: Tue, 26 Feb 2019 19:07:36 -0800 Subject: New high-resolution Alpha Micro manual scans Message-ID: <640b5568-a20f-4853-8677-b2435f93622d@bitsavers.org> http://bitsavers.org/pdf/alphaMicrosystems/amos From curiousmarc3 at gmail.com Tue Feb 26 23:15:35 2019 From: curiousmarc3 at gmail.com (Curious Marc) Date: Tue, 26 Feb 2019 21:15:35 -0800 Subject: BASIC for HP 1000, 21xx series In-Reply-To: References: <5FB6EB64B2364DCD8AEC1EBE41983ADC@medion> Message-ID: <380EB241-9F7C-467B-919F-681CCA710A65@gmail.com> Excellent write up Brent. We?ll refer to it when/if we get our 2116 going! Marc > On Feb 24, 2019, at 10:18 AM, Brent Hilpert via cctalk wrote: > >> On 2019-Feb-24, at 2:03 AM, GerardCJAT via cctalk wrote: >> >> Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN. >> >> Is there some copy still around ?? >> >> I had a look in Google, Bitsavers, HPmuseum, with NO success. >> >> Thank for help and/or advise. > > > This is my own writeup about it, including assembler source and loader files, but as noted there it's Guy Sotomayor (list member) > that deserves the thanks for keeping it around and making it available: > > http://madrona.ca/e/HP21xx/software/hpbasic/index.html > > The source files are also available on bitsavers, link included on above page. > From cc at informatik.uni-stuttgart.de Wed Feb 27 02:39:26 2019 From: cc at informatik.uni-stuttgart.de (Christian Corti) Date: Wed, 27 Feb 2019 09:39:26 +0100 (CET) Subject: HP 85 tapes In-Reply-To: <61f56c68-ed5a-0396-6e60-75aa638d8115@gmail.com> References: <61f56c68-ed5a-0396-6e60-75aa638d8115@gmail.com> Message-ID: On Tue, 26 Feb 2019, Paul Berger wrote: > Well a quick google and I found this > http://vintagecomputers.site90.net/hp85/hp9915_eprom.htm it would seem that > this was one of the tools used to build images of programs to burn into > EPROMs for? 9915 which is a version of the 85 designed to be used as an > embedded controller. I don't think this is the same program. The TAPDUP I'm looking at has 13 tokens/commands, none of which is mentioned in any of the 9915 docs. Christian From j_hoppe at t-online.de Wed Feb 27 01:07:45 2019 From: j_hoppe at t-online.de (=?UTF-8?Q?J=c3=b6rg_Hoppe?=) Date: Wed, 27 Feb 2019 08:07:45 +0100 Subject: Another DEC UNIBUS signal adapter: UniProbe Message-ID: <86030aa6-9a50-a2bc-3787-a9a880b5876c@t-online.de> Hi, most people dealing seriously with older PDP-11s have found means to monitor the UNIBUS traffic. My latest approach is www.retrocmp.com/tools/uniprobe UniProbe is a M9302 terminator, a LED display, a probe for logic analyzer. It can be mounted in Standard or Modified UNIBUS sockets. I'm ordering a batch of PCBs in a few days and will show this and other stuff (UniBone, BlinkenBone) at VCFPNW in Seattle. https://vcfed.org/wp/festivals/vintage-computer-festival-pacific-northwest/ best regards, Joerg From Martin.Hepperle at MH-AeroTools.de Wed Feb 27 04:58:22 2019 From: Martin.Hepperle at MH-AeroTools.de (Martin.Hepperle at MH-AeroTools.de) Date: Wed, 27 Feb 2019 11:58:22 +0100 Subject: HP 85 tapes Message-ID: <007701d4ce8b$5bc77000$13565000$@MH-AeroTools.de> Christian, the TAPDUP binary and associated utility programs in BASIC was used to create EPROMs with programs and data for the 9915 Series-80 box. It can be used to read the directory record and then to read tokenized PROGrams as data on a file-record base - not at low record level. The package also contains programs to massage the PROG data into BASIC DATA statements for creating EPROM burner files. You could use it to read the tape directory and individual PROG files but right now I am not aware of a program which would write this data back to a tape. You would open the directory, look up a file and then OPEN IMAGE it. Next you would READ RECORD IMAGE$ the program record by record. In the end you have not gained much compared to the simple COPY statement. Except for the copy of the directory with attributes and security flags. Alternative: There are also READSECTOR binary programs for reading raw 256 byte records/sectors from disks. They also work on the tape ":T" but seem to start their record count after the directory records. On disks, record 0 is the first real sector. So, to get the complete binary content one could use C$=CATALOG$ from TAPDUP to read the directory record READSECTOR N,R$,D from to read the subsequent raw "data" records. Here are my notes on some of the functions in this binary program: The TAPDUP Binary (Notes by M. Hepperle) This binary contains functions to read tapes (HP-85, 9915) at low level. It does not handle disks. The program was part of the "Tape Duplication and EPROM Programming Pack" (09915-10010). As the original software was not available the binary was re-assembled from an assembler source file. This source file was obviously created by disassembling the original binary. It was found at M. Craggs web site: http://www.biblewitness.org/technical/HP_Series-80/HP-85/ASSM . Martin Craggs home-made disassembler produced many unnecessary DRP and ARP statements, which could be cleaned up to improve readbility. Functions in the TAPDUP binary: C$=CATALOG$ Return the directory record of the tape in form of a 512 byte buffer (2 records). C$ must be DIMed to at least 512. OPEN IMAGE F$ Find the file F$ and open it for reading. ERRN=67: file not found T=READTYPE Return the file type of the currently opened image (the file image must be opened by a preceding call to OPEN IMAGE) 34 = PROG N$=READNAME$ Return the file name of the currently opened image (the file image must be opened by a preceding call to OPEN IMAGE) R$=READ RECORD IMAGE$ Read the next record of the currently opened file. The record has a length of 256 bytes. Reading can be continued by another READ RECORD IMAGE$ until ERRN=71 indicates a read behind the end of the file. See lines 440 ff in IMAGE program for a typical reading loop. (the file image must be opened by a preceding call to OPEN IMAGE) ERRN=71: end of file reached. CREATE IMAGE S$,I,J,K 3 numeric parameters WRITE IMAGE R$ Write record to (where?) "Error 244: No file open" WRITE CATALOG C$ Writes the catalogue back to disk. C$ must contain a valid catalog structure, otherwise your tape will be unreadable afterwards. READLOGLEN Read the logical record length, which is 256. Another useful function in the Program Development ROM C$=CHECKSUM$(S$) Return the IBM SDLC CRC checksum of the given string (the length of the checksum is two bytes). Example: dumping the tape catalog Each catalog entry is 12 bytes 10 DIM C$[512] 20 C$=CATALOG$ 30 K=1 40 FOR I=1 TO 504 STEP 12 50 FOR J=1 TO 12 60 PRINT C$[K,K]; 70 K=K+1 80 NEXT J 90 PRINT 100 NEXT I 110 PRINT 120 END Tape documentation lifted from Everett Kaser's Series-80 Emulator (I hope Everett won't sue me for this blatant copyright infringement): TAPE LAYOUT ------------------------------------------------------- The HP-85 tape cartridges contained at most 43 files. File 0 was always the TAPE DIRECTORY, and was always 4 records long. Files 1-42 were the user-created files. The tape itself had 2 TRACKS, 0 and 1. There were TWO COPIES of the TAPE DIRECTORY, one in records 0 and 1 of file 0, and a second in records 2 and 3 of file 0. Record 2 was an exact duplicate of record 0, and record 3 was an exact duplicate of record 1. Only one record of the directory could be read into memory at a time, so the system had to keep track of whether the first 1/2 or the second 1/2 of the directory was in memory (or neither). Each DIRECTORY RECORD consisted of 21 12-byte directory entries, which equals 252 bytes. The final 4 bytes of each record as follows: 252 directory segment flag (0 or 1). 253 FILE# of file that wraps from the end of TRACK 0 to the beginning of TRACK 1. 254 (2 bytes) RECORD# of first record of the split file 255 that's on TRACK 1. Each DIRECTORY ENTRY consists of 12 bytes, allocated thusly: BYTES DESCRIPTION ----- --------------------------------------------- 0-5 ASCII FILE NAME, blank filled 6 EXTENDED File Type 7 FILE TYPE 8-9 # RECORDS in the file 10-11 # BYTES in each record The FILE TYPE is thus: BIT DESCRIPTION --- ----------------------------------------------- 0 No directory name listed 1 Soft write protect 2 Extended file type (****) 3 Binary Program (BPGM) 4 Data file (DATA) 5 BASIC Program (PRGM) 6 Empty file (NULL) 7 Next available file The most significant bit of the EXTENDED FILE TYPE byte will signify extended file type as well as BIT 2 of FILE TYPE, but it shouldn't be used, as a bug in the system doesn't clear that bit if you purge the file. The lower seven bits allow the differentiation between various extended file types (****). From lproven at gmail.com Wed Feb 27 05:13:14 2019 From: lproven at gmail.com (Liam Proven) Date: Wed, 27 Feb 2019 12:13:14 +0100 Subject: Mystery old computer & terminals on eBay UK Message-ID: I don't recognise this, but I'm no expert. https://www.ebay.co.uk/itm/113665872765 -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From billdegnan at gmail.com Wed Feb 27 05:19:53 2019 From: billdegnan at gmail.com (Bill Degnan) Date: Wed, 27 Feb 2019 06:19:53 -0500 Subject: Mystery old computer & terminals on eBay UK In-Reply-To: References: Message-ID: On Wed, Feb 27, 2019, 6:13 AM Liam Proven via cctalk wrote: > I don't recognise this, but I'm no expert. > > https://www.ebay.co.uk/itm/113665872765 > > -- > Could be a 9 track tape or storage drive/cart storage unit? Or some sort of peripheral? Bill > From jon at jonworld.com Wed Feb 27 05:25:49 2019 From: jon at jonworld.com (Jonathan Katz) Date: Wed, 27 Feb 2019 11:25:49 +0000 Subject: Mystery old computer & terminals on eBay UK In-Reply-To: References: Message-ID: Some google shows BCL=Business Computers Limited (potentially) Or maybe one of these: http://webcache.googleusercontent.com/search?q=cache:mBGDWqY-bzkJ:www.tnmoc.org/special-projects/lost-systems/bcl-molecular-computer+&cd=4&hl=en&ct=clnk&gl=uk On Wed, Feb 27, 2019 at 11:13 AM Liam Proven via cctalk < cctalk at classiccmp.org> wrote: > I don't recognise this, but I'm no expert. > > https://www.ebay.co.uk/itm/113665872765 > > -- > Liam Proven - Profile: https://about.me/liamproven > Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com > Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven > UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 > -- -Jon +44 7792 149029 From binarydinosaurs at gmail.com Wed Feb 27 05:36:49 2019 From: binarydinosaurs at gmail.com (Adrian Graham) Date: Wed, 27 Feb 2019 11:36:49 +0000 Subject: Mystery old computer & terminals on eBay UK In-Reply-To: References: Message-ID: I thought that was a variant of the BCL Mollie, aka Molecular 18 but google disagrees with me. TnMOC have 2 of them so I'll ask the volunteers. -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk On Wed, 27 Feb 2019 at 11:13, Liam Proven via cctalk wrote: > I don't recognise this, but I'm no expert. > > https://www.ebay.co.uk/itm/113665872765 > > -- > Liam Proven - Profile: https://about.me/liamproven > Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com > Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven > UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 > From lproven at gmail.com Wed Feb 27 05:41:33 2019 From: lproven at gmail.com (Liam Proven) Date: Wed, 27 Feb 2019 12:41:33 +0100 Subject: Mystery old computer & terminals on eBay UK In-Reply-To: References: Message-ID: On Wed, 27 Feb 2019 at 12:24, Jonathan Katz wrote: > > Some google shows BCL=Business Computers Limited (potentially) Foolishly I didn't read the comments first. It's one of these: http://www.ps8computing.co.uk/bcl.html -- Liam Proven - Profile: https://about.me/liamproven Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From binarydinosaurs at gmail.com Wed Feb 27 06:30:44 2019 From: binarydinosaurs at gmail.com (Adrian Graham) Date: Wed, 27 Feb 2019 12:30:44 +0000 Subject: Mystery old computer & terminals on eBay UK In-Reply-To: References: Message-ID: Go me :) I've not laid eyes on one of those since I hefted them out of the main computer suite in TnMOC's H-Block back in the noughties so we could clean the room before the arrival of the ICL 2966. I hope they're still around. -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk On Wed, 27 Feb 2019 at 11:41, Liam Proven via cctalk wrote: > On Wed, 27 Feb 2019 at 12:24, Jonathan Katz wrote: > > > > Some google shows BCL=Business Computers Limited (potentially) > > Foolishly I didn't read the comments first. > > It's one of these: > > http://www.ps8computing.co.uk/bcl.html > > -- > Liam Proven - Profile: https://about.me/liamproven > Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com > Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven > UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 > From sales at elecplus.com Wed Feb 27 12:06:25 2019 From: sales at elecplus.com (Electronics Plus) Date: Wed, 27 Feb 2019 12:06:25 -0600 Subject: DECserver 700 PSU fix, H7881-AA In-Reply-To: <6FDB858A-AEBD-4E35-9DC4-EFB39B17BC1D@icloud.com> References: <6FDB858A-AEBD-4E35-9DC4-EFB39B17BC1D@icloud.com> Message-ID: <0c6101d4cec7$28494050$78dbc0f0$@com> https://shop.mitservices.com/product/digital-dec-server-700-psu-h7881-aa/ in stock in the UK. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Gregory Beat via cctalk Sent: Monday, February 25, 2019 12:48 PM To: binarydinosaurs at gmail.com; cctalk at classiccmp.org Subject: Re: DECserver 700 PSU fix, H7881-AA Adrian - ASTEC is now owned by Emerson Power (UK address below). Emerson Power Catalog (find the 57 watt models): https://www.mouser.com/catalog/supplier/library/pdf/Emersonpower_catalog.pdf PowerClinic in Dallas/Fort Worth area services a large number of Switch-Mode power supplies. http://portal.powerclinicinc.com/web/services Power Clinic Inc. 3732 Arapaho Rd Addison, TX 75001 USA == H7881-AA (Refurbished), $177.00 USD https://www.tamayatech.com/parts.php?g=H7881AA H7881-AA Power Supply, 57 watt , $450.00 USD https://www.ipsystemsinc.com/shopping/pgm-more_information.php?id=630 ASTEC - Europe (UK) Waterfront Business Park Merry Hill, Dudley West Midlands, DY5 1LX United Kingdom Telephone: +44 (0) 1384 842 211 Facsimile: +44 (0) 1384 843 355 == From: Adrian Graham To: "General Discussion: On-Topic and Off-Topic Posts" Subject: DECserver 700 PSU fix, H7881-AA Hi folks, My trusty DECserver has bitten the dust in a silent and non-violent way with the fuse still intact so has anyone got tips on troubleshooting? I know it's the PSU because I 'borrowed' another PSU from work and the unit is running again. It's an ASTEC unit under the hood, and in my experience of fixing the older types like the AC8151 (Memotech, TRS80 II/III, Osborne etc) the chief culprits on an utterly dead PSU are the input caps and/or the small 220uF or 330uF startup cap in the feedback circuit. I haven't checked bitsavers etc for a schematic yet, does such a thing exist? Hopefully the ASTEC board has a model number on it. Cheers -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From binarydinosaurs at gmail.com Wed Feb 27 12:50:44 2019 From: binarydinosaurs at gmail.com (Adrian Graham) Date: Wed, 27 Feb 2019 18:50:44 +0000 Subject: DECserver 700 PSU fix, H7881-AA In-Reply-To: <0c6101d4cec7$28494050$78dbc0f0$@com> References: <6FDB858A-AEBD-4E35-9DC4-EFB39B17BC1D@icloud.com> <0c6101d4cec7$28494050$78dbc0f0$@com> Message-ID: Hi folks, Thanks for the links, I should?ve said I work for a DEC/HPE reseller so I can get replacements through work but I thought there might be some folk here who?ve fixed one before and might have some tips. Cheers again Adrian > On 27 Feb 2019, at 18:06, Electronics Plus via cctalk wrote: > > https://shop.mitservices.com/product/digital-dec-server-700-psu-h7881-aa/ > in stock in the UK. > > -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Gregory > Beat via cctalk > Sent: Monday, February 25, 2019 12:48 PM > To: binarydinosaurs at gmail.com; cctalk at classiccmp.org > Subject: Re: DECserver 700 PSU fix, H7881-AA > > Adrian - > > ASTEC is now owned by Emerson Power (UK address below). > Emerson Power Catalog (find the 57 watt models): > https://www.mouser.com/catalog/supplier/library/pdf/Emersonpower_catalog.pdf > > PowerClinic in Dallas/Fort Worth area > services a large number of Switch-Mode power supplies. > http://portal.powerclinicinc.com/web/services > Power Clinic Inc. > 3732 Arapaho Rd > Addison, TX 75001 > USA > == > H7881-AA (Refurbished), $177.00 USD > https://www.tamayatech.com/parts.php?g=H7881AA > > H7881-AA Power Supply, 57 watt , $450.00 USD > https://www.ipsystemsinc.com/shopping/pgm-more_information.php?id=630 > > ASTEC - Europe (UK) > Waterfront Business Park > Merry Hill, Dudley > West Midlands, DY5 1LX > United Kingdom > Telephone: +44 (0) 1384 842 211 > Facsimile: +44 (0) 1384 843 355 > == > From: Adrian Graham > To: "General Discussion: On-Topic and Off-Topic Posts" > Subject: DECserver 700 PSU fix, H7881-AA > > Hi folks, > > My trusty DECserver has bitten the dust in a silent and non-violent way > with the fuse still intact so has anyone got tips on troubleshooting? I > know it's the PSU because I 'borrowed' another PSU from work and the unit > is running again. It's an ASTEC unit under the hood, and in my experience > of fixing the older types like the AC8151 (Memotech, TRS80 II/III, Osborne > etc) the chief culprits on an utterly dead PSU are the input caps and/or > the small 220uF or 330uF startup cap in the feedback circuit. > > I haven't checked bitsavers etc for a schematic yet, does such a thing > exist? > Hopefully the ASTEC board has a model number on it. > > Cheers > -- > adrian/witchy > Owner of Binary Dinosaurs, the UK's biggest private home computer > collection? > t: @binarydinosaurs > f: facebook.com/binarydinosaurs > w: www.binarydinosaurs.co.uk > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk From jnc at mercury.lcs.mit.edu Wed Feb 27 13:37:56 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 27 Feb 2019 14:37:56 -0500 (EST) Subject: PDP-11/60 manuals needed Message-ID: <20190227193756.4908818C086@mercury.lcs.mit.edu> Hi, does anyone have any PDP-11/60 manuals? I went to do articles on the -11/60 and its CPU (KD11-K), but there isn't much online. Bitsavers has EK-KD11K-TD-PRE, but it only covers the maintenance features, not the whole CPU; there is a tech manual - KD11K-TM-001 (I have it in fiche, but my fiche reader has a burned out bulb which I have not yet been able to replace, so it doesn't do me much good). There is a user manual for the FP11-E, which has a certain amount of useful details, but it refers to the technical manual, which is not there. And there's EK-11060-SV-01, which covers the cabinet and power supply. So if anyone has the general -11/60 manual, or the KD11-K tech manual, those would be super useful. The FP11-E tech manual would be nice to have, but isn't as important as the others. Thanks (I hope!)! Noel From derschjo at gmail.com Wed Feb 27 13:56:34 2019 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 27 Feb 2019 11:56:34 -0800 Subject: PDP-11/60 manuals needed In-Reply-To: <20190227193756.4908818C086@mercury.lcs.mit.edu> References: <20190227193756.4908818C086@mercury.lcs.mit.edu> Message-ID: On Wed, Feb 27, 2019 at 11:38 AM Noel Chiappa via cctalk < cctalk at classiccmp.org> wrote: > Hi, does anyone have any PDP-11/60 manuals? I went to do articles on the > -11/60 and its CPU (KD11-K), but there isn't much online. > > Bitsavers has EK-KD11K-TD-PRE, but it only covers the maintenance features, > not the whole CPU; there is a tech manual - KD11K-TM-001 (I have it in > fiche, > but my fiche reader has a burned out bulb which I have not yet been able to > replace, so it doesn't do me much good). There is a user manual for the > FP11-E, which has a certain amount of useful details, but it refers to the > technical manual, which is not there. And there's EK-11060-SV-01, which > covers > the cabinet and power supply. > > So if anyone has the general -11/60 manual, or the KD11-K tech manual, > those > would be super useful. The FP11-E tech manual would be nice to have, but > isn't > as important as the others. > > Thanks (I hope!)! > > Noel > I recently picked up a copy of the PDP-11/60 Processor Handbook, not sure if that's useful for your research, but if it is let me know... - Josh From jnc at mercury.lcs.mit.edu Wed Feb 27 14:03:02 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 27 Feb 2019 15:03:02 -0500 (EST) Subject: PDP-11/60 manuals needed Message-ID: <20190227200302.93F5418C086@mercury.lcs.mit.edu> > From: Josh Dersch > I recently picked up a copy of the PDP-11/60 Processor Handbook, not > sure if that's useful for your research Yes, it almost certainly is (without seeing it, I can't be 100%, but it sounds like it is). Is it by any chance EK-KD11K-TM-001? Thanks! Noel From billdegnan at gmail.com Wed Feb 27 14:10:00 2019 From: billdegnan at gmail.com (Bill Degnan) Date: Wed, 27 Feb 2019 15:10:00 -0500 Subject: PDP-11/60 manuals needed In-Reply-To: <20190227200302.93F5418C086@mercury.lcs.mit.edu> References: <20190227200302.93F5418C086@mercury.lcs.mit.edu> Message-ID: > > > > > Yes, it almost certainly is (without seeing it, I can't be 100%, but it > sounds > like it is). Is it by any chance EK-KD11K-TM-001? > > Thanks! > > Noel > The 11/60 handbook doesn't have that kind of designation. It's EB06498 From leec2124 at gmail.com Wed Feb 27 14:36:05 2019 From: leec2124 at gmail.com (Lee Courtney) Date: Wed, 27 Feb 2019 12:36:05 -0800 Subject: PDP-11/60 manuals needed In-Reply-To: <20190227193756.4908818C086@mercury.lcs.mit.edu> References: <20190227193756.4908818C086@mercury.lcs.mit.edu> Message-ID: Ho Noel, 2485 "11/60" text items in the CHM Collection here: https://www.computerhistory.org/collections/search/?s=11%2F60&f=text HTH - Lee C. On Wed, Feb 27, 2019 at 11:38 AM Noel Chiappa via cctalk < cctalk at classiccmp.org> wrote: > Hi, does anyone have any PDP-11/60 manuals? I went to do articles on the > -11/60 and its CPU (KD11-K), but there isn't much online. > > Bitsavers has EK-KD11K-TD-PRE, but it only covers the maintenance features, > not the whole CPU; there is a tech manual - KD11K-TM-001 (I have it in > fiche, > but my fiche reader has a burned out bulb which I have not yet been able to > replace, so it doesn't do me much good). There is a user manual for the > FP11-E, which has a certain amount of useful details, but it refers to the > technical manual, which is not there. And there's EK-11060-SV-01, which > covers > the cabinet and power supply. > > So if anyone has the general -11/60 manual, or the KD11-K tech manual, > those > would be super useful. The FP11-E tech manual would be nice to have, but > isn't > as important as the others. > > Thanks (I hope!)! > > Noel > -- Lee Courtney +1-650-704-3934 cell From ggs at shiresoft.com Wed Feb 27 11:44:45 2019 From: ggs at shiresoft.com (Guy Sotomayor Jr) Date: Wed, 27 Feb 2019 09:44:45 -0800 Subject: Another DEC UNIBUS signal adapter: UniProbe In-Reply-To: <86030aa6-9a50-a2bc-3787-a9a880b5876c@t-online.de> References: <86030aa6-9a50-a2bc-3787-a9a880b5876c@t-online.de> Message-ID: <8CFAD206-13A7-4996-8923-97772F8CBBB5@shiresoft.com> Did you happen to take a look at my UA11? It?s different in that it goes into an SPC slot. TTFN - Guy > On Feb 26, 2019, at 11:07 PM, J?rg Hoppe via cctech wrote: > > Hi, > > most people dealing seriously with older PDP-11s have found means to monitor the UNIBUS traffic. > My latest approach is www.retrocmp.com/tools/uniprobe > UniProbe is a M9302 terminator, a LED display, a probe for logic analyzer. > It can be mounted in Standard or Modified UNIBUS sockets. > > I'm ordering a batch of PCBs in a few days and will show this and other stuff (UniBone, BlinkenBone) at VCFPNW in Seattle. > https://vcfed.org/wp/festivals/vintage-computer-festival-pacific-northwest/ > > best regards, > Joerg > From aperry at snowmoose.com Wed Feb 27 12:22:44 2019 From: aperry at snowmoose.com (Alan Perry) Date: Wed, 27 Feb 2019 10:22:44 -0800 Subject: Rainbow 100 PSU capacitor list Message-ID: <12e44837-b9d9-d525-2535-2231e96b0975@snowmoose.com> Hi, I think that I need to re-cap the power supply in a Rainbow 100. Does anyone here know if anyone has put together a list of capacitors used in the power supply that I can use to order parts? alan From j_hoppe at t-online.de Wed Feb 27 14:24:43 2019 From: j_hoppe at t-online.de (=?UTF-8?Q?J=c3=b6rg_Hoppe?=) Date: Wed, 27 Feb 2019 21:24:43 +0100 Subject: Another DEC UNIBUS signal adapter: UniProbe In-Reply-To: <8CFAD206-13A7-4996-8923-97772F8CBBB5@shiresoft.com> References: <86030aa6-9a50-a2bc-3787-a9a880b5876c@t-online.de> <8CFAD206-13A7-4996-8923-97772F8CBBB5@shiresoft.com> Message-ID: <50bdbb71-36e1-7c80-b6b1-d7f77fdd9015@t-online.de> Hi, > Did you happen to take a look at my UA11? It?s different in that it goes into an SPC slot. Yes, I was pointed to it after UniProbe was out. Good I saw it not earlier, would have killed my project ;-) best regards, Joerg > > TTFN - Guy > >> On Feb 26, 2019, at 11:07 PM, J?rg Hoppe via cctech wrote: >> >> Hi, >> >> most people dealing seriously with older PDP-11s have found means to monitor the UNIBUS traffic. >> My latest approach is www.retrocmp.com/tools/uniprobe >> UniProbe is a M9302 terminator, a LED display, a probe for logic analyzer. >> It can be mounted in Standard or Modified UNIBUS sockets. >> >> I'm ordering a batch of PCBs in a few days and will show this and other stuff (UniBone, BlinkenBone) at VCFPNW in Seattle. >> https://vcfed.org/wp/festivals/vintage-computer-festival-pacific-northwest/ >> >> best regards, >> Joerg >> > > From ethan.dicks at gmail.com Wed Feb 27 14:52:29 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Wed, 27 Feb 2019 15:52:29 -0500 Subject: PDP-11/60 manuals needed In-Reply-To: References: <20190227200302.93F5418C086@mercury.lcs.mit.edu> Message-ID: On Wed, Feb 27, 2019 at 3:10 PM Bill Degnan via cctalk wrote: > > Yes, it almost certainly is (without seeing it, I can't be 100%, but it > > sounds like it is). Is it by any chance EK-KD11K-TM-001? That part number is for a print-set, specifically the Technical Manual for the KD11K processor, revision 1. > The 11/60 handbook doesn't have that kind of designation. It's EB06498 That is a paperback. I'm following the discussion because I have the two BA11 cabinets for an 11/60, the PSUs, and the front panel (I'm missing the rack). There is scant info out there and I'm interested in anything that turns up. -ethan From derschjo at gmail.com Wed Feb 27 15:23:19 2019 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 27 Feb 2019 13:23:19 -0800 Subject: PDP-11/60 manuals needed In-Reply-To: References: <20190227200302.93F5418C086@mercury.lcs.mit.edu> Message-ID: On Wed, Feb 27, 2019 at 1:04 PM Ethan Dicks via cctalk < cctalk at classiccmp.org> wrote: > On Wed, Feb 27, 2019 at 3:10 PM Bill Degnan via cctalk > wrote: > > > Yes, it almost certainly is (without seeing it, I can't be 100%, but it > > > sounds like it is). Is it by any chance EK-KD11K-TM-001? > > That part number is for a print-set, specifically the Technical Manual > for the KD11K processor, revision 1. > > > The 11/60 handbook doesn't have that kind of designation. It's EB06498 > > That is a paperback. > > Correct. It's like all the other DEC handbooks from that era, printed on that lovely grade triple-Z paper that falls apart if you look at it wrong. This one's held together better than most. Happy to send it to Noel if it's actually of use. - Josh > I'm following the discussion because I have the two BA11 cabinets for > an 11/60, the PSUs, and the front panel (I'm missing the rack). There > is scant info out there and I'm interested in anything that turns up. > > -ethan > From jnc at mercury.lcs.mit.edu Wed Feb 27 16:09:32 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 27 Feb 2019 17:09:32 -0500 (EST) Subject: PDP-11/60 manuals needed Message-ID: <20190227220932.9B84A18C086@mercury.lcs.mit.edu> > From: Bill Degnan > The 11/60 handbook doesn't have that kind of designation. It's EB06498 Yeah, that's the processor handbook, which is the paperback-sized thing which is mostly a programmer's reference; I've got that, its the 8-1/2x11 sized things I'm after. > From: Ethan Dicks > Is it by any chance EK-KD11K-TM-001? > That part number is for a print-set Uhh, no. Looking at the fiche version, EP-KD11K-TM-001, it has lots and lots of text blocks (which I can't read without a fiche reader, of course). We do seem to have the print sets: MP00166 11/60 System (chassis, power contoller, etc) MP00409 KD11-K CPU MP00500 WCS (M7870) MP00429 FP11-E but I'm not desperate enough to learn the -11/60 by looking at them! > I'm following the discussion because I have the two BA11 cabinets for > an 11/60, the PSUs, and the front panel (I'm missing the rack). And by 'the rack', I'm guessing that includes the backplane? Looking through the prints, I think I didn't see details on it (alas). Noel From bobsmithofd at gmail.com Wed Feb 27 16:50:36 2019 From: bobsmithofd at gmail.com (Bob Smith) Date: Wed, 27 Feb 2019 17:50:36 -0500 Subject: PDP-11/60 manuals needed In-Reply-To: <20190227220932.9B84A18C086@mercury.lcs.mit.edu> References: <20190227220932.9B84A18C086@mercury.lcs.mit.edu> Message-ID: my recollection of the JO KD11-K is dusty. It was under development at the same time my group was working on the DMC/KMC11 products. The similarity of the /60 and the DMC/KMC was the fact that they were both based on Harvard architecture implementations. . A Harvard arch implementation of the PDP11 ISP is an interesting challenge. On Wed, Feb 27, 2019 at 5:09 PM Noel Chiappa via cctalk wrote: > > > From: Bill Degnan > > > The 11/60 handbook doesn't have that kind of designation. It's EB06498 > > Yeah, that's the processor handbook, which is the paperback-sized thing which > is mostly a programmer's reference; I've got that, its the 8-1/2x11 sized > things I'm after. > > > > From: Ethan Dicks > > > Is it by any chance EK-KD11K-TM-001? > > > That part number is for a print-set > > Uhh, no. Looking at the fiche version, EP-KD11K-TM-001, it has lots and lots > of text blocks (which I can't read without a fiche reader, of course). > > We do seem to have the print sets: > > MP00166 11/60 System (chassis, power contoller, etc) > MP00409 KD11-K CPU > MP00500 WCS (M7870) > MP00429 FP11-E > > but I'm not desperate enough to learn the -11/60 by looking at them! > > > I'm following the discussion because I have the two BA11 cabinets for > > an 11/60, the PSUs, and the front panel (I'm missing the rack). > > And by 'the rack', I'm guessing that includes the backplane? Looking through > the prints, I think I didn't see details on it (alas). > > Noel From ethan.dicks at gmail.com Thu Feb 28 01:05:19 2019 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Thu, 28 Feb 2019 02:05:19 -0500 Subject: PDP-11/60 manuals needed In-Reply-To: <20190227220932.9B84A18C086@mercury.lcs.mit.edu> References: <20190227220932.9B84A18C086@mercury.lcs.mit.edu> Message-ID: On Wed, Feb 27, 2019 at 5:09 PM Noel Chiappa via cctalk wrote: > > From: Ethan Dicks > > Is it by any chance EK-KD11K-TM-001? > > > That part number is for a print-set > > Uhh, no. Looking at the fiche version, EP-KD11K-TM-001, it has lots and lots > of text blocks (which I can't read without a fiche reader, of course). Ah... I've seen Tech Manuals printed as 2-up on C-sized paper, sometimes with interstitial 11"x17" drawings that would have been fold-outs in 8.5"x11" format. > We do seem to have the print sets: > > MP00166 11/60 System (chassis, power contoller, etc) > MP00409 KD11-K CPU > MP00500 WCS (M7870) > MP00429 FP11-E Cool (MPxxxxx should be Maintenance Prints) > but I'm not desperate enough to learn the -11/60 by looking at them! Totally fair. > > I'm following the discussion because I have the two BA11 cabinets for > > an 11/60, the PSUs, and the front panel (I'm missing the rack). > > And by 'the rack', I'm guessing that includes the backplane? Looking through > the prints, I think I didn't see details on it (alas). No... "the rack" is just the outer box with rails (not an H960 - whatever the designation is for the odd 11/60 cabinet). The backplanes are in the BA11s. I seem to have both MOS and core memory and, I am fairly sure, an RK611, along with the CPU. I need to take a module inventory. -ethan From Martin.Hepperle at MH-AeroTools.de Thu Feb 28 02:20:45 2019 From: Martin.Hepperle at MH-AeroTools.de (Martin.Hepperle at MH-AeroTools.de) Date: Thu, 28 Feb 2019 09:20:45 +0100 Subject: HP 85 tapes Message-ID: <000001d4cf3e$815ec260$841c4720$@MH-AeroTools.de> Christian, there is the document "9915-TapeDuplicationAndEPROMProgrammingSoftware-09915-10011-46pages-Jul83.p df" on the HP-.Museum web site. I think the associated software is not available, but it also uses the TAPDUP binary (pg. 1-2) and the same IMAGE program. The binary itself was part of this and is not documented (it was considered part of the whole package). What is available via M. Craggs web site are the files from a "Hybrid ROM Creation Pak", which includes TAPDUP. The IMAGE program (pg 2-2) contained there is probably similar or the same. The Master/Slave programs and some more are not in this package. >From the "Hybrid ROM Creation Pak" AUXROM.ASM AUXROM.BAS AUXSHELL.BAS CREATEROM.BAS DATAIO-19.BAS DATAIO-29A.BAS EPROM2.BAS IMAGE.BAS --- 20 ! (program "IMAGE", 09915-90022, p.5-5...5-6) (these page numbers do not refer to the manual 09915-10011) MAINBASIC.BAS RBUILD85S.ASM RBUILD87S.ASM ROMSHELL.ASM TAPDUP.ASM Martin From cube1 at charter.net Thu Feb 28 07:49:53 2019 From: cube1 at charter.net (Jay Jaeger) Date: Thu, 28 Feb 2019 07:49:53 -0600 Subject: PDP-11/60 manuals needed In-Reply-To: <20190227193756.4908818C086@mercury.lcs.mit.edu> References: <20190227193756.4908818C086@mercury.lcs.mit.edu> Message-ID: On 2/27/2019 1:37 PM, Noel Chiappa via cctalk wrote: > Hi, does anyone have any PDP-11/60 manuals? I went to do articles on the > -11/60 and its CPU (KD11-K), but there isn't much online. > > Bitsavers has EK-KD11K-TD-PRE, but it only covers the maintenance features, > not the whole CPU; there is a tech manual - KD11K-TM-001 (I have it in fiche, > but my fiche reader has a burned out bulb which I have not yet been able to > replace, so it doesn't do me much good). There is a user manual for the > FP11-E, which has a certain amount of useful details, but it refers to the > technical manual, which is not there. And there's EK-11060-SV-01, which covers > the cabinet and power supply. > > So if anyone has the general -11/60 manual, or the KD11-K tech manual, those > would be super useful. The FP11-E tech manual would be nice to have, but isn't > as important as the others. > > Thanks (I hope!)! > > Noel > I have EK-11060-OP-003: "PDP-11/60 installation and operation manual" and an update EK-11060-OP-C1. Of course this is not the real technical manual that explains the processor in detail, but it has the self-test error halts, boot procedure, etc., which I expect would be handy. I don't see this manual on bitsavers, so let me know and I will scan it in and stick it on my Google drive in a day or two or three where you and Al could snag the scan. I also have a spare processor handbook, EB-06498-20/77, but it is in a box in the garage, so I'd rather wait a week or two for warmer weather to dig it out. JRJ From aek at bitsavers.org Thu Feb 28 11:08:34 2019 From: aek at bitsavers.org (Al Kossow) Date: Thu, 28 Feb 2019 09:08:34 -0800 Subject: PDP-11/60 manuals needed In-Reply-To: References: <20190227193756.4908818C086@mercury.lcs.mit.edu> Message-ID: <199e75f6-b892-12e9-4231-6dda889a889f@bitsavers.org> On 2/28/19 5:49 AM, Jay Jaeger via cctalk wrote: > I don't see this manual on bitsavers, so let me know and I will scan it > in and stick it on my Google drive in a day or two or three where you > and Al could snag the scan. cool, one less thing for me to pull from the archive. all of the paper from the DEC archives have been cataloged, and nothing is coming up beyond that, the handbook and what i've already scanned. From jnc at mercury.lcs.mit.edu Thu Feb 28 13:19:32 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 28 Feb 2019 14:19:32 -0500 (EST) Subject: PDP-11/60 manuals needed Message-ID: <20190228191932.F16AD18C082@mercury.lcs.mit.edu> > From: Jay Jaeger > I have EK-11060-OP-003: "PDP-11/60 installation and operation manual" > and an update EK-11060-OP-C1. Yeah, that's the one I referred to as "the general -11/60 manual"; generally, there's one such for all the -11 models, but the exact name varies from model to model (unlike, say, the CPU tech manuals, the name for which is pretty predictable). > let me know and I will scan it in and stick it on my Google drive in a > day or two or three That would be great; thanks very much! No rush at all... > I also have a spare processor handbook, EB-06498-20/77 We do have that one, thanks. BTW, looking a little more closely at the cabinet/power-supply manual (pg. 1-7), the KD11-K TM might _only_ be available on fiche. If so, that'll be the first time I've ever seen that. Oddly enough, further down the page, the FP11-E TM seems to be available in printed form (EK-FP11E-TM). > From: Ethan Dicks > I've seen Tech Manuals printed as 2-up on C-sized paper Yeah, generally things from the -11/20 era are like that (e.g. the RK11-C manual). Nothing later than that that I've ever seen, though. >>> I have the two BA11 cabinets for an 11/60, the PSUs, and the front >>> panel (I'm missing the rack). > "the rack" is just the outer box with rails (not an H960 - whatever the > designation is for the odd 11/60 cabinet). I think it's the H9500 low-boy corporate cabinet, per Chapter 5 in the cabinet/power manual. > The backplanes are in the BA11s. I seem to have both MOS and core > memory and, I am fairly sure, an RK611, along with the CPU. I need to > take a module inventory. You seem to have most of the crucial bits, although you might be missing the power harness. Do you have the optional WCS module (M7870)? There are also ROM modules, and a diagnostic module, that can go in that slot - only one of the three at a time, though. Noel From fritzm at fritzm.org Thu Feb 28 13:22:33 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Thu, 28 Feb 2019 11:22:33 -0800 Subject: V6 cc needs hash before whitespace before first include? Message-ID: <321A269D-BAC5-430F-B93B-1FE83B98BB99@fritzm.org> So, I've been having some fun playing around with V6 Unix on my 11/45 a bit after that last repair. I've just been tripped up for a little over the fact that the C compiler barfs if there is whitespace/comentary before the first #include; the workaround seems to be to add a lone '#' at the beginning of the file. It took me a while to notice that this was done, for example, in all of the device driver sources. I found this curious. Anybody know what the story is there? --FritzM. From phil at ultimate.com Thu Feb 28 13:43:44 2019 From: phil at ultimate.com (Phil Budne) Date: Thu, 28 Feb 2019 14:43:44 -0500 Subject: V6 cc needs hash before whitespace before first include? In-Reply-To: <321A269D-BAC5-430F-B93B-1FE83B98BB99@fritzm.org> References: <321A269D-BAC5-430F-B93B-1FE83B98BB99@fritzm.org> Message-ID: <201902281943.x1SJhiTw063729@ultimate.com> > Anybody know what the story is there? It's an indicator that the pre-processor needs to be run first. The v6 code I've seen never used an include file for the stty/gtty calls (as opposed to using a struct defined in an include file) so I'm betting it was a speedup to not fork/exec another process if it was going to be a null transform! From jnc at mercury.lcs.mit.edu Thu Feb 28 13:59:59 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 28 Feb 2019 14:59:59 -0500 (EST) Subject: V6 cc needs hash before whitespace before first include? Message-ID: <20190228195959.D1FE218C082@mercury.lcs.mit.edu> > From: Phil Budne > I'm betting it was a speedup to not fork/exec another process if it was > going to be a null transform! It's worse than that! In vanilla V6, the pre-processor is built into 'cc', not a separate command. Here's the relevant code (from expand()): if (getc(ibuf1) != '#') { close(ibuf1[0]); return(file); } The code to implement the directives is, ah, entertaining. Noel From blstuart at bellsouth.net Thu Feb 28 14:09:08 2019 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Thu, 28 Feb 2019 20:09:08 +0000 (UTC) Subject: V6 cc needs hash before whitespace before first include? References: <394600304.7158161.1551384548217.ref@mail.yahoo.com> Message-ID: <394600304.7158161.1551384548217@mail.yahoo.com> On Thu, 2/28/19, Fritz Mueller via cctalk wrote: > I've just been tripped up for a little > over the fact that the C compiler barfs if there is > whitespace/comentary before the first #include; the > > I found this curious.? Anybody > know what the story is there? My recollection is that it's documented in the 6th Ed C manual that # has to be in the first column. Beyond that, I vaguely recall something to the effect that if the first line isn't a preprocessor directive, then it skips any preprocessing at all. BLS From fritzm at fritzm.org Thu Feb 28 14:29:22 2019 From: fritzm at fritzm.org (Fritz Mueller) Date: Thu, 28 Feb 2019 12:29:22 -0800 Subject: V6 cc needs hash before whitespace before first include? In-Reply-To: <201902281943.x1SJhiTw063729@ultimate.com> References: <321A269D-BAC5-430F-B93B-1FE83B98BB99@fritzm.org> <201902281943.x1SJhiTw063729@ultimate.com> Message-ID: <3BACFE36-8843-40BE-8762-BE444FD22ABD@fritzm.org> > On Feb 28, 2019, at 11:43 AM, Phil Budne wrote: > It's an indicator that the pre-processor needs to be run first. Ah, okay! So that's a fun bit of V6 apocrypha. Was this gone by V7? From anders.k.nelson at gmail.com Thu Feb 28 16:57:42 2019 From: anders.k.nelson at gmail.com (Anders Nelson) Date: Thu, 28 Feb 2019 17:57:42 -0500 Subject: eBay: RCA CDP1802 Message-ID: IIRC someone on this list was asking for an 1802 some time ago... https://www.ebay.com/itm/CDP1802-CPU/132727125007 =] -- Anders Nelson +1 (517) 775-6129 www.erogear.com