• Please review our updated Terms and Rules here

is it sacrilege to replace the internal 5 1/4" drive on an 1000 ex with a 3 1/2" one?

Programming with punch cards must have driven people insane after a decade.

Well my dad is still pretty sane and he used them way too often i think.

Or at least i think that people looking at a punch card and telling you what the code on it does without even having a computer nearby might have used them too often.

Then again maybe that's a very special kind of insanity.
 
The FORTAN punch cards I am familiar with had text printed on top which matched the line of text the card was punched for. Leafing through box of punch cards is just like reading the program line by line.

I absolutely hated paper tape. Anything longer than the shortest of programs tended to tear when inserted into the reader. The roll of tape didn't have good warnings when it neared the end. Programs being saved were punched into empty air. The punching process took so long that users would be logged off preventing a second try.
 
Just look at me--I'm sort of sane, sometimes.

What many people don't understand is how slow the old machines were--how would you like a "successful" day where you could get perhaps 2 or 3 compilations performed--and that includes tossing out your job because of a syntax error during compilation? Here's the typical workflow looked like after you'd gotten your first cuppa after the 9 AM status meeting:

1. Using your coding forms, write (block print) your next bit of program code, being careful that "oh", "zero", "i" and "1" are distinct and in the proper columns. You usually did this from a handwritten version on plain paper that you'd worked out, probably from your scribbles on a chalkboard.

2. Read what you've written a few times to pick up any obvious errors, then submit the stack of paper (remember to number the pages) to the keypunch pool.

3. The keypunch ladies (almost always female) read and punch your cards (it's useful if you tell them that a FORTRAN keypunch drum card can be used). Then they take your card deck and repeat the process on a verifier, where what they key in is compared with what's actually been punched. Errors are corrected.

4. Your punched deck, along with the coding forms, are delivered to your desk a few hours later. If you're smart, you take the deck to the room with the unit record equipment (sorters, reproducing punches, interpreters--and most importantly, the accounting machine) and get an "80-80" listing to take back to your desk which you carefully read one more time. If you need to make a correction, a few keypunches are scattered around--with 10 minute timers.

5. You take the punched cards, combine them with any other parts of the program you've previously done (sometimes you could archive your older work on mag tape, so maybe your deck was composed of modifications or additions to the stuff on tape. At any rate, you take the cards, any tapes and a job card that identifies you and your job for accounting purposes to the I/O window and turn it all over to the clerk for running. If you were smart, you punched and interpreted a duplicate deck while you were getting your 80-80 listing, in case some operator dropped your deck or the card reader ate it. By the way, "deck" could be several trays 4-5000 cards) on an I/O cart. Raised floors were wonderful in that one of the filler strips between tiles could come undone and trip up you and your cart....

6. Go back to your desk; contemplate your next step and wait for your job output.

7. Someone comes by about once an hour with a cart piled with not only your input, but your job output. Notice that your compilation/assembly failed because of an undefined symbol. Start all over again.

You develop certain thought and coding habits because of this process. Not all bad, IMOHO.

FWIW, if you were in maintenance, you could spend a few days staring a memory dumps, noting various things on them with a No. 2 pencil before you wrote even one line of code. Program listings could be checked out of a "library" of listings. No CRTs here, sorry.
 
I love my vintage computers, and the challenges that come with them, but I also like to cyborg them as well so to speak, so yes, I would like to add a FreHD to my kaypro for fun, and yes it would be cool to add A gotech to my 1000 ex or sl. ( is there a thread or a link with the work being done for their use as 360k floppy drives, I would love to test, I have one I bought that has not had its original firmware altered yet, it would be cool to put it in the 1000 ex at some point. Perhaps as an external!)

Any updates on that Gotek firmware would be cool. :0)

Cheers folks!
 
Just look at me--I'm sort of sane, sometimes.

What many people don't understand is how slow the old machines were--how would you like a "successful" day where you could get perhaps 2 or 3 compilations performed--and that includes tossing out your job because of a syntax error during compilation? Here's the typical workflow looked like after you'd gotten your first cuppa after the 9 AM status meeting:

1. Using your coding forms, write (block print) your next bit of program code, being careful that "oh", "zero", "i" and "1" are distinct and in the proper columns. You usually did this from a handwritten version on plain paper that you'd worked out, probably from your scribbles on a chalkboard.

2. Read what you've written a few times to pick up any obvious errors, then submit the stack of paper (remember to number the pages) to the keypunch pool.

3. The keypunch ladies (almost always female) read and punch your cards (it's useful if you tell them that a FORTRAN keypunch drum card can be used). Then they take your card deck and repeat the process on a verifier, where what they key in is compared with what's actually been punched. Errors are corrected.

4. Your punched deck, along with the coding forms, are delivered to your desk a few hours later. If you're smart, you take the deck to the room with the unit record equipment (sorters, reproducing punches, interpreters--and most importantly, the accounting machine) and get an "80-80" listing to take back to your desk which you carefully read one more time. If you need to make a correction, a few keypunches are scattered around--with 10 minute timers.

5. You take the punched cards, combine them with any other parts of the program you've previously done (sometimes you could archive your older work on mag tape, so maybe your deck was composed of modifications or additions to the stuff on tape. At any rate, you take the cards, any tapes and a job card that identifies you and your job for accounting purposes to the I/O window and turn it all over to the clerk for running. If you were smart, you punched and interpreted a duplicate deck while you were getting your 80-80 listing, in case some operator dropped your deck or the card reader ate it. By the way, "deck" could be several trays 4-5000 cards) on an I/O cart. Raised floors were wonderful in that one of the filler strips between tiles could come undone and trip up you and your cart....

6. Go back to your desk; contemplate your next step and wait for your job output.

7. Someone comes by about once an hour with a cart piled with not only your input, but your job output. Notice that your compilation/assembly failed because of an undefined symbol. Start all over again.

You develop certain thought and coding habits because of this process. Not all bad, IMOHO.

FWIW, if you were in maintenance, you could spend a few days staring a memory dumps, noting various things on them with a No. 2 pencil before you wrote even one line of code. Program listings could be checked out of a "library" of listings. No CRTs here, sorry.

Wow, thanks for the vivid description of software dev back in the day. I guess a Model II would have been the stuff of science fiction at that point. And now a Model II is a vintage museum piece. What a perspective!
 
Back
Top