Oh, I meant to ask - there's currently no way to hit enter on mobile to start 8088MPH. Is there any secret sauce to skipping the calibration screen?

edit: Or a way to select the effect to play in Area 5150? I have just been patching the script list to make executables that start at a specific effect.

GloriousCow wrote on 2023-07-05, 10:55:

I have to confess I'm a little out of my depth with this stuff - GPU programming especially is something I've only really dabbled in thus far, and only via an abstraction layer (wgpu). I couldn't tell you the difference between DX12 and DX11 other than DX12 is one higher. I'm sort of relying on the wgpu developers to be much smarter than me, hopefully. I can see if I can find time to look into it, if DX11 should work but doesn't maybe I can open an issue or at least ask around.

I write DX code for a living, but am not familiar with Vulkan or wgpu (or Rust for that matter).
So I'm not sure how exactly they chose to implement their multi-API interface... must be some kind of abstraction layer (DX11 and DX12 are vastly different APIs, almost as different as OpenGL vs Vulkan. Each API version is implemented in its own isolated objects, DX12 does not inherit from DX11). Which might mean that the abstraction is leaking somewhere (Joel Spolsky, we meet again), and something may need to be set up in a specific way for DX11 to work.
At least theoretically there should be no reason why this wouldn't work in DX11. From what I understand, it mainly uses the graphics API to do hardware-accelerated stretching and blitting to the screen.
Even a full composite shader should comfortably fit within the capabilities of DX11 hardware.

So far I found that it uses "WGSL" as a shader language, which is aimed at 'webgpu': https://www.w3.org/TR/WGSL/
And according to this tutorial: https://sotrh.github.io/learn-wgpu/beginner/t … -pipeline/#wgsl

WGSL's development focuses on getting it to easily convert into the shader language corresponding to the backend; for example, SPIR-V for Vulkan, MSL for Metal, HLSL for DX12, and GLSL for OpenGL.

Notably absent from that list, as I suspected, is DX11.
So perhaps using shaders in DX11 mode requires some tweaking to the toolset to make it compatible.
The tutorial doesn't seem to go into any details for DX11 specifically.
It does mention that the shaders are translated by a tool called 'naga': https://github.com/gfx-rs/naga
And that tool claims it can support HLSL for DX11.
So it may be a case of just getting the naga configuration correct, my guess would be setting the target profiles for vertex and fragment shaders correctly (version 5.0 for true DX11 hardware (vs_5_0 and ps_5_0 respectively), but lower may also be possible... 4.0 for DX10, and 2.0 or 3.0 for DX9 downlevel support).
By the looks of it, 5.0 is as low as naga will go: https://docs.rs/naga/0.12.1/naga/back/hlsl/index.html

Here's my blogpost about MartyPC. I digress as usual, but I thought I'd bring up some more examples (games from the old days) that other emulators don't really deal with 100%, but this one does.

This also raised the question: what are your thoughts about adding joystick support via keymapping of some kind, perhaps by way of emulating the IBM Game Adapter? One of the games in my post (Lost Tomb) doesn't support anything but the joystick, and there are others like that.
In fact you can't even start the game using the keyboard... I had to hack up a fake 'save state' in DOSBox and load it up in MartyPC just to get that footage. 😉

GloriousCow wrote on 2023-07-05, 10:33:

Of course! The new composite code will have controls for new/old style as well as phase offset, which I think is an interesting feature. Turns out there have been some programs written for composite using a modern scan-converter or LCD monitor, which don't seem to care about the missing color burst in 80 column mode. I guess period-accurate CRTs are getting rare. This ends up "working" on hardware but not displaying right under emulation. Now MartyPC can properly display such programs.

wrong_phase.png

Interesting- but does this really differ from the effects of the hue adjustment? The way I understand it, if the colorburst happens to be missing (or truncated), a decoder could theoretically take a wild guess and decide on an essentially random phase and amplitude for the color carrier, but all it would add up to is hue and saturation errors... unless I'm not getting what I'm looking at here.

GloriousCow wrote on 2023-07-05, 10:33:

That was a deliberate decision, I would just need to select a bilinear sampler in the shader instead. I like the 'crispness' of nearest neighbor vs bilinear personally, although the repeated scanlines are a negative. The desktop version tries to get the best of both worlds by doing linear interpretation on the Y axis but nearest-neighbor on the X axis, but I do this in software which is too slow for the web.

I can play around with it. Maybe it could be an option somehow and I could store it in a cookie (Hello GDPR cookie prompt...) to save your preferences.

Oh, didn't realize the web player was doing any X-axis scaling - I thought that was 1:1... if only Y was being corrected (or only X) I guess it'd be easier.

GloriousCow wrote on 2023-07-05, 11:12:

Oh, I meant to ask - there's currently no way to hit enter on mobile to start 8088MPH. Is there any secret sauce to skipping the calibration screen?

edit: Or a way to select the effect to play in Area 5150? I have just been patching the script list to make executables that start at a specific effect.

8088 MPH calibration screen - not that I know of, but I guess it could be patched. Or if it's easier, maybe an ad-hoc kludge on the player side, so that a click/tap event sends an Enter keystroke?

As for Area 5150, not currently I'm afraid... of course when we release the source with the final version, you'll be able to play with the script every which way 😀

VileR wrote on 2023-07-05, 16:09:

Here's my blogpost about MartyPC. I digress as usual, but I thought I'd bring up some more examples (games from the old days) that other emulators don't really deal with 100%, but this one does.

This also raised the question: what are your thoughts about adding joystick support via keymapping of some kind, perhaps by way of emulating the IBM Game Adapter? One of the games in my post (Lost Tomb) doesn't support anything but the joystick, and there are others like that.
In fact you can't even start the game using the keyboard... I had to hack up a fake 'save state' in DOSBox and load it up in MartyPC just to get that footage. 😉

Thank you, for the lovely blog post - you tested some things I never even did 😀 I've been so laser-focused on 8088MPH and Area5150 that everything else that works in MartyPC is almost just a side-effect of that work, so I've wondered about what other compatibility issues I might have (Maniac Mansion Enhanced won't run, for one... still investigating that one).

I've got to say considering how much time I've spent on your blog, it's a bit unreal to see a blog post up there about my own project.

I've definitely thought about joystick support. That's something that SDL of course provides if I decide to make an SDL front-end, but my current conglomeration of rust libraries doesn't handle. Looks like there's at least one library for joysticks/gamepads (https://crates.io/crates/stick) I might be able to use. I need to get a game adapter assuming my little collection of expansion cards doesn't have one. Is that a game port on this QuadBoard? Got a recommendation for a good-for-the-era joystick? The one I had back in the day was Not Great.

VileR wrote on 2023-07-05, 16:09:

Interesting- but does this really differ from the effects of the hue adjustment? The way I understand it, if the colorburst happens to be missing (or truncated), a decoder could theoretically take a wild guess and decide on an essentially random phase and amplitude for the color carrier, but all it would add up to is hue and saturation errors... unless I'm not getting what I'm looking at here.

You can roll the hue through 360 degrees and nothing looks quite right. Somehow a phase adjustment is intrinsically different, but I haven't worked out the math as to why.

VileR wrote on 2023-07-05, 16:09:

8088 MPH calibration screen - not that I know of, but I guess it could be patched. Or if it's easier, maybe an ad-hoc kludge on the player side, so that a click/tap event sends an Enter keystroke?

The tricky bit is that extra keystrokes seem to hang around and end up causing the Delorean and the polygon scenes to terminate early. Still need to debug that. I think (if you'll forgive me) i'll just patch it out and disable the keyboard on that demo specifically until I know what's causing it.

VileR wrote on 2023-07-05, 16:09:

As for Area 5150, not currently I'm afraid... of course when we release the source with the final version, you'll be able to play with the script every which way 😀

Source code?? Oh heavens, yes please. If I could have bribed you for that 3 months ago.... 😁

GloriousCow wrote on 2023-07-05, 17:42:

Got a recommendation for a good-for-the-era joystick? The one I had back in the day was Not Great.

The Gravis Analog (Pro) is one of the better classic analog 15-pin sticks, I'd say.

^I remember it. There's a transparent version, too. ^^

PS: I like the Keen reference (sticker). The Gravis gamepad was supported in later Keen releases.
Back in the 90s, my daily driver was an ancient Apple II era joystick by CH (beige, boxy).
Very retro, but not so good ergonomics/usability. More like a mouse replacement.
Edited, typo fixed.

Joysticks were never really my thing on the PC; I don't even have one for my daily driver - for joystick games in DOSBox I just use the keymapper to map host keystrokes to emulated joystick events. As far as I know that's also SDL functionality, but may be easier to implement without it... say using the cursor keys, since they seem to be free currently.

The joystick I use on the XT looks exactly like this - seems like it was also sold as 'Magic 909', and maybe other similarly imaginative brandings:

IIRC Quadboards do have a game port- I just use the SBPro 2.0's built in one.

GloriousCow wrote on 2023-07-05, 17:42:

You can roll the hue through 360 degrees and nothing looks quite right. Somehow a phase adjustment is intrinsically different, but I haven't worked out the math as to why.

Hm, weird but intriguing... maybe reenigne would be interested in making sense of it. The whole thing about using a 'random' phase/amplitude to fix a missing color burst reminds me of this - that's from before my time, but it was actually a thing in my country: https://en.wikipedia.org/wiki/Color_kil ... _(Mehikon)

"clients had to adjust the knob every 15 minutes on average in normal conditions, or up to 10 times an hour when special problems occurred". 🤣

GloriousCow wrote on 2023-07-05, 17:42:

The tricky bit is that extra keystrokes seem to hang around and end up causing the Delorean and the polygon scenes to terminate early. Still need to debug that. I think (if you'll forgive me) i'll just patch it out and disable the keyboard on that demo specifically until I know what's causing it.

'Extra keystrokes hanging around and then sneaking up on you' sounds like it may have to do with the PIC's Auto-EOI mode, since I've seen that behavior on the real hardware. But the Delorean and polygon parts are Scali's - perhaps he can say what's up with that?

VileR wrote on 2023-07-06, 06:23:

'Extra keystrokes hanging around and then sneaking up on you' sounds like it may have to do with the PIC's Auto-EOI mode, since I've seen that behavior on the real hardware. But the Delorean and polygon parts are Scali's - perhaps he can say what's up with that?

I don't think 8088 MPH uses auto-EOI mode anywhere, at least not in my parts.
What I think happens is that I developed my parts as standalone, and my standard boilerplate code always has a 'press key to exit' option.
I guess I never removed that code, so you can still end those parts with a keypress.
It may be the case that no other part before it does anything with the keyboard, so if you press extra keys at the calibration stage, or perhaps during some of the other parts, they get stored in the keyboard buffer, and stay there until you reach my parts, where it starts processing the keyboard input.

MartyPC v0.1.3 is out.

This includes a fix for an upstream keyboard bug and includes reenigne's superior composite color code, with a few new composite adjustments.
https://github.com/dbalsom/martypc/releases/tag/0.1.3

Question -- does your emulator have capability to optionally accurately emulate CGA snow?

Would be great for visually debugging demos, so they don't create CGA snow on real machines! Also to show other people computer history, about how early computers glitched.

mdrejhon wrote on 2023-07-08, 00:49:

Question -- does your emulator have capability to optionally accurately emulate CGA snow?

I don't have snow emulation yet. But I think MartyPC is uniquely suited for accurate snow emulation; being that I tick the CGA on character clocks in the worst case. This means I have immediate access to what the CPU wrote to the CGA on the very next tick of the CGA.

We have an accurate description of what snow is based on PCRetroTech's work, based on this excellent video: https://www.youtube.com/watch?v=IQ2UeIx1qIA&t=2127s
If these assumptions are correct:
- The attribute of snow is the byte on the bus being written by the CPU
- The character value of the snow is the value of the byte being overwritten by the CPU

So for snow, in my MMIO CGA write, I think all I need to do is save the last written byte and address, then when ticking the CRTC, if we resolve that particular address, provide the last byte written as the attribute. There may be a bit more to it, I'm not quite sure the interaction that the wait states will have, but I think in general it should work. I'll give it a shot this weekend.

We have snow!

I think the effect of the CGA wait states will cut out about half of this, need to do some testing with PCRetroTech's 'frozen snow' method.

You know, just musing here, but since perfect frame control has been demonstrated by reenigne several times - could you draw a recognizable image on the screen just with snow? Talk about an emulator-breaker...

EDIT: Area 5150 remains free of snow. My snowflake counter ticks up during the plasma effect in 8088MPH but I don't really see anything noticable...

GloriousCow wrote on 2023-07-08, 16:10:

EDIT: Area 5150 remains free of snow. My snowflake counter ticks up during the plasma effect in 8088MPH but I don't really see anything noticeable...

The plasma effect is specifically designed to avoid snow. That is, it only writes to the screen when the display is inactive.
So the 'snow' you would have, is hidden between the visible scanlines.
Ironically the PC does not always boot up in the same phase, so depending on the power cycle, it may be visible.
Our party capture showed a visible column of snow, as it was shifted to the right a bit, because of the phase mismatch.
Aside from that there may be a few glitches of snow on the first scanline or so.

Scali wrote on 2023-07-08, 17:18:

The plasma effect is specifically designed to avoid snow. That is, it only writes to the screen when the display is inactive.
So the 'snow' you would have, is hidden between the visible scanlines.

I guess i should only increment my snowflake counter during display enable.

Scali wrote on 2023-07-08, 17:18:

Ironically the PC does not always boot up in the same phase, so depending on the power cycle, it may be visible.

You're talking about different relative phases between the CPU and CGA (and PIT, i suppose?)
would that be something useful to emulate? it wouldn't be too difficult.

It looks like both reads and writes generate snow. I think I have the write-snow correct, but there are green attribute bytes on real hardware that I'm not seeing. Based on what PCRetrotech stated,

- The attribute of snow is the byte on the bus being written by the CPU
- The character value of the snow is the value of the byte being overwritten by the CPU

But i'm not sure if this logic holds for reads. Obviously in the case of a read from VRAM, nothing is being overwritten, so where does the character value come from?

GloriousCow wrote on 2023-07-08, 17:29:

I guess i should only increment my snowflake counter during display enable.

Yes, the snow is only there when the video circuit reads VRAM, which it only does when the display is enabled.

GloriousCow wrote on 2023-07-08, 17:29:

You're talking about different relative phases between the CPU and CGA (and PIT, i suppose?)
would that be something useful to emulate? it wouldn't be too difficult.

Yes.
I think it may be useful for debugging. As you see, the plasma effect does not avoid snow in all cases. But on real hardware you cannot influence the phase as far as I know.
So you have to keep powercycling to get all possibilities (I believe there were 4), and test that your code works in each one.
If you can just set your emulator to each of the possibilites, it makes testing easier.

Scali wrote on 2023-07-08, 19:13:

So you have to keep powercycling to get all possibilities (I believe there were 4), and test that your code works in each one.
If you can just set your emulator to each of the possibilites, it makes testing easier.

4 phases would make sense if we're talking about the CPU vs PIT, since 1 PIT tick is 4 CPU cycles.
I added a simple pit phase offset config variable. it functions as a temporary offset to the system tick accumulator for the PIT, and valid values are 0-3. It's applied at machine start and restart, but i could theoretically allow you to 'nudge' the PIT off phase at any time. But i wasn't able to get snow in the plasma effect.

Currently the snow is not cycle-accurate as to when it is drawn on screen, so i think it may be there but shifted too far to the left to be visible. Marty fast-forwards the CGA to match the cycle state of T3 when IO occurs, because CRTC updates have to be very precise for Area 5150, but it does not do the same for MMIO. There's no reason it can't (other than performance) but the forwarding logic is a bit more complicated there as there could be up to 4 bus operations per instruction, so we may have to update the CGA multiple times per instruction (!) or figure out a better optimization there, like maybe keeping a 4-element table of snow data for each of the possible bus operations and calculating it after the fact. I'll keep working on it, I imagine cycle-accurate snow emulation would be a great benefit when you're trying to program software that avoids it...

GloriousCow wrote on 2023-07-05, 17:42:

You can roll the hue through 360 degrees and nothing looks quite right. Somehow a phase adjustment is intrinsically different, but I haven't worked out the math as to why.

I think I get it, now that I've had a look at v0.1.3. I must've misconstrued which part of the signal processing chain this applied to.

As far as I can tell, what this adjusts is the phase between the dot output and the color carrier... i.e. it's done at the emulated CGA side of things, not at the emulated NTSC decoder. Since the adjustment is at 90-degree increments, it basically shifts the pixel output by 0..3 hdots with respect to the carrier/burst. That makes artifact colors change their hue, which is determined by the pixel's phase w.r.t. the carrier cycle - but the solid/direct colors are unaffected, since the CGA sets their chroma phase relative to that same carrier waveform. A hue control (as on an NTSC TV) changes the phase of the decoded color relative to the burst, so all colors are affected.

So whatever those modern composite programs are doing, I assume it's not because they're targeting some weird type of monitor/converter, but rather because they were tested on non-IBM CGA cards - on a typical clone CGA that 'baked-in' pixel/burst phase is different from IBM's... which is why they don't play nice with 8088 MPH, or with most composite CGA games really. 😀

If you've seen Planet X3, that game has a neat little hack to support some cards like that in composite mode: you can set that 0..3-dot shift yourself, and it modifies its artifact pixel patterns accordingly. That also works for the PCjr and Tandy 1000, which happen to have 90-degree-increment shifts (relative to the IBM CGA) in mode 6.

VileR wrote on 2023-07-09, 21:43:

That also works for the PCjr and Tandy 1000, which happen to have 90-degree-increment shifts (relative to the IBM CGA) in mode 6.

Is that all that is needed? I would have thought there would be some differences in the multiplexer, too...

GloriousCow wrote on 2023-07-09, 22:01:

VileR wrote on 2023-07-09, 21:43:

That also works for the PCjr and Tandy 1000, which happen to have 90-degree-increment shifts (relative to the IBM CGA) in mode 6.

Is that all that is needed? I would have thought there would be some differences in the multiplexer, too...

There could very well be - to get that figured out, we'd need to sample the same dataset from those machines as reenigne got from the CGA. But mode 6 games typically use either white or gray as the foreground color, so no 'true' chroma is encoded (all color is purely from artifacting - like the Apple II); even if the chroma multiplexer behaves differently, that doesn't come into play. So in this specific case, it'll be 'close enough'... IIRC Sierra also did this in Frogger II, where the dot patterns are shifted 90 degrees between the CGA and PCjr versions.