pouët.net

Go to bottom

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

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
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......
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
bump!
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 :
Code:stosb

for storing single pixels
and
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

32000=$7D00

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
equals
Code:mov [ds:bx],al


unless you adress with BP, then

Code:mov [bp(+??)],al
equals
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
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.
added on the 2023-06-25 13:25:37 by Optimus Optimus
386 32bit addressing is definitelly much better :)
added on the 2023-06-25 13:26:04 by Optimus Optimus
Optimus, If you are using C, you must use "farmalloc":

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.
added on the 2023-06-25 20:40:52 by bitl bitl

login

Go to top