dmi đź’˝ the 16 byte DOS demo from #revision2026 running on real hardware
holy… HOW
RafiX
moth
root42@mothcompute I would have assumed that ES is b800, as it needs to write into text memory...? So yes, the values it reads from the stack need to be somewhat correct to overlap with the VGA text memory. Someone needs to inspect this!
@root42 nope, es is initialized to AB48 (from the instruction bytes from dec ax) whose range still covers all of text memory. it relies on the com starting with si = 100h; the stack isnt used
@root42 i have a cleaner disassembly here https://merping.synth.download/@mothcompute/116349107154007075
mothcompute (@[email protected])
``` ;si=0x100 https://www.pcjs.org/documents/misc/DOS_COM_Startup_Registers.pdf s: les ax,word [si] ; es = [s+2] -> 0xAB48 l: dec ax stosw ;es:[di]=ax add ax,[es:di-82] add ax,[es:di] shr ax, 2 jmp l ```
Matteo Beniamino / Prestissimo@mothcompute @root42 The other clever trick I see here, if I understand the code correctly (I'm not really an assembly guy) is that the code sums two integers and divides the result by 4: this way no matter what you find in memory at the start, you'll sooner or later arrive to 0, and when you decrement ax you restart from 65535, converging to the same pattern no matter what.
@prestissimo yes. And the 82 backwards gives the motion to the upper left. It’s a little bit like the classic fire effect where you average and decrement values from the line below.
Edit: i would have assumed the offset should be 162 (2 bytes per character), but it seems they take the character halfway down the line to the left…
Edit: i would have assumed the offset should be 162 (2 bytes per character), but it seems they take the character halfway down the line to the left…
@prestissimo I have tried out with offset 162, and it works, too. Looks slightly different, but maybe that's what they were originally going for...? not sure!
Leszek
rasteri
divVerent@[email protected] @[email protected] Insane.
I mean, sure, it's just a PRNG writing into video RAM... but still very cool to get it done that short.
My attempt at decompiling (correct modulo the mistakes):
Basically a base-65536 linear shift register of length 32768. Part of which covers the 2048 entries of video memory area from segment 0xB800, and some other random memory that's safe to write and simply does nothing in the usual case.
(I had to take freedom to make d an uint15_t to get the wraparound where needed)
The cool part is of course where the pointer into video RAM (in the original assembly the value of the ES register) comes from:
As SI starts at 0100, this will read AX from C4 04 (i.e. 04C4), and ES from the two following bytes 48 AB (AB48) - i.e. from its own machine code which happens to have the right bytes there. The STOSW is critical. This is technically part of the graphics mode video RAM A000-AFFF, however as the code writes an entire 64k block from there, also covers any segemnts until BB47, which in particular covers both the monochrome text mode video RAM from B000 to B7FF and the "interesting part" of color text mode video RAM from B800 to BFFF.
I mean, sure, it's just a PRNG writing into video RAM... but still very cool to get it done that short.
My attempt at decompiling (correct modulo the mistakes):
uint16_t *base = 0xAB480;
base[0x7FFF] = 0x04C3;
for (uint15_t d = 0; ; ++d) {
base[d] = (base[d - 1] + base[d - 0x29] + base[d]) >> 2 - 1;
}Basically a base-65536 linear shift register of length 32768. Part of which covers the 2048 entries of video memory area from segment 0xB800, and some other random memory that's safe to write and simply does nothing in the usual case.
(I had to take freedom to make d an uint15_t to get the wraparound where needed)
The cool part is of course where the pointer into video RAM (in the original assembly the value of the ES register) comes from:
0x0000000000000100: C4 04 les ax, ptr [si]
0x0000000000000102: 48 dec ax
0x0000000000000103: AB stosw word ptr es:[di], axAs SI starts at 0100, this will read AX from C4 04 (i.e. 04C4), and ES from the two following bytes 48 AB (AB48) - i.e. from its own machine code which happens to have the right bytes there. The STOSW is critical. This is technically part of the graphics mode video RAM A000-AFFF, however as the code writes an entire 64k block from there, also covers any segemnts until BB47, which in particular covers both the monochrome text mode video RAM from B000 to B7FF and the "interesting part" of color text mode video RAM from B800 to BFFF.
LR
jn (big endian energy)@domi @lritter @RafiX oh, executable MD5 hashes with a known and meaningful input would be kind of possible, maybe
reminds me of https://shells.aachen.ccc.de/~spq/md5.gif
Haelwenn /элвэн/ 