This program emulates Infra-Red signals of a wireless keyboard for a Japanese Classic PC called FM77AV and FM77AV40. You also need a deviced called IRToy ( http://dangerousprototypes.com/docs/USB_Infrared_Toy). You can buy from Amazon ( https://www.amazon.com/dp/B01M03RQEQ ).
If you are a classic computer lover, and if you are interested in getting a FM77AV or FM77AV40 from Japan, say Yahoo! Auction, you can get a unit, and has a good chance of getting a working unit. I purchased two, and both two are working fine. But, many doesn't come with a keyboard for some reason. For some reason, many FM77AV owners apparently kept a unit but threw away a keyboard. One solution is to get an adapter for connecting a USB keyboard to FM77AV. Be careful about the connector shape. FM77AV and FM77AV20/40 and FM77AV20EX/40EX and FM77AV40SX all use different connector shape although the signal is the same. Or, you can use this program and IRToy.
I only have FM77AV2 and FM77AV40. So, I cannot test with a FM77AV20, but it probably work with FM77AV20 as well. At least it works perfectly with my test machines. I could finish and see the ending staff roll of Xanadu Scenario 2 with this program. I used a cheat data though.
It cannot be used for FM77AV40EX and later models because those models don't have an Infra-Red sensor.
Although Japanese keyboard is slightly different from US keyboard, if you set this program into the "Translation" mode, the program interprets what you typed and sends a correct key code to FM77AV. Or, for playing games you may want to use "Direct" mode. If you can read Katakana letters and want to type as Romaji, "RKANA" mode will interpret your Romaji typing and sends keycode for corresponding Katakana letters.
[Download (for Windows)]
First, plug your IRToy. Make sure the LED of IRToy is OFF.
Once you plug your IRToy, start this FM77AV Keyboard Emulator. If you are worried about securty of computer virus, read entire souce code and compile the source code by yourself. If you still cannot be comfortable, please don't use it.
Then the program will scan COM ports and look for IRToy.
Then put your IRToy IR LED near FM77AV Infra-Red sensor and type to the program. You will see letters on the monitor of FM77AV.
I am testing this program with IRToy v2 with firmware version v22. If you buy a unit now, probably the unit comes with firmware v07. This program may work with v07, but if it doesn't, you can let the device commit suicide and try upgrading the firmware. (Unfortunately, this unit needs to die once to get firmware upgraded.) But, the Priest who casts a resurrection spell is not of high level, the magic may fail, and the unit may become in the state of ASH. If the second resurrection spell failed again, the unit may be permanently lost. Unfortunately, pressing a reset button won't save the unit. So, good luck!
For developing this program, Mr. Apollo ( http://www.retropc.net/apollo/ ) helped me a lot. Especially, he sampled some IR signal from his FM77AV keyboard, and suggested that the keyboard looked to be using 100us pulse. Mr. Kobayashi of Classic PC and Retro Gaming JAPAN (http://classicpc.org/index.html) told me how to calculate key-release code from key-press code. Without his help, I couldn't eliminate beeps when FM77AV complains that the keyboard signal is lost without key-release code. Mr. Deskuma ( http://d.hatena.ne.jp/deskuma/20110425/1303694255 ) published FM77AV keyboard serial connection, which was very accurate and helpful. Although I couldn't send a message to you because CAPTCHA always tell me I was not typing correct letters, I tried more than 10 times, I really appreciate your work.
The initial plan was to capture infra-red signal from FM77AV40 keyboard using IRToy sensor, and just output the same signal. However, IRToy couldn't recognize off-period between pulses from FM77AV40 keyboard. It basically was thinking FM77AV40 keyboard was emitting Infra Red for 40us continuously when I pressed a key. Actually, a IR wave form from Mr. Apollo indicated that the IR LED was not fully off while the keyboard was sending a code.
Then, I can move the keyboard away from the IR sensor. Any wave intensity decays by the distance square. IRToy captured some gaps between pulses, but it was not precise enough.
I was almost losing hope, when Mr. Kobayashi suggested that maybe I can just send a raw bit pattern as pulses. It was easy to give a try. I just sent a raw bit pattern for 'q'. I initially was not looking at the monitor closely, so I thought nothing happened. But, the next moment, when I looked at the monitor closely, I saw 'q' on the monitor. "YEEEEEES!!!!! IT WOOOOOORKS!!!!!" That was an exciting moment.
Then, when I enabled the speaker, I heard a beep after every key stroke, which was too annoying. By next day, Mr. Kobayashi replied to me with the way to calculate key-release code from key-press code. I corrected my program so that it sends a key-release code when the key is released, and the beeps are gone.
I spent a few more days to come up with a cheap GUI. Made absolutely sure my program won't send 0x24 to IRToy. Finished implementing basic functionalities. So, I released it.
IRToy has a significant advantage over other similar products. My brief google search came back with a bunch of USB-connected Infra-Red devices, but most of them runs on 38kHz clock, and that's the highest pulse resolution that the device can run, which is 26us (micro seconds). On the other hand, IRToy's highest pulse resolution is 0.17us. FM77AV keyboard requires 100us pulse. If I use a conventional IR device to mimic FM77AV keyboard, the closest pulse I can create is 104us. 4% difference. With IRToy, I can make 100.13us pulse. Less than only 0.13% difference. That's exactly I needed. IRToy appears as a COM port, so you can send commands by serial I/O functions.
But, here's one tip if you plan to use IRToy for your own project. NEVER EVER SEND 0x24 TO THE DEVICE. If it is included in the pulse, use different timer to avoid 0x24. The command reference tells that 0x24 enables send byte count in the sampling mode. But, don't use it. YOU MUST AVOID SENDING 0x24 ANY TIME.
Why? In the default running mode, 0x24 ('$') is a command to enter firmware-update mode, or bootloader mode. I call it a suicide mode. The problem is the device will never get out of the suicide mode until you re-flash your firmware. And, you cannot do it from Windows 10. There are numerous reports of failure from Windows 7. Luckily I was able to do it from one of my few-remaining Windows 7 PCs. If you only have Windows 10 computers, your IRToy is dead. No recovery.
Also the firmware-update instruction on the official web site is wrong. It recommends to use a jumper pin, instead of the self-destruction command (0x24). But, the newest model does not come with jumper pins. It also says there is a command option '-reset' to reset the device back to the normal mode, which didn't work in my Windows 7 PC, although it could re-flash my IRToy.
So, all you need to do is make sure the device is in the IR sampling mode before sending 0x24. The problem is there is no way to make sure the device is in that mode. Yes, you can check that the device entered the IR sampling mode by waiting for "S01" from the device. But, while I was programming this FM77AV Keyboard Emulator, the device apparently spontaneously reset to the default mode. In the default mode, when I send 0x02, the device replies with "1ALS". I'm not supposed to see this message if the device is in the IR Sampling mode. Somehow the device was reset. If I accidentally send 0x24, thinking that I was sending a pulse data, the device kills itself. Therefore, even in the pulse data, you should check and make sure 0x24 is not included. Use 0x25 or 0x23 instead. Hopefully, 1/36 difference is ok with your device. If it is in the higher-byte, use a different time step.
In fact, my program accidentally killed the device once. Apparently the reset happened when my IRToy was overwhelmed by the incoming IR pulses from my ceiling light. I saw bunch of seemingly random data, then a tone of USB-device disconnection, and then nothing. My IRToy committed suicide.
I was able to re-flash again to revive it, but since then I added the following filter in my Send function. I never killed my IRToy since then.
i=0; i<nByte; ++i)
printf("Danger! '$' detected! Not going to send it!\n");
By the way, to make sure your IRToy is ready to accept the pulse data, there is (supposed to be) a handshake mode. I send 0x03 to the device, the device replies with 0x3E, then I send 62 bytes, wait for 0x3E, and continue until I send 0xff 0xff. The problem is the device never replies with 0x3E. There are a lot of incorrect descriptions in the official IRToy web site. It is one of them. I am supposed to be able to turn on this handshake by sending 0x26, which didn't work with my device. It is supposed to be in the firmware version v20 and later. Mine is v22. The device replies with "V222" (hardware version 2, firmware version 22) for 'V' command. Probably due to this discrepancy, WinLIRC, which is said to support IRToy, actually doesn't. When you press the transmit button on WinLIRC, WinLIRC freezes. Presumably waiting for 0x3E forever.
So, in summary, IRToy is a very powerful IR tranceiver. You can easily program it for your own purposes with any language that can communicate with a COM port. But, NEVER EVER SEND 0x24 TO THE DEVICE. As long as your program don't send 0x24, you are fine.
Also, don't try to control or diagnose using a terminal program. One accidental stroke of '$' will kill it. If you need to update the firmware, you need to kill it once, but make sure you have at least one Windows XP (not even Windows 7) PC before doing so.
|Comments are welcome. Send E-Mail to:|