From ljw-cctech at ljw.me.uk Tue Sep 1 00:33:30 2020 From: ljw-cctech at ljw.me.uk (Lawrence Wilkinson) Date: Tue, 1 Sep 2020 07:33:30 +0200 Subject: Spam In-Reply-To: <01RP3YQBF9PY8ZDV7U@beyondthepale.ie> References: <01RP3YQBF9PY8ZDV7U@beyondthepale.ie> Message-ID: As a moderator, I am quite sure that no spam actually came through the list. On a few occasions the spam has come from a list member's address and gets passed straight through, but that's quite rare. However the number of spam posts to the list exceeds real posts by a factor of about 10. So it's quite possible that I will click the wrong button and you will all get a spam message. For some reason almost all the current spam is in German. (And if you can, please don't post messages with spammy subjects like "Look at this!" if you want it to go through.) Bill Degnan (or an imposter) did post a couple of empty messages recently, no great harm done there. Lawrence On 1/09/20 12:55 am, Peter Coghlan via cctalk wrote: > Anybody else on cctech/cctalk receive a blatant spam today from an outfit > called "SparkPost" with "OptIn Live" in the subject? > > Regards, > Peter Coghlan. -- Lawrence Wilkinson lawrence at ljw.me.uk The IBM 360/30 page http://www.ljw.me.uk/ibm360 From dkelvey at hotmail.com Tue Sep 1 00:35:00 2020 From: dkelvey at hotmail.com (dwight) Date: Tue, 1 Sep 2020 05:35:00 +0000 Subject: Spam In-Reply-To: References: <01RP3YQBF9PY8ZDV7U@beyondthepale.ie> <35af657c-ca1a-7db5-ad8b-4131f1ff65cb@jwsss.com>, Message-ID: I had troubles with a fellow in England using my email address to mail spam. I traced down his IP address and the company that was being used. I sent mail to him a couple times and asked him to stop using my address. I then sent copies of the junk he was sending to his provider and within a week it stopped. Dwight ________________________________ From: cctalk on behalf of Tom Hunter via cctalk Sent: Monday, August 31, 2020 7:28 PM To: jim stephens ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Spam Today I received two empty emails from Bill Degnan via this list. No subject and no message body. Googled put them into the Spam folder. Tom Hunter On Tue, Sep 1, 2020 at 8:38 AM jim stephens via cctalk < cctalk at classiccmp.org> wrote: > > > On 8/31/2020 3:55 PM, Peter Coghlan via cctalk wrote: > > Anybody else on cctech/cctalk receive a blatant spam today from an outfit > > called "SparkPost" with "OptIn Live" in the subject? > > > > Regards, > > Peter Coghlan. > > > i've found that someone who has had their emails in someones inbox may > get their emails harvested and added to spam lists. > > I've got some past members here who still send spam. > > Unfortunately since we want to respond directly thru this to users, the > email addresses are in the email messages. If a spam creating exploit > is through, it will pluck off the sender's email, which is the reply-to > address. > > It may have nothing to do with the list or any user you can determine, > but sometimes it does. > > Thanks > JIm > From ccth6600 at gmail.com Tue Sep 1 01:18:13 2020 From: ccth6600 at gmail.com (Tom Hunter) Date: Tue, 1 Sep 2020 14:18:13 +0800 Subject: Fwd: Factory Rodent Urine, was Re: Sun SPARCstation LX boot from CDROM? In-Reply-To: References: <623C45C3-48D8-47D7-881E-C192D9673B90@snowmoose.com> <5cc2c1ed-a4bf-9610-50b8-131e39116c34@sydex.com> Message-ID: ---------- Forwarded message --------- From: Tom Hunter Date: Tue, Sep 1, 2020 at 2:17 PM Subject: Re: Factory Rodent Urine, was Re: Sun SPARCstation LX boot from CDROM? To: Chuck Guzis Thanks Chuck, Unfortunately it is well past cleaning. The lead/tin alloy has corroded into a hard oxide with very high melting temperature. Lead oxide melts at 800+ degrees C and tin oxide at 1300+ degrees C. This is well past the 300 degrees C a soldering iron produces. Most importantly the copper pads below and some of the tracks are gone completely. About 70% of the board is pristine. Only the section which has been exposed to the liquid is corroded. I can't say for sure that it is rodent urine, but when I tried to reflow the corroded solder joints it faintly smelled like my firewood where rats nested one winter. Of course there is no chance for a rat or even the tiniest mouse to get into a fully assembled Sun/Sony CDROM with the affected PCB side facing down and somehow urinate upwards towards the PCB. As the drive was never before disassembled it could only have happened during manufacturing. 20 years ago when I put the drive and other SPARX LX gear into my display cabinet I could have easily found a replacement. Now it won't be easy. The sad thing about it is that everything was pristine when I put it in my cabinet. Cheers Tom Hunter On Tue, Sep 1, 2020 at 1:41 PM Chuck Guzis wrote: > On 8/31/20 7:25 PM, Tom Hunter wrote: > > Not funny if your prized treasures fall victim to it. > > > > I found that oven cleaner can loosen layers of the stuff without too > much damage to the electronics underneath. Soap and water won't cut it. > > --Chuck > > From jwsmail at jwsss.com Tue Sep 1 01:56:44 2020 From: jwsmail at jwsss.com (jim stephens) Date: Mon, 31 Aug 2020 23:56:44 -0700 Subject: Factory Rodent Urine, was Re: Sun SPARCstation LX boot from CDROM? In-Reply-To: References: <623C45C3-48D8-47D7-881E-C192D9673B90@snowmoose.com> Message-ID: <8c3cd6a8-884a-ea51-dc0a-c534e28339ac@jwsss.com> On 8/31/2020 7:25 PM, Tom Hunter via cctalk wrote: > Not funny if your prized treasures fall victim to it. > > :-( A friend had Western Dynex 10mb drives years ago which were hard to come by.? Equivalent to the RL02's. He had a test system which could run Microdata Reality as a test station for debugging hardware. As a matter of course, he'd also had a mouse which he took to feeding peanuts to and it would come out and beg. One morning he turned on the drive, it loaded, but wouldn't come ready. Eventually pulled it out and got ready to see what had failed and there were no obvious electrical faults. On looking closer if you recall on those drives they had very fine 4 wire sleeved wiring to the heads.? Used some flex wire shieldng, but most of the length was in clear vinyl small tubing. All 4 of them were neatly clipped off and in the bottom of the drive. Set a rat trap that night, goodby mouse.? I was sad, but that bit cost about $1,500 or so to fix. thankks jim From cctalk at beyondthepale.ie Tue Sep 1 03:10:54 2020 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Tue, 01 Sep 2020 09:10:54 +0100 (WET-DST) Subject: Spam In-Reply-To: <12D28433-2C9E-4EC3-AA97-4BF92ACC9EE8@comcast.net> References: <01RP3YQBF9PY8ZDV7U@beyondthepale.ie> Message-ID: <01RP4I4CUS3W8ZDV7U@beyondthepale.ie> Paul Koning wrote: > > On Aug 31, 2020, at 6:55 PM, Peter Coghlan via cctalk wrote: > > > > Anybody else on cctech/cctalk receive a blatant spam today from an outfit > > called "SparkPost" with "OptIn Live" in the subject? > > > > Regards, > > Peter Coghlan. > > Nope. > > Keep in mind that criminals often forge source addresses. So while it may > say it came from cctalk, it doesn't mean it actually did. Looking at the > full headers will often tell you, if you care to go to the trouble. > The spam I got did not come from cctalk. I didn't say it came from cctalk, I said it came from an outfit called "SparkPost". I asked if anyone else on cctalk received the same spam because I am attempting to figure out how SparkPost obtained the email address that I use only for cctalk. >From the responses received, it appears that other cctalk list members did not receive the same spam which reduces the likelyhood that someone (ie SparkPost) had subscribed to cctalk specifically to harvest the email addresses of the list members, a possibility which was advanced on this list a while back. > > For example, I get spam every few weeks claiming to be from one specific > person on the list here, but it never actually is from that address. > Same here except that it is in regard of the freecycle mailing list rather than cctalk. Regards, Peter Coghlan. > paul > From lars at nocrew.org Tue Sep 1 05:31:41 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 01 Sep 2020 10:31:41 +0000 Subject: Zork from ITS tapes Message-ID: <7wzh69ss8i.fsf@junk.nocrew.org> Hello, Early Zork source and binary files have been found on ITS backup tapes. MIT previously released some December 1977 files here: https://github.com/MITDDC/zork Recently discovered files from January 1978 will appear soon. From binarydinosaurs at gmail.com Tue Sep 1 05:42:13 2020 From: binarydinosaurs at gmail.com (Adrian Graham) Date: Tue, 1 Sep 2020 11:42:13 +0100 Subject: Curt Vendel Message-ID: <5667C680-91A4-477B-A04A-185E0A67AFD5@gmail.com> Folks, I first heard this last night (UK time) but from an unconfirmed source so I waited until this morning and woke to find a tweet from AtariAge confirming it. Seems that Curt Vendel of the Atari History Museum amongst others passed away unexpectedly yesterday. Sending condolences to his family and everyone who knew him. Taken far too soon. RIP Curt. https://twitter.com/AtariAge/status/1300547070034620417 -- Adrian Graham Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaurs f: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk From dave.g4ugm at gmail.com Tue Sep 1 06:14:17 2020 From: dave.g4ugm at gmail.com (Dave Wade) Date: Tue, 1 Sep 2020 12:14:17 +0100 Subject: Spam In-Reply-To: <01RP4I4CUS3W8ZDV7U@beyondthepale.ie> References: <01RP3YQBF9PY8ZDV7U@beyondthepale.ie> <01RP4I4CUS3W8ZDV7U@beyondthepale.ie> Message-ID: <0bc001d68051$08a33bb0$19e9b310$@gmail.com> Peter, I seem to have been receiving various adds for "optimised SMTP" delivery but not sure if any relate to SparkPost. The version of you address with "at" rather than "@" is visible in a couple of places Dave > -----Original Message----- > From: cctalk On Behalf Of Peter Coghlan > via cctalk > Sent: 01 September 2020 09:11 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: Spam > > Paul Koning wrote: > > > On Aug 31, 2020, at 6:55 PM, Peter Coghlan via cctalk > wrote: > > > > > > Anybody else on cctech/cctalk receive a blatant spam today from an > > > outfit called "SparkPost" with "OptIn Live" in the subject? > > > > > > Regards, > > > Peter Coghlan. > > > > Nope. > > > > Keep in mind that criminals often forge source addresses. So while it > > may say it came from cctalk, it doesn't mean it actually did. Looking > > at the full headers will often tell you, if you care to go to the trouble. > > > > The spam I got did not come from cctalk. I didn't say it came from cctalk, I > said it came from an outfit called "SparkPost". I asked if anyone else on cctalk > received the same spam because I am attempting to figure out how > SparkPost obtained the email address that I use only for cctalk. > > From the responses received, it appears that other cctalk list members did > not receive the same spam which reduces the likelyhood that someone (ie > SparkPost) had subscribed to cctalk specifically to harvest the email > addresses of the list members, a possibility which was advanced on this list a > while back. > > > > > For example, I get spam every few weeks claiming to be from one > > specific person on the list here, but it never actually is from that address. > > > > Same here except that it is in regard of the freecycle mailing list rather than > cctalk. > > Regards, > Peter Coghlan. > > > paul > > From PETER at beyondthepale.ie Tue Sep 1 03:01:09 2020 From: PETER at beyondthepale.ie (Peter Coghlan) Date: Tue, 01 Sep 2020 09:01:09 +0100 (WET-DST) Subject: Spam In-Reply-To: <12D28433-2C9E-4EC3-AA97-4BF92ACC9EE8@comcast.net> References: <01RP3YQBF9PY8ZDV7U@beyondthepale.ie> Message-ID: <01RP4I1KJK1Y8ZDV7U@beyondthepale.ie> Paul Koning wrote: > > On Aug 31, 2020, at 6:55 PM, Peter Coghlan via cctalk wrote: > > > > Anybody else on cctech/cctalk receive a blatant spam today from an outfit > > called "SparkPost" with "OptIn Live" in the subject? > > > > Regards, > > Peter Coghlan. > > Nope. > > Keep in mind that criminals often forge source addresses. So while it may > say it came from cctalk, it doesn't mean it actually did. Looking at the > full headers will often tell you, if you care to go to the trouble. > The spam I got did not come from cctalk. I didn't say it came from cctalk, I said it came from an outfit called "SparkPost". I asked if anyone else on cctalk received the same spam because I am attempting to figure out how SparkPost obtained the email address that I use only for cctalk. >From the responses received, it appears that other cctalk list members did not receive the same spam. This reduces the likelyhood that someone has subscribed to cctalk specifically to harvest the email addresses of the list members, a possibility which was advanced on this list a while back. > > For example, I get spam every few weeks claiming to be from one specific > person on the list here, but it never actually is from that address. > Same here except that it is in regard of the freecycle mailing list rather than cctalk. Regards, Peter Coghlan. > paul > From mattislind at gmail.com Tue Sep 1 06:51:04 2020 From: mattislind at gmail.com (Mattis Lind) Date: Tue, 1 Sep 2020 13:51:04 +0200 Subject: IBM 3270 compatible terminal connected to Hercules IBM mainframe emulator. In-Reply-To: References: Message-ID: Hello Connor! Den tis 1 sep. 2020 kl 01:58 skrev Connor Krukosky via cctalk < cctalk at classiccmp.org>: > Wow Mattis this looks great, fantastic work! > Thanks! > > I will see if I can solder up a unit from what you have up on github on > a perf board (I should have a few bluepills kicking around) and see if I > can assist in some way with testing on a 3174-61R I have. > That should be easy to do on a perf board. And if you don't have MAX208 around you can replace them with something similar. Maybe the 3174 is not so picky about interface signals and only need CTS so you could probably skip most of them? The 9 pin serial port is not really necessary and is mostly used for debugging. Two senders or three if CTS is required and one receiver should be enough. > Unfortunately its the only one I have and I have a few 3270 terminals so > I would like to keep it in my ownership. > Sure. But if someone hears about a spare 3174, preferably the smaller ones, I would be very interested. I have a 3279 and a 3178 that could be interesting to test. In the longer run it would be interesting to do SDLC integration over VTAM as well. The SDLC implementation on the STM32 seems to work quite well, but there is quite a lot of work needed on the comm3705.c code inside Hercules to get all things together. > But they definitely do show up, a lot more often than it seems the > terminals do nowadays. > > I have the Ethernet controllers for my 3174-R61 which I know people > generally use for communications with things like Hercules but as those > are much less common it would be nice to see if we can verify this works > on these terminal controllers and make using 3270 terminals with > Hercules more accessible to people! > If you'd like me to work with you on testing this let me know. I'll > definitely see if I can try it out myself anyway. > Either way, fantastic work and thanks for putting everything up on github! > I have one tester now that has ordered boards and built one to connect to a 3174 with 3179 and 3178 terminals so I guess that I will get reports from him if it isn't working. It is always nice with more testers, but there is no hurry. If you do build one I am happy to help you get it working. /Mattis > > -Connor K > > > From lproven at gmail.com Tue Sep 1 07:15:31 2020 From: lproven at gmail.com (Liam Proven) Date: Tue, 1 Sep 2020 14:15:31 +0200 Subject: Sun SPARCstation LX boot from CDROM? In-Reply-To: References: <623C45C3-48D8-47D7-881E-C192D9673B90@snowmoose.com> Message-ID: On Sun, 30 Aug 2020 at 15:33, Tom Hunter via cctalk wrote: > About 70% of the PCB had solder joints that were nice and shiny like brand > new. The remaining section near the front of the drive was quite badly > corroded and it also looked like there was some liquid spilled over that > section of the PCB (component side). This and the rest of what you describe sounds quite like the damaged caused by electrolyte leaking from failed capacitors. This is probably the most common cause of failure in electronics after they get to 2-3 decades old. There was one particular time when this happened prematurely: https://en.wikipedia.org/wiki/Capacitor_plague But it is a general problem with almost all capacitors. I could be wrong but this seems more likely than rodent pee... Personally, I have failed caps in 3 Apple Macs -- one PowerPC and two MC68000. All are awaiting repair. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Tue Sep 1 07:17:21 2020 From: lproven at gmail.com (Liam Proven) Date: Tue, 1 Sep 2020 14:17:21 +0200 Subject: IBM 3270 compatible terminal connected to Hercules IBM mainframe emulator. In-Reply-To: References: Message-ID: On Sun, 30 Aug 2020 at 08:24, Mattis Lind via cctalk wrote: > > I have been working on a project for some time to connect a IBM3270 > compatible Alfaskop terminal with its IBM 3274 compatible cluster > controller to the Hercules mainframe emulator. > > Yesterday I eventually succeeded. I was able to login to TSO on my Hercules > system that ran MVS 3.8j. > > Here are a couple quick video clips: > > https://youtu.be/H1Sxt7xjn4Y > > https://youtu.be/CFfB3yCN9OI Very impressive! I shared links to the videos on the FB vintage mainframes group, where they are attracting some approving comments, too. :-) -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From ccth6600 at gmail.com Tue Sep 1 07:32:59 2020 From: ccth6600 at gmail.com (Tom Hunter) Date: Tue, 1 Sep 2020 20:32:59 +0800 Subject: Sun SPARCstation LX boot from CDROM? In-Reply-To: References: <623C45C3-48D8-47D7-881E-C192D9673B90@snowmoose.com> Message-ID: Hi Liam, You are probably quite correct. In another forum someone came up with the same explanation for my "rat problem". Here is what he wrote: "Were there any electrolytic capacitors in the region of the corrosion? When an electrolytic capacitor leaks (even slightly) the electrolyte often contaminates the solder joint and oxidises it as you describe. The appearance will be dull and the melting point will be significantly higher than that of normal tin-lead joints. When heated, it will emit a "unique" smell that smells like fish or urine. This is often repairable but it's quite a bit of effort. Worthwhile for high-value assemblies I suppose." and: "With regards to small electrolytic capacitor leakage, I very rarely see any "wetness". The leakage takes place very slowly over many years and is almost like a capillary effect along the pads and into the board rather than a liquid spill. One normally only sees the damage (oxidation). It usually discolours the pads of the electrolytic cap and then travels into other nearby pads too. It often eats up the solder mask very quickly, but it takes longer for it to eat up the copper tracks. If your board is multi-layered, that is a very unfortunate situation indeed! Attached is a photo of what capacitor leakage typically looks like (note in this photo the offending caps have been removed and their pads cleaned)." I cannot include the photo as this mailing list doesn't allow photos. I think both you and the guy I quoted are spot on and this explanation is much more rational. I was misled by the smell when trying to reflow some of the pads. So the "rat mystery" is resolved. All I need now is a replacement drive. :-) Thanks Tom Hunter On Tue, Sep 1, 2020 at 8:15 PM Liam Proven via cctalk wrote: > On Sun, 30 Aug 2020 at 15:33, Tom Hunter via cctalk > wrote: > > About 70% of the PCB had solder joints that were nice and shiny like > brand > > new. The remaining section near the front of the drive was quite badly > > corroded and it also looked like there was some liquid spilled over that > > section of the PCB (component side). > > This and the rest of what you describe sounds quite like the damaged > caused by electrolyte leaking from failed capacitors. This is probably > the most common cause of failure in electronics after they get to 2-3 > decades old. > > There was one particular time when this happened prematurely: > https://en.wikipedia.org/wiki/Capacitor_plague > > But it is a general problem with almost all capacitors. > > I could be wrong but this seems more likely than rodent pee... > > Personally, I have failed caps in 3 Apple Macs -- one PowerPC and two > MC68000. All are awaiting repair. > > -- > Liam Proven ? Profile: https://about.me/liamproven > Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com > Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven > UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 > From pat at vax11.net Tue Sep 1 09:13:20 2020 From: pat at vax11.net (Patrick Finnegan) Date: Tue, 1 Sep 2020 10:13:20 -0400 Subject: IBM 3270 compatible terminal connected to Hercules IBM mainframe emulator. In-Reply-To: References: Message-ID: On Sun, Aug 30, 2020 at 2:24 AM Mattis Lind via cctalk < cctalk at classiccmp.org> wrote: > To achieve this I created a small piece of hardware I called SyncDongle, > essentially it's just a few level converters, connectors and a STM32F103 > blue pill. > Neat! > There are good chances that the SyncDongle/BSCBridge combo could work with > a 3274 or 3174 controller as well but I haven't tested since I don't have > one. But no guarantees given, though. If someone has a spare 3174-51R, > -61R, -81R or -91R I would be very interested in it. > > I've got a -91R that I've been wishing that I could use. I could maybe be persuaded to part with it... I've also got a -61R with token ring, an -11L, and a few -21L's that are more appropriate for use with my z890 or MP/2003. Pat From newsgroups at micromuseum.co.uk Tue Sep 1 10:58:50 2020 From: newsgroups at micromuseum.co.uk (newsgroups at micromuseum.co.uk) Date: Tue, 1 Sep 2020 16:58:50 +0100 Subject: Spam In-Reply-To: <01RP4I1KJK1Y8ZDV7U@beyondthepale.ie> References: <01RP3YQBF9PY8ZDV7U@beyondthepale.ie> <01RP4I1KJK1Y8ZDV7U@beyondthepale.ie> Message-ID: <000601d68078$cbbd9b00$6338d100$@micromuseum.co.uk> I actually thought the spam most was better than some of the usual postings on here! -----Original Message----- From: cctalk On Behalf Of Peter Coghlan via cctalk Sent: 01 September 2020 09:01 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Spam Paul Koning wrote: > > On Aug 31, 2020, at 6:55 PM, Peter Coghlan via cctalk wrote: > > > > Anybody else on cctech/cctalk receive a blatant spam today from an > > outfit called "SparkPost" with "OptIn Live" in the subject? > > > > Regards, > > Peter Coghlan. > > Nope. > > Keep in mind that criminals often forge source addresses. So while it > may say it came from cctalk, it doesn't mean it actually did. Looking > at the full headers will often tell you, if you care to go to the trouble. > The spam I got did not come from cctalk. I didn't say it came from cctalk, I said it came from an outfit called "SparkPost". I asked if anyone else on cctalk received the same spam because I am attempting to figure out how SparkPost obtained the email address that I use only for cctalk. >From the responses received, it appears that other cctalk list members did not receive the same spam. This reduces the likelyhood that someone has subscribed to cctalk specifically to harvest the email addresses of the list members, a possibility which was advanced on this list a while back. > > For example, I get spam every few weeks claiming to be from one > specific person on the list here, but it never actually is from that address. > Same here except that it is in regard of the freecycle mailing list rather than cctalk. Regards, Peter Coghlan. > paul > From a.carlini at ntlworld.com Tue Sep 1 11:19:25 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Tue, 1 Sep 2020 17:19:25 +0100 Subject: TZ8x DLT III cartridge - torn leader Message-ID: I've been trying to read data from some ~2000 era DLT III cartridges that were written on a TZ87. The first one read OK. But the second one failed and it seems that the leader was torn off. I tried a new drive and a second cartridge has failed the same way (the leader was there, now it's not). My immediate problem is that I now have two drives (a TZ88 and a TZ870 that fail POST (all LEDs blink). I guess I need to open them up, fish out the stray leader and fix them up somehow. Does anyone have any experience of doing this? My second problem is that I'd quite like to stop this from happening again. I'm guessing that it happened because the cartridge mechanism was jammed. I've just played around with a TK50-K cartridge and if I jam the two release mechanisms (using the "nose" of two pliers), open the "tape hatch" and gently pull the tape, it moves. Then I can "rewind" it and it's back to the way it was. I'm wondering whether this is safe to do on the DLT III tapes I still want to recover? Is it likely to at least tell me which tapes are likely to fail and which might load properly? My third problem i that I have two cartridges without a leader. Is this something that can be rectified? Thanks for any useful information. Antonio -- Antonio Carlini antonio at acarlini.com From technoid6502 at gmail.com Tue Sep 1 15:07:25 2020 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Tue, 01 Sep 2020 16:07:25 -0400 Subject: Curt Vendel Message-ID: <401fbd14b6ca3b88cd37d91b0fd7cd146e4746a1.camel@gmail.com> It is apparently true. He had heart troubles, but this was unexpected and certainly a shock to his family. I met Curt here, on Classiccmp, about twenty years ago. We are both hardcore Atari 8-bit computer geeks, but we met in this forum. He is missed by many as he touched many. Please pray for his soul and for peace for his wife and children. Jeff From technoid6502 at gmail.com Tue Sep 1 15:36:08 2020 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Tue, 01 Sep 2020 16:36:08 -0400 Subject: SunBlade 100 keyboard issues Message-ID: <53f63ff7e878113a1d9256c6e92963dcb88a80ec.camel@gmail.com> I have a Sunblade 100, got it on ebay for $103.00, landed on my doorstep. I hacked the nvram chip with a pair of AA batteries, which should keep the thing going for a hundred years. I really wanted a STOP key, and found an ad on Ebay for new Type 7 usb keyboard/mouse, bought the set. I used a plain jane USB keyboard to install OPENBSD and that works just fine. The type 7 keyboard works great on a pea sea, and, if the Sun is booted, running an operating system, it works fine there too. If the type 7 keyboard is plugged in at any time prior to booting from media, any time the OpenBoot prom is in charge, the prom reports no keyboard detected and defaults to a serial console. This happens even if the type 7 keyboard is plugged in ALONG WITH the generic USB keyboard I am using successfully with the machine right now. An advertisement for the type 7 keyboard gave me a clue that this is a known problem with some early SunBlade machines and that I would need a Firmware upgrade. I've looked on Oraclle's site for Sunblade 100 firmware upgrades and not found them. Can someone link me to the latest firmware for the SunBlade 100 so I can get it to recognize this keyboard? At present I've got OpenBSD 6.7 running with X and a light window manager. Got Dillo running as well, so I can surf. Woot woot! I miss my SParcstation 4/330 though. Thanks! Jeff The OpenBoot Prom utility however, does not see this keyboard at all. I From healyzh at avanthar.com Tue Sep 1 17:15:29 2020 From: healyzh at avanthar.com (Zane Healy) Date: Tue, 1 Sep 2020 15:15:29 -0700 Subject: TZ8x DLT III cartridge - torn leader In-Reply-To: References: Message-ID: What brand tape? I?ve seen this done by a tech on a DLT7000 drive, maybe on a DLT4000, I think they?re basically the same. I seem to remember the tech used a 9-Volt batter to rewind a stuck tape. The leaders as I recall are very similar for TK50, TK70, and DLTIII. Zane > On Sep 1, 2020, at 9:19 AM, Antonio Carlini via cctalk wrote: > > I've been trying to read data from some ~2000 era DLT III cartridges that were written on a TZ87. > > > The first one read OK. But the second one failed and it seems that the leader was torn off. I tried a new drive and a second cartridge has failed the same way (the leader was there, now it's not). > > > My immediate problem is that I now have two drives (a TZ88 and a TZ870 that fail POST (all LEDs blink). I guess I need to open them up, fish out the stray leader and fix them up somehow. Does anyone have any experience of doing this? > > > My second problem is that I'd quite like to stop this from happening again. I'm guessing that it happened because the cartridge mechanism was jammed. I've just played around with a TK50-K cartridge and if I jam the two release mechanisms (using the "nose" of two pliers), open the "tape hatch" and gently pull the tape, it moves. Then I can "rewind" it and it's back to the way it was. I'm wondering whether this is safe to do on the DLT III tapes I still want to recover? Is it likely to at least tell me which tapes are likely to fail and which might load properly? > > > My third problem i that I have two cartridges without a leader. Is this something that can be rectified? > > > Thanks for any useful information. > > > Antonio > > > > -- > Antonio Carlini > antonio at acarlini.com > From jwsmail at jwsss.com Tue Sep 1 18:46:46 2020 From: jwsmail at jwsss.com (jim stephens) Date: Tue, 1 Sep 2020 16:46:46 -0700 Subject: SunBlade 100 keyboard issues In-Reply-To: <53f63ff7e878113a1d9256c6e92963dcb88a80ec.camel@gmail.com> References: <53f63ff7e878113a1d9256c6e92963dcb88a80ec.camel@gmail.com> Message-ID: On 9/1/2020 1:36 PM, Jeffrey S. Worley via cctalk wrote: > > > An advertisement for the type 7 keyboard gave me a clue that this is a > known problem with some early SunBlade machines and that I would need a > Firmware upgrade. I've looked on Oraclle's site for Sunblade 100 > firmware upgrades and not found them. > > Can someone link me to the latest firmware for the SunBlade 100 so I > can get it to recognize this keyboard? > > The OpenBoot Prom utility however, does not see this keyboard at all. > I The system is designed that way. All the Sparc systems would go to the serial port w/o a keyboard. I don't know how that is affected unless they have a problem with the timing of the keyboard powering up or such. the design for the PS/2 keyboard is for the PC, and everyone else that uses it YMMV. I recall with Sun keyboards they could be unplugged and replugged and the firmware would allow you to get them to function (including the L1 button). I guess you've tried bringing up the system and have no FB / keyboard session, so that won't do much good. thanks Jim From curiousmarc3 at gmail.com Wed Sep 2 03:32:32 2020 From: curiousmarc3 at gmail.com (Curious Marc) Date: Wed, 02 Sep 2020 01:32:32 -0700 Subject: IBM 3270 compatible terminal connected to Hercules IBM mainframe emulator. In-Reply-To: References: Message-ID: Awesome! Marc Reply-To: "Mattis com>" , "cctalk at classiccmp.org" I have been working on a project for some time to connect a IBM3270 compatible Alfaskop terminal with its IBM 3274 compatible cluster controller to the Hercules mainframe emulator. Yesterday I eventually succeeded. I was able to login to TSO on my Hercules system that ran MVS 3.8j. Here are a couple quick video clips: https://youtu.be/H1Sxt7xjn4Y https://youtu.be/CFfB3yCN9OI /Mattis From a.carlini at ntlworld.com Wed Sep 2 05:11:23 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Wed, 2 Sep 2020 11:11:23 +0100 Subject: TZ8x DLT III cartridge - torn leader In-Reply-To: References: Message-ID: On 01/09/2020 23:15, Zane Healy wrote: > What brand tape? > > I?ve seen this done by a tech on a DLT7000 drive, maybe on a DLT4000, I think they?re basically the same. I seem to remember the tech used a 9-Volt batter to rewind a stuck tape. The leaders as I recall are very similar for TK50, TK70, and DLTIII. > > Zane > The torn tapes were both DEC "digital DLT CompacTape III". I should be clearer about what I think I see. When you flick open the back of the cartridge you should see the reel of tape and a "hole" or loop at the end of the reel. On the torn tapes that part was missing. One of the tapes showed clear signs of "something got pulled and stretched until it ripped". The other was less clear, and in fact I guess it is possible that the loop has simply been wound too far in. I've freed the cartridge that was trapped in the TZ88. To do that I used a screwdriver to turn the screw at the bottom of the drive (directly under where you would imagine the centre of the inserted cartridge to be) anticlockwise until I could see the cartridge tape pulled back into the cartridge. Then I gently pulled out the lever on the RHS (as you look from the front). There's a relatively large cylinder there, so it should be obvious where that is. That TZ88 still fails POST. Neither that TZ88 nor the TZ87 that I've opened up show any sign of having the "small amount of tape" inside (that seems to be called the leader). Basically this stuff: https://www.ebay.co.uk/itm/2-x-DLT7000-DLT8000-tape-leader-70-28824-01/114375418791 That's also not present in another DLT III drive that I have (and haven't ever tried to use before) that also fails POST. So I'm rather confused about what's happened. More importantly, I don't know how to fix the drives I do have. Antonio -- Antonio Carlini antonio at acarlini.com From pbirkel at gmail.com Wed Sep 2 08:54:43 2020 From: pbirkel at gmail.com (Paul Birkel) Date: Wed, 2 Sep 2020 09:54:43 -0400 Subject: IBM 3270 compatible terminal connected to Hercules IBM mainframe emulator. In-Reply-To: References: Message-ID: <077b01d68130$9c751360$d55f3a20$@gmail.com> Mattis: Is that SDLC implementation generally available? I see some interesting discussion of the possibility on Stack Exchange (Uriel Katz), but no obvious reference to a repository. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mattis Lind via cctalk Sent: Tuesday, September 01, 2020 7:51 AM To: Connor Krukosky; General Discussion: On-Topic and Off-Topic Posts Subject: Re: IBM 3270 compatible terminal connected to Hercules IBM mainframe emulator. .... The SDLC implementation on the STM32 seems to work quite well .... /Mattis From mattislind at gmail.com Wed Sep 2 11:09:41 2020 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 2 Sep 2020 18:09:41 +0200 Subject: IBM 3270 compatible terminal connected to Hercules IBM mainframe emulator. In-Reply-To: <077b01d68130$9c751360$d55f3a20$@gmail.com> References: <077b01d68130$9c751360$d55f3a20$@gmail.com> Message-ID: Hello Paul, Den ons 2 sep. 2020 kl 15:54 skrev Paul Birkel : > Mattis: Is that SDLC implementation generally available? I see some > interesting discussion of the possibility on Stack Exchange (Uriel Katz), > but no obvious reference to a repository. > It is here: https://github.com/MattisLind/alfaskop_emu/tree/master/Utils/SDLCBridge I haven't tested it to the extreme. Rather exchanging a few different messages with a Informer 213 terminal and a 8274 chip. That showed no problems. But then speeds were low. All sorts of buffering problems might creep up if you ramp up speed. /Mattis > > From rp at servium.ch Wed Sep 2 14:02:16 2020 From: rp at servium.ch (Rico Pajarola) Date: Wed, 2 Sep 2020 12:02:16 -0700 Subject: Brittle plastic In-Reply-To: References: Message-ID: I have a friend who is a Materials Science Technologist and specializes in injection molded plastics. So... basically the same thing that's in computer cases (even though he doesn't deal with computer cases). I grilled him at length on this topic, and he insisted that the brittleness with age (and UV light) is expected and irreversible. Basically, the plastic softeners are off-gassing, and there's no way to put them back in. I'm still hoping for a happier second opinion, though I'm not holding my breath. In my experience, brittleness varies wildly and goes from "no big deal" to "crumbles if you blow at it", even for otherwise identical machines. I recently acquired a Japanese Ultra 1 clone, and the back was smashed in shipping, and crumbled into a thousand pieces not even large enough to glue back together. Luckily the front only had a single crack that could be glued back together. On Fri, Aug 28, 2020 at 9:38 AM Tom Hunter via cctalk wrote: > Today I was working on a very nice 1995 vintage SPARCstation LX with CDROM > and QIC-150 tape drive (3 lunchbox type units). I was trying to install a > newer version of NetBSD on it than was already installed. The stack of 3 > units was stored in a museum grade glass display cabinet. Sadly all 3 units > have a small degree of yellowing but more importantly the plastic cases > have become very brittle and bits just break off with minimal mechanical > strain. > > Is there any process to reverse the brittleness which could be used to > preserve the cases? > > Thanks > Tom Hunter > From edcross at gmail.com Wed Sep 2 14:39:51 2020 From: edcross at gmail.com (Ed C.) Date: Wed, 2 Sep 2020 21:39:51 +0200 Subject: Brittle plastic In-Reply-To: References: Message-ID: Same issue with many Atari's ST/E, the plastic becomes super fragile. On Wed, Sep 2, 2020 at 9:11 PM Rico Pajarola via cctalk < cctalk at classiccmp.org> wrote: > I have a friend who is a Materials Science Technologist and specializes in > injection molded plastics. So... basically the same thing that's in > computer cases (even though he doesn't deal with computer cases). I grilled > him at length on this topic, and he insisted that the brittleness with age > (and UV light) is expected and irreversible. Basically, the plastic > softeners are off-gassing, and there's no way to put them back in. > > I'm still hoping for a happier second opinion, though I'm not holding my > breath. > > In my experience, brittleness varies wildly and goes from "no big deal" to > "crumbles if you blow at it", even for otherwise identical machines. I > recently acquired a Japanese Ultra 1 clone, and the back was smashed in > shipping, and crumbled into a thousand pieces not even large enough to glue > back together. Luckily the front only had a single crack that could be > glued back together. > > > > > > On Fri, Aug 28, 2020 at 9:38 AM Tom Hunter via cctalk < > cctalk at classiccmp.org> > wrote: > > > Today I was working on a very nice 1995 vintage SPARCstation LX with > CDROM > > and QIC-150 tape drive (3 lunchbox type units). I was trying to install a > > newer version of NetBSD on it than was already installed. The stack of 3 > > units was stored in a museum grade glass display cabinet. Sadly all 3 > units > > have a small degree of yellowing but more importantly the plastic cases > > have become very brittle and bits just break off with minimal mechanical > > strain. > > > > Is there any process to reverse the brittleness which could be used to > > preserve the cases? > > > > Thanks > > Tom Hunter > > > From cclist at sydex.com Wed Sep 2 15:46:01 2020 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 2 Sep 2020 13:46:01 -0700 Subject: Brittle plastic In-Reply-To: References: Message-ID: On 9/2/20 12:02 PM, Rico Pajarola via cctalk wrote: > I have a friend who is a Materials Science Technologist and specializes in > injection molded plastics. So... basically the same thing that's in > computer cases (even though he doesn't deal with computer cases). I grilled > him at length on this topic, and he insisted that the brittleness with age > (and UV light) is expected and irreversible. Basically, the plastic > softeners are off-gassing, and there's no way to put them back in. > > I'm still hoping for a happier second opinion, though I'm not holding my > breath. > > In my experience, brittleness varies wildly and goes from "no big deal" to > "crumbles if you blow at it", even for otherwise identical machines. I > recently acquired a Japanese Ultra 1 clone, and the back was smashed in > shipping, and crumbled into a thousand pieces not even large enough to glue > back together. Luckily the front only had a single crack that could be > glued back together. It's a very well-known problem among the museum conservation crowd--and with no practical solution. For a discussion, WikiPedia is pretty informative: https://en.wikipedia.org/wiki/Conservation_and_restoration_of_plastic_objects The Getty has a few papers on the subject: http://www.getty.edu/conservation/our_projects/education/cons_plastics/related_mats.html Sadly, there's no good answer, other than making a new duplicate. Apple had some really awful plastics in the 80s that would spontaneously destruct. I doubt that they are alone in that. Give me painted high-density structural foam any day. --Chuck From aperry at snowmoose.com Wed Sep 2 15:55:22 2020 From: aperry at snowmoose.com (Alan Perry) Date: Wed, 2 Sep 2020 13:55:22 -0700 Subject: Brittle plastic In-Reply-To: References: Message-ID: <8572d909-7ab8-4474-e864-657e0b9e4b0b@snowmoose.com> Is the problem age per se or exposure (UV, oxidation, heat, etc.) over time that one can protect against? My Sun lunch box and pizza box systems are not exposed to UV or excessive heat most of the time. Some of them are kept bagged (because it is very dusty where I live). That should help, right? alan On 9/2/20 12:02 PM, Rico Pajarola via cctech wrote: > I have a friend who is a Materials Science Technologist and specializes in > injection molded plastics. So... basically the same thing that's in > computer cases (even though he doesn't deal with computer cases). I grilled > him at length on this topic, and he insisted that the brittleness with age > (and UV light) is expected and irreversible. Basically, the plastic > softeners are off-gassing, and there's no way to put them back in. > > I'm still hoping for a happier second opinion, though I'm not holding my > breath. > > In my experience, brittleness varies wildly and goes from "no big deal" to > "crumbles if you blow at it", even for otherwise identical machines. I > recently acquired a Japanese Ultra 1 clone, and the back was smashed in > shipping, and crumbled into a thousand pieces not even large enough to glue > back together. Luckily the front only had a single crack that could be > glued back together. > > > > > > On Fri, Aug 28, 2020 at 9:38 AM Tom Hunter via cctalk > wrote: > >> Today I was working on a very nice 1995 vintage SPARCstation LX with CDROM >> and QIC-150 tape drive (3 lunchbox type units). I was trying to install a >> newer version of NetBSD on it than was already installed. The stack of 3 >> units was stored in a museum grade glass display cabinet. Sadly all 3 units >> have a small degree of yellowing but more importantly the plastic cases >> have become very brittle and bits just break off with minimal mechanical >> strain. >> >> Is there any process to reverse the brittleness which could be used to >> preserve the cases? >> >> Thanks >> Tom Hunter >> From cclist at sydex.com Thu Sep 3 00:56:00 2020 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 2 Sep 2020 22:56:00 -0700 Subject: Brittle plastic In-Reply-To: <8572d909-7ab8-4474-e864-657e0b9e4b0b@snowmoose.com> References: <8572d909-7ab8-4474-e864-657e0b9e4b0b@snowmoose.com> Message-ID: On 9/2/20 1:55 PM, Alan Perry via cctalk wrote: > > Is the problem age per se or exposure (UV, oxidation, heat, etc.) over > time that one can protect against? > > My Sun lunch box and pizza box systems are not exposed to UV or > excessive heat most of the time. Some of them are kept bagged (because > it is very dusty where I live). That should help, right? > > alan All I've read on the conservation threads seems to indicate that the only protection against degradation is refrigeration under low temperatures. It seems that there are unstable bonds in many plastics that come undone with time. It's an ugly problem--and I suspect the only solution is to replicate the parts. Heaven knows, I've had terrible experiences with PVC and ABS. I'm staring at a 9-track streamer drive that's decomposing on its own in the dark. Problem is that not only the panel parts are made from plastic, but so is the main chassis. This fals warld is bot transitory -- Dunbar --Chuck From dave.g4ugm at gmail.com Thu Sep 3 03:32:58 2020 From: dave.g4ugm at gmail.com (Dave Wade) Date: Thu, 3 Sep 2020 09:32:58 +0100 Subject: Basement Haul Message-ID: <0a8f01d681cc$d43ae7b0$7cb0b710$@gmail.com> At the risk of upsetting people who are perhaps hoping for a bargain can I send a link to this thread.. http://www.vcfed.org/forum/showthread.php?76560-Basement-full-of-DEC-parts-P DP-5-PDP-8-DEC-55-and-more/page2 I notice that there are card desks and an 029 that might interest folks. He says he "must sell" but may be amenable to donating such things. Dave Wade G4UGM & EA7KAE From paulkoning at comcast.net Thu Sep 3 08:08:06 2020 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 3 Sep 2020 09:08:06 -0400 Subject: Basement Haul In-Reply-To: <0a8f01d681cc$d43ae7b0$7cb0b710$@gmail.com> References: <0a8f01d681cc$d43ae7b0$7cb0b710$@gmail.com> Message-ID: <275A20C6-A479-42E4-8608-AC5A96520050@comcast.net> > On Sep 3, 2020, at 4:32 AM, Dave Wade via cctalk wrote: > > At the risk of upsetting people who are perhaps hoping for a bargain can I > send a link to this thread.. > > http://www.vcfed.org/forum/showthread.php?76560-Basement-full-of-DEC-parts-P > DP-5-PDP-8-DEC-55-and-more/page2 Unfortunately access to the pictures is restricted, silly of them. paul From lproven at gmail.com Thu Sep 3 08:15:34 2020 From: lproven at gmail.com (Liam Proven) Date: Thu, 3 Sep 2020 15:15:34 +0200 Subject: Basement Haul In-Reply-To: <275A20C6-A479-42E4-8608-AC5A96520050@comcast.net> References: <0a8f01d681cc$d43ae7b0$7cb0b710$@gmail.com> <275A20C6-A479-42E4-8608-AC5A96520050@comcast.net> Message-ID: On Thu, 3 Sep 2020 at 15:09, Paul Koning via cctalk wrote: > > Unfortunately access to the pictures is restricted, silly of them. Agreed but this is normal for VCFED. I do have an account but I've not used it in years -- the forums are a bit too US-centric for me, and I hate web fora in general. Otherwise I'd share this on FB for increased interest/attention. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From aek at bitsavers.org Thu Sep 3 09:49:42 2020 From: aek at bitsavers.org (=?utf-8?q?aek=40bitsavers=2Eorg?=) Date: Thu, 03 Sep 2020 16:49:42 +0200 Subject: =?utf-8?q?Re=3A?= Basement Haul In-Reply-To: <0a8f01d681cc$d43ae7b0$7cb0b710$@gmail.com> Message-ID: <19d8-5f510280-7d-4ac93500@53909284> On Thursday, September 03, 2020 10:32 CEST, "Dave Wade" wrote: > At the risk of upsetting people who are perhaps hoping for a bargain Hopefully someone with deep pockets can save this stuff that will be hard to move and has deep pockets. He knows he has some things that can be flipped for a lot of money. From aek at bitsavers.org Thu Sep 3 09:50:10 2020 From: aek at bitsavers.org (=?utf-8?q?aek=40bitsavers=2Eorg?=) Date: Thu, 03 Sep 2020 16:50:10 +0200 Subject: =?utf-8?q?Re=3A?= Basement Haul In-Reply-To: <0a8f01d681cc$d43ae7b0$7cb0b710$@gmail.com> Message-ID: <7540-5f510280-ad-111c9e40@169363143> On Thursday, September 03, 2020 10:32 CEST, "Dave Wade" wrote: > may be amenable to donating such things. > nope From dave.g4ugm at gmail.com Thu Sep 3 10:30:05 2020 From: dave.g4ugm at gmail.com (Dave G4UGM) Date: Thu, 3 Sep 2020 16:30:05 +0100 Subject: Compaq Security Enhancements for Microsoft Windows 2000 Message-ID: <005e01d68207$19886740$4c9935c0$@gmail.com> Whilst sifting through the loft I came across this brochure https://1drv.ms/b/s!Ag4BJfE5B3onmNYe9v2yiv2abf2Afg?e=0EjFbM for the Compaq Security Enhancements for Microsoft Windows 2000, which evolved from the Digital product "Secure NT" I wonder if any one actually used these products and can talk about them? Dave Wade (Al feel free to take a copy for Bitsavers) From jwest at classiccmp.org Thu Sep 3 11:10:45 2020 From: jwest at classiccmp.org (jwest at classiccmp.org) Date: Thu, 3 Sep 2020 11:10:45 -0500 Subject: domains available (FTGH) Message-ID: <000b01d6820c$c7a44ba0$56ece2e0$@classiccmp.org> Over the years I've snagged a few domains related to classic computing with the best intentions of doing something with them. I have not, so I will be letting the following expire: decvax.org dgeclipse.org dgnova.org hp1000.org hp2000.org pdp11.org rt-11.org You can of course wait to get them until they expire via your registrar of choice. If you want them sooner, let me know and after a week or so I'll subjectively decide who to approve a transfer to their registrar. Best, J From robert.jarratt at ntlworld.com Thu Sep 3 12:51:09 2020 From: robert.jarratt at ntlworld.com (Jarratt RMA) Date: Thu, 3 Sep 2020 18:51:09 +0100 (BST) Subject: domains available (FTGH) In-Reply-To: <000b01d6820c$c7a44ba0$56ece2e0$@classiccmp.org> References: <000b01d6820c$c7a44ba0$56ece2e0$@classiccmp.org> Message-ID: <749540523.1598231.1599155469767@mail2.virginmedia.com> Hello Jay, In the highly unlikely event that you get no interest in decvax.org I would be interested. I do an occasional blog and keep thinking it would be good to have a place to collect DEC VAX information. I think others are more likely to be able to dedicate more time to it, so give it to anyone you think would do it justice before falling back on me. I don't want it to get into the hands of domain squatters though! Regards Rob > On 03 September 2020 at 17:10 jwest--- via cctalk wrote: > > > Over the years I've snagged a few domains related to classic computing with > the best intentions of doing something with them. I have not, so I will be > letting the following expire: > > > > decvax.org > > dgeclipse.org > > dgnova.org > > hp1000.org > > hp2000.org > > pdp11.org > > rt-11.org > > > > You can of course wait to get them until they expire via your registrar of > choice. If you want them sooner, let me know and after a week or so I'll > subjectively decide who to approve a transfer to their registrar. > > > > Best, > > > > J > > > > > From edcross at gmail.com Thu Sep 3 12:53:42 2020 From: edcross at gmail.com (Ed C.) Date: Thu, 3 Sep 2020 19:53:42 +0200 Subject: domains available (FTGH) In-Reply-To: <000b01d6820c$c7a44ba0$56ece2e0$@classiccmp.org> References: <000b01d6820c$c7a44ba0$56ece2e0$@classiccmp.org> Message-ID: Interested in pdp11.org On Thu, Sep 3, 2020, 18:10 jwest--- via cctalk wrote: > Over the years I've snagged a few domains related to classic computing with > the best intentions of doing something with them. I have not, so I will be > letting the following expire: > > > > decvax.org > > dgeclipse.org > > dgnova.org > > hp1000.org > > hp2000.org > > pdp11.org > > rt-11.org > > > > You can of course wait to get them until they expire via your registrar of > choice. If you want them sooner, let me know and after a week or so I'll > subjectively decide who to approve a transfer to their registrar. > > > > Best, > > > > J > > > > > > From ian at platinum.net Thu Sep 3 12:56:32 2020 From: ian at platinum.net (Ian McLaughlin) Date: Thu, 3 Sep 2020 10:56:32 -0700 Subject: domains available (FTGH) In-Reply-To: References: <000b01d6820c$c7a44ba0$56ece2e0$@classiccmp.org> Message-ID: <78ED7638-D63F-4840-9768-FE7EBF1E6933@platinum.net> Jay, I currently run vaxhaven.com and I would be interested in acquiring decvax.org to point to that site. Ian > On Sep 3, 2020, at 10:53 AM, Ed C. via cctalk wrote: > > Interested in pdp11.org > > On Thu, Sep 3, 2020, 18:10 jwest--- via cctalk > wrote: > >> Over the years I've snagged a few domains related to classic computing with >> the best intentions of doing something with them. I have not, so I will be >> letting the following expire: >> >> >> >> decvax.org >> >> dgeclipse.org >> >> dgnova.org >> >> hp1000.org >> >> hp2000.org >> >> pdp11.org >> >> rt-11.org >> >> >> >> You can of course wait to get them until they expire via your registrar of >> choice. If you want them sooner, let me know and after a week or so I'll >> subjectively decide who to approve a transfer to their registrar. >> >> >> >> Best, >> >> >> >> J >> >> >> >> >> >> From couryhouse at aol.com Thu Sep 3 12:57:09 2020 From: couryhouse at aol.com (ED SHARPE) Date: Thu, 3 Sep 2020 17:57:09 +0000 (UTC) Subject: domains available (FTGH) References: <235669698.2063724.1599155829108.ref@mail.yahoo.com> Message-ID: <235669698.2063724.1599155829108@mail.yahoo.com> Please - Would love t he hp2000 domain Jay. Thanks Ed# On Thursday, September 3, 2020 jwest--- via cctalk wrote: Over the years I've snagged a few domains related to classic computing with the best intentions of doing something with them. I have not, so I will be letting the following expire: decvax.org dgeclipse.org dgnova.org hp1000.org hp2000.org pdp11.org rt-11.org You can of course wait to get them until they expire via your registrar of choice. If you want them sooner, let me know and after a week or so I'll subjectively decide who to approve a transfer to their registrar. Best, J From stefan.skoglund at agj.net Fri Sep 4 04:02:12 2020 From: stefan.skoglund at agj.net (Stefan Skoglund) Date: Fri, 04 Sep 2020 11:02:12 +0200 Subject: Brittle plastic In-Reply-To: References: Message-ID: ons 2020-09-02 klockan 13:46 -0700 skrev Chuck Guzis via cctalk: > On 9/2/20 12:02 PM, Rico Pajarola via cctalk wrote: > > I have a friend who is a Materials Science Technologist and > > specializes in > > injection molded plastics. So... basically the same thing that's in > > computer cases (even though he doesn't deal with computer cases). I > > grilled > > him at length on this topic, and he insisted that the brittleness > > with age > > (and UV light) is expected and irreversible. Basically, the plastic > > softeners are off-gassing, and there's no way to put them back in. > > > > I'm still hoping for a happier second opinion, though I'm not > > holding my > > breath. > > > > It's a very well-known problem among the museum conservation crowd > --and > with no practical solution. > > For a discussion, WikiPedia is pretty informative: > Textilmuseet (textiles and clothes museum in Bor?s, Sweden) have a number of items which was haute couture in the 70s and 80s. Some of them was done in a plastic which today is basically an awful mess... And so they are basically forced to thwrow away items which cost them a fair bit to buy. From lproven at gmail.com Fri Sep 4 05:48:32 2020 From: lproven at gmail.com (Liam Proven) Date: Fri, 4 Sep 2020 12:48:32 +0200 Subject: Brittle plastic In-Reply-To: References: Message-ID: On Fri, 4 Sep 2020 at 11:02, Stefan Skoglund via cctalk wrote: > Textilmuseet (textiles and clothes museum in Bor?s, Sweden) have a > number of items which was haute couture in the 70s and 80s. Some of > them was done in a plastic which today is basically an awful mess... > > And so they are basically forced to thwrow away items which cost them a > fair bit to buy. :-o I did not know it affected fabrics, too, but I guess it makes sense. That's awful. Perhaps the problems of accumulating microplastics in the biosphere will resolve itself sooner than expected... -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From technoid6502 at gmail.com Fri Sep 4 06:45:23 2020 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Fri, 04 Sep 2020 07:45:23 -0400 Subject: Brittle plastic Message-ID: I don't have a way to make plastic new, but I've had good results with WD40 for restoring surfaces with WD40. Some plastics get dusty and highly ablative on the surface with age and environment. Plastic LOVES WD40, if it is 'thirsty' Coat the plastic with WD40, and wait. It will soak in, sometimes it takes an overnight. Repeat this until the plastic no longer 'drinks' the WD40. You've done all you can do now with this method. I don't know that it restores the original strength of plastic, I doubt that, but it sure helps with the surfaces' appearance and wear resistence. Best, Jeff From john at ziaspace.com Fri Sep 4 12:28:05 2020 From: john at ziaspace.com (John Klos) Date: Fri, 4 Sep 2020 17:28:05 +0000 (UTC) Subject: domains available (FTGH) In-Reply-To: References: Message-ID: >> Over the years I've snagged a few domains related to classic computing with >> the best intentions of doing something with them. I have not, so I will be >> letting the following expire: >> >> decvax.org >> >> dgeclipse.org >> >> dgnova.org >> >> hp1000.org >> >> hp2000.org >> >> pdp11.org >> >> rt-11.org For anyone here with an interest in any of these domains, I'm happy to offer free hosting for at least as long as I'm alive (working on finding volunteers to take care of things after that). I've hosted some of my accounts and sites since the '90s and can provide email, web, dynamic web, development, gopher, mailman and more. I have real colocated servers, not purchased services, and the servers are, if nothing else, interesting. The collection include an AlphaServer DS25, a Sun Fire v254, an AMD Ryzen box (with ECC), a 1U Amiga 1200, and a 1U VAX. John Klos From john at ziaspace.com Fri Sep 4 13:36:32 2020 From: john at ziaspace.com (john at ziaspace.com) Date: Fri, 4 Sep 2020 14:36:32 -0400 (EDT) Subject: OFFLIST Re: domains available (FTGH) In-Reply-To: References: Message-ID: > Sun Fire v254, an AMD Ryzen box (with ECC), a 1U Amiga 1200, and a 1U VAX. > John Klos What OS do you run on the Amiga 1200 that is in a 1u case? That is pretty odd :-) - Ethan -- : Ethan O'Toole From healyzh at avanthar.com Fri Sep 4 14:21:24 2020 From: healyzh at avanthar.com (Zane Healy) Date: Fri, 4 Sep 2020 12:21:24 -0700 Subject: Not-OFFLIST Re: domains available (FTGH) In-Reply-To: References: Message-ID: <994A9169-DF5C-44D3-851B-0B50D150E2FF@avanthar.com> > On Sep 4, 2020, at 11:36 AM, John via cctalk wrote: > >> Sun Fire v254, an AMD Ryzen box (with ECC), a 1U Amiga 1200, and a 1U VAX. >> John Klos > > What OS do you run on the Amiga 1200 that is in a 1u case? > > That is pretty odd :-) I have to agree, that?s an interesting configuration. The 1U Vaxstation 4000/VLC makes a lot of sense, this, an A1200 I?m having a bit more trouble understanding. What is the purpose of this system? Zane From ethan at 757.org Fri Sep 4 14:31:53 2020 From: ethan at 757.org (Ethan O'Toole) Date: Fri, 4 Sep 2020 15:31:53 -0400 (EDT) Subject: Not-OFFLIST Re: domains available (FTGH) In-Reply-To: <994A9169-DF5C-44D3-851B-0B50D150E2FF@avanthar.com> References: <994A9169-DF5C-44D3-851B-0B50D150E2FF@avanthar.com> Message-ID: > I have to agree, that?s an interesting configuration. The 1U Vaxstation > 4000/VLC makes a lot of sense, this, an A1200 I?m having a bit more > trouble understanding. What is the purpose of this system? > Zane I would assume it can run Linux/Unix stuff? Though not sure you could get an accelerator on it. I wonder if it was some solution sold to TV stations that used an Amiga and a genlock in a box? - Ethan -- : Ethan O'Toole From john at ziaspace.com Fri Sep 4 17:12:32 2020 From: john at ziaspace.com (John Klos) Date: Fri, 4 Sep 2020 22:12:32 +0000 (UTC) Subject: Not-OFFLIST Re: domains available (FTGH) In-Reply-To: References: <994A9169-DF5C-44D3-851B-0B50D150E2FF@avanthar.com> Message-ID: >> I have to agree, that???s an interesting configuration. The 1U Vaxstation >> 4000/VLC makes a lot of sense, this, an A1200 I???m having a bit more >> trouble understanding. What is the purpose of this system? > > I would assume it can run Linux/Unix stuff? Though not sure you could get an > accelerator on it. > > I wonder if it was some solution sold to TV stations that used an Amiga and a > genlock in a box? The Amiga 1200 and accelerators for it are a form factor of a slightly thick and deep keyboard. Therefore, accelerators are made which don't require much height. The motherboard and accelerator fit tidily in a 1U case: http://lilith.ziaspace.com BTW - the pictures there are from the days of film cameras - that's how long ago I put it in that 1U. After recapping it a few years ago, it's back to being 100% stable. All the machines run NetBSD, and the Alpha, UltraSPARC and Amiga systems compile pkgsrc bulk binary packages for each of their architectures. While I do use the 1U VAX to do test compiles, with 24 megs and 5 VUPs it wouldn't make much of a bulk builder. I have a VAXstation 4000/60 and a 4000/90a for bulk building. Speaking of VAXstations - can anyone recommend someone who does power supply recapping and repair? I would like to get the power supply of the VAXstation 4000/90a fixed, and while I could just open it up and replace the whole circuit board with one from a modern power supply, I'd really rather keep it at least somewhat original. Thanks, John From healyzh at avanthar.com Fri Sep 4 17:34:48 2020 From: healyzh at avanthar.com (Zane Healy) Date: Fri, 4 Sep 2020 15:34:48 -0700 Subject: Not-OFFLIST Re: domains available (FTGH) In-Reply-To: References: <994A9169-DF5C-44D3-851B-0B50D150E2FF@avanthar.com> Message-ID: > On Sep 4, 2020, at 3:12 PM, John Klos via cctalk wrote: > >>> I have to agree, that?s an interesting configuration. The 1U Vaxstation 4000/VLC makes a lot of sense, this, an A1200 I?m having a bit more trouble understanding. What is the purpose of this system? >> >> I would assume it can run Linux/Unix stuff? Though not sure you could get an accelerator on it. >> >> I wonder if it was some solution sold to TV stations that used an Amiga and a genlock in a box? > > The Amiga 1200 and accelerators for it are a form factor of a slightly thick and deep keyboard. Therefore, accelerators are made which don't require much height. The motherboard and accelerator fit tidily in a 1U case: > > http://lilith.ziaspace.com > > BTW - the pictures there are from the days of film cameras - that's how long ago I put it in that 1U. After recapping it a few years ago, it's back to being 100% stable. Given that there are plenty of new film camera available for sale, I?m not going to hazard a guess as how long ago that was. The photo?s I took last weekend were on 35mm film. > All the machines run NetBSD, and the Alpha, UltraSPARC and Amiga systems compile pkgsrc bulk binary packages for each of their architectures. While I do use the 1U VAX to do test compiles, with 24 megs and 5 VUPs it wouldn't make much of a bulk builder. I have a VAXstation 4000/60 and a 4000/90a for bulk building. Okay, I was wondering if this were how you?re using it. This was just about the only use case I could think of for a rack mounted A1200. Have you considered virtualizing your build servers? > Speaking of VAXstations - can anyone recommend someone who does power supply recapping and repair? I would like to get the power supply of the VAXstation 4000/90a fixed, and while I could just open it up and replace the whole circuit board with one from a modern power supply, I'd really rather keep it at least somewhat original. That?s a good question, I have four VAXstation 4000?s, the one /60 runs 24x7, the other /60, as well as the /90 and the /VLC need work. I know the VLC has power supply issues, though if I remember correctly they?re with the bearings. I don?t remember what?s wrong with the other /60, and the /90. I don?t think I?ve ever had the /90 working. I?d love to get one of the ones that isn?t running turned back into a workstation. Zane From john at ziaspace.com Fri Sep 4 18:00:03 2020 From: john at ziaspace.com (John Klos) Date: Fri, 4 Sep 2020 23:00:03 +0000 (UTC) Subject: Not-OFFLIST Re: domains available (FTGH) In-Reply-To: References: <994A9169-DF5C-44D3-851B-0B50D150E2FF@avanthar.com> Message-ID: >> BTW - the pictures there are from the days of film cameras - that's how >> long ago I put it in that 1U. After recapping it a few years ago, it's >> back to being 100% stable. > > Given that there are plenty of new film camera available for sale, I?m > not going to hazard a guess as how long ago that was. The photo?s I > took last weekend were on 35mm film. I should've written that it was when film was the only real option unless you had money. I'd guess it was around 1998. > Okay, I was wondering if this were how you?re using it. This was just > about the only use case I could think of for a rack mounted A1200. > Have you considered virtualizing your build servers? There are three issues with that: One, I don't really trust x86, considering the Intel Management Engine and AMD PSP aren't openly documented, so I prefer to run important services on non-x86. Two, emulation isn't perfect and there are occasionally edge cases which occur because of things that are ever so slightly off because of FPU accuracy or things like that. Three, emulation is often not as fast as real hardware. A VAXstation 4000/90a is about as fast as SIMH running VAX on a really fast x86, and m68k emulation is often slower than on a real m68060 because BSD requires an MMU, and that means that JIT can't be used. > That?s a good question, I have four VAXstation 4000?s, the one /60 > runs 24x7, the other /60, as well as the /90 and the /VLC need work. I > know the VLC has power supply issues, though if I remember correctly > they?re with the bearings. I don?t remember what?s wrong with the > other /60, and the /90. I don?t think I?ve ever had the /90 > working. > > I?d love to get one of the ones that isn?t running turned back into > a workstation. Anyone? :D John From derschjo at gmail.com Sat Sep 5 14:19:44 2020 From: derschjo at gmail.com (Josh Dersch) Date: Sat, 5 Sep 2020 12:19:44 -0700 Subject: ISO: DEC VR100 and early X releases Message-ID: Hi all -- I was fortunate enough to be able to complete my VAXstation 100 setup this week, after a years-long search for parts. (In particular the M7452 fiber optic interface and the fiber optic cabling itself.) After futzing with the 4.3bsd kernel and compiling X10R4 on my VAX-11/750, I actually have it running! (See the below for a picture) https://1drv.ms/u/s!Aqb36sqnCIfMo_cUO4EiMWOHZVk8yg I'm kind of amazed that it all just worked after all this time. As you can see, I'm using an LCD for the display, and that just won't do. The official monitor for the VS100 was the VR100; a 19" monochrome CRT with BNC inputs on the rear for H and V sync and the video signal (ttl level signaling). Anyone have one of these? I'm also looking for earlier releases of X to run on this -- the VS100 was the development platform for X (and W ran on it at one point as well). I haven't been able to track down anything prior to X10R3. Does anyone know of an archive of these earlier releases? While I'm at it -- anyone know precisely what I need to use this under VMS? I believe 4.7 was the last VMS release that supported it, but there were additional packages that needed to be installed to support it, and I'm not entirely sure what they are. Thanks as always, Josh From lars at nocrew.org Sat Sep 5 15:29:19 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 05 Sep 2020 20:29:19 +0000 Subject: ISO: DEC VR100 and early X releases In-Reply-To: (Josh Dersch via cctalk's message of "Sat, 5 Sep 2020 12:19:44 -0700") References: Message-ID: <7wv9gsj7c0.fsf@junk.nocrew.org> Josh Dersch via cctalk writes: > I'm also looking for earlier releases of X to run on this -- the VS100 > was the development platform for X (and W ran on it at one point as > well). I haven't been able to track down anything prior to X10R3. I asked the usual suspects (Reid, Asente, Kantarjiev) about W, but it seems to be lost. From spectre at floodgap.com Sat Sep 5 17:30:04 2020 From: spectre at floodgap.com (Cameron Kaiser) Date: Sat, 5 Sep 2020 15:30:04 -0700 (PDT) Subject: ISO: DEC VR100 and early X releases In-Reply-To: from Josh Dersch via cctalk at "Sep 5, 20 12:19:44 pm" Message-ID: <202009052230.085MU4P635848248@floodgap.com> > I was fortunate enough to be able to complete my VAXstation 100 setup this > week, after a years-long search for parts. (In particular the M7452 fiber > optic interface and the fiber optic cabling itself.) > > After futzing with the 4.3bsd kernel and compiling X10R4 on my VAX-11/750, > I actually have it running! (See the below for a picture) > > https://1drv.ms/u/s!Aqb36sqnCIfMo_cUO4EiMWOHZVk8yg Beautiful! -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Workers of the world, stand up! You have nothing to lose but your chairs. -- From cmhanson at eschatologist.net Sat Sep 5 20:21:17 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 5 Sep 2020 18:21:17 -0700 Subject: Micro Memory VME card info? MM-6316 Message-ID: I have a Micro Memory Inc. 16MB VME DRAM card MM-6316 but unlike many other Micro Memory products I can?t find a user?s manual. Does anyone know anything about the jumpers/switches for this board? ? Chris Sent from my iPad From cmhanson at eschatologist.net Sun Sep 6 14:21:56 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sun, 6 Sep 2020 12:21:56 -0700 Subject: CMU Andrew system (and wm) preservation Message-ID: Back before X11 took off, IBM funded CMU's development of Andrew, which had its own complete window system represented by its "wm" window manager. One of the many things that led to X's prevalence was that to get ahold of Andrew and wm, you had to license it from IBM, whereas X was licensed freely by MIT and available via FTP, tape, etc. When I was at CMU in the early through mid 1990s, the CMU Computer Club continued to maintain a fork of "wm" called "wmc" that was available to club members, including source code. While I'm pretty sure I have an archive of this code on a Zip disk somewhere, I thought I'd put out the call to the community to see if anyone else had preserved early Andrew bits since they're both historically important and architecturally interesting. What's architecturally interesting about them? Among other things, CMU created their own shared library mechanism for Andrew, and their own object oriented dialect of C (implemented via a separate preprocessor) that was surprisingly similar to Objective-C. The entire Andrew system was also component-oriented, such that it supported embedding components for handling different media types within each other, while keeping the embedded ones editable -- most of what developers got later with OLE and OpenDoc. So it'd be great if this stuff was archived in such a way that it could be used with contemporary systems, whether emulated or real hardware. Has anyone done any of this yet? -- Chris From jules.richardson99 at gmail.com Sun Sep 6 15:27:32 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Sun, 6 Sep 2020 15:27:32 -0500 Subject: CGA card (Mitsubishi Electric) with 192K RAM? Message-ID: Digging through old PCs, on a battery-removal spree... came across a Sperry 3070 XT-a-like (I wouldn't quite call it a clone, it's a bit goofy) which has a Mitsubishi Electric system board, RAM expansion, and video hardware. The video hardware is... odd. It's actually two full-length boards, joined with a large IDC cable along the top edge as well as via the ISA bus. The only "complex" IC is a 6845 - other than that it's masses of TTL. Output is via a DE9, and pinouts seem consistent with CGA (15.7KHz on pin 8, 60Hz on pin 9, 3/4/5 at TTL levels and 1/2 ground). There's also an RCA jack on the backplate, and that 6845 IC... it all seems very CGA-like, except that total video memory is 192KB. CGA was normally 16KB, I believe. Hercules and EGA 64KB, although I think toward the end of EGA's existence there was a 192KB option. Physical outputs aren't consistent with EGA's two bits per pixel, though. Does this ring any bells with anyone? I don't know why it needs such a large amount of RAM if it's stuck with CGA capabilities. One board is branded WECD10 and the other WECD11, but there's no "model" or anything. cheers Jules From dstalk at execulink.com Sun Sep 6 16:10:52 2020 From: dstalk at execulink.com (Don Stalkowski) Date: Sun, 6 Sep 2020 17:10:52 -0400 Subject: CMU Andrew system (and wm) preservation In-Reply-To: References: Message-ID: <20200906211052.GA12122@cel2> On Sun, Sep 06, 2020 at 12:21:56PM -0700, Chris Hanson via cctalk wrote: > Back before X11 took off, IBM funded CMU's development of Andrew, which had its own complete window system represented by its "wm" window manager. One of the many things that led to X's prevalence was that to get ahold of Andrew and wm, you had to license it from IBM, whereas X was licensed freely by MIT and available via FTP, tape, etc. > > When I was at CMU in the early through mid 1990s, the CMU Computer Club continued to maintain a fork of "wm" called "wmc" that was available to club members, including source code. While I'm pretty sure I have an archive of this code on a Zip disk somewhere, I thought I'd put out the call to the community to see if anyone else had preserved early Andrew bits since they're both historically important and architecturally interesting. > > What's architecturally interesting about them? Among other things, CMU created their own shared library mechanism for Andrew, and their own object oriented dialect of C (implemented via a separate preprocessor) that was surprisingly similar to Objective-C. The entire Andrew system was also component-oriented, such that it supported embedding components for handling different media types within each other, while keeping the embedded ones editable -- most of what developers got later with OLE and OpenDoc. > > So it'd be great if this stuff was archived in such a way that it could be used with contemporary systems, whether emulated or real hardware. Has anyone done any of this yet? > > -- Chris > Forgive a dumb question, but is this somehow related to the Andrew Tool Kit or the Andrew User Interface System? don From cmhanson at eschatologist.net Sun Sep 6 16:26:40 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sun, 6 Sep 2020 14:26:40 -0700 Subject: CMU Andrew system (and wm) preservation In-Reply-To: <20200906211052.GA12122@cel2> References: <20200906211052.GA12122@cel2> Message-ID: <6433C3B8-AA3D-4002-8790-A22F1900220B@eschatologist.net> On Sep 6, 2020, at 2:10 PM, Don Stalkowski wrote: > > Forgive a dumb question, but is this somehow related to the Andrew Tool Kit > or the Andrew User Interface System? Yes indeed, the Andrew window manager and the Andrew Tool Kit were both part of the Andrew User Interface System. -- Chris From wrcooke at wrcooke.net Sun Sep 6 19:14:12 2020 From: wrcooke at wrcooke.net (wrcooke at wrcooke.net) Date: Sun, 6 Sep 2020 19:14:12 -0500 (CDT) Subject: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: Message-ID: <405035597.328143.1599437652086@email.ionos.com> > On 09/06/2020 3:27 PM Jules Richardson via cctalk wrote: > > > > > Output is via a DE9, and pinouts seem consistent with CGA (15.7KHz on pin > 8, 60Hz on pin 9, 3/4/5 at TTL levels and 1/2 ground). There's also an RCA > jack on the backplate, and that 6845 IC... it all seems very CGA-like, > except that total video memory is 192KB. snip > Does this ring any bells with anyone? I don't know why it needs such a > large amount of RAM if it's stuck with CGA capabilities. One board is > branded WECD10 and the other WECD11, but there's no "model" or anything. > > cheers > > Jules My guess, and ONLY a guess, is that it is sort-of CGA. Perhaps with 640x400 and/or more color depth. 192k should give 640x400 with 12 bits per pixel if my gray matter is working right. It would have to be interlaced, of course, for 640x400. Or maybe 640x200 with 16M colors (24 bpp). Again, just a guess. Will "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery "The names of global variables should start with// " --?https://isocpp.org From newsgroups at micromuseum.co.uk Mon Sep 7 08:17:22 2020 From: newsgroups at micromuseum.co.uk (newsgroups at micromuseum.co.uk) Date: Mon, 7 Sep 2020 14:17:22 +0100 Subject: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: Message-ID: <000b01d68519$3a210f10$ae632d30$@micromuseum.co.uk> You might find reading this thread useful: https://www.vogons.org/viewtopic.php?t=57843 -----Original Message----- From: cctalk On Behalf Of Jules Richardson via cctalk Sent: 06 September 2020 21:28 To: General Discussion: On-Topic and Off-Topic Posts Subject: CGA card (Mitsubishi Electric) with 192K RAM? Digging through old PCs, on a battery-removal spree... came across a Sperry 3070 XT-a-like (I wouldn't quite call it a clone, it's a bit goofy) which has a Mitsubishi Electric system board, RAM expansion, and video hardware. The video hardware is... odd. It's actually two full-length boards, joined with a large IDC cable along the top edge as well as via the ISA bus. The only "complex" IC is a 6845 - other than that it's masses of TTL. Output is via a DE9, and pinouts seem consistent with CGA (15.7KHz on pin 8, 60Hz on pin 9, 3/4/5 at TTL levels and 1/2 ground). There's also an RCA jack on the backplate, and that 6845 IC... it all seems very CGA-like, except that total video memory is 192KB. CGA was normally 16KB, I believe. Hercules and EGA 64KB, although I think toward the end of EGA's existence there was a 192KB option. Physical outputs aren't consistent with EGA's two bits per pixel, though. Does this ring any bells with anyone? I don't know why it needs such a large amount of RAM if it's stuck with CGA capabilities. One board is branded WECD10 and the other WECD11, but there's no "model" or anything. cheers Jules From jules.richardson99 at gmail.com Mon Sep 7 08:49:59 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 7 Sep 2020 08:49:59 -0500 Subject: IBM 5160 math copro switch Message-ID: <8185e77c-2966-7e22-79f8-769f43ca80f0@gmail.com> Sifting through my XTs and clones... I've had three so far with no math copro (8087) fitted, but switch 2 of SW1 is set to off. IBM docs say off is "math copro installed" and on is the "installed" position, i.e. the reverse of what I'm seeing (the minuszerodegrees site repeats this, although I expect that just copied what's in the manual, too). These three machines (two are 5160's, the other a clone) came from completely different sources - it seems unlikely that all three had 8087's fitted which were pulled at some point. Googling a few more system board images, ones with 8087's have that switch on - but for boards without, the setting seems to be pretty much 50/50. Did the meaning of the switch perhaps change at some point (both of my 5160's are late model 256-640 boards), and rather than being a simple installed / not installed it was more along the lines of "software should use it if present / software should never use it"? After all, it's not like the BIOS will do anything with an 8087; it's only there for software specifically coded to make use of it. I suppose it's also possible that users were in the habit of first setting all the switches to off when configuring a machine, then setting the relevant ones to on according to their memory/floppy/video config - and the copro setting just got overlooked. Weird, anyway. Jules From jules.richardson99 at gmail.com Mon Sep 7 10:18:56 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 7 Sep 2020 10:18:56 -0500 Subject: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: <000b01d68519$3a210f10$ae632d30$@micromuseum.co.uk> References: <000b01d68519$3a210f10$ae632d30$@micromuseum.co.uk> Message-ID: <82b4278d-b394-c203-d06f-5f832e64f2c6@gmail.com> On 9/7/20 8:17 AM, newsgroups at micromuseum.co.uk wrote: > You might find reading this thread useful: > > https://www.vogons.org/viewtopic.php?t=57843 That's excellent - thankyou! I'd been trying to find anything about this machine at all and not having much luck (I'll print all that out and leave it inside the case, I think). I wonder what the "advanced features" governed by switch 3/3 were :-) I was hoping there would still be data on the hard disk (it's always fun seeing how these machines were used) but sadly mine throws up a "command error" from the disk hardware at startup - so either the drive's bad, has been LLFed prior to disposal, or there's an issue with the controller itself. Jules From jules.richardson99 at gmail.com Mon Sep 7 10:59:29 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 7 Sep 2020 10:59:29 -0500 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: Message-ID: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> On 9/7/20 2:26 AM, Veit, Holger wrote: > Could this be a PGC card clone? > https://en.wikipedia.org/wiki/Professional_Graphics_Controller That had crossed my mind at one point, but there's no horsepower to this card at all - it's just TTL, RAM, BIOS and the 6845. The color output *appears* to be TTL level - or, at least, that's what it's using at power-on. It's not impossible, I suppose, for it to be switchable to some kind of analog mode, thereby giving more color depth. I'm wondering if it doesn't have some form of high-resolution bitmap mode for visualization, i.e. display construction would be processor-intensive and intended for static images/diagrams. I don't know if that really makes sense though because it would also imply having to switch the monitor - i.e. starting the machine with a CGA type display plugged in, then physically moving to something else later. On the back of that, I just found this thread too which refers to an identical board: http://www.vcfed.org/forum/showthread.php?48718-3-Weird-Video-Cards-any-idea-about-what-they-do ... nothing there really "helps", but someone's comment about the medical field and a higher-resolution display via the RCA jack is interesting - that would at least get around the need to switch monitors (well, unless there was some special autodetecting analog/digital monitor that was sold to go with the hardware, I suppose). It's a shame that the hard disk in the machine is either snafu or has been wiped - the contents would have helped shed light on things. There's an EPROM as part of the video hardware; anyone know of a DOS-based util to poke at the contents and/or snarf them into a file on disk? It's possible I suppose that there might be some useful strings hidden away in there. cheers Jules From billdegnan at gmail.com Mon Sep 7 11:00:11 2020 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 7 Sep 2020 12:00:11 -0400 Subject: IBM 5160 math copro switch In-Reply-To: <8185e77c-2966-7e22-79f8-769f43ca80f0@gmail.com> References: <8185e77c-2966-7e22-79f8-769f43ca80f0@gmail.com> Message-ID: A good game theory word problem.. The rationale causing manufacturers to set the switch to "is installed" given they know that if there is no co-processor installed the system will still work. It would only be an issue if one had the co-precessor installed and the switch was set to "none" So my conclusion would be instructing the customer to insert the chip and verify the switch was "on", rather than have them also flip switches, possibly making an error is best. I could see the conclusion would be to ship them in the "on" position, despite possible confusion by the very small percentage of owners who open the cover and inspect their switches vs the risk of damaging the board or causing misconfigurstion of something else as a result of changing switches incorrectly. I was a support line manager in the early 90s, I remember how simple decisions like that would change call volume, effect labor requirements, etc. Brings back memories. Bill On Mon, Sep 7, 2020, 9:50 AM Jules Richardson via cctalk < cctalk at classiccmp.org> wrote: > > Sifting through my XTs and clones... I've had three so far with no math > copro (8087) fitted, but switch 2 of SW1 is set to off. > > IBM docs say off is "math copro installed" and on is the "installed" > position, i.e. the reverse of what I'm seeing (the minuszerodegrees site > repeats this, although I expect that just copied what's in the manual, > too). > > These three machines (two are 5160's, the other a clone) came from > completely different sources - it seems unlikely that all three had 8087's > fitted which were pulled at some point. Googling a few more system board > images, ones with 8087's have that switch on - but for boards without, the > setting seems to be pretty much 50/50. > > Did the meaning of the switch perhaps change at some point (both of my > 5160's are late model 256-640 boards), and rather than being a simple > installed / not installed it was more along the lines of "software should > use it if present / software should never use it"? After all, it's not > like > the BIOS will do anything with an 8087; it's only there for software > specifically coded to make use of it. > > I suppose it's also possible that users were in the habit of first setting > all the switches to off when configuring a machine, then setting the > relevant ones to on according to their memory/floppy/video config - and > the > copro setting just got overlooked. > > Weird, anyway. > > Jules > > From a.carlini at ntlworld.com Mon Sep 7 11:50:02 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Mon, 7 Sep 2020 17:50:02 +0100 Subject: TZ8x DLT III cartridge - torn leader In-Reply-To: References: Message-ID: On 02/09/2020 11:11, Antonio Carlini wrote: > > > > So I'm rather confused about what's happened. More importantly, I > don't know how to fix the drives I do have. > > > I thought I should follow up with further information, so as not to pollute the archives with mis-information. The one tape unit that I've never used does indeed have a missing leader. As for the others, they had all snapped the tape (from the cartridge) quite some way into the tape. So the leader was attached to the tape, which then surrounded it on the rear spool. I missed that because I didn't know what I was looking for. Once I realised what had happened I gently started to unwind the rear spool enough that I could grab the tape and then I basically pulled it all through (many metres of it) until I reached the tape leader. The tape was discarded and the leader reattached to the hook. That itself proved to be a bit fiddly the first time I did it. I found that to get the drive to POST properly I had to manually rotate the rear spool just enough to have the tape leader pull back gently on the hook. I also had a stuck tape. That required me to use the screw underneath the centre of the inserted cartridge to rewind the tape back into the cartridge. Once I'd rewound all of it the tape leader came into view. It then detached from the tape. I don't remember if I had to do that manually or not. Similarly I may have reattached it to the hook manually. There's a lever to the side of the cartridge that you gently move to allow the tape to be released by lifting the normal handle. Antonio -- Antonio Carlini antonio at acarlini.com From a.carlini at ntlworld.com Mon Sep 7 11:56:56 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Mon, 7 Sep 2020 17:56:56 +0100 Subject: Clicking SCSI disks Message-ID: I have a number of old (2000-era) DEC StorageWorks disks that fail to mount under VMS. They report MEDIUM OFFLINE. They power up in a similar way to other disks that do work, but they persistently click ina? "something isn't right" manner. I've tried reorienting some of the disks to see if that makes any difference, and for the ones I've tried, it didn't help. I've read about the "freezer" trick, but mostly I've seen negative opinions. However, those opinions mostly come from data recovery specialists! So I thought I'd tap the wisdom of the list. Is there any way that people have used to successfully recover data from RZ28, RZ29 disks (which all worked in 2003 :-))? Has anyone tried freezing a double bagged drive? Was it successful? If so, how long did you freeze it for? These disks are in StorageWorks containers ... should I remove them before freezing? Antonio -- Antonio Carlini antonio at acarlini.com From billdegnan at gmail.com Mon Sep 7 12:39:16 2020 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 7 Sep 2020 13:39:16 -0400 Subject: Clicking SCSI disks In-Reply-To: References: Message-ID: On Mon, Sep 7, 2020 at 12:57 PM Antonio Carlini via cctalk < cctalk at classiccmp.org> wrote: > I have a number of old (2000-era) DEC StorageWorks disks that fail to > mount under VMS. They report MEDIUM OFFLINE. > > They power up in a similar way to other disks that do work, but they > persistently click ina "something isn't right" manner. > > > I've tried reorienting some of the disks to see if that makes any > difference, and for the ones I've tried, it didn't help. > > > I've read about the "freezer" trick, but mostly I've seen negative > opinions. However, those opinions mostly come from data recovery > specialists! > > > So I thought I'd tap the wisdom of the list. Is there any way that > people have used to successfully recover data from RZ28, RZ29 disks > (which all worked in 2003 :-))? Has anyone tried freezing a double > bagged drive? Was it successful? If so, how long did you freeze it for? > These disks are in StorageWorks containers ... should I remove them > before freezing? > > > Antonio, If there is no stiction then tapping the disk or opening to spin the disk manually does nothing useful IMHO other than expose the surface to dust. It could be that you need a new controller, you could always try a transplant of the controller electronics from one drive to another to dump the data. Has to be the same type of drive, etc. It's all a percentages thing, you might save one out of 4 swapping around electronics. If you have nothing to lose and you don't mind possibly making it worse ... Bill From cisin at xenosoft.com Mon Sep 7 13:04:10 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 7 Sep 2020 11:04:10 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> Message-ID: On Mon, 7 Sep 2020, Jules Richardson via cctalk wrote: > It's a shame that the hard disk in the machine is either snafu or has been > wiped - the contents would have helped shed light on things. There's an EPROM > as part of the video hardware; anyone know of a DOS-based util to poke at the > contents and/or snarf them into a file on disk? It's possible I suppose that > there might be some useful strings hidden away in there. "DOS based utility program to poke at the contents and/or snarf the int a file on disk"? DEBUG.COM Present since PC-DOS/MS-DOS 1.0 STILL there. As it got more bloated, it eventually became a .EXE file, but still FALSELY named .COM (DOS didn't care which of the two extensions, but looked for "MZ" in first two bytes of the header.) The character generator ROM might not be accessible in the memory map. OR, the ROM could be a BIOS extension. There did exist some CGA-like boards with more RAM. I had one (from Plantronics??) that was a double board, with 640 x 400, and 640 x 200 with more colors. It was NOT the same as yours, in at least trivial ways - it did not have an RCA, but had composite on an RF modulator (4 pin) connector. The Vogons page https://www.vogons.org/viewtopic.php?t=57843 while very useful, is immediately suspect, by starting out with saying "100% compatible". It was NOT. Compatible enough for MOST stuff, but of course, it did not have the IBM BASIC ROMs, and therefore came with GW-BASIC. My buddy had a few Sperry 5160-like machines, as well as some PBM-1000's (Micropro CP/M machine). They were dumpstered immediately when he died 5 years ago. -- Grumpy Ol' Fred cisin at xenosoft.com From cisin at xenosoft.com Mon Sep 7 13:17:57 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 7 Sep 2020 11:17:57 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> Message-ID: BTW, XT compatibles with the Xebec (and Xebec-like) hard disk controllers would not give a "COMMAND ERROR" message for a Low-level-formatted/wiped hard disk. Probably a "1701" error. NOTE: for the 5170 (AT), IBM switched from the Xebec controller to a Western Digital one. There were many models of Xebec controller, and numerous other brands. The specific model Xebec that IBM used had 4 pairs of solder pads near the center of the board for selecting drive type for 2 drives. all open was 10MB. other supported sizes (could be over-ridden by loading software at boot) were 5MB, 16M and 26MB? And, even if it were somehow "compatible" with a completely different hard disk controller, "COMMAND ERROR" doesn't sound like anybody's error message for a wiped drive. More likely to be a generic "READ ERROR" If DOS were booted from floppy, the MS-DOS error message for a wiped HDD (address mark not found) would be "General Failure" -- Grumpy Ol' Fred cisin at xenosoft.com From cctalk at beyondthepale.ie Mon Sep 7 12:50:57 2020 From: cctalk at beyondthepale.ie (Peter Coghlan) Date: Mon, 07 Sep 2020 18:50:57 +0100 (WET-DST) Subject: Clicking SCSI disks In-Reply-To: Message-ID: <01RPDGZWS4OA8ZDV7U@beyondthepale.ie> Antonio Carlini wrote: > > So I thought I'd tap the wisdom of the list. Is there any way that > people have used to successfully recover data from RZ28, RZ29 disks > (which all worked in 2003 :-))? Has anyone tried freezing a double > bagged drive? Was it successful? If so, how long did you freeze it for? > These disks are in StorageWorks containers ... should I remove them > before freezing? > I have some RZ28 (2GB?) disks but I don't recall having any difficulties with them. I do have some RZ29B (4.3GB) disks that fail to spin up when requested to unless they are given some physical encouragement in the form of a sharp twist or some vigourous tapping. They can be heard to make a very faint and short purr when trying and failing to spin up but no clicking noises and no data issues. I have more than one RZ26L (1.05GB) disk which I reinitialised and installed a new system on which then failed horribly with nasty clicking noises after working nicely for a very short time. I haven't found any way to fix this condition and I don't know if almost completely rewriting them is what triggered it to happen or maybe it was because of sudden activity after years of idleness. I didn't try freezing them. I also have one Compaq 9GB SCA disk which made heart-stoppingly loud clunks and clicks at irregular intervals but continued to function normally in this condition for several years. I had copied it's contents to a new disk but left it in place to see how it would fail. It didn't. I eventually took it out and examined it, found nothing obvious wrong, put it back in and decided to make an audio recording of the noises it had been making. Of course, it then refused to make any more noises after being disturbed and continues to work normally without any data issues whatsoever. Regards, Peter Coghlan. From cmhanson at eschatologist.net Mon Sep 7 13:43:51 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Mon, 7 Sep 2020 11:43:51 -0700 Subject: CMU Andrew system (and wm) preservation In-Reply-To: <20200907020157.2851DBEEAB8@cel2.x> References: <20200907020157.2851DBEEAB8@cel2.x> Message-ID: <99A5414B-6E5B-46E7-8C5D-E0E711F6F597@eschatologist.net> On Sep 7, 2020, at 6:24 AM, dstalk at execulink.com wrote: > > The description I have for AUIS (6.3.1) is: > > "AUIS (Andrew User Interface System) - compound document > environment offering a word processor, mail/bulletin board > reader/writer, drawing editor, spreadsheet, font editor, > application builder, and many other facilities" > > Again, an application, not a windowing system per se. Yes, the Andrew environment implemented proper layering, so ATK was made to work atop X and the applications (messages, ez, console, typescript, etc.) came along. At Carnegie Mellon in the early 1990s, you could (with only a little work, to use a console rather than graphical login) use either X or wm on some of the campus workstations. On a DECstation 3100 running Ultrix, if you weren?t going to run any X applications wm was *much* more responsive. I wasn?t around when the clusters had Sun-3 or IBM RT hardware but I can imagine the differences there were even more pronounced. (With wm, a DECstation felt as much faster than a Mac II as it actually was?) Applications built against ATK could run atop either wm or X; I don?t know if there were distinct builds of ATK or if the conditional logic was in the framework itself, but the applications themselves worked just fine with either since Andrew implemented a shared library mechanism. (Yes, even on Ultrix.) The publicly-released Andrew distributions don?t include the wm code, only the X version. I don?t know if they?ll actually build against the wm headers and libraries if they?re present, or if by the time CMU was releasing them publicly they had stripped that code out entirely. ? Chris From w2hx at w2hx.com Mon Sep 7 13:46:31 2020 From: w2hx at w2hx.com (W2HX) Date: Mon, 7 Sep 2020 18:46:31 +0000 Subject: VAX 11-780 Rack Available Message-ID: Hi friends. This rack is available for free. I am located in 10510 happy to drive, up to say 1.5 hours to meet up to transfer vehicles? https://w2hx.com/ForSale/DEC%20Rack/20200719_114742.jpg https://w2hx.com/ForSale/DEC%20Rack/20200719_114751.jpg it is in very nice condition. Comes with wheels/casters, no panels. It is, I believe 24" wide, but it has a set of vertical rails at 19" in addition to 24" I think the space on the right would carry cables etc? Regardless, it will work fine with 19" equipment. Just the perfect think you need to complete your DEC VAX or other DEC set up! Contact me directly. 73 Eugene W2HX PS Please pass onto any other list you may belong to that might have an interest in this rack. Thank you From jules.richardson99 at gmail.com Mon Sep 7 13:54:41 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 7 Sep 2020 13:54:41 -0500 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> Message-ID: <120584b5-b794-0075-4819-568ab0b21b42@gmail.com> On 9/7/20 1:04 PM, Fred Cisin via cctalk wrote: > "DOS based utility program to poke at the contents and/or snarf the int a > file on disk"? > DEBUG.COM Funny, I've only ever used it for quick bits of assembly (just a couple of days ago, in fact), and to do things such as kicking off the formatter embedded in the ROM on some controllers. It didn't even occur to me that it probably has some dumping/loading abilities too! I'll dig some docs out... > My buddy had a few Sperry 5160-like machines, as well as some PBM-1000's > (Micropro CP/M machine).? They were dumpstered immediately when he died 5 > years ago. Honestly I've always been a bit indifferent about the PC stuff (which is probably why I've had these for around a decade and am only now really looking at them) - I'd still rather save them when I see them, though (at least up until the point where I run out of space - but "early x86 PC" seems to have quite a following these days). cheers Jules From dave.g4ugm at gmail.com Mon Sep 7 14:01:12 2020 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Mon, 7 Sep 2020 20:01:12 +0100 Subject: Clicking SCSI disks In-Reply-To: References: Message-ID: <01c501d68549$413138e0$c393aaa0$@gmail.com> No success freezing a drive. Might help with your problem. I wonder if the head has stuck to the rubber bump stop. Freezing might make it less gooey and let it free off. Or you could try this https://hackaday.com/2015/10/13/macintosh-hard-drive-repair/ put you really should only open drives in a clean room... Dave G4UGM > -----Original Message----- > From: cctalk On Behalf Of Bill Degnan via > cctalk > Sent: 07 September 2020 18:39 > To: antonio at acarlini.com; Antonio Carlini ; General > Discussion: On-Topic and Off-Topic Posts > Subject: Re: Clicking SCSI disks > > On Mon, Sep 7, 2020 at 12:57 PM Antonio Carlini via cctalk < > cctalk at classiccmp.org> wrote: > > > I have a number of old (2000-era) DEC StorageWorks disks that fail to > > mount under VMS. They report MEDIUM OFFLINE. > > > > They power up in a similar way to other disks that do work, but they > > persistently click ina "something isn't right" manner. > > > > > > I've tried reorienting some of the disks to see if that makes any > > difference, and for the ones I've tried, it didn't help. > > > > > > I've read about the "freezer" trick, but mostly I've seen negative > > opinions. However, those opinions mostly come from data recovery > > specialists! > > > > > > So I thought I'd tap the wisdom of the list. Is there any way that > > people have used to successfully recover data from RZ28, RZ29 disks > > (which all worked in 2003 :-))? Has anyone tried freezing a double > > bagged drive? Was it successful? If so, how long did you freeze it for? > > These disks are in StorageWorks containers ... should I remove them > > before freezing? > > > > > > > Antonio, > If there is no stiction then tapping the disk or opening to spin the disk > manually does nothing useful IMHO other than expose the surface to dust. > It could be that you need a new controller, you could always try a transplant > of the controller electronics from one drive to another to dump the data. > Has to be the same type of drive, etc. It's all a percentages thing, you might > save one out of 4 swapping around electronics. If you have nothing to lose > and you don't mind possibly making it worse ... > Bill From stefan.skoglund at agj.net Mon Sep 7 14:10:00 2020 From: stefan.skoglund at agj.net (Stefan Skoglund) Date: Mon, 07 Sep 2020 21:10:00 +0200 Subject: CMU Andrew system (and wm) preservation In-Reply-To: <99A5414B-6E5B-46E7-8C5D-E0E711F6F597@eschatologist.net> References: <20200907020157.2851DBEEAB8@cel2.x> <99A5414B-6E5B-46E7-8C5D-E0E711F6F597@eschatologist.net> Message-ID: <0537656821ab33063ac66b5daee42e1fcaf66e6c.camel@agj.net> m?n 2020-09-07 klockan 11:43 -0700 skrev Chris Hanson via cctalk: > On Sep 7, 2020, at 6:24 AM, dstalk at execulink.com wrote: > > The description I have for AUIS (6.3.1) is: > > > > "AUIS (Andrew User Interface System) - compound document > > environment offering a word processor, mail/bulletin board > > reader/writer, drawing editor, spreadsheet, font editor, > > application builder, and many other facilities" > > > > Again, an application, not a windowing system per se. > > Yes, the Andrew environment implemented proper layering, so ATK was > made to work atop X and the applications (messages, ez, console, > typescript, etc.) came along. > > At Carnegie Mellon in the early 1990s, you could (with only a little > work, to use a console rather than graphical login) use either X or > wm on some of the campus workstations. On a DECstation 3100 running > Ultrix, if you weren?t going to run any X applications wm was *much* > more responsive. I wasn?t around when the clusters had Sun-3 or IBM > RT hardware but I can imagine the differences there were even more > pronounced. (With wm, a DECstation felt as much faster than a Mac II > as it actually was?) The hackers in the lab in Ume? Sweden said the same thing about X11 vs Sunview on the lab's 3/60 and 3/80 machines compared with the 1(+?). Running Sun's debug tool (in its sunview version) on a 3/60 were ok, no lag dito starting sunview's cmdtool , while xterm werent so snappy on the same machine. From jules.richardson99 at gmail.com Mon Sep 7 14:22:06 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 7 Sep 2020 14:22:06 -0500 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> Message-ID: <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> On 9/7/20 1:17 PM, Fred Cisin via cctalk wrote: > BTW, XT compatibles with the Xebec (and Xebec-like) hard disk controllers > would not give a "COMMAND ERROR" message for a Low-level-formatted/wiped > hard disk.?? Probably a "1701" error. This one's a Xebec, almost identical to one of the branded variants that IBM used, actually. It's got the four jumpers lower-right for selecting different drive types, but it also has jumpers for ROM and I/O address selection, which I don't think I recall seeing before on the boards that IBM used. One of the ROMs is labeled as "104833A", which isn't too inconsistent with what I've seen on IBM ones (they generally seem to have a 10483xx format). The other ROM has a Mitsubishi Electric sticker though, labeled as "FXD J12" and "213". One of the functions is presumably to hold custom drive parameters, selected via the four board jumpers, but I don't know what other stuff might typically be in that ROM - I didn't want to automatically rule out it being the source of the "command error" (where other responses might be issued for the same underlying error by other firmware) The hard drive in the system is a Miniscribe M3425; at power-on it spins up, runs the heads in and back out, then blinks its LED once - which I believe is normal, "all is well" behavior, and if there were a significant fault with the spindle speed or positioning then it would start blinking out an error code. > And, even if it were somehow "compatible" with a completely different hard > disk controller, "COMMAND ERROR" doesn't sound like anybody's error message > for a wiped drive.? More likely to be a generic "READ ERROR" I agree "read error" would seem more sensible, but this thing's quirky enough that I wouldn't rule anything out right now. I didn't actually try starting the system with the hard disk controller in place but the drive not attached - maybe I'll do that just to see if there's any change in behavior. Jules From mjkerpan at kerpan.com Mon Sep 7 14:29:51 2020 From: mjkerpan at kerpan.com (Michael Kerpan) Date: Mon, 7 Sep 2020 15:29:51 -0400 Subject: CMU Andrew system (and wm) preservation In-Reply-To: <99A5414B-6E5B-46E7-8C5D-E0E711F6F597@eschatologist.net> References: <20200907020157.2851DBEEAB8@cel2.x> <99A5414B-6E5B-46E7-8C5D-E0E711F6F597@eschatologist.net> Message-ID: Has anybody even been able to get the X-based version to build? I remember finding it on some Unix/Linux source code CD-ROM like 20 years ago, thinking it sounded useful and cool, and trying to build it on whatever Linux I was using on my hand-me-down 486 back in 1999/2000. Even back then, it didn't build for me. Mike On Mon, Sep 7, 2020, 2:44 PM Chris Hanson via cctalk wrote: > On Sep 7, 2020, at 6:24 AM, dstalk at execulink.com wrote: > > > > The description I have for AUIS (6.3.1) is: > > > > "AUIS (Andrew User Interface System) - compound document > > environment offering a word processor, mail/bulletin board > > reader/writer, drawing editor, spreadsheet, font editor, > > application builder, and many other facilities" > > > > Again, an application, not a windowing system per se. > > Yes, the Andrew environment implemented proper layering, so ATK was made > to work atop X and the applications (messages, ez, console, typescript, > etc.) came along. > > At Carnegie Mellon in the early 1990s, you could (with only a little work, > to use a console rather than graphical login) use either X or wm on some of > the campus workstations. On a DECstation 3100 running Ultrix, if you > weren?t going to run any X applications wm was *much* more responsive. I > wasn?t around when the clusters had Sun-3 or IBM RT hardware but I can > imagine the differences there were even more pronounced. (With wm, a > DECstation felt as much faster than a Mac II as it actually was?) > > Applications built against ATK could run atop either wm or X; I don?t know > if there were distinct builds of ATK or if the conditional logic was in the > framework itself, but the applications themselves worked just fine with > either since Andrew implemented a shared library mechanism. (Yes, even on > Ultrix.) > > The publicly-released Andrew distributions don?t include the wm code, only > the X version. I don?t know if they?ll actually build against the wm > headers and libraries if they?re present, or if by the time CMU was > releasing them publicly they had stripped that code out entirely. > > ? Chris > > > From cisin at xenosoft.com Mon Sep 7 15:30:03 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 7 Sep 2020 13:30:03 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: <120584b5-b794-0075-4819-568ab0b21b42@gmail.com> References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <120584b5-b794-0075-4819-568ab0b21b42@gmail.com> Message-ID: >> "DOS based utility program to poke at the contents and/or snarf the int a >> file on disk"? >> DEBUG.COM > On Mon, 7 Sep 2020, Jules Richardson via cctalk wrote: > Funny, I've only ever used it for quick bits of assembly (just a couple of > days ago, in fact), and to do things such as kicking off the formatter > embedded in the ROM on some controllers. It didn't even occur to me that it > probably has some dumping/loading abilities too! I'll dig some docs out... 1) If the drive is larger than 32MB, then boot with DOs 3.31 or newer. Although even with the older ones, you can still do quite a bit. 3.31 is the first where DOS supports a partition larger than 32MB MS-DOS 5.00 is first where debug commands have a "/?" option to get a short reminder of usage. If running DEBUG gives you an "INCORRECT DOS VERSION" error, then find the right one, OR (DOS 5.00 or above), figure out what DOS version that copy of DEBUG is demanding, and use SETVER. L 100 2 0 1 will load into DS:100, the contents of drive 2 (C:), first sector, 1 sector (which happens to be the Master Boot Record and Partition Table) D ; will display it. D [address] ; will let you look at other areas in the segment. R ; see register contents N [filename] ; select filename R CX 200 ; set CX to 512; make sure BX is 0 W ; write BX:CX bytes from DS:100 to the file To write 8K from c800:0 to file "TMPCX.DAT": R DS C7EO ; compensate for offset 100 R CX 2000 ;8K N A:TMPCX.DAT W The offset :100 is a carryover from the PSP and TPA of CP/M. Q ; the absolutely most important DEBUG command to know Finding the errors in the above from my aging unrefreshed dynamic wetware is left as an exercise for the reader. There are MANY people on this list that have plentiful experience and better memories. From dstalk at execulink.com Mon Sep 7 16:04:08 2020 From: dstalk at execulink.com (Don Stalkowski) Date: Mon, 7 Sep 2020 17:04:08 -0400 (EDT) Subject: CMU Andrew system (and wm) preservation In-Reply-To: Message-ID: <20200907210408.117B3BEEAC8@cel2.x> On Mon Sep 7 15:29:51 2020 cctalk at classiccmp.org (Michael Kerpan via cctalk) wrote: > > Has anybody even been able to get the X-based version to build? I remember > finding it on some Unix/Linux source code CD-ROM like 20 years ago, > thinking it sounded useful and cool, and trying to build it on whatever > Linux I was using on my hand-me-down 486 back in 1999/2000. Even back then, > it didn't build for me. > > Mike > The version that came with Yggdrasil Linux back in 1993 included binaries ans source. That distro had 0.99.13 kernel, gcc-2.4.5, and XFree86-1.2. So, it did build at one time. don From healyzh at avanthar.com Mon Sep 7 16:26:32 2020 From: healyzh at avanthar.com (Zane Healy) Date: Mon, 7 Sep 2020 14:26:32 -0700 Subject: CMU Andrew system (and wm) preservation In-Reply-To: <20200907210408.117B3BEEAC8@cel2.x> References: <20200907210408.117B3BEEAC8@cel2.x> Message-ID: <697EAE24-0E69-4907-8476-1357B8F38B0C@avanthar.com> > On Sep 7, 2020, at 2:04 PM, Don Stalkowski via cctalk wrote: > > On Mon Sep 7 15:29:51 2020 cctalk at classiccmp.org (Michael Kerpan via cctalk) wrote: >> >> Has anybody even been able to get the X-based version to build? I remember >> finding it on some Unix/Linux source code CD-ROM like 20 years ago, >> thinking it sounded useful and cool, and trying to build it on whatever >> Linux I was using on my hand-me-down 486 back in 1999/2000. Even back then, >> it didn't build for me. >> >> Mike >> > > The version that came with Yggdrasil Linux back in 1993 included > binaries ans source. That distro had 0.99.13 kernel, gcc-2.4.5, and > XFree86-1.2. So, it did build at one time. I want to say that it was included with SLS as well in ?92/93. Really the main thing I remember about CMU Andrew was AFS. I had to work with that from late ?96, until I think 2005. Zane From mjkerpan at kerpan.com Mon Sep 7 17:25:31 2020 From: mjkerpan at kerpan.com (Michael Kerpan) Date: Mon, 7 Sep 2020 18:25:31 -0400 Subject: CMU Andrew system (and wm) preservation In-Reply-To: <697EAE24-0E69-4907-8476-1357B8F38B0C@avanthar.com> References: <20200907210408.117B3BEEAC8@cel2.x> <697EAE24-0E69-4907-8476-1357B8F38B0C@avanthar.com> Message-ID: AFS is also cool, but it's a separate project that's still actively maintained and (presumably) used. The Andrew UI stuff is more firmly in the realm of computer history. Honestly, I'm surprised that it didn't get more traction early on Linux, given that it was included in some of the more influential early distros and it included a more complete set of apps than anything else that you could get for free at the time. That said, it's also a shame that IBM wouldn't allow the native window manager to be released like the rest of the system. It probably would have been a better fit for PC hardware of the early to mid 90s than X11... Mike On Mon, Sep 7, 2020, 5:26 PM Zane Healy wrote: > > > > On Sep 7, 2020, at 2:04 PM, Don Stalkowski via cctalk < > cctalk at classiccmp.org> wrote: > > > > On Mon Sep 7 15:29:51 2020 cctalk at classiccmp.org (Michael Kerpan via > cctalk) wrote: > >> > >> Has anybody even been able to get the X-based version to build? I > remember > >> finding it on some Unix/Linux source code CD-ROM like 20 years ago, > >> thinking it sounded useful and cool, and trying to build it on whatever > >> Linux I was using on my hand-me-down 486 back in 1999/2000. Even back > then, > >> it didn't build for me. > >> > >> Mike > >> > > > > The version that came with Yggdrasil Linux back in 1993 included > > binaries ans source. That distro had 0.99.13 kernel, gcc-2.4.5, and > > XFree86-1.2. So, it did build at one time. > > I want to say that it was included with SLS as well in ?92/93. Really the > main thing I remember about CMU Andrew was AFS. I had to work with that > from late ?96, until I think 2005. > > Zane > > > From jules.richardson99 at gmail.com Mon Sep 7 17:34:18 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 7 Sep 2020 17:34:18 -0500 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> Message-ID: On 9/7/20 2:22 PM, Jules Richardson via cctalk wrote: >> And, even if it were somehow "compatible" with a completely different >> hard disk controller, "COMMAND ERROR" doesn't sound like anybody's error >> message for a wiped drive.? More likely to be a generic "READ ERROR" > > I agree "read error" would seem more sensible, but this thing's quirky > enough that I wouldn't rule anything out right now. Progress! I started looking everything over again, picking stuff apart, reassembling etc. - eventually happening to notice quite by chance how rough the very end of the hard disk control cable felt as I pushed the connector back onto the drive. Out with the loupe, and sure enough - the cable cut wasn't particularly clean across the entire width, and there was a single strand of wire just long enough to bridge across two of the conductors. Now I'm getting "system file not found or disk read error", which although disappointing is at least far more sane. I'll have to rustle up a floppy boot disk and see if I can get any access that way. I have no idea of this machine's history - I don't even know where I got it. Maybe those are factory cables, maybe not. Maybe previous owners goofed around with the system over the years, maybe the drive itself is non-original even (and contains nothing relevant to the video board, even if it was bootable). After doing an initial PSU test the other day, I did strip it down to bare minimum - just system board and video - so it's possible the drive cable wasn't shorted prior to my disturbing things. cheers Jules From cisin at xenosoft.com Mon Sep 7 18:18:16 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Mon, 7 Sep 2020 16:18:16 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> Message-ID: On Mon, 7 Sep 2020, Jules Richardson via cctalk wrote: > Progress! I started looking everything over again, picking stuff apart, > reassembling etc. - eventually happening to notice quite by chance how rough > the very end of the hard disk control cable felt as I pushed the connector > back onto the drive. Out with the loupe, and sure enough - the cable cut > wasn't particularly clean across the entire width, and there was a single > strand of wire just long enough to bridge across two of the conductors. > > Now I'm getting "system file not found or disk read error", which although > disappointing is at least far more sane. I'll have to rustle up a floppy boot > disk and see if I can get any access that way. > > I have no idea of this machine's history - I don't even know where I got it. > Maybe those are factory cables, maybe not. Maybe previous owners goofed > around with the system over the years, maybe the drive itself is non-original > even (and contains nothing relevant to the video board, even if it was > bootable). After doing an initial PSU test the other day, I did strip it down > to bare minimum - just system board and video - so it's possible the drive > cable wasn't shorted prior to my disturbing things. Yep! Floppy boot seems like the next step. Got an IBM "Advanced Diagnostics" floppy to try? Just to add to the confusion and misery, . . . If the controller is bad, . . . XT controllers tended to NOT be interchangeable, even between various OEMs of Xebec! Some HDDs would not work when connected to a different controller. You would expect that a drive LLF with one controller would work with another, or at least another one from same OEM, without redoing the LLF. I don't know what the incompatability was. Possibly different sector numbering? That MIGHT be solvable by swapping the ROM? That was mostly fixed by the time of the 5170/AT WD controllers. From lars at nocrew.org Tue Sep 8 01:09:48 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 08 Sep 2020 06:09:48 +0000 Subject: CMU Andrew system (and wm) preservation In-Reply-To: (Michael Kerpan via cctalk's message of "Mon, 7 Sep 2020 18:25:31 -0400") References: <20200907210408.117B3BEEAC8@cel2.x> <697EAE24-0E69-4907-8476-1357B8F38B0C@avanthar.com> Message-ID: <7wk0x4g5oz.fsf@junk.nocrew.org> Michael Kerpan wrote: > AFS is also cool, but it's a separate project that's still actively > maintained and (presumably) used. MIT uses it, as does the student organization Stacken. From cctalk at gtaylor.tnetconsulting.net Tue Sep 8 01:18:23 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 8 Sep 2020 00:18:23 -0600 Subject: NetWare 5.1 / BorderManager 3.5 Message-ID: Does anyone have any idea where I can get install media at various support pack levels and / or support pack install files for NetWare 5.1 and / or BorderManager 3.5? I'm playing with some old things in VMs and can't get BorderManager 3.5 (sp0?) to work on 5.1sp7 / 5.1sp8. I need older 5.1spX or newer BorderManager. BorderManager patches would be bm35sp2.exe or bm35sp3.exe. -- Grant. . . . unix || die From trash80 at internode.on.net Tue Sep 8 01:39:33 2020 From: trash80 at internode.on.net (Kevin Parker) Date: Tue, 8 Sep 2020 16:39:33 +1000 Subject: Looking for suggestions for this Message-ID: <307f01d685aa$d035a740$70a0f5c0$@internode.on.net> Hi folks - quite some time ago I picked up this little beauty (well I'm sure some may agree or disagree with me) off of ePAY. I happen to like black IBMs of any type. Of course I got gouged at the checkout paying the princely sum of $1.04 AUD - some might say I got robbed. In the photo with the other machines it's the big one. Included was the machine of course, the tape drive, the monitor (the keyboard is somewhere) and a heap of connectors and cables - and I did get the key with it too. What was missing were the HDDs (which they trashed to get rid of the data) and all the documentation (which they tossed before they realised that they could flog it on ePAY and get someone else to take it away). http://koken.advancedimaging.com.au/index.php?/albums/as400/ But as I rationalise space in my increasingly small collection facility I need to make some decisions about things so I'm looking for some suggestions as to what I can do with this machine. At the risk of being applauded for some ideas and being flamed for others some suggestions are: 1. Do nothing - it's a very interesting conversation piece and its worth preserving. 2. Someone is looking for one of these for parts and will pay me a fortune. 3. Dump it. 4. Donate it to a museum - they'll need a truck and four big guys. 5. Trade it for scrap value. 6. Get it running - now there's a big leap I suspect!! I did manage to procure some HDDs from another AS/400 but as to whether they are suitable or this would even work is not even remotely my bailiwick. 7. Gut it and build a cluster inside it so at least it looks and runs like a big computer so I can get some WOW factor from those who don't know any different. 8. Gut it and turn it into a bar fridge. 9. Anything else... Thank you Kevin Parker From mazzinia at tin.it Tue Sep 8 03:25:25 2020 From: mazzinia at tin.it (mazzinia at tin.it) Date: Tue, 8 Sep 2020 10:25:25 +0200 Subject: Looking for suggestions for this In-Reply-To: <307f01d685aa$d035a740$70a0f5c0$@internode.on.net> References: <307f01d685aa$d035a740$70a0f5c0$@internode.on.net> Message-ID: <00d101d685b9$9ae018f0$d0a04ad0$@tin.it> Hello, Were the license documents included in the auction ? otherwise you can only install it with a temporary license and reinstall every , I think, 6 months. If the hdds you got are from an as/400, it should work ( remember to never format them in a normal pc, if you change the factory sector setting, you will turn them into normal disks ) -----Original Message----- From: cctalk On Behalf Of Kevin Parker via cctalk Sent: Tuesday, September 8, 2020 8:40 AM To: 'General Discussion: On-Topic and Off-Topic Posts' Subject: Looking for suggestions for this Hi folks - quite some time ago I picked up this little beauty (well I'm sure some may agree or disagree with me) off of ePAY. I happen to like black IBMs of any type. Of course I got gouged at the checkout paying the princely sum of $1.04 AUD - some might say I got robbed. In the photo with the other machines it's the big one. Included was the machine of course, the tape drive, the monitor (the keyboard is somewhere) and a heap of connectors and cables - and I did get the key with it too. What was missing were the HDDs (which they trashed to get rid of the data) and all the documentation (which they tossed before they realised that they could flog it on ePAY and get someone else to take it away). http://koken.advancedimaging.com.au/index.php?/albums/as400/ But as I rationalise space in my increasingly small collection facility I need to make some decisions about things so I'm looking for some suggestions as to what I can do with this machine. At the risk of being applauded for some ideas and being flamed for others some suggestions are: 1. Do nothing - it's a very interesting conversation piece and its worth preserving. 2. Someone is looking for one of these for parts and will pay me a fortune. 3. Dump it. 4. Donate it to a museum - they'll need a truck and four big guys. 5. Trade it for scrap value. 6. Get it running - now there's a big leap I suspect!! I did manage to procure some HDDs from another AS/400 but as to whether they are suitable or this would even work is not even remotely my bailiwick. 7. Gut it and build a cluster inside it so at least it looks and runs like a big computer so I can get some WOW factor from those who don't know any different. 8. Gut it and turn it into a bar fridge. 9. Anything else... Thank you Kevin Parker From stefan.skoglund at agj.net Tue Sep 8 05:24:32 2020 From: stefan.skoglund at agj.net (Stefan Skoglund) Date: Tue, 08 Sep 2020 12:24:32 +0200 Subject: CMU Andrew system (and wm) preservation In-Reply-To: References: <20200907020157.2851DBEEAB8@cel2.x> <99A5414B-6E5B-46E7-8C5D-E0E711F6F597@eschatologist.net> Message-ID: <0b9ddd32c5b95dd9e2edfa8921ec3bad7e4b3724.camel@agj.net> m?n 2020-09-07 klockan 15:29 -0400 skrev Michael Kerpan via cctalk: > Has anybody even been able to get the X-based version to build? I > remember > finding it on some Unix/Linux source code CD-ROM like 20 years ago, > thinking it sounded useful and cool, and trying to build it on > whatever > Linux I was using on my hand-me-down 486 back in 1999/2000. Even back > then, > it didn't build for me. > > Mike I have a memory of someone running it on an ELC (SunOS4.1.3 days.) So: a fully patched SunOS 4.1 system with dev tools and 1991/1992 sources to Andrew ? From stefan.skoglund at agj.net Tue Sep 8 05:25:36 2020 From: stefan.skoglund at agj.net (Stefan Skoglund) Date: Tue, 08 Sep 2020 12:25:36 +0200 Subject: CMU Andrew system (and wm) preservation In-Reply-To: <7wk0x4g5oz.fsf@junk.nocrew.org> References: <20200907210408.117B3BEEAC8@cel2.x> <697EAE24-0E69-4907-8476-1357B8F38B0C@avanthar.com> <7wk0x4g5oz.fsf@junk.nocrew.org> Message-ID: tis 2020-09-08 klockan 06:09 +0000 skrev Lars Brinkhoff via cctalk: > Michael Kerpan wrote: > > AFS is also cool, but it's a separate project that's still actively > > maintained and (presumably) used. > > MIT uses it, as does the student organization Stacken. So does Chalmers, at least two years ago, the student data pool was AFS. From dstalk at execulink.com Tue Sep 8 11:33:07 2020 From: dstalk at execulink.com (Don Stalkowski) Date: Tue, 8 Sep 2020 12:33:07 -0400 (EDT) Subject: ftgh 95 ohm coax Message-ID: <20200908163307.241BDBEEAD4@cel2.x> ftgh: a few lengths of 95 ohm coax pickup-only here in London, ON From jules.richardson99 at gmail.com Tue Sep 8 16:12:09 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Tue, 8 Sep 2020 16:12:09 -0500 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> Message-ID: <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> On 9/7/20 6:18 PM, Fred Cisin via cctalk wrote: > Floppy boot seems like the next step. OK, it boots off a DOS 3.3 floppy if that floppy is inserted before it attempts to boot from the hard disk. If I wait for it to do its "system file not found" bit, followed by a subsequent prompt to insert boot media and press a key, it attempts to access the floppy drive but then goes off into la-la land. Odd. But anyway, taking the successful floppy boot route, I can certainly access the hard disk in terms of bringing up directory listings and TYPEing files to the display. So far, attempts to run anything from the drive just result in a lock-up (keyboard immediately unresponsive, hard reset required). There appear to be DOS utils on the drive, and command.com, but I've not checked for hidden system files yet. fdisk shows the partition as active. > Got an IBM "Advanced Diagnostics" floppy to try? No, but I see that the minuszerodegrees site has an image, so I'll write that out and see what happens. Looking at the drive contents, incidentally, I didn't see anything that explains (or interacts with) that unusual video hardware - it basically just holds DOS and a bunch of documents written by the original owner. Maybe they got suckered into buying this fancy graphics hardware without having any actual need for it, and then of course EGA and VGA came along and rendered it obsolete anyway. > XT controllers tended to NOT be interchangeable, even between various OEMs > of Xebec! Yes - something that people often seem to forget, too. I've run into that quite often, where someone will hang onto an old drive because of the contents, but they'll dump the controller that it was formatted against. > I don't know what the incompatability was. I don't think there was any kind of standard at all for what the low level looked like - vendors were free to do what they wanted in terms of what values they used for flags and how they actually ordered things within the sector header. I suppose there were some tweaks made over time for optimization or reliability (or at least, recovery) reasons, too, which is why even a single vendor had a few different incompatible formats. I expect it was the same in the SCSI and IDE worlds, but of course with those "the controller" which handles formatting is really part of the package, so it wasn't an issue. Jules From matt at 9track.net Tue Sep 8 17:11:01 2020 From: matt at 9track.net (Matt Burke) Date: Tue, 8 Sep 2020 23:11:01 +0100 Subject: ISO: DEC VR100 and early X releases In-Reply-To: References: Message-ID: <91d46a24-04df-20c7-d154-d17064116c6f@9track.net> On 05/09/2020 20:19, Josh Dersch via cctalk wrote: > While I'm at it -- anyone know > precisely what I need to use this under VMS? I believe 4.7 was the last > VMS release that supported it, but there were additional packages that > needed to be installed to support it, and I'm not entirely sure what they > are. To use the VAXstation 100 with VMS you need to install the "VAXstation Software" layered product. I have not come across any original copies however DEC later contributed the source code to the DECUS library under submission V00376. The submission consists of a CMS library and some other source files. The only place you can reliably get this from is DECUServe as you need to get the files whilst preserving their RMS attributes. Then you need to compile the code and create an installation kit to use the software. The good news is that I've already done all of this so here is a link to the source and installation kit on Simh tap files: http://www.9track.net/bits/dec/vs100/v00376.zip http://www.9track.net/bits/dec/vs100/vsta012.zip This was built on VAX/VMS V4.4 with: Bliss-32 V4.3 FORTRAN V4.7 Pascal V3.7 CMS V2.3 MMS V2.2 I also have a VAXstation 100 that I hope to get working some day but I need the M7452 card and a VS10X-EA mouse. I did win an M7452 on eBay about 10 years ago but the seller then said that he had already sold it. I've not seen another one since (well not one for an affordable price. I did find a reseller that wanted $1000 for one). Matt From lproven at gmail.com Tue Sep 8 17:42:19 2020 From: lproven at gmail.com (Liam Proven) Date: Wed, 9 Sep 2020 00:42:19 +0200 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 at 08:18, Grant Taylor via cctalk wrote: > > Does anyone have any idea where I can get install media at various > support pack levels and / or support pack install files for NetWare 5.1 > and / or BorderManager 3.5? Something like this any help? https://winworldpc.com/product/netware/5x I have physical media of this somewhere: https://archive.org/details/Netware_5_Operating_System_3_User_Demo_Novell -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From lproven at gmail.com Tue Sep 8 17:46:18 2020 From: lproven at gmail.com (Liam Proven) Date: Wed, 9 Sep 2020 00:46:18 +0200 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <120584b5-b794-0075-4819-568ab0b21b42@gmail.com> Message-ID: On Tue, 8 Sep 2020 at 06:47, Fred Cisin via cctalk wrote: > > 1) If the drive is larger than 32MB, then boot with DOs 3.31 or newer. > Although even with the older ones, you can still do quite a bit. 3.31 is > the first where DOS supports a partition larger than 32MB > MS-DOS 5.00 is first where debug commands have a "/?" option to get a > short reminder of usage. Agreed. (Like I'd dare to differ with Fred.) My 2?'s worth is just: for an XT, if you want to fit a CF card or something, try DR-DOS 3.41. It's out there in various places. RAM usage as small as MS-DOS 3.3 but offers most of the benefits of MS-DOS 4 and some of MS-DOS 5 (both of which take a *lot* more RAM on an XT-class machine.) -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From sales at elecplus.com Tue Sep 8 17:48:37 2020 From: sales at elecplus.com (Electronics Plus) Date: Tue, 8 Sep 2020 17:48:37 -0500 Subject: ISO: DEC VR100 and early X releases In-Reply-To: <91d46a24-04df-20c7-d154-d17064116c6f@9track.net> References: <91d46a24-04df-20c7-d154-d17064116c6f@9track.net> Message-ID: <007501d68632$30c06410$92412c30$@com> There is a DEC dealer in the UK that has M7452 cards listed as in-stock. Contact Spencer Dye at sales at swancomp.co.uk. Old mouse I have located, but he has to check if it is actually in stock, and if it works. Cindy -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Matt Burke via cctalk Sent: Tuesday, September 08, 2020 5:11 PM To: Josh Dersch via cctalk Subject: Re: ISO: DEC VR100 and early X releases On 05/09/2020 20:19, Josh Dersch via cctalk wrote: > While I'm at it -- anyone know > precisely what I need to use this under VMS? I believe 4.7 was the last > VMS release that supported it, but there were additional packages that > needed to be installed to support it, and I'm not entirely sure what they > are. To use the VAXstation 100 with VMS you need to install the "VAXstation Software" layered product. I have not come across any original copies however DEC later contributed the source code to the DECUS library under submission V00376. The submission consists of a CMS library and some other source files. The only place you can reliably get this from is DECUServe as you need to get the files whilst preserving their RMS attributes. Then you need to compile the code and create an installation kit to use the software. The good news is that I've already done all of this so here is a link to the source and installation kit on Simh tap files: http://www.9track.net/bits/dec/vs100/v00376.zip http://www.9track.net/bits/dec/vs100/vsta012.zip This was built on VAX/VMS V4.4 with: Bliss-32 V4.3 FORTRAN V4.7 Pascal V3.7 CMS V2.3 MMS V2.2 I also have a VAXstation 100 that I hope to get working some day but I need the M7452 card and a VS10X-EA mouse. I did win an M7452 on eBay about 10 years ago but the seller then said that he had already sold it. I've not seen another one since (well not one for an affordable price. I did find a reseller that wanted $1000 for one). Matt From cisin at xenosoft.com Tue Sep 8 18:04:44 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 8 Sep 2020 16:04:44 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> Message-ID: On Tue, 8 Sep 2020, Jules Richardson via cctalk wrote: > OK, it boots off a DOS 3.3 floppy if that floppy is inserted before it > attempts to boot from the hard disk. If I wait for it to do its "system file > not found" bit, followed by a subsequent prompt to insert boot media and > press a key, it attempts to access the floppy drive but then goes off into > la-la land. Odd. How large is the drive? If it is over 32MB, then try to find DOS 3.31 or newer. MY preference is MS-DOS 6.22 > But anyway, taking the successful floppy boot route, I can certainly access > the hard disk in terms of bringing up directory listings and TYPEing files to > the display. So far, attempts to run anything from the drive just result in a > lock-up (keyboard immediately unresponsive, hard reset required). There > appear to be DOS utils on the drive, and command.com, but I've not checked > for hidden system files yet. fdisk shows the partition as active. Date and time of Command.com and any other DOS files will identify the version number. DIR /A or DIR /A:H will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS had IBMBIO.COM and IBMDOS.COM instead) Can you COPY files from the HDD to floppy? Being able to access contents of files, but not RUN them seems odd. IF the DOS on the floppy misunderstands the partition table, then root directory might look OK, but sub-directories might not be where it thinks they are, . . . >> Got an IBM "Advanced Diagnostics" floppy to try? > No, but I see that the minuszerodegrees site has an image, so I'll write that > out and see what happens. NOT a big deal. It's merely the only method directly from IBM for doing low level format. In most cases, Speedstor is more useful for LLF. > Looking at the drive contents, incidentally, I didn't see anything that > explains (or interacts with) that unusual video hardware - it basically just > holds DOS and a bunch of documents written by the original owner. Maybe they > got suckered into buying this fancy graphics hardware without having any > actual need for it, and then of course EGA and VGA came along and rendered it > obsolete anyway. It is probably completely CGA compatible, unless you invoke of of its other modes. The ROM on the video card may be a BIOS extension, in which case access to extended modes may be handled internally in various programs. For instance Windows 3.x, PC PAint, Pagemaker, and Xerox Ventura let you configure for a variety of video hardware. Otherwise, check to see if CONFIG.SYS has DEVICE commands to load any device drivers, usually .SYS, although sometimes .COM >> XT controllers tended to NOT be interchangeable, even between various OEMs >> of Xebec! > Yes - something that people often seem to forget, too. I've run into that > quite often, where someone will hang onto an old drive because of the > contents, but they'll dump the controller that it was formatted against. It always seemed counter-intuitive that makers of HDD hardware for XT didn't slavishly mimic IBM's XT HDD. And especially counter-intuitive that different vendor Xebec controllers didn't always interchange. -- Grumpy Ol' Fred cisin at xenosoft.com From doug at doughq.com Tue Sep 8 18:16:42 2020 From: doug at doughq.com (Doug Jackson) Date: Wed, 9 Sep 2020 09:16:42 +1000 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> Message-ID: I recall some of the high end cards in the CGA / EGA era had adon boards that were connected with a 20 or 36 pin jumper cable across the top of the boards - They also ran more than 64K or ram, such as the ATI Wonder boards. Maybe it's like that - the ATI boards had 256K so they could page. Kindest regards, Doug Jackson em: doug at doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net ----------------------------------------------------------- Just like an old fashioned letter, this email and any files transmitted with it should probably be treated as confidential and intended solely for your own use. Please note that any interesting spelling is usually my own and may have been caused by fat thumbs on a tiny tiny keyboard. Should any part of this message prove to be useful in the event of the imminent Zombie Apocalypse then the sender bears no personal, legal, or moral responsibility for any outcome resulting from its usage unless the result of said usage is the unlikely defeat of the Zombie Hordes in which case the sender takes full credit without any theoretical or actual legal liability. :-) Be nice to your parents. Go outside and do something awesome - Draw, paint, walk, setup a radio station, go fishing or sailing - just do something that makes you happy. ^G ^G ^G ^G ^G ^G ^G ^G- In more laid back days this line would literally sing ^G ^G ^G ^G ^G ^G ^G ^G On Wed, Sep 9, 2020 at 9:04 AM Fred Cisin via cctalk wrote: > On Tue, 8 Sep 2020, Jules Richardson via cctalk wrote: > > OK, it boots off a DOS 3.3 floppy if that floppy is inserted before it > > attempts to boot from the hard disk. If I wait for it to do its "system > file > > not found" bit, followed by a subsequent prompt to insert boot media and > > press a key, it attempts to access the floppy drive but then goes off > into > > la-la land. Odd. > > How large is the drive? > If it is over 32MB, then try to find DOS 3.31 or newer. > MY preference is MS-DOS 6.22 > > > > But anyway, taking the successful floppy boot route, I can certainly > access > > the hard disk in terms of bringing up directory listings and TYPEing > files to > > the display. So far, attempts to run anything from the drive just result > in a > > lock-up (keyboard immediately unresponsive, hard reset required). There > > appear to be DOS utils on the drive, and command.com, but I've not > checked > > for hidden system files yet. fdisk shows the partition as active. > > Date and time of Command.com and any other DOS files will identify the > version number. > > DIR /A or > DIR /A:H > will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS > had IBMBIO.COM and IBMDOS.COM instead) > > Can you COPY files from the HDD to floppy? > > Being able to access contents of files, but not RUN them seems odd. > IF the DOS on the floppy misunderstands the partition table, then root > directory might look OK, but sub-directories might not be where it thinks > they are, . . . > > > >> Got an IBM "Advanced Diagnostics" floppy to try? > > No, but I see that the minuszerodegrees site has an image, so I'll write > that > > out and see what happens. > > NOT a big deal. It's merely the only method directly from IBM for doing > low level format. > In most cases, Speedstor is more useful for LLF. > > > Looking at the drive contents, incidentally, I didn't see anything that > > explains (or interacts with) that unusual video hardware - it basically > just > > holds DOS and a bunch of documents written by the original owner. Maybe > they > > got suckered into buying this fancy graphics hardware without having any > > actual need for it, and then of course EGA and VGA came along and > rendered it > > obsolete anyway. > > It is probably completely CGA compatible, unless you invoke of of its > other modes. > > The ROM on the video card may be a BIOS extension, in which case access to > extended modes may be handled internally in various programs. For > instance Windows 3.x, PC PAint, Pagemaker, and Xerox Ventura let you > configure for a variety of video hardware. > Otherwise, check to see if CONFIG.SYS has DEVICE commands to load any > device drivers, usually .SYS, although sometimes .COM > > >> XT controllers tended to NOT be interchangeable, even between various > OEMs > >> of Xebec! > > Yes - something that people often seem to forget, too. I've run into > that > > quite often, where someone will hang onto an old drive because of the > > contents, but they'll dump the controller that it was formatted against. > > It always seemed counter-intuitive that makers of HDD hardware for XT > didn't slavishly mimic IBM's XT HDD. And especially counter-intuitive > that different vendor Xebec controllers didn't always interchange. > > > -- > Grumpy Ol' Fred cisin at xenosoft.com > From cisin at xenosoft.com Tue Sep 8 18:28:39 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Tue, 8 Sep 2020 16:28:39 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> Message-ID: On Wed, 9 Sep 2020, Doug Jackson wrote: > I recall some of the high end cards in the CGA / EGA era had adon boards > that were connected with a 20 or 36 pin jumper cable across the top of the > boards - They also ran more than 64K or ram, such as the ATI Wonder > boards. Maybe it's like that - the ATI boards had 256K so they could page. I had a CGA "double board" that did 640x400 or 640x200 by more colors. It was not the same as this one, but might have been internally similar. But I don't remember ATI premium CGA. ATI had some interesting EGA boards, including one that had an add-on that included the mid-board connector for Compaq luggable internal video! Otherwise, you were stuck with Compaq CGA or Compaq EGA. From cctalk at gtaylor.tnetconsulting.net Tue Sep 8 20:18:04 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 8 Sep 2020 19:18:04 -0600 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: References: Message-ID: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> On 9/8/20 4:42 PM, Liam Proven via cctalk wrote: > Something like this any help? > > https://winworldpc.com/product/netware/5x I'm very familiar with WinWorld and VetusWare. I quite like them. They are on the short list to find things like this. There is high overlap between a number of these places. That being said, I haven't tested that specific ISO. But that's mostly because I've long had a version of NetWare 5.1. Now that I'm looking for specific things, particularly patches, I decided to send a broadcast message. > I have physical media of this somewhere: > > https://archive.org/details/Netware_5_Operating_System_3_User_Demo_Novell I've been focusing on 5.1 and I've not yet broadened my net to include 5(.0). I was sort of hoping that someone might have had the support pack files tucked away somewhere. I'm currently working on re-organizing my 48 GB of Novell software. Partially to normalize the names and location, as well as to be able to tell what I do and do not have. Thank you for the reply Liam. You re-enforced the fact that I need to get a better understanding of what /specific/ versions I have and the things I know about are. -- Grant. . . . unix || die From jwsmail at jwsss.com Tue Sep 8 22:25:19 2020 From: jwsmail at jwsss.com (jim stephens) Date: Tue, 8 Sep 2020 20:25:19 -0700 Subject: ISO: DEC VR100 and early X releases In-Reply-To: <007501d68632$30c06410$92412c30$@com> References: <91d46a24-04df-20c7-d154-d17064116c6f@9track.net> <007501d68632$30c06410$92412c30$@com> Message-ID: <7487c5f1-bfe6-0d6d-8b37-ee0668c2540c@jwsss.com> On 9/8/2020 3:48 PM, Electronics Plus via cctalk wrote: > Old mouse I have located, but he has to check if it is actually in stock, and if it works. They aren't the "normal" DEC hockey puck mice.? it's sort of like a PS2 mouse with I think an odd ball.? I had hands on Josh's and one for Paul Birkel (for too long, but they have them now), and the mouse was odd. I don't know how Josh is doing, since is is working, but the cabling on the mouse cord had degraded and had goo on it like the black crap you get form the wrong type of rubber when it turns tar like. Glad Josh got his going, pulling for Paul to get his running.? And interesting they may be a third one. So cool Cameron Kaiser collected two and passed them along. thanks Jim From cctalk at gtaylor.tnetconsulting.net Tue Sep 8 23:33:47 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Tue, 8 Sep 2020 22:33:47 -0600 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> References: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> Message-ID: <1668c3d3-f0c9-c574-e30f-e879893223a0@spamtrap.tnetconsulting.net> On 9/8/20 7:18 PM, Grant Taylor via cctalk wrote: > I haven't tested that specific ISO. The particular ISO that you linked to is Novell NetWare 5.1 (Support Pack 0). So it needs support packs installed on it. I've learned that there are different Support Packs, "Domestic" and "International" having to do with the 128-bit vs 56-bit encryption woes of the '90s. -- Grant. . . . unix || die From lproven at gmail.com Wed Sep 9 06:08:43 2020 From: lproven at gmail.com (Liam Proven) Date: Wed, 9 Sep 2020 13:08:43 +0200 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: <1668c3d3-f0c9-c574-e30f-e879893223a0@spamtrap.tnetconsulting.net> References: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> <1668c3d3-f0c9-c574-e30f-e879893223a0@spamtrap.tnetconsulting.net> Message-ID: On Wed, 9 Sep 2020 at 06:34, Grant Taylor via cctalk wrote: > > On 9/8/20 7:18 PM, Grant Taylor via cctalk wrote: > > I haven't tested that specific ISO. > > The particular ISO that you linked to is Novell NetWare 5.1 (Support > Pack 0). So it needs support packs installed on it. But that's good, isn't it? I confess I may have misread your original message as being "I need NW5.1 with no SPs." Was that wrong? But if you have SP0, no bugfixes, then surely you can just install the SPs on top of it to get to whatever level you want? My $DAYJOB was part of Novell until about a year ago. I _may_ be able to find internal download links still but I am not confident. Want me to start asking around? I may need some fairly specific info as there are few Netware folk left now. E.g. how many separate SPs did NW5.1 get? Do you need both US and ROW versions? > I've learned that there are different Support Packs, "Domestic" and > "International" having to do with the 128-bit vs 56-bit encryption woes > of the '90s. Oh dear... TBH I have a suspicion nobody may have kept stuff like that, even inside Novell... :( -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From jules.richardson99 at gmail.com Wed Sep 9 11:56:31 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Wed, 9 Sep 2020 11:56:31 -0500 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> Message-ID: On 9/8/20 6:04 PM, Fred Cisin via cctalk wrote: > Date and time of Command.com and any other DOS files will identify the > version number. I've got 11/26/85 on command.com. > DIR /A? or > DIR /A:H > will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS > had IBMBIO.COM and IBMDOS.COM instead) The /a switch isn't part of the dir command in whatever 3.3 version I have. However, I just wrote a DOS 6.22 boot disk and that shows three hidden files on the hard disk: MSDOS.SYS (11/18/85) MIO.SYS (11/18/85) SD.INI I'm guessing that the 'M' in MIO.SYS is "Mitsubishi" and the OS is tailored in some way to the machine. TYPEing "sd.ini" indicates that it's related to Norton Speed Disk - not a program I'm familiar with, but as that appears to be a defragmenter, it might hint at why my drive isn't bootable and seems to be having problems with various executables - I wonder if the directory structure "looks sane", but file contents have been completely mangled. > Can you COPY files from the HDD to floppy? Just filling up a few 360K disks with files at random so far, yes. But difficult to say if the file contents are correct. >> Looking at the drive contents, incidentally, I didn't see anything that >> explains (or interacts with) that unusual video hardware - it basically >> just holds DOS and a bunch of documents written by the original owner. >> Maybe they got suckered into buying this fancy graphics hardware without >> having any actual need for it, and then of course EGA and VGA came along >> and rendered it obsolete anyway. > > It is probably completely CGA compatible, unless you invoke of of its other > modes. Maybe. Assuming that the hard drive's directory contents are intact, and therefore there's nothing too unusual on the drive, I've perhaps got nothing to lose by reformatting - the only issue is that MIO.SYS, how it differs from Microsoft's, whether it's corrupt or not, and how - if it is intact - I can migrate it over post-install. Of course maybe speed disk (if that is even the cause of my problems) has some kind of backup / undo aspect, but I doubt it. From lproven at gmail.com Wed Sep 9 12:19:35 2020 From: lproven at gmail.com (Liam Proven) Date: Wed, 9 Sep 2020 19:19:35 +0200 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> Message-ID: On Wed, 9 Sep 2020 at 18:56, Jules Richardson via cctalk wrote: > > On 9/8/20 6:04 PM, Fred Cisin via cctalk wrote: > > Date and time of Command.com and any other DOS files will identify the > > version number. Only after DOS 5 or so, I fear. > I've got 11/26/85 on command.com. > > > DIR /A or > > DIR /A:H > > will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS > > had IBMBIO.COM and IBMDOS.COM instead) > > The /a switch isn't part of the dir command in whatever 3.3 version I have. Yup. `ATTRIB *.*` might work in 3.3 though. > However, I just wrote a DOS 6.22 boot disk and that shows three hidden > files on the hard disk: > > MSDOS.SYS (11/18/85) > MIO.SYS (11/18/85) > SD.INI > > I'm guessing that the 'M' in MIO.SYS is "Mitsubishi" and the OS is tailored > in some way to the machine. Uhoh. Danger, Will Robinson. > > TYPEing "sd.ini" indicates that it's related to Norton Speed Disk - not a > program I'm familiar with, but as that appears to be a defragmenter, it > might hint at why my drive isn't bootable and seems to be having problems > with various executables - I wonder if the directory structure "looks > sane", but file contents have been completely mangled. Oh dear, yes. If the machine is not totally vanilla but close enough to boot vanilla DOS, then it's possible that SPEEDISK could have run but incorrectly and mangled stuff. Similarly running DOS defraggers on a VFAT disk with LFNs would mangle them, in the Win95 era. TBH, though, I'm surprised -- later versions of DOS (such as 6.22) didn't run on DOS compatible machines, because they'd died out by then. It was IBM compatible or nothing by the DOS 6 era, IIRC. So I'd expect a later-era machine to be compatible enough that Norton etc. would have no problem. I ran things like PKARC and PKZIP successfully on DOS-compatibles in the late '80s, because they only did legal file access and wrote plain text to the screen. I wouldn't expect SPEEDISK to run on an early Apricot or something. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From cctalk at gtaylor.tnetconsulting.net Wed Sep 9 12:41:51 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 9 Sep 2020 11:41:51 -0600 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: References: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> <1668c3d3-f0c9-c574-e30f-e879893223a0@spamtrap.tnetconsulting.net> Message-ID: On 9/9/20 5:08 AM, Liam Proven via cctalk wrote: > But that's good, isn't it? Yes and no. Yes in that it's below the problem point. :-) No in that I don't have the necessary Support Pack's to install. :-( > I confess I may have misread your original message as being "I need > NW5.1 with no SPs." Was that wrong? It might have been an ambiguity on my part. I've learned a little bit since my last message. I seem to have NetWare 5.1 (SP 0) for both "Domestic" (128-bit) and "Exportable" (56-bit). But there is a catch. The exportable version is part of Novell Small Business Suite 5.1, which seems to be a superset of NetWare 5.1. I don't yet know if I can bust it down to be a more standard NetWare 5.1 without all the other unwanted NSBS stuff. I did learn that NSBS 5.1 is the "Exportable" (56-bit) version and that it comes with Exportable NetWare 5.1 Support Pack 1 as an install able option on another disk. Said Exportable NetWare 5.1 Support Pack 1 will install on NSBS 5.1. But given that it's the "Exportable" (56-bit) version, it won't install on standard "Domestic" (128-bit) NetWare 5.1. That being said, I don't really care about the 56-bit vs 128-bit. I just want stock NetWare 5.1 without all the NSBS 5.1 ... features. I'll install just the few features that I want. Aside: NSBS 5.1 includes ZENworks (Starter?) and some other things that are above and beyond stock NetWare. I don't want those ... features yet. I want to learn more about stock NetWare 5.1. > But if you have SP0, no bugfixes, then surely you can just install > the SPs on top of it to get to whatever level you want? The only Support Pack that I've been able to find thus far is Exportable NetWare 5.1 Support Pack 1. I've not yet been able to locate any other support packs. Well, I guess I can still get SP7 and SP8 from Novell's Patch Download. But that's beyond what works with what I'm testing with Border Manager 3.5 It's a weird nitch that I'm trying to fit in. Early Domestic (128-bit) NetWare with Support Pack > 0 and < 7. > My $DAYJOB was part of Novell until about a year ago. I _may_ be able > to find internal download links still but I am not confident. Want > me to start asking around? I may need some fairly specific info as > there are few Netware folk left now. E.g. how many separate SPs did > NW5.1 get? Do you need both US and ROW versions? I would be very interested in contacting someone at Novell ~> Micro Focus about acquiring copies of what was freely downloadable ~20 years ago. I did take a swing (and apparently a miss) to contact someone at Micro Focus a year or so ago. But that never went anywhere. But I'm not surprised that a generic web contact us form didn't yield anything. Please ask questions that you need ~> want more information about, be it here or directly off list (your choice). > Oh dear... Ya.... I'm not surprised. But it is making things ... tricky ... entertaining. > TBH I have a suspicion nobody may have kept stuff like that, even > inside Novell... :( Ya. That seems to be the way that a LOT of things have gone in the industry. It's hobbyists like myself that tend to be archiving this stuff. I'm just 15-25 years too late. I'm going through my NetWare disks (5.1 ~> 5.x ~> x.x) and getting a better handle on what version / language(s) / encryption they are. Thank you for your time Liam. I appreciate your input and help. -- Grant. . . . unix || die From technoid6502 at gmail.com Wed Sep 9 13:07:54 2020 From: technoid6502 at gmail.com (Jeffrey S. Worley) Date: Wed, 09 Sep 2020 14:07:54 -0400 Subject: SunBlade 100 with USB type 7 keyboard Message-ID: My Sunblade works fine with a generic USB keyboard, but does not recognize the Type 7 USB keyboard I bought for it. OpenBoot prom reports "no keyboard detected". If I boot with my generic keyboard plugged in and then plug in the type 7, it sees it fine in OpenBSD. It is the openboot prom that doesn't see it. Can anyone steer me to the most current openboot prom update for the SunBlade 100? I've looked like crazy on Oracle's site and all I find are the instructions on how to apply an update, but not the actual update. This problem is firmware, not software or hardware. The Type 7 keyboard works fine on my PC, or if plugged into the Sunblade once it has booted/started to boot. Best, Jeff From wayne.sudol at hotmail.com Wed Sep 9 13:14:25 2020 From: wayne.sudol at hotmail.com (Wayne S) Date: Wed, 9 Sep 2020 18:14:25 +0000 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: References: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> <1668c3d3-f0c9-c574-e30f-e879893223a0@spamtrap.tnetconsulting.net> , Message-ID: Fyi .. there seems to be a lots of Netware for sale on Ebay for some reason. Sent from my iPhone > On Sep 9, 2020, at 10:42, Grant Taylor via cctalk wrote: > > ?On 9/9/20 5:08 AM, Liam Proven via cctalk wrote: >> But that's good, isn't it? > > Yes and no. > > Yes in that it's below the problem point. :-) > > No in that I don't have the necessary Support Pack's to install. :-( > >> I confess I may have misread your original message as being "I need NW5.1 with no SPs." Was that wrong? > > It might have been an ambiguity on my part. > > I've learned a little bit since my last message. > > I seem to have NetWare 5.1 (SP 0) for both "Domestic" (128-bit) and "Exportable" (56-bit). But there is a catch. > > The exportable version is part of Novell Small Business Suite 5.1, which seems to be a superset of NetWare 5.1. I don't yet know if I can bust it down to be a more standard NetWare 5.1 without all the other unwanted NSBS stuff. > > I did learn that NSBS 5.1 is the "Exportable" (56-bit) version and that it comes with Exportable NetWare 5.1 Support Pack 1 as an install able option on another disk. > > Said Exportable NetWare 5.1 Support Pack 1 will install on NSBS 5.1. But given that it's the "Exportable" (56-bit) version, it won't install on standard "Domestic" (128-bit) NetWare 5.1. That being said, I don't really care about the 56-bit vs 128-bit. I just want stock NetWare 5.1 without all the NSBS 5.1 ... features. I'll install just the few features that I want. > > Aside: NSBS 5.1 includes ZENworks (Starter?) and some other things that are above and beyond stock NetWare. I don't want those ... features yet. I want to learn more about stock NetWare 5.1. > >> But if you have SP0, no bugfixes, then surely you can just install the SPs on top of it to get to whatever level you want? > > The only Support Pack that I've been able to find thus far is Exportable NetWare 5.1 Support Pack 1. I've not yet been able to locate any other support packs. > > Well, I guess I can still get SP7 and SP8 from Novell's Patch Download. But that's beyond what works with what I'm testing with Border Manager 3.5 > > It's a weird nitch that I'm trying to fit in. Early Domestic (128-bit) NetWare with Support Pack > 0 and < 7. > >> My $DAYJOB was part of Novell until about a year ago. I _may_ be able to find internal download links still but I am not confident. Want me to start asking around? I may need some fairly specific info as there are few Netware folk left now. E.g. how many separate SPs did NW5.1 get? Do you need both US and ROW versions? > > I would be very interested in contacting someone at Novell ~> Micro Focus about acquiring copies of what was freely downloadable ~20 years ago. > > I did take a swing (and apparently a miss) to contact someone at Micro Focus a year or so ago. But that never went anywhere. But I'm not surprised that a generic web contact us form didn't yield anything. > > Please ask questions that you need ~> want more information about, be it here or directly off list (your choice). > >> Oh dear... > > Ya.... I'm not surprised. But it is making things ... tricky ... entertaining. > >> TBH I have a suspicion nobody may have kept stuff like that, even inside Novell... :( > > Ya. That seems to be the way that a LOT of things have gone in the industry. It's hobbyists like myself that tend to be archiving this stuff. I'm just 15-25 years too late. > > I'm going through my NetWare disks (5.1 ~> 5.x ~> x.x) and getting a better handle on what version / language(s) / encryption they are. > > Thank you for your time Liam. I appreciate your input and help. > > > > -- > Grant. . . . > unix || die From cctalk at gtaylor.tnetconsulting.net Wed Sep 9 13:30:57 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 9 Sep 2020 12:30:57 -0600 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: References: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> <1668c3d3-f0c9-c574-e30f-e879893223a0@spamtrap.tnetconsulting.net> Message-ID: On 9/9/20 12:14 PM, Wayne S wrote: > Fyi .. there seems to be a lots of Netware for sale on Ebay for some reason. Yep. I've acquired a number of things therefrom. Unfortunately, it's quite difficult to tell the difference between various things. Especially things like which support pack and / or language and / or domestic vs exportable. :-( So it's somewhat of a crap shoot. -- Grant. . . . unix || die From peter at vanpeborgh.eu Wed Sep 9 13:52:39 2020 From: peter at vanpeborgh.eu (Peter Van Peborgh) Date: Wed, 9 Sep 2020 19:52:39 +0100 Subject: cctech Digest, Vol 72, Issue 9 In-Reply-To: References: Message-ID: <028601d686da$64bb0920$2e311b60$@vanpeborgh.eu> Thanks -----Original Message----- From: cctech On Behalf Of cctech-request at classiccmp.org Sent: 09 September 2020 18:00 To: cctech at classiccmp.org Subject: cctech Digest, Vol 72, Issue 9 Send cctech mailing list submissions to cctech at classiccmp.org To subscribe or unsubscribe via the World Wide Web, visit http://www.classiccmp.org/mailman/listinfo/cctech or, via email, send a message with subject or body 'help' to cctech-request at classiccmp.org You can reach the person managing the list at cctech-owner at classiccmp.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cctech digest..." Today's Topics: 1. ftgh 95 ohm coax (Don Stalkowski) 2. Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? (Jules Richardson) 3. Re: ISO: DEC VR100 and early X releases (Matt Burke) 4. Re: NetWare 5.1 / BorderManager 3.5 (Liam Proven) 5. Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? (Liam Proven) 6. RE: ISO: DEC VR100 and early X releases (Electronics Plus) 7. Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? (Fred Cisin) 8. Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? (Doug Jackson) 9. Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? (Fred Cisin) 10. Re: NetWare 5.1 / BorderManager 3.5 (Grant Taylor) 11. Re: ISO: DEC VR100 and early X releases (jim stephens) 12. Re: NetWare 5.1 / BorderManager 3.5 (Grant Taylor) 13. Re: NetWare 5.1 / BorderManager 3.5 (Liam Proven) ---------------------------------------------------------------------- Message: 1 Date: Tue, 8 Sep 2020 12:33:07 -0400 (EDT) From: dstalk at execulink.com (Don Stalkowski) To: cctalk at classiccmp.org Subject: ftgh 95 ohm coax Message-ID: <20200908163307.241BDBEEAD4 at cel2.x> Content-Type: text/plain; charset=us-ascii ftgh: a few lengths of 95 ohm coax pickup-only here in London, ON ------------------------------ Message: 2 Date: Tue, 8 Sep 2020 16:12:09 -0500 From: Jules Richardson To: Fred Cisin via cctalk Subject: Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? Message-ID: <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56 at gmail.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed On 9/7/20 6:18 PM, Fred Cisin via cctalk wrote: > Floppy boot seems like the next step. OK, it boots off a DOS 3.3 floppy if that floppy is inserted before it attempts to boot from the hard disk. If I wait for it to do its "system file not found" bit, followed by a subsequent prompt to insert boot media and press a key, it attempts to access the floppy drive but then goes off into la-la land. Odd. But anyway, taking the successful floppy boot route, I can certainly access the hard disk in terms of bringing up directory listings and TYPEing files to the display. So far, attempts to run anything from the drive just result in a lock-up (keyboard immediately unresponsive, hard reset required). There appear to be DOS utils on the drive, and command.com, but I've not checked for hidden system files yet. fdisk shows the partition as active. > Got an IBM "Advanced Diagnostics" floppy to try? No, but I see that the minuszerodegrees site has an image, so I'll write that out and see what happens. Looking at the drive contents, incidentally, I didn't see anything that explains (or interacts with) that unusual video hardware - it basically just holds DOS and a bunch of documents written by the original owner. Maybe they got suckered into buying this fancy graphics hardware without having any actual need for it, and then of course EGA and VGA came along and rendered it obsolete anyway. > XT controllers tended to NOT be interchangeable, even between various > OEMs of Xebec! Yes - something that people often seem to forget, too. I've run into that quite often, where someone will hang onto an old drive because of the contents, but they'll dump the controller that it was formatted against. > I don't know what the incompatability was. I don't think there was any kind of standard at all for what the low level looked like - vendors were free to do what they wanted in terms of what values they used for flags and how they actually ordered things within the sector header. I suppose there were some tweaks made over time for optimization or reliability (or at least, recovery) reasons, too, which is why even a single vendor had a few different incompatible formats. I expect it was the same in the SCSI and IDE worlds, but of course with those "the controller" which handles formatting is really part of the package, so it wasn't an issue. Jules ------------------------------ Message: 3 Date: Tue, 8 Sep 2020 23:11:01 +0100 From: Matt Burke To: Josh Dersch via cctalk Subject: Re: ISO: DEC VR100 and early X releases Message-ID: <91d46a24-04df-20c7-d154-d17064116c6f at 9track.net> Content-Type: text/plain; charset=utf-8 On 05/09/2020 20:19, Josh Dersch via cctalk wrote: > While I'm at it -- anyone know > precisely what I need to use this under VMS? I believe 4.7 was the > last VMS release that supported it, but there were additional packages > that needed to be installed to support it, and I'm not entirely sure > what they are. To use the VAXstation 100 with VMS you need to install the "VAXstation Software" layered product. I have not come across any original copies however DEC later contributed the source code to the DECUS library under submission V00376. The submission consists of a CMS library and some other source files. The only place you can reliably get this from is DECUServe as you need to get the files whilst preserving their RMS attributes. Then you need to compile the code and create an installation kit to use the software. The good news is that I've already done all of this so here is a link to the source and installation kit on Simh tap files: http://www.9track.net/bits/dec/vs100/v00376.zip http://www.9track.net/bits/dec/vs100/vsta012.zip This was built on VAX/VMS V4.4 with: Bliss-32 V4.3 FORTRAN V4.7 Pascal V3.7 CMS V2.3 MMS V2.2 I also have a VAXstation 100 that I hope to get working some day but I need the M7452 card and a VS10X-EA mouse. I did win an M7452 on eBay about 10 years ago but the seller then said that he had already sold it. I've not seen another one since (well not one for an affordable price. I did find a reseller that wanted $1000 for one). Matt ------------------------------ Message: 4 Date: Wed, 9 Sep 2020 00:42:19 +0200 From: Liam Proven To: "General Discussion: On-Topic and Off-Topic Posts" Subject: Re: NetWare 5.1 / BorderManager 3.5 Message-ID: Content-Type: text/plain; charset="UTF-8" On Tue, 8 Sep 2020 at 08:18, Grant Taylor via cctalk wrote: > > Does anyone have any idea where I can get install media at various > support pack levels and / or support pack install files for NetWare > 5.1 and / or BorderManager 3.5? Something like this any help? https://winworldpc.com/product/netware/5x I have physical media of this somewhere: https://archive.org/details/Netware_5_Operating_System_3_User_Demo_Novell -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 ------------------------------ Message: 5 Date: Wed, 9 Sep 2020 00:46:18 +0200 From: Liam Proven To: "General Discussion: On-Topic and Off-Topic Posts" Subject: Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? Message-ID: Content-Type: text/plain; charset="UTF-8" On Tue, 8 Sep 2020 at 06:47, Fred Cisin via cctalk wrote: > > 1) If the drive is larger than 32MB, then boot with DOs 3.31 or newer. > Although even with the older ones, you can still do quite a bit. 3.31 is > the first where DOS supports a partition larger than 32MB > MS-DOS 5.00 is first where debug commands have a "/?" option to get a > short reminder of usage. Agreed. (Like I'd dare to differ with Fred.) My 2?'s worth is just: for an XT, if you want to fit a CF card or something, try DR-DOS 3.41. It's out there in various places. RAM usage as small as MS-DOS 3.3 but offers most of the benefits of MS-DOS 4 and some of MS-DOS 5 (both of which take a *lot* more RAM on an XT-class machine.) -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 ------------------------------ Message: 6 Date: Tue, 8 Sep 2020 17:48:37 -0500 From: "Electronics Plus" To: "'Matt Burke'" , "'General Discussion: On-Topic and Off-Topic Posts'" Subject: RE: ISO: DEC VR100 and early X releases Message-ID: <007501d68632$30c06410$92412c30$@com> Content-Type: text/plain; charset="utf-8" There is a DEC dealer in the UK that has M7452 cards listed as in-stock. Contact Spencer Dye at sales at swancomp.co.uk. Old mouse I have located, but he has to check if it is actually in stock, and if it works. Cindy -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Matt Burke via cctalk Sent: Tuesday, September 08, 2020 5:11 PM To: Josh Dersch via cctalk Subject: Re: ISO: DEC VR100 and early X releases On 05/09/2020 20:19, Josh Dersch via cctalk wrote: > While I'm at it -- anyone know > precisely what I need to use this under VMS? I believe 4.7 was the last > VMS release that supported it, but there were additional packages that > needed to be installed to support it, and I'm not entirely sure what they > are. To use the VAXstation 100 with VMS you need to install the "VAXstation Software" layered product. I have not come across any original copies however DEC later contributed the source code to the DECUS library under submission V00376. The submission consists of a CMS library and some other source files. The only place you can reliably get this from is DECUServe as you need to get the files whilst preserving their RMS attributes. Then you need to compile the code and create an installation kit to use the software. The good news is that I've already done all of this so here is a link to the source and installation kit on Simh tap files: http://www.9track.net/bits/dec/vs100/v00376.zip http://www.9track.net/bits/dec/vs100/vsta012.zip This was built on VAX/VMS V4.4 with: Bliss-32 V4.3 FORTRAN V4.7 Pascal V3.7 CMS V2.3 MMS V2.2 I also have a VAXstation 100 that I hope to get working some day but I need the M7452 card and a VS10X-EA mouse. I did win an M7452 on eBay about 10 years ago but the seller then said that he had already sold it. I've not seen another one since (well not one for an affordable price. I did find a reseller that wanted $1000 for one). Matt ------------------------------ Message: 7 Date: Tue, 8 Sep 2020 16:04:44 -0700 (PDT) From: Fred Cisin To: "General Discussion: On-Topic and Off-Topic Posts" Subject: Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 8 Sep 2020, Jules Richardson via cctalk wrote: > OK, it boots off a DOS 3.3 floppy if that floppy is inserted before it > attempts to boot from the hard disk. If I wait for it to do its "system file > not found" bit, followed by a subsequent prompt to insert boot media and > press a key, it attempts to access the floppy drive but then goes off into > la-la land. Odd. How large is the drive? If it is over 32MB, then try to find DOS 3.31 or newer. MY preference is MS-DOS 6.22 > But anyway, taking the successful floppy boot route, I can certainly access > the hard disk in terms of bringing up directory listings and TYPEing files to > the display. So far, attempts to run anything from the drive just result in a > lock-up (keyboard immediately unresponsive, hard reset required). There > appear to be DOS utils on the drive, and command.com, but I've not checked > for hidden system files yet. fdisk shows the partition as active. Date and time of Command.com and any other DOS files will identify the version number. DIR /A or DIR /A:H will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS had IBMBIO.COM and IBMDOS.COM instead) Can you COPY files from the HDD to floppy? Being able to access contents of files, but not RUN them seems odd. IF the DOS on the floppy misunderstands the partition table, then root directory might look OK, but sub-directories might not be where it thinks they are, . . . >> Got an IBM "Advanced Diagnostics" floppy to try? > No, but I see that the minuszerodegrees site has an image, so I'll write that > out and see what happens. NOT a big deal. It's merely the only method directly from IBM for doing low level format. In most cases, Speedstor is more useful for LLF. > Looking at the drive contents, incidentally, I didn't see anything that > explains (or interacts with) that unusual video hardware - it basically just > holds DOS and a bunch of documents written by the original owner. Maybe they > got suckered into buying this fancy graphics hardware without having any > actual need for it, and then of course EGA and VGA came along and rendered it > obsolete anyway. It is probably completely CGA compatible, unless you invoke of of its other modes. The ROM on the video card may be a BIOS extension, in which case access to extended modes may be handled internally in various programs. For instance Windows 3.x, PC PAint, Pagemaker, and Xerox Ventura let you configure for a variety of video hardware. Otherwise, check to see if CONFIG.SYS has DEVICE commands to load any device drivers, usually .SYS, although sometimes .COM >> XT controllers tended to NOT be interchangeable, even between various OEMs >> of Xebec! > Yes - something that people often seem to forget, too. I've run into that > quite often, where someone will hang onto an old drive because of the > contents, but they'll dump the controller that it was formatted against. It always seemed counter-intuitive that makers of HDD hardware for XT didn't slavishly mimic IBM's XT HDD. And especially counter-intuitive that different vendor Xebec controllers didn't always interchange. -- Grumpy Ol' Fred cisin at xenosoft.com ------------------------------ Message: 8 Date: Wed, 9 Sep 2020 09:16:42 +1000 From: Doug Jackson To: Fred Cisin , "General Discussion: On-Topic and Off-Topic Posts" Subject: Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? Message-ID: Content-Type: text/plain; charset="UTF-8" I recall some of the high end cards in the CGA / EGA era had adon boards that were connected with a 20 or 36 pin jumper cable across the top of the boards - They also ran more than 64K or ram, such as the ATI Wonder boards. Maybe it's like that - the ATI boards had 256K so they could page. Kindest regards, Doug Jackson em: doug at doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net ----------------------------------------------------------- Just like an old fashioned letter, this email and any files transmitted with it should probably be treated as confidential and intended solely for your own use. Please note that any interesting spelling is usually my own and may have been caused by fat thumbs on a tiny tiny keyboard. Should any part of this message prove to be useful in the event of the imminent Zombie Apocalypse then the sender bears no personal, legal, or moral responsibility for any outcome resulting from its usage unless the result of said usage is the unlikely defeat of the Zombie Hordes in which case the sender takes full credit without any theoretical or actual legal liability. :-) Be nice to your parents. Go outside and do something awesome - Draw, paint, walk, setup a radio station, go fishing or sailing - just do something that makes you happy. ^G ^G ^G ^G ^G ^G ^G ^G- In more laid back days this line would literally sing ^G ^G ^G ^G ^G ^G ^G ^G On Wed, Sep 9, 2020 at 9:04 AM Fred Cisin via cctalk wrote: > On Tue, 8 Sep 2020, Jules Richardson via cctalk wrote: > > OK, it boots off a DOS 3.3 floppy if that floppy is inserted before it > > attempts to boot from the hard disk. If I wait for it to do its "system > file > > not found" bit, followed by a subsequent prompt to insert boot media and > > press a key, it attempts to access the floppy drive but then goes off > into > > la-la land. Odd. > > How large is the drive? > If it is over 32MB, then try to find DOS 3.31 or newer. > MY preference is MS-DOS 6.22 > > > > But anyway, taking the successful floppy boot route, I can certainly > access > > the hard disk in terms of bringing up directory listings and TYPEing > files to > > the display. So far, attempts to run anything from the drive just result > in a > > lock-up (keyboard immediately unresponsive, hard reset required). There > > appear to be DOS utils on the drive, and command.com, but I've not > checked > > for hidden system files yet. fdisk shows the partition as active. > > Date and time of Command.com and any other DOS files will identify the > version number. > > DIR /A or > DIR /A:H > will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS > had IBMBIO.COM and IBMDOS.COM instead) > > Can you COPY files from the HDD to floppy? > > Being able to access contents of files, but not RUN them seems odd. > IF the DOS on the floppy misunderstands the partition table, then root > directory might look OK, but sub-directories might not be where it thinks > they are, . . . > > > >> Got an IBM "Advanced Diagnostics" floppy to try? > > No, but I see that the minuszerodegrees site has an image, so I'll write > that > > out and see what happens. > > NOT a big deal. It's merely the only method directly from IBM for doing > low level format. > In most cases, Speedstor is more useful for LLF. > > > Looking at the drive contents, incidentally, I didn't see anything that > > explains (or interacts with) that unusual video hardware - it basically > just > > holds DOS and a bunch of documents written by the original owner. Maybe > they > > got suckered into buying this fancy graphics hardware without having any > > actual need for it, and then of course EGA and VGA came along and > rendered it > > obsolete anyway. > > It is probably completely CGA compatible, unless you invoke of of its > other modes. > > The ROM on the video card may be a BIOS extension, in which case access to > extended modes may be handled internally in various programs. For > instance Windows 3.x, PC PAint, Pagemaker, and Xerox Ventura let you > configure for a variety of video hardware. > Otherwise, check to see if CONFIG.SYS has DEVICE commands to load any > device drivers, usually .SYS, although sometimes .COM > > >> XT controllers tended to NOT be interchangeable, even between various > OEMs > >> of Xebec! > > Yes - something that people often seem to forget, too. I've run into > that > > quite often, where someone will hang onto an old drive because of the > > contents, but they'll dump the controller that it was formatted against. > > It always seemed counter-intuitive that makers of HDD hardware for XT > didn't slavishly mimic IBM's XT HDD. And especially counter-intuitive > that different vendor Xebec controllers didn't always interchange. > > > -- > Grumpy Ol' Fred cisin at xenosoft.com > ------------------------------ Message: 9 Date: Tue, 8 Sep 2020 16:28:39 -0700 (PDT) From: Fred Cisin To: "General Discussion: On-Topic and Off-Topic Posts" Subject: Re: AW: CGA card (Mitsubishi Electric) with 192K RAM? Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 9 Sep 2020, Doug Jackson wrote: > I recall some of the high end cards in the CGA / EGA era had adon boards > that were connected with a 20 or 36 pin jumper cable across the top of the > boards - They also ran more than 64K or ram, such as the ATI Wonder > boards. Maybe it's like that - the ATI boards had 256K so they could page. I had a CGA "double board" that did 640x400 or 640x200 by more colors. It was not the same as this one, but might have been internally similar. But I don't remember ATI premium CGA. ATI had some interesting EGA boards, including one that had an add-on that included the mid-board connector for Compaq luggable internal video! Otherwise, you were stuck with Compaq CGA or Compaq EGA. ------------------------------ Message: 10 Date: Tue, 8 Sep 2020 19:18:04 -0600 From: Grant Taylor To: cctalk at classiccmp.org Subject: Re: NetWare 5.1 / BorderManager 3.5 Message-ID: <9cbe174f-7eb1-bd77-88d9-a433449278f6 at spamtrap.tnetconsulting.net> Content-Type: text/plain; charset=utf-8; format=flowed On 9/8/20 4:42 PM, Liam Proven via cctalk wrote: > Something like this any help? > > https://winworldpc.com/product/netware/5x I'm very familiar with WinWorld and VetusWare. I quite like them. They are on the short list to find things like this. There is high overlap between a number of these places. That being said, I haven't tested that specific ISO. But that's mostly because I've long had a version of NetWare 5.1. Now that I'm looking for specific things, particularly patches, I decided to send a broadcast message. > I have physical media of this somewhere: > > https://archive.org/details/Netware_5_Operating_System_3_User_Demo_Novell I've been focusing on 5.1 and I've not yet broadened my net to include 5(.0). I was sort of hoping that someone might have had the support pack files tucked away somewhere. I'm currently working on re-organizing my 48 GB of Novell software. Partially to normalize the names and location, as well as to be able to tell what I do and do not have. Thank you for the reply Liam. You re-enforced the fact that I need to get a better understanding of what /specific/ versions I have and the things I know about are. -- Grant. . . . unix || die ------------------------------ Message: 11 Date: Tue, 8 Sep 2020 20:25:19 -0700 From: jim stephens To: cctalk at classiccmp.org Subject: Re: ISO: DEC VR100 and early X releases Message-ID: <7487c5f1-bfe6-0d6d-8b37-ee0668c2540c at jwsss.com> Content-Type: text/plain; charset=utf-8; format=flowed On 9/8/2020 3:48 PM, Electronics Plus via cctalk wrote: > Old mouse I have located, but he has to check if it is actually in stock, and if it works. They aren't the "normal" DEC hockey puck mice.? it's sort of like a PS2 mouse with I think an odd ball.? I had hands on Josh's and one for Paul Birkel (for too long, but they have them now), and the mouse was odd. I don't know how Josh is doing, since is is working, but the cabling on the mouse cord had degraded and had goo on it like the black crap you get form the wrong type of rubber when it turns tar like. Glad Josh got his going, pulling for Paul to get his running.? And interesting they may be a third one. So cool Cameron Kaiser collected two and passed them along. thanks Jim ------------------------------ Message: 12 Date: Tue, 8 Sep 2020 22:33:47 -0600 From: Grant Taylor To: cctalk at classiccmp.org Subject: Re: NetWare 5.1 / BorderManager 3.5 Message-ID: <1668c3d3-f0c9-c574-e30f-e879893223a0 at spamtrap.tnetconsulting.net> Content-Type: text/plain; charset=utf-8; format=flowed On 9/8/20 7:18 PM, Grant Taylor via cctalk wrote: > I haven't tested that specific ISO. The particular ISO that you linked to is Novell NetWare 5.1 (Support Pack 0). So it needs support packs installed on it. I've learned that there are different Support Packs, "Domestic" and "International" having to do with the 128-bit vs 56-bit encryption woes of the '90s. -- Grant. . . . unix || die ------------------------------ Message: 13 Date: Wed, 9 Sep 2020 13:08:43 +0200 From: Liam Proven To: "General Discussion: On-Topic and Off-Topic Posts" Subject: Re: NetWare 5.1 / BorderManager 3.5 Message-ID: Content-Type: text/plain; charset="UTF-8" On Wed, 9 Sep 2020 at 06:34, Grant Taylor via cctalk wrote: > > On 9/8/20 7:18 PM, Grant Taylor via cctalk wrote: > > I haven't tested that specific ISO. > > The particular ISO that you linked to is Novell NetWare 5.1 (Support > Pack 0). So it needs support packs installed on it. But that's good, isn't it? I confess I may have misread your original message as being "I need NW5.1 with no SPs." Was that wrong? But if you have SP0, no bugfixes, then surely you can just install the SPs on top of it to get to whatever level you want? My $DAYJOB was part of Novell until about a year ago. I _may_ be able to find internal download links still but I am not confident. Want me to start asking around? I may need some fairly specific info as there are few Netware folk left now. E.g. how many separate SPs did NW5.1 get? Do you need both US and ROW versions? > I've learned that there are different Support Packs, "Domestic" and > "International" having to do with the 128-bit vs 56-bit encryption woes > of the '90s. Oh dear... TBH I have a suspicion nobody may have kept stuff like that, even inside Novell... :( -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 End of cctech Digest, Vol 72, Issue 9 ************************************* From stefan.skoglund at agj.net Wed Sep 9 14:38:12 2020 From: stefan.skoglund at agj.net (Stefan Skoglund) Date: Wed, 09 Sep 2020 21:38:12 +0200 Subject: NetWare 5.1 / BorderManager 3.5 In-Reply-To: References: <9cbe174f-7eb1-bd77-88d9-a433449278f6@spamtrap.tnetconsulting.net> <1668c3d3-f0c9-c574-e30f-e879893223a0@spamtrap.tnetconsulting.net> Message-ID: <1f7bfd2a97ed4460edd8d8f9f34166c05f98c887.camel@agj.net> ons 2020-09-09 klockan 13:08 +0200 skrev Liam Proven via cctalk: > > Oh dear... > > TBH I have a suspicion nobody may have kept stuff like that, even > inside Novell... :( > I will have to check where i read this just recently but well the industry is such that repeatibility and possibility to reproduce something which was computed in different areas of science 10 years ago now is very hard to redo. If the source code to the computations is available (which is a big if) What to run it on ?? Different compilers ... so expect other results if the computations isn't the one which have clear cut answers... From cisin at xenosoft.com Wed Sep 9 14:40:22 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 9 Sep 2020 12:40:22 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> Message-ID: >> Date and time of Command.com and any other DOS files will identify the >> version number. On Wed, 9 Sep 2020, Jules Richardson via cctalk wrote: > I've got 11/26/85 on command.com. That would be MS-DOS version 3.10 Best known for having the "network redirector"? (which was also the loophole that permitted MSCDEX to have CD-ROM (bigger than 32MB, BUT DOS didn't know that it was local - thought that it was on a network somewhere)) 1.00 August 1981 1.10 May 1982 double sided drives 1.25 MS-DOS 2.00 March 1983 HDDs, hierarchical directories, file handle API 2.10 October 1983 slowed down disk access for the PCJr Qumetrak 142 2.11 MS-DOS heavily customized by OEMs 3.00 August 1984 AT/5170, 1.2MB floppy, 3.10 Nov 1985 network redirector? 3.20 January 1986 included PC-DOS 720K 3.5" floppy (some OEM MS-DOS versions had 3.5" since MS-DOS 2.11) 3.30 April 1987 PS/2 3.31 MS-DOS heavily customized by OEMs, >32MB HDD 4.00 PC-DOS HDD >32MB "not compatible with Norton" 4.01 5.00 May 1991 DOS version in the displayed date 6.00 March 1993 massive inclusion of aftermarket add-ons 6.10 IBM's Version 6.20 October 1993 reliability improvements! (such as changing SMARTDRV) 6.21 removal of infringing compression 6.22 addition of non-infringing compression >> DIR /A? or >> DIR /A:H >> will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS >> had IBMBIO.COM and IBMDOS.COM instead) > The /a switch isn't part of the dir command in whatever 3.3 version I have. sorry, try ATTRIB *.* > However, I just wrote a DOS 6.22 boot disk and that shows three hidden files > on the hard disk: > MSDOS.SYS (11/18/85) > MIO.SYS (11/18/85) > SD.INI > > I'm guessing that the 'M' in MIO.SYS is "Mitsubishi" and the OS is tailored > in some way to the machine. > > TYPEing "sd.ini" indicates that it's related to Norton Speed Disk - not a > program I'm familiar with, but as that appears to be a defragmenter, it might > hint at why my drive isn't bootable and seems to be having problems with > various executables - I wonder if the directory structure "looks sane", but > file contents have been completely mangled. COULD BE. HOPE NOT. Just like, . . . when DOS 1.10/1.25 came out, there were disasters when people ran CHKDSK 1.0 on a 1.10 disk, even if running the CHKDSK on DOS 1.10. Chkdsk proceeded to "FIX" the disk (cf. Merck Veterinary manual) THAT disaster resulted in later versions: 1) CHKDSK beagan to require "/F" ("fix"), AND requiring confirmation before "repairs" 2) DOS utilities ("External commands") wouldn't run on any version of DOS other than what they were bundled with. THAT resulted eventuaally in release (V5.00?) of SETVER. In my assembly language class, I showed them how to use DEBUG to patch LINK and EXE2BIN to stop caring about DOS version, and assigned them to go home and do it. (comment out the conditional jump after Int21h, Fn 30h) Ah, but another classic example, . . . Norton fUtilities wasn't compatible with DOS 4.00 or 4.01 >32MB HDD. It needed changes to comply with the 3.31 and newer changes to HDD The press didn't phrase it that way! They said, "DOS 4 is broken, it isn't compatible with Norton! DOS needs to be fixed to work with Norton!" Obviously, a new version of Norton fUtilities was called for to go with the new OS. MICROS~1 learned the hard way that major changes called for meeting with certain software vendors and giving them advanced warning, so that they could come out with new versions at same time as new OS release. >> It is probably completely CGA compatible, unless you invoke of of its other >> modes. > Maybe. Assuming that the hard drive's directory contents are intact, and > therefore there's nothing too unusual on the drive, I've perhaps got nothing > to lose by reformatting - the only issue is that MIO.SYS, how it differs from > Microsoft's, whether it's corrupt or not, and how - if it is intact - I can > migrate it over post-install. If machine works OK from floppy 6.22 boot, then you could re-format with that. Save a copy of the MSDOS.SYS, MIO.SYS, COMMAND.COM, and contents of DOS directory. Try seeing what modes you can set with Int 10h, and poke memory in various modes. You are going to be spending some time in DEBUG! > Of course maybe speed disk (if that is even the cause of my problems) has > some kind of backup / undo aspect, but I doubt it. "and UNDO the IMPROVEMENTS??!?" -- Grumpy Ol' Fred cisin at xenosoft.com From cisin at xenosoft.com Wed Sep 9 14:59:21 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 9 Sep 2020 12:59:21 -0700 (PDT) Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> <30e83f7c-26ee-0ad0-907d-cd6a3efa4e56@gmail.com> Message-ID: >>> Date and time of Command.com and any other DOS files will identify the >>> version number. On Wed, 9 Sep 2020, Liam Proven via cctalk wrote: > Only after DOS 5 or so, I fear. By lookup of the date prior to 5.00; starting with 5.00, visible instead of accurate dates > Oh dear, yes. If the machine is not totally vanilla but close enough > to boot vanilla DOS, then it's possible that SPEEDISK could have run > but incorrectly and mangled stuff. Similarly running DOS defraggers on > a VFAT disk with LFNs would mangle them, in the Win95 era. That is very worrisome. > TBH, though, I'm surprised -- later versions of DOS (such as 6.22) > didn't run on DOS compatible machines, because they'd died out by > then. It was IBM compatible or nothing by the DOS 6 era, IIRC. So I'd > expect a later-era machine to be compatible enough that Norton etc. > would have no problem. various levels of "IBM compatible". PCWorld (1983?) did a test of "compatibles", and misused Xenocopy as "the acid test", using a very early "REAL IBM PC ONLY" version of the program that my publisher (may they rot in pieces) had insisted on for trying to peddle to IBM. By the time of the PCWorld article, RELEASE VERSIONS of XenoCopy ran on anything that had reasonable INT13h, INT1EH, and INT10h compatibility. From martin at shackspace.de Wed Sep 9 16:09:50 2020 From: martin at shackspace.de (Martin Peters) Date: Wed, 9 Sep 2020 23:09:50 +0200 Subject: AW: CGA card (Mitsubishi Electric) with 192K RAM? In-Reply-To: References: <1dee7920-9b80-df7b-38c5-09c32abfaf8f@gmail.com> <160da320-a686-52bf-3d0c-98b91f28f485@gmail.com> Message-ID: <20200909210949.GA18059@zdi2.informatik.uni-stuttgart.de> Fred Cisin via cctalk: (...') > Got an IBM "Advanced Diagnostics" floppy to try? If you want to do a ll-format, you only need debug: A>DEBUG - -I 322 # reads dip-switches (don't think this is needed) -I 321 # read status -O 322 0 # select the controller -I 321 # read status -O 320 04 # ll-format instruction -O 320 00 # 00 for drive C, 20 for drive D -O 320 00 -O 320 00 -O 320 05 -O 320 07 the six "O 320" issue the "low-level format" instruction directly to the controller. Bit 5 in 2nd byte represents the drive. Do not expect any feedback, this is not a program, this is a direct communication with the controller via in/out instructions. The ll-format process is done in the controller's firmware and the Xebec-controllers are very slow. -- Martin Peters martin at shackspace.de From ccth6600 at gmail.com Thu Sep 10 10:11:07 2020 From: ccth6600 at gmail.com (Tom Hunter) Date: Thu, 10 Sep 2020 23:11:07 +0800 Subject: Matsushita 310JLB4 CRT datasheet Message-ID: Has anybody got a datasheet for the 12" black&white CRT made by Matsushita (Panasonic) with part number 310JLB4 (N)? Thanks Tom Hunter From derschjo at gmail.com Thu Sep 10 14:28:15 2020 From: derschjo at gmail.com (Josh Dersch) Date: Thu, 10 Sep 2020 12:28:15 -0700 Subject: ISO: DEC VR100 and early X releases In-Reply-To: <91d46a24-04df-20c7-d154-d17064116c6f@9track.net> References: <91d46a24-04df-20c7-d154-d17064116c6f@9track.net> Message-ID: On Tue, Sep 8, 2020 at 3:11 PM Matt Burke via cctalk wrote: > On 05/09/2020 20:19, Josh Dersch via cctalk wrote: > > While I'm at it -- anyone know > > precisely what I need to use this under VMS? I believe 4.7 was the last > > VMS release that supported it, but there were additional packages that > > needed to be installed to support it, and I'm not entirely sure what they > > are. > > To use the VAXstation 100 with VMS you need to install the "VAXstation > Software" layered product. I have not come across any original copies > however DEC later contributed the source code to the DECUS library under > submission V00376. The submission consists of a CMS library and some > other source files. The only place you can reliably get this from is > DECUServe as you need to get the files whilst preserving their RMS > attributes. Then you need to compile the code and create an installation > kit to use the software. > > The good news is that I've already done all of this so here is a link to > the source and installation kit on Simh tap files: > > http://www.9track.net/bits/dec/vs100/v00376.zip > http://www.9track.net/bits/dec/vs100/vsta012.zip > > This was built on VAX/VMS V4.4 with: > > Bliss-32 V4.3 > FORTRAN V4.7 > Pascal V3.7 > CMS V2.3 > MMS V2.2 > Thanks so much for compiling this and making it available! I'll hopefully have time to give it a go in the next week or so. > > I also have a VAXstation 100 that I hope to get working some day but I > need the M7452 card and a VS10X-EA mouse. I did win an M7452 on eBay > about 10 years ago but the seller then said that he had already sold it. > I've not seen another one since (well not one for an affordable price. I > did find a reseller that wanted $1000 for one). > Yeah, I think I found the same reseller, same price. I got really lucky and stumbled onto a usenet post from 1999 that lead me to a very kind person who still had the parts in his stash. The mouse shouldn't be too difficult to substitute a replacement for, it's just a Hawley, with quadrature signaling. - Josh > > Matt > From silent700 at gmail.com Thu Sep 10 16:08:39 2020 From: silent700 at gmail.com (Jason T) Date: Thu, 10 Sep 2020 16:08:39 -0500 Subject: Virtual VCFMW Schedule Posted Message-ID: Hi folks - we're doing this thing! The schedule is up, with links to the individual videos being filled in by tomorrow evening: https://mailchi.mp/222b57fb03dc/virtual-vcfmw-schedule-posted The videos will be presented in sequence using YouTube's "Premiere" function, which means there will be a live chat on the YT page where (ideally) the video creator will chat along and conduct a Q&A during and after. There is also an all-day open chat on a linked IRC/Discord channel. Details are on our page here: http://vcfmw.org/virtual.html Hope you can join us online for a day of chatting and classiccmp video fun! -jt From sales at elecplus.com Thu Sep 10 16:39:21 2020 From: sales at elecplus.com (Electronics Plus) Date: Thu, 10 Sep 2020 16:39:21 -0500 Subject: Old DEC mice for sale Message-ID: <001b01d687ba$d89c3130$89d49390$@com> My friend Lidan at Continental Computers found some old DEC mice in his warehouse for me. These are in California. 3x VS10X-EA - $120 each (used complete) 1x VS10X-EA - $75 (missing 3 button caps) 1x VSXXX-AA - $125 (NEW in box) 3x VSXXX-AA - $75 (used complete) Lidan Sadon Sales Manager Continental Computers D - 310/906-3553 C - 818/554-8856 lidan at conticomp.com Please contact him directly if you want to order these. I had no idea old DEC mice were so expensive! Cindy -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From tdk.knight at gmail.com Thu Sep 10 16:23:49 2020 From: tdk.knight at gmail.com (Adrian Stoness) Date: Thu, 10 Sep 2020 16:23:49 -0500 Subject: Virtual VCFMW Schedule Posted In-Reply-To: <89b640f9-a825-67a5-7258-c9702b892797@ljw.me.uk> References: <89b640f9-a825-67a5-7258-c9702b892797@ljw.me.uk> Message-ID: aww damn ill be 30miles in the bush at work for 3 days On Thu, Sep 10, 2020 at 4:12 PM Lawrence Wilkinson via cctech < cctech at classiccmp.org> wrote: > -------- Forwarded Message -------- > Subject: Virtual VCFMW Schedule Posted > Date: Thu, 10 Sep 2020 16:08:39 -0500 > From: Jason T via cctalk > Reply-To: Jason T > > > > Hi folks - we're doing this thing! The schedule is up, with links to > the individual videos being filled in by tomorrow evening: > > https://mailchi.mp/222b57fb03dc/virtual-vcfmw-schedule-posted > > The videos will be presented in sequence using YouTube's "Premiere" > function, which means there will be a live chat on the YT page where > (ideally) the video creator will chat along and conduct a Q&A during > and after. There is also an all-day open chat on a linked IRC/Discord > channel. Details are on our page here: > > http://vcfmw.org/virtual.html > > Hope you can join us online for a day of chatting and classiccmp video fun! > > -jt > From w2hx at w2hx.com Fri Sep 11 11:59:06 2020 From: w2hx at w2hx.com (W2HX) Date: Fri, 11 Sep 2020 16:59:06 +0000 Subject: article on TRS-80 in Nuts and Volts Message-ID: <37e0e7463e3941a29fcefc4ee902ab18@EXBE015SV3.NA02.MSEXCHANGEOUTLOOK.COM> Don't know if anyone gets/reads this old rag but I thought I'd share an article I came across: https://www.nutsvolts.com/magazine/article/the-trs-80-model-1 73 Eugene W2HX From rich.cini at verizon.net Fri Sep 11 12:16:48 2020 From: rich.cini at verizon.net (Richard Cini) Date: Fri, 11 Sep 2020 17:16:48 +0000 Subject: article on TRS-80 in Nuts and Volts In-Reply-To: <37e0e7463e3941a29fcefc4ee902ab18@EXBE015SV3.NA02.MSEXCHANGEOUTLOOK.COM> References: <37e0e7463e3941a29fcefc4ee902ab18@EXBE015SV3.NA02.MSEXCHANGEOUTLOOK.COM> Message-ID: Great article, and I still subscribe to N&V. I started with it after Popular Electronics and Radio Electronics folded. IIRC, I think N&V bought the subscription list or something, which is how I got it. Rich http://www.classiccmp.org/cini Long Island S100 User?s Group Get Outlook for iOS ________________________________ From: cctech on behalf of W2HX via cctech Sent: Friday, September 11, 2020 12:59:06 PM To: vcf-midatlantic ; cctech at classiccmp.org Subject: article on TRS-80 in Nuts and Volts Don't know if anyone gets/reads this old rag but I thought I'd share an article I came across: https://www.nutsvolts.com/magazine/article/the-trs-80-model-1 73 Eugene W2HX From dave.dunfield at gmail.com Fri Sep 11 17:23:59 2020 From: dave.dunfield at gmail.com (Dave Dunfield) Date: Fri, 11 Sep 2020 18:23:59 -0400 Subject: What I've been doing lately Message-ID: Hi everyone, Might not be exactly classic computer related, but I know many of you have been following my progress through my recovery (thanks for the many kind words), and I do think many of you might find this a tad interesting. What I've been doing for the past little while - check out my latest project "Dunfield Virtual Machine" on my personal web site: http://dunfield.maknonsolutions.com Regards, Dave -- ---------------------------------------------------------------------------------- Personal site: http://dunfield.maknonsolutions.com ---------------------------------------------------------------------------------- From spedraja at gmail.com Sat Sep 12 00:18:45 2020 From: spedraja at gmail.com (Sergio Pedraja) Date: Sat, 12 Sep 2020 07:18:45 +0200 Subject: What I've been doing lately In-Reply-To: References: Message-ID: Very interesting. By the way I've been reading your comments about your incident in 2019. I am impressed. All the best for you and your near people. Kind Regards Sergio El s?b., 12 sept. 2020 0:24, Dave Dunfield via cctalk escribi?: > Hi everyone, > > Might not be exactly classic computer related, but I know many of you have > been > following my progress through my recovery (thanks for the many kind > words), and > I do think many of you might find this a tad interesting. > > What I've been doing for the past little while - check out my latest > project "Dunfield Virtual Machine" on my personal web site: > http://dunfield.maknonsolutions.com > > Regards, > Dave > -- > > ---------------------------------------------------------------------------------- > Personal site: http://dunfield.maknonsolutions.com > > ---------------------------------------------------------------------------------- > From jfoust at threedee.com Sat Sep 12 08:06:12 2020 From: jfoust at threedee.com (John Foust) Date: Sat, 12 Sep 2020 08:06:12 -0500 Subject: Fwd: [GreenKeys] Teletype 33 near Phoenix AZ Message-ID: <20200912130627.004EE273E1@mx1.ezwind.net> > >From: Joe Clanin >Date: Sat, 12 Sep 2020 04:56:27 -0500 >To: greenkeys at mailman.qth.net >Subject: [GreenKeys] 28KSR, 26, 33 For Sale Near Phoenix, AZ > >I have no affiliation with the seller, just passing it along. > >28:? https://phoenix.craigslist.org/evl/ele/d/mesa-teletype-model-28/7194476271.html > >26:? https://phoenix.craigslist.org/evl/ele/d/mesa-teletype-model-26/7194473134.html > >33:? https://phoenix.craigslist.org/evl/sys/d/mesa-teletype-model-33-ksr/7184200181.html > >-Joe >__________ From athornton at gmail.com Sat Sep 12 12:41:05 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 12 Sep 2020 10:41:05 -0700 Subject: What's the secret to LK201 leaf springs? In-Reply-To: References: Message-ID: <61832F1F-57B4-4D50-A336-030677AFD55B@gmail.com> I got an LK201 recently that was a little damaged in transit. A couple of the keycap assemblies and their corresponding leaf springs have come off. I can see how the leaf springs fit on the little posts on the keycap assemblies, and I can see where those snap into the board, but what I don?t see is how to get that put together and then keep it together while I turn it over and then get it in place. Clearly there is some simple trick I am missing. What is it? Adam From ard.p850ug1 at gmail.com Sun Sep 13 10:04:24 2020 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Sun, 13 Sep 2020 16:04:24 +0100 Subject: What's the secret to LK201 leaf springs? In-Reply-To: <61832F1F-57B4-4D50-A336-030677AFD55B@gmail.com> References: <61832F1F-57B4-4D50-A336-030677AFD55B@gmail.com> Message-ID: On Sat, Sep 12, 2020 at 6:41 PM Adam Thornton via cctalk wrote: > > I got an LK201 recently that was a little damaged in transit. A couple of the keycap assemblies and their corresponding leaf springs have come off. I can see how the leaf springs fit on the little posts on the keycap assemblies, and I can see where those snap into the board, but what I don?t see is how to get that put together and then keep it together while I turn it over and then get it in place. > > Clearly there is some simple trick I am missing. What is it? When it was made, those posts were much longer. After fitting the leaf springs and fitting the unit to the membrane/chassis plate, the posts were melted and formed over to make a large 'head' that held it all together (this is commonly called heat staking). My guess is that the formed over part has broken off (you might find some little white disks of plastic, about 1/8" diameter, rattling about inside the case). Alas I have never found a way to re-fix them. There's not enough plastic in the housing to drill it out and fit screws/nuts. There is no way of gluing something to the ends of the posts that would be strong enough, -tony From marvin at west.net Sun Sep 13 12:15:20 2020 From: marvin at west.net (Marvin Johnston) Date: Sun, 13 Sep 2020 10:15:20 -0700 Subject: What's the secret to LK201 leaf springs? Message-ID: <5f4927e1-2c87-6b49-e69a-8ebea2a8bc9f@west.net> One thing I've tried and seems to work quite well (on another application) is UV curable plastic. The last thing I fixed was when the post holding one side of the exit paper tray broke off, and I used the UV curable plastic to fix it (still working just fine.) The trade name is Bondic, and I ran across it on a YouTube ad (first time EVER I bought something from an unknown YouTube ad!) This apparently is the same type of UV curable "glue" used by Dentists. It cures in about 4 seconds! > My guess is that the formed over part has broken off (you might find > some little white disks of plastic, about 1/8" diameter, rattling > about inside the case). Alas I have never found a way to re-fix them. > There's not enough plastic in the housing to drill it out and fit > screws/nuts. There is no way of gluing something to the ends of the > posts that would be strong enough, > > -tony From ian.finder at gmail.com Sun Sep 13 14:54:29 2020 From: ian.finder at gmail.com (Ian Finder) Date: Sun, 13 Sep 2020 12:54:29 -0700 Subject: Seeking "MEGATEK" Sun 3/4 era (?) VME Graphics accelerator information and driver Message-ID: I picked up a pair (1 set) of these very neat old graphics boards. Alas I have no idea what they are or if there is hope of using them. One is a dual slot 9U VME board that has gobs of video ram all over it, including a board labeled Z buffer. The only output are (3) BNC connectors (R,G, and B) and a 50 pin connector marked P4. The other is a single slot 9UVME board with (8) 30 pin SIMM slots with 1mb SIMM in them, a couple of Weitek chips, another 50 pin connector labeled P4, jumpered with a baby backplane to the other board, and 6 led on the front. Anyone know what these are and where to get drivers? They appear to be Sun 3 era, and the boards are labeled ?Sun OHC? with a megatek sticker. They do not appear to work out-of-box in my 3/260 as console devices- the Kernel does not identify them correctly. Thanks. From drb at msu.edu Sun Sep 13 15:28:29 2020 From: drb at msu.edu (Dennis Boone) Date: Sun, 13 Sep 2020 16:28:29 -0400 Subject: Seeking "MEGATEK" Sun 3/4 era (?) VME Graphics accelerator information and driver In-Reply-To: (Your message of Sun, 13 Sep 2020 12:54:29 -0700.) References: Message-ID: <20200913202829.D889619E69E@yagi.h-net.msu.edu> > Alas I have no idea what they are or if there is hope of using them. Megatek built graphics terminals and I think plotters that were used in CAD shops. Prime used them with some of their CAD offerings. Megatek also did boards for at least DG, -11, Modcomp systems, maybe others. In fact, some of the terminals may be based on Nova processors. The Megagraphic line mentions a bit-slice custom processor inside. The Whizzard line seems to interface via RS-232, but the Megagraphic family brochures say they had pio/dma interfaces for a variety of minicomputers, so are probably closer to matching your board set. You'd be looking for the relevant terminal, I'd think. De From ian.finder at gmail.com Sun Sep 13 16:48:40 2020 From: ian.finder at gmail.com (null) Date: Sun, 13 Sep 2020 14:48:40 -0700 Subject: Seeking "MEGATEK" Sun 3/4 era (?) VME Graphics accelerator information and driver In-Reply-To: <20200913202829.D889619E69E@yagi.h-net.msu.edu> References: <20200913202829.D889619E69E@yagi.h-net.msu.edu> Message-ID: This is a VME board with 3D acceleration, and RGB out. There is no terminal for it. Sent from NeXTMail > On Sep 13, 2020, at 13:28, Dennis Boone wrote: > > ? >> >> Alas I have no idea what they are or if there is hope of using them. > > Megatek built graphics terminals and I think plotters that were used in > CAD shops. Prime used them with some of their CAD offerings. Megatek > also did boards for at least DG, -11, Modcomp systems, maybe others. In > fact, some of the terminals may be based on Nova processors. The > Megagraphic line mentions a bit-slice custom processor inside. > > The Whizzard line seems to interface via RS-232, but the Megagraphic > family brochures say they had pio/dma interfaces for a variety of > minicomputers, so are probably closer to matching your board set. > > You'd be looking for the relevant terminal, I'd think. > > De From aek at bitsavers.org Sun Sep 13 17:44:18 2020 From: aek at bitsavers.org (Al Kossow) Date: Sun, 13 Sep 2020 15:44:18 -0700 Subject: Seeking "MEGATEK" Sun 3/4 era (?) VME Graphics accelerator information and driver In-Reply-To: References: <20200913202829.D889619E69E@yagi.h-net.msu.edu> Message-ID: <31991cfa-e801-b981-4f74-99a37882808c@bitsavers.org> On 9/13/20 2:48 PM, null via cctalk wrote: > There is no terminal for it. Megatek started out making caligraphic displays for DG systems those evolved into the Wizzard series. I have one with a Unibus interface. They switched to raster in the late 70s eventually moving to standalone 3D color raster terminals. The VME boards were their last gasp as a company as the graphics terminal market collapsed. Like all of the specialized 80's VME boards, it is going to be pretty much impossible to find software for them today. From aek at bitsavers.org Sun Sep 13 17:46:51 2020 From: aek at bitsavers.org (Al Kossow) Date: Sun, 13 Sep 2020 15:46:51 -0700 Subject: Seeking "MEGATEK" Sun 3/4 era (?) VME Graphics accelerator information and driver In-Reply-To: <31991cfa-e801-b981-4f74-99a37882808c@bitsavers.org> References: <20200913202829.D889619E69E@yagi.h-net.msu.edu> <31991cfa-e801-b981-4f74-99a37882808c@bitsavers.org> Message-ID: <9bc0194b-62a2-b4cc-c1d1-8cb9ed41f4bb@bitsavers.org> On 9/13/20 3:44 PM, Al Kossow via cctalk wrote: > Like all of the specialized 80's VME boards, it is going to be pretty > much impossible to find software for them today. > You'll note on bitsavers there is almost no documentation on 3rd party VME boards outside of Motorola. They were so specialized, expensive, and sold in such small numbers that not even paper documentation can be found for them. From Aaron.Jackson at nottingham.ac.uk Sun Sep 13 18:17:28 2020 From: Aaron.Jackson at nottingham.ac.uk (Aaron Jackson) Date: Sun, 13 Sep 2020 23:17:28 +0000 Subject: VAX 4000/300 start up / KA670 issues Message-ID: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> Hi I've had a VAX 4000/300 sitting around for the past couple of years. The second time I tried to switch it on there was a bit pop from the power supply. The 12v module of the H7874 PSU is completely dead and despite my best efforts I have not been able to fix it. Tonight I decided to remove that module and just use the PSU to provide the 5v, with -12 and 12v supplied from external supplies. Surprisingly this worked, as long as the 12v rails are up before you turn on the H7874 (so if you have a dead H7874 you might want to try this...). After some messing around with MMJ cables and various serial adapters, I finally got some stuff printing to a terminal (I have abbreviated this slightly because I don't want to type it out. ]] KA670-A V3.4, VMB 2.12 ]] Performing normal system tests. ]] 66..65.. ... 51.. ]] 50..49.. ... 35.. ]] 34..33.. ... 19.. ]] 18..17.. ... 11.. ]] ]] ?5F 2 0F 44 0000 0000 07 ; SUBTEST_5F_0D, DE_SGEC.LIS ]] P1=00000000 P2=00000000 P3=00000000 P4=00000000 P5=00000000 ]] P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] r0=00000054 r1=20084001 r2=00000000 r3=00000000 r4=00000000 ]] r5=1FFFFFFC r6=C0000001 r7=00000000 r8=00004000 EPC=00000000 ]] 10.. ]] ]] ?5C 2 06 FF 0000 0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS ]] P1=00000001 P2=00000000 P3=00000000 P4=00000000 P5=00000000 ]] P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] r0=00000054 r1=0000002E r2=0000005C r3=20140784 r4=2005FFF8 ]] r5=20060028 r6=20065224 r7=20004000 r8=00000000 EPC=00000000 ]] 09..08..07..05..04..03.. ]] Normal operation not possible. ]] ]] >>> It allows me to type at this point but does not appear to do anything with the input. I've looked through the KA670 manual and found a listing of the error codes. 5F = SGEC (Second Generation Ethernet Controller) "loopback_type no_ram_tests" 5C = SHAC (Single Host Adapter Chip) "shac_number" I'm not sure if it is relevant but I removed the TOY battery when I got it to prevent it eating everything. I've not taken apart the console door thing but perhaps it was too late. The SGEC might refer to the ethernet controller installed on that door? If anyone is better at understanding these error messages I'd greatly appreciate any info you could give. Cheers, Aaron P.S. Apologies for the absurd footer appended by my university. You can probably ignore it... The list does not accept mail from my personal mail server for some reason. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From steven at malikoff.com Sun Sep 13 20:44:26 2020 From: steven at malikoff.com (steven at malikoff.com) Date: Mon, 14 Sep 2020 11:44:26 +1000 Subject: What's the secret to LK201 leaf springs? In-Reply-To: References: <61832F1F-57B4-4D50-A336-030677AFD55B@gmail.com> Message-ID: <309cd1c00b3341c3e572e5674b8379e3.squirrel@webmail04.register.com> Tony said > On Sat, Sep 12, 2020 at 6:41 PM Adam Thornton via cctalk > wrote: >> >> I got an LK201 recently that was a little damaged in transit. A couple of the keycap assemblies and their corresponding leaf springs have come off. I can see how the leaf springs fit on the little posts on the keycap assemblies, and I can see where those snap into the board, but what I don?t see is how to get that put together and then keep it together while I turn it over and then get it in place.>> >> Clearly there is some simple trick I am missing. What is it? > > When it was made, those posts were much longer. After fitting the leaf > springs and fitting the unit to the membrane/chassis plate, the posts > were melted and formed over to make a large 'head' that held it all > together (this is commonly called heat staking). > > My guess is that the formed over part has broken off (you might find > some little white disks of plastic, about 1/8" diameter, rattling > about inside the case). Alas I have never found a way to re-fix them. > There's not enough plastic in the housing to drill it out and fit > screws/nuts. There is no way of gluing something to the ends of the > posts that would be strong enough, > > -tony > Perhaps using a 3D printed jig, I would set up the key post in a lathe collet and drill a sub-millimetre hole through the axis. Then glue a sliver of carbon fibre rod in, lastly mill some channels a few thou deep along the outside of the post for binding with a strand of de-braided Kevlar thread to hold the end on. A tiny drop of cyanoacrylate applied with a sharp toothpick keeps the Kevlar in place. The end cap would be drilled with the same drill. I've used this CF+Kevlar method for repairing a number of things where there is not enough surface area for adhesive alone and I am sure the repairs will outlast the items I've fixed. It takes some patience and a need to set up the job reasonably carefully. Steve. From guykd at optusnet.com.au Mon Sep 14 00:27:32 2020 From: guykd at optusnet.com.au (Guy Dunphy) Date: Mon, 14 Sep 2020 15:27:32 +1000 Subject: What's the secret to LK201 leaf springs? In-Reply-To: <61832F1F-57B4-4D50-A336-030677AFD55B@gmail.com> References: Message-ID: <3.0.6.32.20200914152732.014e94a8@mail.optusnet.com.au> At 10:41 AM 12/09/2020 -0700, you wrote: >I got an LK201 recently that was a little damaged in transit. A couple of the keycap assemblies and their corresponding leaf springs have come off. I can see how the leaf springs fit on the little posts on the keycap assemblies, and I can see where those snap into the board, but what I don???t see is how to get that put together and then keep it together while I turn it over and then get it in place. > >Clearly there is some simple trick I am missing. What is it? > >Adam "a couple" ? Heh. I recently bought an old HP 1640B protocol analyzer, very cheap. Turns out some genius had 'lubricated' all the front panel button mechanisms. They are the red-bodied HP 'buckling spring' type, that are heat-staked to the PCB. The 'lubricant' had aged into something with glue-like properties. Also a bit corrosive to PCB traces. I've cut off the melted plastic dots and removed ALL the switches, then disassembled the switches. Still to be carefully cleaned. Then there's the small problem of reattaching 34 switch bodies to the PCB, without enough plastic in the studs to re-heat-stake them. I'm hoping superglue in the PCB holes may work. But the idea of UV-curing Bondic mentioned above sounds appealing. Oh, and 3 of the key switches have broken center shafts too, so I need to find some spare switches. Guy From Aaron.Jackson at nottingham.ac.uk Mon Sep 14 07:36:23 2020 From: Aaron.Jackson at nottingham.ac.uk (Aaron Jackson) Date: Mon, 14 Sep 2020 12:36:23 +0000 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> Message-ID: <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote: > Hi > > I've had a VAX 4000/300 sitting around for the past couple of years. The > second time I tried to switch it on there was a bit pop from the power > supply. The 12v module of the H7874 PSU is completely dead and despite > my best efforts I have not been able to fix it. > > Tonight I decided to remove that module and just use the PSU to provide > the 5v, with -12 and 12v supplied from external supplies. Surprisingly > this worked, as long as the 12v rails are up before you turn on the > H7874 (so if you have a dead H7874 you might want to try this...). > > After some messing around with MMJ cables and various serial adapters, I > finally got some stuff printing to a terminal (I have abbreviated this > slightly because I don't want to type it out. > > ]] KA670-A V3.4, VMB 2.12 > ]] Performing normal system tests. > ]] 66..65.. ... 51.. > ]] 50..49.. ... 35.. > ]] 34..33.. ... 19.. > ]] 18..17.. ... 11.. > ]] > ]] ?5F 2 0F 44 0000 0000 07 ; SUBTEST_5F_0D, DE_SGEC.LIS > ]] P1=00000000 P2=00000000 P3=00000000 P4=00000000 P5=00000000 > ]] P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 > ]] r0=00000054 r1=20084001 r2=00000000 r3=00000000 r4=00000000 > ]] r5=1FFFFFFC r6=C0000001 r7=00000000 r8=00004000 EPC=00000000 > ]] 10.. > ]] > ]] ?5C 2 06 FF 0000 0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS > ]] P1=00000001 P2=00000000 P3=00000000 P4=00000000 P5=00000000 > ]] P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 > ]] r0=00000054 r1=0000002E r2=0000005C r3=20140784 r4=2005FFF8 > ]] r5=20060028 r6=20065224 r7=20004000 r8=00000000 EPC=00000000 > ]] 09..08..07..05..04..03.. > ]] Normal operation not possible. > ]] > ]] >>> > > It allows me to type at this point but does not appear to do anything > with the input. > > I've looked through the KA670 manual and found a listing of the error > codes. > > 5F = SGEC (Second Generation Ethernet Controller) "loopback_type > no_ram_tests" > > 5C = SHAC (Single Host Adapter Chip) "shac_number" > > I'm not sure if it is relevant but I removed the TOY battery when I got > it to prevent it eating everything. I've not taken apart the console > door thing but perhaps it was too late. The SGEC might refer to the > ethernet controller installed on that door? > > If anyone is better at understanding these error messages I'd greatly > appreciate any info you could give. > > Cheers, > Aaron > Never mind. I think these tests can be ignored, and I got rid of the SHAC one by putting the terminator in the right place. The VAX does respond to my keyboard input... when I have the terminal set to the right serial config. Need to figure out how to get it to boot from SCSI. It's picking up my QBUS DHQ11 and DELQA cards fine. I intend to replace the 12v module in the PSU with two small 12v 240v boards and tap into the power coming into the PSU. This seems like a reasonable approach given the nature of the H7874 PSU. Very happy the machine seems to be working! Aaron This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From dave.g4ugm at gmail.com Mon Sep 14 08:07:09 2020 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Mon, 14 Sep 2020 14:07:09 +0100 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> Message-ID: <000501d68a97$f5403950$dfc0abf0$@gmail.com> Aaron, Which SCSI card do you have? These systems are normally DSSI systems not SCSI You should be able to do SHOW DEVICE then BOOT Dave > -----Original Message----- > From: cctalk On Behalf Of Aaron Jackson via > cctalk > Sent: 14 September 2020 13:36 > To: Aaron Jackson ; General Discussion: On- > Topic and Off-Topic Posts > Subject: Re: VAX 4000/300 start up / KA670 issues > > On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote: > > > Hi > > > > I've had a VAX 4000/300 sitting around for the past couple of years. > > The second time I tried to switch it on there was a bit pop from the > > power supply. The 12v module of the H7874 PSU is completely dead and > > despite my best efforts I have not been able to fix it. > > > > Tonight I decided to remove that module and just use the PSU to > > provide the 5v, with -12 and 12v supplied from external supplies. > > Surprisingly this worked, as long as the 12v rails are up before you > > turn on the > > H7874 (so if you have a dead H7874 you might want to try this...). > > > > After some messing around with MMJ cables and various serial adapters, > > I finally got some stuff printing to a terminal (I have abbreviated > > this slightly because I don't want to type it out. > > > > ]] KA670-A V3.4, VMB 2.12 > > ]] Performing normal system tests. > > ]] 66..65.. ... 51.. > > ]] 50..49.. ... 35.. > > ]] 34..33.. ... 19.. > > ]] 18..17.. ... 11.. > > ]] > > ]] ?5F 2 0F 44 0000 0000 07 ; SUBTEST_5F_0D, DE_SGEC.LIS > > ]] P1=00000000 P2=00000000 P3=00000000 P4=00000000 P5=00000000 ]] > > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] > > r0=00000054 r1=20084001 r2=00000000 r3=00000000 r4=00000000 ]] > > r5=1FFFFFFC r6=C0000001 r7=00000000 r8=00004000 EPC=00000000 ]] 10.. > > ]] > > ]] ?5C 2 06 FF 0000 0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS > > ]] P1=00000001 P2=00000000 P3=00000000 P4=00000000 P5=00000000 ]] > > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] > > r0=00000054 r1=0000002E r2=0000005C r3=20140784 r4=2005FFF8 ]] > > r5=20060028 r6=20065224 r7=20004000 r8=00000000 EPC=00000000 ]] > > 09..08..07..05..04..03.. > > ]] Normal operation not possible. > > ]] > > ]] >>> > > > > It allows me to type at this point but does not appear to do anything > > with the input. > > > > I've looked through the KA670 manual and found a listing of the error > > codes. > > > > 5F = SGEC (Second Generation Ethernet Controller) "loopback_type > > no_ram_tests" > > > > 5C = SHAC (Single Host Adapter Chip) "shac_number" > > > > I'm not sure if it is relevant but I removed the TOY battery when I > > got it to prevent it eating everything. I've not taken apart the > > console door thing but perhaps it was too late. The SGEC might refer > > to the ethernet controller installed on that door? > > > > If anyone is better at understanding these error messages I'd greatly > > appreciate any info you could give. > > > > Cheers, > > Aaron > > > > Never mind. I think these tests can be ignored, and I got rid of the SHAC one by > putting the terminator in the right place. > > The VAX does respond to my keyboard input... when I have the terminal set to > the right serial config. > > Need to figure out how to get it to boot from SCSI. It's picking up my QBUS > DHQ11 and DELQA cards fine. > > I intend to replace the 12v module in the PSU with two small 12v 240v boards > and tap into the power coming into the PSU. This seems like a reasonable > approach given the nature of the H7874 PSU. > > Very happy the machine seems to be working! > > Aaron > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please contact the sender and delete the email and attachment. > > Any views or opinions expressed by the author of this email do not necessarily > reflect the views of the University of Nottingham. Email communications with > the University of Nottingham may be monitored where permitted by law. > > > From Aaron.Jackson at nottingham.ac.uk Mon Sep 14 09:02:40 2020 From: Aaron.Jackson at nottingham.ac.uk (Aaron Jackson) Date: Mon, 14 Sep 2020 14:02:40 +0000 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <000501d68a97$f5403950$dfc0abf0$@gmail.com> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> <000501d68a97$f5403950$dfc0abf0$@gmail.com> Message-ID: <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> Hi Dave, In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller because it has compatible centronics sockets. Thinking about the name that was obviously wrong! I have two Emulex UC07, one is spare and the other is in my PDP-11. If I install this into the VAX Q22 bus do you think it will explode or work? Even if this did work it wouldn't be ideal but I'm not sure of any alternatives at the moment. Thanks, Aaron On 14 September 2020 at 14:07 BST, dave.g4ugm at gmail.com wrote: > Aaron, > > Which SCSI card do you have? These systems are normally DSSI systems not > SCSI > You should be able to do SHOW DEVICE then BOOT > > Dave > >> -----Original Message----- >> From: cctalk On Behalf Of Aaron Jackson > via >> cctalk >> Sent: 14 September 2020 13:36 >> To: Aaron Jackson ; General Discussion: > On- >> Topic and Off-Topic Posts >> Subject: Re: VAX 4000/300 start up / KA670 issues >> >> On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote: >> >> > Hi >> > >> > I've had a VAX 4000/300 sitting around for the past couple of years. >> > The second time I tried to switch it on there was a bit pop from the >> > power supply. The 12v module of the H7874 PSU is completely dead and >> > despite my best efforts I have not been able to fix it. >> > >> > Tonight I decided to remove that module and just use the PSU to >> > provide the 5v, with -12 and 12v supplied from external supplies. >> > Surprisingly this worked, as long as the 12v rails are up before you >> > turn on the >> > H7874 (so if you have a dead H7874 you might want to try this...). >> > >> > After some messing around with MMJ cables and various serial adapters, >> > I finally got some stuff printing to a terminal (I have abbreviated >> > this slightly because I don't want to type it out. >> > >> > ]] KA670-A V3.4, VMB 2.12 >> > ]] Performing normal system tests. >> > ]] 66..65.. ... 51.. >> > ]] 50..49.. ... 35.. >> > ]] 34..33.. ... 19.. >> > ]] 18..17.. ... 11.. >> > ]] >> > ]] ?5F 2 0F 44 0000 0000 07 ; SUBTEST_5F_0D, DE_SGEC.LIS >> > ]] P1=00000000 P2=00000000 P3=00000000 P4=00000000 P5=00000000 ]] >> > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] >> > r0=00000054 r1=20084001 r2=00000000 r3=00000000 r4=00000000 ]] >> > r5=1FFFFFFC r6=C0000001 r7=00000000 r8=00004000 EPC=00000000 ]] 10.. >> > ]] >> > ]] ?5C 2 06 FF 0000 0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS >> > ]] P1=00000001 P2=00000000 P3=00000000 P4=00000000 P5=00000000 ]] >> > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] >> > r0=00000054 r1=0000002E r2=0000005C r3=20140784 r4=2005FFF8 ]] >> > r5=20060028 r6=20065224 r7=20004000 r8=00000000 EPC=00000000 ]] >> > 09..08..07..05..04..03.. >> > ]] Normal operation not possible. >> > ]] >> > ]] >>> >> > >> > It allows me to type at this point but does not appear to do anything >> > with the input. >> > >> > I've looked through the KA670 manual and found a listing of the error >> > codes. >> > >> > 5F = SGEC (Second Generation Ethernet Controller) "loopback_type >> > no_ram_tests" >> > >> > 5C = SHAC (Single Host Adapter Chip) "shac_number" >> > >> > I'm not sure if it is relevant but I removed the TOY battery when I >> > got it to prevent it eating everything. I've not taken apart the >> > console door thing but perhaps it was too late. The SGEC might refer >> > to the ethernet controller installed on that door? >> > >> > If anyone is better at understanding these error messages I'd greatly >> > appreciate any info you could give. >> > >> > Cheers, >> > Aaron >> > >> >> Never mind. I think these tests can be ignored, and I got rid of the SHAC > one by >> putting the terminator in the right place. >> >> The VAX does respond to my keyboard input... when I have the terminal set > to >> the right serial config. >> >> Need to figure out how to get it to boot from SCSI. It's picking up my > QBUS >> DHQ11 and DELQA cards fine. >> >> I intend to replace the 12v module in the PSU with two small 12v 240v > boards >> and tap into the power coming into the PSU. This seems like a reasonable >> approach given the nature of the H7874 PSU. >> >> Very happy the machine seems to be working! >> >> Aaron >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please contact the sender and delete the email and attachment. >> >> Any views or opinions expressed by the author of this email do not > necessarily >> reflect the views of the University of Nottingham. Email communications > with >> the University of Nottingham may be monitored where permitted by law. >> >> >> -- Dr Aaron S. Jackson Computer Vision Laboratory School of Computer Science, University of Nottingham ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I will be on leave every Monday and Tuesday until October 2020. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From a.carlini at ntlworld.com Mon Sep 14 09:43:18 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Mon, 14 Sep 2020 15:43:18 +0100 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> <000501d68a97$f5403950$dfc0abf0$@gmail.com> <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> Message-ID: <2132465e-6576-7f6f-d83b-8e63bf84e1d7@ntlworld.com> On 14/09/2020 15:02, Aaron Jackson via cctalk wrote: > Hi Dave, > > In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller > because it has compatible centronics sockets. Thinking about the name > that was obviously wrong! For the future: http://www.bitsavers.org/pdf/dec/qbus/EK-DHQ11-UG-002.pdf :-) I've not seen an octopus cable in a long time. > I have two Emulex UC07, one is spare and the other is in my PDP-11. If I > install this into the VAX Q22 bus do you think it will explode or work? The BA440 Qbus is 22 bits, so that should be fine shouldn't it? I've never tried that combination, so I don't know for sure, but I think the BA440 is QQCD (or whatever the designation is), no serpentine. > Even if this did work it wouldn't be ideal but I'm not sure of any > alternatives at the moment. KDB50 + RA drive? An RA7x would (almost certainly) fit in one of disk bays. You're supposed to use RF disks. I have an RF35 (or maybe two drives) here but I don't know their status. I *think* they're SCSI with an adapter board, and if so I could check the disk status at least. A further alternative would be an HSDx0 + BA350 + StorageWorks disks in caddies. Antonio -- Antonio Carlini antonio at acarlini.com From Aaron.Jackson at nottingham.ac.uk Mon Sep 14 09:48:29 2020 From: Aaron.Jackson at nottingham.ac.uk (Aaron Jackson) Date: Mon, 14 Sep 2020 14:48:29 +0000 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <2132465e-6576-7f6f-d83b-8e63bf84e1d7@ntlworld.com> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> <000501d68a97$f5403950$dfc0abf0$@gmail.com> <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> <2132465e-6576-7f6f-d83b-8e63bf84e1d7@ntlworld.com> Message-ID: <91bmu1s9zya.fsf@mimas.cs.nott.ac.uk> > On 14/09/2020 15:02, Aaron Jackson via cctalk wrote: >> Hi Dave, >> >> In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller >> because it has compatible centronics sockets. Thinking about the name >> that was obviously wrong! > > For the future: > http://www.bitsavers.org/pdf/dec/qbus/EK-DHQ11-UG-002.pdf :-) :) > > I've not seen an octopus cable in a long time. > >> I have two Emulex UC07, one is spare and the other is in my PDP-11. If I >> install this into the VAX Q22 bus do you think it will explode or work? > > > The BA440 Qbus is 22 bits, so that should be fine shouldn't it? I've > never tried that combination, so I don't know for sure, but I think the > BA440 is QQCD (or whatever the designation is), no serpentine. I was fairly sure it would be ok so plugged it in and managed to get into the Emulex configuration menu very quickly. Next step, installing NetBSD :))) > > >> Even if this did work it wouldn't be ideal but I'm not sure of any >> alternatives at the moment. > > > KDB50 + RA drive? An RA7x would (almost certainly) fit in one of disk bays. > > > You're supposed to use RF disks. I have an RF35 (or maybe two drives) > here but I don't know their status. I *think* they're SCSI with an > adapter board, and if so I could check the disk status at least. I will look into this. thanks! Aaron > > > A further alternative would be an HSDx0 + BA350 + StorageWorks disks in > caddies. > > > Antonio -- Dr Aaron S. Jackson Computer Vision Laboratory School of Computer Science, University of Nottingham ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I will be on leave every Monday and Tuesday until October 2020. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From dave.g4ugm at gmail.com Mon Sep 14 10:33:04 2020 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Mon, 14 Sep 2020 16:33:04 +0100 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> <000501d68a97$f5403950$dfc0abf0$@gmail.com> <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> Message-ID: <002701d68aac$571e2650$055a72f0$@gmail.com> Aaron, I believe a UC07 should work in a 4000. The manual says :- http://www.bitsavers.org/pdf/emulex/UC0751001H_UC06_UC07_UC08_Host_Adapter_T echnical_Manual_Nov90.pdf CPU Compatibility The UC07/UC08 is compatible with the Q-Bus used on all DEC LSI-11 arid all DEC MicroVAX II, 3XXX, and 4XXX series computers. You should really use a -III but I think that the only difference is the shielding and cable termination. I would expect the disks to show up as DU2n http://www.bitsavers.org/pdf/dec/vax/4000/EK-337AA-TI-001_VAX_4000_Model_300 _Technical_Information_Mar90.pdf page 1-12. You might need to tweak the q-Bus addresses. Dave > -----Original Message----- > From: Aaron Jackson > Sent: 14 September 2020 15:03 > To: dave.g4ugm at gmail.com > Cc: 'General Discussion: On-Topic and Off-Topic Posts' > > Subject: Re: VAX 4000/300 start up / KA670 issues > > Hi Dave, > > In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller > because it has compatible centronics sockets. Thinking about the name that > was obviously wrong! > > I have two Emulex UC07, one is spare and the other is in my PDP-11. If I install > this into the VAX Q22 bus do you think it will explode or work? > > Even if this did work it wouldn't be ideal but I'm not sure of any alternatives at > the moment. > > Thanks, > Aaron > > > On 14 September 2020 at 14:07 BST, dave.g4ugm at gmail.com wrote: > > > Aaron, > > > > Which SCSI card do you have? These systems are normally DSSI systems > > not SCSI You should be able to do SHOW DEVICE then BOOT > > > > Dave > > > >> -----Original Message----- > >> From: cctalk On Behalf Of Aaron > >> Jackson > > via > >> cctalk > >> Sent: 14 September 2020 13:36 > >> To: Aaron Jackson ; General Discussion: > > On- > >> Topic and Off-Topic Posts > >> Subject: Re: VAX 4000/300 start up / KA670 issues > >> > >> On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote: > >> > >> > Hi > >> > > >> > I've had a VAX 4000/300 sitting around for the past couple of years. > >> > The second time I tried to switch it on there was a bit pop from > >> > the power supply. The 12v module of the H7874 PSU is completely > >> > dead and despite my best efforts I have not been able to fix it. > >> > > >> > Tonight I decided to remove that module and just use the PSU to > >> > provide the 5v, with -12 and 12v supplied from external supplies. > >> > Surprisingly this worked, as long as the 12v rails are up before > >> > you turn on the > >> > H7874 (so if you have a dead H7874 you might want to try this...). > >> > > >> > After some messing around with MMJ cables and various serial > >> > adapters, I finally got some stuff printing to a terminal (I have > >> > abbreviated this slightly because I don't want to type it out. > >> > > >> > ]] KA670-A V3.4, VMB 2.12 > >> > ]] Performing normal system tests. > >> > ]] 66..65.. ... 51.. > >> > ]] 50..49.. ... 35.. > >> > ]] 34..33.. ... 19.. > >> > ]] 18..17.. ... 11.. > >> > ]] > >> > ]] ?5F 2 0F 44 0000 0000 07 ; SUBTEST_5F_0D, DE_SGEC.LIS > >> > ]] P1=00000000 P2=00000000 P3=00000000 P4=00000000 P5=00000000 > ]] > >> > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] > >> > r0=00000054 r1=20084001 r2=00000000 r3=00000000 r4=00000000 ]] > >> > r5=1FFFFFFC r6=C0000001 r7=00000000 r8=00004000 EPC=00000000 ]] > 10.. > >> > ]] > >> > ]] ?5C 2 06 FF 0000 0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS > >> > ]] P1=00000001 P2=00000000 P3=00000000 P4=00000000 P5=00000000 > ]] > >> > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] > >> > r0=00000054 r1=0000002E r2=0000005C r3=20140784 r4=2005FFF8 ]] > >> > r5=20060028 r6=20065224 r7=20004000 r8=00000000 EPC=00000000 ]] > >> > 09..08..07..05..04..03.. > >> > ]] Normal operation not possible. > >> > ]] > >> > ]] >>> > >> > > >> > It allows me to type at this point but does not appear to do > >> > anything with the input. > >> > > >> > I've looked through the KA670 manual and found a listing of the > >> > error codes. > >> > > >> > 5F = SGEC (Second Generation Ethernet Controller) "loopback_type > >> > no_ram_tests" > >> > > >> > 5C = SHAC (Single Host Adapter Chip) "shac_number" > >> > > >> > I'm not sure if it is relevant but I removed the TOY battery when I > >> > got it to prevent it eating everything. I've not taken apart the > >> > console door thing but perhaps it was too late. The SGEC might > >> > refer to the ethernet controller installed on that door? > >> > > >> > If anyone is better at understanding these error messages I'd > >> > greatly appreciate any info you could give. > >> > > >> > Cheers, > >> > Aaron > >> > > >> > >> Never mind. I think these tests can be ignored, and I got rid of the > >> SHAC > > one by > >> putting the terminator in the right place. > >> > >> The VAX does respond to my keyboard input... when I have the terminal > >> set > > to > >> the right serial config. > >> > >> Need to figure out how to get it to boot from SCSI. It's picking up > >> my > > QBUS > >> DHQ11 and DELQA cards fine. > >> > >> I intend to replace the 12v module in the PSU with two small 12v 240v > > boards > >> and tap into the power coming into the PSU. This seems like a > >> reasonable approach given the nature of the H7874 PSU. > >> > >> Very happy the machine seems to be working! > >> > >> Aaron > >> > >> > >> This message and any attachment are intended solely for the addressee > >> and may contain confidential information. If you have received this > >> message in error, please contact the sender and delete the email and > attachment. > >> > >> Any views or opinions expressed by the author of this email do not > > necessarily > >> reflect the views of the University of Nottingham. Email > >> communications > > with > >> the University of Nottingham may be monitored where permitted by law. > >> > >> > >> > > > -- > Dr Aaron S. Jackson > Computer Vision Laboratory > School of Computer Science, University of Nottingham > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~ > I will be on leave every Monday and Tuesday until October 2020. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~ > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please contact the sender and delete the email and attachment. > > Any views or opinions expressed by the author of this email do not necessarily > reflect the views of the University of Nottingham. Email communications with > the University of Nottingham may be monitored where permitted by law. > > > From david at kdbarto.org Mon Sep 14 10:45:11 2020 From: david at kdbarto.org (David Barto) Date: Mon, 14 Sep 2020 08:45:11 -0700 Subject: Seeking "MEGATEK" Sun 3/4 era (?) VME Graphics accelerator information and driver In-Reply-To: <31991cfa-e801-b981-4f74-99a37882808c@bitsavers.org> References: <20200913202829.D889619E69E@yagi.h-net.msu.edu> <31991cfa-e801-b981-4f74-99a37882808c@bitsavers.org> Message-ID: > On Sep 13, 2020, at 3:44 PM, Al Kossow via cctalk wrote: > > On 9/13/20 2:48 PM, null via cctalk wrote: > >> There is no terminal for it. > > Megatek started out making caligraphic displays for DG systems > those evolved into the Wizzard series. I have one with a Unibus > interface. > > They switched to raster in the late 70s eventually moving to > standalone 3D color raster terminals. > > The VME boards were their last gasp as a company as the graphics > terminal market collapsed. > > Like all of the specialized 80's VME boards, it is going to be pretty > much impossible to find software for them today. > > More to the point Megatek (myself and some others) modified the boot ROM?s in the Sun 3/XXX series machines to recognize and use these specialized boards as boot consoles. Technically they should be recognized as cg9(?) video cards if you have the correct boot ROMs. Good luck finding those however. David From ccth6600 at gmail.com Mon Sep 14 11:22:23 2020 From: ccth6600 at gmail.com (Tom Hunter) Date: Tue, 15 Sep 2020 00:22:23 +0800 Subject: Flyback transformer for Televideo TVI-9xx terminal Message-ID: I am looking for replacement flyback transformers for Televideo TVI-912B terminals. The flyback transformer is labelled "KFS-00093" on the actual part and also in the schematic. This same flyback was used in a range of Televideo terminals (TVI-912B, TVI-920, etc). Does anyone know of a source for these? Google found the link below, but the photo looks very different from the actual flyback in the terminal: https://www.tedss.com/2023000453 I confirmed with the supplier that the photo on their website is from the actual part they sell. Unfortunately they don't have a datasheet for the flyback or even a specification sheet. The part is cheap, but they have a US$25 minimum order and then the shipping to Australia is just silly expensive at US$59.10. I could spend US$84.10 just to find out it is the wrong part. Any ideas? Thanks and regards Tom Hunter From Aaron.Jackson at nottingham.ac.uk Mon Sep 14 11:34:51 2020 From: Aaron.Jackson at nottingham.ac.uk (Aaron Jackson) Date: Mon, 14 Sep 2020 16:34:51 +0000 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <002701d68aac$571e2650$055a72f0$@gmail.com> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> <000501d68a97$f5403950$dfc0abf0$@gmail.com> <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> <002701d68aac$571e2650$055a72f0$@gmail.com> Message-ID: <91blfhc9v11.fsf@mimas.cs.nott.ac.uk> Thanks Dave. It does indeed work. I've managed to boot into a NetBSD miniroot with the Emulex UC07 and a scsi2sd, although everything is quite a mess at the moment. https://www.flickr.com/photos/158497991 at N05/50341435063/ https://www.flickr.com/photos/158497991 at N05/50342112766/ Very happy to have this machine running :) Aaron On 14 September 2020 at 16:33 BST, dave.g4ugm at gmail.com wrote: > Aaron, > I believe a UC07 should work in a 4000. The manual says :- > > http://www.bitsavers.org/pdf/emulex/UC0751001H_UC06_UC07_UC08_Host_Adapter_T > echnical_Manual_Nov90.pdf > > CPU Compatibility > The UC07/UC08 is compatible with the Q-Bus used on all DEC LSI-11 arid all > DEC MicroVAX II, 3XXX, and 4XXX series computers. > > You should really use a -III but I think that the only difference is the > shielding and cable termination. I would expect the disks to show up as DU2n > > http://www.bitsavers.org/pdf/dec/vax/4000/EK-337AA-TI-001_VAX_4000_Model_300 > _Technical_Information_Mar90.pdf > > page 1-12. > > You might need to tweak the q-Bus addresses. > > Dave > >> -----Original Message----- >> From: Aaron Jackson >> Sent: 14 September 2020 15:03 >> To: dave.g4ugm at gmail.com >> Cc: 'General Discussion: On-Topic and Off-Topic Posts' >> >> Subject: Re: VAX 4000/300 start up / KA670 issues >> >> Hi Dave, >> >> In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller >> because it has compatible centronics sockets. Thinking about the name that >> was obviously wrong! >> >> I have two Emulex UC07, one is spare and the other is in my PDP-11. If I > install >> this into the VAX Q22 bus do you think it will explode or work? >> >> Even if this did work it wouldn't be ideal but I'm not sure of any > alternatives at >> the moment. >> >> Thanks, >> Aaron >> >> >> On 14 September 2020 at 14:07 BST, dave.g4ugm at gmail.com wrote: >> >> > Aaron, >> > >> > Which SCSI card do you have? These systems are normally DSSI systems >> > not SCSI You should be able to do SHOW DEVICE then BOOT >> > >> > Dave >> > >> >> -----Original Message----- >> >> From: cctalk On Behalf Of Aaron >> >> Jackson >> > via >> >> cctalk >> >> Sent: 14 September 2020 13:36 >> >> To: Aaron Jackson ; General Discussion: >> > On- >> >> Topic and Off-Topic Posts >> >> Subject: Re: VAX 4000/300 start up / KA670 issues >> >> >> >> On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote: >> >> >> >> > Hi >> >> > >> >> > I've had a VAX 4000/300 sitting around for the past couple of years. >> >> > The second time I tried to switch it on there was a bit pop from >> >> > the power supply. The 12v module of the H7874 PSU is completely >> >> > dead and despite my best efforts I have not been able to fix it. >> >> > >> >> > Tonight I decided to remove that module and just use the PSU to >> >> > provide the 5v, with -12 and 12v supplied from external supplies. >> >> > Surprisingly this worked, as long as the 12v rails are up before >> >> > you turn on the >> >> > H7874 (so if you have a dead H7874 you might want to try this...). >> >> > >> >> > After some messing around with MMJ cables and various serial >> >> > adapters, I finally got some stuff printing to a terminal (I have >> >> > abbreviated this slightly because I don't want to type it out. >> >> > >> >> > ]] KA670-A V3.4, VMB 2.12 >> >> > ]] Performing normal system tests. >> >> > ]] 66..65.. ... 51.. >> >> > ]] 50..49.. ... 35.. >> >> > ]] 34..33.. ... 19.. >> >> > ]] 18..17.. ... 11.. >> >> > ]] >> >> > ]] ?5F 2 0F 44 0000 0000 07 ; SUBTEST_5F_0D, DE_SGEC.LIS >> >> > ]] P1=00000000 P2=00000000 P3=00000000 P4=00000000 P5=00000000 >> ]] >> >> > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] >> >> > r0=00000054 r1=20084001 r2=00000000 r3=00000000 r4=00000000 ]] >> >> > r5=1FFFFFFC r6=C0000001 r7=00000000 r8=00004000 EPC=00000000 ]] >> 10.. >> >> > ]] >> >> > ]] ?5C 2 06 FF 0000 0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS >> >> > ]] P1=00000001 P2=00000000 P3=00000000 P4=00000000 P5=00000000 >> ]] >> >> > P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 ]] >> >> > r0=00000054 r1=0000002E r2=0000005C r3=20140784 r4=2005FFF8 ]] >> >> > r5=20060028 r6=20065224 r7=20004000 r8=00000000 EPC=00000000 ]] >> >> > 09..08..07..05..04..03.. >> >> > ]] Normal operation not possible. >> >> > ]] >> >> > ]] >>> >> >> > >> >> > It allows me to type at this point but does not appear to do >> >> > anything with the input. >> >> > >> >> > I've looked through the KA670 manual and found a listing of the >> >> > error codes. >> >> > >> >> > 5F = SGEC (Second Generation Ethernet Controller) "loopback_type >> >> > no_ram_tests" >> >> > >> >> > 5C = SHAC (Single Host Adapter Chip) "shac_number" >> >> > >> >> > I'm not sure if it is relevant but I removed the TOY battery when I >> >> > got it to prevent it eating everything. I've not taken apart the >> >> > console door thing but perhaps it was too late. The SGEC might >> >> > refer to the ethernet controller installed on that door? >> >> > >> >> > If anyone is better at understanding these error messages I'd >> >> > greatly appreciate any info you could give. >> >> > >> >> > Cheers, >> >> > Aaron >> >> > >> >> >> >> Never mind. I think these tests can be ignored, and I got rid of the >> >> SHAC >> > one by >> >> putting the terminator in the right place. >> >> >> >> The VAX does respond to my keyboard input... when I have the terminal >> >> set >> > to >> >> the right serial config. >> >> >> >> Need to figure out how to get it to boot from SCSI. It's picking up >> >> my >> > QBUS >> >> DHQ11 and DELQA cards fine. >> >> >> >> I intend to replace the 12v module in the PSU with two small 12v 240v >> > boards >> >> and tap into the power coming into the PSU. This seems like a >> >> reasonable approach given the nature of the H7874 PSU. >> >> >> >> Very happy the machine seems to be working! >> >> >> >> Aaron >> >> >> >> >> >> This message and any attachment are intended solely for the addressee >> >> and may contain confidential information. If you have received this >> >> message in error, please contact the sender and delete the email and >> attachment. >> >> >> >> Any views or opinions expressed by the author of this email do not >> > necessarily >> >> reflect the views of the University of Nottingham. Email >> >> communications >> > with >> >> the University of Nottingham may be monitored where permitted by law. >> >> >> >> >> >> >> >> >> -- >> Dr Aaron S. Jackson >> Computer Vision Laboratory >> School of Computer Science, University of Nottingham >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ~~~~~~ >> I will be on leave every Monday and Tuesday until October 2020. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ~~~~~~ >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please contact the sender and delete the email and attachment. >> >> Any views or opinions expressed by the author of this email do not > necessarily >> reflect the views of the University of Nottingham. Email communications > with >> the University of Nottingham may be monitored where permitted by law. >> >> >> -- Dr Aaron S. Jackson Computer Vision Laboratory School of Computer Science, University of Nottingham ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I will be on leave every Monday and Tuesday until October 2020. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From billdegnan at gmail.com Mon Sep 14 12:26:27 2020 From: billdegnan at gmail.com (Bill Degnan) Date: Mon, 14 Sep 2020 13:26:27 -0400 Subject: Kennett Classic Anniversary Event and Outdoor Swap 9/26/2020 Message-ID: If you're in the Philadelphia / Baltimore area September 26th, please consider visiting us for our 1 year anniversary / outdoor swap day. We are debuting two new exhibit rooms that day. Because we can admit a limited number of persons inside at a time, we will also run an outdoor swap meet spanning from the outside front door, down the side of the building and into the back parking lot so people can congregate outside. There are a number of outdoor restaurants nearby and we're going to attempt a covid-friendly group dinner afterwards. Swap spaces remain, let me know privately to reserve your place. Kennett Classic is located in Kennett Square, PA. We're fostering a growing local interest in vintage computing. There might be "new stuff" for sale just because there are new-to-the-hobby persons in attendance and we have been publicizing the event locally. For more directions/details see https://www.kennettclassic.com/kennett-classic-in-two-weeks-sept-26-2020/ Thanks Bill 484 732 7041 (shop number) kennettclasic.com From engel at multicores.org Mon Sep 14 08:35:50 2020 From: engel at multicores.org (Michael Engel) Date: Mon, 14 Sep 2020 15:35:50 +0200 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) Message-ID: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Hi, for a planned exhibition, I am thinking of restoring two of the machines to working state again that are in storage here for decades: - A TI Explorer ("Sperry" labeled) and - A Xerox Star (no idea if ours actually ran Interlisp or one of the other OSes for the Star/Dandelion) There is "sen?s dandelion restoration blog" at http://dandelion.sen.cx/ (which seems to be very helpful to test the power supply) and, of course, lots of documents and software on bitsavers. I have quite a bit of experience with TI1500 machines, so the Explorer feels rather familiar, but I have never worked with Xerox machines before. Before I start to disassemble and test the machines, I would be interested to hear about specific problems you might have experienced bringing up one of these two machines, preferably those on the unexpected side. Some things I could not find so far are the mouse and the console cable for the Explorer. It seems that the mouse is related to MouseSystems optical mice used on older Sun/SGI systems (but the interface might be different?). The fiber optics cable for the display (TI part number 2233200 according to the field service manual) might be another problem - if you know any details about this, I would be very interested... Another thing that is also missing is the mouse pad for the three button optical Xerox mouse. Is it possible that an optical mouse pad for Sun/SGI machines is compatible? Best wishes, ??? Michael From aek at bitsavers.org Mon Sep 14 09:00:53 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 14 Sep 2020 07:00:53 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: <3331b54b-560f-0c92-d169-3b2f0b969d2a@bitsavers.org> On 9/14/20 6:35 AM, Michael Engel via cctech wrote: > Hi, > > for a planned exhibition, I am thinking of restoring two of the machines to working state again that are in storage here for decades: > > - A TI Explorer ("Sperry" labeled) > and > - A Xerox Star (no idea if ours actually ran Interlisp or one of the other OSes for the Star/Dandelion) > Best people to talk to are Josh Dersch and Ian Finder From derschjo at gmail.com Mon Sep 14 11:00:48 2020 From: derschjo at gmail.com (Josh Dersch) Date: Mon, 14 Sep 2020 09:00:48 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: On Mon, Sep 14, 2020 at 6:35 AM Michael Engel via cctech < cctech at classiccmp.org> wrote: > Hi, > > for a planned exhibition, I am thinking of restoring two of the machines > to working state again that are in storage here for decades: > > - A TI Explorer ("Sperry" labeled) > and > - A Xerox Star (no idea if ours actually ran Interlisp or one of the > other OSes for the Star/Dandelion) > > There is "sen?s dandelion restoration blog" at http://dandelion.sen.cx/ > (which seems to be very helpful to test the power supply) and, of > course, lots of documents and software on bitsavers. I have quite a bit > of experience with TI1500 machines, so the Explorer feels rather > familiar, but I have never worked with Xerox machines before. > > Before I start to disassemble and test the machines, I would be > interested to hear about specific problems you might have experienced > bringing up one of these two machines, preferably those on the > unexpected side. > > Some things I could not find so far are the mouse and the console cable > for the Explorer. It seems that the mouse is related to MouseSystems > optical mice used on older Sun/SGI systems (but the interface might be > different?). The fiber optics cable for the display (TI part number > 2233200 according to the field service manual) might be another problem > - if you know any details about this, I would be very interested... > > Another thing that is also missing is the mouse pad for the three button > optical Xerox mouse. Is it possible that an optical mouse pad for > Sun/SGI machines is compatible? > > Best wishes, > Michael > > I've restored a Star/1108 (and wrote a Star emulator) and am in the middle of an Explorer restoration, I'm happy to help out where I can. I'd recommend picking up an MFM Emulator (https://www.pdp8.net/mfm/mfm.shtml) along with the SA1000 adapter for same, for use with the Star. The original disks are getting more difficult to keep running, and it's also a lot more convenient for switching between different operating systems, etc. Remove the sound-deadening foam from the panels of the system, it's getting crumbly and isn't going to do you any favors to leave it in place. I've found the power supplies to be fairly reliable. One issue is weak picture tubes in the displays -- the monitors are powered on with the system and have no separate off switch, so they tended to get a lot of hours put on them. We had good luck with a tube rejuvenator on the one we restored at LCM. The Star mouse pad can be recreated with a laser printer (I've used this: http://www.digibarn.com/collections/devices/xerox-mousepad/index.html, and there's a postscript file floating around out there...). Or any surface with a fine pattern on it seems to work pretty well; I was able to make it work on a speckled countertop and the pant leg of my jeans at one point. It's a lot more forgiving than the Sun mice which need the fixed grid of the metal mouse pads. For the Explorer, there are a number of r fa line filter caps in the system, on the power supply board as well as on a separate board near the rear of the chassis. I suggest replacing these immediately as they like to let out smoke. The optical cable is extremely rare and despite some valiant efforts we haven't found an equivalent, or new-old-stock replacements. A friend of mine is working on retrofitting modern optics, and has made some great progress. The mouse is indeed a standard Mouse Systems, I'm missing mine at the moment and haven't yet gotten to the point of adapting a mouse to replace it. I suspect it's equivalent to the M2 used on the Sun-2 and LMI Lambda systems. Media for the Explorer is another question that I'm hoping to answer soon. There are disk images from the Meroko emulator but my understanding is that they are incomplete. Bitsavers has QIC tape images but I have yet to try them. The interface on the Explorer is SCSI but I haven't had luck booting it from a SCSI2SD w/Meroko images loaded. The disk boxes contain an Emulex SCSI->MFM bridge, so use of Dave's MFM emulator might make sense here as well. If you have disks in your Explorer, let me know -- capturing an image of their contents would be extremely useful, and the original Maxtor drives are not long for this world. Hope that helps a bit, happy to answer any questions... or try anyway. - Josh From aek at bitsavers.org Mon Sep 14 12:02:37 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 14 Sep 2020 10:02:37 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: <22fb0275-23c6-cadf-5df8-1839c0d28320@bitsavers.org> On 9/14/20 9:00 AM, Josh Dersch via cctech wrote: > One issue is weak picture > tubes in the displays -- the monitors are powered on with the system and > have no separate off switch, so they tended to get a lot of hours put on > them. We had good luck with a tube rejuvenator on the one we restored at > LCM. > I found my copies of the Ball HD series service manuals, I'll try to get them uploaded today. Xerox used them in the original expansion foam cased 8010 monitors. The ones Fuji/Xerox used that are in the smaller plastic cases are more reliable, but I don't have any documentation for those. From aek at bitsavers.org Mon Sep 14 12:38:32 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 14 Sep 2020 10:38:32 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: <37cb594a-1bc8-5a27-5d59-81c9b24a57e2@bitsavers.org> On 9/14/20 9:00 AM, Josh Dersch via cctalk wrote: > Media for the Explorer is another question that I'm hoping to answer soon. > There are disk images from the Meroko emulator but my understanding is that > they are incomplete. Bitsavers has QIC tape images but I have yet to try > them. The interface on the Explorer is SCSI but I haven't had luck booting > it from a SCSI2SD w/Meroko images loaded. The disk boxes contain an Emulex > SCSI->MFM bridge, so use of Dave's MFM emulator might make sense here as > well. one thing to be aware of is Explorer disks have 256 byte sectors, as I remember From glen.slick at gmail.com Mon Sep 14 14:05:46 2020 From: glen.slick at gmail.com (Glen Slick) Date: Mon, 14 Sep 2020 12:05:46 -0700 Subject: VAX 4000/300 start up / KA670 issues In-Reply-To: <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> References: <91bsgbl9shk.fsf@mimas.cs.nott.ac.uk> <91br1r4a62h.fsf@mimas.cs.nott.ac.uk> <000501d68a97$f5403950$dfc0abf0$@gmail.com> <91bpn6oa22n.fsf@mimas.cs.nott.ac.uk> Message-ID: On Mon, Sep 14, 2020 at 10:08 AM Aaron Jackson via cctalk wrote: > > Hi Dave, > > In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller > because it has compatible centronics sockets. Thinking about the name > that was obviously wrong! If it is a quad wide S-handle card with two 50-pin connectors it would be an M3118 CXY08. The M3107 DHQ11 is a dual wide card with two 40-pin connectors and the M3104 DHV11 is a quad wide card with two 40-pin connectors. The M3118 CXY08 is functionally equivalent to the M3107 DHQ11. The M3118 CXY08 interfaces to two 4-port breakout cables (half an octopus?). There is also the 16-port M3118 CXA16 quad wide S-handle card with two 36-pin connectors. Those interface to the 8-port H3104 "harmonica" MMJ blocks without modem control lines. From aek at bitsavers.org Mon Sep 14 14:24:21 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 14 Sep 2020 12:24:21 -0700 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs Message-ID: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> I just bought one of these thinking it ran off 110, but it uses a 3 pin wall wart. Does anyone have one of these and could tell me the voltages it supplies. From ian.finder at gmail.com Mon Sep 14 13:34:21 2020 From: ian.finder at gmail.com (null) Date: Mon, 14 Sep 2020 11:34:21 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: Message-ID: <922B8C40-784A-4A19-935E-5CC6FA60228A@gmail.com> Regarding the mouse- it is a black Mouse Systems optical mouse, terminated in a two row IDC connector. If desired, I can take internal pictures and send along the pinout. Let me know. > On Sep 14, 2020, at 09:01, Josh Dersch via cctech wrote: > > ?On Mon, Sep 14, 2020 at 6:35 AM Michael Engel via cctech < > cctech at classiccmp.org> wrote: > >> Hi, >> >> for a planned exhibition, I am thinking of restoring two of the machines >> to working state again that are in storage here for decades: >> >> - A TI Explorer ("Sperry" labeled) >> and >> - A Xerox Star (no idea if ours actually ran Interlisp or one of the >> other OSes for the Star/Dandelion) >> >> There is "sen?s dandelion restoration blog" at http://dandelion.sen.cx/ >> (which seems to be very helpful to test the power supply) and, of >> course, lots of documents and software on bitsavers. I have quite a bit >> of experience with TI1500 machines, so the Explorer feels rather >> familiar, but I have never worked with Xerox machines before. >> >> Before I start to disassemble and test the machines, I would be >> interested to hear about specific problems you might have experienced >> bringing up one of these two machines, preferably those on the >> unexpected side. >> >> Some things I could not find so far are the mouse and the console cable >> for the Explorer. It seems that the mouse is related to MouseSystems >> optical mice used on older Sun/SGI systems (but the interface might be >> different?). The fiber optics cable for the display (TI part number >> 2233200 according to the field service manual) might be another problem >> - if you know any details about this, I would be very interested... >> >> Another thing that is also missing is the mouse pad for the three button >> optical Xerox mouse. Is it possible that an optical mouse pad for >> Sun/SGI machines is compatible? >> >> Best wishes, >> Michael >> >> > I've restored a Star/1108 (and wrote a Star emulator) and am in the middle > of an Explorer restoration, I'm happy to help out where I can. > > I'd recommend picking up an MFM Emulator (https://www.pdp8.net/mfm/mfm.shtml) > along with the SA1000 adapter for same, for use with the Star. The > original disks are getting more difficult to keep running, and it's also a > lot more convenient for switching between different operating systems, etc. > > Remove the sound-deadening foam from the panels of the system, it's getting > crumbly and isn't going to do you any favors to leave it in place. I've > found the power supplies to be fairly reliable. One issue is weak picture > tubes in the displays -- the monitors are powered on with the system and > have no separate off switch, so they tended to get a lot of hours put on > them. We had good luck with a tube rejuvenator on the one we restored at > LCM. > > The Star mouse pad can be recreated with a laser printer (I've used this: > http://www.digibarn.com/collections/devices/xerox-mousepad/index.html, and > there's a postscript file floating around out there...). Or any surface > with a fine pattern on it seems to work pretty well; I was able to make it > work on a speckled countertop and the pant leg of my jeans at one point. > It's a lot more forgiving than the Sun mice which need the fixed grid of > the metal mouse pads. > > For the Explorer, there are a number of r fa line filter caps in the > system, on the power supply board as well as on a separate board near the > rear of the chassis. I suggest replacing these immediately as they like to > let out smoke. The optical cable is extremely rare and despite some > valiant efforts we haven't found an equivalent, or new-old-stock > replacements. A friend of mine is working on retrofitting modern optics, > and has made some great progress. The mouse is indeed a standard Mouse > Systems, I'm missing mine at the moment and haven't yet gotten to the point > of adapting a mouse to replace it. I suspect it's equivalent to the M2 > used on the Sun-2 and LMI Lambda systems. > > Media for the Explorer is another question that I'm hoping to answer soon. > There are disk images from the Meroko emulator but my understanding is that > they are incomplete. Bitsavers has QIC tape images but I have yet to try > them. The interface on the Explorer is SCSI but I haven't had luck booting > it from a SCSI2SD w/Meroko images loaded. The disk boxes contain an Emulex > SCSI->MFM bridge, so use of Dave's MFM emulator might make sense here as > well. > > If you have disks in your Explorer, let me know -- capturing an image of > their contents would be extremely useful, and the original Maxtor drives > are not long for this world. > > Hope that helps a bit, happy to answer any questions... or try anyway. > - Josh From engel at multicores.org Mon Sep 14 14:39:08 2020 From: engel at multicores.org (Michael Engel) Date: Mon, 14 Sep 2020 21:39:08 +0200 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <922B8C40-784A-4A19-935E-5CC6FA60228A@gmail.com> References: <922B8C40-784A-4A19-935E-5CC6FA60228A@gmail.com> Message-ID: <08BD816A-1287-4D2A-A3BE-7E143281A5A2@multicores.org> Hi, thanks Ian - I think I found the pinout, it was hidden in TI's Display Unit General Description (http://bitsavers.org/pdf/ti/explorer/2243151-0001A_displ_Jun86.pdf), Fig. 4-6 - not in the Field Service Manual where I expected it... The mouse has a simple quadrature-encoded output (like Atari ST/Amiga mice) on a 9-pin SUB-D style connector. Of course, the pinout is different, for the Explorer it is: 1 - +5V DC 250mA 2 - XA 3 - XB 4 - YA 5 - YB 6 - left key (CLKEY-) - so active low buttons, I assume 7 - middle key (CMKEY-) 8 - right key (CRKEY-) 9 - signal/power ground So it should be easy to build one in case I can't find the original one. It seems that there was also a later non-optical mouse version that looked similar to early Genius PC mice. -- Michael > On 14 Sep 2020, at 20:34, null wrote: > > Regarding the mouse- it is a black Mouse Systems optical mouse, terminated in a two row IDC connector. > > If desired, I can take internal pictures and send along the pinout. Let me know. > >> On Sep 14, 2020, at 09:01, Josh Dersch via cctech wrote: >> >> ?On Mon, Sep 14, 2020 at 6:35 AM Michael Engel via cctech < >> cctech at classiccmp.org> wrote: >> >>> Hi, >>> >>> for a planned exhibition, I am thinking of restoring two of the machines >>> to working state again that are in storage here for decades: >>> >>> - A TI Explorer ("Sperry" labeled) >>> and >>> - A Xerox Star (no idea if ours actually ran Interlisp or one of the >>> other OSes for the Star/Dandelion) >>> >>> There is "sen?s dandelion restoration blog" at http://dandelion.sen.cx/ >>> (which seems to be very helpful to test the power supply) and, of >>> course, lots of documents and software on bitsavers. I have quite a bit >>> of experience with TI1500 machines, so the Explorer feels rather >>> familiar, but I have never worked with Xerox machines before. >>> >>> Before I start to disassemble and test the machines, I would be >>> interested to hear about specific problems you might have experienced >>> bringing up one of these two machines, preferably those on the >>> unexpected side. >>> >>> Some things I could not find so far are the mouse and the console cable >>> for the Explorer. It seems that the mouse is related to MouseSystems >>> optical mice used on older Sun/SGI systems (but the interface might be >>> different?). The fiber optics cable for the display (TI part number >>> 2233200 according to the field service manual) might be another problem >>> - if you know any details about this, I would be very interested... >>> >>> Another thing that is also missing is the mouse pad for the three button >>> optical Xerox mouse. Is it possible that an optical mouse pad for >>> Sun/SGI machines is compatible? >>> >>> Best wishes, >>> Michael >>> >>> >> I've restored a Star/1108 (and wrote a Star emulator) and am in the middle >> of an Explorer restoration, I'm happy to help out where I can. >> >> I'd recommend picking up an MFM Emulator (https://www.pdp8.net/mfm/mfm.shtml) >> along with the SA1000 adapter for same, for use with the Star. The >> original disks are getting more difficult to keep running, and it's also a >> lot more convenient for switching between different operating systems, etc. >> >> Remove the sound-deadening foam from the panels of the system, it's getting >> crumbly and isn't going to do you any favors to leave it in place. I've >> found the power supplies to be fairly reliable. One issue is weak picture >> tubes in the displays -- the monitors are powered on with the system and >> have no separate off switch, so they tended to get a lot of hours put on >> them. We had good luck with a tube rejuvenator on the one we restored at >> LCM. >> >> The Star mouse pad can be recreated with a laser printer (I've used this: >> http://www.digibarn.com/collections/devices/xerox-mousepad/index.html, and >> there's a postscript file floating around out there...). Or any surface >> with a fine pattern on it seems to work pretty well; I was able to make it >> work on a speckled countertop and the pant leg of my jeans at one point. >> It's a lot more forgiving than the Sun mice which need the fixed grid of >> the metal mouse pads. >> >> For the Explorer, there are a number of r fa line filter caps in the >> system, on the power supply board as well as on a separate board near the >> rear of the chassis. I suggest replacing these immediately as they like to >> let out smoke. The optical cable is extremely rare and despite some >> valiant efforts we haven't found an equivalent, or new-old-stock >> replacements. A friend of mine is working on retrofitting modern optics, >> and has made some great progress. The mouse is indeed a standard Mouse >> Systems, I'm missing mine at the moment and haven't yet gotten to the point >> of adapting a mouse to replace it. I suspect it's equivalent to the M2 >> used on the Sun-2 and LMI Lambda systems. >> >> Media for the Explorer is another question that I'm hoping to answer soon. >> There are disk images from the Meroko emulator but my understanding is that >> they are incomplete. Bitsavers has QIC tape images but I have yet to try >> them. The interface on the Explorer is SCSI but I haven't had luck booting >> it from a SCSI2SD w/Meroko images loaded. The disk boxes contain an Emulex >> SCSI->MFM bridge, so use of Dave's MFM emulator might make sense here as >> well. >> >> If you have disks in your Explorer, let me know -- capturing an image of >> their contents would be extremely useful, and the original Maxtor drives >> are not long for this world. >> >> Hope that helps a bit, happy to answer any questions... or try anyway. >> - Josh From cclist at sydex.com Mon Sep 14 15:25:58 2020 From: cclist at sydex.com (Chuck Guzis) Date: Mon, 14 Sep 2020 13:25:58 -0700 Subject: Old tape files needing review Message-ID: Folks, I've got a fair amount of what would be classified as public domain tape data from old customer jobs wandering around. I don't have the time to peruse it in detail and was wondering if someone would like to take a stab at a sample and perhaps volunteer for the rest. Much of this is from university archivists whose job it was to archive all of the unlabeled or private tapes that they found. I doubt that said folks know what to make of the data. At any rate, here's a sample from a Unix (probably V7) tar-ed up: https://app.box.com/s/htvxd534gvbccoajugfp01ndmfeevxt4 The original appears to be cpio-ed. I'll leave it up for a week. --Chuck From paulkoning at comcast.net Mon Sep 14 15:32:33 2020 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 14 Sep 2020 16:32:33 -0400 Subject: Old tape files needing review In-Reply-To: References: Message-ID: > On Sep 14, 2020, at 4:25 PM, Chuck Guzis via cctalk wrote: > > Folks, > > I've got a fair amount of what would be classified as public domain tape > data from old customer jobs wandering around. Out of curiosity, why would you classify it as public domain data? It's certainly possible, but I've seen that term misapplied at times. paul From imp at bsdimp.com Mon Sep 14 15:56:39 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 14 Sep 2020 14:56:39 -0600 Subject: Old tape files needing review In-Reply-To: References: Message-ID: On Mon, Sep 14, 2020 at 2:26 PM Chuck Guzis via cctalk < cctalk at classiccmp.org> wrote: > Folks, > > I've got a fair amount of what would be classified as public domain tape > data from old customer jobs wandering around. I don't have the time to > peruse it in detail and was wondering if someone would like to take a > stab at a sample and perhaps volunteer for the rest. > > Much of this is from university archivists whose job it was to archive > all of the unlabeled or private tapes that they found. I doubt that > said folks know what to make of the data. > > At any rate, here's a sample from a Unix (probably V7) tar-ed up: > > https://app.box.com/s/htvxd534gvbccoajugfp01ndmfeevxt4 > > The original appears to be cpio-ed. > Looks to be more like a USENIX tape based on the directory names... Are your archives online, or is it a bunch of tapes still? Warner From imp at bsdimp.com Mon Sep 14 15:58:32 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 14 Sep 2020 14:58:32 -0600 Subject: Old tape files needing review In-Reply-To: References: Message-ID: On Mon, Sep 14, 2020 at 2:56 PM Warner Losh wrote: > > > On Mon, Sep 14, 2020 at 2:26 PM Chuck Guzis via cctalk < > cctalk at classiccmp.org> wrote: > >> Folks, >> >> I've got a fair amount of what would be classified as public domain tape >> data from old customer jobs wandering around. I don't have the time to >> peruse it in detail and was wondering if someone would like to take a >> stab at a sample and perhaps volunteer for the rest. >> >> Much of this is from university archivists whose job it was to archive >> all of the unlabeled or private tapes that they found. I doubt that >> said folks know what to make of the data. >> >> At any rate, here's a sample from a Unix (probably V7) tar-ed up: >> >> https://app.box.com/s/htvxd534gvbccoajugfp01ndmfeevxt4 >> >> The original appears to be cpio-ed. >> > > Looks to be more like a USENIX tape based on the directory names... > Maybe the 1980 USENIX tape, based on the listings and what's in the TUHS archives... Are your archives online, or is it a bunch of tapes still? > Warner From paulkoning at comcast.net Mon Sep 14 16:26:34 2020 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 14 Sep 2020 17:26:34 -0400 Subject: RSTS/E patches Message-ID: I previously created a Github repository for various DEC things, including updated DECnet/E utilities. I thought that the RSTS patches I had posted in the past were there also, but that wasn't the case. I've added a "patches" subdirectory, which contains the patches I have collected. I just added a new one, which fixes a bug encountered when running SIMH set to be an 11/94. In that case (and possibly some other similar variations) RSTS tries to figure out the line frequency and gets it wrong because SIMH executes much faster. https://github.com/pkoning2/decstuff is the repository. paul From tony.nicholson at computer.org Mon Sep 14 17:09:37 2020 From: tony.nicholson at computer.org (Tony Nicholson) Date: Tue, 15 Sep 2020 08:09:37 +1000 Subject: [HECnet] RSTS/E patches In-Reply-To: References: Message-ID: On Tue, Sep 15, 2020 at 7:28 AM Paul Koning wrote: > I previously created a Github repository for various DEC things, including > updated DECnet/E utilities. I thought that the RSTS patches I had posted > in the past were there also, but that wasn't the case. > > I've added a "patches" subdirectory, which contains the patches I have > collected. I just added a new one, which fixes a bug encountered when > running SIMH set to be an 11/94. In that case (and possibly some other > similar variations) RSTS tries to figure out the line frequency and gets it > wrong because SIMH executes much faster. > > https://github.com/pkoning2/decstuff is the repository. > > paul > > Thanks for this Paul. There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1 under SIMH (posted to the SIMH mailing list in May 2016). You'll find it and the NSP1.TXT describing it in my repository at https://github.com/agn453/RSTS-E in the "decnete" subdirectory. I've recently joined HECnet and will be making some of my updates available soon. Tony -- Tony Nicholson From jbdigriz at dragonsweb.org Mon Sep 14 22:44:11 2020 From: jbdigriz at dragonsweb.org (James B DiGriz) Date: Mon, 14 Sep 2020 23:44:11 -0400 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: <20200914234411.3c9fd8d7@dragonsweb.org> On Mon, 14 Sep 2020 15:35:50 +0200 Michael Engel via cctalk wrote: > Hi, > > for a planned exhibition, I am thinking of restoring two of the > machines to working state again that are in storage here for decades: > > - A TI Explorer ("Sperry" labeled) > and > - A Xerox Star (no idea if ours actually ran Interlisp or one of the > other OSes for the Star/Dandelion) Awesome. I hope there will be online coverage of the exhibition. > Some things I could not find so far are the mouse and the console > cable for the Explorer. It seems that the mouse is related to > MouseSystems optical mice used on older Sun/SGI systems (but the > interface might be different?). The fiber optics cable for the > display (TI part number 2233200 according to the field service > manual) might be another problem > - if you know any details about this, I would be very interested... > This is the same part # listed for the 990, and I would think, lacking documentation on them, the BS600 and BS800 machines, if using the CI404 comm board. I don't know how common those were. My college only started using them after a lightning strike took out some machines through one or more serial links, iirc. But that may broaden your search. From the CI403/CI404 manual (http://bitsavers.org/pdf/ti/990/datacomm/2263897_9701B_CI403_Nov83.pdf): 2233200-0001 Standard duplex fiber-optic cable, 15m 2233201-0002 Fiber-optic extension cable, 60m 2233201-0003 Fiber-optic extension cable, 150m 2233201-0004 Fiber-optic extension cable, 300m 2233210-0001 Converter module kit, includes: Converter, Power Module, and Power Cord. The extension cables include a connector for connectin 2 cables. I may have some more information on the mouse and maybe some cable specs soon. Talking to some people who likely know. jbdigriz From jbdigriz at dragonsweb.org Mon Sep 14 23:04:13 2020 From: jbdigriz at dragonsweb.org (James B DiGriz) Date: Tue, 15 Sep 2020 00:04:13 -0400 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <20200914234411.3c9fd8d7@dragonsweb.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> Message-ID: <20200915000413.586f966c@dragonsweb.org> > From the CI403/CI404 manual > (http://bitsavers.org/pdf/ti/990/datacomm/2263897_9701B_CI403_Nov83.pdf): > You can try http://bitsavers.org/pdf/ti/990/datacomm/2263897-9701B_CI403_Nov83.pdf, too. It may work a little better. jbdigriz From engel at multicores.org Mon Sep 14 15:04:09 2020 From: engel at multicores.org (Michael Engel) Date: Mon, 14 Sep 2020 22:04:09 +0200 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: Hi Josh, whow, seems it's my lucky day :) - thanks a lot for the offer! > On 14 Sep 2020, at 18:00, Josh Dersch wrote: > > I've restored a Star/1108 (and wrote a Star emulator) and am in the middle of an Explorer restoration, I'm happy to help out where I can. > > I'd recommend picking up an MFM Emulator (https://www.pdp8.net/mfm/mfm.shtml) along with the SA1000 adapter for same, for use with the Star. The original disks are getting more difficult to keep running, and it's also a lot more convenient for switching between different operating systems, etc. That's definitely a good idea - and good to know that the disks are simply MFM and not some more exotic standard such as SMD. > Remove the sound-deadening foam from the panels of the system, it's getting crumbly and isn't going to do you any favors to leave it in place. Yeah, I remember the TI1500s also had that problem and the stuff is pretty nasty. > I've found the power supplies to be fairly reliable. Good to know - analog power electronics is not really my area of expertise, but we have a competent electronics department nearby that can probably help just in case. > One issue is weak picture tubes in the displays -- the monitors are powered on with the system and have no separate off switch, so they tended to get a lot of hours put on them. We had good luck with a tube rejuvenator on the one we restored at LCM. Yes, the picture seems to be burnt in quite a bit in all of the displays (we have three systems here). Not sure if I can find a tube rejuvenator here in Trondheim, but you never know. > The Star mouse pad can be recreated with a laser printer (I've used this: http://www.digibarn.com/collections/devices/xerox-mousepad/index.html, and there's a postscript file floating around out there...). Or any surface with a fine pattern on it seems to work pretty well; I was able to make it work on a speckled countertop and the pant leg of my jeans at one point. It's a lot more forgiving than the Sun mice which need the fixed grid of the metal mouse pads. Great, thanks! > For the Explorer, there are a number of r fa line filter caps in the system, on the power supply board as well as on a separate board near the rear of the chassis. I suggest replacing these immediately as they like to let out smoke. Good to know, I'll take care. The roller-type fans (hope that's the correct English term) also made some problems at least on the large TI1500 system back in the '90s, the Explorer should use the identical chassis. > The optical cable is extremely rare and despite some valiant efforts we haven't found an equivalent, or new-old-stock replacements. A friend of mine is working on retrofitting modern optics, and has made some great progress. It seems that the TI931 terminals also had a fiber optics option and used the same cable (http://bitsavers.org/pdf/ti/terminal/crt/2229228-0001A_Model_931_Video_Display_Terminal_General_Description_Dec83.pdf) - but I've never seen a 931 using that option. So that won't make the cable easier to find. > The mouse is indeed a standard Mouse Systems, I'm missing mine at the moment and haven't yet gotten to the point of adapting a mouse to replace it. I suspect it's equivalent to the M2 used on the Sun-2 and LMI Lambda systems. Hm, on some photos I found the Explorer mouse looks identical to the Sun-2 mice (black case with white buttons). However, the Sun-2 (just checked the schematics on bitsavers) already used a serial interface (via a Z8530 SCC) to connect to the mouse, the Explorer (see my other post with the pinout I found) seems to use quadrature encoding. But maybe there have been different options for the Explorer. > Media for the Explorer is another question that I'm hoping to answer soon. There are disk images from the Meroko emulator but my understanding is that they are incomplete. Bitsavers has QIC tape images but I have yet to try them. The interface on the Explorer is SCSI but I haven't had luck booting it from a SCSI2SD w/Meroko images loaded. The disk boxes contain an Emulex SCSI->MFM bridge, so use of Dave's MFM emulator might make sense here as well. I think the firmware on the NUPI-2 NuBus disk/tape controllers (this has its own 68000 CPU) speaks a pre-standardisation SCSI protocol variant (something closer to the original SASI, I think). The TI1500 used Imprimis/CDC WREN 670 MB disks (probably WREN VFH 94181-702) by default IIRC - and those were the only disks (of that size) that worked reliably on the 1500. I assume the NUPI-2 in the Explorer is identical, so that might be the problem with SCSI2SD. We have a number of the disk enclosures, so I hope that some of the disks still work. > If you have disks in your Explorer, let me know -- capturing an image of their contents would be extremely useful, and the original Maxtor drives are not long for this world. We have four machines with drives, I'll definitely do an image of all of the disks first and will also check if I can find some install tapes. > Hope that helps a bit, happy to answer any questions... or try anyway. Thanks a lot - the machines will definitely keep me busy in the upcoming rainy weekends and evenings... Best wishes, Michael From engel at multicores.org Mon Sep 14 17:15:53 2020 From: engel at multicores.org (Michael Engel) Date: Tue, 15 Sep 2020 00:15:53 +0200 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <08BD816A-1287-4D2A-A3BE-7E143281A5A2@multicores.org> References: <922B8C40-784A-4A19-935E-5CC6FA60228A@gmail.com> <08BD816A-1287-4D2A-A3BE-7E143281A5A2@multicores.org> Message-ID: Another update on the Explorer mouse... > On 14 Sep 2020, at 21:39, Michael Engel via cctech wrote: > > So it should be easy to build one in case I can't find the original one. It seems that there was > also a later non-optical mouse version that looked similar to early Genius PC mice. In the back of the Field Service Manual (http://bitsavers.org/pdf/ti/explorer/2243131-0001_ExplFieldMaint.pdf), the non-optical mouse is described (p. 9DT_1-02) and a reference to Logitech's Logimouse-P7 is given: http://bitsavers.org/pdf/logitech/P7-3F_quadrature/ -- Michael From djg at pdp8online.com Mon Sep 14 20:12:22 2020 From: djg at pdp8online.com (David Gesswein) Date: Mon, 14 Sep 2020 21:12:22 -0400 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: <20200915011222.GA10747@hugin3> On Mon, Sep 14, 2020 at 03:35:50PM +0200, Michael Engel wrote: > > Before I start to disassemble and test the machines, I would be interested > to hear about specific problems you might have experienced bringing up one > of these two machines, preferably those on the unexpected side. > I recently worked on getting a Xerox Star running. https://lists.vcfed.org/pipermail/vcf-midatlantic/2020-August/018468.html Others finished getting it running last weekend. If it has a Quantum Q2040 the heads will likely be glued in place by a deteriorating rubber stop. The page above has link to how I delt with it to recover the drive contents. Some also have dry bearings. We decided to use a drive emulator for now using the Darkstar Viewpoint disk image. Also check the voltage drop on the +5.2 under load discussed in the page linked to. > Another thing that is also missing is the mouse pad for the three button > optical Xerox mouse. Is it possible that an optical mouse pad for Sun/SGI > machines is compatible? > You can print one http://www.digibarn.com/collections/devices/xerox-mousepad/index.html From w2hx at w2hx.com Tue Sep 15 08:20:27 2020 From: w2hx at w2hx.com (W2HX) Date: Tue, 15 Sep 2020 13:20:27 +0000 Subject: [HECnet] RSTS/E patches In-Reply-To: References: Message-ID: Are these patches discussed below only for patching SIMH to fix problems with it? Or are these fixes that are for actual PDP hardware implementations of RSTS? -----Original Message----- From: cctalk On Behalf Of Tony Nicholson via cctalk Sent: Monday, September 14, 2020 6:10 PM To: hecnet at update.uu.se Cc: cctalk at classiccmp.org Subject: Re: [HECnet] RSTS/E patches On Tue, Sep 15, 2020 at 7:28 AM Paul Koning wrote: > I previously created a Github repository for various DEC things, > including updated DECnet/E utilities. I thought that the RSTS patches > I had posted in the past were there also, but that wasn't the case. > > I've added a "patches" subdirectory, which contains the patches I have > collected. I just added a new one, which fixes a bug encountered when > running SIMH set to be an 11/94. In that case (and possibly some > other similar variations) RSTS tries to figure out the line frequency > and gets it wrong because SIMH executes much faster. > > https://github.com/pkoning2/decstuff is the repository. > > paul > > Thanks for this Paul. There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1 under SIMH (posted to the SIMH mailing list in May 2016). You'll find it and the NSP1.TXT describing it in my repository at https://github.com/agn453/RSTS-E in the "decnete" subdirectory. I've recently joined HECnet and will be making some of my updates available soon. Tony -- Tony Nicholson From engel at multicores.org Tue Sep 15 07:53:57 2020 From: engel at multicores.org (Michael Engel) Date: Tue, 15 Sep 2020 14:53:57 +0200 Subject: Looking for a TI technical report on Explorer virtual memory Message-ID: Hi, first, a big "thank you" to all of you who support me with my attempt to get our Explorers and Xerox Stars to run again. I?ll head down to the basement in the afternoon to see if I can build a system that is able to image the Explorer not-quite-SCSI disks (according to the documentation, these have in fact 256 byte sectors). Btw., this Raspberry Pi SCSI device emulator supposedly also supports emulating SASI drives: https://hackaday.com/2017/05/01/the-raspberry-pi-becomes-a-scsi-device/ The original Japanese web page linked in the article is no longer online, but there are several versions of the code (and a translated webpage in English) mirrored on github. This might be useful to build a working SCSI device emulation for the Explorer. So I have another favor related to TI Explorers to ask... One of the reasons (apart from the planned exhibition) I am interested in Lisp and Smalltalk machines is that I?m collecting information on systems using persistent memory, which could also help my students who work on persistent memory research topics to obtain a better insight into the topic and its history. There was a research prototype of a persistent virtual memory system for the TI Explorer by Satish M. Tatte (TI Artificial Intelligence Labs) metioned in these papers: Satish M. Thatte. 1986. Persistent memory: a storage architecture for object-oriented database systems. In Proceedings on the 1986 international workshop on Object-oriented database systems (OODS '86). IEEE Computer Society Press, Washington, DC, USA, 148?159. (https://dl.acm.org/doi/pdf/10.5555/318826.318848) and Thatte S.M. (1991) Persistent Memory: A Storage System for Object-Oriented Databases. In: Dittrich K.R., Dayal U., Buchmann A.P. (eds) On Object-Oriented Database Systems. Topics in Information Systems. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-84374-7_16 The second paper cites a more detailed TI Tech Report which I have been unable to find: Thatte, S.M.: "Persistent Memory for Symbolic Computers", Technical Report TR-08-85-21, Central Research Laboratories, Texas Instruments Incorporated, Dallas, TX, July 1985. Does one of you maybe have a copy of this? Best wishes, ??? Michael From dkelvey at hotmail.com Tue Sep 15 09:39:27 2020 From: dkelvey at hotmail.com (dwight) Date: Tue, 15 Sep 2020 14:39:27 +0000 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> Message-ID: It may be low voltage AC and ground or it may be +5V and a high voltage for programming and a return ground. You might look inside to see what the wires lead to. Most all warts don't provide regulated voltage levels but some do. If it provided regulated levels, there would be a direct connection for the ttl to +5V. Dwight ________________________________ From: cctalk on behalf of Al Kossow via cctalk Sent: Monday, September 14, 2020 12:24 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: ISO Advantech Labtool-148C prgrammer wall wart specs I just bought one of these thinking it ran off 110, but it uses a 3 pin wall wart. Does anyone have one of these and could tell me the voltages it supplies. From paulkoning at comcast.net Tue Sep 15 10:16:15 2020 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 15 Sep 2020 11:16:15 -0400 Subject: [HECnet] RSTS/E patches In-Reply-To: References: Message-ID: The patches I posted are mostly for both. The kdj11e.cmd patch is for a problem seen on SIMH that probably can't happen on real hardware. The nsp1.pat file Tony mentioned is certainly more likely on SIMH but I suspect could happen on real hardware also. In any case, none of them will create problems on real hardware. paul > On Sep 15, 2020, at 9:20 AM, W2HX via cctalk wrote: > > Are these patches discussed below only for patching SIMH to fix problems with it? Or are these fixes that are for actual PDP hardware implementations of RSTS? > > -----Original Message----- > From: cctalk On Behalf Of Tony Nicholson via cctalk > Sent: Monday, September 14, 2020 6:10 PM > To: hecnet at update.uu.se > Cc: cctalk at classiccmp.org > Subject: Re: [HECnet] RSTS/E patches > > On Tue, Sep 15, 2020 at 7:28 AM Paul Koning wrote: > >> I previously created a Github repository for various DEC things, >> including updated DECnet/E utilities. I thought that the RSTS patches >> I had posted in the past were there also, but that wasn't the case. >> >> I've added a "patches" subdirectory, which contains the patches I have >> collected. I just added a new one, which fixes a bug encountered when >> running SIMH set to be an 11/94. In that case (and possibly some >> other similar variations) RSTS tries to figure out the line frequency >> and gets it wrong because SIMH executes much faster. >> >> https://github.com/pkoning2/decstuff is the repository. >> >> paul >> >> > Thanks for this Paul. > > There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1 under SIMH (posted to the SIMH mailing list in May 2016). > > You'll find it and the NSP1.TXT describing it in my repository at > > https://github.com/agn453/RSTS-E > > in the "decnete" subdirectory. > > I've recently joined HECnet and will be making some of my updates available soon. > > Tony > > -- > Tony Nicholson From aek at bitsavers.org Tue Sep 15 10:38:01 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 15 Sep 2020 08:38:01 -0700 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> Message-ID: On 9/15/20 7:39 AM, dwight wrote: > It may be low voltage AC and ground or it may be +5V and a high voltage for programming and a return ground. You might look inside to see > what the wires lead to. it is two DC voltages. I haven't traced out which one is 5v From aek at bitsavers.org Tue Sep 15 12:21:01 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 15 Sep 2020 10:21:01 -0700 Subject: Old tape files needing review In-Reply-To: References: Message-ID: <18575b57-abba-7a60-6538-ee24db465077@bitsavers.org> On 9/14/20 1:25 PM, Chuck Guzis via cctalk wrote: > Folks, > > I've got a fair amount of what would be classified as public domain tape > data from old customer jobs wandering around. I don't have the time to > peruse it in detail and was wondering if someone would like to take a > stab at a sample and perhaps volunteer for the rest. > could you put up the tapes as images so that the file dates can be preserved? From cclist at sydex.com Tue Sep 15 12:35:54 2020 From: cclist at sydex.com (Chuck Guzis) Date: Tue, 15 Sep 2020 10:35:54 -0700 Subject: Old tape files needing review In-Reply-To: <18575b57-abba-7a60-6538-ee24db465077@bitsavers.org> References: <18575b57-abba-7a60-6538-ee24db465077@bitsavers.org> Message-ID: On 9/15/20 10:21 AM, Al Kossow via cctalk wrote: > On 9/14/20 1:25 PM, Chuck Guzis via cctalk wrote: >> Folks, >> >> I've got a fair amount of what would be classified as public domain tape >> data from old customer jobs wandering around.? I don't have the time to >> peruse it in detail and was wondering if someone would like to take a >> stab at a sample and perhaps volunteer for the rest. >> > > could you put up the tapes as images so that the file dates can be > preserved? Probably; I have a lot of files to go through and and I want to be super-careful. It could be that there would be proprietary stuff mixed in with the general non-proprietary stuff. Consider it a work in progress. --Chuck From dkelvey at hotmail.com Tue Sep 15 13:24:48 2020 From: dkelvey at hotmail.com (dwight) Date: Tue, 15 Sep 2020 18:24:48 +0000 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> , Message-ID: Hi Al Many programmers use the +5V to switching boost for programming voltage because the needed level has a low current load for the programming level. The additional wire might be for a negative level, such as RS-232 or DRAM. These are still things that can be traced out with and ohm meter and also look for polarized capacitors. If there is RS-232, look for the drivers. Maxim parts use built in capacitive charge pumps and don't need a negative rail. These are all good indicators of what the levels are. PAL programmers need higher programming current than EPROMs. I don't know the particular programmer's purpose you have. Dwight ________________________________ From: cctalk on behalf of Al Kossow via cctalk Sent: Tuesday, September 15, 2020 8:38 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: ISO Advantech Labtool-148C prgrammer wall wart specs On 9/15/20 7:39 AM, dwight wrote: > It may be low voltage AC and ground or it may be +5V and a high voltage for programming and a return ground. You might look inside to see > what the wires lead to. it is two DC voltages. I haven't traced out which one is 5v From rp at servium.ch Tue Sep 15 13:24:06 2020 From: rp at servium.ch (Rico Pajarola) Date: Tue, 15 Sep 2020 11:24:06 -0700 Subject: SPARCstation ELC Installation and repair guide Message-ID: Does anyone have the Sun SPARCstation ELC Installation and repair guide? I have a few naked ELC boards and I'd like to know what that edge connector does (presumably power and video) and if feasible build something from it (1U rackmount Sun4c server? Slim client built into the back of an LCD? SPARC Laptop? Endless possibilities....) From aek at bitsavers.org Tue Sep 15 14:18:27 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 15 Sep 2020 12:18:27 -0700 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> Message-ID: On 9/15/20 11:24 AM, dwight wrote: > I don't know the particular programmer's purpose you have. It is a 2000's era parallel programmer with downloadable FPGA configuration. I can trace it out and note the voltages on the filter caps as an estimate. I was just hoping someone could quickly tell me what the wall wart said. There is an Advantech dealer on ebay in Greece selling one, I've sent them a message if they have the supply or could at least tell me what the voltages should be. I got this one cheap since it has programmable Vcc for read/verify. I have one 2764 giving me trouble reading. I may just be faster to lift the Vcc pin on it and attach it to a bench supply. From dkelvey at hotmail.com Tue Sep 15 15:26:32 2020 From: dkelvey at hotmail.com (dwight) Date: Tue, 15 Sep 2020 20:26:32 +0000 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> , Message-ID: Sounds fun. I was not able to get anything useful out of my one 1702 that is causing difficulties. I believe is was a copy of a bad image. I should try the other one that has a blank section on 25%. It might be an addressing problem but who knows. I can't think of an open address pin that would blanks just 25%. It is more likely just broke inside. It is an early EPROM type with the gold pin that are in bad shape after being stored on the black rubber foam. I've needed to solder a socket to that first one, to get good contacts on all the pins. Messy! Dwight ________________________________ From: cctalk on behalf of Al Kossow via cctalk Sent: Tuesday, September 15, 2020 12:18 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: ISO Advantech Labtool-148C prgrammer wall wart specs On 9/15/20 11:24 AM, dwight wrote: > I don't know the particular programmer's purpose you have. It is a 2000's era parallel programmer with downloadable FPGA configuration. I can trace it out and note the voltages on the filter caps as an estimate. I was just hoping someone could quickly tell me what the wall wart said. There is an Advantech dealer on ebay in Greece selling one, I've sent them a message if they have the supply or could at least tell me what the voltages should be. I got this one cheap since it has programmable Vcc for read/verify. I have one 2764 giving me trouble reading. I may just be faster to lift the Vcc pin on it and attach it to a bench supply. From cmhanson at eschatologist.net Tue Sep 15 15:54:20 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 15 Sep 2020 13:54:20 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> Message-ID: On Sep 14, 2020, at 9:00 AM, Josh Dersch via cctalk wrote: > > The Star mouse pad can be recreated with a laser printer (I've used this: > http://www.digibarn.com/collections/devices/xerox-mousepad/index.html, and > there's a postscript file floating around out there?). Here?s some PostScript that was based on Xerox?s patent: http://rendezvous.eschatologist.net/xerox/XeroxMousepad.ps I?ve also put a PDF version here: http://rendezvous.eschatologist.net/xerox/XeroxMousepad.pdf It just needs to be printed at sufficiently high resolution to be used as a mousepad. ? Chris From engel at multicores.org Tue Sep 15 16:09:05 2020 From: engel at multicores.org (Michael Engel) Date: Tue, 15 Sep 2020 23:09:05 +0200 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <20200914234411.3c9fd8d7@dragonsweb.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> Message-ID: <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> Well, today's my lucky day :) - I found a box with three TI mice+pads and three fiber cables: https://multicores.org/explorer/ If you need any measurements of the connectors or the fiber optic cable itself (I'm sure our physics department can help out...) let me know. And what I thought were simple Tektronix vector terminals turned out to be two Tektronix 4404 machines and one 4406 - the 68010/020-based Smalltalk machines (which can also run Common Lisp). So more great stuff for our exhibition - and more machines to work on... > On 15 Sep 2020, at 05:44, James B DiGriz via cctalk wrote: > > On Mon, 14 Sep 2020 15:35:50 +0200 > Michael Engel via cctalk wrote: > >> Some things I could not find so far are the mouse and the console >> cable for the Explorer. It seems that the mouse is related to >> MouseSystems optical mice used on older Sun/SGI systems (but the >> interface might be different?). The fiber optics cable for the >> display (TI part number 2233200 according to the field service >> manual) might be another problem >> - if you know any details about this, I would be very interested... >> > > This is the same part # listed for the 990, and I would think, lacking > documentation on them, the BS600 and BS800 machines, if using > the CI404 comm board. I don't know how common those were. My college > only started using them after a lightning strike took out some machines > through one or more serial links, iirc. But that may broaden your search. > > From the CI403/CI404 manual > (http://bitsavers.org/pdf/ti/990/datacomm/2263897_9701B_CI403_Nov83.pdf): > > 2233200-0001 Standard duplex fiber-optic cable, 15m > > 2233201-0002 Fiber-optic extension cable, 60m > 2233201-0003 Fiber-optic extension cable, 150m > 2233201-0004 Fiber-optic extension cable, 300m > > 2233210-0001 Converter module kit, includes: Converter, > Power Module, and Power Cord. > > The extension cables include a connector for connectin 2 cables. > > I may have some more information on the mouse and maybe some cable specs > soon. Talking to some people who likely know. > > jbdigriz From aek at bitsavers.org Tue Sep 15 16:19:24 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 15 Sep 2020 14:19:24 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> Message-ID: On 9/15/20 2:09 PM, Michael Engel via cctalk wrote: > And what I thought were simple Tektronix vector terminals turned out to be two Tektronix > 4404 machines and one 4406 - the 68010/020-based Smalltalk machines (which can also > run Common Lisp). So more great stuff for our exhibition - and more machines to work on... > Please dump the firmware and image any floppies you have for this, especially the 020 version And take some internal/external pictures of the unit and the external disk box A simulator is in development. From aek at bitsavers.org Tue Sep 15 16:21:20 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 15 Sep 2020 14:21:20 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> Message-ID: On 9/15/20 2:19 PM, Al Kossow via cctalk wrote: > Please dump the firmware and image any floppies you have for this, especially the 020 version > And take some internal/external pictures of the unit and the external disk box > It should also be possible to image the hard disks, if they still work without having a running Tek machine. From engel at multicores.org Tue Sep 15 16:24:22 2020 From: engel at multicores.org (Michael Engel) Date: Tue, 15 Sep 2020 23:24:22 +0200 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> Message-ID: > On 15 Sep 2020, at 23:19, Al Kossow via cctalk wrote: > > On 9/15/20 2:09 PM, Michael Engel via cctalk wrote: > >> And what I thought were simple Tektronix vector terminals turned out to be two Tektronix >> 4404 machines and one 4406 - the 68010/020-based Smalltalk machines (which can also >> run Common Lisp). So more great stuff for our exhibition - and more machines to work on... > Please dump the firmware and image any floppies you have for this, especially the 020 version I haven't found any floppies for the Tektronix machines so far (but there are more unopened boxes...), but I can dump the disks (they seem to be SCSI) and can certainly also read the EPROMs. > And take some internal/external pictures of the unit and the external disk box Finally some good use for my DSLR :). > A simulator is in development. I found this web page by Seth Morabito: https://loomcom.com/blog/0120_the_next_emulator.html Is this the simulator that is under development? Best, Michael From aek at bitsavers.org Tue Sep 15 16:31:03 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 15 Sep 2020 14:31:03 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> Message-ID: <7b982b61-d8cc-b48b-b9ce-a6d000e9c387@bitsavers.org> On 9/15/20 2:24 PM, Michael Engel via cctalk wrote: >> A simulator is in development. > > I found this web page by Seth Morabito: https://loomcom.com/blog/0120_the_next_emulator.html > Is this the simulator that is under development? > > Best, > Michael > > yes, one of them there is also a skeleton driver in MAME for the 4404 Josh and I both have 4404s we've been trying to get running. I have some docs and software for the 4404 on bitsavers From engel at multicores.org Tue Sep 15 15:52:58 2020 From: engel at multicores.org (Michael Engel) Date: Tue, 15 Sep 2020 22:52:58 +0200 Subject: SPARCstation ELC Installation and repair guide In-Reply-To: References: Message-ID: <44427B2F-536D-4E0F-BA17-D1A039D2F107@multicores.org> Hi, > On 15 Sep 2020, at 20:24, Rico Pajarola via cctech wrote: > > Does anyone have the Sun SPARCstation ELC Installation and repair guide? > > I have a few naked ELC boards and I'd like to know what that edge connector > does (presumably power and video) and if feasible build something from it > (1U rackmount Sun4c server? Slim client built into the back of an LCD? > SPARC Laptop? Endless possibilities....) Somebody had that idea already (and I like it... but I gave away all of my SLCs and ELCs years ago): http://www.sunhelp.org/~mouse/headless-elc.html However, it seems that this is still using the connector board which the actual CPU board plugs into. The page mentions that the author has been sent a pinout of the edge connector, but it isn't linked. Have fun, Michael From antoniob at bell.net Tue Sep 15 15:58:04 2020 From: antoniob at bell.net (antoniob at bell.net) Date: Tue, 15 Sep 2020 16:58:04 -0400 Subject: Sgi gear Message-ID: <20200915205820.OHCK29322.torspm01.bell.net@[172.29.0.110]> Do you have any challenge L deskisde or onyx available? From derschjo at gmail.com Tue Sep 15 17:11:16 2020 From: derschjo at gmail.com (Josh Dersch) Date: Tue, 15 Sep 2020 15:11:16 -0700 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: <7b982b61-d8cc-b48b-b9ce-a6d000e9c387@bitsavers.org> References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> <7b982b61-d8cc-b48b-b9ce-a6d000e9c387@bitsavers.org> Message-ID: On Tue, Sep 15, 2020 at 2:31 PM Al Kossow via cctalk wrote: > On 9/15/20 2:24 PM, Michael Engel via cctalk wrote: > > >> A simulator is in development. > > > > I found this web page by Seth Morabito: > https://loomcom.com/blog/0120_the_next_emulator.html > > Is this the simulator that is under development? > > > > Best, > > Michael > > > > > > yes, one of them > there is also a skeleton driver in MAME for the 4404 > > Josh and I both have 4404s we've been trying to get running. > I have some docs and software for the 4404 on bitsavers > I did recently get my 4404 running, at last. It runs nicely off of a SCSI2SD, replacing the SCSI->MFM bridge, should you so choose. I can share the disk image I did of a clean install of the OS, languages, and tools that are available on Bitsavers. I also have an MFM emulator image of a disk that I believe went to a 4406, but I cannot confirm that it's bootable. - Josh From macro at linux-mips.org Tue Sep 15 19:49:07 2020 From: macro at linux-mips.org (Maciej W. Rozycki) Date: Wed, 16 Sep 2020 01:49:07 +0100 (BST) Subject: Sun SPARCstation LX boot from CDROM? In-Reply-To: References: <623C45C3-48D8-47D7-881E-C192D9673B90@snowmoose.com> Message-ID: On Tue, 1 Sep 2020, Liam Proven via cctalk wrote: > This and the rest of what you describe sounds quite like the damaged > caused by electrolyte leaking from failed capacitors. This is probably > the most common cause of failure in electronics after they get to 2-3 > decades old. > > There was one particular time when this happened prematurely: > https://en.wikipedia.org/wiki/Capacitor_plague There was the issue with the quaternary ammonium salt system earlier on too, e.g. with Chemi-Con SXF parts and several other ones from various reputable manufacturers in early 1990s. Maciej From lars at nocrew.org Wed Sep 16 00:07:01 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 16 Sep 2020 05:07:01 +0000 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: (Josh Dersch via cctalk's message of "Tue, 15 Sep 2020 15:11:16 -0700") References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> <7b982b61-d8cc-b48b-b9ce-a6d000e9c387@bitsavers.org> Message-ID: <7wsgbi48ei.fsf@junk.nocrew.org> Josh Dersch wrote: > I did recently get my 4404 running, at last. Any Lisp screenshots? I believe fibonacci is a required exercise for occations like this. From rp at servium.ch Tue Sep 15 20:41:09 2020 From: rp at servium.ch (Rico Pajarola) Date: Tue, 15 Sep 2020 18:41:09 -0700 Subject: SPARCstation ELC Installation and repair guide In-Reply-To: <44427B2F-536D-4E0F-BA17-D1A039D2F107@multicores.org> References: <44427B2F-536D-4E0F-BA17-D1A039D2F107@multicores.org> Message-ID: On Tue, Sep 15, 2020 at 1:53 PM Michael Engel via cctech < cctech at classiccmp.org> wrote: > Hi, > > > On 15 Sep 2020, at 20:24, Rico Pajarola via cctech < > cctech at classiccmp.org> wrote: > > > > Does anyone have the Sun SPARCstation ELC Installation and repair guide? > > > > I have a few naked ELC boards and I'd like to know what that edge > connector > > does (presumably power and video) and if feasible build something from it > > (1U rackmount Sun4c server? Slim client built into the back of an LCD? > > SPARC Laptop? Endless possibilities....) > > Somebody had that idea already (and I like it... but I gave away all of my > SLCs and ELCs years ago): > http://www.sunhelp.org/~mouse/headless-elc.html > > However, it seems that this is still using the connector board which the > actual CPU board plugs into. The page mentions that the author has been > sent a pinout of the edge connector, but it isn't linked. > thanks, that site didn't turn up in my search. I remember Mouse, I shot him an email and hope I get a reply ;) Have fun, > Michael > > From rdbrown0au at gmail.com Wed Sep 16 07:30:04 2020 From: rdbrown0au at gmail.com (Rodney Brown) Date: Wed, 16 Sep 2020 22:30:04 +1000 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany Message-ID: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> HP 3000 Series 37 on ebay in Germany (7954A, 9144AR, 30457A, 700/92 (German keyboard)) https://www.ebay.com.au/itm/HP-3000-Series-37-Computer-System-RETRO-SELTEN-RARE-ca-1985-1987/283988656899 Thanks to David Collins at the HP Computer Museum, I now have 11 different versions of the HP 3000 Series 64 [,68,70] microcode SYSWCS64.PUB.SYS and 3 different versions respectively of each of SYSWCS37 and WCSLE1 and WCSLE2. I've put notes up at https://en.wikipedia.org/wiki/User:RDBrown/HP3000-WCS-Microcode It's possible that one of the SYSWCS64 files may match the assembly listing on bitsavers, but that listing could allow guessing the architecture, assuming horizontal microcode and matching against the HP 3000 stack machine instruction set it implements. Only the Series 37 rates a mention in the HP Journal, though the common data between the SYSWCS37, WCSLE1 and WCSLE2 suggests they may share a common microcode. Guessing the architecture would be more of a puzzle, unless more documentation is found. J. David Bryan's SIMH work gives a running MPE V for anyone to try. I don't know what other minis of the era also have microcode available as files - I read that the Vax 780 had 1k of microcode patch/extension area for fixes or customer use. From aek at bitsavers.org Wed Sep 16 07:59:26 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 16 Sep 2020 05:59:26 -0700 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> Message-ID: for the archives, the Labtool-148C wall wart is: +5V/1.5A ,+12V/1.5A it also has one of those funny 1/4" square usb looking connectors with the pins arranged in a equilateral triangle From aek at bitsavers.org Wed Sep 16 08:03:51 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 16 Sep 2020 06:03:51 -0700 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> Message-ID: <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> On 9/16/20 5:30 AM, Rodney Brown via cctalk wrote: > It's possible that one of the SYSWCS64 files may match the assembly listing on bitsavers, but that listing could allow guessing the > architecture, assuming horizontal microcode and matching against the HP 3000 stack machine instruction set it implements. > I suspect the listing is for this machine https://www.computerhistory.org/collections/catalog/102691253 I remember looking at the microcode boards in it at one point, and it had APL roms Attempting to dump them isn't possible right now. Was Lee Courtney involved with the APL 3000 project? From dkelvey at hotmail.com Wed Sep 16 08:44:49 2020 From: dkelvey at hotmail.com (dwight) Date: Wed, 16 Sep 2020 13:44:49 +0000 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> , Message-ID: One of the small floppy drive power supplies would be good. Too bad Halted is not still active. Dwight ________________________________ From: cctalk on behalf of Al Kossow via cctalk Sent: Wednesday, September 16, 2020 5:59 AM To: cctalk at classiccmp.org Subject: Re: ISO Advantech Labtool-148C prgrammer wall wart specs for the archives, the Labtool-148C wall wart is: +5V/1.5A ,+12V/1.5A it also has one of those funny 1/4" square usb looking connectors with the pins arranged in a equilateral triangle From toby at telegraphics.com.au Wed Sep 16 08:47:41 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 16 Sep 2020 09:47:41 -0400 Subject: ISO Advantech Labtool-148C prgrammer wall wart specs In-Reply-To: References: <50da2ba7-7f1f-d0b2-9046-faedb4bb55d5@bitsavers.org> Message-ID: On 2020-09-16 9:44 a.m., dwight via cctalk wrote: > One of the small floppy drive power supplies would be good. Too bad Halted is not still active. > Dwight > Any benched PC PSU, which are thrown in dumpsters by the thousands daily. > ________________________________ > From: cctalk on behalf of Al Kossow via cctalk > Sent: Wednesday, September 16, 2020 5:59 AM > To: cctalk at classiccmp.org > Subject: Re: ISO Advantech Labtool-148C prgrammer wall wart specs > > for the archives, the Labtool-148C wall wart is: > > +5V/1.5A ,+12V/1.5A > > it also has one of those funny 1/4" square usb looking connectors with the pins > arranged in a equilateral triangle > > From jfoust at threedee.com Wed Sep 16 10:12:15 2020 From: jfoust at threedee.com (John Foust) Date: Wed, 16 Sep 2020 10:12:15 -0500 Subject: Fwd: [GreenKeys] Teletype Model 28 Free, La Crosse, WI area Message-ID: <20200916151233.A3F814E789@mx2.ezwind.net> > >Subject: [GreenKeys] Model 28 Free >From: GARY WEBB via GreenKeys > >Model 28 with modem installed. Tape reader/reperf. Variable speed. Manuals. Last used 20+ years ago. If no one wants it, soon will be in the local land fill. Located in Onalaska, WI Phone 608-769-5633 NI9V From leec2124 at gmail.com Wed Sep 16 10:19:00 2020 From: leec2124 at gmail.com (Lee Courtney) Date: Wed, 16 Sep 2020 08:19:00 -0700 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> Message-ID: "Was Lee Courtney involved with the APL 3000 project?" - unfortunately no I was not. Just RTE on the 1000 and later MPE on PA-RISC. All I know is that there was microcode support required to run APL on Series II/III micro-architecture machines. That microcode was not moved to later micro-architectures (Series 3x, 4x, 6x, 7x) so there was no APL available. I don't think HP had enough customers using APL to justify the effort. Too bad because was an innovative APL. Stan Sieler et al are trying to get APL\3000 up and running on an emulated 3000 via SIMH. He's CC'd here and can comment. Al - it would be a Very Good Thing to get those APL ROMS dumped when possible. Lee Courtney On Wed, Sep 16, 2020 at 6:04 AM Al Kossow via cctalk wrote: > On 9/16/20 5:30 AM, Rodney Brown via cctalk wrote: > > > It's possible that one of the SYSWCS64 files may match the assembly > listing on bitsavers, but that listing could allow guessing the > > architecture, assuming horizontal microcode and matching against the HP > 3000 stack machine instruction set it implements. > > > > I suspect the listing is for this machine > https://www.computerhistory.org/collections/catalog/102691253 > > I remember looking at the microcode boards in it at one point, and it had > APL roms > Attempting to dump them isn't possible right now. > > Was Lee Courtney involved with the APL 3000 project? > > > -- Lee Courtney +1-650-704-3934 cell From imp at bsdimp.com Wed Sep 16 10:21:53 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 16 Sep 2020 09:21:53 -0600 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> Message-ID: On Wed, Sep 16, 2020 at 9:19 AM Lee Courtney via cctalk < cctalk at classiccmp.org> wrote: > "Was Lee Courtney involved with the APL 3000 project?" - unfortunately no I > was not. Just RTE on the 1000 and later MPE on PA-RISC. All I know is that > there was microcode support required to run APL on Series II/III > micro-architecture machines. That microcode was not moved to later > micro-architectures (Series 3x, 4x, 6x, 7x) so there was no APL available. > I don't think HP had enough customers using APL to justify the effort. Too > bad because was an innovative APL. > Why was microcode support required to make APL work? What did it enable that couldn't be done in other ways? Thanks! Warner > Stan Sieler et al are trying to get APL\3000 up and running on an emulated > 3000 via SIMH. He's CC'd here and can comment. > > Al - it would be a Very Good Thing to get those APL ROMS dumped when > possible. > > Lee Courtney > > On Wed, Sep 16, 2020 at 6:04 AM Al Kossow via cctalk < > cctalk at classiccmp.org> > wrote: > > > On 9/16/20 5:30 AM, Rodney Brown via cctalk wrote: > > > > > It's possible that one of the SYSWCS64 files may match the assembly > > listing on bitsavers, but that listing could allow guessing the > > > architecture, assuming horizontal microcode and matching against the HP > > 3000 stack machine instruction set it implements. > > > > > > > I suspect the listing is for this machine > > https://www.computerhistory.org/collections/catalog/102691253 > > > > I remember looking at the microcode boards in it at one point, and it had > > APL roms > > Attempting to dump them isn't possible right now. > > > > Was Lee Courtney involved with the APL 3000 project? > > > > > > > > -- > Lee Courtney > +1-650-704-3934 cell > From wh.sudbrink at verizon.net Wed Sep 16 11:47:38 2020 From: wh.sudbrink at verizon.net (William Sudbrink) Date: Wed, 16 Sep 2020 12:47:38 -0400 Subject: B.E.I uSounder S-100 board... References: <19c901d68c49$16d33510$44799f30$.ref@verizon.net> Message-ID: <19c901d68c49$16d33510$44799f30$@verizon.net> I just picked up one of these on a lark. It has an SN76477 sound effects chip on it. Not much other info besides the copyright, 1978. Anyone have schematics or a user manual? Thanks, Bill S. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From wh.sudbrink at verizon.net Wed Sep 16 11:47:38 2020 From: wh.sudbrink at verizon.net (William Sudbrink) Date: Wed, 16 Sep 2020 12:47:38 -0400 Subject: B.E.I uSounder S-100 board... References: <19c901d68c49$16d33510$44799f30$.ref@verizon.net> Message-ID: <19c901d68c49$16d33510$44799f30$@verizon.net> I just picked up one of these on a lark. It has an SN76477 sound effects chip on it. Not much other info besides the copyright, 1978. Anyone have schematics or a user manual? Thanks, Bill S. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From leec2124 at gmail.com Wed Sep 16 13:29:16 2020 From: leec2124 at gmail.com (Lee Courtney) Date: Wed, 16 Sep 2020 11:29:16 -0700 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> Message-ID: I believe it was a performance issue. The APL was so slow without the microcode assist that the system was unusable. Lee C. On Wed, Sep 16, 2020 at 8:22 AM Warner Losh wrote: > > > On Wed, Sep 16, 2020 at 9:19 AM Lee Courtney via cctalk < > cctalk at classiccmp.org> wrote: > >> "Was Lee Courtney involved with the APL 3000 project?" - unfortunately no >> I >> was not. Just RTE on the 1000 and later MPE on PA-RISC. All I know is that >> there was microcode support required to run APL on Series II/III >> micro-architecture machines. That microcode was not moved to later >> micro-architectures (Series 3x, 4x, 6x, 7x) so there was no APL available. >> I don't think HP had enough customers using APL to justify the effort. Too >> bad because was an innovative APL. >> > > Why was microcode support required to make APL work? What did it enable > that couldn't be done in other ways? > > Thanks! > > Warner > > >> Stan Sieler et al are trying to get APL\3000 up and running on an emulated >> 3000 via SIMH. He's CC'd here and can comment. >> >> Al - it would be a Very Good Thing to get those APL ROMS dumped when >> possible. >> >> Lee Courtney >> >> On Wed, Sep 16, 2020 at 6:04 AM Al Kossow via cctalk < >> cctalk at classiccmp.org> >> wrote: >> >> > On 9/16/20 5:30 AM, Rodney Brown via cctalk wrote: >> > >> > > It's possible that one of the SYSWCS64 files may match the assembly >> > listing on bitsavers, but that listing could allow guessing the >> > > architecture, assuming horizontal microcode and matching against the >> HP >> > 3000 stack machine instruction set it implements. >> > > >> > >> > I suspect the listing is for this machine >> > https://www.computerhistory.org/collections/catalog/102691253 >> > >> > I remember looking at the microcode boards in it at one point, and it >> had >> > APL roms >> > Attempting to dump them isn't possible right now. >> > >> > Was Lee Courtney involved with the APL 3000 project? >> > >> > >> > >> >> -- >> Lee Courtney >> +1-650-704-3934 cell >> > -- Lee Courtney +1-650-704-3934 cell From sieler at allegro.com Wed Sep 16 17:41:23 2020 From: sieler at allegro.com (Stan Sieler) Date: Wed, 16 Sep 2020 15:41:23 -0700 Subject: APL\3000 microcode. Was: Re: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany Message-ID: Warner asks: "Why was microcode support required to make APL work? What did it enable that couldn't be done in other ways?" [On an HP 3000 Series III, for example] Back in the mid-1970s, on the HP 3000 Series III, the team implementing APL\3000 apparently decided they would need to implement some form of virtual memory (beyond the multiple 64KB spaces the HP 3000 Classic architecture provided). They chose to add 11 new instructions: LDV, STV, MWFV, MWTV, MBFV, MBTV, LDVB, STVB, MVW, and EGOTO (unnamed by HP), LDWX (unnamed by HP) The first 9 are "virtual memory" related instructions. The last two are not. These instructions were added shortly after the original Series III instruction set had previously been expanded by the addition of the new extended COBOL instructions. (So, the Series III had two sets of firmware expansions.) Subsequent HP 3000 models had the COBOL instructions from day 1. I presume that the APL instructions weren't ready when the Series 30/33 design was locked down. I *think* they might have been available later as an add-on. I know that a few years later, the instructions were ported to the Series 40/44 microcode by Leon Leong, but they were never released for it (APL\3000 was in limbo, about to be cancelled at the time.) But, to answer your question, yes...there are other ways. Gavin Scott managed to patch the unimplemented instruction handler in MPE V/R (the release the SIMH HP3000 simulator is running), and got APL\3000 running. In the meantime, I'm slowing trying to add the instructions to the SIMH code. The nice thing about Gavin's approach is that if I get an instruction implemented, his code *for that instruction* simply never gets called ... so we can coexist peacefully. In theory, implementing the APL instructions in SIMH will lead to better performance (because calling one won't cause a missing instruction interrupt, followed by hundreds or thousands of simulated HP 3000 instructions to emulate the instruction). I believe Gavin is preparing a talk about APL\3000 for an APL Users Group. Another alternative would have been for the APL\3000 people to implement references to their virtual memory via "cover functions". However, I suspect that the grasp of SPL programming, the lack of "macros" with parameters in SPL, and concerns about the performance penalty of a procedure call per memory access all would have conspired to argue against this approach. (Having been reading thousands of lines of SPL written in the 1970s, I conclude that perhaps a handful of people at HP understood how to write readable, maintainable SPL code ... and that's probably the same percentage as SPL programmers outside HP :) Stan From sieler at allegro.com Wed Sep 16 17:48:02 2020 From: sieler at allegro.com (Stan Sieler) Date: Wed, 16 Sep 2020 15:48:02 -0700 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> Message-ID: Re: On Wed, Sep 16, 2020 at 11:29 AM Lee Courtney wrote: > I believe it was a performance issue. The APL was so slow without the > microcode assist that the system was unusable. > Close. Without the microcode, they had no apparent way of even halfway efficiently implementing a large virtual memory mechanism (other than using multiple 64KB data segments, and the number of those was severely limited, system-wide). In no way would any HP 3000 (at that time) run APL\3000 at all without the microcode (#1). With the microcode, they managed to get a *very slow* virtual memory system. Marginally adequate for a few light-weight users, it brought the HP 3000 Series III (a megahertz machine, IIRC) to its knees with any heavy use. Which is why HP was sued over APL\3000. When HP won (apparently because the judge decided the person suing should have been able to determine the performance problem before specifying/buying an HP 3000), HP immediately dropped APL\3000. (It had been explained to me that they didn't want to drop it during the case.) Stan 1. Gavin Scott's method lets it run, but by simulating the missing instructions when they are called and cause an interrupt. From shadoooo at gmail.com Thu Sep 17 00:29:13 2020 From: shadoooo at gmail.com (shadoooo) Date: Thu, 17 Sep 2020 07:29:13 +0200 Subject: 9 track tapes and block sizes Message-ID: Hello, I have a question about 9 track tapes and block sizes. What I know is that tape is subdivided in files by means of marks, and each file is subdivided in blocks of equal size. Programs like tar use a specific block size to create files on tape. However files can have different block sizes like bootloader file, installation dumps and root file system copy on 2.11BSD. Now suppose you find and unknown tape you want to preserve: using dd you could easily 1:1 copy tape files to hard disk files using a SCSI drive and Linux. But: how you know which block size is on the tape? Thanks Andrea From drb at msu.edu Thu Sep 17 00:53:08 2020 From: drb at msu.edu (Dennis Boone) Date: Thu, 17 Sep 2020 01:53:08 -0400 Subject: 9 track tapes and block sizes In-Reply-To: (Your message of Thu, 17 Sep 2020 07:29:13 +0200.) References: Message-ID: <20200917055309.189E62BA7F1@yagi.h-net.msu.edu> > What I know is that tape is subdivided in files by means of marks, > and each file is subdivided in blocks of equal size. Er, no. The blocks aren't necessarily of equal size. Unix people who are used to tar often seem to have this mindset, but the general case is that records can be of varying size. > Now suppose you find and unknown tape you want to preserve: using dd > you could easily 1:1 copy tape files to hard disk files using a SCSI > drive and Linux. DON'T DO THAT. If you use dd, you're throwing away information. Specifically, you're throwing away knowledge of the block size. Most of the conventional unix utilities don't care. Many other things do. In many cases, it's difficult or impossible to reconstruct the block sizes from the content, but even if it was, it's terrible archival practice. There are file formats for containing tape image data. The most common one is probably the simh .tap format. These all preserve block lengths, tape marks, indications of errors in reading the original, etc. Many fail to provide a means to embed metadata, but you can put that in separate adjacent files. > But: how you know which block size is on the tape? Generally speaking, do a read of a blocksize as large or larger than the max on the tape, and the system will hand you the full record, and the actual number of bytes read. If you're writing C or scripting code, the unix read() call does this. From the command line, you can do it with dd - specify a large block size and a count of 1, and it'll tell you what it actually got as it exits. For 9 track, few systems could write blocks larger than 32k or 64k, so those are decent guesses for "large" there. If it's DLT or something more modern, then the largest possible block might be a lot larger. The system reading the tape may impose a limit based on available buffer space. You should able to iteratively determine the largest size it will accept. Many of the quarter-inch cartridge formats actually don't support block sizes other than 512 bytes. If they were used on systems that expected to be able to write larger and/or variable records, the system hardware or software may have implemented a logical blocking layer on top of the 512 hardware layer. If you're reading one of these and don't have the original hardware/software to decode it, you'll have to figure out how to decipher it yourself. De From cclist at sydex.com Thu Sep 17 01:32:54 2020 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 16 Sep 2020 23:32:54 -0700 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: <36d951f6-7921-31f0-dadc-45583e84bd22@sydex.com> On 9/16/20 10:29 PM, shadoooo via cctalk wrote: > Hello, > I have a question about 9 track tapes and block sizes. > What I know is that tape is subdivided in files by means of marks, and each > file is subdivided in blocks of equal size. > Programs like tar use a specific block size to create files on tape. > However files can have different block sizes like bootloader file, > installation dumps and root file system copy on 2.11BSD. > Now suppose you find and unknown tape you want to preserve: using dd you > could easily 1:1 copy tape files to hard disk files using a SCSI drive and > Linux. > But: how you know which block size is on the tape? Variable length blocks can be handled using the mt(1) command on linux. "defblksize 0" generally will do this, but this varies between distros. Some use the "setblk 0" parameter. Not all hardware and not all drivers support variable block size. As far as 9 track maximum block size, I've seen 132K blocks--and on old CDC 6000 7-track systems, the 1LT driver would permit a block to be as long as a reel of tape, provided the application reading or writing could keep up. 1LT was a bag of worms. ECS accesses could torpedo a transfer; it made the DD60 flicker like crazy. It was a great source of PSRs. --Chuck From dave.g4ugm at gmail.com Thu Sep 17 01:38:01 2020 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Thu, 17 Sep 2020 07:38:01 +0100 Subject: 9 track tapes and block sizes In-Reply-To: <20200917055309.189E62BA7F1@yagi.h-net.msu.edu> References: <20200917055309.189E62BA7F1@yagi.h-net.msu.edu> Message-ID: <2d5801d68cbd$178de0d0$46a9a270$@gmail.com> > -----Original Message----- > From: cctalk On Behalf Of Dennis Boone via > cctalk > Sent: 17 September 2020 06:53 > To: cctalk at classiccmp.org > Subject: Re: 9 track tapes and block sizes > > > What I know is that tape is subdivided in files by means of marks, > and each > file is subdivided in blocks of equal size. > > Er, no. The blocks aren't necessarily of equal size. Unix people who are used to > tar often seem to have this mindset, but the general case is that records can be > of varying size. On labelled tapes the blocks are almost certainly different sizes. Usually one or more 80-charater labels followed by a tape mark followed by data blocks > > > Now suppose you find and unknown tape you want to preserve: using dd > > you could easily 1:1 copy tape files to hard disk files using a SCSI > drive and > Linux. > > DON'T DO THAT. If you use dd, you're throwing away information. > Specifically, you're throwing away knowledge of the block size. Most of the > conventional unix utilities don't care. Many other things do. In many cases, it's > difficult or impossible to reconstruct the block sizes from the content, but even > if it was, it's terrible archival practice. > > There are file formats for containing tape image data. The most common one > is probably the simh .tap format. These all preserve block lengths, tape marks, > indications of errors in reading the original, etc. Many fail to provide a means > to embed metadata, but you can put that in separate adjacent files. > The docs for SIMH .TAP files are here:- http://simh.trailing-edge.com/docs/simh_magtape.pdf be careful as there are also non-SIMH .tap formats In the IBM Mainframe emulation world there is also .AWS, an IBM format introduced with its P390 Microchannel Mainframe card and .HET a Hercules extension to .AWS which allows compression note all the above formats contain info that allows the file to be read block by block, both forwards and backwards, from any position on the tape. > > But: how you know which block size is on the tape? > > Generally speaking, do a read of a blocksize as large or larger than the max on > the tape, and the system will hand you the full record, and the actual number > of bytes read. If you're writing C or scripting code, the unix read() call does > this. From the command line, you can do it with dd - specify a large block size > and a count of 1, and it'll tell you what it actually got as it exits. > > For 9 track, few systems could write blocks larger than 32k or 64k, so those are > decent guesses for "large" there. If it's DLT or something more modern, then > the largest possible block might be a lot larger. The system reading the tape > may impose a limit based on available buffer space. You should able to > iteratively determine the largest size it will accept. > Long block mean fewer inter-block gaps so are often a choice for archives, especially on 6250BPI 9-track tape. If you are lucky and the tape contains labels these usually have info about the block and record size. http://www.setgetweb.com/p/i5/volum.htm Of and yes tape data often has records embedded in the block without terminating , or characters. So it was common to use tapes with 800 byte blocks, with 10 card images in each block, or 1200 byte blocks with ten 120 byte printer lines in each block. For commercial data you may even find multiple record types, so when I worked in insurance, we would have a customer record with one or more policy records. You will also find variable length records and blocks where there are length fields in the blocks. Of course that was a long time ago... .. also on 9-track tapes its possible to read off the end of the tape. > Many of the quarter-inch cartridge formats actually don't support block sizes > other than 512 bytes. If they were used on systems that expected to be able to > write larger and/or variable records, the system hardware or software may > have implemented a logical blocking layer on top of the > 512 hardware layer. If you're reading one of these and don't have the original > hardware/software to decode it, you'll have to figure out how to decipher it > yourself. > > De Hope this helps Dave From jdbryan at acm.org Wed Sep 16 15:21:14 2020 From: jdbryan at acm.org (J. David Bryan) Date: Wed, 16 Sep 2020 16:21:14 -0400 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com>, <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org>, Message-ID: On Wednesday, September 16, 2020 at 8:19, Lee Courtney via cctech wrote: > Al - it would be a Very Good Thing to get those APL ROMS dumped when > possible. It would be good as well to dump the Series III main instruction set ROMs, assuming they're socketed. Bitsavers has a Series II microcode listing, and there are some notes available on the microcode changes from the II to the III, but there is no existing Series III listing. I've written reverse-microassemblers for the HP 1000 M-Series and for the 1000 E/F-Series microcode, which could be easily adapted to produce a listing from the 3000 Series III ROMs. -- Dave From lars at nocrew.org Thu Sep 17 03:15:46 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 17 Sep 2020 08:15:46 +0000 Subject: 9 track tapes and block sizes In-Reply-To: <2d5801d68cbd$178de0d0$46a9a270$@gmail.com> (Dave Wade G4UGM via cctalk's message of "Thu, 17 Sep 2020 07:38:01 +0100") References: <20200917055309.189E62BA7F1@yagi.h-net.msu.edu> <2d5801d68cbd$178de0d0$46a9a270$@gmail.com> Message-ID: <7w1rj024zx.fsf@junk.nocrew.org> Dave Wade wrote: > The docs for SIMH .TAP files are here:- > > http://simh.trailing-edge.com/docs/simh_magtape.pdf > > be careful as there are also non-SIMH .tap formats Haha, yes very much so. For the fun of it, people like to mix and match these options: - Records padded to even length or not. - Little or big endian record length metadata. - 9-track or 7-track data (the latter may have a parity bit). From holm at freibergnet.de Thu Sep 17 03:41:10 2020 From: holm at freibergnet.de (Holm Tiffe) Date: Thu, 17 Sep 2020 10:41:10 +0200 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: <20200917084110.GA78121@beast.freibergnet.de> shadoooo via cctalk wrote: > Hello, > I have a question about 9 track tapes and block sizes. > What I know is that tape is subdivided in files by means of marks, and each > file is subdivided in blocks of equal size. > Programs like tar use a specific block size to create files on tape. > However files can have different block sizes like bootloader file, > installation dumps and root file system copy on 2.11BSD. > Now suppose you find and unknown tape you want to preserve: using dd you > could easily 1:1 copy tape files to hard disk files using a SCSI drive and > Linux. > But: how you know which block size is on the tape? > > Thanks > Andrea I've sometimes created my own simh .tap to Boottape converter (an later found out that such a thing exists on the net) to create some boottapes for my pdp11's using a tandberg 8GB quarter inch drive. It worked (on Freebsd). I've installed 2.11BSD and on a KA630 Quasijarus Unix, If you set the blocksize to variable you get back the read byte count from the read() system call und you have to preserve that information to the new copied tape (that's what the .tap formats are made for). I know it is the other way around (.tap->tape) but this is my old q&d tape write program, you hae made the other half yourselves... #include #include #include #include #include #include #include #define MAXBLOCK 50 extern int errno; main() { FILE * ifp; FILE * ofp; unsigned char buf[MAXBLOCK*512]; unsigned char * bufp; unsigned long foffs=0; struct mtop mtio; int blnum,mark,mt; unsigned int blen, tlen; mark=0; if((ifp=fopen("tapefile","r"))==NULL) { fprintf(stderr,"Cant open input file\n"); exit(-1); } if(system("mt -f /dev/sa0 blocksize 0")<0) { fprintf(stderr,"Can't set variable blocksize on /dev/sa0\n"); exit(-1); } if((mt=open("/dev/sa0", O_CREAT|O_TRUNC|O_WRONLY,0666))<0) { fprintf(stderr,"Can't open tape device\n"); exit(-1); } blnum=0; l0: while(1) { if(fread(&blen, sizeof(uint32_t),1,ifp)!=1) { fprintf(stderr,"Can't read blocklen\n"); fclose(ifp); close(mt); exit(-1); } foffs+=sizeof(uint32_t); if(blen==0) { if(mark) { fprintf(stderr,"EOT detected\n"); fclose(ifp); mtio.mt_op = MTWEOF; mtio.mt_count = 2; if (ioctl(mt, MTIOCTOP, &mtio) < 0) fprintf(stderr, "MTIOCTOP err: %d\n", errno); close(mt); exit(0); foffs+=sizeof(uint32_t); if(blen==0) { if(mark) { fprintf(stderr,"EOT detected\n"); fclose(ifp); mtio.mt_op = MTWEOF; mtio.mt_count = 2; if (ioctl(mt, MTIOCTOP, &mtio) < 0) fprintf(stderr, "MTIOCTOP err: %d\n", errno); close(mt); exit(0); } else { fprintf(stderr,"tapemark detected foffs= %08x\n", blen,foffs); mark=1; mtio.mt_op = MTWEOF; mtio.mt_count = 1; if (ioctl(mt, MTIOCTOP, &mtio) < 0) fprintf(stderr, "MTIOCTOP err: %d\n", errno); goto l0; } } else mark=0; fprintf(stderr,"foffs %08x, blen bl %d = %d:%04x\n",foffs,blnum,blen,blen); blnum++; blen=blen&0x0fffffff; // erase error flags if(fread(buf,sizeof(unsigned char),blen,ifp)!=blen) { fprintf(stderr,"Cant read blen %dbytes into buffer\n",blen); fclose(ifp); exit(-1); } if (write(mt, buf, blen) < 0) { fprintf(stderr,"Cant write blen %d bytes into buffer\n",blen ); fclose(ifp); close(mt); exit(1); } foffs+=blen; if(fread(&tlen, sizeof(uint32_t),1,ifp)!=1) { fprintf(stderr,"Cant read trailing blocklen\n"); fclose(ifp); exit(-1); } foffs+=sizeof(uint32_t); if(blen!=tlen) { fprintf(stderr,"heading blocklen %08x != trailing blocklen %08x\n", blen,tlen); fclose(ifp); exit(-1); } bzero(buf,MAXBLOCK*512); } } Regards to Italy, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Goethestrasse 15, 09569 Oederran, USt-Id: DE253710583 info at tsht.de Fax +49 37292 709779 Tel +49 37292 709778 Mobil: 0172 8790 741 From lars at nocrew.org Thu Sep 17 03:59:56 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 17 Sep 2020 08:59:56 +0000 Subject: Care and feeding of some Lisp machines (TI Explorer and Xerox Star) In-Reply-To: (Josh Dersch's message of "Tue, 15 Sep 2020 23:19:56 -0700") References: <8c053d22-64c2-550e-dabc-eadfc791eb8e@multicores.org> <20200914234411.3c9fd8d7@dragonsweb.org> <967CBFA8-DF5F-421A-A4CA-B45C40C59E72@multicores.org> <7b982b61-d8cc-b48b-b9ce-a6d000e9c387@bitsavers.org> <7wsgbi48ei.fsf@junk.nocrew.org> Message-ID: <7wsgbgzskz.fsf@junk.nocrew.org> Josh Dersch wrote: > Not a ton to see, lisp-wise, it's just a port of Franz Lisp to > Uniflex. I can try to benchmark fibonacci later this week if you want. Thanks! I wasn't expecting a benchmark, just a little defun. For the record, I have a Maclisp over here that will do (fib 40) in less than 9 seconds. From matt at 9track.net Thu Sep 17 07:26:01 2020 From: matt at 9track.net (Matt Burke) Date: Thu, 17 Sep 2020 13:26:01 +0100 Subject: 9 track tapes and block sizes In-Reply-To: <2d5801d68cbd$178de0d0$46a9a270$@gmail.com> References: <20200917055309.189E62BA7F1@yagi.h-net.msu.edu> <2d5801d68cbd$178de0d0$46a9a270$@gmail.com> Message-ID: <91aaa0e0-c1da-b2f7-c9bc-1d7c6f764fea@9track.net> On 17/09/2020 07:38, Dave Wade G4UGM via cctalk wrote: > The docs for SIMH .TAP files are here:- > > http://simh.trailing-edge.com/docs/simh_magtape.pdf > > be careful as there are also non-SIMH .tap formats > > In the IBM Mainframe emulation world there is also .AWS, an IBM format > introduced with its P390 Microchannel Mainframe card > and .HET a Hercules extension to .AWS which allows compression > vtapeutils is quite handy for translating between (or listing) a few of the emulated tape formats. It supports AWS, TPC (2 byte record headers) and TAP (Simh - 4 byte record headers). https://sourceforge.net/projects/vtapeutils/ I've used TPC on RSX-11M and VMSTPC on VAX/VMS to read 9-track tapes. Then I used vtapeutils to convert from TPC to TAP format for Simh. Matt From cctalk at v6y.net Thu Sep 17 05:13:18 2020 From: cctalk at v6y.net (Justin Keogh) Date: Thu, 17 Sep 2020 03:13:18 -0700 Subject: Tektronix 4953 Graphics Tablet Message-ID: <160033759849.2330.2610926990364250987@zbook> Hello everyone! I present to you a rare bird; the Tek 4953 graphics tablet, with (I think!?) everything. https://www.ebay.com/itm/203108439922 I am look forward to posting a series of _nice_ Tek terminals and complete DG rack systems. Please contact me directly if you have any questions. -Justin Keogh (520) 265-0034 From paulkoning at comcast.net Thu Sep 17 08:19:02 2020 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 17 Sep 2020 09:19:02 -0400 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: > On Sep 17, 2020, at 1:29 AM, shadoooo via cctalk wrote: > > Hello, > I have a question about 9 track tapes and block sizes. > What I know is that tape is subdivided in files by means of marks, and each > file is subdivided in blocks of equal size. As others have said, no, "equal size" is not a valid assumption. Even for operating systems that use constant data block sizes, the file labels have a different block size. Consider DEC DOS-11 format, which is used by a number of PDP-11 operating systems. That has a 14 byte file label followed by (usually) 512 byte data records. A very common format is ANSI labeled files. These have several 80 byte file labels, a tape mark, data records that can be any size up to "very large" and may or may not be all the same, then another tape mark and another set of 80 byte labels. Other operating systems may be much stranger. Looking at a CDC 6000 series NOS "deadstart" (system boot") tape, the record sizes of the first 12 records are 486, 930, 936, 825, 945, 960, 930, 951, 141, 486, 1266, 3816. And the largest record size is 3846; the shortest is 6 bytes. Yes, that goes against the "rule" which is really just an IBM convention that blocks smaller than 18 bytes are "noise". CDC also supports "long blocks" in which the I/O for a single block is done in pieces, so blocks can be read or written that are longer than what you would think is the limit from the device limits. I'm not sure how long the longest "long block" is. paul From cclist at sydex.com Thu Sep 17 10:31:58 2020 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 17 Sep 2020 08:31:58 -0700 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: On 9/17/20 6:19 AM, Paul Koning via cctalk wrote: > CDC also supports "long blocks" in which the I/O for a single block is done in pieces, so blocks can be read or written that are longer than what you would think is the limit from the device limits. I'm not sure how long the longest "long block" is. When testing out mods to 1LT, the longest record that I ever successfully read and wrote was about half a reel at 556 bpi. Of course, the data was meaningless. This was on a Cyber 74 (6600) using a 657 drive as the target and a derivative of SCOPE 3.1.6 (Special Systems hack). Acoustically, the best tapes were the short-record "stranger" tapes. All sorts of interesting noise. I could tell from across the room when someone was running the tape section of the Navy audit tests for COBOL just by the sounds. --Chuck From elson at pico-systems.com Thu Sep 17 10:56:45 2020 From: elson at pico-systems.com (Jon Elson) Date: Thu, 17 Sep 2020 10:56:45 -0500 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: <5F63873D.4040308@pico-systems.com> On 09/17/2020 12:29 AM, shadoooo via cctalk wrote: > Hello, > I have a question about 9 track tapes and block sizes. > What I know is that tape is subdivided in files by means of marks, and each > file is subdivided in blocks of equal size. This is not necessarily true. Many systems can handle "VBS" (Variable Block Sequential) tape files. But, yes, fixed block size is more common. > Programs like tar use a specific block size to create files on tape. > However files can have different block sizes like bootloader file, > installation dumps and root file system copy on 2.11BSD. > Now suppose you find and unknown tape you want to preserve: using dd you > could easily 1:1 copy tape files to hard disk files using a SCSI drive and > Linux. > But: how you know which block size is on the tape? > OK, the tape formatter will know, and signal the system when reading. So, you would issue a read command to the OS, giving a block size at least as big as the biggest block you expected to see. The formatter/interface would report the number of bytes in that block. Now, when putting a tape image into a disk file, that gets more complicated. There are various "tape container file" schemes where the block size is encoded into the data in some form. If the tape just contains a single file, it may not matter as the data is just a stream of bytes. But, if the tape contains multiple files, then it is pretty important to preserve the record lengths and file marks. I'm a lot more familiar with IBM and DEC tape formats, and had my own container file format to process disk images of tapes. Unix systems support all these options in one way or another, but tar tapes are just a stream of bytes, and I don't think the block size has much effect. Jon From cclist at sydex.com Thu Sep 17 13:11:15 2020 From: cclist at sydex.com (Chuck Guzis) Date: Thu, 17 Sep 2020 11:11:15 -0700 Subject: 9 track tapes and block sizes In-Reply-To: <5F63873D.4040308@pico-systems.com> References: <5F63873D.4040308@pico-systems.com> Message-ID: <126e2ceb-7ce9-1327-f048-ed34f52dcfde@sydex.com> On 9/17/20 8:56 AM, Jon Elson via cctalk wrote: > This is not necessarily true.? Many systems can handle "VBS" (Variable > Block Sequential) tape files. > But, yes, fixed block size is more common. "Hybrid" files are quite common, where all blocks are the same size, but for the last one. Or, in the case of some PDP 11 tapes, there's a short record containing file name, etc. followed by the file data in uniformly-sized blocks, but for the last one in the file. Prior to uniform conventions, tape files were anything that the originator could dream up with regards to block sizes. Very often, the correspondence was 1 record = 1 block. Even the convention of 80 character ANSI tape labels ran afoul of some 36 bit systems, where label records were 81 bytes. --Chuck From paulkoning at comcast.net Thu Sep 17 14:06:39 2020 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 17 Sep 2020 15:06:39 -0400 Subject: 9 track tapes and block sizes In-Reply-To: <126e2ceb-7ce9-1327-f048-ed34f52dcfde@sydex.com> References: <5F63873D.4040308@pico-systems.com> <126e2ceb-7ce9-1327-f048-ed34f52dcfde@sydex.com> Message-ID: > On Sep 17, 2020, at 2:11 PM, Chuck Guzis via cctalk wrote: > > On 9/17/20 8:56 AM, Jon Elson via cctalk wrote: > >> This is not necessarily true. Many systems can handle "VBS" (Variable >> Block Sequential) tape files. >> But, yes, fixed block size is more common. > > "Hybrid" files are quite common, where all blocks are the same size, but > for the last one. Or, in the case of some PDP 11 tapes, there's a short > record containing file name, etc. followed by the file data in > uniformly-sized blocks, but for the last one in the file. Even there you might find some oddities. A RSTS distribution tape, for recent releases, begins with some DOS-11 formatted data, i.e., 14 byte file header and 512 byte data. That is followed by ANSI labelled data, so 80 byte file labels and data in a VMS-style backupset, 2048 byte blocks I think. paul From fmc at reanimators.org Thu Sep 17 17:49:21 2020 From: fmc at reanimators.org (Frank McConnell) Date: Thu, 17 Sep 2020 15:49:21 -0700 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> Message-ID: <4D01819D-7A15-4D31-9AB4-190C466BE7EB@reanimators.org> On Sep 16, 2020, at 5:30, Rodney Brown via cctalk wrote: > > HP 3000 Series 37 on ebay in Germany (7954A, 9144AR, 30457A, 700/92 (German keyboard)) > > https://www.ebay.com.au/itm/HP-3000-Series-37-Computer-System-RETRO-SELTEN-RARE-ca-1985-1987/283988656899 > > Thanks to David Collins at the HP Computer Museum, I now have 11 different versions of the HP 3000 Series 64 [,68,70] microcode SYSWCS64.PUB.SYS > and 3 different versions respectively of each of SYSWCS37 and WCSLE1 and WCSLE2. > I've put notes up at https://en.wikipedia.org/wiki/User:RDBrown/HP3000-WCS-Microcode SYSWCS37 is for a Series 37 (and probably 37XE too which is the expanded-chassis model, the XE is mostly the SIMB expander). I think WCSLE1 is for a "Micro 3000 XE? (and probably also ?Micro 3000? which I think was same thing in a single chassis; faster than Series 37) and WCSLE2 is for the Micro GX/LX/RX (repackaging with CPU, RAM, PIC/GIC on one card) but may be wrong about that. I know I have seen documentation of this, and recently. Ah! HP Channels, Dec 1986, probably from the HP Computer Museum site. > It's possible that one of the SYSWCS64 files may match the assembly listing on bitsavers, but that listing could allow guessing the architecture, assuming horizontal microcode and matching against the HP 3000 stack machine instruction set it implements. There is a Series 64 Reference/Training Manual PDF on bitsavers, that will shed some light on the architecture. It?s fancy: ECL, dual ALUs (driven by wider microcode word), central system bus bridged to up to three IMB-style I/O buses (room in the architecture for a fourth I think), memory cache. Writable control store too (this was not usual for the 3000 product line). In retrospect it looks like they threw everything they had at making a 3000 that would go kinda sorta fast and count have a lot of I/O devices (mostly GICs and ATPs) connected. The ATP was another Series 64 innovation, which was also made to fit on the Series 37 as the TIC and later Micro 3000s as the ATP/M; I think it had a dedicated 6809-like processor for each port?s data transmission needs and another 6809-like processor for every several ports? flow and modem control lines, and I think most of what it did was put something between the terminal and the 3000 that didn?t need to interrupt the 3000 until there was enough received data to actually complete a read request or initiate a break. I am thinking the ?Series 68? upgrade was new front panel plastic and a tape with a new microcode file that implemented changes enabling system table expansions for MPE V/E. ?Series 70? was similar (some frequently used MPE routines were implemented as microcode) but also included hardware changes (memory cache increased from 8K to 128K). > Only the Series 37 rates a mention in the HP Journal, though the common data between the SYSWCS37, WCSLE1 and WCSLE2 suggests they may share a common microcode. Guessing the architecture would be more of a puzzle, unless more documentation is found. Yes. Not very well documented but clearly from the same family, they all use the ?Synchronous IMB? or SIMB bus. One interesting note from one of the HPJ articles is that the console interface that runs at power-up (before microcode is loaded from disc/tape) is not a separate microprocessor like it is on series 64/68/70 (and I think 4x/5x), it is a microprogram from a 16-bit-wide ROM that drives only 16 of the microinstruction word bits. > J. David Bryan's SIMH work gives a running MPE V for anyone to try. Microcoded in C! Note that as it simulates a Series III at present, the MPE is MPE V/R, which is really a roll-up of MPE IV for the Series II/III. MPE V/P had disc caching, MPE V/E had expanded system tables and got updates for a while. MPE V/E T-MIT was the first release supporting ?Mighty Mouse? (Series 37). BUT, one of the special Series 37 instructions is one to tell the microcode whether MPE V/P or MPE V/E is being run! I?m sure development started before the release of MPE V/E and this came in handy for that. -Frank McConnell From fmc at reanimators.org Thu Sep 17 17:51:45 2020 From: fmc at reanimators.org (Frank McConnell) Date: Thu, 17 Sep 2020 15:51:45 -0700 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> Message-ID: <35274959-D788-41B4-AFDA-4C5659F4BFB8@reanimators.org> On Sep 16, 2020, at 13:21, J. David Bryan via cctalk wrote: > > On Wednesday, September 16, 2020 at 8:19, Lee Courtney via cctech wrote: > >> Al - it would be a Very Good Thing to get those APL ROMS dumped when >> possible. > > It would be good as well to dump the Series III main instruction set ROMs, > assuming they're socketed. Bitsavers has a Series II microcode listing, > and there are some notes available on the microcode changes from the II to > the III, but there is no existing Series III listing. It is my belief that the Series II microcode listing was a part of the standard manual set that you got with an HP 3000 Series II. We had one at the high school (where the 3000 started out as a Series II and was upgraded in its chassis to a Series III). Also that the Series III?s microcode listing was not part of the Series III?s standard manual set. We didn?t get an update for it at the high school either. -Frank McConnell From fmc at reanimators.org Thu Sep 17 17:51:45 2020 From: fmc at reanimators.org (Frank McConnell) Date: Thu, 17 Sep 2020 15:51:45 -0700 Subject: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany In-Reply-To: References: <34420c8d-f448-89d6-3065-4aa81125b834@gmail.com> <1e6f5777-f889-87c8-d250-25c04aa79783@bitsavers.org> Message-ID: <35274959-D788-41B4-AFDA-4C5659F4BFB8@reanimators.org> On Sep 16, 2020, at 13:21, J. David Bryan via cctalk wrote: > > On Wednesday, September 16, 2020 at 8:19, Lee Courtney via cctech wrote: > >> Al - it would be a Very Good Thing to get those APL ROMS dumped when >> possible. > > It would be good as well to dump the Series III main instruction set ROMs, > assuming they're socketed. Bitsavers has a Series II microcode listing, > and there are some notes available on the microcode changes from the II to > the III, but there is no existing Series III listing. It is my belief that the Series II microcode listing was a part of the standard manual set that you got with an HP 3000 Series II. We had one at the high school (where the 3000 started out as a Series II and was upgraded in its chassis to a Series III). Also that the Series III?s microcode listing was not part of the Series III?s standard manual set. We didn?t get an update for it at the high school either. -Frank McConnell From c.murray.mccullough at gmail.com Thu Sep 17 19:25:35 2020 From: c.murray.mccullough at gmail.com (Murray McCullough) Date: Thu, 17 Sep 2020 20:25:35 -0400 Subject: Computer History Message-ID: I've recently reread *Fire In The Valley, Ed. 1,2 &3.* They are the seminal, authoritative & comprehensive sources for the history of the microcomputer. We in the classic computer community need to know the history of our hobby to keep it vital and relevant to today's society. More than ever we need to know how microcomputers came about that may be helpful in understanding the role microcomputers play in our lives now. Happy computing all. Murray ? Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From rdawson16 at hotmail.com Thu Sep 17 19:28:16 2020 From: rdawson16 at hotmail.com (Randy Dawson) Date: Fri, 18 Sep 2020 00:28:16 +0000 Subject: Computer History In-Reply-To: References: Message-ID: fix your links. CC yourself and see if you can click on them. ________________________________ From: cctalk on behalf of Murray McCullough via cctalk Sent: Thursday, September 17, 2020 5:25 PM To: cctalk Subject: Computer History I've recently reread *Fire In The Valley, Ed. 1,2 &3.* They are the seminal, authoritative & comprehensive sources for the history of the microcomputer. We in the classic computer community need to know the history of our hobby to keep it vital and relevant to today's society. More than ever we need to know how microcomputers came about that may be helpful in understanding the role microcomputers play in our lives now. Happy computing all. Murray ? Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From billdegnan at gmail.com Thu Sep 17 19:31:36 2020 From: billdegnan at gmail.com (Bill Degnan) Date: Thu, 17 Sep 2020 20:31:36 -0400 Subject: Computer History In-Reply-To: References: Message-ID: +1 On Thu, Sep 17, 2020 at 8:25 PM Murray McCullough via cctalk < cctalk at classiccmp.org> wrote: > I've recently reread *Fire In The Valley, Ed. 1,2 &3.* They are the > seminal, authoritative & comprehensive sources for the history of the > microcomputer. We in the classic computer community need to know the > history of our hobby to keep it vital and relevant to today's society. More > than ever we need to know how microcomputers came about that may be helpful > in understanding the role microcomputers play in our lives now. > > Happy computing all. > > Murray ? > > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > Virus-free. > www.avg.com > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > From paulkoning at comcast.net Thu Sep 17 19:40:57 2020 From: paulkoning at comcast.net (Paul Koning) Date: Thu, 17 Sep 2020 20:40:57 -0400 Subject: Computer History In-Reply-To: References: Message-ID: > On Sep 17, 2020, at 8:28 PM, Randy Dawson via cctalk wrote: > > fix your links. CC yourself and see if you can click on them. Which links? You mean the "virus-free" thing at the bottom? That's just .signature spam. I don't know why people put that in, especially since a declaration in a piece of mail that it's "virus-free" isn't worth the electrons it's written on. paul From jwsmail at jwsss.com Thu Sep 17 19:41:54 2020 From: jwsmail at jwsss.com (jim stephens) Date: Thu, 17 Sep 2020 17:41:54 -0700 Subject: Computer History In-Reply-To: References: Message-ID: <6b9b00ed-b0c3-334d-504b-e3a85a3f3133@jwsss.com> The links are to his anti virus pages, or email client filtered thru there.? Noting to see here, move along. Seriously, you need to dig out the link, trim all the crap after the ampersand, so that we don't inherit a bunch of tracking cookie crumbs, test it and forward. Thanks, would love to read anything you share. thanks Jim On 9/17/2020 5:28 PM, Randy Dawson via cctalk wrote: > fix your links. CC yourself and see if you can click on them. > > ________________________________ > From: cctalk on behalf of Murray McCullough via cctalk > Sent: Thursday, September 17, 2020 5:25 PM > To: cctalk > Subject: Computer History > > I've recently reread *Fire In The Valley, Ed. 1,2 &3.* They are the > seminal, authoritative & comprehensive sources for the history of the > microcomputer. We in the classic computer community need to know the > history of our hobby to keep it vital and relevant to today's society. More > than ever we need to know how microcomputers came about that may be helpful > in understanding the role microcomputers play in our lives now. > > Happy computing all. > > Murray ? > > > Virus-free. > www.avg.com > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > From cisin at xenosoft.com Thu Sep 17 20:04:05 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Thu, 17 Sep 2020 18:04:05 -0700 (PDT) Subject: Computer History In-Reply-To: References: Message-ID: >> fix your links. CC yourself and see if you can click on them. On Thu, 17 Sep 2020, Paul Koning via cctalk wrote: > Which links? You mean the "virus-free" thing at the bottom? That's just .signature spam. I don't know why people put that in, especially since a declaration in a piece of mail that it's "virus-free" isn't worth the electrons it's written on. When people install AVG anti-virus, it alters their signature to insert an ad for itself. WITHOUT their authorization, or, usually, awareness. THAT may not be as dangerous, but it's still malware. From mjkerpan at kerpan.com Thu Sep 17 21:18:49 2020 From: mjkerpan at kerpan.com (Michael Kerpan) Date: Thu, 17 Sep 2020 22:18:49 -0400 Subject: Exploring early GUIs Message-ID: Something in another recent thread about LISP machines got me wondering: how many early graphical systems are well emulated (or emulated at all)? I know that there are more or less functional emulations of Alto, Star, and Lisa out there, but what about the various LISP machines or the early workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators for some of these systems out there, has any software to run on them and been archived? Mike From tdk.knight at gmail.com Thu Sep 17 21:37:11 2020 From: tdk.knight at gmail.com (Adrian Stoness) Date: Thu, 17 Sep 2020 21:37:11 -0500 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: would early gui include hmi systems On Thu, Sep 17, 2020 at 9:19 PM Michael Kerpan via cctalk < cctalk at classiccmp.org> wrote: > Something in another recent thread about LISP machines got me wondering: > how many early graphical systems are well emulated (or emulated at all)? I > know that there are more or less functional emulations of Alto, Star, and > Lisa out there, but what about the various LISP machines or the early > workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators > for some of these systems out there, has any software to run on them and > been archived? > > Mike > From jlw at jlw.com Thu Sep 17 20:13:14 2020 From: jlw at jlw.com (Jeff Woolsey) Date: Thu, 17 Sep 2020 18:13:14 -0700 Subject: 9 track tapes and block sizes In-Reply-To: <91aaa0e0-c1da-b2f7-c9bc-1d7c6f764fea@9track.net> References: <91aaa0e0-c1da-b2f7-c9bc-1d7c6f764fea@9track.net> Message-ID: > On 17/09/2020 07:38, Dave Wade G4UGM via cctalk wrote: > >/The docs for SIMH .TAP files are here:- />//>/http://simh.trailing-edge.com/docs/simh_magtape.pdf />//>/be careful as there are also non-SIMH .tap formats />//>/In the IBM Mainframe emulation world there is also .AWS, an IBM format />/introduced with its P390 Microchannel Mainframe card />/and .HET a Hercules extension to .AWS which allows compression />// > vtapeutils is quite handy for translating between (or listing) a few of > the emulated tape formats. It supports AWS, TPC (2 byte record headers) > and TAP (Simh - 4 byte record headers). > > https://sourceforge.net/projects/vtapeutils/ > > I've used TPC on RSX-11M and VMSTPC on VAX/VMS to read 9-track tapes. > Then I used vtapeutils to convert from TPC to TAP format for Simh. > > Matt > I have over 1000 TAP images in my collection, so I thought I'd give this a whirl.? It's handy for a quick summary of what the TAP image is.? However, documentation is a bit light, as is its robustness for corrupt TAP images (of which I have plenty), although it seems forgiving of unpadded blocks (unlike another, stricter tool I could mention). For unlabelled tapes, it lists block count and min and max block size for each file. Nice. But it does not do that for labelled tapes; instead they get the labels that enclose each dataset decoded, and the number of blocks is reported and checked.? A warning is printed if the actual block count differs.? Sometimes this warning is incorrect, reporting 0 or a large negative number (-17342528 usually) of blocks.? It is usually correct for those of my tapes that have duplicate blocks (which I don't expect it to detect/report otherwise).? The 0s might be extraneous EOF1/EOV1 labels.? The negatives might be extraneous tapemarks.? Or stuff past EOI. It would be nice if it printed the name of the TAP file in its report. Built from source (edited Makefile to add $(CC) ).??? I didn't try vtapecp. -- 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 jlw at jlw.com Thu Sep 17 20:17:49 2020 From: jlw at jlw.com (Jeff Woolsey) Date: Thu, 17 Sep 2020 18:17:49 -0700 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: <14444db4-7e87-950a-def7-f9d2eb9231ad@jlw.com> > Acoustically, the best tapes were the short-record "stranger" tapes. > All sorts of interesting noise. I could tell from across the room when > someone was running the tape section of the Navy audit tests for COBOL > just by the sounds. > MALET was also pretty good, reading and writing a bunch of blocks that were one frame longer or shorter than the last.? Loud rising or falling tone in the noisy computer room. -- 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 lars at nocrew.org Fri Sep 18 00:17:44 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 18 Sep 2020 05:17:44 +0000 Subject: Computer History In-Reply-To: (Murray McCullough via cctalk's message of "Thu, 17 Sep 2020 20:25:35 -0400") References: Message-ID: <7wpn6jwtmv.fsf@junk.nocrew.org> Murray McCullough wrote: > We in the classic computer community need to know the history of our > hobby I for bigger iron history, I suggest "Dream Machine" by Waldrop. It's not just about Licklider, though his is a very interesting story by itself. From shadoooo at gmail.com Fri Sep 18 00:40:16 2020 From: shadoooo at gmail.com (shadoooo) Date: Fri, 18 Sep 2020 07:40:16 +0200 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: dear all, thanks for the useful informations! So now a question comes to mind... what is the best utility for Linux to be used to read and archive tapes? Thanks Andrea From pat at vax11.net Fri Sep 18 07:21:06 2020 From: pat at vax11.net (Patrick Finnegan) Date: Fri, 18 Sep 2020 08:21:06 -0400 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: I usually use tapeutils: https://github.com/brouhaha/tapeutils Pat On Fri, Sep 18, 2020 at 1:40 AM shadoooo via cctalk wrote: > dear all, > thanks for the useful informations! > So now a question comes to mind... > what is the best utility for Linux to be used to read and archive tapes? > > Thanks > Andrea > > From paulkoning at comcast.net Fri Sep 18 08:35:13 2020 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 18 Sep 2020 09:35:13 -0400 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: > On Sep 17, 2020, at 10:18 PM, Michael Kerpan via cctalk wrote: > > Something in another recent thread about LISP machines got me wondering: > how many early graphical systems are well emulated (or emulated at all)? I > know that there are more or less functional emulations of Alto, Star, and > Lisa out there, but what about the various LISP machines or the early > workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators > for some of these systems out there, has any software to run on them and > been archived? > > Mike One system that could be considered a GUI, or at least the beginnings of one, is the PLATO system. Emulations of that are alive and well, in particular the system described at cyber1.org. paul From paulkoning at comcast.net Fri Sep 18 08:36:37 2020 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 18 Sep 2020 09:36:37 -0400 Subject: Computer History In-Reply-To: References: Message-ID: <451F8526-DDF8-442E-94A7-2B034BE87359@comcast.net> > On Sep 17, 2020, at 9:04 PM, Fred Cisin via cctalk wrote: > >>> fix your links. CC yourself and see if you can click on them. > > On Thu, 17 Sep 2020, Paul Koning via cctalk wrote: >> Which links? You mean the "virus-free" thing at the bottom? That's just .signature spam. I don't know why people put that in, especially since a declaration in a piece of mail that it's "virus-free" isn't worth the electrons it's written on. > > When people install AVG anti-virus, it alters their signature to insert an ad for itself. WITHOUT their authorization, or, usually, awareness. THAT may not be as dangerous, but it's still malware. Clearly that's a sufficient reason to consider that software to be malware and never use it for any purpose. But in addition, such a message in the signature is clearly meaningless because it could just as easily be inserted there by a virus as by an anti-virus. paul From lars at nocrew.org Fri Sep 18 08:51:21 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 18 Sep 2020 13:51:21 +0000 Subject: Exploring early GUIs In-Reply-To: (Michael Kerpan via cctalk's message of "Thu, 17 Sep 2020 22:18:49 -0400") References: Message-ID: <7wlfh7tcpy.fsf@junk.nocrew.org> Michael Kerpan wrote: > Something in another recent thread about LISP machines got me > wondering: how many early graphical systems are well emulated (or > emulated at all)? I know that there are more or less functional > emulations of Alto, Star, and Lisa out there, but what about the > various LISP machines There are emulators for the CADR Lisp machine and a lot of software has been preserved. There's no emulators for the CONS, but I claim it would be interesting to attempt one. Now NLS and TX-2 emulators, that would be something. From aek at bitsavers.org Fri Sep 18 09:53:24 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 18 Sep 2020 07:53:24 -0700 Subject: 9 track tapes and block sizes In-Reply-To: References: Message-ID: On 9/18/20 5:21 AM, Patrick Finnegan via cctalk wrote: > I usually use tapeutils: > https://github.com/brouhaha/tapeutils > I should bug Eric about this, but the .tap files that library creates doesn't have the Supnik SIMH extensions I use it for all of the SCSI recoveries that I do on Linux machines. It also works with 1/4" cartridges but you want to keep the block size at 512 so that if there is a bad physical block it will only return that one block as bad instead of however many blocks the read attempts to return. From lars at nocrew.org Fri Sep 18 10:17:04 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 18 Sep 2020 15:17:04 +0000 Subject: 9 track tapes and block sizes In-Reply-To: (Al Kossow via cctalk's message of "Fri, 18 Sep 2020 07:53:24 -0700") References: Message-ID: <7w7dsrt8r3.fsf@junk.nocrew.org> Al Kossow wrote: >> I usually use tapeutils: >> https://github.com/brouhaha/tapeutils > > I should bug Eric about this, but the .tap files that library creates > doesn't have the Supnik SIMH extensions In case Eric doesn't have time to make updates, bug me instead. I'm kind of maintaining that. From aek at bitsavers.org Fri Sep 18 10:44:18 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 18 Sep 2020 08:44:18 -0700 Subject: 9 track tapes and block sizes In-Reply-To: <7w7dsrt8r3.fsf@junk.nocrew.org> References: <7w7dsrt8r3.fsf@junk.nocrew.org> Message-ID: On 9/18/20 8:17 AM, Lars Brinkhoff wrote: > I'm kind of maintaining that. > where? Are you feeding the changes back to Eric or have you come up with your own no one knows about it except you version? the issues will be in the tap library from John Wilson From aek at bitsavers.org Fri Sep 18 10:45:30 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 18 Sep 2020 08:45:30 -0700 Subject: 9 track tapes and block sizes In-Reply-To: References: <7w7dsrt8r3.fsf@junk.nocrew.org> Message-ID: On 9/18/20 8:44 AM, Al Kossow via cctalk wrote: > On 9/18/20 8:17 AM, Lars Brinkhoff wrote: > >> I'm kind of maintaining that. >> > > where? > Are you feeding the changes back to Eric or have you come up with your > own no one knows about it except you version? > > the issues will be in the tap library from John Wilson and since your fscking around inside of it, have you added the Bordynuik extensions in the ToTS tape images? From lars at nocrew.org Fri Sep 18 11:42:40 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 18 Sep 2020 16:42:40 +0000 Subject: 9 track tapes and block sizes In-Reply-To: (Al Kossow's message of "Fri, 18 Sep 2020 08:44:18 -0700") References: <7w7dsrt8r3.fsf@junk.nocrew.org> Message-ID: <7wwo0rrq7z.fsf@junk.nocrew.org> Al Kossow wrote: >> I'm kind of maintaining that. > where? Here: https://github.com/brouhaha/tapeutils > and since your fscking around inside of it, have you added the > Bordynuik extensions in the ToTS tape images? No, but I certainly will if yout tell me what it is. From dave.dunfield at gmail.com Fri Sep 18 12:52:15 2020 From: dave.dunfield at gmail.com (Dave Dunfield) Date: Fri, 18 Sep 2020 13:52:15 -0400 Subject: What I've been doing lately Message-ID: >Very interesting. By the way I've been reading your comments about your >incident in 2019. I am impressed. All the best for you and your near people. >Kind Regards >Sergio Thanks! It's been an "interesting" year! Btw, for anyone who was interested enough to download my DVM demo... I've made a lot of updates, additions, improvements, and fixed a few bugs. Might be worth grabbing it again. Dave ---------------------------------------------------------------------------------- Personal site: http://dunfield.maknonsolutions.com Check out "DVM" - run custom apps. anywhere! From jacob at dahl-pind.dk Fri Sep 18 13:23:07 2020 From: jacob at dahl-pind.dk (jacob at dahl-pind.dk) Date: Fri, 18 Sep 2020 20:23:07 +0200 (CEST) Subject: Exploring early GUIs In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020, Michael Kerpan via cctalk wrote: > Something in another recent thread about LISP machines got me wondering: > how many early graphical systems are well emulated (or emulated at all)? I > know that there are more or less functional emulations of Alto, Star, and > Lisa out there, but what about the various LISP machines or the early > workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators > for some of these systems out there, has any software to run on them and > been archived? > > Mike > Mame can emulate the Apollo Domain machines, https://wiki.mamedev.org/index.php/Driver:Apollo Regards -- Jacob Dahl Pind | telefisk.org | fidonet 2:230/38.8 From raywjewhurst at gmail.com Fri Sep 18 14:30:24 2020 From: raywjewhurst at gmail.com (Ray Jewhurst) Date: Fri, 18 Sep 2020 15:30:24 -0400 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: Also available on MAME is HP VUE on the 9000/360 and 370 and not a super early GUI but quite breathtaking is Irix on the SGI Indy. Directions to set up both are all over the web. Ray On Fri, Sep 18, 2020, 2:23 PM jacob--- via cctalk wrote: > On Thu, 17 Sep 2020, Michael Kerpan via cctalk wrote: > > > Something in another recent thread about LISP machines got me wondering: > > how many early graphical systems are well emulated (or emulated at all)? > I > > know that there are more or less functional emulations of Alto, Star, and > > Lisa out there, but what about the various LISP machines or the early > > workstations (Sun 68K, Apollo, etc) Also, assuming that there are > emulators > > for some of these systems out there, has any software to run on them and > > been archived? > > > > Mike > > > > Mame can emulate the Apollo Domain machines, > https://wiki.mamedev.org/index.php/Driver:Apollo > > Regards > > -- > Jacob Dahl Pind | telefisk.org | fidonet 2:230/38.8 > > From couryhouse at aol.com Fri Sep 18 14:48:17 2020 From: couryhouse at aol.com (ED SHARPE) Date: Fri, 18 Sep 2020 19:48:17 +0000 (UTC) Subject: Exploring early GUIs References: <2072686656.4022118.1600458497672.ref@mail.yahoo.com> Message-ID: <2072686656.4022118.1600458497672@mail.yahoo.com> I re mn ember? GEm5 as a guide ran under dos .? . Ed# On Friday, September 18, 2020 Paul Koning via cctalk wrote: > On Sep 17, 2020, at 10:18 PM, Michael Kerpan via cctalk wrote: > > Something in another recent thread about LISP machines got me wondering: > how many early graphical systems are well emulated (or emulated at all)? I > know that there are more or less functional emulations of Alto, Star, and > Lisa out there, but what about the various LISP machines or the early > workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators > for some of these systems out there, has any software to run on them and > been archived? > > Mike One system that could be considered a GUI, or at least the beginnings of one, is the PLATO system.? Emulations of that are alive and well, in particular the system described at cyber1.org. ??? paul From mechanic_2 at charter.net Fri Sep 18 14:52:16 2020 From: mechanic_2 at charter.net (Richard Pope) Date: Fri, 18 Sep 2020 14:52:16 -0500 Subject: Exploring early GUIs In-Reply-To: <2072686656.4022118.1600458497672@mail.yahoo.com> References: <2072686656.4022118.1600458497672.ref@mail.yahoo.com> <2072686656.4022118.1600458497672@mail.yahoo.com> Message-ID: <5F650FF0.5020503@charter.net> Hello all, There are emulations of the Amiga out there. GOD Bless and Thanks, rich! >> On Sep 17, 2020, at 10:18 PM, Michael Kerpan via cctalk wrote: >> >> Something in another recent thread about LISP machines got me wondering: >> how many early graphical systems are well emulated (or emulated at all)? I >> know that there are more or less functional emulations of Alto, Star, and >> Lisa out there, but what about the various LISP machines or the early >> workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators >> for some of these systems out there, has any software to run on them and >> been archived? >> >> Mike From paulkoning at comcast.net Fri Sep 18 14:56:56 2020 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 18 Sep 2020 15:56:56 -0400 Subject: Exploring early GUIs In-Reply-To: <2072686656.4022118.1600458497672@mail.yahoo.com> References: <2072686656.4022118.1600458497672.ref@mail.yahoo.com> <2072686656.4022118.1600458497672@mail.yahoo.com> Message-ID: <135249F9-A012-4B37-B710-2B7E2F10AB4D@comcast.net> > On Sep 18, 2020, at 3:48 PM, ED SHARPE via cctalk wrote: > > > I re mn ember GEm5 as a guide ran under dos . . > Ed# > On Friday, September 18, 2020 Paul Koning via cctalk wrote: > > >> On Sep 17, 2020, at 10:18 PM, Michael Kerpan via cctalk wrote: >> >> Something in another recent thread about LISP machines got me wondering: >> how many early graphical systems are well emulated (or emulated at all)? I >> know that there are more or less functional emulations of Alto, Star, and >> Lisa out there, but what about the various LISP machines or the early >> workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators >> for some of these systems out there, has any software to run on them and >> been archived? >> >> Mike > > One system that could be considered a GUI, or at least the beginnings of one, is the PLATO system. Emulations of that are alive and well, in particular the system described at cyber1.org. > > paul I'm not sure about the year that goes with the various examples people mentioned. DOS implies 1980s. Apollo ditto. PLATO started in 1961, though the current generation (PLATO IV) with the full graphics plasma panel terminals is from the early 1970s. paul From dave.g4ugm at gmail.com Fri Sep 18 15:27:15 2020 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Fri, 18 Sep 2020 21:27:15 +0100 Subject: Exploring early GUIs In-Reply-To: <2072686656.4022118.1600458497672@mail.yahoo.com> References: <2072686656.4022118.1600458497672.ref@mail.yahoo.com> <2072686656.4022118.1600458497672@mail.yahoo.com> Message-ID: <595a01d68dfa$19543de0$4bfcb9a0$@gmail.com> Not sure if I missed it but the Atari ST also ran GEM from ROM. I have been using mine recently with a GoTek and Flash Floppy. There are many emulators. I remember when I first used it being fascinated by the fact you could do many tasks without using the keyboard. Mind you I generally used it with Gulam a "unix like" shell with a built in Micro Emacs. Dave G4UGM > -----Original Message----- > From: cctalk On Behalf Of ED SHARPE via > cctalk > Sent: 18 September 2020 20:48 > To: mjkerpan at kerpan.com; cctalk at classiccmp.org > Subject: Re: Exploring early GUIs > > > I re mn ember GEm5 as a guide ran under dos . . > Ed# > On Friday, September 18, 2020 Paul Koning via cctalk > wrote: > > > > On Sep 17, 2020, at 10:18 PM, Michael Kerpan via cctalk > wrote: > > > > Something in another recent thread about LISP machines got me wondering: > > how many early graphical systems are well emulated (or emulated at > > all)? I know that there are more or less functional emulations of > > Alto, Star, and Lisa out there, but what about the various LISP > > machines or the early workstations (Sun 68K, Apollo, etc) Also, > > assuming that there are emulators for some of these systems out there, > > has any software to run on them and been archived? > > > > Mike > > One system that could be considered a GUI, or at least the beginnings of one, is > the PLATO system. Emulations of that are alive and well, in particular the > system described at cyber1.org. > > paul From rich.cini at gmail.com Fri Sep 18 20:46:01 2020 From: rich.cini at gmail.com (Richard Cini) Date: Sat, 19 Sep 2020 01:46:01 +0000 Subject: Vintage BBS setup for demo Message-ID: Is there anyone on-list with experience setting-up a Searchlight (or similar) BBS? I have mine up and running with multiple dial-up nodes (for a hopeful future VCF demonstration) but I?m having problems with setting up the file areas properly. If someone could drop me a note off-list, I?d appreciate it. Thanks! Rich http://www.classiccmp.org/cini Long Island S100 User?s Group Get Outlook for iOS From engel at multicores.org Sat Sep 19 07:50:49 2020 From: engel at multicores.org (Michael Engel) Date: Sat, 19 Sep 2020 14:50:49 +0200 Subject: Tektronix 440x photos Message-ID: <5abff1ea-c896-5619-0b8a-d693ba8d201e@multicores.org> I managed to take some pictures of our Tektronix Smalltalk machines today: https://multicores.org/pictures/Tektronix_440x/ Both 4404s are identical, including the firmware versions in the EPROMs. The 4406 is a bit harder to disassemble, this will take some more time. All of the photos inside this directory are released into the public domain (and I should get a tripod and better lighting...). Trying to get our ancient EPROM programmer to work now... -- Michael From jnc at mercury.lcs.mit.edu Sat Sep 19 11:00:16 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 19 Sep 2020 12:00:16 -0400 (EDT) Subject: Exploring early GUIs Message-ID: <20200919160016.E3BCE18C0DB@mercury.lcs.mit.edu> > From: Lars Brinkhoff > There are emulators for the CADR Lisp machine ... There's no emulators > for the CONS, but I claim it would be interesting to attempt one. I'm not sure CONS ever ran as a stand-alone system; I suspect (but don't recall for sure; RG, TK or Moon or someone could confirm one way or the other) that it ran as a loosely-coupled co-processor to MC, the way the Chess Machine did. The CONS and the Chess Machine were both in the same room; 906-907 or so: https://gunkies.org/wiki/File:9th_floor_techsquare.png When the first CADR was built, its console was in the room next door (in the higher-numbered room direction); I remember watching over Moon's shouulder the night they first tried to boot it. Noel From lars at nocrew.org Sat Sep 19 14:48:48 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 19 Sep 2020 19:48:48 +0000 Subject: Exploring early GUIs In-Reply-To: <20200919160016.E3BCE18C0DB@mercury.lcs.mit.edu> (Noel Chiappa via cctalk's message of "Sat, 19 Sep 2020 12:00:16 -0400 (EDT)") References: <20200919160016.E3BCE18C0DB@mercury.lcs.mit.edu> Message-ID: <7w363dpmxr.fsf@junk.nocrew.org> Noel Chiappa wrote: > I'm not sure CONS ever ran as a stand-alone system; I suspect (but > don't recall for sure; RG, TK or Moon or someone could confirm one way > or the other) that it ran as a loosely-coupled co-processor to MC, the > way the Chess Machine did. I believe you are entirely correct, except it was AI rather than MC. As I'm sure you know, AI had the Rubin 10-11 interface with eight Unibuses for attaching processors through shared memory. MC had the DTE20 and DL10, but those were for PDP-11 front ends. The Chess Machine CHEOPS was used with MacHack VI running on MC, but communicating over Chaosnet. At least, that's how I interpret the code in MacHack. This doesn't make me less interested in emulating both CONS and CHEOPS. Time permitting - which it doesn't. I don't see any technical obstacles; we already have one of the 10-11 processors working. I have reviewed the amount of preserved software, and I think chances are good microcode and microassemblers for CONS and CHEOPS still exist. There is some debate over whether the CONS had a display of its own, and if so whether it could draw to a bitmap. Do you remember? As a mid-70s technology, it might be a contender for one of the early GUIs this thread is about. > The CONS and the Chess Machine were both in the same room; 906-907 or > so: [...] When the first CADR was built, its console was in the room > next door (in the higher-numbered room direction); I remember watching > over Moon's shouulder the night they first tried to boot it. I have talked to Lispm enthusiasts, and they have a hard time pinpointing a birthdate for the CADR. Do you have a recollection when, even what year, the first boot attempt was? My information says room 907 at various points in time housed CADR-1, "Chess, Lisp machines", Lisp Machine Consoles, GT40 (Lisp machine). From camiel at vaxbarn.com Sun Sep 20 02:04:44 2020 From: camiel at vaxbarn.com (Camiel Vanderhoeven) Date: Sun, 20 Sep 2020 09:04:44 +0200 Subject: Looking for Logicraft Omni-Ware Message-ID: <3D02FEC3-368F-4462-B3BA-54331131BE14@vaxbarn.com> I?m looking for a piece of software called Omni-Ware for VMS or UNIX , by a Nashua company called Logicraft. I?ve just received the pieces to build a Logicraft PC (286 motherboard with custom BIOS and a special network card that emulates the keyboard, mouse, CGA video card and hard disk). I also received the documentation for the VAX/VMS version of the software, but I?m now looking for the accompanying software for VMS or UNIX. The idea is to install this software on a workstation, and connect it to the Omni-Ware PC. The PC then boots off a disk image stored on the workstation, with input and output in an X-Windows window. Logicraft apparently supplied disk images with DOS, Xenix, OS/2 or MS Windows installed. I?m really hoping someone has a copy of this software still lying around somewhere. Cheers, Camiel From jnc at mercury.lcs.mit.edu Sun Sep 20 12:56:44 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 20 Sep 2020 13:56:44 -0400 (EDT) Subject: Exploring early GUIs Message-ID: <20200920175644.967E018C0E7@mercury.lcs.mit.edu> > From: Lars Brinkhoff > it was AI rather than MC. As I'm sure you know, AI had the Rubin 10-11 > interface Really? (I expect you're correct, mind.) I just remember one day MC wasn't running as normal, and I was told it was because CHEOPS was in some tournament, and MC had been taken offline so that it could focus on the game. So I assumed CHEOPS was connected to MC (and had indeed wondered why/how, when I wrote that message, with the Rubin interface being on AI). > communicating over Chaosnet. At least, that's how I interpret the code > in MacHack. Again, probably right. It was pretty early, but I guess the CHAOSNET was already running then. My guess is that AI didn't do much but act as a communication node between CHEOPS and MC, for that. > There is some debate over whether the CONS had a display of its own, and > if so whether it could draw to a bitmap. Do you remember? Not explicily, but I would tend to guess 'no'; I would tend to guess that they were still in the mindset where it was a specialized co-processor, like CHEOPS. I certainly don't recall a 'CONS display' in the room where the first CADR display was; but that doesn't mean much. (Actually, I'm not positive there was a CADR display in there the night I recall Moon trying to get it running; for sure a Knight TV console, and he may have been using it to run something on it to poke at the CADR.) > they have a hard time pinpointing a birthdate for the CADR. Do you have > a recollection when, even what year, the first boot attempt was? Sorry, no; it only stuck in my memory because I was later taken at having beeen there for the early CADR work; I think that night I only barely knew what a CADR was. (I was kind of amused that Moon's audience that night was someone from LCS... :-) I mean, it was pretty early, but I have no idea of even what year it was. Noel From aek at bitsavers.org Sun Sep 20 13:49:04 2020 From: aek at bitsavers.org (Al Kossow) Date: Sun, 20 Sep 2020 11:49:04 -0700 Subject: Interface Technology RS-432 manual Message-ID: <91c88649-03f0-b75f-9591-5aaab39a432d@bitsavers.org> I don't remember if this was discussed here recently here or on the VCF site, I found one message here about it. Found the manual going through some test equipment manual boxes http://bitsavers.org/test_equipment/interfaceTechnology/Interface_Technology_RS-432_Microprocessor_Controlled_Data_and_Timing_Generator_198004.pdf From spam at hell.org Sun Sep 20 16:17:47 2020 From: spam at hell.org (Mike Begley) Date: Sun, 20 Sep 2020 21:17:47 +0000 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: There's also the windowing system used on the AT&T 3B1 (AKA Unix PC, AK PC7300), which I think was called MGR. It may have also been ported to other systems as well. When I had one of these machines it was adequate, although terribly slow on a 512K system. There's a writeup, with images, here: http://toastytech.com/guis/unixpc.html and apparently an emulator here: https://www.philpem.me.uk/code/3b1emu I have a parted-out 7300 in my closet, but I'm not sure I have all the pieces. Part of me thinks I should dig it out and revive it, part of me thinks I should let sleeping dogs lie... -mike -----Original Message----- From: cctalk On Behalf Of Michael Kerpan via cctalk Sent: Thursday, September 17, 2020 7:19 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Exploring early GUIs Something in another recent thread about LISP machines got me wondering: how many early graphical systems are well emulated (or emulated at all)? I know that there are more or less functional emulations of Alto, Star, and Lisa out there, but what about the various LISP machines or the early workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators for some of these systems out there, has any software to run on them and been archived? Mike From fmc at reanimators.org Sun Sep 20 20:01:22 2020 From: fmc at reanimators.org (Frank McConnell) Date: Sun, 20 Sep 2020 18:01:22 -0700 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: On Sep 17, 2020, at 19:18, Michael Kerpan wrote: > Something in another recent thread about LISP machines got me wondering: > how many early graphical systems are well emulated (or emulated at all)? I > know that there are more or less functional emulations of Alto, Star, and > Lisa out there, but what about the various LISP machines or the early > workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators > for some of these systems out there, has any software to run on them and > been archived? Something in the "early graphical" space that I think may be difficult or impossible to emulate: the Culler-Fried Online System. I think it was built around an IBM 360 and operated at one site (UCSB) late 1960s into 1970s with the goal of running a particular educational/research application programming environment, CHM has one of the dual keyboards, and I am not at all certain that software exists. Not so early to timesharing (late 1960s) but using storage scopes for graphical output terminals. Al has a couple manuals in . So we can get some idea of what it was like. -Frank McConnell From lars at nocrew.org Mon Sep 21 02:45:36 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 21 Sep 2020 07:45:36 +0000 Subject: Exploring early GUIs In-Reply-To: <20200920175644.967E018C0E7@mercury.lcs.mit.edu> (Noel Chiappa's message of "Sun, 20 Sep 2020 13:56:44 -0400 (EDT)") References: <20200920175644.967E018C0E7@mercury.lcs.mit.edu> Message-ID: <7w4knrlgin.fsf@junk.nocrew.org> Noel Chiappa wrote: > > it was AI rather than MC. As I'm sure you know, AI had the Rubin > > 10-11 interface > > Really? (I expect you're correct, mind.) I just remember one day MC > wasn't running as normal, and I was told it was because CHEOPS was in > some tournament, and MC had been taken offline so that it could focus > on the game. So I assumed CHEOPS was connected to MC (and had indeed > wondered why/how, when I wrote that message, with the Rubin interface > being on AI). The MaHack sources seem to say it was made to run on the KL10 out of timesharing, so I suppose the intent was to really have the full machine dedicated to chess. I hope it did well! > It was pretty early, but I guess the CHAOSNET was already running > then. My guess is that AI didn't do much but act as a communication > node between CHEOPS and MC, for that. I think that's correct. From john at yoyodyne-propulsion.net Mon Sep 21 02:46:52 2020 From: john at yoyodyne-propulsion.net (John Many Jars) Date: Mon, 21 Sep 2020 08:46:52 +0100 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: I have an SGI Indy that some idiot (tm) (okay, it was me) put Linux on. Anyone have any way to undo my mistake? (: I'd like to get the thing running properly again, if it even still powers up. I imagine the HD is probably knackered by now anyway. On Fri, 18 Sep 2020 at 20:30, Ray Jewhurst via cctalk wrote: > Also available on MAME is HP VUE on the 9000/360 and 370 and not a super > early GUI but quite breathtaking is Irix on the SGI Indy. Directions to set > up both are all over the web. > > Ray > > On Fri, Sep 18, 2020, 2:23 PM jacob--- via cctalk > wrote: > > > On Thu, 17 Sep 2020, Michael Kerpan via cctalk wrote: > > > > > Something in another recent thread about LISP machines got me > wondering: > > > how many early graphical systems are well emulated (or emulated at > all)? > > I > > > know that there are more or less functional emulations of Alto, Star, > and > > > Lisa out there, but what about the various LISP machines or the early > > > workstations (Sun 68K, Apollo, etc) Also, assuming that there are > > emulators > > > for some of these systems out there, has any software to run on them > and > > > been archived? > > > > > > Mike > > > > > > > Mame can emulate the Apollo Domain machines, > > https://wiki.mamedev.org/index.php/Driver:Apollo > > > > Regards > > > > -- > > Jacob Dahl Pind | telefisk.org | fidonet 2:230/38.8 > > > > > -- Yoyodyne Propulsion Systems: "The Future Begins Tomorrow" Visit us at: http://www.yoyodyne-propulsion.net -------- "When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him." -- Jonathan Swift From ccth6600 at gmail.com Mon Sep 21 06:41:48 2020 From: ccth6600 at gmail.com (Tom Hunter) Date: Mon, 21 Sep 2020 19:41:48 +0800 Subject: Osborne 1 keyboard repair? Message-ID: I am trying to figure out if it is possible to repair a Osborne 1 keyboard. The keyboard is made by "Oak Switch Systems" and the type is FTM or "Full Travel Membrane". The problem I am seeing is that 3 keys ("h", "j" and "y") are permanently pressed. I did some experiments with the "h" key. I measured about 20 ohm across the matrix pins for the "h" key. I pulled off the "h" key keycap and the white plastic plunger with the both large and small spring - no change in resistance. I cleaned the now exposed membrane using Isopropyl alcohol - no change in resistance. I applied moderate heat using an electric hair dryer to both sides of the area around the "h" key - no change in resistance. I then used a lab power supply set to current limit hoping to zap whatever is causing the partial short (20 ohm). I slowly increased the voltage and current limit in short bursts until I hit 100 mA before I gave up the experiment not wanting to destroy the two flex PCBs feeding into the membrane. They did get warm but not hot. I have run out of ideas of what else to try. I still measure 20 ohm across the two keyboard matrix pins associated with the "h" key. Has anyone got experience repairing or restoring this type of membrane keyboard mechanism used in the Osborne 1 and probably in other keyboards too? Here are some good and detailed photos of keyboard mechanism: https://www.flickr.com/photos/123564336 at N03/sets/72157644113347562/ Thanks Tom Hunter From aek at bitsavers.org Mon Sep 21 07:08:30 2020 From: aek at bitsavers.org (Al Kossow) Date: Mon, 21 Sep 2020 05:08:30 -0700 Subject: Osborne 1 keyboard repair? In-Reply-To: References: Message-ID: On 9/21/20 4:41 AM, Tom Hunter via cctalk wrote: > I cleaned the now exposed membrane using Isopropyl alcohol - no change in > resistance. https://deskthority.net/wiki/Membrane_keyboard#Spring_over_membrane you exposed the top of three sheets. the contamination/deformation is between the two outer sheets many people have complained about switch failures in osborne keyboards it is probably corrosion between these switch layers you might be able to change something if you can inject a solvent into the side of the switch by drilling through the top layer, but just a solvent on top will do nothing From poc at pocnet.net Mon Sep 21 07:21:36 2020 From: poc at pocnet.net (Patrik Schindler) Date: Mon, 21 Sep 2020 14:21:36 +0200 Subject: Osborne 1 keyboard repair? In-Reply-To: References: Message-ID: <31243958-1444-4202-BD3A-B7F7768B1033@pocnet.net> Hello Tom, Am 21.09.2020 um 13:41 schrieb Tom Hunter via cctalk : > Has anyone got experience repairing or restoring this type of membrane keyboard mechanism used in the Osborne 1 and probably in other keyboards too? Not with the Osbornes, but with others. This kind is cheaper to manufacture than the ones with "true switches". Anyway, to get rid of the problem, carefully heat the ground plate to "does not hurt if I touch it for 10 seconds" and remove all the spring housings. Punctual further heating is most likely needed. This enables you to separate the sheets, and clean them. This should remove remains of soft drink spills (possibly explaining your particular problem), as well as insulating black silver sulphide layers. I Germany we have a very mild solvent for electronics, proved to do wonders to this type of partly-conductive foils. https://www.amazon.de/KONTAKT-CHEMIE-71809-Tuner-Kontaktreiniger/dp/B000NI2NTA Maybe there's something similar where you live? Also, carefully inspect the foils if there's some mechanical damage, like dents on the actual contact spots, providing a contact all the time. If there are, there's some creativity needed to even them out. I never needed to do that. > Here are some good and detailed photos of keyboard mechanism: > > https://www.flickr.com/photos/123564336 at N03/sets/72157644113347562/ Thanks, this helped a lot! :wq! PoC PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc From jules.richardson99 at gmail.com Mon Sep 21 07:24:20 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Mon, 21 Sep 2020 07:24:20 -0500 Subject: Osborne 1 keyboard repair? In-Reply-To: References: Message-ID: On 9/21/20 6:41 AM, Tom Hunter via cctalk wrote: > I cleaned the now exposed membrane using Isopropyl alcohol - no change in > resistance. I don't think you've really exposed anything, have you? The membrane is going to be three layers - a bottom layer with traces on the upper side, a spacer layer, then the top layer with traces on the underside; you're looking at the top of the membrane from the "outside". I expect it's all heat-staked together, but it might be possible to dismantle, separate the layers, clean the conductive surfaces and the spacer, then reassemble. My guess is that what happens is either: a) repeated keypresses over time result in some conductive material wearing off and depositing itself on the spacer, eventually bridging the gap and registering as a short/press. b) corrosion of the conductive surfaces results in the same thing. Either way, cleaning would likely fix it - but only if the membrane comes apart; it may well be sealed together at the edges. Alternately you might, I suppose, be able to drill a small hole through the membrane close to the problem area and inject some cleaning solution between the layers that way, but I don't know how successful that would be. cheers Jules From pete at dunnington.plus.com Mon Sep 21 07:18:40 2020 From: pete at dunnington.plus.com (Pete Turnbull) Date: Mon, 21 Sep 2020 13:18:40 +0100 Subject: Osborne 1 keyboard repair? In-Reply-To: References: Message-ID: <8cbcb1e7-46d8-186f-7472-0365ffa89e84@dunnington.plus.com> On 21/09/2020 12:41, Tom Hunter via cctalk wrote: > The problem I am seeing is that 3 keys ("h", "j" and "y") are permanently > pressed. I'm not familiar with this keyboard, so despite having fixed lots of other types, what I'm about to write is no more than musing and may be inapplicable drivel, but... A friend once spilled a glass of wine into his keyboard and had a similar problem. I've seen the same from a cola spillage. Washing it fixed it. Can you see if there are any spillage residues in there? IPA isn't always better than water and detergent - though you might want to use it as a water removal agent afterwards. As I imagine you've already realised, the keys are adjacent and likely share a track. I looked at the pictures. Can you get at the other side of the circuit board? If the it's fibreglass or even SRBP with copper tracks, maybe you can get at the tracks to the 'h' etc keys and cut them with a scalpel or craft knife to isolate them to see where the resistance really is. Before cutting anything, obviously make sure you can get a soldering iron in there afterwards to bridge the cuts. -- Pete Pete Turnbull From poc at pocnet.net Mon Sep 21 07:26:40 2020 From: poc at pocnet.net (Patrik Schindler) Date: Mon, 21 Sep 2020 14:26:40 +0200 Subject: Osborne 1 keyboard repair? In-Reply-To: References: Message-ID: <177908E6-8D85-4DDE-A8F1-790B9388E8E7@pocnet.net> Hello Al, Am 21.09.2020 um 14:08 schrieb Al Kossow via cctalk : > you might be able to change something if you can inject a solvent into the side of the switch by drilling through the top layer And then, the solvent is meant to stay there? I had bad experiences with "put magic fluid in between and the problem will be gone". :-) Depending on solvent, the solvent has no chance to evaporate away between the plastic layers. And if it could evaporate, the dirt has moved around but not away. Also, letting solvent staying on these delicate conducting silver strips is most likely doing more damage over time. Also, depending on solvent. :wq! PoC PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc From mjkerpan at kerpan.com Mon Sep 21 11:06:17 2020 From: mjkerpan at kerpan.com (Michael Kerpan) Date: Mon, 21 Sep 2020 12:06:17 -0400 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: Well, CD images are available on the Web for both IRIX 5.3 and 6.5. Various manuals, including installation guides seem to be available at http://irix7.com/techpubs.html As long as you have a CD drive (which you would have needed to install Linux), you should be good to go, though certain bits and pieces like the compilers probably need license keys to work properly. Mike On Mon, Sep 21, 2020 at 3:46 AM John Many Jars via cctalk wrote: > > I have an SGI Indy that some idiot (tm) (okay, it was me) put Linux on. > > Anyone have any way to undo my mistake? (: I'd like to get the thing > running properly again, if it even still powers up. I imagine the HD is > probably knackered by now anyway. > > On Fri, 18 Sep 2020 at 20:30, Ray Jewhurst via cctalk > wrote: > > > Also available on MAME is HP VUE on the 9000/360 and 370 and not a super > > early GUI but quite breathtaking is Irix on the SGI Indy. Directions to set > > up both are all over the web. > > > > Ray > > > > On Fri, Sep 18, 2020, 2:23 PM jacob--- via cctalk > > wrote: > > > > > On Thu, 17 Sep 2020, Michael Kerpan via cctalk wrote: > > > > > > > Something in another recent thread about LISP machines got me > > wondering: > > > > how many early graphical systems are well emulated (or emulated at > > all)? > > > I > > > > know that there are more or less functional emulations of Alto, Star, > > and > > > > Lisa out there, but what about the various LISP machines or the early > > > > workstations (Sun 68K, Apollo, etc) Also, assuming that there are > > > emulators > > > > for some of these systems out there, has any software to run on them > > and > > > > been archived? > > > > > > > > Mike > > > > > > > > > > Mame can emulate the Apollo Domain machines, > > > https://wiki.mamedev.org/index.php/Driver:Apollo > > > > > > Regards > > > > > > -- > > > Jacob Dahl Pind | telefisk.org | fidonet 2:230/38.8 > > > > > > > > > > > -- > Yoyodyne Propulsion Systems: "The Future Begins Tomorrow" > Visit us at: http://www.yoyodyne-propulsion.net > > -------- > "When a true genius appears in the world, you may know him by this sign, > that the dunces are all in confederacy against him." -- Jonathan Swift From spacewar at gmail.com Mon Sep 21 15:11:23 2020 From: spacewar at gmail.com (Eric Smith) Date: Mon, 21 Sep 2020 14:11:23 -0600 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: On Sun, Sep 20, 2020 at 3:24 PM Mike Begley via cctalk < cctalk at classiccmp.org> wrote: > There's also the windowing system used on the AT&T 3B1 (AKA Unix PC, AK > PC7300), which I think was called MGR. It may have also been ported to > other systems as well. When I had one of these machines it was adequate, > although terribly slow on a 512K system. > MGR was not the Unix PC's native GUI environment; I'm not sure what that was named. MGR was an open source environment that could be installed on the Unix PC. For best performance, it was necessary to replace a PAL chip on the motherboard ("VIDPAL") to allow user-space access to the frame buffer. The native GUI environment did not require or benefit from that. The linked photos are of the native GUI environment. Since the Unix PC was developed by Convergent, and the SVR2 it runs is derived from Convergent CTIX, I suspect that the native GUI environment was from Convergent as well. It might be derived from Convergent WGS/Desktop, but I've never seen that. From bill.gunshannon at hotmail.com Mon Sep 21 16:21:41 2020 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 21 Sep 2020 17:21:41 -0400 Subject: Exploring early GUIs In-Reply-To: References: Message-ID: On 9/21/20 4:11 PM, Eric Smith via cctalk wrote: > On Sun, Sep 20, 2020 at 3:24 PM Mike Begley via cctalk < > cctalk at classiccmp.org> wrote: > >> There's also the windowing system used on the AT&T 3B1 (AKA Unix PC, AK >> PC7300), which I think was called MGR. It may have also been ported to >> other systems as well. When I had one of these machines it was adequate, >> although terribly slow on a 512K system. >> > > MGR was not the Unix PC's native GUI environment; I'm not sure what that > was named. MGR was an open source environment that could be installed on > the Unix PC. https://en.wikipedia.org/wiki/ManaGeR bill From spectre at floodgap.com Mon Sep 21 17:38:34 2020 From: spectre at floodgap.com (Cameron Kaiser) Date: Mon, 21 Sep 2020 15:38:34 -0700 (PDT) Subject: Exploring early GUIs In-Reply-To: from Bill Gunshannon via cctalk at "Sep 21, 20 05:21:41 pm" Message-ID: <202009212238.08LMcYLN13631620@floodgap.com> > > MGR was not the Unix PC's native GUI environment; I'm not sure what that > > was named. MGR was an open source environment that could be installed on > > the Unix PC. > > https://en.wikipedia.org/wiki/ManaGeR Almost looks like a SunView ancestor. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- "Python: Because you don't know any better" -------------------------------- From bill.gunshannon at hotmail.com Mon Sep 21 18:11:22 2020 From: bill.gunshannon at hotmail.com (Bill Gunshannon) Date: Mon, 21 Sep 2020 19:11:22 -0400 Subject: Exploring early GUIs In-Reply-To: <202009212238.08LMcYLN13631620@floodgap.com> References: <202009212238.08LMcYLN13631620@floodgap.com> Message-ID: On 9/21/20 6:38 PM, Cameron Kaiser via cctalk wrote: >>> MGR was not the Unix PC's native GUI environment; I'm not sure what that >>> was named. MGR was an open source environment that could be installed on >>> the Unix PC. >> >> https://en.wikipedia.org/wiki/ManaGeR > > Almost looks like a SunView ancestor. > Here's a bit more taken from the posting to comp.sources.unix. ----------------- MGR - C Language Application Interface Stephen A. Uhler Bell Communications Research MGR (ManaGeR) is a window system for Unix that currently runs on Sun Workstations. MGR manages asynchronous updates of overlapping windows and provides application support for a heterogeneous network environment, i.e., many different types of computers connected by various communications media. The application interface enables applications (called client programs) to be written in a variety of programming languages, and run on different operating systems. The client program can take full advantage of the windowing capabilities regardless of the type of connection to the workstation running MGR. This document describes the C interface library for MGR which provides a set of macros and functions that implement the stream protocol. This library provides client programs written in C with a function call interface to MGR. The library provides the lowest level access to MGR functions and represents a one to one mapping to the underlying stream protocol. ------------------- bill From healyzh at avanthar.com Mon Sep 21 18:20:28 2020 From: healyzh at avanthar.com (Zane Healy) Date: Mon, 21 Sep 2020 16:20:28 -0700 Subject: Exploring early GUIs In-Reply-To: <202009212238.08LMcYLN13631620@floodgap.com> References: <202009212238.08LMcYLN13631620@floodgap.com> Message-ID: <9A943079-A5FC-424E-AE75-A8F8B9BA1D47@avanthar.com> > On Sep 21, 2020, at 3:38 PM, Cameron Kaiser via cctalk wrote: > >>> MGR was not the Unix PC's native GUI environment; I'm not sure what that >>> was named. MGR was an open source environment that could be installed on >>> the Unix PC. >> >> https://en.wikipedia.org/wiki/ManaGeR > > Almost looks like a SunView ancestor. It was the first GUI for Linux, back in ?92. Once X-Windows was able to support my video card I moved to that. Then in ?94 I had to move to a laptop with only 4MB RAM, so I used MGR until a version of X-Windows was released that would work well with only 4MB RAM. In both cases, I was mainly after the DVI viewer for TeX, and multiple terminal windows. Then again, even today, the main reason I use X-Windows is for multiple terminal windows. :-) Between ?92 and roughly ?96, X-Windows drove all my RAM purchases, after that it was graphics software and web browsers. Zane From cmhanson at eschatologist.net Mon Sep 21 23:24:54 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Mon, 21 Sep 2020 21:24:54 -0700 Subject: Exploring early GUIs In-Reply-To: <202009212238.08LMcYLN13631620@floodgap.com> References: <202009212238.08LMcYLN13631620@floodgap.com> Message-ID: <0087E9AF-8DCB-4E26-8BF5-B0991542146A@eschatologist.net> On Sep 21, 2020, at 3:38 PM, Cameron Kaiser via cctalk wrote: > > Almost looks like a SunView ancestor. I?m pretty sure SunWindows/SunView predates MGR by 2-3 years. ? Chris From mechanic_2 at charter.net Mon Sep 21 23:29:14 2020 From: mechanic_2 at charter.net (Richard Pope) Date: Mon, 21 Sep 2020 23:29:14 -0500 Subject: Exploring early GUIs In-Reply-To: <0087E9AF-8DCB-4E26-8BF5-B0991542146A@eschatologist.net> References: <202009212238.08LMcYLN13631620@floodgap.com> <0087E9AF-8DCB-4E26-8BF5-B0991542146A@eschatologist.net> Message-ID: <5F697D9A.8010509@charter.net> Hello all, The Amiga 1000 with AmigaDos and Workbench was released in late 1985. AmigaDos is based on Unix and Workbench is based on X-windows. GOD Bless and Thanks, rich! On 9/21/2020 11:24 PM, Chris Hanson via cctalk wrote: > On Sep 21, 2020, at 3:38 PM, Cameron Kaiser via cctalk wrote: >> Almost looks like a SunView ancestor. > I?m pretty sure SunWindows/SunView predates MGR by 2-3 years. > > ? Chris > > From cmhanson at eschatologist.net Mon Sep 21 23:36:24 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Mon, 21 Sep 2020 21:36:24 -0700 Subject: Exploring early GUIs In-Reply-To: <5F697D9A.8010509@charter.net> References: <202009212238.08LMcYLN13631620@floodgap.com> <0087E9AF-8DCB-4E26-8BF5-B0991542146A@eschatologist.net> <5F697D9A.8010509@charter.net> Message-ID: <8609FB58-6ABB-4380-A872-E488A7B4811C@eschatologist.net> On Sep 21, 2020, at 9:29 PM, Richard Pope wrote: > > The Amiga 1000 with AmigaDos and Workbench was released in late 1985. AmigaDos is based on Unix and Workbench is based on X-windows. Neither of these claims is correct. ? Chris From abuse at cabal.org.uk Tue Sep 22 05:02:09 2020 From: abuse at cabal.org.uk (Peter Corlett) Date: Tue, 22 Sep 2020 12:02:09 +0200 Subject: Exploring early GUIs In-Reply-To: <5F697D9A.8010509@charter.net> References: <202009212238.08LMcYLN13631620@floodgap.com> <0087E9AF-8DCB-4E26-8BF5-B0991542146A@eschatologist.net> <5F697D9A.8010509@charter.net> Message-ID: <20200922100209.GA25153@mooli.org.uk> On Mon, Sep 21, 2020 at 11:29:14PM -0500, Richard Pope via cctalk wrote: > The Amiga 1000 with AmigaDos and Workbench was released in late 1985. > AmigaDos is based on Unix and Workbench is based on X-windows. Er, no. The Amiga's operating system is a pre-emptive multitasking microkernel which uses asynchronous message-passing betwen subsystems, which is not the Unix way of doing things at all. Unix provide libraries of synchronous procedure calls which block the caller until the job is done. Although "AmigaDOS" appears prominently in the terminal as one boots Workbench, that's only the filesystem and command-line shell. Due to time pressure, they bought in TRIPOS and filed off the serial number. TRIPOS is a fairly clunky thing written in BCPL that never sat well with the rest of the system, but it was quite probably the only DOS they could buy in which worked in a concurrent environment. TRIPOS is the reason why disks were slow on the Amiga. The other bit that got reduced from a grander vision was the graphics, which became blocking libraries rather than device drivers. The window manager ran as its own thread which gave the illusion of responsiveness. The "X Window System" (not X-windows or other misnomers) is an ordinary[1] Unix process which provides low-level primitives for a windowing system. "Workbench" is just an ordinary AmigaDOS process which provides a file manager. You can even quit it to save memory, and the rest of the GUI still works. They are not the same thing or "based" on each other at all. [1] Well, some implementations are setuid root or have similar elevated privileges so they can have unfettered access to the bare metal and thus tantamount to being part of the kernel, but that's basically corner-cutting by a bunch of cowboys and it is possible to do this sort of thing properly without introducing a massive security hole. From ian.finder at gmail.com Tue Sep 22 12:53:38 2020 From: ian.finder at gmail.com (ian.finder at gmail.com) Date: Tue, 22 Sep 2020 10:53:38 -0700 Subject: PSA to SparcBook 2 Users Message-ID: There is a 1000uf 10v cap on the main logic board just above the Bt display controller. It is leaking... a lot. (4/4 samples so far) Go replace it, flush the area and scrub the with 99.9% IPA. From aperry at snowmoose.com Tue Sep 22 13:03:00 2020 From: aperry at snowmoose.com (Alan Perry) Date: Tue, 22 Sep 2020 11:03:00 -0700 Subject: PSA to SparcBook 2 Users In-Reply-To: References: Message-ID: You flush electronics with Indian Pale Ale? Too many TLAs. This isn't a problem on the model of SparcBook you sold me, is it? On 9/22/20 10:53 AM, Ian Finder via cctalk wrote: > There is a 1000uf 10v cap on the main logic board just above the Bt display controller. > > It is leaking... a lot. (4/4 samples so far) > > Go replace it, flush the area and scrub the with 99.9% IPA. > From ian.finder at gmail.com Tue Sep 22 13:45:33 2020 From: ian.finder at gmail.com (null) Date: Tue, 22 Sep 2020 11:45:33 -0700 Subject: PSA to SparcBook 2 Users In-Reply-To: References: Message-ID: <1072AC35-D3AD-4ED2-AB2C-1D0D5A8F913B@gmail.com> No, this applies only to Tadpole Series 2 and potentially Series 1 machines (although I have not observed the latter) Series 3(/3000) are completely different internally. Your SB3000 is safe- at least from this failure mode. > On Sep 22, 2020, at 11:02, Alan Perry via cctalk wrote: > > ?You flush electronics with Indian Pale Ale? Too many TLAs. > > This isn't a problem on the model of SparcBook you sold me, is it? > >> On 9/22/20 10:53 AM, Ian Finder via cctalk wrote: >> There is a 1000uf 10v cap on the main logic board just above the Bt display controller. >> It is leaking... a lot. (4/4 samples so far) >> Go replace it, flush the area and scrub the with 99.9% IPA. From ian.finder at gmail.com Tue Sep 22 13:53:05 2020 From: ian.finder at gmail.com (null) Date: Tue, 22 Sep 2020 11:53:05 -0700 Subject: Amiga Roots, TRIPOS - Off Topic, was Re: Exploring early GUIs In-Reply-To: <20200922100209.GA25153@mooli.org.uk> References: <20200922100209.GA25153@mooli.org.uk> Message-ID: Forking this thread as we are now way off the original and very cogent topic, which I would like to see continued. (Very valid to ask about good emulations of early GUI systems like Apollo, LispMs, PERQ, Xerox D* etc) Peter?s mentions of TRIPOS (which was used on a Sage IV for Amiga Lorraine bring-up) has me renew my ask: If anyone has media for TRIPOS for the Sage/Stride systems please reach out. > On Sep 22, 2020, at 03:02, Peter Corlett via cctalk wrote: > > ?On Mon, Sep 21, 2020 at 11:29:14PM -0500, Richard Pope via cctalk wrote: >> The Amiga 1000 with AmigaDos and Workbench was released in late 1985. >> AmigaDos is based on Unix and Workbench is based on X-windows. > > Er, no. > > The Amiga's operating system is a pre-emptive multitasking microkernel which > uses asynchronous message-passing betwen subsystems, which is not the Unix way > of doing things at all. Unix provide libraries of synchronous procedure calls > which block the caller until the job is done. > > Although "AmigaDOS" appears prominently in the terminal as one boots Workbench, > that's only the filesystem and command-line shell. Due to time pressure, they > bought in TRIPOS and filed off the serial number. TRIPOS is a fairly clunky > thing written in BCPL that never sat well with the rest of the system, but it > was quite probably the only DOS they could buy in which worked in a concurrent > environment. TRIPOS is the reason why disks were slow on the Amiga. > > The other bit that got reduced from a grander vision was the graphics, which > became blocking libraries rather than device drivers. The window manager ran as > its own thread which gave the illusion of responsiveness. > > The "X Window System" (not X-windows or other misnomers) is an ordinary[1] Unix > process which provides low-level primitives for a windowing system. "Workbench" > is just an ordinary AmigaDOS process which provides a file manager. You can > even quit it to save memory, and the rest of the GUI still works. They are not > the same thing or "based" on each other at all. > > > [1] Well, some implementations are setuid root or have similar elevated > privileges so they can have unfettered access to the bare metal and thus > tantamount to being part of the kernel, but that's basically corner-cutting > by a bunch of cowboys and it is possible to do this sort of thing properly > without introducing a massive security hole. > From a.carlini at ntlworld.com Tue Sep 22 17:51:13 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Tue, 22 Sep 2020 23:51:13 +0100 Subject: DLT III tapes (TK85-K) and sticky-shed Message-ID: <6c9374cf-7169-95c7-6e2e-047649bf8d8b@ntlworld.com> I've seen plenty of complaints (here and elsewhere) about TK50 cartridges being very difficult to read these days. I'm trying to read TK85-K (DLT III) cartridges and I'm experiencing problems. I've had tapes ripped (although I've found that data elsewhere). So now I'm being particularly careful. If the drive asks for a cleaning tape, I run through a cleaning cycle until it is happy and then I try to load the tape again. However, by the time I've mounted the tape, the drive "Cleaning Required" light is on again. This happens repeatedly, I run a cleaning pass or two and then I get a green light. I might even get as far as loading the tape without and issue, but by the time the tape is mounted, the "Cleaning Required" light is on. So is this likely to be sticky shed? Is the DLT III formulation known to have the same issues? Does baking help? (Not that I'm set up to do that, but I'm in no rush ...) I suppose that it is possible that my cleaning tape is worn out and now past its sell by date. Has anyone cleaned a TZ87 or TZ88 head successfully? It doesn't seem to be terribly accessible, and I'm not sure what I can dismantle without wrecking the alignment. Anyone got any useful suggestions? Antonio -- Antonio Carlini antonio at acarlini.com From engel at multicores.org Wed Sep 23 13:51:39 2020 From: engel at multicores.org (Michael Engel) Date: Wed, 23 Sep 2020 20:51:39 +0200 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? Message-ID: Hi, still working on backing up the Tektronix 440x disks. My current problem is that the ACB4000 SCSI-to-MFM adapter doesn?t support SCSI parity. I finally managed to find a PCI SCSI controller (Adaptec 2940) and a Pentium 4 PC with PCI slots and installed OpenBSD 6.7. I disabled parity checking in the Adaptec BIOS config and it detects a disk at ID 0 with no name. So far, so good. However, OpenBSD always seems to enable SCSI parity and complains about disk parity errors. I tried to disable all lines in the aic7xxx and ahc_pci driver source files that seem to enable parity, but nothing seems to make a difference. The drive/ACB4000 is not detected by OpenBSD, I get a "device not configured" error when accessing the disk device files (/dev/sdxc and /dev/rsdxc). Do you know if is there another OS which would make it easier to change crucial SCSI parameters in the driver (config) or maybe a specialized tool that could help me to image the disk? -- Michael From cctalk at gtaylor.tnetconsulting.net Wed Sep 23 13:54:15 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Wed, 23 Sep 2020 12:54:15 -0600 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> On 9/23/20 12:51 PM, Michael Engel via cctech wrote: > Do you know if is there another OS which would make it easier to change > crucial SCSI parameters in the driver (config) or maybe a specialized > tool that could help me to image the disk? Try booting off of a Linux live CD / DVD and seeing if it will behave any different. -- Grant. . . . unix || die From engel at multicores.org Wed Sep 23 15:28:42 2020 From: engel at multicores.org (Michael Engel) Date: Wed, 23 Sep 2020 22:28:42 +0200 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> Message-ID: On 9/23/20 8:54 PM, Grant Taylor via cctech wrote: > On 9/23/20 12:51 PM, Michael Engel via cctech wrote: >> Do you know if is there another OS which would make it easier to >> change crucial SCSI parameters in the driver (config) or maybe a >> specialized tool that could help me to image the disk? > > Try booting off of a Linux live CD / DVD and seeing if it will behave > any different Not really, unfortunately. The error messages are a bit cryptic: [ 1069.277571] (scsi8:A:0:0): Sending SDTR period 45, offset 0 [ 1069.278961] scsi 8:0:0:0: Attempting to queue a TARGET RESET message [ 1069.278964] CDB: 0x12 0x0 0x0 0x0 0x24 0x0 [ 1069.278975] scsi 8:0:0:0: Command not found [ 1069.278979] aic7xxx_dev_reset returns 0x2002 [ 1069.279286] (scsi8:A:0:0): Sending SDTR period 45, offset 0 [ 1069.280736] scsi8: Slave Alloc 1 [ 1069.543400] scsi target8:0:1: asynchronous [ 1069.543416] scsi8: target 1 using asynchronous transfers [ 1069.543420] scsi8: Selection Timeout on A:1. 0 SCBs aborted It seems that the problem lies in the firmware of the ACB4000, which doesn?t seem to support some standard commands, e.g. the INQUIRY command. Most recent Linux SCSI drivers seem to use this command. Some information on this problem can be found here: https://www.zot.org/~hamish/hacks/acb-4000.html There?s a thread (in German, sorry) in which someone tried to get a disk on an ACB4000 to work: https://de.comp.os.unix.linux.misc.narkive.com/ti21cHO0/scsi-1-platte-unter-linux-ansprechen and somebody else (also in German...) claims that he could run a disk on an ACB4000 (from an Atari SH204) on an Adaptec 1542: https://forum.classic-computing.de/forum/index.php?thread/18576-wie-programme-vom-pc-auf-atari-mega-st-bringen/&pageNo=2 So maybe an Atari ST with an ACSI->SCSI adapter might help. That seems to be one of the machines we don?t have here... -- Michael From derschjo at gmail.com Wed Sep 23 15:44:15 2020 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 23 Sep 2020 13:44:15 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> Message-ID: On Wed, Sep 23, 2020 at 1:28 PM Michael Engel via cctech < cctech at classiccmp.org> wrote: > > > On 9/23/20 8:54 PM, Grant Taylor via cctech wrote: > > On 9/23/20 12:51 PM, Michael Engel via cctech wrote: > >> Do you know if is there another OS which would make it easier to > >> change crucial SCSI parameters in the driver (config) or maybe a > >> specialized tool that could help me to image the disk? > > > > Try booting off of a Linux live CD / DVD and seeing if it will behave > > any different > Not really, unfortunately. The error messages are a bit cryptic: > > [ 1069.277571] (scsi8:A:0:0): Sending SDTR period 45, offset 0 > [ 1069.278961] scsi 8:0:0:0: Attempting to queue a TARGET RESET message > [ 1069.278964] CDB: 0x12 0x0 0x0 0x0 0x24 0x0 > [ 1069.278975] scsi 8:0:0:0: Command not found > [ 1069.278979] aic7xxx_dev_reset returns 0x2002 > [ 1069.279286] (scsi8:A:0:0): Sending SDTR period 45, offset 0 > [ 1069.280736] scsi8: Slave Alloc 1 > [ 1069.543400] scsi target8:0:1: asynchronous > [ 1069.543416] scsi8: target 1 using asynchronous transfers > [ 1069.543420] scsi8: Selection Timeout on A:1. 0 SCBs aborted > > It seems that the problem lies in the firmware of the ACB4000, which > doesn?t seem to support some standard commands, e.g. the INQUIRY > command. Most recent Linux SCSI drivers seem to use this command. > Earlier versions of SunOS and Solaris know how to deal with Adaptec SCSI bridges properly; I've done so on SunOS 4.1.4, for example. I'd still suggest using something like this: https://www.pdp8.net/mfm/mfm.shtml to image the MFM disks themselves. A friend of mine is in the middle of assembling a run of them... - Josh From plamenspam at afterpeople.com Wed Sep 23 23:13:43 2020 From: plamenspam at afterpeople.com (Plamen Mihaylov) Date: Thu, 24 Sep 2020 07:13:43 +0300 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> Message-ID: I have the same problem with Torch Triple X disk which uses OMT SCSI/MFM adapter. I believe the best solution is to use David?s MFM emulator board. Best regards, Plamen On Wednesday, September 23, 2020, Michael Engel via cctech < cctech at classiccmp.org> wrote: > > > On 9/23/20 8:54 PM, Grant Taylor via cctech wrote: > >> On 9/23/20 12:51 PM, Michael Engel via cctech wrote: >> >>> Do you know if is there another OS which would make it easier to change >>> crucial SCSI parameters in the driver (config) or maybe a specialized tool >>> that could help me to image the disk? >>> >> >> Try booting off of a Linux live CD / DVD and seeing if it will behave any >> different >> > Not really, unfortunately. The error messages are a bit cryptic: > > [ 1069.277571] (scsi8:A:0:0): Sending SDTR period 45, offset 0 > [ 1069.278961] scsi 8:0:0:0: Attempting to queue a TARGET RESET message > [ 1069.278964] CDB: 0x12 0x0 0x0 0x0 0x24 0x0 > [ 1069.278975] scsi 8:0:0:0: Command not found > [ 1069.278979] aic7xxx_dev_reset returns 0x2002 > [ 1069.279286] (scsi8:A:0:0): Sending SDTR period 45, offset 0 > [ 1069.280736] scsi8: Slave Alloc 1 > [ 1069.543400] scsi target8:0:1: asynchronous > [ 1069.543416] scsi8: target 1 using asynchronous transfers > [ 1069.543420] scsi8: Selection Timeout on A:1. 0 SCBs aborted > > It seems that the problem lies in the firmware of the ACB4000, which > doesn?t seem to support some standard commands, e.g. the INQUIRY command. > Most recent Linux SCSI drivers seem to use this command. > > Some information on this problem can be found here: > https://www.zot.org/~hamish/hacks/acb-4000.html > > There?s a thread (in German, sorry) in which someone tried to get a disk > on an ACB4000 to work: > https://de.comp.os.unix.linux.misc.narkive.com/ti21cHO0/scsi > -1-platte-unter-linux-ansprechen > and somebody else (also in German...) claims that he could run a disk on > an ACB4000 (from an Atari SH204) on an Adaptec 1542: > https://forum.classic-computing.de/forum/index.php?thread/ > 18576-wie-programme-vom-pc-auf-atari-mega-st-bringen/&pageNo=2 > > So maybe an Atari ST with an ACSI->SCSI adapter might help. That seems to > be one of the machines we don?t have here... > > -- Michael > > From camiel at vaxbarn.com Thu Sep 24 02:12:02 2020 From: camiel at vaxbarn.com (Camiel Vanderhoeven) Date: Thu, 24 Sep 2020 09:12:02 +0200 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> Message-ID: > On Sep 23, 2020, at 10:28 PM, Michael Engel via cctech wrote: > > > > On 9/23/20 8:54 PM, Grant Taylor via cctech wrote: >> On 9/23/20 12:51 PM, Michael Engel via cctech wrote: >>> Do you know if is there another OS which would make it easier to change crucial SCSI parameters in the driver (config) or maybe a specialized tool that could help me to image the disk? >> >> Try booting off of a Linux live CD / DVD and seeing if it will behave any different > Not really, unfortunately. The error messages are a bit cryptic: > > [ 1069.277571] (scsi8:A:0:0): Sending SDTR period 45, offset 0 > [ 1069.278961] scsi 8:0:0:0: Attempting to queue a TARGET RESET message > [ 1069.278964] CDB: 0x12 0x0 0x0 0x0 0x24 0x0 > [ 1069.278975] scsi 8:0:0:0: Command not found > [ 1069.278979] aic7xxx_dev_reset returns 0x2002 > [ 1069.279286] (scsi8:A:0:0): Sending SDTR period 45, offset 0 > [ 1069.280736] scsi8: Slave Alloc 1 > [ 1069.543400] scsi target8:0:1: asynchronous > [ 1069.543416] scsi8: target 1 using asynchronous transfers > [ 1069.543420] scsi8: Selection Timeout on A:1. 0 SCBs aborted > > It seems that the problem lies in the firmware of the ACB4000, which doesn?t seem to support some standard commands, e.g. the INQUIRY command. Most recent Linux SCSI drivers seem to use this command. > > Some information on this problem can be found here: > https://www.zot.org/~hamish/hacks/acb-4000.html > > There?s a thread (in German, sorry) in which someone tried to get a disk on an ACB4000 to work: > https://de.comp.os.unix.linux.misc.narkive.com/ti21cHO0/scsi-1-platte-unter-linux-ansprechen > and somebody else (also in German...) claims that he could run a disk on an ACB4000 (from an Atari SH204) on an Adaptec 1542: > https://forum.classic-computing.de/forum/index.php?thread/18576-wie-programme-vom-pc-auf-atari-mega-st-bringen/&pageNo=2 > > So maybe an Atari ST with an ACSI->SCSI adapter might help. That seems to be one of the machines we don?t have here? Yes, the ACB-4000 doesn?t play well with anything modern. The SPU (service processor) disk on my Convex C-1 uses a Fujitsu MFM disk with an ACB-4000. I absolutely had to save the contents of that disk, so here is my approach: I used an Ancot Ultra2080/Lite SCSI-bus Analyzer. This is a device that connects to a SCSI bus and has a serial port. Over the serial port, you can monitor the signals on the SCSI bus, and use it as a SCSI protocol analyzer. There?s also the possibility to construct and send a SCSI command. Rather than connect a serial terminal to the serial port, I connected a PC, then wrote a C program to control the Ancot. I had the Ancot send commands to the disk to read a sector at a time, and recorded the data sent in response to a file to create a disk image. Slow as hell (each byte on the disk requires sending two hex characters and a space over a slow serial line), but it works. I had to make several passes over the disk, because occasionally the data received from the disk turned out to be data from a different sector than the one I was trying to read. By reading the disk multiple times, I could get rid of these mis-read sectors. I put the image created this way on a new disk (well, an old DEC 1GB disk with a SCSI-1 mode jumper) and was able to boot the SPU from this disk (It could not boot off the original disk), and later replaced it with a SCSI2SD. If you?re interested, and have access to an Ancot, I can probably dig out the C code I wrote. Camiel From cctalk at gtaylor.tnetconsulting.net Thu Sep 24 10:23:25 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Thu, 24 Sep 2020 09:23:25 -0600 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> Message-ID: <86033795-e07e-7b0a-db0b-e72fafec765e@spamtrap.tnetconsulting.net> On 9/24/20 1:12 AM, Camiel Vanderhoeven via cctalk wrote: > I used an Ancot Ultra2080/Lite SCSI-bus Analyzer. This is a device > that connects to a SCSI bus and has a serial port. Over the serial > port, you can monitor the signals on the SCSI bus, and use it as a > SCSI protocol analyzer. There?s also the possibility to construct > and send a SCSI command. Rather than connect a serial terminal to the > serial port, I connected a PC, then wrote a C program to control the > Ancot. I had the Ancot send commands to the disk to read a sector at > a time, and recorded the data sent in response to a file to create a > disk image. Slow as hell (each byte on the disk requires sending two > hex characters and a space over a slow serial line), but it works. I > had to make several passes over the disk, because occasionally the data > received from the disk turned out to be data from a different sector > than the one I was trying to read. By reading the disk multiple times, > I could get rid of these mis-read sectors. Very NICE hack Camiel. I like it! I am a little surprised by getting different data for the same sectors. I find that mildly concerning. Did you do something like read each byte multiple times to find a majority sample? 2/3, 3/5, 4/6, etc? Do you think the different data was an artifact of the old drive? Or was it a tickle of a bug elsewhere in the chain? -- Grant. . . . unix || die From camiel at vaxbarn.com Thu Sep 24 11:21:15 2020 From: camiel at vaxbarn.com (Camiel Vanderhoeven) Date: Thu, 24 Sep 2020 18:21:15 +0200 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <86033795-e07e-7b0a-db0b-e72fafec765e@spamtrap.tnetconsulting.net> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <86033795-e07e-7b0a-db0b-e72fafec765e@spamtrap.tnetconsulting.net> Message-ID: > On Sep 24, 2020, at 5:23 PM, Grant Taylor via cctalk wrote: > > On 9/24/20 1:12 AM, Camiel Vanderhoeven via cctalk wrote: >> I used an Ancot Ultra2080/Lite SCSI-bus Analyzer. This is a device that connects to a SCSI bus and has a serial port. Over the serial port, you can monitor the signals on the SCSI bus, and use it as a SCSI protocol analyzer. There?s also the possibility to construct and send a SCSI command. Rather than connect a serial terminal to the serial port, I connected a PC, then wrote a C program to control the Ancot. I had the Ancot send commands to the disk to read a sector at a time, and recorded the data sent in response to a file to create a disk image. Slow as hell (each byte on the disk requires sending two hex characters and a space over a slow serial line), but it works. I had to make several passes over the disk, because occasionally the data received from the disk turned out to be data from a different sector than the one I was trying to read. By reading the disk multiple times, I could get rid of these mis-read sectors. > > Very NICE hack Camiel. I like it! > > I am a little surprised by getting different data for the same sectors. I find that mildly concerning. Did you do something like read each byte multiple times to find a majority sample? 2/3, 3/5, 4/6, etc? Do you think the different data was an artifact of the old drive? Or was it a tickle of a bug elsewhere in the chain? The drive was what seems to be a pre-production Fujitsu model (with a serial number of 37), 17MB in size; I?m pretty sure the disk itself had issues. On the first pass of reading the disk, about 8% of all sectors wouldn?t read, returning an ?Unrecoverable Read Error?; when I did a second pass reading just these failed sectors, I found that I could read about 2/3rds of them. I repeated this 20 times or so, and then I had almost everything. There were 43 sectors near the end of the disk that I never managed to read, but these were beyond the filesystems on the disk. That gave me a disk that would boot, but I has some corrupt files and a corrupt directory. Looking at these, I found that the corrupt bits were sector-sized, and were identical copies of sectors elsewhere on the disk. In the end, what I ended up doing was read the entire disk 2 more times (so two more times the 20 iterations of reading the missing sectors until I had a complete image), and compared the resulting three disk images sector-by-sector. For some 99% of the sectors, all three copies were in agreement; where they were not, there were always two images in agreement, so I knew which one to pick. I?ve documented some of this here: https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics From camiel at vaxbarn.com Thu Sep 24 11:25:22 2020 From: camiel at vaxbarn.com (Camiel Vanderhoeven) Date: Thu, 24 Sep 2020 18:25:22 +0200 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <86033795-e07e-7b0a-db0b-e72fafec765e@spamtrap.tnetconsulting.net> Message-ID: <5A4B2340-16DB-4AF2-9EDC-667549B80E73@vaxbarn.com> > On Sep 24, 2020, at 6:21 PM, Camiel Vanderhoeven via cctalk wrote: > > > > > >> On Sep 24, 2020, at 5:23 PM, Grant Taylor via cctalk wrote: >> >> On 9/24/20 1:12 AM, Camiel Vanderhoeven via cctalk wrote: >>> I used an Ancot Ultra2080/Lite SCSI-bus Analyzer. This is a device that connects to a SCSI bus and has a serial port. Over the serial port, you can monitor the signals on the SCSI bus, and use it as a SCSI protocol analyzer. There?s also the possibility to construct and send a SCSI command. Rather than connect a serial terminal to the serial port, I connected a PC, then wrote a C program to control the Ancot. I had the Ancot send commands to the disk to read a sector at a time, and recorded the data sent in response to a file to create a disk image. Slow as hell (each byte on the disk requires sending two hex characters and a space over a slow serial line), but it works. I had to make several passes over the disk, because occasionally the data received from the disk turned out to be data from a different sector than the one I was trying to read. By reading the disk multiple times, I could get rid of these mis-read sectors. >> >> Very NICE hack Camiel. I like it! >> >> I am a little surprised by getting different data for the same sectors. I find that mildly concerning. Did you do something like read each byte multiple times to find a majority sample? 2/3, 3/5, 4/6, etc? Do you think the different data was an artifact of the old drive? Or was it a tickle of a bug elsewhere in the chain? > > > The drive was what seems to be a pre-production Fujitsu model (with a serial number of 37), 17MB in size; I?m pretty sure the disk itself had issues. On the first pass of reading the disk, about 8% of all sectors wouldn?t read, returning an ?Unrecoverable Read Error?; when I did a second pass reading just these failed sectors, I found that I could read about 2/3rds of them. I repeated this 20 times or so, and then I had almost everything. There were 43 sectors near the end of the disk that I never managed to read, but these were beyond the filesystems on the disk. That gave me a disk that would boot, but I has some corrupt files and a corrupt directory. Looking at these, I found that the corrupt bits were sector-sized, and were identical copies of sectors elsewhere on the disk. > > In the end, what I ended up doing was read the entire disk 2 more times (so two more times the 20 iterations of reading the missing sectors until I had a complete image), and compared the resulting three disk images sector-by-sector. For some 99% of the sectors, all three copies were in agreement; where they were not, there were always two images in agreement, so I knew which one to pick. > > I?ve documented some of this here: > > https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on > > > https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics > Oh, I was lucky when I spotted it; the first corrupt file I encountered was part of the microcode to be loaded onto the vector processor. Those files have checksums, and the microcode loader complained. I wrote a small utility to extract the files from the disk image (it uses a variant of the UFS file system), and had a look at the corrupt file; one of the blocks in the file looked like part of a directory, which was easy to spot, and that led me to the conclusion that it was valid data, but read from the wrong place. Camiel From jm at x25.ee Thu Sep 24 12:04:17 2020 From: jm at x25.ee (Jonas M) Date: Thu, 24 Sep 2020 17:04:17 +0000 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: <20200924170417.GA2068@lysithea> Hi, I remember I used Linux with an AdvanSys PCI adapter to successfully read a disk connected through an ACB4000. It's been a while but I believe I had to run an old kernel which I compiled myself with support for ACB4000. Might have been that a patch was applied. All I found in my archives is a copy of the dmesg from the host showing: Linux version 2.0.38 (root at localhost.localdomain) (gcc version 2.7.2.3) #2 Wed Nov 11 20:33:21 CET 2009 [...] scsi0 : AdvanSys SCSI 3.1E: PCI Ultra 16 CDB: IO D400/F, IRQ 12 scsi : 1 host. scsi0 channel 0 : resetting for second half of retries. SCSI bus is being reset for host 0 channel 0. advansys: advansys_reset: reset request not active or waiting, completing anyway fbd018 Vendor: ADAPTEC Model: ACB-40XX Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 01 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: hdwr sector= 512 bytes. Sectors= 148135 [72 MB] [0.1 GB] sda: unknown partition table Can try to dig around old disks some day to see if I find the patch. Br, Jonas On Wed, Sep 23, 2020 at 08:51:39PM +0200, Michael Engel via cctalk wrote: > Hi, > > still working on backing up the Tektronix 440x disks. My current problem is > that the ACB4000 SCSI-to-MFM adapter doesn?t support SCSI parity. > > I finally managed to find a PCI SCSI controller (Adaptec 2940) and a Pentium > 4 PC with PCI slots and installed OpenBSD 6.7. I disabled parity checking in > the Adaptec BIOS config and it detects a disk at ID 0 with no name. So far, > so good. > > However, OpenBSD always seems to enable SCSI parity and complains about disk > parity errors. I tried to disable all lines in the aic7xxx and ahc_pci > driver source files that seem to enable parity, but nothing seems to make a > difference. The drive/ACB4000 is not detected by OpenBSD, I get a "device > not configured" error when accessing the disk device files (/dev/sdxc and > /dev/rsdxc). > > Do you know if is there another OS which would make it easier to change > crucial SCSI parameters in the driver (config) or maybe a specialized tool > that could help me to image the disk? > > -- Michael From jm at x25.ee Thu Sep 24 12:04:17 2020 From: jm at x25.ee (Jonas M) Date: Thu, 24 Sep 2020 17:04:17 +0000 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: <20200924170417.GA2068@lysithea> Hi, I remember I used Linux with an AdvanSys PCI adapter to successfully read a disk connected through an ACB4000. It's been a while but I believe I had to run an old kernel which I compiled myself with support for ACB4000. Might have been that a patch was applied. All I found in my archives is a copy of the dmesg from the host showing: Linux version 2.0.38 (root at localhost.localdomain) (gcc version 2.7.2.3) #2 Wed Nov 11 20:33:21 CET 2009 [...] scsi0 : AdvanSys SCSI 3.1E: PCI Ultra 16 CDB: IO D400/F, IRQ 12 scsi : 1 host. scsi0 channel 0 : resetting for second half of retries. SCSI bus is being reset for host 0 channel 0. advansys: advansys_reset: reset request not active or waiting, completing anyway fbd018 Vendor: ADAPTEC Model: ACB-40XX Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 01 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: hdwr sector= 512 bytes. Sectors= 148135 [72 MB] [0.1 GB] sda: unknown partition table Can try to dig around old disks some day to see if I find the patch. Br, Jonas On Wed, Sep 23, 2020 at 08:51:39PM +0200, Michael Engel via cctalk wrote: > Hi, > > still working on backing up the Tektronix 440x disks. My current problem is > that the ACB4000 SCSI-to-MFM adapter doesn?t support SCSI parity. > > I finally managed to find a PCI SCSI controller (Adaptec 2940) and a Pentium > 4 PC with PCI slots and installed OpenBSD 6.7. I disabled parity checking in > the Adaptec BIOS config and it detects a disk at ID 0 with no name. So far, > so good. > > However, OpenBSD always seems to enable SCSI parity and complains about disk > parity errors. I tried to disable all lines in the aic7xxx and ahc_pci > driver source files that seem to enable parity, but nothing seems to make a > difference. The drive/ACB4000 is not detected by OpenBSD, I get a "device > not configured" error when accessing the disk device files (/dev/sdxc and > /dev/rsdxc). > > Do you know if is there another OS which would make it easier to change > crucial SCSI parameters in the driver (config) or maybe a specialized tool > that could help me to image the disk? > > -- Michael From syseng at gfsys.co.uk Thu Sep 24 12:18:43 2020 From: syseng at gfsys.co.uk (Chris Quayle) Date: Thu, 24 Sep 2020 18:18:43 +0100 Subject: Disabling SCSI parity checking to dump disk on ACB4000, MFM-SCSI adapter? In-Reply-To: References: Message-ID: <5F6CD4F3.2030507@gfsys.co.uk> On 09/24/20 18:00, cctech-request at classiccmp.org wrote: > Disabling SCSI parity checking to dump disk on ACB4000 > MFM-SCSI adapter? I have a sun 3 system with acb4000 and suspect the protocol was not fully sorted in that time frame. They can be fussy about what they will talk to, ime. Would lend a hand if you are in the uk, but otherwise, if you have an early Sparc system, I would try that, as it would probably still support the older controllers. Sparcstation 1 or 2 + Sunos probably has the required entries in the format utility, format.dat file. An early pci or isa Adaptec card might be worth trying as well, under Suse 11.4 or similar, as that has a good disk utility... Chris From jfoust at threedee.com Thu Sep 24 12:56:52 2020 From: jfoust at threedee.com (John Foust) Date: Thu, 24 Sep 2020 12:56:52 -0500 Subject: Revived Terak 8510 In-Reply-To: <5A4B2340-16DB-4AF2-9EDC-667549B80E73@vaxbarn.com> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <86033795-e07e-7b0a-db0b-e72fafec765e@spamtrap.tnetconsulting.net> <5A4B2340-16DB-4AF2-9EDC-667549B80E73@vaxbarn.com> Message-ID: <20200924175729.3C0F9273DE@mx1.ezwind.net> Mine stopped working a decade or so ago. I have a dozen or so, but none are powering up any more. I seem to remember someone here who'd revived one. Did it mean replacing sockets, replacing caps? - John From derschjo at gmail.com Thu Sep 24 13:03:37 2020 From: derschjo at gmail.com (Josh Dersch) Date: Thu, 24 Sep 2020 11:03:37 -0700 Subject: Revived Terak 8510 In-Reply-To: <20200924175729.3C0F9273DE@mx1.ezwind.net> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <86033795-e07e-7b0a-db0b-e72fafec765e@spamtrap.tnetconsulting.net> <5A4B2340-16DB-4AF2-9EDC-667549B80E73@vaxbarn.com> <20200924175729.3C0F9273DE@mx1.ezwind.net> Message-ID: On Thu, Sep 24, 2020 at 10:57 AM John Foust via cctalk < cctalk at classiccmp.org> wrote: > > Mine stopped working a decade or so ago. I have a dozen or so, > but none are powering up any more. > > I seem to remember someone here who'd revived one. Did it mean > replacing sockets, replacing caps? > I repaired mine a couple of years back. The caps on my supplies (both in the CPU and the external disk unit) were mostly dead at the time (there was electrolyte leaking out of them, in fact). Replacing them brought them back to life. There was a fair amount of corrosion on the sockets for the RAM on mine due to the environment it had been stored in, this may not be the case on yours, but I was unable to make it run reliably until I replaced them. - Josh > > - John > > From barythrin at gmail.com Thu Sep 24 22:24:21 2020 From: barythrin at gmail.com (John Herron) Date: Thu, 24 Sep 2020 22:24:21 -0500 Subject: PSA to SparcBook 2 Users In-Reply-To: <1072AC35-D3AD-4ED2-AB2C-1D0D5A8F913B@gmail.com> References: <1072AC35-D3AD-4ED2-AB2C-1D0D5A8F913B@gmail.com> Message-ID: Apologies if this is easily found info but is there a good guide on getting into the tadpole systems? I recall my last time felt futile and I read some warnings from folks smarter than me suggesting its easy to break but not properly disassemble. On Tue, Sep 22, 2020, 1:45 PM null via cctalk wrote: > No, this applies only to Tadpole Series 2 and potentially Series 1 > machines (although I have not observed the latter) > > Series 3(/3000) are completely different internally. Your SB3000 is safe- > at least from this failure mode. > > > On Sep 22, 2020, at 11:02, Alan Perry via cctalk > wrote: > > > > ?You flush electronics with Indian Pale Ale? Too many TLAs. > > > > This isn't a problem on the model of SparcBook you sold me, is it? > > > >> On 9/22/20 10:53 AM, Ian Finder via cctalk wrote: > >> There is a 1000uf 10v cap on the main logic board just above the Bt > display controller. > >> It is leaking... a lot. (4/4 samples so far) > >> Go replace it, flush the area and scrub the with 99.9% IPA. > From jules.richardson99 at gmail.com Thu Sep 24 13:15:58 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Thu, 24 Sep 2020 13:15:58 -0500 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> Message-ID: <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> On 9/23/20 3:28 PM, Michael Engel via cctech wrote: > It seems that the problem lies in the firmware of the ACB4000, which > doesn?t seem to support some standard commands, e.g. the INQUIRY command. > Most recent Linux SCSI drivers seem to use this command. Lack of Inquiry support seems to be quite typical for early SCSI devices, sadly - and the Linux kernel at least has depended on it for a very long time. I remember trying to work out how to bypass it in the kernel source, but there were so many layers of code (without any design-type docs that I could find) that I ended up homebrewing a SCSI controller out of a few TTL chips and hacking some user-land code to drive it. From what I recall (this was around 15 years ago now) there aren't any timeouts to worry about on the HBA side of things, only on the targets, so it didn't matter that it was slow as molasses. cheers Jules From cctalk at gtaylor.tnetconsulting.net Thu Sep 24 22:10:41 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Thu, 24 Sep 2020 21:10:41 -0600 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> Message-ID: On 9/24/20 12:15 PM, Jules Richardson via cctech wrote: > the Linux kernel at least has depended on it for a very long time Do you have any idea how far back one might need to go to get a kernel that didn't depend on SCSI Inquiry? I wonder if a retro computer with a really old kernel and a SCSI card that it supported might be a viable option. -- Grant. . . . unix || die From dave.g4ugm at gmail.com Fri Sep 25 03:49:16 2020 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Fri, 25 Sep 2020 09:49:16 +0100 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> Message-ID: <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> Gentles, As its really an MFM Disk why not read it with an MFM adaptor? Something like:- https://www.pdp8.net/mfm/mfm.shtml which will read and image MFM disks and replace them. Expensive perhaps, but perhaps some one can lend you one to get an image... ... or if the SCSI <=> MFM adaptor supports two disks the use a DREM https://www.drem.info/tech-info and perhaps DD to copy the data..... Dave G4UGM > -----Original Message----- > From: cctalk On Behalf Of Grant Taylor via > cctalk > Sent: 25 September 2020 04:11 > To: cctech at classiccmp.org > Subject: Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM- > SCSI adapter? > > On 9/24/20 12:15 PM, Jules Richardson via cctech wrote: > > the Linux kernel at least has depended on it for a very long time > > Do you have any idea how far back one might need to go to get a kernel that > didn't depend on SCSI Inquiry? > > I wonder if a retro computer with a really old kernel and a SCSI card that it > supported might be a viable option. > > > > -- > Grant. . . . > unix || die From aek at bitsavers.org Fri Sep 25 07:24:52 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 25 Sep 2020 05:24:52 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> Message-ID: On 9/25/20 1:49 AM, Dave Wade G4UGM via cctalk wrote: > Gentles, > As its really an MFM Disk why not read it with an MFM adaptor? That was what I was wondering as well. From aek at bitsavers.org Fri Sep 25 07:28:14 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 25 Sep 2020 05:28:14 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> Message-ID: <605d18ca-34e6-396b-5a98-404251f38997@bitsavers.org> On 9/25/20 5:24 AM, Al Kossow via cctalk wrote: > On 9/25/20 1:49 AM, Dave Wade G4UGM via cctalk wrote: >> Gentles, >> As its really an MFM Disk why not read it with an MFM adaptor? > > That was what I was wondering as well. > > You really want one of Dave's boards if you need to do any sort of oddball mfm hd recovery. I just recovered the data yesterday from a ETH Ceres 32016 workstation with one. From pete at pski.net Fri Sep 25 07:31:37 2020 From: pete at pski.net (Peter Cetinski) Date: Fri, 25 Sep 2020 08:31:37 -0400 Subject: TRS-80 Trash Talk Live #7 Message-ID: We?re having another TRS-80 Trash Talk online gathering tomorrow. Everyone is welcome to join us! https://www.trs80trashtalk.com/2020/08/trs-80-trash-talk-live-7-is-coming-on.html Thanks, Pete From plamenspam at afterpeople.com Fri Sep 25 12:08:26 2020 From: plamenspam at afterpeople.com (Plamen Mihaylov) Date: Fri, 25 Sep 2020 20:08:26 +0300 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <605d18ca-34e6-396b-5a98-404251f38997@bitsavers.org> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> <605d18ca-34e6-396b-5a98-404251f38997@bitsavers.org> Message-ID: I was able to dump Torch Triple X System V, Release 1 Version 1.2 If anyone is interested I can share the image. Best regards, Plamen On Friday, September 25, 2020, Al Kossow via cctalk wrote: > On 9/25/20 5:24 AM, Al Kossow via cctalk wrote: > >> On 9/25/20 1:49 AM, Dave Wade G4UGM via cctalk wrote: >> >>> Gentles, >>> As its really an MFM Disk why not read it with an MFM adaptor? >>> >> >> That was what I was wondering as well. >> >> >> > You really want one of Dave's boards if you need to do any sort of oddball > mfm hd recovery. I just recovered the data yesterday from a ETH Ceres 32016 > workstation with one. > > From aek at bitsavers.org Fri Sep 25 12:31:46 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 25 Sep 2020 10:31:46 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> <605d18ca-34e6-396b-5a98-404251f38997@bitsavers.org> Message-ID: <2141b930-e537-1116-3d71-7e16c8a08368@bitsavers.org> On 9/25/20 10:08 AM, Plamen Mihaylov wrote: > I was able to dump Torch Triple X System V, Release 1 Version 1.2 > If anyone is interested I can share the image. I have a Torch Quad X CPU prototype CPU, missing the ASIC From aek at bitsavers.org Fri Sep 25 12:33:17 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 25 Sep 2020 10:33:17 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <2141b930-e537-1116-3d71-7e16c8a08368@bitsavers.org> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> <605d18ca-34e6-396b-5a98-404251f38997@bitsavers.org> <2141b930-e537-1116-3d71-7e16c8a08368@bitsavers.org> Message-ID: <6045cd15-eb85-06f8-dc8b-43006e055309@bitsavers.org> On 9/25/20 10:31 AM, Al Kossow via cctalk wrote: > On 9/25/20 10:08 AM, Plamen Mihaylov wrote: >> I was able to dump Torch Triple X System V, Release 1 Version 1.2 >> If anyone is interested I can share the image. > > I have a Torch Quad X CPU prototype CPU, missing the ASIC > did the ever scan all the manuals? http://www.computinghistory.org.uk/det/1031/Torch-Triple-X/ From jules.richardson99 at gmail.com Fri Sep 25 13:35:06 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Fri, 25 Sep 2020 13:35:06 -0500 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <2141b930-e537-1116-3d71-7e16c8a08368@bitsavers.org> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> <605d18ca-34e6-396b-5a98-404251f38997@bitsavers.org> <2141b930-e537-1116-3d71-7e16c8a08368@bitsavers.org> Message-ID: On 9/25/20 12:31 PM, Al Kossow via cctalk wrote: > On 9/25/20 10:08 AM, Plamen Mihaylov wrote: >> I was able to dump Torch Triple X System V, Release 1 Version 1.2 >> If anyone is interested I can share the image. > > I have a Torch Quad X CPU prototype CPU, missing the ASIC Interesting. I had a couple of Quad-X systems; one went off to the Centre for Computing History when I moved to the US, but the other I parked at TNMoC and can hopefully get back at some stage (post-pandemic). I don't know how many QX systems were made, but I don't think it was many - and they're probably significantly rare in the US. I do have some Quad-X source/design bits and pieces, I believe - I inherited a pile of Torch corporate hardware ~15 years ago, and among that were a couple of drives which had come from one of the company servers. cheers Jules From aek at bitsavers.org Fri Sep 25 16:05:52 2020 From: aek at bitsavers.org (Al Kossow) Date: Fri, 25 Sep 2020 14:05:52 -0700 Subject: Tektronix PDP-11 Signal Processing System BASIC 1980 Message-ID: Just recovered these RX01 diskettes today ca. 1980 http://bitsavers.org/bits/Tektronix/SPS_BASIC manuals http://bitsavers.org/test_equipment/tektronix/wdi From glen.slick at gmail.com Fri Sep 25 11:38:50 2020 From: glen.slick at gmail.com (Glen Slick) Date: Fri, 25 Sep 2020 09:38:50 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: On Wed, Sep 23, 2020 at 11:51 AM Michael Engel via cctech wrote: > > Hi, > > still working on backing up the Tektronix 440x disks. My current problem > is that the ACB4000 SCSI-to-MFM adapter doesn?t support SCSI parity. > > I finally managed to find a PCI SCSI controller (Adaptec 2940) and a > Pentium 4 PC with PCI slots and installed OpenBSD 6.7. I disabled parity > checking in the Adaptec BIOS config and it detects a disk at ID 0 with > no name. So far, so good. > If the Adaptec 2940 BIOS seems to detect the disk I wonder what would happen if DOS was set up on the system and ASPI8DOS.SYS was loaded. Would the Adaptec 2940 and ASPI driver respect the BIOS parity setting and interact with the ACB4000 bridge well enough for a fairly simple DOS program to be able to use the ASPI interface to send READ CDBs to read the sectors from the device? If I had such a device myself to experiment with I'd probably give that a try to see if it works. From boris at summitclinic.com Fri Sep 25 18:30:39 2020 From: boris at summitclinic.com (Boris Gimbarzevsky) Date: Fri, 25 Sep 2020 15:30:39 -0800 Subject: Tektronix PDP-11 Signal Processing System BASIC 1980 In-Reply-To: References: Message-ID: <20200925233106.10158273D9@mx1.ezwind.net> This may be unrelated, but seems that a Tektronix disk controller board I found when going through my shop might be related to the graphics terminal. Hadn't found Tektronix section on bitsavers prior to this post and drew a blank searching internet. Manufacturing dates on chips are 1980 and it's a Disk Controller J6928-01. It has 8 EPROM's which have labels that range from 160-0956 to 160-0963 where it appears that last 2 digits indicate bit position stored in the EPROM. Has NEC D765C chip which is a floppy disk controller and suspect that I knew this 35 years ago as was in proximity to an 8" floppy drive that bought. Have no idea what piece of Tektronix equipment it came from but it's available to a good home if anyone in need of it. Hadn't looked at old Tektronix test equipment for decades and remember seeing a lot of it in labs but generally beyond our research budget althought it was very well made and worked for decades. >Just recovered these RX01 diskettes today ca. 1980 > >http://bitsavers.org/bits/Tektronix/SPS_BASIC > >manuals >http://bitsavers.org/test_equipment/tektronix/wdi From cctalk at gtaylor.tnetconsulting.net Fri Sep 25 22:22:18 2020 From: cctalk at gtaylor.tnetconsulting.net (Grant Taylor) Date: Fri, 25 Sep 2020 21:22:18 -0600 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: On 9/25/20 10:38 AM, Glen Slick via cctalk wrote: > If the Adaptec 2940 BIOS seems to detect the disk I wonder what would > happen if DOS was set up on the system and ASPI8DOS.SYS was loaded. > Would the Adaptec 2940 and ASPI driver respect the BIOS parity setting > and interact with the ACB4000 bridge well enough for a fairly simple > DOS program to be able to use the ASPI interface to send READ CDBs > to read the sectors from the device? If I had such a device myself > to experiment with I'd probably give that a try to see if it works. If it would work, I wonder if you could then use something like Ghost to copy the drive to an image or another more standard drive that could then more easily be worked with. -- Grant. . . . unix || die From aek at bitsavers.org Sat Sep 26 02:47:17 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 26 Sep 2020 00:47:17 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: On 9/25/20 8:22 PM, Grant Taylor via cctalk wrote: > If it would work, I wonder if you could then use something like Ghost to copy the drive to an image or another more standard drive that > could then more easily be worked with. > > > DO NOT ATTEMPT TO USE A PC MFM CONTROLLER WITH DISKS FROM EARLY BRIDGE BOARDS There is a thread on VCF where someone tried to read a disk from a Viasyn S100 system with a PC controller and it silently REWROTE the contents of cyl 0 You have been warned From ard.p850ug1 at gmail.com Sat Sep 26 06:42:38 2020 From: ard.p850ug1 at gmail.com (Tony Duell) Date: Sat, 26 Sep 2020 12:42:38 +0100 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <6045cd15-eb85-06f8-dc8b-43006e055309@bitsavers.org> References: <1ea4fcc2-03a7-306d-6ec9-798720628f98@spamtrap.tnetconsulting.net> <82ba5f02-18ef-cc88-6c1d-8ac76a02de7d@gmail.com> <1d2701d69318$c0e37a80$42aa6f80$@gmail.com> <605d18ca-34e6-396b-5a98-404251f38997@bitsavers.org> <2141b930-e537-1116-3d71-7e16c8a08368@bitsavers.org> <6045cd15-eb85-06f8-dc8b-43006e055309@bitsavers.org> Message-ID: On Fri, Sep 25, 2020 at 6:33 PM Al Kossow via cctalk wrote: > > On 9/25/20 10:31 AM, Al Kossow via cctalk wrote: > > On 9/25/20 10:08 AM, Plamen Mihaylov wrote: > >> I was able to dump Torch Triple X System V, Release 1 Version 1.2 > >> If anyone is interested I can share the image. > > > > I have a Torch Quad X CPU prototype CPU, missing the ASIC > > > > did the ever scan all the manuals? > http://www.computinghistory.org.uk/det/1031/Torch-Triple-X/ I have a couple of Triple-Xs and a currently non-working Quad-X Somewhere I have the schematic I reverse-engineered of the Triple-X. I can dig it out and scan it if there's any interest. I also seem to have 13 tiff files which claim to be the official quad-X CPU board schematic which again I can share. I don't know if I kept the Triple-X service manual. I had it at one point and it was useless! No schematics. No pinouts. A block diagram with major errors. And a glossary with entries like : 'IC : Integrated Circuit. one of those black things on legs on a circuit board ICs : More than one IC' I am not making that up. [And it's not even accurate. The 68000, 68450 and 68451 are in ceramic packages and are therefore not black. Two of the ICs on the Omti SCSI-ST412 interface are in PLCC packages and are therefore not 'on legs'] -tony From pbirkel at gmail.com Sat Sep 26 06:51:50 2020 From: pbirkel at gmail.com (Paul Birkel) Date: Sat, 26 Sep 2020 07:51:50 -0400 Subject: Seeking: TMS32010 Assembly Language Programmer's Guide (1983) Message-ID: <098501d693fb$6c33b250$449b16f0$@gmail.com> All; I seek a copy (hard or electronic) of the "TMS32010 Assembly Language Programmer's Guide" (1983). Paperback : 194 pages ISBN-10 : 0904047423 ISBN-13 : 978-0904047424 Publisher : Texas Instruments (December 1, 1983) Item Weight : 1.11 pounds Language: : English The "TMS32010 User's Guide" (1985) is readily available. Not so the (more important!) Programmer's Guide :-{. I recently obtained a TMS 32010 Evaluation Module (EVM). So I'm motivated to "learn something" about the details of programming the TMS 32010. My first hands-on foray into the (early) world of DSP :-}. I've searched all of the nooks-n-crannies of the web to no avail. All help in locating/obtaining a copy of this document will be greatly appreciated. I do have a copy of "Digital Signal Processing Using TMS32010" (Douglas L. Jones) on order as a stop-gap measure. Thank you, paul From engel at multicores.org Sat Sep 26 10:32:53 2020 From: engel at multicores.org (Michael Engel) Date: Sat, 26 Sep 2020 17:32:53 +0200 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: On 9/26/20 5:22 AM, Grant Taylor via cctalk wrote: > On 9/25/20 10:38 AM, Glen Slick via cctalk wrote: >> If the Adaptec 2940 BIOS seems to detect the disk I wonder what would >> happen if DOS was set up on the system and ASPI8DOS.SYS was loaded. >> Would the Adaptec 2940 and ASPI driver respect the BIOS parity >> setting and interact with the ACB4000 bridge well enough for a fairly >> simple DOS program to be able to use the ASPI interface to send READ >> CDBs to read the sectors from the device? If I had such a device >> myself to experiment with I'd probably give that a try to see if it >> works. > > If it would work, I wonder if you could then use something like Ghost > to copy the drive to an image or another more standard drive that > could then more easily be worked with Using DOS might be another option, I seem to hit a roadblock with every Unix version I try... After quite a bit experimenting it seems that older Linux kernels (down to 2.2, I?m not sure if earlier kernels would support the Pentium 4 I have here) don?t seem to make a difference, Linux doesn?t talk to the disk via the Adaptec 2940 and complains about parity errors. So I tried another idea from this thread - using a SunOS 4 machine. I set up a Sparcstation LX for netbooting SunOS 4.1.4 and it discovers the disk (typed in from the screen, I didn?t think of setting up a serial console): sd3: non-CCS device found at target 0 lun 0 on esp0 sd3: at esp0 target 0 lun 0 sd3: corrupt label - wrong magic number sd3: Vendor ?ADAPTEC*?, product ?ACB4000*********?, 181520 512 byte blocks The corrupt label is expected and the vendor and product name as well as the disk size seem to be discovered correctly. However, when I try to dump the disk, I get the following error message: # dd if=/dev/sd3c of=/root/foo bs=512 (same for /dev/rsd3c) SunOS complains: dd: open: /dev/sd3c: No such device or address The disk is jumpered to address 0, it shows as address 3 due to the strange SCSI address renumbering of SunOS 4. Partition c should be the "whole disk" device. When I rejumper the ACB4000 to address 3, it shows as sd0 as expected - but I still get the same error message (with the other disk device name shown, of course). /dev/sd3c has major device ID 7, minor 26 (sd0c is 7/2), both were generated with the SunOS 4 MAKEDEV script in the NFS root directory, so they should be correct. I can also read the internal disk just fine with dd when I connect it. So it seems that this is a problem of a missing disk label that confuses the SunOS SCSI driver (I seem to remember having similar problems in the ?90s with our Suns)? Maybe I have to start reading SunOS kernel code... Btw., NetBSD (I tried 1.3.3 and 1.6.2) on the Sparc LX complains about SCSI phase errors if the ACB4000 is attached, so that?s also probably not an option. -- Michael From aek at bitsavers.org Sat Sep 26 10:56:04 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 26 Sep 2020 08:56:04 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: <85b486f7-35be-2d8e-51f9-e0cb53e68206@bitsavers.org> > sd3: non-CCS device found at target 0 lun 0 on esp0 > sd3: at esp0 target 0 lun 0 > sd3: corrupt label - wrong magic number > sd3: Vendor ?ADAPTEC*?, product ?ACB4000*********?, 181520 512 byte blocks ACB4000s aren't common command set. it expects the driver to tell it the drive parameters just get a gesswein mfm emulator already.. this is a trivial data recovery job for it From aek at bitsavers.org Sat Sep 26 10:59:25 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 26 Sep 2020 08:59:25 -0700 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <85b486f7-35be-2d8e-51f9-e0cb53e68206@bitsavers.org> References: <85b486f7-35be-2d8e-51f9-e0cb53e68206@bitsavers.org> Message-ID: <694ffa31-8a65-8983-e11b-bde5fa276529@bitsavers.org> On 9/26/20 8:56 AM, Al Kossow via cctech wrote: > >> sd3: non-CCS device found at target 0 lun 0 on esp0 >> sd3: at esp0 target 0 lun 0 >> sd3: corrupt label - wrong magic number >> sd3: Vendor ?ADAPTEC*?, product ?ACB4000*********?, 181520 512 byte blocks > > ACB4000s aren't common command set. > it expects the driver to tell it the drive parameters > > just get a gesswein mfm emulator already.. > this is a trivial data recovery job for it > i'm sorry if this offends you, but i watched the whole thread on vcf unfold where the guy screwed around with his rare copy of viasyn ccpm until he wiped out a part of it you ARE doing this with write-gate cut on the cable, right? From rdawson16 at hotmail.com Sat Sep 26 14:12:32 2020 From: rdawson16 at hotmail.com (Randy Dawson) Date: Sat, 26 Sep 2020 19:12:32 +0000 Subject: Tektronix PDP-11 Signal Processing System BASIC 1980 In-Reply-To: References: Message-ID: Hi Al, Fantastic! Your work here has always been the best, and the Tektronix graphics documents, as a subject was on target. I have a Tek 4051, and, its gathering dust. I need to fix a broken trace blanking, but this thing is hard to get into. Its going to be lay it out on the bench for scope probing. Thanks Al, for the post, Randy ________________________________ From: cctalk on behalf of Al Kossow via cctalk Sent: Friday, September 25, 2020 2:05 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Tektronix PDP-11 Signal Processing System BASIC 1980 Just recovered these RX01 diskettes today ca. 1980 http://bitsavers.org/bits/Tektronix/SPS_BASIC manuals http://bitsavers.org/test_equipment/tektronix/wdi From mmcgraw74 at gmail.com Sat Sep 26 15:31:29 2020 From: mmcgraw74 at gmail.com (Monty McGraw) Date: Sat, 26 Sep 2020 15:31:29 -0500 Subject: Tektronix PDP-11 Signal Processing System BASIC 1980 In-Reply-To: References: Message-ID: Randy, If you haven't checked already, we have quite a few posts on Tektronix 4051,4052 and 4054 including repairs on vcfed.org in the "Other" forum. I have recovered lots of old 4050 program tapes and posted them to my github repository: https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files If your 4051 includes the RS-232 option in your ROM backpack, you can download the programs from a PC serial program like Realterm to your 4051, once you get your 4051 repaired. I just repaired my 4054A, which stopped clearing the screen when I pressed the PAGE key or ran the PAGE command. I found that the problem was the one-shot IC on that circuit had died and had to be replaced. If your problem is on the display board - it is easy to access with the cover removed. Monty On Sat, Sep 26, 2020 at 2:12 PM Randy Dawson via cctalk < cctalk at classiccmp.org> wrote: > Hi Al, > > Fantastic! > Your work here has always been the best, and the Tektronix graphics > documents, as a subject was on target. > I have a Tek 4051, and, its gathering dust. I need to fix a broken trace > blanking, but this thing is hard to get into. Its going to be lay it out > on the bench for scope probing. > Thanks Al, for the post, > Randy > > > ________________________________ > From: cctalk on behalf of Al Kossow via > cctalk > Sent: Friday, September 25, 2020 2:05 PM > To: General Discussion: On-Topic and Off-Topic Posts < > cctalk at classiccmp.org> > Subject: Tektronix PDP-11 Signal Processing System BASIC 1980 > > Just recovered these RX01 diskettes today ca. 1980 > > http://bitsavers.org/bits/Tektronix/SPS_BASIC > > manuals > http://bitsavers.org/test_equipment/tektronix/wdi > From jules.richardson99 at gmail.com Sat Sep 26 17:47:46 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Sat, 26 Sep 2020 17:47:46 -0500 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: <85b486f7-35be-2d8e-51f9-e0cb53e68206@bitsavers.org> References: <85b486f7-35be-2d8e-51f9-e0cb53e68206@bitsavers.org> Message-ID: <4943dc2b-d52c-050e-3f9d-0e4cef2f1290@gmail.com> On 9/26/20 10:56 AM, Al Kossow via cctech wrote: > ACB4000s aren't common command set. > it expects the driver to tell it the drive parameters I'm possibly/probably wrong, but I thought the ACB-4000 only needs the parameters setting prior to format - I don't know it it has some form of non volatile RAM (unlikely) or if it stores the params in the first sector on the drive and then offsets r/w requests by a set amount (I know at least one vendor's board did that) so that they don't get overwritten. From jules.richardson99 at gmail.com Sat Sep 26 17:51:11 2020 From: jules.richardson99 at gmail.com (Jules Richardson) Date: Sat, 26 Sep 2020 17:51:11 -0500 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: <10154a3b-b326-6f9e-71dc-55ab0016c287@gmail.com> On 9/26/20 10:32 AM, Michael Engel via cctech wrote: > Using DOS might be another option, I seem to hit a roadblock with every > Unix version I try... hmm, have a look here: http://ftp.vim.org/ftp/pub/ibiblio/kernel/patches/scsi ... adaptec-40XX-1.02.tar.gz looks like it might do the trick. Use at your own risk etc. :-) From plamenspam at afterpeople.com Sun Sep 27 03:52:31 2020 From: plamenspam at afterpeople.com (Plamen Mihaylov) Date: Sun, 27 Sep 2020 11:52:31 +0300 Subject: dec tk50z-ga issues Message-ID: Hi all, Since I don't have a machine with qbus and I need to backup some vms and ultrix tk50 tapes, I purchased a tk50z-ga from ebay. Upon power up, the red led flashing rapidly(which means drive fault) then goes to solid red. I've never used TK50 drives in the past so if you have any hint how to troubleshoot this it would be appreciated. Or should I start looking for a replacement? Regards, Plamen From rich.cini at gmail.com Sun Sep 27 09:07:50 2020 From: rich.cini at gmail.com (Richard Cini) Date: Sun, 27 Sep 2020 10:07:50 -0400 Subject: SCP/Microsoft 20HAL uploader Message-ID: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> All ? I?ve done a quite a bit of work with my Seattle Gazelle, and I just did some work on 86DOS.SYS (not released in source form, as far as I know) and its comparison to PC DOS 1.0 (at the code level, a very high correlation as you can imagine). Partially related to that is a program called ?20HAL? which was a code uploader Microsoft used in the late stages to get code from Microsoft in Bellevue to IBM in Boca Raton, FL. I did a little write-up on it here (http://www.classiccmp.org/cini/hal.htm) There are some holes in the analysis ? I think it?s pretty close, though -- but I?d really like to get some more details on it. Unfortunately, it?s 40-year-old code at this point, and how many people remember how they used a file transfer utility that long ago? Anyway, enjoy the read. If anyone sees any corrections that need to be made, let me know. Thanks! Rich -- Rich Cini http://www.classiccmp.org/cini http://www.classiccmp.org/altair32 From dkelvey at hotmail.com Sun Sep 27 12:34:59 2020 From: dkelvey at hotmail.com (dwight) Date: Sun, 27 Sep 2020 17:34:59 +0000 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> Message-ID: This is great work, Rich. It is like looking at dinosaur bones and trying to figure what it was eating. Dwight ________________________________ From: cctalk on behalf of Richard Cini via cctalk Sent: Sunday, September 27, 2020 7:07 AM To: Discussion: On-Topic Posts Only Subject: SCP/Microsoft 20HAL uploader All ? I?ve done a quite a bit of work with my Seattle Gazelle, and I just did some work on 86DOS.SYS (not released in source form, as far as I know) and its comparison to PC DOS 1.0 (at the code level, a very high correlation as you can imagine). Partially related to that is a program called ?20HAL? which was a code uploader Microsoft used in the late stages to get code from Microsoft in Bellevue to IBM in Boca Raton, FL. I did a little write-up on it here (http://www.classiccmp.org/cini/hal.htm) There are some holes in the analysis ? I think it?s pretty close, though -- but I?d really like to get some more details on it. Unfortunately, it?s 40-year-old code at this point, and how many people remember how they used a file transfer utility that long ago? Anyway, enjoy the read. If anyone sees any corrections that need to be made, let me know. Thanks! Rich -- Rich Cini http://www.classiccmp.org/cini http://www.classiccmp.org/altair32 From dkelvey at hotmail.com Sun Sep 27 12:34:59 2020 From: dkelvey at hotmail.com (dwight) Date: Sun, 27 Sep 2020 17:34:59 +0000 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> Message-ID: This is great work, Rich. It is like looking at dinosaur bones and trying to figure what it was eating. Dwight ________________________________ From: cctalk on behalf of Richard Cini via cctalk Sent: Sunday, September 27, 2020 7:07 AM To: Discussion: On-Topic Posts Only Subject: SCP/Microsoft 20HAL uploader All ? I?ve done a quite a bit of work with my Seattle Gazelle, and I just did some work on 86DOS.SYS (not released in source form, as far as I know) and its comparison to PC DOS 1.0 (at the code level, a very high correlation as you can imagine). Partially related to that is a program called ?20HAL? which was a code uploader Microsoft used in the late stages to get code from Microsoft in Bellevue to IBM in Boca Raton, FL. I did a little write-up on it here (http://www.classiccmp.org/cini/hal.htm) There are some holes in the analysis ? I think it?s pretty close, though -- but I?d really like to get some more details on it. Unfortunately, it?s 40-year-old code at this point, and how many people remember how they used a file transfer utility that long ago? Anyway, enjoy the read. If anyone sees any corrections that need to be made, let me know. Thanks! Rich -- Rich Cini http://www.classiccmp.org/cini http://www.classiccmp.org/altair32 From rich.cini at verizon.net Sun Sep 27 12:39:49 2020 From: rich.cini at verizon.net (Richard Cini) Date: Sun, 27 Sep 2020 13:39:49 -0400 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> Message-ID: Thanks Dwight. I call it "digital archaeology". Doing a little more work on it today, trying to see what responses it might expect from the remote system. I did find specific text strings that have "CPM" in it, so my theory about the origination is probably right. I'm hoping to use some "six degrees of Kevin Bacon" here...maybe someone knows someone who knows. I may post the edited listing file at some point. Rich ?On 9/27/20, 1:35 PM, "cctalk on behalf of dwight via cctalk" wrote: This is great work, Rich. It is like looking at dinosaur bones and trying to figure what it was eating. Dwight ________________________________ From: cctalk on behalf of Richard Cini via cctalk Sent: Sunday, September 27, 2020 7:07 AM To: Discussion: On-Topic Posts Only Subject: SCP/Microsoft 20HAL uploader All ? I?ve done a quite a bit of work with my Seattle Gazelle, and I just did some work on 86DOS.SYS (not released in source form, as far as I know) and its comparison to PC DOS 1.0 (at the code level, a very high correlation as you can imagine). Partially related to that is a program called ?20HAL? which was a code uploader Microsoft used in the late stages to get code from Microsoft in Bellevue to IBM in Boca Raton, FL. I did a little write-up on it here (http://www.classiccmp.org/cini/hal.htm) There are some holes in the analysis ? I think it?s pretty close, though -- but I?d really like to get some more details on it. Unfortunately, it?s 40-year-old code at this point, and how many people remember how they used a file transfer utility that long ago? Anyway, enjoy the read. If anyone sees any corrections that need to be made, let me know. Thanks! Rich -- Rich Cini http://www.classiccmp.org/cini http://www.classiccmp.org/altair32 From rich.cini at verizon.net Sun Sep 27 12:39:49 2020 From: rich.cini at verizon.net (Richard Cini) Date: Sun, 27 Sep 2020 13:39:49 -0400 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> Message-ID: Thanks Dwight. I call it "digital archaeology". Doing a little more work on it today, trying to see what responses it might expect from the remote system. I did find specific text strings that have "CPM" in it, so my theory about the origination is probably right. I'm hoping to use some "six degrees of Kevin Bacon" here...maybe someone knows someone who knows. I may post the edited listing file at some point. Rich ?On 9/27/20, 1:35 PM, "cctalk on behalf of dwight via cctalk" wrote: This is great work, Rich. It is like looking at dinosaur bones and trying to figure what it was eating. Dwight ________________________________ From: cctalk on behalf of Richard Cini via cctalk Sent: Sunday, September 27, 2020 7:07 AM To: Discussion: On-Topic Posts Only Subject: SCP/Microsoft 20HAL uploader All ? I?ve done a quite a bit of work with my Seattle Gazelle, and I just did some work on 86DOS.SYS (not released in source form, as far as I know) and its comparison to PC DOS 1.0 (at the code level, a very high correlation as you can imagine). Partially related to that is a program called ?20HAL? which was a code uploader Microsoft used in the late stages to get code from Microsoft in Bellevue to IBM in Boca Raton, FL. I did a little write-up on it here (http://www.classiccmp.org/cini/hal.htm) There are some holes in the analysis ? I think it?s pretty close, though -- but I?d really like to get some more details on it. Unfortunately, it?s 40-year-old code at this point, and how many people remember how they used a file transfer utility that long ago? Anyway, enjoy the read. If anyone sees any corrections that need to be made, let me know. Thanks! Rich -- Rich Cini http://www.classiccmp.org/cini http://www.classiccmp.org/altair32 From spectre at floodgap.com Sun Sep 27 15:45:29 2020 From: spectre at floodgap.com (Cameron Kaiser) Date: Sun, 27 Sep 2020 13:45:29 -0700 (PDT) Subject: Alpha Micro goes gopher Message-ID: <202009272045.08RKjTgf37683314@floodgap.com> (also posted to VCF) If you'd like a longer story version, I posted this in long form with some pictures: https://oldvcr.blogspot.com/2020/09/hacking-gopher-client-into-alpha-micro.html I've hacked up a Gopher client into the Alpha Micro. It requires AMOS 2.3A and either AlphaTCP 1.3C or 1.5A, and is written in both assembly (using a hacked version of the AlphaTCP finger client) and AlphaBASIC. gopher://gopher.floodgap.com/1/archive/alpha-micro/gopher And why would I do this, other than the fact I like Gopherspace? Because I've also uploaded the Alpha Micro Users' Society Network Library to the Floodgap gopher server, with oodles of free binaries and source code lovingly preserved in their original PPNs. gopher://gopher.floodgap.com/1/archive/alpha-micro/amus (No Gopher client? Visit https://gopher.floodgap.com/overbite/ to download one, or view it on the proxy: https://gopher.floodgap.com/gopher/gw?gopher://gopher.floodgap.com:70/1/archive/alpha-micro ) And, if you want to know more about Alpha Microsystems, the Alpha Micro Phun Machine has been updated as well: http://ampm.floodgap.com/ -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Seen on hand dryer: "Push button for a message from your congressman." ----- From gavin at learn.bio Sun Sep 27 16:21:49 2020 From: gavin at learn.bio (Gavin Scott) Date: Sun, 27 Sep 2020 16:21:49 -0500 Subject: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff. Message-ID: As some people here are aware, I have spent probably too much time this summer hacking on J. David Bryan's excellent Classic HP 3000 simulator and trying to build up the ultimate classic 1980s HP 3000 system (virtually speaking). I started with the MPE V/R KIT that's widely available and expanded that into a 5x120MB HP 7925 disc system and configured things like the system directory size and all the system tables to make a fully functional multi-user server. I then set about collecting as much old MPE software as I could find, which included Keven Miller's collection of the old Contributed Software Library tapes which were conveniently available in SIMH format. This is a huge trove of cool stuff including most of the classic mini/mainframe games (Dungeon, Warp, Advent, etc., etc.) and even a little game called DRAGONS that was written in 1980 by a guy named Bruce Nesmith when he was in college and he used it to get a job at TSR and went on to write parts of many classic D&D products and eventually landed at Bethesda where among other things he was the lead designer for another little game called The Elder Scrolls V: Skyrim. I was able to track Bruce down and give him a copy of the system with his 40 year old game running on it. The CSL tapes also include other amazing goodies that people developed and gave away over the years, including a FORTH and LISP, as well as most of the system and utility programs that people used to run their 3000 shops. It's quite fun to explore. I was curious how far we could push the 3000 simulator, so I hacked all the memory bank registers to be six bits instead of four bits, and we now have a simulated HP 3000 Series III that supports 8MB of memory, 4x more than any physical system ever did. I started trying to do the same thing for giant disc drives, but MPE turned out to have too much knowledge of what the supported disc models look like to make it practical. Bummer. Since I met my first HP 3000 in 1980 (40 years ago this month), people would talk about what was probably the most rare and exotic HP software subsystem ever produced, APL\3000. APL on the 3000 was a project started at HP Labs in Palo Alto in the early 1970s. They were likely motivated by the success IBM was having with mainframe APL timesharing services. This would be the first full APL implementation on a "small" (non-mainframe) computer. It would be the first APL with a compiler (and a byte-code virtual machine to execute the compiled code), it would include an additional new language APLGOL (APL with ALGOL like structured control statements), and it managed to support APL workspaces of unlimited size through a clever set of system CPU microcode extensions that provided a flat 32-bit addressing capability (on a 16-bit machine where every other language was limited to a 64KB data segment). Because APL required these extra special CPU instructions that you got as a set of ROM chips when you bought the $15,000 APL\3000, and because APL ultimately failed as a product (another story in itself) and thus HP never implemented these instructions on their later HP 3000 models, I never saw it run on a real HP 3000, but over the years we talked about wouldn't it be cool to find a way to get APL running again. With assistance and moral support from Stan Sieler and Frank McConnell and others, I was ultimately able to reverse-engineer the behavior of the undocumented ten magic APL CPU instructions needed to get it to run and implement them as part of the MPE unimplemented instruction trap and now APL\3000 runs again for the first time in ~35 years. Somewhat ironically, this implementation method could have been used back in 1980 as I didn't actually end up changing the hardware simulation code at all, and it should also run (if a bit slowly) on any physical classic architecture 3000. So that was cool and all, but what is APL without all the weird overstruck characters and whatnot? APL\3000 supports the use of plain ASCII terminals through blecherous trigraphs like "QD for the APL quad character, but this is hardly satisfying. So the quest was on to find a solution. Back in 1976 when APL\3000 was released, there was a companion HP terminal in the 264x line, the HP 2641A APL Display Station, which was basically an HP 2645A with special firmware and APL character set ROMs that supported all the APL special characters as well as overstrikes (the terminal would take XY and lookup to see if it had a character to represent Y overstriking X and if so it would show that on the display, and if that got transmitted to the host it would convert it back into the original three character overstriking sequence). I briefly looked into the idea of hacking QCTerm or Putty or something, but then I found out from Curious Chris that an HP 2645A emulator already existed in the MAME emulator system! Since the '41 is basically just a '45 with modified firmware, and Bitsavers had both the character set ROMs as well as the firmware ROMs from a '41, this sounded like it might be easy! There was a snag however in that the firmware ROM images that were allegedly from a '41 turned out to actually be from an ordinary '45. But we did have the character sets and one of the ROMs from the second CTL PCA. I put out a call on the Vintage HP list to see if anyone might possibly have a lead on an actual HP 2641A, and Kyle Owen responded that not only did he have one he could also dump the ROMs for us. So a few days and a few hacks to F. Ulivi's MAME hp2645 driver later we now have a functioning MAME HP 2641A terminal emulation, so you can experience APL\3000 in all its original glory. I bundled up a somewhat stripped down MAME along with my turnkey 3000 setup so both emulated HP terminals are just a couple clicks away. So that's how I spent my summer vacation (who am I kidding, it's pretty much all vacation these days). It has been a lot of fun revisiting all this old 3000 stuff as well as the numerous people I talked to along the way including some of those who were around at APL\3000's birth (before my time). It was rather a lot of work so I'd like to feel it might be useful to someone in the future who is digging into this part of history. Because of all the usual reasons, I don't plan on hosting it permanently until and unless we maybe someday get the licensing worked out (the 50th anniversary of the HP 3000 will be in a couple years so maybe people will get interested again then) but I will offer it up here to my fellow computer history nuts if you want to help ensure that it doesn't vanish if I get run over by a bus or something :) This is a simulated HP 3000 Series III (circa 1980) running MPE V/R (circa 1986) with 8MB of memory, all the language subsystems (APL, BASIC, BASICOMP, RPG, FORTRAN (66), SPL, PASCAL, COBOL (68), COBOL II (74)), 20 years of users group contributed software, many classic historical computer games, etc. Software archaeologists can get lost in here for years. Oh, and thanks to Dave Elward, the HP 2000 Timesharing BASIC contributed library is even included (kinda sorta converted to MPE BASIC) for good measure. This is a streamlined turnkey edition that's ready to run out of the box with no assembly required (all batteries are included). Currently, I only provide executables for Windows (sorry) but am in the process of getting the 3000 simulator changes (for large memory support) and the new MAME hp2641 driver back upstream. Instructions and further details can be found in the README.txt hint book for this adventure. 94MB Google Drive link: https://drive.google.com/file/d/1bmXvHkBLbUeLAid73EJ4H1yQ2uwXQuRu Gavin P.S. I'm giving a talk on the history of APL\3000 and its resurrection to the ACM APLBUG group in a couple weeks. If anyone is interested I can provide more details when I have them. From leec2124 at gmail.com Sun Sep 27 16:28:43 2020 From: leec2124 at gmail.com (Lee Courtney) Date: Sun, 27 Sep 2020 14:28:43 -0700 Subject: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff. In-Reply-To: References: Message-ID: Gavin, A-W-E-S-O-M-E ! ! ! On Sun, Sep 27, 2020 at 2:22 PM Gavin Scott via cctalk < cctalk at classiccmp.org> wrote: > As some people here are aware, I have spent probably too much time this > summer > hacking on J. David Bryan's excellent Classic HP 3000 simulator and trying > to > build up the ultimate classic 1980s HP 3000 system (virtually speaking). > > I started with the MPE V/R KIT that's widely available and expanded that > into a > 5x120MB HP 7925 disc system and configured things like the system directory > size and all the system tables to make a fully functional multi-user > server. > > I then set about collecting as much old MPE software as I could find, which > included Keven Miller's collection of the old Contributed Software Library > tapes > which were conveniently available in SIMH format. This is a huge trove of > cool > stuff including most of the classic mini/mainframe games (Dungeon, Warp, > Advent, etc., etc.) and even a little game called DRAGONS that was written > in > 1980 by a guy named Bruce Nesmith when he was in college and he used it > to get a job at TSR and went on to write parts of many classic D&D products > and eventually landed at Bethesda where among other things he was the > lead designer for another little game called The Elder Scrolls V: Skyrim. > I was > able to track Bruce down and give him a copy of the system with his 40 year > old game running on it. The CSL tapes also include other amazing goodies > that people developed and gave away over the years, including a FORTH and > LISP, as well as most of the system and utility programs that people used > to > run their 3000 shops. It's quite fun to explore. > > I was curious how far we could push the 3000 simulator, so I hacked all > the memory bank registers to be six bits instead of four bits, and we > now have a simulated HP 3000 Series III that supports 8MB of memory, 4x > more than any physical system ever did. I started trying to do the same > thing > for giant disc drives, but MPE turned out to have too much knowledge of > what the supported disc models look like to make it practical. Bummer. > > Since I met my first HP 3000 in 1980 (40 years ago this month), people > would > talk about what was probably the most rare and exotic HP software subsystem > ever produced, APL\3000. APL on the 3000 was a project started at HP Labs > in Palo Alto in the early 1970s. They were likely motivated by the success > IBM > was having with mainframe APL timesharing services. This would be the first > full APL implementation on a "small" (non-mainframe) computer. It would be > the > first APL with a compiler (and a byte-code virtual machine to execute the > compiled code), it would include an additional new language APLGOL (APL > with ALGOL like structured control statements), and it managed to support > APL workspaces of unlimited size through a clever set of system CPU > microcode extensions that provided a flat 32-bit addressing capability (on > a 16-bit machine where every other language was limited to a 64KB data > segment). > > Because APL required these extra special CPU instructions that you got as > a set of ROM chips when you bought the $15,000 APL\3000, and because > APL ultimately failed as a product (another story in itself) and thus HP > never > implemented these instructions on their later HP 3000 models, I never saw > it run on a real HP 3000, but over the years we talked about wouldn't it be > cool to find a way to get APL running again. > > With assistance and moral support from Stan Sieler and Frank McConnell > and others, I was ultimately able to reverse-engineer the behavior of the > undocumented ten magic APL CPU instructions needed to get it to run and > implement them as part of the MPE unimplemented instruction trap and now > APL\3000 runs again for the first time in ~35 years. Somewhat ironically, > this > implementation method could have been used back in 1980 as I didn't > actually end up changing the hardware simulation code at all, and it should > also run (if a bit slowly) on any physical classic architecture 3000. > > So that was cool and all, but what is APL without all the weird overstruck > characters and whatnot? APL\3000 supports the use of plain ASCII terminals > through blecherous trigraphs like "QD for the APL quad character, but this > is hardly satisfying. So the quest was on to find a solution. Back in 1976 > when > APL\3000 was released, there was a companion HP terminal in the 264x line, > the HP 2641A APL Display Station, which was basically an HP 2645A with > special firmware and APL character set ROMs that supported all the APL > special characters as well as overstrikes (the terminal would take > XY > and lookup to see if it had a character to represent Y overstriking X and > if > so it would show that on the display, and if that got transmitted to the > host it > would convert it back into the original three character overstriking > sequence). > > I briefly looked into the idea of hacking QCTerm or Putty or something, but > then I found out from Curious Chris that an HP 2645A emulator already > existed > in the MAME emulator system! Since the '41 is basically just a '45 with > modified > firmware, and Bitsavers had both the character set ROMs as well as the > firmware ROMs from a '41, this sounded like it might be easy! There was a > snag > however in that the firmware ROM images that were allegedly from a '41 > turned > out to actually be from an ordinary '45. But we did have the character > sets and > one of the ROMs from the second CTL PCA. I put out a call on the Vintage HP > list to see if anyone might possibly have a lead on an actual HP 2641A, and > Kyle Owen responded that not only did he have one he could also dump the > ROMs for us. So a few days and a few hacks to F. Ulivi's MAME hp2645 driver > later we now have a functioning MAME HP 2641A terminal emulation, so you > can experience APL\3000 in all its original glory. I bundled up a somewhat > stripped down MAME along with my turnkey 3000 setup so both emulated HP > terminals are just a couple clicks away. > > So that's how I spent my summer vacation (who am I kidding, it's pretty > much all > vacation these days). It has been a lot of fun revisiting all this old > 3000 stuff as > well as the numerous people I talked to along the way including some of > those > who were around at APL\3000's birth (before my time). It was rather a lot > of > work so I'd like to feel it might be useful to someone in the future > who is digging > into this part of history. Because of all the usual reasons, I don't > plan on hosting > it permanently until and unless we maybe someday get the licensing worked > out > (the 50th anniversary of the HP 3000 will be in a couple years so maybe > people > will get interested again then) but I will offer it up here to my > fellow computer > history nuts if you want to help ensure that it doesn't vanish if I > get run over by a > bus or something :) > > This is a simulated HP 3000 Series III (circa 1980) running MPE V/R (circa > 1986) > with 8MB of memory, all the language subsystems (APL, BASIC, BASICOMP, RPG, > FORTRAN (66), SPL, PASCAL, COBOL (68), COBOL II (74)), 20 years of users > group > contributed software, many classic historical computer games, etc. Software > archaeologists can get lost in here for years. Oh, and thanks to Dave > Elward, the > HP 2000 Timesharing BASIC contributed library is even included (kinda sorta > converted to MPE BASIC) for good measure. This is a streamlined turnkey > edition > that's ready to run out of the box with no assembly required (all > batteries are included). > Currently, I only provide executables for Windows (sorry) but am in > the process of > getting the 3000 simulator changes (for large memory support) and the new > MAME > hp2641 driver back upstream. Instructions and further details can be > found in the > README.txt hint book for this adventure. 94MB Google Drive link: > > https://drive.google.com/file/d/1bmXvHkBLbUeLAid73EJ4H1yQ2uwXQuRu > > Gavin > > P.S. I'm giving a talk on the history of APL\3000 and its resurrection > to the ACM APLBUG > group in a couple weeks. If anyone is interested I can provide more > details when I have > them. > -- Lee Courtney +1-650-704-3934 cell From dave.g4ugm at gmail.com Sun Sep 27 16:49:11 2020 From: dave.g4ugm at gmail.com (dave.g4ugm at gmail.com) Date: Sun, 27 Sep 2020 22:49:11 +0100 Subject: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff. In-Reply-To: References: Message-ID: <333501d69518$0958da20$1c0a8e60$@gmail.com> I can only say "wow"... .... what a wonderful effort..... Dave Wade > -----Original Message----- > From: cctalk On Behalf Of Gavin Scott via > cctalk > Sent: 27 September 2020 22:22 > To: cctalk at classiccmp.org > Subject: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff. > > As some people here are aware, I have spent probably too much time this > summer hacking on J. David Bryan's excellent Classic HP 3000 simulator and > trying to build up the ultimate classic 1980s HP 3000 system (virtually > speaking). > > I started with the MPE V/R KIT that's widely available and expanded that into > a 5x120MB HP 7925 disc system and configured things like the system > directory size and all the system tables to make a fully functional multi-user > server. > > I then set about collecting as much old MPE software as I could find, which > included Keven Miller's collection of the old Contributed Software Library > tapes which were conveniently available in SIMH format. This is a huge trove > of cool stuff including most of the classic mini/mainframe games (Dungeon, > Warp, Advent, etc., etc.) and even a little game called DRAGONS that was > written in > 1980 by a guy named Bruce Nesmith when he was in college and he used it to > get a job at TSR and went on to write parts of many classic D&D products and > eventually landed at Bethesda where among other things he was the lead > designer for another little game called The Elder Scrolls V: Skyrim. I was able > to track Bruce down and give him a copy of the system with his 40 year old > game running on it. The CSL tapes also include other amazing goodies that > people developed and gave away over the years, including a FORTH and LISP, > as well as most of the system and utility programs that people used to run > their 3000 shops. It's quite fun to explore. > > I was curious how far we could push the 3000 simulator, so I hacked all the > memory bank registers to be six bits instead of four bits, and we now have a > simulated HP 3000 Series III that supports 8MB of memory, 4x more than any > physical system ever did. I started trying to do the same thing for giant disc > drives, but MPE turned out to have too much knowledge of what the > supported disc models look like to make it practical. Bummer. > > Since I met my first HP 3000 in 1980 (40 years ago this month), people would > talk about what was probably the most rare and exotic HP software > subsystem ever produced, APL\3000. APL on the 3000 was a project started > at HP Labs in Palo Alto in the early 1970s. They were likely motivated by the > success IBM was having with mainframe APL timesharing services. This would > be the first full APL implementation on a "small" (non-mainframe) computer. > It would be the first APL with a compiler (and a byte-code virtual machine to > execute the compiled code), it would include an additional new language > APLGOL (APL with ALGOL like structured control statements), and it managed > to support APL workspaces of unlimited size through a clever set of system > CPU microcode extensions that provided a flat 32-bit addressing capability > (on a 16-bit machine where every other language was limited to a 64KB data > segment). > > Because APL required these extra special CPU instructions that you got as a > set of ROM chips when you bought the $15,000 APL\3000, and because APL > ultimately failed as a product (another story in itself) and thus HP never > implemented these instructions on their later HP 3000 models, I never saw it > run on a real HP 3000, but over the years we talked about wouldn't it be cool > to find a way to get APL running again. > > With assistance and moral support from Stan Sieler and Frank McConnell and > others, I was ultimately able to reverse-engineer the behavior of the > undocumented ten magic APL CPU instructions needed to get it to run and > implement them as part of the MPE unimplemented instruction trap and > now > APL\3000 runs again for the first time in ~35 years. Somewhat ironically, this > implementation method could have been used back in 1980 as I didn't > actually end up changing the hardware simulation code at all, and it should > also run (if a bit slowly) on any physical classic architecture 3000. > > So that was cool and all, but what is APL without all the weird overstruck > characters and whatnot? APL\3000 supports the use of plain ASCII terminals > through blecherous trigraphs like "QD for the APL quad character, but this is > hardly satisfying. So the quest was on to find a solution. Back in 1976 when > APL\3000 was released, there was a companion HP terminal in the 264x line, > the HP 2641A APL Display Station, which was basically an HP 2645A with > special firmware and APL character set ROMs that supported all the APL > special characters as well as overstrikes (the terminal would take > XY and lookup to see if it had a character to represent Y > overstriking X and if so it would show that on the display, and if that got > transmitted to the host it would convert it back into the original three > character overstriking sequence). > > I briefly looked into the idea of hacking QCTerm or Putty or something, but > then I found out from Curious Chris that an HP 2645A emulator already > existed in the MAME emulator system! Since the '41 is basically just a '45 with > modified firmware, and Bitsavers had both the character set ROMs as well as > the firmware ROMs from a '41, this sounded like it might be easy! There was > a snag however in that the firmware ROM images that were allegedly from a > '41 turned out to actually be from an ordinary '45. But we did have the > character sets and one of the ROMs from the second CTL PCA. I put out a call > on the Vintage HP list to see if anyone might possibly have a lead on an actual > HP 2641A, and Kyle Owen responded that not only did he have one he could > also dump the ROMs for us. So a few days and a few hacks to F. Ulivi's MAME > hp2645 driver later we now have a functioning MAME HP 2641A terminal > emulation, so you can experience APL\3000 in all its original glory. I bundled > up a somewhat stripped down MAME along with my turnkey 3000 setup so > both emulated HP terminals are just a couple clicks away. > > So that's how I spent my summer vacation (who am I kidding, it's pretty much > all vacation these days). It has been a lot of fun revisiting all this old > 3000 stuff as > well as the numerous people I talked to along the way including some of > those who were around at APL\3000's birth (before my time). It was rather a > lot of work so I'd like to feel it might be useful to someone in the future who > is digging into this part of history. Because of all the usual reasons, I don't > plan on hosting it permanently until and unless we maybe someday get the > licensing worked out (the 50th anniversary of the HP 3000 will be in a couple > years so maybe people will get interested again then) but I will offer it up > here to my fellow computer history nuts if you want to help ensure that it > doesn't vanish if I get run over by a bus or something :) > > This is a simulated HP 3000 Series III (circa 1980) running MPE V/R (circa 1986) > with 8MB of memory, all the language subsystems (APL, BASIC, BASICOMP, > RPG, FORTRAN (66), SPL, PASCAL, COBOL (68), COBOL II (74)), 20 years of > users group contributed software, many classic historical computer games, > etc. Software archaeologists can get lost in here for years. Oh, and thanks to > Dave Elward, the HP 2000 Timesharing BASIC contributed library is even > included (kinda sorta converted to MPE BASIC) for good measure. This is a > streamlined turnkey edition that's ready to run out of the box with no > assembly required (all batteries are included). > Currently, I only provide executables for Windows (sorry) but am in the > process of getting the 3000 simulator changes (for large memory support) > and the new MAME > hp2641 driver back upstream. Instructions and further details can be found in > the README.txt hint book for this adventure. 94MB Google Drive link: > > https://drive.google.com/file/d/1bmXvHkBLbUeLAid73EJ4H1yQ2uwXQuRu > > Gavin > > P.S. I'm giving a talk on the history of APL\3000 and its resurrection to the > ACM APLBUG group in a couple weeks. If anyone is interested I can provide > more details when I have them. From elson at pico-systems.com Sun Sep 27 18:43:49 2020 From: elson at pico-systems.com (Jon Elson) Date: Sun, 27 Sep 2020 18:43:49 -0500 Subject: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter? In-Reply-To: References: Message-ID: <5F7123B5.2070006@pico-systems.com> On 09/26/2020 02:47 AM, Al Kossow via cctalk wrote: > On 9/25/20 8:22 PM, Grant Taylor via cctalk wrote: > >> If it would work, I wonder if you could then use >> something like Ghost to copy the drive to an image or >> another more standard drive that could then more easily >> be worked with. >> >> >> > > DO NOT ATTEMPT TO USE A PC MFM CONTROLLER WITH DISKS FROM > EARLY BRIDGE BOARDS > > There is a thread on VCF where someone tried to read a > disk from a Viasyn S100 > system with a PC controller and it silently REWROTE the > contents of cyl 0 > > You have been warned > > Cutting the write wire should prevent that! Jon From drb at msu.edu Sun Sep 27 19:22:00 2020 From: drb at msu.edu (Dennis Boone) Date: Sun, 27 Sep 2020 20:22:00 -0400 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: (Your message of Sun, 27 Sep 2020 10:07:50 -0400.) <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> Message-ID: <20200928002200.DE5052856E2@yagi.h-net.msu.edu> > Partially related to that is a program called ?20HAL? which was a > code uploader Microsoft used in the late stages to get code from > Microsoft in Bellevue to IBM in Boca Raton, FL. The TOPS-10 manual says that: (SET) TTY FILL n sets delay characteristics for the line to class `n`. There's a table of the number of filler characters sent after each of a number of different control characters. Class 3 uses the most fillters. The filler characters used are CR after a CR, and DEL after all the others. It could make sense to do this during a file transfer, depending on the assorted endpoints, etc. De From rich.cini at verizon.net Sun Sep 27 19:30:10 2020 From: rich.cini at verizon.net (Richard Cini) Date: Mon, 28 Sep 2020 00:30:10 +0000 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: <20200928002200.DE5052856E2@yagi.h-net.msu.edu> References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> ,<20200928002200.DE5052856E2@yagi.h-net.msu.edu> Message-ID: Excellent! That?s a great piece of info. Not sure why a TOPS-10 command would be embedded in a program like this. The notion of filtering/delay itself makes sense but that command would make sense only if IBM had a DECSYSYEM too, no? http://www.classiccmp.org/cini Long Island S100 User?s Group Get Outlook for iOS ________________________________ From: cctalk on behalf of Dennis Boone via cctalk Sent: Sunday, September 27, 2020 8:22:00 PM To: cctalk at classiccmp.org Subject: Re: SCP/Microsoft 20HAL uploader > Partially related to that is a program called ?20HAL? which was a > code uploader Microsoft used in the late stages to get code from > Microsoft in Bellevue to IBM in Boca Raton, FL. The TOPS-10 manual says that: (SET) TTY FILL n sets delay characteristics for the line to class `n`. There's a table of the number of filler characters sent after each of a number of different control characters. Class 3 uses the most fillters. The filler characters used are CR after a CR, and DEL after all the others. It could make sense to do this during a file transfer, depending on the assorted endpoints, etc. De From rich.cini at verizon.net Sun Sep 27 19:43:34 2020 From: rich.cini at verizon.net (Richard Cini) Date: Sun, 27 Sep 2020 20:43:34 -0400 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> <20200928002200.DE5052856E2@yagi.h-net.msu.edu> Message-ID: <46AE7E69-06F4-41CA-8B83-25404741D896@verizon.net> One more interesting tidbit. On startup, the program sends ETX,ETX,"PJ",0dh to the serial channel. Does this seem DEC-like? I'm wondering if the development machine was connected to a pass-through serial port on a terminal (VT-100??) which sat on the DECSYSTEM-20. ?On 9/27/20, 8:30 PM, "cctalk on behalf of Richard Cini via cctalk" wrote: Excellent! That?s a great piece of info. Not sure why a TOPS-10 command would be embedded in a program like this. The notion of filtering/delay itself makes sense but that command would make sense only if IBM had a DECSYSYEM too, no? http://www.classiccmp.org/cini Long Island S100 User?s Group Get Outlook for iOS ________________________________ From: cctalk on behalf of Dennis Boone via cctalk Sent: Sunday, September 27, 2020 8:22:00 PM To: cctalk at classiccmp.org Subject: Re: SCP/Microsoft 20HAL uploader > Partially related to that is a program called ?20HAL? which was a > code uploader Microsoft used in the late stages to get code from > Microsoft in Bellevue to IBM in Boca Raton, FL. The TOPS-10 manual says that: (SET) TTY FILL n sets delay characteristics for the line to class `n`. There's a table of the number of filler characters sent after each of a number of different control characters. Class 3 uses the most fillters. The filler characters used are CR after a CR, and DEL after all the others. It could make sense to do this during a file transfer, depending on the assorted endpoints, etc. De From drb at msu.edu Sun Sep 27 21:03:23 2020 From: drb at msu.edu (Dennis Boone) Date: Sun, 27 Sep 2020 22:03:23 -0400 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: (Your message of Mon, 28 Sep 2020 00:30:10 -0000.) References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> , <20200928002200.DE5052856E2@yagi.h-net.msu.edu> Message-ID: <20200928020324.476B32857F6@yagi.h-net.msu.edu> > Excellent! That's a great piece of info. Not sure why a TOPS-10 > command would be embedded in a program like this. The notion of > filtering/delay itself makes sense but that command would make sense > only if IBM had a DECSYSYEM too, no? That part's a puzzler. Perhaps the link was from the PC to the MS DEC-10 and thence out to IBM? De From rich.cini at verizon.net Sun Sep 27 21:12:39 2020 From: rich.cini at verizon.net (Richard Cini) Date: Mon, 28 Sep 2020 02:12:39 +0000 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: <20200928020324.476B32857F6@yagi.h-net.msu.edu> References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> , <20200928002200.DE5052856E2@yagi.h-net.msu.edu>, <20200928020324.476B32857F6@yagi.h-net.msu.edu> Message-ID: Great point. Does a VT100 have a pass-through serial port? Maybe the development machine was connected to a pass through serial port on a terminal and then sent command to the DEC-20 to send the files. So there would have been some sort of connection from the DEC-20 to IBM. Leased line? Packet switched? A great puzzle. http://www.classiccmp.org/cini Long Island S100 User?s Group Get Outlook for iOS ________________________________ From: cctalk on behalf of Dennis Boone via cctalk Sent: Sunday, September 27, 2020 10:03:23 PM To: cctalk at classiccmp.org Subject: Re: SCP/Microsoft 20HAL uploader > Excellent! That's a great piece of info. Not sure why a TOPS-10 > command would be embedded in a program like this. The notion of > filtering/delay itself makes sense but that command would make sense > only if IBM had a DECSYSYEM too, no? That part's a puzzler. Perhaps the link was from the PC to the MS DEC-10 and thence out to IBM? De From imp at bsdimp.com Sun Sep 27 22:12:39 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 27 Sep 2020 21:12:39 -0600 Subject: SCP/Microsoft 20HAL uploader In-Reply-To: References: <68941093-D0BB-4AFC-8699-9FAC7AA1926E@gmail.com> <20200928002200.DE5052856E2@yagi.h-net.msu.edu> <20200928020324.476B32857F6@yagi.h-net.msu.edu> Message-ID: On Sun, Sep 27, 2020, 8:12 PM Richard Cini via cctalk wrote: > Great point. Does a VT100 have a pass-through serial port? It's how printers were connected... Warner Maybe the development machine was connected to a pass through serial port > on a terminal and then sent command to the DEC-20 to send the files. So > there would have been some sort of connection from the DEC-20 to IBM. > Leased line? Packet switched? > > A great puzzle. > > > http://www.classiccmp.org/cini > Long Island S100 User?s Group > > Get Outlook for iOS > > ________________________________ > From: cctalk on behalf of Dennis Boone > via cctalk > Sent: Sunday, September 27, 2020 10:03:23 PM > To: cctalk at classiccmp.org > Subject: Re: SCP/Microsoft 20HAL uploader > > > Excellent! That's a great piece of info. Not sure why a TOPS-10 > > command would be embedded in a program like this. The notion of > > filtering/delay itself makes sense but that command would make sense > > only if IBM had a DECSYSYEM too, no? > > That part's a puzzler. Perhaps the link was from the PC to the MS > DEC-10 and thence out to IBM? > > De > From ljw-cctech at ljw.me.uk Mon Sep 28 08:12:50 2020 From: ljw-cctech at ljw.me.uk (Lawrence Wilkinson) Date: Mon, 28 Sep 2020 15:12:50 +0200 Subject: Digitizing video frame for printing In-Reply-To: <81723E42-050A-4AFC-B75D-BBA4EB4348A1@computerhistory.org> References: <81723E42-050A-4AFC-B75D-BBA4EB4348A1@computerhistory.org> Message-ID: <210b560b-18bb-8502-f52f-5c0aeb7f8d34@ljw.me.uk> Sorry I accidentally deleted this message from Dag Spicer, so here it is for cctalk. Reply to him or the list, not me! Lawrence -------- Forwarded Message -------- Subject: Digitizing video frame for printing Date: Mon, 28 Sep 2020 06:00:21 +0000 From: Dag Spicer via cctech Reply-To: Dag Spicer , General Discussion: On-Topic Posts To: cctalk at classiccmp.org Hi there, Trying to help a former operator of a digital portrait scanning booth ?back in the day?? He writes: ++++ IN 1976, I worked at "get your portrait by computer" store. The heart of the system was a 16 bit, Data General, Nova II computer. A black and white, analog, standard definition CCTV camera was tethered to a "digitizer" box that was connected to the computer. The photographer hit the ?Capture? button on the "Digitizer" box to instantaneously freeze the image and "digitize" it. The image was then sent to a Centronics, 102AL, 7 pin, dot matrix printer to print. A perceived grey scale of 26 shades was created by numbers and letters. What I am trying to find out is what the "Digitizer" box was and how it worked. Ram? Tape loop? I DO know that it said 'Digital Image Systems' on the outside but have not been able to learn more. ++++ Can anyone help with more information about DIS or generically about these systems? They were popular in shopping malls for a few years in the mid-70s? Thanks for any tips! Dag ?? Dag Spicer Senior Curator Computer History Museum 1401 N. Shoreline Blvd. Mountain View, CA 94043 dspicer at computerhistory.org From ccth6600 at gmail.com Mon Sep 28 08:43:08 2020 From: ccth6600 at gmail.com (Tom Hunter) Date: Mon, 28 Sep 2020 21:43:08 +0800 Subject: 5.25" analog alignment floppy disk Message-ID: I have two poorly aligned 5.25" floppy drives. They read/write disks formatted by themselves but are marginal on disks formatted by other drives. Rather than using a crude "good enough" alignment I would like to do this properly. Is there still a supplier for 5.25" analog alignment floppy disks? Thanks Tom Hunter From abuse at cabal.org.uk Mon Sep 28 09:25:54 2020 From: abuse at cabal.org.uk (Peter Corlett) Date: Mon, 28 Sep 2020 16:25:54 +0200 Subject: Digitizing video frame for printing In-Reply-To: <210b560b-18bb-8502-f52f-5c0aeb7f8d34@ljw.me.uk> References: <81723E42-050A-4AFC-B75D-BBA4EB4348A1@computerhistory.org> <210b560b-18bb-8502-f52f-5c0aeb7f8d34@ljw.me.uk> Message-ID: <20200928142554.GA30453@mooli.org.uk> On Mon, Sep 28, 2020 at 03:12:50PM +0200, Lawrence Wilkinson via cctalk wrote: > Sorry I accidentally deleted this message from Dag Spicer, so here it is > for cctalk. Reply to him or the list, not me! [I'm not going to attempt to clean-up the top-quoted mess; check your archive if you can't remember what it said.] I don't know anything about the unit described, but we can make an educated guess based on the known facts. A quick search tells me that the printer has 132 columns and can do 330 cps. Assuming square characters, 99 rows are needed to maintain the 4:3 aspect ratio of the video image. 99 is convenient for neither computers nor NTSC, so some nearby round figure is indicated. I'll arbitrarily pick 120, i.e. every other scanline, since this is a reasonable upper bound. Taking 132 samples of a video line requires a sample rate of roughly 2MHz. I'm not sure of the state of the art in 1976 but that feels achievable. 26 greyscale levels only needs a 5-bit ADC, which also sounds doable. 132x120 is 15,840, which is close to 16,384, and given the 4116 was launched in 1975, five of those would be perfect. This has a certain elegance and given the "instantly freeze" claim, my money's on this design. None of the dimensions are convenient powers of two, nor small integer multiples thereof, so the actual page size and greyscale depth would be tweaked to make the digital logic simpler. 128x80 (every third scanline) or 120x96 (every second scanline plus a bit of cropping) feel most likely, and perhaps a depth reduction to 4 bits since who is going to check if it's really 26 levels rather than merely assume so because it's made out of letters? If I'm overestimating the abilities of mid-70s digital electronics, halve the horizonal figures: digitise at 1MHz and print 64 columns (in 80 column mode). It'll still impress the great unwashed. One may as well make it 64 rows as well so it fits in a cheaper 1K DRAM. A tape loop could be sampled a row at a time at the convenience of the digital hardware. It still has to sample with 500ns precision, but not every 500ns. Again, my calculations suggest six samples per line is sufficient to feed the printer at 330cps. However, while this saves on high-speed digital components, it adds a complex and unreliable analogue device which might not take kindly to the hostile environment it's placed in, so I doubt it. Another alternative is the wheeze done with cheap video digitisers on the 8-bit micros: one sample per scanline, slow-scanning horizontally, and the subject is told to sit still for the required duration. The one I saw was PAL and output to a BBC Micro with its 160x256 mode, so it'd need to sample over 160 fields, or 3.2 seconds. That's not exactly "instantly" but might be close enough to fool enough people, especially when compared to a traditional photo booth. From curiousmarc3 at gmail.com Mon Sep 28 16:35:40 2020 From: curiousmarc3 at gmail.com (Curious Marc) Date: Mon, 28 Sep 2020 14:35:40 -0700 Subject: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff. In-Reply-To: References: Message-ID: Bravo! Marc > On Sep 27, 2020, at 2:22 PM, Gavin Scott via cctalk wrote: > > ?As some people here are aware, I have spent probably too much time this summer > hacking on J. David Bryan's excellent Classic HP 3000 simulator and trying to > build up the ultimate classic 1980s HP 3000 system (virtually speaking). > > I started with the MPE V/R KIT that's widely available and expanded that into a > 5x120MB HP 7925 disc system and configured things like the system directory > size and all the system tables to make a fully functional multi-user server. > > I then set about collecting as much old MPE software as I could find, which > included Keven Miller's collection of the old Contributed Software Library tapes > which were conveniently available in SIMH format. This is a huge trove of cool > stuff including most of the classic mini/mainframe games (Dungeon, Warp, > Advent, etc., etc.) and even a little game called DRAGONS that was written in > 1980 by a guy named Bruce Nesmith when he was in college and he used it > to get a job at TSR and went on to write parts of many classic D&D products > and eventually landed at Bethesda where among other things he was the > lead designer for another little game called The Elder Scrolls V: Skyrim. I was > able to track Bruce down and give him a copy of the system with his 40 year > old game running on it. The CSL tapes also include other amazing goodies > that people developed and gave away over the years, including a FORTH and > LISP, as well as most of the system and utility programs that people used to > run their 3000 shops. It's quite fun to explore. > > I was curious how far we could push the 3000 simulator, so I hacked all > the memory bank registers to be six bits instead of four bits, and we > now have a simulated HP 3000 Series III that supports 8MB of memory, 4x > more than any physical system ever did. I started trying to do the same thing > for giant disc drives, but MPE turned out to have too much knowledge of > what the supported disc models look like to make it practical. Bummer. > > Since I met my first HP 3000 in 1980 (40 years ago this month), people would > talk about what was probably the most rare and exotic HP software subsystem > ever produced, APL\3000. APL on the 3000 was a project started at HP Labs > in Palo Alto in the early 1970s. They were likely motivated by the success IBM > was having with mainframe APL timesharing services. This would be the first > full APL implementation on a "small" (non-mainframe) computer. It would be the > first APL with a compiler (and a byte-code virtual machine to execute the > compiled code), it would include an additional new language APLGOL (APL > with ALGOL like structured control statements), and it managed to support > APL workspaces of unlimited size through a clever set of system CPU > microcode extensions that provided a flat 32-bit addressing capability (on > a 16-bit machine where every other language was limited to a 64KB data > segment). > > Because APL required these extra special CPU instructions that you got as > a set of ROM chips when you bought the $15,000 APL\3000, and because > APL ultimately failed as a product (another story in itself) and thus HP never > implemented these instructions on their later HP 3000 models, I never saw > it run on a real HP 3000, but over the years we talked about wouldn't it be > cool to find a way to get APL running again. > > With assistance and moral support from Stan Sieler and Frank McConnell > and others, I was ultimately able to reverse-engineer the behavior of the > undocumented ten magic APL CPU instructions needed to get it to run and > implement them as part of the MPE unimplemented instruction trap and now > APL\3000 runs again for the first time in ~35 years. Somewhat ironically, this > implementation method could have been used back in 1980 as I didn't > actually end up changing the hardware simulation code at all, and it should > also run (if a bit slowly) on any physical classic architecture 3000. > > So that was cool and all, but what is APL without all the weird overstruck > characters and whatnot? APL\3000 supports the use of plain ASCII terminals > through blecherous trigraphs like "QD for the APL quad character, but this > is hardly satisfying. So the quest was on to find a solution. Back in 1976 when > APL\3000 was released, there was a companion HP terminal in the 264x line, > the HP 2641A APL Display Station, which was basically an HP 2645A with > special firmware and APL character set ROMs that supported all the APL > special characters as well as overstrikes (the terminal would take XY > and lookup to see if it had a character to represent Y overstriking X and if > so it would show that on the display, and if that got transmitted to the host it > would convert it back into the original three character overstriking sequence). > > I briefly looked into the idea of hacking QCTerm or Putty or something, but > then I found out from Curious Chris that an HP 2645A emulator already existed > in the MAME emulator system! Since the '41 is basically just a '45 with modified > firmware, and Bitsavers had both the character set ROMs as well as the > firmware ROMs from a '41, this sounded like it might be easy! There was a snag > however in that the firmware ROM images that were allegedly from a '41 turned > out to actually be from an ordinary '45. But we did have the character sets and > one of the ROMs from the second CTL PCA. I put out a call on the Vintage HP > list to see if anyone might possibly have a lead on an actual HP 2641A, and > Kyle Owen responded that not only did he have one he could also dump the > ROMs for us. So a few days and a few hacks to F. Ulivi's MAME hp2645 driver > later we now have a functioning MAME HP 2641A terminal emulation, so you > can experience APL\3000 in all its original glory. I bundled up a somewhat > stripped down MAME along with my turnkey 3000 setup so both emulated HP > terminals are just a couple clicks away. > > So that's how I spent my summer vacation (who am I kidding, it's pretty much all > vacation these days). It has been a lot of fun revisiting all this old > 3000 stuff as > well as the numerous people I talked to along the way including some of those > who were around at APL\3000's birth (before my time). It was rather a lot of > work so I'd like to feel it might be useful to someone in the future > who is digging > into this part of history. Because of all the usual reasons, I don't > plan on hosting > it permanently until and unless we maybe someday get the licensing worked out > (the 50th anniversary of the HP 3000 will be in a couple years so maybe people > will get interested again then) but I will offer it up here to my > fellow computer > history nuts if you want to help ensure that it doesn't vanish if I > get run over by a > bus or something :) > > This is a simulated HP 3000 Series III (circa 1980) running MPE V/R (circa 1986) > with 8MB of memory, all the language subsystems (APL, BASIC, BASICOMP, RPG, > FORTRAN (66), SPL, PASCAL, COBOL (68), COBOL II (74)), 20 years of users group > contributed software, many classic historical computer games, etc. Software > archaeologists can get lost in here for years. Oh, and thanks to Dave > Elward, the > HP 2000 Timesharing BASIC contributed library is even included (kinda sorta > converted to MPE BASIC) for good measure. This is a streamlined turnkey edition > that's ready to run out of the box with no assembly required (all > batteries are included). > Currently, I only provide executables for Windows (sorry) but am in > the process of > getting the 3000 simulator changes (for large memory support) and the new MAME > hp2641 driver back upstream. Instructions and further details can be > found in the > README.txt hint book for this adventure. 94MB Google Drive link: > > https://drive.google.com/file/d/1bmXvHkBLbUeLAid73EJ4H1yQ2uwXQuRu > > Gavin > > P.S. I'm giving a talk on the history of APL\3000 and its resurrection > to the ACM APLBUG > group in a couple weeks. If anyone is interested I can provide more > details when I have > them. From cz at alembic.crystel.com Tue Sep 29 09:10:22 2020 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 29 Sep 2020 10:10:22 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) Message-ID: Question for the group: I have a document set here from DEC that is the "XT Hardware Handbook". It's basically the entire pre-release documentation set for the "XT-100" terminal/computer which became the Professional 325/350. Is there a copy of this on the internet, and what are the thoughts on scanning this? Is there already a better copy of this information out there, this seems to cover the whole internal bus, how the cards work, and so forth... Chris From paulkoning at comcast.net Tue Sep 29 09:15:48 2020 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 29 Sep 2020 10:15:48 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: References: Message-ID: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> I have wanted to see that for my work on the Pro. It would be great to get it scanned and posted, whether the copy lands on Bitsavers or elsewhere. As far as I know it is not currently available. Does it include the programming manual for the 4-line UART option board? I have such a board and since I wrote a driver for it, decades ago, I must at one time have had a programming manual, but I certainly don't have it any longer. The internal bus and the boot ROM details are examples of stuff not covered in the currently available manuals on Bitsavers; those details were not exposed to the outside world for some reason. paul > On Sep 29, 2020, at 10:10 AM, Chris Zach via cctalk wrote: > > Question for the group: I have a document set here from DEC that is the "XT Hardware Handbook". It's basically the entire pre-release documentation set for the "XT-100" terminal/computer which became the Professional 325/350. > > Is there a copy of this on the internet, and what are the thoughts on scanning this? Is there already a better copy of this information out there, this seems to cover the whole internal bus, how the cards work, and so forth... > > Chris From a.carlini at ntlworld.com Tue Sep 29 10:18:41 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Tue, 29 Sep 2020 16:18:41 +0100 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: References: Message-ID: <1cfc7ed0-6557-6c63-f939-ceaed86e24a9@ntlworld.com> On 29/09/2020 15:10, Chris Zach via cctalk wrote: > > Is there a copy of this on the internet, and what are the thoughts on > scanning this? If it helps you decide, multiple DEC "restricted" docs are already on bitsavers (the VAXBI SRM, the VAX SRM, various chips specs). Yours won't be the first "restricted" document on there. Antonio -- Antonio Carlini antonio at acarlini.com From robert.jarratt at ntlworld.com Tue Sep 29 10:31:18 2020 From: robert.jarratt at ntlworld.com (Rob Jarratt) Date: Tue, 29 Sep 2020 16:31:18 +0100 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> Message-ID: <002301d69675$9431ccc0$bc956640$@ntlworld.com> I have broken 350s and would love to get hold of this information too... Regards Rob > -----Original Message----- > From: cctalk On Behalf Of Paul Koning via > cctalk > Sent: 29 September 2020 15:16 > To: Chris Zach ; cctalk at classiccmp.org > Subject: Re: Thoughts on restricted distribution documents (Dec Professional > 350) > > I have wanted to see that for my work on the Pro. It would be great to get it > scanned and posted, whether the copy lands on Bitsavers or elsewhere. As far > as I know it is not currently available. > > Does it include the programming manual for the 4-line UART option board? I > have such a board and since I wrote a driver for it, decades ago, I must at one > time have had a programming manual, but I certainly don't have it any longer. > > The internal bus and the boot ROM details are examples of stuff not covered in > the currently available manuals on Bitsavers; those details were not exposed to > the outside world for some reason. > > paul > > > > On Sep 29, 2020, at 10:10 AM, Chris Zach via cctalk > wrote: > > > > Question for the group: I have a document set here from DEC that is the "XT > Hardware Handbook". It's basically the entire pre-release documentation set > for the "XT-100" terminal/computer which became the Professional 325/350. > > > > Is there a copy of this on the internet, and what are the thoughts on scanning > this? Is there already a better copy of this information out there, this seems to > cover the whole internal bus, how the cards work, and so forth... > > > > Chris From cz at alembic.crystel.com Tue Sep 29 12:56:37 2020 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 29 Sep 2020 13:56:37 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <002301d69675$9431ccc0$bc956640$@ntlworld.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> Message-ID: Ok, got a good starter scan. Did it at 600dpi, black/white, saving here as Tiff and JPG formats in different directories. Will make a cheap-o PDF version and put it on iguana.crystel.com in a bit. I also have the 4 volume set of Professional Toolkit and a 4 volume set of Ultrix/11 manuals. Have these already been uploaded somewhere? C On 9/29/2020 11:31 AM, Rob Jarratt wrote: > I have broken 350s and would love to get hold of this information too... > > Regards > > Rob > >> -----Original Message----- >> From: cctalk On Behalf Of Paul Koning via >> cctalk >> Sent: 29 September 2020 15:16 >> To: Chris Zach ; cctalk at classiccmp.org >> Subject: Re: Thoughts on restricted distribution documents (Dec > Professional >> 350) >> >> I have wanted to see that for my work on the Pro. It would be great to > get it >> scanned and posted, whether the copy lands on Bitsavers or elsewhere. As > far >> as I know it is not currently available. >> >> Does it include the programming manual for the 4-line UART option board? > I >> have such a board and since I wrote a driver for it, decades ago, I must > at one >> time have had a programming manual, but I certainly don't have it any > longer. >> >> The internal bus and the boot ROM details are examples of stuff not > covered in >> the currently available manuals on Bitsavers; those details were not > exposed to >> the outside world for some reason. >> >> paul >> >> >>> On Sep 29, 2020, at 10:10 AM, Chris Zach via cctalk > >> wrote: >>> >>> Question for the group: I have a document set here from DEC that is the > "XT >> Hardware Handbook". It's basically the entire pre-release documentation > set >> for the "XT-100" terminal/computer which became the Professional 325/350. >>> >>> Is there a copy of this on the internet, and what are the thoughts on > scanning >> this? Is there already a better copy of this information out there, this > seems to >> cover the whole internal bus, how the cards work, and so forth... >>> >>> Chris > From cz at alembic.crystel.com Tue Sep 29 13:29:50 2020 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 29 Sep 2020 14:29:50 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <002301d69675$9431ccc0$bc956640$@ntlworld.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> Message-ID: <15003915-4cff-ebe0-c441-50ade86feede@alembic.crystel.com> Ok, it's scanned and a compressed PDF is up at: http://iguana.crystel.com/pro350/xt100.pdf Some of the pages are slightly skewed, I'll see about correcting those before putting the whole .tiff set up there (that's over 14gb). Not much difference between 300dpi (the first 20 pages) and 600dpi (the rest) so I might just scan at 300dpi going forward. CZ On 9/29/2020 11:31 AM, Rob Jarratt wrote: > I have broken 350s and would love to get hold of this information too... > > Regards > > Rob > >> -----Original Message----- >> From: cctalk On Behalf Of Paul Koning via >> cctalk >> Sent: 29 September 2020 15:16 >> To: Chris Zach ; cctalk at classiccmp.org >> Subject: Re: Thoughts on restricted distribution documents (Dec > Professional >> 350) >> >> I have wanted to see that for my work on the Pro. It would be great to > get it >> scanned and posted, whether the copy lands on Bitsavers or elsewhere. As > far >> as I know it is not currently available. >> >> Does it include the programming manual for the 4-line UART option board? > I >> have such a board and since I wrote a driver for it, decades ago, I must > at one >> time have had a programming manual, but I certainly don't have it any > longer. >> >> The internal bus and the boot ROM details are examples of stuff not > covered in >> the currently available manuals on Bitsavers; those details were not > exposed to >> the outside world for some reason. >> >> paul >> >> >>> On Sep 29, 2020, at 10:10 AM, Chris Zach via cctalk > >> wrote: >>> >>> Question for the group: I have a document set here from DEC that is the > "XT >> Hardware Handbook". It's basically the entire pre-release documentation > set >> for the "XT-100" terminal/computer which became the Professional 325/350. >>> >>> Is there a copy of this on the internet, and what are the thoughts on > scanning >> this? Is there already a better copy of this information out there, this > seems to >> cover the whole internal bus, how the cards work, and so forth... >>> >>> Chris > From a.carlini at ntlworld.com Tue Sep 29 14:06:37 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Tue, 29 Sep 2020 20:06:37 +0100 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> Message-ID: <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> On 29/09/2020 18:56, Chris Zach via cctalk wrote: > Ok, got a good starter scan. Did it at 600dpi, black/white, saving > here as Tiff and JPG formats in different directories. Will make a > cheap-o PDF version and put it on iguana.crystel.com in a bit. You don't want JPG for text. It'll have fuzzy edges, which isn't (afaict) good for future OCR. > > I also have the 4 volume set of Professional Toolkit and a 4 volume > set of Ultrix/11 manuals. Have these already been uploaded somewhere? > > If you check titles or part #s on https://manx-docs.org/ you should whether something has definitely been scanned (if there's a working Online link). It's always possible that there's a copy somewhere that no-one has told manx about, but that doesn't often happen in my experience. Antonio -- Antonio Carlini antonio at acarlini.com From a.carlini at ntlworld.com Tue Sep 29 14:09:39 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Tue, 29 Sep 2020 20:09:39 +0100 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <15003915-4cff-ebe0-c441-50ade86feede@alembic.crystel.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <15003915-4cff-ebe0-c441-50ade86feede@alembic.crystel.com> Message-ID: <0292acd8-86c3-7212-0eb9-e191a6789923@ntlworld.com> On 29/09/2020 19:29, Chris Zach via cctalk wrote: > > Some of the pages are slightly skewed, I'll see about correcting those > before putting the whole .tiff set up there (that's over 14gb). Not > much difference between 300dpi (the first 20 pages) and 600dpi (the > rest) so I might just scan at 300dpi going forward. > I think bitsavers sets a minimum of 400 dpi to allow for certain post-processing work, so I'd suggest sticking with 600 dpi. Unless of course, you really meant 14GiB (and not 14MiB) in which case it must be quite a document :-) Antonio -- Antonio Carlini antonio at acarlini.com From paulkoning at comcast.net Tue Sep 29 14:13:12 2020 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 29 Sep 2020 15:13:12 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> Message-ID: <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> > On Sep 29, 2020, at 3:06 PM, Antonio Carlini via cctalk wrote: > > On 29/09/2020 18:56, Chris Zach via cctalk wrote: >> Ok, got a good starter scan. Did it at 600dpi, black/white, saving here as Tiff and JPG formats in different directories. Will make a cheap-o PDF version and put it on iguana.crystel.com in a bit. > > > You don't want JPG for text. It'll have fuzzy edges, which isn't (afaict) good for future OCR. Right. JPEG is, as the name indicates, ONLY for photos. Not line art, not text, not anything with edges. TIFF is always good. PNG is also generally a good choice. paul From cz at alembic.crystel.com Tue Sep 29 15:29:27 2020 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 29 Sep 2020 16:29:27 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> Message-ID: <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> Makes sense. Still it's uncompressed so pretty big. I'll need to work on cleaning up the scans a bit, then I'll put the Tiffs up for download/whatever. Just don't want a lot of copies, consider that pdf as a proof of concept to review. C > Right. JPEG is, as the name indicates, ONLY for photos. Not line art, not text, not anything with edges. TIFF is always good. PNG is also generally a good choice. > > paul > > From paulkoning at comcast.net Tue Sep 29 15:48:02 2020 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 29 Sep 2020 16:48:02 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> Message-ID: <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> > On Sep 29, 2020, at 4:29 PM, Chris Zach via cctalk wrote: > > Makes sense. Still it's uncompressed so pretty big. I'll need to work on cleaning up the scans a bit, then I'll put the Tiffs up for download/whatever. Just don't want a lot of copies, consider that pdf as a proof of concept to review. TIFF supports compression, in a number of different schemes. LZW tends to work well for gray and RGB; the CCITT schemes are for bitonal (black/white bitmap). All TIFF compressions are lossless so they are all safe for material of all types. Is what you posted the whole document you have, or are there others? I was really hoping for the "CT bus manual". I did see interesting stuff in this one, though; for example, the first documentation I've seen of the hard drive FORMAT command. paul From bdweb at mindspring.com Tue Sep 29 16:34:44 2020 From: bdweb at mindspring.com (Bjoren Davis) Date: Tue, 29 Sep 2020 17:34:44 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> Message-ID: <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> If it helps, I bought a copy of the DEC Professional 350 Field Maintenance Print Set (MP-01394) on eBay a few months back. I've scanned it but I've been waffling about where to post it. Scanned @600DPI with lossless compression it's huge: 1 GB.? Saved as an "optimized" PDF (with very little visible difference) it's 94 MB. In the short term I've temporarily thrown up the optimized copy onto Google drive: https://drive.google.com/file/d/1BHpaneWpvWTO4UXUhLRgNV09rIiWTf3P/view I'd love to be able to contribute this to something like bitsavers. Thanks. --Bjoren Davis On 9/29/2020 4:48 PM, Paul Koning via cctalk wrote: > >> On Sep 29, 2020, at 4:29 PM, Chris Zach via cctalk wrote: >> >> Makes sense. Still it's uncompressed so pretty big. I'll need to work on cleaning up the scans a bit, then I'll put the Tiffs up for download/whatever. Just don't want a lot of copies, consider that pdf as a proof of concept to review. > TIFF supports compression, in a number of different schemes. LZW tends to work well for gray and RGB; the CCITT schemes are for bitonal (black/white bitmap). All TIFF compressions are lossless so they are all safe for material of all types. > > Is what you posted the whole document you have, or are there others? I was really hoping for the "CT bus manual". I did see interesting stuff in this one, though; for example, the first documentation I've seen of the hard drive FORMAT command. > > paul > > From cz at alembic.crystel.com Tue Sep 29 16:39:15 2020 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 29 Sep 2020 17:39:15 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> Message-ID: That's neat! Thanks! I always liked the Pro/350: When you get into the OS command prompt it's a really nice system and Synergy wasn't a bad windowing system either. I used it a lot in the day and it worked pretty well with a mouse. Also venix wasn't bad, for awhile my Venix equipped 350 was on the internet via uucico. Those were the days... C On 9/29/2020 5:34 PM, Bjoren Davis via cctalk wrote: > If it helps, I bought a copy of the DEC Professional 350 Field > Maintenance Print Set (MP-01394) on eBay a few months back. > > I've scanned it but I've been waffling about where to post it. Scanned > @600DPI with lossless compression it's huge: 1 GB.? Saved as an > "optimized" PDF (with very little visible difference) it's 94 MB. > > In the short term I've temporarily thrown up the optimized copy onto > Google drive: > https://drive.google.com/file/d/1BHpaneWpvWTO4UXUhLRgNV09rIiWTf3P/view > > I'd love to be able to contribute this to something like bitsavers. > > Thanks. > > --Bjoren Davis > > On 9/29/2020 4:48 PM, Paul Koning via cctalk wrote: >> >>> On Sep 29, 2020, at 4:29 PM, Chris Zach via cctalk >>> wrote: >>> >>> Makes sense. Still it's uncompressed so pretty big. I'll need to work >>> on cleaning up the scans a bit, then I'll put the Tiffs up for >>> download/whatever. Just don't want a lot of copies, consider that pdf >>> as a proof of concept to review. >> TIFF supports compression, in a number of different schemes.? LZW >> tends to work well for gray and RGB; the CCITT schemes are for bitonal >> (black/white bitmap).? All TIFF compressions are lossless so they are >> all safe for material of all types. >> >> Is what you posted the whole document you have, or are there others? >> I was really hoping for the "CT bus manual".? I did see interesting >> stuff in this one, though; for example, the first documentation I've >> seen of the hard drive FORMAT command. >> >> ????paul >> >> From aek at bitsavers.org Tue Sep 29 16:57:11 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 29 Sep 2020 14:57:11 -0700 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> Message-ID: <77283737-7eaa-5091-9590-df6601e17bd0@bitsavers.org> On 9/29/20 2:34 PM, Bjoren Davis via cctalk wrote: > I'd love to be able to contribute this to something like bitsavers. i'll upload it today. 100mb is beleivable for a compressed color/grayscale 600dpi scan From cz at alembic.crystel.com Tue Sep 29 17:25:03 2020 From: cz at alembic.crystel.com (Chris Zach) Date: Tue, 29 Sep 2020 18:25:03 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <77283737-7eaa-5091-9590-df6601e17bd0@bitsavers.org> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> <77283737-7eaa-5091-9590-df6601e17bd0@bitsavers.org> Message-ID: <031d231f-b1b1-ca0a-b340-716c88494ea0@alembic.crystel.com> Al: Would you want the uncompressed Tiffs? I'd like to make mine OCRed and searchable if there is software to do so, but 140 pages comes out to 14 gigabytes uncompressed. On 9/29/2020 5:57 PM, Al Kossow via cctalk wrote: > On 9/29/20 2:34 PM, Bjoren Davis via cctalk wrote: > >> I'd love to be able to contribute this to something like bitsavers. > > i'll upload it today. 100mb is beleivable for a compressed > color/grayscale 600dpi scan From spectre at floodgap.com Tue Sep 29 17:35:27 2020 From: spectre at floodgap.com (Cameron Kaiser) Date: Tue, 29 Sep 2020 15:35:27 -0700 (PDT) Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: from Chris Zach via cctalk at "Sep 29, 20 05:39:15 pm" Message-ID: <202009292235.08TMZRL934078740@floodgap.com> > That's neat! Thanks! I always liked the Pro/350: When you get into the > OS command prompt it's a really nice system and Synergy wasn't a bad > windowing system either. I used it a lot in the day and it worked pretty > well with a mouse. > > Also venix wasn't bad, for awhile my Venix equipped 350 was on the > internet via uucico. Those were the days... I rather like Venix (I have it on a PRO/380). Too bad there's no SLIP capability. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- FORTUNE: You will be hit with a lot of money. Avoid armoured trucks. ------- From aek at bitsavers.org Tue Sep 29 17:45:32 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 29 Sep 2020 15:45:32 -0700 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <031d231f-b1b1-ca0a-b340-716c88494ea0@alembic.crystel.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> <77283737-7eaa-5091-9590-df6601e17bd0@bitsavers.org> <031d231f-b1b1-ca0a-b340-716c88494ea0@alembic.crystel.com> Message-ID: <1f8fb825-613a-76b2-2135-842d1605e551@bitsavers.org> On 9/29/20 3:25 PM, Chris Zach via cctalk wrote: > Al: > > Would you want the uncompressed Tiffs? I'd like to make mine OCRed and searchable if there is software to do so, but 140 pages comes out to > 14 gigabytes uncompressed. let me see what happens if I OCR the 90mb file From aek at bitsavers.org Tue Sep 29 18:34:22 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 29 Sep 2020 16:34:22 -0700 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <1f8fb825-613a-76b2-2135-842d1605e551@bitsavers.org> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> <77283737-7eaa-5091-9590-df6601e17bd0@bitsavers.org> <031d231f-b1b1-ca0a-b340-716c88494ea0@alembic.crystel.com> <1f8fb825-613a-76b2-2135-842d1605e551@bitsavers.org> Message-ID: On 9/29/20 3:45 PM, Al Kossow via cctalk wrote: > On 9/29/20 3:25 PM, Chris Zach via cctalk wrote: >> Al: >> >> Would you want the uncompressed Tiffs? I'd like to make mine OCRed and searchable if there is software to do so, but 140 pages comes out >> to 14 gigabytes uncompressed. > > let me see what happens if I OCR the 90mb file > it's under 60mb, so I uploaded it From paulkoning at comcast.net Tue Sep 29 19:11:19 2020 From: paulkoning at comcast.net (Paul Koning) Date: Tue, 29 Sep 2020 20:11:19 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <031d231f-b1b1-ca0a-b340-716c88494ea0@alembic.crystel.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> <77283737-7eaa-5091-9590-df6601e17bd0@bitsavers.org> <031d231f-b1b1-ca0a-b340-716c88494ea0@alembic.crystel.com> Message-ID: <9923B1D7-F8C1-4663-B26C-2B435C0E359C@comcast.net> > On Sep 29, 2020, at 6:25 PM, Chris Zach via cctalk wrote: > > Al: > > Would you want the uncompressed Tiffs? TIFF compression is lossless. Leaving them uncompressed might save a small amount of processing time on opening, at the expense of much more time taken transmitting and reading them. I can't see a reason ever to use the uncompressed TIFF option. paul From aek at bitsavers.org Tue Sep 29 21:07:24 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 29 Sep 2020 19:07:24 -0700 Subject: Manuals for Imprimis/Seagate 5" Elite SMD/IPI drives Message-ID: <0f487517-2a5e-e54a-546b-bcd5f666498c@bitsavers.org> one of the white whales. anyone have OEM documentation for their 5" Elite SMD or IPI drives? The only thing I've ever been able to find was an installation manual for the SMD verison From p.gebhardt at ymail.com Wed Sep 30 01:03:43 2020 From: p.gebhardt at ymail.com (P Gebhardt) Date: Wed, 30 Sep 2020 06:03:43 +0000 (UTC) Subject: Manuals for Imprimis/Seagate 5" Elite SMD/IPI drives In-Reply-To: <0f487517-2a5e-e54a-546b-bcd5f666498c@bitsavers.org> References: <0f487517-2a5e-e54a-546b-bcd5f666498c@bitsavers.org> Message-ID: <1021672831.35236.1601445823678@mail.yahoo.com> > >one of the white whales. >anyone have OEM documentation for their 5" Elite SMD or IPI drives? > >The only thing I've ever been able to find was an installation manual for the SMD verison I'd be *very*? interested to see docs on bitsavers, too. There are four IPI-2? drives (5-inch) in a SUN enclosure and I never came across any documents for them. Cheers, Pierre ----------------------------------------------------------------------------- http://www.digitalheritage.de From derschjo at gmail.com Wed Sep 30 01:25:52 2020 From: derschjo at gmail.com (Josh Dersch) Date: Tue, 29 Sep 2020 23:25:52 -0700 Subject: ISO: Motorola MDP-1000 info/software Message-ID: Hi all -- This is a long shot, but I was curious if anyone might have information on the Motorola MDP-1000 minicomputer. I picked one up recently and I'm working on restoring it. Of particular interest is the power supply, which is external to the processor and which I am missing. I think I have the voltages worked out (+/-5V and +/-15V), but there are a number of other signals on the power supply connector that I'm unsure of at the moment. I've put a few pictures up here: https://1drv.ms/u/s!Aqb36sqnCIfMpIVYmzKjFnsT3nHh8w?e=b2iqqv I'll note that this isn't technically an MDP-1000 -- it's labeled as an MDP-6650 on the rear. I suspect that this is a ruggedized version of the 1000 intended for harsher environments. The front panel of mine appears to be identical to the drawings of the MDP-1000 in the manuals I have. It also came with a binder of documentation (but alas no schematics) that I'll be scanning soon and getting off to Al. It's an odd little system -- 5 12-bit registers, a 12-bit ALU, and a 12-bit Instruction Register, but the memory is 8 bits wide. Instructions are packed into two bytes normally, but there's a special 64-byte region of memory that can be used to store "shared bytes," which allow encoding certain instructions into a single byte, taking the other byte from the shared region. I've never seen anything quite like this. I wonder why they didn't just use 12-bit wide memory... Also the process for using the front panel to examine and deposit memory is insane. Here's the instructions for reading a memory location; it's 10 steps. Depositing is 17. https://1drv.ms/u/s!Aqb36sqnCIfMpIVWThgwlxgCMQo59A If anyone has anything on this, let me know. Not expecting much, but it's worth a shot. - Josh From mattislind at gmail.com Wed Sep 30 01:55:54 2020 From: mattislind at gmail.com (Mattis Lind) Date: Wed, 30 Sep 2020 08:55:54 +0200 Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: References: Message-ID: Den ons 30 sep. 2020 kl 08:26 skrev Josh Dersch via cctalk < cctalk at classiccmp.org>: > Hi all -- > > This is a long shot, but I was curious if anyone might have information on > the Motorola MDP-1000 minicomputer. I picked one up recently and I'm > working on restoring it. Of particular interest is the power supply, which > is external to the processor and which I am missing. I think I have the > voltages worked out (+/-5V and +/-15V), but there are a number of other > signals on the power supply connector that I'm unsure of at the moment. > > I've put a few pictures up here: > > https://1drv.ms/u/s!Aqb36sqnCIfMpIVYmzKjFnsT3nHh8w?e=b2iqqv Interesting machine. I see many standard Texas Instruments TTL parts in there, for example SN7475, SN7483, SN7401. But there are also chips marked SN4813, SN4814, SN4820. Never seen TI chips marked 48xx before. Also a few chips marked SN6392. Out of curiosity I tried to look them up in the old databooks at bitsavers, but didn't find them. What kind of lCs are these? /Mattis > > From aek at bitsavers.org Wed Sep 30 03:49:16 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 30 Sep 2020 01:49:16 -0700 Subject: Manuals for Imprimis/Seagate 5" Elite SMD/IPI drives In-Reply-To: <1021672831.35236.1601445823678@mail.yahoo.com> References: <0f487517-2a5e-e54a-546b-bcd5f666498c@bitsavers.org> <1021672831.35236.1601445823678@mail.yahoo.com> Message-ID: <6b34ad11-3716-7f6d-f347-43cc5239698b@bitsavers.org> On 9/29/20 11:03 PM, P Gebhardt wrote: > I'd be *very*? interested to see docs on bitsavers, too. There are four IPI-2? drives (5-inch) in a SUN enclosure and I never came across any documents for them. > Cheers, > Pierre > > ----------------------------------------------------------------------------- > http://www.digitalheritage.de > I see they lowered the price on the 5-600, and it used IPI drives https://www.ebay.com/itm/264733056848 Wonder if Cameron needs another Solbourne From couryhouse at aol.com Wed Sep 30 05:12:57 2020 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 30 Sep 2020 10:12:57 +0000 (UTC) Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: References: Message-ID: <429086877.225793.1601460777029@mail.yahoo.com> Josh I posted? ?photo? of? a manual? we? had? ?a long? time? but? not? too long if? you? want? to search? the? ?cctalk? here..?Also? always? wondered? which? plant built in...?is? this? same? ?basically as? a? pbp 8? or? ?is? it? just that? they are both? 12 bits???Thanks? Ed#?In a message dated 9/29/2020 11:26:36 PM US Mountain Standard Time, cctalk at classiccmp.org writes:? Hi all --?This is a long shot, but I was curious if anyone might have information onthe Motorola MDP-1000 minicomputer.? I picked one up recently and I'mworking on restoring it.? Of particular interest is the power supply, whichis external to the processor and which I am missing.? I think I have thevoltages worked out (+/-5V and +/-15V), but there are a number of othersignals on the power supply connector that I'm unsure of at the moment.?I've put a few pictures up here:?https://1drv.ms/u/s!Aqb36sqnCIfMpIVYmzKjFnsT3nHh8w?e=b2iqqv?I'll note that this isn't technically an MDP-1000 -- it's labeled as anMDP-6650 on the rear.? I suspect that this is a ruggedized version of the1000 intended for harsher environments.? The front panel of mine appears tobe identical to the drawings of the MDP-1000 in the manuals I have.?It also came with a binder of documentation (but alas no schematics) thatI'll be scanning soon and getting off to Al.? It's an odd little system --5 12-bit registers, a 12-bit ALU, and a 12-bit Instruction Register, butthe memory is 8 bits wide.? Instructions are packed into two bytesnormally, but there's a special 64-byte region of memory that can be usedto store "shared bytes," which allow encoding certain instructions into asingle byte, taking the other byte from the shared region.? I've never seenanything quite like this.? I wonder why they didn't just use 12-bit widememory...?Also the process for using the front panel to examine and deposit memory isinsane.? Here's the instructions for reading a memory location; it's 10steps.? Depositing is 17.?https://1drv.ms/u/s!Aqb36sqnCIfMpIVWThgwlxgCMQo59A?If anyone has anything on this, let me know.? Not expecting much, but it'sworth a shot.- Josh From aek at bitsavers.org Wed Sep 30 06:07:13 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 30 Sep 2020 04:07:13 -0700 Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: <429086877.225793.1601460777029@mail.yahoo.com> References: <429086877.225793.1601460777029@mail.yahoo.com> Message-ID: On 9/30/20 3:12 AM, ED SHARPE via cctalk wrote: > Josh I posted? ?photo? of? a manual? we? had? ?a long? time? but? not? too long if? you? want? to search? the? ?cctalk? here.. If you did, it was eaten, since cctlk doesn't allow attachements From aek at bitsavers.org Wed Sep 30 06:08:34 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 30 Sep 2020 04:08:34 -0700 Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: References: <429086877.225793.1601460777029@mail.yahoo.com> Message-ID: <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> On 9/30/20 4:07 AM, Al Kossow via cctalk wrote: > On 9/30/20 3:12 AM, ED SHARPE via cctalk wrote: >> Josh I posted? ?photo? of? a manual? we? had? ?a long? time? but? not? too long if? you? want? to search? the? ?cctalk? here.. > > If you did, it was eaten, since cctlk doesn't allow attachements > CHM has some documentation in the collection. I haven't looked to see what it is https://www.computerhistory.org/collections/search/?s=mdp-1000 From couryhouse at aol.com Wed Sep 30 06:51:03 2020 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 30 Sep 2020 11:51:03 +0000 (UTC) Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> Message-ID: <185585842.245379.1601466663445@mail.yahoo.com> i may have? posted? ?a link? yes? i k ow? cctalk is? lacking in image handling.? maybe? some? day? that? will? change.?it was? ?years? back. it? may be? something josh has already... but? maybe not. neat? he? found? the? hardware!??In a message dated 9/30/2020 4:08:43 AM US Mountain Standard Time, cctalk at classiccmp.org writes:? On 9/30/20 4:07 AM, Al Kossow via cctalk wrote: > On 9/30/20 3:12 AM, ED SHARPE via cctalk wrote: >> Josh I posted? ?photo? of? a manual? we? had? ?a long? time? but? not? too long if? you? want? to search? the? ?cctalk? here.. > > If you did, it was eaten, since cctlk doesn't allow attachements > CHM has some documentation in the collection. I haven't looked to see what it is https://www.computerhistory.org/collections/search/?s=mdp-1000 From couryhouse at aol.com Wed Sep 30 07:20:15 2020 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 30 Sep 2020 12:20:15 +0000 (UTC) Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> Message-ID: <645318535.242089.1601468415536@mail.yahoo.com> whats? the? story on? this...i? see? items? ?but no pix.?also? ?check? your? spelling on Motorola; Instrmentation and Control, Inc. ?that? is? in? the? index.?let me? now? if? there? is a photo? group? for this at? least with the? covers???I always? wondered if it? was? just? a? 12 bit? computer or? if it? was? ?software? compatible? with pdp-8??I wonder? what? else? this? division of Motorola produced....? ?there? was a? teleprinter? ?they made...???Here is? the link? to the? teleprinter? it? is? filed under gov? div.?http://www.smecc.org/motolola_government.htmi? think i got the? 12 bit? computer manual? from same person.?Ed?In a message dated 9/30/2020 4:08:43 AM US Mountain Standard Time, cctalk at classiccmp.org writes:? On 9/30/20 4:07 AM, Al Kossow via cctalk wrote: > On 9/30/20 3:12 AM, ED SHARPE via cctalk wrote: >> Josh I posted? ?photo? of? a manual? we? had? ?a long? time? but? not? too long if? you? want? to search? the? ?cctalk? here.. > > If you did, it was eaten, since cctlk doesn't allow attachements > CHM has some documentation in the collection. I haven't looked to see what it is https://www.computerhistory.org/collections/search/?s=mdp-1000 From billdegnan at gmail.com Wed Sep 30 08:41:35 2020 From: billdegnan at gmail.com (Bill Degnan) Date: Wed, 30 Sep 2020 09:41:35 -0400 Subject: Shipping via USPS Los Angeles is STALLED Message-ID: I have a vintage computer sitting in the LA USPS since 9/17, with no further updates. I have read in the local papers there that the entire post office has ground to a halt. What's going on there? I have never heard of anything like this. I assume my package will survive but think of the zoo there if they've been stacking packages for TWO WEEKS. I'd strongly suggest not attempting to ship anything out of LA for the time being. WOW. I know people complain about the post office, I am not complaining, just stating the facts. Normally the USPS is reliable. They must really have overall problems in southern CA due to the fire and related management issues. BIll From toby at telegraphics.com.au Wed Sep 30 09:39:47 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 30 Sep 2020 10:39:47 -0400 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: References: Message-ID: <7642ca00-4129-05d5-dc45-325de99a6003@telegraphics.com.au> On 2020-09-30 9:41 a.m., Bill Degnan via cctalk wrote: > I have a vintage computer sitting in the LA USPS since 9/17, with no > further updates. I have read in the local papers there that the entire > post office has ground to a halt. What's going on there? I have never > heard of anything like this. I assume my package will survive but think of > the zoo there if they've been stacking packages for TWO WEEKS. I'd > strongly suggest not attempting to ship anything out of LA for the time > being. WOW. > > I know people complain about the post office, I am not complaining, just > stating the facts. Normally the USPS is reliable. They must really have > overall problems in southern CA due to the fire and related management > issues. > > BIll > It's under new management, I heard. From emu at e-bbes.com Wed Sep 30 09:42:43 2020 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 30 Sep 2020 10:42:43 -0400 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> Message-ID: On 2020-09-29 17:34, Bjoren Davis via cctalk wrote: > If it helps, I bought a copy of the DEC Professional 350 Field > Maintenance Print Set (MP-01394) on eBay a few months back. EXCELLENT! > > I've scanned it but I've been waffling about where to post it. Scanned > @600DPI with lossless compression it's huge: 1 GB.? Saved as an > "optimized" PDF (with very little visible difference) it's 94 MB. > > In the short term I've temporarily thrown up the optimized copy onto > Google drive: > https://drive.google.com/file/d/1BHpaneWpvWTO4UXUhLRgNV09rIiWTf3P/view > > I'd love to be able to contribute this to something like bitsavers. Personally, I prefer file names to start with the DEC designator, like MP....... But I'm happy already to see this ;-) From edcross at gmail.com Wed Sep 30 09:52:01 2020 From: edcross at gmail.com (Ed C.) Date: Wed, 30 Sep 2020 16:52:01 +0200 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: References: Message-ID: I was in a similar situation for 2 months with a couple of packages, April-June, in the end I received everything ok. On Wed, Sep 30, 2020 at 3:41 PM Bill Degnan via cctalk < cctalk at classiccmp.org> wrote: > I have a vintage computer sitting in the LA USPS since 9/17, with no > further updates. I have read in the local papers there that the entire > post office has ground to a halt. What's going on there? I have never > heard of anything like this. I assume my package will survive but think of > the zoo there if they've been stacking packages for TWO WEEKS. I'd > strongly suggest not attempting to ship anything out of LA for the time > being. WOW. > > I know people complain about the post office, I am not complaining, just > stating the facts. Normally the USPS is reliable. They must really have > overall problems in southern CA due to the fire and related management > issues. > > BIll > From cctalk at ibm51xx.net Wed Sep 30 10:05:02 2020 From: cctalk at ibm51xx.net (Ali) Date: Wed, 30 Sep 2020 08:05:02 -0700 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: Message-ID: <1N4yRU-1kVIc136ai-010q6c@mrelay.perfora.net> Hi Bill, I haven't seen any issues with USPS in LA. It is actually been super smooth. For example I shipped out a package last week media mail. It was slated to arrive in Illinois tomorrow. Arrived yesterday, a whole two days early. Most of the stuff I have been getting from eBay has been arriving early as well. Only issue seems to be China and to smaller extent all international mail.?-Ali -------- Original message --------From: Bill Degnan via cctalk Date: 9/30/20 6:41 AM (GMT-08:00) To: "General Discussion: On-Topic and Off-Topic Posts" Subject: Shipping via USPS Los Angeles is STALLED I have a vintage computer sitting in the LA USPS since 9/17, with nofurther updates.? I have read in the local papers there that the entirepost office has ground to a halt.? What's going on there?? I have neverheard of anything like this.? I assume my package will survive but think ofthe zoo there if they've been stacking packages for TWO WEEKS.? I'dstrongly suggest not attempting to ship anything out of LA for the timebeing.? WOW.I know people complain about the post office, I am not complaining, juststating the facts.? Normally the USPS is reliable.? They must really haveoverall problems in southern CA due to the fire and related managementissues.BIll From paulkoning at comcast.net Wed Sep 30 10:23:08 2020 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 30 Sep 2020 11:23:08 -0400 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: References: Message-ID: <180D87D2-F363-46C1-927F-F8C4BA845B0B@comcast.net> > On Sep 30, 2020, at 9:41 AM, Bill Degnan via cctalk wrote: > > I have a vintage computer sitting in the LA USPS since 9/17, with no > further updates. I have read in the local papers there that the entire > post office has ground to a halt. That sounds like creative writing. paul From jwest at classiccmp.org Wed Sep 30 10:40:23 2020 From: jwest at classiccmp.org (jwest at classiccmp.org) Date: Wed, 30 Sep 2020 11:40:23 -0400 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: References: Message-ID: <000901d69740$02ac5d80$08051880$@classiccmp.org> Bill D wrote: ---------- I have a vintage computer sitting in the LA USPS since 9/17, with no further updates. ---------- Just a few weeks ago I ordered a vintage fuel pump for an heirloom garden tractor restoration I'm doing. It came from ohio via ebay, and I had a couple phone conversations with the guy. He sells a pretty fair amount in his ebay store, and he said the postal facility that serves his region is supposed to have 200 people on staff and they are currently down to 50 - completely due to covid. He said it was hit or miss, some packages sailed right through but others sat for 2-4 weeks and then moved again. Mine sailed right through... J From cclist at sydex.com Wed Sep 30 11:10:23 2020 From: cclist at sydex.com (Chuck Guzis) Date: Wed, 30 Sep 2020 09:10:23 -0700 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: <000901d69740$02ac5d80$08051880$@classiccmp.org> References: <000901d69740$02ac5d80$08051880$@classiccmp.org> Message-ID: <00f96e3a-b483-0f10-4b84-fdae14b6cba0@sydex.com> It seems to depend on which postal hub an item is shipped through. A few days ago, I received an item that was shipped USPS 3-day priority that spent 10 days in Las Vegas (point of origin). All in all, it took about 2 weeks to reach me here in Oregon. The USPS didn't say if the package was comped dinner or drinks for the layover in LV. --Chuck From billdegnan at gmail.com Wed Sep 30 11:41:16 2020 From: billdegnan at gmail.com (Bill Degnan) Date: Wed, 30 Sep 2020 12:41:16 -0400 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: <00f96e3a-b483-0f10-4b84-fdae14b6cba0@sydex.com> References: <000901d69740$02ac5d80$08051880$@classiccmp.org> <00f96e3a-b483-0f10-4b84-fdae14b6cba0@sydex.com> Message-ID: Seems like the western US is a lot worse off than anywhere else in the US except maybe NYC. On Wed, Sep 30, 2020 at 12:10 PM Chuck Guzis via cctalk < cctalk at classiccmp.org> wrote: > It seems to depend on which postal hub an item is shipped through. > > A few days ago, I received an item that was shipped USPS 3-day priority > that spent 10 days in Las Vegas (point of origin). All in all, it took > about 2 weeks to reach me here in Oregon. > > The USPS didn't say if the package was comped dinner or drinks for the > layover in LV. > > --Chuck > From cisin at xenosoft.com Wed Sep 30 12:00:34 2020 From: cisin at xenosoft.com (Fred Cisin) Date: Wed, 30 Sep 2020 10:00:34 -0700 (PDT) Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: <00f96e3a-b483-0f10-4b84-fdae14b6cba0@sydex.com> References: <000901d69740$02ac5d80$08051880$@classiccmp.org> <00f96e3a-b483-0f10-4b84-fdae14b6cba0@sydex.com> Message-ID: On Wed, 30 Sep 2020, Chuck Guzis via cctalk wrote: > It seems to depend on which postal hub an item is shipped through. > A few days ago, I received an item that was shipped USPS 3-day priority > that spent 10 days in Las Vegas (point of origin). All in all, it took > about 2 weeks to reach me here in Oregon. > The USPS didn't say if the package was comped dinner or drinks for the > layover in LV. Only comped lodging. With encouragement to extend free stay. But, a detour to any casino will get the comped drinks. I've had a few packages delayed here and there. Including one UPS "SurePost" that was lost on the way across the street from a UPS hub to USPS. And, a refund on a package from Switzerland, with an explanation that he could no longer ship to USA through DeutchPost. (A DVD including "Sharktopus V Whalewolf" for "Shark weak" as the weakest premise of a horror movie. Unless/until I can come up with a way to hack a capture of Amazon Prime Video, the only copies are in Switzerland, either shipped direct, or via UK.) But, overall, MOST USPS sees to be doing unusually well! -- Grumpy Ol' Fred From gavin at learn.bio Wed Sep 30 12:05:32 2020 From: gavin at learn.bio (Gavin Scott) Date: Wed, 30 Sep 2020 12:05:32 -0500 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: References: <000901d69740$02ac5d80$08051880$@classiccmp.org> <00f96e3a-b483-0f10-4b84-fdae14b6cba0@sydex.com> Message-ID: USPS (and UPS SurePost which is USPS last-mile-ish) have been delivering on schedule or often ahead of schedule to here in the Chicagoland area over the last month or so. USPS service has been excellent, with sometimes two deliveries per day (regular mail and small packages and a separate overflow package delivery. Zero issues across a couple dozen shipments. From jwest at ezwind.net Wed Sep 30 12:09:01 2020 From: jwest at ezwind.net (jwest at ezwind.net) Date: Wed, 30 Sep 2020 12:09:01 -0500 Subject: paging Jerome Fine Message-ID: <000201d6974c$649085b0$2db19110$@ezwind.net> Anyone know if Jerome Fine is still around and/or a good email address? From derschjo at gmail.com Wed Sep 30 12:40:22 2020 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 30 Sep 2020 10:40:22 -0700 Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: <645318535.242089.1601468415536@mail.yahoo.com> References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> <645318535.242089.1601468415536@mail.yahoo.com> Message-ID: On Wed, Sep 30, 2020 at 5:20 AM ED SHARPE via cctalk wrote: > whats the story on this...i see items but no pix. also check > your spelling on Motorola; Instrmentation and Control, Inc. that is in > the index. let me now if there is a photo group for this at least > with the covers I always wondered if it was just a 12 bit computer > or if it was software compatible with pdp-8? I wonder what else > this division of Motorola produced.... there was a teleprinter they > made... Here is the link to the teleprinter it is filed under gov > div. http://www.smecc.org/motolola_government.htmi think i got the 12 > bit computer manual from same person. The link is dead (seems misspelled, but even correcting it (and changing htmi to html) doesn't result in a link that works). I can't find any reference to you posting a link to the manual in the cctalk archives, but that doesn't mean it isn't there, somewhere. If you're able to scan this manual, I'd love a copy. The MDP-1000 is in no way like a PDP-8. Different memory word-size, has an actual ALU, 5 registers, etc. It's a very odd little system. I was doing a bit more reading last night and while the ALU is 12 bits wide, the Link (carry) bit is the carry out from bit 7. Logical operations only operate on the low 8 bits, though there are variants that work on the upper 4 bits only, as well. - Josh From a.carlini at ntlworld.com Wed Sep 30 13:06:49 2020 From: a.carlini at ntlworld.com (Antonio Carlini) Date: Wed, 30 Sep 2020 19:06:49 +0100 Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> <645318535.242089.1601468415536@mail.yahoo.com> Message-ID: <211820e5-3123-77b4-b40b-15c3c435ad6a@ntlworld.com> On 30/09/2020 18:40, Josh Dersch via cctalk wrote: > On Wed, Sep 30, 2020 at 5:20 AM ED SHARPE via cctalk > wrote: > >> whats the story on this...i see items but no pix. also check >> your spelling on Motorola; Instrmentation and Control, Inc. that is in >> the index. let me now if there is a photo group for this at least >> with the covers I always wondered if it was just a 12 bit computer >> or if it was software compatible with pdp-8? I wonder what else >> this division of Motorola produced.... there was a teleprinter they >> made... Here is the link to the teleprinter it is filed under gov >> div. http://www.smecc.org/motolola_government.htmi think i got the 12 >> bit computer manual from same person. > > The link is dead (seems misspelled, but even correcting it (and changing > htmi to html) doesn't result in a link that works). I can't find any > reference to you posting a link to the manual in the cctalk archives, but > that doesn't mean it isn't there, somewhere. If you're able to scan this > manual, I'd love a copy. > > The MDP-1000 is in no way like a PDP-8. Different memory word-size, has an > actual ALU, 5 registers, etc. It's a very odd little system. I was doing > a bit more reading last night and while the ALU is 12 bits wide, the Link > (carry) bit is the carry out from bit 7. Logical operations only operate > on the low 8 bits, though there are variants that work on the upper 4 bits > only, as well. > > - Josh Maybe here: http://www.smecc.org/motolola_government.htm?? ? I think the "i" wasn't an "ell" it was an "I" as in "I think ..."? Antonio -- Antonio Carlini antonio at acarlini.com From couryhouse at aol.com Wed Sep 30 13:31:28 2020 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 30 Sep 2020 18:31:28 +0000 (UTC) Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: <211820e5-3123-77b4-b40b-15c3c435ad6a@ntlworld.com> References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> <645318535.242089.1601468415536@mail.yahoo.com> <211820e5-3123-77b4-b40b-15c3c435ad6a@ntlworld.com> Message-ID: <1421061191.395067.1601490688913@mail.yahoo.com> her is? the? Motorola? hi speed? teleprinter? and? this is? a little? calc? device? ?pretty? neat....Motorola Military Electronics Division, Chicago Center 1450 Cicero Avenue Chicago 51 Illinois.? (Ed Groth Collection at SMECC) "http://www.smecc.org/motolo3.gif"? ?thanks? ed# ??? From couryhouse at aol.com Wed Sep 30 13:33:30 2020 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 30 Sep 2020 18:33:30 +0000 (UTC) Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: <211820e5-3123-77b4-b40b-15c3c435ad6a@ntlworld.com> References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> <645318535.242089.1601468415536@mail.yahoo.com> <211820e5-3123-77b4-b40b-15c3c435ad6a@ntlworld.com> Message-ID: <1102468636.403835.1601490810787@mail.yahoo.com> ?http://www.smecc.org/motolola_government.htm IS? URL? DO NOT? KNOW? WHERE? EXTRA LETTER? CAME? FROM? From jwsmail at jwsss.com Wed Sep 30 13:34:24 2020 From: jwsmail at jwsss.com (jim stephens) Date: Wed, 30 Sep 2020 11:34:24 -0700 Subject: Shipping via USPS Los Angeles is STALLED In-Reply-To: References: Message-ID: On 9/30/2020 6:41 AM, Bill Degnan via cctalk wrote: > I have a vintage computer sitting in the LA USPS since 9/17, Bill, I'm in Orange County, and items are moving in and out here (south of LA).? But they are all very small bubble pack and express mail type stuff. Sorry to hear of your problem.? If you need any in person attention, let me know.? We're just hanging out, and if we can do it with COVID precautions will do it. We did have three letters go somewhere, but we think the clerk who was an asshole did something.? We sent out duplicates and informed another desk person of the prior problem (this was about Sep 19 for the original) and they went in 3 days with first class postage. Also we mailed two items from our UPS Store drop, rather than taking them to the counter at the PO, one of which went to Gretta @ the CHM and it went in 2 days. BTW the main facilities for UPS / FEDX / USPS are all in Riverside County usually show up as Fontana.? they are all within a mile of each other with 200 or 300 sf operations each.? Los Angeles would be a local drop, not a normal freight or heavy parcel place to stall. I presume it wasn't shipped by some horrid Ebay discount shipping method.? If so it could be scanned once at this end, and shipped via "USPS" and it magically appears at some similar regional terminal set and pops back out into the USPS though it may actually be carried by one off the three.? I had something take > 2 weeks a month ago (smallish package with Raspberrypi and some accessories) show up and traveled like that. thanks Jim From nw.johnson at ieee.org Wed Sep 30 14:13:17 2020 From: nw.johnson at ieee.org (Nigel Johnson) Date: Wed, 30 Sep 2020 15:13:17 -0400 Subject: paging Jerome Fine In-Reply-To: <000201d6974c$649085b0$2db19110$@ezwind.net> References: <000201d6974c$649085b0$2db19110$@ezwind.net> Message-ID: I just spoke to Jerome on the phone a few days ago.? He just doesn't answer emails! I will be going to his house sometime in the near future, is there a message? cheers, Nigel Nigel Johnson, MSc., MIEEE, VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org On 30/09/2020 13:09, jwest--- via cctalk wrote: > Anyone know if Jerome Fine is still around and/or a good email address? > From geneb at deltasoft.com Wed Sep 30 14:27:54 2020 From: geneb at deltasoft.com (geneb) Date: Wed, 30 Sep 2020 12:27:54 -0700 (PDT) Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: <1102468636.403835.1601490810787@mail.yahoo.com> References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> <645318535.242089.1601468415536@mail.yahoo.com> <211820e5-3123-77b4-b40b-15c3c435ad6a@ntlworld.com> <1102468636.403835.1601490810787@mail.yahoo.com> Message-ID: On Wed, 30 Sep 2020, ED SHARPE via cctalk wrote: > ?http://www.smecc.org/motolola_government.htm IS? URL? DO NOT? KNOW? WHERE? EXTRA LETTER? CAME? FROM? > IT COMES FROM THAT GARBAGE FIRE OF AN EMAIL PROGRAM YOU INSIST ON USING! 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 couryhouse at aol.com Wed Sep 30 14:36:56 2020 From: couryhouse at aol.com (ED SHARPE) Date: Wed, 30 Sep 2020 19:36:56 +0000 (UTC) Subject: ISO: Motorola MDP-1000 info/software In-Reply-To: References: <429086877.225793.1601460777029@mail.yahoo.com> <739c4cf3-3e1a-a840-f8e0-8710aa61199f@bitsavers.org> <645318535.242089.1601468415536@mail.yahoo.com> <211820e5-3123-77b4-b40b-15c3c435ad6a@ntlworld.com> <1102468636.403835.1601490810787@mail.yahoo.com> Message-ID: <839763966.424887.1601494616896@mail.yahoo.com> wrong....? ?probably? my crippled? hands...? so there? wise ass! In a message dated 9/30/2020 12:27:59 PM US Mountain Standard Time, geneb at deltasoft.com writes:?On Wed, 30 Sep 2020, ED SHARPE via cctalk wrote: > ?http://www.smecc.org/motolola_government.htm IS? URL? DO NOT? KNOW? WHERE? EXTRA LETTER? CAME? FROM? > IT COMES FROM THAT GARBAGE FIRE OF AN EMAIL PROGRAM YOU INSIST ON USING! 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 jfoust at threedee.com Wed Sep 30 14:46:45 2020 From: jfoust at threedee.com (John Foust) Date: Wed, 30 Sep 2020 14:46:45 -0500 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200930185120.8E91A18C0B2@mercury.lcs.mit.edu> References: <20200930185120.8E91A18C0B2@mercury.lcs.mit.edu> Message-ID: <20200930200211.7C9374E6CA@mx2.ezwind.net> At 01:51 PM 9/30/2020, Noel Chiappa wrote: >I guess all this PDP-11 hardware detail isn't really on-topic for this list; I >should move it to Classic Computers, or something. I've got Riordan's udis[01..10].DSK disk images that I presume are similar to http://www.bitsavers.org/bits/Terak/mini-unix/ IMD images. Which filesystem would I find in these images, and which tool can burst the image into its files? - John From derschjo at gmail.com Wed Sep 30 15:04:41 2020 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 30 Sep 2020 13:04:41 -0700 Subject: Datasheet / Info for Motorola SC5330 IC? Message-ID: I'm in the middle of working out the pinout for the power supply connector on the MDP-1000. I'm aided somewhat by a set of test points on the backplane, unfortunately the "+" and "-" symbols (in the solder mask labels next to the test points) are nearly indiscernible, so I'm trying to verify that I'm not mixing up + and - 15V. On the core memory boards are eight Motorola SC5330 IC's (datecodes from early 1969), which have pins connected to both the + and - 15V lines -- if I can find a datasheet I could pretty easily confirm which is which. Trouble is I can't find anything on this chip. I've scanned through the databooks on Bitsavers, no luck. Anyone have any ideas? Here's a picture in case that helps at all: https://1drv.ms/u/s!Aqb36sqnCIfMpIVXm5draSrWHGMzJg - Josh From wdonzelli at gmail.com Wed Sep 30 15:08:03 2020 From: wdonzelli at gmail.com (William Donzelli) Date: Wed, 30 Sep 2020 16:08:03 -0400 Subject: Datasheet / Info for Motorola SC5330 IC? In-Reply-To: References: Message-ID: The Motorola SC prefix means a custom or semicustom part. Good luck! -- Will On Wed, Sep 30, 2020 at 4:05 PM Josh Dersch via cctalk wrote: > > I'm in the middle of working out the pinout for the power supply connector > on the MDP-1000. I'm aided somewhat by a set of test points on the > backplane, unfortunately the "+" and "-" symbols (in the solder mask labels > next to the test points) are nearly indiscernible, so I'm trying to verify > that I'm not mixing up + and - 15V. > > On the core memory boards are eight Motorola SC5330 IC's (datecodes from > early 1969), which have pins connected to both the + and - 15V lines -- if > I can find a datasheet I could pretty easily confirm which is which. > Trouble is I can't find anything on this chip. I've scanned through the > databooks on Bitsavers, no luck. Anyone have any ideas? > > Here's a picture in case that helps at all: > https://1drv.ms/u/s!Aqb36sqnCIfMpIVXm5draSrWHGMzJg > > - Josh From raywjewhurst at gmail.com Wed Sep 30 15:09:01 2020 From: raywjewhurst at gmail.com (Ray Jewhurst) Date: Wed, 30 Sep 2020 16:09:01 -0400 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200930200211.7C9374E6CA@mx2.ezwind.net> References: <20200930185120.8E91A18C0B2@mercury.lcs.mit.edu> <20200930200211.7C9374E6CA@mx2.ezwind.net> Message-ID: Where would one find these images? I would like to get them working on Simh. Thanks Ray On Wed, Sep 30, 2020, 4:02 PM John Foust via cctalk wrote: > At 01:51 PM 9/30/2020, Noel Chiappa wrote: > >I guess all this PDP-11 hardware detail isn't really on-topic for this > list; I > >should move it to Classic Computers, or something. > > I've got Riordan's udis[01..10].DSK disk images that I presume > are similar to http://www.bitsavers.org/bits/Terak/mini-unix/ > IMD images. > > Which filesystem would I find in these images, and which tool > can burst the image into its files? > > - John > > From imp at bsdimp.com Wed Sep 30 15:14:51 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 30 Sep 2020 14:14:51 -0600 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: References: <20200930185120.8E91A18C0B2@mercury.lcs.mit.edu> <20200930200211.7C9374E6CA@mx2.ezwind.net> Message-ID: If we can't use MINIUNIX to rebuild MINIUNIX kernel, should we try to bodge together rebuilding via apout? I have done some work there for 2.11BSD stuff, but didn't need it for bootstrapping (just needed to use it to bootstrap as). Warner On Wed, Sep 30, 2020 at 2:09 PM Ray Jewhurst via cctalk < cctalk at classiccmp.org> wrote: > Where would one find these images? I would like to get them working on > Simh. > > Thanks > Ray > > On Wed, Sep 30, 2020, 4:02 PM John Foust via cctalk > > wrote: > > > At 01:51 PM 9/30/2020, Noel Chiappa wrote: > > >I guess all this PDP-11 hardware detail isn't really on-topic for this > > list; I > > >should move it to Classic Computers, or something. > > > > I've got Riordan's udis[01..10].DSK disk images that I presume > > are similar to http://www.bitsavers.org/bits/Terak/mini-unix/ > > IMD images. > > > > Which filesystem would I find in these images, and which tool > > can burst the image into its files? > > > > - John > > > > > From jnc at mercury.lcs.mit.edu Wed Sep 30 16:35:42 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 30 Sep 2020 17:35:42 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200930213542.3431918C0BD@mercury.lcs.mit.edu> > From: Warner Losh > If we can't use MINIUNIX to rebuild MINIUNIX kernel, should we try to > bodge together rebuilding via apout? Good basic idea (using a different system to build on), but there's a better/easier approach (in the same basic vein): bring up V6, and mount the RK pack with Mini-Unix on it (it's a V6 file system, so is mountable); V6 is rock solid running under simulators. The V6 tools can I'm pretty sure be used directly to build new Mini-Unix kernels; user program can I think use the V6 C compiler, but I'm pretty sure not the standard V6 linker (the Mini-Unix linker loads tham at the non-standard address used by Mini-Unix). Noel From gavin at learn.bio Wed Sep 30 16:40:45 2020 From: gavin at learn.bio (Gavin Scott) Date: Wed, 30 Sep 2020 16:40:45 -0500 Subject: Datasheet / Info for Motorola SC5330 IC? In-Reply-To: References: Message-ID: Josh wrote: > https://1drv.ms/u/s!Aqb36sqnCIfMpIVXm5draSrWHGMzJg Would these potentially be the sense amp / comparators for the core? I wonder if they were anything like: https://datasheetspdf.com/pdf-file/1092342/Motorola/MC1711L/1 which might have a similar application and take +15 and -7 on L package pins 11 and 4 respectively with ground on pin 12. Being another Motorola design from what looks like a similar time period, I wonder if there could be a similarity in pinouts by some chance? From spacewar at gmail.com Wed Sep 30 16:44:28 2020 From: spacewar at gmail.com (Eric Smith) Date: Wed, 30 Sep 2020 15:44:28 -0600 Subject: Thoughts on restricted distribution documents (Dec Professional 350) In-Reply-To: <9923B1D7-F8C1-4663-B26C-2B435C0E359C@comcast.net> References: <580E5E3D-E7C7-44C3-85AF-288D8C7B4EA1@comcast.net> <002301d69675$9431ccc0$bc956640$@ntlworld.com> <09bea157-9cec-2563-5091-4599885893a8@ntlworld.com> <6D328FFC-FC2E-4A8C-B64F-B7CCBFAF5892@comcast.net> <7010cae3-5e44-240a-1fd8-7a738bd52d46@alembic.crystel.com> <057122CE-093C-43B9-927D-B7D9AD2263A7@comcast.net> <0e93b319-7d10-f563-6f6b-b250927987b4@mindspring.com> <77283737-7eaa-5091-9590-df6601e17bd0@bitsavers.org> <031d231f-b1b1-ca0a-b340-716c88494ea0@alembic.crystel.com> <9923B1D7-F8C1-4663-B26C-2B435C0E359C@comcast.net> Message-ID: On Tue, Sep 29, 2020 at 6:11 PM Paul Koning via cctalk < cctalk at classiccmp.org> wrote: > TIFF compression is lossless. > TIFF is only a container format ("Tagged Image File Format"). TIFF does not define any one compression. It in fact can contain either lossy or lossless compression, or even uncompressed images. For black-and-white documents (text and line art, no grey scale), it used to be somewhat common to use TIFF Class F Group 3 or Group 4 fax format, which is lossless, but TIFF can also contain DCT-compressed images (equivalent to JPEG). From lproven at gmail.com Wed Sep 30 17:19:03 2020 From: lproven at gmail.com (Liam Proven) Date: Thu, 1 Oct 2020 00:19:03 +0200 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200930213542.3431918C0BD@mercury.lcs.mit.edu> References: <20200930213542.3431918C0BD@mercury.lcs.mit.edu> Message-ID: On Wed, 30 Sep 2020 at 23:35, Noel Chiappa via cctalk wrote: > > Good basic idea (using a different system to build on), but there's a > better/easier approach (in the same basic vein): bring up V6, and mount the RK > pack with Mini-Unix on it (it's a V6 file system, so is mountable); V6 is rock > solid running under simulators. Would the x86-32 "reimplementation" of v6 UNIX be able to mount and/or read-write such filesystems? https://pdos.csail.mit.edu/6.828/2012/xv6.html -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053 From spacewar at gmail.com Wed Sep 30 17:25:45 2020 From: spacewar at gmail.com (Eric Smith) Date: Wed, 30 Sep 2020 16:25:45 -0600 Subject: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff. In-Reply-To: References: Message-ID: On Sun, Sep 27, 2020 at 3:22 PM Gavin Scott via cctalk < cctalk at classiccmp.org> wrote: > APL on the 3000 was a project started at HP Labs > in Palo Alto in the early 1970s. [...] > This would be the first > full APL implementation on a "small" (non-mainframe) computer. > There was IBM APL\1130 version 2, introduced in 1969. Maybe that can't considered "full"? I don't know all of what's missing; some accounts claim that it almost had feature parity with APL\360, except the circle function, which admittedly is a rather significant omission. I would be surprised if the circle function didn't make an appearance in later releases. In any case, that's awesome work resurrecting it! I used a 3000 a little bit in school from 1982 to 1984, but unfortunately it was mostly used for RJE to a System/370 elsewhere, so I didn't learn too much about the 3000. From derschjo at gmail.com Wed Sep 30 17:40:58 2020 From: derschjo at gmail.com (Josh Dersch) Date: Wed, 30 Sep 2020 15:40:58 -0700 Subject: Datasheet / Info for Motorola SC5330 IC? In-Reply-To: References: Message-ID: On Wed, Sep 30, 2020 at 2:41 PM Gavin Scott via cctalk < cctalk at classiccmp.org> wrote: > Josh wrote: > > https://1drv.ms/u/s!Aqb36sqnCIfMpIVXm5draSrWHGMzJg > > Would these potentially be the sense amp / comparators for the core? I > wonder if they were anything like: > > https://datasheetspdf.com/pdf-file/1092342/Motorola/MC1711L/1 > > which might have a similar application and take +15 and -7 on L > package pins 11 and 4 respectively with ground on pin 12. > > Being another Motorola design from what looks like a similar time > period, I wonder if there could be a similarity in pinouts by some > chance? > It's not an MC1711L based on that pinout. (But I suspect as you do that it's part of the sense amp for the core). In particular Pin 1 of the IC is connected to what I believe to be +15V. (It's also hard to tell what pin 1 is, since there's no orientation marker on these... ) Ground is pin 10. I suspect -15V is pin 7. - Josh From gavin at learn.bio Wed Sep 30 17:46:30 2020 From: gavin at learn.bio (Gavin Scott) Date: Wed, 30 Sep 2020 17:46:30 -0500 Subject: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff. In-Reply-To: References: Message-ID: Eric wrote: > There was IBM APL\1130 version 2, introduced in 1969. It's actually sorta annoying when you discover how much HP copied from IBM in those days. The first giveaway is that APL\3000 has a backslash in the product name when everything else was a forward slash as in BASIC/3000, FORTRAN/3000, and even RPG/3000 (which was another functional copy of an IBM product), and of course this is likely because of APL\360. Most people, even inside HP, started calling it APL/3000 almost immediately though. APL\3000 is supposed to be a functional superset of IBM APL SV (APL\360 with Shared Variables etc.) and HP advertised it as such. The other one that took me a while to notice is the HP 2641A APL Display Station that came out after the 2640 and 2645. That out-of-order numbering was kind of interesting until you discover that the IBM Selectric-based printing terminal with the APL type ball was the IBM 2741 (sigh). From jnc at mercury.lcs.mit.edu Wed Sep 30 17:58:05 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 30 Sep 2020 18:58:05 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200930225805.4D7A218C0BE@mercury.lcs.mit.edu> > From: Liam Proven > Would the x86-32 "reimplementation" of v6 UNIX be able to mount and/or > read-write such filesystems? No, it looks like it uses a different fie-system layout. Besides; there's not much point: the big adantage of using V6 is that one can use the V6 tool-chain to prepare Mini-Unix binaries; XV6 wouldn't allow that. If all one wants to do is get files in or out, there's already a program (compilable with gcc, that uses Standard I/O) to read files out of a V6 filesystem. If there was any good need, it could be extended to write (although that would be non-trivial). Noel From glen.slick at gmail.com Wed Sep 30 18:39:47 2020 From: glen.slick at gmail.com (Glen Slick) Date: Wed, 30 Sep 2020 16:39:47 -0700 Subject: Intel Developers' Insight CD-ROM collection archived anywhere? Message-ID: Does anyone have a collection of Intel Developers' Insight CD-ROMs in physical form or as images? The only physical CD-ROMs I have are a two disk set from February 1998. I don't know what time period these were available. Maybe mid or late 1990s to early 2000s? They have a variety of information on them such as datasheets and manuals that might not always be easy to find online anywhere anymore. As one example of something that I was recently unable to find online anywhere is a copy of either of these, which might have been available on some of the Intel Developers' Insight CD-ROMs: 297372 16-Mbit Flash Product Family User?s Manual 297508 FLASHBuilder Design Resource Tool Those are mentioned in various Intel flash memory datasheets and databooks from around the 1995 timeframe. The February 1998 CD-ROMs contain a copy of the Intel Flash SOFTWAREBuilder, which appears to be related to but different from the FLASHBuilder tool. From macro at linux-mips.org Wed Sep 30 20:55:53 2020 From: macro at linux-mips.org (Maciej W. Rozycki) Date: Thu, 1 Oct 2020 02:55:53 +0100 (BST) Subject: Intel Developers' Insight CD-ROM collection archived anywhere? In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020, Glen Slick via cctalk wrote: > Does anyone have a collection of Intel Developers' Insight CD-ROMs in > physical form or as images? The only physical CD-ROMs I have are a two > disk set from February 1998. I don't know what time period these were > available. Maybe mid or late 1990s to early 2000s? They have a variety > of information on them such as datasheets and manuals that might not > always be easy to find online anywhere anymore. I have physical discs, although apparently not here. They were issued quarterly and I had a subscription, so I should have them all. The span I have recorded is Oct 1996 through to May 1999. Some 15 years ago I made copies of all the PDF documents, so I can reach for any right away. For any other stuff I'd have to check the actual discs at my other site. > As one example of something that I was recently unable to find online > anywhere is a copy of either of these, which might have been available > on some of the Intel Developers' Insight CD-ROMs: > 297372 16-Mbit Flash Product Family User?s Manual > 297508 FLASHBuilder Design Resource Tool > Those are mentioned in various Intel flash memory datasheets and > databooks from around the 1995 timeframe. Sadly neither seems to be among the files I have copied. I could yet check Intel Dec 1995 Data on Demand discs I happen to have, and do have here, but they are cumbersome to handle as they use a proprietary format requiring a DOS app to access, and yet more hassle to get anything exported (assuming I can recall how I did that many years ago), so it'll take a little. Maciej From bobalan at sbcglobal.net Wed Sep 30 21:48:07 2020 From: bobalan at sbcglobal.net (Bob Rosenbloom) Date: Wed, 30 Sep 2020 19:48:07 -0700 Subject: Datasheet / Info for Motorola SC5330 IC? In-Reply-To: References: Message-ID: <290c6a22-faf6-d84a-84ed-f6d10f3c84db@sbcglobal.net> On 9/30/2020 3:40 PM, Josh Dersch via cctalk wrote: > On Wed, Sep 30, 2020 at 2:41 PM Gavin Scott via cctalk < > cctalk at classiccmp.org> wrote: > >> Josh wrote: >>> https://1drv.ms/u/s!Aqb36sqnCIfMpIVXm5draSrWHGMzJg >> Would these potentially be the sense amp / comparators for the core? I >> wonder if they were anything like: >> >> https://datasheetspdf.com/pdf-file/1092342/Motorola/MC1711L/1 >> >> which might have a similar application and take +15 and -7 on L >> package pins 11 and 4 respectively with ground on pin 12. >> >> Being another Motorola design from what looks like a similar time >> period, I wonder if there could be a similarity in pinouts by some >> chance? >> > It's not an MC1711L based on that pinout. (But I suspect as you do that > it's part of the sense amp for the core). In particular Pin 1 of the IC is > connected to what I believe to be +15V. (It's also hard to tell what pin 1 > is, since there's no orientation marker on these... ) Ground is pin 10. I > suspect -15V is pin 7. > > - Josh That pinout sounds like the Motorola MC1440 sense amp though the voltages are different. Bob -- Vintage computers and electronics www.dvq.com www.tekmuseum.com www.decmuseum.org