>
>Subject: Re: these RTL or what?
> From: woodelf <bfranchuk at jetnet.ab.ca>
> Date: Sat, 06 Oct 2007 18:10:55 -0600
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>William Donzelli wrote:
>
>>> Crunching numbers was a part of the task. The other part was moving
>>> and handeling data in mass storage and memory. Most of the DEC hardware
>>> moved data pretty fast. What was the demise of PDP-10 was simple, megabytes.
>>
>> And being six bit machine in an eight bit world...
>>
>SEVEN bit world. We can blame IBM for all our 8 bit PC ASCII stuff.
>Eight bits I think for EBDC was earlier. Having 4 bit sized TTL stuff
>does not make for nice octal digits. Ben.
Does it really makes that much differnce the number of bits for a char?
Really, Six bits was kinda tight for work where upper or lower case
was used but it didn't affect calculating Pi to a 100 places.
Wasn't the basic chunk 9 bits for PDP10 and it happened (DEC
software) used 6 bit char notation as a carry over from earlier
life with friden flexowriter and TTYs on earlier machines?
While It may have been an issue and part of the picture I don't
feel it was as heavy a weight as VAX was easier to promote and
potentially could address Gigabyte size memories with 32 bit
pointers rather than 256KW with a memory extension to 4MW.
I find it easier to see and recognize that bigger machines with
bigger memories for big programs crunching huge amounts of data
is what had a big part in the 10s demise.
Only opinion but hey, it's free.
Allison
>
>Subject: Re: these RTL or what?
> From: "William Donzelli" <wdonzelli at gmail.com>
> Date: Fri, 05 Oct 2007 13:55:28 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>> Using ultra-fast ECL doesn't make much sense when you've got nanoseconds
>> of delay to the backplane, to the next board, and back to the part that
>> needs the signal.
>
>That depends on how tight everything is. Thermal Conduction Module, anyone?
At 1ns/ft even the TCMs were not tight/dense enough.
>> The ECL technology used in the VAX9000 was gate arrays with roughly the
>> same timing parameters as 100K ECL (0.5 to 1.0 ns propogation delays).
>
>Yes, but I do not think that was the cutting edge anymore. Considering
>the 9000 was supposed to be the machine that finally convinces the
>mainframe world to accept DEC, it may have been a poor choice. We
>probably will never know. 9000 may have been as big of an
>embarrassment as the KC10.
>
>Even though the 9000s were bombs, they are one of the few VAX machines
>I would chase after.
;) the problem is the 9000 by time it got out the door CMOS system on a chip
was around the corner. With the ability to put transistors literally next to
each other it was easier to achieve overall speed. When you consider that
you could put multiple systems in less space than a 9000 well, quantity has
it's own special quality.
>> Responsiveness of a computer system depends on a lot more than the
>> speed of the semiconductors used to build it. Plenty of modern examples
>> of how to make fast silicon seem slow are coming out of Redmond I
>> notice :-).
;) I was always amazed that a dozen users could be on an 11/34 but one
user could bring a 486 to it's knees.
>
>I am thinking raw horsepower - all the benchmarking stuff. Looking at
>the KL10 (or the other DEC ECL machines), it justs seems like they
>should have been better number crunchers.
Crunching numbers was a part of the task. The other part was moving
and handeling data in mass storage and memory. Most of the DEC hardware
moved data pretty fast. What was the demise of PDP-10 was simple, megabytes.
A PDP-10 could not address the huge volumes of data in one chunk comming
>from the more complex models and programs in use. VAX offered a 32bit
address, PDP-10 was basicially 18bits with memory extension. If your
munching a model or database of millions of elements that is as important
as the time to add two word size numbers. It's why PDP-11 was replaced
with VAX and why VAX was replaced with Alpha.
In the end ECL was a way to speed but always at such a high system cost
and complexity it was often behind the curve for integration and delivery.
Usually other technologies were close enough behind and had the higher
density or ease of integrationin to larger systems needed to offset the
per gate speed with sometimes better complex function speeds.
Allison
>--
>Will
Second try at sending this to list.
----- Original Message -----
From: "Keys" <jrkeys at concentric.net>
To: "cctalk at classiccmp" <cctalk at classiccmp.org>
Sent: Friday, October 05, 2007 8:51 PM
Subject: Software Find at Thrift
> While checking out a old hangout I found a copy of IBM's Hollywood
> software Version 1.0 (on 3.5 FD), complete in the box for $1.81 plus tax.
> There was not much else there like it was in the long ago past. Speaking
> of Hollywood, the Hollywood video store near us is closing and I went
> dumpster driving the other night and found that they had tossed all the
> video game cases that had been on display. Most but not all were empty, I
> found PS2 and PS3 DVD's in some of the cases. It got too dark and I had to
> stop pulling cases from the dumpster but there was over 150 cases left in
> the trash.
>
> John
>
>Subject: Re: these RTL or what?
> From: "William Donzelli" <wdonzelli at gmail.com>
> Date: Sat, 06 Oct 2007 16:48:07 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>> >That depends on how tight everything is. Thermal Conduction Module, anyone?
>>
>> At 1ns/ft even the TCMs were not tight/dense enough.
>
>Have you ever seen a IBM TCM?
Yes, but conductors on substrate are slower depending on substrate used.
They are dense but TCMs still have to talk to other TCMs.
>> Crunching numbers was a part of the task. The other part was moving
>> and handeling data in mass storage and memory. Most of the DEC hardware
>> moved data pretty fast. What was the demise of PDP-10 was simple, megabytes.
>
>And being six bit machine in an eight bit world...
;) minor thing.
>--
>Will
>
>Subject: Re: New DSDD 5.25" floppies?
> From: "Ethan Dicks" <ethan.dicks at gmail.com>
> Date: Sat, 06 Oct 2007 17:41:24 +0200
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 10/5/07, Zane H. Healy <healyzh at aracnet.com> wrote:
>> And you all seem to have missed what I'm referring to. :^) Note the
>> "III" portion of 1541-III. :^)
>> http://jderogee.tripod.com/project1541.htm
>
>I've seen that before, and have often contemplated throwing one together.
>
>> I'm about ready to start collecting the parts needed and to see about
>> getting at least a couple circuit boards made.
>
>Would you mind sharing where you are getting Nokia 3310 phones (or the
>Phillips PDC 8544 LCD display)?
>
>> BTW, I currently have 3-5 1541's, 1 1571, and 1 or 2 Excelerator+Plus
>> (minus power-supplies) drives. I tend to use a pair of the 1541's.
>> Though the 1571 is at home rather than lost up in storage. :^) I use
>> the 1541's as I don't have a spare 1571. I prefer to only use drives
>> if I have a spare.
>
>I've never had a 1571 - I started with 1540 in 1982 (and wish I could
>find it - I think it has my Spartan Apple-II interface mounted inside
>it), then acquired a number of 1541s in my C-64 days, but never moved
>over to the C-128, so froze there in time (except for the 1581 I have
>that came from a defunct Commodore dealer - it works, but I haven't
>put more than a couple floppies through it).
>
>I _am_ interested in the 1541-III, but I'd *really* be interested in a
>FLASH-storage-based 2031 - i.e., with an IEEE-488 interface. I still
>do lots with PETs, and the .D64 support would solve one of the
>problems I have with running old programs - Infocom used "random
>files" (unstructured raw block access) for their Zmachine. The games
>were very much floppy-based, with no obvious way to migrate them to a
>hard disk or other non-floppy medium.
>
>-ethan
Something similar to that would be appealing for my Epson PX-8.
Allison
First, I don't think that DVD media is subject to "infant mortality" at all,
which is not to say that a just burned disc can't be defective. Now a
couple of things that look like infant mortality are possible, although the
mechanisms are not the same as what we usually call infant mortality. One
of these is that data written a burner whose laser power is below spec can
"fade" over time, but this is mostly a problem when using "RW" media (which
should be avoided for archival and backup uses). Also, a media that is
subject to bending can delaminate .... DVDs are a sandwich of two layers of
plastic glued together, and the data is stored on a dye layer coating on the
inside, at the juncture of the two layers. Delamination is fatal to the
data, and normally occurs from the outside in .... Good advice is to only
use 80% to 90% of the media capacity, leaving the outside edge (which is
where the first damage usually occurs) unused for data anyway.
Second, there is no doubt, I don't think, that dual layer media is
considerably less reliable than single layer media (knowing how dual layer
works, it's hard to believe that it works at all). That said, I have not
yet had a problem with any of the dual layer backups that I've made.
The subject of optical media longevity is one of considerable debate. All
studies by the media makers suggest a life of several decades to centuries,
but some skeptics insist on saying less than 10 years. I have optical CD
media that is now 12 years old that I can still read just fine. I think
that some of your practices are excessively conservative (such as only
applying power when the drives are being used), but will do no harm. The
biggest risk, I think, is burning with a marginal burner (low laser power
and/or bad or just dirty optics). Reading the media with a variety of
drives other than the one used for burning is certainly not a bad idea, but
for most users is unacceptably time consuming.
Wundebar...
That's nearly as bad as Vienna.
Rod
-----Original Message-----
From: cctech-bounces at classiccmp.org
[mailto:cctech-bounces at classiccmp.org] On Behalf Of Paul Heller
Sent: 05 October 2007 19:57
To: General Discussion: On-Topic Posts Only
Subject: Re: [Fwd: PDP8 im Ebay]
---- Original Message -----
From: "Rod Smallwood" <RodSmallwood at mail.ediconsulting.co.uk>
> I'm a bit confused as to where it is. The only Penzing I know is in
> Austria near Vienna.
> If it was northern Germany I'd go and get it. The system unit might be
> the basis for building up a PDP 8 system.
>
Google maps shows it near Munich.
Paul
On 10/5/07, Zane H. Healy <healyzh at aracnet.com> wrote:
> And you all seem to have missed what I'm referring to. :^) Note the
> "III" portion of 1541-III. :^)
> http://jderogee.tripod.com/project1541.htm
I've seen that before, and have often contemplated throwing one together.
> I'm about ready to start collecting the parts needed and to see about
> getting at least a couple circuit boards made.
Would you mind sharing where you are getting Nokia 3310 phones (or the
Phillips PDC 8544 LCD display)?
> BTW, I currently have 3-5 1541's, 1 1571, and 1 or 2 Excelerator+Plus
> (minus power-supplies) drives. I tend to use a pair of the 1541's.
> Though the 1571 is at home rather than lost up in storage. :^) I use
> the 1541's as I don't have a spare 1571. I prefer to only use drives
> if I have a spare.
I've never had a 1571 - I started with 1540 in 1982 (and wish I could
find it - I think it has my Spartan Apple-II interface mounted inside
it), then acquired a number of 1541s in my C-64 days, but never moved
over to the C-128, so froze there in time (except for the 1581 I have
that came from a defunct Commodore dealer - it works, but I haven't
put more than a couple floppies through it).
I _am_ interested in the 1541-III, but I'd *really* be interested in a
FLASH-storage-based 2031 - i.e., with an IEEE-488 interface. I still
do lots with PETs, and the .D64 support would solve one of the
problems I have with running old programs - Infocom used "random
files" (unstructured raw block access) for their Zmachine. The games
were very much floppy-based, with no obvious way to migrate them to a
hard disk or other non-floppy medium.
-ethan
> Hi Dave, I'm also interesting in doing this, but for a Star
Imagedisk should work fine. They are double sided, double density disks.
Somewhere I have a Unix program that can extract the contents from them.
I have at least a hundred 8010 floppies read already with various versions
of the Star OS, Interlistp-D, Server software and XDE.
