Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
tree: 30f3ac0d3b
Fetching contributors…

Cannot retrieve contributors at this time

executable file 315 lines (223 sloc) 8.835 kb
== BROTHER ELECTROKNIT KH940 FLOPPY FILE/MEMORY STRUCTURE ============
The machine uses the first 32 sectors on a floppy for storage.
For the entirety of this document, the contents of these sectors
are treated as a single coherent 32kB chunk of binary data with
big-endian format where applicable.
Note that this is not likely an actual file format, rather a binary
dump of all contents in the external RAM memory of the machine.
* When writing about offsets, they are from LAST_BYTE (end of file),
Example: The file address for offset of 0x0120 would be
0x7EDF = 0x7FFF - 0x0120
** When writing about alternatives, it means that contents is not
entirely classified, and could be any of several alternatives.
Further investigation was not warranted because knowing the
exact specification is not necessary to build a functional
disk image.
Offset Bytes Content
0x0000 686 PATTERN_LIST
Contains array of *up to* 98 pattern descriptors.
Unused items are filled with 0x55 except for FINHDR which
also needs XX=0 and PTN_NUM=next unused id.
Patterns are not always stored in linear order, ie the list
may be 901, 904, 902, 903. This happens when patterns are
deleted in the machine.
Content Address (Offset* from header)
/---------------\ <- 0x0000
| Header 901 |
\---------------/ <- 0x0006
/---------------\ <- 0x0007
| Header 902 |
\---------------/ <- 0x000D
/---------------\ <- 0x000E
| FINHDR |
\---------------/ <- 0x0014
/---------------\ <- 0x0015 <- CONTROL_DATA 0x10 points here
. . .
. . .
| Unused memory |
\---------------/ <- 0x02AD
Each entry is 7 bytes:
/ DATA_OFFSET \ / HEIGHT \/ WIDTH \ /XX\/ PTN_NUM \
OOOOOOOO-OOOOOOOO-HHHHHHHH-HHHHWWWW-WWWWWWWW-0000NNNN-NNNNNNNN
\byte 0/ \byte 1/ \byte 2/ \byte 3/ \byte 4/ \byte 5/ \byte 6/
DATA_OFFSET
Format: Binary 16bit unsigned
Data: Offset* to last byte of pattern data
HEIGHT
Format: BCD 3nibbles/digits
Data: Heigh/number of rows
WIDTH
Format: BCD 3nibbles/digits
Data: Width/number of stitches
XX
Always a 0x0 nibble
PTN_NUM
Format: BCD 3nibbles/digits
Data: Pattern number 0x901 to 0x998
0x02AE 31794 PATTERN_MEMORY
Pattern memory is arranged much as a stack and is written backwards
so that the first pattern has it's last byte in location 0x7EDF.
Example:
Content Address (Offset* from header)
/---------------\ <- 0x02AE
. . .
. . .
| Unused memory |
\---------------/ <- 0x7ECF
/---------------\ <- 0x7ED0
| Pattern 902 |
\---------------/ <- 0x7EDB (0x0124)
/---------------\ <- 0x7EDC
| Pattern 901 |
\---------------/ <- 0x7EDF (0x0120)
There MAY be gaps between patterns read from the machine so do not
expect patterns to be arranged end-to-end: USE THE POINTERS!
Unused memory is filled with either 0x55 or 0xAA.
Each pattern is divided into two sections, arranged as:
/---------------\
| PatternDATA |
\---------------/
/---------------\
| PatternMEMO |
\---------------/ <- Offset* points here
MEMO
Each row of the pattern may have a number assigned to it but
it is not significant for operation, consider it meta-data.
Each such number requires one nibble for every row, ie HEIGHT/2.
This is rounded to the nearest byte, hence a pattern
containing 7 rows will have 4 bytes of MEMO data.
A pattern with 10 rows will have 5 bytes of MEMO data.
This can be calculated as:
ceil(height/2) // where ceil() is round upwards
Write as: 0x00
DATA
Each row of the pattern requires WIDTH bits for storage and
this is rounded up to the nearest nibble by padding it with
0-bits until the number of bits is a multiple of 4.
A pattern that has 7 stitches will therefore require 2 bytes
per row. One that has 9 stiches will require 2.5 bytes per row.
This means that rows may not be aligned on byte boundaries.
Patterns are stored top-down, right-left.
This means the pattern is flipped right to left compared to the
actual knitted design once completed.
The number of bytes used to store data can be calculated as:
ceil(ceil(width/4)*height/2) // where ceil() is round upwards
The layout is best described via examples:
0 = pad bits (binary 0)
X = stitch bits (binary 1)
- = no stitch bits (binary 0)
Example 1 - 4x4
---- Row 0: 0x0
-XX- Row 1: 0x6
-XX- Row 2: 0x6
---- Row 3: 0x0
Byte data (hex): 06 60
Example 2 - 6x5
00X----X Row 0: 0x21
00------ Row 1: 0x00
00--XX-- Row 2: 0x0C
00X----X Row 3: 0x21
00-XXXX- Row 4: 0x1E
Byte data (hex): 21 00 0C 21 1E
Example 3 - 9x9
0000 Padding: 0x0
000XXXXXXXXX Row 0: 0x1FF
000X-------X Row 1: 0x101
000X-XXXXX-X Row 2: 0x17D
000X-X---X-X Row 3: 0x145
000X-X-X-X-X Row 4: 0x155
000X-X---X-X Row 5: 0x145
000X-XXXXX-X Row 6: 0x17D
000X-------X Row 7: 0x101
000XXXXXXXXX Row 8: 0x1FF
Byte data (hex): 01 FF 10 11 7D 14 51 55 14 51 7D 10 11 FF
Note for example 3 that there is a nibble of padding before the
design because the design does not round up to an even byte.
0x7EE0 7 AREA0
Seems to be completely unused.
Content with patterns: 0x55 or 0xAA
Content after format: 0x55
Write as: 0x55
0x7EE7 25 AREA1
Contains unidentified bit pattern.
Best guess is working memory for pattern input.
Content with patterns: several repetitions of an n-byte pattern
Content after format: 0x55
Write as: 0x00
0x7F00 23 CONTROL_DATA
0x00 2 PATTERN_PTR1
Format: Binary 16-bit unsigned
Data: Offset* of next byte to be written by next pattern input
Write as: Offset of first byte of last pattern + 1
0x02 2 UNK1
Format: Binary 16-bit unsigned
Data: Unknown, 0x0001 with patterns, 0x0000 after format
Write as: 0x0001
0x04 2 PATTERN_PTR0
Format: Binary 16-bit unsigned
Data: Same as BYTE 0-1 with patterns, 0x0000 after format
Write as: Offset of first byte of last pattern + 1
0x06 2 LAST_BOTTOM
Format: Binary 16-bit unsigned
Data: Alt1**: Offset to last byte of currently active pattern
Alt2**: Offset to last byte of last created pattern
Write as: Offset to last byte of last created pattern
0x08 2 UNK2
Data: Always 0x0000
Write as: 0x0000
0x0A 2 LAST_TOP
Format: Binary 16-bit unsigned
Data: Alt1**: Offset to first byte of currently active pattern
Alt2**: Offset to first byte of last created pattern
Write as: Offset to first byte of last created pattern
0x0C 4 UNK3
Data: Unknown, 0x00008100 with patterns, 0x00000000 after format
Write as: 0x00008100
0x10 2 HEADER_PTR
Format: Binary 16-bit unsigned
Data: Offset to end of pattern header list, 0x7FF9 after format
See PATTERN_LIST memory layout for exact pointer
Write as: 0x7FF9
0x12 2 UNK_PTR
Format: Binary 16-bit unsigned
Data: Unknown offset
This was only present in one file, after a delete had
recently been made. Best guess is mem. move pointer.
Write as: 0x0000
0x14 3 UNK4
Data: Always 0x000000
Write as: 0x000000
0x7F17 25 AREA2
Contains unidentified bit pattern.
Best guess is working memory for pattern input.
Content with patterns: several repetitions of an n-byte pattern
Content after format: 0x55
Write as: 0x00
0x7F30 186 AREA3
Seems to be completely unused.
Content with patterns: 0x00
Content after format : 0x00
Write as: 0x00
0x7FEA 2 LOADED_PATTERN
Alt1**: Contains currently active pattern number.
Alt2**: Contains last created pattern number.
Content after format : 0x1000
Write as: Last created pattern number
[XX]/ PTN_NUM \
0001NNNN-NNNNNNNN
\byte 0/ \byte 1/
XX
Always a 0x1 nibble
PTN_NUM
Format: BCD 3nibbles/digits
Data: Pattern number
0x7FEC 19 AREA4
Seems to be completely unused.
Content with patterns: 0x00
Content after format : 0x00
Write as: 0x00
0x7FFF 1 LAST_BYTE
Contains unidentified byte.
Content with patterns: Different every time
Content after format: 0x00
Write as: 0x02
Jump to Line
Something went wrong with that request. Please try again.