Well, here's a notable example of one single architecture that birthed both types of machine, and it came from a company not really noted for either one: Texas Instruments.
But how would a Unix shell work on a single line screen, or for that matter, a Gopher menu? We'll explore some concepts, but before we do that, for context and understanding of their capabilities we'll start with the history of these machines — and because their development is unavoidably tangled with TI's other consumer products and their home computer family, we'll necessarily rehash some of those highlights and nadirs as well.
The Compact Computer family and the CC-40
The obvious progenitors of the pocket-handheld computer family were the programmable calculators emerging from various manufacturers in the mid-1970s. In this genre TI was a notable vendor despite being just one of several. Arguably the first of these was the Hewlett-Packard HP-65, released in 1974. Although not a computer in the conventional sense (despite HP's marketing), it could accept up to 100 lines of "program text" (key presses) and read and write them using magnetic stripe cards, and was robust enough to go into space with the Apollo mission in 1975. TI fired back in 1975 with the SR-52, also programmable with mag stripe, and supporting 224 lines.
As competing calculators added power and new capabilities, a higher end model dubbed the Advanced Language Calculator (or ALC for short, codenamed "Lonestar") sought to introduce more computer-like features to the handheld range with its own scrolling LCD and cartridge-based software and programming languages. The idea turned out to be an atypically forward-thinking move on TI's part because the market dramatically changed in 1980 when Sharp introduced the PC-1210 and PC-1211, the first true pocket computers with full alphanumerics and programmability in BASIC (the PC-1211 was rebadged by Tandy Radio Shack as the PC-1). In quick succession followed the Panasonic HHC family, even based on a more conventional architecture, the 6502, and shortly afterwards Casio introduced their own pocket line.
This new offshoot of the calculator market caused TI management to reexamine how Project X and the ALC should be positioned. Commissioning a user survey in July 1981, TI's marketing team broadened both concepts into three potential niches (RM 1000, RM 2000 and RM 3000), reworking the original programmable calculator product into the lowest price point (1000) while adding a BASIC-based single-line LCD pocket computer (2000) and a full multi-line LCD portable as higher tiers (3000). The obvious inheritor of Project X, the RM 1000 eventually morphed into the still-born TI-88 calculator, produced and prototyped but unexpectedly cancelled pre-launch in 1982 due to fears it was already obsolete.
In parallel, the Texas Instruments consumer products division was determined to maximize sales volume, initially through discounts, reductions in production cost and heavily courting retailers, and in September 1982 newly promoted division head William Turner openly ignited a home computer price war with Jack Tramiel's resurgent Commodore. Turner aimed to push Commodore out of the market again by competing on price, now Tramiel's home turf, and use the installed base to move their vendor-locked software and peripherals. While TI sales duly increased, Commodore persistently hung on in the low end market as in retrospect the VIC-20 was a much cheaper system against which the expensive and arguably overengineered TI 99/4A could not indefinitely compete. Nevertheless, through the rest of 1982 the 99/4A outsold the VIC-20 and for some period of time was the number one home computer in the United States, and management rapidly plotted how to diversify the line. Alongside wilder ideas like the 99/7 terminal and a direct successor alternately referred to as the 99/4B or 99/5, at least two concepts got as far as actual hardware. The 99/8 (codenamed "Armadillo") was intended to attack the high side of the market, a substantial expansion of the 99/4A with more RAM and built-in Extended BASIC, while the 99/2 was meant to hit the ultra-low end as a direct response to systems like the UK Sinclair ZX81 (subsequently introduced States-side in slightly modified form as the Timex Sinclair 1000). Although also a full 16-bit member of the 9900 family — with a TMS9995 CPU, the same as the Tomy Tutor — the diminutive 99/2 used a Chiclet style keyboard similar to Lonestar and a very limited black-and-white video chip, less capable than the 9918A but also less expensive. It supported cassette tape and cartridges, and as a stepping stone to the larger systems, BASIC programs written on a 99/2 were designed to be upwardly compatible with the 99/4A and 99/8.
For expansion options, TI created a new and simpler peripheral interface called Hexbus (also variously seen as Hex-Bus, HEXBUS and HexBus in period literature and user notes, though here I'll render it Hexbus for the remainder of the article). TI positioned Hexbus as a universal means to service all but the highest-bandwidth devices, from modems and serial communications to printers and mass storage. As such, they replaced Lonestar's original 9-pin I/O port with Hexbus and additionally fitted it to the 99/2 and the 99/8. The protocol is straightforward to understand and implement, and I'll talk a bit about the technical aspects a little later since the devices we'll use all connect that way. TI planned to extend Hexbus support to the 99/4A and RM 3000 (in whatever form it ended up taking) so that as many of their comsumer computers as possible could use the same peripherals.
Meanwhile, as Tramiel began driving price cuts faster and deeper and TI was repeatedly forced to match them (as the old Klingon proverb says, revenge is a dish best served cold), management began considering the ALC/Lonestar as a potential anchor in the portables market where competition was not nearly so fierce. The ALC prototype (now the ALC-A, for Product A) was extended into a family of machines: a low-end ALC-LC ("Low Cost") with a 16-character LCD, limited BASIC, Hexbus but no cartridge port, and 1K of RAM; a high-end ALC-C to succeed the RM 3000 with a 40x6 character LCD, larger keyboard, cartridge port, Hexbus, cassette port and 8K of RAM (a terminal variant ALC-T added a 300bps modem); and then the ALC-A itself expanded into the ALC-A2, with the same 31-character LCD and original Chiclet keyboard, plus 2K of RAM, cartridge port and Hexbus. The cartridge port could accommodate programming languages like BASIC, Fortran and Pascal as well as application software, and Turner insisted it also allow RAM expansion.
TI was justifiably very proud of Hexbus and demonstrated at least three peripherals at the show: an RS-232 serial interface for $100 [around $325 in 2025 dollars], a four-colour printer-plotter which many of you have already guessed the mechanism of and selling for $200 [$650], and a licensed version of the Exatron Stringy Floppy that TI reworked into what they called "wafertape." Its sole mass storage option, the wafertape drive was priced at $139 [$460] plus media cost, which wasn't disclosed. A modem, full-size printer, wand input device and a video interface were announced for later in the year.
Despite being arguably more powerful, the 99/2 was clearly positioned as the junior product — TI priced it at just $100 [$325] while the CC-40 retailed for $249.95 [$810]. Software support likewise reflected the CC-40's higher priority. TI announced eight cartridges at the show, but only two of them were for the 99/2 at $19.95 [$65] each, and about twenty more promised titles were to be released on cassette tape at $9.95 [$32] a pop. On the other hand, the CC-40 got at least six cartridges (seven listed here) and at least thirteen additional software packages on wafertape, with a promised seventy-five more; the most expensive of these retailed for almost $150 [$485]. TI informed attendees both computers would be available by summer.
In fairness, TI was not the only one in trouble and both Atari and Mattel took massive losses as well. 1983 was also the year of the crap home computer with many other underwhelming systems being introduced at or near that magic $100 price point — and I know if I mention any by name, someone out there will howl because there will always be at least one person who loved theirs. Unlike TI's hardware, however, such systems were made cheap to sell cheap: while most customers correctly perceived them as technologically inferior, they at least covered their cost per unit, even though most of these fly-by-night also-rans flamed out within months.
Seeing all this upon arrival in Chicago, TI management abruptly decided not to exhibit the 99/8 either and hastily put the display model behind a locked door for the show's duration. (Ironically, the Tomy Tutor — nothing less than a modified clone of the 99/8 — made its American debut at the very same convention.) Although a public relations debacle of its own (some mischievous press coverage even reportedly printed pictures of the door), TI's most enduring announcement from that Summer CES was a threat to completely lock out third-party software for the 99/4A, a deeply unpopular and thinly veiled attempt to maximize its failing razor-and-blades model, and one they mostly made good on by enforcing their patents on GROM chips. The company's stock cratered after announcing a $119 million loss in July — both due to production costs and a critical overestimation of demand — and Bill Turner was forced out of the company. Incredibly, Turner's replacement Peter Field decided to double down on the strategy by slashing the price of peripherals as well as the computer.
The keyboard, however, was one thing that did change. While the ALC and the CC-40 use the same "Chiclet" keyboard in the same overall layout, including a small numeric keypad, some of the keys were moved around and certain others removed. The undated ALC image I have above likely came from the same source as these documents from a former TI engineer, one of which shows the MODE key crossed out, the LBL key replaced with CTRL and the equals key at the bottom left of the numeric keypad replaced with a generic "FN" function key. It looks like the ALC was also proposed to support some sort of Japanese language entry, most likely katakana (the display was not sufficient for most hiragana, let alone full-blown kanji), but this feature was also subsequently eliminated. On the image here I can't distinguish what the shifted characters were meant to be, but this photograph appears to be of the same or similar ALC mockup, showing some typographical characters also moved around as well as a line of deep blue secondary functions possibly for debugging purposes.
TI produced two RAM cartridges for the CC-40, though because of the CC-40's unusual BASIC memory map, not all of their RAM was useable under all circumstances. The most common, and arguably the most useful for a particular reason I'll mention shortly, was the 8K Constant Memory cartridge. This cartridge contained battery-backed RAM which could either be added to the system as expansion memory for BASIC (but resets the system when taken out), or be used as a removable storage medium with a small machine language program. In this second mode the entire memory of the standard 6K system could be copied to the cartridge and back, and since it carried a small lithium battery, its contents — including the machine language subroutine necessary to load from it — would persist when unplugged. TI estimated this battery would last about three to five years using a mechanism that would connect the battery only on first use. Naturally, unless you find an unused NOS unit, current examples are dead as doornails but despite not being user-serviceable the batteries can be replaced with some effort.
The second option was the 16K RAM cartridge that TI had originally promised. This unit lacked a battery and was completely volatile. Although technically capable of serving as a storage medium, it could only do so while the cartridge remained connected and the computer's batteries were good, so it was most useful simply as expanded memory. Unfortunately, while the original 2K iteration could take advantage of all 8K and 16K (to yield 10K and 18K respectively), BASIC's memory map in the released 6K CC-40 couldn't access 4K of either device — which is to say the 8K cartridge could only add 4K of memory to BASIC to yield 10K (though all 8K was addressable), and the 16K only 12K to yield 18K. Although TI did mention a 2K expander in documentation, no such cartridge was sold. Despite this deficiency, the CC-40's memory map can support up to 32K of external memory and modern homebrew RAM cartridges typically provide all 32K with battery backup a la the original 8K Constant Memory.
TI intended Hexbus to service all kinds of peripherals and assigned fixed device number ranges to various classes. In practice this was not always strictly observed, nor were all assigned device classes actually used or all possible numerical ranges actually assigned. Among others, officially 1-2 were for cassette tape but 3-8 for tape mass storage, 10-19 for various sorts of printers (with subclasses beneath them) but 50-53 for Centronics-style parallel interfaces, 20-23 for RS-232 serial and 70-73 for modems, 30-33 and 40-43 for colour and black and white video interfaces, 100-109 for 5.25" floppy disk drives, 110-117 for 3.5", and 90-95 for barcode readers and scanners. 118-239 was explicitly dedicated to third-party use but most homebrew Hexbus devices, including the ones we'll use in this article, emulate the standard device IDs. Thirty-one different commands are defined; devices are only required to implement those which are relevant to their operation.
Hexbus mandated the host be capable of no less than 3000 bytes/second for "peripherals that require a minimum I/O transfer rate" and the CC-40's user's guide rates the CC-40 as capable of up to 6000 bytes/second. Theoretically a nybble could be transmitted about every 16 microseconds, yielding a maximum throughput of around 31,250 bytes/second, though rarely was anything close to this top speed realized. Part of the problem was the protocol's overhead as well as the computers themselves, which for reasons of power consumption did not drive the bus particularly efficiently under ordinary circumstances. The other wart on Hexbus are the cables, which have poor strain relief and rely on a sometimes mushy friction fit in the ports, which themselves aren't well-reinforced either.
In retrospect TI's choice of the Stringy Floppy was peculiar because the device already had a somewhat chequered reputation on other platforms. Although reasonably fast, its storage capacities were unimpressive compared to floppies and the media wasn't cheap. Worse still, the tape media was well-known for being prone to tangling and even sometimes outright fracturing, a problem that only got worse as tapes got older and more fragile, and tended to happen more with expensive higher-capacity cartridges because the tape in them was thinner. Repairing a mangled or broken tape could be an exceptionally fiddly business which I've experienced enough firsthand to the point where I rarely use the wafertape drive anymore except for demonstrations.
Yet all that was not sufficient to deter TI, who wanted to avoid the association of ordinary cassette storage with home computers, and believed the wafertape drive would be seen as handy, speedy and state of the art. However, two more flaws subsequently became apparent. The first was that tape handling became even more unreliable on battery power, especially as the batteries got low, and virtually necessitated the device be connected to the wall. But the second, discovered in October 1983, was a rare but critical fault in its internal microcontroller where under specific circumstances it could unexpectedly fail to wake on an interrupt and thus go out of synchronization.
One other mass storage device was created by TI for Hexbus, a 5.25" floppy drive, but while it may have been able to work with the CC-40 this device was actually intended for the home computer line and went unreleased. There was also a prototype Hexbus colour video interface, in practice more like a serial terminal that accepts commands from the CC-40 and draws a screen with its own internal 9918 (actually a 9118, which is functionally equivalent). The also-unreleased Editor/Assembler cartridge can control this interface for full-screen editing. Without a viable mass storage option, however, there didn't seem much point in releasing either one.
Orienting the battery compartment to the bottom, the topmost three chips here are the RAM. In the base model these are three 2K 6116 static RAM chips, yielding an unusual total of 6K. However, notice that the two at the top of this picture sit on pads bigger than they are and the one below them does not, plus wire jumpers just above the 5.000MHz crystal oscillator. We'll come back to those items in a moment. The power and reset circuitry is on the left side set off by a weird little plastic sleeve containing a bridging resistor.
The CPU is a TMS70C20 and indeed a CMOS version of the 8-bit TMS7000 microcontroller we discussed earlier, with the "2" indicating a built-in 2K of mask ROM (the version of the mask ROM is C11002, "C" meaning standard microcode), and a date code of 10th week 1983. The full model designation of "TMX70C20N2L" is interesting for several reasons: "TMX" indicates the earliest stage of production device where the die may not be fully developed (versus the TMP "prototype" where it is, and the TMS "sale" version designation is fully qualified for production), and the "N2" is a 70mil (0.07" or 1.78mm)-spaced DIP as opposed to the more typical "N" which is a 100mil (0.1" or 2.54mm)-spaced DIP, both rated for operation in typical temperature ranges ("L"). It divides down the 5MHz signal from the ASIC to yield its nominal clock speed of 2.5MHz, and has a 16-bit address bus for a maximum 64K addressing space.
Like the Intel 8051 and Motorola 6801, with which it was intended to directly compete, the TMS7000 family included onboard RAM and I/O standard. The 70x0 and 70Cx0 chips accepted up to a 5MHz clock source (divided by two or four) and provided 128 bytes of onboard RAM, a single 13-bit timer and 16, 8 and 8 (respectively) bidirectional, input and output I/O lines. In the CC-40, those I/O lines are mostly dedicated to the keyboard and memory addressing. The higher grade 70x2 and 70Cx2 chips accepted up to an 8MHz clock source and provided 256 bytes of onboard RAM, two 13-bit and one 10-bit timers, an on-chip serial port and 22, 2 and 8 bidrectional, input and output I/O lines. On the other hand, the TMS7000 was more like the 6801 in that it was a Von Neumann architecture and incorporated the on-chip features as memory-mapped I/O. 10MHz crystals were later supported, though these were still divided down for the internal clock.
The TMS7000 turned out to be a very bright spot for TI; it was substantially faster than the 8051 at most operations and quicker than even an equivalently clocked 6801 or Zilog Z8. I'll have more to say about the CPU when we get to actually writing assembly code for it.
The lower of the two RAM chips has no extra pads. This is in fact the original 2K configuration and what would have been present on any CC-40 variant. This lowest 2K is reserved by the system and not available for BASIC programs in any CC-40 configuration, but can be used by machine language programs and is legitimately addressable RAM.
The other notable chip on this board is directly above the SY6551, a 22-pin TI 1052911 manufactured 18th week 1983. This is the Intelligent Peripheral Bus Controller (IBC for short), managing the Hexbus lines for the CPU instead of requiring additional bitbanging, and generating an interrupt when data is available. In later devices it is superseded by the 28-pin TP0370. Everything else is off-the-shelf. We'll have more to say about the RS-232 box when we get to discussing Hexbus communication options in detail.
The lack of a viable mass-storage option severely damaged TI's attempts to portray the CC-40 as a useful portable computer. Consequently (and ironically), many owners tended to treat it as an overgrown programmable calculator instead, a task at which it nevertheless excelled in part due to its higher-precision base 100 BCD floating point and polynomial transcendentals, as well as the software on the limited selection of Solid State Cartridges which (although expensive and few in number) were generally high quality. On top of that, it was also substantially faster than TI's other programmable calculators and was of course capable of more sophisticated algorithms. Some users were able to source remaindered wafertape drives through unofficial channels but a third-party Hexbus storage device, the Mechatronics QD-01 Quickdisk using an unusual 2.8" medium, did not become widely available until 1986. Meanwhile, the consumer products division, now under half a billion dollars in cumulative debt from their ruinous price war with Commodore Business Machines, threw in the towel and announced on October 28, 1983 that they were abandoning the home computer market. The 99/8, all but cut from life support already, was officially canned earlier in October after about 150 had been made; production also immediately ceased for the 99/4A, after which it was heavily discounted and the remaining stock liquidated in March 1984.
The TI-74 BASICALC
In the meantime TI nevertheless worked on two direct follow-ons to the CC-40. One was the final embodiment of the RM 3000/ALC-C concept, incorporating a larger 40-character by 6-line LCD with a proper full size-and-travel keyboard intended to compete with the TRS-80 Model 100. Since the CC-40 now shipped in an 18K configuration, the so-called Compact Computer 70 ("CC-70") would likely have shipped with even more memory than the 8K of the original ALC-C. We'll never know, unfortunately, because the only known example is an empty mockup shell, reportedly because the first batch of gate array chips for the prototype were defective.
The other was an expanded CC-40 based generally on the same hardware called the CC-40 Plus ("CC-40+"), internally model "CC40001". Externally similar, and still nominally a 6K unit (though an 18K version was planned), its biggest upgrade was a new built-in 9-pin port to finally support loading and saving to cassette tape. Although implemented as an internal peripheral with its own notional Hexbus device number (device 1, replacing the wafertape drive, though properly in the range designated for cassette devices), there is specific support and prompts in the CC-40+ ROM for driving it and the cable cannot be retrofitted to an original CC-40. To accommodate these and other possible changes the on-chip system ROM was expanded to 4K and thus was introduced the TMS70C40 to the CC-40 family.
The CC-40 Plus got as far as prototyping and a small number of test machines were produced before it, what then existed of the CC-70, and the CC-40 itself were all quietly cancelled in November 1984. No explanation could be publicly ascertained — until late in 1985, when a new device emerged from a different branch of the consumer products division.
Although the TI-74 was introduced shortly before the high-end $200 TI-95 PROCALC in 1986, the PROCALC is nearly the same hardware, just with the 31-character display divided into two lines (one 16-character general line and five three-character function key descriptions on the second). It can accept the same peripherals and much of what I'll talk about in this history section applies to it, but it is not programmable in BASIC and is closer in feel and operation to the earlier TI-59 which it was positioned to succeed. While it is legitimately a member of the CC-40 family, I won't talk a great deal more about it in this specific article.
The trick here is that two of the Dockbus lines are for power, both for the TI-74 to power connected peripherals and for a common supply from a peripheral to power the TI-74. Like the Convergent WorkSlate, which had a similar feature, these pins allow peripherals to share power with the computer. They obviously should not be connected to a CC-40 Hexbus device, nor the Dockbus-specific reset line. TI wisely keyed this connector to avoid letting out any magic smoke.
Dockbus also has a little known "user mode" where, with two control lines placed in a recognized unusual configuration, an application can drive the four data lines directly to a device that knows how to communicate in this mode. As a consequence of the specification, compliant legacy Hexbus devices on the bus will ignore bus traffic when this mode is active. Dockbus user mode avoids nearly all of the Hexbus packet overhead and allows real-time signaling, but necessarily completely monopolizes the bus, and isn't supported by any of the classic Hexbus peripherals.
In the initial rollout the PC-324 and CI-7 were the only two peripherals; there was never an RS-232 option. The TI-74 also had its own improved version of the 8K Constant Memory battery-backed RAM cartridge (there was likewise no 16K version, and a 32K version was never released). The ROM usefully added support directly to BASIC for saving but also swapping RAM with the cartridge, and although it still carried its own backup lithium cell, as long as it was plugged in this cartridge could also draw power from the TI-74's batteries to avoid draining the lithium battery — even if the calculator was turned off. Finally, some of the CC-40's software packages were upgraded and ported to the TI-74, here initially the Statistics, Mathematics and Pascal cartridges, and later Finance and a BASICALC-specific Chemical Engineering cartridge. Some of these packages were also ported to the TI-95.
In 1989 TI introduced a new Dockbus peripheral for the TI-74 and TI-95, the PC-IF PC Interface. This device could connect to a DOS-based server on a standard PC via the PC's parallel port and exchange files with it for much faster performance than tape. It could also use the PC as a display terminal through the same server program, eliminating the need for the Hexbus video box. The PC-IF became a very popular accessory and the general concept has been expanded, culminating in today's TIIF2, though sadly the software is not open-source.
The TI-74 family remained available well into the early 1990s until it was discontinued around 1992, marking the end of the CC-40 and its descendants, and the end of our history. All that was to get you the context to understand the similarities and the differences between these machines, which will become very important a little later on. Let's get our CC-40 and TI-74 communicating with the outside world, and to do that we should start with the peripherals — old and new.
Communication options with Hexbus
The modem, on the bottom, has a telephone connection switch, RJ-11 phone jacks (one for your line, one for your handset, since the modem can't dial), and also a set of Hexbus ports. The connection switch is not for answer/originate, as is typical with many non-Hayes 300bps modems where the right modulation had to be manually selected; rather, this switch is for whether the modem is listening to the line. To make a call, a user would set the switch to OFF, manually dial the remote system with their telephone handset, wait for the answer tone, and then flip the switch to ON.
We won't talk further about the modem here, though it's certainly better than nothing, and since it doesn't require a dial tone you can have it manually answer any other compatible 300bps modem to exchange data using just an RJ-11 phone cord (your Commodore 64 can send data to it, for example). However, the RS-232 unit is capable of running up to 19.2kbps thanks to its onboard ACIA, a very impressive speed for the time particularly with this class of computer, and far faster than the modem. We will be treating it as our gold standard device for comparison purposes.
Unfortunately, both the modem and the RS-232 box have the same problem: ain't nobody making them.
On the left is the original, Jim Brain's HEXTIr. This is an Arduino-based device implementing a serial printer port (device 10), RS-232 port (device 20), SD card reader for loads and saves (device 100) and a battery-backed real-time clock (device 230). It is open-source hardware and firmware and yours truly has contributed improvements in the past which are now part of the current firmware package. Because it is an open-source unit, it is occasionally offered for sale in small quantities by various third parties and this was one of those that I bought some years ago; it came with a separate 3-D printed enclosure.
On the right is a newer entry, the the TI Hexbus Serial USB Adapter by StarDust and sold by Jeff Birt/Soigeneris, which I'll refer to as the "StarDust adapter." It offers two serial ports, one with an on-board DB-25 and the other via USB (devices 27 and 26, respectively), and has multiple Hexbus connectors and a Dockbus connector. It is not an open-source design (I've asked), but is sold and supported as a commercial product, and comes to you fully assembled with an enclosure of its own and ready to use. This device is particularly unique in that it has a basic configuration interface accessible as device 200, plus a simple console shell on either serial port. However, although it can also load and save files, this functionality requires a additional BackPack drive be connected to the DB-25 (as device 100) which is sold separately and requires its own battery.
The StarDust adapter goes a different way, besides using a micro-B USB jack: it uses 8-pin IDC connectors which are much more widely available, and it provides two of them allowing multiple devices to be connected. Soigeneris sells you cables to connect to these along with the necessary adapters. You'll need some to connect it to a CC-40, but the StarDust adapter is best paired with the TI-74 because it has built-in Dockbus and plugs directly into the port — it can even draw power from the Dockbus (switchable) if not connected to a USB source. If you don't need to connect to anything else, it can go right into a TI-74 and offer basic functionality straight from the shipping envelope.
When bringing up the CC-40 (or TI-74), if you have the Hexbus connected but the device on the other end isn't powered on, the computer will show its I/O indicator on screen and then stall out. Instead, both the HEXTIr and StarDust adapter will immediately power up when connected to USB, and then the computer can be turned on after that.
The key combinations for the Memo Processor are a bit arcane, but fortunately it comes with a nice spiral-bound manual (with the inevitable "The Wafertape™ Digital Tape Drive is not available" insert) and two keyboard overlays we can place over the main keyboard and numeric keypad to help us. This overlay also tells us what the LCD indicator marks are meant to designate. The cartridge has a single program on it called MP, so we enter (as the overlay hints us) RUN"MP" to start it up.
With the advent of the microcomputer, even though a substantial percentage of its business remained government customers, Telos management started to steer the product line towards personal computing in the early 1980s as a means of diversification. These initiatives were consolidated under two 1983 subsidiaries, Telos Computing and Telos Software Products, with the latter developing Memo Processor for TI. However, Telos Software Products became much better known for Filevision, a 1984 product for the then-new Apple Macintosh that presented a graphical means of designing databases by linking on-screen graphic objects with data stores. It sold briskly to rave reviews and in 1985 users were creating applications for it as diverse as airport layouts and airline routes, rabbit farm management, and the state of bills in the Florida legislature — all real entries in that year's contest. Filevision subsequently evolved into a larger version in 1986 called Business Filevision, but HyperCard became seen as a superior means for constructing such interfaces after it emerged in 1987 and gradually displaced it. Although the Software Products subsidiary was ultimately dissolved in 2002, its parent Telos Corporation remains in business today (presently in Ashburn, Virginia) and still primarily as a vendor to government entities, but now with an emphasis on cybersecurity.
From the keyboard overlay you'd get the idea that these are the only settings allowed, but in fact there is a hidden advanced settings page only mentioned parenthetically in the manual. When asked for the device number (i.e., at this prompt in the communications settings), press FN-Q instead, and you get a different prompt.
I mentioned that the two modern devices both have throughput considerations. If you have a StarDust adapter, you may occasionally drop characters unless you move its console to the serial port you're not using (e.g., if you're connected over USB, set console serial), and all but the most recent firmware doesn't work right with the default 300bps. However, once the console is redirected it seems to run fine at 19200bps with the same settings as the HX-3000, using either device 26 or 27. (This is not true for the TI-74, but I'll get to that later.)
The HEXTIr's firmware, on the other hand, has a very small receive buffer and to date I have not had success fixing this. While it might be better with a later CPU, this Uno R3 can only reliably work asynchronously at 300bps, and in that case the MP's default settings are best.
In terminal mode the MP presents a 31x1 window on an 80x24 virtual screen, though it implements no particular kind of terminal emulation, and even things like backspace and delete require control-key combinations (CTL-H and CTL-down respectively). XON/XOFF (CTL-S and CTL-Q) pause the display so that you can use the arrow keys to scroll, or FN-up/FN-down to jump to the top or bottom, or page the display with FN-S (FN-A to do so automatically).
The MP behaves very curiously with Hexbus. In TI's original conception of how Hexbus-based systems would communicate over RS-232, everything was synchronous and done in record-based transactions, which fit the Hexbus packet model well. This is typically the way you would drive such devices from BASIC, and all known Hexbus RS-232 devices including the HEXTIr and StarDust support this and (except for the modem) at high speed. However, this type of operation doesn't work effectively at all for asynchronous communications like a dummy terminal, which was exactly the type of service link the MP was intended to support. Although the HX-3000 RS-232 box, and later the HX-3100 modem, are capable of interrupting the main computer when data has arrived — which should have made connections very fast and seamless — the problem is that when this happens, the computer only knows that an interrupt has occurred and not what caused it, and as we mentioned earlier is thus obliged to poll any and all enabled devices on the bus to find out. Depending on the configuration, this could be a rather slow process and as a result end up losing data.
So the MP's solution is brute-force: it polls the bus incessantly, asking the selected device over and over if data has arrived and grabbing the response immediately if so. This shows up as the I/O indicator flickering non-stop on the LCD and the amber LED on the modem or RS-232 box remaining lit while on-line. This behaviour solves the data problem, which is the most critical, but at the price of reduced battery life and a lot more inefficient Hexbus traffic. It's also really rough on the HEXTIr and StarDust adapters which must bitbang Hexbus and serial in software at the same time (unlike the HX-3000 with its own dedicated ACIA and bus transceiver). Still, this method is the least unreliable way to run a terminal program the way Hexbus is implemented, at least for the CC-40 family.
Memo Processor suffices for the CC-40 itself, but the TI-74 doesn't have a terminal program of any sort that I know of. TI likely intended the PC-IF to handle this role. That seems unnecessary.
The first? terminal program for the TI-74 BASICALC
I'm going to stake a claim to being the author of the first terminal program for the BASICALC, but TI doesn't make it easy. It's just not possible to drive Hexbus at high speeds from BASIC on the CC-40 and this goes double for the TI-74 where the CPU is downclocked, so now we need to turn to assembly language. Let's talk more about the TMS7000 series of processors.
As with any microcontroller, the chips have substantial built-in I/O facilities realized as timers and ports. These onboard peripherals are handled as memory-mapped I/O from $0100-$01ff as the "peripheral file" and referenced as P0-P255 by specific instructions. Both the CC-40 and TI-74/95 CPUs have a single timer controlled in this range, but the CC-40 TMS70C20 has 32 I/O lines (eight inputs, eight outputs, 16 bidirectional) while the TI-74/95 TMS70C46 has eight more bidirectional lines explicitly dedicated to servicing Dockbus/Hexbus. Because the I/O lines overlap with the address and data lines, some number of them are lost when accessing off-chip resources. In these machines both microcontrollers run in what the data sheet refers to as "full expansion" mode, where external resources (RAM in this case) are available between $0200 and the bottom of internal ROM at the top of the addressing space. Twenty I/O pins are reserved for the multiplexed address and data busses in this mode, leaving eight inputs and four outputs (and the TMS70C46's eight additional bidirectional lines) uncontended, plus the single timer. Four levels, six in certain members, of interrupt priority are available. This range is where the CPU controls the bus, beeper (CC-40 only), battery sense, keyboard and LCD.
As a result, the TMS7000 family was a competitive microcontroller option during the 1980s and even early 1990s, appearing in many diverse applications such as point of sale terminals, handheld games (MAME emulates the Tiger Punch Your Lights Out), peripheral controllers (like the keyboard in the Olivetti M24), pinball machines (the audio controller in 68K-based Technoplay pins) and one-armed bandits, or pokies as my wife would call them. In fact, my parents' first burglar alarm was a TMS7000-based system because I remember looking at the circuit board while Dad was installing it and noticing it had a TMS7-something as the CPU (I think a TMS70C20 but that was many years ago and it was ripped out since). This stuck in my memory because as a kid I had recently cracked open my Tomy Tutor and wondered if its TMS9995 was related (they're not).
Indeed, one place the TMS7000 was not found much was in standalone microcomputers. Its instruction set was incompatible with everything else, even TI's other CPU lines, and its advantages in embedded systems didn't really translate to general purpose machines. A rare exception was the French Exelvision EXL 100 and EXELTEL home computers, another competitor for the French Plan Informatique pour Tous ("Computing for All Plan") — compare with the Thomson MO5 — that saw limited use in French schools. The use of TI chips in the Exelvision family was largely because Exelvision consisted primarily of former TI employees, and their CPUs are one of the uncommon ones with custom microcode to accelerate their custom VDP. Otherwise, aside from TI's own development SBCs, the closest thing most of us will get to a TMS7000-powered computer are our twin friends here.
Due to various implementational choices and the TMS7000's own strong big-endian orientation, one feels like you're coding in a mirror when working with these two machines. The stack is at the bottom of memory and grows up (compare with, say, the Motorola 6800 which is also big-endian but has a 16-bit stack pointer growing down), and instructions referencing a register pair X operate on addresses X-1 (MSB) and X (LSB), not X (MSB) and X+1 (LSB). To save space on loops that must frequently test for equality, the operating system tends to put everything at high addresses working down to low (so testing the end condition just means a decrement and looking at the processor's zero flag). This idiom was specifically catered to in the instruction set and obligatory for achieving the highest code density, so buffers and strings are usually stored in reverse order in memory, and programs are often loaded at the top of a given range.
The CC-40, and subsequently the TI-74 and TI-95, has a very modular operating system. The 2K internal mask ROM in the TMS70C20, which maps to $f800-$ffff, contains the lowest level reset code and system control drivers. However, the 32K BASIC ROM, which contains BASIC and the rest of the OS' higher level calls, is only banked in with 8K blocks (at $d000-$efff). This allows sufficient space for any installed cartridge's ROM or RAM ($5000-$cfff), portions of which can also be banked in and out if needed. The low 2K system RAM appears at $0800, and then BASIC text starts at $1000 up to $1fff (6K) or $4fff (18K); the address range $0200-$07ff is otherwise unpopulated. One of the very important routines in the CC-40's 2K ROM is CALPAG, a routine that takes a page number (0-3) in A and routine number in B, banks in the appropriate page, and makes the call. The vast majority of system calls on the CC-40 and TI-74/95 must be called through this routine; even in the 4K mask ROM of the TI-74/95 only a minimum number of system routines are always accessible. Another major routine in high ROM would be IOS, used for commanding devices through the I/O subsystem. In our case, this will be our Hexbus serial ports.
Because the TI-74 descends from the CC-40 Plus, substantial portions of the two systems' firmware are not only compatible but practically identical, even down to their usage of internal RAM registers. Most of the same calls also exist on both systems, but the calling convention is where the most critical difference lies. To incorporate cassette support, and later the extra calculator math routines, not even the extra 2K of RAM in the TMS70C40 (on which the TMS70C46 is based, not the TMS70C42) turned out to be enough to accommodate it. TI solved this problem in two ways. The first was to gut the system ROM, tossing out features not deemed germane to its primary purpose as a calculator such as the internal debugger and direct memory access. This, plus convenience, is the main reason we're writing the proof-of-concept on the CC-40 first.
The second way TI squeezed everything in was to change the way routines are called. A CALPAG-assisted call on the CC-40 looks something like this (using canonical TI assembler syntax):
movd %>0036,b
call >f836
or, as I prefer to write it since this is slightly faster and takes up the same number of bytes (seven),
mov %>00,a
mov %>36,b
call >f836
both of which will call the DSPCHR routine in the BASIC ROM. This routine expects a character in $5c and writes it to the screen in character position $53. (Notice that the 16-bit movd is to B, not A, because 16-bit operations work with X-1 as the MSB and X as the LSB.) On the TI-74, the register usage is the same, but the call stanza is markedly shorter:
trap 20
byte 18
This is just two instructions to make the same call, a savings of 71% (!). The trap instruction pushes the program counter like any other subroutine call and pulls the destination address from vectors at $ffd0 (stored, you guessed it, backwards), all in a single byte and in the same cycle count as call. Although the trap instruction is legal and exists on the TMS70C20 also, TI made the heaviest use of it here, though not all system calls were converted to traps. It is therefore feasible in our cross-assembled source to have assemble-time defines to select either the CC-40 or TI-74 calling convention (such as different macros), yet have most of the core assembler source be otherwise the same. This can be used to build both versions off a single source file and that's exactly what we've done.
To actually run our program, we'll need to get into memory, and we'd prefer not to have to deal with creating a cartridge ROM (perhaps in a future article) — ideally it should be something we can type in or load from an SD card or a BackPack drive. Happily, this task is greatly facilitated by the various memory management subprograms in CC-40 BASIC, meaning we can just create a BASIC loader and have it store everything in RAM. TI BASIC in its various forms is unusual for its heavy reliance on subprograms, which are separate modules (usually in a low-level language like assembly or 99/4 GPL, but also supported in CC-40 BASIC with the SUB keyword) activated with the CALL keyword, like CALL CHAR to redefine the shape of a character. (Even Tomy Tutor BASIC has subprograms internally, being descended from TI Extended BASIC, though you can't create more and Tomy wisely eliminated the need for the CALL keyword.) CC-40 cartridges can even provide subprograms of their own for immediate use with BASIC.
The relevant subprograms for our task here are CALL GETMEM, POKE (and if needed PEEK), EXEC and RELMEM. CALL GETMEM is basically malloc(), accepting a request to reserve a certain amount of bytes of memory and returning the address where it was allocated; CALL RELMEM is, analogously, free(). Once the memory is reserved, we can CALL POKE to populate it, taking advantage of the fact it allows storing multiple values in one statement, and then run the program with CALL EXEC. Here's the finished product for the CC-40. It is indeed short enough that you can just key it in, if you want, or you can get CCATRM.PGM from the Github project and run it from the HEXTIr or BackPack (e.g., RUN"100.CCATRM.PGM").
99 PRINT"Connecting":OPEN #1,"20.B=300,D=8,P=N,S=1,E=N,R=N,T=C,E=N" 100 CALL GETMEM(262,XBADDR) 110 CALL POKE(XBADDR,6,114,20,70,114,3,69,213,68,136,9,29,60,213,67,213,66,136) 120 CALL POKE(XBADDR+18,0,30,65,213,73,213,63,224,116,213,63,213,62,213,61,34) 130 CALL POKE(XBADDR+34,0,82,57,142,248,54,93,0,230,69,114,4,69,114,1,63,18) 140 CALL POKE(XBADDR+51,92,45,230,226,86,45,231,226,82,45,13,226,24,45,234,226) 150 CALL POKE(XBADDR+67,16,45,250,226,8,45,246,230,14,34,127,224,10,34,8,224) 160 CALL POKE(XBADDR+83,6,34,13,224,2,34,10,139,9,29,136,0,70,118,181,142,248) 170 CALL POKE(XBADDR+100,75,125,0,61,226,7,34,0,82,93,142,248,54,114,3,69,213) 180 CALL POKE(XBADDR+117,63,213,61,213,73,136,0,70,118,181,142,248,75,125,0) 190 CALL POKE(XBADDR+132,61,230,148,125,0,63,230,5,224,141,10,224,39,77,73,63) 200 CALL POKE(XBADDR+148,230,15,213,83,136,9,60,89,34,0,82,30,142,248,54,224) 210 CALL POKE(XBADDR+164,231,34,30,211,73,50,73,106,192,170,9,0,45,13,226,4) 220 CALL POKE(XBADDR+180,45,10,230,17,114,30,74,82,31,34,32,194,171,9,30,93) 230 CALL POKE(XBADDR+196,0,230,248,224,200,45,8,226,43,45,127,226,39,50,74,230) 240 CALL POKE(XBADDR+212,28,208,72,82,29,170,9,30,195,171,9,30,93,1,226,4,194) 250 CALL POKE(XBADDR+229,194,224,241,34,32,139,9,30,211,74,18,72,171,9,30,210) 260 CALL POKE(XBADDR+245,74,224,153,125,30,74,226,166,211,74,50,74,195,34,32) 270 CALL POKE(XBADDR+260,224,185) 1000 CALL EXEC(XBADDR):CALL RELMEM(XBADDR):CLOSE #1
This code is generated from the assembled binary with a Perl preprocessor and then tokenized using Texas Instruments' TIC74.EXE utility (works for both CC-40 and TI-74), which is available under Utils/ in the TIIF/TIIF2 archive. Naturally, that's an MS-DOS executable, so to run it as part of the build process we use David Lee's NT Virtual DOS Machine as the emulator. To keep it short I've eliminated niceties like the cursor, which isn't strictly needed for navigation on a single-line display, and which also makes it a bit quicker.
By default the terminal program opens an 300bps, 8N1 connection using device 20, which will work for the HX-3000 and the HEXTIr. If you want to use a different device, change the 20 in line 99 and line 110; if you want to change the baud rate, change the 300 in line 99. This is the same string you would use in, for example, Memo Processor with FN-Q. Here's the StarDust connecting at 19.2kbps:
There are a few important things to note about our code. Because we have no idea where we will get loaded to, our assembler source must exclusively use relative branches internally (dealing with limited displacements with jump islands), with the only absolute addresses being outside our program to specific registers and ROM calls. This limitation is not necessary with a cartridge. We also reuse some briefly idle portions of BASIC's memory for our own temporary storage, such as keeping both the buffer for Hexbus data and our scrolling screen line in the BASIC input buffer. These are stored (yet again) reversed because TI. To talk to the external device, we create a temporary Peripheral Access Block in the section of internal RAM BASIC itself uses for this purpose. This structure contains addresses for buffers and the Hexbus command bytes, and is passed to IOS to send out on the bus and gather a reply. We don't need to do this to initially configure the device, however, because the OPEN statement in our BASIC loader will do that for us (channel #1 is otherwise unused). We use the same brute-force method as MP because that's the least bad way to accomplish what we need reliably, though we have slightly less overhead, so we can maintain better data rates.
TI provided their own assembler, but here we use the well-known multi-architecture Macroassembler AS which is what I use for most architectures that aren't the 6502 or PowerPC. AS does not accept canonical TI syntax, so specify hex and immediates as you see them in the source file, and be cautious about modification as it will attempt to emit instructions for mnemonics the 70C20 may not support. One glitch, possibly to be fixed in the future, is that movd #...,b assembles incorrectly: you need to specify the register by number. (Not much of a loss because mov #..,a and mov #..,b do work, and together they generate code that is the same size yet slightly faster.)
That's the CC-40 done. Unfortunately, to get this running on the TI-74 requires a bit more work because CALL GETMEM, RELMEM, POKE and EXEC are part of the multiple subprograms TI liquidated to get everything to fit. But there's nothing that says you can't store a subprogram in RAM.
Next, load the TI-74 version of the terminal program, either by putting 74ATRM.PGM from the Github project on your HEXTIr or BackPack, or keying in the following:
99 PRINT"Connecting":OPEN #1,"26.B=300,D=8,P=N,S=1,E=N,R=N,T=C,E=N" 100 CALL GETMEM(271,XBADDR) 110 CALL POKE(XBADDR,6,138,32,31,208,126,114,26,70,114,3,69,213,68,136,33,29) 120 CALL POKE(XBADDR+17,60,213,67,213,66,136,0,30,65,213,73,213,63,224,125,213) 130 CALL POKE(XBADDR+33,63,213,62,213,61,235,19,93,0,230,76,114,4,69,114,1,63) 140 CALL POKE(XBADDR+50,18,92,45,230,226,93,45,231,226,89,45,13,226,24,45,191) 150 CALL POKE(XBADDR+66,226,16,45,250,226,8,45,246,230,14,34,127,224,10,34,8) 160 CALL POKE(XBADDR+82,224,6,34,13,224,2,34,10,139,33,29,18,126,139,32,31,235) 170 CALL POKE(XBADDR+99,0,136,0,70,118,181,142,240,69,125,0,61,226,7,34,15,139) 180 CALL POKE(XBADDR+116,32,31,235,0,114,3,69,213,63,213,61,213,73,136,0,70) 190 CALL POKE(XBADDR+132,118,181,142,240,69,125,0,61,230,146,125,0,63,230,12) 200 CALL POKE(XBADDR+147,224,139,18,126,139,32,31,235,0,10,224,34,77,73,63,230) 210 CALL POKE(XBADDR+163,10,213,83,136,33,60,89,235,10,224,229,34,30,211,73) 220 CALL POKE(XBADDR+178,50,73,106,192,170,33,0,45,13,226,4,45,10,230,17,114) 230 CALL POKE(XBADDR+194,30,74,82,31,34,32,194,171,33,30,93,0,230,248,224,205) 240 CALL POKE(XBADDR+210,45,8,226,43,45,127,226,39,50,74,230,28,208,72,82,29) 250 CALL POKE(XBADDR+226,170,33,30,195,171,33,30,93,1,226,4,194,194,224,241) 260 CALL POKE(XBADDR+241,34,32,139,33,30,211,74,18,72,171,33,30,210,74,224,158) 270 CALL POKE(XBADDR+257,125,30,74,226,166,211,74,50,74,195,34,32,224,185) 1000 CALL EXEC(XBADDR):CALL RELMEM(XBADDR):CLOSE #1
Once you have things the way you want them, you could consider putting it on a Constant Memory cartridge with a CALL PUT(1) so you don't have to keep doing so (and either a CALL GET(1) to retrieve it, or CALL GET(-1) to swap memory contents). This helpfully stores not only the terminal program but also all the subprograms you have loaded into memory. If you do this, I advise unplugging the cartridge if you won't be using the TI-74 for awhile or if you remove its batteries, because once the main AAAs run down the computer may draw on the lithium cell in the cartridge to keep its own memory contents alive and kill it quicker. Don't ask me how I know this.
There are some minor differences in the TI-74 version. As it has no beeper, if there is an I/O error the terminal program will instead turn on some of the LCD's on-screen indicators in an obviously impossible configuration. Press OFF to exit (as with the CC-40 version), after which more information may be displayed. The key shortcuts are still supported (such as CLR for BS/^H), though note that DEL on the TI-74 is SHIFT-7, and because SHIFT-ENTER is the equals sign the TI-74 version moves CR/^M to the RUN key.
Okay, we now have both the CC-40 and the TI-74 talking to a serial port. What can we do with that? Well, as our last stop, I did promise you Gopherspace, didn't I?
Finally, of one-line shells and Gopher clients
And I don't mean a shell or a Gopher client that's a one-liner — we need to think about how to meaningfully present information formatted for a full-size screen on a single-row, 31-column display. Since we're not running the client on the actual computer itself, this gives us some options for what's effectively server-side rendering, but we're still constrained by the limited amount of text we can display at any one time.
Paging is unavoidable, but because Gopher menus and text documents are line-oriented we can do so line-by-line. Also, since both Memo Processor and our hacky miniterm can scroll the screen, we can use this mechanic for communicating longer continuous lines to the user (the visual effect is even heightened at slower bit rates, which is a helpful side effect). So that we can more efficiently move through a document, we can also allow the user to quickly jump to the next line instead of having to scroll the entirety of a line they might not want to page through. For those sorts of navigational commands we'll just use single keypresses, accepting a text string from the user as necessary.
To hook up our software clients to the serial port, we'll dust off the old usb2ppp tool we originally wrote for the Brother GeoBook, but which can actually run any program over a serial port without having to mess with things like getty as long as you have appropriate permissions to the device. (Linux people, check your udev rules.) For convenience I have included it in the Github project for this article, and it can be compiled on most Un*x-like systems with something approximating cc -O3 -o usb2ppp usb2ppp.c (only termios.h and the basic standard library are required). Both clients are in the Github project.
I've dubbed the gopher client the "GOLM" (Gopher One Line Mangler). It's written in Perl 5 (so there), so you can easily modify it, and it runs under usb2ppp with something like (on my MacBook Air) ./usb2ppp /dev/cu.usbserial-110 300 perl golm.pl which runs it over /dev/cu.usbserial-110 at 300bps. Since this is the kind of thing you'd really want to see live and in action, here's a short video (YouTube link) with the CC-40 running the HEXTIr at 300bps.
The client has a very basic built-in quick menu when you start it (basically the Floodgap gopher and Veronica-2). You can scroll through lines with the ENTER key, or immediately jump to the next line with the SPACE bar, or move backwards with the CLR [backspace] key. The G key goes to a menu link, the L key opens a new location, the B key goes back in your history (resuming at the same line you left) and the Q key quits. Here, we browse the Floodgap menu, then search Veronica-2 for some hot hot Texas Instruments action (using the CLR [backspace] key to move back up to the menu item we want), and read about it in text. This is all live, on real Gopher servers. There you are — Gopherspace on a Texas Instruments Compact Computer 40.I'm pretty patient with my geriatric machines but even considering that I found the interface quite useable even at 300bps. Naturally, when I got it working, I had to see if the idea could work for other things. Is this sort of interface generalizeable? Like, what if we could run a shell prompt this way?
Well! No need to imagine because of course I decided to write up a proof of concept, just to see. It's in Perl too, named the SLOSH ("Single Line Onscreen SHell"), and you can start it with something like ./usb2ppp /dev/cu.usbserial-D3B19P0Y 4800 perl slosh.pl. Here it is, this time on the TI-74 with the StarDust adapter at 4800bps (also YouTube due to size):
With a long USB cable (or a wireless link, I guess), you could do this kind of thing right from your couch. In this example, I listed out my development directory, tried a few real commands, attempted to vainly browse Google's home page with curl (worked sort of), and read a man page (man's man page, the manliest man page there is). There is a very simple prompt which uses your PATH to find utilities (it will print an X if it can't find it so that at 300bps you don't have to get annoyed scrolling Command not found you idjit in longhand all the time). When you're done, type exit.The main advancement you may have noticed here is that spaces were compressed in the output so you could see more on the screen and blank lines were dropped. I have this implemented in the gopher client, too, but Gopher menus are usually written for fixed width fonts and spaces and blank lines are often salient, so shrink-wrapping of this sort is off there by default. The $WIDTH and $SHRINK environment variables (use set KEY=value to change) control the width of the scrolling display and whether spaces should be squished together (tabs are handled properly). If you want to play with this in the Gopher client, set the environment variable(s) before starting golm.pl.
It should go without saying you shouldn't use this as your real shell, or at least not yet, because there are a lot of edge cases to iron out. Necessarily this must connect a pipe to the command so we can paginate it, which some commands aren't going to tolerate well (I also don't hoover up the entire output into memory since we have no idea how big that might be, so you can't back up to a prior line presently), and this may not work properly with some sorts of pipe chains. There is at least code to check for some shell metacharacters so you can still redirect output to a file if you want, but I'm sure it can be fooled, and I'm sure some of you will attempt to.
I wrote both of these clients in a generic fashion such that any pocket or handheld computer with a single line display could use one of these clients: they are not in any way specific to the CC-40 or TI-74. If someone came up with a serial port option for my beloved Tandy PC-4 (there's an idea), you could set $WIDTH to 11 characters (!!) and see how far you get. I'd be interested to hear how this works on other handheld systems if someone gets the idea to try.
To build your own version of the ASMTRM terminal utility, you'll need make, Perl 5, the Macroassembler AS, TIC74.EXE (under Utils/ in the TIFF/TIFF2 distribution), and NTVDM; see the README for instructions. Both Perl clients, the C source for usb2ppp and the assembly source for the CC-40/TI-74 terminal program are in this blog post's Github project. ASMTRM, SLOSH and GOLM are all released under the BSD 2-clause license.
No comments:
Post a Comment
Comments are subject to moderation. Be nice.