A few days ago I had this short conversation with Trixter, and it seems that changes to 03D8 and 03D9 are instantaneous, making it possible to switch 640x200 mono and 320x200 4-color modes on the fly mid-screen. No DOS program ever used that, to my knowledge (I was triggered by this since Elite for the BBC uses the same trick on the BBC), but it would be cool to make a PoC. So the question is, does your CGA implementation handle this correctly (or, what we now think is correct, nobody tried it yet to my knowledge)?

JAL

jal wrote on 2023-12-20, 17:15:

A few days ago I had this short conversation with Trixter, and it seems that changes to 03D8 and 03D9 are instantaneous, making it possible to switch 640x200 mono and 320x200 4-color modes on the fly mid-screen. No DOS program ever used that, to my knowledge (I was triggered by this since Elite for the BBC uses the same trick on the BBC), but it would be cool to make a PoC. So the question is, does your CGA implementation handle this correctly (or, what we now think is correct, nobody tried it yet to my knowledge)?

JAL

With the caveat that I defer graphics/text mode and character clock changes to the next hsync after the mode is changed, it should basically work, at least in RGBI mode. I only update reenigne's composite parameters once per frame, so that might need tweaking.
As you probably know one effect in Area 5150 switches from 40 col text to 320x200 graphics and back, but that doesn't change the character clock. At one point I tried instant mode changes, but I was getting some black pixels in that effect. I should be able to use my logic analyzer rig to measure the mode change latency, if any. If you come up with a PoC let me know!

I will, thanks. Maybe I have some spare time over Christmas 😁.

Yes, it's been known that changes to the Mode/Color Select registers take effect immediately; making it otherwise would probably have complicated the CGA's design (additional latches?), to no benefit that I can think of. As GloriousCow points out, we relied on that in Area 5150 - at least one effect uses it to get a true split-screen mode, and there are others where it's less obvious (done more for the sake of abusing certain 'improper' bit combinations in 3D8h).

I've considered the idea of a mode 4 <-> 6 split-screen, but in a different context: using composite color, that would increase the number of artifact-color palettes you could exploit using mid-frame (or per-scanline) palette changes. But you could probably find a novel use for it in RGBI color as well... e.g. introducing certain color combinations that mode 4 wouldn't allow by itself (say 0 and 1, or 8 and 9). Would be interesting to see what you come up with!

@GloriousCow: if you manage to find out why instantaneous updates make those black pixels show up, I'd be curious to know. I mean, when you rewrite one of those registers, I expect that there's probably some kind of propagation and setup delay before the change is actually visible on screen, perhaps a handful of character clocks... but we were careful to lay out the frame structure so it allows for some uncertainty - those particular transitions should be seamless even if the updates were truly instantaneous. 😀

VileR wrote on 2023-12-21, 10:58:

@GloriousCow: if you manage to find out why instantaneous updates make those black pixels show up, I'd be curious to know. I mean, when you rewrite one of those registers, I expect that there's probably some kind of propagation and setup delay before the change is actually visible on screen, perhaps a handful of character clocks... but we were careful to lay out the frame structure so it allows for some uncertainty - those particular transitions should be seamless even if the updates were truly instantaneous. 😀

Yeah, I imagine there's some minor delay at least. But this was also before I improved my interrupt timings, so I haven't gone back and made them instant again to see if the black pixels come back. I'll put it on the ever-growing list of things to research...

Meanwhile, I'm still working hard to get all the features I wanted for 0.2.0 done. Next on the agenda was an improvement to the floppy browser.
Now you can specify multiple floppy source directories as part of the new resource definition system, and the floppy browser supports subdirectories. There will be an optional compile flag for native file browsers as well, but I'm keeping the little quick access menu as it's still more convenient.

Trying to run the latest from the version_0_2_0 branch, but it exits with the error: "MDA not implemented", despite me selecting CGA for a video device.

Am I being punished for my impatience?

Edit: never mind. Needed to remove the EGA config overlay. Works now.

keenmaster486 wrote on 2023-12-27, 17:00:

Trying to run the latest from the version_0_2_0 branch, but it exits with the error: "MDA not implemented", despite me selecting CGA for a video device.

Am I being punished for my impatience?

Edit: never mind. Needed to remove the EGA config overlay. Works now.

you found a fun match fallthrough bug! the EGA is conditionally compiled behind the 'ega' build feature. to get EGA you need to build cargo build -r -features=ega

it really shouldn't even let you specify an EGA card overlay if you haven't compiled with the ega feature, but apparently I do and then the bus dispatcher can't find a matching card. what's funny is MDA *is* implemented now, but i never changed the failure message when a card type isn't found.

Just bear in mind that a lot of stuff may be broken at any given point. MartyPC development is sort of chaotic at the moment.

GloriousCow wrote on 2023-12-27, 18:07:

you found a fun match fallthrough bug! the EGA is conditionally compiled behind the 'ega' build feature. to get EGA you need to build cargo build -r -features=ega

it really shouldn't even let you specify an EGA card overlay if you haven't compiled with the ega feature, but apparently I do and then the bus dispatcher can't find a matching card. what's funny is MDA *is* implemented now, but i never changed the failure message when a card type isn't found.

Just bear in mind that a lot of stuff may be broken at any given point. MartyPC development is sort of chaotic at the moment.

Nice.

I'm noticing some display issues with EGA, but I assume those are yet to be fixed since this is a WIP. Seems to work otherwise.

keenmaster486 wrote on 2023-12-28, 05:43:

I'm noticing some display issues with EGA, but I assume those are yet to be fixed since this is a WIP. Seems to work otherwise.

Yeah EGA is maybe, 65% done if I had to hazard a guess. I am debating whether I leave it compiled in for 0.2.0. I still have to finish MDA too.

This emulation stuff is a lot of work for one person...

If I may report a couple more issues I've seen, assuming you don't already know about them:

My machine:
i5-12400
RTX 3070 Ti
Linux Mint 21.2
Kernel 6.2

5150 won't boot from HDD (have to use 5160)
PC speaker seems stuttery
GUI window likes to stay on top of everything else unless I specifically minimize it

keenmaster486 wrote on 2023-12-28, 17:46:

5150 won't boot from HDD (have to use 5160)

known issue

keenmaster486 wrote on 2023-12-28, 17:46:

PC speaker seems stuttery

Could be audio library issues, or performance related. if you look at the performance window are you holding 60fps?

keenmaster486 wrote on 2023-12-28, 17:46:

GUI window likes to stay on top of everything else unless I specifically minimize it

and i assume you didn't set always_on_top in [[emulator.window]] ? What window manager are you using?

GloriousCow wrote on 2023-12-28, 19:13:

keenmaster486 wrote on 2023-12-28, 17:46:

PC speaker seems stuttery

Could be audio library issues, or performance related. if you look at the performance window are you holding 60fps?

It seems to be holdling between 53 and 55 fps.
Edit: it seems to be using all of one thread.

GloriousCow wrote on 2023-12-28, 19:13:

keenmaster486 wrote on 2023-12-28, 17:46:

GUI window likes to stay on top of everything else unless I specifically minimize it

and i assume you didn't set always_on_top in [[emulator.window]] ? What window manager are you using?

X with Cinnamon. Yep, always_on_top is off.

keenmaster486 wrote on 2023-12-28, 22:59:

It seems to be holdling between 53 and 55 fps.

that would do it. if the framerate isn't keeping 60fps, the audio buffer will eventually empty , and then it will wait until it has N samples before replaying again, then we will repeat... this will sound stuttery. A better way perhaps would be to dynamically resample based on current framerate, but i'd rather just fix why you can't get 60fps honestly. your hardware should be plenty fast enough...

EDIT: CGA is currently set for cycle-accuracy in the current build, that might do it. is EGA faster? would you mind opening a github issue so we can troubleshoot further there?

GloriousCow wrote on 2023-12-28, 23:10:

EDIT: CGA is currently set for cycle-accuracy in the current build, that might do it. is EGA faster? would you mind opening a github issue so we can troubleshoot further there?

Will do.

Nope, EGA is not faster.

Mistyped my CPU model. Fixed in my previous post. Doubt that changes anything though; it's a fast CPU.

I was hoping I'd get a release out this weekend, but it looks like Windows Defender is having a hissy fit over something in the latest builds, so I am going to need to get a code signing cert. Which, apparently, requires me to have a physical token delivered. Alas. Well, it gives me an excuse for a few more days of polishing.

Ok, I've finally managed to create a working example of both changing the colour (in 640 mode) mid-frame, and switching to 320 mode. One thing that I notice is that MartyPC, as opposed to a my NuXT with ATi Small Wonder, seems to apply changes per 8 lines or thereabouts, at least the jitter I get seems about a character high. On my NuXT it's max. 2 scan lines high, although changing from 640 to 320 mode mid-frame causes really weird artifacts on it. (I also wonder where the jitter comes from, if I count my cycles right they should be way inside the number of cycles I have available during horizontal retrace, but that's probably a discussion for a different thread.)

jal wrote on 2024-01-01, 14:12:

Ok, I've finally managed to create a working example of both changing the colour (in 640 mode) mid-frame, and switching to 320 mode. One thing that I notice is that MartyPC, as opposed to a my NuXT with ATi Small Wonder, seems to apply changes per 8 lines or thereabouts, at least the jitter I get seems about a character high. On my NuXT it's max. 2 scan lines high, although changing from 640 to 320 mode mid-frame causes really weird artifacts on it. (I also wonder where the jitter comes from, if I count my cycles right they should be way inside the number of cycles I have available during horizontal retrace, but that's probably a discussion for a different thread.)

can you share?

I hope I'm allowed to attach an EXE file, let's see... (Note the code is a bit Q&D, but the loop setting the colour should be fairly optimal.)

I got my code signing cert, but it hasn't stopped MartyPC from getting flagged as a virus by Defender/Smartscreen, which is just wonderful since I basically wasted $300. I haven't any idea what it is triggering on. I tried pulling out a crate that could make web requests (it was only used to make my github link clickable), but no dice.

I'm sort of stumped.

GloriousCow wrote on 2024-01-10, 14:23:

I'm sort of stumped.

Google 'site:github.com wacatac' and you'll see dozens of unfortunate developers dealing with this bullcrap from Microsoft at present.