4 Currently keyboard input is only accepted with the mouse cursor
5 above the window (donno why). Likely related: doesn't work with the
6 AfterStep window manager.
10 A rough, but machine independent job should be easily done.
12 - Complete the keyboard emulation
14 Currently we try hard to map X keys to nascom keys. This has some
15 problems as shift goes to shift, eg when you press Shift-2 to get @,
16 nascom will actually get 'shift' '2' and make the '"'
18 Doing a more standard emulation will loose the possibility of
19 emulating shift keys. Ideally, there should be an invokation flag
20 to chose between the two ways of doing it as it really depends on
21 the application. Most wont need the shift event.
27 It should be fairly simple to log all serial output to a file, and
28 getting serial input from a file (prompting for a new one, once the
29 end of the first is reached).
31 I'd need to find the hardware information about the UART though.
35 Requires precise timings. This could be simple on machines with
36 sound support: just keep an output channel open and pipe the status
39 - Complete hardware emulation
41 Check other ports that require emulation
45 The current organisation is a bit of a quick hack, but it works
48 The current PutBYTE hold quite an overhead to trap writes to
49 screen-memory and ROM, but if we want to make the write-protect to
50 ROM areas this is hard to avoid anyway.
52 - Screen: Are Nascom characters really 16 pixels high?