• Please review our updated Terms and Rules here
  • Exhibitor application for VCF West 2022 is now open! If you are interested in exhibiting, please fill out the form here.

8088 Domination: A new FMV method for 8088 PCs

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621

Trixter

Veteran Member
Joined
Aug 31, 2006
Messages
7,205
Location
Chicagoland, Illinois, USA
For anyone who wants to see what this looks like in 16 colors on a Tandy, I added support for 160x200x16, as well as a small sample file that fits on a floppy disk.
 

stynx

Experienced Member
Joined
May 20, 2013
Messages
177
Location
Germany
Hi Jim,

i am more of a Apple II guy with a side dish of 8088 PCs but i have watched your demonstration with much interest.
Right now i have not looked trough your published code, but i wanted to ask, if you have used any special compression besides the optimization.
Antoine Vignau and Oliver Zardini have implemented LZ4 for the Apple II and the decompression is even faster than uncompressed loading of the data.
Furthermore i have read your comments on the Apple II and Apple IIgs with much interest as well.

I would be very happy to see a similar approach on the apple II in HGR (280x192x6) or even DHGR (140x192x16).

-Jonas
 

Trixter

Veteran Member
Joined
Aug 31, 2006
Messages
7,205
Location
Chicagoland, Illinois, USA
The only "compression" that occurs is a form of RLE. Spans of changed bytes are checked to see if they have any runs of a similar byte in them, and if so, are encoded using an optimized form that takes up less space and also takes less time to write to the screen.

Many years ago, as part of research for XDC, I wrote an 8088-optimized LZ4 decompressor to see if actual compression was feasible from both a space and time standpoint. While it was for space, it was not for time. "transparent" decompression was a requirement for the project, so I did not use that in XDC.

I would also like to see something like this implemented for the Apple II in DHGR, but it won't come from me :) It would also require a slightly different approach; the CoCo 3 video player came up with the same concepts but they had a fixed bandwidth, interrupt-driven serial stream device to read from, which I imagine would be similar to whatever the Apple II would hook up. In that system, data is transferred from the storage device directly to video memory and a DAC. PC/clone storage/audio devices aren't designed that way; disk access is through a system API and has unpredictable performance characteristics, so I had to simultaneously take advantage of that, and be wary of /work around it.
 

stynx

Experienced Member
Joined
May 20, 2013
Messages
177
Location
Germany
I would also like to see something like this implemented for the Apple II in DHGR, but it won't come from me :) It would also require a slightly different approach; the CoCo 3 video player came up with the same concepts but they had a fixed bandwidth, interrupt-driven serial stream device to read from, which I imagine would be similar to whatever the Apple II would hook up. In that system, data is transferred from the storage device directly to video memory and a DAC. PC/clone storage/audio devices aren't designed that way; disk access is through a system API and has unpredictable performance characteristics, so I had to simultaneously take advantage of that, and be wary of /work around it.

-----------------

Hmm ... as far as i have seen, the LZ4 decompression is faster than raw-byte reads but the simple RLE approach you have chosen might give you the same kind of acceleration with less computing. Regarding Apple II storage, there are several solutions using DMA and archive transfer rates of over 200k/s on the Apple //e (1mhz). Other solutions allow a byte-stream (Slinky-Ram) to be read continuously until the 'end of the memory' is reached. The most 'modern' way to access a mass storage device is through the SmartPort-API (//e with 3.5" Card, //c and //gs). But as on the PC, the use of the API will result in unpredictable data transfer rates.

The biggest problem on the Apple II is that you find several solutions to archive big mass data storage.

Example for the Apple //e:
As the Apple //e has a maximum AUX-Ram (bank-switching memory) of 16Mb, you could allow at least around 16mb of memory for a video if you don't use mass storage. OK, 16mb is not possible right now, as there is no AUX-memory expansion of that size available. Therefore AUX-ram is nice but will not be sufficient for buffering the video. The AUX ram would be perfect, because you can set read-operations to one bank and write-operations to another. A cool feature... but only useful as buffer for a few frames. A sophisticated frame-buffering may be possible with the usage of DMA and bank-switching... but i doubt it is possible to use DMA and memory access from the CPU at the same time.

Even though i have no time at all for 'another' Project, i will try to study your approach ;-)

-----------------

What is your thought of accelerating the 8088 (NEC V20 or upgrade-cards)? I got several 8mhz 8088->286 Accelerators that i have upgraded to 20Mhz 286. The most advanced upgrade card i have is the Inboard386-PC running at 50mhz. Do you have had personal experience with something like that?

What is the limit of upgrades to the XT until it is no longer interesting to you?

-Jonas
 

Trixter

Veteran Member
Joined
Aug 31, 2006
Messages
7,205
Location
Chicagoland, Illinois, USA
Hmm ... as far as i have seen, the LZ4 decompression is faster than raw-byte reads

You need to be careful when making statements like that. For example, the above statement can only be true when the decompression rate exceeds the disk transfer rate AND the compression ratio is significant. On an Apple IIgs (and most 8-bit systems), with the data I believe you're referring to, this is common. For my platform (8088) this is not the case. If you want to see actual tests I performed with their decompression times and compression ratios, refer to the link in my previous post; I found only a single case (heavy use of RLE) that outperformed raw reads, and only because the CPU had an optimized instruction for doing so.

Regarding Apple II storage, there are several solutions using DMA and archive transfer rates of over 200k/s on the Apple //e (1mhz).

Kilobits or kilobytes? Important distinction! If KB/s, then 200KB/s is definitely fast enough to support video playback in this way. Heck, if you've got 200KB/s then don't bother with any compression; DHGR is 140x192x16=~13KB per frame so even without any processing you can achieve 15fps right there.

But as on the PC, the use of the API will result in unpredictable data transfer rates.

In those cases, you create a system that can be tuned for the available bandwidth (which is what I did) and just make sure you stay within the slowest conditions you are likely to encounter.

What is your thought of accelerating the 8088 (NEC V20 or upgrade-cards)?

Can you be more specific? What about accelerating the 8088 do you want my thoughts on?

What is the limit of upgrades to the XT until it is no longer interesting to you?

When I used these systems as a teen in the 1980s, I enjoyed hotrodding them. I installed an NEC Vx0 chip, I lusted after accelerator cards, I cut holes into my case to add drives, I added a math coprocessor, I added a hardcard, I ran speaker wires out to a jack so I could amplify the speaker, etc. (Sample video for one of these systems, if you're curious)

Now that I program them for the challenge, I don't enhance them at all. The fun, for me, is breaking previously-established limits with stock hardware, or at the very least, using hardware that was available at the time.

Put another way: If I had chosen an accelerated machine with which to develop my video playback system, I would have designed something completely different (likely a VQ scheme that performs actual heavy lifting). But then again, it's not really that impressive to say that you've created a video system for a 50MHz machine, is it?
 

stynx

Experienced Member
Joined
May 20, 2013
Messages
177
Location
Germany
Can you be more specific? What about accelerating the 8088 do you want my thoughts on?
...
But then again, it's not really that impressive to say that you've created a video system for a 50MHz machine, is it?

The IBM-PC was built to allow upgrades. What is a typical XT configuration, or what is allowed in a PC XT to be a PC XT? My interest is mainly hardware centered (even if i am a programmer) and i love to get the most out of it. An unmodified system is very nice to see non the less.

I have upgraded the XT to a 486DLC on the Inboard386 with 25mhz Inboard clock, doubled in the DLC-CPU and the XT-mainboard at 8mhz as well as 2Mb XMS. The system sports a 1mb ET4000, SCSI HD (with CF-SCSI Adapter) and CD-Rom, 8Mb EMS and some other cards (11 in total). Most people say "why don't you just take a faster computer?" ... they are right in terms of speed, but i can take all the stuff out, install the original 8088 and i have a completely original XT. No modification on the XT is permanent or soldered.

As i want to get to the pinnacle of function for the XT with hardware, you have archived it with limited hardware resources simply in software. I remember a paper where software development and hardware development were compared. Simply by optimizing the software to a the individual platform a speedup in computing of times 3 could be archived in sorting and prime number algorithms. Your demo shows that there are a lot of possibilities still available to optimize if you have a good idea.

If i would want to implement a FMV approach on the Apple II, i would have to take into account which machines were produced. The IIc was a very well sold specimen but it has little to no expansion capabilities: 128k ram and a 5.25" Floppy, 2 Serial ports and a SmartPort-interface. But in terms of Hardware features you could call it the lowest common denominator of the modern Apple II Systems (e,c,gs). If i wanted to implement FMV on the IIc, i would have to use serial (up to 115Kbaud), as the SmartPort-harddisks are like unobtainium. A serial-Harddrive implementation is available, but this is very slow (around 10kb/s max) as mass storage. As for graphics there are LGR (40x48x16), DLGR (80x48x16), HGR(280x192x6), DHGR (140x192x16 or 560x192x2) and i would think that the way you have made your demos would as well be the way to go on the Apple II. First implement FMV for the DLGR mode then try to get higher resolutions done ;-)

But as with the XT we have the "vanilla" problem, the stock hardware is very limited and has to be programmed with godlike coding skills, i surely don't have on either the PC nor on the Apple II.

Thanks for your clarification

-Jonas
 

reenigne

Veteran Member
Joined
Dec 13, 2008
Messages
702
Location
Cornwall, UK
What is a typical XT configuration, or what is allowed in a PC XT to be a PC XT?

It's a little bit of a matter of opinion, but I think this is the most common answer to this question: most of the software produced in the first decade of the PC's life (i.e. 1981-1991) was written to be able to run on a 4.77MHz 8088 with CGA, 640kB of RAM, PC speaker sound only, no FPU, and two 360kB floppy drives (although software produced towards the end of this period would give a better experience with better hardware). So, this is what I consider the "standard PC". It was all available (using original IBM parts) when the first PC came out, with the exception of the RAM (which could be upgraded much more gradually than, say, the video, so having 640kB was very common).

By way of example, consider the Ultima series. Ultima VI came out in 1990 and supported CGA (I first played it on a PC1512 with 4 colour graphics). Ultima VII came out in 1992 and required VGA.

But as with the XT we have the "vanilla" problem, the stock hardware is very limited and has to be programmed with godlike coding skills, i surely don't have on either the PC nor on the Apple II.

The limitations of the "standard PC" are not too dissimilar to those of the Apple II platform you mentioned. Yes, you need to do some serious assembly programming to do impressive things, but that's a big part of the fun!
 

stynx

Experienced Member
Joined
May 20, 2013
Messages
177
Location
Germany
It's a little bit of a matter of opinion, but I think this is the most common answer to this question: most of the software produced in the first decade of the PC's life (i.e. 1981-1991) was written to be able to run on a 4.77MHz 8088 with CGA, 640kB of RAM, PC speaker sound only, no FPU, and two 360kB floppy drives ...
... you need to do some serious assembly programming to do impressive things, but that's a big part of the fun!
If you think about it, even the Soundblaster 1.0 was first introduced 1989, 6 years after the PC XT. The AdLib Card was available since 1987.
I find that especially strange since multi channel music cards like GameBlaster for the PC (1987) were available on the Apple II since 1978.

I see several parallels between Apple II and the IBM PC platform and since many Apple II people migrated directly to the PC, i cannot understand, why much of the hardware appears to be 'set back' several years. You could use graphics cards with the Apple II since 1981 with 512x512x2 resolution. Could it be that the PC platform was too fragmented at first with too many manufacturer specific features before 1987?

Anyways, i am happy to have some answers to my questions, thanks.

-Jonas
 

reenigne

Veteran Member
Joined
Dec 13, 2008
Messages
702
Location
Cornwall, UK
If you think about it, even the Soundblaster 1.0 was first introduced 1989, 6 years after the PC XT. The AdLib Card was available since 1987.

Oh sure, those things were definitely available before 1991. Same with EGA and VGA cards. And a lot of software released before 1991 did support those things, but usually as an optional extra that would improve the experience rather than as a baseline requirement. So if you were designing a game back then you might draw all your graphics as 320x200 in 256 colours and then dither them down to 16 colours or 4 colours for EGA and CGA respectively at install time. Similarly with sound. It was an annoying extra step in development/testing to be sure, but not doing it would significantly reduce the size of your potential market.

Could it be that the PC platform was too fragmented at first with too many manufacturer specific features before 1987?

That is one reason why consoles were a popular target - developing for NES/SNES/Master system/Megadrive meant that you knew exactly what hardware the player would have and would only have one configuration to test against. PC games development was more complicated before VGA+Soundblaster became the de-facto standard.
 

Great Hierophant

Veteran Member
Joined
Mar 22, 2006
Messages
1,920
Location
Massachusetts, USA
That is one reason why consoles were a popular target - developing for NES/SNES/Master system/Megadrive meant that you knew exactly what hardware the player would have and would only have one configuration to test against. PC games development was more complicated before VGA+Soundblaster became the de-facto standard.

A game developer in the late 80s trying to obtain the widest possible market may have had to make his graphics work with different the five-most commonly supported video adapters, VGA (and MCGA), EGA, TGA, HGC & CGA. If they were very ambitious, they may have also considered supporting the various sound devices (in addition to the PC speaker) on the market, Adlib, Roland MT-32, Game Blaster, Tandy 3-voice and possibly the lesser known Innovation SSI-2001 and Covox Sound Master and Voice Master.
 

vwestlife

Veteran Member
Joined
May 2, 2008
Messages
5,129
Location
central NJ
The VGA/MCGA 320x200 256-color mode quickly became the standard for DOS games in the early '90s. The resolution was kinda crappy, but the color depth made up for it, and it was on par with games for the Amiga, Atari ST, and Sega Genesis. (I think the SNES had slightly higher resolution, but still had to work within the limitations of an NTSC TV signal.)

To support CGA, Tandy, and EGA, they just took the same 320x200 graphics and reduced it to 16 or 4 colors.

Hercules graphics was usually only supported on more "grown-up" games that adults might play on their computers at work, such as Tetris (complete with the "boss key" to bring up a fake Lotus 1-2-3 spreadsheet on the screen!).
 

Trixter

Veteran Member
Joined
Aug 31, 2006
Messages
7,205
Location
Chicagoland, Illinois, USA
For video standards, there was a very small window (1988-1990) where all five standards were targeted, and only by companies who had an established base of older systems (Sierra, who would produce 16-color versions of their 256-color games), or companies whose reputation was one of pushing technical boundaries (Access, for example Mean Streets supports all five and dithers VGA runtime to other standards as necessary).

For sound card adoption, I refer you to MobyGames, where you can see for yourself how many titles each card was supported in. It's not a spoiler that the SSI-2001, Sound Master, and Voice Master were supported by less than 50 titles (out of 3500).
 

vwestlife

Veteran Member
Joined
May 2, 2008
Messages
5,129
Location
central NJ
This music video should be easy to convert to 8088 Domination or even 8088 Corruption, since it's already very blocky and with a limited color palette:

 

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,746
Location
UK
One could be forgiven for thinking that the producer must surely have seen Trixter's work.
 

modma

New Member
Joined
Jul 19, 2016
Messages
2
You're interested toimplement Am strad PC1512 special CGA mode? it's cga and use a proprietary 640x200 16 colors, is easy to implement it (i can send examples),
the demo videos works perfectly, but is interested in try this relic? DONT WORRY i have a computer of this characteristic to test it
 

Trixter

Veteran Member
Joined
Aug 31, 2006
Messages
7,205
Location
Chicagoland, Illinois, USA
I replied on the website, but I'll duplicate it here for posterity: There are a few hurdles in implementing PC1512 mode. It’s 64KB per frame instead of 16KB, so you’d need quadruple the CPU time and data to make videos that can take full advantage of the mode. Secondly, the Amstrad 640x200x16 mode is arranged by bitplanes, so according to the information at http://www.retroisle.com/amstrad/pcs/Technical/Hardware/PC1512_Video.php it would be very slow to update large portions of the screen. I’d also have to write a compiler specifically for that mode.

The Tandy TL/RL/SL series also has a 640x200x16 mode, but I believe it’s arranged in chunky fashion which would make it easier to support. But I have no such plans at the moment. All source is freely available, if anyone else wants to give it a shot.
 

modma

New Member
Joined
Jul 19, 2016
Messages
2
ok, thanks, i understand the method to dump data in this mode is not very standard compared with for example EGA or Tandy, I dislike amstrad for this and another (mouse port for example, and monitor conector)...
yes 4 planes = x 4 cpu and more video bandwidth, (if try to implement a fast RLE decompressor, can reduce, but i can't get hot much penalty will be, I use a XTIDE to emulate hard disk, the next try will be a RAM disk; and another video samples for example tron discs, the system waits to fills buffers a lot) :( only the advantage is that the CPU is 8mhz
ok, i'm a good programmer in C, maybe try to operate a test-demo if remember old times of pascal, but I share your conclusion, I deduce: this mode is not standard and not is CGA at all :(
maybe it can't do good results, but, my motto : if you do not try you never know if you will be successful...
thanks!
 
Last edited:

Simone2013

Experienced Member
Joined
Aug 21, 2013
Messages
120
Location
Ravenna (Italy)
Very Amazing Trixter...

Just to use the XT-IDE full throughput I've programmed a simple full-screen video player (here reproduced on Olivetti Prodest PC1) for 640x200 b/w mode because is not a composite-mode CGA.
I't just a direct INT13 to screen memory but is near to 20fps. (no sound, because is pc-speaker only!)
maybe interlacing it can show better animation. In the initial specification for this PC there was a 160x200x16 color mode but vanished on final model. That has to be very interesting because you can modify the palette and choose it freely from 512 different shades.

Here is the result, however, played on 320x200x4 grey mode:

 
Top