was all excited: wrote a program to not only test (read-back) all real ports 0-256, but also took into consideration that "b" is placed on the high address byte during port reads
(BTW, this was part of my inspiration for my 24-bit "real" addressing idea, load a to A23-16... it'd be ignored, usually, but flip a bit, prior to a 16bit-instruction, and it'd switch in a to A23-16 on the bus for one instruction's memory-read, rather than the port5/6 map.)
So, instead of reading 256 ports, i tried all 65536 "ports"... and found "new" data!
But, it now looks like I'd've gotten the same if I just read ports 0-7 at such high rates and repetitiveness.
So, the "new" data amounts to an extra bit on port3 being active from time to time, and, the Write Only ports read-back 0x00 sometimes rather than 0x78 (which, I'm near certain, though haven't checked, 0x78 is the last byte in the 'in a, (c)' instruction, which remains on the data-bus after its fetch due to capacitance on the bus inputs, since nothing else drives it during a port read from a write-only port).
OK, looking at port3, I had to look at the docs for the TI-85, it looks like the change from the normal 0x08 to 0x0A, briefly, might be due to the bit which indicates there was a timer-interrupt (since the last read?). EXCEPT that it doesn't seem the bits at 0x08 nor 0x02 align with those in the 85's docs. They also seem inverted. But, they're almost certainly dealt with in circuitry /internal/ to the z80 VLSI, right? So, I'm kinda at a loss. One possibility might be that things like those on this port really are handled with plain ol' GPIOs. There's a lot of weird circuitry I can't follow, involving transistors and maybe even R/C networks... I thought they were related to low-power switching-off of things like ROM... but... Is it possible the 200Hz timer interrupt is simply an RC oscillator connected to GPIOs?!
OK, then, say it is... why don't I see 0x0A on port3 very often... indicating the timer interrupted? Probably, simply, the interrupt-handler usually gets to it first, but not always.
OK, then there's reading 0x00 from the WriteOnly ports... which is also rare, but not nearly as rare... It may /also/ have to do with interrupt-handling... wherein, I'm a bit confused, because I was pretty sure the interrupt vectors after an instruction completes, but this would suggest some amount of pipelining. The instruction for port-input has already been fetched, yet gets executed /after/ reading the interrupt vector's byte(s)? Maybe.
So, then, why does 0x00 come through far more regularly than 0x0A, when they're /both/ from the same (?) source? Well, that might have something to do with how much time is spent loading then processing the in instruction, which maybe can get interrupted, if there's a tiny bufer/pipeline vs the plausibly only one clock-cycle where the in is executed before the int takes over. Or something... brain's sorta getting lost on this one.
So... no new ports, it seems.
BUT... there was some weirdness I noticed back when I was testing 65536 ports... the higher address bytes seemed to show patterns! Wait a minute... if it was timer-interrupt-related, then that should've depended /greatly/ on the amount of time between pressing enter to acknowledge the finding... wait a minute... now it doesn't make sense, at all. That was reading-back 0x00... like, one time it found 0x00 at ...
LOL... that pattern thing was /so/ repeatable I only bothered to take one picture:
...like it never happened...
Say, like, 0x7700, 0x5700, 0x2700, 0x0700... seriously, I saw /many/ such patterns in the various runs, but the actual /timing/ of each read was determined by my pressing enter between each... how on earth could that've been the result if it had to do with timer-interrupts? HAH!
...like it never happened.