Apple-2-HW/unified_retro_keyboard
1
0
Fork 0
mirror of https://github.com/osiweb/unified_retro_keyboard.git synced 2025-02-19 10:30:26 +00:00
Code Issues Projects Releases Wiki Activity

Updated README to reflect progress

Browse Source
This commit is contained in:
Dave 2020-04-15 15:23:42 -05:00
parent 427080a666
commit f2eead4db8
1 changed files with 21 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
firmware/asdf/README.md
View File

@ -22,13 +22,13 @@ Features:
-- --
* modifiers: A set of modifier keys may be specified. When only a few modifiers * modifiers: A set of modifier keys may be specified. When only a few modifiers
are used, this mechanism is a low-overhead alternative to a keymap overlay for are used, this mechanism is a low-overhead alternative to a keymap overlay for
keyboard states that only change the key value, such as SHIFT, CAPS LOCK, CONTROL, keyboard states that only change the key codes produced by a keypress, such as
etc. The state of each modifier key is kept in a state variable. In most SHIFT, CAPS LOCK, CONTROL, etc. The state of each modifier key is kept in a
cases, pressing the key will set the value to a "pressed" state, and releasing state variable. In most cases, pressing the key will set the value to a
will reset the value to an "unpressed" state. However some functions interact. "pressed" state, and releasing will reset the value to an "unpressed" state.
For example, Shift Lock is sticky, so pressing Shift Lock toggles the Shift However some functions interact. For example, Shift Lock is sticky, so
Lock state, and Releasing Shift Lock does nothing; but pressing "Shift" will pressing Shift Lock toggles the Shift Lock state, and Releasing Shift Lock
reset the "Shift Lock" state. does nothing; but pressing "Shift" will reset the "Shift Lock" state.
All modifier state variables are kept in a modifier state variable array. On a All modifier state variables are kept in a modifier state variable array. On a
regular keypress, all of the modifier state variables are OR'ed together to regular keypress, all of the modifier state variables are OR'ed together to
@ -46,6 +46,7 @@ Features:
* (1): ADM-style ASCII keyboard (all caps) * (1): ADM-style ASCII keyboard (all caps)
* (2): Apple 2 ASCII keyboard (upper/lower) * (2): Apple 2 ASCII keyboard (upper/lower)
* (3): Apple 2 ASCII keyboard (standard all caps) * (3): Apple 2 ASCII keyboard (standard all caps)
* (4): Sol-20 ASCII keyboard
* Debounce and Repeat functions: The main keyscan logic implements key * Debounce and Repeat functions: The main keyscan logic implements key
debouncing. Multiple keys may be debounced simultaneously using a separate debouncing. Multiple keys may be debounced simultaneously using a separate
@ -78,7 +79,7 @@ Porting
This firmware was written in modular, portable C99, to be compiled with GCC This firmware was written in modular, portable C99, to be compiled with GCC
(avr-gcc for the Atmega). The hardware-sepecific files are in Arch/*.[ch]. To (avr-gcc for the Atmega). The hardware-sepecific files are in Arch/*.[ch]. To
adapt the Atmega port for additional hardware, enter the ./src/Arch directory, adapt the Atmega port for additional hardware, enter the ./src/Arch directory,
and copy the files asdf_arch_atmega328p.c and asdf_arch_astmega328p.h to new and copy the files asdf_arch_atmega2560.c and asdf_arch_astmeg2560.h to new
filenames, and edit them to suit the hardware changes. filenames, and edit them to suit the hardware changes.
The firmware is designed to run from ROM on a slow vintage processor, with a The firmware is designed to run from ROM on a slow vintage processor, with a
@ -90,7 +91,7 @@ The code was written to favor readability over cleverness. While tempted to
optimize bit testing via bithacks, I opted for code simplicity since the optimize bit testing via bithacks, I opted for code simplicity since the
performance benefit was not there for 8-bit values. performance benefit was not there for 8-bit values.
To port to a new processor architecture, you may use the atmega328p files as an To port to a new processor architecture, you may use the atmega2560 files as an
example, and create a pair of architecture-specific .c and .h files for the new example, and create a pair of architecture-specific .c and .h files for the new
hardware, exporting the following functions: hardware, exporting the following functions:
@ -109,5 +110,15 @@ hardware, exporting the following functions:
that case, this function is not needed, and the "superloop" in main.c would that case, this function is not needed, and the "superloop" in main.c would
contain a call to the scheduler. contain a call to the scheduler.
- asdf_arch_XXXX_set: The hardware provides a number of physical resources, such as TTL or tri-state outputs, which can be used to drive LEDs, TTL logic output lines, etc. These are driven by a virtual output layer. The virtual layer requires a function to set the state of the physical resources. One function is provided for each such resource. For example, if a TTL output is called OUT1, then the function asdf_arch_out1_set() must be defined. - asdf_arch_XXXX_set: The hardware provides a number of physical resources, such
as TTL or tri-state outputs, which can be used to drive LEDs, TTL logic output
lines, etc. These are driven by a virtual output layer. The virtual layer
requires a function to set the state of the physical resources. One function
is provided for each such resource. For example, if a TTL output is called
OUT1, then the function asdf_arch_out1_set() must be defined. For now, the
required devices are:
- LED1, LED2, LED3 (LED outputs)
- OUT1, OUT2, OUT3 (TTL outputs)
- OUT1\_OPEN\_HI, OUT2\_OPEN\_HI, OUT3\_OPEN\_HI (Open collector outputs)
- OUT1\_OPEN\_LO, OUT2\_OPEN\_LO, OUT3\_OPEN\_LO (Open emitter outputs)