Comment by Shonumi

> The second one, using the previous Y coordinate, well, treat the command stream not as a series of points, but as a sequence of movements. Move needle (X) by this many, move the feed (Y) by this many. It clearly makes sense that the needle would use wherever the feed had moved to last.

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.