pouët.net

Tiny Intro Toolbox Thread

category: code [glöplog]
tiny in intros at least...
Does Olly work with that 16 bit com stuff under win7?
I'm basically stuck with win7 here and need a proper toolchain.
added on the 2012-05-15 17:39:08 by las las
Quote:
Does Olly work with that 16 bit com stuff under win7?


not w/DOS app.

Quote:
I'm basically stuck with win7 here and need a proper toolchain.

w7 doesn't support fullscreen? use Dosbox, it's easy.
Some simple mode 13h code.
Code: org 100h section .text _start: mov ax, 0x13 ; is mov al, 0x13 a better idea here? int 0x10 push word 0xa000 pop es _mainloop: stosb ; write something to the screen... xor ax, ax ; maybe this can be removed later - given ah could be zeroed by accident somewhere else ; ESC check in al, 0x60 dec ax jnz short _mainloop mov al, 0x3 ; ah is 0 already due to mainloop exit condition int 0x10 ret
added on the 2012-05-16 12:11:33 by las las
Quote:

; is mov al, 0x13 a better idea here?

Is it safe to assume ah to be 0 here?
added on the 2012-05-16 12:12:41 by las las
Most simple "toolchain" using NASM.
Code: nasm main.asm -fbin -o main.com ndisasm -o100h main.com dir main.com
added on the 2012-05-16 12:14:43 by las las
From cositos...
Code: mov al,13h ;MCGA mode (320x200x256). int 10h ;Video interrupt request. les bp,[bx] ;Sweet little trick that loads 0a000h ;(the beginning of the VGA video memory) ;into es (instead of, say, "push word ;0a000h" and then "pop es").

How does that lXs trick exactly work?
added on the 2012-05-16 12:31:07 by las las
ndisasm? why?
added on the 2012-05-16 12:54:51 by Gargaj Gargaj
ndisasm just to have a look at the bytes generated.
added on the 2012-05-16 13:07:23 by las las
las: The les bp,[bx] trick does not loads 0a000h into ES but 09ff0h which is the address of the VGA video memory, offset by 16px to the left.
added on the 2012-05-16 13:29:22 by p01 p01
s/09ff0h/09f7fh but you get the idea: les bp,[bx] is small and gives something close enough to 0a000h
added on the 2012-05-16 13:33:52 by p01 p01
in al, 0x60
dec al
jnz short _mainloop

int 20h

mov al, 0x3 ; ah is 0 already due to mainloop exit condition
int 0x10


or ret instead?
probably simple code must contain vertical retrace check.
IIRC, dec ax is one byte smaller than dec al. Also, ret is smaller than int 20h and works just fine for .com files.

verical retrace check:
mov dx, 3dah

@wait1:
in al, dx
test al, 8
jz @wait1

@wait2:
in al, dx
test al, 8
jnz @wait2
added on the 2012-05-16 14:48:03 by Preacher Preacher
Is performance a major problem or can I just go for brutal 256 step raymarching without the people crying? :)
added on the 2012-05-16 20:19:22 by las las
I don't think anybody cares about performance as long as it's tiny. Puls in dosbox dynamic at 100% gives me less than 1fps (probably would run a bit faster if I had Windows XP 32-bit or native DOS, rather than in emulation).
added on the 2012-05-16 23:22:21 by FreeFull FreeFull
las: try to make it run nice on your machine so chances are good that it will run nice on other ones too. if you can take a nap while a single ray marches something is wrong :D
Quote:
Puls in dosbox dynamic at 100% gives me less than 1fps

same with Digimind 'Ufo transmission' a matter is in the .conf file
las: go for it :)
added on the 2012-05-17 11:56:27 by Preacher Preacher
I guess I always could run it in something faster, like qemu or virtualbox.
added on the 2012-05-17 14:30:48 by FreeFull FreeFull
I wrote a tiny test framework... The thing I have in mind runs even there with 0.2 fps only. It's more or less a shader converted to fpu code.
added on the 2012-05-17 17:21:31 by las las
Explanation for
Code:les bp, [bx]
: At start of execution of a .COM file, bx is 0, and DS=CS=segment the COM file lives in. The contents of the COM file get loaded to offset 0x100 in that segment. Before that is the PSP (program segment prefix), layout information here. The PSP starts with 0xCD 0x20 (int 20h, which exits the program), so that's what gets loaded into BP. The next word is the number of the last free conventional memory segment, typically 0x9fff (but can be something different if parts of the upper memory range are either not installed or allocated).

The les bp, [bx] thing ignores that possibility and just assumes we actually get 0x9fff. That's just segment 0xa000 minus 16 bytes. :)

fr-0.1 didn't use that trick because it actually does a divide to get x and y coordinates. To fix the 16-pixel shift up would need a sub with 16 (3 extra bytes); that makes it cheaper to just "push 0a000h / pop es". It's also more compatible.
added on the 2012-05-17 18:03:02 by ryg ryg
As for http://canonical.org/~kragen/demo/fr-016.html:

FS under DOS is 0 by default. The first 0x400 (1k) bytes of memory are the interrupt vector table (IVT). After that is the BIOS data area (is that the proper name? Don't remember). At 0x46c (typically accessed as 040h:06ch in a DOS program) is the BIOS tick counter (incremented with every timer interrupt tick, 18.2 times a second by default). So there. ;)
added on the 2012-05-17 18:07:43 by ryg ryg
Quote:
Is performance a major problem or can I just go for brutal 256 step raymarching without the people crying? :)


good luck, considering that average cheapo videocard does fp calculations about 100x-10000x faster than even a high-end $1400 cpu :)
added on the 2012-05-18 04:19:10 by Digimind Digimind

login