Achieving period-correct graphics in personal computer emulators

[Rincewind]

The goal is accuracy without compromises - and you can learn a lot reading 270 pages long thread. For example - that cycle-accurate emulation of Sound Blaster is inherently slow - and machine speeds up a lot when it is replaced with emulated Gravis Ultrasound.

You can experience the same thing in DOSBox, but you might be missing something here: it's not slow *because* of the accurate SB emulation; it's slow because the mixing is done by the CPU. The GUS emulation just mixes the PCM samples from the "emulated GUS memory" directly, without putting load on the emulated CPU.

I'd even say accurate SB emulation is *less* expensive than accurate GUS emulation, overall, when you're only talking about emulating the soundcard itself.

Of course don't expect miracles - full speed cycle-accurate Pentium 1 emulation requires insanely fast PC.

Plus it's an utterly pointless exercise in futility, as we've discussed many times previously.

Any random PC isn't "cycle-level compatible" with any other random PC having a similar configuration. That's the whole point of the PC architecture that's it's a lot more flexible than a home computer or a console.

I don't see much value in emulating a *very specific* PC config in a cycle accurate manner when virtually 100% of all software is written in a manner *not* to exploit the obscure low-level timing details of any specific configuration. That would've been a surefire recipe to make your software/game work on *one* specific machine, then fail on 99% other PC configs out there...

And that's exactly what's happening with the Area 5150 and 8088 mph demos. They only work on a very specific setup. You use a different CGA card with a different chipset, suddenly half the demo breaks.

Having said that, emulating graphics cards and sound cards that games/demos used to bang directly is a necessity. But even that doesn't have to be literally cycle accurate, just good enough high-level emulation (same or very close output to for the same input combinations). That's the DOSBox approach; higher emulation accuracy where it matters, lower where it doesn't.

 

[Rincewind]

Btw, it's a fun exercise in DOSBox: you can run a GUS modplayer like CapaMod at full speed even at 800 cycles with no problem. The screen updates will be a bit sluggish, but the MOD file will play back 100% fine.

That's equivalent to a 8 MHz 286!

Then to listen to the same module in Multi Module Player with high-quality CPU mixing at 45 kHz with oversampling & antialiasing filters on an emulated Sound Blaster 16, you *need* about 150k cycles, which is fast 166 / 200 MHz Pentium MMX territory.

This is a huge difference, and one of the reasons why Sound Blasters were shit compared to the Amiga. The GUS and the AWE32 were the first cards that surpassed the Amiga's capabilities (and *far* surpassed them, in fact—they were great cards, but sadly criminally underutilised by games).

 

[Avonaeon]

As an alternative to PCem, you could try 86Box. On my mid-low end main rig (Ryzen 5 5600, RX6650XT, 32GB Ram) I got a 233Mhz/Voodoo 2 Win98se emulated machine working with minimal slowdown. Phil's Computer Lab did a good video on this recently:


I haven't messed with CRT shaders, but I've been following this thread and now I want to. It looks closer to how I remember games looking and thankfully, I do have some CRTs to compare to if I wanted. Is there something similar to ShaderGlass for linux?

 

[Rincewind]

Not sure if the situation has improved, but 86box was significantly worse than PCem whenever I tried it. Probably still true because I remember people complaining abut 86box vs PCem performance in December.

Basically, 86box is about 30% slower than PCem when emulating the exact same CPU, and the mouse pointer is choppy and jumpy as hell. That's a hard no for mouse-driven adventures, RPGs, strategy games, etc.

Anyway, just a heads up. Anyone who tries 86box should give PCem at least a go. Also, the 86box authors seem to be super into 80s PCs, but the more recent 90s/early 2000s stuff we care about in the context of Win95/98 emulation isn't a high priority for them, apparently. Just saying.

 

[Nutmeg]

and one of the reasons why Sound Blasters were shit compared to the Amiga

Another (alleged, I don't actually know) reason is that tracks were often composed using completely different LA synths, and then hastily arranged for the (admittedly gimped) OPL2.

In the right (usually Japanese) hands, the YM3812 could sing:

 

[Nutmeg]

So good. I love the YM3812. Legendary music chip.

 

[Rincewind]

Another (alleged, I don't actually know) reason is that tracks were often composed using completely different LA synths, and then hastily arranged for the (admittedly gimped) OPL2.

Yeah, that was common with Sierra games, for instance. Those were composed for the MT-32 by the main composer guy, then usually another guy did the OPL2 conversion. With varying results.

Games originally composed for the OPL2 can sound very good, though. Dark Seed, Alone in the Dark, I like those OPL soundtracks. And like you're saying, many of these Japanese games make glorious use of the sound chips.

But MIDI -> OPL conversions are usually a bit shit. Especially in mid-late-90s games where the conversion was done automatically by the driver. Ugh. That's utter rubbish.

Same deal for the DOS ports of most Amiga games. The Amiga music used custom samples, then the OPL and even MT-32 conversions were quite questionable in most cases. I'm actually putting together a comparison article featuring the music of such Amiga originals and their DOS ports to show people what they're missing...

 

[Nutmeg]

I'm actually putting together a comparison article featuring the music of such Amiga originals and their DOS ports to show people what they're missing

I am very much looking forward to this.

 

[solemgar]

So, here are some PCem screenshots as promised before by me.

PCem is pass-through-ing a USB cd-rom that contains a copy of Master of Orion 2 (original) and I could install it on a Windows 98 PCeM VM running a P2 450 MHz with 128 ram and a Voodoo 3 system. Pretty slick

Feels almost like the real thing!

I agree with Rincewind that you will never have the same experience 1to1 than with a real physical system, but for people like me that does not have physical space to put a huge CRT and an old PC tower, this is the next best thing. And from an engineering point-of-view is just amazing how far we had come in terms of vintage systems emulation.

For good performance, I would say a semi-modern CPU is required that gives at least 4.8 GHZ sustained speeds . The emulators are purely single threaded (except for vGPU emulation) since multi-core is a thing of more recent times. Also, helps if you have a CPU like modern Intel one to pin the process to the P-cores and not the E-cores. A lot.

Also agree again with Rincewind that pcem is still somewhat faster than 86box. 86box as far as I understood, strives more for accuracy. With 86box I can only run well a 300 P2 CPU and definitely is choppier. Still, it has a lot more active development. More screenshot with 86box provided, running good ol' Ishar

Vogons forums has a lot of good information, although if someone believes rpgcodex is full of elitist ... you will just feel right like home there :D

https://www.vogons.org/viewtopic.php?f=9&t=96688

 

[solemgar]

Anyone mess with this?

He sounds retarded. Retro Rigs don't "suck", he does. Nor do they require CDs. "Hurr they're loud". Aren't you a hardware expert who's supposed to be able to solve this? This zoomer content is brainrot inducing in real time.

PCem, last I tried it, couldn't emulate more than 133 Mhz on my high end cpu, so a lot if not most Win98 games are out the window. It's okay for early Win95 games.
I got DosBox-pure that runs Win98 and you can install 3Dfx drivers on it. I played through Fallout 1 like this through RA with CRT shaders, it was good. I haven't tried more demanding games.

What I'd ideally want is for either of those two programs to start emulating Sound Blaster Audigy. But it doesn't look like PCem had any major updates since 2021.

Linus videos are quite click-baity, take it with a pinch of salt all that he says there.

 

[Azdul]

Btw, it's a fun exercise in DOSBox: you can run a GUS modplayer like CapaMod at full speed even at 800 cycles with no problem. The screen updates will be a bit sluggish, but the MOD file will play back 100% fine.

That's equivalent to a 8 MHz 286!

Then to listen to the same module in Multi Module Player with high-quality CPU mixing at 45 kHz with oversampling & antialiasing filters on an emulated Sound Blaster 16, you *need* about 150k cycles, which is fast 166 / 200 MHz Pentium MMX territory.

This is a huge difference, and one of the reasons why Sound Blasters were shit compared to the Amiga. The GUS and the AWE32 were the first cards that surpassed the Amiga's capabilities (and *far* surpassed them, in fact—they were great cards, but sadly criminally underutilised by games).

CPU mixing was also used on Amiga. When you listen closely to Chris Hülsbeck's Turrican 2 intro - quality of sound goes down as more things appear on the screen.

Gravis itself was unable to write good Windows driver for Ultrasound - so it's hard to expect game developers will write good GUS driver for their game. Unless they've composed their music in Sound Tracker anyway - and all they needed was Amiga with 16-bit sound and more than 4 hardware channels - which they've never got from Commodore .

AWE32 was released in 1994 - and by that time there was an option of CD audio. Moreover - CPUs were already so powerful that you could just send bytes through two printer ports - and get 8-bit stereo sound in 22kHz for the cost of 36 resistors.

 

[Rincewind]

Azdul Yeah, CPU mixing was used a litlle bit on the Amiga, but it was rare. Future Composer did realtime synth tone generation instead of PCM samples, that was used at least in some cracktros where size was a consideration. But that's not CPU mixing, actually There was Oktalyzer and probably a few other trackers that supported 8 channels, but the quality wasn't great.

Dunno about Windows GUS drivers. When everbody just needed a stereo 16 bit/44kHz PCM stream in Windows, Gravis has already lost.

But the original GUS came out in 1992 and it *was* well documented and it was a joy to program. Gravis literally gave the cards away to prominent demoscene groups, attended and supported demoscene events, etc. The scene guys loved the card, and the well-written and free SDK played a great role in that.

32 hardware channels at 44.1 kHz (ok, only until 14 channels on GUS Classic) and a dedicated 512 KB sample RAM (expandable to 1 MB) was a dream come true coming from the Amiga. Good output quality too. SB boards were horibble noisy pieces of utter garbage until the AWE32. Maybe there are some SB16 revisions that don't sound like garbage, dunno. Some of my friends who were into tracker music on the PC used Creative cards, and I was apalled at the analog output quality of those boards, and CPU mixing sounded like dogshit too even on early Pentiums compared to the linear sample interpolation done in hardware by the GUS.

I think I would have hated the PC like the plague after the Amiga if I did not have a GUS I still hated many things (no hardware mouse cursor, blocky looking low-res graphics on VGA, no multitasking in pure DOS, etc.)

The problem was the GUS did not have great SB compatibility, partly due to Creative intentionally obfuscating things and not releasing proper documentation. But the bigger issue was the Creative cards were already entrenched in the market and Creative's ultra-aggressive, deceptive marketing stunts worked like clockwork with the normies.

So the GUS became a demoscene standard, but not a gaming standard. I spent most time on my PC between 1995-1999 in FastTracker II, hence I missed most of the classic DOS games The Roland MIDI emulation of the GUS was also very respectable; I played some DOS games with Roland MIDI sound on my 1 MB red GUS Classic.

 

[solemgar]

I still have a vague memory of listening the heroes 2 soundtrack on the gravis ultrasound and feeling the music was even better then the CD version. I never could hear that soundtrack again in a a gravis. Wonder if I ever dreamed it

 

[Rincewind]

I still have a vague memory of listening the heroes 2 soundtrack on the gravis ultrasound and feeling the music was even better then the CD version. I never could hear that soundtrack again in a a gravis. Wonder if I ever dreamed it

You can do so in DOSBox Staging again Our GUS emulation is very accurate. I've even implemented the mixer rate lowering quirk of the GUS Classic when using more than 14 channels; it adds a certain character.

 

[Rincewind]

Bester Quick tip: enable "Performance mode" in ReShade, this makes a big difference with Lagless VSync. I will mention this in my updated Amiga shader article, very important step.

 

[Azdul]

32 hardware channels at 44.1 kHz (ok, only until 14 channels on GUS Classic) and a dedicated 512 KB sample RAM (expandable to 1 MB) was a dream come true coming from the Amiga. Good output quality too. SB boards were horibble noisy pieces of utter garbage until the AWE32.

512 kB sample RAM was a demoscene standard - but Gravis sold a lot of cards with 256 kB. As always - demoscene does not care about ignorant cheapskates that had not expanded their base model - but game developers have to.

Compare that to AWE32 - which had 512 kB as standard - plus 1 MB of E-mu ROM samples. Suddenly - all nasty tricks that GUS did to fit / swap on-the-fly 6.5 MB of soundfonts / samples from HDD into 256 kB / 512 kB on-board RAM are not necessary. It is possible to write stable Windows driver - and the DOS General MIDI music works fine. Reverb, echo and chorus are added in hardware by E-mu DSP - not by software.

For musicians - AWE32 continues tradition of being Creative horrible noisy piece of utter garbage . But - beautiful, clear sound is available on one of E-mu DSP chip pins - so with few hardware hacks AWE32 can sound good.

And AWE32 offers Roland MT-32 emulation. Little clunky - but probably better than GUS emulation of Sound Blaster.

In my opinion what ultimately killed GUS was not AWE32 - but its inability to behave well in Windows 3.1 protected mode. Sound cards contemporary to GUS were finally killed by arrival of Windows Vista.

 

[Rincewind]

512 kB sample RAM was a demoscene standard - but Gravis sold a lot of cards with 256 kB. As always - demoscene does not care about ignorant cheapskates that had not expanded their base model - but game developers have to.

Maybe mine came with 256 KB then. It must have if that was the factory default; can't remember. But then I upgraded to 1 MB, I'm sure of that because my XM files all have 1 MB of sample data

EDIT: No, I had the GUS MAX, not the Classic. The MAX came with 512 KB of RAM and the 16-bit sampling feature built-in. I used that a lot to sample my guitars

For musicians - AWE32 continues tradition of being Creative horrible noisy piece of utter garbage . But - beautiful, clear sound is available on one of E-mu DSP chip pins - so with few hardware hacks AWE32 can sound good.

Hmm, my AWE32 CT3900 I bought last year is not too noisy. I mean there's background noise, but it's a lot better than earlier SB models. I have an ESS AudioDrive 1868 too which is a lot quieter than any SB and ESFM (their own non-licensed OPL clone) sounds great too.

Not sure about that digital out hack, my model has an SPDIF connector on the board. I just need some breakout bracket for it. Maybe it wasn't available on the budget models.

My main goal for 2024 is to add AWE32 emulation to Staging, that's why I bought it. Had a look at PCem's AWE32 emulation, but it's questionable, so I'll reverse engineer it myself from zero.

 

[solemgar]

I still have a vague memory of listening the heroes 2 soundtrack on the gravis ultrasound and feeling the music was even better then the CD version. I never could hear that soundtrack again in a a gravis. Wonder if I ever dreamed it

You can do so in DOSBox Staging again Our GUS emulation is very accurate. I've even implemented the mixer rate lowering quirk of the GUS Classic when using more than 14 channels; it adds a certain character.

Oh I didn't know you were a contributor to dosbox staging! Amazing project I tried it for a while but sadly unreal didn't work on W98 / voodoo emulation so I forgot about it. Now you gave me another reason to go back to it

 

[Rincewind]

I still have a vague memory of listening the heroes 2 soundtrack on the gravis ultrasound and feeling the music was even better then the CD version. I never could hear that soundtrack again in a a gravis. Wonder if I ever dreamed it

You can do so in DOSBox Staging again Our GUS emulation is very accurate. I've even implemented the mixer rate lowering quirk of the GUS Classic when using more than 14 channels; it adds a certain character.

Oh I didn't know you were a contributor to dosbox staging! Amazing project I tried it for a while but sadly unreal didn't work on W98 / voodoo emulation so I forgot about it. Now you gave me another reason to go back to it

Yeah, current project lead, actually

Emulating Win9x is not among the project's goals, but Win 3.11 is. I guess many Win9x apps work by fluke, but we don't actively test it.

 

[solemgar]

I still have a vague memory of listening the heroes 2 soundtrack on the gravis ultrasound and feeling the music was even better then the CD version. I never could hear that soundtrack again in a a gravis. Wonder if I ever dreamed it

You can do so in DOSBox Staging again Our GUS emulation is very accurate. I've even implemented the mixer rate lowering quirk of the GUS Classic when using more than 14 channels; it adds a certain character.

Oh I didn't know you were a contributor to dosbox staging! Amazing project I tried it for a while but sadly unreal didn't work on W98 / voodoo emulation so I forgot about it. Now you gave me another reason to go back to it

Yeah, current project lead, actually

Emulating Win9x is not among the project's goals, but Win 3.11 is. I guess many Win9x apps work by fluke, but we don't actively test it.

Nice to meet you , always happy to interact with people who work on open-source projects :D
I mixed dosbox-x with dosbox staging, my bad :D , the number of forks is becoming increasingly alarming , I am trying dosbox staging right now. Will let you know when I set up Heroes 2 with GUS

 

[solemgar]

Rincewind

 

[deama]

Ok so I went ahead and created my own python script this time, without ffmpeg, it's much faster, though I didn't bother implementing the curviture stuff, just the scanlines, phospher, blur, bloom, and gamma.
I wasn't sure on the values, I can always tweak it, so some crituque would be nice.

Original:

ffmpeg version I used:

my python one:

I think it turned out pretty good, it's blurrier, but it blends everything nicely. I've also slightly dimmed it compared to the ffmpeg one cause I thought it was maybe a bit too much, but not sure.

Rincewind

It's much quicker at least, so you can actually use it for converting movies I bet, I'll give it a go.

I think the ffmpeg one also has that blur/blend value as well that I may have disabled, but the config is a bit confusing, at least for what I want.

 

[Rincewind]

deama It's nice. My personal preference would be to dial back the blur by about 50%. But it depends on what you want to emulate. The ffmpeg variant is closer to how a non-shity quality PC VGA monitor looks. Yours is closer to a Commodore/arcade monitor with the blur.

What I'm missing is the phosphor overlay / slotmask pass. That would go nicely with your version. But then, the extra detail can cause problems with video compressors.

 

[deama]

deama It's nice. My personal preference would be to dial back the blur by about 50%. But it depends on what you want to emulate. The ffmpeg variant is closer to how a non-shity quality PC VGA monitor looks. Yours is closer to a Commodore/arcade monitor with the blur.

What I'm missing is the phosphor overlay / slotmask pass. That would go nicely with your version. But then, the extra detail can cause problems with video compressors.

The phosphor overlay is that mask thing right?

• Shadowmask:
  The image of the phosphor overlay is taken from the respective .png file, scaled down by the specified OVL_SCALE factor (w/gamma correction before and after!), then tiled and cropped to fill the 'screen'. This also gets the anti-moiré curvature treatment with 4x oversampling, and is saved as a temporary image.

I played with it with the ffmpeg version but never liked it, is it like a big requirement for the CRT look?

 

[deama]

Ok so I made it work with videos and .gifs too now:
Sadly wasn't able to figure out an easy way to keep them RGBA, so it'll remove the transparency.

original:

new:

Here's the link if anyone is interested:
https://drive.google.com/file/d/1x7WcRZQFDuoDg_0q0XhGpvjWvgdeOLCo/view?usp=sharing

You can tweak the values in the scanlines.py at the end.

There's a req.txt for the packages to be installed, and you'll also need ffmpeg installed for video stuff.

So far it only works on 1 thread, so if the video stuff is still too slow, you could probably speed it up a lot by doing multithreading.