Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cartons of Punch Cards

113 views
Skip to first unread message

Charles Richmond

unread,
Nov 21, 2011, 9:34:56 AM11/21/11
to
I know this was covered many times before, but how many boxes of punch cards
came in a carton???

And while I'm at it... how many punch cards came in a box??? The number
2000 sticks in my mind, but I'm *not* feeling sure about it.

--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond nume...@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

Stephen Wolstenholme

unread,
Nov 21, 2011, 10:05:04 AM11/21/11
to
On Mon, 21 Nov 2011 08:34:56 -0600, "Charles Richmond"
<net...@aquaporin4.com> wrote:

>I know this was covered many times before, but how many boxes of punch cards
>came in a carton???
>
>And while I'm at it... how many punch cards came in a box??? The number
>2000 sticks in my mind, but I'm *not* feeling sure about it.

Yep, 2000 it was.

Steve

--
Neural network software applications, help and support.

Neural Network Software. www.npsl1.com
EasyNN-plus. Neural Networks plus. www.easynn.com
SwingNN. Forecast with Neural Networks. www.swingnn.com
JustNN. Just Neural Networks. www.justnn.com

Nick Spalding

unread,
Nov 21, 2011, 10:23:05 AM11/21/11
to
Charles Richmond wrote, in <jadnii$8mn$1...@dont-email.me>
on Mon, 21 Nov 2011 08:34:56 -0600:

> I know this was covered many times before, but how many boxes of punch cards
> came in a carton???
>
> And while I'm at it... how many punch cards came in a box??? The number
> 2000 sticks in my mind, but I'm *not* feeling sure about it.

That is right. I'm thinking five boxes to a carton making 10,000.
--
Nick Spalding

Rod Speed

unread,
Nov 21, 2011, 1:27:30 PM11/21/11
to
Charles Richmond wrote:

> I know this was covered many times before, but how many boxes of punch cards came in a carton???

Pretty sure it was 5.

> And while I'm at it... how many punch cards came in a box??? The
> number 2000 sticks in my mind, but I'm *not* feeling sure about it.

Yes, thats correct.
http://en.wikipedia.org/wiki/Punched_card#IBM_80_column_punched_card_format


hanc...@bbs.cpcn.com

unread,
Nov 21, 2011, 2:18:41 PM11/21/11
to
On Nov 21, 9:34 am, "Charles Richmond" <netn...@aquaporin4.com> wrote:
> I know this was covered many times before, but how many boxes of punch cards
> came in a carton???
>
> And while I'm at it...  how many punch cards came in a box??? The number
> 2000 sticks in my mind, but I'm *not* feeling sure about it.

I think you can still buy blank or pre-printed punched card stock from
paper makers, though more for specialty index card use, not data
storage. Certain time-clock cards are "IBM" style, not sure if the
same size as a punch card.

Peter Flass

unread,
Nov 21, 2011, 3:29:07 PM11/21/11
to
On 11/21/2011 9:34 AM, Charles Richmond wrote:
> I know this was covered many times before, but how many boxes of punch
> cards came in a carton???
>
> And while I'm at it... how many punch cards came in a box??? The number
> 2000 sticks in my mind, but I'm *not* feeling sure about it.
>

Yup. AIR you could get 3000 in a metal carrying case.

David Dyer-Bennet

unread,
Nov 21, 2011, 3:49:07 PM11/21/11
to
"Charles Richmond" <net...@aquaporin4.com> writes:

> I know this was covered many times before, but how many boxes of punch
> cards came in a carton???

I remember it as being a single row, either 5 or 6.

> And while I'm at it... how many punch cards came in a box??? The
> number 2000 sticks in my mind, but I'm *not* feeling sure about it.

I remember that as correct. The 3000-card program was the first thing I
worked on that exceeded a box (it was a big jump).
--
David Dyer-Bennet, dd...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

Rod Speed

unread,
Nov 21, 2011, 4:45:23 PM11/21/11
to
David Dyer-Bennet wrote
> Charles Richmond <net...@aquaporin4.com> wrote

>> I know this was covered many times before, but how
>> many boxes of punch cards came in a carton???

> I remember it as being a single row,

Yes.

> either 5 or 6.

5

Charles Richmond

unread,
Apr 20, 2012, 2:59:41 PM4/20/12
to
"David Dyer-Bennet" <dd...@dd-b.net> wrote in message
news:ylfkk46t...@dd-b.net...
> "Charles Richmond" <net...@aquaporin4.com> writes:
>
>> I know this was covered many times before, but how many boxes of punch
>> cards came in a carton???
>
> I remember it as being a single row, either 5 or 6.
>
>> And while I'm at it... how many punch cards came in a box??? The
>> number 2000 sticks in my mind, but I'm *not* feeling sure about it.
>
> I remember that as correct. The 3000-card program was the first thing I
> worked on that exceeded a box (it was a big jump).
>

With 2,000 80-column cards to a box of cards, that means the maximum data
contained would be 160 kilobytes. With the olden 1.4 meg floppy disk (now
also considered ancient), one could store almost *nine* complete boxes of
cards. Of course, source deck cards seldom have all 80 bytes used, so the
practical boxes stored might be twice that.

A CD-R holding a puny 700 meg of data... could store 4,375 boxes of cards
having the *max* 80 bytes per card, and a regular DVD (4.7 gig) could store
over six times that many, or about 25,000 boxes of cards. Now with a Bluray
disk... but you get the idea. I'm sure *one* DVD could hold an entire
operating system release (either TOPS-10 or 360). And DVD's don't have to
use vacuum columns like the reel-to-reel tapes that the OS's traditionally
were distributed on.

(And there are as many nanoseconds in one second... as there are seconds in
31 years. There are as many picoseconds in one second... as there are
seconds in 310 centuries. There are as many femtoseconds in one second...
as there are seconds in 31,000 millennia. And this is figuring
conservatively.)

hanc...@bbs.cpcn.com

unread,
Apr 20, 2012, 3:10:31 PM4/20/12
to
On Apr 20, 2:59 pm, "Charles Richmond" <netn...@aquaporin4.com> wrote:

> With 2,000 80-column cards to a box of cards, that means the maximum data
> contained would be 160 kilobytes.  With the olden 1.4 meg floppy disk (now
> also considered ancient), one could store almost *nine* complete boxes of
> cards.  Of course, source deck cards seldom have all 80 bytes used, so the
> practical boxes stored might be twice that.

I believe in the 1990s the 1.4" floppy disk could be purchased for
about $1 each ($10 for a box of ten). In the 1970s I believe a box of
2,000 punch cards was about $2.00. Probably a lot more today.

Files on floppy disks could be 'zipped' to get signficantly more
storage space.

Then there are flash drives. The cost per bit on them is much lower.

Thinking about this makes me depressed. I used to think a box of
punched cards represented an "awful lot" of data. I used to think
reading cards at 1,000 cards per minute (2542) was "amazingly fast".
Yet I sit impatiently waiting for my flash drive to save an 8 meg
file.

I bought a single plane of core storage from a museum. I realized the
cost per bit for that was higher than the cost per bit than cheap PC
memory at that time.

Like I said, I'm depressed.

Charlie Gibbs

unread,
Apr 20, 2012, 8:14:30 PM4/20/12
to
In article
<564be0b8-d33a-4bef...@m18g2000vbl.googlegroups.com>,
hanc...@bbs.cpcn.com (hancock4) writes:

> I bought a single plane of core storage from a museum. I realized
> the cost per bit for that was higher than the cost per bit than cheap
> PC memory at that time.

I remember reading in a trade rag in the early '70s about how IBM
rocked the industry by slashing the price of a megabyte of memory
on the 370 from $75,000 to a mere $15,000.

The other day I added a gigabyte of memory to a laptop for $32.
That's a price reduction of six orders of magnitude.

> Like I said, I'm depressed.

The thing that depresses me is how much of that price/performance
improvement has been squandered by bloatware. But I guess when
you cut your teeth programming business applications that run in
16K, being told that you need a gigabyte to do it just doesn't
ring true.

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

Peter Flass

unread,
Apr 21, 2012, 8:08:54 AM4/21/12
to
On 4/20/2012 2:59 PM, Charles Richmond wrote:
>
> A CD-R holding a puny 700 meg of data... could store 4,375 boxes of
> cards having the *max* 80 bytes per card, and a regular DVD (4.7 gig)
> could store over six times that many, or about 25,000 boxes of cards.
> Now with a Bluray disk... but you get the idea. I'm sure *one* DVD could
> hold an entire operating system release (either TOPS-10 or 360). And
> DVD's don't have to use vacuum columns like the reel-to-reel tapes that
> the OS's traditionally were distributed on.

They do. I *believe* IBM distributes a developer release of z/OF
including software like DB/2, CICS, etc. on one DVD.

Hercules people get a complete release of MVS or VM/370 including all
source on a DVD.

--
Pete

jmfbahciv

unread,
Apr 21, 2012, 10:23:55 AM4/21/12
to
Charlie Gibbs wrote:
> In article
> <564be0b8-d33a-4bef...@m18g2000vbl.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>
>> I bought a single plane of core storage from a museum. I realized
>> the cost per bit for that was higher than the cost per bit than cheap
>> PC memory at that time.
>
> I remember reading in a trade rag in the early '70s about how IBM
> rocked the industry by slashing the price of a megabyte of memory
> on the 370 from $75,000 to a mere $15,000.
>
> The other day I added a gigabyte of memory to a laptop for $32.
> That's a price reduction of six orders of magnitude.
>
>> Like I said, I'm depressed.
>
> The thing that depresses me is how much of that price/performance
> improvement has been squandered by bloatware. But I guess when
> you cut your teeth programming business applications that run in
> 16K, being told that you need a gigabyte to do it just doesn't
> ring true.
>
That's why a TOPS-10 tri-SMP system felt faster than the systems
I have today.

/BAH

hanc...@bbs.cpcn.com

unread,
Apr 21, 2012, 10:05:02 PM4/21/12
to
On Apr 20, 8:14 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> The thing that depresses me is how much of that price/performance
> improvement has been squandered by bloatware.  But I guess when
> you cut your teeth programming business applications that run in
> 16K, being told that you need a gigabyte to do it just doesn't
> ring true.

yeah, they managed ran a whole hospital on a 16k 1401 with disk.
Apparently the programs included a "roll your own" pagination to disk.

Howard S Shubs

unread,
Apr 22, 2012, 2:09:41 AM4/22/12
to
In article <1132.528T1...@kltpzyxm.invalid>,
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> In article
> <564be0b8-d33a-4bef...@m18g2000vbl.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>
> > I bought a single plane of core storage from a museum. I realized
> > the cost per bit for that was higher than the cost per bit than cheap
> > PC memory at that time.
>
> I remember reading in a trade rag in the early '70s about how IBM
> rocked the industry by slashing the price of a megabyte of memory
> on the 370 from $75,000 to a mere $15,000.
>
> The other day I added a gigabyte of memory to a laptop for $32.
> That's a price reduction of six orders of magnitude.

More than that. Consider inflation.

Using <http://www.davemanuel.com/inflation-calculator.php>, $3 from 1974
would be almost $14 now.

Using <http://www.halfhill.com/inflation.html>, $3 from 1974 would be
over $15 now.

<http://146.142.4.24/cgi-bin/cpicalc.pl?cost1=3&year1=1974&year2=2012>
effectively agrees with davemanuel.com.

Add another order of magnitude.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

Walter Banks

unread,
Apr 22, 2012, 5:38:51 PM4/22/12
to


Charlie Gibbs wrote:

> In article
> <564be0b8-d33a-4bef...@m18g2000vbl.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>
> > I bought a single plane of core storage from a museum. I realized
> > the cost per bit for that was higher than the cost per bit than cheap
> > PC memory at that time.
>
> I remember reading in a trade rag in the early '70s about how IBM
> rocked the industry by slashing the price of a megabyte of memory
> on the 370 from $75,000 to a mere $15,000.
>
> The other day I added a gigabyte of memory to a laptop for $32.
> That's a price reduction of six orders of magnitude.

I ran a research center in the early 70's and bought a bunch of
PDP-11's in 1971 or 1972. During the negotiations I managed to
get the price of memory down to a dollar a byte a new local benchmark.

Everytime I pick up a thumb drive at my local grocery store for
about a $ per Gig I think of my discussions on that day 40 years
ago.

If only I had a time machine I would now be rich. :)

Walter Banks



Message has been deleted

Peter Flass

unread,
Apr 23, 2012, 7:58:22 AM4/23/12
to
On 4/22/2012 8:21 PM, Morten Reistad wrote:
> In article<4F947A6B...@bytecraft.com>,
> Walter Banks<wal...@bytecraft.com> wrote:
>>
>>
>> Charlie Gibbs wrote:
>>
>
> ..snip..
>>> The other day I added a gigabyte of memory to a laptop for $32.
>>> That's a price reduction of six orders of magnitude.
>>
>> I ran a research center in the early 70's and bought a bunch of
>> PDP-11's in 1971 or 1972. During the negotiations I managed to
>> get the price of memory down to a dollar a byte a new local benchmark.
>>
>> Everytime I pick up a thumb drive at my local grocery store for
>> about a $ per Gig I think of my discussions on that day 40 years
>> ago.
>>
>> If only I had a time machine I would now be rich. :)
>
> Yep. I keep the telex response from Prime Computer, dated
> September 1985 that confirms the order of 2 megabytes of
> memory, 1 FMD 315MB disk and a 15/16-line AMLC card for
> NOK 580K; about $100k at that time.
>
> None of these hardware items were particular stars, but
> they weren't total losers either.
>
> AFAIK they were in use until the system was dismantled in
> 1997.
>

One thing about core. There wasn't much that could go wrong with it.

--
Pete

jmfbahciv

unread,
Apr 23, 2012, 10:04:11 AM4/23/12
to
Unless the CPU developed a bit sprayer. I was working on my fucntional
spec for the USAGE project stand-alone on the KI one morning at 4:00.
Having the machine stand-alone, I did not do the usual EX$$ every few
minutes. All of a sudden, I heard <CTRL>G<CTRL>G<CTRL<G> and the system
died an _immediate_ horrible death. I screamed. JMF and TW came
over to see what was wrong. Later, they took my stand-alone pack, which
had the crash dump, and tried to retrieve the document I'd had in core.
There wasn't a recognizable bit left...the bit spraying was thorough.


/BAH

Charles Richmond

unread,
Apr 23, 2012, 10:41:40 AM4/23/12
to
"Walter Banks" <wal...@bytecraft.com> wrote in message
news:4F947A6B...@bytecraft.com...
>
> [snip...] [snip...]
> [snip...]
>
> I ran a research center in the early 70's and bought a bunch of
> PDP-11's in 1971 or 1972. During the negotiations I managed to
> get the price of memory down to a dollar a byte a new local benchmark.
>
> Everytime I pick up a thumb drive at my local grocery store for
> about a $ per Gig I think of my discussions on that day 40 years
> ago.
>
> If only I had a time machine I would now be rich. :)
>

If we knew back in the early 70's... that memory would be *so* cheap in the
21st century... we would have been *so* discouraged, we'd have given up!!!
;-)

Charles Richmond

unread,
Apr 23, 2012, 10:45:28 AM4/23/12
to
"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004BE5...@ac81c44f.ipt.aol.com...
>
> [snip...] [snip...] [snip...]
>
> Unless the CPU developed a bit sprayer. I was working on my fucntional
> spec for the USAGE project stand-alone on the KI one morning at 4:00.
> Having the machine stand-alone, I did not do the usual EX$$ every few
> minutes. All of a sudden, I heard <CTRL>G<CTRL>G<CTRL<G> and the system
> died an _immediate_ horrible death. I screamed. JMF and TW came
> over to see what was wrong. Later, they took my stand-alone pack, which
> had the crash dump, and tried to retrieve the document I'd had in core.
> There wasn't a recognizable bit left...the bit spraying was thorough.
>

SOS may have been a clunky editor, but it did have a setting so that it
would *automatically* save your file every 10 minutes. That would limit the
amount of loss sometimes.

David Dyer-Bennet

unread,
Apr 23, 2012, 10:57:55 AM4/23/12
to
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:

> In article
> <564be0b8-d33a-4bef...@m18g2000vbl.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>
>> I bought a single plane of core storage from a museum. I realized
>> the cost per bit for that was higher than the cost per bit than cheap
>> PC memory at that time.
>
> I remember reading in a trade rag in the early '70s about how IBM
> rocked the industry by slashing the price of a megabyte of memory
> on the 370 from $75,000 to a mere $15,000.

I remember the day word ran around MRO that the Vax memory price had
been dropped below $10,000 per megabyte. Even though Vax wasn't exactly
our favorite architecture around LCG software engineering, that was
clearly a great and momentous occasion.

> The other day I added a gigabyte of memory to a laptop for $32.
> That's a price reduction of six orders of magnitude.

Yep. Just remarkable.

My first hard drive (bought late, 1985) was big enough to hold about 1.3
digital images from my current camera (D700, in NEF format, Nikon's raw
forma).

Magnitudes have changed remarkably.

>> Like I said, I'm depressed.
>
> The thing that depresses me is how much of that price/performance
> improvement has been squandered by bloatware. But I guess when
> you cut your teeth programming business applications that run in
> 16K, being told that you need a gigabyte to do it just doesn't
> ring true.

One decision that's made frequently is whether to write custom code to
perform some function, or include a library that already exists.
Inlcluding the library will make your code bigger -- especially if the
library bundles a bunch of stuff together. However, the date handling
in a well-chosen library will be more complete and better tested than
what you'd probably write yourself for the project (it's existed for
years and been used by dozens or hundreds of other projects). And of
course it's already written, you just integrate it.

So, you've added 10 times the code you would have added writing your own
date code that did only what you needed in this project. But you're
sure it's right, and the facilities that will be needed in the future
are already there.

Was this a bad decision? It depends. But frequently something like
this is the right decision. It sill makes your code a lot bigger; but
memory is cheap these days.

(Which is not to say that there aren't sometimes sloppy lazy choices
that make code bigger for bad reasons. I'm sure there are.)

Michael Black

unread,
Apr 23, 2012, 11:34:29 AM4/23/12
to
On Mon, 23 Apr 2012, Charles Richmond wrote:

> "Walter Banks" <wal...@bytecraft.com> wrote in message
> news:4F947A6B...@bytecraft.com...
>>
>> [snip...] [snip...] [snip...]
>>
>> I ran a research center in the early 70's and bought a bunch of
>> PDP-11's in 1971 or 1972. During the negotiations I managed to
>> get the price of memory down to a dollar a byte a new local benchmark.
>>
>> Everytime I pick up a thumb drive at my local grocery store for
>> about a $ per Gig I think of my discussions on that day 40 years
>> ago.
>>
>> If only I had a time machine I would now be rich. :)
>>
>
> If we knew back in the early 70's... that memory would be *so* cheap in the
> 21st century... we would have been *so* discouraged, we'd have given up!!!
> ;-)
>
But is that so true?

Alan Kay created the Dynabook in the late sixties, but couldn't implement
it because the technology wasn't there. Doug Englerbart was doing that
stuff with the mouse and such, certain that at some point in the future
computers would be cheap enough to be personal.

The Xerox Alto was too early to be cheap, yet it set certain standards
that others eventually followed.

A lot of that work was dependent on CPUs getting faster, and cheaper, and
memory becoming denser and cheaper.

Those people at least saw a bright future, and plodded on.

The very price of these things have provided a different curve, density of
users. There are lots of people who can remember expensive memory, but
compared to those who came later because it became cheap, we are dwarfed.
So while we can tell stories of expensive RAM and the time before hard
drives were feasible on home computers, lots of other people have no idea
what we're talking about, their point of intersection has those cheap MP3
players and such.

Michael

Walter Bushell

unread,
Apr 23, 2012, 11:58:50 AM4/23/12
to
In article <ylfk4nsa...@dd-b.net>,
Well, with modern operating systems only the used code is loaded or at
least it gets swapped out to disk, so that is no longer a biggie,
although it can get annoying, like when I want to bring up a Save
dialog and the disk has to be restarted to bring it into ram.

--
This space unintentionally left blank.
Message has been deleted

Ben Pfaff

unread,
Apr 23, 2012, 12:27:15 PM4/23/12
to
jmfbahciv <See....@aol.com> writes:

> Unless the CPU developed a bit sprayer.

What's a "bit sprayer"?

Rod Speed

unread,
Apr 23, 2012, 2:19:21 PM4/23/12
to
Michael Black <et...@ncf.ca> wrote
> Charles Richmond wrote
>> Walter Banks <wal...@bytecraft.com> wrote

>>> I ran a research center in the early 70's and bought a bunch of
>>> PDP-11's in 1971 or 1972. During the negotiations I managed to
>>> get the price of memory down to a dollar a byte a new local benchmark.

>>> Everytime I pick up a thumb drive at my local grocery store for about a
>>> $ per Gig I think of my discussions on that day 40 years ago.

>>> If only I had a time machine I would now be rich. :)

>> If we knew back in the early 70's... that memory would be *so* cheap in
>> the 21st century... we would have been *so* discouraged, we'd have given
>> up!!! ;-)

> But is that so true?

No. Some still operate like that, most obviously with the tiny little
memory in so many machine controllers at the toaster level etc.

> Alan Kay created the Dynabook in the late sixties, but couldn't implement
> it because the technology wasn't there. Doug Englerbart was doing that
> stuff with the mouse and such, certain that at some point in the future
> computers would be cheap enough to be personal.

> The Xerox Alto was too early to be cheap, yet it set certain standards
> that others eventually followed.

> A lot of that work was dependent on CPUs getting faster, and cheaper, and
> memory becoming denser and cheaper.

And that even happened with Win. It wasn't really viable at
1.0 it needed the horsepower to catch up to make it viable.

Rod Speed

unread,
Apr 23, 2012, 2:26:06 PM4/23/12
to
Peter Flass <Peter...@Yahoo.com> wrote
> Morten Reistad wrote
>> Walter Banks<wal...@bytecraft.com> wrote
>>> Charlie Gibbs wrote

>>>> The other day I added a gigabyte of memory to a laptop for $32.
>>>> That's a price reduction of six orders of magnitude.

>>> I ran a research center in the early 70's and bought a bunch of
>>> PDP-11's in 1971 or 1972. During the negotiations I managed to
>>> get the price of memory down to a dollar a byte a new local benchmark.

>>> Everytime I pick up a thumb drive at my local grocery store for about
>>> a $ per Gig I think of my discussions on that day 40 years ago.

>>> If only I had a time machine I would now be rich. :)

>> Yep. I keep the telex response from Prime Computer, dated
>> September 1985 that confirms the order of 2 megabytes of
>> memory, 1 FMD 315MB disk and a 15/16-line AMLC card for
>> NOK 580K; about $100k at that time.

>> None of these hardware items were particular
>> stars, but they weren't total losers either.

>> AFAIK they were in use until the system was dismantled in 1997.

> One thing about core. There wasn't much that could go wrong with it.

That's just plain wrong. The problem was in the electronics that was
needed to use it. The signal levels were so low that the sense amps
had slice levels that had to be tweaked quite frequently and it wasn't
a trivial operation either, mostly germanium transistors too.
Message has been deleted

DJT

unread,
Apr 23, 2012, 6:08:22 PM4/23/12
to
I used to work on a GE 225 with care memory. We had the unfortunate
problem of one of the sense wires broke. The engineer had considerable
problem soldering it back together, very fine wire.

DJT

Joe Morris

unread,
Apr 23, 2012, 7:09:46 PM4/23/12
to
"Peter Flass" <Peter...@Yahoo.com> wrote:

> One thing about core. There wasn't much that could go wrong with it.

One of the stories I've heard (and can't cite authoratative sources
for...but it's still a good story):

The 7030 STRETCH used core memory that was immersed in a circulating oil
bath to maintain the optimum operating temperature. One of the early
machines developed a nasty habit of throwing memory errors from one of the
core boxes, but the location of the error was unpredictable.

After much head-scratching the engineers concluded that the only failure
mode that fit the symptoms was that there was a small solder blob floating
around in the oil, where it would from time to time short two wires in the
memory arrays. The response was to remove the oil from the memory tub and
replace it with fresh oil; after this was done the problem disappeared.

Joe


Rich Alderson

unread,
Apr 23, 2012, 8:23:00 PM4/23/12
to
"Charles Richmond" <net...@aquaporin4.com> writes:

> With 2,000 80-column cards to a box of cards, that means the maximum data
> contained would be 160 kilobytes. With the olden 1.4 meg floppy disk (now
> also considered ancient), one could store almost *nine* complete boxes of
> cards. Of course, source deck cards seldom have all 80 bytes used, so the
> practical boxes stored might be twice that.

On the ClassicCmp mailing list a while back, someone raised the question of how
many DECtape images could be fit onto a 2TB disk drive. After some quick back
of the envelope calculations, the consensus answer was "All of them!"

A DECtape can hold 256K words of 16-bit words on the PDP-11. The standard for
representing a PDP-11 DECtape for SimH (as an example) is as a 512KB stream of
bytes.

1TB = 1000GB = 100000MB = 1024000000KB = 2,000,000 DECtape inages.

We feel it is unlikely that as many as 4,000,000 DECtapes were manufactured.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

Walter Banks

unread,
Apr 23, 2012, 10:38:10 PM4/23/12
to


Michael Black wrote:

> On Mon, 23 Apr 2012, Charles Richmond wrote:
>
> > "Walter Banks" <wal...@bytecraft.com> wrote in message
> > news:4F947A6B...@bytecraft.com...
> >>
> >> [snip...] [snip...] [snip...]
> >>
> >> I ran a research center in the early 70's and bought a bunch of
> >> PDP-11's in 1971 or 1972. During the negotiations I managed to
> >> get the price of memory down to a dollar a byte a new local benchmark.
> >>
> >> Everytime I pick up a thumb drive at my local grocery store for
> >> about a $ per Gig I think of my discussions on that day 40 years
> >> ago.
> >>
> >> If only I had a time machine I would now be rich. :)
> >>
> >
> > If we knew back in the early 70's... that memory would be *so* cheap in the
> > 21st century... we would have been *so* discouraged, we'd have given up!!!
> > ;-)
> >
> But is that so true?
>
> Alan Kay created the Dynabook in the late sixties, but couldn't implement
> it because the technology wasn't there. Doug Englerbart was doing that
> stuff with the mouse and such, certain that at some point in the future
> computers would be cheap enough to be personal.
>
> The Xerox Alto was too early to be cheap, yet it set certain standards
> that others eventually followed.

John Corman and I developed probably the first commercial mouse available
on a IBM PC, few months after it was released for a company that was
developing yet another OS for the PC. The mouse was plugged in between
the keyboard and the PC.

Mice were hand manufactured under Doug Engelbart's patent and available in
very small quantities for $300 each. For a while they were production limited to
< 20 a week. We needed hundreds.

Walter..


jmfbahciv

unread,
Apr 24, 2012, 10:10:16 AM4/24/12
to
Once in a great, thankfully, while, a CPU could go berserk and
write bits all over memory. Sometimes, the system would crash
before all of memory was sprayed. In my case, the CPU was
throrough before the OS detected a problem.

You would have to ask a field service type for the technical
details.

/BAH

jmfbahciv

unread,
Apr 24, 2012, 10:10:19 AM4/24/12
to
Charles Richmond wrote:
> "jmfbahciv" <See....@aol.com> wrote in message
> news:PM0004BE5...@ac81c44f.ipt.aol.com...
>>
>> [snip...] [snip...] [snip...]
>>
>> Unless the CPU developed a bit sprayer. I was working on my fucntional
>> spec for the USAGE project stand-alone on the KI one morning at 4:00.
>> Having the machine stand-alone, I did not do the usual EX$$ every few
>> minutes. All of a sudden, I heard <CTRL>G<CTRL>G<CTRL<G> and the system
>> died an _immediate_ horrible death. I screamed. JMF and TW came
>> over to see what was wrong. Later, they took my stand-alone pack, which
>> had the crash dump, and tried to retrieve the document I'd had in core.
>> There wasn't a recognizable bit left...the bit spraying was thorough.
>>
>
> SOS may have been a clunky editor, but it did have a setting so that it
> would *automatically* save your file every 10 minutes. That would limit the
> amount of loss sometimes.

I never used that; I hated it. Remember that my job was to do massive
edits to files in a group who did this work. when my shift was done,
I would mark where I stopped so the next shift could pick up where
I left off. Since we worked on development machines, system crashes
were very common and part of the job environment. I would always
mark where I did an EX$$ so I didn't have to waste time backtracking
if I lost part of an edit.

/BAH

Charles Richmond

unread,
Apr 24, 2012, 10:27:36 AM4/24/12
to
"Michael Black" <et...@ncf.ca> wrote in message
news:Pine.LNX.4.64.12...@darkstar.example.net...
But Alan Kay and Doug Englebart were trying to *invent* a future for
computers. If they could have seen the resulting bloatware and computer
waste of today, they might have been disappointed a bit "back in the day".
IMHO Alan Kay did *not* want to invent DynaBook... so some twit could listen
to his MP3's or spend all his time texting. I don't believe that Doug
Englebart wanted the crap-wear that Mi$uck produced out of his windowing
ideas.

What I was talking about... was folks who were trying to get stuff done with
the relatively piddling resources of 40 years ago. If I were one of those
folks, it would be discouraging to me to *know* that in the future, the
things I was doing would be considered trivial and inconsequential. That is
the depressing and discouraging aspect I was referring to.

Charles Richmond

unread,
Apr 24, 2012, 10:38:24 AM4/24/12
to
"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004BE6...@aca22c28.ipt.aol.com...
"I sit by my window and I watch the cars.
I fear I'll do some damage one fine day.
But I would not be convicted by a jury of my peers.
Still crazy after all these years."

Sometimes when your program goes "off into the weeds", the CPU can do some
fine damage to what's in core. Cause and effect are *not* always localized
with a computer program.

Ben Pfaff

unread,
Apr 24, 2012, 12:02:02 PM4/24/12
to
jmfbahciv <See....@aol.com> writes:

> Ben Pfaff wrote:
>> jmfbahciv <See....@aol.com> writes:
>>
>>> Unless the CPU developed a bit sprayer.
>>
>> What's a "bit sprayer"?
>
> Once in a great, thankfully, while, a CPU could go berserk and
> write bits all over memory. Sometimes, the system would crash
> before all of memory was sprayed. In my case, the CPU was
> throrough before the OS detected a problem.

This was really a hardware fault rather than a software one?
I've never run into anything similar in the machines I've used
since 1985 or so. I'd be likely to laugh at anyone who claimed
that his modern computer had such a hardware fault.

Peter Flass

unread,
Apr 24, 2012, 2:33:24 PM4/24/12
to
On 4/24/2012 10:27 AM, Charles Richmond wrote:
>
> But Alan Kay and Doug Englebart were trying to *invent* a future for
> computers. If they could have seen the resulting bloatware and computer
> waste of today, they might have been disappointed a bit "back in the
> day". IMHO Alan Kay did *not* want to invent DynaBook... so some twit
> could listen to his MP3's or spend all his time texting. I don't believe
> that Doug Englebart wanted the crap-wear that Mi$uck produced out of his
> windowing ideas.
>
> What I was talking about... was folks who were trying to get stuff done
> with the relatively piddling resources of 40 years ago. If I were one of
> those folks, it would be discouraging to me to *know* that in the
> future, the things I was doing would be considered trivial and
> inconsequential. That is the depressing and discouraging aspect I was
> referring to.
>

The big driver for technology has been "entertainment" (for some values
of "entertainment"). P@rn was a big driver for the internet, and at one
point was the biggest user. I think the most popular app for the iPad
is "angry birds." It wouldn't be my preferred direction, but mostly I'm
happy to see the technology developed so the stuff I favor can get
dragged along and we can run TOPS-10 and VM/370 on our laptops.


--
Pete

Joe Pfeiffer

unread,
Apr 24, 2012, 11:11:13 PM4/24/12
to
I'm remembering a DeAnza graphics unit ca. 1980 (ok, yes that's before
1985), which needed to have all of its control registers refreshed any
time we changed one of them, as that reduced the likelihood of totally
random changes. Also, if the graphics buffer was cleared before we went
home, we'd find a lovely random star field when we came back in...

Walter Bushell

unread,
Apr 24, 2012, 11:37:53 PM4/24/12
to
In article <jn6dt1$l1n$1...@dont-email.me>,
"Charles Richmond" <net...@aquaporin4.com> wrote:

> "jmfbahciv" <See....@aol.com> wrote in message
> news:PM0004BE6...@aca22c28.ipt.aol.com...
> > Ben Pfaff wrote:
> >> jmfbahciv <See....@aol.com> writes:
> >>
> >>> Unless the CPU developed a bit sprayer.
> >>
> >> What's a "bit sprayer"?
> >
> > Once in a great, thankfully, while, a CPU could go berserk and
> > write bits all over memory. Sometimes, the system would crash
> > before all of memory was sprayed. In my case, the CPU was
> > throrough before the OS detected a problem.
> >
> > You would have to ask a field service type for the technical
> > details.
> >
>
> "I sit by my window and I watch the cars.
> I fear I'll do some damage one fine day.
> But I would not be convicted by a jury of my peers.
> Still crazy after all these years."
>
> Sometimes when your program goes "off into the weeds", the CPU can do some
> fine damage to what's in core. Cause and effect are *not* always localized
> with a computer program.

Hopefully today it's limited to your program by memory protection.

Walter Bushell

unread,
Apr 24, 2012, 11:44:29 PM4/24/12
to
In article <jn6rjt$f94$1...@dont-email.me>,
Peter Flass <Peter...@Yahoo.com> wrote:

> P@rn was a big driver for the internet, and at one
> point was the biggest user.

And for the users machine it was gamez. Even today the gamers are the
biggest consumers of high end graphic cards.
Message has been deleted
Message has been deleted

Peter Flass

unread,
Apr 25, 2012, 6:51:18 AM4/25/12
to
The problem is that if it's hardware all bets are off and anything can
happen.

--
Pete

jmfbahciv

unread,
Apr 25, 2012, 9:09:33 AM4/25/12
to
Very definitely hardware.

/BAH

jmfbahciv

unread,
Apr 25, 2012, 9:09:39 AM4/25/12
to
Morten Reistad wrote:
> In article <proto-035FC1....@news.panix.com>,
> Indeed. This is also where "ring-1-style" kernel threads come
> in handy. A crash in one of these can be contained somewhat.

I do not remember a software bit-sprayer crash ever. I wouldn't
even know how to code one. Buffer overruns just weren't done
as they are done today.

/BAH

jmfbahciv

unread,
Apr 25, 2012, 9:09:30 AM4/25/12
to
Walter Bushell wrote:
> In article <jn6rjt$f94$1...@dont-email.me>,
> Peter Flass <Peter...@Yahoo.com> wrote:
>
>> P@rn was a big driver for the internet, and at one
>> point was the biggest user.
>
> And for the users machine it was gamez. Even today the gamers are the
> biggest consumers of high end graphic cards.
>
Those people do a valuable service w.r.t. testing.

/BAH

Walter Bushell

unread,
Apr 25, 2012, 9:47:31 AM4/25/12
to
In article <PM0004BE8...@ac81673f.ipt.aol.com>,
I had one. I stored data in an array beyond the bounds and executed a
floating point number, which turned out to be a jump instruction which
jumped around a part of my program. I ended up killing the bug with
DDT.

Walter Bushell

unread,
Apr 25, 2012, 9:53:37 AM4/25/12
to
In article <PM0004BE8...@ac81673f.ipt.aol.com>,
jmfbahciv <See....@aol.com> wrote:

Not to mention financing.
Message has been deleted

Charlie Gibbs

unread,
Apr 25, 2012, 12:06:33 PM4/25/12
to
In article <jn6dt1$l1n$1...@dont-email.me>, net...@aquaporin4.com
(Charles Richmond) writes:

> "jmfbahciv" <See....@aol.com> wrote in message
> news:PM0004BE6...@aca22c28.ipt.aol.com...
>
>> Ben Pfaff wrote:
>>
>>> jmfbahciv <See....@aol.com> writes:
>>>
>>>> Unless the CPU developed a bit sprayer.
>>>
>>> What's a "bit sprayer"?
>>
>> Once in a great, thankfully, while, a CPU could go berserk and
>> write bits all over memory. Sometimes, the system would crash
>> before all of memory was sprayed. In my case, the CPU was
>> throrough before the OS detected a problem.
>>
>> You would have to ask a field service type for the technical
>> details.
>
> "I sit by my window and I watch the cars.
> I fear I'll do some damage one fine day.
> But I would not be convicted by a jury of my peers.
> Still crazy after all these years."
>
> Sometimes when your program goes "off into the weeds", the CPU can
> do some fine damage to what's in core. Cause and effect are *not*
> always localized with a computer program.

I remember in my IMSAI days the sinking feeling you'd get when
the lights would start to flicker in a pattern that indicated
what we called a "stack loop" - which wiped all memory to copies
of the instruction that wiped it.

Speaking of cause and effect, I still occasionally get buffer
overruns that clobber that portion of the stack that holds
the return address and register contents. That's when my program
starts suddenly terminating with no message - not even a typical
OS-generated "your program has failed". A symbolic debugger doesn't
help because its idea of where everything is has been clobbered as
well. And, of course, these problems don't occur until you exit
the function that caused them. Sometimes there's no sign of trouble
until the program tries to terminate. And, of course, if you insert
some debugging code, the clobbered area moves somewhere harmless and
your program runs without error. Another Heisenbug...

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

Message has been deleted

Walter Banks

unread,
Apr 25, 2012, 1:01:29 PM4/25/12
to


Charles Richmond wrote:

>
> Sometimes when your program goes "off into the weeds", the CPU can do some
> fine damage to what's in core. Cause and effect are *not* always localized
> with a computer program.
>

Old computers were fun in their failure modes. IBM1620's would miss a flag
on a one of its variable length numbers and bang the lights would have a
familiar
pattern of a math operation never completing. Red button on the console time.

The best (or worst) failure I have seen in that era was a two pass fortran
compiler that read in cards and stored the information on a mag tape during
the first pass as n improvement from when the cards would need to be
read twice.

The card reader had a grooved belt that picked the cards and held on to
them around a pulley through a reader station around a second pulley and
stacked them in a second tray.

The top of each pulley was stabilized with a flat brace to the main frame
of the reader.

In this particular fateful day the cards read in on the first pass going by
the reader then separating from the belt airborne until hitting the brace
to the second pulley where they were each split horizontally fluttering away
into a pile on the floor. An observant operator realized that the contents
was still available in machine readable form on the mag tape intermediate
storage and thereby yanking success out of the jaws of failure. All he had
to do was wait for the tape to stop spinning and dismount it.

No it wasn't what you would think, the file was not erased. Success, the
tape was secured now it was utility time to read the tape and punch a
new deck of cards. After several days a utility was written and tried
only to find out that the file on the tape had been tokenized.

Several days after hundreds of cards were destroyed the sound of a
026 keypunch could be heard well into the night punching the contents
of an old listing without recent changes onto cards.

No I don't miss the old days of computing

w..


Rod Speed

unread,
Apr 25, 2012, 3:51:08 PM4/25/12
to
jmfbahciv <See....@aol.com> wrote
> Walter Bushell wrote
>> Peter Flass <Peter...@Yahoo.com> wrote

>>> P@rn was a big driver for the internet,

That’s always been a myth.

>>> and at one point was the biggest user.

Don’t believe it ever was.

>> And for the users machine it was gamez. Even today the
>> gamers are the biggest consumers of high end graphic cards.

> Those people do a valuable service w.r.t. testing.

That’s very arguable indeed with high performance graphics
systems that don’t in fact get used by anyone else much,

That area has now diverged significantly, what best
for gaming isnt actually much use for anything else.
Similarly with the other high end graphics systems.

Rod Speed

unread,
Apr 25, 2012, 3:55:08 PM4/25/12
to
jmfbahciv <See....@aol.com> wrote
> Ben Pfaff wrote
>> jmfbahciv <See....@aol.com> wrote
>>> Ben Pfaff wrote
>>>> jmfbahciv <See....@aol.com> wrote

>>>>> Unless the CPU developed a bit sprayer.

>>>> What's a "bit sprayer"?

>>> Once in a great, thankfully, while, a CPU could go berserk
>>> and write bits all over memory. Sometimes, the system
>>> would crash before all of memory was sprayed. In my case,
>>> the CPU was throrough before the OS detected a problem.

>> This was really a hardware fault rather than a software one?
>> I've never run into anything similar in the machines I've used
>> since 1985 or so. I'd be likely to laugh at anyone who claimed
>> that his modern computer had such a hardware fault.

> Very definitely hardware.

But not seen much at all with modern systems for some reason.

Presumably those who know why it happened with the
10 or 20 know why it doesn’t happen with modern systems.

Not unusual with hardware faults, some approaches do have their
characteristic failure modes that arent seen with other approaches.

What happened with core is nothing like what happens with ram.

Rod Speed

unread,
Apr 25, 2012, 4:08:58 PM4/25/12
to
jmfbahciv <See....@aol.com> wrote
> Morten Reistad wrote
>> Walter Bushell <pr...@panix.com> wrote
>>> Charles Richmond <net...@aquaporin4.com> wrote
>>>> jmfbahciv <See....@aol.com> wrote
>>>>> Ben Pfaff wrote
>>>>>> jmfbahciv <See....@aol.com> wrote

>>>>>>> Unless the CPU developed a bit sprayer.

>>>>>> What's a "bit sprayer"?

>>>>> Once in a great, thankfully, while, a CPU could go berserk and
>>>>> write bits all over memory. Sometimes, the system would crash
>>>>> before all of memory was sprayed. In my case, the CPU was
>>>>> throrough before the OS detected a problem.

>>>>> You would have to ask a field service type for the technical details.

>>>> "I sit by my window and I watch the cars.
>>>> I fear I'll do some damage one fine day.
>>>> But I would not be convicted by a jury of my peers.
>>>> Still crazy after all these years."

>>>> Sometimes when your program goes "off into the weeds",
>>>> the CPU can do some fine damage to what's in core. Cause
>>>> and effect are *not* always localized with a computer program.

>>> Hopefully today it's limited to your program by memory protection.

>> Indeed. This is also where "ring-1-style" kernel threads come
>> in handy. A crash in one of these can be contained somewhat.

> I do not remember a software bit-sprayer crash ever.
> I wouldn't even know how to code one.

One obvious way to do one with a 10 or 20 is with
that arbitrary byte size instruction, with a 1 bit byte.

Maybe that’s why hardware bit sprayers arent common
at all outside the 10 and 20, maybe it was a hardware
failure in that area that produced that. Don’t know
enough about how that was implemented to say.

> Buffer overruns just weren't done as they are done today.

Largely because those came with the use of null terminated strings.

Charles Richmond

unread,
Apr 25, 2012, 7:19:58 PM4/25/12
to
"Walter Banks" <wal...@bytecraft.com> wrote in message
news:4F982DE9...@bytecraft.com...
Congratulations!!! You just invented the IBM 1620 card shredder!!! It's
much more sturdy than the flimsy shredders you buy in the business supply
store.

> No it wasn't what you would think, the file was not erased. Success, the
> tape was secured now it was utility time to read the tape and punch a
> new deck of cards. After several days a utility was written and tried
> only to find out that the file on the tape had been tokenized.
>
> Several days after hundreds of cards were destroyed the sound of a
> 026 keypunch could be heard well into the night punching the contents
> of an old listing without recent changes onto cards.
>
> No I don't miss the old days of computing
>

Couldn't a piece of software be written to de-tokenize the file on the
tape???

Peter Flass

unread,
Apr 25, 2012, 8:11:32 PM4/25/12
to
On 4/25/2012 12:06 PM, Charlie Gibbs wrote:
>
> Speaking of cause and effect, I still occasionally get buffer
> overruns that clobber that portion of the stack that holds
> the return address and register contents. That's when my program
> starts suddenly terminating with no message - not even a typical
> OS-generated "your program has failed". A symbolic debugger doesn't
> help because its idea of where everything is has been clobbered as
> well. And, of course, these problems don't occur until you exit
> the function that caused them. Sometimes there's no sign of trouble
> until the program tries to terminate. And, of course, if you insert
> some debugging code, the clobbered area moves somewhere harmless and
> your program runs without error. Another Heisenbug...

Yes, I get these too. In my NSH opinion, this is due to Intel's stupid
idea to have the stack grow down instead of up. If you're going to
clobber something it's usually by exceeding array bounds or string
lengths. When the stack grows up the junk gets written into empty space
- still an error, but doesn't hurt anything else. When the stack grows
down you're guaranteed to clobber something you need, and the return
address is often the thing that's in the line of fire.

--
Pete

Joe Morris

unread,
Apr 25, 2012, 8:55:12 PM4/25/12
to
"Peter Flass" <Peter...@Yahoo.com> wrote:

> The problem is that if it's hardware all bets are off
> and anything can happen.

...and usually does.

When Mike Armstrong was at the University of Rochester they took delivery of
a 3032, but it had a nasty habit of blowing the system away from long-stable
parts of the code. As I recall Mike's description, the problem was a flaky
bit in the instruction decoder - one of the few places where a data bus
didn't have parity checking - which had the effect of occasionally turning
an addition operation into a subtraction. I'm still amazed that the
sysprogs there figured it out; the diagnostics didn't.

At my PPOE we had a 3031 that for a short time after delivery had a no-cost
extra feature: "Branch Maybe," aka an intermittent failure of one of the
condition code latches. The diagnostics did eventually find this one,
probably (I don't remember) via margin checking.

Joe


Joe Morris

unread,
Apr 25, 2012, 9:09:46 PM4/25/12
to
"Walter Banks" <wal...@bytecraft.com> wrote:

> Old computers were fun in their failure modes. IBM1620's would miss a flag
> on a one of its variable length numbers and bang the lights would have a
> familiar
> pattern of a math operation never completing. Red button on the console
> time.

> The best (or worst) failure I have seen in that era was a two pass fortran
> compiler that read in cards and stored the information on a mag tape
> during
> the first pass as n improvement from when the cards would need to be
> read twice.
>
> The card reader had a grooved belt that picked the cards and held on to
> them around a pulley through a reader station around a second pulley and
> stacked them in a second tray.

What card reader model was that? The only card device I ever saw attached
to a 1620 was the 1622 reader/punch, which had the same basic design as the
1402: for both the reader and the punch cards feed from the bottom of the
supply stack, but then are carried linearly across the first and second read
brushes (read side; punch and verify brushes on the punch side) by rollers
and eventually drop into one of three stackers[*]. That machine didn't have
a feed that routed cards around a pulley.

Joe

[*] Yes, the 1402, 1622, and 2540 all had five stackers - but a card could
go into only one of three. Two stackers were dedicated to the reader, two
to the punch, and the center stacker could receive cards from either side.


Louis Krupp

unread,
Apr 26, 2012, 5:03:02 AM4/26/12
to
The space above the stack might not be as empty as one would hope. I
helped port some C++ code to an HPUX box a few years ago. The stack
grew up, if I recall correctly, but past the end of the stack was
other stuff, including a block of pointers to system functions. This
block shouldn't have been writable, but was. A wild pointer or a
stack overflow or something -- I don't remember exactly what --
clobbered the pointer to the read() function. Everything muddled
along until the next call to read(), which failed with a segmentation
fault.

Part of the fun was dealing with C++ programmers who couldn't believe
that there was *any* limit to virtual memory or stack space.

Burroughs Large Systems had a stack that grew up instead of down, as
do (as far as I know) their Unisys successors. The stack had a limit
register; it could be extended automatically at least a few times,
but a runaway program would eventually fail with a stack overflow
rather than corrupt random pieces of memory.

Louis

Peter Flass

unread,
Apr 26, 2012, 6:14:11 AM4/26/12
to
You know Mike? If he's the Mike Armstrong I knew - sysprog at the U of
R around 1966 - he taught a course I took. I have him to hlm to blame
for PL/I! There's a long time span between the 360/50 and the 3031 though.


--
Pete

Walter Banks

unread,
Apr 26, 2012, 7:34:16 AM4/26/12
to
Doesn't matter which way the stack grows. As a compiler writer for
the last 40+ years if it grows down just allocate space for the stack
at the bottom of RAM and and globals above it. Then wait for the
stack to wrap and kill your variables:)

Until stack growth could be reliably trapped it was always a problem.

w..

Joe Morris

unread,
Apr 26, 2012, 6:38:10 AM4/26/12
to
"Peter Flass" <Peter...@Yahoo.com> wrote:
> On 4/25/2012 8:55 PM, Joe Morris wrote:

>> When Mike Armstrong was at the University of Rochester they took delivery
>> of
>> a 3032, but it had a nasty habit of blowing the system away from
>> long-stable
>> parts of the code. As I recall Mike's description, the problem was a
>> flaky
>> bit in the instruction decoder - one of the few places where a data bus
>> didn't have parity checking - which had the effect of occasionally
>> turning
>> an addition operation into a subtraction. I'm still amazed that the
>> sysprogs there figured it out; the diagnostics didn't.

> You know Mike? If he's the Mike Armstrong I knew - sysprog at the U of R
> around 1966 - he taught a course I took. I have him to hlm to blame for
> PL/I! There's a long time span between the 360/50 and the 3031 though.

Probably the same Mike Armstrong.

I knew him not at UOR (I've never been in Rochester) but through SHARE, the
user group of large academic and research IBM mainframe customers. After
leaving UOR Mike ran the IT operations at Ryder (and IIRC lost out in a
major RIF there) and made history at SHARE by being elected president on a
write-in ballot. I don't know where he is these days since my shop left
SHARE when it removed its IBM mainframes back in the mid-1990s.

Joe


Walter Banks

unread,
Apr 26, 2012, 7:51:28 AM4/26/12
to
Today we would do that in a instant. The intermediate file was not
documented and the time it would have taken to reverse engineer it
coupled with the fact that card punches didn't write the text on cards
the way a keypunch did sealed the deal, re-type.

The card reader story wasn't on a 1620 at the time (mid 60's) I was
using the IBM 1620 a lot and I was running some large fortran programs.
Most of the programs I was running took hours of execution time
on the 1620.

A professor friend had arranged for me to get time on another computer
with significantly more computing power. I was in the room when the
card splitting occurred, actually next in line. I was to be the last job
of the day so it could run over night. Now it might take a minute
on my Windows7 touchpad.

I never did run my program on that computer. I think it was an early
GE but can't remember. The card reader was a third party cardreader
bought because it would speed things up :)).

w..

Walter Banks

unread,
Apr 26, 2012, 8:03:30 AM4/26/12
to


Joe Morris wrote:

> "Walter Banks" <wal...@bytecraft.com> wrote:
>
> > Old computers were fun in their failure modes. IBM1620's would miss a flag
> > on a one of its variable length numbers and bang the lights would have a
> > familiar
> > pattern of a math operation never completing. Red button on the console
> > time.
>
> > The best (or worst) failure I have seen in that era was a two pass fortran
> > compiler that read in cards and stored the information on a mag tape
> > during
> > the first pass as n improvement from when the cards would need to be
> > read twice.
> >
> > The card reader had a grooved belt that picked the cards and held on to
> > them around a pulley through a reader station around a second pulley and
> > stacked them in a second tray.
>
> What card reader model was that? The only card device I ever saw attached
> to a 1620 was the 1622 reader/punch, which had the same basic design as the
> 1402: for both the reader and the punch cards feed from the bottom of the
> supply stack, but then are carried linearly across the first and second read
> brushes (read side; punch and verify brushes on the punch side) by rollers
> and eventually drop into one of three stackers[*]. That machine didn't have
> a feed that routed cards around a pulley.

THere we two stories the first was a run away 1620 and the second involved
a third party reader on I believe an early GE. I just posted a longer
explanation
in this thread.

Sorry to mislead you on the card reader story.

Ay the time I was working on a physic's thesis and had almost exclusive use
of a IBM1620 midnight to morning and some weekends. Some runs were
taking 20+ hours. I was also using several other computers some because I
had a professor who wanted to see the work done and some I was swapping
computer time for programming. If fast FFT's had been available at that time
it would not have taken nearly as long. (Where were you when I needed
you Morvin aka Morvin Gentleman of fast FFT fame)

It was a good experience, I rewrote a IBM1620 fortran compiler and libraries
to get more performance and fell in love with programming and optimization
which ultimately became my career.

w..

Walter Banks

unread,
Apr 26, 2012, 8:17:47 AM4/26/12
to


Rod Speed wrote:

> jmfbahciv <See....@aol.com> wrote
> > Ben Pfaff wrote
> >> jmfbahciv <See....@aol.com> wrote
> . . . .
> >> This was really a hardware fault rather than a software one?
> >> I've never run into anything similar in the machines I've used
> >> since 1985 or so. I'd be likely to laugh at anyone who claimed
> >> that his modern computer had such a hardware fault.
>
> > Very definitely hardware.
>
> But not seen much at all with modern systems for some reason.
>
> Presumably those who know why it happened with the
> 10 or 20 know why it doesn’t happen with modern systems.
>
> Not unusual with hardware faults, some approaches do have their
> characteristic failure modes that arent seen with other approaches.
>
> What happened with core is nothing like what happens with ram.

The internet made computing in a bad environment a science.
Recovery from failure modes was in its infancy with the Bell ESS-1
project. Reliably almost killed it and put it way behind schedule.
The internet had to continue to function through hardware failure
and flaky software and malicious users. In networked computers
the reliability equations simply had too many series terms. A couple
of the ESS-1 people were at the University of Waterloo when we
were working on developing and simulating the various network
protocols and they definitely influenced the outcome. One in
particular, Eric Manning was still smarting from the ESS scars in
the early 70's and the experience often came up in discussions there.

Walter..






Walter Bushell

unread,
Apr 26, 2012, 7:29:04 AM4/26/12
to
In article <jna6d...@news4.newsguy.com>,
Typically intermittent bugs are found by programmers and the
manufacture's diagnostics don't catch them

Walter Bushell

unread,
Apr 26, 2012, 7:32:46 AM4/26/12
to
In article <jna3ok$db4$1...@dont-email.me>,
Mayhap the hardware should have bounds checking on the stack?

jmfbahciv

unread,
Apr 26, 2012, 9:49:01 AM4/26/12
to
Sigh! I did say. It was a CPU hardware failure which bit
sprayed all of memory. That is why JMF and TW couldn't
retrieve my document from the crash file.

<snip>

/BAH

jmfbahciv

unread,
Apr 26, 2012, 9:48:54 AM4/26/12
to
That's a lonely sound :-).

>> >
>> > No I don't miss the old days of computing
>> >
>>
>> Couldn't a piece of software be written to de-tokenize the file on the
>> tape???
>
> Today we would do that in a instant. The intermediate file was not
> documented and the time it would have taken to reverse engineer it
> coupled with the fact that card punches didn't write the text on cards
> the way a keypunch did sealed the deal, re-type.
>
> The card reader story wasn't on a 1620 at the time (mid 60's) I was
> using the IBM 1620 a lot and I was running some large fortran programs.
> Most of the programs I was running took hours of execution time
> on the 1620.
>
> A professor friend had arranged for me to get time on another computer
> with significantly more computing power. I was in the room when the
> card splitting occurred, actually next in line. I was to be the last job
> of the day so it could run over night. Now it might take a minute
> on my Windows7 touchpad.
>
> I never did run my program on that computer. I think it was an early
> GE but can't remember. The card reader was a third party cardreader
> bought because it would speed things up :)).

I think we've all had lessons about slow but steady vs. "faster".

/BAH

jmfbahciv

unread,
Apr 26, 2012, 9:48:58 AM4/26/12
to
C'mon, Rod. If you have hardware or software which needs to be
tested and heavily used, just write a game which stresses
all the weak areas of the code.

Gamers get very noisy if the code doesn't work. They're great
w.r.t. finding workarounds and/or sniffing out where the fault
is happening.

/BAH

jmfbahciv

unread,
Apr 26, 2012, 9:48:55 AM4/26/12
to
Walter Bushell wrote:
> In article <PM0004BE8...@ac81673f.ipt.aol.com>,
> jmfbahciv <See....@aol.com> wrote:
>
>> Walter Bushell wrote:
>> > In article <jn6rjt$f94$1...@dont-email.me>,
>> > Peter Flass <Peter...@Yahoo.com> wrote:
>> >
>> >> P@rn was a big driver for the internet, and at one
>> >> point was the biggest user.
>> >
>> > And for the users machine it was gamez. Even today the gamers are the
>> > biggest consumers of high end graphic cards.
>> >
>> Those people do a valuable service w.r.t. testing.
>>
>> /BAH
>
> Not to mention financing.
>
Maybe. MS uses its games to test their distribution enhancements.
Games used to be "overhead". We didn't sell games but I sure wanted
to put the ones we had on the Customer Supported Tape. I was
always voted down.

/BAH

jmfbahciv

unread,
Apr 26, 2012, 9:48:50 AM4/26/12
to
I always got ?PDL overflow errors.

/BAH

Anne & Lynn Wheeler

unread,
Apr 26, 2012, 9:58:03 AM4/26/12
to
"Joe Morris" <j.c.m...@verizon.net> writes:
> At my PPOE we had a 3031 that for a short time after delivery had a no-cost
> extra feature: "Branch Maybe," aka an intermittent failure of one of the
> condition code latches. The diagnostics did eventually find this one,
> probably (I don't remember) via margin checking.

recent disucssion of 303x machines in comp.arch
http://www.garlic.com/~lynn/2012f.html#22 Indirect Bit

303x was Q&D effort to get stuff back into 370 product pipeline (after
Future System imploded) ... in parallel with 370-xa and 3081 ... which
was going to take much longer.

the 370/158 was horizontal microcode engine shared between running the
158 integrated channel microcode and the 370 emulation microcode.

for 303x machines, they took the 370/158 microcode engine with just the
integrated channel microcode (and no 370 microcode) to create the 303x
"channel director".

a 3031 was pair of 370/158 engines ... one was a 370/158 engines running
just the 370 emulation microcode and a second was the 303x channel
director (dedicated to running the 370/158 integrated channel
microcode).

misc. past posts mentioning future system effort (was going to
completely replace 360/370, during the FS activity 370 efforts were
being suspended and/or killed ... which is created with allowing the 370
clone processors to get market foothold).
http://www.garlic.com/~lynn/2012f.html#submain.html#futuresys

even tho 370-xa & 3081 took much longer to get out (being done
in parallel with 303x effort) ... it was a lot of warmed over
future system stuff ... some discussion here:
http://www.jfsowa.com/computer/memo125.htm

this has some old RAIN benchmarks for 158, 3031 & 4341 ... showing 3031
running (370) faster than 158 ... aka dedicated microcode engine
... instead of shared between 370 emulation and integrated channel
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?

--
virtualization experience starting Jan1968, online at home since Mar1970

Anne & Lynn Wheeler

unread,
Apr 26, 2012, 10:24:31 AM4/26/12
to
Peter Flass <Peter...@Yahoo.com> writes:
> The big driver for technology has been "entertainment" (for some
> values of "entertainment"). P@rn was a big driver for the internet,
> and at one point was the biggest user. I think the most popular app
> for the iPad is "angry birds." It wouldn't be my preferred direction,
> but mostly I'm happy to see the technology developed so the stuff I
> favor can get dragged along and we can run TOPS-10 and VM/370 on our
> laptops.

i've mentioned long ago & far away we were brought as consultants into
small client/server startup that wanted to do payment transactions on
their server; they also had invented this technology called "SSL" they
wanted to use; the result is now frequently called "electronic
commerce". recent reference in this (linkedin) "MainFrame Experts"
discussion regarding interconnection between parallel DBMS, electronic
commerce and supercomputers
http://www.garlic.com/~lynn/2012f.html#43 Time to competency for new software language?

over time we would visit some of the big electronic commerce
outsourcers/hosted ... they hosted the websites and provided the
electronic commerce services. One very large outsource pointed out that
their top ten websites were all P@rn ... and all ten websites had much
more hits per month than the #1 website in the public lists of largest
number hits per month (these guys were in it for the business not for
webby publicity ... which they didn't need).

the other point was that the game&software e-commerce websites had
better than ten times the fraud rates for P@rn (some snide comments
that P@rn customers are enormously more ethical than gaming&software
customers).

for other internet lore ... tcp/ip is the technology basis for the
modern internet, nsfnet backbone was the operation basis for the modern
internet and CIX was the business basis for the modern internet. misc.
past posts mentioning internet
http://www.garlic.com/~lynn/subnetwork.html#internet

and past posts mentioning NSFNET
http://www.garlic.com/~lynn/subnetwork.html#nsfnet

we had been working with various of the entities leading up to the
NSFNET backbone. when the NSFNET backbone RFP was released, internal
politics prevented us from bidding. the NSF director attempted to help
by writing a letter to the corporation (copying the CEO ... little
things like what we already had running was at least five years ahead of
all the RFP responses) ... but that just made the internal politics
worse
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

this old email reference
http://www.garlic.com/~lynn/2006w.html#email870109

is truncated ... but was a forwarded collection of large number of
internal emails from the communication group involving huge amount of
misinformation and FUD regarding potential of being able to use SNA/VTAM
for the NSFNET backbone ... in this post
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

this was in period when the communication group was spreading
misinformation about needing to also convert the internal network to
SNA/VTAM
http://www.garlic.com/~lynn/2006x.html#email870302
http://www.garlic.com/~lynn/2011.html#email870306
more discussion
http://www.garlic.com/~lynn/2011.html#4 Is email dead? What do you think?

but obviously if the internal network was to be converted to something,
it would have been much more efficient and cost/effective to have
converted the internal network to tcp/ip.

misc. past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

David Dyer-Bennet

unread,
Apr 26, 2012, 10:57:22 AM4/26/12
to
"Joe Morris" <j.c.m...@verizon.net> writes:

> [*] Yes, the 1402, 1622, and 2540 all had five stackers - but a card could
> go into only one of three. Two stackers were dedicated to the reader, two
> to the punch, and the center stacker could receive cards from either side.

I remember writing a program to make striped decks of cards. You put
blank cards of different colors in the reader and punch, and ran the
program (with a control card first in the reader), and it then stacked
you a deck in the common hopper (still blank; then you could use that as
the blank cards for a new object deck or a source copy or something you
wanted to really stand out).
--
David Dyer-Bennet, dd...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

Anne & Lynn Wheeler

unread,
Apr 26, 2012, 11:19:38 AM4/26/12
to
David Dyer-Bennet <dd...@dd-b.net> writes:
> I remember writing a program to make striped decks of cards. You put
> blank cards of different colors in the reader and punch, and ran the
> program (with a control card first in the reader), and it then stacked
> you a deck in the common hopper (still blank; then you could use that as
> the blank cards for a new object deck or a source copy or something you
> wanted to really stand out).

I had early undergraduate job doing part of univ. registration. lots of
tables in stadium ... line up for class you want, get a card and fill in
... sense cards produced punched cards and would be read in by 2540 and
feed to central stacker (shared by both reader and punch), registration
was validated ... if there was some problem ... would then punch a blank
card behind it. All the registration cards were uncolored (plain manila
card stock). Cards in the punch had colored stripe across the top.

when all the cards were back in large number of card trays ... the
problem registration cards could be identified by the colored card
immediately behind them in the tray.

David Dyer-Bennet

unread,
Apr 26, 2012, 1:06:54 PM4/26/12
to
We used a slightly different scheme; no sense cards, no filling in.
Student picked up their own card, and then picked up cards for each
course, and then turned in the bundle. Everything pre-punched, so
(short of attempts to cheat, or damage), very low error rate when
reading them in. This also conveniently enforced the limit on
registration for each course (the number of cards pre-punched for it).

(Much smaller school, but I guess it *was* done in the old gymnasium.)

They changed this while I was still there to an online scheme where you
had to visit the window at the registrar during the registration period
(and it lasted several weeks instead of all being over in a day). To
avoid lines, they gave people earliest start times. And suddenly it was
no longer possible to get up early to help your odds on that one class
you really really needed. On the other hand, it was no longer necessary
to get up early just to be on the safe side.

I wonder how they do it now? I should ask somebody. I'd kind of
imagine using an intranet site.

Rod Speed

unread,
Apr 26, 2012, 2:33:38 PM4/26/12
to
jmfbahciv <See....@aol.com> wrote
> Rod Speed wrote
>> jmfbahciv <See....@aol.com> wrote
>>> Walter Bushell wrote
>>>> Peter Flass <Peter...@Yahoo.com> wrote

>>>>> P@rn was a big driver for the internet,

>> That’s always been a myth.

>>>>> and at one point was the biggest user.

>> Don’t believe it ever was.

>>>> And for the users machine it was gamez. Even today the
>>>> gamers are the biggest consumers of high end graphic cards.

>>> Those people do a valuable service w.r.t. testing.

>> That’s very arguable indeed with high performance graphics
>> systems that don’t in fact get used by anyone else much,

>> That area has now diverged significantly, whats best
>> for gaming isnt actually much use for anything else.
>> Similarly with the other high end graphics systems.

> C'mon, Rod. If you have hardware or software which
> needs to be tested and heavily used, just write a game
> which stresses all the weak areas of the code.

No one actually does that anymore for various reasons.

The reality of the modern games market is that games
have moved on to be an end in themselves now, they
arent done to wring out the hardware for testing any more.

> Gamers get very noisy if the code doesn't work.

Yes, but that isnt used for testing hardware anymore.

> They're great w.r.t. finding workarounds and/or
> sniffing out where the fault is happening.

Yes, but that’s at the game software level now.

We don’t even see Linux used for the high performance
games, those into games normally have a Win system
for the games and/or some games consoles.

They world has moved on a hell of a long way on that stuff now.


Rod Speed

unread,
Apr 26, 2012, 2:38:59 PM4/26/12
to
jmfbahciv <See....@aol.com> wrote
No you didn’t at that level.

> It was a CPU hardware failure which bit sprayed all of memory.

Yes, but WHY isnt that seen with any other cpu much at all ?

> That is why JMF and TW couldn't retrieve
> my document from the crash file.

Sure, but that still doesn’t explain why it was seen
on the 10 and 20 and nowhere else much at all.

Was it seen on both the 10 and the 20 ?

Rich Alderson

unread,
Apr 26, 2012, 3:21:53 PM4/26/12
to
That's because the PDP-10 architecture *does* do hardware checking on the stack
bounds. Both ends--stack underflow errors are also possible if the stack is
popped too many times.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

Rich Alderson

unread,
Apr 26, 2012, 3:34:21 PM4/26/12
to
"Rod Speed" <rod.sp...@gmail.com> writes:

> jmfbahciv <See....@aol.com> wrote
>> Ben Pfaff wrote
>>> jmfbahciv <See....@aol.com> wrote
>>>> Ben Pfaff wrote
>>>>> jmfbahciv <See....@aol.com> wrote

>>>>>> Unless the CPU developed a bit sprayer.

>>>>> What's a "bit sprayer"?

>>>> Once in a great, thankfully, while, a CPU could go berserk
>>>> and write bits all over memory. Sometimes, the system
>>>> would crash before all of memory was sprayed. In my case,
>>>> the CPU was throrough before the OS detected a problem.

>>> This was really a hardware fault rather than a software one?
>>> I've never run into anything similar in the machines I've used
>>> since 1985 or so. I'd be likely to laugh at anyone who claimed
>>> that his modern computer had such a hardware fault.

>> Very definitely hardware.

> But not seen much at all with modern systems for some reason.

> Presumably those who know why it happened with the
> 10 or 20 know why it doesn't happen with modern systems.

This is not a failure mode which I have ever encountered in 35 years of using
PDP-10 systems, but then, it may well have had to do with some weakness of core
memory vs. semiconductor. That said, I've never even *heard* of this fialure
mode until this thread, so it wasn't common even on core-based systems (and I
have friends in the PDP-10 community whose experience extends back before
Barb's).

Rod Speed

unread,
Apr 26, 2012, 7:02:44 PM4/26/12
to
Rich Alderson <ne...@alderson.users.panix.com> wrote
> Rod Speed <rod.sp...@gmail.com> wrote
Then maybe it was just a design problem and
they fixed the design so it couldn’t happen again.

Freddy1X

unread,
Apr 26, 2012, 6:59:03 PM4/26/12
to
Ben Pfaff wrote:

> jmfbahciv <See....@aol.com> writes:
>
>> Unless the CPU developed a bit sprayer.
>
> What's a "bit sprayer"?

There was a computer game proposed in the late 70's I believe, that involved
2 competing programs in a memory space trying to eliminate each other.
This might have been published in Byte magazine.

The two programs would be placed randomely in a memory array not knowing
where the opponent was. The programs executed "program" bytes and could
read or write "program" or "data" bytes to anywhere it chooses in the
memory space. To win, one program has to cause the other one to attempt to
execute a data byte which is illegal and crashes, and thus that one loses.

Several strategies were detailed. A program could randomly drop
data "bombs" in memory not part of it's program in the hopes of scoring a
hit on the other program. A program could just plod along sequentially
writing data hoping to get the other. You could also read random places in
order to discover where the other program resides, and then attack
directly. A program could setup detection barriers to monitor for the
approach of the enemy and take action. It is also possible to "run away"
by relocating to different memory.

Many common program features are supported such as branching and
subroutines. However, I think that the simple "one for me, one for you"
execution of turns favored the simplest and fastest programs, with one
named "Imp" being the best performer. Imp was a very small loop writing
data bytes ahead of itself as it copied itself foreward and moved quickly
through memory. It could overrun the other before a "heavier" program
could react.

Freddy,
going into battle.

--
Approved by state board of accounts 1996.



/|>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\|

/| I may be demented \|

/| but I'm not crazy! \|

/|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<\|

* SPAyM trap: there is no X in my address *


Joe Morris

unread,
Apr 26, 2012, 8:46:28 PM4/26/12
to
"Walter Banks" <wal...@bytecraft.com> wrote:

> Ay the time I was working on a physic's thesis

Um...was the food in the dorm cafeteria that bad that you had to write a
thesis about the medicine you needed after a meal? <gd&r>

(Of course, *I* have never made tyops like that...)

Joe


Patrick Scheible

unread,
Apr 26, 2012, 7:47:20 PM4/26/12
to
The University of Washington went from scanned sheets to touch-tone
phone to website. In all systems, it's necessary to get up early to
have the best choice of classes.

-- Patrick

Michael N. LeVine

unread,
Apr 27, 2012, 4:45:49 AM4/27/12
to
In article <0NCdnW6OT_OjfQTS...@earthlink.com>,
Core wars see
http://en.wikipedia.org/wiki/Core_War
http://www.corewars.org/
--
Michael LeVine - mle...@redshift.com
"Witnessing the Republicans and the Democrats bicker
over the U.S. Debt is like watching two drunks argue
over a bar bill on the Titanic."

Peter Flass

unread,
Apr 27, 2012, 7:36:59 AM4/27/12
to
For all I know SHARE might have an "associate membership," but if they
don't they should, for those of us who no longer have mainframes but
whose hearts are still there.

--
Pete

Peter Flass

unread,
Apr 27, 2012, 7:38:51 AM4/27/12
to
Maybe people who worked for hardware vendors were more used to these
kind of problems, but I got "don't blame the hardware" beaten into me
early, and I'd probably spend many long days looking for bugs in my code
before even considering it.

--
Pete

Peter Flass

unread,
Apr 27, 2012, 7:43:48 AM4/27/12
to
Not an easy thing to do. If you go over the top of the stack segment
you'll trap, but if you overwrite the previous frame you won't. A
different architecture could do this with, for example, an instruction
that allocates the frame and sets the equivalent of "EBP" and a limit
register. In this case you're not trying to protect one user from
another but protect a user from him/herself. Sure would be nice.

I expect that Burroughs Large Systems Architecture (B5500, etc) would
have done this.

--
Pete

Peter Flass

unread,
Apr 27, 2012, 7:49:15 AM4/27/12
to
On 4/26/2012 10:57 AM, David Dyer-Bennet wrote:
> "Joe Morris"<j.c.m...@verizon.net> writes:
>
>> [*] Yes, the 1402, 1622, and 2540 all had five stackers - but a card could
>> go into only one of three. Two stackers were dedicated to the reader, two
>> to the punch, and the center stacker could receive cards from either side.
>
> I remember writing a program to make striped decks of cards. You put
> blank cards of different colors in the reader and punch, and ran the
> program (with a control card first in the reader), and it then stacked
> you a deck in the common hopper (still blank; then you could use that as
> the blank cards for a new object deck or a source copy or something you
> wanted to really stand out).

A little too much spare time, maybe? ;-)

--
Pete

Harry Vaderchi

unread,
Apr 27, 2012, 7:55:45 AM4/27/12
to
Still going (just)
rec.games.corewar


--
[dash dash space newline 4line sig]

Albi CNU

Walter Bushell

unread,
Apr 27, 2012, 8:47:40 AM4/27/12
to
In article <jne0d5$nb4$3...@dont-email.me>,
Peter Flass <Peter...@Yahoo.com> wrote:

> Maybe people who worked for hardware vendors were more used to these
> kind of problems, but I got "don't blame the hardware" beaten into me
> early, and I'd probably spend many long days looking for bugs in my code
> before even considering it.

Yea, verily yea. But it does happen. One for NASA was on a 16 bit
computer that one in a million times would drop the high order bit
when loading the accumulator. We sent our lead guy to Bolivia up in
the hills and he finally found the problem.

It even happened to me directly, but fortunately the machine stopped
and lit the parity error light. Otherwise who is going to believe,
unless one goes through long and weary dances. If the program runs
sometimes and not others with the same data, it's a Heisenbug. For
example on machines that don't clear memory, caused by Jai Random
Contents of some memory location.

jmfbahciv

unread,
Apr 27, 2012, 9:23:34 AM4/27/12
to
I had the same thought :-))). But colors and coloring was useful
when handling cards.

/BAH

jmfbahciv

unread,
Apr 27, 2012, 9:23:38 AM4/27/12
to
It wasn't a software problem. It was a hardware problem with
that particular KI.

/BAH

jmfbahciv

unread,
Apr 27, 2012, 9:23:37 AM4/27/12
to
No. Once again it was a hardware glitch in the KI. It
got fixed.

/BAH

jmfbahciv

unread,
Apr 27, 2012, 9:23:40 AM4/27/12
to
So why don't all architectures use that feature?

/BAH

>

jmfbahciv

unread,
Apr 27, 2012, 9:23:44 AM4/27/12
to
Could you juryrig a trap using a page fault (or has that hardware
feature gone away, too?).

/BAH
It is loading more messages.
0 new messages