The C64 is so popular for demos. It's nice to see people push the IBM PC because it's not taken too seriously in the demo scene from what I've seen. I liked the full-motion video demo that someone did a few years ago.

idspispopd wrote:

The 1024 colour stuff is also great, but in a different way (less about coding, more artistically and exploiting the limited CGA hardware).

The 1024 colours also required clever code to trick the CRTC into displaying that many colours. It starts a new frame every 2 scanlines.
So you are technically not looking at a single frame with 200 scanlines, but at 100 frames with 2 scanlines.
I think this is actually the most groundbreaking code, an approach of coding that has never been done before on this platform. Sprite compilers and mod players with self-modifying code have been done before.

idspispopd wrote:

It's just a pity that you had to limit yourself to such a specific PC platform, there are probably more C64 today than PC's that could run this demo properly. But I understand why you had to do that.

Well, the C64 is the most sold computer of all time. As the saying goes, there's a C64 in every closet.
There are many more C64s out there than IBM PC's.
Then again, it's not THAT grim. You have the IBM 5150, 5155 and 5160 on which the demo is guaranteed to work (final version will also fix the problems with cards with non-Motorola 6845s losing sync).
And there are various clones that are close enough that they can run the whole demo.
Even a Tandy 1000 can run the demo, with just a few issues here and there: https://youtu.be/rAUM89Xu7jo

One of my clones is a Philips P3105, and when you install a real IBM old style CGA card in it, it runs the demo 100% the same as a real IBM.
With the ATi Small Wonder CGA clone that came with the machine, the demo runs, and only has two issues really: Kefrens bars don't look exactly as intended, and the colours are off.
There may even be CGA clones that are 100% identical.

HunterZ wrote:

I liked the full-motion video demo that someone did a few years ago.

That was 8088 Domination by Trixter (MobyGamer): http://www.pouet.net/prod.php?which=63591
And 8088 Corruption before that (also Trixter): http://www.pouet.net/prod.php?which=13722

Trixter was also the initiator of this project, and in a way, 8088 MPH is the successor to these demos.

Hornet, CRTC and DESiRE are pleased to announce a final version of 8088 MPH which can be downloaded at http://www.reenigne.org/8088MPH_final.ZIP . Also a capture of the final version can be seen and heard at https://www.youtube.com/watch?v=hNRO7lno_DM . This final version has some new graphics, minor bug fixes and compatibility improvements, but it still breaks all your emulators.

For those who are interested, I tried to sum all all the changes we made for the final version, explaining some of the technical background behind some of the glitches and incompatibilites: https://scalibq.wordpress.com/2015/08/02/8088 … -final-version/

The song at the end is still much quieter than the preceding music, although it's understandable (and still sounds amazing).

I spotted a greet from reenigne to the SRCS in the end credits. I should really check SRCS out sometime since I live in the area (although almost an hour away); I probably don't have anything exciting to bring myself, though, except for a modest collection of early '90s video/audio cards and MS-DOS 1.x disk+manual in the original pink binder (but no sleeve).

HunterZ wrote:

The song at the end is still much quieter than the preceding music, although it's understandable (and still sounds amazing).

Yes, it's just a result of the signal that is produced. The PC speaker has no volume control, it either on or off.
With the regular music, you just let the PC speaker turn itself on and off at a given frequency for each note you play, creating a square wave signal. So on average it is always enabled for 50% of the time, which is perceived as 'loud'.

For the sample playback, a pulse-width-modulation technique is used, which works in a different way.
For a given 'carrier frequency' (sample rate), in our case ~16 KHz, you vary the volume of each sample by its duty cycle. So softer samples are played by enabling the speaker for a shorter time.

This means that the speaker is not enabled 50% of the time on average, but it depends on the music. In theory you could have PWM-based 'music' (well, at least sound, it may not necessarily sound musical) that sounds as loud as regular PC music, but in practice, such music tends to have more dynamic range, so it turns out softer, especially this rather mellow end-tune. Which is somewhat ironic... Early sound chips tend not to be very subtle in the way of dynamics and such, so people tend to perceive music from SID, POKEY etc as 'loud' and 'busy'.

In theory we could put some kind of 'loudness mapping' on it, by remapping the samples to an exponential curve rather than a linear one. But it would take some extra CPU cycles, which means the carrier frequency will be lower, which means it will be more audible (16 KHz is just about at the limit of the hearing of an adult person).

So yes, loudness wars on 1981 hardware 😀

HunterZ wrote:

I spotted a greet from reenigne to the SRCS in the end credits. I should really check SRCS out sometime since I live in the area (although almost an hour away); I probably don't have anything exciting to bring myself, though, except for a modest collection of early '90s video/audio cards and MS-DOS 1.x disk+manual in the original pink binder (but no sleeve).

Unfortunately you probably won't meet me there - I moved to the UK about 3 years ago. I definitely recommend checking it out, though - they're a great bunch of people. No need to bring anything, it's fine to just come and chat and play with the toys others have brought.

Scali wrote:

In theory we could put some kind of 'loudness mapping' on it, by remapping the samples to an exponential curve rather than a linear one. But it would take some extra CPU cycles, which means the carrier frequency will be lower, which means it will be more audible (16 KHz is just about at the limit of the hearing of an adult person).

You could avoid the overhead by precalculating the sample waveform values with loudness mapping so you don't have to do it at runtime in the playing/mixing routine.

However, I don't know if preprocessing each sample separately would sound worse than postprocessing the linear combined output sample, but given the limitations, this way it does not change the player routine at all, just the MOD sample loading routine.

IIRC, for each sample, didn't your player calculate separate waveforms for each volume level anyway?

Jepael wrote:

You could avoid the overhead by precalculating the sample waveform values with loudness mapping so you don't have to do it at runtime in the playing/mixing routine.

Yes, we could do that but it would introduce more distortion for a given loudness increase than doing it on the mixed waveform.

Ultimately I opted not to introduce any distortion at all, reproducing the musician's intended result as accurately as possible and living with some loudness decrease. A 4-channel arbitrary-waveform player is never going to be as loud as a 1-channel, 100% amplitude square wave player anyway.

Jepael wrote:

You could avoid the overhead by precalculating the sample waveform values with loudness mapping so you don't have to do it at runtime in the playing/mixing routine.

We did actually discuss a sort of 'non-linear' mixing routine, using xlatb rather than addition to mix samples that way. The idea was that doing three such additions would give you an exponential volume response.
Something like this:
remap1(remap0(channel0+channel1) + remap0(channel2+channel3))

Something like this is quite common for 'many channel' tracker routines, since if you have more than ~8 channels, doing linear mixing will make individual channels extremely quiet.

I played the final demo on both my old and new IBM CGA cards. It ran seamlessly on both whereas the party version had some difficulty with my new CGA card because it uses the HD6845. It detected my "old" CGA card as "old" even though it was converted from a new CGA card.

The only issue I had was that the colors appeared to be "off" on my new CGA card. I tried and tried but could not get my new CGA card to mirror the image in the included newcga_optimal_calibration.png. The palette on the calibration screen had more colors, so I just went with that. Most of the demo was OK, but the photorealistic images of the flower girl and the creators just were not right with way too much green.

After running the demo once, I could not figure out for the life of me what went wrong. I read Scali's blog post and decided to try it again. I ran the demo again, and on the calibration screen I finally noticed the "Space: CGA model [old]" I just didn't realize that I had to hit the Spacebar to get new CGA colors. I had assumed that the program would pick the proper color palette because it autodetected my cards correctly. Once I changed the calibration screen to "Space: CGA model [new]", my color problems disappeared.

By the way, a belated happy birthday to Trixter. Could this be a birthday present to himself? 😉

Great Hierophant wrote:

I ran the demo again, and on the calibration screen I finally noticed the "Space: CGA model [old]" I just didn't realize that I had to hit the Spacebar to get new CGA colors. I had assumed that the program would pick the proper color palette because it autodetected my cards correctly.

Ha! I guess we should have documented that a bit better. The initial screen doesn't actually detect anything as far as the program is concerned (there's no way for software to programmatically detect the difference between old and new CGA), it just displays a very clever image (courtesy of VileRancour) which says "old" for old CGA cards and "new" for new CGA cards (if you look carefully, a ghost of the other image may be just barely visible). So you still need to select the right CGA model in the calibration program. Glad you figured it out in the end!

Yep - can't detect via software/hardware? do it in wetware. 😉

Here's my own writeup on how that image works, among other things on the graphical side: http://8088mph.blogspot.com/2015/08/8088-mph- … -and-other.html

That first 2x2 grid picture is interesting - especially comparing the "proper" old- and new-CGA versions. In particular, the new-CGA version seems to have some darker hues compared to the original old-CGA rendering. Probably can't read too much into it, though, since everything is apparently hand-tweaked.

Heh, well spotted... new CGA does have more contrast in it's 'palette', which gives you more shades to play with on the darker end. I believe that's because the color burst signal has a lower amplitude than on old CGA, which causes the receiver to compensate by normalizing it (and jacking up the contrast overall).

Speaking of palettes, perhaps that is something we have not actually documented much, if at all.
As in, the CGA colours are all direct colours, they aren't indexed into a palette like with EGA/VGA and various other platforms... or even the 'colorram' approach that the C64 has, where you can quickly modify colours per character or per sprite.
We need to perform that extra step ourselves, eg to map a light intensity to a (dithered) colour gradient, or with the sprite fade-to-white, by reading pixels from screen, remapping them with a table, and writing back.
Or the plasma, manually indexing the combined sine-shapes into a palette, rather than just setting up a palette once and then plotting the sine-values to a bitmap.

I'm trying to run this on my 256KB 5150, running in to some trouble.

My CGA card has the resistors in place near the rear connectors, but has the "old" model number stamped on it. The test screen looks "more right" using "old" mode, however, with the squares fading right to left.

But way worse than that, it doesn't play anything after flower girl. Just shows the scrolling text for each scene, showing the team photos, then dumps to command prompt. What gives?

Edit: Nevermind, I completely forgot the 640KB requirement. I have a XT clone board with 640KB on it, but composite colour simply won't work on it, the ISA speed is too far out of spec I think.

Hmm - it'd be odd for an XT clone board to get the speed that wrong... plus an IBM CGA uses the clock signal on the ISA bus for *all* its timing needs, including hsync/vsync, so if the frequency was that far out of whack the symptoms would be worse than a lack of color.

OTOH, IBM motherboards (and perhaps some clones) have a variable "color adjust" trimmer capacitor to fine-tune the frequency over a narrow range, which can compensate for having a colorless image - is there such a thing on your board by any chance?

VileRancour wrote:

Hmm - it'd be odd for an XT clone board to get the speed that wrong... plus an IBM CGA uses the clock signal on the ISA bus for *all* its timing needs, including hsync/vsync, so if the frequency was that far out of whack the symptoms would be worse than a lack of color.

OTOH, IBM motherboards (and perhaps some clones) have a variable "color adjust" trimmer capacitor to fine-tune the frequency over a narrow range, which can compensate for having a colorless image - is there such a thing on your board by any chance?

It does have a trimmer near the 14.318MHz crystal, and that was the first thing I went for, but adjusting this only gets me from a stable, clear picture in the centre, to an unstable picture at either extreme.

It was alarming actually, because this was the first system my CGA card got installed into when I received it. I began to think that maybe my CGA card was faulty. Thankfully, when I transferred it to my 5150 that the colour started working immediately.