Indian Spirit

2019-04-08T17:35:22Z

Trixter:

{{Tinyprog|title=Indian Spirit|author=Hellmood|bsize=32|link=http://www.pouet.net/prod.php?which=80341}}
[[Category:Case Study]]
Indian Spirit implements a 640x400 American Indian cloth tapestry while playing music inspired by that culture. Original Readme:

<nowiki>"Indian Spirit" - HellMood / DSR
released just for fun 02/2019

DOSBOX - 32 bytes - PC Speaker

Somewhat inspired by Adoks "Indian" Series
i coded for one hour to see what i can come up
with, but in 32 bytes, and with sound. At the
same time i exploited the "secret mode" 0x69
which switches to 640x400 in 256 colors, but
without using the size-unfriendly VESA functions.
For that reason, this demo only works in DOSBOX
or on a computer which as the EXACT graphic card
dosbox emulates.

Youtube Capture :
https://www.youtube.com/watch?v=TeIkW31Blf0</nowiki>

<syntaxhighlight lang=nasm>
pop ds
cwd
Y:
xor al,0x69
int 0x10
mov dl,cl
mov al,[0x46C]
neg al
xor dl,al
and al,32+16+4+2
or al,0x41
out 0x42,al
out 0x61,al
mov ah,12
loop Y
inc bl
jmp short Y
</syntaxhighlight>

Indian Spirit

2019-04-08T17:33:40Z

Trixter: Created page with "{{Tinyprog|title=Indian Spirit|author=Hellmood|bsize=32|link=http://www.pouet.net/prod.php?which=80341}} Category:Case Study Indian Spirit implements a 640x400 American In..."

2016-08-20T17:35:22Z

Trixter: /* Doesn't in4k cover this material? */

== History ==

sizecoding.org grew from a conversation between [[User:Trixter|Trixter]], [[User:HellMood|HellMood]], and [[User:qkumba|qkumba]] when it was determined there was no central repository for sizecoding information. Trixter had inquired because VileR was dipping his toes into the lake that is sizecoding, and wanted to point him to a starting point for resources suitable for beginners. None existed, so Trixter stood up sizecoding.org, and all three of them contributed information and examples to the initial launch.

Many thanks to the entire demoscene for knowledge and inspiration.

== Why a Wiki? ==

Wikis have the lowest barrier to entry for contributing to information stores. We encourage the entire demoscene and assembler programming community to contribute.

== Doesn't in4k cover this material? ==

[https://in4k.github.io/ in4k] mostly concentrates on 1k and larger productions, across all environments (Windows, javascript, webgl, etc.). SizeCoding is much more targeted, and concentrates on 512b and lower, x86 only.

SizeCoding:About

2016-08-20T17:27:36Z

Trixter:

== History ==

sizecoding.org grew from a conversation between [[User:Trixter|Trixter]], [[User:HellMood|HellMood]], and [[User:qkumba|qkumba]] when it was determined there was no central repository for sizecoding information. Trixter had inquired because VileR was dipping his toes into the lake that is sizecoding, and wanted to point him to a starting point for resources suitable for beginners. None existed, so Trixter stood up sizecoding.org, and all three of them contributed information and examples to the initial launch.

Many thanks to the entire demoscene for knowledge and inspiration.

== Why a Wiki? ==

Wikis have the lowest barrier to entry for contributing to information stores. We encourage the entire demoscene and assembler programming community to contribute.

== Doesn't in4k cover this material? ==

in4k mostly concentrates on 1k and larger productions, across all environments (Windows, javascript, webgl, etc.). SizeCoding is much more targeted, and concentrates on 512b and lower, x86 only.

2016-08-18T16:35:11Z

Trixter:

The FPU offers a lot of complex floating-point operations not available to classic x86 CPUs, like <code>SIN</code>, <code>COS</code>, <code>ATAN</code>, <code>SQRT</code>, etc. ([http://www.website.masmforum.com/tutorials/fptute/appen1.htm SIMPLY FPU] by Raymond Filiatreault has a compact overview of all FPU commands for the curious.)

== FPU Basics ==

Usage and communication with the FPU is quite uncommon and takes a bit to get used to, so we'll start with a simple example. This is what [[Output#Outputting_in_mode_13h_.28320x200.29|our code example]] looks like originally:

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get column in AH
add ax,di ; offset by framecounter <-- REPLACE THIS WITH FPU CODE
xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

and this is how the code looks if we replace the instruction with FPU code :

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get "column" in AX

fninit ; init FPU first
mov [si],ax ; write first addend to a memory location
fild word [si] ; F(pu) I(nteger) L(oad)D a WORD from memory location to the FPU stack
mov [si],di ; write second addend to a memory location
fiadd word [si] ; Directly add the word in the memory location to the top FPU stack
fist word [si] ; F(pu) I(nteger) ST(ore) the result into a memory location
mov ax,[si] ; Get the word from the memory location into AX

xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

(Obviously that made the program bigger instead of smaller, but the point of this exercise is to illustrate how to work with the FPU.) Looking at our changes, you get a sense of what usual interaction with the FPU is:
# <code>F(N)INIT</code>: Initialize the FPU
# transfer values from CPU registers to memory location(s)
# transfer values from memory location(s) onto FPU stack
# do the actual calculations using the FPU (more on this soon)
# transfer result from the FPU stack into memory location(s)
# transfer result from memory location(s) back into registers

That is a lot of extra code for a single integer addition, but that's a simple example; ''once more complex floating point operations are involved, it starts to pay off.''

== Optimizing with the FPU ==

For more advanced FPU operation, let's start from scratch with an unoptimized program which plots the distance of each pixel to the screen center as color, in 49 bytes.

[[File:Distance to center example.png|thumb|Distance to center]]

<syntaxhighlight lang="nasm">push 0a000h
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
fninit ; -
; it's useful to comment what's on the
; stack after each FPU operation
; to not get lost ;) start is : empty (-)
X:
xor dx,dx ; reset the high word before division
mov bx,320 ; 320 columns
mov ax,di ; get screen pointer in AX
div bx ; construct X,Y from screen pointer into AX,DX
sub ax,100 ; subtract the origin
sub dx,160 ; = (160,100) ... center of 320x200 screen
mov [si],ax ; move X into a memory location
fild word [si] ; X
fmul st0 ; X²
mov [si],dx ; move Y into a memory location
fild word [si] ; Y X²
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp word [si] ; -
mov ax,[si] ; get the result from memory
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

A few words on this :
* The FPU registers (st0, st1, ...) are organized as a stack. When you load something to the FPU, everything else will be moved one location further away from the top (implicitly!) Some FPU instructions work only on the top, other allow the explicit parametrization with arbitrary FPU registers.
* Depending on what you do, sometimes <code>F(N)INIT</code> can be omitted. Real hardware will refuse to work more often than emulators, but it's always worth the try.
* Accessing memory (size) efficiently can be a real pain. The safest way is to reference absolute memory locations (f.e <code>[1234]</code>) but that's two bytes more per instruction than referencing memory with <code>[BX]</code>, <code>[SI]</code>, <code>[BX+SI]</code>, <code>[BP+DI]</code>, <code>[BP+SI]</code>, <code>[DI]</code> or <code>[BX+DI]</code>. When working with FPU and this ''classic'' approach of FPU communication, you have to design your codeflow to have one or some of these locations available.
* Accessing the memory is always with regard to the segment register <code>DS</code> unless you perform segment overrides. When accessing memory with <code>[BP+??]</code> be aware that the memory is accessed with regard to the segment register <code>SS</code> (see [http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_4/CH04-2.html here, at 4.6.2.2 The Register Indirect Addressing Modes])
* There are a few conventions which help you identify FPU commands. "i" stands for integer (WORD or DWORD), "p" means "pop stack afterwards", so <code>FST</code> means just "store" while <code>FISTP</code> means "store as integer, then pop the stack"

Now let's unleash the state of the art sizecoding arsenal onto this, to bring it down to 37 bytes (40 bytes with aspect correction)

[[File:Distant to center optimized.png|thumb|Distance to center : optimized]]

<syntaxhighlight lang="nasm">push 0a000h - 70 ; modified to center to 160,100
aas ; aspect ratio constant part
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
X:
mov ax,0xCCCD ; perform the famous...
mul di ; ... Rrrola trick =)
sub dh,[si] ; align vertically
pusha ; push all registers on stack
fild word [bx-8] ; X
fmul st0 ; X²
fild word [bx-9] ; Y X²
fmul dword [bx+si] ; aspect ratio correction
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp dword [bx-5] ; -
popa ; pop all registers from stack
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

The resulting image is almost identical to to the former. Let's go through this step by step:

* <code>push 0a000h - 70</code>
Instead of aligning horizontally with <code>sub dx,160</code> we can code this implicitly by moving our segment register ten units - that is 10 * 16 = 160 pixels - to the left (see [https://en.wikipedia.org/wiki/X86_memory_segmentation#Real_mode Real Mode Addressing]). With further multiple subtraction of 20 units - that is 320 pixels, we can shift the visible screen towards the top, to finetune vertical alignment. As long as this shift is no more than 4 lines ''( 65536 / 320 - 200 = 4,8 )'' there is no further visual impact.
* <code>aas</code>
This is the high byte of a constant, placed in a way that <code>[SI]</code> or <code>[BX+SI]</code> resolves to ~1.24 when read as 32bit float. The last byte of segment <code>ES</code> is also of importance. Check yourself with the [http://www.h-schmidt.net/FloatConverter/IEEE754.html IEEE 754 Converter]
* <code>mov ax,0xCCCD</code> & <code>mul di</code> (The "Rrrola trick")
Instead of constructing X and Y from the screen pointer <code>DI</code> with <code>DIV</code> you can get a decent estimation with multiplying the screen pointer with <code>0xCCCD</code> and read X and Y from the 8bit registers <code>DH</code> (+DL as 16bit value) and <code>DL</code> (+AH as 16bit value). The idea is to interpret <code>DI</code> as a kind of 16 bit float in the range <code>[0,1]</code>, from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results in the row before the comma, and again as a kind of a float, the column after the comma. The representation <code>0xCCCD</code> is the nearest rounding of 204,8 * 256 ( = 52428,8 ~ 52429 = 0xCCCD). As long as the 16 bit representations are used, there is no precision loss.
* <code>sub dh,[si]</code>
The instruction at <code>[SI]</code> is <code>push <word></code> and has the opcode <code>0x68</code> which is 104 in decimal. Combined with the fine tuned vertical alignment above ( ~4 lines) this results in (virtually) subtracting 100 for perfect vertical alignment. This is one byte shorter than <code>sub dh,100</code>.
* <code>pusha / popa</code>
Instead of going the ''classical'' way of communicating with the FPU, we push all the registers, read/write values with memory addressing to/from the FPU, then pop all registers again. This works when <code>DS</code> = <code>SS</code> and <code>SP</code> is "close enough" to <code>BX</code> (initially zero and kept that way) to allow <code>[BX+<signed byte>]</code> addressing. It comes with the special benefit of implicit 8bit shifts. One serious drawback is loss of precision, since the registers <code>DL</code> and <code>AH</code> "lose connection" when using <code>PUSHA</code> (see the order of registers : [http://x86.renejeschke.de/html/file_module_x86_id_270.html PUSHA/PUSHAD documentation]
*<code>fild word [bx+<signed byte>]</code> & *<code>fistp dword [bx+<signed byte>]</code>
This is the so called "stack addressing". We assume that <code>BX=0</code> and <code>SP=0xFFFE</code> at start, so we know where the registers are in memory after <code>pusha</code> (AX at [BX-4], CX at [BX-6] etc.). It's important to realize that we work with signed 16 bit values now, in the full range of [-32768,32767]. That is also why we need <code>DWORD</code> when storing the result : <code>sqrt(x²+y²)</code> exceeds the signed 16bit range for quite some value pairs. Note that there are already implicit 8bit shifts (bx-9,bx-5)
*<code>fmul dword [bx+si]</code>
With the "Rrrola" trick above, we have the row number to be 204 at maximum, but also the column can't be greater than 256. This results in a wrong aspect ratio, but it can almost completely be fixed with this two byte instruction (+ one byte for the <code>AAS</code> instruction) : 256 * 1,24 = 317,44 which is quite close to 320. If aspect ratio is of no meaning to the desired effect, this three bytes can be shaved off.

Now let's add some features:
* extract angle as opposed to the distance and combine both
* reverse divide the distance to create the "tunnel" effect
* animate with smooth steps along the distance
* improve on the colors with subselecting from the standard palette
* quit the program on ESC

This results in the following program with a size of 63 bytes :

[[File:Tunnel effect neontube.png|thumb|tunnel effect neontube]]

<syntaxhighlight lang="nasm">push 0xa000 - 10 - 3 * 20 ; video base - 3.5 lines
or al, 0x13 ; mode 13h = 320 x 200 in 256 colors
pop es ; get aligned video memory base
int 0x10 ; switch videomode
X:
sub dh, [si] ; vertical alignment
pusha ; push all registers on stack
fild word [bx-9] ; fpustack : x
fild word [bx-8] ; fpustack : y x
fpatan ; fpustack : arc
fst st1 ; fpustack : arc arc
fcos ; fpustack : cos(arc) arc
fimul dword [si] ; fpustack : l*cos(arc) arc
fidiv word [bx-8] ; fpustack : l*cos(arc)/x arc
fiadd word [bp+si] ; fpustack : l*cos(arc)/x+offset arc
fistp dword [bx-7] ; fpustack : arc
fimul word [byte si+val] ; fpustack : scaled_arc
fistp word [bx-5] ; fpustack : -
popa ; pop all registers from stack
xor al, cl ; XOR scaled_arc with distance
and al, 16 + 8 + 2 ; sub selecting palette part
stosb ; writing to screen
mov ax, 0xCCCD ; Performing the famous
mul di ; Rrrola trick
jo X ; next frame check
add word [bp+si], byte 23 ; change offset smoothly
in al, 0x60 ; check for ...
dec ax ; ...ESC key
jnz X ; otherwise continue
ret ; quit program
val: dw 6519 ; n = 160 * 256 / pi / 2 ; 0x1977</syntaxhighlight>

Many other tiny tunnel effects have been coded, so it is highly recommended to check out the documented source code of [http://web.archive.org/web/20050216133244/http://www.farb-rausch.de/ryg/tunnel.asm "Constant Evolution" by ryg/Farbrausch] and the [http://www.pouet.net/prod.php?which=29412 "Heart shaped tunnel" from Lord Kelvin], both with a size of 64 bytes. While "Constant Evolution" takes a slightly different route than the example here (''classic'' FPU communication, ''classic'' X Y construction, sqrt(x²+y²) instead of using <code>fcos</code>+<code>fimul</code>), "Heart shaped tunnel" uses no FPU at all.

The takeaways from this example are:

* Loading a constant from the code with some degrees of freedom
<code>fimul dword [si]</code> multiplies with a 32 bit integer dividend for the tunnel effect. The highest byte of this constant points to our code, to the opcode from <code>or al, 0x13</code>. This instruction puts <code>0x13</code> into <code>al</code>, and since there a lot of possibilities to achieve this, there is a direct way of changing the appearance of the tunnel with changing this instruction to one of the following : <code>mov al,0x13</code>, <code>add al,0x13</code>, <code>xor al,0x13</code>, <code>adc al,0x13</code>, <code>sbb al,0xED</code> or <code>sub al,0xED</code>. In this special case, the instruction can also be swapped with <code>pop es</code> to gain a further degree of freedom.

* normal loading of a constant which can't be reused as opcode
Although it's the ultimate goal to not even use a single extra byte for constants, sometimes the required sequence simply does not appear in the code. In this case, a constant is needed to convert the angle from the range [-pi,pi] to the color space in a way that no gaps appear while stepping from 359° to 0°. In the last line at <code>val:</code> the value <code>160</code> in the comment is 32 * 5 where 5 is number of "spiral arms" the tunnel effect has. The 8bit shift (*256) is to increase precision. It turns out that 16bit precision is enough to get a decent "gap closer" for values obtained by <code>fpatan</code>.

* operating directly on an indirect memory location without offset
The location <code>[bp+si]</code> is used as animation variable, while both participatory registers are kept fixed (the value is <code>0x0A??</code> and therefor way above our code). Since we work with 16bit values and the top 8bit are the measurement in pixels, the instruction <code>add word [bp+si], byte 23</code> allows for sub pixel precision in animation, while occupying 3 bytes of space. Depending on the target hardware, this value 23 can be increased/decreased to achieve faster/smoother animation.

* Optimizing the check for the next frame
Normally, there is a check like <code>test di,di</code> with direct consecutive branch necessary. The used approach allows for direct branching after <code>mul di</code> with <code>jo</code>, since the overflow flag is always but twice triggered for a frame. This saves two bytes, but also requires adjustment of the animation constant, because the animation constant is also added twice. A further benefit is that in one of these two cases, <code>AX</code> is zero which save a further byte on the following ESC check (<code>dec ax</code> instead of <code>dec al</code> )

Now if we abandon all the comfort, alignment, smoothness and convenience, and optimize this straight for size, we end up with a 52 byte version. This does not include the possible exclusion of color tuning (2 bytes), after all the effect is supposed to look at least somewhat appealing ;)

[[File:Neontube 52b optimized.png|thumb|Neontube 52b optimized]]
<syntaxhighlight lang="nasm">mov al,0x13
int 0x10
X:
or al, [bp+si]
xor al, 0x68
mov dx, 0x79F
pusha
fild word [bx-9] ; x
fild word [bx-8] ; y x
fpatan ; arc
fst st1 ; arc arc
fcos ; cos(arc) arc
fimul dword [si] ; l*cos(arc) arc
fidiv word [bx-8] ; l*cos(arc)/x arc
fistp dword [bx-4] ; arc
fimul word [bx] ; scarc
fistp word [bx-5] ; -
popa
sub ah, [bp+si]
xor al, ah
and al, 16 + 8 + 4
stosb
mov ax, 0xCCCD
mul di
jmp short X-1</syntaxhighlight>

''to be continued''

Floating-point Opcodes

2016-08-18T16:34:45Z

Trixter: /* Optimizing with the FPU */

The FPU offers a lot of complex floating-point operations not available to classic x86 CPUs, like <code>SIN</code>, <code>COS</code>, <code>ATAN</code>, <code>SQRT</code>, etc. ([http://www.website.masmforum.com/tutorials/fptute/appen1.htm SIMPLY FPU] by Raymond Filiatreault has a compact overview of all FPU commands for the curious.)

== FPU Basics ==

Usage and communication with the FPU is quite uncommon and takes a bit to get used to, so we'll start with a simple example. This is what [[Output#Outputting_in_mode_13h_.28320x200.29|our code example]] looks like originally:

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get column in AH
add ax,di ; offset by framecounter <-- REPLACE THIS WITH FPU CODE
xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

and this is how the code looks if we replace the instruction with FPU code :

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get "column" in AX

fninit ; init FPU first
mov [si],ax ; write first addend to a memory location
fild word [si] ; F(pu) I(nteger) L(oad)D a WORD from memory location to the FPU stack
mov [si],di ; write second addend to a memory location
fiadd word [si] ; Directly add the word in the memory location to the top FPU stack
fist word [si] ; F(pu) I(nteger) ST(ore) the result into a memory location
mov ax,[si] ; Get the word from the memory location into AX

xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

(Obviously that made the program bigger instead of smaller, but the point of this exercise is to illustrate how to work with the FPU.) Looking at our changes, you get a sense of what usual interaction with the FPU is:
# <code>F(N)INIT</code>: Initialize the FPU
# transfer values from CPU registers to memory location(s)
# transfer values from memory location(s) onto FPU stack
# do the actual calculations using the FPU (more on this soon)
# transfer result from the FPU stack into memory location(s)
# transfer result from memory location(s) back into registers

That is a lot of extra code for a single integer addition, but that's a simple example; ''once more complex floating point operations are involved, it starts to pay off.''

== Optimizing with the FPU ==

For more advanced FPU operation, let's start from scratch with an unoptimized program which plots the distance of each pixel to the screen center as color, in 49 bytes.

[[File:Distance to center example.png|thumb|Distance to center]]

<syntaxhighlight lang="nasm">push 0a000h
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
fninit ; -
; it's useful to comment what's on the
; stack after each FPU operation
; to not get lost ;) start is : empty (-)
X:
xor dx,dx ; reset the high word before division
mov bx,320 ; 320 columns
mov ax,di ; get screen pointer in AX
div bx ; construct X,Y from screen pointer into AX,DX
sub ax,100 ; subtract the origin
sub dx,160 ; = (160,100) ... center of 320x200 screen
mov [si],ax ; move X into a memory location
fild word [si] ; X
fmul st0 ; X²
mov [si],dx ; move Y into a memory location
fild word [si] ; Y X²
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp word [si] ; -
mov ax,[si] ; get the result from memory
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

A few words on this :
* The FPU registers (st0, st1, ...) are organized as a stack. When you load something to the FPU, everything else will be moved one location further away from the top (implicitly!) Some FPU instructions work only on the top, other allow the explicit parametrization with arbitrary FPU registers.
* Depending on what you do, sometimes <code>F(N)INIT</code> can be omitted. Real hardware will refuse to work more often than emulators, but it's always worth the try.
* Accessing memory (size) efficiently can be a real pain. The safest way is to reference absolute memory locations (f.e <code>[1234]</code>) but that's two bytes more per instruction than referencing memory with <code>[BX]</code>, <code>[SI]</code>, <code>[BX+SI]</code>, <code>[BP+DI]</code>, <code>[BP+SI]</code>, <code>[DI]</code> or <code>[BX+DI]</code>. When working with FPU and this ''classic'' approach of FPU communication, you have to design your codeflow to have one or some of these locations available.
* Accessing the memory is always with regard to the segment register <code>DS</code> unless you perform segment overrides. When accessing memory with <code>[BP+??]</code> be aware that the memory is accessed with regard to the segment register <code>SS</code> (see [http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_4/CH04-2.html here, at 4.6.2.2 The Register Indirect Addressing Modes])
* There are a few conventions which help you identify FPU commands. "i" stands for integer (WORD or DWORD), "p" means "pop stack afterwards", so <code>FST</code> means just "store" while <code>FISTP</code> means "store as integer, then pop the stack"

Now let's unleash the state of the art sizecoding arsenal onto this, to bring it down to 37 bytes (40 bytes with aspect correction)

[[File:Distant to center optimized.png|thumb|Distance to center : optimized]]

<syntaxhighlight lang="nasm">push 0a000h - 70 ; modified to center to 160,100
aas ; aspect ratio constant part
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
X:
mov ax,0xCCCD ; perform the famous...
mul di ; ... Rrrola trick =)
sub dh,[si] ; align vertically
pusha ; push all registers on stack
fild word [bx-8] ; X
fmul st0 ; X²
fild word [bx-9] ; Y X²
fmul dword [bx+si] ; aspect ratio correction
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp dword [bx-5] ; -
popa ; pop all registers from stack
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

The resulting image is almost identical to to the former. Let's go through this step by step:

* <code>push 0a000h - 70</code>
Instead of aligning horizontally with <code>sub dx,160</code> we can code this implicitly by moving our segment register ten units - that is 10 * 16 = 160 pixels - to the left (see [https://en.wikipedia.org/wiki/X86_memory_segmentation#Real_mode Real Mode Addressing]). With further multiple subtraction of 20 units - that is 320 pixels, we can shift the visible screen towards the top, to finetune vertical alignment. As long as this shift is no more than 4 lines ''( 65536 / 320 - 200 = 4,8 )'' there is no further visual impact.
* <code>aas</code>
This is the high byte of a constant, placed in a way that <code>[SI]</code> or <code>[BX+SI]</code> resolves to ~1.24 when read as 32bit float. The last byte of segment <code>ES</code> is also of importance. Check yourself with the [http://www.h-schmidt.net/FloatConverter/IEEE754.html IEEE 754 Converter]
* <code>mov ax,0xCCCD</code> & <code>mul di</code> (The "Rrrola trick")
Instead of constructing X and Y from the screen pointer <code>DI</code> with <code>DIV</code> you can get a decent estimation with multiplying the screen pointer with <code>0xCCCD</code> and read X and Y from the 8bit registers <code>DH</code> (+DL as 16bit value) and <code>DL</code> (+AH as 16bit value). The idea is to interpret <code>DI</code> as a kind of 16 bit float in the range <code>[0,1]</code>, from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results in the row before the comma, and again as a kind of a float, the column after the comma. The representation <code>0xCCCD</code> is the nearest rounding of 204,8 * 256 ( = 52428,8 ~ 52429 = 0xCCCD). As long as the 16 bit representations are used, there is no precision loss.
* <code>sub dh,[si]</code>
The instruction at <code>[SI]</code> is <code>push <word></code> and has the opcode <code>0x68</code> which is 104 in decimal. Combined with the fine tuned vertical alignment above ( ~4 lines) this results in (virtually) subtracting 100 for perfect vertical alignment. This is one byte shorter than <code>sub dh,100</code>.
* <code>pusha / popa</code>
Instead of going the ''classical'' way of communicating with the FPU, we push all the registers, read/write values with memory addressing to/from the FPU, then pop all registers again. This works when <code>DS</code> = <code>SS</code> and <code>SP</code> is "close enough" to <code>BX</code> (initially zero and kept that way) to allow <code>[BX+<signed byte>]</code> addressing. It comes with the special benefit of implicit 8bit shifts. One serious drawback is loss of precision, since the registers <code>DL</code> and <code>AH</code> "lose connection" when using <code>PUSHA</code> (see the order of registers : [http://x86.renejeschke.de/html/file_module_x86_id_270.html PUSHA/PUSHAD documentation]
*<code>fild word [bx+<signed byte>]</code> & *<code>fistp dword [bx+<signed byte>]</code>
This is the so called "stack addressing". We assume that <code>BX=0</code> and <code>SP=0xFFFE</code> at start, so we know where the registers are in memory after <code>pusha</code> (AX at [BX-4], CX at [BX-6] etc.). It's important to realize that we work with signed 16 bit values now, in the full range of [-32768,32767]. That is also why we need <code>DWORD</code> when storing the result : <code>sqrt(x²+y²)</code> exceeds the signed 16bit range for quite some value pairs. Note that there are already implicit 8bit shifts (bx-9,bx-5)
*<code>fmul dword [bx+si]</code>
With the "Rrrola" trick above, we have the row number to be 204 at maximum, but also the column can't be greater than 256. This results in a wrong aspect ratio, but it can almost completely be fixed with this two byte instruction (+ one byte for the <code>AAS</code> instruction) : 256 * 1,24 = 317,44 which is quite close to 320. If aspect ratio is of no meaning to the desired effect, this three bytes can be shaved off.

=== Adding some features ===

Now let's add some features:
* extract angle as opposed to the distance and combine both
* reverse divide the distance to create the "tunnel" effect
* animate with smooth steps along the distance
* improve on the colors with subselecting from the standard palette
* quit the program on ESC

This results in the following program with a size of 63 bytes :

[[File:Tunnel effect neontube.png|thumb|tunnel effect neontube]]

<syntaxhighlight lang="nasm">push 0xa000 - 10 - 3 * 20 ; video base - 3.5 lines
or al, 0x13 ; mode 13h = 320 x 200 in 256 colors
pop es ; get aligned video memory base
int 0x10 ; switch videomode
X:
sub dh, [si] ; vertical alignment
pusha ; push all registers on stack
fild word [bx-9] ; fpustack : x
fild word [bx-8] ; fpustack : y x
fpatan ; fpustack : arc
fst st1 ; fpustack : arc arc
fcos ; fpustack : cos(arc) arc
fimul dword [si] ; fpustack : l*cos(arc) arc
fidiv word [bx-8] ; fpustack : l*cos(arc)/x arc
fiadd word [bp+si] ; fpustack : l*cos(arc)/x+offset arc
fistp dword [bx-7] ; fpustack : arc
fimul word [byte si+val] ; fpustack : scaled_arc
fistp word [bx-5] ; fpustack : -
popa ; pop all registers from stack
xor al, cl ; XOR scaled_arc with distance
and al, 16 + 8 + 2 ; sub selecting palette part
stosb ; writing to screen
mov ax, 0xCCCD ; Performing the famous
mul di ; Rrrola trick
jo X ; next frame check
add word [bp+si], byte 23 ; change offset smoothly
in al, 0x60 ; check for ...
dec ax ; ...ESC key
jnz X ; otherwise continue
ret ; quit program
val: dw 6519 ; n = 160 * 256 / pi / 2 ; 0x1977</syntaxhighlight>

Many other tiny tunnel effects have been coded, so it is highly recommended to check out the documented source code of [http://web.archive.org/web/20050216133244/http://www.farb-rausch.de/ryg/tunnel.asm "Constant Evolution" by ryg/Farbrausch] and the [http://www.pouet.net/prod.php?which=29412 "Heart shaped tunnel" from Lord Kelvin], both with a size of 64 bytes. While "Constant Evolution" takes a slightly different route than the example here (''classic'' FPU communication, ''classic'' X Y construction, sqrt(x²+y²) instead of using <code>fcos</code>+<code>fimul</code>), "Heart shaped tunnel" uses no FPU at all.

The takeaways from this example are:

* Loading a constant from the code with some degrees of freedom
<code>fimul dword [si]</code> multiplies with a 32 bit integer dividend for the tunnel effect. The highest byte of this constant points to our code, to the opcode from <code>or al, 0x13</code>. This instruction puts <code>0x13</code> into <code>al</code>, and since there a lot of possibilities to achieve this, there is a direct way of changing the appearance of the tunnel with changing this instruction to one of the following : <code>mov al,0x13</code>, <code>add al,0x13</code>, <code>xor al,0x13</code>, <code>adc al,0x13</code>, <code>sbb al,0xED</code> or <code>sub al,0xED</code>. In this special case, the instruction can also be swapped with <code>pop es</code> to gain a further degree of freedom.

* normal loading of a constant which can't be reused as opcode
Although it's the ultimate goal to not even use a single extra byte for constants, sometimes the required sequence simply does not appear in the code. In this case, a constant is needed to convert the angle from the range [-pi,pi] to the color space in a way that no gaps appear while stepping from 359° to 0°. In the last line at <code>val:</code> the value <code>160</code> in the comment is 32 * 5 where 5 is number of "spiral arms" the tunnel effect has. The 8bit shift (*256) is to increase precision. It turns out that 16bit precision is enough to get a decent "gap closer" for values obtained by <code>fpatan</code>.

* operating directly on an indirect memory location without offset
The location <code>[bp+si]</code> is used as animation variable, while both participatory registers are kept fixed (the value is <code>0x0A??</code> and therefor way above our code). Since we work with 16bit values and the top 8bit are the measurement in pixels, the instruction <code>add word [bp+si], byte 23</code> allows for sub pixel precision in animation, while occupying 3 bytes of space. Depending on the target hardware, this value 23 can be increased/decreased to achieve faster/smoother animation.

* Optimizing the check for the next frame
Normally, there is a check like <code>test di,di</code> with direct consecutive branch necessary. The used approach allows for direct branching after <code>mul di</code> with <code>jo</code>, since the overflow flag is always but twice triggered for a frame. This saves two bytes, but also requires adjustment of the animation constant, because the animation constant is also added twice. A further benefit is that in one of these two cases, <code>AX</code> is zero which save a further byte on the following ESC check (<code>dec ax</code> instead of <code>dec al</code> )

Now if we abandon all the comfort, alignment, smoothness and convenience, and optimize this straight for size, we end up with a 52 byte version. This does not include the possible exclusion of color tuning (2 bytes), after all the effect is supposed to look at least somewhat appealing ;)

[[File:Neontube 52b optimized.png|thumb|Neontube 52b optimized]]
<syntaxhighlight lang="nasm">mov al,0x13
int 0x10
X:
or al, [bp+si]
xor al, 0x68
mov dx, 0x79F
pusha
fild word [bx-9] ; x
fild word [bx-8] ; y x
fpatan ; arc
fst st1 ; arc arc
fcos ; cos(arc) arc
fimul dword [si] ; l*cos(arc) arc
fidiv word [bx-8] ; l*cos(arc)/x arc
fistp dword [bx-4] ; arc
fimul word [bx] ; scarc
fistp word [bx-5] ; -
popa
sub ah, [bp+si]
xor al, ah
and al, 16 + 8 + 4
stosb
mov ax, 0xCCCD
mul di
jmp short X-1</syntaxhighlight>

''to be continued''

Floating-point Opcodes

2016-08-18T16:33:33Z

Trixter: Clarified sections and wording

The FPU offers a lot of complex floating-point operations not available to classic x86 CPUs, like <code>SIN</code>, <code>COS</code>, <code>ATAN</code>, <code>SQRT</code>, etc. ([http://www.website.masmforum.com/tutorials/fptute/appen1.htm SIMPLY FPU] by Raymond Filiatreault has a compact overview of all FPU commands for the curious.)

== FPU Basics ==

Usage and communication with the FPU is quite uncommon and takes a bit to get used to, so we'll start with a simple example. This is what [[Output#Outputting_in_mode_13h_.28320x200.29|our code example]] looks like originally:

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get column in AH
add ax,di ; offset by framecounter <-- REPLACE THIS WITH FPU CODE
xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

and this is how the code looks if we replace the instruction with FPU code :

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get "column" in AX

fninit ; init FPU first
mov [si],ax ; write first addend to a memory location
fild word [si] ; F(pu) I(nteger) L(oad)D a WORD from memory location to the FPU stack
mov [si],di ; write second addend to a memory location
fiadd word [si] ; Directly add the word in the memory location to the top FPU stack
fist word [si] ; F(pu) I(nteger) ST(ore) the result into a memory location
mov ax,[si] ; Get the word from the memory location into AX

xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

(Obviously that made the program bigger instead of smaller, but the point of this exercise is to illustrate how to work with the FPU.) Looking at our changes, you get a sense of what usual interaction with the FPU is:
# <code>F(N)INIT</code>: Initialize the FPU
# transfer values from CPU registers to memory location(s)
# transfer values from memory location(s) onto FPU stack
# do the actual calculations using the FPU (more on this soon)
# transfer result from the FPU stack into memory location(s)
# transfer result from memory location(s) back into registers

That is a lot of extra code for a single integer addition, but that's a simple example; ''once more complex floating point operations are involved, it starts to pay off.''

== Optimizing with the FPU ==

For more advanced FPU operation, let's start from scratch with an unoptimized program which plots the distance of each pixel to the screen center as color, in 49 bytes.

[[File:Distance to center example.png|thumb|Distance to center]]

<syntaxhighlight lang="nasm">push 0a000h
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
fninit ; -
; it's useful to comment what's on the
; stack after each FPU operation
; to not get lost ;) start is : empty (-)
X:
xor dx,dx ; reset the high word before division
mov bx,320 ; 320 columns
mov ax,di ; get screen pointer in AX
div bx ; construct X,Y from screen pointer into AX,DX
sub ax,100 ; subtract the origin
sub dx,160 ; = (160,100) ... center of 320x200 screen
mov [si],ax ; move X into a memory location
fild word [si] ; X
fmul st0 ; X²
mov [si],dx ; move Y into a memory location
fild word [si] ; Y X²
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp word [si] ; -
mov ax,[si] ; get the result from memory
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

A few words on this :
* The FPU registers (st0, st1, ...) are organized as a stack. When you load something to the FPU, everything else will be moved one location further away from the top (implicitly!) Some FPU instructions work only on the top, other allow the explicit parametrization with arbitrary FPU registers.
* Depending on what you do, sometimes <code>F(N)INIT</code> can be omitted. Real hardware will refuse to work more often than emulators, but it's always worth the try.
* Accessing memory (size) efficiently can be a real pain. The safest way is to reference absolute memory locations (f.e <code>[1234]</code>) but that's two bytes more per instruction than referencing memory with <code>[BX]</code>, <code>[SI]</code>, <code>[BX+SI]</code>, <code>[BP+DI]</code>, <code>[BP+SI]</code>, <code>[DI]</code> or <code>[BX+DI]</code>. When working with FPU and this ''classic'' approach of FPU communication, you have to design your codeflow to have one or some of these locations available.
* Accessing the memory is always with regard to the segment register <code>DS</code> unless you perform segment overrides. When accessing memory with <code>[BP+??]</code> be aware that the memory is accessed with regard to the segment register <code>SS</code> (see [http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_4/CH04-2.html here, at 4.6.2.2 The Register Indirect Addressing Modes])
* There are a few conventions which help you identify FPU commands. "i" stands for integer (WORD or DWORD), "p" means "pop stack afterwards", so <code>FST</code> means just "store" while <code>FISTP</code> means "store as integer, then pop the stack"

Now let's unleash the state of the art sizecoding arsenal onto this, to bring it down to 37 bytes (40 bytes with aspect correction)

[[File:Distant to center optimized.png|thumb|Distance to center : optimized]]

<syntaxhighlight lang="nasm">push 0a000h - 70 ; modified to center to 160,100
aas ; aspect ratio constant part
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
X:
mov ax,0xCCCD ; perform the famous...
mul di ; ... Rrrola trick =)
sub dh,[si] ; align vertically
pusha ; push all registers on stack
fild word [bx-8] ; X
fmul st0 ; X²
fild word [bx-9] ; Y X²
fmul dword [bx+si] ; aspect ratio correction
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp dword [bx-5] ; -
popa ; pop all registers from stack
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

The resulting image is almost identical to to the former. Let's go through this step by step:

* <code>push 0a000h - 70</code>
Instead of aligning horizontally with <code>sub dx,160</code> we can code this implicitly by moving our segment register ten units - that is 10 * 16 = 160 pixels - to the left (see [https://en.wikipedia.org/wiki/X86_memory_segmentation#Real_mode Real Mode Addressing]). With further multiple subtraction of 20 units - that is 320 pixels, we can shift the visible screen towards the top, to finetune vertical alignment. As long as this shift is no more than 4 lines ''( 65536 / 320 - 200 = 4,8 )'' there is no further visual impact.
* <code>aas</code>
This is the high byte of a constant, placed in a way that <code>[SI]</code> or <code>[BX+SI]</code> resolves to ~1.24 when read as 32bit float. The last byte of segment <code>ES</code> is also of importance. Check yourself with the [http://www.h-schmidt.net/FloatConverter/IEEE754.html IEEE 754 Converter]
* <code>mov ax,0xCCCD</code> & <code>mul di</code> (The "Rrrola trick")
Instead of constructing X and Y from the screen pointer <code>DI</code> with <code>DIV</code> you can get a decent estimation with multiplying the screen pointer with <code>0xCCCD</code> and read X and Y from the 8bit registers <code>DH</code> (+DL as 16bit value) and <code>DL</code> (+AH as 16bit value). The idea is to interpret <code>DI</code> as a kind of 16 bit float in the range <code>[0,1]</code>, from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results in the row before the comma, and again as a kind of a float, the column after the comma. The representation <code>0xCCCD</code> is the nearest rounding of 204,8 * 256 ( = 52428,8 ~ 52429 = 0xCCCD). As long as the 16 bit representations are used, there is no precision loss.
* <code>sub dh,[si]</code>
The instruction at <code>[SI]</code> is <code>push <word></code> and has the opcode <code>0x68</code> which is 104 in decimal. Combined with the fine tuned vertical alignment above ( ~4 lines) this results in (virtually) subtracting 100 for perfect vertical alignment. This is one byte shorter than <code>sub dh,100</code>.
* <code>pusha / popa</code>
Instead of going the ''classical'' way of communicating with the FPU, we push all the registers, read/write values with memory addressing to/from the FPU, then pop all registers again. This works when <code>DS</code> = <code>SS</code> and <code>SP</code> is "close enough" to <code>BX</code> (initially zero and kept that way) to allow <code>[BX+<signed byte>]</code> addressing. It comes with the special benefit of implicit 8bit shifts. One serious drawback is loss of precision, since the registers <code>DL</code> and <code>AH</code> "lose connection" when using <code>PUSHA</code> (see the order of registers : [http://x86.renejeschke.de/html/file_module_x86_id_270.html PUSHA/PUSHAD documentation]
*<code>fild word [bx+<signed byte>]</code> & *<code>fistp dword [bx+<signed byte>]</code>
This is the so called "stack addressing". We assume that <code>BX=0</code> and <code>SP=0xFFFE</code> at start, so we know where the registers are in memory after <code>pusha</code> (AX at [BX-4], CX at [BX-6] etc.). It's important to realize that we work with signed 16 bit values now, in the full range of [-32768,32767]. That is also why we need <code>DWORD</code> when storing the result : <code>sqrt(x²+y²)</code> exceeds the signed 16bit range for quite some value pairs. Note that there are already implicit 8bit shifts (bx-9,bx-5)
*<code>fmul dword [bx+si]</code>
With the "Rrrola" trick above, we have the row number to be 204 at maximum, but also the column can't be greater than 256. This results in a wrong aspect ratio, but it can almost completely be fixed with this two byte instruction (+ one byte for the <code>AAS</code> instruction) : 256 * 1,24 = 317,44 which is quite close to 320. If aspect ratio is of no meaning to the desired effect, this three bytes can be shaved off.

Now let's add some features:
* extract angle as opposed to the distance and combine both
* reverse divide the distance to create the "tunnel" effect
* animate with smooth steps along the distance
* improve on the colors with subselecting from the standard palette
* quit the program on ESC

This results in the following program with a size of 63 bytes :

[[File:Tunnel effect neontube.png|thumb|tunnel effect neontube]]

<syntaxhighlight lang="nasm">push 0xa000 - 10 - 3 * 20 ; video base - 3.5 lines
or al, 0x13 ; mode 13h = 320 x 200 in 256 colors
pop es ; get aligned video memory base
int 0x10 ; switch videomode
X:
sub dh, [si] ; vertical alignment
pusha ; push all registers on stack
fild word [bx-9] ; fpustack : x
fild word [bx-8] ; fpustack : y x
fpatan ; fpustack : arc
fst st1 ; fpustack : arc arc
fcos ; fpustack : cos(arc) arc
fimul dword [si] ; fpustack : l*cos(arc) arc
fidiv word [bx-8] ; fpustack : l*cos(arc)/x arc
fiadd word [bp+si] ; fpustack : l*cos(arc)/x+offset arc
fistp dword [bx-7] ; fpustack : arc
fimul word [byte si+val] ; fpustack : scaled_arc
fistp word [bx-5] ; fpustack : -
popa ; pop all registers from stack
xor al, cl ; XOR scaled_arc with distance
and al, 16 + 8 + 2 ; sub selecting palette part
stosb ; writing to screen
mov ax, 0xCCCD ; Performing the famous
mul di ; Rrrola trick
jo X ; next frame check
add word [bp+si], byte 23 ; change offset smoothly
in al, 0x60 ; check for ...
dec ax ; ...ESC key
jnz X ; otherwise continue
ret ; quit program
val: dw 6519 ; n = 160 * 256 / pi / 2 ; 0x1977</syntaxhighlight>

Many other tiny tunnel effects have been coded, so it is highly recommended to check out the documented source code of [http://web.archive.org/web/20050216133244/http://www.farb-rausch.de/ryg/tunnel.asm "Constant Evolution" by ryg/Farbrausch] and the [http://www.pouet.net/prod.php?which=29412 "Heart shaped tunnel" from Lord Kelvin], both with a size of 64 bytes. While "Constant Evolution" takes a slightly different route than the example here (''classic'' FPU communication, ''classic'' X Y construction, sqrt(x²+y²) instead of using <code>fcos</code>+<code>fimul</code>), "Heart shaped tunnel" uses no FPU at all. The takeaways from this example are :

* Loading a constant from the code with some degrees of freedom
<code>fimul dword [si]</code> multiplies with a 32 bit integer dividend for the tunnel effect. The highest byte of this constant points to our code, to the opcode from <code>or al, 0x13</code>. This instruction puts <code>0x13</code> into <code>al</code>, and since there a lot of possibilities to achieve this, there is a direct way of changing the appearance of the tunnel with changing this instruction to one of the following : <code>mov al,0x13</code>, <code>add al,0x13</code>, <code>xor al,0x13</code>, <code>adc al,0x13</code>, <code>sbb al,0xED</code> or <code>sub al,0xED</code>. In this special case, the instruction can also be swapped with <code>pop es</code> to gain a further degree of freedom.

* normal loading of a constant which can't be reused as opcode
Although it's the ultimate goal to not even use a single extra byte for constants, sometimes the required sequence simply does not appear in the code. In this case, a constant is needed to convert the angle from the range [-pi,pi] to the color space in a way that no gaps appear while stepping from 359° to 0°. In the last line at <code>val:</code> the value <code>160</code> in the comment is 32 * 5 where 5 is number of "spiral arms" the tunnel effect has. The 8bit shift (*256) is to increase precision. It turns out that 16bit precision is enough to get a decent "gap closer" for values obtained by <code>fpatan</code>.

* operating directly on an indirect memory location without offset
The location <code>[bp+si]</code> is used as animation variable, while both participatory registers are kept fixed (the value is <code>0x0A??</code> and therefor way above our code). Since we work with 16bit values and the top 8bit are the measurement in pixels, the instruction <code>add word [bp+si], byte 23</code> allows for sub pixel precision in animation, while occupying 3 bytes of space. Depending on the target hardware, this value 23 can be increased/decreased to achieve faster/smoother animation.

* Optimizing the check for the next frame
Normally, there is a check like <code>test di,di</code> with direct consecutive branch necessary. The used approach allows for direct branching after <code>mul di</code> with <code>jo</code>, since the overflow flag is always but twice triggered for a frame. This saves two bytes, but also requires adjustment of the animation constant, because the animation constant is also added twice. A further benefit is that in one of these two cases, <code>AX</code> is zero which save a further byte on the following ESC check (<code>dec ax</code> instead of <code>dec al</code> )

Now if we abandon all the comfort, alignment, smoothness and convenience, and optimize this straight for size, we end up with a 52 byte version. This does not include the possible exclusion of color tuning (2 bytes), after all the effect is supposed to look at least somewhat appealing ;)

[[File:Neontube 52b optimized.png|thumb|Neontube 52b optimized]]
<syntaxhighlight lang="nasm">mov al,0x13
int 0x10
X:
or al, [bp+si]
xor al, 0x68
mov dx, 0x79F
pusha
fild word [bx-9] ; x
fild word [bx-8] ; y x
fpatan ; arc
fst st1 ; arc arc
fcos ; cos(arc) arc
fimul dword [si] ; l*cos(arc) arc
fidiv word [bx-8] ; l*cos(arc)/x arc
fistp dword [bx-4] ; arc
fimul word [bx] ; scarc
fistp word [bx-5] ; -
popa
sub ah, [bp+si]
xor al, ah
and al, 16 + 8 + 4
stosb
mov ax, 0xCCCD
mul di
jmp short X-1</syntaxhighlight>

''to be continued''