[vcf-midatlantic] assembler is tedious (was WooHoo!) (Jeffrey Jonas)
hjohnson at retrotechnology.info
Thu Aug 3 11:31:29 EDT 2017
There's some irony in discussing the tedium of assembly language
programming, by using (excuse me) the tedium of emails as a learning and
describing tool. It's my bias, but the hardest way to learn something,
is by having several people explain it, post streams of details, argue
amongst each other in the process, get sidetracked, etc. I understand,
that's the 21st century way; no insult, it's just not my 20th century
way (or my textbook way, I was formally educated in computing).
Look. The vintage basis for assembly-language programming, included the
limited resources available to microprocessor owners in the 1970's.
Hand-assembly and front panels, limited memory, limited I/O, limited
storage. Limited access to prior source-code. The other limitation was
the owner him/herself: programming was likely a mystery, at least
programming that particular processor, and later in time the mystery of
whatever "system" architecture in use.
Results matter. Those owners learned, became computing experts, who
became employed in the personal-computer boom to come.
So - that old-school way, mattered then; and matters now as a matter of
historic preservation. So why preserve it? To remember the lessons of
the 20th century past: a past of limited resources, versus the 21st
century experiences of ABUNDANT, STANDARDIZED computing.
And so, calling assembly language programming "tedious" misses these
points, imposes those 21st century assumptions on 20th century tech.
This is not some old man's problem with the future. My vintage Web site,
attracts people who ask me "I wanna start with some vintage computing;
where do I learn, how to program and repair these things?" I'm stumped -
modern resources have mostly given up "assembly language" and "TTL
logic" or even "read this schematic"!
If the above is too "tedious", if you are messing with vintage computers
"for fun", and don't care about historic perspective, that's fine. But
you have a choice. Try to sledge-hammer C code (or some
language-of-the-year) from a cross-compiler into an Apple II, and trip
over all the I/O it needs to "know"? Or, work within the Apple II's
BASIC, Sweet-16, and assembly-language calls (documented long ago) - in
assembler (readily accessible) - and get something DONE? And learn
If you are worried about looking trivial - buy a Raspberry Pi and
*guarantee* your results are trivial, just in a larger social group.
Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT retrotechnology DOT info
More information about the vcf-midatlantic