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.

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.

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

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.

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

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.

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?

That is known to happen, yes: https://scalibq.wordpress.com/2015/08/09/fixing-genesis-proj...

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.

Not on the original PC/XT machines, as the ISA bus was basically the CPU data bus. So regardless of whether you had memory on board or on an ISA card, data transfers were exactly the same speed. On later machines, the CPU would be clocked faster than the ISA bus, so this was no longer true.

In short, textmode gives you 80x25 characters of 8x8 pixel resolution each, making 640x200 resolution, with 16-colours, where each character can be assigned a foreground and background colour. The 'Macrocom Method' reprograms the character height from 8 rows to 2 rows, which effectively gives you 80x100 characters. You can then use each of the 256 characters in the characterset as an 8x2 'glyph' with a foreground and background colour to build your images from. So you can't technically control the colour of every pixel on screen, but you can make a decent approximation with well-chosen character 'glyphs' and foreground/background colours.

This can also be automated with pattern-matching, where you convert an image to glyphs by algorithmically selecting the nearest match.

Correct, as "XT" stands for eXtended Technology. You can't extend it without having the basic technology first. The 5150, aka the PC, was that basic technology. However, in terms of CPU, graphics, sound and all other aspects relevant to this demo, the 5150 and 5160 are interchangeable.

The main differences between 5150 and 5160 are: 5160 upgraded from 5 to 8 ISA slots (also changing the size of the bracket, which has been the standard ever since, even today with PCI-e 5.0). 5160 removed the cassette port. 5160 came with a harddisk as standard (and as a result, a more powerful PSU, as the stock PSU of a 5150 was insufficient for a HDD, and generally required an upgrade).

Memory-wise, there are various different revisions of 5150 and 5160 boards, which can take different amounts of memory onboard. For the 5150, the early revisions took 16k-64k, the later revisions took 64k-256k. For the 5160, the early revisions took 64k-256k, the later revisions took 256k-640k. In all cases it is possible to add additional memory up to 640k via an ISA card. So it is possible to have a 5150 configuration with the full 640k that the most high-spec 5160 had.

Then there is also the IBM 5155, the 'portable' PC. This is essentially a 5160 motherboard in a modified case, with an integrated CRT. As such, it is also fully compatible with the 5150 and 5160, and can run these demos flawlessly.

That was how the predecessor 8088 MPH worked. Area 5150 however is aimed at a TTL RGBI monitor, and as such, does not use NTSC composite artifacting. It can only display 16 colours at once. So in this demo, you get 640x200 in 16 colours, where additional colours are implied by using dither patterns. (Technically 8088 MPH did more or less the same, except these 'dither patterns' would result in NTSC artifact colours).

Yes, originally CGA and MDA at the same time. Hercules was a non-IBM standard, based on MDA. Hercules has 64k of memory, where 32k is in the area of MDA, and the second 32k overlaps with the CGA area. You could disable the second 32k when you had a CGA card in your system. EGA and VGA were also made backwards compatible, and could co-exist with an MDA or Hercules card.

The demo Stars by NoooN (https://www.pouet.net/prod.php?which=301) has an easter egg for a combination of VGA and MDA/Hercules: on the monochrome screen, a Snake game appears, which can be played via keyboard while the demo is running.

This was in the context of using the video as a texture. As I tried to explain, the RGB texture formats with 8-bit precision use 32-bit words. There are no 24-bit formats available as a texture format. NV12 is also a native texture format, so it makes sense to compare these two formats in this context.

I would like to nuance that by saying it's nice if you have a good deal of domain knowledge, but my article focuses more on the case where you venture into new territory, and the architect is the person who needs to obtain the required domain knowledge.

In my 20+ years of work experience, I rarely worked on projects where I had all the relevant knowledge beforehand. Most of the time, it was 'learning on the job'. For example, I once worked on the software for an automated orchid greenhouse. Now how many software architects would have domain knowledge of growing, categorizing and shipping orchids? It's the client who had the domain knowledge, and as an architect I had to extract the relevant information from them, and translate it to a software context.

I never did anything with flowers since, so that domain knowledge was never used again. It was like that for most of my projects.

In theory emulators recreate the hardware in software. In practice, emulators approximate the hardware in software. In the case of PCs, there is so much hardware variation, that it was never a requirement to be very accurate in terms of speed, unlike machines such as the C64, Amiga, Atari ST, NES and various other machines, where many tricks found in games and demos depend on manipulating specific hardware registers in very specific timeframes.

This demo has various effects that depend on the exact speed of the CPU and hardware. No PC emulator is anywhere near that accurate, leading to effects not working correctly, or just hanging altogether (eg the end-tune depends on instructions being in the prefetch-buffer at a specific time).

Another issue was the 1k colour effect, which exploits the way the NTSC signal is generated. Most emulators didn't emulate NTSC composite very accurately (just treating it as a 16-colour mode).

The timing in this demo is so critical, that even most clones with an 8088 at 4.77 MHz and a CGA-compatible clone card do not play the demo correctly.

The artifact colours are quite off as well, so I suspect the card used was not a real IBM CGA card. On my ATi Small Wonder and Paradise PVC4 cards, I get the exact same Kefrens bars, with the top chopped off.

Having said that, the fact that the music slows down noticeable during the moire-effect seems to indicate that indeed some instructions are a few cycles off here and there.

Yes, CGA has an RCA connector on the back for NTSC composite. This is what we used for the demo. There is also a header on the card itself, to which an RF modulator can be connected, for a regular TV antenna input (this was an option, probably because of regulations. An RF modulator generates a lot of interference, so fitting one stock would require expensive shielding. Fitting it 'aftermarket' circumvents that). The IBM 5155 portable PC abuses this header to connect the composite signal to an internal monochrome CGA monitor.