Don Lancaster

we are faced with the assertion that the washing machine was sending 3.7 gigabytes per day of data

someone asserted that that is an unreasonable amount of data for a washing machine to generate

i'm pointing out an easy way for a washing machine might generate 2000 times more data than that

the fact that the network interface is possibly insufficient to send the data out is irrelevant to the question of whether the washing machine can or cannot generate it in the first place, which is what was being discussed

however, i will point out that if it's using tcp, unless it opens a new tcp connection for each telemetry message, the tcp stack will batch together many telemetry messages into a single tcp segment, probably about 1500 bytes worth

— ⁂ —

of course you can control a washing machine with an 8051, or an eprom and a register clocked from the power line (see jeff laughton's printing press controller at https://laughtonelectronics.com/Arcana/One-bit%20computer/One-bit%20computer.html), or for that matter a mechanical timer or, as i've done, by unplugging the power cord and pulling a rubber drain plug when you think the agitator motor has been running for long enough. but more powerful control systems enable new functionality

historically it is true that manufacturers have used low-spec microcontrollers because more powerful ones were too expensive. today digi-key will sell you a 500-megahertz i.mx rt1010 cortex-m7 from philips/nxp, with 128 kilobytes and dc/dc…

The ZX80/81 used Don Lancaster's "Cheap Video and Lying To the Machine" method of graphics output: http://laughtonelectronics.com/Arcana/KimKlone/BrideOfSon%20KK%20Lancaster.html

Essentially, the CPU executes each line of video, jumping to the start of each line of cells. The video system latches each byte onto a shift register and displays it.

But the CPU is tricked -- NOPs are forced onto its data bus right before it decodes the instruction. So it merrily marches along fetching successive bytes for the video subsystem, without interpreting them.

That is, until a certain bit of the character code is seen, then the CPU is allowed to execute the instruction and terminate the scanline (usually HALT on the ZX). This process repeats over and over for each scanline.

As a result, it's pretty tricky to program animations. There's not much CPU time left for anything while a frame is being displayed.

Probably the second-best fun I ever had was reverse engineering a primitive, discrete-TTL processor and the firmware written for it. These were embedded in some Xerox Diablo daisy-wheel printers dating from the latter half of the 20th Century. And the best fun I ever had was hacking that code to better suit the unique needs of my customer!

I wrote about the Diablos here [1]. The good stuff about the hacking starts about halfway down the page, "the Diablo proprietary processor."

HN has honored me in past by recognizing other items on the site, such as "One-Bit Computing at 60 Hertz" [2] and "the KK Computer - a radical 6502 redesign" [3].

[1]https://laughtonelectronics.com/oldsite/comm_mfg/commercial_diablo.html
[2]https://laughtonelectronics.com/Arcana/One-bit%20computer/One-bit%20computer.html
[3]https://laughtonelectronics.com/Arcana/KimKlone/Kimklone_short_summary.html

Read the article, he's thought of that. There is a trick with two registers in there that allows you to pivot from one bank to another.

More explanation in the appendix on the instruction set. The opcodes are 13, 23, eb and fb:

http://www.laughtonelectronics.com/arcana/BrideOfSon%20KK%20Instruction%20List.html

Bottom of the list.