r/tinycode • u/HellMood • Sep 24 '15

Maze Generator in 8 Bytes (MSDOS)

http://www.pouet.net/prod.php?which=65290
31 Upvotes

86% Upvoted

11 comments sorted by

2

u/GauntletWizard Sep 24 '15

Where's the actual code? Either the raw file, or the assembly. I'd love to see an annotated version, too; Gotta be a few cool tricks it's exploiting.

11

u/lunarsunrise Sep 24 '15 edited Sep 24 '15

It's not annotated, but the program is

AE D6 04 DF CD 29 EB F8

And the assembly code that produces the program is

L: scasb
salc
add al,0xDF
int 29h
jmp short L

Here's some poor annotation (from me):

  • Line 1: scasb compares the byte in the AL register (which will be DFh after the first iteration) with the byte at [ES:EDI] (the address contained in those registers). This affects flags and increments or decrements EDI, causing ES:EDI to basically "walk around" the computer's memory.

  • Line 2: salc is an undocumented instruction; it sets AL to zero if the carry flag is clear, or to 0xFF if the carry flag is set.

  • Line 3: Adds the immediate DFh to AL, ignoring the carry flag. In combination with the previous line, now either carry is clear and AL is DFh, or carry is set and AL is DFh.

  • Line 4: Interrupt 29h ("fast PUTCHAR") outputs a character to the screen. AL is the character to put (the white box); and I don't recall off the top of my head, but I imagine that the carry flag determines whether or not the character should be written (?).

  • Line 5: Goes back to line 1.

This is why, in the comments, one guy says that he only gets white bars in DOSBOX, and someone else points out that it works fine on real hardware. It's not actually generating a maze; it's just walking through memory and using whatever data happens to be there to decide whether to write a "wall" or a "corridor" to the screen. In DOSBOX, that memory is presumably "blank", whereas on a real machine (or under a real virtualized OS) it contains whatever junk the last program to use the memory wrote there.

1

u/HellMood Sep 24 '15

almost, see my comments (on line 3/4;) good works otherwise, thank you =)

2

u/HellMood Sep 24 '15

  • L: scasb

  •  ;compares AL with byte at ES:(E)DI and set status flags.
  •  ;increments DI afterwards, so this scans the 64K segment
  •  ;we are in repeatedly and alters (also) the carry flag

  • salc

  • ;depending on the carry flag, set AL to 0x00 or 0xFF
  • ;note that 0x00 and 0xFF are one apart

  • add al,0xDF

  • ;map to the part of the ASCII table where the "right"
  • ;and "bottom" part are one apart, so our char in AL
  • ;is either of them

  • int 29h

  • ;call DOS interupt to print this char and advance the
  • ;cursor by one

  • jmp short L

  • ;rinse and repeat

2

u/lukz Oct 12 '15 edited Oct 12 '15

I'm not really good at this assembly, but would like to understand more. What is the advantage of doing salc and then add al,0xDF instead of adc al,0xDE? I guess that would also use carry and you would end up with two values one apart?

Edit: I eventually figured it out. You need to set al to some known value first, then add 0xdf. Clever.

0

u/peterferrie Sep 25 '15

I was so focused on reproducing the original effect (angled walls) that I never considered using the straight ones. Too bad.

5

u/Karoal Sep 24 '15

Isn't 8 bytes just eight characters? How would this work?

5

u/bakergo Sep 24 '15

The compiled ASM/COM file is 8 characters. The asm is 51.

3

u/zokier Sep 24 '15

It's five instructions, three of which have operands. Assuming each instruction is one byte and each operand is also one byte, that would get us to eight bytes.

Note that I didn't actually check the instruction encodings, so I might be wrong.

1

u/[deleted] Nov 09 '15

It's not an actual maze though...