Live data from Hacker News

Video playback on low-end MS-DOS machines

scalibq.wordpress.com

1–10 of 35 posts

Re: Video playback on low-end MS-DOS machines

#5
post #4

> 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.

Re: Video playback on low-end MS-DOS machines

#6

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.

Re: Video playback on low-end MS-DOS machines

#8
post #3

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.
Post reply on HN