Pouet really doesn't make it obvious where to actually watch the demo. If anyone's confused, https://www.youtube.com/watch?v=8Q1vN51o-Dg is the place to be (unless you've somehow got the hardware to run their actual code).
Is the music also produced by the computer? I suppose that it is but it's hard to believe given the quality. Impressive work.
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.
That's kind of the awesome thing here, this machine isn't even capable of 1MIPs, so it has to pump audio out of the COVOX and read, decode and display the video.
From the pouet page from one of the authors:
"1. This computer has no DMA. We have to read all data "manually" from HDD registers, word by word. As well as switch heads, cylinders and sectors on fly.
2. This computer is very slow, it spends up to 72 CPU cycles to move a number from one memory cell to another. And it runs on 4 MHz only."
This is kind of shocking. Was the PDP-11 that bad?
I remember making a knock-off and having doubts if something this simple would work. But it did and it was absolutely magnificent. The PC stopped beeping and started making proper sounds. The sunset of the age of tangible computer wonders :)
I wonder what we might call such a convenient arrangement...
The frameworks make everything easier, more portable, more future-proof, more extensible, and quicker to develop. The only cost is that it's all slower and less elegant.
which does abstraction and containers
OS on top
a container on top
an application toolkit
a cross platform development framework
a browser embedded inside
which runs framework
which generates their own, non-standard UI widgets.
Oh, and don't get me started about all the languages
"easier, more portable, more future-proof, more extensible, and quicker to develop"? I mean, people aren't doing it this way simply out of incompetence or for the hell of it.
It's also something of a local minimum in the platform wars. We can't have truly cross-platform everything because the platform vendors wouldn't be able to take their cut. The only reason the web survives as a cross-platform platform is it's where they've fought each other to a standstill.
Free time to do something else but coding.
Or you get your own team and build the equivalent of a Subaru Rally car by investing a similar budget
Bad Apple is a famous Flash animation from ~10 years ago set to a pop song remix of a video game stage theme. Because it's so stylized there's a whole bunch of parodies / homages that imitate it. Here it's parodying old iTunes commercials.
There's another famous demoscene program named 8088 Domination that includes a version of the same song: https://youtu.be/_yTsCOy7j0M?t=168
Keep in mind while you're watching these videos that they're showing full-motion video and audio playback on a machine with single-digit Mhz of processing power. I like to think about this every time Slack pegs one of my cores to render an emoji.
The OP link says the program runs on a "BK-0010/11M" which Wikipedia says is a Soviet clone of the PDP-11. Looks like it's a popular platform on this demoscene gallery.
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:
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.
The old tricks of 160x100 pseudo-text mode and composite artifact colors both allowed for 16 colors at once when used in the obvious manner. 8088MPH reached 1024 colors by combining both tricks:
(yep you read it, that's 128 bytes; to give you an idead the tiniest GIF image is 26 bytes long). This post is 191 bytes long :-)
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
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.
They called me a hipster. :<
As such, it's a very impressive feat of coding prowess.
Compare and contrast with web "programming".
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.
I can imagine how inefficient it is to have every command take 3 bytes, kind of explain its slowness (but other 8-bit machines weren't much better in MIPS terms)
Surprisingly similar orthogonality to ARM.
4c 00 c0 jmp $c000
Growing up on the Commodore computers in a country with no access to originals, I've never seen original software for Commodore64 in my life.
The machine I did most of my 6502 stuff on was a BBC Micro, which had a basic assembler built in, so that really helped but the KIM-1 which I used before that was so sparse that even though an assembler existed I would have first had to expand the memory (big $back then). So memorize opcodes and use the handy 'opcode card' that you could get for those CPUs back in the day. No big deal, though I was really happy once I moved on to automating that part of the process. Especially branch calculation is tricky because if a branch is on a boundary you could fix it easily in something with macros but by hand it is hell because if the branch can't reach the target you need to invert the branch and then use a JMP, which requires more space, which may cause other branches to no longer reach their targets and so on.
Here is the original music video:
So many myths about what computing is and isn't -- I've not experienced anything remotely similar in any other field of human endeavor.
> I've not experienced anything remotely similar in any other field of human endeavor.
Similar to what?
Similar to mentality in any other profession.