Close

Inside the TI-86

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

It even has a keyboard!

eric-hertzEric Hertz 05/29/2021 at 23:150 Comments

Random notes, randomly updating, for now ...

RAM: https://pdf1.alldatasheet.com/datasheet-pdf/view/47125/SONY/CXK581000ATM.html

128KB, has one NC pin, pin 9, so 256K in the same form-factor might be a thing, though not seen amongst the list of related parts... it's entirely likely this is JEDEC(?) standardized...

70ns, though 55ns parts exist

Pin 9 doesn't have a visible trace, though neither does pin7, A15, nor several others, which must be under the chip.

1,2,3,4, 7, 9, 10, 11, 12, 13, 14, 15, 16

17, 18, 19, 20, 24, 31

32 = TP1

12, 11, 10 go to far side of board, away from cpu, nearer ROM, A12, A14, and A16. Is that right??? 

13=TP7 de

14=TP8(?) de

15=TP5(?) dead-end

18=TP4 dead-end

19=TP2 dead-end

17 traces come out under the chip package, 18 unaccounted-for pins... bah, pin9 might be a pipe-dream.

...

Interesting note: A16 (on the SRAM, which technically could have its address pins in any order, no?) Seems to go to the ROM... IF it is actually A16 from the CPU, that means that the banked-memory address lines are shared between ROM and RAM. Does that make sense? Hmmm...

Sooner or later a multimeter might help.

...

Random aside: LCD: 18 Pins from the main board (3 power?) to an LCD board with a big ol' TQFP Toshiba T6A7(?)0 looks to be the row-driver. Appears to have only One pin connecting to the column-driver (e.g. common reset or hsync). 32 pin flex-cable to column-driver, chip-on-flex, many of the pins are tied together... power?

But, that leaves easily 14 signals... seems a lot for a col driver. But wait! It looks like some are connected far-left AND far-right... hmmm....

1, 32 shield?

2,3 -> D4, C18 -> 31, 30

4, 29

5, 28

6,7 possibly under board to 27, 26

8? No visible trace

14, 15, 16 -> C21

17-21 -> C21 (other terminal)

8, 9, 10, 11, 12, 13, 22, 23, 24, 25 seem to possibly be signals. 10 bits. Possibly 8-pixel parallel-load...

(Pin 8, no visible trace is at RIGHT side of screen, as viewed, which might be shift-out if a second 128-column-driver were used in a 256-column display.)

But wait!

Cable to mainboard doesnt seem to have 8 signal traces. And 4pixel parallel load was quite common...

MANY traces to mainboard seem to go into the diodes and transistors at the right... the various voltages for AC?

Also, many of the 10 column-driver traces go straight to vias, which might be connected on the underside.

...

ROM: AT27C020-15JC 256KB, 150ns

RAM: Yes the 256K version exists, and yes, pin9 is A17. Put in 2000 for the part number's 1000

...

A16 is connected to both RAM and ROM (!!!)

A17 is not.

Now, technically ROM needn't be wired in order, either, but, There is a chip ID, internally, which could require ordered addresses to reach... ... A0 and A9, all others are low, so they could, still, be in any order to the CPU's.

...

Why I'm skeptical of the shared A16: because of the memory-banking system and my understanding of z80, having only 16 address bits (A0-A15). Since a register attached to an I/O "port" is responsible for selecting which of two 16KB banks (in ROM or RAM) are shoved into addresses from 16K-32K and 32K-48K... that to me would indicate the highest address bits would be used for selecting the bank within the memory. Further, since allegedly either ROM or RAM can be selected to fill either slot, then the bank selector must have another addressish bit to choose between the two devices' ChipSelect.

16 banks exist in ROM, 8 in RAM, 16x16=256K ROM, 128K RAM...

Four address bits (likely A17-A14) are used to select a ROM bank.

Three address bits to select a RAM bank (A16-A14?)

(Maybe that remaining bit selects between ROM and RAM?)

Actually, the circuit I imagined is getting quite a bit more complex... and if it's as complex as I'm now imagining, then it really wouldn't be much more complex to actually have most of the address bus and chip selects rerouted differently than merely remapping a few address lines... hmmmm...

(BTW this day is going exceptionally well...)

...

86ports.txt claims that ROM banks 0x0e and 0x0f are blank, except the last byte which contains a value (possibly a checksum?)

Which then leads to the possibility of replacing the EPROM with a FLASH, and loading nearly 32KB of user stuff!

....

OK, it seems it's not much more complicated than I imagined, and so likely the RAM and ROM share address bits after all. The key may be that the ROM has an active-low Chip-Enable, while the RAM has active-high as an option (though, of course adding an inverter would be easy). Then it's merely a matter of throwing the RAM/ROM on a high address bit (A20, plausibly, since bit 6 of the port5/6 remap registers choose RAM/ROM). Then, basically it's just a matter of some tiny decoding logic of A15 and A14, two 8-bit registers with Output Enables, and a few buffers with OE... Pretty simple, really.

And I have a vague idea that 24bit addressing could be accomplisheable with only a tiny bit of work by exposing essentially the outputs of an internal register... via another output-enable. Kinda akin to how the B register is loaded to the upper address bits when doing port accesses. it'd only take one additional instruction to do-so... e.g. "next memory access is 24-bit". The same could be done with two direct port-writes, (A23-A16, and "go"), basically 8 1bit registers for those addresses, two buffers for A15-14, a flip-flop for "go", and a little glue to automatically reset it. Which'd be FAR fewer instructions than trying to calculate which port to use to remap, how to fit the remap in, then go, then remap it back... since they already threw two ports at it, i can't imagine they'da passed this up. And there supposedly are "direct" 24-bit addressing routines...

...

So, IF that's right, then there should be 128k of unwired memory in the RAM space, with all necessary signals accessible. Which would take a little decoding to break apart from the 128k of built-in RAM, so it doesn't loop in that space, but surfacemount 1-gang TTL exists... so... FLASH there might be the way to go since messing with the ROM might not be easy if it checksums... and besides, most kiddos with TI Calculators probably don't already have a ROM reader/writer...

...

http://jgmalcolm.com/z80/variables/abso#Get_Word_ahl521d

I believe some of these routines might indicate what I suspected. Some, accessing bytes with 24bit addressing, don't result in "memory page changed"... Though, of course, it's entirely plausible the routine might read the original mapping, remap to access, then rewrite the original mapping, that'd be a slow process! Also, I think some of those also could inc/dec the 24bit pointer in the same routine...

_WriteB_Inc_ahl=$5567

Which implies the intent to reaccess that same page again soon (without, again, leaving the routine with the page remapped!)  Similarly, there are block-copy routines between two separate absolute addresses, which would be absurd with having to swap between to pages, back and forth.

So, ahl and bde, essentially combining an 8bit register with a 16bit to handle 24bit addresses. Now, if A in ahl happens to be output through a buffer to the high byte of the address bus, simultaneously with hl, then things could be quite fast, indeed... not a huge addition to the cpu, considering there's already the rest, though I guess the question becomes whether they designed the entirety of the silicon layout, or was the z80 a block, and the port registers a separate block, etc... in which case running register A's signals outside the CPU might be difficult. intriguing, anyhow. Like I said, I think I can see it doable with a regular z80 and two port writes, followed by a regular 16bit-addressed memory-access, which, again, would be far faster than using the mapping ports that are well-documented. Or, actually, maybe a single port-write, since the address decoding circuitry for loading that "address high" port could also trigger the "next instruction is 24-bit (so bypass the remapping registers)" circuitry...

OTOH, I tend to forget this isn't Harvard Architecture, and intermixed with the actual memory-accesses /requested/ by the instruction are many memory accesses request/ing/ plausibly many bytes to get the instruction in the first place. WEIRD. That could put a damper on my theory!

...

http://www.datamath.org/Graphing/JPEG_TI-86.htm

LCD row driver T6A40, not 70, datasheet is available(!) Also the column driver... T6A23

https://www.datasheetarchive.com/T6A23-datasheet.html

Looks like "carry" is handled by an enable output, so 8 data bits, off-screen, could easily be latched into a DFF like the 74574... or 74244 buffers could drive 8 LEDs if flicker is acceptible... lots of options.

I'da never imagined there'd be datasheets for these... not sure whether to be pleased, or a little saddened that that reverse-engineering challenge is already solved. But, there's plenty else to do.

...

And... no... the column-driver is 160 long, but of course is only wired-up to 128 columns. The carry output would only work if the controller can send more than 160 cols. But, as far as I've seen, 160 is the controller's limit (at least, as allegedly configurable by ports). Apparently the TI-83 has an LCD controller (not the row driver we see on our LCD) which is documented on Ports 0x10 and 0x11, which is far more configurable than I've seen regarding the TI-86...

.

Discussions