256 byte MSDOS demo. Byte.

Previously, previously, previously, previously, previously, previously, previously, previously, previously.

Tags: , , , , ,

19 Responses:

  1. phuzz says:

    If you posted a screenshot of it running, the image would be larger than the code! Just flabbergasting.
    I wonder what hardware it needs to run? Would it run on a 386, or does it trade (modern) CPU speed for space?

    • Kyzer says:

      It runs on DOSBox and only DOSBox because it needs to make assumptions about initial register values to fit. There is also a version for FreeDOS (smaller but with no MIDI output) and a version for Windows XP's MS-DOS.

      • Derpatron9000 says:

        Are you sure?

        Oh my bad, i read too fast, you tried these. Okay, there might be more assumptions that don't work on your system. It worked for me on two notebooks with FreeDos and Windows XP, but i can only test the hardware i have :D


        • Kyzer says:

          Yes, I'm sure.

          $ head -13 memories2/memories.asm | tail -6
          ; CHOOSE YOUR TARGET PLATFORM (compo version is dosbox)
          ; be sure to use the dosbox.conf from this archive!
          ; only ONE of the defines should be active!
          %define dosbox ; size : 256 bytes
          ;%define freedos ; size : 230 bytes
          ;%define winxpdos ; size : 263 bytes

          • Derpatron9000 says:

            The demo does run on freedos and windows xp, the freedos build is smaller, the xp one understandably larger. Contrary to your response that the demo can't be run on real hardware, and the statement that it requires dosbox.

            • Kyzer says:

              "The demo", the one you're watching, is and is 256 bytes. You can see that from the first seconds of the video.

              The reason we're discussing this at all is because it won the Revision 2020 256b demo competition and has garnered worldwide acclaim. The rules of the competition required it to run on real hardware under FreeDOS with a "quite recent CPU" but no sound OR run emulated in DOSBox 0.74-3 with the default config. What we're watching is the latter.

              The only reason the demo meets the strict 256b limit is by making assumptions that only hold true in the DOSBox emulator. That demo does not run on real hardware.

              Another version of the demo, doesn't make those assumptions and so runs on real hardware... but it's 7 bytes larger, so wouldn't be in the competition, let alone win it, and you'd never have heard of it. We aren't watching that version.

              Another version of the demo, is also 7 bytes larger, but has the sound code stripped out (given the competition machine has no sound), making it 33 bytes smaller, so it could win the competition and run on real hardware... but as you can clearly hear on the Youtube video, we aren't watching this silent version.

              It seems the author will work on a more widely compatible version after testing with other people's hardware, but the version you're watching only works on an emulator. To the original requester's point, it's likely the 263 byte version should run on real hardware with FreeDOS and at least a 200MHz Pentium CPU and a MIDI device.

  2. Wout Mertens says:

    And here I was feeling pretty proud of once writing a 93 byte Mandelbrot set plotter...

    Btw the SARS-CoV-2 virus is 29k letters from a 4 letter alphabet, so it's about 7KB. Tiny code can change the world.

  3. deater says:

    it'll be interesting if they release the code to see how much BIOS/DOS code is called into. The tiny demos are impressive but sometimes they depend on a lot of external code (like the crazy 4k demos that depend on all of DirectX for the 3d) or having a lot of scratch RAM. x86 does give you an advantage, it allows really dense 16-bit code.

    I'm guilty of this too, my best effort is an Apple II 64-byte demo that cheats a bit and calls into the firmware text scrolling code to save a chunk of bytes.

    • jwz says:

      They did release the code, click the link.

      • deater says:

        you're right, sorry, I sometimes expect source to be a separate link on pouet rather than being included in the download

        so in this case the thing I'm mostly jealous of is the "imul" instruction which would take quite a few 6502 instructions. Also assuming a MIDI sound card is a huge benefit for DOS demos. And I also see at the end they're using 8087 floating point, extravagant luxury ;)

    • Jonathan says:

      I don’t know why you would describe that as cheating. Ultimately you have to rely on some other code, somewhere. Even initiating mode setting is leveraging a bunch of stuff you don’t have to write yourself.

      • deater says:

        as always it's a HW/SW tradeoff. Relying on microcode inside the CPU? Arguably mostly hardware. Relying on the boot firmware to init state? OK, acceptable. Relying on BIOS-like code that's more or less a software library that happens to be permanently in ROM? Pushing it. Relying on whatever software a default OS install puts on the hard-drive? Things start getting silly there. You could write a win95 64-byte demo that runs minesweeper, but would that count as a minesweeper-in-only-64-bytes demo?

        Usually this isn't a problem as the judges know enough to make some value judgement on whether something is enough of a hack or not to count as being cool. Unless you're working on an obscure platform where only 5 people in the world understand the tricks you pulled enough to be impressed.

        Anyway I have a lot of unpopular demoscene opinions. I also don't think you should really call something ANSI art that's wider than 80 columns (or maybe 132 if you're pushing it).

    • Kyzer says:

      For those too lazy to read the code, the answer is one call to change to mode 13h and one call to set an interrupt handler.

      In the case of MS-DOS 256b intros, their small size comes from there being zero overhead for the .COM format, and a tiny overhead to change screenmode and loop over linear one-byte-per-pixel screen memory, leaving you about 220 bytes to write an amazing pixel colouring function. And these days you're running on DOSBox on modern PCs so you can crank up the number of CPU cycles (compare 1999's wolf with 2009's puls). And x86 is itself an incredibly compact instruction encoding. However, that shouldn't take away from how tricky it is to write these and make something impressive, especially the hoops you have to go through if you have an amazing 280 byte effect and need to get it down to 256.

      There's nothing wrong with using Direct3D. This critique tends to come up every time size limits on demos are discussed. Every competitor has the same limits. 4k demos are not impressive because they can invoke a powerful GPU, it's what data they can generate for the GPU that's impressive. There are no hinterland geometries or banging tunes hiding in the graphics card driver.

      • jwz says:

        Yeah, I will never understand the "but that's cheating" crowd who show up for these things. Dude, I would be hard pressed to make something like this with 2 or 3 orders of magnitude more resources to work with, and I am sometimes regarded as being good at this shit.

      • deater says:

        the answer is one call to change to mode 13h and one call to set an interrupt handler.

        check out a VGA bios listing sometime, the int10h call to set mode 13h runs more bytes of code than this entire demo.

        I'm not saying this demo isn't impressive, it's just DOS demos have a huge advantage. There's the x86 code-density, 16-bit registers, the VGA bios/mode13h, the soundblaster/midi, the "imul" and "div" instructions, possibly an 8087 FPU, there's likely at least 1MB of RAM available if not possibly gigabytes of RAM, you might have up to GHz levels of CPU power.

        My talk of cheating had some implied smilies around it that didn't really come across.

        It just makes you despair if you're trying to do something useful in 256 bytes on a 1MHz 6502 with a video subsystem made up of 7400 series logic designed by a crazed genius who was more worried about saving a gate here and there than any sort of sane memory layout. Just getting a "fast" 16 bit multiply in this case often involves a 512 byte lookup table and nearly a thousand CPU cycles.

        And when you finally think you've done something impressive, the C64/Atari people come along and make fun of your graphics and the DOS people make fun of your code size.

        • Kyzer says:

          You have my sympathies. The MS-DOS environment has a lot of nice things for size coding competitions that other machines don't have, including the unlikely situation of a 1980s unitasking operating environment running on a 40 years newer CPU.

          Size-coding competitions can provide a shim to standardise and eliminate the essential overhead, see JS1k and Dwitter as an example. This is why demos shouldn't be compared cross-platform, even though people do because they love their machines. We have to accept each environment has different strengths and weaknesses, unless you want to start measuring demo size by gate count.

          Demosceners shine in many ways and love to cut the gordian knot. Why lament computing things legitimately when you can carefully pick inputs or get away with approximations instead?

  4. Kyzer says:

    The author has kindly written up how it works.

  • Previously