Reply 80 of 198, by superfury
wrote:No, there is no VGA emulation in CAPE. However I am working on a rewrite of all MDA/Herc/CGA/EGA parts using a 6845 emulator. Most of the current issues in CAPE with 8088MPH are related to CGA innacuracies which this re-write should solve.
I'm looking forward to the result when it's done(although all those things already work in UniPCemu, which uses a general patch-style VGA renderer at it's core, with customizations/extensions for all CGA/MDA/SVGA accesses). The only thing left needing accuracy in UniPCemu is the CPU itself(timing only). Although the 80286 still has some execution bugs(mostly protection fault errors afaik, seeing as it runs without problems(except for keyboard(errors out when resetting it using command 0xFF)/CMOS(why this is is unknown, seeing as it should be giving the correct results, albeit using the high resolution clock combined with the actual Windows time as it's relative RTC time(displacement added to the actual time to obtain emulated timestamp) source instead of running at the same speed as the emulated hardware) and FDC(Not 100% accurate yet: seek timings are emulated, but read/write times aren't yet)). All other hardware besides floppy(read/write timings only)/CMOS(RTC timestamp only) are already emulated cycle-accurate(afaik). So only the FDC and CPU still need work to become cycle-accurate, all other hardware is already cycle-accurate(although the OPL2 emulation still needs fixing on the drumkit, which odd enough seems to fail using the formulas I've found in OPL3EMU). The RTC won't be changed anymore(time-wise), because it's built to keep time accurately(high-resolution clock) synchronized with the actual time reported by the host OS(gettimeorday-based or equivalent). So setting time in the emulator to a certain date/time, terminating the emulator and starting it up again exactly 5 hours later will result in the emulated RTC reporting the time 5 hours later as well(so it will act just like an actual RTC was installed, except when the host System time is changed, which will affect emulated time by the same amount that it's changed due to the same synchronizing effect). So essentially it keeps time like Dosbox, but it time changed in the emulated RTC will be kept consistent automatically due to UniPCemu only storing time divergeance compared to the Host OS timestamp.
wrote:Currently I have 4 individual emulations for each card however in the new scheme I have a 6845 emulator that each card can use. Still early but I am hoping to iron out the CGA issues in 8088mph with this.
That sounds about the same as my VGA renderer emulation, which isn't exactly emulating a 6845, but rather a generic VGA framework(with general functions performing cycle-exact rendering at a specified pixel rate) which is extended or modified by special CGA, MDA or SVGA handlers to modify it's functionality and extend it to support the specific hardware fully.
The renderer, to be exact, just renders pixel according to stored display precalculated parameters(retrace, blanking, bitdepth etc. Just the VGA precalculated values) at the set pixelrate. The I/O and MMU handling etc. is handled by the hardware-specific(or general in case of the SVGA emulation using the IBM VGA hardware layer) CGA, MDA or VGA(all other video cards) handlers in their seperate units. Although most of the emulation is split according to the VGA documentation(Attribute controller, CRT controller, Sequencer, MMU controller, I/O controller).
So essentially, the current UniPCemu video card emulation can be explained like this:
VGA base+CRT emulation is the base of all.
CGA/MDA emulation overrides the VGA I/O and precalcs base emulation only, leaving the CRT emulation unmodified.
EGA overrides part of the VGA emulation only by masking off parts of the registers and custom code in the VGA base emulation.
SVGA emulation extends the VGA base and precalcs with it's new values only. Otherwise, it's still normal VGA emulation, giving full compatibility with the VGA emulation.
CGA/MDA emulation core, which overrides the VGA emulation core for the most part: https://bitbucket.org/superfury/unipcemu/src/ … mda.c?at=master
The NTSC/RGBI conversion routines are hardcoded in the renderer itself, but are toggled on/off using various flags in the VGA base emulation itself(read by the general renderer to decide how to render a scanline or pixel).
Base renderer: https://bitbucket.org/superfury/unipcemu/src/ … rer.c?at=master
The extensions (CGA/MDA/SVGA) essentially work by hooking the VGA emulation and handling part of the I/O and precalcs by overriding it with their own handlers or precalculated CRT values(). See the VGA_registerExtension function call at the bottom of the CGA/MDA emulation unit. If this function and it's related functions isn't called, just a normal IBM VGA is emulated.
Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io