A.D.A. Amiga Demoscene Archive

        Welcome guest!

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / coding tutorial: how to structure a asm project.

 

Author Message
z5_
Member
#1 - Posted: 19 Nov 2004 15:35 - Edited by Admin
Reply Quote
everything about structuring a asm project shoudl go in here :)
z5_
Member
#2 - Posted: 19 Nov 2004 15:40
Reply Quote
noname wrote:

ok then.

you should consider having a basic structure consisting of two assigns when wanting to code assembly.

1.) includes:
2.) sources:

they could be anywhere but lets presume they are on your coding-partition (it's a good idea to have one) at root-level and that your coding partition is called "asm:". then you will have two assign statements in your s:user-startup reading:

assign "includes:" "asm:includes"
assign "sources:" "asm:sources"

copy all commodore and custom include-files to the includes directory and have all your sources in your sources directory (obviously use subsdirs there for different projects). get the includes from any devcd or probably the cloanto one. there should be cd's by a german company called "schatztruhe" as well.

then tell your assembler where the includes are.
asmone liked this somewhere in the source:
"incdir includes:"

i was also common practice to have assigns for bigger projects. so i had additional assigns for my demosystem and for every demo/intro.

hope this makes sense. i don't say it has to be like this, but i could recommend it from personal experience. never do something like "incbin dh1:coolpic.cnk" though or you deserve to be shot.
z5_
Member
#3 - Posted: 19 Nov 2004 15:46
Reply Quote
@noname:
Ok. Understood :) But how do you put structure in your data files that go with the asm project. I create a directory per project in my sources dir. Where do i put data files (.raw, .pal, modules,...) and how do i include them. And how do i avoid that the user wanting to run the executable has to make assigns?
noname
Member
#4 - Posted: 19 Nov 2004 16:39
Reply Quote
it's up to you, really.

i ended up with something like this (presuming we already have an assign called "sources:" pointing to the root of our source-directory)

save your sources for the demo in sources:mydemo
make a second assign esp. for this demo. lets call it "mydemo:"

then have some dirs
mydemo:data (cnk, raw, pal, mod, p61, tp3, dat, you name it)
mydemo:exe (my final executeable would go here)
mydemo:fx (pre-assembled demo-parts in this dir)
mydemo:temp (ever growing mess-dir. you'll need it!)

note1: don't think to long about the fx and exe folders here. you won't need them for the first steps with single-load demos.

note2: also consider having your original files (iff, mod, etc) somewhere in that structure. probably the data dir would be enough, but a seperate mydemo:gfx could also be feasible, depending on the project.



--- single file demos and tests ---
just e.g. "incbin mydemo:data/p61.cooltune"
the assign is then not needed for the final version as as long as you won't load off the disk.

--- multi-load ---
in that case you might want to use "PROGDIR:" which is generated for you (you being the executeable that is) at runtime. this is really easy and advanced at the same time. unfortunately the PROGDIR path is not available when you run your stuff from within asm-one. so my final solution was that i had an assign for the demo during development (e.g. ms99: for mnemonics) and then loaded the music with from ms99:music.tp3. (please note that loading at run time is not the same as incbin or include. this is a very important difference. if it doesn't make any sense, read it again or stop now!).

--- final touches ---
i then had a parser that ate away the "ms99:" bit of every string i fed in. i then had two possibilites:
1.) prefix every string with PROGDIR: and load from there
2.) load from some kind of archive

the first option would led into the demo requiring a dedicated dir with lots of data files. i decided that the second option would be cooler so i wrote some kind of tar-ball archiver that my demo-system could handle. in the final step i appended that archive to the executeable (on a binary level) and loaded the data at runtime from the executeable. by doing so i could store arbitrarily big amounts of data in my exe without increasing the memory requirements for the code at all and without having the need for any assigns.

--- short summary ---
your user won't need assigns as long as you just have a single-file with all data already assembled into the exe (single-load, e.g. intros).

if you want to have multiload, use "PROGDIR:"
if you want to have singlefile multiload, go the long way (or use my demosystem)
z5_
Member
#5 - Posted: 19 Nov 2004 22:23
Reply Quote
I have a hard time finding the necessary include files. Can i get them somewhere online?
Overflow
Member
#6 - Posted: 19 Nov 2004 22:33
Reply Quote
I belive I found my Includes at www.playagain.net

Then press "tosec sets". Then Single roms. Then "Commodore Amiga - Applications". And then "D" ...and then I chose "Devpac v3.02 (1992)(Hisoft)(Disk 2 of 2)[Includes 2.0]".

Im 99% sure thats were I downloaded em...My memory and Harddrive is a equal mess...soo...
z5_
Member
#7 - Posted: 19 Nov 2004 22:51
Reply Quote
@Overflow:
But are these includes still up to date? Doesn't one have to have the latest includes for the latest kickstart/workbench/chipset whatever?
Overflow
Member
#8 - Posted: 19 Nov 2004 23:29
Reply Quote
Prolly not the most up to date, but I had to use something. I couldnt find anything else and each time I asked on a board I usually just got "its easy to find em...google for em"....very helpful right? :P

Anyhow...Ive tested those on my Amiga1200 030 with fast mem and WinUAE, and as long as my current sources works Im happy...

I guess Ill try to find newer ones at one point...but ...Considering we are still struggling with the basics, U really think having older includes will make much of a difference from a learning standpoint? Ofcorz, when we are going up against TBL and Loaderror at The Gathering 2020 we might wanna have the newest systemfiles ;)
z5_
Member
#9 - Posted: 19 Nov 2004 23:34 - Edited by Admin
Reply Quote
@Overflow:
To be on the safe side, make that 2040 :) (at least for me).

I just want to build a modern environment so that i don't have to worry anymore about that later (learning asm should give me enough headaches). So it would be neat to have such a system from the beginning, and accessible for everyone...

btw. aren't the includes on the Amigaforever cd you bought?
amigarealm has some interesting stuff in their resources dir. (including includes...)
dalton
Member
#10 - Posted: 20 Nov 2004 20:37
Reply Quote
I think the asm-one archive contains includefiles
z5_
Member
#11 - Posted: 21 Nov 2004 09:34
Reply Quote
@dalton:
haven't found them in asm-one archives...

Anyone who want to put together a little package with the latest includes and put it online?
z5_
Member
#12 - Posted: 28 Nov 2004 13:14
Reply Quote
as noname pointed out, the latest includes can be downloaded from NDK3.9.

I still got one question. Am i allowed to do this:
move.w $0000,dmacon0

or should everything be written relative to the base address like this
move.w $0000,dmacon0(a0), with the base address in a0

what about the copperlists? I mean, should i write them as offsets from the base or just write color, color+$02,...
Cyf
Member
#13 - Posted: 28 Nov 2004 14:31
Reply Quote
in copperlist, NO base address
everywhere, relative to the base address, else $96 is not the dmacon address. $dff000 is the base for all chip registers
z5_
Member
#14 - Posted: 28 Nov 2004 22:55
Reply Quote
@cyf:

so whenever i'm using a name, i should do this before:

lea custom,a1 (get the base for all chip registers)
move.w $xxxx,dmacon(a1)

Is that correct? And what include do i need to get the custom thingie working (my compiler doesn't understand 'custom', but the only include i have so far is hardware/custom.i)

Also, i don't understand why the addresses in the copper don't need to be relative to the base address (for example, isn't the color0 located at $dff180?).
Cyf
Member
#15 - Posted: 29 Nov 2004 11:02 - Edited
Reply Quote
custom base address = $DFF000.
you need a custom.i for dmacon, color00...

Also, i don't understand why the addresses in the copper don't need to be relative to the base address

because the Copper can't read other addresses ! only custom chip registers at $DFFxxx
z5_
Member
#16 - Posted: 5 Dec 2004 20:01 - Edited by Admin
Reply Quote
Suppose that my project and all files are stored on "work:asm/sources/intro". Sometimes, include files contain other include files: for example, the player routine p61 has an asm file called 610.4.asm but in this file, you can find:
incdir include/
include Player61.i

So i have added in my dir a directory called includes ("work:asm/sources/intro/includes") and placed the Player61.i file in there.

I'm including the 610.4.asm in my source but i get a file error on the Player61.i.

How do i work with includes within includes??
dalton
Member
#17 - Posted: 5 Dec 2004 21:02
Reply Quote
I usually type the entire path...

like this: include work:wathever/player61.i

that particular file however I moved to include: since it is used in almost every project =)
dalton
Member
#18 - Posted: 5 Dec 2004 21:03
Reply Quote
I generally change the incdir from include: to the project-dir after loading the necessary system includes...
noname
Member
#19 - Posted: 5 Dec 2004 22:47
Reply Quote
@z5: several ways to solve your problem:

1.) the unmodified 610.4.asm works from the current directory. in asmone you can change the current directory with the "v" command (e.g. "v myfirstdemo:"). the unmodified 610.4 then expects that there is a subdir at this place which goes by the name of "include" ("incdir include/" would then refer to "myfirstdemo:include/"). test that you can assemble the replayer alone by opening 610.4.asm and changing the "example" define from 0 to 1. assemble and start. you should be hearing a module then. if you can't get it work, find out why before goig back to the original question.
sidenote:you will also find the answer to your level 3 interrupt related question from another thread in the lines just above "example = 0".

2.) i for myself modified by includable version of 610.4.asm in the way that i commented out the lines "incdir" + "include" and then included the include file on my own in my programs.

3.) you can also incbin the player itself and just use the offsets from the include file to jump to the appropriate functions. also a nice solution but save this one for later.
TheDarkCoder
Member
#20 - Posted: 6 Dec 2004 09:47
Reply Quote
@z5:

So i have added in my dir a directory called includes ("work:asm/sources/intro/includes") and placed the Player61.i file in there.

I'm including the 610.4.asm in my source but i get a file error on the Player61.i.


please, take a look also to 610.6!!! ;-)
z5_
Member
#21 - Posted: 15 Dec 2004 22:39
Reply Quote
I tried ti include more commodore includes like this:

incdir "includes:"

include "includes:dos/dosextens.i"
include "includes:dos/dos_lib.i"
include "includes:exec/exec_lib.i"
include "includes:graphics/gfxbase.i"

include "includes:hardware/custom.i"
include "includes:hardware/dmabits.i"
include "includes:hardware/intbits.i"
include "includes:hardware/dmabits.i"
include "includes:hardware/blit.i"

And Asm-One gives me the following error:

Illegal Operator
In file "INCLUDES:HARDWARE/CUSTOM.I (line: 12) >> FUNCDEF Supervisor
21 Include "includes:exec/exec_lib.i"

Any idea what this is all about? Also, do i need those 2 dos includes? And what includes do i need for the _LVOOpenlibrary,...?
Cyf
Member
#22 - Posted: 15 Dec 2004 23:57 - Edited
Reply Quote
openlibrary is in exec_lib.i
if you write incdir "includes:", no need to add "includes:..." in include path

use "exec/exec.i" for FUNCDEF macro
Cyf
Member
#23 - Posted: 16 Dec 2004 15:54
Reply Quote
the doslibrary is used for I/O access under dos (read,write,seek,creat dir...)
z5_
Member
#24 - Posted: 16 Dec 2004 18:29
Reply Quote
I f*¨^cking just can't get this includes to compile :( I have now added exec.i but now i'm getting EXACTLY the same error in dosextens.i :( Is there an order to be respected regarding the includes (first exec.i, then something else...)?

Also, i have exec.i on top of my program and i have exec.i which gets included with the P61 replayer?

And what is an include jam? Asm-one gives me this error first time i assemble my source (it doesn't give this error anymore after first assemble)

grrr...all that for setting up some bloody includes...
StingRay
Member
#25 - Posted: 7 Dec 2005 14:02
Reply Quote
He, that's the reason why I almost never use system includes :) Too much hassle. :) You can do everything demorelated without 'em anyway. :)

z5: the "include jam" error is one of a lot of bugs of Asm-One. :)
put an "INCDIR" at the top of your source, should fix the annoying include jam, at least it did for me.
dalton
Member
#26 - Posted: 7 Dec 2005 19:02
Reply Quote
if you get an include jam, just assemble again. I get it all the time.
StingRay
Member
#27 - Posted: 9 Dec 2005 13:57
Reply Quote
the empty incdir statement should fix it. so you won't have to assemble twice as that's pretty annoying, specially with large sources.
rload
Member
#28 - Posted: 9 Dec 2005 14:25
Reply Quote
never do something like "incbin dh1:coolpic.cnk" though or you deserve to be shot.

word!!

 

  Please log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0