about summary refs log tree commit diff
path: root/converter/pbm/mdaspec.txt
blob: a93c0af78f546f8f89402d1da9d1e8506ef25f30 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239

         MicroDesign 3 page (.MDP) and area (.MDA) file specifications
                                       
   This publication and all information contained herein is Copyright ©
   Creative Technology 1992. This information carries no guarantees of
   accuracy or liabilities on the part of either Creative Technology or
   myself.
   
   A hard copy of this document (with far better artwork) is available
   from Creative Technology, 10 Park Street, Uttoxeter, Staffs ST14 7AG,
   creative@net-shopper.co.uk.
   
   [Note: throughout this file hexadecimal numbers are represented as
   #nn; 'one pixel' refers to one PCW screen pixel, ie. a MicroDesign
   half-pixel; 'word' format indicates a 16-bit word stored with the LSBs
   first]
   
The MDA (MicroDesign Area) file formats

   There are two different MDA file formats. The earlier MicroDesign2
   format uses a simple compression technique to reduce continuous areas
   of white and black, while the more recent MicroDesign3 format uses a
   more sophisticated technique which generally results in smaller disc
   files.
   
   MicroDesign2, ProSCAN and Tweak (versions 1 and 2) can only load and
   save the earlier format, but either format may be loaded or saved in
   MicroDesign3. In MD3, the filetype is detected automatically on load,
   but the user must choose whether to save in 'AREA2' or 'AREA3' format.
   
   The format is identified in byte 21 of the initial file 'stamp' record
   - for a MicroDesign2 area this byte is "0" (#30), whereas for a
   MicroDesign3 area it is "3" (#33).
   
   When loaded into memory and uncompressed an Area file can occupy up
   the 720k of data, but its size on disc is indeterminate due to the
   compression used. Because of the compression it is not possible to
   perform 'random-access' reads or writes to the disc file - it must be
   read sequentially in order correctly to decompress the data.
   
   The older MicroDesign2 Area file format is as follows:
   
Bytes 0..127: file 'stamp':
    0 -   3 (#00 - #03)  .MDA            File Type  (4 bytes)
    4 -  17 (#04 - #11)  MicroDesignPCW  Program Identifier (14 bytes)
   18 -  22 (#12 - #16)  v1.00           File Version  (5 bytes)
   23 -  24 (#17 - #18)  CR,LF           ie. 13,10 decimal (2 bytes)
   25 -  31 (#19 - #1F)  xxxxxxx         User Serial No (ASCII) (7 bytes)
   32 -  33 (#20 - #21)  CR,LF           ie. 13,10 decimal (2 bytes)
   34 - 127 (#22 - #7F)                  fill with zeroes (#00) (94 bytes)

Bytes 128..: file proper:
  128 - 129 (#80 - #81)  Height in Lines (multiple of 4) (word)
  130 - 131 (#82 - #83)  Width in Bytes (Pixels * 8) (word)
  132 -     (#84 -    )  Bit-Image Data as follows...

   Bytes read from left to right in lines, top line first.
   
   Each byte is standard 1-bit-per-pixel layout where MSB = LH pixel, LSB
   = RH pixel, 1 = white ('on'), and 0 = black ('off'). Each #00 (all
   black) or #FF (all white) byte is followed by a 'count' byte (ie. #00
   #03 means 3 whole bytes width of solid black; #FF #A0 means 160 bytes
   width of solid white). A value #00 for the count byte means 256. This
   'count' can overrun into the next (several) lines.
   
   For example: (. represents black, # white)
   
    ....#### ##..##.. ####.... ........ ..###### ######## ########
       0F       CC       F0      00,01     3F          FF,02

    ####.... ........ ........ ........ ........ ........ ........
       F0                            00,06

   Because of this compression the file length is indeterminate, but
   there must be HEIGHT * WIDTH bytes of actual image data by the time it
   has been uncompressed.
   
   The newer MicroDesign3 Area file format is as follows:
   
Bytes 0..127: file 'stamp':
    0 -   3 (#00 - #03)  .MDA            File Type  (4 bytes)
    4 -  17 (#04 - #11)  MicroDesignPCW  Program Identifier (14 bytes)
   18 -  22 (#12 - #16)  v1.30           File Version  (5 bytes)
   23 -  24 (#17 - #18)  CR,LF           ie. 13,10 decimal (2 bytes)
   25 -  31 (#19 - #1F)  xxxxxxx         User Serial No (ASCII) (7 bytes)
   32 -  33 (#20 - #21)  CR,LF           ie. 13,10 decimal (2 bytes)
   34 - 127 (#22 - #7F)                  fill with zeroes (#00) (94 bytes)

Bytes 128..: file proper:
  128 - 129 (#80 - #81)  Height in Lines (multiple of 4) (word)
  130 - 131 (#82 - #83)  Width in Bytes (Pixels * 8) (word)
  132 -     (#84 -    )  Bit-Image Data as follows...

   Bytes read from left to right in lines, top line first.
   
   Each byte is standard 1-bit-per-pixel layout where MSB = LH pixel, LSB
   = RH pixel, 1 = white ('on'), and 0 = black ('off').
   
   Each line of data is compressed according to one of three 'line
   types'. The first byte of data for each line is the line type.
   
Line type byte:
  #00: Line is ALL-SAME-BYTE type
  #01: Line is DATA type
  #02: Line is DIFFERENCE DATA type

   The actual data for each line follows this type byte:
   
   ALL-SAME-BYTE type:
          One more byte follows the initial #00 type byte - this is the
          actual bit-image data with which to fill the whole line width.
          
          eg. Whole line of white = #00 #FF, whole line of black = #00
          #00
          
   DATA type:
          Following the initial #01 type byte, the data content of the
          line is compressed as follows:
          
          Data is encoded in 'blocks', which are of *either* repeating
          data bytes *or* non-repeating bytes. Each block starts with a
          control byte, which determines whether the data which follows
          it is *either* just one data byte to be repeated *or* a
          sequence of dissimilar bytes.
          
          If the control byte N is negative (-1 to -127 in two's
          complement - #FF for -1, #81 for -127), *one* data byte follows
          which is to be repeated -N times. This means that there are to
          be a total of (-N+1) occurrences of this data byte.
          
          If the control byte N is positive (0 to 127; #00 to #7F), it is
          followed by (N+1) bytes of dissimilar data to load directly
          into the line.
          
          For instance: 01 (line type), then:
          
....#### ##..##.. ####.... ........ ######## ######## ########
          03,0F,CC,F0,00                       FE,FF

#####... #.#.#.#. #.#.#.#. #.#.#.#. #.#.#.#. #.#..... ........
  00,F8                 FD,AA                     01,A0,00

          Note: the POSITIVE control bytes are 1 LESS than the number of
          dissimilar bytes following them; NEGATIVE ones are (MINUS) 1
          LESS than the number of occurrences of the byte following them.
          
   DIFFERENCE DATA type:
          Following the initial #02 type byte, the difference between the
          data content of this line and the content of the previous line
          is stored: ie. this line is XORed with the previous line to
          produce a 'difference' line, which is then compressed using the
          same method as for a DATA type line.
          
          For instance, the following line stored as a 'difference' line
          from the line above would be 02 (line type), then: (the second
          pixel row below shows the results of XORing the first two
          lines)
          
....#### ##..##.. ##..##.. ......## ######## ######## ########
........ ........ ..####.. ......## ........ ........ ........
      FF,00           01,3C,03                 FE,00

######.. #.#.#.#. #.#.#.#. #.#.#.#. #.#.#.#. #.#.#.#. ........
.....#.. ........ ........ ........ ........ ....#.#. ........
 00,04                  FD,00                     01,0A,00

          Note: this DIFFERENCE encoding is used if it will result in
          less bytes of data being stored in the file. The line type of
          the previous line is irrelevant.
          
   Because of these various types of compression the file length on the
   disc is indeterminate, but there must be HEIGHT * WIDTH bytes of
   actual image data by the time it has been uncompressed.
   
The MDP (MicroDesign Page) file formats

   MicroDesign3's Page (.MDP) files are identical to its Area (.MDA)
   files except for the following differences:
   
Bytes 0..127: file 'stamp':
    0 -   3 (#00 - #03)  .MDP            File Type  (4 bytes)
   34       (#22)        nn: dpi         00 = 240dpi
                                         01 = 360dpi
                                         02 = 300dpi
   35       (#23)        nn: format      00 = A5 portrait
                                         01 = A5 landscape
                                         02 = A4 portrait
                                         03 = A4 landscape
                                         04 = A5 portrait (hi-res)
                                         05 = A5 landscape (hi-res)
   36       (#24)        nn: page ram required in 16k blocks

   In all other respects a Page (.MDP) file is identical to an Area
   (.MDA) file (MD3 type).
   
The CUT image format

   (Note: this information is in no way 'official' and results from my
   own dabblings; it is separate from the above information on the MDA
   format and is included here for convenience. No warranty expressed or
   implied)
   
   CUT files have a format as follows:
   
    0 -   1 (#00 - #01)  Height code h1 (word) (see below)
    2 -   3 (#02 - #03)  Width code w1 (word) (see below)
    4 -     (#04 -    )  Bitmap data, row-by-row

   The height in pixels h1 can be calculated from the height code h using
   h = (h1+3)/2; the width in pixels is w = w1+2; the number of whole
   bytes per row in the file is wb = INT((w+8)/8). Bitmap data in the
   file is stored row-by-row, with a whole number of bytes per row; the
   LSBs of the last byte that extend beyond the right edge of the image
   should be discarded. As usual in bitmap data the MSB is towards the
   left and the LSB towards the right.
   
   Note: the formula above for wb implies that if the image is a whole
   multiple of 8 pixels wide, none of the bits from the last byte in the
   row will be used. Strange, but there you go.
   
The GRF image format

   (Same disclaimer applies; this is all from experiment)
   
   GRF files are substantially similar to CUTs (although slightly more
   logical) and have a format as follows:
   
    0 -   1 (#00 - #01)  Width in pixels (word)
    2 -   3 (#02 - #03)  Height in pixels (word)
    4 -     (#04 -    )  Bitmap data, row-by-row

   The number of bytes per row is simply the width in pixels divided by
   8, rounded up; no catches here. As with CUTs unused rightmost bits
   should be discarded.
     _________________________________________________________________
                                      
   
    Go to CP/M page or main page
    Last updated 16 April 1997; Jacob Nevins