Old Computers
17 messages in this thread
Hey,
where I work (Nassau County BOCES) we still use Card readers. We
employ full-time key-punch operators. They use this archaic input
IBMs that run payroll for Nassau County. That's what our education system
is using. Do I get any points or do I gather negitive points.
djw
Go directly to Jail. Do not pass GO, do not collect $200. Actually, it is
my belief that EVERY programmer should start out for the first 6 months on
punch cards with a system that has 2 hour turn-around for runs. You can
learn a lot about debugging by intuition when you have have to work in that
environment. You spend a lot more time *DESIGNING* and *CHECKING* your code
before you even bother to submit it, and many times will find and fix bugs
*BEFORE* you even get the results. I have seen too many people who debug
programs into existance.
John,
I dunno. I can take a well-written, bug-free code and modify it into a
roach-motel with a few carefully thought out keystrokes, and still get paid
for doing it.
Guess I'm just naturally talented. 8)
Anarchy Now! (But only if the bennies are good)
Doug
p.s. Can I have your leftovers when you get done writing?
Actually, I am quite proud that most of my programs go through little
structural changes- I have one that is about 8 years old now, has been ported
to well over 30 different machines and there are whole source files that have
never been touched. This is even after ownership of the code has passed
through 3 different people to handle it. Now off by one errors are a
different story… but in the end they balance out.
John,
That IS something to be proud of. I'm pretty handy with figuring the
proper method to whack at it with but the details somehow never seem to
gel. I'll get something that runs- provided I'm the one using it, as I
know where the wobbly bits are. Changing one thing one place seems to
break half a dozen things elsewhere.
Now, off-by-one never happens to me. Unlike most, I think of Zero as a
Whole number, and offsets strike me as a natural method. Probably because
my thought processes operate through association and are normally indirect.
8)
You CAN Get There From Here,
But It Means A Detour through A Toll Road,
Doug
Part of the approach to the problem is to do it in layers. I have a good
ability to break down a problem into individual pieces and then isolate the
work associated with each piece. Once you have done that, it is a matter of
writing each piece independenty. Magically, you end up with a program that
doesn't have to be modified in multiple places.
John,
I normally have canned routines (previously written stuff that either I
or someone else sweated over once) and have few problems when I use them. I
just make sure the blocks aren't going to fall over when I stack 'em.
The problems arise when I decide it's time to write something 'tight' and
without a lot of frills that get wasted and cause overweight executable.
Some people can remember the necessary arguments and their order for
BlitBitMapRastPort() as well as the necessary #define values, etc. I
can't. (Heck, I have problems recalling the switches for printf() 8) I
struggle with it once to make it a general routine then promptly forget the
details and go on with other things. So, when I do go back to tighten
things up a bit, I wind up with another learning curve bashing me in the
forehead.
In fact, I'm in the process of editing my old stuff to take advantage of
2.0. It's slow going as I'm both learning 2.0 and waiting for (FINALLY!)
the compiler upgrade. Now, if they'd just release the RKM; Libraries…
"GUI: something (usually) sugar coated that causes tooth decay and weight
gain, is half-melted and soft, but tastes irresistable."
Well, part of the solution to the problem is in defining the level of support
necessary at each part of the picture. When I design an I/O subsystem, I
note what it needs to do (block/record I/O, streams/random, buffering,…).
Initially, you can start with the full fledged building block, but for the
final product you have to have a real good idea of what the system provides.
Hmm… and here I thought programming was debugging the nULL program until
it did what you want!
-larry
No, you start with random bits in memory and work your way up to a set of
requirements. True bottom up programming.
Bill Roberts in Ellettsville In. via Whap!
John,
If you want to learn debugging by intuition, work on an embedded system for
a while where the ONLY tools available are the assembler, compiler and
linker (at least until you get the box up enough to get a monitor running).
No I/O system, no emulator, no logic analyser (always had a scope though).
Just think a LOT, write a little and go directly to EPROM. (BTW, you also
don't know if the hardware works right yet ;^)
It's LOADS of fun! I've done it at least twice.
Peter
Yes I know what you mean. I had an energy management system on the IBM
Series/1 which I had to do a lot of debugging on. Not only did I have to
worry about the main system, but there were dozens of SBC's I was talking to
that I had to deal with. You certainly learn to carefully consider a lot of
situations.
I did something more elaborate than that for 7 years as a Z80
assembly language programmer 7 years ago. Once I was told to fix a
broken wire with a software code change over my protests that it was
broken. I got a technician to ohm out the line for me and fix it.
(There was this running battle between the software group and the
hardware group! We also served crow regularly! 🙂 )
We did have a Mostek AID-80F development system with an ICE
(In-Circuit Emulator). The clock had to come from the embedded
system when emulating.
The development system had constantly running 8-inch floppy diskette
drives. Printouts were done on a Centronics 201 printer.
I had (and still have) the advantage of being able to show the hardware
people where the problems were instead of arguing over the fault being
hardware or software, since I started out as a tech (and still manage to
keep my secret cache of tools available for use when the hardware guys
aren't looking ;^).
Peter,
Unfortunately, I only had my logic without Mr. Spock's formiable
reputation. To this day there is probably still a delay loop in the
powerup code because the hardware must be given time to initialize.
Somebody missed the fact that the Z80 chip is hardware and won't run the
software if it isn't initialized or whatever, i.e., getting to the software
delay loop means that the hardware is already doing fine. (Of course,
that's not to say that I was always the person with the truest vision. It
was the hardware engineer that talked the customer into a Z80 chip instead
of an 8080 chip as originally spec'd. Whew! Sometimes we did 'sing from
the same music!')
Oh well, sometimes the program is written to indulge the customer's
and/or the boss's pet conceptions/myths/whatever.
Sincerely,
(Mr.) Gayle Lee Fairless
'Perfessor Fearless' from the Rocket City!
– via Whap!
2 hour turnaround would have been great when I was learning to program at
Penn State. Usually 4-6 hours was normal (ah, those nights sitting around
the computer center, waiting). At the end of the semester, 24 hours was
not unusual, and 36 on occasion. This is on a Wendsday, and the project is
due Friday (why didn't I start when it was assigned, four weeks ago?)
Bill Roberts in Ellettsville In. via Whap!
Well, it got like that for us too. I was just being kind.