[J-core] Talk video.
BGB
cr88192 at gmail.com
Thu Jan 19 22:59:24 EST 2017
On 1/19/2017 2:37 PM, Rob Landley wrote:
> The talk is up!
>
> Video: http://youtu.be/o0milqmt4ao
> Slides: http://landley.net/talks/lca-2017.txt
>
> Alas, I ran out of time (not enough practice run-throughs of the
> material. Downside of preparing the outline while attending a busy
> conference.) But I hope you find it interesting.
yep, I found it interesting.
revived just enough motivation to start working on an
Emscripten/web-browser port of my emulator.
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/
facing troubles with Emscripten's built-in terminal interface being
pretty terrible (and needing to use SDL already for this), for the
emulator I am considering doing a rendered console interface.
I sort of have it working, but the existing in-browser console interface
is basically unusable.
this leads to some TBD issues:
should the console buffer be mapped into the emulator?
should the interface also provide a graphical framebuffer?
8bpp, 15bpp (hi-color), or 32bpp true-color?
probably will use either 640x480 or 1024x768, currently leaning
for 640x480 15bpp or 32bpp.
probably the framebuffer would exist either way (also needed for the
console), but in text-mode is likely to be regularly stomped by
redrawing text (probably, there would be some memory-mapped registers to
control this).
say, possibly:
00A0_0000 .. 00DF_FFFF: framebuffer
00E0_0000 .. 00E0_FFFF: text-mode console, graphics registers,
ASCII ROM, ...
00E4_0000 .. 00E7_FFFF: color-cell tiles (?)
(unless anyone has an existing design for a framebuffer interface they
want me to use).
a case could possibly be made for a color-cell graphics mode, but don't
know if I will do so (would more matter if I wanted to do semi-fast
graphics in the emulator, as I don't expect ability to quickly redraw a
bitmapped framebuffer for this).
would need to decide specifics for this, ex: 4x4 vs 8x8 blocks, storage
size, ... decided to omit going into specifics, but it could be useful
for some types of tasks (with different tasks favoring different tile
layouts).
my previous leaning was for 8x8 tiles each using 256 bits, with a few
specialized tile-modes.
in color-cell mode, the emulator would redraw tiles into the framebuffer.
in text-mode, console interface is likely to be structured similarly to
VGA text mode:
ascii:BYTE (CP-437)
attrib:BYTE (4 bit fg color, 3 bit bg color, blink bit)
could also make it logically word based:
00FF: ascii
0F00: fg color
7000: bg color
8000: blink
though, a case could possibly be made for 32-bit console cells.
probably the existing virtual serial interface will be routed to this
console (probably with basic ANSI code support).
ATM, will use raster rendering rather than WebGL (already had enough
battling with WebGL recently).
or such...
More information about the J-core
mailing list