Close

Memory Cleared Defaults Set, part 2

A project log for Vintage Z80 palmtop compy hackery (TI-86)

It even has a keyboard!

eric-hertzEric Hertz 07/17/2021 at 04:385 Comments

yup.

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.

Discussions

ziggurat29 wrote 07/23/2021 at 20:04 point

"some ASIC CAD program... but this chip is pretty old, did they even have such programs back then?" -- 1996? you betcha.  Hardware description languages have been around since the 1960's.  Carver Mead and Lynn Conway  published "Introduction to VLSI" in 1979, and as VLSI principles gained prominence in the 1980's synthesizable HDLs such as Verilog and VHDL appeared.
[sidebar, Lynn Conway is an early trans engineer-of-note, along with Sophie Wilson of ARM fame.  There is a fun movie "Micro Men" you can find on YouTube where the early days of ARM are dramatised.  Sophie-actual has a cameo near the end as a pub landlady.  A fascinating watch and the depiction of Sir Clive Sinclair is just spot on.]

As far as unused bits in peripheral registers being read/writable -- sometimes they are, sometimes they aren't.  When designing with TTL they often are because you use an SSI octal latch or something, but in these synthesized designs there's no special reason to make that the case.

  Are you sure? yes | no

Eric Hertz wrote 07/23/2021 at 21:42 point

interesting... all of it.

Well, i think this chip appeared in the TI-81, first, in 1990-ish, but I guess those six years were not a huge difference in the corporate-computing realm... big difference in personal-computers, though!

SSI vs. ASIC vs. VLSI, I always get confused... todays "average" level of integration being far beyond VLSI's! BUT, such terms carry more meaning than their names imply... I should probably be more on top of that!

Indeed, my working-out of this thing's internals (RAM/ROM mapping ports, video controller, etc.), and how I might do similar in an inspired design very much considers how it'd be done with 74xx chips... 74574 8x D-ff being one of my longtime faves (ins on one side, outs on the other! What were they thinking with the 374?!). But, also in that realm, /reading back/ the 574's data requires an additional 244, which is exactly what they didn't put on IBM PC/XT parallel ports to enable not only read-back of the output data, but /also/--with one tiny modification, using a spare 374 output which wasn't assigned a purpose, yet /was/ wired to a 244 for readback, in the parallel port control register--allowed for data-input via the parallel port's data lines! Hah! I kinda love that story. Almost Everything was already there, it just needed a 244 and one wire that was grounded to be wired to a register that was already in place (for exactly the reason you mention, they come in 8's) but not used.

I'll check out these folk you mentioned.

  Are you sure? yes | no

ziggurat29 wrote 07/24/2021 at 07:20 point

I do hope you check out these folks.  They made great contributions and also just had to deal with a little extra -- perhaps as we all have to from time-to-time.

  Are you sure? yes | no

Eric Hertz wrote 08/06/2021 at 05:09 point

Re: folk:

Keeping the tab open for the next time my direction-register is set to input. Thankya!

  Are you sure? yes | no

Eric Hertz wrote 08/10/2021 at 20:17 point

Lynn Conway, very interesting read, and a huge contribution to the VLSI/CPU realm. Thanks for sharing that.

Also responsible for "Out of order" execution of instructions in CPUs, which is quite a lot to take in, being so used to carefully taking into account my instructions' order and often  timing when using assembly! I can see how it would be great for number-crunching, or executing compiled C... but, whooo boy... working with that going on unseen in the background could drive me up the wall!

I ran into a case where the avr-gcc optimizer did something like that... i'm trying to remember... I think it had to do with toggling a GPIO, wherein it considered that my gpio's toggling/out-to-port had no effect on the variable itself, so thought it could get away with incrementing the variable /before/ outing to the port. It would seem, from this description, it should've been smarter than that, but it was apparently a really weird case I can't quite remember. I think I wrote about it in another of my projects' logs....

Oh, now I remember... no, I needed a single-cycle pulse on the GPIO, and the way to do it was to use the single-cycle "out" instruction... so what I did was (in C) have two 8bit variables, one containing the port value during the pulse and one containing the port value /after/ the pulse. I calculated them prior, then wrote the two outs back-to-back. The optimizer instead calculated the first variable, did the out, then calculated the second variable, then did the second out. Instead of a single-cycle pulse, it was active for /numerous/ cycles. I only found that out after looking at the disassembly... what it did was try to reuse the same register for both output values... and, of course, could only do-so step-by-step... /completely/ out of order from how I wrote it. 

Actually, I think that was the first time I wrote my own assembly (inline in C)...

... so, I can see how things like that, cache, branch prediction, etc. are great for computations, but I guess stradling the line between hardware and software, I find those things extremely daunting... unpredictable! Kinda exactly the opposite of why I like my field, heh.

Maybe if there was a z80 co/pre-processor sorta chip/circuit that acted as the intermediary for such things, i might grasp it better... it'd do the actual bus transactions with memories, then feed the instructions to the z80 in its own order... could be pretty interesting, actually... heh, maybe in TTL.

The rest of her story... wow. She had a lot on her plate all the while coming up with huge contributions to the field! 

I'll keep this tab open for the others, next time my direction-register is set to input. Thanks for sharing, yo!

  Are you sure? yes | no