Video playback on low-end MS-DOS machines | Hacker News Reader

Video playback on low-end MS-DOS machines

scalibq.wordpress.com

78 pointszdw33 comments

16 FPS video and audio on a Commodore 64 demo. Very, very highly compressed and optimized data and algorithm:

https://m.youtube.com/watch?t=12m55s&v=yW5v93P-gBw&feature=y...

EDIT: and some details on the audio encoding method, might as well start here: https://m.youtube.com/watch?t=11m55s&v=yW5v93P-gBw&feature=y...

That's actually really good.

The Atari 2600 says, "Hold my beer."

https://forums.atariage.com/topic/318978-movie-cart/

>It uses a 16mips pic (64hz 4-cycle) driving 1K of an 8k dual port ram.

This is much closer to the "Reverse Emulation" of the NES that https://www.youtube.com/watch?v=ar9WRwCiSr0 did than playing a movie on the actual device. Using the original hardware as nothing more than an RF output interface is clearly not the same work, though just like in the reverse emulation of the NES, it is still a neat thing.

The reason video on original IBM 5150s is so neat to most people is that it could have reasonably been done in it's heyday if we could take knowledge and algorithms back in time, which the reverse emulation versions could not.

It was common, especially in the later days of the 2600, for cartridges to include helper circuitry including RAM and even sound chips.

First full color I saw on low end PC was 1987 demo on IBM Model 30. 8086 CPU. It used 128 out of 256 colors to hide the palette switch flash. It was a clip from National Geographic mammals and a classroom video. It was digitized using a laserdisc and at&t Targa16 to get one frame at a time. Was captured on a compaq 386/20 because IBM didn't have any micro channel capture cards. So IBM paid for the compaq. Video was in 320x200 mode since no higher 256 color modes on M30. It took SVGA cards to commonly see higher res 256 color modes. This wasn't dithered video, so looked pretty good.

I had a 486DX - if I wanted to play an MP3, I had to exit out of everything and run only the DOS player.

On my 486 I don't remember being able to play MP3s in realtime. I remember having to convert a 3MB MP3 to a 50MB WAV that took up my whole HDD just to play it.

Ken Silverman, creator of the BUILD Engine, made MP3PC.exe that's still hosted on his Utilities page. I'm pretty sure I used this on a 486 years ago and was surprised at how well it worked, though it apparently is picky about MP3 encodings. From the description:

> MP3PC.EXE (73,483 bytes): Got no sound card? MP3PC plays MP3 files through your PC speaker! For some reason I like to make programs work through the PC speaker. Some people still don't know that it's possible to play real sounds through it. Unfortunately, you must run this in pure DOS mode for it to work.

His Utilities page can be found at: http://advsys.net/ken/utils.htm

Wow, I just learned that he is also the author of PNGOut.

There were entire games, eg. star control 2, that played sample audio through the PC speaker. It included voice sample in parts (eg. The pkunk swear words).

It was actually patented by Access Software, under the name of RealSound. https://en.wikipedia.org/wiki/RealSound

What a dumb patent. We were already doing this before their patent. We just ignored it and they didn't try to challenge. I remember talking to my EE father at the time and he said the idea of doing PWM for audio was obvious and ludicrous to patent.

I had a 486 dx4/100 there was a checkbox in winamp options you needed to tick in order to be able to play mp3's, I've long since forgotten what it was labelled but when you checked the tickbox it worked and audio played correctly but basically pegged the entire cpu - forget about skipping or being able to seek within the track. Just moving mouse cursor etc. was massively delayed the whole computer was unusable until the track finished playing.

My next computer after the dx4 was a Pentium 166 MHZ - it could play mp3's and Quake simultaneously.

> And indeed, I found that it set a period of 1 instead of a period of 1.

I assume this should be ...

> And indeed, I found that it set a period of 1 instead of a period of 0.

Yes, thanks! Fixed the original text.

Love how people are still pushing old hardware. These are also two excellent demo's on the XT:

Area 5150 https://youtu.be/fWDxdoRTZPc?feature=shared

8088 MPH https://youtu.be/yHXx3orN35Y?feature=shared

Same guy, I think.

> It is impossible for the audio to drift ahead of or behind the video, regardless of the video framerate or audio samplerate.

How is this "impossible" if the video clock and audio clock are on different physical devices?

The video clock (I assume you mean pixel clock) isn't relevant. The synchronization of video and audio happens on a per-frame basis. And since the frames are clocked out on the audio-clock, there cannot be any drift.

Having said that, the CGA card does not actually have its own clock. It takes the NTSC base frequency of 14.31818 MHz from the OSC-pin of the ISA bus. On early PCs, such as the IBM 5150/5160, the CPU frequency is also derived from this same base clock (which is why you get the oddly specific speed of 4.77 MHz).

This is awesome. I tried doing this in the early 90s by breaking down video frames into averaged color triangle polygons and then using the renderer I had to draw them. It worked fine, but obviously best on large swathes of flat color like cartoons where it would create the smallest number of vertices and the largest runs of bytes.

Somewhere on Usenet there is a post of mine about running it on my 286, but I just wasted an hour trying to find it.

This seems very similar to how the cinematic platformer Another World (1991, also known as Out of This World) was doing its elaborate full screen animation sequences, although the animations were rotoscoped rather than generated by an automatic encoder.

re: decomposing video to triangles - That makes me think of State of the Art[0] and Nine Fingers[1], though I don't actually know how they worked.

[0] https://www.pouet.net/prod.php?which=99

[1] https://www.pouet.net/prod.php?which=100

YES! I was trying to remember the names of these demos, they came out the same time I was working on my code. Really was peak demo scenes days in 93/94. I feel like we were doing it that way because we had hammers and saw everything as a nail. I don't think any of us knew how an actual video codec worked back then, there was so little information available until the Internet started taking off in late-93 onwards.

The Amiga had a hardware blitter that was very good at drawing lines and doing area fills, so it made perfect sense to encode video to polygons on that particular hardware.

Yep! That's what I meant in an obtuse way about the hammers and nails :D

Well, I would argue that a 'conventional' video codec would not work nearly as well on a stock Amiga 500 as this polygon approach does. The closest thing to full-motion video on the platform was probably what they used on the CDTV (same hardware as an Amiga 500, but with CD-ROM). It used the CDXL format: https://en.wikipedia.org/wiki/CDXL.

In short, you got 160x100 video at 12 fps. It was uncompressed data, because the system was too slow to decompress in realtime. So the Amiga really wasn't powerful enough for 'conventional' codecs to begin with. Especially 9 Fingers gets pretty detailed video at the full resolution and certainly more than 12 fps. And the whole thing fits on just two floppies, so the storage is quite efficient as well. Imagine what you could do with a CD-ROM.

The successor to the CDTV, the CD32, got a hardware MPEG decoder, despite having a much faster CPU and chipset than the original Amiga the CDTV was based on.

That is an interesting difference with the 8088+CGA platform by the way. The Amiga has no problem displaying entire screens of uncompressed data. CGA however is so bandwidth-limited that you simply can't update an entire screen at acceptable framerates, so the lossy compression that is used with XDC is a requirement to improve the framerate to FMV-like levels, it is not primarily required for data reduction on disk.

I had a CDTV and a CD32, but I never knew the details about CDXL format, thank you! I just checked and it looks like ffmpeg supports it, bless. It looks like the simplest possible video encoding format you could imagine.

Yes, the reason I was doing it like that on the PC was for the same reason you mention -- using polygons probably is faster because you cut out a lot of math and branches (as long as the polys are large enough) and just drop down to blitting huge swathes of solid color into the frame buffer.

On a PC it is different, because you need to render the polygons in software. On an Amiga you basically draw lines into each bitplane, and then do a single area fill at the end, all with the blitter. The area fill won't have to be stored, as this is done for each frame. Which means you only need to store the lines, and those can be stored directly as preprocessed register values for the blitter. So you can basically just stream the data directly from floppy and fire it off into the blitter.

But as I say, on early PCs you couldn't draw ANYTHING quickly into video memory. Which is also why for the 8088 MPH demo I developed a polygon renderer that calculated the differences with the previous frame, and then only drew that. This allowed a much higher framerate than clearing the stream and redrawing all polys. Similar to how the XDC encoder here encodes the differences.

On the Amiga the CPU isn't fast enough to draw entire screens either, but it has the chipset with the blitter, DMA transfers and whatnot to help it.

so, it's full screen compiled sprites.

Yes, combined with streaming the data from disk in realtime, and playing the audio over the PC speaker in this case, bit-banged. Given the limited performance of both the HDD system and the CGA adapter, the most important thing the compiler has to do is to stay within the budget of HDD and CGA resources.

Reply on news.ycombinator.com