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!