81–90 of 123 posts
Tiny binaries probably relied heavily on the native OS's system libraries.
Earlier quoted context omitted.
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…
Thats weird "reference". Why 8 as the base number? Nobody works with 3bit bytes. 8^8 == 2^24 == 2^(8 * 3) == 256^3, i.e. the combination space of three bytes . The smallest category in pouet for reference is 32b (or 256 bits), so 2^256 combinations to brute force. For comparison usually 128bit encryption is considered "safe" and infeasible to brute force. You might be able to constrain the search space to only valid…
It'd probably not constrain the search space nearly enough though.
But even if it did and you'd somehow manage to even generate every combination, you'd still face the second problem of how to evaluate if they do something "interesting enough" to be worthwhile reviewing.
The source code really looks like black magic. It's incredible they were able to cram the tunnel effect into 64 bytes [1]. The entire video is here [2], if you just want to watch the final product. EDIT: link fixed. [1] https://www.pouet.net/prod.php?which=85227 [2] https://www.youtube.com/watch?v=Imquk_3oFf4
There's something beautiful about the fact that the video is FAR larger in size than the program that initially generated the output. Almost worth watching for that fact alone.
Seems like this would be perfect for videos that are just e.g. gameplay of games made of tiles+sprites: the video could just store one copy of the assets, and the frames could just be tile maps + sprite position information.
It would also work well for “videos” that are really just a single static image. Or videos that are visualizations of the audio stream: the VM could actually take the audio frames as input and output the respective video frame.
I am always very impressed when I see these demos and how much can be done with so little. If you are like me you just jumped to Youtube[1] to see it in action. When trying to make my significant other to understand what was happening I wanted to run it myself. I was amazed how simple that was! - Install the assembler[2] - Install dosbox[3] - Get the source[4] and put it into c:\temp\demo\memories.asm - Start nasm an…
For macOS users (with brew): brew install dosbox nasm nasm memories.asm -fbin -o memories.com dosbox mount D ~/Development/memories (or whatever) D: memories So, almost the same! Hit FN+Ctrl+F12 to speed it up (it's time-independent, for smoother animations, hit that combination quite a few times). It didn't output any audio for me, but that's probably fixable.
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
It's wonderful. More impressed with this being 64k than the originally posted 256 bytes.
It's interesting that the demo scene is very Windows/DOS focused, unlike other hacker scenes. Linux or Mac demos are basically not a thing. You're far more likely to see C64 or Amiga demos.
Earlier quoted context omitted.
It's wonderful. More impressed with this being 64k than the originally posted 256 bytes.
PC64k is the main size constrained demo format, where people do seriously impressive things. 256b is the masochists category, where doing anything at all is hard. 4k intros are in between. It's interesting that the demo scene is very Windows/DOS focused, unlike other hacker scenes. Linux or Mac demos are basically not a thing. You're far more likely to see C64 or Amiga demos.
Normally these demos are filled with all kinds of 'tricks' to make things smaller. Things like self modifying code, using bits of the bios or video ROM in ways they weren't intended by jumping into the middle of them, saving space by using code as data or vice versa, tiny packers which compress or uncompress the code, massive pregenerated buffers to do runtime lookups to generate data in one order but use it in anoth…
- Jumping into the middle of video ROM and/or the BIOS
- Using substantial amounts of code as data
- Pregenerated buffers and data reordering
oooooo.
Earlier quoted context omitted.
A handler for executing arbitrary code. What could possibly go wrong?
We already allow arbitrary code to execute by clicking a link, in the form of JavaScript. You may argue that JS is sandboxed, but so is DOSBox. At least DOSBox can’t easily connect to remote servers over the internet.
Given that, it's not much of a sandbox.
Or does that require intervention from the host system rather than auto-mounting home and similar?
> In 320x200 mode, instead of constructing X and Y from the screen pointer DI with DIV, you can get a decent estimation with multiplying the screen pointer with 0xCCCD and read X and Y from the 8bit registers DH (+DL as 16bit value) and DL (+AH as 16bit value). The idea is to interpret DI as a kind of 16 bit float in the range [0,1], from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results…
This explanation was so confusing that I had to write a program to get it clear in my head. https://gistpreview.github.io/?9b252f267cd1fdf9754059bb73a18... More clearly: DI = (y * 320) + x Multiply by 0xCCCD => (y * 0x1000040) + (x * 0xcccd) Take top byte is equivalent to divide by 0x1000000. So that gives you Y. The next lower (third) byte is then (x * 0xcccd / 0x10000) == (x * 52429 / 65536) =~ (x * 256/320). And t…
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?
It depends on the speed of the CPU - if you look at the archive at https://www.pouet.net/prod.php?which=85227 , you'll find a DOSBox config specifically for this demo. If you run it in DOSBox you can fiddle with the emulation speed by pressing C-F11 and C-F12 and you'll notice the speed of the animation change. Later: Your question made me wonder what the performance of virtual 'target CPU' is - the 'cycles' setting…