Good Apple (Bad Apple Remix) on the Soviet BK-0010/11M

I think it's the COVOX 8-bit thing. Not sure what the specs are, but if you can load samples and loops and set them off at specific intervals, you can accomplish a whole lot with almost no burden to the main computer.

Edit: nope. The COVOX was a parallel port DAC. The computer has to send each sample out. I suspect some light compression, pre-rendered audio segments and an interrupt-driven routine to get data from the HDD and send enough samples per second the sound doesn't get distorted.

It's unnecessary. We are running a:

  cpu
  which does abstraction and containers
  OS on top
  a container on top
  an application toolkit
  a cross platform development framework
  a browser embedded inside
  with containers
  with a javascript vm
  which runs framework
  which generates their own, non-standard UI widgets.

What am I gaining? Only more layers, and possible flaws

Oh, and don't get me started about all the languages

Good summary. A bit more generally, demos are often written to run under constrained conditions. They are also often written for competitions that set those conditions.

Sometimes, like in this case, the constraints are entirely dictated by the hardware, and the objective is just to make the most impressive demo given the particular device’s limitations, very often pushing the hardware way past what was commonly thought to be possible. Modifying the hardware is usually not allowed, but playing “dirty” in software by using undocumented and maybe even unintended, obscure implementation details of the platform is highly encouraged. No stone is left unturned.

8088MPH (by the same makers as 8088 Domination) is a very good example. For decades, nobody knew it would be possible to display 1024 colors, at the same time, on the original PC (which most nominally supports only 4 colors at the same time, which could be stretched to 8 with a trick). You can watch the demo here: https://youtu.be/yHXx3orN35Y And read about the methods used and invented here: https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-al...

Sometimes, there are also additional constraints like size limits, which is especially popular on more advanced hardware like modern PCs. For example, the objective could be to make the most impressive demo in 1024 bytes.

To add a little more commentary on why this is particularly impressive, they're more or less using the stock hardware, with the only "modifications" being some custom peripherals. But those peripherals still have to move data through the I/O ports of the original machine. The pouet comment by one of the authors says that it isn't even able to read data off of the IDE hard drive at 16kB/frame @ 30 fps (480kB/sec) because it's so slow.

On top of it, COVOX audio device requires the CPU to generate the sound and pulse it out of the parallel port where it acts as a DAC. Here it's generating a 22.725Khz stereo signal along with the hard drive I/O along with the computation required to decode the video stream and display it.

This machine is ~.5MIPS and is a clone of a PDP-11.

In demoscene conventions, this actually is a controversial production because it's technically a "video" and demoscene productions need to generate their display and run in real time. But there's lots of argument that the ability to harness this machine in the way they did is computationally impressive enough that there's some debate over it.

However there are some categories of demoscene works that also allow for these kinds of productions and the debate is really over how it was competed more than what it is.

For comparison, here's what games on the BK normally look like https://www.youtube.com/watch?v=-IOre6AAcGc

https://www.youtube.com/watch?v=X7zVVeirSdI&t=161s

> Bad Apple[1] is a famous Flash animation from ~10 years ago set to a pop song remix of a video game stage theme.

I just realized that the video can be summarized as "a downsampling of a parody of a music video of a remix of a song from a niche Japanese video game."

The internet is weird.

The clock might have been 4MHz, but the actual MIPS was only 0.5, IIRC.

The beauty of that cpu/architecture is that you could write in machine code easily, no assembly required. For example, MOV a constant to a pointer in memory was code 012737 with 01 denoting move command, 27 specifying the first operand as a constant residing in the memory immediately following that instruction, and 37 is specifying the second operand as a pointer, also in memory.

010102 was MOV register 1 to register 2.

I self-taught myself this while in the high school, because Basic was too slow there.

This simply is not correct - the scene is huge. If you think that, you're hanging out with the wrong crowd.

So many myths about what computing is and isn't -- I've not experienced anything remotely similar in any other field of human endeavor.