Tiny Intro Toolbox Thread
category: code [glöplog]
Well then I'll share my tool here ;)
Floating-point Instruction Bytecode Generator & Recompiler (fpb module)
Last version can be downloaded here (full description is inside)
Intro based on fpb module: HerbaKaif (short description is also available on this page)
This module allows to pack FPU code up to ≈ 3.5x \o/ (excluding 50-96 bytes of recompiler)
It can also be used in 256b intros too (even in 128b in some cases) :)
Floating-point Instruction Bytecode Generator & Recompiler (fpb module)
Last version can be downloaded here (full description is inside)
Intro based on fpb module: HerbaKaif (short description is also available on this page)
This module allows to pack FPU code up to ≈ 3.5x \o/ (excluding 50-96 bytes of recompiler)
It can also be used in 256b intros too (even in 128b in some cases) :)
One more tool.
grab2bmp is written to grab frames in VGA mode 13h to BMP files (that can be later converted to video).
EXAMPLE OF USING (NASM/FASM).
Initialization (only required once):
Grab an image to file (VGA mode 13h only):
grab2bmp is written to grab frames in VGA mode 13h to BMP files (that can be later converted to video).
EXAMPLE OF USING (NASM/FASM).
Initialization (only required once):
Code:
pusha
mov ax,0F001h ; function 1 (init)
mov bp,'gb' ; use 6267h in MASM/TASM
xor cx,cx ; first file number (0)
mov dx,0FFFFh ; maximal file (frame) number (use value 0FFFFh to break your program manually when you want)
mov bx,bx ; no minimal number of digits in filename (set bx = 0..7 = X to use minimum X+1 digits in filename)
int 2Fh ; call grab2bmp
popaGrab an image to file (VGA mode 13h only):
Code:
pusha
mov ax,0F003h ; function 3 (grab image)
mov bp,'gb' ; use 6267h in MASM/TASM
int 2Fh ; call grab2bmp
test al,al ; check the result (0 - success, 1 - grabbing is disabled, 2 - invalid video mode (not 13h), 3 - input/output error)
popa
jnz .exit ; exit program when all frames are grabbed (use this if dx < 0FFFFh on initialization)Using FindNumbers console tool you can find required integer and floating-point numbers (and ranges) in your binary to use code as data :)
E.g. FindNumbers intro.com /fsda 0.1 0.5 /iw 64 64 /iw 128 128 /ids * -1 will find 32-bit and 64-bit FP numbers in range from 0.1 to 0.5 and from -0.5 to -0.1, 16-bit integers with values 64 and 128 and negative signed 32-bit integers in file intro.com.
E.g. FindNumbers intro.com /fsda 0.1 0.5 /iw 64 64 /iw 128 128 /ids * -1 will find 32-bit and 64-bit FP numbers in range from 0.1 to 0.5 and from -0.5 to -0.1, 16-bit integers with values 64 and 128 and negative signed 32-bit integers in file intro.com.
Some noob questions:
------
When coding tiny intro we usually assume that at the start of the program we have:
AX=0, BX=0, CX=255
But Rrrola in one thread wrote that neither DosBox nor Windows clear the upper 16 bytes of registers between program launches. I guess even DOS doesn't do that.
In my case, for example, it is critical that the 16 high-order bits of ECX be in zeros.
What do you think? Should I be worried about this?
-------
What contain stack after running the program?
If I do POP AX immediately after starting the program? Will I get AX=0, or any random byte?
Or is it a bad idea to pop something from the stack without putting anything there? ;)
-------
------
When coding tiny intro we usually assume that at the start of the program we have:
AX=0, BX=0, CX=255
But Rrrola in one thread wrote that neither DosBox nor Windows clear the upper 16 bytes of registers between program launches. I guess even DOS doesn't do that.
In my case, for example, it is critical that the 16 high-order bits of ECX be in zeros.
What do you think? Should I be worried about this?
-------
What contain stack after running the program?
If I do POP AX immediately after starting the program? Will I get AX=0, or any random byte?
Or is it a bad idea to pop something from the stack without putting anything there? ;)
-------
Top stack always has 0x0000, so that RET jumps to 0x0000 and that contains "int 20h" which actually quits. Register content is mostly fixed. The top bits of ECX don't have to be zero by force. All from top of the head. www.sizecoding.org has all these information :) Or join our discord https://discord.gg/fX8Yk4b5 :)
HellMood, thanx ;)
Hi guys. I found a strange behavior in "DOSBox-X".
In real-mode this operation bring fits of anger at DOSBOX-X:
message in the console: "Segment limit violation. Limit check ffff+2-1 = 10000 > ffff ES:DI"
It causes lag or freeze.
There is no such problem in the official version of DosBox. Just like on real hardware.
What do you think about this? Is this a DosBox-x bug?
How important it is to avoid such situations when it comes to sizecoding?
In real-mode this operation bring fits of anger at DOSBOX-X:
Code:
mov di, 0ffffh
stosw
message in the console: "Segment limit violation. Limit check ffff+2-1 = 10000 > ffff ES:DI"
It causes lag or freeze.
There is no such problem in the official version of DosBox. Just like on real hardware.
What do you think about this? Is this a DosBox-x bug?
How important it is to avoid such situations when it comes to sizecoding?
i think Free DOS freezes too.
