Scali

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.

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.

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.

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

Yes, thanks! Fixed the original text.

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.

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.

Some will agree, some won't. This is a good watershed moment to cut off the ones that won't.

"Justify why people died" Lol, you sound as unhinged and radicalized as Jim. The point I was making was that all these people had a criminal record that showed they had a violent nature, and were likely there to cause trouble. But to understand that, you need to be not radicalized, and be able to think calmly, logically, and humanly.

Also, a conversation is more than just deflecting and ignoring things, it means engaging with a topic and exchanging arguments. Clearly Jim was not open to that. The way he was misrepresenting what I said at some point is nothing short of sick. Much like what you were doing just now.

Which is funny... from 56+ pages of conversation, you STILL have to twist and frame my words in an attempt to make me look bad. Lol.

Given that the demo targets AT-class hardware, it is unlikely that something like PCem or MESS was used, because in those cases you'd actually have to select an AT-configuration to make it work, instead of an XT-configuration. DOSBox does not have this option, it always emulates AT-class hardware, in which case this demo 'just works'.