CLICK HERE

What's the largest amount of RAM any Amiga OS consumes right now ? While browsing the AMIGA_HowToCode7.pdf I noticed the section on dynamic RAM allocation.

Obviously, on Jaguar, without any OS, everything is always placed at fixed address (you got 2 MB and that's it). Hell, I spent 2 weeks recently merely refactoring the system and now almost everything uses a fixed constant for each pointer.

To rewrite the whole game and engine using the OS allocation, that would take easily 6-8 weeks across all engine and game components. Obviously, that's out of the question for the first game on Vampire.

Is there any OS that takes more than, say, 16 MB RAM ? I'll gladly sacrifice first X MB of RAM for that.

Not sure I understand your question reason?

Lets say on V4 of the 512 MB you might have 506 MB free.
Lets say your game is 100 MB
The will load is "somewhere" and correct all relocation for you.
You have nothing to worry about.

Unfortunately, there's ~100,000 lines of code that relies strictly on absolute addresses - there's only few things like FrameBuffers and couple arrays that are handled in a relocatable way.

Everything else has a fixed address, e.g. $13F800, right in the source code, via .EQU constants - because every single Jaguar out there has only 2 MB of RAM and all audio and video registers are at identical addresses (unlike Amiga).

So, I reckon, most of OS shouldn't really take up more than 16 MB, right ? So, I'll sacrifice first 16 MB (just to be safe) and place executable starting at 16 MB.
Should the OS complain and try to crash, I can certainly write one block allocation upon startup and ask for a single block of, say, 512-16 = 492 MB RAM - and this way the game will have all RAM it needs.

Vladimir Repcak wrote:

So, I reckon, most of OS shouldn't really take up more than 16 MB, right ? So, I'll sacrifice first 16 MB (just to be safe) and place executable starting at 16 MB.

Well ...
This sounds pretty dirty.

I understand that you fixed GFX register addresses.
But I fail to understand why the program itself needs be put on fixed address.

Can you not just use labels?

BSR 3dmath
BSR clip
BSR render

like this?

But the variables that touch HW (Blitter, ObjectProcessor) are mostly done like this:

VAR1 .equ $1F3800
VAR2 .equ $1F3840
VAR3 .equ $1F3880
VAR4 .equ $1F3900
VAR5 .equ $1F3A00

Given the issues in the Jaguar's assembler and linker - especially the broken alignment (not always - just sometimes - which is just enough to drive one crazy), this was the fastest way to debug and ensure your code will actually work every single time you add a line of code somewhere else.

Variables that don't interact with HW can be placed via dc.w, dc.l as their alignment doesn't matter.

Your code can start as early as $400. That's where the .ORG directive starts.

Every single Jaguar has 2 MB of RAM and that's it. There's no OS to ask for available RAM block.

Why on Earth would you introduce additional and completely useless memory abstraction layer there? Each game handles the dynamic memory allocation as it needs.

I have my own dynamic memory allocator that uses a portion of RAM for dynamic allocations.

Because the linker has to compute absolute addresses of all jumps and data segment/variables during link time.

That, however, would probably kill one address register and introduce performance penalties, as any complex address computation is a multi-cycle op. If that had to be done for every single variable access...

This is normal.
The linker will make list of all those addresses and put behind executable. This is called relocation table.
The OS does parse this onloading your EXE, and will adjust your binary.

Et Voila, Your binary can run on any address.

So, I just downloaded Abacus Advanced System Programmers Guide For the Amiga and found the section on DOS Library, which contains (among others) these functions:

File IO:  Open/Close, Read/Write, Lock/Unlock, Input/Output
Programs: Execute, LoadSeg, UnloadSeg
Process:  CreateProc, DeviceProc, Exit, Delay, WaitForChar

And some functions of Exec Library:
Allocate / Deallocate, AllocMem, AllocAbs, FreeMem, AvailMem,

So, I suspect those are the OS library functions people are referring to ?

Meaning, every single OS for Amiga has to support them ?

I haven't found any notes on the relocation table there, though.

Option 1: Absolute address of executable via .ORG $1000000
Exec.AllocAbs (ProgramLength, $1000000)

Option 2: Relocatable executable
Exec.AllocMem (ProgramLength, Requirements)

Lets say your code looks like this
 
  ADD.L DATA1,D0
  move.l D0,RESULT1
  rts

DATA1: DC.l 5
result1 dc.l 0

You can just compile this.
The ASM will create a file with included all data to run this, at ANY address.
And when you start the program on AMIGA OS then the OS will take care. The program will just work.

AllocAbs() requests memory at a specified location. If that memory is already taken, the call will fail and your program will either crash (bad) or abort silently because it can't have what it needs (semi-bad).

AllocMem() gives you a chunk of memory of the requested type at just any location where the OS sees an empty spot in its memory lists. The function returns a pointer to that chunk of memory or, if there isn't enough memory of the requested type available, returns -1. If your program doesn't check for this return code and there is not enough memory available, => crash.

AllocMem(), btw, is deprecated anyway, better use AllocVec(). You may also consider the "Pool" functions (AllocPooled() and friends).

Generally you will not use fixed addresses. As you already noticed, the Amiga is a computer with an operating system. More precisely it is a multitasking computer without memory protection which is why programs need to behave nicely to get along. In 1985 coders came to the Amiga from the C=64 and just didn't get this new stuff about not using fixed addresses. They killed the OS (that doesn't even protect itself) and just coded the way they always did on the C=64. It took some years until they finally understood that not all Amigas were created equal and that in fact the OS and hardware changed over time which caused their programs to fail badly.

Don't treat the Amiga as a games console. You will have to adapt your code to variable addresses. If you are really desperate, you could probably use self-modifying code to just overwrite all the fixed addresses you are using now with the addresses of what the OS gives you on your AllocVec() requests and write these addresses right into your fixed-address code. Personally I think this would be rather dirty and probably more work than learning the clean way and rewriting your code to use variable addressing. Furthermore, if you do some tricks like calculating hardcoded addresses (e.g. something like MOVE.l a0,d0; BSET #10,d0; MOVE.l d0,a0 to switch screenbuffer or whatever), this will never work well on an Amiga.

Just have a look at a few coding examples, it's quite simple and you have done infinitely more complicated stuff than this.

Arrg no! please not do this.

There is really no need to ORG a program to a fixed address.
Just let the Assembler create you binary.
The assembler can happily used absolute addressing - this is fine.
The AMIGA OS will do this "rewrite" of your executable when its first loaded into memory.
This means you can happily code using absolute addresses and they will be the correct addresses to the memory where the OS loaded you.

Really its easy this way.