Tiny Intro Toolbox Thread
category: code [glöplog]
Digimind and ryg discussing hard - lovely thread.
Waiting impatiently for 256B intro from las.
Introduction
Zine #12 article: English | Polish
Operating system
Windows XP. I can't imagine working on 256B intro without possibility to run it normal way. Currently my main operating system is Windows 7 64bit, but parallelly I have installed Windows XP 32bit, DOS 6.22, and Slackware (XOSL as bootloader). I have small experience with virtual machines, but I suppose it's not too hard to setup 13h intros compatible environment.
Editor / IDE
EditPlus - lightweight and fast in one hand, in another one equipped with all necessary features for setting up great asm IDE. Except obvious attributes like cool configurability, handy editing functions, syntax coloring, auto-completion etc etc etc, allows to run external programs from editor level. Just create proper bat files and with single pressings your favorite keys assemble and run the intro. Tool groups allow to configure different programs parallelly on the same keys, so you can easily assemble sources written for different assemblers.
The only disadvantage is that it's not free.
Assembler
The Netwide Assembler - NASM, the most handy one. TASM and FASM are also fine, used by many intro coders.
Disassembler
NDISASM provided with NASM is enough.
Debugger
Unnecessary.
HexEditor
Viewing executable in hexadecimal mode is useful, for example for checking if some code parts can be used as constants. HxD is good and free. I used to use also Hex Workshop (with useful calculator), but it's not free.
Emulator
DOSBox is an obvious choice. Good, but for many intros very slow. Does not support new instructions like fcomi, so some intros (eXcentricity, Blub! II, ...) don't work there.
Evaldraw
Playing with math is usually more comfortable on the level higher than asm, so often we used languages like C or Pascal in early stages of intro developing. As Tigrou mentioned, old DOS compatible compilers are cool for this. Another great program we use is Evaldraw by Ken Silverman. Just run the attached demos and see how fantastic it is. Tutorial online.
Screenshots
Hard to understand that sometimes person with abilities to code intro in Assembler, makes its screenshot as shitty jpg with strange size, probably DOSBox window cut from whole desktop print screen.
In DOSBox press Ctrl+F5. Snarf is an example of nice DOS capture utility. Then just convert to png.
Palette
You asked about some tool for palette displaying / testing. This snippet I wrote something like hundred years ago.
Video capturing
People using latest Windows versions can't run 256B intros normal way anymore, so I decided to create videos of all IND intros. They can be watched online: Capped.TV (very good quality) and YouTube (lower quality).
Already explained as an answer to comment under some intro, let me quote:
1. Saving frames into BMP files. Using own frame-grabber which I'm linking with intro code, then executing (with DOSBox more comfortable - in background, and often faster).
2. Resizing frames with some smoothing filter - 640x400 for Capped.TV, 1280x720 for YouTube (original 320x200 looks like stamp, uploaded on YouTube looks like shit). Using FastStone Photo Resizer.
3. Converting frames to AVI - 30FPS, for exceptional fuckers 60FPS. Using VirtualDub with Xvid.
Instruction set
Many coders don't know all commands ("i didn't know shld."). Good to have handy list of all instructions with descriptions - which flags set, how many cycles need etc. Can be found on the internet. I used some old Polish books.
Registers starting values
Listed by Rrrola in another thread.
les bp,[bx]
Explained already by ryg. Use it in 32B intros only, because can cause displaying problems under DOS.
moebius
XP:
DOS:
wurm
XP:
DOS:
Waiting impatiently for 256B intro from las.
Introduction
Zine #12 article: English | Polish
Operating system
Windows XP. I can't imagine working on 256B intro without possibility to run it normal way. Currently my main operating system is Windows 7 64bit, but parallelly I have installed Windows XP 32bit, DOS 6.22, and Slackware (XOSL as bootloader). I have small experience with virtual machines, but I suppose it's not too hard to setup 13h intros compatible environment.
Editor / IDE
EditPlus - lightweight and fast in one hand, in another one equipped with all necessary features for setting up great asm IDE. Except obvious attributes like cool configurability, handy editing functions, syntax coloring, auto-completion etc etc etc, allows to run external programs from editor level. Just create proper bat files and with single pressings your favorite keys assemble and run the intro. Tool groups allow to configure different programs parallelly on the same keys, so you can easily assemble sources written for different assemblers.
The only disadvantage is that it's not free.
Assembler
The Netwide Assembler - NASM, the most handy one. TASM and FASM are also fine, used by many intro coders.
Disassembler
NDISASM provided with NASM is enough.
Debugger
Unnecessary.
HexEditor
Viewing executable in hexadecimal mode is useful, for example for checking if some code parts can be used as constants. HxD is good and free. I used to use also Hex Workshop (with useful calculator), but it's not free.
Emulator
DOSBox is an obvious choice. Good, but for many intros very slow. Does not support new instructions like fcomi, so some intros (eXcentricity, Blub! II, ...) don't work there.
Evaldraw
Playing with math is usually more comfortable on the level higher than asm, so often we used languages like C or Pascal in early stages of intro developing. As Tigrou mentioned, old DOS compatible compilers are cool for this. Another great program we use is Evaldraw by Ken Silverman. Just run the attached demos and see how fantastic it is. Tutorial online.
Screenshots
Hard to understand that sometimes person with abilities to code intro in Assembler, makes its screenshot as shitty jpg with strange size, probably DOSBox window cut from whole desktop print screen.
In DOSBox press Ctrl+F5. Snarf is an example of nice DOS capture utility. Then just convert to png.
Palette
You asked about some tool for palette displaying / testing. This snippet I wrote something like hundred years ago.
Code:
[org 100h]
mov AL,13h
int 10h
push 0A000h
pop ES
;put some palgen here
xor AX,AX
wyswietl:
xor BX,BX
xor DI,DI
add DI,AX
linia:
stosb
add DI,319
inc BX
cmp BX,200
jna short linia
inc AX
cmp AX,0FFh
jna short wyswietl
mov AH,00h
int 16h
mov AX,0003h
int 10h
retVideo capturing
People using latest Windows versions can't run 256B intros normal way anymore, so I decided to create videos of all IND intros. They can be watched online: Capped.TV (very good quality) and YouTube (lower quality).
Already explained as an answer to comment under some intro, let me quote:
1. Saving frames into BMP files. Using own frame-grabber which I'm linking with intro code, then executing (with DOSBox more comfortable - in background, and often faster).
2. Resizing frames with some smoothing filter - 640x400 for Capped.TV, 1280x720 for YouTube (original 320x200 looks like stamp, uploaded on YouTube looks like shit). Using FastStone Photo Resizer.
3. Converting frames to AVI - 30FPS, for exceptional fuckers 60FPS. Using VirtualDub with Xvid.
Instruction set
Many coders don't know all commands ("i didn't know shld."). Good to have handy list of all instructions with descriptions - which flags set, how many cycles need etc. Can be found on the internet. I used some old Polish books.
Registers starting values
Listed by Rrrola in another thread.
les bp,[bx]
Explained already by ryg. Use it in 32B intros only, because can cause displaying problems under DOS.
moebius
XP:
DOS:wurm
XP:
DOS:
About testing : some people (like me) will not be able to test or run 256b, even in pure dos/winxp because nvidia as dropped 13h mode support in their card since a very long time (who would use dos on recent 3D card anyway ?).
The only possibility then is to use dosbox (make sure core=dynamic; not set by default) or, if speed is needed, install a virtualbox machine with dos on it (look for "dos622.img" on google). Under virtualbox it will run almost as fast as under the real stuff...
The only possibility then is to use dosbox (make sure core=dynamic; not set by default) or, if speed is needed, install a virtualbox machine with dos on it (look for "dos622.img" on google). Under virtualbox it will run almost as fast as under the real stuff...
Quote:
nvidia as dropped 13h mode support in their card since a very long time
In my new comp bought last summer I have GF GTX560 and there is no problem with 13h mode.
Quote:
In my new comp bought last summer I have GF GTX560 and there is no problem with 13h mode
new pc hasbeen bought last october will laugh. w7 too:D
Great post pirx - thank you.
which video modes are supported in dos depends on the video BIOS, not the GPU; at some point they used to be different between card vendors (evga, msi, pny etc.), though i haven't checked in a long time.
Quote:
Debugger
Unnecessary.
Bahaha
@ryg: yes you are right. actually I changed both motherboard and graphic card at same time and never investigate too much. if it cames from bios / motherboard vendor (asus) it is very strange that they dont provide implementation. the card was a A8NSLI which was far from being the cheapest card of that time. why did they remove such a thing ? 10h implementation should not cost to much bytes...
How unfond of self-modifying code is windows? Would be possible to put a call-ret wrapper around a 256/512b demo and have it write to a backbuffer somewhere.. run things faster than dosbox, use moar SSE, etc?
quintix: the main problem is that dos stuff runs in 16-bit mode whereas windows code is 32-bit mode. and 64-bit windows doesn't have *any* support for 16-bit anymore.
could of sworn sincos was Pentium only... was that instruction in x87?
When people say 16bit/32bit they usually mean real mode(not necessarily 16bit)/protected mode... it should be quite possible to malloc 640k in protected mode and let pointers run wild in that space.
[bump]
fsincos, just as fsin and fcos, is 387+.
wtf - this is blatantly wrong on many different levels...
first off, independent of "what people say", there's an actual distinction between 16-bit code and 32-bit code, namely the D bit of the current code segment descriptor. with D=0, code defaults to 16-bit operand sizes and addresses; with D=1, it defaults to 32-bit operand sizes and addresses. address and operand sizes can be toggled per-instruction using the operand size (0x66) and address size (0x67) prefixes. 16-bit addressing (and its version of the mod R/M byte) is very different from (and incompatible to) the 32-bit version of the mod R/M byte (which works differently and supports the optional SIB that's used for scaled/indexed addressing modes).
16-bit code is written for D=0 (and uses operand/address size prefixes to encode usage of 32-bit registers/addressing modes when necessary). if you drop such code into a 32-bit code segment, the instructions won't even decode correctly!
this has nothing to do with real vs. protected mode. the two are completely orthogonal. you can have 16-bit real mode (8086+), 16-bit protected mode (286+), 32-bit protected mode (386+) and 32-bit real mode (386+). note the latter is very rarely used; it's related to but distinct from "unreal mode" (which has 32-bit segment base/limits set up, but still D=0). and of course there's all the permutations including v86 mode too (64-bit aka long mode is a separate thing though).
second, the amount of addressable memory in real mode (286+) is 1088k - 16 bytes, not 640k. in particular, video memory is outside the 640k range (which ends with segment 0x9fff).
third, even if you allocate enough memory, and ignoring the D bit for now, you can't just run real-mode code in protected mode because it calls interrupts that don't work in 32-bit mode and modifies segment registers expecting them to have real-mode semantics! (i.e. segment is just added to the linear address). in protected mode, you write selectors into segment registers. they work differently - they just select a segment descriptor from a descriptor table. the descriptor tables are maintained by the OS and modifying them is a privileged operation.
which brings me to the fourth point: to set up a segment descriptor with D bit set to 0, you need OS support for doing so, because you can't do it by yourself (as said, it's a privileged operation). and as i already mentioned, all 64-bit versions of windows don't support this anymore.
fin.
Quote:
When people say 16bit/32bit they usually mean real mode(not necessarily 16bit)/protected mode... it should be quite possible to malloc 640k in protected mode and let pointers run wild in that space.
wtf - this is blatantly wrong on many different levels...
first off, independent of "what people say", there's an actual distinction between 16-bit code and 32-bit code, namely the D bit of the current code segment descriptor. with D=0, code defaults to 16-bit operand sizes and addresses; with D=1, it defaults to 32-bit operand sizes and addresses. address and operand sizes can be toggled per-instruction using the operand size (0x66) and address size (0x67) prefixes. 16-bit addressing (and its version of the mod R/M byte) is very different from (and incompatible to) the 32-bit version of the mod R/M byte (which works differently and supports the optional SIB that's used for scaled/indexed addressing modes).
16-bit code is written for D=0 (and uses operand/address size prefixes to encode usage of 32-bit registers/addressing modes when necessary). if you drop such code into a 32-bit code segment, the instructions won't even decode correctly!
this has nothing to do with real vs. protected mode. the two are completely orthogonal. you can have 16-bit real mode (8086+), 16-bit protected mode (286+), 32-bit protected mode (386+) and 32-bit real mode (386+). note the latter is very rarely used; it's related to but distinct from "unreal mode" (which has 32-bit segment base/limits set up, but still D=0). and of course there's all the permutations including v86 mode too (64-bit aka long mode is a separate thing though).
second, the amount of addressable memory in real mode (286+) is 1088k - 16 bytes, not 640k. in particular, video memory is outside the 640k range (which ends with segment 0x9fff).
third, even if you allocate enough memory, and ignoring the D bit for now, you can't just run real-mode code in protected mode because it calls interrupts that don't work in 32-bit mode and modifies segment registers expecting them to have real-mode semantics! (i.e. segment is just added to the linear address). in protected mode, you write selectors into segment registers. they work differently - they just select a segment descriptor from a descriptor table. the descriptor tables are maintained by the OS and modifying them is a privileged operation.
which brings me to the fourth point: to set up a segment descriptor with D bit set to 0, you need OS support for doing so, because you can't do it by yourself (as said, it's a privileged operation). and as i already mentioned, all 64-bit versions of windows don't support this anymore.
fin.
Quote:
It would like to ask some of our n byte intro (with n <=256b) experts to share their knowledge and tricks.
Where to start? What tools can you recommend for developing tiny intros on current systems?
And especially sharing some "standard tricks" (and some non standard tricks) would be pretty damn cool.
start readin assembler language, study schemantics if its for an oldschool platform, and use your imagination.
wow @ryg. quite the explanation. didn't do the logic with d-bits. that's what i leave to the kernel i'm working on. but basic definition is the 16 or 32 bit address register range thing. isn't that what counts?!
pluto128: 
transformers: 
in you'r face!
transformers: in you'r face!
wrong names, , wtf. anyway. - was talking about beer.
I am now just slightly less of an idiot than before. Thanks ryg for the education. So I guess running existing <1kb demos outside of dosbox or some other emulator/vm is a no-go.
QUINTIX: There is mostly no problem running them outside of an emulator up to WinXP. Some things run, some don't and some look different under dosbox compared to XP (or real DOS, as Pirx pointed out).
Oh hai! I never did palete generation tool, maybe some other dude.
Optimus: Now you have destroyed the great myth about your secret tool :D
there's different approaches. you see the one you feel is best for that particular tiny-intro you want to make. for example the transformers 32b intro was entirely made in x86 asm, because of experimentation with instructions for generating numbers. the moving voxel landscape was first made in C, also optimize crunched down alot in C, then converted to asm, and finally crunched alot again in asm.
Quote:
Are there any nice tools for palette testing / generation or whatever?
the point is, you really don't always can rely on a palette generation tool, because sometimes you can save bytes if you generate the palette inside the program loop (or program loops). and sometimes you'd have to adapt the palette with the registers wither having some form of adaptive palette.
hey guys, this is just a "wild" idea but what about creating a tool/intro-launcher that transcribes the 16bit DOS code to 32/64bit ?
(some sort of simple mode 13 "VM" -- add SB/GUS/MIDI support for bonus points!)
(some sort of simple mode 13 "VM" -- add SB/GUS/MIDI support for bonus points!)
