• Calcy the rugged outdoorsman

    esot.eric11 hours ago 0 comments

    Apparently I convinced whoever's in charge of the rain that I was pretty serious about making some progress today, rain or shine.

    Also, saw this on my way here...

    Yup, that's a truck on a towtruck on a towtruck. And I think the crane that made it possible. I didn't have time to grab the camera for the police escort. This really made my day.

  • Calcy's great uncle, and project updates

    esot.eric2 days ago 3 comments

    look at that wonderful VFD!

    <s>Well, shoot, I took the batteries out, and they've since fallen well out of reach. You'll just have to take my word for it,</s> that's a nice little Vacuum Fluorescent Display. $2.99, how could I pass it up?!

    Half of me wants to hack it into the TI-86 for some purpose... maybe displaying the z80's data/address bus? 8 digits is perfect... 24 address bits after the memory-mappers is 6 hex digits, two more for data... I had been contemplating single-stepping and toggle-switch inputs a while back...

    Initially, upon seeing this i thought each digit was a separate display, which I thought would be great for a wristwatch, and maybe various other projects. But, even weirder than those flat VFDs you find in VCRs and such, this guy is in a glass /tube/, cylindrical! How 'bout that?

    You can almost make it out, here. Interestingly, both ends have wires coming out, unlike most tubes.

    ... oh heck, I've already gone this far, and I left the lone screw out since it still snaps together quite nicely at some 50 years(?!) old.

    I dig that the leads are spiralled out from the circular layout.

    Bad shot, sorry... but there's really not much in there, and what is is mostly repairable/replaceable/hackable... I dig that, too. Probably part of the reason it's still around after fifty years.

    Also, oddly, I noticed no friggin' datecodes! Best I found was maybe "45", but obviously that can't be right... right? Oh, hey, I just saw a vid the other day saying that Japan didn't use the AD year-system until after they were well into the electronics business. So, it might actually be from year '45, in whatever their system was, then. I may look that up, soon. That vid was about something from the late sixties, as I recall.

    Anyhow, this guy's in near pristine condition, would be a bit of a shame to gut it... but who knows what its future holds. There's plenty of space inside, which could also make for a project-box... hmm...

    Alternatively: i heard once of someone hacking a cheapo calculator for counting events: enter 1+1, then some sensor triggers the Equals key, repeatedly, automatically adding one each time. 

    Along those lines, as long as all you intend to display is a single number up to 8 decimal digits long, the keyboard matrix could be broken-out for a microcontroller to control. Send a ribbon cable through the battery compartment and the vintage calc keeps its look, brains, and functionality... but can be used for other purposes too... hmm...

    ... A couple days later: one idea might be a Digital-Readout for an axis on a CNC machine, which also just happens to be a calculator, too, with a dimension already entered, ready to be divided by three for calculating the next move, or something... heh.



    In the compy backup realm... I've accounted for 500,000 of the 1million "missing" files. Yep, I had done some massive cleanup the day after my last backup in July, and even typed-up a log of my doing-so. Sometimes I'm not a complete idiot. But, still, that leaves 500,000 ,"missing" files still unaccounted-for. What The Heck Did I Do? 'diff -rq' doesn't even seem to help in that regard.... something burried deep in some folder that was in the trash? Maybe some kernel source or something?

    Though, I think I've determined for sure that diff /is/ smart enough to recognize when two files are hardlinks to the same inode, so doesn't actually go through the process of comparing them byte-for-byte. VERY handy, since my backups link-dest each other... I was able to diff some 200+GB of backed-up files in about 15min... which would've taken /days/ otherwise, on this system's singular USB port.

    Still... Where Are My Files?


    Also, /finally/ organized all the backups I did from the TI-86... MANY different versions of the same include/libraries now organized to the latest versions, but with the oldest timestamps (being that backing up the same file again later gives it a new timestamp, now...

    Read more »

  • While I'm backing-up...

    esot.eric09/10/2021 at 17:43 0 comments

    Brief (yeah, right...) recap... 

    What I need is a somewhat-accurate reading of the CPU frequency so that I can bitbang a bidirectional UART.

    This differs from my previous "UARto[S]T" (Universal Asynchronous Receiver to [Synchronous] Transmitter), because for that I was able to control the interface at the byte-packet-level at the computer-side, using the computer's data transmission as a clock for the calculator's data transmission. This time I don't have that luxury, so need a "real" UART implementation which can read and write packets which actually are truly asynchronous. ...Well, mostly.

    The idea, then, comes down to watching /another/ communications port, and deriving timing from it. 

    That port is not a UART, nor does it communicate at a similar baud. But, it /does/ have a defined and steady-enough bit-rate, such that if I can count/calculate the number of calculator CPU cycles during its bits, then I can get a pretty accurate idea of how fast the CPU is running. And, from there, can add appropriate CPU-cycle delays in my UART bitbanging.

    The logic-level-toggling-rate of that comm-channel, however, is /really/ fast, in comparison. So fast, in fact, that, at least in my z80 skill-set, I can /just barely/ guarantee that every high and low will be detected /at all/. Nevermind trying to measure their duration.

    On the plus side, every bit in that protocol has both a high and a low, so clocking is inherent. Also, once a packet is started, all its bits flow back-to-back, even between bytes.

    So, I plan to store several hundred samples at a known sampling-rate of 21 CPU cycles, then count the toggles. That'll get me a pretty good idea of the CPU frequency, at the time those samples were taken. I figure it won't vary /dramatically/ thereafter, at least for a few UART transactions, then I can do it again.

    Also, luckily, the UART system only communicates after the calculator requests it. So, there's plenty of time to measure/recalculate timing whenever necessary.


    But, that means processing samples... and I thought it might be handy and easy to do-so with those I'd already taken as logic-analyzer screenshots...

    And, I somehow managed to corrupt some data in places that have nothing to do with my project. And now it's acting /really/ weird. So, memory-reset again, despite all those wonderful "Memory Recovered" messages.

    That flash backup thing would sure be handy!


    On the plus side, this other stuff has helped get ready for that, I now know a thing or two about accessing/creating "variables" which includes things like programs and source "files"... so, actually, it shouldn't be too difficult to write that backup/restore utility... yahknow, I imagine a day or two, so it'd probably be two months.


    Multitasking bit me in the butt...

    I recently acquired from a garage sale an external hard disk large enough to backup my internal drive... So I've been writing zeros to it in about 40GB chunks whenever I've got the compy running for other purposes... make sure there's no bad sectors, whatnot.

    And, I'd forgotten my internal drive is connected via the same USB hub. Which meant, in this case, that connecting the external drive /before/ power-up could (and did) cause /it/ to be /dev/sda, instead of the boot drive...

    'dd if=/dev/zero of=/dev/sda seek=200G'

    Yeah, i noticed, thankfully, about 1.5G in because (again thankfully) it was running much slower than usual. And, looking closer, the wrong hd light was blinking. I do like hd lights.

    So... shit. Now I'm learning about debugfs and ext4 block sizes and inodes... some 250,000 blocks means potentially up to 250,000 files (especially considering all my small sourcecode includes, or the friggin 512Byte sectors from #OMNI 4 - a Kaypro 2x Logic Analyzer ). Thankfully I do have another backup drive to recover many/most(?!)/all(?!!) of them from, but first I have to figure out which files were zeroed!

    So, first yah gotta calculate where the...

    Read more »

  • TI-86 Logic Analysis

    esot.eric09/03/2021 at 18:10 0 comments

    whelp... I managed to speed up the sampling rate dramatically...

    My signal is /supposed/ to toggle (or not) at 8us intervals...

    My original sampling code took 39T-States per sample, or at 6MHz 6.5us/sample... IF I understand the z80 right...

    The new code doesn't use a loop. INIR takes 21T states for each of 256 samples until the last one where it takes 5 fewer, since it doesn't repeat/loop itself.

    So, presumably (I have Very Little to go on, here) if I insert a 5 T-State "NOP" between calls to INIR, then samples would be perfectly spaced in time, even crossing from sample 256 to sample 257. Thus each sample now takes 21 T-States, or 3.5us (at 6MHz). Right?

    Now, at 3.5us/sample and 8us signals, each high or low should be /at least/ 2 samples, right? I mean, even if it's as they say and the TI-86's clock speed decreases with the batteries, still hard to imagine it'd slow too dramatically... 2+ samples per high/low still seems pretty reasonable... right? And, /surely/ the clock rate doesn't vary dramatically between cycles, right?

    But... Apparently.... 

    There are still /many/ single-sample highs and lows, some even back-to-back!


    I'm at a bit of a loss... theories abound, but testing them all would be quite an undertaking. Especially since documentation on this protocol is /sparse/.

    The other factor is that this may not really serve my end-goal. Theory there, allegedly, goes that since this particular signal bus is always chattering, rather than only responding to requests from the external device (i.e. my calculator), there must be another signal bus for the latter purpose.

    Now, there /is/ wiring for that... but, as I said, documentation has been sparse, and since it'd only speak when spoken-to, I have to figure out /how/ to speak to it in the first place! And, of course, /presume/ that whatever I come up with actually "sounds" like what I think it should to the other device. Did I mention that this second bus uses a different protocol entirely?

    So, there's that...

    Now, from what little I understand of /this/ bus/protocol (in the screenshot), I shouldn't be seeing what I'm seeing. Which suggests /my/ "ears" aren't even hearing correctly what's being "spoken." So, if /that's/ the case, then surely /speaking/ yet /another/ language, with /no/ real-world examples to learn from, would be quite difficult, nevermind, again, expecting what I speak to actually /sound/ like I intended. Hah!

    In TI-86 terms: I wonder whether what I'm seeing is the result of many things, e.g. a lack of documentation regarding special cases (i.e. the "host" is interrupting a talking device, or two devices try to talk simultaneously, and they're negotiating, etc.) Or, maybe, there are interrupts going on in the Z80 despite my having disabled them, slowing two samples. Or maybe there are wait-states /internal/ to the z80-VLSI when accessing port7. 

    Or, here's a weird one, because I came across it for different reasons entirely, WabbitEmu's TI-86 source code https://github.com/sputt/wabbitemu/blob/master/hardware/86hw.c has a "port 10" which, if I understand correctly, is used to transfer the LCD framebuffer to the emulator's display memory... could it be that /that/ is how the real implementation works? A bunch of OUTIRs to the display, much like my INIRs...? I did some grepping of the firmware for other in/out functions, rather than the  'in a, (10)' or 'out (10), a' instructions which are easy to grep... nothing stuck out. And, besides, the LCD keeps refreshing even when interrupts are disabled... So, that'd require an NMI, no? And, surely, that'd've been well documented by now... its effects would be tremendous on all those game devs! So, is "port 10" (and a similar port 11!) a hack for emulation purposes, or a real thing not documented in any of the usual sources? (Note that port10, as i recall, is an actual thing on e.g. the TI-83, but that uses a different Z80-VLSI and a different/external display...

    Read more »

  • TI-86 Logic Analyzer

    esot.eric08/29/2021 at 17:36 0 comments

    Ok, so it's gnarly-dusty and that's not real sample-data, but here goes:

    That's two lines of sample-data, from the link-port, wrapping, to show as much as reasonably-viewable (1024x2 Samples visible).

    Presently, I think each sample (pixel) is around 6us... that's about as fast as I could code it, with more than 256 samples.


    I'm planning to view a signal that toggles at a minimum of 8us, so it's going to have some ugly aliasing(? stretching, anyhow)-effects, but I /think/ I can work with it... in post-processing.


    This brings me to the link-cable... I've got the "For Windows Only" graphlink (aka "blacklink") from TI, which is actually quite "dumb", as in it doesn't do anything except level-shifting to make the TI-link protocol work with RS-232 voltages, and vice-versa.

    I broke out its schematic a while-back in a past log. https://hackaday.io/project/179772-vintage-z80-palmtop-compy-hackery/log/194140-blacklink-cable-schematic 

    It's really quite simple, using comparators with open-collector outputs and pull-up resistors in both directions. It doesn't even invert the logic levels (which would've been more per the RS-232 standard, but this is /hardly/ RS-232 compliant, thus "Windows only"), which works in my favor.

    Vbias zener ~=1.6V sets the low<->high threshold for both directions. A pretty decent threshold for most logic-levels.

    Vpu zener regulates the TI link to 5V (if available) or drops-out due to the other diode, allowing the calculator to do the pulling-up to closer to 5V (a little gnarly with the voltage-divider between the two TI-Link outputs' pull-not-up-but-to-each-other, better look into that).

    Basically, what we have here is a logic level-shifter which is pretty durn easy to interface with various logic levels...

    Or, in this case, since my source signal is 5V logic, pretty much matching the TI-86 link port, a handy little isolator... just in case. I mean, it's not /isolated/ per se, but at least it's not feeding my alleged 5V signal (which may well be higher, since I measured ~4.6V with a multimeter while data was flowing) /directly/ into my calculator's CPU.

    ... handy.

    I've [ab]used it a couple times, now, like this... 

    The prior case was with my UARtoT software... I had (and used) several options, including wiring the link port directly to the 3.3V-level Tx/Rx signals broken-out from my USB-Serial dongle (as opposed to the RS-232-level signals at the DB-9, which are level-shifted by an HIN213, kinda like a MAX232). I was able to get away with that because long ago I added my own zener-regulators to its signals. 

    BUT. I could've just-as-well used (and did) the blacklink wired to those 3.3V signals, because... the comparators work down to 2V, have open-collector outputs, and diodes prevent things like Vpu being too low from interfering. And, though, if driven at 3.3V, it won't be able to pull up the TI link to 5V, the calculator does that.

    So, frankly, it's really quite handy as a general-purpose TI-Link-to-anything level-shifter + 2.5mm three-connector (kinda rare) phone-plug breakout + input/output separator.

    And, frankly, it could easily be recreated from common parts... the /least/ common, maybe, being that 2.5mm connector!


    Looks like I may also be using it with 7V logic (Wha?!). Gotta get myself a 7V source for that, heh.


    I haven't figured out enough of TI-OS to maximize the number of samples; the sampling routine can do up to 64k, but of course, without remapping during sampling, which'd slow it down, the absolute limit is just shy of 48k...

    The key factor, of course, is that of reading each sample into its own byte. Memory-wasteful, but computationally fast, for the highest sample rate possible (~140KSps).

    So, since I've touched on this rabbithole... Lessee, the z80-VLSI (Toshiba T6A43) doesn't seem to have a means to remap addresses 0xC000-0xFFFF. They're stuck at RAM page 0. I gather that's not just a software limitation....

    Read more »


    esot.eric08/26/2021 at 17:56 0 comments

    I /finally/ figured out /exactly/ the reason I took on this project... it's a major component of another project I'd backburnered so far as to only have the vague recollection of its needs, and to nab it when I found it.

    Along the way, easily two years, now, I thought of many potential solutions, saw many others on HaD, found a few /almost/ solutions at Goodwill, including a few "JuiceBox" toys, which probably would've worked, but not ideally...

    If this was my prior "normal" life"style", it'd've been probably one of two options: either build something with an AVR and scavenged-parts, or just use a friggin' laptop. But both these options are pretty difficult in this life"style."

    A couple years back I was living on my uncle's farm... he had a blutooth doodad which would make a phone again /almost/ perfect... but the app was far too limited, and the affordable ones apparently haven't been hacked-enough for better to exist, nor protocol documentation... and, again, in this environment coding [learning to!] Android apps isn't really feasible...

    No, what I needed was a low power, small, computer with a couple 5V GPIOs that I could develop the software /on/.

    And here I finally have one... three, in fact, and mighta wound-up with a fourth if I didn't calm myself down upon seeing it for $7... And I've been far more than "dinking around" on this thing for /months/ without its even once, until waking this morning, occurring to me /why/.


    Nevermind the many-times-daily reminders. Nevermind even having written about a probably-more-important project I'd been neglecting. I had two, two was thrown at me... but I guess I forgot to put them together.


  • "FTDI"-type USB-Serial link?

    esot.eric08/26/2021 at 00:47 0 comments

    Now, it seems, rather than working on my FLASH backup software (which was an offshoot/tangent of my original project goals, and which also got offshot for several weeks), I've become somewhat fixated on the idea of a new "homebrew" graphlink, using one of the many now-commonly-available USB-to-Logic-Level-Serial-RxTx adapters, e.g. the "FTDI" built-in to most arduinos...

    Personally, I'm rather fond of the PL2303, And I built my college research project with a CP2101 (as I recall), Though, an FT232, etc, would also do the job, /sans/ the RS232 level converter found in retail USB-RS232 converters... I'm talking about the little boards I'm almost certain are a few bucks from sparkfun or adafruit, these days.


    The idea is: wire-up the Tx to the "white wire" and Rx to the red. Maybe add a pull-up resistor. Ground, of course. And bam you've got yourself a $5 USB graphlink that works with TILP.

    But, this isn't an easy task, making this possible.

    ... Though, it's mostly software, which most folk would never see the inner workings of.

    So, here's an overview of the inner-workings, starting with an "It's not /that/ easy, even for the end-user"

    The thing is, the TI linking protocol, at the lowest level, is not /at all/ compatible with Asynchronous Serial of the sort coming from such USB converters, (or a real serial port with a MAX232-like level-shifter, if you'd prefer).

    So, this creates a chicken-egg problem. If you want such a simple/affordable/ubiquitous interface between your calculator and your computer, you've got to teach the calculator how to communicate with it.

    If this were the era of my middle/high school years, that'd simply mean asking Bobby in Math Class to download the utility from his calculator. But, I get the impression TI-8x "sneaker-net" isn't nearly so common these days. So, you could download the utility off the internet, but how would you transfer it to the calculator, when you need that utility on the calculator to download the utility from the computer onto the calculator?

    Right. So, for the user, it wouldn't be /exceptionally/ difficult...

    The TI-86 allows you to enter custom programs by-hand in hex-code.

    Get a calculator from Goodwill, grab the "FTDI" you've already got in your drawer, type in some hex, load up TILP, select "upload AsyncLinkUtility" then, thereafter, it just works.


    Now, forgetting for a moment how much friggin' work it would be to make it that simple for the user...

    I gotta wonder how much is reasonable to expect of them.

    So far, it seems, it'd be about 32 hex-codes that have to be hand-entered (in hex, 64 characters) just to create /a container/ for the utility which will later be uploaded.

    OK, then we need /more/ hex values for the calculator to understand the bytes coming in from the computer's Tx line... I'm guessing also somewhere around 32 bytes to be hand-entered.

    I /think/ it could be done about that small... about 128 characters to be typed, and 64 spaces. Typed /correctly/ mind-you!

    I dunno, that seems like a lot when there are other options from the parts-drawer. OTOH, those other options are also lacking in many ways. 

    Also, as far as I know, the TI-86 is the only one which /can/ run hand-entered applications. So, this'd be useless for TI-85's, 83's, etc. (Lacking sneaker-net).


    Another option is just to throw a microcontroller inbetween. And, in this era of arduinos and such, that's not a huge ordeal--for someone proficient-enough to wire-up an "FTDI"--to wire-up and program. Maybe even less-so than hand-entering the upload utility. The microcontroller speaks native TI linking protocol on one side, and Async Serial on the other (maybe even acts as a USB-CDC serial converter). 

    This option, really, is /way/ better, in a lot of ways. E.G. it wouldn't interfere with normal linking with other calcs, and it doesn't require special utilities on the calc. But, not everyone has /the/ arduino sitting in their drawer... whereas, I think they'd be more...

    Read more »

  • What Next?

    esot.eric08/21/2021 at 18:15 0 comments

    well, now that I've FINALLY backed-up that FLASH, I guess I should start working on the stuff to actually /use/ it!

    Which, too, isn't really what this project was about... another tangent or branch in the fractal that is this project... to /enable/ this project. Zooming out to get the whole picture... I can't really seem to do. But, having finished the last part, at least I can zoom out a little.

    OK, so I added the FLASH chip months(?) ago so that I could do quick nonvolatile backups of my progress with this project... a place to permanently store source code, libraries, executables, etc. Especially for those moments when I'm about to try some code or hardware modification that might wipe the memory...

    The irony, I guess, is that I wound-up doing /most/ of that stuff /while/ trying to backup the flash to eventually enable my doing /of/ that stuff. Heh.


    And, now, I don't really have many ideas of what else I wanted to do like that. Heh!


    Software-wise, there was some discussion about writing a custom OS, or at least some bare-metal code that could boot the system separately from TI-OS... basically dual-boot the thing. But, again, I don't really know what to /do/ with that!

    That idea, though, extended to my full-RAM-backup-to-FLASH idea might make restores easier... hmm. Backup from within TI-OS, then if "memory cleared" flip a switch to boot from flash, wherein the memory would be restored and plausibly TI-OS could be given back control (flipping that switch back, or maybe toggling a flip-flop) as though it'd never been not running... 

    But... again, heh... this wasn't the project, just an enabler!


    Other ideas, well... at one point I thought maybe it'd make for a handy UI for other projects, e.g. a dumb terminal for an arduino or maybe even a linux box... but, really... small screen, weird keyboard... A SmartResponse would be smarter. And, besides, why add an arduino when what we've got here is a full-fledged computer? 

    OTOH, maybe I'm not thinking about this right... if I thought about this TI-86 as a (MY) friggin' calculator (since my trusty TI-82 I've had since middleschool was somewhat poorly hacked with a backlight that causes memory-clears), yahknow, a tool instead of as a thing to be hacked, maybe it'd be a bit more like a piece of test-equipment. Then, a dumb-terminal already at my side could be quite handy. Hmmm.


    In a similar vein, I've somewhat pondered connecting #sdramThingZero - 133MS/s 32-bit Logic Analyzer to it... kinda goofy, in this era, but a huge part of that project was the goal of its being inerfaceable with even old compies of this vintage via parallel port.


    In other realms, well... For some reason I've felt the urge to connect up some old ISA cards, CGA, VGA, Soundblaster... I really have no idea why, though... just to make this a computer, I guess.

    In other other realms... well... blinking LEDs is doable with a shiftregister on the link port... that's just software, hack-wise. 

    Adding a PS2 keyboard to the link port shouldn't be too difficult, especially having seen the 200Hz interrupt handler can call a user-function. I think someone already did that. Even a PS2 mouse, as I recall (huh, how would that work with the OS?)

    So, I suppose that was part of my interest in seeing about other I/O options than the link port, because a serial port, mouse, and keyboard can't all be connected at once, eh?


    Oh, I got a for-parts Palm Vx for less than $10... was kinda thinking about /maybe/ hacking its backlight into this calculator... and now it occurs maybe the touchscreen is also possible.


    Oh, and some thoughts of hooking up #The Artist--Printze...

    But, really... I dunno what I'm going for with all this... and after finishing the FLASH backup /finally/ instead of elation, I've mostly felt like most of my projects are little more than a waste of time. 

    This past month my poor van has been trying to tell me she needs some lovin'... and believe me, she deserves far better than I give her......

    Read more »

  • UARtoT Functions -Flash Transferred

    esot.eric08/21/2021 at 04:39 22 comments

    Brief recap:

    The ultimate goal of this project was long long burried under tangent after tangent that each seemed almost certain to take only a few hours at most, and wound-up taking weeks, instead.

    I piggy-backed a 256K FLASH chip on the TI-86's OTP ROM what must've been months ago for the sake of being able to run full system backups while I was doing gnarly testing of hardware/software ideas that could easily result in "Memory Cleared" on countless occasions... which would be quite a setback, since I'm writing the software /on/ the calculator...

    Yes, I understand I could back it up regularly to a computer. That's another story. But, sufficed to say that's what I've been doing for backups these past weeks, instead of backing up to the flash, which is already installed and functioning.


    Because I found that chip in my long-ago-scavenged sorted-parts bin, and realized that over the past few years I've dug out old PCBs that'd been scavenged and realized many times that I might like to get some of them functional again someday. So, somewhere in there is one missing its firmware... and this chip might contain it. 

    So, no idea /what/ it came from, I decided to dedicate a few /hours/ to backing up its contents.

    Three (more?) WEEKS later, it's /finally/ done.

    What's it from? Apparently it's the BIOS from a Compaq Presario... which, frankly, even if it's from my once-beloved P150 laptop (as opposed to, say, some random desktop someone passed onto me), I certainly wouldn't've gone to all that effort for it... (Oddly, I don't see many strings in there at all... basically just "Phoenix BIOS" and "Compaq Presario"... what about all the settings /in/ the BIOS Setup program?!)

    OTOH, in the process I managed to give the TI-86 a new trick... it can now transmit RS-232-compatible serial data through the "Windows Only" "blacklink" graph-link cable, which was originally designed to be bit-banged from Windows via the handshaking lines.

    Yep, that's right... My TI-86 has UART capability, now... and it was "only" a matter of rewiring the blacklink's DB-9 through a passive adapter and a little software.

    OK, not quite... The TI-86 doesn't seem to have a high-speed counter/timer/clock accessible via software. The only thing like that is an interrupt about 200 times a second... and, I'm not too interested in 200Baud communication. So, really, not being a z80 wiz, bitbanging asynchronous serial frames would be quite difficult.

    I actually spent quite a bit of time near-certain there must be a higher-speed counter accessible /somewhere/, and dug all around the ports, for many days, to no avail...

    Then a moment of clarity... Hey, I need a clock, why not use the computer as the clock?

    So, now, the computer transmits 0x55, which results in 10 alternating bits (including start and stop) and the calculator looks for those edges and transmits its own serial frames/bytes synchronized to those edges.

    I have this weird feeling I have, yet also haven't, heard of this before. I mean, it's so friggin' simple, surely others have done this... but, I can't at all think of /where/ I might've heard of it. 

    Regardless, it /does/ work, and surprisingly well. I transferred all 256KB of the Flash twice without a single bit error. 4800baud was more than fine for my needs. But that speed-choice was a remnant of something else, by no means the limit. Interesting side-effect of this technique, the other device doesn't care what the computer's baudrate is, as long as it has enough processing time. Kinda groovy.

    So, I call it a UARtoT. Receive 0x55, Transmit whatever you want. Unidirectional, but that's all I needed.


    Ugh... now why did something /so/ simple throw me off-course for WEEKS?!

    Lemme put it this way: 


    NO! You CANNOT store every possible combination of 8 bits in a bash variable. No. Don't even try it. Even if you think you've found "the trick" I assure you you've...

    Read more »


    esot.eric08/19/2021 at 00:36 5 comments

    while [ 1 ]


      read -n 1 byte < /dev/ttyUSB0




    while [ 1 ]


      read -n 1 byte 


    done < /dev/ttyUSB0



    Friggin code worked great. Friggin blacklink powered fine. Friggin weird voltages on PL2303 and HIN213 work fine. Friggin inverted-logic for RS-232 levels worked fine. Friggin bypassing RS232 levels worked fine. Friggin current-draw from a handshake line worked fine. Friggin 5V source creating 2.5V highs right at the HIN213' threshold worked fine. Friggin 8V battery worked fine. I'm sure I'm forgetting a friggin lot of friggin things I friggin tried.

    Friggin 9600baud worked fine. Friggin 300 baud worked fine. Friggin 19200 baud had one measly bit error. Looks like the only test i tried that wouldn't've worked was 75 baud.

    Put the friggin' pipe on the friggin' while loop, not on friggin read.


    This explains it pretty clearly /for a file/: https://stackoverflow.com/questions/58829941/i-o-redirection-in-a-while-loop

    And, I think, were I writing it for a file, I'd've thought of it like that... I've certainly, in the past /written/ it like that, for files and strings, using the <<< redirector...

    So why would I've expected differently with a serial port? The device node is designed to look like a file. Heh!

    Now, I guess, this again is where stty might play a role... and maybe IFS?

    Unlike a file, the serial port device node isn't static. If you read the first byte in that "file" it will be different each time. Right? And you can't exactly seek the twentieth byte, then go back and seek the first. Right?

    So, I guess, I thought the serial port was different.

    But, now that I think about it, redirection of stdin is a bit more like reading a serial port than reading a file... stdin isn't seekable, either. Right?

    Maybe, maybe, you could treat a "line" as seekable, as though each /line/ is a temporary file... but, mostly, one reads that entire line in one go, then processes its bytes/words/whatever afterwards.

    So, again, I guess this may be where stty and IFS may play a role. When one accesses stdin for a read, or redirects a file or serial port to stdin for a read, what exactly happens?

    A normal 'read' call would halt the script while the user typed... until they hit Enter, (IFS, right?). Then the 'read' would be solely responsible for processing /all/ of what the user typed in that time. Another call to 'read', then, wouldn't process whatever was left-over from the last read, it would wait for an entirely new line to be entered.

    So, probably, with default stty settings on a serial port, it would do the same. Duh.

    It gets confusing with read -n1, because, now I recall doing similar in the past, it doesn't follow its normal rules.

    Normally read reads each word (separated by space) into each variable name supplied, e.g:

    $ read var1 var2 var3

    Will store three sequential words into the three variables. BUT, it says it /also/ stores anything remaining in the last var... So, if you enter four words, var3 will contain the third AND fourth words.

    OK. So better to write it:

    $ read var1 var2 var3 varExcess

    And, just don't use varExcess if you don't care.

    Now, logically, from that explanation, say we just wanted to grab one byte:

    $ read -n1 char1 excess

    Sould put the first byte into char1, and any remaining bytes (up to Enter, per IFS, right?) into excess...

    But, I don't see that happening. The variable 'excess' is always empty.

    Maybe it's to do with my initial testing, which only sent one character every half-second... But, per default stty settings, it should've waited at that read until it received Enter... which, of course, my test never sent. BUT it /didn't/ wait for Enter, or else it'd've never finished that first 'read' and would've appeared frozen.

    So /somewhere/ it was sorta set up the way I intended... so, then, it would seem maybe an stty setting told 'read' it was done whenever the buffer...

    Read more »