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 :

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....

added on the 2006-08-07 12:45:32 by Tigrou Tigrou
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 :)
added on the 2006-08-07 12:50:34 by Optimus Optimus
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.
added on the 2006-08-07 13:06:41 by nitro2k01 nitro2k01
Oh stupid me, overlapping segments, right?
added on the 2006-08-07 13:10:35 by nitro2k01 nitro2k01
How about using the stack segment?
added on the 2006-08-07 13:42:57 by Adok Adok
OT: Adok, if you're gonna use that mensa logo, at least make it look decent in 16'16 pixels.
added on the 2006-08-07 13:51:47 by nitro2k01 nitro2k01
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).
added on the 2006-08-07 14:52:06 by KK KK
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......
added on the 2006-08-07 15:41:29 by Tigrou Tigrou
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.
that means only 1 segment =>64k?
i need to store several frame which is 64k X something :s

added on the 2006-08-07 15:46:06 by Tigrou Tigrou
ok may what i wanna do is impossible...
added on the 2006-08-07 15:53:15 by Tigrou Tigrou
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?
added on the 2006-08-07 21:08:58 by Optimus Optimus
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
added on the 2006-08-07 21:46:43 by p01 p01
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...
added on the 2017-11-28 19:34:26 by gorgh gorgh
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.
added on the 2017-11-28 20:23:41 by HellMood HellMood
yes,that worked for me fine, thanks,
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 :

for storing single pixels
Code:rep stosw

for clearing the screen
apart from that there are only variables modifications, I do not use DS whatsoever.
What could be the problem?
added on the 2017-11-28 22:18:19 by gorgh gorgh
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.
added on the 2017-11-29 01:23:31 by Adok Adok
mov cx,32000


for my intro cx=0, so

mov ch,$7D

or come like that $FA(for movsb)
added on the 2017-11-29 05:45:48 by g0blinish g0blinish
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.
added on the 2017-11-29 08:44:32 by Harekiet Harekiet
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.
added on the 2017-11-29 12:42:52 by gorgh gorgh
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

Code:mov [bx],al
Code:mov [ds:bx],al

unless you adress with BP, then

Code:mov [bp(+??)],al
Code:mov [ss:bp(+??)],al

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 :

Code:push word 0x8000 pop ds push word 0xa000 pop es mov si,di L: movsb loop L

that will always copy 65536 pixels after the first loop.
added on the 2017-11-29 14:04:29 by HellMood HellMood
HellMood: thanks a lot mate!
added on the 2017-11-29 23:02:31 by gorgh gorgh