Rare Apple I computer sells for $216,000 in London

Having seen the insides of a 33 I'm not surprised.

There was more electronics and less mechanical wizardry in the card punches I knew (029s).

That probably bollixed up the mechanical ASCII encoder/keyboard mechanism, I would hate to try and fix that, I was always amazed that they got it to work at all let alone in mass production.

I doubt it from what I've seen of the innards of them, but I've never tried it.

Yup. We had a large production program that I'd patch until the whole thing fell apart - only then would I try to wheedle the 40 minutes of machine time that it took to re-assemble it.

I finally wrote my own assembler. Although it had a number of very nice features that were missing from the stock assembler, its primary goal (which I achieved) was to run twice as fast. It was a bit easier to scrounge 20 minutes of machine time than 40.

That one's a keeper, Barb.

-- /~\ snipped-for-privacy@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!

s/right/rite/

On second thought, given the modern culture of entitlement, perhaps you're right after all...

"Those who cannot remember the past are doomed to repeat it." -- George Santayana

And if there was too much data to fit on a single card, you suffered the nightmare of needing multiple physical records to hold a single logical record. Awareness of this has a good influence on data design.

You could always explain it as a form of data corruption, right down to the level of a spindle hole flipping a single bit.

Maybe you can type that fast, but I can't. And, I don't know anybody who can. Several hundred pages of 1411 listings, mostly full.

The program is already developed, and the output is pretty good, so far. It's just that it is S L O W.

No, I think not, as I don't have one, and I figured it out.

jmfbahciv wrote

There wasnt any question that wasnt just puerile silly stuff.

Guess again.

And you clearly never did maintenance on them yourself.

Pity about the cost of them and the cost of that maintenance.

With a decent collection of punches, there was always one or two with a problem.

Not surprising given that they were entirely electromechanical devices, no electronics at all.

difficult to fix.

Pigs arse I ever did.

Never said they were, just quite expensive to maintain because they werent that reliable.

Much more expensive to maintain than what replaced them.

jmfbahciv wrote

write on.

pockets.

numbering.

paper.

It didnt even happen. And I know because I worked there.

Nope. There might have been one loon or two that went that route but I doubt even that.

re:

I had the machine time ... since I got 48hrs straight every weekend ... it was that it was usually faster to patch it than re-assemble.

I had conditional assembly ... one that ran stand-alone ... with its own device drivers, interrupt handlers, etc that assembled in approx. 30 mins ... and the one that ran under os/360 using open/close, read/write and DCB macros that assembled in approx. an hour (on 360/30) ... the DCB macros taking 5-6 mins elapsed time each ... it was possible to see it in the front panel lights when it had hit a DCB macro.

the folklore was that the person doing opcode lookup assembler routine had been told that it had to be done in 256 bytes (or some such) ... so the lookup table was reloaded from disk on each statement. the assembler got much faster when somebody improved opcode lookup (using the memory to keep the table loaded).

Since I often work in embedded systems, some with very limited memory, this has come back to me fairly often. Instead of making records big enough to handle the worst case, I can make them big enough to handle the common case, saving a lot of memory, then usually with a single bit indicate "look to next record for more of this record's data" or other tricks to that effect. Using extra space only when actually necessary.

I don't recall that I ever needed to into that, but yes, that would work.

- Bill

some interest in the 64, a basic internet connection has been operated off one. They are easily set up as controllers for displays. (Amateur versions of traffic displays).

Or you made each input record self-contained. We did that with our USAGE data spec (computer usage data for downstream billing programs).

It hadn't occurred to me (before Bill's post) that cards helped concepts of the unseen bits...but they did.

/BAH

Curious (20 min vs 40 min). Could make a guess of how many minutes were the threshold? 30 mins?

/BAH

problem.

electronics at all.

difficult to fix.

that reliable.

Keypunches were very reliable unless you abused them extremely.

/BAH

thanks. I couldn't believe my fingers created that one.

/BAH

jmfbahciv wrote

problem.

electronics at all.

difficult to fix.

that reliable.

Like I said, with a decent collection of punches, there was always one or two with a problem.

And the cost of having them on maintenance contract was substantial.

Perhaps I was wearing my "Freudian slip"... ;-)

What did you do, replace their sequential search of the symbol table with a hash or an AVL tree???

write on.

pockets.

numbering.

paper.

"Computer scientists" used to output all

Hmm I don't remember anybody called rod speed at DCR, so how would you know?

cardpunch itself was a bastard to maintain,

which turned out to be that the

cards as they were fed into the punching

was a non replaceable part. So I got the

punch was obsolete) or do without. There

punched another card again which made it

of time and money.

I was at ABS from '73 to '76 and from '80 to '86. ANU, in my experience were pretty anti-IBM, the academics preferred Univac.