Difference between revisions of "Getting Started"

Latest revision as of 16:14, 28 June 2022

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:

nasm main.asm -fbin -o main.com
ndisasm -o100h main.com
dir main.com

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:

a86 main.asm
debug main.com
dir main.com

Know your environment

A simple graphics mode

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 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:

AX=0000
BX=0000
CX=00FF
DX=CS
SI=0100
DI=FFFE
BP=09xx
SP=FFFC (DOS child process) or FFFE (the default)

flags=xx02

(For a full list of values per specific version of DOS, consult http://www.fysnet.net/yourhelp.htm)

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

Usually, the top stack contains 0000h. That allows for using the one byte instruction RET to exit your program, since at location CS:0000h there is the value 20CDh (= int 20h). See Program Segment Prefix.

Different DOS versions may differ slightly in the above. A full chart exists at http://www.fysnet.net/yourhelp.htm to help you check if your specific target has different defaults than the standard settings above.

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 Toledo Atomchess is 9 bytes larger if loaded from boot sector than from a .COM file -- it has to spend bytes setting things up like a .COM file for the rest of the code to work.

If you still want to target boot sectors, your reward is 510 bytes available for program code (the last two bytes must be 0x55, 0xAA to be recognized as a boot sector).

1-byte opcodes

The 80x86 family was originally a CISC design, a design philosophy that attempts to create instructions that perform multiple steps. As such, there are some single instructions that perform complex actions, such as the string opcodes (LODS, MOVS, CMPS, and SCAS). 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):

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

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:

org 100h                        ;specify .COM file

start:
        mov     al,13h          ;AX=0000 at program start
        int     10h             ;init mode 13h
        push    word 0A000h     ;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.
;Write 8-bit values to A000:0000 to draw some pixels.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

        ;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     al              ;if ESC, AL 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

How to think like a sizecoder

This example framework can be shrunk! Think a little bit about how you might do it, then check out the example below:

org 100h                        ;specify .COM file

start:
        mov     al,13h          ;AX=0000 at program start
        int     10h             ;init mode 13h
        les     bx,[bx]         ;contains 0x9FFF at program start; close enough to 0xA000 ;-)
        
mainloop:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;This is where you do your mega-amazing tiny program.
;Write 8-bit values to ES:xxxx to draw some pixels.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

        ;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     al              ;if ESC, AL now 0
        jnz     mainloop        ;fall through if 0, jump otherwise
        ret                     ;.COM files can exit with RET
                                ;Don't care if we set text mode, user can just MODE CO80

By casually disregarding the user experience :-) and fudging the start of video memory, our basic framework is now 13 bytes.

Where to go from here?

Hello World! console output shows how to output text.

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 external resources.