I started this project for several reasons 1/ bad experience with a usb to Apple IIe converter (I had to rewrite a part of the code, [bad table lookup I had to recode to avoid the lookup]) 2/ lack of ps/2 keyboard (none of my keyboard sold as usb/ps2 really works in ps/2 mode) 3/ I wanted to use my everyday french keyboard 4/ I wanted to control several machines from the same usb keyboard solution used: hc05 modules 1 master , several slaves I set a name for example: usbkey-c64-1 for the c64 usbkey-vic20-1 for the vic20 usbkey-coco2-1 for the coco2 the master hc05 browse the hc05 modules visibles then it connect to the one I want to use actually I'm working on a windows application the windows application process the keyboard (when the application has the focus) and send the data via bluetooth to one of the slave hc05 Later I'll make a small board using a Vinculum II to replace the PC solution tested with a Vinculum II evaluation board a sdcard to change the firmware / add new keyboard layout a small oled screen + buttons to select the target machine For the slave one board made, I'm sending the order to oshpark in 2 or 3 days... On 30/06/2015 10:41, Marko Mäkelä wrote: > Hi Didier, > > On Tue, Jun 30, 2015 at 10:07:06AM +0200, Didier Derny wrote: >> I'm working on usb/bluetooth keyboard for several machines >> I wanted to detect when the commodore is starting to scan the keyboard > > I wonder if the ‘gaming keyboards’ are assigning one GPIO pin per > key. I wouldn’t consider it unthinkable. > > If your goal is to connect the old keyboards to newer devices, you > can’t of course ditch the keyboard matrix. If not, skip to the quoted > text below. > > What you could do is that you could improve the keyboard scanning. > Some 20 years ago, I made some experiments on the C128. I found that > making the outputs to all-1 between each scan iteration would reduce > the shadowing. > > Another idea that you could do is to read the matrix from ‘both > directions’ (first driving the columns and reading the rows, then > driving the rows and reading the columns). Remember that you have a > dedicated CPU for the keyboard, and not just a few hundred 6502 clock > cycles in a timer interrupt. > > Also, did you check the article in the C=Hacking Issue #6 about > keyboard scanning: http://codebase64.org/doku.php?id=magazines:chacking6 > >> 1 usb keyboard or 1 windows application controlling a C64 or a tandy >> coco 1/2/3 the same board can fit a coco 3 or a C64 or VIC 20 (just >> different connectors) the communication is done via serial bluetooth >> >> a prototype works on a breadboard, I make a first PCB in a few days > > Hmm, this seems the opposite route: using a modern keyboard with old > hardware. I thought that Jim Brain already has something for this > application. AFAIU he is controlling a programmable switch matrix with > a microcontroller. > > If you know which way the software is reading the keyboard matrix, you > can theoretically replace it with something simpler, such as > essentially a RAM that connects address lines to columns and data > lines to rows, or vice versa. Instead of address and data lines, you > might even use the GPIO lines of a fast enough microcontroller, and > maybe implement Pin Change Interrupt on those lines. > > Marko > > Message was sent through the cbm-hackers mailing list Message was sent through the cbm-hackers mailing listReceived on 2015-06-30 13:00:07
Archive generated by hypermail 2.2.0.