If the rendering thread is read only it won't impact the CPU emulation however the other way around is not always true as you might be in a middle of a write from CPU when you are reading memory so stuff might appear corrupted on the screen for one frame or so.

One thing to keep in mind too is resolution changes. Depending on how you manage your buffers and if you do not have locks you could be reading from the wrong size of buffer in the rendering thread which either makes the display very wrong (wrong pitch) or just plainly crash (as you read memory that is not there anymore).

Vlad.

Emulated VRAM doesn't have locks. The main thread reads and writes to emulated VRAM. The rendering thread only reads from emulated VRAM.

Any VGA register changes (resolution changes and other settings of the VGA) are protected with locks when updating the renderer information from the CPU thread(this lock also applies to the pixel block renderer itself).

I'm not sure if this design could work. You have made the rendering independent of the emulation of CPU and VGA hardware?
On a real machine they are dependent. So you should emulate an entire frame (and record all changes to any CRTC registers at their respective raster positions), then pass the framebuffer and rastertime-based state content to your renderer. Then the CPU/VGA emulation will render to a NEW frame/statebuffer (which start out with the last state of the previous frame).
This way you won't have issues with the rendering interfering with the emulation. And you can support all raster effects that the hardware supports (such as palette changes, scrolling partial screens, etc).

What I am doing is slightly what Scali is describing. None of my registers writes (for either a MDA, Hercules, CGA or VGA devices) are locked (except for mode changes). I think that would slow down things. Then from my main clock class I call the device to render a single scan-line at (relative) correct time intervals. The "render a scanline" operation is just putting pixels in a buffer which is later passed to my filter then my scaler and finally to SDL for displaying. The buffer is never cleared just simply more rasterlines are replaced into it. Once I reach the last raster line I do the vsync stuff. On a resolution change I destroy and recreate the framebuffer into which I draw scanlines.

Vlad.

Yes, I said 'entire frame', but the same approach could also work for 'entire scanline', with some extra handling for the top and bottom of the screen (vblank area and all that).
I just hope people don't just implement one state per scanline... That's how DOSBox works. It makes simple rasterbars possible (it just uses one background colour value for the whole scanline), but nothing mode advanced, and it is not an accurate emulation of what the hardware does. For full accuracy you want to have a timestamp of *where* on the scanline the register was changed. And don't forget that real hardware doesn't just have visible pixels, but also a visible border. So you can also see changes of background colour in the border, not just in the pixel area.

Scali, you mean not all registers are read only during horizontal or vertical retrace? Some of them are read during the scanline drawing too? I did not know that.That makes the emulation slightly more complicated.

Vlad.

vladstamate wrote:

Scali, you mean not all registers are read only during horizontal or vertical retrace? Some of them are read during the scanline drawing too? I did not know that.That makes the emulation slightly more complicated.

Yup... You want proof? 😀
Look at this: http://www.reenigne.org/blog/adventures-in-crtc-lockstep/
The background colour can be changed at any position on the screen, as you can see.
Or see this: https://youtu.be/jyHSWDi8lg8
The original code was rather slow, so the changing of the background colour happened in the visible part of the border. You can see it jitter.

I don't know if there are *any* registers that are only read during horizontal retrace. I know the 6845 reads at least some registers only in vertical retrace (but even then you can trick the card to generate multiple retraces on a single physical frame on the monitor, like how 8088 MPH generates its high-colour modes). But the palette logic is not latched at all, any write you do takes effect immediately.

Yup... You want proof? 😀

Oh no, I believe you! 😀 Thank you for the links.

(apologies to superfury for hijacking his thread.)
Vlad.