SizeCoding - User contributions [en]

Resources

2025-02-23T17:12:40Z

HellMood: The hardcode update is now containing releases up to the year 2025, description changed accordingly

== 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.

We also have an active discord server dedicated to sizecoding at: https://discord.gg/pZE5rAQrHx

== Seminars ==

Seminars on various sizecoding topics have been presented at the Lovebyte demoparty, and can be watched here: [https://www.youtube.com/playlist?list=PLr4JCYhdWe8mq3aDvAtL0ooO7hAC9gU2s Lovebyte seminars on YouTube]

In recent years 256b intro coding has been covered in presentation sessions at other demo parties. The recordings are available on YouTube. There are
[https://www.youtube.com/watch?v=WbWYBE9vjdk part 1] and [https://www.youtube.com/watch?v=51BOp5Pi4mU part 2] of Řrřola's talk "Magic of 256-byte x86 intros" held at Demobit 2017 and 2018 respectively. A similar talk [https://www.youtube.com/watch?v=V_ntnQKemWA "256 byte intros on modern PCs"] was held by TomCat/Abaddon at the Function 2017 party. Supplemental files can be downloaded from [http://www.pouet.net/prod.php?which=72454 Pouet.net]. The presentations cover everything from setting up the coding environment to all kinds of code optimization, constant reuse, flag tricks, palette generation, and how to get from an idea to the final intro. TomCat also provides a [https://www.abaddon.hu/usbdos/ dev tools page] and his [https://www.abaddon.hu/256b/ SizeCoding Blog] with lots of optimization ideas.

== 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 [https://web.archive.org/web/20170418182707/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 [http://ref.x86asm.net/geek.html#modrm_byte_16 last part] covers modr/m bytes, which is useful.

[https://www.felixcloutier.com/x86/ Yet another reference] by Félix Cloutier.

[http://www.techhelpmanual.com/2-main_menu.html Tech Help Manual] includes a dense reference of DOS interrupts and x86 instructions.

[http://c9x.me/x86/ c9x.me]: A x86 instruction reference

[https://kernfunny.org/x86/ 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.

Intel IA-32 Software Developer's Manual Instruction Set Reference [http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/whgdata/whlstt2.htm hypertext version].

[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://en.wikipedia.org/wiki/Program_Segment_Prefix Program Segment Prefix] : what's in front of our .COM code, and why.

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

[http://www.agner.org/optimize/optimizing_assembly.pdf An optimization guide for x86 platforms By Agner Fog] Chapter 10: Optimizing for size.

[http://home.sch.bme.hu/~ervin/codegems.html Code Gems by Ervin/AbaddoN] Nice collection based on the Imphobia diskmagazine article.

[http://wiki.osdev.org/Programmable_Interval_Timer Programmable Interval Timer]: Timing is everything, if you're targeting a slow system. Very old but good text [http://www.phatcode.net/res/246/files/pctim003.txt PCTIM003.TXT]

[http://stanislavs.org/helppc/bios_data_area.html BIOS data area]: Direct system communication overview. There are environment values here you may be able to utilize.

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

[http://www.voidaudio.net/percussion.html Roland GS/GM2 Drum Set List and Note Map] : Detailed Description of all MIDI drumkits.

[http://www.h-schmidt.net/FloatConverter/IEEE754.html Online IEEE 754 Converter] : Excellent tool for optimizing/reusing FPU constants

[https://baseconvert.com/ieee-754-floating-point Base Convert IEEE 754] : Alternative tool for optimizing/reusing FPU constants with live update

[https://www.reddit.com/r/tinycode Tinycode on Reddit]: Collection of many different size coding productions incl. x86 based ones with discussion (mostly provided by [https://www.reddit.com/user/Hell__Mood/ HellMood] himself)

[https://marqueedesign.demoscene.com/blog Superogue's sizecoding microblog]: Collection of demoscene and sizecoding related articles and development writeups up [https://marqueedesign.demoscene.com various Marquee Design tiny intros]

[https://www.xtof.info/Timing-on-PC-familly-under-DOS.html Timing-on-PC-familly-under-DOS] A complete and very detailed guide about timing, timers, callbacks, interrupts in conjunction with MSDOS

== 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.

* [https://files.scene.org/get/demos/compilations/hardcode/hardcode.zip Scene.org link] to this archive

* [https://files.scene.org/get/demos/compilations/hardcode/hc_update.zip Scene.org link] to an archive update from 2017 to 2025

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

Paint16b

2025-02-17T16:26:16Z

HellMood: added screenshot

{{Tinyprog|title=paint16b|author=Hellmood|bsize=16|link=http://www.pouet.net/prod.php?which=63826}}
[[Category:Case Study]]

[[File:Pa!nt 16b - Screenshot.jpg|frame|center|Pa!nt 16b - Screenshot]]

paint16b implements a mouse-driven drawing program which has the ability to exit back to DOS and also display the mouse cursor.

<syntaxhighlight lang=nasm>
org 100h ; code starts at 0x100
mov al,0x12 ; assume ah = 0 ; set graphics mode to 640*480
inc bx ; assume bx = 0 ; set to 1 (show cursor)
mloop:
int 0x10 ; first loop, switch to graphic mode
; further loops, set pixel
xchg bx,ax ; first loop, set AX to 1 (show cursor)
; further loops, restore old calling mode
xor al,0x02 ; switch modes : show cursor <-> get mouse state
; updating XY every second loop plus drawing
; one pixel left results in thicker lines
int 0x33 ; call the mouse interrupt
xchg bx,ax ; store the button state in AL for drawing
; remember the current calling mode
; for switching it later (in BX)
mov ah,0x0C ; set mode to "set pixel"
loop mloop ; dec CX -> draw one pixel left from cursor
; basically enables drawing pixels
; while the cursor is active
; allows exit if the mouse is leftmost
ret ; assume [[FFEE]] = [0] = CD20 = int 20
</syntaxhighlight>

File:Pa!nt 16b - Screenshot.jpg

2025-02-17T16:25:50Z

HellMood:

Pa!nt 16b - Screenshot

2020-04-30T17:11:28Z

HellMood:

This writeup is still in the works! Come back later to get information on all the mean tricks ;) Meanwhile you can [https://www.pouet.net/prod.php?which=85485 download and comment] the intro.

==Original version : 65 bytes==
We'll start with the old 65 bytes version and bring it down to 32 bytes. 

 
It will help to understand what the core algorithm does, before optimizing it. I will not go into the details of random number generation and key handling since these parts are removed in the final version anyway. Setting up screen mode and putting pixels to the screen is described in the basic sectionn of this Wiki. The core routine computes the [https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life#Rules "normal" game of life rules, but with a twist. Instead of regarding only eight neighbour cells inside a 3x3 neighbourhood , ALL nine cells are taken into consideration, and the rules are reinterpreted as:
 
* If the number of cells is 3, the center cell will be alive.
* If the number of cells is 4, the center cell keeps its state.
* Otherwise, the cell dies (or stays dead).
 
Like in other (trivial) implementations, the 2D space is parsed cell by cell, from left to right, and from top to bottom. Since the game of life does not work "in situ" (updating the current cell instantly will lead to wrong results of following calculations), current cells are "marked", and when the calculations are advanced far enough that the cell in question does not influence any calculation of the current iteration, it will be "corrected" by <code>shr [byte di-65],5</code> to the target value of the next iteration. The summation is as usual, an inner loop, adding up 3 cells of one column, and the outer loop, shifting from right (+1) to the left (-1), thus adding up 9 cells of a 3x3 neighbourhood. 
 
At the start of the loop, there is already the first "trick" happening. The register of summation <code>cl</code> is not properly cleaned, but at this point it can either contain 0 or 32 from the instruction <code>and al,0x20</code> after <code>xchg cx,ax</code>. If an arbitrary amount of cells has this on bit set, that won't hurt the calculation because of a special property of the <code>rcr</code> instruction. [https://kernfunny.org/x86/html/file_module_x86_id_273.html "The processor restricts the count to a number between 0 and 31 by masking all the bits in the count operand except the 5 leastsignificant bits."] 
 
When the summation is complete, the aforementioned <code>rcr</code> is executed, but not before setting the carry flag (<code>stc</code>) which will be rotated in from the left, and directly right of the original cell value. By extracting the 6th bit of this rotated value (with <code>and al,0x20</code> we get exactly the value according to the rules defined above. 
 
This value is now set in the original cell with <code>or [si-1],al</code>, which as shown before, does not hurt the computation, besides the cell value has a temporary value of 32 or 33, thus being visible as brighter blue pixel in the short time span between marking and correction.

<syntaxhighlight lang="nasm">
; http://read.pudn.com/downloads208/sourcecode/asm/981812/LIFE65.ASM__.htm
; Life simulator, 72 bytes - Vladislav Kaipetsky and Tenie Remmel
; 65 bytes - Mark Andreas

; If no args, regs on startup are:

; AX = BX = 0000h
; SI = IP = 0100h
; DI = SP = FFFEh

IDEAL
MODEL TINY
P386
CODESEG
ORG 100h

Start: int 1ah ; ah=00: cx=hours, dx=tic counter

mov al,13h ; Set mode 13h
int 10h

xchg dx,ax

push 09000h ; DS = last 64K segment
pop ds
push 0A000h ; ES = video memory
pop es
; BX is already zero
RandLoop:
rol ax,1 ; Generate random number
adc [bx],al
dec bx
jnz RandLoop

; BX will not be equal to 3 the first time this loop is executed, but
; it will be for all other times. As SI = 0100h and DI = FFFEh on
; startup, SI - DI will be equal to 258.

LifeLoop:
xchg cx,ax
AccLoop:
add cl,[di+bx-64] ; Add in this column
add cl,[si+bx-2]
add cl,[si+bx+318]
dec bx ; Loop back
jnz AccLoop

mov al,[si] ; Get center cell, set pixel
stosb
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
; +---> 0.00x100?0 (rcr 4)
or [si-1],al ; Add in new cell ^
shr [byte di-65],5 ; Shift previous value

mov bl,3 ; 3 iterations in AccLoop
inc si ; Loop while not zero
jnz LifeLoop

mov ah,1 ; Check for key
int 16h
jz LifeLoop ; Loop if no key

xchg ax,bx ; Set text mode
int 10h
ret ; Return
End Start
</syntaxhighlight>

==Remove key handler and RNG : 44 bytes==
In order to reach 32 bytes, all the convenient stuff has to be removed. In case there is space left, parts of it could be reintegrated again. There are tiny changes to make this work as intended. The segment where all the calculation takes place has been changed to <code>1000h</code>, pointing to a lower memory location. (Note: this might be working just with DosBox) The activity there (visible on the screen) helps spawning actual game of life structures.
[[File:Gol44.png|thumb|right|game of life, 44 bytes]]
[[File:Gol44c.png|thumb|game of life, 44 bytes, increased contrast]]
<code>mov al,[si]</code> and <code>inc si</code> have been replaced with <code>lodsb</code> since that saves one byte.
<syntaxhighlight lang="nasm">
Start:

mov al,13h ; Set mode 13h
int 10h

push 01000h ; DS = low memory segment
pop ds
push 0A000h ; ES = video memory
pop es
; BX is already zero
LifeLoop:
xchg cx,ax
AccLoop:
add cl,[di+bx-64] ; Add in this column
add cl,[si+bx-2]
add cl,[si+bx+318]
dec bx ; Loop back
jnz AccLoop

;mov al,[si] ; Get center cell, set pixel
lodsb
stosb
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
; +---> 0.00x100?0 (rcr 4)
or [si-1],al ; Add in new cell ^
shr [byte di-65],5 ; Shift previous value

mov bl,3 ; 3 iterations in AccLoop
; inc si ; Loop while not zero
jmp short LifeLoop
</syntaxhighlight>

[[File:Golt38.png|thumb|game of life, text mode, 32b - 38b]]
== Switching to Textmode : 38 bytes==
Setting up screen mode and pixel access is requiring quite a bit of space, so in this version, it is removed. That is directly punished with an additional byte, because <code>DI</code> is no longer involved in the process, thus, an optimization had to be removed. The assumption is that the computer this runs on, is already in text mode (40x25 chars, colors). This also helps with the calculation, since now it takes place directly on the screen (only one segment has to be set up) and no content has to be generated initially, since there is always at least something on the screen that works as seed value. A small downside is the alignment of cells, because in textmode, one cell occupies TWO bytes (one for color information). Luckily, the color information is by default set to "gray on black". An additional <code>dec bx</code>, replacing <code>lodsb</code> with <code>lodsw</code> and changing <code>mov bl,3</code> to <code>mov bl,6</code> helps fixing the alignment issue. Additionally, the screen address changed (<code>push 0xb800</code> <code>pop ds</code>) Another lucky coincident is, that instead of blue pixels, we now have a "smiley char" with orthogonal borders, which is a decent representation of a living cell. Inbetween marking and correction it shortly changes to an exclamation mark (!), which is barely visible.

<syntaxhighlight lang="nasm">
push 0xb800
pop ds
LifeLoop:
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
or [si-2],al ; Add in new cell ^
shr byte [si-160-6],5 ; Shift previous value
mov bl,6
xchg cx,ax
AccLoop: add cl,[si+bx-160-4] ; Add in this column
add cl,[si+bx-4]
add cl,[si+bx+160-4]
dec bx ; Loop back
dec bx ; Loop back
jnz AccLoop
lodsw
jmp short LifeLoop
</syntaxhighlight>

== Using instructions as segment adress : 36 bytes ==
[[File:LDStrick.png|frame|center|possible instructions for LDS trick in textmode]]
Instead of using <code>push</code> and <code>pop</code> to get the screen adress, there is also the instruction <code>lds</code> available, which reads the segment value from memory. A value "close" to <code>0xb800</code> would be sufficient, because the visible screen in textmode is just a tiny part of the 64 kilobytes addressable by one segment. The idea is now to reuse parts of the code as segment address, which is possible when the instructions is one of the above. If there is such an instruction, it can start at the 4th byte (<code>[si]</code> points to the start of the code and <code>lds bx,[si]</code> puts the first two bytes into BX and the 3rd and 4th into DS, reversed). In this case <code>lodsw</code> can be reused as the first (higher) byte of the segment. The 3rd byte would be only relevant for alignment, so instead of putting "0x00" there, a one-byte-instruction can be used there. The whole process saves two bytes.

<syntaxhighlight lang="nasm">
lds bx,[si]
LifeLoop:
stc ; 3 = birth, 4 = stay (tricky):
lodsw
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
or [si-2],al ; Add in new cell ^
shr byte [si-160-6],5 ; Shift previous value
mov bl,6
xchg cx,ax
AccLoop: add cl,[si+bx-160-4] ; Add in this column
add cl,[si+bx-4]
add cl,[si+bx+160-4]
dec bx ; Loop back
dec bx ; Loop back
jnz AccLoop
jmp short LifeLoop
</syntaxhighlight>

== Synchronizing SI/DI, Improved cleanup : 34 bytes ==
A lot of tiny changes were the result of just one idea: How to optimize the clean up step? After all it is not really neccessary to correct a marked cell as soon as possible, instead, it can be waited for a certain amount of time/steps. But any nontrivial version of <code>shr byte [si-160-6],5</code> still uses four bytes, unless it is brought into one of the "pure" forms that only take up THREE bytes: <code>shr byte[(bp/bx)+si/di],x</code>. Since SI and BX were already in use, and the usage of BP would implicate that the register SS is used instead of DS, the only remaining register possible is DI. 
Now there are very short instructions available to advance the registers SI and DI, some of them at the same time, and one of them is <code>cmpsw</code>. Not only does it not "hurt" the intended computation (the "compare" part of the instruction can be ignored), it also advances both SI and DI by TWO, so that the alignment of the screen in text mode is perfectly matched. 
The usage of <code>cmpsw</code> requires to remove <code>lodsw</code> since there is no simple command to advance SI in the opposite direction (without involving direction flags), so it had been changed again to <code>lodsb</code> to be one of the commands that also works as high byte of a segment adress, and an additional <code>dec si</code> to align DI and SI, so that the clean up step is always in the same distance "behind" the current calculation. The assumption DI = SI - 258 is true on almost every DOS system. As a byproduct, one of the memory access instruction can now be rewritten to use DI instead of SI (like in the original), to save one byte.
<syntaxhighlight lang="nasm">
lds bx,[si]
LifeLoop:
stc ; 3 = birth, 4 = stay (tricky):
lodsb
dec si
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
or [si],al ; Add in new cell ^
cmpsw
shr byte [di],5 ; Shift previous value
mov bl,6
xchg cx,ax
AccLoop: add cl,[di+bx+94] ; Add in this column
add cl,[si+bx-4]
add cl,[si+bx+160-4]
dec bx ; Loop back
dec bx ; Loop back
jnz AccLoop
jmp short LifeLoop
</syntaxhighlight>
== Combining exchange with alignment : 33 bytes ==
When thinking about <code>xchg cx,ax</code> and how to skip one row to get rid of one of the double <code>dec bx</code>, my own production "M8trix" (2015) came to mind, where i did [https://www.pouet.net/prod.php?which=63126#c713378 pretty much the same as here], pulling the <code>xchg</code>into the loop and doing alternating counting, so that <code>cl</code> counts the acual cells, while <code>al</code> is never actually used (it "counts" the colors). To make that little dance work, <code>bl</code> has to start at 7.

<syntaxhighlight lang="nasm">
lds bx,[si]
LifeLoop:
stc ; 3 = birth, 4 = stay (tricky):
lodsb
dec si
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
or [si],al ; Add in new cell ^
cmpsw
shr byte [di],5 ; Shift previous value
mov bl,7
AccLoop: xchg cx,ax
add al,[di+bx+94] ; Add in this column
add al,[si+bx-4]
add al,[si+bx+160-4]
dec bx ; Loop back
jnz AccLoop
jmp short LifeLoop
</syntaxhighlight>

Game of Life 32b

2020-04-30T16:56:41Z

Game of Life 32b

2020-04-30T15:49:28Z

HellMood: /* Switching to Textmode : 38 bytes */

File:Golt38.png

2020-04-30T15:49:13Z

HellMood:

game of life, textmode, 32b - 38b

Game of Life 32b

2020-04-30T15:47:17Z

HellMood: /* Switching to Textmode : 39 bytes */

Game of Life 32b

2020-04-30T12:28:28Z

HellMood:

==Original version : 65 bytes==
We'll start with the old 65 bytes version and bring it down to 32 bytes.

<syntaxhighlight lang="nasm">
; http://read.pudn.com/downloads208/sourcecode/asm/981812/LIFE65.ASM__.htm
; Life simulator, 72 bytes - Vladislav Kaipetsky and Tenie Remmel
; 65 bytes - Mark Andreas

; If no args, regs on startup are:

; AX = BX = 0000h
; SI = IP = 0100h
; DI = SP = FFFEh

IDEAL
MODEL TINY
P386
CODESEG
ORG 100h

Start: int 1ah ; ah=00: cx=hours, dx=tic counter

mov al,13h ; Set mode 13h
int 10h

xchg dx,ax

push 09000h ; DS = last 64K segment
pop ds
push 0A000h ; ES = video memory
pop es
; BX is already zero
RandLoop:
rol ax,1 ; Generate random number
adc [bx],al
dec bx
jnz RandLoop

; BX will not be equal to 3 the first time this loop is executed, but
; it will be for all other times. As SI = 0100h and DI = FFFEh on
; startup, SI - DI will be equal to 258.

LifeLoop:
xchg cx,ax
AccLoop:
add cl,[di+bx-64] ; Add in this column
add cl,[si+bx-2]
add cl,[si+bx+318]
dec bx ; Loop back
jnz AccLoop

mov al,[si] ; Get center cell, set pixel
stosb
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
; +---> 0.00x100?0 (rcr 4)
or [si-1],al ; Add in new cell ^
shr [byte di-65],5 ; Shift previous value

mov bl,3 ; 3 iterations in AccLoop
inc si ; Loop while not zero
jnz LifeLoop

mov ah,1 ; Check for key
int 16h
jz LifeLoop ; Loop if no key

xchg ax,bx ; Set text mode
int 10h
ret ; Return
End Start
</syntaxhighlight>
==Remove key handler and RNG : 44 bytes==
<syntaxhighlight lang="nasm">
Start:

mov al,93h ; Set mode 13h
int 10h

push 09000h ; DS = last 64K segment
pop ds
push 0A000h ; ES = video memory
pop es
; BX is already zero
LifeLoop:
xchg cx,ax
AccLoop:
add cl,[di+bx-64] ; Add in this column
add cl,[si+bx-2]
add cl,[si+bx+318]
dec bx ; Loop back
jnz AccLoop

;mov al,[si] ; Get center cell, set pixel
lodsb
stosb
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
; +---> 0.00x100?0 (rcr 4)
or [si-1],al ; Add in new cell ^
shr [byte di-65],5 ; Shift previous value

mov bl,3 ; 3 iterations in AccLoop
; inc si ; Loop while not zero
jmp short LifeLoop
</syntaxhighlight>
== Switching to Textmode : 39 bytes==
<syntaxhighlight lang="nasm">
push 0xb800
pop ds
LifeLoop:
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
or [si-2],al ; Add in new cell ^
shr byte [si-160-6],5 ; Shift previous value
mov bl,6
xchg cx,ax
AccLoop: add cl,[si+bx-160-4] ; Add in this column
add cl,[si+bx-4]
add cl,[si+bx+160-4]
dec bx ; Loop back
dec bx ; Loop back
jnz AccLoop
lodsw
jmp LifeLoop
</syntaxhighlight>
== TODO ==
<syntaxhighlight lang="nasm">
</syntaxhighlight>

Game of Life 32b

2020-04-30T12:26:56Z

HellMood:

==Original version : 65 bytes==
We'll start with the old 65 bytes version and bring it down to 32 bytes.

<syntaxhighlight lang="nasm">
; http://read.pudn.com/downloads208/sourcecode/asm/981812/LIFE65.ASM__.htm
; Life simulator, 72 bytes - Vladislav Kaipetsky and Tenie Remmel
; 65 bytes - Mark Andreas

; If no args, regs on startup are:

; AX = BX = 0000h
; SI = IP = 0100h
; DI = SP = FFFEh

IDEAL
MODEL TINY
P386
CODESEG
ORG 100h

Start: int 1ah ; ah=00: cx=hours, dx=tic counter

mov al,13h ; Set mode 13h
int 10h

xchg dx,ax

push 09000h ; DS = last 64K segment
pop ds
push 0A000h ; ES = video memory
pop es
; BX is already zero
RandLoop:
rol ax,1 ; Generate random number
adc [bx],al
dec bx
jnz RandLoop

; BX will not be equal to 3 the first time this loop is executed, but
; it will be for all other times. As SI = 0100h and DI = FFFEh on
; startup, SI - DI will be equal to 258.

LifeLoop:
xchg cx,ax
AccLoop:
add cl,[di+bx-64] ; Add in this column
add cl,[si+bx-2]
add cl,[si+bx+318]
dec bx ; Loop back
jnz AccLoop

mov al,[si] ; Get center cell, set pixel
stosb
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
; +---> 0.00x100?0 (rcr 4)
or [si-1],al ; Add in new cell ^
shr [byte di-65],5 ; Shift previous value

mov bl,3 ; 3 iterations in AccLoop
inc si ; Loop while not zero
jnz LifeLoop

mov ah,1 ; Check for key
int 16h
jz LifeLoop ; Loop if no key

xchg ax,bx ; Set text mode
int 10h
ret ; Return
End Start
</syntaxhighlight>
==Remove key handler and RNG : 44 bytes==
<syntaxhighlight lang="nasm">
Start:

mov al,93h ; Set mode 13h
int 10h

push 09000h ; DS = last 64K segment
pop ds
push 0A000h ; ES = video memory
pop es
; BX is already zero
LifeLoop:
xchg cx,ax
AccLoop:
add cl,[di+bx-64] ; Add in this column
add cl,[si+bx-2]
add cl,[si+bx+318]
dec bx ; Loop back
jnz AccLoop

;mov al,[si] ; Get center cell, set pixel
lodsb
stosb
stc ; 3 = birth, 4 = stay (tricky):
rcr al,cl ; 1.00?0000x --> 0.0x100?00 (rcr 3)
and al,20h ; ^carry | ^
; +---> 0.00x100?0 (rcr 4)
or [si-1],al ; Add in new cell ^
shr [byte di-65],5 ; Shift previous value

mov bl,3 ; 3 iterations in AccLoop
; inc si ; Loop while not zero
jmp short LifeLoop
</syntaxhighlight>
== Switching to Textmode : 39 bytes==
<syntaxhighlight lang="nasm">
</syntaxhighlight>
== TODO ==
<syntaxhighlight lang="nasm">
</syntaxhighlight>