@ziggurat29 has been spending much of his spare time this past week+ coding at the lowest-level for a machine he's never even seen, except in photos.

I had a moment a while-back feeling it a bit like the olden days I've caught-wind of recently from the datasheets of old mask-ROM microcontrollers I've found in my PCB-scrap-bin. I came across at least one that supplied an empty table, in the back pages, that purchasers could fill with the raw hex values of their program, then mail to the manufacturer to do the actual ROM-writing. Heh, sneakernet, eat your heart out. We don't need to deal with the multitude of different floppy formats you might send-in! And, No. We can't supply you with an assembler to run at your own workplace, but if you'd like to dial-in to time-share on our central computer for a fee only huge corporations could afford, you can use the assembler we use here. They've got that, but, no mention of uploading ROM images. And, again, an empty table on several pages of paper.

Heh. What an era.

Alright, well, he's not looking up raw hex values... But still... "write it out, send it in."

For a minute there I also thought it a bit like NASA uploading new firmware to a probe, in order to overcome whatever weird new situation it faces... But then I realized, heck, I bet even in that extremely "out there" situation, NASA's programmers almost certainly have a duplicate in a lab that they can debug on.

A couple days after my thinking this, he suggested pretty much the same idea:

Comparing it to e.g. the way-back when a university might have a single computer, and the research-professors would send their stacks of punchcards to be processed. Their having to write the entire program, with no debugger and no step-by-step testing. Then waiting, possibly a few days, while a queue of others' code was executed, before hearing the result... And, then, possibly finding out they forgot to punch a hole. Heh! Or the instruction-set documentation *seemed* crystal-clear, while in-fact being ambiguous... Or who knows what all.

...

Anyhow, it's quite something.

In the times when I await the next stack of punch-cards, I'm running-around trying to maintain the central systems, over here... 

E.G. The "punch card reader" (my beloved 486 laptop and my also-beloved parallel-port chip-programmer) is in sore need of a recalibration or two. Also, there's word in the industry of an upgrade that might remove a step or two... (Did you know FAT32 didn't come out until Win95 OSR2? And apparently Android doesn't do FAT16, heh! Yeah, this whole thing can run off a Win98 boot floppy, but then I need PCMCIA support in DOS, which I've never done... So... choices, choices...).

Anyhow, Central Systems also offers its remote clients limited debugging-support; Our maintenance/operations-tech has become somewhat-familiar with The Central Computer's Instruction-Set, and can spot a few common mistakes, increasing deugging turnaround-times from days to, well... days. Heh! 

("increasing" "de-ugging"... hah! If Freud were here...!)

...

The cat says it's time for bed.

Anyhow, in short, we've got quite a few of the peripherals going... Turn it on at the stroke of midnight and you've got a clock in a rackmount! (Actually, maybe it's more of an instrument-case?) 

And the "DART" (back then they hadn't yet standardised on "UART") is coming "soon" (where'd that operations-tech run off to, anyhow?), so we can attach a terminal!

Discussion for the future has gone as far as developing a C-Runtime Library and porting BASIC. And the system has been likened to "Heck yeah! Who doesn't want a rackmount TRS-80 in their garage?!"

...

The deeper we get into the system itself, well... I joked the other day along the lines of:

"A physicist, a chemist, and an electrical engineer walk into a bar... OK, so what *really* happened was the EE walked into the bar while looking at his calculator. The physicist and chemist, well, they saw it coming and thought it'd be funny to watch, not realizing they'd have to take-on the EE's duties while he was in the hospital during the month before their deadline."

Yeah, I'd say "it's that bad" (almost as bad as that joke's delivery/punchline). But, it's actually quite interesting, from my end, to see how *well* it works, despite its implementation: "Good practices" that, frankly, I had never tried (nor had seen) a system like this go without. Maybe their importance is greatly-exaggerated in my field?

I might do another post on those details, later.

But, with every new "stack of punchcards," I have to remind myself of many previously-observed factors. Like: that big Reset button on the front has been necessary, on many occasions dating back to its unboxing, for a proper boot after power-up. Or that my logic-probe picks up beep-inducing electromagnetic radiation before even touching pins. (Never did *that* before!)

That I discovered, actually, when I sat it on the laptop keyboard, which was not only powered-off, but also switched-off at the power-strip feeding its isolated power-brick. WOW, it radiates measurably by a *logic* probe, nearly six inches away! I'm near certain that's due to my "Modified Sine" inverter... which is little more than a fancy way of saying a square-wave that goes positive and negative. Pretty sure most things don't really like that... those high harmonics, and likely overshoot and ringing at the edges. My oscilloscope absolutely hates it:

[Forgot to mention in the vid, the probes are shorted to the scope's GND!]

So, debugging involves a bit more than merely checking whether it does what was intended in the "punchcards." 

But we've come a long way despite the hurdles!

[Hey, Tech, quit yer yappin' and get back to debuggin'!]