[J-core] emulator status (Re: keyboard fix)

[BGB]

things are hit-or-miss, as I am currently doing a machining class, and 8 
hour classes eat up a lot of my time to work on stuff.

link is still here, and a few minor things have changed:
https://cr88192.github.io/bgbtech_html/btesh2.html

there is now a boot menu.


>
> 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, ...
>     ...
>

didn't get to these, but was working on fine-tuning emulator performance 
and similar in a few areas.
discovered that it was being seriously throttled and a majority of the 
running time was going into redrawing the screen (as opposed to actually 
emulating stuff).

I did go and add partial emulation of Dreamcast's graphics hardware 
(framebuffer only, no PowerVR/GPU stuff, I can only guess if it is 
"about right").

this currently ends up resulting in a duplicate framebuffer (and a need 
to transcribe one framebuffer to another), but allows the logical 
resolution and bit-depth of this framebuffer to be changed dynamically.


I looked, and I am probably not going to attempt to emulate the 
Dreamcast's sound system.


> 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.

tested, basically works.

I have a video in the emulator, which admittedly looks kind of like crap.
I don't really have enough virtual CPU speed in the emulated code to 
handle decoding newer video codecs (ex: MPEG), nor currently to handle 
higher display resolutions (for testing, was using 320x180).


it does seem to be sufficient though to handle MS-CRAM, including in the 
browser (more or less).
MS-CRAM is in some ways a pretty terrible codec, but it was the most 
convenient option at the time.

ended up re-encoding (in an arguably stupid way) from normal CRAM into a 
more restricted subset of CRAM, which can reduce file sizes by ~50% (vs 
MS's encoder), albeit at some quality loss (though not nearly as bad as 
trying to get a similar bitrate directly from MS's encoder).

a better strategy though would be encoding directly from RGBA input.
this subset is a little more friendly to the "console graphics" system 
(vs requiring a RGB framebuffer).

the main alternative would be using the original QuickTime / RPZA format.

idle, could do a CRAM/RPZA hybrid, could look something like (note, 
structured as 16-bit words):
     XXXX AAAA BBBB
     BBBB AAAA XXXX YYYY
         XXXX ranges from 0000..7FFF
         pixel data is XXXX (4x4x1) if AAAA is 0000..7FFF
         pixel data is XXXX_YYYY (4x4x2) if AAAA is 8000..FFFF
     80XX: Flat Color
     81XX: Skip (1..255)
     82XX: Run of prior color (1-64), run of 4x4x1 blocks (1-64), run of 
4x4x2 blocks (1-64)
     8800..FFFF: Flat Color

but this is likely missing the point of the exercise.


sort of half wondering how things worked in old times, as I think I 
remember full-screen video playback on 486's and similar.

but, the emulator seems to strain some despite being AFAICT a bit faster 
than a 486.
granted, in those days they were likely also doing this stuff with 
hand-crafted ASM as well or something.


had ended up special-casing a lot of "MOV Reg,Reg" and "ADD #Imm,Reg" 
forms and similar, mostly as noting that these were eating a lot of 
cycles, and some function pointers with dedicated register values did 
help some with performance.

a JIT could probably help more-so, but I am on the fence.
looks like things like memory loads may also need some work.


>     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, ...
>

if/when I get to it, will probably do a looping PCM buffer.
tradeoff: delta-sigma modulation eats cycles and emulation requires 
going back to PCM, and is rather lossy.

I realized that the electronics for doing the modulation in hardware 
wouldn't really be more complicated (and maybe actually cheaper) than 
the hardware for doing it via a shift register.

more so, giving PCM to the hardware allows for things like volume and 
level controls to potentially be done in hardware as well (some of the 
hardware interfaces I had looked at, had supported HW based 
master-volume controls), ...

possible interface:
     0x007F0000: Audio ring-buffer (Left)
     0x007F4000: Audio ring-buffer (Right)
     0x007F8000: Audio registers
         0x007F8004: Sample rover
         0x007F8008: Left Volume
         0x007F800C: Right Volume
         0x007F8010: Sample rate
         ? ...


or such...