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.
I'm basically stuck with win7 here and need a proper toolchain.
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
Quote:
; is mov al, 0x13 a better idea here?
Is it safe to assume ah to be 0 here?
Most simple "toolchain" using NASM.
Code:
nasm main.asm -fbin -o main.com
ndisasm -o100h main.com
dir main.com
From cositos...
How does that lXs trick exactly work?
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?
ndisasm? why?
The answer can be found here...
http://canonical.org/~kragen/demo/fr-016.html
http://canonical.org/~kragen/demo/klappquadrat.html
http://canonical.org/~kragen/demo/fr-016.html
http://canonical.org/~kragen/demo/klappquadrat.html
ndisasm just to have a look at the bytes generated.
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.
s/09ff0h/09f7fh but you get the idea: les bp,[bx] is small and gives something close enough to 0a000h
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?
dec al
jnz short _mainloop
int 20h
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
verical retrace check:
mov dx, 3dah
@wait1:
in al, dx
test al, 8
jz @wait1
@wait2:
in al, dx
test al, 8
jnz @wait2
Is performance a major problem or can I just go for brutal 256 step raymarching without the people crying? :)
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).
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 :)
I guess I always could run it in something faster, like qemu or virtualbox.
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.
Explanation for
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.
Code:
: 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).les bp, [bx]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.
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. ;)
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. ;)
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 :)
