[J-core] keyboard fix ( Re: Talk video. )

[BGB]

On 1/21/2017 6:33 PM, BGB wrote:
> On 1/21/2017 3:47 PM, Rob Landley wrote:
>>
>> On 01/20/2017 06:23 PM, BGB wrote:
>>> On 1/20/2017 3:08 PM, Rob Landley wrote:
>>>> On 01/19/2017 09:59 PM, BGB wrote:
>>>>> this is mostly noting how recent-ish I discovered I could do pages on
>>>>> GitHub, and then as another (semi-successful) test, stuck my newer 3D
>>>>> engine project in the browser, linked to from here:
>>>>> https://cr88192.github.io/bgbtech_html/
>>>> I saw your tweet. I can't get it to run in my android phone (maybe it
>>>> does and takes forever, I gave it ~5 minutes to show a sign of 
>>>> life) and
>>>> https pages won't resolve via tethering in tasmania (at the 2g speeds
>>>> all the https negotiation times out for some reason, I can't access 
>>>> any
>>>> https page unless I've got wifi, which I don't at the airport).
>>>>
>>>> But I look forward to trying it back in Austin.
>>> yeah. I don't actually have any Android devices sufficient to test 
>>> it with.
>>> FWIW: it is an interpreter written in C compiled into JS (via
>>> Emscripten, which uses ASM.js).
>> I left it running in another window, came back and it had booted to an
>> aboriginal linux prompt (I really need to get a first mkroot release
>> out), and then when I typed "ls -l" and hit enter it typed just "l" and
>> the newline and then hung eating 100% cpu.
>
> not sure there; commands typically work on my end, though a lot of 
> keys don't work;
> for whatever reason, a lot of the keys don't actually seem to generate 
> scancode events in the SDL implementation provided by Emscripten, but 
> I could look more into it and see if some things are getting 
> translated wrong.
>
> keys which don't seem to get through:
>     arrow keys;
>     other cursor keys;
>     numeric keypad;
>     F-keys;
>     CTRL / ALT / ...
>     ...
>
> for my 3D engine, I had to fudge the input scheme around the range of 
> keys I was getting input for.
>

yeah... it seems I somewhat misunderstood how SDL's keyboard input 
works, I ended up largely redoing how I approached keyboard input, and 
now seem to have access to most of the rest of the keyboard (it got 
botched up a bit when I converted some of my keyboard-handling code from 
the Win32 API to SDL).

was also working on making it so that, when feeding keys over the 
virtual serial link, it generates the appropriate ANSI sequences (this 
was annoying, as the listings were in terms of abstract operations 
rather than specific keyboard keys), then realized I could just do 'cat' 
in a terminal and see the escape sequences.

things like 'vi' seem to be in the Linux image, but it still doesn't 
work correctly.

thinking for CTRL keys I send the "^whatever" keys from the ASCII chart 
(ex: CTRL-C sends ^C or '\x03'), this part not done yet.


well, some improvement at least.
put an updated version online, which apart from the slightly improved 
keyboard, prints a few text-strings to verify that a few of the features 
work, but doesn't really verify all that much.

the test-graphic looks pretty terrible, but this may be due mostly to 
needing more work on the logic for converting a TGA image into 
escape-coded data (and/or an issue with rendering the tiles).


I may make the native code version of the emulator graphical as well, 
given it is possible to provide a more functional interface (for 
emulating Linux) this way than via the Windows terminal (ex: doesn't 
actually work), though TBD for Linux (native Linux console might be less 
problematic than doing an X11 or SDL based interface).

or, at least short of figuring out how WS4L does it, but even then it 
doesn't really seem to handle a lot of ANSI codes without making a 
mangled-looking mess of things, so dunno (a lot of Linux terminal-based 
UI programs are sort of a twitching mangled mess of multicolored 
characters in WS4L).


as for emulator proper:
     maybe do a full SH4 MMU, vs the current lazy attempt at an MMU in 
this mode;
     maybe add the currently omitted FPU features;
     maybe add a feature to limit what parts of the ISA are available in 
what modes
         ex: no SH4 ops in SH2 mode, ...
     ...

or, other things:
     maybe as a test, experiment with doing a simple platformer game or 
maybe a video player in the emulator.
     the emulator isn't really fast, but may be fast enough to handle 
playback of 90s era video codecs.
     I guess for either of these, might want an audio device.
         probably good old "circular buffer with a pointer that goes 
around in a circle" style.
         don't necessarily want to emulate the "turn pin on and off 
really fast" style of doing audio on MCU's.
         idle: relative complexity of sound-HW which is given 
pre-D/S-modulated 1-bit audio, rather than PCM?...
             sound chipset is then basically a ring-buffer and a 
shift-register or similar.
             otherwise, there would be pins to enable/disable the output 
bridge-driver and similar, ...

or such...