71–80 of 123 posts
On a related note: 2019, "Dope on Wax" was 1st in the PC 64k section. There is a breakdown of this demo on youtube, it's roughly ~2 hours. They explained how they made this demo. Really interesting to watch. Demo: https://www.youtube.com/watch?v=QhqT0DhV9yE Breakdown: https://www.youtube.com/watch?v=hFIyj5Yv440
Earlier quoted context omitted.
Note your comment about how unimpressed you are is 214 bytes longer than the demo.
Obviously he didn't do any 'tricks' to make it smaller.
Also, the tiny unpackers are generally used from 4096b and upwards. The size of the unpacker takes too much space and doesn't make up for the compression ratio at 256b.
Earlier quoted context omitted.
Wouldn’t that be 256^256? That’s certainly a hell of a haystack
Unreasonably impossible as of yet, yes. For handy reference: 8^8: 16,777,216 8^16: 281,474,976,710,656 8^32: 79,228,162,514,264,337,593,543,950,336 8^64: 6,277,101,735,386,680,763,835,789,423,207,666,416,102,355,444,464,034,512,896 8^128: ... 8^256: ? 8^512: hello from the other side of the quantum dimension 8^8 sounds interesting. 16 million reboots of a real {PC,C64,ST,Amiga,Mac,Z80,...} sounds like a collectively…
Not MS-DOS, but my favourite 256 byte demo is for the C64: "A Mind Is Born", check it out: https://www.youtube.com/watch?v=sWblpsLZ-O8 that music is astonishing.
Also discussed previously at https://news.ycombinator.com/item?id=14164907
Since these are so small I don't see why we couldn't have a "demoscene launcher" with a "mailto:" style protocol handler and just let people click on base64 encoded links to start the demo.
Let's see if HN accepts the URL:
https://floooh.github.io/tiny8bit/c64.html?prg=AQgLCB4AnjIwN...
Since these are so small I don't see why we couldn't have a "demoscene launcher" with a "mailto:" style protocol handler and just let people click on base64 encoded links to start the demo.
A handler for executing arbitrary code. What could possibly go wrong?
Can anyone describe at a high level for a complete noob how this kind of thing works? Someone who is not going to be able to read a bunch of ASM and interpret it? I'm guessing that it is something along the lines of: - the graphics "driver" reads values out of certain registers (AL and AH?) at a set interrupt (maybe every X clock cycles?) and writes one pixel to the screen of whatever color those registers had in the…
It gets much simpler when you realise that in the original PC there's no "driver" in the way but bits of hardware are wired directly to various processor buses. This is sixteen-bit assembly, so you have the famous 640kb of RAM available to the user and a 64k bit of RAM beyond that (see "0xa000" in the program). The graphics hardware is continuously rendering frames out of there at 320x200, one pixel per byte, using t…
Since these are so small I don't see why we couldn't have a "demoscene launcher" with a "mailto:" style protocol handler and just let people click on base64 encoded links to start the demo.
How do you handle time with such small code size? I see a timer interrupt for the music, but what about the animation? Is it dependent on the speed of the underlying CPU?
I haven't had a look at the source code for this, but I expect that it syncs with the screen refresh rate.
256 bytes is in the "let's try every combination" range, I think. So, write a program that tries all of them and determines if any do something interesting enough to forward to a human for review.