AmigaOS 3.2 and beyond

[Don_Adan]

Very funny, if people dont understand that THIS IS NOT 32KB of memory, but this is 32KB of chip memory.
Chip memory is very limited.
Its not problem for me, if it will be wasted 32KB of fast memory.

But it can not, for MMU it must memory started from 0 address.
Every Amiga coder know, that Motorola 68k has 4 bytes direct acceses for first 32KB of memory, via jmp $xx.w or jsr $xx.w.
When normally this is 6 bytes direct address via jmp $xxxx or jsr $xxxx.


MMU.library wasted/used more than 7MB of fast memory for tables on some Amiga configs.
And this is not problem for me.
Only a few strange for me, that this is DEFAULT, not OPTIONAL feature, like I heard from this Amiga user.
Same strange like kickstart 3.2 authors seems dont know that 68000, 68010 and 68020 CPU has NO MMU.
And seems dont know that exist something like CPU detection, and OPTIONAL CODE.

This demo of game uses about 1.8MB of chip memory.
And perhaps can not works on kick 3.2, because 32KB of chip memory was wasted as DEFAULT.

https://www.amigajump.com/

[Thomas Richter]

Originally Posted by malko

This is where you are mistaken.
MAC emulation is an application like any other applications that can be ran on the Amiga - be it game, paint program, word processor, etc. Therefore it is not the role of the OS to handle the specific needs of a particular application by stealing for all others users a resource that those other users may legitimately need for their use of the computer. To provide a better OS experience, the OS has to offer the possibility , on demand, to access a specific resource. Otherwise it is just 'bloat'.

Look, if all the Os 3.2 features that take additional RAM is "bloat" for you, then don't use the "bloat". That simple. That Os 3.2 on the cited A500+ takes apparently ~100K of chip ram (and not 24K) is the result of such "bloat" others call "features". You cannot get it right for everyone. Some users request more features, some not.

[Don_Adan]

Originally Posted by daxb

Sorry, but most games already started to not work on A1200 3.1 (fastram or not) or maybe since ROM 2.x. and that is more then 30 years ago. You know this of course. A lot of programs exist to bypass incompatibilities where the most known are JST and WHDLoad. However, as you wrote it isn't the best option to use 3.2 on low end systems. If you do you know the limitations or just have to live with it.

I also guess that nobody expects that everything works on every configuration. If you do you will be disappointed.

Again, I wrote that this is not only problem of games, but normal programs too.
F.e when I was alive, I used FileMaster 2.2 (sometimes 2 copies), CED 3.5, Asmone 1.20, EaglePlayer 1.54d for playing music from chipram.
For some mods I see "not enough memory".
Of course this is not enough chip memory, not fast memory.

And about games this is not true. Almost all games created after 1992 year works under kick 2.0/3.0/3.1. Older can not works mostly due 68020 CPU.

[Thomas Richter]

Originally Posted by Don_Adan

Very funny, if people dont understand that THIS IS NOT 32KB of memory, but this is 32KB of chip memory.

No, 24K. You cannot use the lowest chip ram anyhow, There are CPU autovectors in it, and some (not documented) Os state information in case of a software alert.

Originally Posted by Don_Adan

Only a few strange for me, that this is DEFAULT, not OPTIONAL feature, like I heard from this Amiga user.

You can turn that off, so yes, it is optional. You seem to believe that 24K on top if a "loss of a majority of Os users". But that's not the case. It is not a loss nor a problem for a majority, you just want to make it sound so. Actually, it is more a win than a lost as it gets rid of a bad hack, and that makes maintainence simpler and error fixing simpler. That's a win if there are limited development resources.

[Don_Adan]

Originally Posted by Thomas Richter

No, 24K. You cannot use the lowest chip ram anyhow, There are CPU autovectors in it, and some (not documented) Os state information in case of a software alert.



You can turn that off, so yes, it is optional. You seem to believe that 24K on top if a "loss of a majority of Os users". But that's not the case. It is not a loss nor a problem for a majority, you just want to make it sound so. Actually, it is more a win than a lost as it gets rid of a bad hack, and that makes maintainence simpler and error fixing simpler. That's a win if there are limited development resources.

Really 24K?
Especially for you:

https://www.ppa.pl/forum/amiga/46924...-ram/2#m821759

For A600 with 1MB chip, kick 3.2.2 has less about 36kB of memory available to use.
For A500 with 0.5MB chip and 0.5MB slow, kick 3.2.2 has less about 100kB available to use.

Differences between kick 2.0 and kick 1.3 is about 49kB.
Then for A500 kick 3.2.2 wasted/used 100-49=51kB of memory.
About 15kB more than for A600 with same kick 3.2.2

Thanks for infos, that MMU tables can be turned off.
And yes, I know that about 8KB of Amiga chip memory can not be allocated.
But this memory is used by kickstart.
So if kick 3.2 allocated this memory for MMU, then must use other chip memory area.
Then this is still 32KB, from my memory 31KB, because first 1KB is unused (except vectors), if I remember right.

[Tpod]

@ Don_Adan
Why would anyone in their right mind put a 3.2 ROM in an Amiga with only 1MB & no Fast RAM
By the way, no need to blow your Chip RAM playing mod files, just use HippoPlayer. It can load mods into Fast RAM, plus it's been getting plenty of updates lately.

[h0ffman]

Originally Posted by Tpod

@ Don_Adan
Why would anyone in their right mind put a 3.2 ROM in an Amiga with only 1MB & no Fast RAM
By the way, no need to blow your Chip RAM playing mod files, just use HippoPlayer. It can load mods into Fast RAM, plus it's been getting plenty of updates lately.

Fair, but that doesn't help you using ProTracker on a real Amiga does it.

[malko]

Originally Posted by Thomas Richter

[...] Some users request more features, some not.

I am part of the users that request an OS featuring extended footprint only on demand and not by questionable design choices depending on a scenario that may never happen for the vast majority of users.

[koobo]

Originally Posted by h0ffman

Fair, but that doesn't help you using ProTracker on a real Amiga does it.

Offtopic: There is a Protracker clone from 1994 which supports samples in fast ram called MaxTracker (https://ftp.funet.fi/pub/amiga/apps/audio/compose/)

[Thomas Richter]

Originally Posted by malko

I am part of the users that request an OS featuring extended footprint only on demand and not by questionable design choices depending on a scenario that may never happen for the vast majority of users.

The questionable design is that of the patch/hack that makes the lowest 32K available for such programs, and I doubt that it matters for the majority of users whether additional 24K become available or not. For those for which it does, there is a tool. The design choice is quite reasonable, and the implementation is straightforward.

[malko]

Originally Posted by Thomas Richter

The questionable design is that of the patch/hack that makes the lowest 32K available for such programs, and I doubt that it matters for the majority of users whether additional 24K become available or not. For those for which it does, there is a tool. The design choice is quite reasonable, and the implementation is straightforward.

As I already pointed several times, the amount of memory blocked is non important. In the opposite, the selected design choice to 'fix a bug' that is not part of the AmigaOS to start with is definitively questionable.
Therefore, as you like to reuse at infinity the same arguments even if we have put the dots on the i, I will let you walk alone on this Moebius strip like discussion.

[xavlahaye]

It's funny reading this thread helped me solve some problems I had with "emulating" CD32 games on my 1200 with OS 3.2
By softkicking 3.1 I could make Flink run, finally!
I'm not sure but I think the issue was with available chip RAM
Easy enough to do on an accelerated 1200, so I use 3.2 most of the time, 1.3 and 3.1 when necessary

[Don_Adan]

Originally Posted by Tpod

@ Don_Adan
Why would anyone in their right mind put a 3.2 ROM in an Amiga with only 1MB & no Fast RAM
By the way, no need to blow your Chip RAM playing mod files, just use HippoPlayer. It can load mods into Fast RAM, plus it's been getting plenty of updates lately.

Seems, you dont understand what are tests.
Thor talk that ONLY 24KB of chip memory is wasted for kick 3.2.2.
He is WRONG.
Kick 3.2.2 used about 36 kB more chip RAM, when TOTALLY WASTED (allocated and NEVER USED on 68000/68010/68020) is perhaps 31 KB.
For 68080 and some CPU detected as 68040 it will be about 27KB of wasted chip memory.
Rest (about 5 kB) is perhaps used for new kick 3.2.2 features, but can be bug too, like twice allocation or not free allocated memory problem.

Not all Amiga music modules are Protracker mods to be easy enough playable from fast memory.
I prefered exotic modules format.
And about 10-15 years ago EP 1.54 was for me much better than Hippoplayer.
I dont know present time for Hippoplayer.
Maybe Hippoplayer is now better than EP 1.54.

[saimo]

It looks like it needs to be reiterated again...

First and foremost, it is simply a terrible design choice to implement in the OS a feature that is specific for a single application. That's simply wrong in general and even worse in this specific case, where the OS is supposedly being worked on to become better.

Then, the choice is double-terrible because is wastes a scarce resource. In theory, the OSes are supposed to manage the resources wisely to make them available to the user. We all know that, in practice, nowadays we are drowning in bloatware but... that definitely should not happen with AmigaOS! Isn't one of its (few remaining) strenghts being lean?

Finally, the choice is triple-terrible because it favours an application that only few users are interested in, providing a minimal improvement (avoiding a reboot), but impacting all the other users (yes, even those who have FAST RAM).

That said, I'm glad that boemann already reported that the feature will be removed - that was a good decision and the having listened to the feedback is worthy of praise

[boemann]

Originally Posted by saimo

That said, I'm glad that boemann already reported that the feature will be removed - that was a good decision and the having listened to the feedback is worthy of praise

It wasn't as much listening to feedback, as much as to discover/realize what had been done. The words we uttered should not be repeated in public. After having spend countless of hours to minimize our consumption of chip ram and then to find out this.

Someone was asking for a compromize, and while we want to allow some kind of compromize we are not going to implement some elaborate scheme. I see no way to avoid macos emulation having to reboot again

Now this is the last you will hear me talking about this. The matter is closed as far as I see it.

[Gorf]

Originally Posted by boemann

Someone was asking for a compromize, and while we want to allow some kind of compromize we are not going to implement some elaborate scheme. I see no way to avoid macos emulation having to reboot again

fair enough!

[Don_Adan]

Seems that some people still dont understand.
Amiga Mac emulators (Fusion and Shapeshifter) used ONLY 4KB of chip memory started from address 0.
And this is acceptable and can be useful for easy debugging buggy code, when often enough read/write to zero page occured.
Problem is with next 28KB of chip memory, allocated for mmu.library (not for MacOS).
It can be allocated too, but not as DEFAULT, but as OPTION in BootMenu.
Or 2 versions of 3.2.2+ kickstarts can be created.
Without and with allocation.

[Tpod]

Originally Posted by Don_Adan

Seems, you dont understand what are tests.
Thor talk that ONLY 24KB of chip memory is wasted for kick 3.2.2.
He is WRONG.
Kick 3.2.2 used about 36 kB more chip RAM, when TOTALLY WASTED (allocated and NEVER USED on 68000/68010/68020) is perhaps 31 KB.
For 68080 and some CPU detected as 68040 it will be about 27KB of wasted chip memory.
Rest (about 5 kB) is perhaps used for new kick 3.2.2 features, but can be bug too, like twice allocation or not free allocated memory problem.

Not all Amiga music modules are Protracker mods to be easy enough playable from fast memory.
I prefered exotic modules format.
And about 10-15 years ago EP 1.54 was for me much better than Hippoplayer.
I dont know present time for Hippoplayer.
Maybe Hippoplayer is now better than EP 1.54.

Well as a non-coder I don't understand those tests. I would think you would need to test a system with at least 2MB Fast RAM (equal to the minimum total RAM the OS requires) before you could judge how the OS draws on Chip rather than Fast RAM.


For example on booting my A2000 with 1MB Chip & 8MB Fast, with just plain Gray as WBPattern (pattern mode) on a PAL:High Res. 8 colour Screen, I have 945,192 Chip RAM. If I was desperate to save Chip RAM (to launch a game or whatever) I can boot into an NTSC:High Res. 2 colour screen then I have 1,001,320 Chip RAM (& 6,685,552 Fast). I certainly don't feel hard done by in OS3.2 on the Chip RAM front!


Unfortunately some things will always drain Chip RAM but with so many having plenty of Fast RAM nowadays, I would hope that as we go forward developers while try (even more than they used to) to avoid using it.

[Dunny]

You could simply test:

1. An A600 with 1MB Chip, no expansios, no PCMCIA cards, one single internal floppy and a 3.1 ROM booting a blank bootable floppy - no WB. Run Avail from the CLI, check used chipram.

2. Replace the ROM with 3.2.2 and repeat the test. Note any difference in chipram consumption.

All else is negotiable. WB setups consume varying amounts of the RAM types. Expansion hardware with autoconf ditto. You need as bare a system as you can, if you want to measure how much 3.2.2 will consume as a default state.

[FOL]

Originally Posted by xavlahaye

It's funny reading this thread helped me solve some problems I had with "emulating" CD32 games on my 1200 with OS 3.2
By softkicking 3.1 I could make Flink run, finally!
I'm not sure but I think the issue was with available chip RAM
Easy enough to do on an accelerated 1200, so I use 3.2 most of the time, 1.3 and 3.1 when necessary

Hit this problem with Rise Of The Robots. I went another approach as CD was assigning its own buffers. I simply altered CD to use less buffers, freeing up enough chip ram to run, as it required the full 2 MB.