Skip to content

LineageOS 14.1 security patch builds

I've resurrected a few of my older Android devices. They're not supported by current LineageOS releases, and I really don't like running gear without the latest security patches for obvious reasons.

Completely understandably, LineageOS sundowned 14.1 builds quite some time ago. Security patches still show up in the source tree, though, with the intention of enabling end users to build their own updated images.

So that's what I did. I've rigged a build infrastructure to produce up-to-date images each Saturday night for the Nexus 5 (hammerhead), 2013 Nexus 7 (deb and flo), and Asus ZenBook 8.0 (P024, both Z380KL and Z380KNL variants).

I reckon there are others out there that have similar needs, so I've made them available at These images are built from a completely unmodified source tree, and that tree is updated nightly to pull in the latest patches.


Contacted by the bankruptcy trustee for "seven dreamers"

It appears that posting a quick precis on LinkedIn had immediate apparent results. The bankruptcy trustee sent me an email at around 0200 this morning.

"It comes to our attention that you have a claim against Seven Dreamers Laboratories, and (we) have started investigation about your claim."

Included were a copy of the bankruptcy notice and an application for creditor claim.

This is getting a bit interesting.

Legally I am an employee of "seven dreamers"; however, in an email dated 23 April the "executive secretary" of 7D stated that the trustee had been consulted and that I did not have a claim.

After I went public, posting my contract and the attempt at cancellation, suddenly I'm invited to file a claim.

Which I will do.

Coincidentally, I spoke with a doctor today who knew of 7D. He had interesting things to say about the "Nastent" product. I'll post more about that, the Laundroid, and the Panasonic/Haier deal tomorrow.

seven dreamers, Haier, laundroid, Shin Sakane (阪根 信一), and Makoto Sato (佐藤 誠)

So ... "seven dreamers" filed for bankruptcy on 23 April 2019. You might have seen it on Yahoo! Japan,, or engadget.

They hired me on 28 February as a director to shepherd the Laundroid (styled "/laundroid") to production ramp in time for Christmas. They tried to illegally cancel the accepted contract not too long before they filed.

They never paid me. They didn't pay their employees or creditors, either. They're now in receivership and, according to my lawyer I have no recourse but to join the creditors and receive perhaps 10% of what they owe.

I have quite a bit to say on the subject, and I will over the next few days. They didn't have a shippable product for v1, what they did plan to release violated the GPL, and lied repeatedly about contracts and capabilities.

NDAs do not apply to bankrupt entities.

I invite any "seven dreamers" employees to contact me with their stories; I'll anonymize them and post them here.

Executive summary for now: don't join any company that has anything to do with either Shin Sakane (阪根 信一) or Makoto Sato (佐藤 誠).

Real instructions on getting a Lantronix UDS-10 serial-to-Ethernet bridge working

CommodoreTI-99/4A (edited to add data from IM for accuracy -- want this to be correct and complete)

The Lantronix UDS-10 is rather popular among the AtariAge TI-99/4A crowd. It's basically one port of a Cisco 2511; it's a bidirectional telnet-to-serial bridge. The TI folks use it to connect to the outside world, because it is extraordinarily unlikely that the TI will ever get even a ten-megabit PEB card, due to the screwed-up interrupt handling on the TI. It's also a fantastic alternative to the Commodore 64NIC+, without any of the compatibility problems that go along with it.

A fellow named "Omega" (or "Ohm"; real name elided here) put together a document that purports to describe configuration. I'll be right up front here and say that I don't care much for "Omega" (and he doesn't like me much, either). His antics were a large contributing factor to my departure from AtariAge. I see him as an "ideas man" ... not a guy that actually produces anything, but constantly chirps up with "wouldn't it be cool if somebody did X" and doesn't understand anything about engineering or technical design. I also suspect that he was the author of an anonymous nastygram to yours truly awhile back; I can't respect anyone who hides behind anonymity while engaging in armchair psychology.

His UDS-10 document, which I will not link to here, is a good example of that. It's about 80% correct, but like most things that Omega "creates", that 20% will kill you. Not a word in the document about what one would do with a UDS-10 fresh off of eBay, with completely incorrect network configuration. No, Omega would have the UDS-10 purchaser install a Windows program to search for the unit, then try to configure it via telnet.

As usual with things that Omega writes, that'll only work in specific limited cases (i.e., the eBay seller resets the UDS-10 to factory default before shipping) and doesn't mention the existence of newer/better firmware. But no worries, as the official documentation and firmware is still available from Lantronix. I've put up a mirror here, but here's the general gist of what you want to do:

  • Do not buy a UDS-10-IAP. It will not work properly due to fatal firmware bugs. You want a plain UDS-10. Thanks, IM, for the pointer -- I didn't know there was a difference between the two.
  • Plug the UDS-10 into a serial port (USB, onboard, whatever) connected to a real computer running a real terminal program. Settings are 9600 8N1. Hold down the "x" key ...
  • ... while attaching the UDS-10 to power. That'll force the UDS-10 into setup mode on the serial interface.
  • Hit 0, and set it up for an IP address of to make it do DHCP. Or set the proper IP address for your LAN. I assume that you know your own network better than Omega does.
  • Set whatever other parameters you want here. The important one is the IP address. Once back at the main menu, save and exit.
  • If you are doing DHCP, watch your DHCP server logs for the DHCP lease. If you're doing static IP, then wait about a minute for things to stabilize.
  • Grab "ltx5805.rom" from either the official Lantronix site or my mirror referenced above.
  • tftp to the UDS-10 IP address. Set binary mode. Execute "put ltx5805.rom 3L". The UDS-10 will upgrade to the latest firmware and reboot.
  • Hold down the "x" key in the serial terminal while rebooting to get back into setup mode.
  • Choose option 1.
  • Port speed maximum 2400 for TI (9600 for Commodore 64 over user port with UP9600 and so forth), I/F mode 4C, flow 02, port 0, connect mode D6, auto-increment. That's mostly the same as Omega's doc, except you want to use 0 for the source port (to randomize) and auto-increment (again, to randomize).
  • That should do it. Read the official docs for more information on how to use this device; don't rely on a random shiny PDF floating around AtariAge as an official source-of-truth.

    When you get your unit working on your TI, please patronize IM's resurrected HeatWave BBS at (port 9640). It's all well and good to telnet into your *NIX boxes to transfer files, but the real fun is the BBS experience.

    (Omega, I replied to your comment via the email address you broadcasted on AA. I'd like to continue that dialog with you, but lack of response tends to support my hypothesis as set forth in the first few paragraphs of my email. The ball is in your court)


    TI-99/4A Readers may remember my attempts to do an in-console 32k upgrade, which failed with two separate techniques and I thought I'd killed the board.

    Readers may also remember my recommendation to replace the console power switch as soon as one receives a console.

    Turns out that I should have heeded my own advice. I finally got around to looking at the "dead" board. It powered up. Then it didn't. Then it did again, three times in a row, then refused to turn on.

    Swapping the power switch with a DPDT rocker fixed that. I removed the 4116s while I was at it, because with a F18A they only consume power and generate heat.

    So, closure. There's a rule in this house: either it works, or is in the process of being fixed, or it goes in the trash. I can now justify keeping this console to the wife. And this console has the known-good 16-bit 32k expansion, not the 8-bit possibly-misdocumented expansion, so I can swap it for the unexpanded console and get stuff done faster.

    Upgrading a Super Snapshot V5.xx to 32k

    Commodore So I've been in China for the past several weeks, trying to get ${EMPLOYER}'s crash production project back on track and mostly failing.

    Having returned to Tokyo for a couple of days' rest, I'm not feeling up to doing anything heavy on the TI EE front. Feeling that I needed to do *something*, though, I decided to take a look at upgrading one of my Commodore bits-and-bobs.

    Freezer cartridges were very popular in the Commodore ecosystem in the mid-nineties. A lot of people (mostly Europeans) swear by the Action Replay cartridge, but I always preferred the Super Snapshot. It was more geared towards the cracker than the Action Replay (which was geared towards the "infinite lives" gamer demographic).

    I still have an original Super Snapshot v5.22 cartridge. I've left behind the original console, drives, and 100% of my software library over the years ... but somehow, that cartridge was always packed away somewhere in my seabag.

    The Super Snapshot came with 8k (in the form of a 6264) on board, and was upgradeable (via returning it to the vendor) to 32k. I used the multimeter on a few traces, and determined that not only could it be field-upgraded, but it was built to use the 62256 as an upgrade.

    Those who have been following this 'blog have probably figured out that I have roughly a billion 62256s lying around as part of my TI HRD+ experiments. So I fired up the soldering iron, unrolled the desoldering braid, and had at it.

    Pro tip: the original manufacturer didn't clean up the left-over flux from the original FATP process, so it's best just to clip the 6264 off of the board, pull the leftover pins, and clean up the holes with the braid. Scrub well with isopropyl alcohol, let it dry, and put a 28-pin socket in.

    There's an unsoldered jumper block right next to the SRAM chip marked J1. It's hard-wired for a 6264. Cut the trace between position 2 and position 3 of the jumper block, put a wire between position 1 and position 2, and emplace a 62256. I recommend the Alliance CMOS 62C256, but whatever is available is fine.

    If you're wondering what J2 on the board does, it's for the C128 kill switch. If you have a C128 and you want to keep it from going into C64 mode when the cartridge is plugged in, cut the trace between the poles on J2 and use a switch to bridge the now-isolated poles.

    So there you go ... if you have an original SS, this is how you upgrade it to 32k. Hope this helps someone.

    The HRD+ upgrade design is validated.

    TI-99/4A The final piggyback board arrived today; this one eliminates the open-collector 74xx156 with a 74xx155 and a 74xx08 to handle what the pullup resistor used to do.

    Everything works well, with one caveat: I never could get reliable operation out of the low-power CMOS 6264 handling the DSR. The old [HN]MOS 6264 that came with the card did fine, but the new Alliance CMOS part kept throwing errors up towards the top of the memory space.

    It could be due to the HRD+ build instructions telling us to wire A14 into pin 1 shared by all of the memory chips. This is a non-connected pin on the 6264, but it's possible that Alliance's part doesn't like a fluctuating input.

    It could also be due to the funky pullup/pulldown scheme on one of the two chip selects on the 6264. The chip turns on when one is high and the other is low, and turns off when the logic levels are reversed. The HRD+ does that by feeding Vcc through an LED to the non-inverted CS pin, and then grounding it through a resistor. I replaced that with all sorts of schemes (feeding that CS through the signal that handles the actual RAM disk, going to a two-resistor approach, etc) but nothing was stable ... and I didn't have a spare CMOS 6264 to test. My TL866 swears that this 6264 is okay, so fine ...

    ... I have a bunch of low-power Alliance 62256 chips. Standby current draw is roughly the same as the Alliance 6264, the package and pinout is mostly the same, and most importantly it has only one chip select pin. Ground pin 1 (A14) and pin 26 (A13), attach pin 20 (!CS) to Vcc via a pullup resistor to kick it into power-saving mode when the switch is flipped, and suddenly everything worked fine.

    I'll post the piggyback boards (schematics, PCBs, and instructions) when I get a moment over the next few days. The design is validated, so I don't see any reason not to do a full layout and release that as well. This layout will require a 62256, because I won't release a variant that I couldn't get to work myself.

    So ... we now have a vetted multi-megabyte RAM disk for the TI-99/4A that can be built by regular humans using currently-available parts. Total cost for the chips should be under thirty bucks; the PCB costs however much the fab charges you. You can choose to upgrade an existing HRD+ or build a new one, your choice.

    (I'll also throw in a 32k expansion daughterboard PCB that plugs into the DSR chip socket. That's totally untested, of course, but it should work ... )

    Notes on building a 32k RAM expansion for the TI PEB

    TI-99/4A I finally gave up on the OEM TI 32k RAM PEB card. It just wasn't reliable ... it passed all diagnostics that I could find, but it wouldn't pass the acid test -- function-6 GROM verification in Gazoo's excellent Extended BASIC Suite v2.7.

    I've previously detailed attempts to build a working in-console 32k expansion. The 8-bit expansion, although popular, is too invasive for my tastes; the 16-bit expansion killed my main board for reasons as yet undetermined and has even more wires than the 8-bit version.

    Since I was resigned to an 8-bit design, and I had a spare PEB proto board from Ksarul, I decided to build an in-PEB replacement using a static RAM that used +5VDC only (instead of the OEM dynamic 4116s that need +12, +5, and -5).

    Luckily, Thierry had already done the design work which can be found here. There are a few things that need changed or clarified to make this go, though.

    First, the address connections to the RAM chip are A1/3/4/.../15 (circuit side) to A13-A0 (RAM chip). Note that A2 is not connected, because it's used with A0 to derive A14. This is not explicitly stated in the instructions.

    Second, it's easier to connect A0 and A2 twice to the four-input AND gate rather than wire two of the inputs to +5VDC. Those signals are buffered; even if you're using TTL parts instead of CMOS, you're still not going to have a problem with fanout.

    Third, Ksarul's PEB board expects a non-inverted input to drive the board activity LED. Thierry's design uses an inverted input (the RAM chip select) to drive the LED. There's three ways to work around this: rework the board to put the LED in parallel to the 2N3904 rather than in series between Vcc and the transistor collector, or add a transistor to invert the input along the lines of the first option, or add a 74xx04 to invert. I had a spare 74HCT04, so I opted for the third option. Connect RDBENA* to pin 1, connect "LED DRVR" to pin 2, and you're good to go. Ignore the gunk from RAM !CS through a '125 to the LED.

    (note: on Ksarul's PEB board, RDBENA* is isolated from the common PEB RDBENA* by the 74xx125 buffer. It's safe to tap the signal from this location; you won't be picking up signals from anything else in the PEB)

    (further note: the PEB board handles all of the '125 bits for RDBENA* and the '245 !CS. The connection that would have been !CS from the RAM chip to CS* should now be from RAM !CS to the board's RDBENA* pad; the board's '125 will handle the rest. You can ignore the bottom part of the schematic that involves OE*, the '125, and RDBENA*)

    Fourth, Ksarul's PEB board has a slight error. The direction pin for the 74xx245 data buffer is connected to MEMEN*, but it should be connected to DBIN. Fixing this requires cutting the trace and running a jumper wire, but it's not difficult. The LED polarity as silkscreened on the PCB is reversed, too ... the flat side should be on the bottom, not the top.

    Fifth, there should be a 4.7k ohm resistor between G1 (pin 6) of the 74xx138 and Vcc. You can also opt to connect G2B (pin 5) directly to ground (I did).

    Don't forget to put a 0.1uF decoupling cap between the Vcc and ground pins on every chip.

    Anyway, that's it. It's trivial to build a PEB-based replacement for the 32k RAM expansion if you have a Ksarul PEB proto board. I highly recommend doing this if you have a few free hours; the power savings alone are worth it.

    I may make Eagle schematics and a board file available for download in the near future.

    Building the HxC command-line tool

    TI-99/4A As previously noted, I've replaced the floppy drives in my TI gear with HxC floppy emulators.

    There are both GUI and command-line tools to convert floppy disk image files to the HxC's native HFE format. I needed to implement proper 80-track DSSD support for my TI floppy images. The build framework for the CLI tool is sort of a mess; to make things easier, I cloned the git repos (four of them!) and refactored the code as follows:

  • Changed libraries from shared to static by default. There's no reason whatsoever to have shared libraries for a single command-line tool (and I'd also argue against the need for shared libraries when building both CLI and GUI versions)
  • Changed the framework to build out of the repository as cloned from git. The original author appears to still be using subversion on SourceForge; as such, the project cannot be built straight from the repo without Makefile modification
  • Removed a few Linux-isms to allow this to be built on FreeBSD (and, by extension, pretty much any POSIX platform)
  • Use my rewritten TI V9T9 image conversion logic. This derives the target disk format from the geometry embedded in sector 0 of the HFE image, rather than guess based on image size. This is much more reliable than the logic in the mainstream tool, and has not yet been merged into the original author's codebase
  • Here's how to build:

  • mkdir hxcfe
  • cd hxcfe
  • git clone
  • git clone
  • git clone
  • git clone
  • cd libhxcadaptor/build/
  • make
  • cd ../../libhxcfe/build/
  • make
  • cd ../../libusbhxcfe/build/
  • make
  • cd ../../HxCFloppyEmulator_cmdline/build/
  • make
  • Enjoy.

    Refurbishing a TI PEB power supply

    TI-99/4A I've seen a number of people recommending replacing the older forty-ish watt TI PEB power supply with AT(X) power supplies.

    As with most stopgaps/workarounds that the TI community has come up with, I'm not sure that's a good idea. The original PSU emitted +16VDC, +8VDC, -16VDC, and +5/12VDC for the stuff in the drive bay, and the PEB cards are expected to have on-board regulators to produce the desired voltage.

    An AT(X) PSU, on the other hand, emits +12/+5/-12VDC. The folks that have done the conversion recommend that the original +8 and +16 be wired into the +12 rail, and the -16 wired into the -12 rail. That will work if and only if the voltage regulator on each card will go into bypass/shunt mode when the input voltage is below the regulator's input voltage floor (typically about two and a half volts over the specified output voltage).

    If the card regulator goes into bypass mode, it might as well not be there at all. The entire point of the per-card regulator scheme has been negated -- you've lost the protection afforded by the onboard regulator, and are at the mercy of the PSU. The only case where this isn't an issue is on a +5VDC-only card, and if you haven't replaced the 7805s on the cards with switching equivalents, you'll see a dramatic increase in heat generated by the regulators.

    Therefore, if one has an ailing PSU in a PEB, I reckon it's better to refurbish the original PSU rather than replace it with under-specced voltages.

    The PEB PSU is pretty simple. It uses a gigantic multi-tapped transformer to step down the voltages to somewhere around nominal, simple full-wave bridge rectifiers and a few large electrolytic capacitors to smooth things into DC, and a couple of 78xx regulators to deliver the +5 and +12VDC. The schematic is here.

    First, replace the 7805 (in a TO-220 form factor) with a switching equivalent. I used CUI Inc's V7805-1000, which handles one amp without breaking a sweat. It's probably better to get the -1000R, which has longer leads for mounting flush against the PCB, but the non-R leads are long enough to fit as well.

    Second, replace the 7812 (in a TO-3 form factor) with a switching equivalent. These are harder to find ... I used the EzSBC PSU6, which is also good for one amp. Do not forget to put the screws back into the mounting holes; if you don't, the regulator won't be grounded and will go into bypass mode. That'll put an unregulated +16VDC onto the +12VDC rail, with bad consequences.

    Third, replace all of the electrolytic capacitors. All are axial-mount 35V polarized units; you'll need two 4700uF, two 3300uF, two 1000uF, and two 47uF. The replacement 35V caps are probably thinner than the originals (mine were), but if you go up one more size to 50V, the physical dimensions should match pretty closely.

    Fourth, replace D1 through D6 (i.e., all of the diodes) with 1N5401s. D3 and D4 are already 1N5401, but they're at least thirty years old and are near or past their service lifetime. The other diodes were 1N4002s, which are the less-beefy cousin of the 5401 (the 4002 can handle one amp, the 5401 is good for three amps). The 5401s are a bit bigger than the 4002s, but they'll fit into the mounting holes with a bit of elbow grease.

    While you're in there, you might consider replacing the original fan (running on 110VAC) with a normal PC fan (running on +12VDC). The size is standard. Wire that into the regulated +12VDC rail wherever convenient. Instructions can be found here.

    That's pretty much it. Plug the P1 cable from the transformer back into the regulator board, turn the PEB on, and verify the voltages at the P2 and P3 connectors against the schematic referenced above. If everything matches (the unregulated voltages will be high, because there's no load), then you're done.

    This should return your PEB PSU back to original strength.

    Replace your #$%& console power switch!

    TI-99/4A If "the solder joints are always bad" is rule #1 when repairing old gear, "the power switch is worn out and must be replaced" is rule #2.

    The TI-99/4A in-console power supply has a DPDT switch that handles +5VDC and +12VDC. The switch internals will wear grooves in the contacts over time. After nearly forty years, that power switch is going to be grumpy as hell. It will not reliably make nor keep contact when energized, and should be replaced. Desolder the sucker, take it down to your local parts house, and look for something that is close enough to work.

    The closest replacement I could find in Akihabara was a non-PCB-mount switch. The actuator is a bit taller than the original, and I had to bend the mounting lugs out ninety degrees to make contact with the PCB pads, but the console in question now powers on reliably. The only thing missing is the tactile "thunk" when switching it between "on" and "off" positions, but that's an aesthetic thing that can be ignored.

    The TI-99/4A console power switch is like a VW shift hanger -- if you haven't replaced it, or even looked at it, then it is bad and will cause problems. Just replace the (redacted) thing as soon as you open up the console, and you'll save yourself a lot of heartache down the road.

    Well, it wasn't the 32k card.

    TI-99/4A I spent an unreasonable amount of time trying to get an in-console expansion working. I'd previously modified my main console with the 16-bit mod, which worked fine, and I thought I'd give Tursi's scheme a test drive.

    I wasn't successful. I used the PCB that fellow (name forgotten) had put up on OSHPark, and I noticed the following:

  • One of the address lines is wrong. The address line on pin 21 is documented as going to pin 11 of a 74xx74, but it actually needs to go to the same pin on a 74xx00 right next to it. This is a typo in Tursi's instruction PDF; I'm surprised that it wasn't pointed out by anyone.
  • The board layout isn't smart about +5VDC or ground. It just slavishly replicates the instructions in the PDF, and omits decoupling capacitors. The guy that put this together had two layers to work with (because, well, OSHPark), but used only one.
  • The board layout isn't smart about mapping the RAM address pins to the CPU. If it were me, I'd replace the first eight wire pads with a header and solder that right onto the CPU, rather than run a bunch of wires.
  • Once I'd fixed the pin 21 issue, it still failed the Corcomp expansion test (whereas the 32k expansion in the PEB, perversely enough, passed before I started this project). The error address was random, and based on the diag results it looked like the 8->16 translation was glitching (expected FFFF, saw FF05, and the error was always in the low byte).

    I ripped it out and replaced it with the old 16-bit modification, and that killed the board completely.

    I have a (third) spare parts machine, and I swapped the main boards. Now everything works, modulo having to wait about thirty seconds after the PEB powers up before powering the console because I haven't fixed the new HRD+'s powerup reset bits yet.

    So the problem wasn't in the 32k card, it's somewhere in the console. I'll restore it back to non-expanded configuration and do the desoldering/replace routine when I have a day to kill.

    My suspicions are, in descending order of probability based on how things broke:

  • Either the '244 or '373 are slightly toast.
  • One of the 4116s on the mainboard is busted and is screwing with the address bus. The right thing to do is to pull them and try again (everything has F18s), but I was lazy. (pulling the 4116s saves an incredible amount of power; recommended for all F18 consoles)
  • The 9900 is glitching an address line.
  • What I really need to do is design a 16-bit RAM expansion piggyback board, along the lines of what I did for the HRD+. Stacking chips and running wires everywhere in a EF-noisy environment is never a good idea.

    Notes on reworking a low-serial-number HRD into a HRD+

    TI-99/4A Along with the Horizon 4000 (that I repaired and documented in the previous entry), IM also sent an original HRD. It uses the same board as the HRD+, but had a bit of extra glue logic and was missing the '259 and '138 stacks.

    It was populated with a number of stacked 6264s, and had chip-enable wires flying everywhere. I intend to use this board as a test bed for a one-megabyte daughter board (I'm awaiting delivery from the fab), but in order to do so I figured I should bring it up to HRD+ specs.

    That entailed removing U10 (and its socket), the socket from U1, and desoldering a stacked '138 from U19. After that, the 138/259/154 stack-replacement boards slotted right in. I fully-populated it with 62256s, reworked the power regulator as detailed for the Horizon 4000, connected the wires between U1, U10, and the various chips per the HRD+ construction manual, and fired it up for a test.

    Nothing. The ROS config utility didn't probe it. MEGTEST would test the DSR RAM chip (the sole 6264 left on the board), but would lock up halfway through the tests.

    It took about a day of dinking around with it, comparing the wiring against my other HRD+, and pulling chips for test in my TOP3000 (all chips passed) ... before I remembered rule #1 for repairing mid-eighties homebrew equipment: the original solder job is always going to be marginal.

    I touched up (and, in some cases, resoldered) all of the pads for the address glue logic. Suddenly, ROS config could see the card. The DSR test would still crash halfway through, so I replaced the original 6264 with a new CMOS workalike. Not only did that not fix the crash issue, but it also started throwing read errors during the bit verification test. My best guess is the weird germanium-diode-driven chip-select logic that turns on the 6264 is generating a signal that's marginally bad.

    It turns out that the 32k expansion card in the PEB has at least one bad chip. MEGTEST runs from expansion RAM. Removing the 32k expansion and swapping the console for a unit that has a known-good internal 32k expansion fixed the MEGTEST crash issue. All tests passed, the new HRD+ is happily chugging along at 384k, and all is well.

    Rather than troubleshoot the 32k card, I'm going to replace it with an in-console expansion. There's no point in replacing a slew of 4116s; they're weird (need +12V, +5V, and -5V), obsolete, and power-hungry. Tursi's two-chip expansion scheme costs less than ten bucks; I'm going to go that route.

    A side note: it's possible to rework the HRD+ to host the 32k expansion. There's a writeup on the site; the author claims that it's for the HRD 2000, but the writeup and board pictures are obviously for the HRD+. There's a few discrepancies and/or errors on that site. I wrote about one in a previous entry here.

    I did send an email to the guy running the site about the flex card issue. No response, which didn't come as a surprise as the site hasn't been updated since 2010. Hence, I document the issues here.

    Anyway ... that's it for Horizon stuff until the one-meg board arrives from the fab. The design should be able to address four megs directly (with 512k x 8 SRAM) while eliminating the need for any '154s. I'll post the results here when everything is tested.

    Refurbishing a Horizon 4000 RAMdisk

    TI-99/4A Ksarul and IM sent over a Horizon 4000 that wasn't working right. To wit, it wouldn't be detected at all by what passes for an OS on the TI-99/4A.

    I got it working, and it didn't take too long. Along the way, I noticed some odd things about the design. My notes are below, in case someone else ends up working on a similarly broken board.

    It turns out that U9, which was specced as a 6264 on the schematics, was a 62256. Although the 62256 passed a quick test with the TL866, it wasn't working with the 32/8 jumper in either position (and, per the documentation, that jumper was the selector between a 6264 (8) and a 62256 (32)).

    There's bad weirdness going on with the 32/8 switch. It's on the schematic right next to R3, and if the schematic can be trusted, that jumper merely switches the power source for one of the chip selects on the CSR RAM from mains to battery. You don't want that. That doesn't switch pin 26 from a chip-enable (6264) to an address line (62256). Leave the jumper at the 8 position to keep it wired to the main voltage rail and avoid unnecessary battery drain ...

    ... the other CS (or A13 if you're using a 62256, which is what the aforementioned 32/8 switch should be frobbing) is more or less held high by the power LED, a diode, and a resistor before it hits the base of Q2. That's not a reliable way to do this. I think it works on a 6264 because TTL is voltage-tolerant, and chip-select is really tolerant. I can see a 62256 address line having issues with this. If I were redesigning it, I'd wire it high to the main voltage rail through a dedicated 4.7k resistor and depend on the !CS2 mentioned in bullet point one. No need for a 32/8 switch if that is done.

    The '156 that is ultimately handling the !CS2 signal is open-collector, so it needs to stay connected to the main voltage rail. That bit I wouldn't change.

    The power circuit needs to have R9 removed, and both CR10 and CR11 replaced with wires. This achieves several things: makes the circuit compatible with modern switching 7805 replacements, removes the voltage drop from the main power rail, and eliminates the need to add the same amount of voltage to the regulator's ground connection to compensate for the previous diode. CR12 handles any direct backwash from the battery power circuit (+5B), so CR10 and CR11 are both unnecessary and harmful.

    After replacing U9 with a 6264 and moving the jumper to the 8 position, the RAMdisk fired up fine. Everything past that was either cosmetic (fixing the power circuit so that it didn't shed scads of waste heat) or investigative. These are weird boards, designed weirdly, and there's room for improvement. For example, the 74HC154s should not be HC, they should be HCT and they should not be on the battery-backup circuit.

    I'm sure there's more weirdness in the design, but that's good enough for one post. Hope this helps someone else trying to fix one of these boards.

    No more AtariAge.

    TI-99/4A Well, there I was basking in the warmth that was the TI-99/4A AtariAge forum. I felt comfortable, I was among friends (some of whom I wouldn't like in real life, I think, but at least civil people).

    However, I forgot rule one for non-Americans: don't point out the decline of the American civilization to Americans, even if you are or used to be one. It never ends well.

    So, to avoid more bloodshed, I've withdrawn from AA. I'm pretty turned off on the whole TI-99/4A scene at the moment; if I do any more hardware work on this machine, I will post here rather than AA.

    Sorry, Ksarul/IM/Tursi/ralphb. You guys are okay. I don't much care for the country that two of you live in (three, if we count China), but that doesn't (or, rather, shouldn't) affect our friendship.

    Your cohorts at AA, however ... I don't care to associate with people like that.

    You guys can always reach me here, or via email.