AmigaOS 3.2 and beyond

[Don_Adan]

Originally Posted by Thomas Richter

Which means that the amount of users that profit from that is extremely limited, and the amount of hard-to-detect errors due to improper error checking increases. Besides, as I already said, it conflicts with existing hardware.




That depends on the configuration.



Again, the purpose of the zero page is *not* to act as a trampoline for MuRedox. The purpose of the zero page is to detect NULL pointers by MuForce. How large that area needs to be depends on the MMU page size, and the MMU page size you can configure. It is not by accident that the maximum MMU page size *also* matches the 32K zero page size, and conveniently also matches the size of the MacOs globals.

MacGlobals are relocated to other memory area by Mac emulators, Fusion and Shapeshifter.

Whow, you want to made with every Amiga debugging machine?
For what?
This is very useless option for average Amiga user.
And for about 99% cases, 1KB of zero page is enough to find wrong access bugs.

As choosable OPTION it can be acceptable.
As DEFAULT this only wasted Amiga resources.
And is totally useless for Amigas with 68000, 68010, 68020,68080, 68040 (PiStorm version).

Too bad that you are not Amiga games player.
You can learn how bugs are catched by WHDLoad.

[Don_Adan]

Originally Posted by Thomas Richter

Correct, in case you haven't understood it so far.

Really,? You made one BIG HOLE in Amiga memory. Available for strange programs.
Even in C new viruses can be written, due many free and unused memory for 68000/68020.

[NorthWay]

Just a curio: I patched my KS(3.1) to start chipmem from $0000F000, but I have a well expanded machine so I'm not bothered.
Oh, and I tried using $00010000 but I'm not sure what happened there: I just got a grey screen. I looked a lot at it, but couldn't find any obvious bug in what I did. *Shrug*

[aros-sg]

Maybe it would be possible to ~delay the 32k reservation in boot sequence. Make it such that ~relocatable "stuff" ends up in this low memory area and somewhere later in startup-sequence (a chip memory hungry game would start before that) move the stuff out of the way.

Relocatable things may be copperlists, buffer for sprite, bitplanes, ...

Known/~fixed MEMF_CHIP allocations that happen at every boot would/could be built into a table at kickstart build/compile time and early in the boot sequence the entries in the table would be AllocAbs()ed. So they are basically pre-allocated at build time.

[Thomas Richter]

Originally Posted by Don_Adan

MacGlobals are relocated to other memory area by Mac emulators, Fusion and Shapeshifter.

Are you now making up such statements? You *cannot* relocate the globals - point being that they are accessed by MacOs programs. These are globals because programs access them there.

Originally Posted by Don_Adan

Whow, you want to made with every Amiga debugging machine?

No, getting rid of bad patches. Which is not so uncommon because that was already the reason for enlarging the zero page to 4K in 3.1 Oh well..

Originally Posted by Don_Adan

As choosable OPTION it can be acceptable.

It *is* an option in case that wasn't clear to begin with.

[Thomas Richter]

Originally Posted by aros-sg

Maybe it would be possible to ~delay the 32k reservation in boot sequence.

*Sigh* This entire discussion is pointless. The people that argue here do not have the techical insight to even understand the problem.


Again, you cannot *delay* the reservation because something is already *initialized* in this region to begin with when the system starts before it even boots. That is expansion, graphics, trackdisk... whatever runs early, and sometimes so early not even a KickTag can kick in. Which is exactly *why* PrepareEmul is such an ugly hack that, depending on the machine, has to choose between several strategies to work from, and is even kickstart depending in some cases.



Yes, I'm really serious, the entire thing is a really really ugly hack that is absolutely not future proof, and no, it does not make sense to write a different version for each kickstart to come.

[Thomas Richter]

Originally Posted by Don_Adan

Really,? You made one BIG HOLE in Amiga memory. Available for strange programs.

No, a 24K hole. And now go troll elsewhere, thank you.

[malko]

Originally Posted by Thomas Richter

[...] The solution is available in Aminet since day 1 [...]

Originally Posted by Thomas Richter

[...]It *is* an option in case that wasn't clear to begin with.

It is an *option* when you can choose to activate it (opt-in) NOT when you have to deactivate it (opt-out) with a tool that you have to download from a third party site .

[Docent]

Originally Posted by Thomas Richter

Again, you cannot *delay* the reservation because something is already *initialized* in this region to begin with when the system starts before it even boots. That is expansion, graphics, trackdisk... whatever runs early, and sometimes so early not even a KickTag can kick in.

How about this approach:
Reserve 32kb as of now but, depending on an option from boot menu, leave it as is for emulation or mmu tables use, otherwise add 24kb from 32kb of reserved memory as another chunk to free memory list. The option should be by default off, so users can have this memory available for allocations. Maybe even would be possible to merge back this chunk with main free chip ram memchunk, making the largest block larger

[cloverskull]

Hey guys, didn’t boemann say this chip ram thing is going to change in a future update?

Might I request that if this IS the case, that the entire chip ram argument move into a different thread so that this thread can continue to focus on other things? I feel like the point of this thread is completely derailed at this point.

[aros-sg]

Originally Posted by Thomas Richter

Again, you cannot *delay* the reservation because something is already *initialized* in this region to begin with when the system starts before it even boots

With "boot sequence" I did not mean the late stuff that is done from startup-sequence onwards. I meant from the earliest code executed when machine starts up.

Said otherwise: you keep having your 32k reserved very early as it is now, but you still put - through whatever means - some of memf_chip requiring stuff in this low memory area if it's such stuff that can be relocated (moved out of the low 32k) sometime after startup-sequence starts being processed (and after chip hungry game would be started) before there is any program (Mac emu) that relies on this 32k being available for use.


So at very beginning of s:startup-sequence free chip memory is higher. Then ~"Relocate32k" is executed: stuff in reserved area gets removed, rebuilt, whatever and it ends up in memory after 32k area. Free chip memory gets lower. But a chip hungry game is not affected, because it would start before that. And an mac emulator would only run after.


Just need to find/identify those memf_chip allocations done by the OS during boot(strap) that are safe for such relocations.

[Thomas Richter]

Originally Posted by aros-sg

Said otherwise: you keep having your 32k reserved very early as it is now, but you still put - through whatever means - some of memf_chip requiring stuff in this low memory area if it's such stuff that can be relocated (moved out of the low 32k) sometime after startup-sequence starts being processed (and after chip hungry game would be started) before there is any program (Mac emu) that relies on this 32k being available for use.

You cannot relocate AmigaOs structures once they have been placed in this memory area because you do not know which other structures or processes already took pointers to such structures. Just to name one, it is absolutely not uncommon to have ConfigDevs of expansion devices in that memory area, and it is neither uncommon that device drivers (required for booting) keep pointers to these ConfigDevs. That is, once they are placed in that memory, they have to stay for the lifetime of the system.


What you can do is to reinitialize the chip memory pool MemHeader structure to also include additional memory at lower end. While that formally gives you memory back, it probably does not help much because at this point the memory is already fragmented - the part above the allocated structures, and the new area below what has been allocated already.

Originally Posted by aros-sg

Just need to find/identify those memf_chip allocations done by the OS during boot(strap) that are safe for such relocations.

You cannot, simply because that's not under control of the Os.