256b need help
category: general [glöplog]
i'm writing my 256b demo but have some problems:
I want to store some frame in memory and render it for later use but dont know how to do it. one frame is 320*200=64000 bytes, and since there no memory allocation or something like this :/
i have see some prod which store a second image in 09000h or 08000h instead of 0a000 for double buffering... is there any other place to write ?
what i wanna do :
init
pal etc.
[precalc some frames into video memory or in other place]
[render the precalc stuff]
if someone can help me or give me some code....
I want to store some frame in memory and render it for later use but dont know how to do it. one frame is 320*200=64000 bytes, and since there no memory allocation or something like this :/
i have see some prod which store a second image in 09000h or 08000h instead of 0a000 for double buffering... is there any other place to write ?
what i wanna do :
init
pal etc.
[precalc some frames into video memory or in other place]
[render the precalc stuff]
if someone can help me or give me some code....
I always write in the 64k segments just before 0a000h, like 09000h and 08000h as you say. But I don't know how safe or good idea that is. Here, I'd also like to hear someone else opinion :)
This is just a total guess, but: Since the code is only 256b small, shouldn't there be 64k-256b of space in the segment that code lies in, right after the code?
Another option might be downloading the source of a 256b demo and look how other people do it.
Another option might be downloading the source of a 256b demo and look how other people do it.
Oh stupid me, overlapping segments, right?
How about using the stack segment?
OT: Adok, if you're gonna use that mensa logo, at least make it look decent in 16'16 pixels.
You can try using text mode segment (0B000h), as in 13h mode its unused. I'm not sure how efficient it would be (it's probably mapped to video memory, but I'm not an expert), but at least it should be quite safe (except for leaving garbage on the console after exiting).
Quote:
I always write in the 64k segments just before 0a000h, like 09000h and 08000h
can i also write into 07000h 06000h and so on ?
i didnt find any document on the net about memory mapping......
8000h is free for use, it's the base segment address for CGA/EGA (can't really remember). Just use it.
but at least it should be quite safe (except for leaving garbage on the console after exiting). Exiting with a mode change back to text mode (03h) avoid that garbage problem.
but at least it should be quite safe (except for leaving garbage on the console after exiting). Exiting with a mode change back to text mode (03h) avoid that garbage problem.
that means only 1 segment =>64k?
i need to store several frame which is 64k X something :s
i need to store several frame which is 64k X something :s
ok may what i wanna do is impossible...
Nothing is impossible :)
Ok, how many segments you need? With 640kb at max, it's 10 segments and much less since a portion of memory is occupied by DOS. Maybe you'd need to access that memory over the 1MB but wouldn't that need to move in protected mode instead of real mode? I never needed to do anything like that in a tiny intro, since 640kb were enough for me. Would that one be not advantage for size?
Ok, how many segments you need? With 640kb at max, it's 10 segments and much less since a portion of memory is occupied by DOS. Maybe you'd need to access that memory over the 1MB but wouldn't that need to move in protected mode instead of real mode? I never needed to do anything like that in a tiny intro, since 640kb were enough for me. Would that one be not advantage for size?
640kb should be enough for everyone
Anyway, couldn't you downscale the frame by 2 so you could fit 4 frames in one segment and just use a base offset that you increment by 16384 so it's magically clipped
Anyway, couldn't you downscale the frame by 2 so you could fit 4 frames in one segment and just use a base offset that you increment by 16384 so it's magically clipped
bump!
Is it possible for 13h mode to copy stored image data from 0x9000 to 0xa000 by using
?
I've heard some graphics modes have problems with this...
Is it possible for 13h mode to copy stored image data from 0x9000 to 0xa000 by using
Code:
rep movsw?
I've heard some graphics modes have problems with this...
Of course. You can opt for faster copying with movsd even ;)
I would suggest using 0x8000 as offscreen though, there is something
right below 0xA000 which makes freedos crash on exit if you overwrite it.
Same is true if you use the "les bx,[bx]" trick to get a pointer to the screen,
which ends up overwriting said data (0x9FFF or similiar) or use advanced
tricks to squeeze out some bytes.
I don't know about general other problems though.
I would suggest using 0x8000 as offscreen though, there is something
right below 0xA000 which makes freedos crash on exit if you overwrite it.
Same is true if you use the "les bx,[bx]" trick to get a pointer to the screen,
which ends up overwriting said data (0x9FFF or similiar) or use advanced
tricks to squeeze out some bytes.
I don't know about general other problems though.
yes,that worked for me fine, thanks,
I've got another question:
I copy the block of ram in this manner:
But this gives me garbage on screen, only when I add at the beginning and end:
It works as it should be working. I don't know why it's causing the problem, the only memory instruction I use is :
for storing single pixels
and
for clearing the screen
apart from that there are only variables modifications, I do not use DS whatsoever.
What could be the problem?
I've got another question:
I copy the block of ram in this manner:
Code:
push word 0x8000
pop word ds
xor si,si
push word 0xa000
pop word es
xor di,di
mov cx,32000
rep movsw
But this gives me garbage on screen, only when I add at the beginning and end:
Code:
push ds
...
pop ds
It works as it should be working. I don't know why it's causing the problem, the only memory instruction I use is :
Code:
stosbfor storing single pixels
and
Code:
rep stoswfor clearing the screen
apart from that there are only variables modifications, I do not use DS whatsoever.
What could be the problem?
You write: "apart from that there are only variables modifications, I do not use DS whatsoever", probably what you wanted to write is that you only use registers? Variables (as defined e.g. by DB or DW) are locations in memory so the value of DS is relevant for them.
mov cx,32000
32000=$7D00
for my intro cx=0, so
mov ch,$7D
or come like that $FA(for movsb)
32000=$7D00
for my intro cx=0, so
mov ch,$7D
or come like that $FA(for movsb)
stosb would always write to the ES segment so you'd have to make sure that points to your temporary segment when doing your pixel manipulations.
Herekiet: thanks
Adok: I'm using fpu and store some data in memory locations placed after the code. In the code I use only ax and di registers. Anyway, thanks for your comments.
Adok: I'm using fpu and store some data in memory locations placed after the code. In the code I use only ax and di registers. Anyway, thanks for your comments.
I think Adok is on the right track actually.
When you store or load from "locations after the code",
you do this implicitly via DS
unless you adress with BP, then
To overcome your problem, you can :
Address with BP, or override DS (f.e. fs: movsw)
or like you did, save and restore DS for the copying process.
by the way, there are several tricks to optimize the size of the copying process.
for example, if you dont touch CX, you can do :
that will always copy 65536 pixels after the first loop.
When you store or load from "locations after the code",
you do this implicitly via DS
Code:
equals mov [bx],al Code:
mov [ds:bx],alunless you adress with BP, then
Code:
equals mov [bp(+??)],alCode:
mov [ss:bp(+??)],alTo overcome your problem, you can :
Address with BP, or override DS (f.e. fs: movsw)
or like you did, save and restore DS for the copying process.
by the way, there are several tricks to optimize the size of the copying process.
for example, if you dont touch CX, you can do :
Code:
push word 0x8000
pop ds
push word 0xa000
pop es
mov si,di
L:
movsb
loop Lthat will always copy 65536 pixels after the first loop.
HellMood: thanks a lot mate!
I was curious about this as someone told me to avoid using 09000h as some TSR might run there, or something else.
Currently working on some 286 demo in C/asm in OpenWatcom. At some point I might have hit something as I tried to malloc more stuff, that I am sure fit in under 640k, but crashed. Then I ended up doing things like this for each part.
uint8 far *background = (uint8 far*)MK_FP(0x8000, 0);
int16 far *spheremap = (int16 far*)MK_FP(0x7000, 0);
So, instead of mallocing and releasing, if I need certain 64k or less area for my effect, but want them to be in unique segments for my assembly code, I'll just do that and pass the pointer. And I go from 0x8000 below, not touching 0x9000.
I also need to find how to ask for memory, I don't know how low I can go, but could test. In other parts of the C code, I might have static tables and other stuff, it can quickly add up.
Currently working on some 286 demo in C/asm in OpenWatcom. At some point I might have hit something as I tried to malloc more stuff, that I am sure fit in under 640k, but crashed. Then I ended up doing things like this for each part.
uint8 far *background = (uint8 far*)MK_FP(0x8000, 0);
int16 far *spheremap = (int16 far*)MK_FP(0x7000, 0);
So, instead of mallocing and releasing, if I need certain 64k or less area for my effect, but want them to be in unique segments for my assembly code, I'll just do that and pass the pointer. And I go from 0x8000 below, not touching 0x9000.
I also need to find how to ask for memory, I don't know how low I can go, but could test. In other parts of the C code, I might have static tables and other stuff, it can quickly add up.
386 32bit addressing is definitelly much better :)
Optimus, If you are using C, you must use "farmalloc":
Memory to you should allocate DOS. Taking and using some static addresses for your needs is not right. If this still somehow works in Dosbox, then on a real DOS it will lead to a freeze in 99% of cases.
PS: The way that sizecoders usually take with 256 bytes intros doesn't work here.
Code:
char far *buffer;
buffer=(char far *)farmalloc(64000L);Memory to you should allocate DOS. Taking and using some static addresses for your needs is not right. If this still somehow works in Dosbox, then on a real DOS it will lead to a freeze in 99% of cases.
PS: The way that sizecoders usually take with 256 bytes intros doesn't work here.
