Go to bottom

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) :)
added on the 2021-04-05 13:16:24 by Jin X Jin X
One more tool.
grab2bmp is written to grab frames in VGA mode 13h to BMP files (that can be later converted to video).


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 popa

Grab 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)
added on the 2022-02-07 16:00:45 by Jin X Jin X
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.
added on the 2022-02-07 16:14:16 by Jin X Jin X
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? ;)

added on the 2022-08-05 18:50:44 by bitl bitl
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 :)
added on the 2022-08-05 19:51:06 by HellMood HellMood
HellMood, thanx ;)
added on the 2022-08-05 20:22:06 by bitl bitl
Hi guys. I found a strange behavior in "DOSBox-X".

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?
added on the 2022-10-21 16:04:55 by bitl bitl
i think Free DOS freezes too.


Go to top