hbekel / keyman64 Goto Github PK

Press n times to execute a command

Some configurations, like performing a reset, might be very annoying when issued by accident. To prevent this, I use the 'even'-policy in my configuration:
R:0 exec RESET
With this, I have to type <meta+R> twice to perform a reset. However, if I hit <meta+R> once, do some other stuff and eventually hit <meta+R> again, the reset is performed immediately (because this is how the even-policy works). My suggestion is enhancing the even/odd-policy to work like this (image a mouse double-click):

R:0 the command is issued every 2nd, 4th, 6th... time, regardless of what is typed in between
R:1 the command is issued every 1st, 3rd, 5th... time, regardless of what is typed in between
R:2 the command is issued if <meta+R> is hit two consecutive times
R:3 the command is issued if <meta+R> is hit three consecutive times
...and so on.

When running make on the latest build of XCODE Version 10.2 (10E125) on OS X the following error messages appear:

Roels-MacBook-Pro:keyman64-1.6 Roel$ make
cc -std=gnu99 -Wall -Wno-unused -Wno-expansion-to-defined -O2 -DVERSION=1.6 -o keyman64 strings.c range.c usb.c intelhex.c keyman64.c -lusb-1.0
In file included from keyman64.c:23:
./keyman64.h:52:42: warning: implicit declaration of function 'Sleep' is invalid
      in C99 [-Wimplicit-function-declaration]
  unsigned int sleep(unsigned int sec) { Sleep(sec*1000); return 0; }
                                         ^
1 warning generated.
Undefined symbols for architecture x86_64:
  "_Sleep", referenced from:
      _sleep in keyman64-3f1019.o
      _expect in keyman64-3f1019.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [keyman64] Error 1

Add commands to memorize/recall state in memory, and make save/restore always write and read back state to/from eeprom.

This way state can be memorized and recalled at runtime without changing the last saved state in eeprom and without causing unneccessary eeprom writes.

For example, the user may want to change to a different (unreadable) font when locking the keyboard, and recall the previously used font after unlock.

Lock the C64 until a password is entered

By using a designated command (i.e. 'LOCK'), Keyman64 stops relaying keystrokes to the C64, until a password is entered. A second command (i. e. 'SETPASSWORD') is used to let the user enter the password. The C64's BASIC prompt could be used for providing the necessary feedback.

Mock-up of the pwchange procedure:

READY. <meta+p>
ENTER NEW PASSWORD: ******
RE-ENTER NEW PASSWORD: ******
PASSWORD HAS BEEN CHANGED.

Configuration Terminal

Let the Keyman64 be programmable from the C64 alone by implementing a console-like command interface that uses the BASIC prompt as a terminal. You could list the current configuration, alter control lines directly or even program new macros.

Mock-Up example:

READY. <meta+F7> issues 'CONSOLE'-command
KEYMAN64 VERSION x.x BY HENNING
TYPE '?' FOR HELP.
] SHOW CONFIG
C: INCREASE PORT A BITS 0-1
K: INCREASE PORT A BITS 2-3
R: EXEC $FA

$FA: CLEAR PORT B BIT 7
$FA: SLEEP 20
$FA: TRISTATE PORT B BIT 7

] SHOW PORTS
0 1 2 3 4 5 6 7
A: C C T T T T T T
B: T T S T C C C C

] TRISTATE PORT A BIT 0
B: T C T T T T T T

Grouping individual control lines

In the current software, consecutive control lines can be tempered with as a n-bit-value using commands like 'increment port a bits 0-3' or 'clear port b bits 6-7'. However, there are situations where it would be very useful if individual lines on both ports could be grouped together to perform as above, i.e. when using a ribbon cable to connect the control lines. My suggestion is the implementation of a 'GROUP' command. As a side effect, the configuration would become more readable.

Examples:
GROUP RepromCharset=port a bit 0, port b bit 0
GROUP RepromKernal=port a bit 1, port b bit 1
GROUP MixSID=port a bit 6, port a bit 7

Now the Charset and Kernal could be changed with:
C: INCREASE RepromCharset
K: INCREASE RepromKernal

When a definable key is held down while powering up the unit, an alternative init-config is executed instead of (or following the) default one at the beginning of the config. The user could select which Kernal to use, mount a certain disk-image on the 1541U etc.

What do you think about a power connector where one can drive i.e. the Overlay64 without having to draw power from the motherboard? It could be placed next to the serial interface and the USB socket.

Add an additional pin header to access the USB lines for alternative connection schemes.

Suggested by Oliver Dierich.