My program was bordering on 200 lines, painstakingly entered by thumbs twiddling meta keys mistakenly at many wrong times, backspacing, re-entering....
Built me some of my first libraries, a hex-printer... but, yahknow, didn't back-up during my roll, and now it's all gone.
I did get one thing tested, though... wrote 0xff to port 5 and 6, and read them back, as well. So... technically, reading back a register means two things, A) there's a register there, and B) it was designed /to/ be read-back. That means those ports actually have registers on the otherwise allegedly "unused" bits... so, why would they do that if they don't go anywhere? Could've been laziness, slapping a "block" down in some ASIC CAD program... but this chip is pretty old, did they even have such programs back then? And, otherwise, it'd've been cheaper not to go that route... so, I'm still led to believe it's entirely plausible there's room for expansion, here. At the very least, an extra 128K untapped with the "RAM" chip-select, but I'm still thinking even more; that wouldn't require any more than the documented bits on those mapping ports.
Anyhow, this time I think I managed too many 'pops' from the stack. Last time it was having forgotten a 'ret'. People really code like this?! I mean, it'd be /easy/ to muck up a running OS with these sorts of mistakes! We just rely on the idea it'll crash hard, but [most likely] only affecting RAM, so will reboot OK?! No worries about damaged hardware? Heh. Look what it did to the screen... that just ain't right. Those pixels are definitely not "on."
And not off, either.