> Let me just say that the way these 3 machines handle everything is dumb. There's absolutely nothing intuitive about using 0x14 as a replacement for zero. There's absolutely nothing intuitive about using the previous Y coordinate instead of the next one.
Two simple explanations. The scheme of using some range of values like this where the midpoint represents 0 is known as a "biased representation". One advantage of it is that it's unsigned, easy to convert to an absolute value (just a subtract), but crucially, it can index into a table of linearly increasing values. This is exceptionally common in Japanese embedded programming that I've seen. The values aren't values, they're indexes into a table of subroutines, or loop counters.
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. So I'm not sure what else you were expecting -- the processor could move the feed first, and then the needle, I suppose, but that's independent of how the "points" are specified.
Another benefit of biased representation, is that it makes error values extremely noticeable.
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.
A biased representation makes a lot of sense in this case because the feed mechanism is (by default) moving the fabric through at a consistent rate per needle cycle
-> "0" is 6 in that case and you only need 4 bits to store your index. In addition in hardware it's somewhat common to have definitely non symmetrical ranges, e.g. from -20 to 150 or things like that.
> 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.
"Today, cheap digitized sewing is the norm, but at the turn of the century, Jaguar sparked a sort of revolution by giving consumers affordable and easy to use equipment."
Actually, digitized sewing was already a thing in the USA during the 90s thanks to Pfaff's PC Designer. You connected via your computer's parallel port and uploaded patterns to your sewing machine via their Windows 3.1 software. This is also why Singer's Jaguar copy did so poorly: The American market was already saturated with PCD based patterns.
Even earlier than that. In the 1980's Brother had a sewing machine with a floppy disk drive.
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.
There's a cool python library for machine embroidery called inkstitch, but I love the idea of using a gameboy..
It seems like there could be some interesting ways to teach programming using machine embroidery. So, eg, kids program a pattern, and then get to stitch it onto a hat. Feels like an area with a big pay off right away, but also incredible depth (eg turning an image into a stitched pattern).
X range is absolute - needle position, Y is relative - feed.
I have a sewing machine, Janome calls it Decor Computer which is surprisingly good description. Under the cover it is a feed system, servos and quite a lot of electronics.
Overlocker (serger) on the over hand is purely mechanical marvel.
Nintendo does stuff like this because you can't say No to your boss in a Japanese company.
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.
Yoshi has had a few design tweaks, this looks kinda like an old design (look at the Super Mario World promo art), although it came out in 2000 which makes it bizarre
Two simple explanations. The scheme of using some range of values like this where the midpoint represents 0 is known as a "biased representation". One advantage of it is that it's unsigned, easy to convert to an absolute value (just a subtract), but crucially, it can index into a table of linearly increasing values. This is exceptionally common in Japanese embedded programming that I've seen. The values aren't values, they're indexes into a table of subroutines, or loop counters.
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. So I'm not sure what else you were expecting -- the processor could move the feed first, and then the needle, I suppose, but that's independent of how the "points" are specified.