Weeks... whoops.

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

It even has a keyboard!

Eric HertzEric Hertz 10/25/2021 at 20:450 Comments

Update 12/5/21:

There's a simple circuit for exactly this purpose... bidirectional, even. Most folk these days show it with a mosfet. I'm not too fond of discreet mosfets, too many friggin' parameters. Big Clive introduced me to the term "SUN", (or something similar...) just use a "Standard Universal NPN". It was /much/ harder to find mention of a BJT version of the circuit, despite its being nearly identical and /much/ easier to comprehend. I feel stupid not having come up with it on my own. 2n2222, 2n3904, whatever. Put one between the two devices, Emitter on one side, collector on the other, doesn't really even matter which. Then pull the base to the lower of the two source voltages (or even lower). Done.


Didn't I write a log-entry titled something like "How Robust Is That Link Port, anyhow?" A while ago?

Because, apparently I forgot that "little" concern over the past week(s?!).


So, now, I think I have a perty-durn-great bitbanged-UART-Rx function just minutes away from being tested...


I *just now* realized it doesn't work toward my end-goal.

Unless I change it.... the end-goal.

And, having gone through all that, I just might.

Realistically, I guess, the Rx function I wrote is /far/ more likely to be used in /other/ projects, which the original goal's Rx function would be somewhat absurd to use anywhere other than this particular setup, or the rare others like it.

But... again, it means rethinking my goal, here.

Which, frankly, I guess I'd been putting-off somewhat intentionally, at the start, until I managed to forget about it near completely.

Thing is, I guess, there's really no reason to do it that way, except that it would've meant I could use the link-cable's circuitry as-is...

I can come up with a different circuit. Yeah?

And the work-around was pretty insane, anyhow; the link-cable's circuitry would act as a low-triggered latch on the incoming data, which could only be delatched by the receiver's (calculator's) pulling its input high VERY often... I did some rough calculations, just now, (didn't I do similar in that "robust" log-entry?)... To get it fast-enough to /possibly/ work (as in, I don't know it will) means unlatching and sampling the Rx line about 20 times per bit, 200 times per serial byte. And, that leaves Zero time for actually /processing/ those samples. Now, my attached device might send about 13 bytes back-to-back... which means 2600 samples... assuming no idle between serial frames. but... we're not sampling just one wire, here... to get this fast-enough means reading the entire 8bit link-port and storing that entire byte with every sample! So, now, I need a buffer of around 3KB to receive 13 measly bytes of data.


And then, of course, an /entirely/ different function for processing those samples into actual data.


Actually, it /almost/ seems doable. But, the big question is whether the transmitter will see that its One, following a Zero, is still (latched) Zero, and think that there's a collision, and end its transmission. (This is a bidirectional one-wire UART).

That's the "fast-enough" part that has me resetting that latch as quickly as possible... which I doubt I can get much faster than 20 times per bit, and the slower it is, the more likely it'll be noticed by the transmitter.

No data on this sorta thing, as far as I've seen. So, realistically, this idea is probably a bit ridiculous... A) it's somewhat likely it won't even work. B) it's VERY niche. C) I don't know enough about this system to even really be able to recognize if its likely not-working from the start is due to this or one of the gazillion other educated-guesses I've had to make...

Or... I could just come up with a different interface circuit. And use the far-more-common system I just finished.


And... now we're back to "Just How Robust Is That Link Port, Anyhow?"

From the schematics I've seen, frankly, it seems like I could wire the white wire on the link-connector /directly/ to my device, even though that device's "High" may be pulled as high as 12V!

The schematic for the link port shows a diode between the wire and the CPU's input that I think Should effectively turn the device's high into a Hi-Z after the diode, then the calculator's internal pull-up would turn /that/ into 5V for the CPU input.

It seems like it not only should work, but that that's kinda exactly the design-intent. E.G. One calc's batteries are at 4.8V while the other's are at 6V... Don't want 6V going into the CPU powered by 4.8V!

OTOH... 12V? I dunno...

Can the transistor take 12V across C-E? Is this some sorta fast-schottkey, low-Vf, specialized diode that can't handle 7V reverse-voltage? Oh, I think I also saw some capacitors in there... is a switch from 0-12V going to cause a gnarly ground-bounce?

I'm /really/ hesitant to put my TI-86 through that... OTOH, if it /is/ designed for such, that could be a /really/ handy discovery.

OTOOH, if it is, then even the really cheap "blacklink" cable could've been made significantly cheaper... but it wasn't. So, then what? Is the 86's link-port's diode a "new" addition not in earlier calcs? Hmm...