I had to disassemble the keyboard drivers for the SLAVE and IKAT processors to figure out the SLAVE/IKAT commands but after that it was smooth sailing. Luckily these are very small drivers.
This has limited utility because there are only a very few titles out there that support a CD-i keyboard. I know of the following ones:
- Philips/Standaard Interactieve Encyclopedie (to enter search terms)
- Philips Medische Encyclopediedisc (to enter search terms)
- CD-Online discs (to enter URLs)
All of these require a DV cartridge and are thus not (yet) supported by CD-i Emulator.
However, there is (very rudimentary) keyboard support in the Philips player shells, just enough to verify that your CD-i keyboard is actually working.
The "old player shell" (found on CD-i 60x, CD-i 200, CD-i 210 F2 and below, CD-i 220 F3 and below and CD-i 350) supports the "p" key (lowercase only!) as equivalent to clicking the "PLAY CD-I" button.
CD-i 605 with old player shell
The "new player shell" (found on CD-i 210 F3 and up, CD-i 220 F4 and up, CD-i 4xx, CD-i 615, CD-i 660 and CD-i 740) supports any key to abort the introductory animation.
CD-i 210 with new player shell
The above now also works in CD-i Emulator.
Supposedly one or both player shells also support the keyboard for naming favorite track selections, but I haven't verified this.
Most people will think of the "CD-i KeyControl" (22ER9042) when they hear the term "CD-i keyboard", but there also exists a true "CD-i Keyboard" (22ER9041). The former was introduced in 1996 with the CD-Online discs but the latter is much older, its specification was published in May 1993.
CD-i KeyControl, photo courtesy of http://www.freetimeweb.nl
CD-i Keyboard, photo taken by myself (click to enlarge)
CD-i Keyboard backside, photo taken by myself (click to enlarge)
The "CD-i Keyboard" is a full PC-AT style keyboard (without a "Windows" key, and using the term "SuperShift" for what is usually called "Alt") that connects to a CD-i player just like any other peripheral. It was intended for the professional market (specifically, the so-called "CD-IX" configuration) and is colored accordingly (whitish). This is the keyboard that the original CD-i keyboard protocol (later called "K-mode" because of it's ASCII "K" device identifier byte) was written for. It transmits key events in two-byte packets at 1200 baud.
The CD-i KeyControl also supports a so-called "T-mode" which uses a different protocol. The keyboard actually masquerades as a graphical tablet with a device identifier byte of ASCII "T". This protocol transmits key events in four-byte packets at 1200 baud.
Why was the "T-mode" introduced when there was already a perfectly usable keyboard device protocol? The reasons for this are arcane, to say the least, and provide a very nice "horror" story about product design and compatibility; it also illustrates the lengths that Philips went to in order to maintain the "All CD-i titles can be used with all CD-i players" principle.
First we need a little background. Most CD-i players have two input ports, usually one on the back and one on the front. Newer players support the use of a splitter cable to connect two peripherals to the front port, in reality these players have two "front" ports that are smartly wired together in a single connector (dual front port support is a feature of the IKAT coprocessor in the newer CD-i players, specifically Mono-III and later).
However, front and back ports are not functionally identical. Back ports are fully bidirectional RS232 ports supporting both serial input and serial output; they are invariably connected directly to the on-chip UART port of the 68070 processor. Front ports are unidirectional; they can only receive serial input and are connected via the SLAVE or IKAT coprocessor (an 68HC05).
The SLAVE processor fully supports the "K" protocol on its single input port, but the IKAT processor only supports it on its secondary port (the one that only becomes accessible when a splitter cable is used). There is no good technical reason for this limitation as far as I know: both ports are supported by software in the IKAT and it should have been easy to support the "K" protocol on both.
Hence the following requirement from the CD-i KeyControl manual:
Splitter cable is required for models CDI 210/40, CDI210/60 and CDI 470/00 and up.(you can see the full manual here).
There is however a complication with the CD-i 450 and FW 380i players (and their variations the CD-i 550 and Magnavox CDI 5000 and CDI 9000): they do not have a back port! Instead one of the two "ports" that make up the front port is connected to the 68070 and thus bidirectional, the other is unidirectional. For some reason the secondary port was chosen to be the bidirectional one, possibly to lessen the load in the main 68070 processor in the usual case or for fail-safety reasons (if a user blows up a port it would tend to be the primary one, which would leave the 68070 port accessible for diagnostics).
The CD-i modem has to be connected to a bidirectional input port, otherwise the CD-i player would not be able to send out data. This means the back port on those players that have it, or the secondary front port on those that do not.
From the above you can deduce that this leaves players without a back port without the possibility to connect a K-mode keyboard while also using a modem! That means that the CD-i 450 and FW 380i players (and their variations) could not be used in the modem + keyboard configuration, which was unacceptable for both marketing and philosophical reasons.
So a workaround was devised. By having the CD-i KeyControl masquerade as a graphical tablet, it could be supported on the primary input port of the IKAT. The coprocessor dutifully reports the "tablet" data to the main processor, which then (using a custom driver that was included on the application disc) transforms it back into keyboard data that the CD-i application can process in the normal way.
When both a modem and a CD-i KeyControl are connected to a CD-i 450 or the FW 380i player, there is no possibility for connecting a wired pointing device (both input ports are in use). These players have no remote (infrared) capability which would make it impossible to "point and click". To remedy this, another workaround was devised. In the T-mode, the function keys F3 to F6 act as cursor keys while the F1 and F2 keys act as button and button 2, respectively
No comments:
Post a Comment