On 1/21/2017 3:47 PM, Rob Landley wrote:
>
> On 01/20/2017 06:23 PM, BGB wrote:
>> 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).
> I left it running in another window, came back and it had booted to an
> aboriginal linux prompt (I really need to get a first mkroot release
> out), and then when I typed "ls -l" and hit enter it typed just "l" and
> the newline and then hung eating 100% cpu.
not sure there; commands typically work on my end, though a lot of keys
don't work;
for whatever reason, a lot of the keys don't actually seem to generate
scancode events in the SDL implementation provided by Emscripten, but I
could look more into it and see if some things are getting translated wrong.
keys which don't seem to get through:
arrow keys;
other cursor keys;
numeric keypad;
F-keys;
CTRL / ALT / ...
...
for my 3D engine, I had to fudge the input scheme around the range of
keys I was getting input for.
> The console stuff isn't working for me. Emulator seems to run the kernel
> though. And there's a second test window at the bottom of the screen
> that doesn't display whole lines of text (scrolls off the bottom at a
> partial line...)
that is the normal textual/printf interface provided by Emscripten;
I started working on the console interface on the top of the screen as
that lower interface was basically unusable, if one tries to get input
from it, it basically does a text-input pop-up box (similar to the
password box which pops up when trying to log into some FTP sites in the
browser);
it also will not display printed text unless it has a newline;
in other cases, I have also noted that it is fairly slow (takes a good
number of milliseconds for each print event);
...
so, faced with that, I set up a 640x480 display window, and started
printing the console output to this.
I may start working on using this as the primary console, as from the
normal Windows console I have the issue that ANSI codes don't work (and
Linux locks up as soon as a command is typed).
I sort of have it working a little better, but there are still issues
(mistyping commands can cause it to lock-up, and backspacing too much
erases the prompt and causes a crash, ...). I am not sure if some of
this is due to a bug in the 'hush' shell or similar, or in my emulator,
or if the shell expects something special from the terminal.
ex:
in the shell, hit backspace a bunch of times, type something, hit enter,
it crashes.
> What does lock/hide mouse pointer do?
I haven't figured that out yet, that part came with Emscripten.
>> 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).
> This netbook has some kind of windup toy called an AMD C-60. (Apparently
> I can get a replacement instance of this model on ebay for $70, although
> I'd have to upgrade the ram again.)
yeah.
I have new desktop PC; it has 24 GB of RAM, and an 8-core CPU (at 4.2 GHz).
ATM, I have it set up for 64-128GB of swap, as scarily enough there are
actually times when I end up needing this much.
>> only part of the keyboard works as seemingly only part of the keyboard
>> generates key-events inside of a browser window.
> Uh-huh.
I don't currently know of a fix for this.
>> 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).
> We were going to do a simple framebuffer for the turtle HDMI. Jeff knows
> the details (and possibly Rich), I don't. (It's whatever the maximum
> resolution of the free spec you don't need to license stuff is.)
>
> I have a tab open on the home machine (still at LAX) with the Chaos
> Computer Conference talk by the guy who did the HDMI. It's probably
> https://www.youtube.com/watch?v=VXBM0frM48E
>
> Also, they did one about geting USB running on a microcontroller
> (https://www.youtube.com/watch?v=G_tdJ9Lu7Zk) and I was talkign to
> somebody at LCA who was convinced they could make a spartan 6 do USB2
> (not just USB 1.1 with a bridge upshifting to 2) which _might_ have been
> the same guy, I'll have to sort through business cards and see who
> emails me...
>
> Speaking of which Jeff was talking to somebody about getting Turtle
> boards actually manufactured, but I dunno the current status of that,
> let alone schedule...
yeah, dunno.
IIRC, Dreamcast was nominally 640x480;
found some info about its display (addresses, registers, ...) at one
point, but wasn't able to find it again, and couldn't remember the
specifics off-hand.
my original thinking of 0x00A00000 was homage to the VGA framebuffer at
0x000A0000 (or A000:0000), with some initial thinking of putting a
console with a VGA-like layout at 00B80000. this all changed around
mostly because there wasn't enough space for the original framebuffer
(and VGA's space wasn't even really big enough for VGA...).
00800000..00FEFFFF gives "just enough" space to fit in a 1920x1080x32bpp
linear framebuffer (~ 8MB).
some of the remaining space was used for a text-mode buffer (but, 720p
or 1080p with 8px character cells would result in a console too big to
fit in this space). (here, I am pretending that 4K and 8K don't exist).
I might work on the emulator more, try to see if I can get some things
working a little nicer.
also working some in trying to test/validate that the various ANSI-code
features work (ex: for sake of possible colored text and box-graphics
and so on).
did do a little hacky extension to allow low-res bitmap graphics in the
terminal via escape codes:
4x4 pixels per character cell (with 2 colors from a 16 color
palette per-cell)
these use the same character cells as normal console characters.
each pixel selects 1 of the 2 colors.
cost is ~ 4 characters/cell (base85)
if it doesn't work, it looks like a big blob of base85.
cost is ~ 2bits/cell, so a 320x240 image would take approx 20kB.
don't expect much serious use vs normal ANSI-code features though.