rlcarr@athena.mit.edu (Richard L. Carreiro) (03/11/88)
Greetings!
Sorry for such an elementary question, but I am getting a bit confused.
I know that graphics and sound data must go into Chip ram, but other data
(and code) can go into Fast Ram.
My question: I am working on a n-body simulation program. I want the
code to be in Fast RAM to do the number-crunching as fast as possible.
I also want to plot to the screen.
Now, if I use pre-intitialized structures (i.e. RKM), what compiler/linker
flags do I have to use to get the data right? What about if I do something
like:
struct Window *MakeWindow(x,y,...,...)
long x,y,..,...;
{
struct NewWindow Nw;
Nw.TopEdge = x;
.
.
.
return((struct Window *)OpenWindow(&Nw));
}
(pardon any mistakes in this - I am teaching myself C and trying to
learn Amiga-specifics at the same time - but I think you see the general idea.)
Then how do I have to set the flags?
I have read and reread the Lattice 4.0 manual and various Amiga books I have,
but I am still confused.
I have an Amiga 1000 with a 2Meg StarBoard2.
Any help would be greatly arrpeciated.
Please EMAIL unless you thing it would be of general interest.
(But you all already knew that :-)
Thanks,
Rich
ARPAnet: rlcarr@athena.mit.edu
UUCP: ...!mit-eddie!athena.mit.edu!rlcarr
or maybe
rlcarr%athena.mit.edu@eddie(.mit.edu)
BITNET: rlcarr%athena.mit.edu@MITVMA.mit.edu
*******************************************************************************
* Richard L. Carreiro "Havlicek stole the ball!!!!" *
* rlcarr@athena.mit.edu -- Johnny Most 4/15/65 *
*******************************************************************************cmcmanis%pepper@Sun.COM (Chuck McManis) (03/12/88)
Good news, there aren't too many things that have to be in chip ram.
As a matter of fact there are only three that you will encounter in
99% of your programming. These are (in order of appearance) :
Image Data - Anything that will appear as an Image on the screen
of the Amiga. This includes sprites, the Pointer, Gadgets with
images in them, bitmaps holding images etc.
Sound Data - Anytime you want to call the audio.device and send it
a sample to play, the sample will have to be in CHIP ram.
Trackdisk data - Anytime you call the trackdisk.device to send
data to or from the floppies that data will have to be in
CHIP ram.
Thats it, all the structures, borders, screen structs, window structs, etc
can be in fast ram. So what's the problem you ask?
Generally, preinitialized gadgets where the GadgetRender pointer is pointing
at a struct Image. Or a custom image on a proportional gadget. The easyest
way to handle these cases is to leave the preinitialized stuff in your
code, but before you use them use AllocMem() to get an equally sized
chunk in CHIP ram and copy the data into it, then use a pointer to that
copy of the data in your code.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/13/88)
In article <45205@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >Good news, there aren't too many things that have to be in chip ram. >As a matter of fact there are only three that you will encounter in >99% of your programming. These are (in order of appearance) : > > Image Data [ ... ] > Sound Data [ ... ] > Trackdisk data [ ... ] You forgot Copper lists, Chuck... (or does that account for the other 1%?) _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/15/88)
In article <5425@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > You forgot Copper lists, Chuck... (or does that account for the >other 1%?) Definitely in the other 1%. When you get to building Custom Copper lists you should know everything that depends on being in chip RAM. When asked once why I didn't think the Atari programs, that stuff the color registers in real time, were 'competition' for the Amiga I answered, "Simple, because they use up the most of the available CPU cycles to achieve those effects, whereas on the Amiga there is a chip, the Copper, that was *designed* to play those kinds of games behind the CPUs back." When I start describing what the Copper can do, these same people stop wondering why one might want a custom coprocessor to handle these things. I suspect as more people become aware of it's abilities, the more interesting displays will be appearing. May take this moment to encourage everyone who is going to DevCon to go to the Blitter/Copper talk. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.