[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PC to Apple 2 Keyboard Conversion



pausch@saaf.se (Paul Schlyter) writes:
>> But it won't be that simple.  You either have to do the conversion
>> externally, most likely by using a dedicated microprocessor, or
>> fix the ROM inside the Apple II to do the conversion.
> 
>The latter wouldn't work, for two reasons:
> 
>1. It would require the Apple II program to do all keyboard input
>through some appropriate monitor routine; however many real-world
>Apple II programs read the keyboard by accessing the I/O-mapped
>addresses $C000 and $C010 directly.

Quite so. Any replacement keyboard must be indistinguishable from the real
thing (except by having extra keys).
> 
>The former is probably the best route to go even today.  Yes, it requires
>some extra hardware, but microcontrollers are much more capable today.
>SInce microcontrollers rarely have parallell I/O, one would have to
>do it with serial I/O and add a UART afterwards:
> 
>                 ___________________       ________
>           scan  |                 | ASCII |      |====== Apple II
> PC keybd -------| Microcontroller |-------| UART |====== ASCII
>           codes |_________________| codes |______|====== kbd input
>                         |    |__________________________ RESET signal
>                         |_______________________________ Kbd strobe

PIC micros have parallel I/O. For example:

PIC16C54 has 12 I/O bits, 25 bytes of RAM and 512 words of ROM.

	RA2   1		18 RA1
	RA3   2		17 RA0
	TOCKI 3		16 CLKIN
	/MCLR 4		15 CLKOUT
	Vss   5		14 Vdd
	RB0   6		13 RB7
	RB1   7		12 RB6
	RB2   8		11 RB5
	RB3   9		10 RB4

I would use RB6..RB0 as the 7 data bits, RB7 as Strobe.
Port A would be used to talk to the PC/AT keyboard and for RESET.

As the keyboard has a clock line we don't even need exceptional
timing stability so an RC clock for the PIC would save the crystal.

>The microcontroller should read the scan codes from the PC,
>translating them to ASCII when appropriate, and also keeping track of
>the states of the Shift, Ctrl and Alt keys (the Alt key could be
>ignored, or it could be given the functionality of the RESET key,
>e.g. pressing Alt-R could be interpreted as equivalent to pressing
>RESET - this would require one 1-bit output from the microcontroller
>to be reserved for the RESET signal).

Why not Control-Alt-Del?

>Optionally the code in the microcontroller could implement auto-repeat,
>but this isn't necessary since the original Apple II keyboard didn't
>have any auto-repeat function.

If there is enough space for the code you might as well do this.

>Perhaps this could be done with the common and cheap PIC microcontroller?

Yes.

>1. A stand-alone unit with connectors to the PC keyboard, the Apple II
>keyboard input, and some power supply.  This is the easiest to build,
>and should be chosen during the development stage.  Since that "extra
>box" would be pretty small, it could be considered the permanent
>solution as well.
> 
>2. Built into the PC keboard -- this would "convert" the PC keoboard
>to an Apple II keyboard.  The connector from the keyboard would then
>also need to be replaced.  The keyboard as well as the
>microcontroller would get its power from the Apple.
> 
>3. Built onto a prototype card inserted into one of the Apple II
>slots - this would give the Apple II a connector to PC keyboards.
>That protptype board would also need a wire to a connector to the
>Apple II keyboard input.

4. I would build a small PCB with a DIP header soldered to the underneath.
Thus it would plug straight into the keyboard socket on an Apple ][.
It would also have a 4-5 pin header to connect a 5pin DIN socket on the end
of a cable so it could be mounted at the rear of the Apple ][.

Adapting a //e would be more difficult as you would need to replace both
the onboard 3600 decoder and the keyboard ROM.
--
David Wilson  School of IT & CS, Uni of Wollongong, Australia