Edge of Emulation: Game Boy Sewing Machines

It is common in automotive situations to reserve part of the representable range to indicate error or SNA (signal not available) conditions. If you wanted to reserve the largest positive numbers for error codes, then their hex representation would look something like 0x7FFF, which can be hard to spot in a data stream. If you used the largest negative numbers, then they would look something like 0x8000, which is also not very intuitive.

By using biased representation, you can use values like 0xFFFF to indicate error values.

Of course, you could use something like bit-flags to represent errors, but that wastes a whole bit of bandwidth. Much more efficient to amortize the enumerated value over the whole signal.

You can see a real-world example of these types of signals as defined by SAE for heavy duty trucks here: https://www.scania.com/content/dam/scanianoe/market/au/produ...

In some of my earliest attempts at figuring out these sewing machines did interpret the coordinates as a sequence of movements. However, I was expecting it to be something like:

X1, Y1 -> Move Needle to X1, Move Fabric by Y1, Stitch X2, Y2 -> Move Needle to X2, Move Fabric by Y2, Stitch

I was basically anticipating that each XY pair in the packet would match up to one movement of the needle/fabric. 1st XY pair represents 1st needle/fabric movement, 2nd XY pair represents the 2nd needle/fabric movement, etc.

Not mentioned in the article is the fact that packets for those patterns ("regular" patterns found in Sewing Machine Operating Software, different from the embroidery ones on the JN-2000) also have initial XY coordinates in their headers. They kind of act as a starting position, but they start to "mess up" the ordering. So with X0 and Y0 being those initial coordinates, it looks something like this:

X0, Y0 -> Move Needle to X1, Move Fabric by Y0, Stitch X1, Y1 -> Move Needle to X2, Move Fabric by Y1, Stitch X2, Y2 -> Move Needle to X3, Move Fabric by Y2, Stitch

X0 for most purposes can be ignored, and I believe the hardware does so too (if I'm remembering one of my tests correctly). As such, when emulating these machines, I always started processing at X1, e.g. move by X1 horizontally first, then grab Y0 and move vertically. So that's where having to use the previous Y coordinate comes from.

In my mind, however, it seems a bit convoluted. The initial XY coordinates are weird in that in some cases they're both ignored anyway but Y1 repeats in that situation. If I could change these machines, I'd just get rid of the initial XY coordinates in the header, and start processing XY coordinates as I first described. But that's just my perspective as a programmer and not someone who makes hardware or knows much about designing hardware. If you had me making hardware, umm... things probably wouldn't go well :P

In hindsight, the biased representation should have been obvious to me. In terms of reverse-engineering the pattern protocol, however, I was myself "biased", thinking it should have acted like the JN-2000's embroidery data (with the One's complement). I was way too hung up on that idea that I couldn't see the protocol was clearly using a simple LUT for the values. Others have pointed out that is common not only in Japanese embedded software, but lots of Japanese software in general. As I said, I can see the reasoning behind it, but I'm still more than a little salty about the process I went through (literally hours of frustration) to understand it.

The sewing machine drive turns out to be compatible with the old TRS-80 Model 100 laptop, so retro computer collectors fall over themselves to get one.

If you look at the last few decades you can see horrible ideas executed at a professional level.

Whenever I see a Nintendo Ad, I'm thinking to myself, those poor regional Marketing department have to sell this. Then again, Nintendo knows to advertise primarily to children, so maybe it's not that hard.