A.D.A. Amiga Demoscene Archive

Please excuse my noobish question, but could please someone confirm: If an A500 has a 512k slowmem trapdoor expansion installed, this memory (starting at C00000 iirc) will be of type MEMF_FAST (and not CHIP) when using AllocMem(), right?

In the memorymap diagram at amigacoding.com there is mentioned a 512k trapdoor CHIP ram area at 80000-fffff. Is that a mistake? Or do such expansion boards indeed exist?

If you have slowmem installed then it will indeed be used if you try to allocate MEMF_FAST.
However, it's most likely better to just allocate without using a specific memory type flag. As long as you do *not* specify _CHIP then you'll get slowmem or fastmem when it's available (and chip if that's the only type installed).

As for your second question: yes, you can have trapdoor expansions with chipmem (as long as you have the right Agnus version and mainboard revision). :)

Thanks for clarifying! Viewing this from an somewhat unorthodox angle this means it is possible to force specific allocations to be placed outside of chipmem on an A500+slowmem (and any amiga with real fastmem for that matter).

Let's say I would write a small program that has all sections put in slow/fastram: When this program kills the system after it has been loaded into fastmem by the OS, I suspect I would be free to put stuff at absolute adresses in CHIP ram (say after the first 64K to not disrupt any vectors etc.) without problems (no OS interfering)?

I guess a graceful exit to shell/workbench is not really possible anymore in this case, but that's a price i'm willing to pay :)

However, forcing stuff into non-chip means that your code won't work on machines that only have chipmem, even if they have enough free ram overall - for instance vanilla a600 / a1200 or a500's with chipram expansions.

If you really need to make a program that is loaded as a regular file and also needs absolute addressing then you might want to look at manually relocating your code instead. I.e. let the OS load your stuff into whichever memory section it wants and then do new allocations and relocation afterwards.
Or a variation of this where you just load a tiny piece of code at first and then load the remainder of your stuff directly where you want it. (However, this'll break down if you overwrite memory positions that are needed by the OS file loading).

Either way, I think the first question would be: do you really need to do this? :)

Yeah, on chipmem-only amigas this will not work :)
I was just trying to come up with some kind of super-simple demo system concept, where I could have some kind of loader stub that executes from slow/fastmem, kills the system, and then provides some useful data (sin-tables etc.) and commonly used helper routines to demo parts which get loaded to a fixed address in chipram (and thus avoiding to deal with hunk relocation stuff, because i'm lazy and noob).
Maybe even provide the helper functions via TRAP or something like that.

(this is inspired by some discussions of Magnus/Insane and bifat, which I read on pouet)

There are very few scenarios I can think of where you'd need to deal with hunk relocation or absolute memory addressing though, so this sounds like you're planning for something that might never happen. :)
And if you for some reason need total control and access to as much memory as possible then you should be looking at trackloading instead, which means you can stop caring about how the OS loads your files.

If this is mainly about creating a simple framework / demosystem then I'd focus on the contents of the helper functions and data first, preferably also testing it out with some actual releases where you simply include them in your prod the same way you'd do any other code.
"Normal" one-file demos are (imho) by far easier to work with.

Of course, if you want to build your framework in a specific way just for the hell of it then my above arguments are completely void. :-D

Really late to the party, but you should consider using LDOS. Arnaud Carré (Leonard / Oxygene) used this on ST and ported it to Amiga. It does A500 OCS really well, and is very easy to use. Does not have a lot of helper functions, but sourcecode is included and it can be expanded.

http://github.com/arnaud-carre/ldos

Best of luck!

If you are planning to run your demo on an A500 and you don't need real fastmem you should use MEMF_ANY, that way your miggy will try to use fast mem first (even if it's slow/ranger trapdoor memoy) and if there's not fast ram available it will use chipmem. That way your productions will also work on A500+/A600 or A500 rev5/6 with 1MB agnus and with just 1MB chip.