Re: reading vic20 or c64 column

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 list