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.
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.
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, 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.
Yes, I posted a followup which investigates the issue somewhat further.
It appears to be some bug with the message queue handling, specifically when the UI is in Aero mode. In classic mode, the problem is not there. In Windows XP, the problem is also not there.
https://scalibq.wordpress.com/2012/03/28/the-story-of-micros...
Exactly. As I tried to explain, you NEED a context switch (which doesn't make it a spin-wait) in order to avoid the deadlock between your main loop and the processing of the Windows message queue (and as you see, I do check the quantum, via QueryPerformanceCounter()).
The goal was to find a way that didn't deadlock the system, while also not wasting so much time that it impacts your framerate to the point where you can't even drive a high-refresh display at say 144 Hz.
Ofcourse I'm open to even better solutions, but so far this is the best solution I know of.
I doubt that events/semaphores would work better, as they'd be implemented as spinlocks for short periods of time, in which case they wouldn't actually trigger a context switch. Once you use a long enough time to get to a context switch, it's probably going to be worse than doing the context switch explicitly, the way I do here.
All in all, it's a bug in Windows Aero, as the followup blog expained (not sure if it was ever fixed in later versions of Windows, I haven't been working with multiple display adapters/screens in situations like these in recent years):
https://scalibq.wordpress.com/2012/03/28/the-story-of-micros...
"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.
The ATi Small Wonder is not entirely cycle-accurate. When I studied the CGADEMO by Codeblasters, I found that the scroller didn't look entirely correct, because the Small Wonder was slightly slower: https://scalibq.wordpress.com/2014/11/22/cgademo-by-codeblas...
It appears to insert a few extra waitstates compared to an IBM card.
This may trip up some effects in Area 5150.
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'.
I wonder... certain software, such as Flight Simulator and Lotus 1-2-3 had a profound effect on the level of compatibility of clones.
So perhaps if software was released that demanded EVEN MORE compatibility, we would have even more compatible clones than we do now?
What may also have had an impact was that clones were generally XT-clones (using the newer, smaller ISA card layout, and no cassette port), not PC-clones. And indeed, they were specifically advertised as 'XT-clone', 'XT-class' and such.
So the 5150 is really the oddball here.
Back in the old days I understood the usage as follows: 'PC' was a catch-all term for all IBM PC-compatible machines that ran DOS. 'XT' was the term used for machines with an 8088 (or sometimes V20) CPU (and of course there was the 'Turbo XT' subclass for CPUs running at more than 4.77 MHz). 'AT' was the term for 286 machines.
After that era, people just identified PCs by the CPU used, so you had '386es', '486es', 'Pentiums' etc.
Yes, especially somewhat later in the life of the 8088, most applications would demand quite a bit of memory, and the 640k configuration became standard for the later 5160s and most clones.
So I wouldn't be surprised if 5150 owners also upgraded the memory on their machines.
The AST Six Pak Plus card was quite a popular upgrade.
It could add up to 384k, so if you had 256k on board (fully loaded later model 5150), there's your 640k.
If you were unlucky enough to have an early model 5150, the board could only take 64k. That limit was however because 4116 memory chips of 16kbit capacity were used. The board could be modified to take the later 4164 chips of 64kbit capacity, in which case it would take 256k.
Alternatively, you could use two memory expansion cards to bring the memory up from 64k onboard to 640k total. Although I doubt many people would use such a contraption in practice.
Early model 5150s also required a BIOS upgrade, as a bug would prevent the BIOS from detecting more than 544k of installed memory.
So in theory it is possible to have a 5150 with 640k, and no doubt such machines exist in the wild. But it's probably far more common to find a 5155 or 5160 with 640k. So just like with 8088 MPH I guess that's the 'practical' target of the demo.
I wouldn't know if 'most of them' don't work, but I know for a fact that I have one (made by Vivanco, using a Prolific chip) that works fine in combination with my IBM 5160. I use it in combination with FastLynx, which still works even under Windows 11.
It's the only one I've tried, so I've not encountered any that didn't work.
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.