Need help adapting a PS/2 keyboard to an FM-77AV

[TheRogue]

Hello everyone, this is my first post on this forum. I have posted on a few other forums about this problem, and I've been told you guys are the ones who will be able to help me if anyone can. I have a computer museum here in Vancouver, BC, Canada, and I have just acquired an FM-77 AV 40 SX. The only problem is it came without a keyboard. I have all the information required to create an adapter to let me use PS/2 keyboards with the FM, but I just don't have the practical hardware development experience to turn the information into an actual device. Can someone give me a little help? I have all the codes that the keyboard sends to the computer for every single key, as well as the data rate, the repeat timing, and how the keyboard responds to multiple key presses, as well as the pinouts. I know this problem can be solved with a uController or a (C)PLD, or better yet an Arduino, but I just don't have the experience with VHDL or Microcontrollers nor the knowledge of the PS/2 protocol to actually put it together. Can someone possibly help me? I will post all the pertinent information below:

Info on data rate etc: https://docs.google.com/document/d/1ES069x3zrfYlR6ruTYY5UFvNByLysXoxOFGJ-IDGm4A/edit
Keyboard Serial Codes: https://docs.google.com/spreadsheet/ccc?key=0Alhvp8gopwkpdG03Ni10UmNrN2tzQ2U4TWlTUHFnVnc
Pinout: https://docs.google.com/open?id=0B1hvp8gopwkpOGQ5NjM0ZGYtNWI0My00NzM5LThmNzEtOGUwODY0MmQ3NDM2

Please, if anyone out there can help me, it would be very much appreciated. I can't put the FM 77 AV in my museum without a keyboard.

PS I know the Spreadsheet is messed up a little bit, I'm working on fixing it, for now you can see the data by clicking on the cells.

EDIT: The Spreadsheet is fixed, the cells have proper width

[REVENGE]

That's funny, because people would rather adapt the FM-Towns keyboard to PS/2 instead. :Dd

[TheRogue]

That's funny, because people would rather adapt the FM-Towns keyboard to PS/2 instead. :Dd

FM-Towns keyboards are much more common then the FM-77AV keyboards. I really do need help with this though, so I can display this machine when my museum opens next year. Please.

[Soarer]

Arduino might be fine, another similar choice would be a Teensy* programmed using C. (Of course USB isn't required for the end product, but it's certainly useful for development). Do you have some programming experience? Any C?

The output looks very time critical. So I think it would be easier to replace the controller inside a keyboard, rather than read PS/2 input since that would also be time critical. I don't know how much you're prepared to pay for a keyboard, but something with NKRO would make the coding easier (no need to write anti-ghosting code then). Reading a keyboard matrix directly is not particularly time criticial. For a controller replacement, the Teensy++ has plenty of pins, and in a sensible arrangement.

The heart of it could be a timer interrupt routine called every 100uS, which would output the next bit from an output buffer. If no keys are pressed, the buffer is full of '1' bits. Ideally this would be the only active interrupt in the system, to ensure a steady rate of output. After outputting a bit, the routine could continue to do part of reading the keyboard matrix (perhaps a column per interrupt, or per two interrupts). Once the matrix has been fully scanned, the 'next' output buffer could be created (this would happen outside the interrupt, in the main routine, since it may take longer than 100uS). Every 200 interrupts (i.e. 20mS) the 'next' output buffer becomes the current buffer, and the cycle repeats.

Well, that a rough idea of one shape the code could take, anyway! Obviously not with every detail addressed, but that would give a reasonable scan rate and give the repeating key behaviour that's desired.

* I'm sure there's lots of controllers that would be fine for this, but I suggest a Teensy because you'd need no special hardware beyond a USB port to be able to program it, and the C compiler (WinAVR) and tools are free and work well.

[TheRogue]

Thanks for the quick reply. I believe I do need a keyboard with NKRO, because from what I have read about the original keyboard it did have this feature. The original FM7 could not read more then one key at a time, and people complained about this, so fujitsu changed the keyboard design in the FM77 series, and in fact there was an easter egg that was accessed by holding down about 10 keys at once. Let's get down to brass tacks here. How much for someone to build me this keyboard? The code should be very simple from what I know. So how much for the whole deal including the keyboard itself? I have heard that you guys take custom build jobs, so this shouldn't be a problem right?

[hasu]

Why don't you buy the original keyboard?
Visitors of your museum will prefer it than emulated PS/2 keyboard.

Occasionally you can find some FM77 keyboards on Yahoo! auction in Japan.
It is around 5000yen. It is still very cheap  though you must pay some for transfer agent service.
At least it is cheaper than payment for someone to develop. I'm sure that.

I'm not sure the information you offered is enough to build the adapter.
Without FM77 box and keyboard itself it will be unrealistic or very difficult to develop it.

But FM77 keyboard adapter is still a fun project.
You seem to have enough time to learn C programming and micro controller until your museum opens next year.
Try it yourself and have a fun!

[TheRogue]

I would buy the original keyboard but they don't come up very often. I have actually got some friends in the BBC Micro community who are going to give me a hand solving this problem using a BBC Micro, but I would still prefer having one actually developed. I don't mind paying more to develop one. I am curious what more information would be required? If the codes, data rate, key repeat rate, etc is already available, what more would be required? If perchance it doesn't behave right wouldn't it just be possible to report the problem and have the code modified? The way the BBC Micro community wants to solve the problem is to interface a BBC Micro to the FM77 through the beebs userport and feed it the appropriate keycodes for each keypress on the beebs keyboard, then interface a PS/2 keyboard to the Beeb through the userport, implement a PS/2 scanning routine, and then make those two work together and run them on an ARM board. I really want to work with this computer as soon as possible, so I will start working on things this way, and if anyone from this board would like to take the job on, then that will be great, but I guess no one is interested.

Why don't you buy the original keyboard?
Visitors of your museum will prefer it than emulated PS/2 keyboard.

Occasionally you can find some FM77 keyboards on Yahoo! auction in Japan.
It is around 5000yen. It is still very cheap  though you must pay some for transfer agent service.
At least it is cheaper than payment for someone to develop. I'm sure that.

I'm not sure the information you offered is enough to build the adapter.
Without FM77 box and keyboard itself it will be unrealistic or very difficult to develop it.

But FM77 keyboard adapter is still a fun project.
You seem to have enough time to learn C programming and micro controller until your museum opens next year.
Try it yourself and have a fun!

[hasu]

The information you offered is a (google) translation of this page, right? http://d.hatena.ne.jp/deskuma/
As the author said, this doesn't analyze the keyboard protocol enough to do further work.
I'm not sure that how to operate when multiple keys are press/hold simultaneously and break(or release) them.
And I think the scan codes is too long and redundancy. We might look over some

I found this page says old "Oh! FM" magazine('86/05) has an article about FM77AV keyboard encoder. This article may help.
http://retropc.net/ryu/xm7/xm7.shtml#reference "FM77AV キーボードエンコーダ詳解" (Oh!FM 86年5月号)
And some FM77 Hardware Reference books seem to had existed at that time. I found some of them on search page of National Diet Library. I think they offer a copy service of books on the net.

I'm interested in how BBC Micro community solve this problem and I like to learn from them.
And I might be able to some help them.
Can you post URL of the thread on the BBC Micro community?

And your museum have a site? If so, post the URL.

[Soarer]

TheRogue - it is kinda interesting, but while we can offer lots of help, it would be a slow process for anyone to develop the code without having the machine to try things out on. And slow = expensive, when paying by the hour! It's unlikely to be satisfactory for either you or the coder. Custom projects here tend to stem from either someone's personal desire to see something exist, or a 'group buy' kind of project to share costs.

Hasu - The scan code is encoded to avoid sequences of more than 2 bits that are the same, since there is no separate clock signal. The actual scan code is the middle 8 bits in the right hand column entries. The other two bits there are start and parity. I don't know why it goes through two stages of expansion; one should be sufficient for that purpose.

There is maybe enough info there to make a keyboard, but I'm sure it would still involve a lot of trial and error. For example, in the 20mS between repeats, there is only enough time to send 4 or 5 codes (4mS each, but we don't know how much, if any, gap there must be between sending codes). Certainly not enough time to send the 10 codes needed to trigger the easter egg!

[TheRogue]

I considered it a starting point, which could be refined further through testing. I do know that there was an article in Oh!FM but I couldn't find a copy anywhere. My Japanese is very limited too. Someone who has designed similar adapters has agreed to help with the project. I do know someone who has a keyboard, so I will send him an Arduino loaded with the Arduinoscope sketch and connectors added so that he can hook his keyboard up and take readings of every key and the behavior of multiple keypresses, as well as the datarate. Soarer, thank you for the extra information you have given me. It is very helpful! I have one question, and again this is something that I would pay for. Hasu, I notice you are located in Tokyo. If you were able to go to Akihabara and try to find me a keyboard. I would pay for your trouble of course. Would you consider it?

EDIT: Sorry I forgot to answer your questions. The BBC community I have been communicating with is not on a forum, it's on a mailing list. This is the email address of the mailing list: bbc-micro@lists.cloud9.co.uk. The site to sign up for the mailing list is here: http://lists.cloud9.co.uk/mailman/listinfo/bbc-micro. As for my museum, it doesn't have a site yet, I am right now tied up with negotiating the conditions of the brick and mortar museum location. Once that is sorted out I will set up a site for it. But anyway, please consider my request, it would be very helpful, and I would pay you for your time. I have only been to Akihabara once but from what I saw, I would think it would be possible to find one. I would be so grateful for the help.

The information you offered is a (google) translation of this page, right? http://d.hatena.ne.jp/deskuma/
As the author said, this doesn't analyze the keyboard protocol enough to do further work.
I'm not sure that how to operate when multiple keys are press/hold simultaneously and break(or release) them.
And I think the scan codes is too long and redundancy. We might look over some

I found this page says old "Oh! FM" magazine('86/05) has an article about FM77AV keyboard encoder. This article may help.
http://retropc.net/ryu/xm7/xm7.shtml#reference "FM77AV キーボードエンコーダ詳解" (Oh!FM 86年5月号)
And some FM77 Hardware Reference books seem to had existed at that time. I found some of them on search page of National Diet Library. I think they offer a copy service of books on the net.

I'm interested in how BBC Micro community solve this problem and I like to learn from them.
And I might be able to some help them.
Can you post URL of the thread on the BBC Micro community?

And your museum have a site? If so, post the URL.

[TheRogue]

Ok guys, I have worked out how I am going to get the data needed to do this properly. I am going to buy a portable multimeter/oscilloscope that can also be hooked up to a PC via USB off ebay next friday when I get paid, then I will send it to my friend who has a keyboard, along with an adapter for him to connect it to his keyboard, and he will push every button one at a time, recording the order that he pushed them in, then he will hold some keys down to make them repeat, recording which ones he pushes and for how long then he will push various combinations of keys, recording the order he pushed them in. Hopefully this will give us the information we need. I was going to construct the Arduino oscilloscope/logic analyzer project, but it's just too slow to sample the data we need properly. The one I am going to buy has the following specs, so it should be good enough:

Basic Functions              Range                                   Best Accuracy
DC Voltage          400mV/4V/40V/400V/1000V                    (0.8%+8)
AC Voltage            4V/40V/400V/750V                               (1%+15)
DC Current            400mA /4000mA/40mA/400mA/4A/10A    (1%+8)
AC Current            400mA/4000mA/40mA/400mA/4A/10A     (1.5%+8)
Resistance            400W/ 4kW/40kW/400kW/4MW/ 40MW    (1%+5)
Capacitance        40nF /400nF/4mF/40mF/100mF            (3%+8)
Frequency            10Hz~10MHz                                       (0.1%+3)
Vertical Accuracy                                                 (5%+1)
Input Sensitivity    20mV/div-500V/div(1-2-5)    
Horizontal Accuracy                                                 (0.01%+1)
Timebase Range    100ns/div-5s/div(1-2-5)    
Bandwidth    8MHz    
Display Resolution    160X160    
Real-Time Sample Rate    40MSa/s    
Duty Cycle                  0.1%~99.9%

Do you think a thorough sampling with this equipment will be good enough for our purposes?

[Soarer]

Making some assumptions, I'd have to say probably not. What's usually missing from such equipment is the ability to do a relatively long capture at medium (or high) frequency - for this we'd want (at least) 40mS at 100kHz (or more), to really see what happens with multiple keys pressed, requiring at least a 4k buffer. However, if we trust the documentation thus far, perhaps such detail is not needed, and it would be sufficient to sample at about 20kHz, just to see when the codes are sent.

[TheRogue]

If the device is hooked up via USB to a computer running the appropriate software isn't it possible to stream the data in real time to a PC? It says it can sample at much higher frequencies then 100KHz... I'll trust you if you say it can't handle it... There is another one on eBay with the following stats:

Channel:2 Channels
Impedance:1MΩ 25pF
Coupling:AC/DC/GND
Vertical resolution:8Bit
Gain range:10mV-5V, 9Steps
DC accuracy:±3%
Timebase range:4ns-1h, 38 Steps
Vertical adjustable:Yes
Input protection:Diode clamping
X-Y:Yes
Autoset:Yes (30Hz to 40MHz)
EXT. input:Yes
Trigger Mode:Auto, Normal and Single
Trigger Slope:+/-
Trigger level adjustable:Yes
Trigger Type:Rising edge, falling edge
Trigger Source:CH1, CH2, EXT
Pre/Post trigger:0-100%
Buffer size:10K-32KB/Channel
Shot bandwidth:DC to 40MHz
Max. Sample rate:100MS/s
Sampling selection:Yes
Waveform Display:port/line, waveform average, persistence, intensity
Network:Open/Close
Vertical mode:CH1, CH2, Dual, ADD
Cursor measurement:Yes
Spectrum analyzer:
Channel:2 Channels
Math:FFT, addition, subtraction, multiplication, division.
Bandwidth:40MHz
Cursor:Frequency, Voltage
Data Samples:10K-32K/Channel
Accessories:S/W CD, probes, manual, USB cord

Do you think this one might be better? This one isn't built into a multimeter, it's just a box that plugs into your USB port with BNC connectors for probes.

[Soarer]

That's the trouble - while these things could theoretically stream data to the PC, at least at the lower sample rates, they generally don't. They capture to a buffer, upload the buffer, and then repeat the process. So there are gaps. Oscilloscopes are best at looking at repeating signals, or one-off events, rather than continuous data streams.

That said, that one you just listed the specs for does appear to have a decent size buffer. I'm just reluctant to recommend you spend money on something unless I'm positive it's good for the job, and that it's required!

I'd be inclined to experiment with the line in on a soundcard (with a couple of resistors to lower the voltage) - it's not really a high enough sample rate to see the codes well, but if we trust that document that's not a major issue (and they would still sort of show). The data encoding is designed to be pretty much an AC signal, so I think it could work quite well. It should clearly show any gap between sending codes, roughly show what happens with the codes when multiple keys are pressed together, and record for as long as desired. And would cost 10 cents instead of 100$ :-)

Code: [Select]

data -----/\/\/\/\/\-----|-----\/\/\/\/\/\------- GND
              47k        |          2k2
                         |
                      line-in

Beyond that, there's the Open Logic Sniffer - a cheap logic analyzer which (with the latest software) is capable of some very long samples. It's overkill really, but still cheaper than the 'scopes, even allowing for buying the probes separately ($50 + probes). The only problem at the moment seems to be finding them in stock anywhere, although SparkFun has some (at an inflated price :-/ ).

[TheRogue]

What sort of probes are required for the Open Logic Sniffer? I am going to buy one I think, not just for this project but for other projects as well. I canput it in a simple project box with bnc connectors. Please if you can post a link to the appropriate probes for that particular logic analyzer. The sound card solution is really neat I will definitely try it but I want the real logic analyzer for other things.

[Soarer]

I got my OLS from Seeedstudio, with the expansion wing and lots of probes. Still haven't found anything needing 32 channels though!

One hassle is that all enabled but unused channels should be grounded, to avoid noise. This is especially true when using the run-length encoded capture mode (which is what lets it do really long captures). But it's only a minor hassle.

edit: There is someone who makes a case for it, Synthetos. If it wasn't for the postage and import taxes, I would've bought one by now, even though it costs almost as much as the OLS!

[TheRogue]

Thanks Soarer! I am going to pick one up next friday, along with the buffer, probes, and case. I actually have someone who is working on this with me who thinks that it might not even be necessary to gather any more data. He designed an ADB to PS/2 converter that he is modifying for my purposes. He is going to send it to me along with a debugger so I can load new code into it. First off he is going to load code that will just send the letter A whenever any key is pressed, just to confirm that the data rate is acceptable, which he suspects it is since the signal is self clocking. After that we will add full key support, and then try to work out what to do about rollover. It might not be a fully functional replacement, replicating the huge amount of NKRO available in the original but it should be a functional solution. I just hope we don't run into any roadblocks.

[hasu]

Hasu - The scan code is encoded to avoid sequences of more than 2 bits that are the same, since there is no separate clock signal. The actual scan code is the middle 8 bits in the right hand column entries. The other two bits there are start and parity. I don't know why it goes through two stages of expansion; one should be sufficient for that purpose.

I can understand that the bit sequence probably uses some existent well known encoding like Manchester, NRZI or any other, though I have no enough knowledge about that thing. I doubt they used their original encoding method for the keyboard. I just felt uncomfortable with the way of  decoding offered by TheRogue(or the blog page) I like to know an exact theory of encoding behind the bit stream from the keyboard.


I came upon with this idea with looking raw data. I found it shows same 4 bit sequence many time, and there are only 2 kind of sequence.(except for beginning and ending sequence part) This result is more reasonable for scan code. I think this is prospect.
Though I'm not sure this is existent well known encoding method. what do you think?

Code: [Select]


ESC: 1 0110     1001    1001    1001    1001    1001    1001    1001    0110    011
                0       0       0       0       0       0       0       1               0x01

  1: 1 0110     1001    1001    1001    1001    1001    1001    0110    1001    011
                0       0       0       0       0       0       1       0               0x02

  9: 1 0110     1001    1001    1001    1001    0110    1001    0110    1001    011
                0       0       0       0       1       0       1       0               0x0A

  0: 1 0110     1001    1001    1001    1001    0110    1001    0110    0110    011
                0       0       0       0       1       0       1       1               0x0B

  Q: 1 0110     1001    1001    1001    0110    1001    1001    1001    0110    011
                0       0       0       1       0       0       0       1               0x11

  W: 1 0110     1001    1001    1001    0110    1001    1001    0110    1001    011
                0       0       0       1       0       0       1       0               0x12

  A: 1 0110     1001    1001    1001    0110    0110    0110    0110    1001    011
                0       0       0       1       1       1       1       0               0x1E

  S: 1 0110     1001    1001    1001    0110    0110    0110    0110    0110    011
                0       0       0       1       1       1       1       1               0x1F

  D: 1 0110     1001    1001    0110    1001    1001    1001    1001    1001    011
                0       0       1       0       0       0       0       0               0x20


[hasu]

I considered it a starting point, which could be refined further through testing. I do know that there was an article in Oh!FM but I couldn't find a copy anywhere. My Japanese is very limited too. Someone who has designed similar adapters has agreed to help with the project. I do know someone who has a keyboard, so I will send him an Arduino loaded with the Arduinoscope sketch and connectors added so that he can hook his keyboard up and take readings of every key and the behavior of multiple keypresses, as well as the datarate. Soarer, thank you for the extra information you have given me. It is very helpful! I have one question, and again this is something that I would pay for. Hasu, I notice you are located in Tokyo. If you were able to go to Akihabara and try to find me a keyboard. I would pay for your trouble of course. Would you consider it?

I usually drop at Akihabara once a week or two, so I can go about there to find the keyboard for you.
But I doubt there is any chance I can find those old junks there. The number of junk shops is very few in Akihabara, it is a town of maid cafe, manga and anime now...

And I found Oh! FM magazine(86/05) on Yahoo auction and put a bid. I will get it in a week unless hard competitors appears.
I became curious about the FM77 keyboard protocol. I think I can post here the brief of the article anytime soon.



Thinks for the information. I will read the mailing list archives and follow the activities.

EDIT: Sorry I forgot to answer your questions. The BBC community I have been communicating with is not on a forum, it's on a mailing list. This is the email address of the mailing list: bbc-micro@lists.cloud9.co.uk. The site to sign up for the mailing list is here: http://lists.cloud9.co.uk/mailman/listinfo/bbc-micro. As for my museum, it doesn't have a site yet, I am right now tied up with negotiating the conditions of the brick and mortar museum location. Once that is sorted out I will set up a site for it. But anyway, please consider my request, it would be very helpful, and I would pay you for your time. I have only been to Akihabara once but from what I saw, I would think it would be possible to find one. I would be so grateful for the help.

[TheRogue]

From my limited knowledge of such things, I think your approach sounds completely reasonable. I really really appreciate that you are taking time to study this problem and look at it from a different perspective. If I get more data will you be able and/or willing to look deeper into the problem? I have someone tackling this problem from a practical perspective, but I have a feeling that there may be certain things that can't be surpassed without a greater understanding of what is going on with this protocol. I have contacted someone who may be able to gather the extra data soon without much effort. I'll get back to you relatively soon one way or another. If this person can't get the data for me, I'll send the Open Logic Sniffer to my friend who has a keyboard and he'll sample all the data we could need.

EDIT: Thank you very much for agreeing to look in Akihabara for me. I really really appreciate it. I will pay you for the purchase price and shipping, and for your trouble. You are really very kind. I thank you also for locating the copy of Oh!FM. I searched for it, but I was unsuccessful. Thank you so much. I really owe you much. Thank you so much!

[hasu]

Not bad totally hehe.
I just wept about the decline of  radio, electronics and computer hobby.

[Soarer]

I can understand that the bit sequence probably uses some existent well known encoding like Manchester, NRZI or any other, though I have no enough knowledge about that thing. I doubt they used their original encoding method for the keyboard. I just felt uncomfortable with the way of  decoding offered by TheRogue(or the blog page) I like to know an exact theory of encoding behind the bit stream from the keyboard.

I've long since forgotten anything I ever learned about the details of such encoding schemes - probably as soon as I walked out of the exam! And I hadn't thought too much about this encoding, since an adapter could simply lookup and replay the 40-bit codes (an inefficient use of storage, but there is plenty these days).

I came upon with this idea with looking raw data. I found it shows same 4 bit sequence many time, and there are only 2 kind of sequence.(except for beginning and ending sequence part) This result is more reasonable for scan code. I think this is prospect.
Though I'm not sure this is existent well known encoding method. what do you think?

Intriguing. On the plus side, you get a logical sequence of scan codes, and the encoding of each bit is independant (does not depend on the encoding of the previous bit). On the minus side, you've lost the parity bit.

Clearly the 40-bit code for FULL_2 in the spreadsheet is incorrect, and should probably be 0b1011010011001100110011001100101100110011. The same code is obtained by either working backwards from the value at C4, or by your method assuming that the scan code for '2' is 0x03.

Incidentally, since the codes begin and end with 1s, and the idle state of KSDATA is high, it has to be negative logic on the line (low=1).

[Soarer]

Thanks Soarer! I am going to pick one up next friday, along with the buffer, probes, and case. I actually have someone who is working on this with me who thinks that it might not even be necessary to gather any more data. He designed an ADB to PS/2 converter that he is modifying for my purposes. He is going to send it to me along with a debugger so I can load new code into it. First off he is going to load code that will just send the letter A whenever any key is pressed, just to confirm that the data rate is acceptable, which he suspects it is since the signal is self clocking. After that we will add full key support, and then try to work out what to do about rollover. It might not be a fully functional replacement, replicating the huge amount of NKRO available in the original but it should be a functional solution. I just hope we don't run into any roadblocks.

I agree, there might be enough data, if you accept some limitations on NKRO. It would be nice to trigger that easter egg though!

That sounds like a sensible plan, I think it should be relatively straightforward to get up to 4KRO working.

[TheRogue]

Someone I know who has a fully working FM77AV40SX wants to know if he can gather some data for us by running an FBASIC program on the machine. Do you think we will be able to get something useful this way?

[TheRogue]

Hasu, I noticed the copy of Oh!FM May 1986 has disappeared from Yahoo! Auctions. Did you win it or did someone else snatch it out from under you? I hope you were able to get it!

[hasu]

An unexpected competitor showed up at the end of bid term and raised the price a bit... But fortunately I won!
I am waiting for its arrival. It will be happen in this week.

[TheRogue]

That is very good news! I hope it provides some useful information. I also hope you didn't have to pay too much. Hasu, something else if you ever run into a Sharp X1TurboZ at a junk shop I would love to have one and again would of course pay for your trouble. There are 2 on Yahoo!Japan right now but the price is just way too high. It is one of the few things that I am missing that is really hard to find. Occasionally they turn up but most of the time they just sit there forever because people post them with unrealistic prices. If you ever see one around for a decent price I would be very happy to have it.

[Soarer]

Someone I know who has a fully working FM77AV40SX wants to know if he can gather some data for us by running an FBASIC program on the machine. Do you think we will be able to get something useful this way?

I don't know anything about the machine, but if it has a perpheral chip dealing with the encoding then it's unlikely that software would be able to access the low-level side in any useful way; it would only see the decoded scan codes.

[TheRogue]

I don't know anything about the machine, but if it has a perpheral chip dealing with the encoding then it's unlikely that software would be able to access the low-level side in any useful way; it would only see the decoded scan codes.

I thought that might be the case, but I wasn't sure. The reason I asked is because I know some of the Japanese machines of that era offer a high degree of control and accessibility over the hardware, so I thought it might be possible to poll the chip that handles the keyboard and read what it is receiving. I will see if I can get in contact with any of the people who wrote FM77 emulators or people who are involved in usergroups and see if any of them know. The only real barrier to that is the language issue. I only have a very very basic understanding of Japanese, but I think google translate will be helpful as long as I keep my wording simple and don't confuse the translator. I will hope that someone out there has some useful information, either about the keyboard protocol itself or about whether it is possible to gather data from an FBASIC program. I will keep everyone posted.

[TheRogue]

So, an update for everyone. My FM77AV40SX arrived today. I have confirmed the pinout as listed in the information I posted. I have passed this info onto the person who has constructed the hardware. He is going to attach the required cable to the adapter and then send it off to me. I will then confirm that the timing is correct. If it is, and it should be since the bitstream is self-clocking, my friend will modify the software, send it to me, I will load it into the uC and then I should have a fully working adapter! If anything goes wrong, I will send an Open Logic Sniffer to someone I know who has a compatible keyboard and he will record all the data we need. Hopefully though that won't even be required. We'll see.

[hasu]

I got 'Oh! FM' magazine the other day and have read the article.("FM77AV キーエンコーダ詳解" Oh! FM '86/05)
I'll not post scan images of it in public to avoid infringement of copyright. If you want to read it plz PM me. Note that it is written in Japanese.

Unlike what I expected, this article does not supplies enough info about encoding/protocol between keyboard and FM77 box. Instead it gives how to use keyboard controller(decoder) on FM77 box with 6809 assembly codes which is not what we want.


I'll explain some I got from the article below.

Protocol:
The article says that FM77AV keyboard supports Full N key roll over.
Keyboard sends a scan code(make or break) per 20mS.
Last make code is sent repeatedly with 20mS interval.
Repeating make code can be interrupted with break code and after that continue to repeat.
Repeating make code can be ceased with its break code or another make code.


Encoding:
The article doesn't have any clear description about encoding. So I tried to guess an encoding rules from what we can have now.
Following rules can make KSDATA raw data from a scan code though the theory behind this keyboard encoding is still unclear.

Code: [Select]

Logic: Negative(Captured KSDATA's 0 is expressed with High and 1 with Low. Idle state of KSDATA line is High)
Bit order: MSB first
Data: 8bit

1) extend scan code bits with following rule.
    0 -> 01
    1 -> 10
    example) SHIFT_L(0x53): 0101 0011 -> 01100110 01011010
2) add start and stop bit
    start bit:  110
    stop bit:   10
    example) 01100110 01011010 -> 110 01100110 01011010 10
3) encode with Manchester encoding
    0 -> 10
    1 -> 01
    example) 110 01100110 01011010 10
             -> 010110 1001011010010110 1001100101100110 0110



Scan Codes:
I could find some scan codes and that MSB(bit7) is break flag in sample assembly.

Following displays the scan codes found in sample codes.
These scan codes are same as what decoded from captured KSDATA with my decoding method I posted before.

Code: [Select]

SHIFT_L:    53
SHIFT_R:    54
CAPS:       55
GRAPH:      56
KANA:       5A


So that you can get all scan codes from captured raw KSDATA and my decoding rule below.
(see here for captured KSDATA. http://d.hatena.ne.jp/deskuma/20110425/1303694255)

Code: [Select]

1001 -> 0
0110 -> 1


I came upon with this idea with looking raw data. I found it shows same 4 bit sequence many time, and there are only 2 kind of sequence.(except for beginning and ending sequence part) This result is more reasonable for scan code. I think this is prospect.
Though I'm not sure this is existent well known encoding method. what do you think?

Code: [Select]

ESC: 1 0110     1001    1001    1001    1001    1001    1001    1001    0110    011
                0       0       0       0       0       0       0       1               0x01

  1: 1 0110     1001    1001    1001    1001    1001    1001    0110    1001    011
                0       0       0       0       0       0       1       0               0x02

  9: 1 0110     1001    1001    1001    1001    0110    1001    0110    1001    011
                0       0       0       0       1       0       1       0               0x0A

  0: 1 0110     1001    1001    1001    1001    0110    1001    0110    0110    011
                0       0       0       0       1       0       1       1               0x0B

  Q: 1 0110     1001    1001    1001    0110    1001    1001    1001    0110    011
                0       0       0       1       0       0       0       1               0x11

  W: 1 0110     1001    1001    1001    0110    1001    1001    0110    1001    011
                0       0       0       1       0       0       1       0               0x12

  A: 1 0110     1001    1001    1001    0110    0110    0110    0110    1001    011
                0       0       0       1       1       1       1       0               0x1E

  S: 1 0110     1001    1001    1001    0110    0110    0110    0110    0110    011
                0       0       0       1       1       1       1       1               0x1F

  D: 1 0110     1001    1001    0110    1001    1001    1001    1001    1001    011
                0       0       1       0       0       0       0       0               0x20


[TheRogue]

Oh WOW! Thank you so much Hasu! This information is so so so useful! Thank you so much! I am so so so appreciative and very very grateful! Let me see if I understand right. The most significant bit (the first bit following the start bits) should be 1001 for make and 0110 for break? Am I right about this? Also, it seems that since the first bit of the start bits is 0 (high) and the KSDATA line idles on high, the first 0 of the start bit sequence is lost, so effectively the start bit sequence is 5 bits long, not 6. Am I correct? So for example:

Code: [Select]

        Start Bits  Mk/BkBit  |-----------------------DATA------------------------|     Stop Bits
W (Make): (0)10110     1001     1001    1001    0110    1001    1001    0110    1001       011(0)
                         0        0       0       1       0       0       1       0          

            Start Bits  Mk/BkBit |------------------------DATA------------------------|    Stop Bits
W (Break):   (0)10110     0110     1001    1001    0110    1001    1001    0110    1001       011(0)
                            1        0       0       1       0       0       1       0          

This is extremely useful information! I think without it we would never have been able to succeed fully with a PS/2 adapter. Did I understand the way the make/break bits work? You said that the MSB is first, so it seems to me that this is how make/break works. Did I get it right? Please confirm this for me so I can let the hardware designer know.

Thank you very very much! I will pass this information on to the hardware designer. Thanks again so very much!

[hasu]

Right. It is exactly what I tried to explain.
But I'm still not sure about start bit and stop bit things.

[TheRogue]

Hi everyone! I have a most excellent update for you all! The board arrived yesterday. I just gave it a quick test and... drumroll please... IT WORKS! Right now it is currently only programmed to send the letter "a" for every keypress, as the current firmware was designed just to confirm the timing of the bitstream. I hooked it all up, booted the computer to basic, and pressed a some keys. Immediately "a"s appeared on my screen! It seems the logic levels (inverted logic, idle high, thank you very much Hasu!) and bitstream timing are perfect! I have notified the person who constructed the adapter for me, and he will get back to me soon with updated code. It seems as though we're on the home stretch now! Hasu, we couldn't have done it without you. You have provided invaluable information. Thank you again!

[hasu]

Nice! Thanks for sharing the result.

[TheRogue]

So, here's another update. The next firmware has been fully tested and A-Z and 1-9 are fully working! The next update should be the complete firmware, and soon after that will be a run of these boards. I'm so glad that this all worked out. I once again have to say thank you so much to hasu, for gathering so much information, and also to gubbish for putting it all together into something that actually works! You two have really been great! Thank you so much!