SizeCoding - User contributions [en]

Case Studies

2021-03-13T17:58:57Z

Qkumba: fix broken link

Sometimes it can be helpful to examine a tinyprog in detail, seeing what choices were made and why:

:[[MELT.COM]]: We take a cute program from the 1980s and see how far we can crunch it down

:[[m8trix 8b]]: An "Enter The Matrix" screen display in only 8 bytes

:[[4is256]]: Řrřola's Tetris is a full tetris clone with scoring

:[[paint16b]]: Hellmood's paint program in 16 bytes (really)

:[[Indian Spirit]]: An American Indian tapestry with music in 32 bytes

:[[Essence]]: Fakery of path tracing and lighting, with audio, in 64 bytes

:[[Memories]]: Detailed writeup on [https://www.pouet.net/prod.php?which=85227 "Memories" (256 bytes)]

:[[Game of Life 32b]]; Writeup for game of life in 32 bytes

== External Case Studies ==

[https://en.wikipedia.org/wiki/Brainfuck Brainfuck] is a very tiny language, having only 8 commands and an instruction pointer. Several compilers and interpreters have been made; Gynvael archived [http://gynvael.coldwind.pl/bf125/ many different versions along with their source code], the smallest of which was 125 bytes. qkumba took that as inspiration and created his own [http://pferrie.epizy.com/misc/tiny/brainfck.htm brainfuck compiler in 100 bytes] (104 for one that is fully compliant). (Note: The term "compiler" is used mistakenly a lot in these descriptions; the majority of brainfuck programs are actually interpreters that load brainfuck programs and execute native code token by token. This one is an exception in that it really does compile the code entirely into native instructions first.)

[https://revival-studios.com/marquee/blog/blog_homogenic.html Small Beginnings: The development of Homogenic] Development Write up on [https://www.pouet.net/prod.php?which=84537 Homogenic, by: Marquee Design (256 bytes)]

[https://revival-studios.com/marquee/blog/blog_nanorail.html Moving on: The development of Nanorail] Development Write up on [https://www.pouet.net/prod.php?which=84624 Nanorail, by: Marquee Design (256 bytes)]

[https://revival-studios.com/marquee/blog/blog_enigma.html Full Circle: The development of Enigma] Development Write up on [https://www.pouet.net/prod.php?which=85232 Enigma, by: Marquee Design (256 bytes)]

[https://revival-studios.com/marquee/blog/blog_microdose.html Crunching content: The development of Microdose] Development Write up on [https://www.pouet.net/prod.php?which=85677 Microdose, by: Marquee Design (128 bytes)]

[https://abaddon.hu/crevenge/history.html The long journey to 1k real-time ray-tracing] Detailed technical writeup on [https://www.pouet.net/prod.php?which=87078 Chrome Revenge by Abaddon (1024 bytes)]

[http://canonical.org/~kragen/demo/fr-016.html Disassembly of Farbrausch's "fr-016: bytes"]

[http://canonical.org/~kragen/demo/klappquadrat.html A disassembly of the 64-byte version of Klappquadrat]

[https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ Maze generation in 10 bytes]

MELT.COM

2016-08-15T04:37:17Z

Qkumba:

[[Category:Case Study]]
MELT.COM was written by an unknown author in the 1980s. Originally 49 bytes in size, it performs the following cute effect:

{{#ev:youtube|https://www.youtube.com/watch?v=MoGKh5X3nS4}}

(The video is simulated and shows how MELT performs on the old hardware it was written for.) This effect is achieved by increasing or decreasing each onscreen character's value until it reaches #32, the space character. The original source is lost to history, but here's a quick commented disassembly:

<syntaxhighlight lang=nasm>
org 100h

mov ax, 0B800h
mov es, ax ; es now points to screen segment

doScreen:
mov cx, 2000 ; Going to loop over all (80*25=)2000 characters
xor bx, bx ; bx = 0. Also our "num of altered chars" counter
mov di, bx ; es:di now points at the screen (b800:0000)

alterChars:
mov ah, es:[di] ; Retreive onscreen character
cmp ah, 32 ; comp to a space character (#32)
jz short nextChar ; If already a space, do nothing
jl short upToSpace ; If lower than a space, increase upward
dec ah ; If higher than a space, decrease downward
mov es:[di], ah ; Store altered character back to screen
inc bx ; increase "number of processed chars" counter
jmp short nextChar ; Keep processing characters

upToSpace:
inc ah ; Increase character upwards towards a space
mov es:[di], ah ; Store altered character back to screen
inc bx ; increase "number of processed chars" counter

nextChar:
inc di
inc di ; es:di now points to next character
loop alterChars ; Continue processing characters
cmp bx, 0 ; Were any characters processed?
jnz short doScreen ; If so (bx != 0), keep processing
mov ah, 4Ch ; Otherwise, get ready to terminate
int 21h ; DOS - 2+ - QUIT WITH EXIT CODE (EXIT)
</syntaxhighlight>

There are some very quick wins right off the bat:

* AX is already 0, so set AX=B800 by setting AH=B8
* Replace DOS exit sequence with RET, since this is a .COM file
* The "CMP bx,0" can be replaced with a shorter test like "OR bx,bx"
* There is inefficient loading and saving of screen characters with manually advancing DI twice -- 80x86 has 1-byte string instructions to do that, so we'll use LODSW and STOSW. This will load the character attribute byte redundantly, but we don't care about speed, we care about size. Because we only use LODS once, we can shave a byte by getting rid of MOV DS,AX (3 bytes) and using ES: LODS (2 bytes) in the inner loop.

This shaves 12 bytes down to 37 total. At this point we can make some drastic changes that will shave bytes, but also make the program not behave ''exactly'' as it did before. I chose to do the following:

* 2000 is 7D0 in hex. Change MOV CX,2000 (decimal) to MOV CH,08 (hex) to shave a byte. This could result in CX being anywhere in the range 0800 to 08FF but the difference is minimal at execution time. It's also larger than the original area, but that is fine since there is there is extra screen RAM after the visible portion of the screen.
* The code contains a check for characters below #32 (space) and moves them upward. Most characters onscreen are going to be above #32, so this isn't really necessary and I removed the check. Even if it were necessary, removing the check will just rotate them downward until they wrap around to 255, then go downward again until hitting #32 and stopping.

This gets the code down to 29 bytes:

<syntaxhighlight lang=nasm>
org 100h

mov ah, 0B8h
mov es, ax ; es so we can use es: LODS and STOS to the same place

doScreen:
mov ch, 08 ; (80 * 25 = 2000/07d0h)
xor bx, bx ; bx is also our "num of altered chars" counter
mov di, bx ; es:di now points at the screen (b800:0000)
mov si, di ; ds:si = es:di, needed for lods/stos

alterChars:
es: lodsw ; Retreive onscreen character
cmp al, 32 ; comp to a space character (#32)
jz short nextChar ; If already a space, do nothing
dec al ; If higher than a space, decrease downward
inc bx ; increase "number of processed chars" counter

nextChar:
stosw
loop alterChars ; Continue processing characters
or bx,bx ; Were any characters processed?
jnz short doScreen ; If so (bx != 0), keep processing
ret ; exit

</syntaxhighlight>

Optimizing the above is left as an exercise to the reader. It may be possible to shrink it further using instructions for the 80186 and later processors, but it runs way too quickly on those systems, so if doing so you may want to insert a HLT to pace the animation at 18.2 Hz. It may also be possible to shrink it by taking advantage of the fact that ASCII character #0 is a null and shows nothing onscreen (just like the #32 space character), so instead of decrementing down to #32, you could decrement down to #0 in a more optimized form (like using the zero flag).

== Or you could rethink it completely ==

If you're willing to deviate from the original target environment (namely, that it was designed for a 4.77 MHz 8088), you can eliminate range checking for all sorts of optimizations.
Instead of using two pointers/segments, it's possible to use only one, and directly operate on the chars on screen. Combined with optimized segment assignment and exclusion of the "processed chars"-count (fixed amount of iterations, set to the maximum possible 65536 * 255) this results in a 17 byte variation :

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "nop" = 0AF90h
nop ; for alignment, maybe optimization potential here ;)
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],32 ; is the current char on screen a "space"?
jz short skip ; yes, don't decrement
dec byte [di] ; nope, decrement
skip:
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

The above performs the same function as the previous optimization, but runs much more slowly as it traverses more RAM areas than necessary.

There might be a way of altering the <code>NOP</code> to something useful.

Returning to the non-printing null char, we can shave one more byte, to produce this 16 bytes version:

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "nop" = 0AF90h
nop ; for alignment, maybe optimization potential here ;)
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],al ; is the current char on screen a "null"?
jz short skip ; yes, don't decrement
dec byte [di] ; nope, decrement
skip:
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

The above performs a similar function as the previous optimization, but runs even more slowly as it requires regular characters to be decremented further than before.

Note the <CODE>CMP/JZ/DEC</CODE> sequence. If we can control the carry flag as a result of the comparison, then we can perform a conditional decrement without the branch, via an <CODE>ADC</CODE>.

Of course, if the AL register is zero, then there can never be a carry as a result of the comparison, but if we increase AL to 1, then every value other than zero will clear the carry.

To increase the AX register would normally cost us one byte, but we happen to have one to spare in the <CODE>LDS</CODE> alignment.

That allows us to shave one more byte, to produce this 15 bytes version:

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "inc" = 0AF40h
inc ax ; set AL to 1, also for alignment
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],al ; is the current char on screen a "null"?
adc byte [di],ff ; if not, then decrement
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

MELT.COM

2016-08-15T04:33:13Z

Qkumba: 15 bytes MELT

[[Category:Case Study]]
MELT.COM was written by an unknown author in the 1980s. Originally 49 bytes in size, it performs the following cute effect:

{{#ev:youtube|https://www.youtube.com/watch?v=MoGKh5X3nS4}}

(The video is simulated and shows how MELT performs on the old hardware it was written for.) This effect is achieved by increasing or decreasing each onscreen character's value until it reaches #32, the space character. The original source is lost to history, but here's a quick commented disassembly:

<syntaxhighlight lang=nasm>
org 100h

mov ax, 0B800h
mov es, ax ; es now points to screen segment

doScreen:
mov cx, 2000 ; Going to loop over all (80*25=)2000 characters
xor bx, bx ; bx = 0. Also our "num of altered chars" counter
mov di, bx ; es:di now points at the screen (b800:0000)

alterChars:
mov ah, es:[di] ; Retreive onscreen character
cmp ah, 32 ; comp to a space character (#32)
jz short nextChar ; If already a space, do nothing
jl short upToSpace ; If lower than a space, increase upward
dec ah ; If higher than a space, decrease downward
mov es:[di], ah ; Store altered character back to screen
inc bx ; increase "number of processed chars" counter
jmp short nextChar ; Keep processing characters

upToSpace:
inc ah ; Increase character upwards towards a space
mov es:[di], ah ; Store altered character back to screen
inc bx ; increase "number of processed chars" counter

nextChar:
inc di
inc di ; es:di now points to next character
loop alterChars ; Continue processing characters
cmp bx, 0 ; Were any characters processed?
jnz short doScreen ; If so (bx != 0), keep processing
mov ah, 4Ch ; Otherwise, get ready to terminate
int 21h ; DOS - 2+ - QUIT WITH EXIT CODE (EXIT)
</syntaxhighlight>

There are some very quick wins right off the bat:

* AX is already 0, so set AX=B800 by setting AH=B8
* Replace DOS exit sequence with RET, since this is a .COM file
* The "CMP bx,0" can be replaced with a shorter test like "OR bx,bx"
* There is inefficient loading and saving of screen characters with manually advancing DI twice -- 80x86 has 1-byte string instructions to do that, so we'll use LODSW and STOSW. This will load the character attribute byte redundantly, but we don't care about speed, we care about size. Because we only use LODS once, we can shave a byte by getting rid of MOV DS,AX (3 bytes) and using ES: LODS (2 bytes) in the inner loop.

This shaves 12 bytes down to 37 total. At this point we can make some drastic changes that will shave bytes, but also make the program not behave ''exactly'' as it did before. I chose to do the following:

* 2000 is 7D0 in hex. Change MOV CX,2000 (decimal) to MOV CH,08 (hex) to shave a byte. This could result in CX being anywhere in the range 0800 to 08FF but the difference is minimal at execution time. It's also larger than the original area, but that is fine since there is there is extra screen RAM after the visible portion of the screen.
* The code contains a check for characters below #32 (space) and moves them upward. Most characters onscreen are going to be above #32, so this isn't really necessary and I removed the check. Even if it were necessary, removing the check will just rotate them downward until they wrap around to 255, then go downward again until hitting #32 and stopping.

This gets the code down to 29 bytes:

<syntaxhighlight lang=nasm>
org 100h

mov ah, 0B8h
mov es, ax ; es so we can use es: LODS and STOS to the same place

doScreen:
mov ch, 08 ; (80 * 25 = 2000/07d0h)
xor bx, bx ; bx is also our "num of altered chars" counter
mov di, bx ; es:di now points at the screen (b800:0000)
mov si, di ; ds:si = es:di, needed for lods/stos

alterChars:
es: lodsw ; Retreive onscreen character
cmp al, 32 ; comp to a space character (#32)
jz short nextChar ; If already a space, do nothing
dec al ; If higher than a space, decrease downward
inc bx ; increase "number of processed chars" counter

nextChar:
stosw
loop alterChars ; Continue processing characters
or bx,bx ; Were any characters processed?
jnz short doScreen ; If so (bx != 0), keep processing
ret ; exit

</syntaxhighlight>

Optimizing the above is left as an exercise to the reader. It may be possible to shrink it further using instructions for the 80186 and later processors, but it runs way too quickly on those systems, so if doing so you may want to insert a HLT to pace the animation at 18.2 Hz. It may also be possible to shrink it by taking advantage of the fact that ASCII character #0 is a null and shows nothing onscreen (just like the #32 space character), so instead of decrementing down to #32, you could decrement down to #0 in a more optimized form (like using the zero flag).

== Or you could rethink it completely ==

If you're willing to deviate from the original target environment (namely, that it was designed for a 4.77 MHz 8088), you can eliminate range checking for all sorts of optimizations.
Instead of using two pointers/segments, it's possible to use only one, and directly operate on the chars on screen. Combined with optimized segment assignment and exclusion of the "processed chars"-count (fixed amount of iterations, set to the maximum possible 65536 * 255) this results in a 17 byte variation :

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "nop" = 0AF90h
nop ; for alignment, maybe optimization potential here ;)
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],32 ; is the current char on screen a "space"?
jz short skip ; yes, don't decrement
dec byte [di] ; nope, decrement
skip:
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

The above performs the same function as the previous optimization, but runs much more slowly as it traverses more RAM areas than necessary.

There might be a way of altering the <code>NOP</code> to something useful.

Returning to the non-printing null char, we can shave one more byte, to produce this 16 bytes version:

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "nop" = 0AF90h
nop ; for alignment, maybe optimization potential here ;)
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],al ; is the current char on screen a "null"?
jz short skip ; yes, don't decrement
dec byte [di] ; nope, decrement
skip:
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

The above performs a similar function as the previous optimization, but runs even more slowly as it requires regular characters to be decremented further than before.

Note the <CODE>CMP/JZ/DEC</CODE> sequence. If we can set the carry flag as a result of the comparison, then we can perform a conditional decrement without the branch, via an <CODE>ADC</CODE>.

Of course, if the AL register is zero, then there can never be a carry as a result of the comparison, but if we increase AL to 1, then every value other than zero will set the carry.

To increase the AX register would normally cost us one byte, but we happen to have one to spare in the <CODE>LDS</CODE> alignment.

That allows us to shave one more byte, to produce this 15 bytes version:

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "inc" = 0AFh
inc ax ; for alignment
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],al ; is the current char on screen a "null"?
adc byte [di],ff ; if not, then decrement
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

Resources

2016-08-14T22:54:48Z

Qkumba:

== Discussions ==

Pouet's [http://www.pouet.net/topic.php?which=8791&page=1 Tiny Intro Toolbox Thread] was one of sizecoding.org's main inspirations.

== References ==

The Hugi demoscene diskmag has been kind to the sizecoding movement. They included [http://www.hugi.scene.org/online/coding/hugi%20se%204%20-%20index%20sorted%20by%20topic.htm many programming articles] since it started in 1996. Additionally, the [http://www.hugi.scene.org/compo/compoold.htm Hugi Size Coding Competition Series] is the gold standard for learning how to sizecode: Each competition was given a specific task, then participants submitted their results. ([http://retrolandia.net/hugi/showthread.php?tid=7&pid=13#pid13 All of the entries with their source code] are available, as are [http://retrolandia.net/hugi/showthread.php?tid=7&pid=396#pid396 the rules for each challenge].) Hugi #35 also provided a [http://hugi.scene.org/online/hugi35/hugi%2035%20-%20demoscene%20forum%20adok%20256b%20intros%20round-table.htm 256b intros round-table] between Baze, Digimind, Řrřola, Pirx, Optimus, and Seven.

fysnet.net has an extensive [http://www.fysnet.net/yourhelp.htm list of DOS .COM register starting values]. If your environment isn't listed, [http://www.fysnet.net/yourhelp.com a program] is also available that can print out all of the register starting values. See also [http://pferrie.host22.com/misc/lowlevel12.htm DOS Register Starting Values] to understand why the register starting values for .COM files are set the way that they are.

The [http://sparksandflames.com/files/x86InstructionChart.html Sparks And Flames x86 Instruction Chart] is awesome, once you can "read" it. Find out what the bright green (1-byte) commands do, and use them. For the extreme sizecoding (<=32 bytes) it's also very useful to have the HEX value in sight.

The [http://ref.x86asm.net/geek.html Geek Edition x86asm-ref] is comprehensive and dense. It might be the only reference you'll need. The last part covers modr/m bytes, which is useful.

[http://x86.renejeschke.de/ Rene Jeschke's preservation of siyobik.com's x86 Documentation] is one of the most compact and understandable references to the x86 instruction set you'll ever see.

[http://www.rcollins.org/secrets/OpCodes.html Robert Collins' Undocumented Opcodes] page has some gems you can exploit depending on your target environment.

[http://wiki.osdev.org/PC_Speaker PC Speaker Basics] For everything from simple bleeps to sophisticated synthesizers.

[https://de.wikipedia.org/wiki/Program_Segment_Prefix Program Segment Prefix] : whats in front of our code, and why.

Never underestimate [http://www.hugi.scene.org/online/coding/hugi%2017%20-%20coaax.htm The Hidden Power of BCD Instructions].

[http://wiki.osdev.org/Programmable_Interval_Timer Programmable Interval Timer] : timing is everything.

[http://stanislavs.org/helppc/bios_data_area.html BIOS data area] : direct system communication overview

[https://www.midi.org/specifications/item/table-1-summary-of-midi-message Summary of MIDI messages] : Summary of MIDI messages

== Repositories ==

Tinyprogs are so small that you sometimes don't need the source code to understand them: Just pop them into a disassembler (like IDA) or a debugger and look at them. If you want to grab specimens for study, here are some places to start.

Pouet can be searched for the latest tinyprogs: [http://www.pouet.net/prodlist.php?type%5B%5D=256b&platform%5B%5D=MS-Dos&page=1 256b], [http://www.pouet.net/prodlist.php?type%5B%5D=128b&platform%5B%5D=MS-Dos&page=1 128b], [http://www.pouet.net/prodlist.php?type%5B%5D=64b&platform%5B%5D=MS-Dos&page=1 64b], and even [http://www.pouet.net/prodlist.php?type%5B%5D=32b&platform%5B%5D=MS-Dos&page=1 32b and smaller].

[http://hardcode.untergrund.net/ HardCode] is a repository of 7800 64KB and smaller intros.

[http://256bytes.untergrund.net 256b.com] is a website dedicated primarily to 256b and smaller releases.

General Coding Tricks

2016-08-14T22:47:09Z

Qkumba:

== Data is code, code is data ==

Code is nothing more than data that the CPU interprets. For example, consider this multi-byte instruction:

<syntaxhighlight lang=nasm>
mov ah,37h
</syntaxhighlight>

This assembles to <code>B4 37</code>. <code>B4</code> by itself isn't interesting, but <code>37</code> happens to be the opcode for <code>AAS</code>. Let's say you had this code before a loop, and you needed to perform <code>AAS</code> at the top of a loop. Rather than put AAS at the top of the loop, you can reuse the opcode that will already be there as part of the <code>mov ah,37</code> that comes before it. Just jump directly into the middle of the <code>mov ah,37h</code>, which will get interpreted and executed as <code>AAS</code>:

<syntaxhighlight lang=nasm>

label:
mov ah,37h
;misc. stuff
loop label+1
</syntaxhighlight>

The <code>+1</code> specifies the jump should go to 1 byte past the actual location.

=== Reuse ===

You can use opcodes hidden in your existing data. For example, .COM files can end with <code>RET</code>, which is opcode <code>C3</code>. If you already have a <code>C3</code> somewhere else in your code, even as part of data, just <code>JMP</code> to that pre-existing <code>C3</code> instead of adding a <code>RET</code>.

== If your environment holds you back, change it ==

The [https://en.wikipedia.org/wiki/Video_Graphics_Array#/media/File:VGA_palette_with_black_borders.svg default MCGA palette] is fairly horrible, but can be size advantages to changing it: While setting a new palette costs bytes, the new palette arrangement could save you headaches down the road. For example, if your code is calculating pixel colors that fall into goofy ranges, rather than constantly adjust the colors to sane ranges (ie. aligned to powers of 2), just set the palette so that values falling into those ranges look the way you want. (This assumes you have very small ways of redefining the palette, of course.)

The above is maybe not the best example. Rewrites to this section are welcome.

== Need a constant? ==

If you need a constant value but you're out of space, search your assembled code for a byte value you can use.

== A smaller way to point to Mode 13's screen segment ==

Rather than <code>mov ah,0a0h; mov es,ax</code> or <code>push word 0a000h; pop es</code>, try this 2-byte wonder:

<syntaxhighlight lang=nasm>
les bp,[bx]
</syntaxhighlight>

This sets ES=9FFF, only one away from A000. You can write to the screen with ES: this way as long as you are aware the segment is one paragraph (16 bytes) behind, so just increase your offset by 16 if you need exact placement.

How does this work? At start of execution of a .COM file, BX=0, and DS=CS. The contents of the COM file get loaded to offset 0x100 in that segment, but loaded before that is the PSP (program segment prefix), which DOS populates with information about the loaded program and other info. The PSP starts with <code>CD 20</code> (<code>INT 20</code>, which exits the program), so that's what gets loaded into BP. The next word is the number of the last free conventional memory segment, typically 0x9fff (but can be something different if parts of the upper memory range are either not installed or allocated).

'''Warning:''' This trick doesn't always work. On FreeDos, this can set ES=9FE0 and there is something resident at that location that can screw up the system after normal program exit if you overwrite it.

== Accessing the timer tick for free ==

If using a 386+, FS=0 at .COM start. So, <code>FS:[046C]</code> gets you the DOS timer tick variable, which you could use for timing/pacing, or a random seed. Some environments, especially EMS/XMS programs, can modify the FS register, so it can't always assumed to be 0000h. <code>POP DS</code> right after the start and accessing <code>[046C]</code> does the trick then with equal size.

== Looping twice ==

If you need to repeat a section of code that doesn't modify the carry flag, and you know the carry flag is clear, you can loop once in only 3 bytes:

<syntaxhighlight lang=nasm>
looping:
;do stuff here
cmc
jc looping
</syntaxhighlight>

== Looping three times ==

If you need to repeat a section of code and you have a register whose value is zero and can be incremented freely, or whose value is -1 and can be decremented freely, you can loop twice in only 3 bytes:

<syntaxhighlight lang=nasm>
looping:
;do stuff here
inc bx ;if decrementing instead, parity check must be reversed
jpo looping ;1 (01b) and 2 (10b) have odd parity, 3 (11b) has even parity
</syntaxhighlight>

General Coding Tricks

2016-08-14T22:46:17Z

Qkumba: looping three times

== Data is code, code is data ==

Code is nothing more than data that the CPU interprets. For example, consider this multi-byte instruction:

<syntaxhighlight lang=nasm>
mov ah,37h
</syntaxhighlight>

This assembles to <code>B4 37</code>. <code>B4</code> by itself isn't interesting, but <code>37</code> happens to be the opcode for <code>AAS</code>. Let's say you had this code before a loop, and you needed to perform <code>AAS</code> at the top of a loop. Rather than put AAS at the top of the loop, you can reuse the opcode that will already be there as part of the <code>mov ah,37</code> that comes before it. Just jump directly into the middle of the <code>mov ah,37h</code>, which will get interpreted and executed as <code>AAS</code>:

<syntaxhighlight lang=nasm>

label:
mov ah,37h
;misc. stuff
loop label+1
</syntaxhighlight>

The <code>+1</code> specifies the jump should go to 1 byte past the actual location.

=== Reuse ===

You can use opcodes hidden in your existing data. For example, .COM files can end with <code>RET</code>, which is opcode <code>C3</code>. If you already have a <code>C3</code> somewhere else in your code, even as part of data, just <code>JMP</code> to that pre-existing <code>C3</code> instead of adding a <code>RET</code>.

== If your environment holds you back, change it ==

The [https://en.wikipedia.org/wiki/Video_Graphics_Array#/media/File:VGA_palette_with_black_borders.svg default MCGA palette] is fairly horrible, but can be size advantages to changing it: While setting a new palette costs bytes, the new palette arrangement could save you headaches down the road. For example, if your code is calculating pixel colors that fall into goofy ranges, rather than constantly adjust the colors to sane ranges (ie. aligned to powers of 2), just set the palette so that values falling into those ranges look the way you want. (This assumes you have very small ways of redefining the palette, of course.)

The above is maybe not the best example. Rewrites to this section are welcome.

== Need a constant? ==

If you need a constant value but you're out of space, search your assembled code for a byte value you can use.

== A smaller way to point to Mode 13's screen segment ==

Rather than <code>mov ah,0a0h; mov es,ax</code> or <code>push word 0a000h; pop es</code>, try this 2-byte wonder:

<syntaxhighlight lang=nasm>
les bp,[bx]
</syntaxhighlight>

This sets ES=9FFF, only one away from A000. You can write to the screen with ES: this way as long as you are aware the segment is one paragraph (16 bytes) behind, so just increase your offset by 16 if you need exact placement.

How does this work? At start of execution of a .COM file, BX=0, and DS=CS. The contents of the COM file get loaded to offset 0x100 in that segment, but loaded before that is the PSP (program segment prefix), which DOS populates with information about the loaded program and other info. The PSP starts with <code>CD 20</code> (<code>INT 20</code>, which exits the program), so that's what gets loaded into BP. The next word is the number of the last free conventional memory segment, typically 0x9fff (but can be something different if parts of the upper memory range are either not installed or allocated).

'''Warning:''' This trick doesn't always work. On FreeDos, this can set ES=9FE0 and there is something resident at that location that can screw up the system after normal program exit if you overwrite it.

== Accessing the timer tick for free ==

If using a 386+, FS=0 at .COM start. So, <code>FS:[046C]</code> gets you the DOS timer tick variable, which you could use for timing/pacing, or a random seed. Some environments, especially EMS/XMS programs, can modify the FS register, so it can't always assumed to be 0000h. <code>POP DS</code> right after the start and accessing <code>[046C]</code> does the trick then with equal size.

== Looping twice ==

If you need to repeat a section of code that doesn't modify the carry flag, and you know the carry flag is clear, you can loop once in only 3 bytes:

<syntaxhighlight lang=nasm>
looping:
;do stuff here
cmc
jc looping
</syntaxhighlight>

== Looping three times ==

If you need to repeat a section of code and you have a register whose value is zero and can be incremented freeyl, or whose value is -1 and can be decremented freely, you can loop twice in only 3 bytes:

<syntaxhighlight lang=nasm>
looping:
;do stuff here
inc bx ;if decrementing instead, parity check must be reversed
jpo looping ;1 (01b) and 2 (10b) have odd parity, 3 (11b) has even parity
</syntaxhighlight>

Case Studies

2016-08-14T22:31:34Z

Qkumba: display Řrřola's name properly

Case Studies

2016-08-14T22:29:39Z

Qkumba: tiny compiler is really a compiler

MELT.COM

2016-08-14T22:19:16Z

Qkumba:

[[Category:Case Study]]
MELT.COM was written by an unknown author in the 1980s. Originally 49 bytes in size, it performs the following cute effect:

{{#ev:youtube|https://www.youtube.com/watch?v=MoGKh5X3nS4}}

(The video is simulated and shows how MELT performs on the old hardware it was written for.) This effect is achieved by increasing or decreasing each onscreen character's value until it reaches #32, the space character. The original source is lost to history, but here's a quick commented disassembly:

<syntaxhighlight lang=nasm>
org 100h

mov ax, 0B800h
mov es, ax ; es now points to screen segment

doScreen:
mov cx, 2000 ; Going to loop over all 2000 characters
; (80 * 25 = 2000)
xor bx, bx ; bx = 0
; bx is also our "num of altered chars" counter
mov di, bx ; es:di now points at the screen (b800:0000)

alterChars:
mov ah, es:[di] ; Retreive onscreen character
cmp ah, 32 ; comp to a space character (#32)
jz short nextChar ; If already a space, do nothing
jl short upToSpace ; If lower than a space, increase upward
dec ah ; If higher than a space, decrease downward
mov es:[di], ah ; Store altered character back to screen
inc bx ; increase "number of processed chars" counter
jmp short nextChar ; Keep processing characters
; ---------------------------------------------------------------------------

upToSpace:
inc ah ; Increase character upwards towards a space
mov es:[di], ah ; Store altered character back to screen
inc bx ; increase "number of processed chars" counter

nextChar:
inc di
inc di ; es:di now points to next character
loop alterChars ; Continue processing characters
cmp bx, 0 ; Were any characters processed?
jnz short doScreen ; If so (bx != 0), keep processing
mov ah, 4Ch ; Otherwise, get ready to terminate
int 21h ; DOS - 2+ - QUIT WITH EXIT CODE (EXIT)
</syntaxhighlight>

There are some very quick wins right off the bat:

* AX is already 0, so set AX=B800 by setting AH=B8
* Replace DOS exit sequence with RET, since this is a .COM file
* The "CMP bx,0" can be replaced with a shorter test like "OR bx,bx"
* There is inefficient loading and saving of screen characters with manually advancing DI twice -- 80x86 has 1-byte string instructions to do that, so we'll use LODSW and STOSW. This will load the character attribute byte redundantly, but we don't care about speed, we care about size. Because we only use LODS once, we can shave a byte by getting rid of MOV DS,AX (3 bytes) and using ES: LODS (2 bytes) in the inner loop.

This shaves 12 bytes down to 37 total. At this point we can make some drastic changes that will shave bytes, but also make the program not behave ''exactly'' as it did before. I chose to do the following:

* 2000 is 7D0 in hex. Change MOV CX,2000 (decimal) to MOV CH,08 (hex) to shave a byte. This could result in CX being anywhere in the range 0800 to 08FF but the difference is minimal at execution time. It's also larger than the original area, but that is fine since there is there is extra screen RAM after the visible portion of the screen.
* The code contains a check for characters below #32 (space) and moves them upward. Most characters onscreen are going to be above #32, so this isn't really necessary and I removed the check. Even if it were necessary, removing the check will just rotate them downward until they wrap around to 255, then go downward again until hitting #32 and stopping.

This gets the code down to 29 bytes:

<syntaxhighlight lang=nasm>
org 100h

mov ah, 0B8h
mov es, ax ; es so we can use es: LODS and STOS to the same place

doScreen:
mov ch, 08 ; (80 * 25 = 2000/07d0h)
xor bx, bx ; bx is also our "num of altered chars" counter
mov di, bx ; es:di now points at the screen (b800:0000)
mov si, di ; ds:si = es:di, needed for lods/stos

alterChars:
es: lodsw ; Retreive onscreen character
cmp al, 32 ; comp to a space character (#32)
jz short nextChar ; If already a space, do nothing
dec al ; If higher than a space, decrease downward
inc bx ; increase "number of processed chars" counter

nextChar:
stosw
loop alterChars ; Continue processing characters
or bx,bx ; Were any characters processed?
jnz short doScreen ; If so (bx != 0), keep processing
ret ; exit

</syntaxhighlight>

Optimizing the above is left as an exercise to the reader. It may be possible to shrink it further using instructions for the 80186 and later processors, but it runs way too quickly on those systems, so if doing so you may want to insert a HLT to pace the animation at 18.2 Hz. It may also be possible to shrink it by taking advantage of the fact that ASCII character #0 is a null and shows nothing onscreen (just like the #32 space character), so instead of decrementing down to #32, you could decrement down to #0 in a more optimized form (like using the zero flag).

== Or you could rethink it completely ==

If you're willing to deviate from the original target environment (namely, that it was designed for a 4.77 MHz 8088), you can eliminate range checking for all sorts of optimizations.
Instead of using two pointers/segments, it's possible to use only one, and directly operate on the chars on screen. Combined with optimized segment assignment and exclusion of the "processed chars"-count (fixed amount of iterations, set to the maximum possible 65536 * 255) this results in a 17 byte variation :

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "nop" = 0AF90h
nop ; for alignment, maybe optimization potential here ;)
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],32 ; is the current char on screen a "space"?
jz short skip ; yes, don't decrement
dec byte [di] ; nope, decrement
skip:
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

The above performs the same function as the previous optimization, but runs much more slowly as it traverses more RAM areas than necessary.

There might be a way of altering the <code>NOP</code> to something useful.

Returning to the non-printing null char, we can shave one more byte, to produce this 16 bytes version:

<syntaxhighlight lang=nasm>
lds bx,[si] ; load DS from our code "scasw" + "nop" = 0AF90h
nop ; for alignment, maybe optimization potential here ;)
doChar:
scasw ; used to advance DI by 2, and as DS high byte (0AFh)
cmp byte [di],al ; is the current char on screen a "null"?
jz short skip ; yes, don't decrement
dec byte [di] ; nope, decrement
skip:
dec dx ; first loop, besides the first time
jnz doChar ; it's 65536 iterations
loop doChar ; second loop, 255 times
ret ; quit
</syntaxhighlight>

The above performs a similar function as the previous optimization, but runs even more slowly as it requires regular characters to be decremented further than before.

Getting Started

2016-08-14T18:29:42Z

Qkumba: clarify initial SP

== Words of warning ==

Sizecoding assumes a basic level of assembler knowledge. You should have at least a few regular (non-optimized) assembler programs under your belt before you attempt sizecoding. Also, don't assume sizecoding is ''normal'' -- shaving bytes is a black art that should be kept far, far away from normal programming targets. People sizecode for fun, not profit!

== Tools and Workflows ==

Most people use NASM (it's free) and DOSBox for testing. A simple workflow:

<syntaxhighlight>
nasm main.asm -fbin -o main.com
ndisasm -o100h main.com
dir main.com
</syntaxhighlight>

Some crazy sizecoders like writing tinyprogs on very old hardware. For that, a86 is a good choice for an assembler, as it assembles source directly to a .COM file in one pass. Even on the first 8086 systems, you can use debug.com to check the assembly and size:

<syntaxhighlight>
a86 main.asm
debug main.com
dir main.com
</syntaxhighlight>

== Know your environment ==

Most sizecoders choose to write to mode 13h, a chunky 320x200 graphics mode located at segment A000:0000. Each byte is a pixel, and the graphics buffer is linear, so it is extremely easy to program for. Because it is contained to a single segment, you can be sloppy, as overwriting or underwriting the offset value won't damage anything. The [https://en.wikipedia.org/wiki/Video_Graphics_Array#/media/File:VGA_palette_with_black_borders.svg default palette] leaves a little to be desired, so if you have room, you may want to change it.

=== .COM file defaults ===

Knowing what register values are initialized at program start can save you the trouble of having to set them in your code. On most (but not all) DOS environments, the following registers have these default values:

<pre>
AX=0000
BX=0000
CX=00FF
DX=Same as CS register
SI=0100
DI=FFFE
SP=FFFC (DOS child process) or FFFE (the default)
</pre>

Because .COM files only support 64K executables, <code>DS</code>, <code>ES</code>, and <code>SS</code> are all set to the same value as <code>CS</code>. The rest can't be counted on for any specific value, except that <code>BP</code> is mostly 09??h so you can usually count on the high byte being <code>09h</code>.

Usually, the top stack contains <code>0000h</code>. That allows for using the one byte instruction <code>RET</code> to exit your program, since at location <code>CS:0000h</code> there is the value <code>20CDh</code> (= <code>int 20h</code>). See [https://en.wikipedia.org/wiki/Program_Segment_Prefix Program Segment Prefix].

=== Boot sector defaults ===

Boot sector tinyprogs are occasionally explored, but The BIOS changes every register value as it executes before the boot sequence, so there's not much to count on other than what occurs directly before execution of the boot sector:
* The boot sector is loaded at 0000:7C00
* DL holds the drive number that was booted from, so if booted from a floppy disk in drive A:, it will be 00
* The stack pointer is 512 bytes beyond the end of the boot sector, so SP is likely 7E00h

This is why most sizecoders target .COM files, and is also why [https://github.com/nanochess/Toledo-Atomchess Toledo Atomchess] is 9 bytes larger if loaded from boot sector than from a .COM file.

=== 1-byte opcodes ===
The 80x86 family was originally a [https://en.wikipedia.org/wiki/Complex_instruction_set_computing CISC] design, which is a design philosophy that intentionally attempts to create many instructions that perform multiple steps. In sizecoding, you are trying to perform as much work in as little space as possible, so it is helpful to know (or memorize!) every 1-byte instruction in the 80x86 family. Here's a handy chart (segments and prefixes omitted):

{| class="wikitable sortable"
|-
! Opcode !! Mnemonic !! Arch !! Description !! Notes
|-
| 37 || AAA || || ASCII adjust AL (carry into AH) after addition
|-
|3F||AAS || ||ASCII adjust AL (borrow from AH) after subtraction
|-
|98||CBW || ||Convert byte into word (AH = top bit of AL)
|-
|99||CDQ ||80386+||Convert dword to qword (EDX = top bit of EAX)
|-
|F8||CLC || ||Clear carry flag
|-
|FC||CLD || ||Clear direction flag so SI and DI will increment
|-
|FA||CLI || ||Clear interrupt enable flag; interrupts disabled
|-
|F5||CMC || ||Complement carry flag
|-
|A6||CMPS mb,mb || ||Compare bytes [SI] - ES:[DI], advance SI,DI
|-
|A7||CMPS mv,mv || ||Compare words [SI] - ES:[DI], advance SI,DI
|-
|A6||CMPSB || ||Compare bytes DS:[SI] - ES:[DI], advance SI,DI
|-
|A7||CMPSD ||80386+||Compare dwords DS:[SI] - ES:[DI], advance SI,DI
|-
|A7||CMPSW || ||Compare words DS:[SI] - ES:[DI], advance SI,DI
|-
|99||CWD || ||Convert word to doubleword (DX = top bit of AX)
|-
|98||CWDE ||80386+||Sign-extend word AX to doubleword EAX
|-
|27||DAA || ||Decimal adjust AL after addition
|-
|2F||DAS || ||Decimal adjust AL after subtraction
|-
|F4||HLT || ||Halt||Resumes operation if an interrupt occurs; could use this for pacing effects that run too fast
|-
|EC||IN AL,DX || ||Input byte from port DX into AL
|-
|ED||IN eAX,DX || ||Input word from port DX into eAX
|-
|6C||INS rmb,DX ||80186+||Input byte from port DX into [DI], advance DI
|-
|6D||INS rmv,DX ||80186+||Input word from port DX into [DI], advance DI
|-
|6C||INSB ||80186+||Input byte from port DX into ES:[DI], advance DI
|-
|6D||INSD ||80386+||Input dword from port DX into ES:[DI], advance DI
|-
|6D||INSW ||80186+||Input word from port DX into ES:[DI], advance DI
|-
|CC||INT 3 || ||Interrupt 3 (trap to debugger)||If performing very many CALLs to a single procedure, could make it INT 3
|-
|CE||INTO || ||Interrupt 4 if overflow flag is 1
|-
|CF||IRET || ||Interrupt return (far return and pop flags)
|-
|CF||IRETD ||80386+||Interrupt return (pop EIP, ECS, Eflags)
|-
|9F||LAHF || ||Load: AH = flags SF ZF xx AF xx PF xx CF
|-
|C9||LEAVE ||80186+||Set SP to BP, then POP BP (reverses previous ENTER)
|-
|AC||LODS mb || ||Load byte [SI] into AL, advance SI
|-
|AD||LODS mv || ||Load word [SI] into eAX, advance SI
|-
|AC||LODSB || ||Load byte [SI] into AL, advance SI
|-
|AD||LODSD ||80386+||Load dword [SI] into EAX, advance SI
|-
|AD||LODSW || ||Load word [SI] into AX, advance SI
|-
|A4||MOVS mb,mb || ||Move byte [SI] to ES:[DI], advance SI,DI
|-
|A5||MOVS mv,mv || ||Move word [SI] to ES:[DI], advance SI,DI
|-
|A4||MOVSB || ||Move byte DS:[SI] to ES:[DI], advance SI,DI
|-
|A5||MOVSD ||80386+||Move dword DS:[SI] to ES:[DI], advance SI,DI
|-
|A5||MOVSW || ||Move word DS:[SI] to ES:[DI], advance SI,DI
|-
|90||NOP || ||No Operation
|-
|EE||OUT DX,AL || ||Output byte AL to port number DX
|-
|EF||OUT DX,eAX || ||Output word eAX to port number DX
|-
|6E||OUTS DX,rmb ||80186+||Output byte [SI] to port number DX, advance SI
|-
|6F||OUTS DX,rmv ||80186+||Output word [SI] to port number DX, advance SI
|-
|6E||OUTSB ||80186+||Output byte DS:[SI] to port number DX, advance SI
|-
|6F||OUTSD ||80386+||Output dword DS:[SI] to port number DX, advance SI
|-
|6F||OUTSW ||80186+||Output word DS:[SI] to port number DX, advance SI
|-
|1F||POP DS || ||Set DS to top of stack, increment SP by 2
|-
|07||POP ES || ||Set ES to top of stack, increment SP by 2
|-
|17||POP SS || ||Set SS to top of stack, increment SP by 2
|-
|61||POPA ||80186+||Pop DI,SI,BP,x ,BX,DX,CX,AX (SP value is ignored)
|-
|61||POPAD ||80386+||Pop EDI,ESI,EBP,x,EBX,EDX,ECX,EAX (ESP ign.)
|-
|9D||POPF || ||Set flags register to top of stack, increment SP by 2
|-
|9D||POPFD ||80386+||Set eflags reg to top of stack, incr SP by 2
|-
|0E||PUSH CS || ||Set [SP-2] to CS, then decrement SP by 2
|-
|1E||PUSH DS || ||Set [SP-2] to DS, then decrement SP by 2
|-
|06||PUSH ES || ||Set [SP-2] to ES, then decrement SP by 2
|-
|16||PUSH SS || ||Set [SP-2] to SS, then decrement SP by 2
|-
|60||PUSHA ||80186+||Push AX,CX,DX,BX,original SP,BP,SI,DI
|-
|60||PUSHAD ||80386+||Push EAX,ECX,EDX,EBX,original ESP,EBP,ESI,EDI
|-
|9C||PUSHF || ||Set [SP-2] to flags register, then decrement SP by 2
|-
|9C||PUSHFD ||80386+||Set [SP-4] to eflags reg, then decr SP by 4
|-
|C3||RET || ||Return to caller (near or far, depending on PROC)
|-
|CB||RETF || ||Return to far caller (pop offset, then seg)
|-
|C3||RETN || ||Return to near caller (pop offset only)
|-
|9E||SAHF || ||Store AH into flags SF ZF xx AF xx PF xx CF
|-
|AE||SCAS mb || ||Compare bytes AL - ES:[DI], advance DI
|-
|AF||SCAS mv || ||Compare words eAX - ES:[DI], advance DI
|-
|AE||SCASB || ||Compare bytes AL - ES:[DI], advance DI
|-
|AF||SCASD ||80386+||Compare dwords EAX - ES:[DI], advance DI
|-
|AF||SCASW || ||Compare words AX - ES:[DI], advance DI
|-
|36||SS || ||Use SS segment for the following memory reference
|-
|F9||STC || ||Set carry flag
|-
|FD||STD || ||Set direction flag so SI and DI will decrement
|-
|FB||STI || ||Set interrupt enable flag, interrupts enabled
|-
|AA||STOS mb || ||Store AL to byte [DI], advance DI
|-
|AB||STOS mv || ||Store eAX to word [DI], advance DI
|-
|AA||STOSB || ||Store AL to byte ES:[DI], advance DI
|-
|AB||STOSD ||80386+||Store EAX to dword ES:[DI], advance DI
|-
|AB||STOSW || ||Store AX to word ES:[DI], advance DI
|-
|9B||WAIT || ||Wait until floating-point operation is completed
|-
|D7||XLAT || ||Set AL to memory byte DS:[BX + unsigned AL]
|-

|}

Additionally, there are accumulator-optimized (AX) forms of opcodes that are one byte, such as <code>DEC AX</code>, <code>INC AX</code>, and <code>XCHG reg,AX</code>.

== A sample framework ==

Want to just dive in and see what happens? Here's a skeleton that sets up Mode 13h, loops until a keypress is detected, then exits. Although it assembles to only 19 bytes, do not consider this fully and finally optimized; your program's structure may allow some of this to be reduced further. But it's a good place to start:

<syntaxhighlight lang=nasm>
org 100h ;specify .COM file

start:
mov al,13h ;AX=0000 at program start
int 10h ;init mode 13h
push word A000h ;Requires 80186 or higher to PUSH IMMED
pop es ;ES now points to mode 13h screen segment

mainloop:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;this is where you do your mega-amazing tiny program;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;Check for user wanting to leave by pressing ESC
in al,60h ;read whatever is at keyboard port; looking for ESC which is #1
dec ax ;if ESC, AX now 0
jnz mainloop ;fall through if 0, jump otherwise
mov al,03 ;AX=0000 due to mainloop exit condition
int 10h ;Switch back to text mode as a convenience
ret ;.COM files can exit with RET
</syntaxhighlight>

== Where to go from here? ==

[[Techniques|Tips, Tricks, and Techniques]] can help you with ideas on optimizing your next production, or help you design while you're writing it.

Some [[Case Studies]] are provided that illustrate and explain some of the choices made when sizecoding.

Can't find what you need? Check our list of [[Resources|external resources]].

User:Qkumba

2016-08-14T18:20:23Z

Qkumba: create page

I started coding for 6502 CPUs in 1982 ([http://pferrie.host22.com/misc/appleii.htm and still do]), x86 since 1990 or so. Some of my recent efforts are on [http://pferrie.host22.com/misc/intel.htm this page] of [http://pferrie.host22.com/misc/intel.htm my website], and on my [https://github.com/peterferrie GitHub site].

Resources

2016-08-12T23:06:55Z

Qkumba: link to register value derivation

== Discussions ==

Pouet's [http://www.pouet.net/topic.php?which=8791&page=1 Tiny Intro Toolbox Thread] was one of sizecoding.org's main inspirations.

== References ==

The Hugi demoscene diskmag has been kind to the sizecoding movement. They included [http://www.hugi.scene.org/online/coding/hugi%20se%204%20-%20index%20sorted%20by%20topic.htm many programming articles] since it started in 1996. Additionally, the [http://www.hugi.scene.org/compo/compoold.htm Hugi Size Coding Competition Series] is the gold standard for learning how to sizecode: Each competition was given a specific task, then participants submitted their results. ([http://retrolandia.net/hugi/showthread.php?tid=7&pid=13#pid13 All of the entries with their source code] are available, as are [http://retrolandia.net/hugi/showthread.php?tid=7&pid=396#pid396 the rules for each challenge].) Hugi #35 also provided a [http://hugi.scene.org/online/hugi35/hugi%2035%20-%20demoscene%20forum%20adok%20256b%20intros%20round-table.htm 256b intros round-table] between Baze, Digimind, Rrrola, Pirx, Optimus, and Seven.

fysnet.net has an extensive [http://www.fysnet.net/yourhelp.htm list of DOS .COM register starting values]. If your environment isn't listed, [http://www.fysnet.net/yourhelp.com a program] is also available that can print out all of the register starting values. See also [http://pferrie.host22.com/misc/lowlevel12.htm DOS Register Starting Values] to understand why the register starting values for .COM files are set the way that they are.

The [http://sparksandflames.com/files/x86InstructionChart.html Sparks And Flames x86 Instruction Chart] is awesome, once you can "read" it. Find out what the bright green (1-byte) commands do, and use them. For the extreme sizecoding (<=32 bytes) it's also very useful to have the HEX value in sight.

The [http://ref.x86asm.net/geek.html Geek Edition x86asm-ref] is comprehensive and dense. It might be the only reference you'll need. The last part covers modr/m bytes, which is useful.

[http://x86.renejeschke.de/ Rene Jeschke's preservation of siyobik.com's x86 Documentation] is one of the most compact and understandable references to the x86 instruction set you'll ever see.

[http://www.rcollins.org/secrets/OpCodes.html Robert Collins' Undocumented Opcodes] page has some gems you can exploit depending on your target environment.

[http://wiki.osdev.org/PC_Speaker PC Speaker Basics] For everything from simple bleeps to sophisticated synthesizers.

[https://de.wikipedia.org/wiki/Program_Segment_Prefix Program Segment Prefix] : whats in front of our code, and why.

Never underestimate [http://www.hugi.scene.org/online/coding/hugi%2017%20-%20coaax.htm The Hidden Power of BCD Instructions].

[http://wiki.osdev.org/Programmable_Interval_Timer Programmable Interval Timer] : timing is everything.

== Repositories ==

Tinyprogs are so small that you sometimes don't need the source code to understand them: Just pop them into a disassembler (like IDA) or a debugger and look at them. If you want to grab specimens for study, here are some places to start.

Pouet can be searched for the latest tinyprogs: [http://www.pouet.net/prodlist.php?type%5B%5D=256b&platform%5B%5D=MS-Dos&page=1 256b], [http://www.pouet.net/prodlist.php?type%5B%5D=128b&platform%5B%5D=MS-Dos&page=1 128b], [http://www.pouet.net/prodlist.php?type%5B%5D=64b&platform%5B%5D=MS-Dos&page=1 64b], and even [http://www.pouet.net/prodlist.php?type%5B%5D=32b&platform%5B%5D=MS-Dos&page=1 32b and smaller].

[http://hardcode.untergrund.net/ HardCode] is a repository of 7800 64KB and smaller intros.

[http://256bytes.untergrund.net 256b.com] is a website dedicated primarily to 256b and smaller releases.

Resources

2016-08-12T22:59:58Z

Qkumba: corrected 256.com link

== Discussions ==

Pouet's [http://www.pouet.net/topic.php?which=8791&page=1 Tiny Intro Toolbox Thread] was one of sizecoding.org's main inspirations.

== References ==

The Hugi demoscene diskmag has been kind to the sizecoding movement. They included [http://www.hugi.scene.org/online/coding/hugi%20se%204%20-%20index%20sorted%20by%20topic.htm many programming articles] since it started in 1996. Additionally, the [http://www.hugi.scene.org/compo/compoold.htm Hugi Size Coding Competition Series] is the gold standard for learning how to sizecode: Each competition was given a specific task, then participants submitted their results. ([http://retrolandia.net/hugi/showthread.php?tid=7&pid=13#pid13 All of the entries with their source code] are available, as are [http://retrolandia.net/hugi/showthread.php?tid=7&pid=396#pid396 the rules for each challenge].) Hugi #35 also provided a [http://hugi.scene.org/online/hugi35/hugi%2035%20-%20demoscene%20forum%20adok%20256b%20intros%20round-table.htm 256b intros round-table] between Baze, Digimind, Rrrola, Pirx, Optimus, and Seven.

fysnet.net has an extensive [http://www.fysnet.net/yourhelp.htm list of DOS .COM register starting values]. If your environment isn't listed, [http://www.fysnet.net/yourhelp.com a program] is also available that can print out all of the starting register values.

The [http://sparksandflames.com/files/x86InstructionChart.html Sparks And Flames x86 Instruction Chart] is awesome, once you can "read" it. Find out what the bright green (1-byte) commands do, and use them. For the extreme sizecoding (<=32 bytes) it's also very useful to have the HEX value in sight.

The [http://ref.x86asm.net/geek.html Geek Edition x86asm-ref] is comprehensive and dense. It might be the only reference you'll need. The last part covers modr/m bytes, which is useful.

[http://x86.renejeschke.de/ Rene Jeschke's preservation of siyobik.com's x86 Documentation] is one of the most compact and understandable references to the x86 instruction set you'll ever see.

[http://www.rcollins.org/secrets/OpCodes.html Robert Collins' Undocumented Opcodes] page has some gems you can exploit depending on your target environment.

[http://wiki.osdev.org/PC_Speaker PC Speaker Basics] For everything from simple bleeps to sophisticated synthesizers.

[https://de.wikipedia.org/wiki/Program_Segment_Prefix Program Segment Prefix] : whats in front of our code, and why.

Never underestimate [http://www.hugi.scene.org/online/coding/hugi%2017%20-%20coaax.htm The Hidden Power of BCD Instructions].

[http://wiki.osdev.org/Programmable_Interval_Timer Programmable Interval Timer] : timing is everything.

== Repositories ==

Tinyprogs are so small that you sometimes don't need the source code to understand them: Just pop them into a disassembler (like IDA) or a debugger and look at them. If you want to grab specimens for study, here are some places to start.

Pouet can be searched for the latest tinyprogs: [http://www.pouet.net/prodlist.php?type%5B%5D=256b&platform%5B%5D=MS-Dos&page=1 256b], [http://www.pouet.net/prodlist.php?type%5B%5D=128b&platform%5B%5D=MS-Dos&page=1 128b], [http://www.pouet.net/prodlist.php?type%5B%5D=64b&platform%5B%5D=MS-Dos&page=1 64b], and even [http://www.pouet.net/prodlist.php?type%5B%5D=32b&platform%5B%5D=MS-Dos&page=1 32b and smaller].

[http://hardcode.untergrund.net/ HardCode] is a repository of 7800 64KB and smaller intros.

[http://256bytes.untergrund.net 256b.com] is a website dedicated primarily to 256b and smaller releases.