• Please review our updated Terms and Rules here

8088 Domination: A new FMV method for 8088 PCs

I'm using a WD1004-27X and an interleave of 4. According to Spinrite, that is optimal for that machine. I'll fiddle with that a bit more.

Looking closer, I was wrong about the colors, my machine or composite-to-VGA converter is displaying them way off. Is there a good program for testing the CGA artifacting mode? This CDP CGA card does a few odd things too.
 
Not sure what you mean by "testing" -- I think if you've noticed they're way off, there's your test :)

Vile Rancour wrote a small program called WHICHCGA.COM that displays an image that helps you identify if you have the "old" or "new" style CGA card; a search of this forum might turn it up. Tandy 1000 systems output CGA composite mode with the hue shifted 180 degrees (!) and I've been told the PCjr composite output is also slightly off but I can't remember by how much.
 
FYI, the trimmer on the 5150 PC and 5160 XT motherboards is used to adjust the CGA artifact colors. It adjusts the system's 14.31818 MHz clock crystal timing, which in turn adjusts the timing of the video signal after it gets through a few dividers to produce the 3.579545 MHz NTSC color burst frequency.
 
Unfortunately, I don't know if any of the trimmers on my CDP 1600 are a color adjust. There are three of them and they are located under the floppy drive housing, so I will have to take those apart to get to them.

What I meant by test, was just some kind of calibration tool that would display a reference image in that specific mode. The CGACAL tool only uses normal text mode.

Anyway, here are some images I captured from my thing-a-majig:
cgacal.jpg
dom2.jpg
whichcga.jpg
 
CGACAL is an RGB calibration test only; you can't use it for composite output.

I'm not an expert but it looks like a +80-degree hue shift -- which means I have no idea what is going on.
 
What's even weirder here is that the 8088 Domination colors are shifted, but the WHICHCGA colors aren't -- that last shot looks entirely consistent with an "old"-style IBM CGA.

I can only guess that the composite output on this CDP card changes the pixel clock/color carrier phase difference in mode 6 (8088dom) as opposed to mode 4 (whichcga). Which would be unusual, but not unheard of... the Tandy 1000 shows a similar difference in hue shifts between modes.
 
What's even weirder here is that the 8088 Domination colors are shifted, but the WHICHCGA colors aren't -- that last shot looks entirely consistent with an "old"-style IBM CGA.

I think that's because WHICHCGA is in text mode and uses direct colours whereas 8088 Domination uses graphics mode and artifact colours. The direct colours have the normal phase relationship with each other (and in particular with colour 6 which is used for the color burst) but they have a different relationship with the pixel grid so the artifact colours are different.
 
I think that's because WHICHCGA is in text mode and uses direct colours whereas 8088 Domination uses graphics mode and artifact colours.
It's not that - WhichCGA is mode 4 and uses both direct and artifact colors (I didn't find purely direct color combinations to be as useful in distingushing the models). In RGB it looks like this:
whichcga_000.png

The top part exploits artifacting, so I would've expected it to look different on SomeGuy's card vs. the corresponding IBM cards, but it's the same... while 8088 Domination isn't, hence my conjecture above. That said, I'm fully prepared to facepalm in case I'm overlooking something obvious :)
 
The top part exploits artifacting, so I would've expected it to look different on SomeGuy's card vs. the corresponding IBM cards, but it's the same...

Oh, huh - weird. It could be that the phase shift just happens to make only a very small difference for these particular patterns. Or it could be that the phase shift only occurs in 1bpp mode.
 
Searching around I found the "16rows" tool here: http://www.seasip.info/VintagePC/cga.html#ccomp

This gives me a good test of all of the artifact colors at the same time. Using this, I was able to adjust my hue to make this and 8088dom look about right. But then, of course, the text colors look a bit off.

16rows01.jpg
This is what it was giving me before the hue adjustment.

16rows_vbox.jpg
And this is a color reference from DOSBOX.

Good enough for now. I'm just adding this this information because there is so little information out there about the CDP 1600.

Oh, and Trixter, 8088dom is awesome! :bow2::bow2::bow2::bow2:

Edit: and as it turns out, the optimal interleave for this controller on this machine is 5 despite what spinrite says. Now it keeps up just fine.
 
Last edited:
I'm not sure how applicable it is to this demo, but I just realized something:

Provided there's some spare RAM in the 0xC800 or 0xB800 segment from another expansion card (such as Hercules), isn't it possible to use a mem-to-mem* DMA xfer to speed up rendering even further? Or would the overhead of the transfer cancel out any gains?

*Limited to in-segment xfers.
 
Memory-to-memory DMA transfers operate using two bus cycles (read then write), so the performance should be the same as with a V20. However there is a lot of set up overhead, especially when dealing with small areas (it might be slightly faster than an 8088 transferring 8 or 16KB though).

Trixters latest encoder makes use of rep stosw a lot (IIRC) for run-length encoding, so each word takes 11 clocks (just under 3 bus cycles).
 
Searching around I found the "16rows" tool here: http://www.seasip.info/VintagePC/cga.html#ccomp

This gives me a good test of all of the artifact colors at the same time. Using this, I was able to adjust my hue to make this and 8088dom look about right. But then, of course, the text colors look a bit off.

View attachment 19211
This is what it was giving me before the hue adjustment.

View attachment 19214
And this is a color reference from DOSBOX.

Good enough for now. I'm just adding this this information because there is so little information out there about the CDP 1600.

Oh, and Trixter, 8088dom is awesome! :bow2::bow2::bow2::bow2:

Edit: and as it turns out, the optimal interleave for this controller on this machine is 5 despite what spinrite says. Now it keeps up just fine.

A nice feature of those programs is that they allow you to set each bit of the Mode Control and Color Select Registers independently. 0-5 on the keyboard will set bits 0-5 of the Mode Control Register, and letters A-F will set bits 0-5 of the Color Select Register. This way, you can test every possible combination of colors in color composite mode.
 
Sorry for the thread bump, but here is my homage to Trixter's work:


It's a 5150 motherboard with a CGA and a SBpro2 with a tiny 3,5'' composite video lcd, running 8088 Domination.





I hope you like it ;)
 
I'm speechless. Seriously, I've never had my software turned into an art installation before. This is a really wonderful birthday present :-D

Now I really need to get the source/.exe/docs released. I'll work on it this weekend, promise!
 
I've finally released everything: Source, binaries, some example files, and most importantly documentation. Head over to http://x86dc.wordpress.com/ for everything. Now everyone who wants to create a video for their vintage PCs with CGA can do so, and I'm sure all three of you will enjoy that very much ;-) The documentation for the compiler also has a link to a screencast where I walk through the conversion of a video from start to finish.

I apologize for how much preprocessing is necessary; if an enterprising programmer (Mike Chambers, I'm looking at you) wants to make a "helper" utility that will accept an .AVI and spit out frames and a script, I would happily add it to the site to make the process easier for everyone.
 
I've finally released everything: Source, binaries, some example files, and most importantly documentation. Head over to http://x86dc.wordpress.com/ for everything. Now everyone who wants to create a video for their vintage PCs with CGA can do so, and I'm sure all three of you will enjoy that very much ;-) The documentation for the compiler also has a link to a screencast where I walk through the conversion of a video from start to finish.

I apologize for how much preprocessing is necessary; if an enterprising programmer (Mike Chambers, I'm looking at you) wants to make a "helper" utility that will accept an .AVI and spit out frames and a script, I would happily add it to the site to make the process easier for everyone.

Sweet!! Yeah, I might start on that this weekend. First I'm going to play with encoding some videos. I've been waiting for this. :)

I'm thinking about making a native Windows player for the video files. Is there documentation of the format available? Since the frame data is executable code, I could rip the CPU core from Fake86 and base it around that.
 
I'm thinking about making a native Windows player for the video files. Is there documentation of the format available? Since the frame data is executable code, I could rip the CPU core from Fake86 and base it around that.

The file format description in one of the source files contains everything you need, however there is a generic unix player that may be quicker and easier to implement than a full emulation core, since the number of instructions I use in the output are limited.
 
Back
Top