test-drb December 2005

test-drb@ccmp.vtda.org

235 participants
580 discussions

VS2000 speed (was RE: A Hobbyist DECnet Network)

by ajp166＠bellatlantic.net

> >Subject: Re: VS2000 speed (was RE: A Hobbyist DECnet Network) > From: "John Allain" <allain at panix.com> > Date: Fri, 09 Dec 2005 15:23:30 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >I remember my uVII (RD54 on QBus, no Windowing) taking about 9 minutes >to boot, and about 15 seconds to do a HELP page. Still worth the wait, >compared to PCDOS certainly. > >John A. I bet if it had 6mb of ram it was alot. Also if "help" was that slow it's because to save disk space it wasn't unpacked, add to that a lot of paging and swaping and eek bad. My smaller ba23 uVAXII is only 8mb but, I gave up the tape for a second disk an RD31. The RD31 was the swap and page disk as they were fairly fast (16 heads not a lot of cylinders). That helped a lot and the tuning of the startup helped. Got a lot of the waiting out. The BA123 has SCSI with two RZ56 and MSCP for RD54 and 53 and that with 16mb of ram is noticeably faster, even with DECwindows running useing the local hardware it's not bad. One VMS trick I've found helps is put the page and swap on another spindle, it helps. Even a netbooted VS2000 with 20mb local for page and swap flies noteably better. Allison

18 years, 9 months

A Hobbyist DECnet Network

by ajp166＠bellatlantic.net

> >Subject: RE: A Hobbyist DECnet Network > From: "Zane H. Healy" <healyzh at aracnet.com> > Date: Thu, 08 Dec 2005 22:47:25 -0800 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >At 9:33 PM -0500 12/8/05, Allison wrote: >> > [The first "personal" VAX I ever owned was a VS2000, around 1989/1990. I >>>used to come home, turn it on, and I could make dinner while I waited for it >>>to boot and start DECwindows!] >> >>I have three of them, one is used for formatting disks both floppy and hard. >>My first uVAX was a MicroVAX-II in BA23, still have it. > >Is a VS2000 really that slow to boot? I own one, but it has memory >problems, they don't prevent me from formating drives, but they do >prevent it from booting an OS. The VS2k is a bare bones uVAX-II cpu and inst very fast but I never thought the boot to be unusually slow unless the dianogstic were running. However if the startup of the various added processes (DECNnet and DECwindows) is in the wrong order or done all at once the process can drag out as you run into needing one to enable the next and they are all eating up the cpu at the same time. A little tweeking of SYS$startup.com makes a differnce. One thing is pruning off unused or unneeded stuff. >My first uVAX was a VAXstation II/RC in a BA23, I've still got it, >though the monitor needs repaired. My second was a MicroVAX II in a >BA123, and was the first VAX I got running, it's now my PDP-11/73. >I've never seen a MicroVAX II boot slow enough to make dinner :^) > > Zane I always used VT100/125 or VT340 as they are smaller than the huge 19" DECwindows tube. Allison

18 years, 9 months

Old MS-DOS & WIN Software

by dm561＠torfree.net

I'm getting rid of several large boxes of old MS-DOS & WIN software, OSs, apps, languages, utilities, games, etc. Also boxes of hardware such as PC MoBos, cards, keyboards, external print buffers, converters, <=9600bd modems etc. I realize without a detailed list this is rather vague, but I'd like to know if there's any interest in this sort of stuff to make it worth while actually making that list. If not here, maybe someone knows of another list where someone may be interested? TIA, mike

18 years, 9 months

A Hobbyist DECnet Network

by ajp166＠bellatlantic.net

> >Subject: Re: A Hobbyist DECnet Network > From: Sridhar Ayengar <ploopster at gmail.com> > Date: Fri, 09 Dec 2005 01:07:33 -0500 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Robert Armstrong wrote: >>>How would you protect these older systems against abuse from >>>the random crackers? VMS is probably tolerably safe in >>>current versions, if properly managed, but I'm betting there >>>are problems with other OSes. You could do vpns, I suppose. >> >> >> Depends on what you mean. Ordinary ("ordinary" :-) people who don't have >> a VAX running Multinet and join the "network" wouldn't be able to get in to >> any of the DECnet machines. >> >> However, it is true that the Multinet DECnet virtual circuit over IP has >> virtually no security. It would be easy, if you knew a little bit about >> DECnet and were so motivated, to sniff or spoof the traffic. Probably there >> just aren't many hackers out there who know enough about DECnet to worry >> about, and they have better targets for their efforts. >> >> Yes, you could solve the problem with VPNs. Multinet v5.1 seems to have >> the ability to do IPSEC, but I have no experience with that feature. If >> it's anything like IPSEC on a PC, it's a lot of overhead for a poor VAX. > >Ciscos will do DECnet Phase IV secure tunnels over IP too. So will IBM >Mainframes. > >Peace... Sridhar At one time DECnet was the routing protocal for other tunneled protocals. Allison

18 years, 9 months

VS2000 speed (was RE: A Hobbyist DECnet Network)

by ajp166＠bellatlantic.net

> >Subject: RE: VS2000 speed (was RE: A Hobbyist DECnet Network) > From: "a.carlini at ntlworld.com" <arcarlini at iee.org> > Date: Fri, 09 Dec 2005 19:03:42 +0000 > To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org> > >Robert Armstrong wrote: >>> The VS2k is a bare bones uVAX-II cpu and inst very fast but I never >>> thought the boot to be unusually slow unless the dianogstic >>> were running. >> >> RD5x drives are painfully slow, and this is especially a problem in >> the VS2000 because the integrated disk controller a) lacks DMA, and >> b) lacks the T11 chip to do local processing found in a RQDXn - the >> uVAX CPU has to do all the work. > >Wolfgang Moeller produced some patches way back when for the >uVAX/VS 2000 that would allow it to use a SCSI disk. > >Never actually tried it myself (as I had RD drives available >and faster machines if I just wanted speed). > >Antonio I have RD drives so I never tried it. I also now have RZ drives and it would be a good time to try it. Allison

18 years, 9 months

Reading Mac 800k Disks on Non-Mac Systems

by alhartman＠yahoo.com

On my Atari 520-ST, I have a "Magic Sac" from David Small, that emulates a Mac 128/512 or a Mac Plus with the appropriate ROMS. I bought the optional "Transporter One" which is a seperate computer (Z-80 Based, I think...) that reads and writes to 800k Floppies using the Floppy Controller port and the MIDI ports on the ST to communicate to the Transporter One. I also have a Spectre GCR, which is the follow on product when David Small started his own company. This unit has something in it that allows it to read/write to 800k Floppies without the Transporter One. The Transporter is slow, and we used to convert Mac Floppies to the Proprietary Magic Sac 800k Format that could be accessed with the ST's Floppy Controller. This was a pretty neat solution at the time, giving one a FASTER Mac than a Mac, with a bigger screen and access to Parallel Printers (using "Epstart"). I did a lot of advertising work on my ST back in the day. Unfortunately, my AERCO Ram upgrade gave up the ghost, and I can't find the Docs for it. So, I'm back to 512k unless I want to piggyback some RAM and take it up to 1024k. Used to have 2.5mb, which for a Mac Plus was plenty! Someday, I'll get it working again... Or find a MegaST cheap with a Hard Drive. Those were nice systems. A shame Atari didn't sell them as business computers in a professional form factor. I also used to have a Trackstar 128, which would allow a PC to Emulate an Apple ][+, and with a minor mod to certain floppy drives... Read and Write Apple II disks natively. I've gotta find another one of those someday. I think I have a board here called a "Hydra", at least... That's what the guy who sold it to me said it was... It was a board for an AT that was a MacPlus on a board, and allowed the PC to run Mac Software. I don't have any docs, software, or cables for it... And I'm not even sure this board IS a "Hydra" board. It has a 68k processor on it, but I don't see any Mac ROMS. This might be a terminal emulator board that someone thought was a Hydra Board. Regards, Al Hartman Philadelphia, PA __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

18 years, 9 months

cctalk Digest, Vol 28, Issue 27

by alhartman＠yahoo.com

A question... Anyone remember a board called "The Trash Compactor"? I went into a TRS-80 Model I case, and basically turned it into a Model III. It included the Disk Controller, Serial Interface and parallel interface all on one board. If anyone even has info about this board, I'd be interested to see it. Thanks! Al __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

18 years, 9 months

Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software

by ajp166＠bellatlantic.net

> >Subject: Re: Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software > From: "Chuck Guzis" <cclist at sydex.com> > Date: Fri, 09 Dec 2005 10:52:21 -0800 > To: cctalk at classiccmp.org > >On 12/9/2005 at 1:38 PM Allison wrote: > >>The early NEC 8080 (round lid prior to 77ish) set the flags wrong >>I believe it was the sign flag though I'd have to check. After IMSAI >>and others dumped them for the big they redesigned to exactly match >>the Intel 8080A, NEC part was 8080AF. > >I thought it was interesting that although IMSAI wouldn't use the NEC 8080A >part on their CPU cards, they freely used it in their floppy controller. >Probably to use up old stock, who knows? > >Cheers, >Chuck >(still got one of them old round-lid NECs) the FDC was canned code (rom) so they know what it was going to do. the S100 cpu broke with some basics using the NEC. Funny thing is the Intel data from '74 may also have been misleading. Allison

18 years, 9 months

TSX Plus distribution status...

by lbickley＠bickleywest.com

I've received a number of emails over the past few months as to the status of the TSX Plus distribution for hobbiests. I'm finally to the place where I thought I would be a few months ago! Some of this is background material - but I've included a fair amount of technical information which I hope will enable others to recover data from old disk drives that would otherwise be unreadable. -- As you may recollect, some months ago I contacted S&H Computer Systems, Inc. on behalf of collectors to see if I could obtain a free license, binaries, and documentation for TSX-Plus for collectors. After a bit of negotiating regarding the free license, I was granted permission to release TSX-Plus to hobbiests. I was provided with a copy of the latest release, including documentation. -- About the same time, I was told that S&H might be scrapping out their 11/73 system "in a few months". I told them not to scrap it out - but let me know when they wanted to "make it go away". Shortly thereafter, I was told they needed the space for a tenant - and the 11/73 needed to disappear. I put out a "rescue" request on this list (The "Nashville rescue") - and after a good deal of back-and-forth, a couple of folks responded to rescue. The only items I wanted were the disks that contained TSX "anything" - and that I'd be willing to pay whatever shipping costs there were to California. What I got was six RL02 packs and one Fujitsu 2312K (at about 85 pounds) and its associated Emulex SC02/C controller, cables, etc. (The SC02/C makes the 2312K look like two RK07's plus one RK06). I put together an 11/83 system from spare parts I had around, including a "new" TK50 drive. After getting it up - I tried out the 2312K - and it wouldn't even go "ready". When I disassembled the drive electronics (two boards) - I found that one of the jumpers on the second board was bent badly and the jumper had fallen off in shipment. My guess is that it was bent from the getgo - and the jumper fell off in the process of shipping it from Nashville to CA. At any rate - after I straightened out the pins and replaced the jumper - the drive would go "ready". I was able get directories for DM0:, DM1: and DM2:!!! I thought I was "home free" - but then a "nastyness" occurred - I got many errors (temporary and permanent) reading files from the 2312. I put out a manual request on this list - and fortunately, Joe Heck responded to my request and mailed me a copy of the M2312K manual. This was a Godsend - I couldn't have gone much further without it. After reading both the M2312K manual and the Emulex manual - I discovered a feature which saved the day. The drive and Emulex controller support "Servo Offset Plus and Minus". This means that the conroller will, on discovering a sector error, offset the cylinder position either plus or minus 3 micrometers off track and attempt to read the record again. I modified settings on the Emulex board to turn this feature "on". Subsequent to making this setting, the disk could "almost" entirely be read without permanent errors. Unfortunately, when I tried to backup and verify the disk to tape - I got a number of verify errors. Back to the "drawing board". Many of the files on the disk were huge ".dsk" files. Unfortunately, the likelihood of a permanent error in a huge file proved to be very likely. So while the above fix made recovering small files very likely - the huge files (12,000-36000 blocks long) remained error prone. I concluded that I'd have to further enhance my recovery technique. I decided to add a 40 MB RD32 (ST-251) to the system and recover data by disk to disk copies, followed by tape backup of the RD32. I found the best way of recovering data in this situation was to "mount" the "filename.dsk" files to a logical disks - and then copy the contents to a newly created and mounted logical disk on the backup disk. In many cases there were no errors in any of the copied files - even when the original .dsk files had several errors! While this technique worked well, it took a LOT of work and time. I literally spent weeks getting all the data off the 2312, The good news is this: The original release I received from S&H (which is all end users ever received) was 5.6 MB in size. After the 2312 and RL02 data recovery - I have about 73.5 MB of source, data and code. Included is a complete PDP-11 accounting system (which I've also received permission to release after I strip it of data files). I have the TSXPlus licensing software which can generate keys. This may or may not me necessary for hobbiest use - but at least I now have it if we need it. I haven't had the time to look at all the stuff that's in the 73.5 MB - that's a LOT of PDP-11 code! Given that I also have a "real" job - this has taken an extraordinary amount of work. I feel very relieved that the worst is over and now I can actually "play" with whatever I have archived. (Archived on tape, ZIP disks, and my companies RAID5 disk array - I'm not about to loose it now!!!). Additionally, I paid for the shipment of four huge boxes of TSX-Plus source listings to be sent from Nashville to California - and have given them to Al for scanning into bitsavers. While some of the source is in the archived data - most of it was "lost" by S&H at some point in history - except for the hard copy listings... After a bit of recovery time, I'll finally start getting TSXPlus, RTSORT, S&H COBOL and documentation - with licensing forms - on my Website for any and all PDP-11 hobbiests to download. Cheers, Lyle -- Lyle Bickley Bickley Consulting West Inc. Mountain View, CA http://bickleywest.com "Black holes are where God is dividing by zero"

18 years, 9 months

Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software

by ajp166＠bellatlantic.net

> >Subject: Re: Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software > From: "Chuck Guzis" <cclist at sydex.com> > Date: Fri, 09 Dec 2005 09:54:34 -0800 > To: cctalk at classiccmp.org > >On 12/9/2005 at 7:35 AM Allison wrote: > >>The other differences were internal effective address calculation was >>handled >>differntly from 8088 which shaved a few cycles of the execution. For the >>same clock V series were between 5-10% faster. Also the V20/V30 had 8080 >>emulation. > >Hmmm, thought I just said that. One of the more highly-touted performance >improvements in the V20/V30 was the implemenation of dual internal data >busses. In practice, I don't know if it made a huge difference in speed, >but NEC claimed up to a 30% improvement for som operations.. I added why it was faster. For the V20 in a XT clone it was easily 10% and for the V30 is was more.. Really nice parts. I'm generally not into 8088 but I've kept some of the older and newer V20s that have crossed my path for "maybe one day". The faster parts could scream. I kept a Tandy 1000hx because it was odd and used the V20. >FWIW, my reference manual for the 70108/70116 is dated August 1985 and >identifies both as "Low Power CMOS"; no mention otherwise of any other fab >technology. NEC did later offer the -H series variants (V20H, V30H, etc.) >which featured fully static operation and lower power consumption than the >V20/V30--and you could get them in clock speeds of up to 16 MHz. Those were the HCMOS process the change was mostly for speed. >I've got a reasonably thick folder in my files titled "Natick" with a bunch >of correspondence with the NEC folks there on the whole subject. The V40, >which was sort of an 80188 in CMOS (PGA, QFP and PLCC pacakges) also >claimed to emulate the 8080 instruction set, but I never got hold of one to >try it out (or I didn't care to). Likely from my old office and boss. By 85 it was CMOS before that it was NMOS. Even the first NMOS parts were really hybrid and much lower in power than the HMOSII from intel. Between 82 and 85 NEC was working on CMOS designs real hard and the first non-propritory 8 bit parts were 80C35. I have a few of the first samples with the page boundary bug, fixed in production. The V40/50 parts were still futures in 83 when I left. But looked interesting. >I thought it interesting that the 8080 emulation of the V20/V30 emulated >the Intel 8080A and not tne NEC 8080A instruction set. > >Cheers, >Chuck Well the Intel 8080A and the NEC8080AF are the same. NEC discontinued the incompatable 8080 version back around '78, they got burnt bad. The V20 implemented the 8080AF as bad memories were not lost. I have both versions. Taught them a lesson in compatability that wasn't forgotten. Even the 8085 and D780(Z80) execute the same undocumented instructions. On the other hand there is a sorta improved Z80 like thing NEC did, the ucom7800 series and they are interesting. Looks Z80 like but the instruction set is anything but. I have a bunch of the PIGGYback (78PG11) and romless 7800 parts. Allison

18 years, 9 months

← Newer
1
...
39
40
41
42
43
44
45
...
58
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb December 2005