[J-core] keyboard fix ( Re: Talk video. )
cr88192 at gmail.com
Sun Jan 22 01:06:56 EST 2017
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:
>>>> 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
>>>> 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;
> 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
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
maybe add the currently omitted FPU features;
maybe add a feature to limit what parts of the ISA are available in
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, ...
More information about the J-core