A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in

  

  

  

Demos Amiga Demoscene Archive Forum / Coding / How to start
 Page:  1  2  »» 
Author Message
FB_mach2
Member
#1 - Posted: 16 Dec 2004 23:13
Reply Quote
Hi all,

I plan to start coding demos/games for Amiga.

I have good knowledge of assembler programming and computer architecture but I'm know in the amiga world.

So how to start coding on this system?
Cyf
Member
#2 - Posted: 16 Dec 2004 23:43 - Edited
Reply Quote
First, read the Amiga Hardware Reference Manual : http://www.amigarealm.com/computing/knowledge/hardref/ch1.htm (ch1 to 8)
and a MC68000 reference manual :
http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/index.HTML

and read all posts of this forum in Coding section...and post your questions (some great gurus are here : NoName, The Dark Coder...)

already tutored -> lesson 1, startup code (my version and Dark Coder version if you want to start directly), what is the Blitter, Copper, colors, sprites, general questions (clear screen...), Timing, Interrupt, Vertical Blank, sound...

and use a good assembler (devpac3, asm-one...)

and watch many demos ^^ (on which amiga you want to start ?)
FB_mach2
Member
#3 - Posted: 17 Dec 2004 20:40
Reply Quote
OK thank you for helping me, the links are full of useful information.

I'll start to study amiga architecture yet
FB_mach2
Member
#4 - Posted: 17 Dec 2004 20:59
Reply Quote
Another question: where can I find Amiga 1200 addendum, I mean similar information to those of amiga realm chapters 1 to 8 but related to A1200 additional features??
Cyf
Member
#5 - Posted: 17 Dec 2004 22:03
Reply Quote
for AGA features, a good doc "Programming AGA hardware" by Randy/Comax :
http://aminet.back2roots.org/pub/aminet/docs/misc/RandyAGA.lha
z5_
Member
#6 - Posted: 17 Dec 2004 22:56
Reply Quote
@FB_mach2:

Very cool that you want to code amiga demos !!! Do you have experience in coding demos on other platforms?

Also, about your question on AGA addendum, there is a nice AGA.guide included in the asm-one archive (asm-one being on of the free assembler available on Amiga) which you can download here. A bit short, but contains an overview of all custom chipset registers for AGA amigas.
FB_mach2
Member
#7 - Posted: 18 Dec 2004 18:52
Reply Quote
To be honnest I don't have a demo coding experience but I want to learn... I plan to write a game on the amiga too.

however, I understand well real time and synchro aspects which can be helpfull to write good prodcuctions
Torisoft
Member
#8 - Posted: 16 Mar 2016 10:20
Reply Quote
Hi everyone.
I am totally new to assembly on Amiga, though I loved and used the machine back in the years.
Sorry, if the question is too primary:

I include a file like "exec.i" and assemble my code, asmone gives me an error about "types.i" or "nodes.i"
Other libraries such as intuition provide the same problem.

As I have not included the nodes or types files, I can only guess that the exec.i is including them on its own account! Is this true? and what is the source of my problem?

Do I need to arrange the folders of include files in a specific way?

Using asmone1.6 on a500 hdd workbench.
z5
Admin
#9 - Posted: 16 Mar 2016 17:49 - Edited
Reply Quote
@Torisoft: maybe this can help: include jam. Not sure if it is the same problem so hopefully someone with more knowledge can help you.
Torisoft
Member
#10 - Posted: 27 Mar 2016 07:41
Reply Quote
Thank you dear Admin for the effort. I found the source of problem a few days passed.

The include files are a little tricky for rookies it seems! I used to program C++ a lot in the 90s, and my knowledge relied on that, here though it was a little different. I studied the include files and saw that some include files tend to include other files (if they are not already included, they check it first, cool).

And, I saw the "INCDIR" command and experienced a little bit! It seems when a directory is given by the INCDIR, unless we define another directory for other files by INCDIR, then AsmOne only searches the first directory we specified by the first INCDIR.

Example: let's suppose we first have a command like: INCDIR "ASM:Includes/"
From here on the assembler looks for all include files in this directory. This is for our include files and sub-directories, works fine until you want to include from another parent directory!

For other directories the assembler still searches the same path! Even if the next include commands contain paths like: INCLUDE "ASM:Examples/hw_examples.i"
In this case the assembler searches the path "ASM:INCLUDES/ASM:Examples/...". which naturally does not exist at all!

The only choice is to change the directory by another INDCIR command before using another parent directory.
I did that and everything is now honeymooney!

The solution
Torisoft
Member
#11 - Posted: 27 Mar 2016 07:56 - Edited
Reply Quote
Cheers to FB_Mach who wishes to start coding the legendary Amiga.
One coder to anoterh(!), you will love the beast though its best years are long passed.

I loved coding the c64, I still do! provides an ocean of work to do in a lifetime! and yet it may surprise you. Amiga is the bigger brother sort of thing! It has lots of bugs and tricks one can spend years to learn and master.

I used to program on PCs in the 90s and a little visual programing too, it sure was fun. But not as fun as the commodore systems. I hope you enjoy learning your way around Amiga system.

I am a newcomer to Amiga assembly as well, though I did a bit of cracking and C on the machine in early 90s. Back then resources were scarce to me. Now it seems the embargo is lifted!

Let's work together and exchange questions and ideas, if you would.

Torisoft
Member
#12 - Posted: 27 Mar 2016 07:58
Reply Quote
New Question: When making a copperlist I reach the $FF vertical position and after that I cannot change any colors!
Everything I poke into the copperlist seems to disappear! What the hell is going on? Isn't it support to turn $00 after the $ff to continue up to $12c vertical?

LaBodilsen
Member
#13 - Posted: 27 Mar 2016 14:01
Reply Quote
Hi Torisoft

correct, but you have to wait for $FFe1, as the last horisontal position, and then you can wait for eg. $0037, and change the color again.


dc.w $ffe1,$fffe
dc.w $003f,$fffe
Torisoft
Member
#14 - Posted: 28 Mar 2016 08:25
Reply Quote
That's the trick? Thanks.
I 'll give it a try and let you know.


Torisoft
Member
#15 - Posted: 28 Mar 2016 08:27
Reply Quote
New Question:

I have learned to show highres and lowres images by use of the copper.
Though I have to use IFF Convertor and change the format to "Raw Blit" before loading it into my code.
How can I read a real IFF file and get the palette, dimension, depth, and other info out of it?
Is there a source for such info? can I just load the image in memory and look for the data, or is it packed or something and needs to be unpacked or deciphered first?

Torisoft
Member
#16 - Posted: 28 Mar 2016 08:30
Reply Quote
Another Question: Important:

How does one bring up text on the screen? By libraries (I suppose DOS) and without them! I prefer the second method.

My own idea is that I have to load a font or find the address of the system font (like we get the pointer to system copper through graphics.lib) and do a bit of calculations to get the data for each character and then plot them onto the screen. For the last I will need the current X,Y positions of the window!
LaBodilsen
Member
#17 - Posted: 28 Mar 2016 13:22
Reply Quote
Iff loader
1. write a iff unpacker.. if you hex edit the iff file, the file structure is pretty easy to understand. its got some sections, FORM ILBM. CMAP, BODY

the BODY i thinks is RLE encoded.

2. Use asm-pro and Inciff: instead of incbin, you simply inciff your picture, and inciffp, to include the colormap.

LaBodilsen
Member
#18 - Posted: 28 Mar 2016 13:29
Reply Quote
Text
oldschool way:
Create a picture in deluxe paint where all the chars is listet in a matrix. make note of the position of all chars, and write it in a table.

it's easier with fixed width fonts, where eg. all the chars is 16 pixel wide.

then inciff/incbin the file in your code, and blitter copy from the position you have in the table, to your screenbuffer.

LaBodilsen
Member
#19 - Posted: 28 Mar 2016 13:32
Reply Quote
Torisoft
Member
#20 - Posted: 30 Mar 2016 06:56
Reply Quote
LaBodilsen:
correct, but you have to wait for $FFe1, as the last horisontal position, and then you can wait for eg. $0037, and change the color again.


Yes, it worked and thanks. I got a small piece of color line at the end of the same Y position, but the next lines appeared ok. Any idea about that piece and how to remove? I used even "ffE2" and the whole frame went crazy, so I cannot make it wait longer!
Torisoft
Member
#21 - Posted: 30 Mar 2016 07:00
Reply Quote
Thanks, yeah I have seen Photon do it for his scroler (the dpaint idea). What about font files? Can they be used or what?

Also, is it easy for a rookie to make an IFF unpacker? or should one just search and find the algorithm from somewhere?

The infiff was a good thing to point to. Thanks again.
LaBodilsen
Member
#22 - Posted: 30 Mar 2016 08:15
Reply Quote
Iff unpacker:
it might not be easy, and if you are going for A500/OCS-ECS releases, i would not choose that road anyway.

Reason: if you load an IFF, and have to decode it to somewhere else in memory, then the picture will take up the memory og both the iff picture, and your own decoded image. if you instead use an iff converter -> RAW, or use IncIff. then your picture will only take the amount of memory needed. ofcourse for a slideshow, i might be nice to have the pictures stored in some compact form in memory.

on the other hand if you don't mind the extra memory taken for the iff picture, then it should be pretty straight forward to write a iff decoder.

eg. load the file with incbin. search the memory for the section you need (CMAP, BODY etc.) and then decode/copy the data from that section to your new screenbuffer (or other memory section).

truth be told, i've never written one myself, and never really had much use for it. In the old days i always used an iff converter. and now i simply use Inciff and Inciffp in Asm-pro, which works great for even brush'es saved from Deluxe Paint, so you can cut the brush you need in Deluxe Paint. save it as a brush, and inciff it in Asm-pro.
LaBodilsen
Member
#23 - Posted: 30 Mar 2016 08:52
Reply Quote
Found this great text file, that explains in good detail how iff pictures are saved.

http://www.textfiles.com/programming/AMIGA/iff.txt

so to eg. search for the BODY chunk, you would simply compare with a longword of $424F4459 (=BODY). when found, the next longword would then contain the length of that section.

LaBodilsen
Member
#24 - Posted: 30 Mar 2016 08:53
Reply Quote
Fonts:
i don't know much about system font's, but i guess it would be possible to load the font files directly, or use them from system libraries. it's not something i've ever done myself.

if you look at blueberry's startup, there is an option to include the default Topaz font, and use that from a pointer given.
z5
Admin
#25 - Posted: 30 Mar 2016 12:25 - Edited
Reply Quote
From the little experience i have (i'm no expert at all and only managed to release two intros) and especially from doing things the wrong way (waisting lots of time), i feel it's important to get a good demosystem and workflow before starting to code. That includes setting up music (P61), importing graphics (brushes, colors, pictures,...) and fonts, a solid starup code system and a system that calls the different "main" routines synched to a timer or to the music (which iirc is possible with the pattern numbering in modules).

I missed an easy way to import graphics/colors into my code back then and spent ages converting graphics with an iff to raw converter, again and again. However, i did the graphics myself and had the annoying habit of constantly changing and importing them. Yikes... it was horrible. I assume it's easier when you have a graphician who knows what he's doing.

But yes, before you start, good system startup code, an easy way of importing graphics, a music player routine and a good workflow will probably prove useful in the long run. And routines for color manipulation (fades and stuff).
Angry Retired Bastard
Member
#26 - Posted: 30 Mar 2016 13:59
Reply Quote
I'd like to point out that while what z5 says makes a lot of sense it's very Very VERY important to be careful and NOT FALL INTO THE TRAP OF BUILDING FRAMEWORKS FOREVER! Far too many people have done that, with the result that they never get anything released.

As for the import "pipeline", I've been using manual conversion (iff2raw, png2chunky, etcetc..) for all the releases I've ever done so it's definitely possible. :) (However, I won't claim that it's necessarily very clever..)

As always the key rule is: Be pragmatic and focus on your end goal. Don't be afraid of doing stuff "the wrong way" as long as you still have fun. :)
corial
Member
#27 - Posted: 30 Mar 2016 17:17
Reply Quote
Yeah, I also convert my stuff manually. I use PicCon to convert the graphics into chunky (I only do aga c2p stuff) and PicCon is also very friendly in terms of outputting the palette.
Torisoft
Member
#28 - Posted: 3 Apr 2016 06:39 - Edited
Reply Quote
Thanks everybody for the comments and links.

Truth is I have designed a grand plan for my assembly experience. I have made the main bulk of an IFF Viewer program, one that searches the current directory, finds any iffs, and shows them one by one until there is none left.

Well, I am a newbie and this would be large project. But the reason I devised this plan was due to the fact that it contained a lot of cool stuff to learn and to do. I have written the main body and will have to work on the different modules (a top-bottom approach if I may). One part concerns dos work, the other coding (e.g. the unpacking and stuff you all pointed), another graphics, another intuition (maybe). And, there is no rush!

Right now I am reading a lot of manuals and writing small routines to test the functions and libraries and registers. The development so far has been amazing, and I am getting the hang of those libs and functions. Any help on this path will be appreciated a lot.

Also, having read your comments, I am ditching the IFF unpacking or converting for now. Will do with raw forms (iff converters) until I can find/code a decent unpacking module.

Best for all


noname
Member
#29 - Posted: 3 Apr 2016 10:29
Reply Quote
Might be worth checking ifflib and newiff: Fish Disk 674
Torisoft
Member
#30 - Posted: 5 Apr 2016 07:44
Reply Quote
Thanks a lot, cool stuff.
 Page:  1  2  »» 

  Please register a new account or log in to comment

  

  

  

 

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