LineageOS 14.1 sustaining builds for Moto Z Play and Moto G4

It appears that my LineageOS 14.1 sustaining build service has been well-received. Some folks have pinged me on XDA about adding more devices; there’s still enough space on the web server, so I’ve added them.

Weekly builds for the Motorola Moto Z Play (addison) and Motorola Moto G4 (athene) are at https://lineageos.disavowed.jp/addison and https://lineageos.disavowed.jp/athene.

As with the others, they’re built against the latest LineageOS source tree and therefore incorporate the latest available security patch (currently 05 October 2019).

Please drop me a line if you would like devices added to the build roster. I’ll keep this service going as long as there is interest (and I can afford the hosting bill!)

Posted in LineageOS | Leave a comment

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 lineageos.disavowed.jp. These images are built from a completely unmodified source tree, and that tree is updated nightly to pull in the latest patches.

Enjoy.

Posted in LineageOS | 2 Comments

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.

Posted in seven dreamers | Leave a comment

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, slashdot.org, 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 other 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 (佐藤 誠).

Posted in seven dreamers | Leave a comment

Finished and verified: SMD replacement boards for Horizon HRD+

As previously mentioned, I’ve been working on an old Horizon HRD+ RAMdisk card for the TI-99/4A.

Three of the chips (a 74LS138, a 74LS154, and a 74LS259) had other chips stacked and soldered on top of them, with leads bent out and wires connecting to various places on the board. One chip (the 154) is no longer available in .600 DIP form.

For obvious reasons, I decided to replace these chip stacks with plug-in boards. Each board is electrically equivalent to the chip stack that it replaced, with the exception of the 138 replacement board incorporating errata wiring later published by Horizon. All chips are SMD, and are currently available as HCT.

The Eagle schematic and board files are available here.

All three of these boards designs have been tested and are currently in use in my HRD+.

Enjoy. Hopefully this will help someone out there that’s trying to get one of these working, but is stymied by the stacked chips and/or can’t find a package-exact replacement for the 74LS154.

Posted in Horizon, TI-99/4A | Leave a comment

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

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.

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 96008N1. 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 0.0.0.0 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 heatwave.ddns.net (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.

Posted in Commodore, TI-99/4A | Leave a comment

Upgrading a Super Snapshot V5.xx to 32k

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.

Posted in Commodore | Leave a comment

The HRD+ upgrade design is validated

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 … )

Posted in Horizon, TI-99/4A | Leave a comment

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

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.

Posted in TI-99/4A | Leave a comment

Refurbishing a TI PEB power supply

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.

Posted in TI-99/4A | Leave a comment