GloriousCow wrote on 2023-05-26, 01:41:

Yep, I have a copy. It's quite the tome. It's evidence that even after getting Area5150 running, there's a whole world of behavior I have yet to tackle and future demos might exploit. I have an MC6845 connected to a Teensy microcontroller too, but I haven't explored it any where near in as much depth as the 8088. That's a future blog article, or two. Hey, maybe I can come up with my own effect!

I think some progress was being made amongst BBC Micro users in reverse-engineering the 6845 based on Sean Riddle's die photos, but those photos appear to be of the HD6845S (the -S variant wasn't used on original CGA boards, although a few enhanced compatibles were based on it).

GloriousCow wrote on 2023-05-26, 01:41:

Speaking of releases, how would you feel about me possibly including 8088MPH/Area 5150 with my binary release? My thoughts were it would be great to give people a way to experience the demos as intended themselves "out of the box", but I completely understand if you'd rather not have it distributed that way. I am not sure what the etiquette is there, so apologies if that suggestion is gauche.

It's not just my own call to make, but personally I wouldn't have any problem with it at all - on the contrary. I'd kindly like to ask only that the included copy will be brought up to date, once we actually release the final version. 😀
We recently noticed Area 5150 in the list of software preloaded with that new 'Book8088' mini laptop (https://forum.vcfed.org/index.php?threads/chi … -3#post-1318513), and it's one of the very few things in there that *doesn't* violate some kind of license or copyright...

GloriousCow wrote on 2023-05-26, 01:41:

And boy did I not understand how the hell composite artifact color worked. In black and white, sure, the diagrams on your blog make it fairly simple. You can even do a simple 16-slot color LUT with 4 pixels as your input the high res monochrome CGA modes in the most naïve implementation.

Ha... that naïve implementation of composite color (a fixed grid of digital-looking pixels, using a fixed 16-color LUT) is something I used to see a lot in Apple II emulation, and even then I could tell that there was something very 'off' about it. To this day most Apple II screenshots you can find on the web look like crap, and the same goes for all those 'play online' emulators: they completely mis-represent what the originals looked like.
(I think this may also have something to do with how the IIgs emulated older II graphics using its RGB output, but I don't know enough about that machine to say for sure.)

GloriousCow wrote on 2023-05-26, 01:41:

Do some luma sampling first and multiply and you even get a passible result. But as soon as you add color, it all falls apart. So I bought an oscilloscope and I sat down with the CGA schematic and an "Old style" CGA card fresh from ebay and I spent a few weeks figuring out how to convert the flower girl image from the raw RGBI source. That's when I learned about the multiplexer, and the fact that you have to model half-hdots as certain colors are out of phase by half a cycle. You may recall I emailed you for permission to use your art for a planned blog post about all that. My code isn't the most accurate, but I'm still proud of it. Just not quite satisfied. For example, in the CGA type detection screen, i'm somewhere between "NEW" and "OLD" despite modelling old-style. Just probably have some values wrong somewhere.

That sounds like the best way to go about it. I didn't really have the engineering background or the tools to do my own research that way, so the technical part of my explanation in that blog post was mostly second-hand. My ulterior motive for trying to understand it was to be able to use it effectively when creating graphics: if you simply assume an orderly grid of pixels with a fixed palette, you miss out on useful tricks and methods (and run into blunders, like placing blue and orange next to each other and getting a bright white for your troubles). But yes, I suppose I didn't really go into the specifics of the 'direct' colors and their phase relationships. I wanted to go into that sort of detail in a further article or two "for the artist", but never got around to it... maybe one day.

Still, as I recall (reengine may correct me if I'm misremembering here), modeling the color decoding process from scratch still left some unexplained inaccuracies vs. the real thing, although it got *very* close; that's where sampling the multiplexer output proved to be a better strategy. I don't know how a pure software model could be brought to the same level of fidelity - maybe if the multiplexer itself were fully reverse-engineered or something?

GloriousCow wrote on 2023-05-26, 01:41:

Was it worth it? I think so. It's that kind of esoteric, pointless technical knowledge that really impresses during dinner conversation.

You must have more interesting dinners than I do. 😁

GloriousCow wrote on 2023-06-01, 00:16:

I've made an initial Windows release of my emulator, available here:
https://github.com/dbalsom/martypc/releases/

Interested to see what people think. I'm open to suggestions and feature requests!

Excellent, I'll have a play with it and see!

GloriousCow wrote on 2023-05-30, 12:44:

Should be easy to fix. The color control register controls the overscan color. […]
Show full quote

superfury wrote on 2023-05-30, 09:59:

OK. Mostly went fine, but somehow the overscan seems to always seems to be black?

Should be easy to fix. The color control register controls the overscan color.

superfury wrote on 2023-05-30, 09:59:

During the 3D vector part. it runs almost 100%, except the area between the 3D object going up and down has black between the jumping area and the top and bottom static pictures?

This effect switches between text and graphics modes mid-screen. If you see a black bar, that's a result of the tetrahedron, which is intended for graphics mode, being drawn in text mode. There's nothing too devious about this effect other than requiring accurate interrupt timing.

I'm guessing that black bars may also appear in between the static images and the moving object, even if the latter is rendered in graphics mode. If that's the case, then fixing issue #1 above should take care of this one too (which is also a slight spoiler perhaps).

What I eventually found worked best for emulating the composite colour waveforms and multiplexer was to set up a table of samples indexed by current RGBI colour (4 bits), previous RGBI colour (4 bits) and phase (2 bits) for a total of 1024 entries. The I signal doesn't go through the multiplexer so its behaviour can be characterised by 256 data points, but the larger table makes it simpler to implement in an emulator. The values in the table can be constructed by making measurements of various combinations of foreground colour, background colour and pixel pattern, and solving the equations.
Reverse-engineering the circuitry in the multiplexer wouldn't really help because its digital behaviour is well-understood - the issue is the various bits of analogue behaviour; timings of various gate delays in particular. I tried to account for all the delays I could think of at one point and got a model that was really difficult to work with but still had various problems with its output. Treating it as a black box and essentially measuring the output for each possible input worked much better.

VileR wrote on 2023-06-02, 10:28:

GloriousCow wrote on 2023-05-30, 12:44:

Should be easy to fix. The color control register controls the overscan color. […]
Show full quote

superfury wrote on 2023-05-30, 09:59:

OK. Mostly went fine, but somehow the overscan seems to always seems to be black?

Should be easy to fix. The color control register controls the overscan color.

superfury wrote on 2023-05-30, 09:59:

During the 3D vector part. it runs almost 100%, except the area between the 3D object going up and down has black between the jumping area and the top and bottom static pictures?

This effect switches between text and graphics modes mid-screen. If you see a black bar, that's a result of the tetrahedron, which is intended for graphics mode, being drawn in text mode. There's nothing too devious about this effect other than requiring accurate interrupt timing.

I'm guessing that black bars may also appear in between the static images and the moving object, even if the latter is rendered in graphics mode. If that's the case, then fixing issue #1 above should take care of this one too (which is also a slight spoiler perhaps).

Managed to fix the overscan. The issue was that the CGA's updating of registers (although this affects the EGA/VGA-compatible video cards as well) were giving a special command to update a specific section of registers in the video rendering unit (think attribute controller, crt controller, dac, etc.). In this case, it requests the updating of all attribute controller registers (so that includes the VGA-compatible overscan register (which is written by the CGA compatibility layer) as well as all color registers (which map different attributes in different way to actual foreground/background color values, like the VGA attribute controller register 0 through Fh).
The issue in this case was that although the section update was detected, it then checks what section to update, which is OR-ed together for the actual value (so it's SECTIONUPDATEFLAG(0x20000)|area(there's also lower bits indicating a register for the lowest 12 bits, but that should be ignored in that case when the SECTIONUPDATEFLAG is set). The issue here was that the area wasn't checked on it's own (by masking off the SECTIONUPDATEFLAG bit area and the register area), so it was matching the section's area against the area bits, register bits as well as the SECTIONUPDATEFLAG (which is always set in this case). So setting the required SECTIONUPDATEFLAG should be ignored when checking within the section (it's also checking the full update value using the == equals C++ operand for individual registers, but that isn't the case here), but because it's a direct comparison against the section itself, it never matched! So any and all of those color/overscan color register updated would never be registered by the attribute controller, thus never displaying the correct values (unless all registers are triggered for a global register update (which has all the bits in the whereupdated variable set to 0) to update all precalcs in one fell swoop, which almost never happens.

The only other area affected by this bug is the CRT full update when updating the VGA sequencer register 01h as well as the character width.

GloriousCow wrote on 2023-06-01, 00:16:

I've made an initial Windows release of my emulator, available here:
https://github.com/dbalsom/martypc/releases/

Interested to see what people think. I'm open to suggestions and feature requests!

I've tried it on two machines around here... one is a desktop Core i7 860 with a GeForce 970. The other is a laptop Core i7 2720QM with an nVidia NVS4200M.
Neither system was fast enough to run at full speed. Which was somewhat expected, as these aren't exactly the fastest machines around.
However, they didn't perform the way I expected.
That is, the 2720QM usually has the better performance where CPU is involved. And emulators tend to be CPU-hungry, and not very heavy on the GPU.

In this case however, the 860 would get about 50 fps emulated in RGBI mode, where the 2720 gets only 30 fps, so significantly slower.
When I enable composite mode, the performance is more or less cut in half on both machines.

Also, on the NVS4200M I get a Vulkan error for enumerate_adapters. No surprise, as Vulkan is not supported on that GPU.

But that makes me wonder: do you use the GPU for more than just trivial rendering of framebuffers generated by the emulator on the CPU?
That would explain why the system with 860 would be faster, as it has a much better GPU.
Also the GeForce 970 does support Vulkan.

So do you actually render the screen with Vulkan, if available? And if not, what does it fall back on?

Also, my task manager tells me that the CPU usage is only about 25%, so apparently it's not making a lot of use of all the CPU cores available.
Perhaps some of the emulation could be made to use the extra cores? For example, the composite seems very heavy... but it's probably trivial to process it in a separate thread asynchronously, while the emulator will move on to the next frame. Which in theory would make the composite mode as fast as the RGBI mode.

Scali wrote on 2023-06-02, 22:00:

I've tried it on two machines around here... one is a desktop Core i7 860 with a GeForce 970. The other is a laptop Core i7 2720QM with an nVidia NVS4200M.

But that makes me wonder: do you use the GPU for more than just trivial rendering of framebuffers generated by the emulator on the CPU?

The GPU is used for scaling the buffer to the window and compositing the GUI debug windows, but not much else at the moment. I eventually want to have a few shaders available for post-processing effects. (CRT emulation, color/geometry adjustments, etc)

Scali wrote on 2023-06-02, 22:00:

So do you actually render the screen with Vulkan, if available? And if not, what does it fall back on?

I'm using wgpu to render. It will prefer Vulkan on windows/linux but Metal on Apple platforms. Here are the backends it supports: https://docs.rs/wgpu/latest/wgpu/enum.Backend.html

Scali wrote on 2023-06-02, 22:00:

Also, my task manager tells me that the CPU usage is only about 25%, so apparently it's not making a lot of use of all the CPU cores available.

Perhaps some of the emulation could be made to use the extra cores? For example, the composite seems very heavy... but it's probably trivial to process it in a separate thread asynchronously, while the emulator will move on to the next frame. Which in theory would make the composite mode as fast as the RGBI mode.

Multithreading an emulator can be tricky, but its certainly possible... Ultimately, what I planned to do is make the composite conversion into a fragment shader, which would eliminate the performance hit entirely. I have a working shader for the monochrome high resolution composite mode, but it doesn't simulate the color multiplexer yet so is no use for 8088mph:

I'm not exaggerating though when I say that MartyPC has really no attempt whatsoever at optimization in its current form. It's hard to have the goal of making things accurate and making things fast at the same time, and I was just too excited about getting Area 5150 working to wait until I had time to take an optimization pass or two over my code before putting it out into the world. I have a fairly beefy PC (5900X, 3080ti) so it wasn't something I really had to worry about during development, apart from scenarios where I was logging incredible amounts of data. Running well on a variety of hardware is important to me, so I'll be working on making things more performant.

GloriousCow wrote on 2023-06-03, 01:07:

The GPU is used for scaling the buffer to the window and compositing the GUI debug windows, but not much else at the moment. I eventually want to have a few shaders available for post-processing effects. (CRT emulation, color/geometry adjustments, etc)

Okay, that should be trivial enough that there shouldn't be massive performance differences between GPUs/APIs/drivers.

GloriousCow wrote on 2023-06-03, 01:07:

I'm using wgpu to render. It will prefer Vulkan on windows/linux but Metal on Apple platforms. Here are the backends it supports: https://docs.rs/wgpu/latest/wgpu/enum.Backend.html

Ah, it supports a wide range of APIs.
Would it be possible to show in the console/UI which backend it has selected (as in my case, apparently Vulkan wasn't available, but I don't know what it picked instead)?
Or even better: could you make an option to manually select the backend, so end users can experiment with which backend works best on their system?

GloriousCow wrote on 2023-06-03, 01:07:

Multithreading an emulator can be tricky, but its certainly possible... Ultimately, what I planned to do is make the composite conversion into a fragment shader, which would eliminate the performance hit entirely. I have a working shader for the monochrome high resolution composite mode, but it doesn't simulate the color multiplexer yet so is no use for 8088mph:

Right, the main emulation will need to be closely synchronized, making multithreading difficult.
But composite is basically a post-processing filter that can be applied to the raw frame data.
Likewise a part of the audio emulation could also be done via post-processing in a separate thread, depending on how you emulate it...
In theory the PC speaker is a 1.19 Mhz 1-bit digital audio-source, so if you do a bit-exact emulation, you'd need to convert it down to a more conventional 16-bit 44.1 kHz PCM signal or such before outputting. Which could also be done on a seperate core.

But indeed, the post-processing for the video is ultimately best done in a shader on the GPU.

GloriousCow, congrats on this impressive work!

Scali wrote on 2023-06-03, 11:19:

Okay, that should be trivial enough that there shouldn't be massive performance differences between GPUs/APIs/drivers. […]
Show full quote

GloriousCow wrote on 2023-06-03, 01:07:

The GPU is used for scaling the buffer to the window and compositing the GUI debug windows, but not much else at the moment. I eventually want to have a few shaders available for post-processing effects. (CRT emulation, color/geometry adjustments, etc)

Okay, that should be trivial enough that there shouldn't be massive performance differences between GPUs/APIs/drivers.

GloriousCow wrote on 2023-06-03, 01:07:

I'm using wgpu to render. It will prefer Vulkan on windows/linux but Metal on Apple platforms. Here are the backends it supports: https://docs.rs/wgpu/latest/wgpu/enum.Backend.html

Ah, it supports a wide range of APIs.
Would it be possible to show in the console/UI which backend it has selected (as in my case, apparently Vulkan wasn't available, but I don't know what it picked instead)?
Or even better: could you make an option to manually select the backend, so end users can experiment with which backend works best on their system?

GloriousCow wrote on 2023-06-03, 01:07:

Multithreading an emulator can be tricky, but its certainly possible... Ultimately, what I planned to do is make the composite conversion into a fragment shader, which would eliminate the performance hit entirely. I have a working shader for the monochrome high resolution composite mode, but it doesn't simulate the color multiplexer yet so is no use for 8088mph:

Right, the main emulation will need to be closely synchronized, making multithreading difficult.
But composite is basically a post-processing filter that can be applied to the raw frame data.
Likewise a part of the audio emulation could also be done via post-processing in a separate thread, depending on how you emulate it...
In theory the PC speaker is a 1.19 Mhz 1-bit digital audio-source, so if you do a bit-exact emulation, you'd need to convert it down to a more conventional 16-bit 44.1 kHz PCM signal or such before outputting. Which could also be done on a seperate core.

But indeed, the post-processing for the video is ultimately best done in a shader on the GPU.

UniPCemu also resamples it from 1.19MHz 1-bit to 44.1kHz 16-bit the official way, in 44.1kHz chunks.
First it converts any ~1.19MHz(14318180/12) 1-bit sample into 16-bit by converting by simple if(set)/else to +32767/-32768. Then it low-pass filters at output rate divided by 32 (niquist divided by 16) and stores the last result of that.
Finally, when all 1.19MHz samples of the period of the resulting 44.1kHz speed (=~1193181(.66666=exactly 2/3)/44100 samples) are done, the result that's stored is the sample to render at 44.1kHz. This entire loop and then concatenating it to the 44.1kHz 16-bit stream is the entire method of resampling UniPCemu uses.
So about 27 or 28 1-bit samples are looped for each 44.1kHz 16-bit output.

Ticking the emulated CGA card at 14Mhz is expensive. In the current release of MartyPC, the CGA device takes 3x the CPU time to emulate than the CPU itself.

I tried ticking the CGA by character clock, which would mean I could update the card at 1.79Mhz instead of 14Mhz. This worked for all of Area5150 except the Wibble and Lake (End credits) effects. They apparently still need cycle accurate timing.

So why not do both?

If a CRTC update occurs in the middle of an LCLOCK, we switch to cycle-accurate mode until the next LCLOCK, then drop back to ticking by HCLOCK. The pink areas represent areas in the border region where the CGA card is in cycle-accurate mode. You can see several CRTC updates just before the first scanline of the effect. The vertical pink bars are then the regular CRTC updates per scanline.

This represents a significant performance boost and will be in the next release of MartyPC among with several other optimizations - Scali, I hope it will run at full speed for you after this!

GloriousCow - amazing work on your emulator!!

Almost everything I've tried with it has just worked. A couple of things that would make it pretty much perfect-

There seems to be some corruption to the text in the CGA Compatibility Tester vertical scroll test,
CGA Compatibility Tester

Also the CGA game Prohibition has scrolling issues, I guess it just needs this port mirroring fix,
Unofficial CGA port mirroring? (Prohibition).

Just found that CRTC mirroring issue to exist in UniPCemu as well.
Although the issue was only half-present (only correctly decoded for MDA and EGA(and newer) in mono modes).
It's in the source code now!

th3bar0n wrote on 2023-06-11, 10:16:

There seems to be some corruption to the text in the CGA Compatibility Tester vertical scroll test,
CGA Compatibility Tester

Interesting, I'll check it out.

th3bar0n wrote on 2023-06-11, 10:16:

Also the CGA game Prohibition has scrolling issues, I guess it just needs this port mirroring fix,
Unofficial CGA port mirroring? (Prohibition).

I did notice the incomplete IO address decoding in the CGA's schematic and was planning to add all the port mirrors. This is good motivation to do so for the next release, thanks!

GloriousCow wrote on 2023-06-01, 00:16:

I've made an initial Windows release of my emulator, available here:
https://github.com/dbalsom/martypc/releases/

Interested to see what people think. I'm open to suggestions and feature requests!

Finally had a chance to give it a spin, and I'm *seriously* impressed, not only with the accuracy but also with all those extra debugging and monitoring tools. As you may have gathered, that's a huge selling point for me - having every relevant piece of state up on the screen and updated in real time (for CPU and devices) is super useful. I'm a fan of how single-stepping the CPU lets me see the exact position of the CRT beam, and what it's drawing while each instruction is executed!

A few specific requests/questions:

• With a CGA program running (and a screen full of content), why would the memory view show all zeros in the 16kb framebuffer at B800:0000? Curiously the MDA's 4kb at B000:0000 does seem to be full of '20 07's, i.e. a cleared screen.
• The memory view has a slight usability hiccup: if I type in a new address and hit enter, the view is updated but the scroll position seemingly isn't; the next attempt to scroll (with the mouse wheel or the scrollbar) will proceed from the old position instead of the new one, at least that's what I think is happening. (May also occur in some of the other widgets that work the same way.)
• I'm probably missing something, but I couldn't figure out how to save trace logs. I can enable trace logging and see the results on screen, but after 'flush trace logs', the only thing in traces\ is still a zero-byte 'validator_trace.log'.
• It'd be awesome if all the debug-related views/widgets could be spun off to a separate window. Especially useful on a two-monitor setup; maybe not so much on a single monitor, so perhaps that could be made an optional setting.
• The only other items on my wish list would be more 'standard' debugger features - the ability to modify memory/registers and to read/write IO ports; multiple breakpoints per type (and maybe additional types, e.g. break on port I/O); have a register name translated to its current value when part of an entered address.
  Not sure what else, but these are really just conveniences.

I could probably come up with more requests regarding the monitor/video emulation, but I'll lay off the entitlement for the time being 😉
Either way, hats off for all your work on this!

VileR wrote on 2023-06-11, 17:53:

[*]With a CGA program running (and a screen full of content), why would the memory view show all zeros in the 16kb framebuffer at B800:0000? Curiously the MDA's 4kb at B000:0000 does seem to be full of '20 07's, i.e. a cleared screen.

The memory viewer doesn't currently support MMIO; since the CGA card owns its own memory which is then mapped into the system and the viewer is not aware of that it shows all 0's. That could be addressed with CGA fairly trivially as it doesn't have pages, but there would be a question for say, EGA/VGA - what should I show for those ranges? Other emulators often have a dropdown for MMIO ranges specifically, and I could follow that model. I've also been considering a dedicated video memory viewer, with options to view VRAM as either hex or various graphical interpretations...

VileR wrote on 2023-06-11, 17:53:

[*]The memory view has a slight usability hiccup: if I type in a new address and hit enter, the view is updated but the scroll position seemingly isn't; the next attempt to scroll (with the mouse wheel or the scrollbar) will proceed from the old position instead of the new one, at least that's what I think is happening. (May also occur in some of the other widgets that work the same way.)

There's a lot of jank with the memory viewer at the moment, and a lot of if it centers around scrolling. It's more me fighting how to synchronize the position of the custom control that draws the memory viewer with the scrollbar position which is handled by the GUI toolkit. It bothers me too; so i'd definitely like to fix it.

VileR wrote on 2023-06-11, 17:53:

[*]I'm probably missing something, but I couldn't figure out how to save trace logs. I can enable trace logging and see the results on screen, but after 'flush trace logs', the only thing in traces\ is still a zero-byte 'validator_trace.log'.

Odd; it should be making a 'instr_trace.log' for the CPU. I'll check that I'm not doing anything dumb.

VileR wrote on 2023-06-11, 17:53:

[*]It'd be awesome if all the debug-related views/widgets could be spun off to a separate window. Especially useful on a two-monitor setup; maybe not so much on a single monitor, so perhaps that could be made an optional setting.

I agree that would be useful. I'm not sure how difficult it will be. The windowing library I'm using does in theory support multiple windows, but I don't know if the wgpu stuff will play nice. I've recently refactored my emulator core into a library so i can support multiple front ends, so if my current library stack won't cooperate I can try to find one better suited for that.

VileR wrote on 2023-06-11, 17:53:

[*]The only other items on my wish list would be more 'standard' debugger features - the ability to modify memory/registers and to read/write IO ports; multiple breakpoints per type (and maybe additional types, e.g. break on port I/O); have a register name translated to its current value when part of an entered address.
Not sure what else, but these are really just conveniences.[/list]

More debugging is coming; register and memory editing for sure (the CPU status window is already a bunch of edit controls, just need to send events when you change them). A breakpoint overhaul is definitely needed. Rather than add a million new little debug windows I'm planning on adding a little quake-like console window where you can issue commands. You'll be able to create named breakpoints of various types, and set up profiling between two breakpoints for cycle counts/time between any two breakpoints you have defined.

I appreciate you checking it out! Don't hold back on the suggestions. If there's even a remote chance I could make it good enough for people to use it for demo development, that would make me very happy.

GloriousCow wrote on 2023-06-06, 16:39:

This represents a significant performance boost and will be in the next release of MartyPC among with several other optimizations - Scali, I hope it will run at full speed for you after this!

Yea, these improvements sound promising!
I wonder though... do you actually have a system that runs the composite emulation at the full 60 fps?
If so, what kind of specs are we looking at?

Scali wrote on 2023-06-13, 10:00:

Yea, these improvements sound promising!
I wonder though... do you actually have a system that runs the composite emulation at the full 60 fps?
If so, what kind of specs are we looking at?

I have a Ryzen 5900X CPU, so a fairly recent and rather high-end CPU.

This is the performance view of the new build (I've added displays of the adapter and backend at your suggestion):

This is sort of the worst-case scenario on my system as both emulation and render time have some variable spikes to them. I'd say during 8088mph emulation time ranges from 2.6-6ms and render time 4.6-6ms.
Of course as long as we complete everything in under 16ms we can run at 60fps, so in this shot I still have about 6ms of headroom. That's still a lot of resources to emulate a 40 year old computer, but consider before I made the CPU and CGA cycle-accurate my emulation time was consistently around 1.5ms, and that's prior to any optimization whatsoever.

"Emulation time" is how much time is spent ticking the cpu and all devices, including the CGA card, which does internal rendering into an indexed color framebuffer as it ticks, per cycle/pixel if necessary...
"Render time" is how much time is spent converting the index color array produced by the CGA into RGBA either via the normal means or via composite conversion, and optionally aspect-correcting it.

Composite conversion adds about 4ms of render time on my system, which is a hefty hit, true. With it off, render time is around ~0.6 ms, with the occasional 1ms spike I'm trying to track down. As a shader it would run nearly instantaneously, with the caveat that you'd be locked to a full-screen display of the window (unless I figure out how to run a shader on a subsection of the viewport)

The new version of MartyPC is at least 2x as fast, and I'd like to release it as soon as I figure out a lingering bug that rarely occurs during mode changes that throws my new character-clock synchronization out of whack (updating sync width during hsync maybe?) There's still plenty of optimizations to make, like an interpreter cache, a proper scheduler, perhaps a scheduled timer vs ticked.

Awesome project! Now if someone could fix area5150 so that it runs on my 286, that would be nice 😀 It runs pretty far, but crashes at some point late in the demo.

Lovely to see that your emulator is multi platform! Very impressive! Will check it out on my M1 Mac to finally see the end of area5150!

th3bar0n wrote on 2023-06-11, 10:16:

There seems to be some corruption to the text in the CGA Compatibility Tester vertical scroll test, CGA Compatibility Tester […]
Show full quote

There seems to be some corruption to the text in the CGA Compatibility Tester vertical scroll test,
CGA Compatibility Tester

Also the CGA game Prohibition has scrolling issues, I guess it just needs this port mirroring fix,
Unofficial CGA port mirroring? (Prohibition).

Both of these should be fixed in the next release. The scrolling bug was a bit embarrassing, considering how much I check cgacomp output and somehow missed that...
The CGA actually handles addressing differently for text and graphics mode. Specifically, address line 12 off the CRTC chip is passed through some logic that, in graphics mode, sets A12 high if if the row address 0 line is high. This is how we get the 0x2000 offset in graphics memory for odd scanlines in CGA graphics modes. However the CGA treats the addresses produced by the CRTC as word addresses, so it's really 0x1000. And we shouldn't add 0x1000, it's an OR. So to calculate an address, instead of shifting and adding 0x2000 + offset and masking, we should OR, shift, add offset and then mask.

Area5150 worked, of course, because all of its scrolling is in text mode.

Regarding port mirrors, if I'm reading the schematic right, there should be another set of port mirrors due to incomplete decoding at 1D0 as well. I'll have to test this.

root42 wrote on 2023-06-13, 14:03:

Awesome project! Now if someone could fix area5150 so that it runs on my 286, that would be nice 😀 It runs pretty far, but crashes at some point late in the demo.

The 'Wibble' (Charlie Chaplin) and 'Lake' (End credits) effects will never run, unfortunately, as they are perfectly cycle-counted effects that will only run properly on an 8088. Even if they didn't crash, you'd just see spaghetti, if your monitor didn't refuse to sync at all.