[J-core] emulator status (Re: keyboard fix)
cr88192 at gmail.com
Tue Jan 31 00:40:01 EST 2017
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:
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
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
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), ...
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
More information about the J-core