Use emulated memory as pixels buffer in SDL console

[mfld-fr]

Opened this issue to track one remaining option in #32.

[mfld-fr]

Maybe we would see nanoX running in EMU86 :laughing: ?

[ghaerr]

I was just thinking about your comment:

It means for example not to render the character immediately with the raster font on INT10h, but writing the character code in the emulated video memory (in 80x25 text mode as in real PC), and render that emulated video memory periodically in the main loop.

Actually, in order to emulate PC memory for ELKS direct console, it's probably better to go with your idea. The PC memory would be inspected every 10,000 cycles or so and text (or graphical) output would be created. Its not a big deal, except from prior experience this can be very slow when having to create an entire screen of graphical text pixels, so I'm still thinking about the best approach.

The current approach allows "streaming" output which can still be useful. Emulating the PC memory directly would allow anything to run, including nano-X.

But when implemented, it should mean that nano-X should run for free!!

[ghaerr]

But when implemented, it should mean that nano-X should run for free!!

Ugh. Thinking more about this, in these old systems bitmap graphics isn't done "framebuffer style". Instead, we would have to emulate the EGA (4-planes, messy). But a 4-bit "framebuffer" could be easily emulated instead, matching newer hardware, and then nano-X would run 😏

[mfld-fr]

To avoid rendering all the characters in text video mode, you could add an array of 'dirty' bytes, one for each character, to update only the changed characters, right ?

[ghaerr]

Actually an easier method is to keep track of a "bounding rectangle" which encompasses all dirty screen contents, then update that in a single SDL update. I have that code almost ready to go in other places.

[ghaerr]

Now that SDL is working perfectly for the headless and BIOS console cases, what we really need is stdio-based EMU86 control, to start/stop emulation while screen contents unchanged. How do you want to implement that?

[ghaerr]

Looking a bit further into emulating video text memory: in order to have a cursor, we will also have to emulate a 6845 CRT controller. This is required for hardware cursor. In my current SDL implementation, I get the cursor location through a BIOS call, or emulate it in a tricky fashion for streaming data.

In non-BIOS (direct) video text mode, the kernel direct console driver gets the port address of the 6845 through the BDA at 0040:63h (which we also would need to emulate, ugh), and uses that to write the hw cursor and hw page address. The emulation is easy, but still needs to be done. I hadn't realized the ELKS direct console is dependent on BDA and 6845.

Another thing : emulating video text memory won't work on stdio backend. So we will always want an EMU86 version that works as it does now, including for SDL "streaming" output. Having both at the same time isn't a big deal, but its another thing to think about.

FYI!

[ghaerr]

Proof of concept demonstrated in #50.

[mfld-fr]

Improvement performed in #50