[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:

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

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