The Seven Dreamers fiasco

I wrote this up awhile back, but never got around to hitting the publish button. This is what transpired between Seven Dreamers and myself in the months leading up to their bankruptcy.

In November (2018), I was contacted by a guy recruiting for 7D. They wanted someone to take over factory operations, factory security, and so forth … they wanted to bring the laundroid to the Japanese market by Christmas 2019.

I wasn’t too enthusiastic about going back to China, but the laundroid was a project that I really wanted to see succeed. So I had a bunch of meetings with Shin, Makoto, and their former head of engineering. As the talks continued, the feeling grew that there was something not quite right with 7D. So I asked to have a frank discussion about the state of 7D/laundroid, with special emphasis on intellectual property and manufacturing rights, signed an NDA, and had that meeting.

They’d just received their third (or possibly fourth) round of funding (which seemed really odd for a “startup” that had been around since 2011), they were ready to do a production verification test run at the Chinese factory (Haier), and they just needed someone to shepherd to production ramp.

Little tidbits kept slipping out during the discussions, however. They’d done DVT and EVT (development/engineering verification test) runs at a factory in Japan (Panasonic, not Haier), and wanted to air-drop everything over to Haier and ramp there. This was tried without success at Apple, when they tried to move production of a random iPhone from Foxconn to Pegatron. Most of the gear arrived at Pegatron damaged. Foxconn denied responsibility, but anyone who spent any time at a Chinese contract manufacturer knows what happened.

It turned out that they hadn’t yet signed a contract with Haier. This bit will become rather important in this story a few paragraphs down.

At this point, I was starting to suspect that they were in a bit of trouble. Nobody sane jumps from one contract manufacturer to another after a PVT or two, and especially not without restarting the *VT process. The whole point of the progression is to make sure the factory is actually capable of making the product.

You don’t just throw the schematics and production documents over the fence to the CM and call it good. However, that was exactly what they were planning to do.

Panasonic was apparently very upset that 7D pulled out of the production deal in favor of Haier. They didn’t come right out and say that, but the asks of the role I was being brought in for made it pretty clear that they were not going to bring any production tooling from Panasonic to Haier.

At this point I told them that I’d need full disclosure in order to decide if I was going to take the gig. That’s when the NDA bit happened.

They were going to use an NVidia ARM platform. Their intention was to release the laundroid as an API; 7D would control the hardware and the OS, third-parties would write apps that ran on the laundroid. Ambitious, I thought …

… except for that pesky GPL. Which they had never heard of. Which essentially ensured that they’d have to provide source code for their OS value-add to any customer who asked. They asked why they couldn’t simply ignore that, as “nobody does that”. I urged them to check the license requirements and run it past their lawyers.

They had frozen the hardware design around December 2018. The firmware was in what we’d call a “slushy freeze”. The OS side was admittedly a heap of spaghetti, and was to be refactored sanely. Shin said that they’d run out of time, and were going to ship what they had as v1 come hell or high water, with dev resources being focused on v2. I’m personally unsure that the v1 firmware was anywhere near shippable; they were still asking how they should go about basic things like performance metric transmission … but that’s what they said.

Another highlight of the meeting was that they’d given Haier the rights to market the laundroid in mainland China; 7D intended to market it elsewhere. I further recommended that they go over that contract with a fine-toothed comb. “That’s not necessary,” they said, “they’re our trusted partner”.

I thought about it for a week or so, made a couple of adjustments to the proposed employment contract, they agreed, I signed, and was set to start on 18 March.

Then things started getting really weird. The Friday before my start date, 7D said that they had run into some contractual issues. Shin needed to go to China to meet with Haier, and the timetable was suddenly out the window. They asked me to hold off on starting until 01 June — it probably wouldn’t be that long, but they wanted to worst-case it.

I said that was fine, and I’d stand by awaiting instructions. No worries on my end; the contract said I was employed effective 18 March, they didn’t amend it, so I was taken care of … I thought. I was going to negotiate back-pay after I actually started deploying to China.

Not long after, they sent a one-page to me via the recruiter saying that they couldn’t hire me. You can read it at

That was, of course, extremely unacceptable. I demanded a meeting.

We met on 10 April. Only the executive secretary (Makoto Sato) attending. The first half of the meeting was me determining what in fact had happened (and getting gibberish in return), the second half me explaining that they couldn’t just do that, and giving them until 26 April to work out a deal.

“Sure, 26th April, that’s fair!”

They’d already filed for bankruptcy at that point, although Makoto denies it in the recording I made of the meeting. I thought I was safe because Japanese bankruptcy simply can’t happen that fast.

So I waited. I’d given up on them, tried to reconnect with recruiters, and abided by my NDA.

Yahoo Japan reported they’d declared bankruptcy on 23 April. I sent them an email demanding a response upon pain of legal action, they said “nope, talk to the bankruptcy trustee, and by the way, you weren’t an employee”.

I talked to my lawyer, who said a) they’re wrong and b) you’ll get nothing out of a bankrupt company. So I posted the situation on LinkedIn, and the trustee reached out to me at 0200 the following day (a Saturday!), inviting me to join the mass of creditors.

I’ve got email to back most of this (the recruiter helpfully cc’ed me on his discussions with 7D).

Posted in seven dreamers | Leave a comment

LineageOS 14.1 Sustaining Build for HTC 10 (pme)

By request, I’ve added the HTC 10 (pme) to the LineageOS 14.1 “build rooster”. Same deal as all the other builds — generated weekly, available at

As a side note, I’d like to publicly thank Adam_J_T from the XDA forum for his very kind donation toward defraying server hosting costs.

Posted in LineageOS | Leave a comment

Refurbishing a Quadra 700

I picked up a Quadra 700 on eBay. Although it powered on out-of-the-box, it needed a bit of upgrading to be useful. I pulled together information from a number of external resources, and am writing it up here in the hope that it’ll save someone else a few hours of research.

Here’s what you need:

(I’ll insert spinup guidelines here as time permits)

Posted in Apple, Macintosh (m68k) | Leave a comment

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 and

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


Posted in LineageOS | Leave a comment

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

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 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.

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