Dag Ågren ↙︎↙︎↙︎
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 /элвэн/ 
Efi (nap pet) 🦊💤@domi a 16 byte payload for some kind of interpreter, I assume
snow 
@snow i’m not good at it either! we can learn together! :D
i have started hacking up a demo for bash with graphics (yeah) and audio (… yeah), but i’m fine with virtually any platform :D
Shiz
Eloy.
@domi @snow so technically I have *two* at RevSpace, a PC-9821Ap and a PC-9801VX :>
and some years ago I started writing a basic graphics library for the GDC/GCRG/EGC: https://codeberg.org/shiz/gfxi
it's not much (yet), but it's a start?
ev
DeltaLima 🐧@domi so no dosbox bug used as suspected in the stream
natalie[ee]@domi this looks like a frame from Hackers (1995)
moralrecordings@domi The code:
- Sets ES:AX to *[DS:SI]. For a COM exe in DOSBox this resolves to AB48:04C4.
- Thanks to real mode, segment AB48 happens to include all of B800:0000 - B800:0FA0, AKA the text display buffer.
- The code loops through every 16-bit word in segment AB48
- AX is incremented by current word + the word 82 spaces behind (AKA one full horizontal screen row + 2)
- AX is divided by 4
- AX is decremented by 1
- AX is stored into ES:DI, DI is incremented by 2
Result: a moving, fading pattern
- Sets ES:AX to *[DS:SI]. For a COM exe in DOSBox this resolves to AB48:04C4.
- Thanks to real mode, segment AB48 happens to include all of B800:0000 - B800:0FA0, AKA the text display buffer.
- The code loops through every 16-bit word in segment AB48
- AX is incremented by current word + the word 82 spaces behind (AKA one full horizontal screen row + 2)
- AX is divided by 4
- AX is decremented by 1
- AX is stored into ES:DI, DI is incremented by 2
Result: a moving, fading pattern
Joan AM