41–50 of 123 posts
Earlier quoted context omitted.
Your comment's html source code (the entire ) is also larger with its 380 bytes.
It always stings when I make a website/app pulled through all the optimizers and compression algorithms, and the content people fuck it all up by adding 10MB of images :/.
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…
Note your comment about how unimpressed you are is 214 bytes longer than the demo.
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…
It will be fun to replace "sleep 5 && echo ok" with an automated version of such writeup :)
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…
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 the default system palette.
The rendering is rather like a pixel shader. There is a big for loop over all the pixels, and at each point it computes a pixel value. First it decides which frame number it is on (stored in BP register I think), then calls an "effect" for that pixel.
It then jumps three pixels. This gives that nice "dissolve" transition between effects.
Keyboard controller is wired directly to the bus, so you can read the keyboard with a single instruction.
A MIDI controller is wired directly to address 0x330 (not standard equipment, back in the day this required a Roland card or SoundBlaster 32?), so you can just write MIDI to that.
There is a system timer interrupt configured for the music. The graphics appear to run continously, I can't see a link to the timer or vertical sync in the graphics code, that appears to just run continuously.
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
https://www.pouet.net/prod.php?which=78045
I ported it to a boot sector so you can run it with a single (rather long!) Linux command line in qemu:
https://rwmj.wordpress.com/2019/12/08/pyrit-by-rrrola-incred...
The source code for Pyrit is worth reading too (see first link). It's very clever and quite readable.
> 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…
That said, those demos are truly impressive.
> 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…
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 the lower two bytes are noise.