[J-core] Talk video.

[BGB]

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:
>> https://cr88192.github.io/bgbtech_html/
> 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 any
> 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).


as-is, it needs a 256MB heap (a single 256MB JavaScript array), of which 
128MB is the emulator's DRAM, and the rest is misc stuff (AFAICT, 
Emscripten only supports power-of-2 heap-sizes).

to run it, the Chrome instance seems to need ~ 400MB.

for Linux to boot, there is a bit of a delay.
checking the clock, it is about 48 seconds before the kernel visibly 
boots on my desktop PC (currently using an AMD FX 8350).

only part of the keyboard works as seemingly only part of the keyboard 
generates key-events inside of a browser window.


changes from prior email:
memory layout for framebuffer was tweaked, made reserved space for 
framebuffer start at 0x00800000 and be large enough to hold a 1920x1080 
framebuffer (even if a bit overkill for 640x480);
console is located at 0x00FF0000, control registers are at 0x00FF8000, 
and ASCII font at 0x00FF8800.

I ended up going with using 32-bit RGBA for the framebuffer.

the console buffer uses 32-bit cells, where I used some more of the bits 
to support additional effects and multiple fonts (though, does not 
directly support unicode).

theoretically supported via ANSI codes:
     basic colored text;
     blink, bold, italic, underline, strike-through, reverse-colors;
     most of the cursor-related commands have been implemented;
     ...

currently only 32-bit memory accesses are supported for writing to 
graphics memory/registers.
though, will see if I do something graphical in the emulator.


I had considered trying to clone whatever was the de-facto graphics 
hardware for SH, but I wasn't really find anything documented (the 
closest I could find was for the Dreamcast hardware, but wasn't really 
able to find much documentation for it).

details here still subject to change.