test-drb May 2008

test-drb@ccmp.vtda.org

199 participants
350 discussions

by silent700＠gmail.com

http://www.intelligencecareers.com/jobs/jobview.cfm?jobid=282560&refsrc=shp… "Equipment to maintain includes IBM S390, RAMAC disk array, Cisco routers, VAX 4000, TU81 Tape Drives, Sun Servers and other electronic equipment."

16 years, 1 month

Minimal CP-M SBC design

by ajp166＠bellatlantic.net

> >Subject: Re: Minimal CP-M SBC design > From: Jules Richardson <jules.richardson99 at gmail.com> > Date: Mon, 12 May 2008 12:05:54 -0500 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Chuck Guzis wrote: >> If one wants to enjoy a "vintage" experience, what sense is there in >> being diskless? At any rate, even something as simple as a WD1770- >> type controller added to the design would give that capability with a >> minimum of support "glue". > >Agreed. > >> Alternatively, one could stay diskless and add a sound-effects module >> to emulate the "chunk" and "grrr" of a head-load and seek--and the >> "thunk-click" of a drive door being opened and a floppy inserted. > >And the high-pitched squeal of a disk shedding its coating in the drive... >(maybe a dip-switch for "Wabash mode"? :-) > >Personally I'm all for adding to vintage systems (hard disks where none were >originally supported, video additions etc.) if it makes the system a little >easier for frequent use - but not at the expense of original features. Part of >the 'experience' is being able to enjoy the system as it was originally used, >after all. (Similarly, I'm in awe of emulator writers - but give me the >original hardware any day...) > >cheers > >Jules I run the other extreme. I had the experiences, all the gory ones too. I still, Run Kaypro, AmproLB+, NS* horizon, CCS and Visual 1050 with real disks of all sorts. So what I do is build now what I was wishing I could build then whith parts that were unavailable then or frightenly expensive. Things like megabyte sized ramdisks and romdisks, fast storage that can beat the Teltek HDC and Q540 disk. It's about the code, the applications and if possible as much performance as I ever had only it runs on a few penlite cells. Most of all it's hacking hardware. I have many really good emulators/simulators and theres nothing like running one of those without brakes an a 2.4ghz dualcore to make one wish a real 100mhz++ Z80 really existed. Haven't you ever used a SD Horizon with it's whopping 82K per disk and a max of three drives and wondered what it would be like with three 8mb drives that run at CPU speeds back then or even now? I have and I've done it side by side! It's a kick to run a DBASE project that took 10 minutes to index on two floppies and see it done in a small fraction of the time. I not only open the envelope I punch holes in the corners. Back the I did "what if.." and even now I still do "what if..". Allison

16 years, 1 month

Is this the smallest PDP-11 compatible?

by cclist＠sydex.com

The Soviet Soyuz-Neon PK-11: http://www.leningrad.su/museum/show_calc.php?n=245 Regardless, a very interesting site with photos of various Soviet-era personal computers. Cheers, Chuck

16 years, 1 month

Another classic comp job

by tshoppa＠wmata.com

Evan writes: > One more data point: http://tinyurl.com/63uzvg -- see about 3/4 > down the story. What's astonishing is that they refer to EMC's disk arrays as a "cheap, new approach". Today, thirteen years after that article, EMC is the poster child for marketing obsolete way-overpriced technology through FUD intimidation! I would argue that by the mid-90's EMC had fallen into that trap. Tim.

16 years, 1 month

Another classic comp job

by tshoppa＠wmata.com

Evan asks: > Could they really still have a running RAMAC? At least in the early 90's IBM had rececycled RAMAC to mean a specific RAID product of theirs. e.g. "RAMAC array DASD". I remember a very large financial customer in the mid-90's being proud of having bought a terabyte of disk storage (oh, sorry "a terabyte of RAMAC array DASD") pretty much devoting an entire office building floor to it, and now I can go down to Staples and buy a terabyte of disk for a couple hours worth of paycheck. Tim.

16 years, 1 month

Early Appletalk; was Re: Interconnecting classic computers

by tsw-cc＠johana.com

--- Brad Parker <brad at heeltoe.com> wrote: > > > Ray Arachelian wrote: > > > >It's funny how they use CSMA/CA on this network instead of CSMA/CD, and > >when ethernet came out, they continued to use the same protocol until > >nearly modern days where they switched to encapsulating Appletalk > >packets inside TCP/IP frames. > > In fairness it would be proper to separate the mac (physical) layer from > the network layer. > > All the network layer needed was unreliable datagram delivery and > broadcasts. Both Localtalk and Ethernet provide that. > > Collision detect was not really possible on localtalk, unlike ethernet. > But I would argue that CA and CD are refinements which affect maximum > utilization, not gross access to the wire. And both rely on an > appropriate back-off algorithm to work correctly. > > (it's fun to go read the original AlohaNet papers and the DIX blue book > for more on that subject) > > >I was almost like they were re-inventing Ethernet. :-) > > When Sidhu started on that project ethernet was still pretty nascent. > And ethernet was thought of as too expensive and complex (which was > true, I think, when concidering a classic macintosh). > > And at that time there were many many protocols-of-the-day. It wasn't > clear at all which would be dominant. IPX, DecNet, TCP/IP, SNA, ISO ... > > >I suppose they > >could have actually ran ethernet over phone cables, but probably someone > >thought they had a better way to control collisions; perhaps they did. > > I think it was a cost issue. You can't beat the SCC's fm mode (and the > internal pll). They added a little RTS 'beacon' to reserve the wire > which was part of their 'collision avoidance' scheme. It worked pretty > well if you dedicated a cpu to it. > > >Of course there was nothing but trouble with early Ethernet switches and > >EtherTalk since they continued to use CSMA/CA for quite some time. > > I think that was a different problem; Appletalk V1 is very "chatty" > and uses broadcasts a lot. Many early networks were bridged and > this caused problems. I could go on and on, but localized broadcast > based discovery protocols don't work well over long haul bridged > networks, nor do broadcast based distance vector routing protocols > (i.e. NBP and RTMP). > > heh. I once crashed (I kid you not) several hundred VAX's with a single > NBP broadcast packet. Bridged networks are not my friend. > > >I guess there's nothing quite like the not invented here syndrome. > > Certainly some of that, but more in Appletalk v2 and than original > Appletalk. To my mind the original appletalk was simple and elegant - a > good fit for the system... > > -brad > > AppleTalk (in its various forms (LocalTalk, EtherTalk, and even TokenTalk) worked quite well for its INTENDED purpose. When Apple went from "Phase 1" to "Phase 2", it was because they realized at the time that routing packets were really clogging the system. The internal AppleTalk network Apple was using at the time would be passing around routing information on an idle network for over 10% of the traffic. It was simply getting out of hand. There was all this traffic at odd hours in the late night/early morning. "Phase 2" helped quite a bit as it narrowed down the traffic necessary to get the job done. Apple's internal network had LOTS of zones in it (all over the world), and even more nodes (they have lots of desks!). Before the earthquake every was always running around trying to find out who unplugged what (usually several cubes away under some desk). It was really bad. I was working on A/UX (Apple's Unix at the time, pre Linux!) networking in the AppleTalk area, and the idea there was to get printing to function (it did). Most of AppleTalk was a big push to get "plug & play" to work, and lots of effort was expended to this goal. It did work quite well, but if one was to administer a network, the "plug & play" aspect was almost counter to good administrative practices. The largest problem was naming. Plug & Play implied local naming, and good administrative practices indicate a central naming scheme. Oh, well. For the most part, Apple's networking was MUCH easier to use than the others at the time, if they existed at all. I've even got a couple of PC's connected to an AppleTalk server (there is code in Linux for it). If you want to run an understandable networking under MS-DOS, AppleTalk for PC's isn't that bad. A far sight easier than Novell's stuff (memory footprints aside). I note that even today, network printers have AppleTalk in them, and will still connect to ancient 68K based Macs (like my Quadra 840AV). No reason to change what is quite functional! Even today, networking seems to elicit "black magic" practices, but we are getting better! -- Sorry, No signature at the moment. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

16 years, 1 month

cctalk Digest, Vol 57, Issue 24

by cclist＠sydex.com

> Date: Mon, 12 May 2008 01:13:55 -0700 > From: Don North > I spent 15 years at Apple. My suspicion is Ron is probably still there. I have a memory of Ron at IIT (this would be about 1967) talking to a couple of older gentlemen visiting from Taiwan--in German. It's just one of those incongruous things that you never forget. Cheers, Chuck

16 years, 1 month

Minimal CP-M SBC design

by cclist＠sydex.com

> Date: Sat, 10 May 2008 12:29:24 -0400 > From: Dave McGuire > I dunno Chuck...the only reason more CP/M systems weren't ROM- > resident back in the day was due to convention, not technical > restrictions. I (personally) don't think there's anything > non-"period" about ROM-ing CP/M. It's not the ROM-ing of CP/M that disturbs me, but rather the "disklessness" of the thing. Wasn't the whole idea of CP/M originally to give you something to manage files on your floppy drives? I mean, that's what the bulk of the code in CP/M is for-- heaven knows, the support for other I/O is nothing to write home about. If one wants to enjoy a "vintage" experience, what sense is there in being diskless? At any rate, even something as simple as a WD1770- type controller added to the design would give that capability with a minimum of support "glue". Alternatively, one could stay diskless and add a sound-effects module to emulate the "chunk" and "grrr" of a head-load and seek--and the "thunk-click" of a drive door being opened and a floppy inserted. I still don't have the hang of this "vintage" thing yet, probably because I'm vintage myself. Please forgive my density... Cheers, Chuck

16 years, 1 month

cctalk Digest, Vol 57, Issue 24

by aek＠bitsavers.org

> I spent 15 years at Apple. My suspicion is Ron is probably still there. He was, the last I heard. He's one of the senior system architects, like Dave Conroy, that you will never hear anything about outside The Fruit.

16 years, 1 month

DOS/Floppy backup program benchmarks

by cclist＠sydex.com

> Date: Sun, 11 May 2008 22:35:36 -0500 > From: Jim Leonard > If I missed an obvious one that runs on XT-class hardware, let me know. I think I might have a couple to add to your list. I know I have an earlier version of FastBack that *does* use a proprietary format. I can shoot you a copy if you're interested. Cheers, Chuck

16 years, 1 month

← Newer
1
...
18
19
20
21
22
23
24
...
35
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 May 2008