AmigaOS 3.2 and beyond

[Minuous]

A good emulator should virtualize the guest memory so that it can be mapped to anywhere in the host memory.

[meynaf]

Originally Posted by Thomas Richter

Unfortunately, that list is not quite complete. What MacOs keeps in the lower 32K amongst others is the trap table, that is the list of addresses within the ROM to which the lineA traps of the Os jump to. It also contains the list of device drivers and their addresses within the ROM (or the driver). So, in the end, it doesn't help. That 32K are reserved for MacOs, and free memory (for applications to allocate) start above the 32K. This part you can relocate by providing MacOs an alternative start address for the memory pool. The 32K you cannot because the kernel works from it - and probably some MacOs "Init"s likely too.

But MacOs can be patched by the emulator to relocate these accesses. The problem is only with user programs.

Originally Posted by Thomas Richter

The appendix does. It also tells you where the memory pool starts.

Sorry, no appendix in the version i've seen.

[Thomas Richter]

Originally Posted by Minuous

A good emulator should virtualize the guest memory so that it can be mapped to anywhere in the host memory.

That requires a good host operating system which allows it, and also allows sharing of its own resources by the emulation. You could relocate the 32K with the MMU, however, as ShapeShifter also requires AmigaOs for disk access, this *also* means that the 32K needs to be free of Os resources. Take it as it is: Shapeshifter requires the 32K free, like it or not, and no mind about reasons because nobody is going to change that code anymore. Problem being: It is much easier to release parts of that memory later than to reserve it upfront.

[Thomas Richter]

Originally Posted by meynaf

But MacOs can be patched by the emulator to relocate these accesses. The problem is only with user programs.

Not necessarily. Also Mac "Init"s which may access the area there.

[malko]

Originally Posted by Thomas Richter

Boot shapeshifter without 32K reserved. [...]

What, just one example?
With all the posts you're making around here, there aren't any more examples?

Originally Posted by Thomas Richter

[...] Now go trolling elsewhere, thank you.

Troll? And the person who claims that it is normal that the OS monopolise part of the chip ram for a very specific case (a really specific use case, it should be remembered - and therefore little used on principle) - that represents what, 0.1% of cases? - to the detriment of the other 99.9% of users, what do you call it?

If tomorrow another third-party application asks for 100K reserved, are you going to roll out the red carpet and make the OS block the necessary surplus?

Once again, the majority of people here have nothing against *the OS offering help* to a specific use case, but the solution implemented is a bad one because it's to the detriment of the 99.9% of users as it is mandatory by default as soon as you turn on the computer.

[Don_Adan]

"ShapeShifter is a multitasking freeware Macintosh-II emulator for
the Amiga and DraCo computers. It allows to run Macintosh software
concurrently to Amiga applications without hardware add-ons or
modifications.

Some of the emulation's features:

- Supports MacOS 7.1 thru 8.1"

Shapeshifter IS NOT Macintosh emulator.
Shapeshifter is Macintosh-II emulator, with supported MacOS from 7.1 to 8.1.

If Thor want to create new Mac emulator, then this extra memory can be necessary.
For now 28KB of chip memory is wasted.
This area (from $1000 to $8000) is used for COMPATIBILITY WITH OLDER Macs programs.
All other accessed are patched.
If something (any access) is missing, Thor can fix Shapeshifter, NOT WASTING Amiga chip RAM.

Here are ShapeShifter source code:

https://aminet.net/package/misc/emu/ShapeShifter_src

[Thomas Richter]

Originally Posted by malko

What, just one example?

Go through the thread, there is another...

Originally Posted by malko

If tomorrow another third-party application asks for 100K reserved, are you going to roll out the red carpet and make the OS block the necessary surplus?

Why would I?

Originally Posted by malko

Once again, the majority of people here have nothing against *the OS offering help* to a specific use case, but the solution implemented is a bad one because it's to the detriment of the 99.9% of users as it is mandatory by default as soon as you turn on the computer.

Hold on, where is that 99.9% coming from? From your nose? That it took about six years for someone actually even to notice, even though it is in the FAQ along with instructions, speaks probably more for how harmless this actually is.

[Thomas Richter]

Originally Posted by Don_Adan

If Thor want to create new Mac emulator, then this extra memory can be necessary.

You got the logic backwards. Unless I would want to waste huge effort to create a new emulator, that memory is right now necessary. Not the other way around. Besides, I already pointed out that this is not the only use case here.

Originally Posted by Don_Adan

For now 28KB of chip memory is wasted.

Nothing is "wasted". It is reserved, and you can claim it.

Originally Posted by Don_Adan

This area (from $1000 to $8000) is used for COMPATIBILITY WITH OLDER Macs programs.
All other accessed are patched.

Says who? Where is that "older" coming from? Again, I told you what is living in this area. And no, it is not "patched" because in general you cannot patch it.

Originally Posted by Don_Adan

If something (any access) is missing, Thor can fix Shapeshifter, NOT WASTING Amiga chip RAM.

Hold on. I'm providing a practical solution for a real problem. I'm not going to touch that program, by no means. It has compatibility implications, it requires access to sources of MacOs to really learn what can be done, and no, I have no spare time to waste.


The problem with PrepareEmul is that is not at all forward compatible. It assumes that the Kickstart bootstrap code is in a particular location, and that the code that reserves the zero page is in a particular location. This is not going to work in a future version of Kickstart - unless Kick takes care of it for itself.

To put it around: You are the one that claims "oh, it's just a minor patch to MacOs, why don't you 'just patch it'". Well, go along, show "how easy this is".



I'm not holding my breath for this kind of nonsense for a non-existing problem that does not affect the majority of users. Apparently, so little that it was apparently not being noticed all the years, despite proper documentation.

[a/b]

Originally Posted by Thomas Richter

That it took about six years for someone actually even to notice, even though it is in the FAQ along with instructions, speaks probably more for how harmless this actually is.

People noticed, and I clearly remember it being discussed here before. As for me, it was then when I stopped reading the release notes and said something like:
"$@#$ $@# $@#$ $@#$ #@$ #@$ @#$@##$ @#$ {redacted by FBI and KGB}. I'm out, C= 3.x is good enough for me. You apparently don't want my $$$, so good luck."
Yeah, I find it insulting that they would reserve ~32kb chipmem for, subjectively, irrelevant piece of userland software (involving Apple Mac nonetheless) and make you go through extra steps/reboot to nullify it, and expect the majority to suck it up.

Just a silent majority guy voicing his immutable opinion. Over and out.

[Thomas Richter]

Originally Posted by a/b

People noticed, and I clearly remember it being discussed here before. As for me, it was then when I stopped reading the release notes and said something like...

...and in the end, what did not work? The decision to be made here was a simple one: PrepareEmul would not continue to work as it is bound to a particular implementation. Wheras the average bootloader games do not care about chipram allocation anyhow would not be affected, and for the average workbench user it would not make any practical difference.


IOWs, your reaction is all more emotional, without being actualy backed up by facts (after all, you did not even use it, so you do not know whether it made a difference?), whereas the decision towards this feature was driven by a factual analysis of the problem and how to solve it without impacting user experience too much.

[meynaf]

Originally Posted by Thomas Richter

Not necessarily. Also Mac "Init"s which may access the area there.

Listen, software is either part of the Os, in that case it can be relocated, or third party. Do not add new players in the field.

Originally Posted by Thomas Richter

Hold on, where is that 99.9% coming from? From your nose? That it took about six years for someone actually even to notice, even though it is in the FAQ along with instructions, speaks probably more for how harmless this actually is.

So a bug that has gone inconspicuous for a long time does not need to be fixed anymore, now ?

Originally Posted by Thomas Richter

Hold on. I'm providing a practical solution for a real problem.

But it is a bad solution.
You are allocating 32k of precious chipmem - which is nearly as scarce as rom space - for just one or two programs.
You have to understand that the needs of the many outweight the needs of the few.
IOW if two programs don't work, then these two programs have to be changed, not the OS. Unless it is absolutely impossible to make them work (which doesn't appear to have been proven, btw), and even so other software must not be affected.

Originally Posted by Thomas Richter

(...) I have no spare time to waste.

Of course, as you prefer wasting other ppl's chipmem.

Originally Posted by Thomas Richter

The problem with PrepareEmul is that is not at all forward compatible. It assumes that the Kickstart bootstrap code is in a particular location, and that the code that reserves the zero page is in a particular location. This is not going to work in a future version of Kickstart - unless Kick takes care of it for itself.

Then at least give PrepareEmul some kind of API to do it properly, instead of reserving chipmem in all cases !

Another solution could be to add an option in the boot menu for reserving that space. Have you even thought of doing it this way ?

[Thomas Richter]

Originally Posted by meynaf

Listen, software is either part of the Os, in that case it can be relocated, or third party. Do not add new players in the field.

"Init"s are third party software that, however, run so early that they integrate into core components of the Os where other regular applications do not reach. I'm not "adding a new player", I'm just giving you some insight how MacOs works.

Originally Posted by meynaf

So a bug that has gone inconspicuous for a long time does not need to be fixed anymore, now ?

Bug? Which bug? There is no bug here. It is a requirement of the structure of MacOs.

Originally Posted by meynaf

But it is a bad solution.
You are allocating 32k of precious chipmem - which is nearly as scarce as rom space - for just one or two programs.

..in a way such that it can be released, actually without going through hoops and hacks, yes. I just wonder what the reaction would have been if 3.1.4 would have lost applications. There would also be complaints. You cannot make it right for everyone, and this solution had the smaller impact.
Again, which games do *not* run under 3.1.4 due to this decision?

Originally Posted by meynaf

You have to understand that the needs of the many outweight the needs of the few.

Exactly, and this is why this choice was made. It is a minimal impact solution for a problem for which no ideal solution exists. Again, the majority of games hunting for chip mem are either boot loaders, where the problem does not matter, or run from a workbench or a startup-sequence, where in case of trouble (is there actually any?) the problem could be addressed.

Originally Posted by meynaf

IOW if two programs don't work, then these two programs have to be changed, not the OS.

We don't have this luxury in Amiga-land. Go ahead, try your luck, but I certainly will not.

Originally Posted by meynaf

Unless it is absolutely impossible to make them work (which doesn't appear to have been proven, btw), and even so other software must not be affected.

Again, you are invited to go ahead. I would not hold my breath since the problem goes deep into the internals of MacOs and its software landscape.

Originally Posted by meynaf

Then at least give PrepareEmul some kind of API to do it properly, instead of reserving chipmem in all cases !

Now, guess what MoveMemLo is? Exactly this API.

Originally Posted by meynaf

Another solution could be to add an option in the boot menu for reserving that space. Have you even thought of doing it this way ?

No, and again, I do not right away see the need for that. You are reacting emotionally, but not rational. A rational argument would be pinpoint to critical applications that break due to that problem - but there is nothing on the table, actually. Anything that could break could be worked around by "pulling the switch". Whether that is in the boot menu, requiring a reboot after setting a checkmark, or in a program in the startup-sequence does not make a practical difference. To avoid memory fragmentation, you need to go through a reboot anyhow. The program is the better solution since it can be automated. The boot menu you have to check manually.

[Don_Adan]

Originally Posted by Thomas Richter

You got the logic backwards. Unless I would want to waste huge effort to create a new emulator, that memory is right now necessary. Not the other way around. Besides, I already pointed out that this is not the only use case here.



Nothing is "wasted". It is reserved, and you can claim it.



Says who? Where is that "older" coming from? Again, I told you what is living in this area. And no, it is not "patched" because in general you cannot patch it.



Hold on. I'm providing a practical solution for a real problem. I'm not going to touch that program, by no means. It has compatibility implications, it requires access to sources of MacOs to really learn what can be done, and no, I have no spare time to waste.


The problem with PrepareEmul is that is not at all forward compatible. It assumes that the Kickstart bootstrap code is in a particular location, and that the code that reserves the zero page is in a particular location. This is not going to work in a future version of Kickstart - unless Kick takes care of it for itself.

To put it around: You are the one that claims "oh, it's just a minor patch to MacOs, why don't you 'just patch it'". Well, go along, show "how easy this is".



I'm not holding my breath for this kind of nonsense for a non-existing problem that does not affect the majority of users. Apparently, so little that it was apparently not being noticed all the years, despite proper documentation.

Read this again:

https://eab.abime.net/showpost.php?p...&postcount=223


Especially this "reserve the lower 4K of memory (which is all that the Mac needs - not 32K)."

4K, not 32K.

And this is not problem, if accessed memory over 4K occured. THIS IS BUG.
Fix Shapeshifter (sources available), NOT MADE STUPID CHANGES in Amiga ROM.
Maybe do you want to fix all buggy accesses for 32 KB before 0 address?

You know how many accesses to $ffff8000-$ffffffff area occured in buggy Amiga programs?
Aaa, sorry, but you dont like idea to add HiMem for Amiga OS.


Of course, you compared same Mac program under ShapeShifter and under Fusion?
Or maybe this bug occured only for Shapeshifter?
Which Mac program(s) call/use area from $1000 to $8000 under ShapeShifter?

And because you cant fix Shapeshifter code, you create very special "bypass"?
Genial.

[meynaf]

Originally Posted by Thomas Richter

"Init"s are third party software that, however, run so early that they integrate into core components of the Os where other regular applications do not reach. I'm not "adding a new player", I'm just giving you some insight how MacOs works.

You are adding a new player. These are obviously third party software.

Originally Posted by Thomas Richter

Bug? Which bug? There is no bug here. It is a requirement of the structure of MacOs.

No, that AmigaOs reserves 32k of chipmem for everyone is not a requirement of the structure of MacOs.
The bug is that some AmigaOs version now eats memory where it shouldn't.

Originally Posted by Thomas Richter

..in a way such that it can be released, actually without going through hoops and hacks, yes. I just wonder what the reaction would have been if 3.1.4 would have lost applications. There would also be complaints. You cannot make it right for everyone, and this solution had the smaller impact.

The problem is that it shouldn't be allocated at first place.

Originally Posted by Thomas Richter

Again, which games do *not* run under 3.1.4 due to this decision?

Perhaps examples have been posted there already, but this is not the point. AmigaOs is lean and mean and must remain so.

Originally Posted by Thomas Richter

Exactly, and this is why this choice was made. It is a minimal impact solution for a problem for which no ideal solution exists. Again, the majority of games hunting for chip mem are either boot loaders, where the problem does not matter, or run from a workbench or a startup-sequence, where in case of trouble (is there actually any?) the problem could be addressed.

There shouldn't be 'minimal impact'. There should be 'no impact at all'.

Originally Posted by Thomas Richter

We don't have this luxury in Amiga-land. Go ahead, try your luck, but I certainly will not.

If you don't have the time to properly fix a problem, then don't attempt to fix it at all.
We also don't have the luxury to waste chipmem.

Originally Posted by Thomas Richter

Again, you are invited to go ahead. I would not hold my breath since the problem goes deep into the internals of MacOs and its software landscape.

Really ? Doesn't the problem lie, rather, in the will to change AmigaOs internals in a way that's incompatible with PrepareEmul ?

Originally Posted by Thomas Richter

Now, guess what MoveMemLo is? Exactly this API.

Nope. If this was, that 32k would be free to start with.

Originally Posted by Thomas Richter

No, and again, I do not right away see the need for that. You are reacting emotionally, but not rational. A rational argument would be pinpoint to critical applications that break due to that problem - but there is nothing on the table, actually. Anything that could break could be worked around by "pulling the switch". Whether that is in the boot menu, requiring a reboot after setting a checkmark, or in a program in the startup-sequence does not make a practical difference. To avoid memory fragmentation, you need to go through a reboot anyhow. The program is the better solution since it can be automated. The boot menu you have to check manually.

This is of course not emotional by me, where did you fetch that ?
I don't give a sh** actually, still being using Os3.0.
I just read this thread out of curiosity and tried to help.
Now, ask yourself the question if you are not a little emotional here.

The crux is : do *not* reserve that memory unless explicitly told to do so, either by boot menu option or PrepareEmul-kind of program (thru some MoveMemLo API if you want).
What you did is to reserve this 32k all the time. The proper way to handle it is to reserve it only when the user wants it. Just do this, and everything will be fine. Even if this needs a reboot, which it always needed up to now anyway.

[malko]

Originally Posted by Thomas Richter

[...] Now, guess what MoveMemLo is? Exactly this API. [...]

How can you seriously call MoveLow an API ?

[Thomas Richter]

Yup. Do you seriously expect a full blown library for a single binary switch? It does what it is supposed to do, in the shortest and most efficient way.

[Thomas Richter]

Originally Posted by meynaf

You are adding a new player. These are obviously third party software.

Yes, and? Do you just want to boot MacOs to look at the desktop? In case you do not know, an "Init" is a functional extension of MacOs. There are plenty, some of which come with MacOs itself, others from third parties.

Originally Posted by meynaf

No, that AmigaOs reserves 32k of chipmem for everyone is not a requirement of the structure of MacOs.

If you believe so.... Reality disagrees. You can stomp on your foot, I believe MacOs is rather unimpressed. Anyhow, go along, try it, it's on you...

Originally Posted by meynaf

The bug is that some AmigaOs version now eats memory where it shouldn't.

"Should" or "should not" is a matter of requirements. The requirement is "keep existing software working", and "be forward compatible to future versions."

Originally Posted by meynaf

The problem is that it shouldn't be allocated at first place.

Says you. I don't. I believe it "should", as it was the minimal invasive solutiont that was the most harmful solution.

Originally Posted by meynaf

Perhaps examples have been posted there already, but this is not the point. AmigaOs is lean and mean and must remain so.

If you say so. Apparently, demands change, and depend on persons. Some people buy new versions due to new features. If you do not need new features, what's the point in a new version in first place?

Originally Posted by meynaf

There shouldn't be 'minimal impact'. There should be 'no impact at all'.

Well, if that's all you want, then "no change" means that you are not a potential customer of a new version. Suits me fine, really. But then don't complain.

Originally Posted by meynaf

If you don't have the time to properly fix a problem, then don't attempt to fix it at all.

There is no problem. I'm not going to fiiddle in third-party software for third parties. Leave alone that there is really nothing broken. You, with no experience whatsoever in MacOs systems programming, come to claim "No, MacOs only needs 4K lower memory". Well, as stated before, it's not that simple, and reality is more complex. But hey, it's a free world, go along, "fix it" if you think it is so easy. I personally do not waste my time there but go for a pragmatic solution. IOWs, get your hands dirty, try yourself.

Originally Posted by meynaf

We also don't have the luxury to waste chipmem.

We do, because, in case you really need, you can address the problem. Apparently, not many people had. There was traffic on the AmigaOs customer support, but really nothing much on this.

Originally Posted by meynaf

Really ? Doesn't the problem lie, rather, in the will to change AmigaOs internals in a way that's incompatible with PrepareEmul ?

The "incompatible change" is just "changing the bootstrap code slightly, then yes.

Originally Posted by meynaf

This is of course not emotional by me, where did you fetch that ?

Because there wasn't really much you had to show where this does damage anything.

[Minuous]

Originally Posted by Thomas Richter

If you believe so.... Reality disagrees. You can stomp on your foot, I believe MacOs is rather unimpressed.

Most Mac emulators on most platforms make no such requirement of the host system. It is not necessary for emulation in general, only for particular emulators where the hardware is not fully virtualized.

[meynaf]

Originally Posted by Thomas Richter

Yes, and? Do you just want to boot MacOs to look at the desktop? In case you do not know, an "Init" is a functional extension of MacOs. There are plenty, some of which come with MacOs itself, others from third parties.

That's still only two categories : MacOs itself and whatever comes with it, which may be patched by the emulator, and other software.

Originally Posted by Thomas Richter

If you believe so.... Reality disagrees. You can stomp on your foot, I believe MacOs is rather unimpressed. Anyhow, go along, try it, it's on you...

No, really, an OS does not have to be changed to accomodate for emulating other OSes. It's not its job.

Originally Posted by Thomas Richter

"Should" or "should not" is a matter of requirements. The requirement is "keep existing software working", and "be forward compatible to future versions."

You forgot "don't annoy users".

Originally Posted by Thomas Richter

Says you. I don't. I believe it "should", as it was the minimal invasive solutiont that was the most harmful solution.

The solution where this allocation is only optional and done only upon request, isn't harmful and is 'minimal invasive' too.

Originally Posted by Thomas Richter

If you say so. Apparently, demands change, and depend on persons. Some people buy new versions due to new features. If you do not need new features, what's the point in a new version in first place?

New features may need memory, there is nothing wrong with that - but they shouldn't allocate it when they are not used.

Originally Posted by Thomas Richter

Well, if that's all you want, then "no change" means that you are not a potential customer of a new version. Suits me fine, really. But then don't complain.

I'm not complaining, just trying to explain why this change is bad.

Originally Posted by Thomas Richter

There is no problem. I'm not going to fiiddle in third-party software for third parties. Leave alone that there is really nothing broken. You, with no experience whatsoever in MacOs systems programming, come to claim "No, MacOs only needs 4K lower memory". Well, as stated before, it's not that simple, and reality is more complex. But hey, it's a free world, go along, "fix it" if you think it is so easy. I personally do not waste my time there but go for a pragmatic solution. IOWs, get your hands dirty, try yourself.

And again, a personal attack ! I had to do a little bit of MacOs programming to be able to port a 1,5MB game to Amiga, you fool. And the docs i've seen do not mention 32k.
Of course, i'm not alone saying this - including Jim Drew who actually wrote a Mac emulator. Seen that link in Don Adan's post ?

Originally Posted by Thomas Richter

We do, because, in case you really need, you can address the problem. Apparently, not many people had. There was traffic on the AmigaOs customer support, but really nothing much on this.

So you admit this is a waste. Fine.

Originally Posted by Thomas Richter

The "incompatible change" is just "changing the bootstrap code slightly, then yes.

If the change is small, perhaps it must be questioned.

Originally Posted by Thomas Richter

Because there wasn't really much you had to show where this does damage anything.

I know by experience that if something can go wrong, then something will go wrong. This is a programmer's life, nothing emotional.

[malko]

Originally Posted by Thomas Richter

Yup. Do you seriously expect a full blown library for a single binary switch? It does what it is supposed to do, in the shortest and most efficient way.

YOU said this is an API. I pointed out it is not and now you would like me to expect a full blown library ?
You are invited to propose a real Amiga API to fix this MAC OS specific problem. I am sure not only the 0,1% of MAC customers buying the Amiga OS for that use will reward you accordingly, but also the others 99,9% of Amiga users as well.

Originally Posted by meynaf

[...] AmigaOs is lean and mean and must remain so. [...]