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 something "old"? If you are worried about looking trivial - buy a Raspberry Pi and *guarantee* your results are trivial, just in a larger social group. Harumph, Herb Johnson -- 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