but altirra has a problem in that it doesn't recognise the escape key
Possibly a stupid thought, but have you tried the Ctrl-[ key sequence? That's the official
escape CTRL code from the teletype terminal days, and because many desktop computer platforms which came along afterwards (IBM, Apple, Commodore, etc.) emulated support for those codes, Ctrl-[ will often be seen by old programs as the ESC keyboard key itself.
More specific explanation: ascii character 27 (
1Bh) was the escape character in the teletype days. Just as pressing the space bar generated ASCII 32, pressing ESC generated ASCII 27. And for keyboards without escape keys, "they" chose Ctrl-[ as another way of sending ASCII 27. Anyway, then along come home desktop computer platforms, and their makers not wanting to upset old habits, many coded their BIOSes to put ASCII 27 in the keyboard read interrupt when
either the ESC key, or Ctrl-[, was pressed. Thus if software was written to do 8-bit reads from the keyboard read interrupt, they would look for 27 to know when ESC had been pressed -- yet wouldn't know if the real ESC key was pressed or if Ctrl-[ was pressed, causing either one to work equally well in the end.
Not sure about the Atari platform, but as an aside, in the IBM world, 16-bit keyboard read interrupts also exist in addition to older style 8-bit keyboard read interrupts. When a key is pressed, these 16-bit interrupts return
two (instead of one) bytes (i.e. a 16-bit word), where the low 8 bits contain the traditional ASCII value for the key that was pressed (e.g. 27 for escape), but where the high 8 bits contain what is called a "scan code". Scan codes were essentially created because by the time of the IBM PC's invention, keyboards were having more and more keys, especially ones for which no traditional teletype-era ASCII values existed. E.g., the F1, F2, and F3 keys on IBM compatible PCs (and thus on today's Windoze PCs) return 3B00, 3C00, and 3D00 (scan codes 3B, 3C, and 3D, but traditional ASCII codes all 0). Scan codes were
also used to distinguish between keys that were duplicated on keyboards. E.g., numeric pad up_arrow = 4800, and numeric pad PgUp = 4900 ... but regular up_arrow = 48E0, and regular PgUp = 49E0. Point of all this is: when reading the keyboard via a 16-bit interrupt, real ESC = 1A
1Bh, but Ctrl-[ = 01
1Bh.
So assuming the Atari platform used 27 (1Bh) for ESC
and also made Ctrl-[ deliver 27, then it's possible that if the emulator doesn't support the ESC key at the hardware level, Ctrl-[ will still generate 27. If that's true, then if the EPG software only pays attention to the low 8 bits, Ctrl-[ might just bring up its menu.
I just know that Windows itself reads 16-bit all the time, so Ctrl-[ never fools Windows programs into thinking ESC has been pressed. But when I run my old DOS programs, Ctrl-[ fools most of them into thinking ESC was pressed, because they're only checking the keyboard 8-bit style.
In atari land, it seems (this is all new to me) that the raw keyboard code is 1C, this is translated to ASCII as 1B, no matter what modifier is pressed (and no other keyboard combination returns 1B at this stage) then our code has some funky translation thing that changes it to 5B. The code then looks for an incoming Keypress of 5B to do the escape routines.