AmigaOS 3.2 and beyond

[alpine9000]

Originally Posted by NorthWay

Would you prefer it to have a prefs program where it could be toggled back on, or some kind of ENV setting that SetPatch would read and react to?

Apart from that, this is a one-way street: All allocations are done from low to high addresses, and the chances of the OS allocating some chipmem before you get to have a say and then later freeing it are slim-to-none. If it got freed then it would be a sitting duck for a new alloc before you get to make a move.

If this was important to you, you could always try to petition the devs to use MEMF_REVERSE for allocations that are never expected to be freed again. Chances are that it would help close to nothing.

EDIT: It would be more interesting if the whole first 64K was skipped - there are a few bugs that creep out of the woodwork with Enforcer type tools due to code using (Ax,Dx) addressing with a 0 in Ax.

I guess two things I find interesting is that the default is that we reserve space for Mac emulators ?

And the second part is the tool to revert this is not included in the OS ? I would have thought a nice Workbench tool like "NoFastMem" would be the go.

I find the background to these decisions interesting and in this case it's probably not the way I would have gone - but I have a computer with only 1mb of chip ram and never run Mac emulators, so for me losing "28k" of precious chip ram for something I will never use seems a weird default (But that's me).

Maybe the developers judged more people run Mac emulators than need that extra chip ram ?

[NorthWay]

Originally Posted by alpine9000

Maybe the developers judged more people run Mac emulators than need that extra chip ram ?

It does at least cut one possible extra reboot for Mac users (sorry, I don't know if Mac emulators do that).

Apart from possibly making different ROM versions available, I could foresee a number of different heuristics for automatically giving the memory back; like only reserve if 68020+, or give back if only chip/slowmem is found. That would need some devs discussion for what is workable logic for that.

[malko]

Originally Posted by alpine9000

From the 3.2 FAQ
[...]
I'm quite intrigued by this, for a couple of reasons:
Firstly that Mac emulation is such a priority that this would be the default ?
And secondly, that a better technical solution to this could not be developed ? (Edit: technical solution to enabling/disabling it more seamlessly)
Any background on this that could be shared ?

This is indeed really astonishing.
... and greatly disappointing that such allocation is not performed "when needed" (but by 'new' default design).
I second you : this requires a better technical solution.
No user should be thieved chip memory.

[Don_Adan]

If I remember right , Jim Drew wrote that only first 4KB of chip memory is necessary to be free for Mac emulation.
More than this is simple wasting of chip memory.
Maybe this is used by mmu.library for fast patching for some missing instructions, but for me this is kickstart 3.2 bug.
Is totally useless for 68000/68020/68030 and perhaps 68040 Amiga users.
Maybe if this useful for 68060 users, then can be done ONLY IF 68060 IS DETECTED.
Not for all Amigas.

[Thomas Richter]

Originally Posted by alpine9000

Firstly that Mac emulation is such a priority that this would be the default ?

Second of all, are 24K of memory really so important to give it any priority? If I have the chance to invest a tiny bit of memory to get rid of a hack, it's a good deal. It's not only Mac emulation, though mostly. It is also memory management for the MMU. 32K is divisible by all page sizes in use, and the largest page size the 68030 and 68581 can handle. It isn't much memory either, and if you really need it, you can also release it.

Originally Posted by alpine9000

And secondly, that a better technical solution to this could not be developed ? (Edit: technical solution to enabling/disabling it more seamlessly)

You cannot keep additional memory free at boot time because this is the chip memory pool memory is allocated from at boot time. You could possibly enlarge the chip memory at boot time with a bit of tweaks such that you get some pieces of memory back, though at that time, the memory is already fragmented simply because graphics (and some other Os components) already allocated chip memory. So while you gain "numerically" some memory, it is probably less helpful than it sounds.



In a sense, since 3.1.4 "MuMove4K PrepareEmul" is more or less built into the Os, avoiding some hacks you would need to go through to get some applications running. MoveMemLow uses an (albeit undocumented) interface to tell the Os to only reserve minimal memory for itself in case you really need it.

[Thomas Richter]

Originally Posted by Don_Adan

If I remember right , Jim Drew wrote that only first 4KB of chip memory is necessary to be free for Mac emulation.

Then Jim is wrong. Quite simple. Read "Inside MacIntosh", in particular the MacOs globals. It's the first 32K. Really. I did some Mac programming, actually.

[alpine9000]

Originally Posted by Thomas Richter

Second of all, are 24K of memory really so important to give it any priority? If I have the chance to invest a tiny bit of memory to get rid of a hack, it's a good deal. It's not only Mac emulation, though mostly. It is also memory management for the MMU. 32K is divisible by all page sizes in use, and the largest page size the 68030 and 68581 can handle. It isn't much memory either, and if you really need it, you can also release it.

For people wanting to play games that don't take over the OS on small Amiga systems - 24k is huge - otherwise all of these "ADDxxK" programs would not exist.

I assume that the memory is reserved by the Kickstart, so even games booting from floppy do not get access to it (Unless they kill the OS)?

I am thinking of small systems with a 3.2 rom installed that are now not able to load games that a 3.1 system could ?

And the benefit is someone gets one less reboot when starting a Mac emulator ?

Please correct me if I am wrong - I don't want to start a big flame war - just trying to understand the situation.

[Thomas Richter]

Originally Posted by alpine9000

For people wanting to play games that don't take over the OS on small Amiga systems - 24k is huge - otherwise all of these "ADDxxK" programs would not exist.

Look, people that just see Amiga as games machine probably don't have a need for an updated kickstart anyhow. Go for 1.3, be happy. If you occasionally want to play a game, a solution was provided, MoveMemLow exists. Most of this type of "Software" doesn't use the Os anyhow, so why bother in first place. It's not 1989 anymore, RAM is cheap, expansions exist, and 24K isn't much.

Originally Posted by alpine9000

I am thinking of small systems with a 3.2 rom installed that are now not able to load games that a 3.1 system could ?

Same as before. Now I have Kickstart 3.1 installed, I am now not able to load games a 1.3 system could? Yup, exactly that. There are tools to get them working, the tools have been made available for you, but please understand that priorities for an Os are different that acting as a boot loader for games.

Originally Posted by alpine9000

And the benefit is someone gets one less reboot when starting a Mac emulator ?

You got it.

[Don_Adan]

Originally Posted by Thomas Richter

Then Jim is wrong. Quite simple. Read "Inside MacIntosh", in particular the MacOs globals. It's the first 32K. Really. I did some Mac programming, actually.

Really?
Fusion author is wrong?
It will be crashed Amiga.
And you miss one thing, Mac emulator is not equal to be real MacOS.
Mac emulator can patch some routines when installing MacOS.
Sorry, but in this case I trust Jim.
Then kickstart 3.2 wasting 28KB of chip memory for NOTHING.

[alpine9000]

Originally Posted by Thomas Richter

Look, people that just see Amiga as games machine probably don't have a need for an updated kickstart anyhow. Go for 1.3, be happy. If you occasionally want to play a game, a solution was provided, MoveMemLow exists. Most of this type of "Software" doesn't use the Os anyhow, so why bother in first place. It's not 1989 anymore, RAM is cheap, expansions exist, and 24K isn't much.

People buy the kickstart and install it, then complain to game developers when the game won't start. Chip ram is not cheap or easy to upgrade in many Amigas.

Originally Posted by Thomas Richter

Same as before. Now I have Kickstart 3.1 installed, I am now not able to load games a 1.3 system could? Yup, exactly that. There are tools to get them working, the tools have been made available for you, but please understand that priorities for an Os are different that acting as a boot loader for games.
.

Why do Mac emulation enthusiast get priority over all other Amiga users ? Seems backwards.

It's not about the OS being a bootloader for games - it's about needing to choose between upgrading the OS or having to double boot every time you want to use all available ram - which can be for many reasons - not just games.

If the compromise added benefit outside running a Mac emulator I would be less confused by the design choice.

[Thomas Richter]

Originally Posted by Don_Adan

Really?
Fusion author is wrong?
It will be crashed Amiga.

*READ* the documentation. It's not that I did not provide sources for you to do some research.

Originally Posted by Don_Adan

Sorry, but in this case I trust Jim.

Good for you. I trust the MacOs implementation.

Originally Posted by Don_Adan

Then kickstart 3.2 wasting 28KB of chip memory for NOTHING.

If that makes you happy, go for it. Surely PREPAREMUL is a complete waste...

[Thomas Richter]

Originally Posted by alpine9000

People buy the kickstart and install it, then complain to game developers when the game won't start. Chip ram is not cheap or easy to upgrade in many Amigas.

Then game developers should probably start using the Os.

Originally Posted by alpine9000

Why do Mac emulation enthusiast get priority over all other Amiga users ? Seems backwards.

Because Game developers don't care about the Os in first place. Why should the Os care about them?

Originally Posted by alpine9000

It's not about the OS being a bootloader for games - it's about needing to choose between upgrading the OS or having to double boot every time you want to use all available ram - which can be for many reasons - not just games.

So many that the problem appeared only five years after the 32K reservation of RAM was introduced? Seriously?

Originally Posted by alpine9000

If the compromise added benefit outside running a Mac emulator I would be less confused by the design choice.

Again, there are more reasons related moving exec to FastRAM in some implementations.

[Don_Adan]

Originally Posted by Thomas Richter

*READ* the documentation. It's not that I did not provide sources for you to do some research.



Good for you. I trust the MacOs implementation.



If that makes you happy, go for it. Surely PREPAREMUL is a complete waste...

But you know how works Mac emulators on Amiga?
Or you only read somewhere than MacOS needs 32 KB of zero page memory?
If you read infos from the net then Jim often wrote, that he rewrote some/many MacOS parts to 68k assembler.
And Fusion is fastest than original Mac for this same 68040 CPU.

Anyway you are interesting.
You know EVERYTHING better even if you dont know.

[alpine9000]

Originally Posted by Thomas Richter

Then game developers should probably start using the Os.

My latest game (demo) tries it's absolute hardest to be friendly with the OS - to the point where the network version operates reliably using any popular TCP stack - keeping all the TCP stacks happy seemed a pretty decent measure about how sucessfully my game co-operated with the OS.

Originally Posted by Thomas Richter

Because Game developers don't care about the Os in first place. Why should the Os care about them?

No-one is saying that are they ? Many games use the OS - maybe not graphics.library.

Originally Posted by Thomas Richter

So many that the problem appeared only five years after the 32K reservation of RAM was introduced? Seriously?

Maybe people don't read the FAQ as carefully as I did - I don't think anyone is suggesting this is a huge problem, just a confusing design choice - and the OS is something we all share. I think this is probably a surprise to some people.

Originally Posted by Thomas Richter

Again, there are more reasons related moving exec to FastRAM in some implementations.

I'd love to hear about any details you'd care to share.

[Thomas Richter]

Originally Posted by alpine9000

Maybe people don't read the FAQ as carefully as I did - I don't think anyone is suggesting this is a huge problem, just a confusing design choice - and the OS is something we all share. I think this is probably a surprise to some people.

So do I think. It's not a huge problem, it solves an inconvenience, so why make a big fuzz about it?

[alpine9000]

Originally Posted by Thomas Richter

So do I think. It's not a huge problem, it solves an inconvenience, so why make a big fuzz about it?

It solves an inconvenience for Mac emulation users and adds an inconvenience for other users ?

I don't think I am making a big fuss ? Asking about the reasons you settled on the design ?

The best outcome for me would be a technical solution that allows Mac emulators to run and people with only 1mb of chip ram to use all available ram. Sounds like a fun challenge to me.

[Thomas Richter]

Originally Posted by alpine9000

It solves an inconvenience for Mac emulation users and adds an inconvenience for other users ?

For which others? In particular? Which particular applications are affected? You seem to imply "all others" is a big volume, yet the volume is so small that this is the first thread after 5 years where someone constructs a problem where, from all the experience of the past years, there is none.

Originally Posted by alpine9000

The best outcome for me would be a technical solution that allows Mac emulators to run and people with only 1mb of chip ram to use all available ram. Sounds like a fun challenge to me.

Go for your challenge. In the meantime, there is a solution for the few where it actually does matter. The solution is available in Aminet since day 1 of 3.1.4. Hint: You can hack the MemHeader of the MEMF_CHIP and relocate. Additional hint: Won't solve potential fragmentation, but would add some memory.

[alpine9000]

Originally Posted by Thomas Richter

For which others? In particular? Which particular applications are affected? You seem to imply "all others" is a big volume, yet the volume is so small that this is the first thread after 5 years where someone constructs a problem where, from all the experience of the past years, there is none.

Sounds to me like you are really not interested in this and would rather we just stop discussing it - your wish is my command.

For people that do have a problem with it (and trust me they do exist - as I am one of them) - as you recommend - sticking with older versions of the OS might be the best option.