A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / A500 trapdoor slowmem allocation

 

Author Message
jar
Member
#1 - Posted: 6 Jan 2020 19:58
Reply Quote
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?
Angry Retired Bastard
Member
#2 - Posted: 7 Jan 2020 15:27
Reply Quote
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). :)

jar
Member
#3 - Posted: 7 Jan 2020 18:01
Reply Quote
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 :)
Angry Retired Bastard
Member
#4 - Posted: 8 Jan 2020 08:58
Reply Quote
jar:
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)?


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? :)
jar
Member
#5 - Posted: 8 Jan 2020 13:42
Reply Quote
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.
jar
Member
#6 - Posted: 8 Jan 2020 13:45
Reply Quote
(this is inspired by some discussions of Magnus/Insane and bifat, which I read on pouet)
Angry Retired Bastard
Member
#7 - Posted: 8 Jan 2020 14:24
Reply Quote
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

 

  Please register a new account or log in to comment

  

  

  

 

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