I’ve looked into a bunch of copy protections for the Atari ST. I’ll publish them on this blog, but they can also be found on GitHub.
Category: Reverse Engineering
Waves GTR Ground MIDI Protocol
This information is also available at GitHub.
The Waves GTR Ground is a MIDI foot controller with 11 buttons and 2 foot pedals. It has three 15-segment LEDs for seven buttons, plus two LEDs and brightness control for the LEDs.
The device is a USB MIDI compliant device with a USB Vendor ID of 0x6824 and a USB Product ID of 0x0100. My device returned Version “ 1.01” and “Waves Audio LTD.” as the Manufacturer. The MIDI properties for my device are:
- SerialNumber = “Ver. 1.4”;
- Manufacturer = “Waves Audio LTD.”;
- Model = “GTR Ground Ver 1.4”;
- Name = “GTR Ground Ver 1.4”;
The following MIDI events are send from the device:
- MIDI CC 0x0E = Right Pedal (0x00..0x7F)
- MIDI CC 0x0F = Left Pedal (0x00..0x7F)
- MIDI CC 0x10 = Button ‘A’ (0x7F: pushed down, 0x00:released)
- MIDI CC 0x11 = Button ‘B’ (0x7F: pushed down, 0x00:released)
- MIDI CC 0x12 = Button ‘C’ (0x7F: pushed down, 0x00:released)
- MIDI CC 0x13 = Button ‘D’ (0x7F: pushed down, 0x00:released)
- MIDI CC 0x14 = Button ‘E’ (0x7F: pushed down, 0x00:released)
- MIDI CC 0x15 = Button ‘F’ (0x7F: pushed down, 0x00:released)
- MIDI CC 0x16 = Button A/B (0x7F: pushed down, 0x00:released)
- MIDI CC 0x17 = Button Down (0x7F: pushed down, 0x00:released)
- MIDI CC 0x18 = Button Up (0x7F: pushed down, 0x00:released)
- MIDI CC 0x19 = Button Preset/Stomp (0x7F: pushed down, 0x00:released)
- MIDI CC 0x1A = Button Tuner/Tap Tempo (0x7F: pushed down, 0x00:released)
To control the LEDs on the device, a USB Real Time message can be send to the device: The message is always 48 bytes long, all unused bytes are set to 0x00, the last byte is 0xF7.
0xF0, 0x7F, 0x00, 0x20, 0x66, <type>, <variable data>, 0x00*, 0xF7
An example
All LED segments on for button A (1st event), LED to max brightness (2nd event), both A/B LEDs on (3rd event)
F0 7F 00 20 66 41 00 38 7F 7F 7F 7F 7F 7F 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F7
F0 7F 00 20 66 51 0F 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F7
F0 7F 00 20 66 62 03 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F7
Controlling the LEDs next to A/B button
- 0x62, 0x01 = B LED on
- 0x62, 0x02 = A LED on
- 0x62, 0x03 = A LED and B LED on
Controlling the brightness of the LED displays
- 0x51, value Brightness for ‘A’
- 0x52, value Brightness for ‘B’
- 0x53, value Brightness for ‘C’
- 0x54, value Brightness for ‘D’
- 0x55, value Brightness for ‘E’
- 0x56, value Brightness for ‘F’
- 0x57, value Brightness for Preset
value =
- 0x00 .. 0x07 LEDs off
- 0x08 .. 0x0F Brightness (dark … bright)
Setting the segments in the LED displays
- 0x41 Set LED Text above the ‘A’ button
- 0x42 Set LED Text above the ‘B’ button
- 0x43 Set LED Text above the ‘C’ button
- 0x44 Set LED Text above the ‘D’ button
- 0x45 Set LED Text above the ‘E’ button
- 0x46 Set LED Text above the ‘F’ button
- 0x47 Set LED Text below the Preset button
There are the 3 15 Segment-LEDs per button:
- - - A
|\|/| |\|/| |\|/| BCDEF
- - - - - - G H
|/|\| |/|\| |/|\| IJKLM
- . - . - . N O
1st 2nd 3rd
The ‘A’ to ‘O’ above are the references to a specific LED segment.
The format is as followed:
1. Byte
0x00 (this byte seems to be unused and always 0x00)
2. Byte (by bits)
6 - (unused)
5 - Dot behind the 3rd segment
4 - Dot behind the 2nd segment
3 - Dot behind the 1st segment
2 - (unused)
1 - (unused)
0 - (unused)
3. Byte (by bits) (1. LED)
6 - G (left middle bar)
5 - B
4 - I
3 - N (the 6 outside segments, counter clockwise)
2 - M
1 - F
0 - A
4. Byte (by bits)
6 - J
5 - K
4 - L
3 - E (the 6 inside segments, counter clockwise)
2 - D
1 - C
0 - H (right middle bar)
5. Byte (by bits) (2. LED)
6 - G (left middle bar)
5 - B
4 - I
3 - N (the 6 outside segments, counter clockwise)
2 - M
1 - F
0 - A
6. Byte (by bits)
6 - J
5 - K
4 - L
3 - E (the 6 inside segments, counter clockwise)
2 - D
1 - C
0 - H (right middle bar)
7. Byte (by bits) (3. LED)
6 - G (left middle bar)
5 - B
4 - I
3 - N (the 6 outside segments, counter clockwise)
2 - M
1 - F
0 - A
8. Byte (by bits)
6 - J
5 - K
4 - L
3 - E (the 6 inside segments, counter clockwise)
2 - D
1 - C
0 - H (right middle bar)
PC Protocol of Suunto D9
This document describes the transfer protocol and memory layout of these suunto diving computers:
- Suunto D6 (a D9 without the air integration)
- Suunto D9
Suunto changed the protocol for these models – again. One reason is that the D9 is capable in recording not only the depth, but also pressure and temperature throughout the dive. The computers also have no longer just 8kb, but 32kb of memory for the profile information.
Communication
The interface is technically still a RS232 interface, but with a USB connector. With a device driver from the USB chipset vendor FTDI it will be recognized as a standard serial port.
The RS232 should be 9600 baud, 8N1.
Transfer
The protocol for the Suunto D9 is slightly different from other Suunto computers. The first thing is that the interface is USB only. But with the standard driver is behaves like a serial port (see above). These standard drivers are available for Mac OS X and Linux, so there should be no reason to go into too much detail.
All data is send in packages to and from the computer. Every package is followed by a CRC for checksum reasons.
unsigned char checksum = 0x00;
for(int i=0; i<packageLen; ++i)
checksum ^= package[i];
The package starts with a command byte, followed by the length of bytes for the parameters ($00 $03 = 3 Bytes), the actual parameters and the CRC at the end. Here are examples of the most common commands:
- ReadMemory – reads memory from the Suunto
- to Suunto: $05 + $00 + $03 + addr_high + addr_low + count (1..$78) + CRC
- from Suunto: $05 + $00 + $03 + addr_high + addr_low + count (1..$78) + count Bytes + CRC
- WriteMemory – changes the memory inside the Suunto (WARNING: this can damage your watch!!!)
- to Suunto: $06 + $00 + $03 + addr_high + addr_low + count (1..$78) + CRC
- from Suunto: $06 + $00 + $03 + addr_high + addr_low + count (1..$78) + count Bytes + CRC
- GetVersion / check for connected computer
- to Suunto: $0F + $00 + $00 + CRC
- from Suunto: $0F + $00 + $00 + ID + HIGH + MID + LOW + CRC = Version HIGH.MID.LOW (ID)
- ResetMaxDepth – resets maximum depth in the history to 0.0m
- to Suunto: $20 + $00 + $00 + CRC
- from Suunto: $20 + $00 + $00 + CRC
The DiveManager Software from Suunto does the following when reading data from a D6/D9: – GetVersion() – ReadMemory($0, $78) – ReadMemory($168, $78) (Reading the memory header) – ReadMemory($F0, $78)
After that the DiveManager reads the headers of all profiles first (by following the linked list in the headers), but always $78 bytes and later fills in the holes in the memory, if necessary. This allows the DiveManager to display a progress bar for the import.
To change the personal information, it does the following: – GetVersion() – Write($015E,$28) – Read($0168,$78) – GetVersion() – Read($0000,$78)
To reset the max. depth to zero it does the following: – GetVersion() – ResetMaxDepth() – Read($00F0,$78) – Read($0168,$78) – GetVersion() – Read($0000,$78)
Firmware versions
There have been two recalls of the Suunto D9 so far.
- The first one was a hang of the D9, which is fixed in firmware version 1.2.8 and later (serial numbers 4xxxxxxxx – 450000699)
- The second one (serial numbers below 62102582, an inacuracy of the clock in 0.6% of the cases) seemed to be fixed in firmware version 1.2.11 and later. This one also affects the Suunto D6 (serial numbers below 62103693)
Memory layout
The 32kb of memory is split into a $019A bytes header and the rest is a ring-buffer with the dive profiles. The ring-buffer is a stream of data, which ends at the position, that is marked in the header. At this position the computer starts writing the information from the next dive. If the write pointer reaches the value $8000, it jumps back to $019A.
I am using the following parameter types:
parameter types | Description |
---|---|
B | 8 bit Byte |
Bn | n Bytes |
W | 16 bit LSB integer |
An | ASCII string, max. n Bytes long |
All units inside the Suunto are metric (meter/centimeter, bar)!
Memory Header
offset | format | testvalue | content
$00 | B | $00 | empty |
$01-$02 | A2 | “D9” | Type of the dive computer, “D9”, “D6” or “D4” |
$03-$0A | A8 | “20050228” | Manufacturing date (28 Feb 2005) |
$0B-$12 | A8 | “00001204” | Serial number? |
$13-$15 | B | $00 $55 $00 | ??? |
$16-$22 | B | .. $FF .. | unused |
$23-$26 | B4 | $50 $90 $12 $34 | official serial number ($50901234) Production date: 2000+5 / 09 week, watch 234 |
$27 | B | $FF | unused |
$28 | B | $0E | model ($0E=D9, $0F=D6 (can also be $0E?), $12=D4) |
$29-$2A | B2 | $01,$02 | Version (1.2.10 – well, were does the 10 come from?) |
$2B-$2D | B | $04,$09,$82 | ??? |
$2E | B | $82 | XOR Checksum $28..$2D |
$2F-$31 | B | .. $FF .. | unused |
$32-$33 | B | $01 $01 | ??? |
$34-$35 | B2 | $00 $00 | $0000 = metric, $0101 = imperial |
$36 | B | $FF | unused |
$37-$3A | B | $83 $00 $82 $F2 | ??? |
$3B | B | $0C | XOR Checksum $32..$3A |
$3C-$3F | B | $FE $00 $00 $00 | ??? |
$40-$63 | B | .. $FF .. | unused |
$64-$6F | B | .. | calibration data for sensors |
$70 | B | $.. | XOR Checksum $64..$6F |
$71-$73 | B | .. $FF .. | unused |
$74-$7D | B | .. | calibration data for sensors |
$7E | B | $.. | XOR Checksum $74..$7D |
$7F-$83 | B | .. $FF .. | unused |
$84-$8D | B | .. | calibration data for sensors |
$8E | B | $.. | XOR Checksum $84..$8D |
$8F-$015D | B | .. $FF .. | unused |
$015E-$0185 | A40 | .. | owner name (“Suunto Diver”), $00 terminated if short than 40 bytes |
$0186-$0187 | W | $F010 | max. depth ($10F0 = 4336 cm) |
$0188-$0189 | W | $AB02 | total dive time ($02AB = 683 minutes) |
$018A-$018B | W | $0C00 | total number of dives ($000C = 12) |
$018C | B | $.. | XOR Checksum $0186..$018B |
$018D-$018F | B | .. $FF .. | unused |
$0190-$0191 | W | $0A $46 | Ptr to the last dive in the ring-buffer (Offset $460A) |
$0192-$0193 | W | $0C $00 | Number of dives in the ring-buffer ($000C = 12) |
$0194-$0195 | W | $7E $4B | Ptr to behind the latest dive in the ring-buffer (Offset $4B7E) |
$0196-$0197 | W | $9A $01 | Ptr to the oldest dive in the ring-buffer (Offset $019A) |
$0198-$0199 | W | $5C $0E | checksum ??? (if changed SDM can no longer read the profiles) |
Dive Profile Header
Every dive in the profile memory has a $4A bytes header.
offset | format | testvalue | content |
---|---|---|---|
$00-$01 | W | $9A $01 | Offset to previous dive ($019A – this is the very first) |
$02-$03 | W | $CF $06 | Offset to next dive ($06CF) |
$04-$0C | B | .. | ??? |
$0D-$0E | W | $F0 $10 | max. depth ($10F0 = 4336 cm) |
$0F-$10 | W | $1E $00 | dive time ($001E = 30 minutes) |
$11-$12 | W | .. | if value is $FFFF, there is no pressure information for the dive |
$13 | B | $03 | OLF PCT (3%) |
$14 | B | .. | ??? |
$15 | B | $0A | Date: hour (10 AM) |
$16 | B | $24 | Date: minutes (36) |
$17 | B | $0E | Date: seconds (14) |
$18-$19 | W | $D5 $07 | Date: year (2005) |
$1A | B | $0C | Date: month (12) |
$1B | B | $0B | Date: day (11) |
$1C | B | $0A | Sample recording interval (every 10 seconds) |
$1D | B | $00 | Gas model (0=Air, 1=Nitrox, 2=Gauge) |
$1E | B | $01 | repetitive dive number (1) |
$1F | B | $00 | Surface time (0 minutes) |
$20 | B | $00 | Surface time (0 hours) |
$21 | B | $03 | RGBM PCT (3%) |
$22 | B | $00 | Personal Setting (P0..P2) |
$23 | B | $00 | Altitude Setting (A0..A2) |
$24 | B | .. | ??? |
$25 | B | $20 | O2 PCT (only if in Nitrox mode, 32%) |
$26 | B | $15 | O2 PCT 2 (only if in Nitrox mode, 21%) |
$27 | B | $15 | O2 PCT 3 (only if in Nitrox mode, 21%) |
$28 | B | $00 | ??? |
$29-$2A | W | $.. $.. | PREVTPRESSURE_1 |
$2B-$2C | W | $.. $.. | PREVTPRESSURE_2 |
$2D-$2E | W | $.. $.. | PREVTPRESSURE_3 |
$2F-$30 | W | $.. $.. | PREVTPRESSURE_4 |
$31-$32 | W | $.. $.. | PREVTPRESSURE_5 |
$33-$34 | W | $.. $.. | PREVTPRESSURE_6 |
$35-$36 | W | $.. $.. | PREVTPRESSURE_7 |
$37-$38 | W | $.. $.. | PREVTPRESSURE_8 |
$39-$3A | W | $.. $.. | PREVTPRESSURE_9 |
$3B-$46 | B | .. | ??? |
$47 | B | $05 | Temperature recording interval (every 5 depth samples) |
$48-$4B | B | .. | ??? |
$4C-$4D | W | $4D $00 | Offset to the first marker position in the profile |
Dive Profile Data
The length of the profile data can be found by looking into the profile header: the difference between the offset of the next dive to the current offset minus the size of the header ($4A).
Warning: Remember that the data is stored in a ring-buffer! The next dive pointer might actually be smaller than the current dive pointer.
To parse the profile data, you start with a time of 0:00 minutes and read to LSB 16 bit values. The first value is the current depth in cm. The second value is the tank pressure in bar * 100. Before reading the next value you increment the time by the “Sample recording interval” (Header offset $1C). Every “Temperature recording interval” (Header offset $47) there is another byte following with the temperature in degrees celcius. You stop once you’ve read the beginning of the next dive.
But, there is another twist: the dive profile can contain events, which are encoded into the profile information. For this you need check for the “Offset to the first marker position” (Header offset $4C). The first offset into the dive profile is $0000, you increment it with every byte you’ve read from the profile (4 or 5 per sample, see above). If the marker is equal to the current profile position, the next byte is an event type. You have to read all events till you will get Event $01 “Next Event Marker”. After you’ve read this one, you can continue normal parsing till you hit the next marker position.
Event | Type | Parameter | Function |
---|---|---|---|
$01 | Next Event Marker | WW | set the position of the next event marker (1st: current position, 2nd: next position) |
$02 | Surfaced | BB | Reached Surface at current timestamp + 2nd byte: seconds (for a more exact value) |
$03 | Event | BB | Other dive related events (1st: type, 2nd: time offset like in “Surfaced”) |
$04 | Bookmark/Heading | BBW | Bookmark & Heading (1st:???, 2nd: time offset like in “Surfaced”, 3rd: heading * 4, if < 0: Bookmark instead) |
The Dive Events from Event $03 are 7 bit values. If bit 7 is set, like in $8E which only seems to occur in that form, it means: Event has ended. So you can get a start and a stop time for one event.
Dive Event | Description |
---|---|
$01 | Mandatory Safety Stop |
$04 | Asc Warning |
$06 | Mandatory Safety Stop Ceiling Error |
$07 | ??? |
$09 | Depth alarm |
$0D | Air Time Warning |
$8E | Rgbm Warning (End) (always before the first profile data at the beginning of the dive) |
Inside information of the Pronto IR Remote
The Philips Pronto is a programmable remote control. It looks a bit like a Palm Pilot, but it is the most flexible remote control on the market (below the $1000…). The interesting thing with the Pronto is, that it is fully customizable with the Pronto Edit software.
Unfortuanlly the Pronto Edit software is for Windows only, so i reverse engineered the format of the CCF files and also tried to get information about the communication with the Pronto.
CCF file format
Source code for parsing a CCF file:
- Parse.cp (last change: 10. Nov. 1999; now with support for hidden panels, timers and beeps)
- ParseGCC.cp (last change: 12. Jul. 2001, source code for the GCC on Linux systems)
Serial Communication
Pronto has a serial port for the communication with a computer. This port works at 115200 baud, 8N1. The communication is pretty simple:
First: get attention of the Pronto. This is done by sending an ACK (0x06) to the Pronto. The Pronto should send a ‘!’ (standby mode) or a ‘*’ (awaiting data, done by holding the left and right key down, while the serial cable was plugged in). If the Pronto don’t respond, try again until timeout.
When the Pronto awaits a command, you can send strings (terminated with CR (0x0D)) like:
irlearn 3500
The Pronto now awaits an infra red signal to learn. The result is send via YModem CRC protocol.
q ccf
Inquiry. The Pronto sends a string containing 4 decimal numbers. The first is the dirty flag (CCF data in the Pronto changed by the user and is not uploaded to the computer yet), the second is the size of the CCF file, the third the the date (in a 8 digit decimal BCD format), the fourth is the time (in a 6 digit decimal BCD format) of the last change of the CCF file.
ul ccf
Uploading a CCF file from the Pronto to the computer. The CCF file is simply send via YModem CRC protocol to the computer.
dl ccf
Downloading a CCF file to the Pronto from the computer. The CCF file is simply send via YModem CRC protocol to the Pronto.
reboot
Reboot the Pronto.
Some links to interesting Pronto websites
- Philips Pronto Homepage {OFFLINE}
- Pronto Edit {OFFLINE}
- Remote Central
- Tonto A clone of ProntoEdit written in Java and therefore cross-platform
PC Protocol of Suunto Spyder
This document describes the transfer protocol and memory layout of these Suunto diving computers:
- Suunto Sypder
Communication
The protocol uses 2400 8O1, which means 2400 baud with 8 bits, odd parity and 1 stop-bit. The check for the interfaces uses 2400 8N1, but it also works with 2400 8O1. This was the trivial part… But some lines have a special meaning with the interface!
The DTR line should always be set. It is used as a power supply for the interface.
RTS is a toggle for the direction of the half-duplex interface. To send a command to the interface, set RTS. When you await a command, clear RTS. Timing also seems to be critical! To make sure that all data is sent to the interface, before clearing RTS, I wait about 200ms. After clearing RTS, I also have to wait 400ms and use a 500ms timeout for receiving data.
The test for the existance of the interface is simple: the computer sends AT plus a CR ($41, $54, $0D) and awaits the same answer.
Transfer
The protocol for the Suunto Spyder, Vyper and Cobra are identical, but the memory layout of the Spyder is different. All data is send in packages to and from the computer. Every package is followed by a CRC for checksum reasons.
unsigned char checksum = 0x00;
for(int i=0; i<packageLen; ++i)
checksum ^= package[i];
- Read memory
- to Spyder: 05 + addr_high + addr_low + count (1..32) + CRC
- from Spyder: 05 + addr_high + addr_low + count (1..32) + n Bytes + CRC
- Write memory
- to Spyder: 06 + addr_high + addr_low + count (1..31)+ n Bytes + CRC
- from Spyder: 06 + addr_high + addr_low + count (1..31) + CRC
- Used before every ‘Write memory’ call
- to Spyder: 07 + $a5 + CRC
- from Spyder: 07 + $a5 + CRC
- Get first dive profile
- to Spyder: 08 + $a5 + CRC
- from Spyder: 08 + count (1..32) + n Bytes + CRC (if more than 32 bytes needs to be transmitted, they are split in 32 byte packages)
- Get next dive profile
- to Spyder: 09 + $a5 + CRC
- from Spyder: 09 + count (1..32) + n Bytes + CRC (if more than 32 bytes needs to be transmitted, they are split in 32 byte packages)
The DiveManager Software from Suunto does the following when reading data from a Spyder: – Check for correct computer – Read Memory ($24, 1) – Read the internal memory: – Read Memory ($1E, 14) – Read Memory ($2C, 32) – Read Memory ($53, 30) – Get first dive profile – Get next dive profile – … – If “next dive profile” returns a null package, the end of the log memory is reached.
Memory layout
Default name of the LOG file: ‘‘PROFILE.ACW’’
offset | format | testvalue | content
$00-$15 | MSB binary | … | unused by the PC software, probably configuration values for the computer |
$16-$17 | MSB binary | $0102 | Firmware version of the Spyder (old ACW $0101, new ACW $0102) |
$18-$1B | MSB binary | … | Serialnumber (new ACW, e.g. $0002.0F7F = 203.967) or ID no. (old ACW, e.g. $2E.61.122E = 469704654) of the Spyder |
$1C-$1D | MSB binary | … | Ptr to the last $82 byte in the profile ringbuffer |
$1E-$1F | MSB binary | $3F46 | max. depth in ft * 128.0 |
$20-$21 | MSB binary | … | total dive time in minutes |
$22-$23 | MSB binary | … | total number of dives |
$24 | MSB binary | $14 | interval (20s, 30s or 60s, Changing ist not allowed by DiveManager software! Why? Marketing?) |
$25 | MSB binary | … | altitude and personal settings (height (0..2) + 3 * personal (0..2)) |
$26-$2B | MSB binary | … | ? ($0B,$03,$1F,$FF,$1F,$FF : identical on all Suunto computers?) |
$2C-$49 | ASCII | ACW Diver | personal information (“ACW Diver”, otherwise filled to the maximum length with spaces) |
$4A-$4B | MSB binary | … | ? ($01, $01 : identical on all ACW?!? Version of the profile memory?) |
$4C-$1FFF | MSB binary | … | ring buffer for the profile memory |
The ring-buffer is a stream of data, which ends at the position, that is marked in the header. At this position the computer starts writing the information from the next dive. If the write pointer reaches the value $2000, it jumps back to $4C.
Format for one dive
offset | format | description |
---|---|---|
0 | MSB binary | unknown — air preassure at the end of the dive? |
1 | MSB binary | temperature in degress celcius. |
2… | binary | profile data from the end to the beginning of the dive,this means reverse order! |
n | MSB binary | minutes at the beginning of the dive |
n + 1 | MSB binary | hours at the beginning of the dive |
n + 2 | MSB binary | day at the beginning of the dive |
n + 3 | MSB binary | month at the beginning of the dive |
n + 4 | MSB binary | year at the beginning of the dive (90..99 = 1990..1999, 00..89 = 2000..2089) |
n + 5 | MSB binary | altitude and personal settings (height (0..2) + 3 * personal (0..2)) |
n + 6 | MSB binary | unknown — air preassure at the beginning of the dive? |
n + 7 | MSB binary | interval (20s, 30s or 60s) |
n + 8 | MSB binary | dive number in the Spyder (for repetitive dives) |
n + 9 | MSB binary | hours of the surface interval |
n + 10 | MSB binary | minutes of the surface interval |
Profile information
The profile data is a stream of bytes. Every minute (or 30s or 20s – see the profile interval) a byte is recorded. This byte is the delta depth in ft to the last depth! E.g. you start your dive at a depth of 0 feet go down to 30ft in a minute, so the value is –30ft (because you go 30ft down) or $E2 in binary, if you then go up to 20ft, the next value will be +10ft (because you go 10ft up) or $0A in binary.
Some values have special meanings:
Byte | Type | Description |
---|---|---|
$7d | Surfaced | you have reached the surface while (or after) the dive |
$7e | ASC | dive now is a decompression dive |
$7f | ERR | decompression missed |
$80 | End | end of the dive. The next byte is n + 1 in the format description of the dive. |
$81 | Slow | Slow warning while the dive. If the dive ends with $7d8180 (Surfaced, Slow, End) it means, you finished the dive with a blinking SLOW warning in the display. |
$82 | End of data | set after the last dive (written after the dive as a marker, so technically not profile information) |
Necessary conversions
meter = (int)(feet * 0.3048 * 10) / 10
psi = bar * 14.50377377
fahrenheit = celcius * 1.8 + 32
Altitude:
value | meters | feet |
---|---|---|
0 | 700m | 2300ft |
1 | 1500m | 5000ft |
2 | 2400m | 8000ft |
ATTN: the computers don’t round after the 2. digit, when calculating feet => meter! They cut it after the 2. digit. This results to the modified formula.
PC Protocol of Suunto Cobra, Vyper, Stinger, Mosquito, Vytec and Gekko
This document describes the transfer protocol and memory layout of these suunto diving computers:
- Suunto Cobra
- Suunto Vyper 1 & 2
- Suunto Stinger
- Suunto Mosquito
- Suunto Vytec DS
- Suunto Gekko
Communication
The protocol uses 2400 8O1, which means 2400 baud with 8 bits, odd parity and 1 stop-bit. The check for the interfaces uses 2400 8N1, but it also works with 2400 8O1. This was the trivial part… But some lines have a special meaning with the interface!
The DTR line should always be set. It is used as a power supply for the interface.
RTS is a toggle for the direction of the half-duplex interface. To send a command to the interface, set RTS. When you await a command, clear RTS. Timing also seems to be critical! To make sure that all data is sent to the interface, before clearing RTS, I wait about 200ms. After clearing RTS, I also have to wait 400ms and use a 500ms timeout for receiving data.
The test for the existance of the interface is simple: the computer sends AT plus a CR ($41, $54, $0D) and awaits the same answer.
Transfer
The protocol for the [[Suunto Spyder]], Vyper and Cobra are identical, but the memory layout of the Spyder is different. All data is send in packages to and from the computer. Every package is followed by a CRC for checksum reasons.
unsigned char checksum = 0x00;
for(int i=0; i<packageLen; ++i)
checksum ^= package[i];
- Read memory
- to Cobra: 05 + addr_high + addr_low + count (1..32) + CRC
- from Cobra: 05 + addr_high + addr_low + count (1..32) + n Bytes + CRC
- Write memory
- to Cobra: 06 + addr_high + addr_low + count (1..31)+ n Bytes + CRC
- from Cobra: 06 + addr_high + addr_low + count (1..31) + CRC
- Used before every ‘Write memory’ call
- to Cobra: 07 + $a5 + CRC
- from Cobra: 07 + $a5 + CRC
- Get first dive profile
- to Cobra: 08 + $a5 + CRC
- from Cobra: 08 + count (1..32) + n Bytes + CRC (if more than 32 bytes needs to be transmitted, they are split in 32 byte packages)
- Get next dive profile
- to Cobra: 09 + $a5 + CRC
- from Cobra: 09 + count (1..32) + n Bytes + CRC (if more than 32 bytes needs to be transmitted, they are split in 32 byte packages)
The DiveManager Software from Suunto does the following when reading data from a Cobra: – Check for correct computer – Read Memory ($24, 1) – Read the internal memory: – Read Memory ($1E, 14) – Read Memory ($2C, 32) – Read Memory ($53, 30) – Get first dive profile – Get next dive profile – … – If “next dive profile” returns a null package (count = 0), the end of the log memory is reached.
Memory layout
Default name of the LOG file: ‘‘PROFILE.VPR’’
offset | format | testvalue | content
$00-$1D | MSB binary | … | unused by the PC software, probably configuration values for the computer |
$1E-$1F | MSB binary | $6038 | max. depth in ft * 128.0 |
$20-$21 | MSB binary | … | total dive time in minutes |
$22-$23 | MSB binary | … | total number of dives |
$24 | MSB binary | $0C | Type of the computer ($03:Stinger, $04:Mosquito, $0A:new Vyper, $0C:Vyper or Cobra, $0B:Vytec, $0D:Gekko) |
$25 | MSB binary | … | firmware version (30: Cobra, 33: Cobra, 21: Stinger, 15: Mosquito), the minor part is always .0.0 |
$26-$29 | MSB binary | $00005A38 | serial number e.g. a Vyper: $00.01.04.41 (= 00010465) |
$2A-$2B | MSB binary | $0000 | unknown |
$2C-$49 | ASCII | Vyper Diver | personal information (“Vyper Diver”, “Cobra Diver”, “ACW Diver”, “Mosquito Diver” fill with zero bytes, if changed by the user filled to the maximum length with spaces) |
$4A-$50 | MSB binary | $00..$00 | unknown (only the first 2 bytes are read by DM software) |
$51-$52 | MSB binary | … | Ptr to the last $82 byte in the profile ringbuffer (not read by DM software) |
$53 | MSB binary | $14 | interval (10s, 20s, 30s or 60s) |
$54 | MSB binary | … | altitude and personal settings (height (0..2) + 3 * personal (0..2)) |
$55-$5B | MSB binary | … | unknown ($0E.05.1F.FF.1F.FF.01 : identical on all Suunto computers?) |
$5C-$5D | MSB binary | $0000 | max. freediving depth (only on Mosquito and Stinger) in ft * 128.0 |
$5E-$5F | MSB binary | $0000 | total freediving time in minutes (only on Mosquito and Stinger) |
$60 | MSB binary | $01 | 12/24 hour flag, 00 = 24 hours, 01 = 12 hours plus AM/PM |
$61 | MSB binary | $00 | unknown |
$62 | MSB binary | $01 | 0 = imperial, 1 = metric |
$63 | MSB binary | $01 | Model (0: Air, 1:Nitrox/EAN, 2:Gauge; Mosquito, Stinger: Bit 3 set: Diving active, Bit 7 set: Free Diving active) |
$64 | MSB binary | $8A | Light (Bit 7: on; Bit 0..6: time in s) |
$65 | MSB binary | $03 | Bit 0: dive time alarm = on, Bit 1: dive depth alarm = on |
$66-$67 | MSB binary | $0037 | dive time for the alarm in minutes (max. 999 minutes, normal max. 4:59) |
$68-$69 | MSB binary | $3138 | depth for the alarm in ft * 128.0 (rounded to 0.5m or 1ft; valid: 0m, 3m–150m (Cobra, Vyper: 100m)) |
$6A-$70 | MSB binary | … | unknown ($46.00.00.00.00.00.00) |
$71-$1FFF | MSB binary | … | ring buffer for the profile memory |
The ring-buffer is a stream of data, which ends at the position, that is marked in the header. At this position the computer starts writing the information from the next dive. If the write pointer reaches the value $2000, it jumps back to $71.
Format for one dive
offset | format | description |
---|---|---|
0 | MSB binary | 00, with Nitrox: OLF % * 2 ($32 * 2 = 100 CNS), if bit 7 is set: OTU instead of CNS |
1 | MSB binary | pressure at the end of the dive in bar / 2 |
2 | MSB binary | temperature at the end of the dive in degress celcius |
3 | MSB binary | temperature at the max depth in degress celcius |
4… | binary | profile data from the end to the beginning of the dive,this means reverse order! |
n | MSB binary | minutes at the beginning of the dive |
n + 1 | MSB binary | hours at the beginning of the dive |
n + 2 | MSB binary | day at the beginning of the dive |
n + 3 | MSB binary | month at the beginning of the dive |
n + 4 | MSB binary | year at the beginning of the dive (90..99 = 1990..1999, 00..89 = 2000..2089) |
n + 5 | MSB binary | temperature of the air in degress celcius |
n + 6 | MSB binary | ? unused? (PO2??? 0=1.2, 1=1.3, 2=1.4, 3=1.5, 4=1.6???) |
n + 7 | MSB binary | Oxygen in % (= Nitrox mode, air mode: 0); Bit 6 & 7 are ignored. |
n + 8 | MSB binary | pressure at the beginning of the dive in bar / 2 |
n + 9 | MSB binary | altitude and personal settings (height (0..2) + 3 * personal (0..2)). Bit 6:Gauge active (on Stinger and Mosquito) |
n + 10 | MSB binary | interval (10s, 20s, 30s or 60s) |
n + 11 | MSB binary | dive number in the Vyper/Cobra (for repetitive dives) |
n + 12 | MSB binary | hours of the surface interval |
n + 13 | MSB binary | minutes of the surface interval |
Profile information
The profile data is a stream of bytes. Every minute (or 30s or 20s – see the profile interval) a byte is recorded. This byte is the delta depth in ft to the last depth! E.g. you start your dive at a depth of 0 feet go down to 30ft in a minute, so the value is –30ft (because you go 30ft down) or $E2 in binary, if you then go up to 20ft, the next value will be +10ft (because you go 10ft up) or $0A in binary.
Some values have special meanings:
Byte | Type | Description |
---|---|---|
$79 | unused | |
$7a | Slow | The diver ascended above dive depth limit. This symbol marks every interval in which the SLOW indicator appeared |
$7b | Attn/Violation | Dive Attention Mark as described in the dive computer user manual |
$7c | Bookmark/Heading | The diver pressed the PLAN button during this interval |
$7d | Surfaced | The diver ascended above the minimum diving depth (1.2m) during this interval |
$7e | Deco | A decompression ceiling first appeared during this interval. The dive computer’s ASC indicator appeared |
$7f | Ceiling | The diver ascended above the decompression ceiling during this interval |
$80 | End | end of the dive. The next byte is n + 1 in the format description of the dive |
$81 | Safety Stop | The diver ascended above a mandatory safety stop ceiling during this interval |
$82 | End of data | set after the last dive (written after the dive as a marker, so technically not profile information) |
$83 | Increased workload (not generated by the computers) | |
$84 | unused | |
$85 | Cold water (not generated by the computers) | |
$86 | unused | |
$87 | Gas change | Vytec only: switched to a different gas. The following byte contains the percent of oxygen in that gas |
Necessary conversions
meter = (int)(feet * 0.3048 * 10) / 10
psi = bar * 14.50377377
fahrenheit = celcius * 1.8 + 32
Altitude:
value | meters | feet |
---|---|---|
0 | 700m | 2300ft |
1 | 1500m | 5000ft |
2 | 2400m | 8000ft |
ATTN: the computers don’t round after the 2. digit, when calculating feet => meter! They cut it after the 2. digit. This results to the modified formula.
PC Protocol of Suunto EON/Solution/Vario
This document describes the transfer protocol and memory layout of these suunto diving computers:
- Suunto Eon
- Suunto Eon Lux
- Suunto Solution Alpha
- Suunto Solution Alpha Lux
- Suunto Solution Nitrox
- Suunto Vario (same as the Nitrox model)
The [[Suunto Solution]] is an older model with a different communication scheme.
Open Questions / Unknown things
- Does more than the 3 bytes for the transmission exist? I checked all letters, but there may be others?!?
- Any way to set the time of the EON? I don’t think so 🙁
- Does the EON really has a 3 byte counter for the number of dives? Or is it only 2 bytes and the first byte has a special meaning?
- What meanings have the other bytes in the header (32..255 with the exception of the serial number in 244..246)? I think 32..210 are unused, but the other contains constant (they never changed at my EON) data.
- How does the PC software find out, where the first dive in the log starts? At the moment I get the $82 position from the header and search for next $80 (end of dive), skip the temperature and pressure byte and – viola – the first (oldest) dive.
- information about the Nitrox model missing
Communication
The protocol uses 1200 8N2, which means 1200 baud with 8 bits, no parity and 2 stop-bits.
Transfer
You can send the following data to the EON:
- ‘N’ ($4E) followed by 20 bytes, sets the owner name of the dive computer.
- ‘T’ ($54) followed by 1 byte ($14, $1E, $3C, which are 20s, 30s and 60s) sets the data rate for the diving profile. Other values may be possible, so the profile values may be recorded with a 1s to a 255s interval – but they should not be used (information from the developer of the EON)
- ‘P’ ($50) The computer sends $901 bytes (I call it the P-block) back to the computer.
Format of the P-block
The P-block has a $100 byte header and a $800 byte ring-buffer for the profile data plus a one byte checksum. The ring-buffer on a new interface only consists of $FF bytes.
The last byte after the P-block is a checksum: c
unsigned char chk = 0x00;
for(int i=0; i<0x900; ++i)
chk += buf[i];
The default name of the LOG files are: * ‘‘PROFILE.EON’’ for the Suunto Eon * ‘‘PROFILE.SOA’’ for the Suunto Solution Alpha * ‘‘PROFILE.SNV’’ for the Suunto Solution Nitrox/Vario
Header of the P-block
offset | format | testvalue | content
0–2 | MSB binary | $00015E | number of dives made with the computer (here: 180; from the history). I am not sure, if the upper byte is used (I haven’t made 65536 dives yet 🙂 |
3–4 | MSB binary | $0258 | divetime under water in minutes (here: 600; from the history) |
5–6 | MSB binary | $3F46 | max. depth (here: $3F46 / 128.0 = 126.5 feet; from the history) |
7–8 | MSB binary | $0100 | $900 – this value = offset after the last dive (here: $800) |
9 | MSB binary | $3C | current profile interval (here: 60s) |
10 | MSB binary | $18 | altitude settings (value / 32 = Altitude, here: $18 / 32 = 0, so A0) [bit 0: unknown (always = 0?), bit 1: nitrox, bit 2: unknown (always = 0?), bit 3: metric, bit 4: air (= EON)] |
11 | MSB binary | $60 | current year – 1900 (here: 96 => 1996, 00 would be 2000) |
12..31 | ASCII | “EON – Markus Fritze ” | 20 bytes string, that is filled with spaces. Not zero terminated! If the owner name is never set, it contains $FF..$FF |
32..210 | binary | $FF | unused? |
211..243 | binary | $?? | unknown |
244..246 | BCD | $502159 | serial number of the computer (here: 502159) |
247..255 | binary | $?? | unknown |
Ring-Buffer of the P-block
The ring-buffer is a stream of data, which ends at the position, that is marked in the header. At this position the computer starts writing the information from the next dive. If the write pointer reaches the value $900, it jumps back to $100.
Format for one dive
offset | format | testvalue | content |
---|---|---|---|
0 | MSB binary | $05 | surface interval (minutes) |
1 | MSB binary | $01 | surface interval (hours) (here: 1:05) |
2 | MSB binary | $01 | repetitive dive counter (here: the first dive). The counter resets to 1, when the computer turns off after a longer pause. Every dive before that is a repetitive dive and increments the counter. |
3 | MSB binary | $3C | profile interval for this dive (here: 60s), this is necessary, because the interval may be changed after every dive and the ring-buffer still contains information about dives with other profile intervals. |
4 | MSB binary | $38 | altitude settings (value / 32 = Altitude, here: $18 / 32 = 0, so A0) – bit 0: unknown (always = 0?), bit 3: metric, bit 4: air (= EON) |
5 | MSB binary | $64 | A solution alpha always transmits a 0. on nitrox: nitrogen level |
6 | BCD | $97 | year (here: 1997). Year 2000 is $00 |
7 | BCD | $01 | month (here: 1 = January) |
8 | BCD | $31 | day (here: 31) |
9 | BCD | $13 | hour (here: 13 or 1pm) |
10 | BCD | $35 | minute (here: 35) |
11 | … binary | … | profile data |
n | MSB binary | $80 | end of the dive marker |
n + 1 | MSB binary | $3C | temperature at the dive in degree celcius – 40 (here: 60 – 40 = 20 degree celcius) |
n + 2 | MSB binary | $19 | tank preassure at the end of the dive in bar (here: 25 * 2 = 50bar) – A solution alpha always transmits a 0. |
Profile information
The profile data is a stream of bytes. Every minute (or 30s or 20s – see the profile interval) a byte is recorded. This byte is the delta depth in ft to the last depth! E.g. you start your dive at a depth of 0 feet go down to 30ft in a minute, so the value is –30ft (because you go 30ft down) or $E2 in binary, if you then go up to 20ft, the next value will be +10ft (because you go 10ft up) or $0A in binary.
Some values have special meanings:
Byte | Type | Description |
---|---|---|
$7d | Surfaced | you have reached the surface while (or after) the dive |
$7e | ASC | dive now is a decompression dive |
$7f | ERR | decompression missed |
$80 | End | end of the dive. |
$81 | Slow | Slow warning while the dive. If the dive ends with $7d8180 (Surfaced, Slow, End) it means, you finished the dive with a blinking SLOW warning in the display. |
$82 | End of data | set after the last dive (written after the dive as a marker, so technically not profile information) |
Necessary conversions
meter = (int)(feet * 0.3048 * 10) / 10
psi = bar * 14.50377377
fahrenheit = celcius * 1.8 + 32
Altitude:
value | meters | feet |
---|---|---|
0 | 700m | 2300ft |
1 | 1500m | 5000ft |
2 | 2400m | 8000ft |
ATTN: the computers (checked on the solution alpha) don’t round after the 2. digit, when calculating feet => meter! They cut it after the 2. digit. This results to the modified formula.
PC Protocol of Suunto Solution
These computers is the first Suunto computer with a PC interface. The protocol is totally different from the later models. Gary Lorensen described it first, the PDF is available on his server: http://www.aquadivelog.org/divelog/docman/solution.pdf
PC Protocol of Suunto EON/Solution/Vario
This document describes the transfer protocol and memory layout of these Suunto diving computers:
- Suunto Eon
- Suunto Eon Lux
- Suunto Solution Alpha
- Suunto Solution Alpha Lux
- Suunto Solution Nitrox
- Suunto Vario (same as the Nitrox model)
The [[Suunto Solution]] is an older model with a different communication scheme.
Open Questions / Unknown things
- Does more than the 3 bytes for the transmission exist? I checked all letters, but there may be others?!?
- Any way to set the time of the EON? I don’t think so 🙁
- Does the EON really has a 3 byte counter for the number of dives? Or is it only 2 bytes and the first byte has a special meaning?
- What meanings have the other bytes in the header (32..255 with the exception of the serial number in 244..246)? I think 32..210 are unused, but the other contains constant (they never changed at my EON) data.
- How does the PC software find out, where the first dive in the log starts? At the moment I get the $82 position from the header and search for next $80 (end of dive), skip the temperature and pressure byte and – viola – the first (oldest) dive.
- information about the Nitrox model missing
Communication
The protocol uses 1200 8N2, which means 1200 baud with 8 bits, no parity and 2 stop-bits.
Transfer
You can send the following data to the EON:
- ‘N’ ($4E) followed by 20 bytes, sets the owner name of the dive computer.
- ‘T’ ($54) followed by 1 byte ($14, $1E, $3C, which are 20s, 30s and 60s) sets the data rate for the diving profile. Other values may be possible, so the profile values may be recorded with a 1s to a 255s interval – but they should not be used (information from the developer of the EON)
- ‘P’ ($50) The computer sends $901 bytes (I call it the P-block) back to the computer.
Format of the P-block
The P-block has a $100 byte header and a $800 byte ring-buffer for the profile data plus a one byte checksum. The ring-buffer on a new interface only consists of $FF bytes.
The last byte after the P-block is a checksum: c
unsigned char chk = 0x00;
for(int i=0; i<0x900; ++i)
chk += buf[i];
The default name of the LOG files are: * ‘‘PROFILE.EON’’ for the Suunto Eon * ‘‘PROFILE.SOA’’ for the Suunto Solution Alpha * ‘‘PROFILE.SNV’’ for the Suunto Solution Nitrox/Vario
Header of the P-block
offset | format | testvalue | content
0–2 | MSB binary | $00015E | number of dives made with the computer (here: 180; from the history). I am not sure, if the upper byte is used (I haven’t made 65536 dives yet 🙂 |
3–4 | MSB binary | $0258 | divetime under water in minutes (here: 600; from the history) |
5–6 | MSB binary | $3F46 | max. depth (here: $3F46 / 128.0 = 126.5 feet; from the history) |
7–8 | MSB binary | $0100 | $900 – this value = offset after the last dive (here: $800) |
9 | MSB binary | $3C | current profile interval (here: 60s) |
10 | MSB binary | $18 | altitude settings (value / 32 = Altitude, here: $18 / 32 = 0, so A0) [bit 0: unknown (always = 0?), bit 1: nitrox, bit 2: unknown (always = 0?), bit 3: metric, bit 4: air (= EON)] |
11 | MSB binary | $60 | current year – 1900 (here: 96 => 1996, 00 would be 2000) |
12..31 | ASCII | “EON – Markus Fritze ” | 20 bytes string, that is filled with spaces. Not zero terminated! If the owner name is never set, it contains $FF..$FF |
32..210 | binary | $FF | unused? |
211..243 | binary | $?? | unknown |
244..246 | BCD | $502159 | serial number of the computer (here: 502159) |
247..255 | binary | $?? | unknown |
Ring-Buffer of the P-block
The ring-buffer is a stream of data, which ends at the position, that is marked in the header. At this position the computer starts writing the information from the next dive. If the write pointer reaches the value $900, it jumps back to $100.
Format for one dive
offset | format | testvalue | content |
---|---|---|---|
0 | MSB binary | $05 | surface interval (minutes) |
1 | MSB binary | $01 | surface interval (hours) (here: 1:05) |
2 | MSB binary | $01 | repetitive dive counter (here: the first dive). The counter resets to 1, when the computer turns off after a longer pause. Every dive before that is a repetitive dive and increments the counter. |
3 | MSB binary | $3C | profile interval for this dive (here: 60s), this is necessary, because the interval may be changed after every dive and the ring-buffer still contains information about dives with other profile intervals. |
4 | MSB binary | $38 | altitude settings (value / 32 = Altitude, here: $18 / 32 = 0, so A0) – bit 0: unknown (always = 0?), bit 3: metric, bit 4: air (= EON) |
5 | MSB binary | $64 | A solution alpha always transmits a 0. on nitrox: nitrogen level |
6 | BCD | $97 | year (here: 1997). Year 2000 is $00 |
7 | BCD | $01 | month (here: 1 = January) |
8 | BCD | $31 | day (here: 31) |
9 | BCD | $13 | hour (here: 13 or 1pm) |
10 | BCD | $35 | minute (here: 35) |
11 | … binary | … | profile data |
n | MSB binary | $80 | end of the dive marker |
n + 1 | MSB binary | $3C | temperature at the dive in degree celcius – 40 (here: 60 – 40 = 20 degree celcius) |
n + 2 | MSB binary | $19 | tank preassure at the end of the dive in bar (here: 25 * 2 = 50bar) – A solution alpha always transmits a 0. |
Profile information
The profile data is a stream of bytes. Every minute (or 30s or 20s – see the profile interval) a byte is recorded. This byte is the delta depth in ft to the last depth! E.g. you start your dive at a depth of 0 feet go down to 30ft in a minute, so the value is –30ft (because you go 30ft down) or $E2 in binary, if you then go up to 20ft, the next value will be +10ft (because you go 10ft up) or $0A in binary.
Some values have special meanings:
Byte | Type | Description |
---|---|---|
$7d | Surfaced | you have reached the surface while (or after) the dive |
$7e | ASC | dive now is a decompression dive |
$7f | ERR | decompression missed |
$80 | End | end of the dive. |
$81 | Slow | Slow warning while the dive. If the dive ends with $7d8180 (Surfaced, Slow, End) it means, you finished the dive with a blinking SLOW warning in the display. |
$82 | End of data | set after the last dive (written after the dive as a marker, so technically not profile information) |
Necessary conversions
meter = (int)(feet * 0.3048 * 10) / 10
psi = bar * 14.50377377
fahrenheit = celcius * 1.8 + 32
Altitude:
value | meters | feet |
---|---|---|
0 | 700m | 2300ft |
1 | 1500m | 5000ft |
2 | 2400m | 8000ft |
ATTN: the computers (checked on the solution alpha) don’t round after the 2. digit, when calculating feet => meter! They cut it after the 2. digit. This results to the modified formula.
Newton Keyboard Enabler
The Newton Keyboard Enabler (NKE) allows you to connect the Newton keyboard to any Macintosh and use it as a replacement for the big ADB keyboards. Very nice for presentations where space is rare.
The NKE is a system extension, but it does not do any trap patching. To be exact: the NKE is a FBA (faceless background application), that works like a normal application, but without any human interface. The NKE should work on any Macintosh with Mac OS 7 and at least one free serial port. NKE will grab the serial port, so it is not possible for any other application to use the port.
You may quit the NKE with a “Quit” AppleEvent or with the hotkey Control-Option-^. Hold the three keys for about 2 seconds down, if it doesn’t work: retry. If you are lucky, you hear three beeps, then you have to press a key on the Newton keyboard. After that, the NKE has quit.
The Newton Keyboard Enabler is freeware. You may use it as you wish, but need written permission for any commercial distribution!
Configuring the NKE
The configuration is a bit tricky, you have to use ResEdit or Resorcerer!
- Choose the serial port — Open NKE with ResEdit and open the STR# 128 Resource. For the modem port (the default) enter “.AIn” and “.AOut”; for the printer port enter “.BIn” and “.BOut”. Pay attention to internal modems on PowerBooks etc.
- Choose the keyboard layout and language — Open the PREF 128 resource (attention: only a Resorcerer template is available, ResEdit users have to use the hex-editor). The resource is 4 bytes long:
- The last byte is the keyboard language. 3 is default (Germany), you may want to change it to 0 (US-English).
- The first byte (default: 0 = off) allows you to send different codes for the shift keys of the Newton keyboard (set the value to 1). You should leave this value unchanged.
After installing NKE (dragging it onto the system folder) and connecting the keyboard to the right serial port, restart your Macintosh. If NKE can’t recognize the keyboard, you may have to check the serial port. If the keyboard layout is wrong, you have to change the keyboard language.
Hint: You may change the Filetype of NKE from “appe” to “APPL” and launch NKE directly from your desktop – no restart necessary!
The current version
- newton-keyboard-enabler–10.sit 6kb, just the binary
- NKEsrc.sit 43kb, NKE Sourcecode, MacOpen Artikel (German), etc
- NKE MacOpen Artikel (German)
NKE MacOpen Artikel
Newton Keyboard am Mac
Dieses mal will ich etwas zu dem Anschluß eines Newton Keyboards am Mac schreiben. Das Newton Keyboard ist nämlich durch seine kleinen Abmessungen ideal für Messen etc. zu verwenden.
Der Anschluß
Das Newton Keyboard ist für etwas über 100,- DM im Apple Fachhandel zu erhalten. Das kleine schwarze Keyboard wird inklusiver einer Tasche geliefert. Da es beim Newton an die serielle Schnittstelle angeschlossen wird, kam mir die Idee das Keyboard an einen Mac anzuschließen. Mit Hilfe eines Terminalprogramms habe ich schnell ermitteln können, daß das Keyboard mit 9600 Baud seine Daten an den Rechner sendet – 8 Bits pro Zeichen, keine Parität, ein Stop-Bit. Elektrisch war die Ansteuerung also kein Problem.
Nun mußte ich rausbekommen, was für Daten von der Tastatur gesendet werden. Auch hier: keine Überraschungen. Die Tastatur sendet bei jedem Tastendruck bzw. beim Loslassen einer Taste ein Byte. Unterscheiden kann man das Drücken bzw. Loslassen einer Taste daran, daß beim Loslassen Bit 7 gesetzt wird. Der 7 Bit Scancode entspricht quasi zu 100% denen der normalen Mac-Keyboards.
Sobald die Schnittstelle geöffnet wird, sendet das Keyboard einen String mit Identifikationsdaten. Leider habe ich keine genaueren Informationen über den Aufbau der Daten, es reicht jedoch zur Erkennung der Newton-Tastatur.
Die Software
Die Aufgabe eines Newton Keyboard Treibers ist also recht klar umrissen: Serielle Schnittstelle öffnen, die ersten Bytes ignorieren, dann bei jedem gesendeten Byte entweder das Drücken oder das Loslassen einer Taste melden. So weit so gut. Nur wie macht man das?
Ich wollte versuchen keine Systemerweiterung zu schreiben, die irgendwelche Traps patched, sondern dachte zuerst: das muß ja einfach sein, einfach per PostEvent() das Drücken und Loslassen melden und fertig. Leider ist es “etwas” komplizierter…
Der einfache Teil ist klar: ich schreibe eine “faceless background application” kurz FBA. Ein FBA verhält sich für den normalen Anwender, wie eine Systemerweiterung und wird auch in dem Ordner installiert. Für das MacOS handelt es sich aber um ein ganz normales Mac-Programm mit Event-Loop. FBAs dürfen jedoch – mit Ausnahme des Notification Managers – keine Bildschirmausgaben tätigen. Für einen Tastaturtreiber stellt dies aber kein Problem dar. FBAs erlauben AppleEvents und so kann man sehr elegant kleinere Erweiterungen für viele Programme als FBA implementieren z.B. AppleScript-Erweiterungen für FileMaker Pro.
Die serielle Schnittstelle
Das Öffnen der Schnittstelle mit OpenDriver() ist relativ einfach und klar. Die Namen der Ports habe ich in den Resource-Fork abgelegt, so daß man sie bei Bedarf leicht ändern kann. Besser wäre natürlich ein Kontrollfeld, wo man den Port direkt wählen kann – oder die Möglichkeit den Port automatisch zu ermitteln. Die Baudrate setze ich danach auf 9600 8N1 – ist normalerweise eh Standard, aber sicher ist sicher. Handshaking ist für die Tastatur nicht nötig. Um der Tastatur die Möglichkeit zu geben ihre Identifikation zu senden, wartet der Treiber 1/2 Sekunde und liest dann alle an der seriellen Schnittstelle anliegenden Bytes ein. Welche Bytes erwartet werden, kann man dem Listing entnehmen. Ein kleiner Plausibilitätstest stellt sicher, daß auch wirklich eine Newton Tastatur angeschlossen ist.
Nun kommt aber der Trick: anstatt im Event-Loop die serielle Schnittstelle zu pollen, lese ich asynchron von der Schnittstelle! Dies belastet das MacOS fast gar nicht und bei jedem Byte, das an der Schnittstelle ankommt, wird automatisch eine Callback-Routine von mir aufgerufen. Dort verarbeite ich das gelesene Byte und starte den nächsten Lesevorgang. Einzige Falle ist hier, daß man den Parameterblock und andere Variablen globale halten muß, denn auf dem lokalen Stack würden sie ja beim Verlassen des Unterprogramms gleich gelöscht werden. Abstürze wären die Folge.
In der Testphase hat es sich als nützlich erwiesen, wenn man den Treiber beenden kann. Dazu setzt man den Dateityp nicht auf ‘appe’ (der Filetype von FBAs), sondern ganz normal auf ‘APPL’. Nun kann man den Treiber einfach per Doppelklick starten. Per Hot-Key (Control-Option-^) bzw. Quit-AppleEvent verläßt der Treiber nun den Event-Loop. Nach drei SysBeeps() wartet er auf ein letztes Byte an der serielle Schnittstelle und beendet sich dann selbst. Den Hot-Key muß man etwas länger drücken, denn der Event-Loop wird nur einmal pro Sekunde durchlaufen. Normalerweise braucht der Treiber ja diesen Event-Loop gar nicht und so kostet er wenigstens kaum Rechenzeit.
Die Scancodes
Die Tastatur meldet ja nur ein Byte für einen Tastendruck. Dieses Byte (Scancode genannt) muß nun in einen ASCII-Code umgerechnet werden. Dazu gibt es im MacOS die KMAP- und KCHR-Resourcen. KMAP erlaubt es Scancodes von verschiedenen Tastaturen zu normalisieren, d.h. auf gleiche Scancodes umzurechnen. Jede Tastatur kann ja völlig eigene Scancodes senden. Ferner wird in der KMAP-Resource definiert, bei welchen Tastendrücken die LEDs am erweiterten Keyboard angeschaltet werden. Das Newton Keyboard hat keine LEDs, so erübrigt sich weiterer Aufwand in diese Richtung.
Ebenfalls muß das Verhalten der Capslock-Taste simuliert werden. Beim Newton Keyboard wird sie ja nicht mechanisch blockiert. Man muß also per Software einen Caps-Schalter implementieren.
Den erzeugten normalisierten Keycode muß man nun in die KeyMap-Bitmaske übertragen. Diese Bitmaske erhält man, wenn man die Funktion GetKeys() aufruft. Viele Programme tun dies und wir müssen diese Bitmaske selbst aktualisieren. Hierbei gibt es folgendes zu beachten: es können mehrere Tastaturen angeschlossen sein! Jede Tastatur braucht ihre eigene interne KeyMap, die bei jedem Tastendruck einfach in die KeyMap des Systems kopiert wird.
Ferner müssen noch einige (undokumentierte) globale Variablen richtig gesetzt werden, damit u.a. Auto-Repeat funktioniert. Diese Variablen habe ich durch Analyse des originalen ADB-Treibers von Apple gefunden. Nunja, eine andere Möglichkeit kenne ich nicht und Auto-Repeat ist irgendwie zu witzig, als das man es nicht unterstützt.
Zu guter Letzt wird der Scancode in einen (oder zwei) ASCII-Codes umgerechnet. Dazu braucht man lediglich die Funktion KeyTranslate() aufrufen. Diese Funktion bekommt eine KCHR-Routine übergeben, welche beschreibt, wie man einen Scancode in einen ASCII-Code umrechnet. Unterschiedliche KCHR-Resourcen erlauben es z.B. für verschiedene Sprachen verschiedene Tastaturlayouts zu unterstützen. Die Scancodes sind nämlich – trotz unterschiedlich beschrifteter Tastenkappen – gleich! Es gibt aber noch ein paar Dinge zu beachten: Die Funktion kann zwei ASCII-Codes erzeugen, da einige Tastaturen auf einen realen Tastendruck zwei Tastendrücke simulieren. Ich glaube in Japan ist soetwas nicht unüblich. Ferner muß man den Status “state” global halten. In diesem Status wird zwischen zwei Tastendrücken gespeichert, ob z.B. ein Dead-Key gedrückt wurde. Beispiel: man drückt ein Taste, die ein Akzent einleitet und danach eine Taste, auf welche das Akzent gesetzt werden soll.
Zu guter Letzt wird der Tastendruck als keyDown bzw. keyUp Message an MacOS gepostet. Natürlich nicht ohne vorher noch ein paar undokumentierte Variablen im MacOS zu setzen. Nunja.
Die Kompilierung
Um das Programm zu kompilieren muß lediglich der Source, wie auch die Resource kompiliert werden. Das Programm bekommt als Dateityp ‘appe’ und als Creatorcode ‘NwtK’ zugewiesen. 64k Speicherzuteilung reichen dicke. Lediglich die Flags müssen sorgfältig gesetzt werden (siehe Grafik). Wer will, kann den Dateityp auf ‘APPL’ setzen und den Treiber per Doppelklick bei Bedarf starten.
Um die serielle Schnittstelle zu ändern, muß man lediglich in der STR# 128 Resource die Einträge von “.AIn” und “.AOut” (Modemanschluß) z.B. auf “.BIn” und “.BOut” (Druckeranschluß) ändern.
In der PREF 128 Resource kann man sowohl das Keyboard Layout umschalten: das letzte Byte ist 3 für Deutschland oder 0 für US-Englisch. Weitere Layouts sind möglich, man muß lediglich entsprechende KCHR-Resourcen zur Verfügung stellen. Üblichweise sind seit MacOS 7.5 alle internationalen Keyboard-Layouts bereits im System vorhanden.
Das erste Byte ermöglicht es zwischen der KMAP 0 und KMAP 1 Resource zu wählen. Diese Layouts unterscheiden sich durch die Behandlung der gemeinsamen Shift-Tasten. Üblich ist es, daß beide Shift, Command, etc. Tasten den gleichen Scancode an die Anwenderprogramme melden. Wählt man die KMAP 1 Resource, so werden diese Tasten unterschiedlich gemeldet. Programme können dies zwar per Software umschalten (MagicMac nutzt dies z.B.), aber dies erfordert die direkte Programmierung der ADB-Tastaturen, was bei unserer Newton Tastatur an der seriellen Schnittstelle halt nicht möglich ist.
Die aktuelle Version des Newton Keyboard Enablers findet sich auf http://www.emagic.de/mmm/ – neben vielen anderen Programmen von mir.
########################################
############### LISTINGs ###############
########################################
/***
* Newton Keyboard Enabler.c
*
* Erlaubt die Nutzung eines seriellen Newton-
* Keyboards an einem Mac. Das Keyboard verhält
* sich in fast allen Fällen genau wie ein
* originales ADB-Keyboard (Ausnahme: MacsBug
* kann es nicht nutzen)
*
* Entwickelt mit dem CodeWarrior 9 von
* Metrowerks.
*
* (c)1996 MAXON Computer, Markus Fritze
***/
// c_moeller@macopen.com
// true, wenn das Programm beendet werden soll
Boolean gDoQuitFlag;
/***
* unsere AppleEvent-Routinen
* (schließlich sind wir ein ordentliches
* MacOS Programm)
***/
static pascal OSErr DoAENoErr(
const AppleEvent*, AppleEvent*, long)
{
return noErr; // AppleEvent ist ok
}
static pascal OSErr DoAEQuitAppl(
const AppleEvent*, AppleEvent*, long)
{
gDoQuitFlag = true; // Programm beenden
return noErr;
}
// einen (hoffentlich) undefinierten Code
// benutzen wir als ID-Code für die Tastatur
#define NEWTON_KEYBOARD_CODE 117L
// Zugriffsfunktionen ähnlich <LowMem.h>
// für den Tastaturtreiber
static inline SInt16 LMGetKeyLast()
{ return *(SInt16*)0x0184; };
static inline void LMSetKeyLast(SInt16 value)
{ *(SInt16*)0x0184 = value; };
static inline SInt16 LMGetHiKeyLast()
{ return *(SInt16*)0x0216; };
static inline void LMSetHiKeyLast(SInt16 value)
{ *(SInt16*)0x0216 = value; };
static inline SInt32 LMGetKeyTime()
{ return *(SInt32*)0x0186; };
static inline void LMSetKeyTime(SInt32 value)
{ *(SInt32*)0x0186 = value; };
static inline SInt32 LMGetKeyRepTime()
{ return *(SInt32*)0x018A; };
static inline void LMSetKeyRepTime(SInt32 value)
{ *(SInt32*)0x018A = value; };
// ohne "inline", wegen eines 68k Compilerbugs
// beim CodeWarrior 9
static /*inline*/ KeyMap *LMGetKeyMapPtr()
{ return (KeyMap*)0x0174; };
// Unsere globalen Variablen für die Tastatur
Handle gKMAP;
Handle gKCHR;
UInt8 gKeyMap[16];
/***
* Keyboard-Variablen initialisieren
***/
static void InitKeyboard()
{
Handle thePref =
::Get1Resource('PREF', 128);
// eigener Typ: Newton Keyboard
gKMAP = ::Get1Resource('KMAP', **thePref);
if(!gKMAP) ::ExitToShell();
::HLockHi(gKMAP);
// ein deutsches Keyboard:
gKCHR = ::GetResource('KCHR',
((short*)*thePref)[1]);
if(!gKCHR)
// ein US-Keyboard:
gKCHR = ::GetResource('KCHR', 0);
if(!gKCHR) ::ExitToShell();
::HLockHi(gKCHR);
// eigene Keymap löschen
for(int i=0; i<sizeof(gKeyMap); i++)
gKeyMap[i] = 0;
::ReleaseResource(thePref);
}
/***
* Tastencode senden
***/
static void PostKeyMessage(
UInt8 inKey, UInt8 inKeyCode)
{
// keine Taste => raus
if(inKey == 0x00L) return;
// Message zusammensetzen
UInt32 theMessage = inKey
| UInt16(inKeyCode << 8)
| (NEWTON_KEYBOARD_CODE << 16);
// Taste gedrückt
if(!(inKeyCode & 0x80)) {
SInt32 theTicks = LMGetTicks();
LMSetKeyTime(theTicks);
LMSetKeyRepTime(theTicks);
LMSetKeyLast(theMessage);
LMSetHiKeyLast(NEWTON_KEYBOARD_CODE);
::PostEvent(keyDown, theMessage);
// Taste losgelassen
} else {
// Key-Up-Flag löschen
theMessage &= 0xFFFF7FFF;
::PostEvent(keyUp, theMessage);
}
}
/***
* Tastendruck (bzw. das Loslassen) dem MacOS
* melden
***/
static void EnterKeycode(UInt8 inCode)
{
// aktuelle Taste im System löschen
LMSetKeyLast(0);
LMSetHiKeyLast(0);
// true, wenn Taste losgelassen wurde
Boolean theDownFlag =
(inCode & 0x80) == 0x80;
// MacOS-Keycode erzeugen
UInt8 theKeyCode;
Ptr theKMAP = *gKMAP;
theKeyCode = theKMAP[(inCode & 0x7F) + 4];
// Sondercode erkannt?
if(theKeyCode & 0x80) {
// erstmal das Kennungs-Bit löschen
theKeyCode &= 0x7F;
// Anzahl der Sondereinträge
SInt16 theCount =
*reinterpret_cast<SInt16*>
(&theKMAP[0x84]);
// ab hier geht es mit den Tabellen los
UInt8 *theKMapP =
reinterpret_cast<UInt8*>
(&theKMAP[0x86]);
while(theCount-- > 0) {
// Code gefunden?
if(*theKMapP++ != theKeyCode) {
// zum nächsten Eintrag
theKMapP += theKMapP[1] + 2;
continue;
}
if((*theKMapP & 0x0F) == 0x00)
return;
break;
}
}
// Capslock Abfrage
if(theKeyCode == 0x39) {
if(theDownFlag) { // Taste gedrückt?
// Caps bereits gesetzt?
if(gKeyMap[theKeyCode >> 3]
& (1 << (theKeyCode & 7))) {
// dann lösen!
theDownFlag = false;
}
} else { // Taste losgelassen?
// (das interessiert uns nie!)
return;
}
}
// in die KeyMap eintragen (vorerst nur in
// die eigene)
if(theDownFlag) {
gKeyMap[theKeyCode >> 3] |=
1 << (theKeyCode & 7);
} else {
gKeyMap[theKeyCode >> 3] &=
~(1 << (theKeyCode & 7));
// Flag für "losgelassen"
theKeyCode |= 0x80;
}
// Tastencodes in globalen Variablen merken
LMSetKbdLast(theKeyCode);
LMSetKbdType(NEWTON_KEYBOARD_CODE);
// globale KeyMap updaten
::BlockMoveData(gKeyMap, LMGetKeyMapPtr(),
sizeof(KeyMap));
// aktuelle Modifiers für KeyTranslate lesen
UInt16 theModifiers = *(3 +
reinterpret_cast<UInt16*>
(LMGetKeyMapPtr()));
// ROL.W #1,<ea>
theModifiers = (theModifiers >> 15)
| (theModifiers << 1);
// ASCII-Codes (denkbar: zwei pro
// Tastendruck!) errechnen
static UInt32 state = 0;
UInt32 lStructure = ::KeyTranslate(*gKCHR,
theKeyCode | (theModifiers << 8),
&state);
// ggf. zwei Tasten posten
PostKeyMessage(lStructure >> 16, theKeyCode);
PostKeyMessage(lStructure, theKeyCode);
}
/***
* diese asynchrone Routine pollt das Keyboard
* an der Seriellen
***/
#include <Serial.h>
// UPP für die Callback-Routine
IOCompletionUPP gIOUPP;
// Refnums für Serial ein/aus
SInt16 gSDIn, gSDOut;
// das empfangene Zeichen
UInt8 gInChar;
// der Parameterblock (asynchron!)
ParamBlockRec gParamBlk;
/***
* das nächste Byte von der
* Tastatur asynchron lesen
***/
static void GetNextByte()
{
if(gDoQuitFlag) return;
// Callback setzen
gParamBlk.ioParam.ioCompletion = gIOUPP;
// Port lesen
gParamBlk.ioParam.ioRefNum = gSDIn;
// Buffer auf unser Byte
gParamBlk.ioParam.ioBuffer = (Ptr)&gInChar;
// ein Byte lesen
gParamBlk.ioParam.ioReqCount = 1L;
// ab der aktuellen Position
gParamBlk.ioParam.ioPosMode = fsAtMark;
// kein Offset...
gParamBlk.ioParam.ioPosOffset = 0L;
// Anforderung absetzen
PBReadAsync(&gParamBlk);
}
/***
* Diese Routine wird angesprungen,
* wenn ein Byte eingetroffen ist.
***/
static void MyCompletion(
ParmBlkPtr ioParam : __A0)
{
#pragma unused(ioParam)
// Byte verarbeiten
EnterKeycode(gInChar);
// nächstes Byte anfordern
GetNextByte();
}
/***
* main()
***/
void main()
{
// 16k anstatt 2k an Stack!
::SetApplLimit((Ptr)((UInt32)
::GetApplLimit() - 0x4000));
// Crasht vor MacOS 7.5.4, falls eine zweite
// FBA ebenfalls MaxApplZone() aufruft:
// ::MaxApplZone();
// weitere Init-Calls sind bei FBAs nicht
// erlaubt
::InitGraf(&qd.thePort);
// AppleEvents installieren (wenn vorhanden)
long response;
if(!::Gestalt(gestaltAppleEventsAttr,
&response)) {
if(response &
(1L<<gestaltAppleEventsPresent)) {
if(::AEInstallEventHandler(
kCoreEventClass,
kAEOpenApplication,
NewAEEventHandlerProc(DoAENoErr),
0L, 0))
return;
if(::AEInstallEventHandler(
kCoreEventClass,
kAEOpenDocuments,
NewAEEventHandlerProc(DoAENoErr),
0L, 0))
return;
if(::AEInstallEventHandler(
kCoreEventClass,
kAEPrintDocuments,
NewAEEventHandlerProc(DoAENoErr),
0L, 0))
return;
if(::AEInstallEventHandler(
kCoreEventClass,
kAEQuitApplication,
NewAEEventHandlerProc(DoAEQuitAppl),
0L, 0))
return;
}
}
// globale Keyboard-Variablen initialisieren
InitKeyboard();
// ".AIn" und ".AOut" öffnen
OSErr theErr;
Str255 theStr;
::GetIndString(theStr, 128, 2);
theErr = ::OpenDriver(theStr, &gSDOut);
if(theErr) ::ExitToShell();
::GetIndString(theStr, 128, 1);
theErr = ::OpenDriver(theStr, &gSDIn);
if(theErr) goto raus;
// 9600 8N1
theErr = ::SerReset(gSDOut,
baud9600+data8+stop10+noParity);
if(theErr) goto raus;
// Handshaking ausschalten
SerShk theSHandShk;
theSHandShk.fXOn = 0;
theSHandShk.fCTS = 0;
theSHandShk.errs = 0;
theSHandShk.evts = 0;
theSHandShk.fInX = 0;
theSHandShk.fDTR = 0;
theErr = ::Control(gSDOut, 14, &theSHandShk);
if(theErr) goto raus;
long theTicks;
// 1/2 Sekunde auf das Keyboard warten
::Delay(30, &theTicks);
// Anzahl der Byte an der Schnittstelle ermitteln
SInt32 theCount;
::SerGetBuf(gSDIn, &theCount);
// und alle lesen
Str255 theBuf;
::FSRead(gSDIn, &theCount, &theBuf);
// Daten von der Tastatur zum Rechner, wenn die
// Schnittstelle angeschaltet wird (9600 8N1):
// <0x16><0x10> 0x02,
// 'd_id', 0x0CL, // Device-ID?
// 'kybd','appl', 0x01L, // Keyboard-Typ
// 'nofm', 0L, 0x1003dde7L // ???
if(reinterpret_cast<long*>(&theBuf)[3]
!= 'ybda')
goto raus;
gIOUPP = NewIOCompletionProc(MyCompletion);
GetNextByte(); // erstes Byte erwarten
gDoQuitFlag = false;
while(!gDoQuitFlag) {
EventRecord theEvent;
// nur einmal pro Sekunde erwarten wir einen
// Null-Event!
::WaitNextEvent(
everyEvent, &theEvent, 60, 0L);
if(theEvent.what == kHighLevelEvent)
::AEProcessAppleEvent(&theEvent);
#if DEBUG
// zum Debuggen: '^' + Control + Option
// beendet das Programm!
KeyMap theMap;
::GetKeys(theMap);
if((theMap[0] & 0x40000) &&
((theMap[1] & 0xC) == 0xC)) {
break;
}
#endif
}
// auf ein letztes Byte warten!
SysBeep(10); SysBeep(10); SysBeep(10);
// auf Abschluß des aktuellen Polls warten
while(gParamBlk.ioParam.ioResult > 0) {}
// Tastaturstatus zurücksetzen
LMSetKeyLast(0);
LMSetHiKeyLast(0);
for(int i=0; i<sizeof(gKeyMap); i++)
gKeyMap[i] = 0;
::BlockMoveData(gKeyMap, LMGetKeyMapPtr(),
sizeof(KeyMap));
raus:
if(gSDOut) ::KillIO(gSDOut);
if(gSDIn) ::CloseDriver(gSDIn);
if(gSDOut) ::CloseDriver(gSDOut);
}
/***
* Newton Keyboard.r
***/
resource 'KMAP' (0) {
0,
0,
{ 0,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,59,55,56,57,58,59,56,58,59,
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
},
{
}
};
resource 'KMAP' (1) {
0,
0,
{ 0,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,59,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
},
{
}
};
resource 'STR#' (128, "Portnames") {
{ ".AIn",
".AOut"
}
};
data 'TMPL' (128, "PREF") {
/* .Different Shift */
$"1544 6966 6665 7265 6E74 2053 6869 6674"
/* -Keys?BOOL.Keybo */
$"2D4B 6579 733F 424F 4F4C 0E4B 6579 626F"
/* ardregionRGNC */
$"6172 6472 6567 696F 6E52 474E 43"
};
data 'PREF' (128) {
$"0000 0003"
};
/***
* ab hier: optional!
***/
resource 'vers' (1) {
0x1,
0x0,
release,
0x0,
verGermany,
"1.0",
"1.0, ©1996 MAXON Computer, Markus Fritze"
};
resource 'BNDL' (128) {
'NwtK',
0,
{ 'FREF', { 0, 128 },
'ICN#', { 0, 128 }
}
};
resource 'FREF' (128) {
'appe',
0,
""
};
resource 'icl4' (128) {
$"0FFF FFFF FFFF FFFF FFFF FFFF FFFF 0000"
$"F000 0000 0000 0000 0000 0000 000C F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"FF0F CCCC CCCC CCCC CCCC CCCC CCCC F0F0"
$"F0FF CCCC CCCC CCCC CCCC CCCC CCCC FF0F"
$"000F CC99 9999 9999 9999 9999 99CC F0CF"
$"000F CC99 9999 9999 9999 9999 99CC CCCF"
$"000F CC99 C9C9 C9C9 C9C9 C9C9 99CC CCCF"
$"000F CC99 9999 9999 9999 9999 99CC CCCF"
$"000F CC99 9C9C 9C9C 9C9C 9C9C 99CC CCCF"
$"000F CC99 9999 9999 9999 9999 99CC CCCF"
$"000F CC99 C9C9 C9C9 C9C9 C9C9 99CC CCCF"
$"000E CC99 9999 9999 9999 9999 99CC CCCF"
$"000E CC99 9C9C 9CCC CCCC 9C9C 99CC CCCF"
$"000F CC99 9999 9999 9999 9999 99CC FCCF"
$"F00F CC99 9999 9999 9999 9999 99CC FFCF"
$"FF0F CCCC CCCC CCCC CCCC CCCC CCCC F0F0"
$"F0F0 CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"F0CC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"FCCC CCCC CCCC CCCC CCCC CCCC CCCC F000"
$"0FFF FFFF FFFF FFFF FFFF FFFF FFFF"
};
resource 'icl8' (128, purgeable) {
$"00FF FFFF FFFF FFFF FFFF FFFF FFFF FFFF"
$"FFFF FFFF FFFF FFFF FFFF FFFF 0000 0000"
$"FF00 0000 0000 0000 0000 0000 0000 0000"
$"0000 0000 0000 0000 0000 00F6 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FFFF 00FF F8F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 FF00"
$"FF00 FFFF F8F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FFFF 00FF"
$"0000 00FF F8F6 A5A5 A5A5 A5A5 A5A5 A5A5"
$"A5A5 A5A5 A5A5 A5A5 A5A5 F6F8 FF00 F6FF"
$"0000 00FF F8F6 A5A5 A5A5 A5A5 A5A5 A5A5"
$"A5A5 A5A5 A5A5 A5A5 A5A5 F6F6 F6F6 F8FF"
$"0000 00FF F8F6 A5A5 F8A5 F8A5 F8A5 F8A5"
$"F8A5 F8A5 F8A5 F8A5 A5A5 F6F6 F6F6 F8FF"
$"0000 00FF F8F6 A5A5 A5A5 A5A5 A5A5 A5A5"
$"A5A5 A5A5 A5A5 A5A5 A5A5 F6F6 F6F6 F8FF"
$"0000 00FF F8F6 A5A5 A5F8 A5F8 A5F8 A5F8"
$"A5F8 A5F8 A5F8 A5F8 A5A5 F6F6 F6F6 F8FF"
$"0000 00FF F8F6 A5A5 A5A5 A5A5 A5A5 A5A5"
$"A5A5 A5A5 A5A5 A5A5 A5A5 F6F6 F6F6 F8FF"
$"0000 00FF F8F6 A5A5 F8A5 F8A5 F8A5 F8A5"
$"F8A5 F8A5 F8A5 F8A5 A5A5 F6F6 F6F6 F8FF"
$"0000 00FC F8F6 A5A5 A5A5 A5A5 A5A5 A5A5"
$"A5A5 A5A5 A5A5 A5A5 A5A5 F6F6 F6F6 F8FF"
$"0000 00FC F8F6 A5A5 A5F8 A5F8 A5F8 F8F8"
$"F8F8 F8F8 A5F8 A5F8 A5A5 F6F6 F6F6 F8FF"
$"0000 00FF F8F6 A5A5 A5A5 A5A5 A5A5 A5A5"
$"A5A5 A5A5 A5A5 A5A5 A5A5 F6F8 FFF8 F8FF"
$"FF00 00FF F8F6 A5A5 A5A5 A5A5 A5A5 A5A5"
$"A5A5 A5A5 A5A5 A5A5 A5A5 F6F8 FFFF F8FF"
$"FFFF 00FF F8F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 FF00"
$"FF00 FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FF00 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F6"
$"F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00 0000"
$"FFF6 F8F8 F8F8 F8F8 F8F8 F8F8 F8F8 F8F8"
$"F8F8 F8F8 F8F8 F8F8 F8F8 F8F8 FF00 0000"
$"00FF FFFF FFFF FFFF FFFF FFFF FFFF FFFF"
$"FFFF FFFF FFFF FFFF FFFF FFFF"
};
resource 'ICN#' (128) {
{ $"7FFF FFF0 8000 0008 8000 0008 8000 0008"
$"8000 0008 8000 0008 8000 0008 8000 0008"
$"8000 0008 D000 000A B000 000D 13FF FFC9"
$"13FF FFC1 1355 55C1 13FF FFC1 13AA AAC1"
$"13FF FFC1 1355 55C1 13FF FFC1 13A8 0AC1"
$"13FF FFC9 93FF FFCD D000 000A A000 0008"
$"8000 0008 8000 0008 8000 0008 8000 0008"
$"8000 0008 8000 0008 8000 0008 7FFF FFF0",
$"7FFF FFF0 FFFF FFF8 FFFF FFF8 FFFF FFF8"
$"FFFF FFF8 FFFF FFF8 FFFF FFF8 FFFF FFF8"
$"FFFF FFF8 DFFF FFFA 9FFF FFFF 1FFF FFFF"
$"1FFF FFFF 1FFF FFFF 1FFF FFFF 1FFF FFFF"
$"1FFF FFFF 1FFF FFFF 1FFF FFFF 1FFF FFFF"
$"1FFF FFFF 9FFF FFFF DFFF FFFA FFFF FFF8"
$"FFFF FFF8 FFFF FFF8 FFFF FFF8 FFFF FFF8"
$"FFFF FFF8 FFFF FFF8 FFFF FFF8 7FFF FFF0"
}
};
resource 'ics#' (128) {
{ $"FFFE 8002 8002 8002 C003 DFFB 5559 5FF9"
$"5A29 5FF9 DFFB C003 8002 8002 8002 FFFE",
$"FFFE FFFE FFFE FFFE FFFE FFFF 7FFF 7FFF"
$"7FFF 7FFF FFFF FFFE FFFE FFFE FFFE FFFE"
}
};
resource 'ics4' (128) {
$"FFFF FFFF FFFF FFF0 FCCC CCCC CCCC CCF0"
$"FCCC CCCC CCCC CCF0 FCCC CCCC CCCC CCF0"
$"FFCC CCCC CCCC CCFF FFC9 9999 9999 9CFF"
$"0FC9 D9D9 D9D9 9CCF 0FC9 9999 9999 9CCF"
$"0FC9 9D9D DD9D 9CCF 0EC9 9999 9999 9CCF"
$"FFC9 9999 9999 9CFF FFCC CCCC CCCC CCFF"
$"FCCC CCCC CCCC CCF0 FCCC CCCC CCCC CCF0"
$"FCCC CCCC CCCC CCF0 FFFF FFFF FFFF FFF0"
};
resource 'ics8' (128) {
$"FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF00"
$"FFF6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00"
$"FFF6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00"
$"FFF6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00"
$"FFFF F8F6 F6F6 F6F6 F6F6 F6F6 F6F8 FFFF"
$"FFFF F8A5 A5A5 A5A5 A5A5 A5A5 A5F8 FFFF"
$"00FF F8A5 F8A5 F8A5 F8A5 F8A5 A5F6 F6FF"
$"00FF F8A5 A5A5 A5A5 A5A5 A5A5 A5F6 F6FF"
$"00FF F8A5 A5F8 A5F8 F8F8 A5F8 A5F6 F6FF"
$"00FC F8A5 A5A5 A5A5 A5A5 A5A5 A5F6 F6FF"
$"FFFF F8A5 A5A5 A5A5 A5A5 A5A5 A5F8 FFFF"
$"FFFF F8F6 F6F6 F6F6 F6F6 F6F6 F6F8 FFFF"
$"FFF6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00"
$"FFF6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00"
$"FFF6 F6F6 F6F6 F6F6 F6F6 F6F6 F6F8 FF00"
$"FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF"
};
data 'NwtK' (0, "Owner resource") {
$"00"
};