AmigaOS 3.2 and beyond

[saimo]

Originally Posted by boemann

It wasn't as much listening to feedback, as much as to discover/realize what had been done.

That's still a good attitude

The words we uttered should not be repeated in public.

I'm not sure what you're referring to here - but that's OK, it doesn't matter.

After having spend countless of hours to minimize our consumption of chip ram and then to find out this.

I'm happy to hear efforts have been made to minimize the consumption of CHIP RAM.

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

I find this a correct decision, both technically and because it avoids spending time that is wiser to dedicate to something more useful.

[Dunny]

Originally Posted by saimo

I'm not sure what you're referring to here - but that's OK, it doesn't matter.

I suspect that when they discovered what the OS was doing - eating up chipram - then the air turned blue with expletives and cursing.

[Don_Adan]

Because I dont want to be Thor was unhappy.
Then maybe for Amigas with MMU, he can use/have (4 bytes long) access to 32KB fast ram memory area via jsr/jmp -$xx(A7) ?
Even it can be 2 memory areas, one for SP and one for USP, of course perhaps a few limited, but maybe useful for something.

[Tpod]

Originally Posted by 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.

Thanks for mentioning AVAIL, I booted with no startup sequence entered AVAIL which gives me: In-Use Chip 52168, Fast 225832 Total 278000 (Available Chip 980024, Fast 8162776). Obviously if I detached things I would have more RAM. My main point was to see how much Chip rather than just total RAM the OS uses you need to have a fair amount of Fast RAM (in my simplistic estimate 2MB+ as that's the total RAM the OS requires). This will give you more real world figures (of how intelligently the OS draws from Fast where possible) especially if you check after Workbench has loaded.

If developers produce games that are so tight on Chip RAM that there is a fair chance you can't run them from Workbench (so this 24k may even matter), then their going down the same frustrating root as the developers of Capital Punishment!

I know I'm pretty ignorant on this stuff but doing any memory tests on Amigas with only 50% of the minimum memory requirements of the OS (even if this is pre-boot) & no Fast RAM just seems odd.

[malko]

Originally Posted by Tpod

[...] If developers produce games that are so tight on Chip RAM that there is a fair chance you can't run them from Workbench (so this 24k may even matter) [...]

In a nutshell : "Producing" a 2 bitplanes (4 colours) tool for Workbench or a game with 4 bitplanes (16 colours), 5 bitplanes (32 colours) or even 6 bitplanes are different things as the memory impact will greatly differ. Given that the custom chips can only access the chip ram (thus the name), the math is quickly done and loosing some KBs, even on a 2MB chip ram system, can be enormous.

[modrobert]

My Amiga 1200 with original 3.1 mask ROMs.

AMIGA ROM Operating System and Libraries
Copyright © 1985-1993 Commodore-Amiga, Inc.
All Rights Reserved.
1> avail
Type  Available    In-Use   Maximum   Largest
chip    2027992     68136   2096128   2027784
fast    8238016    150592   8388608   8237760
total  10266008    218728  10484736   8237760

Booted without Startup-Sequence. What are the A1200 chip RAM numbers for 3.2.2?

[daxb]

My Amiga 1200 with original 3.1 mask ROMs. Booted without Startup-Sequence:

> avail
chip In-Use: 92480
fast in-Use: 681824

Boot to desktop (DOpus5 Magellan II, DBLPal 4Bit):

> avail
chip In-Use: 278904
fast in-Use: 10056560

[Swe_Kryten2x4b]

Originally Posted by modrobert

Booted without Startup-Sequence. What are the A1200 chip RAM numbers for 3.2.2?

A1200, kick 3.2.2.1. Also no s-s.

Type  Available    In-Use   Maximum   Largest

chip    2007088     73680   2080768   2007088

fast  130603368   2041496 132644864 130075488

total 132610456   2115176 134725632 130075488

[Don_Adan]

When support for HiMem ($80000000-$FFFFFFFF) will be added to Amiga OS 3.4.
Then last 32KB can be reserved for MMU usage in kickstart 3.4.
And Thor can used jmp/jsr -$xx.w
Perhaps even without existed memory, for MMU its possible to remap this area now.
But Im not MMU expert, and maybe it will be too slow to be useable.

[CCRider]

Originally Posted by Tpod

If developers produce games that are so tight on Chip RAM that there is a fair chance you can't run them from Workbench (so this 24k may even matter), then their going down the same frustrating root as the developers of Capital Punishment!

I'd say the most frustrated ones were Capital Punishment's players...

...let alone buyers.

[Thomas Richter]

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.

You don't listen. That's the problem. First, the amount of lower chip RAM reserved increased, to avoid bad hacks and to have a more robust system. That's one thing. But there are other things that the Os in total apparently also needs a bit more chip ram for itself. That's neither a surprise. A new version implementing new features will take more RAM.



Every additional floppy you connect to the machine will take more RAM (or "wastes it"). Setting the default screen depth to a different size will take more RAM (or "wastes it").


The graphics cliprect cache takes probably more RAM as soon as windows are moved or resized. That RAM is relesead on an AVAIL FLUSH, but it also keeps the overall RAM fragmentation low.

Originally Posted by Don_Adan

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.

Hardly. It's not that they aren't bugs, but not such bugs.

Originally Posted by Don_Adan

I prefered exotic modules format.

And I prefer a robust Os that is easy to develop from. You don't get that with hacks necessary.

[Thomas Richter]

Originally Posted by Don_Adan

When support for HiMem ($80000000-$FFFFFFFF) will be added to Amiga OS 3.4.

This address space area you cannot savely use for RAM. First of all, by design of some Os structures like KickTags and AllocEntry() which use bit 31 as a flag, second of all because there are already expansions that use this area for its own purpose, such as the Grex reserving it for PCI address space.

Originally Posted by Don_Adan

Then last 32KB can be reserved for MMU usage in kickstart 3.4.

They are already reserved for that, essentially CyberPatcher, OxyPatcher and MuRedox mirror RAM there, but this is not the issue with the lowest 32K, it is not repurposed for anything like that. The reason is that you want to provide users the freedom to use also larger page sizes on processors like the 68030, and *there* you need 32K. As a second reason beyond emulation and MacOs globals.

[Thomas Richter]

Originally Posted by boemann

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

I don't think it is, no. It is a more general discussion of where the Os should go. Make it robust and maintainable, or carrying old burden around, or worse, creating new burden on top.



There are plenty of decisions I'm not quite happy about, and there are many open ends that should have higher priority than creating a fancy GUI or boopsifying everything - or at least not until one of the major design issues with boopsis had been fixed, namely that they block up the input.device and thus make the system less reactive. Essentially a boopsi layout turns the Os into a single-tasking system where everything is done in the input.device task.

[modrobert]

@daxb
@Swe_Kryten2x4b

Thanks for the info.

Originally Posted by Thomas Richter

Make it robust and maintainable, or carrying old burden around, or worse, creating new burden on top.

I know how hard it can be to make systems robust and maintainable, and many times it's a thankless job because it's mainly happening in the backend. Still, the challenge makes it really interesting.

Besides boopsi, can you elaborate on other parts of the OS which needs attention in this regard?

[Thomas Richter]

Plenty. If you look into the RKRM DOS, it goes into quite some detail where defects are, and (partially) how to work around them, and that is only the dos.library and the system handlers and file systems. Just to name some: Assign and the assign functions have race conditions, the way how the assign wedge is working is that it is a "second class citizen" mirroring some os structures, System() from file (instead of a string) cannot be run synchronously, some Os functions do not set return codes... There are really plenty of issues left in the dos.library alone.

Then we have graphics, which is an entire mess of its own, sure there is P96 all the bitmap abstractions need to go into the system and not into a third party product, just to name another big construction side.

Then we have DefIcons, which is an entirely opaque and non-extensible system with a database structure that looks fine on paper, but it is too rigid to be easily maintainable.

Then we have the big junk pile called "PCI" I'm currently working on just to get a well integrated system, the entire junk pile of getting a straight documentation (not that I haven't worked towards it).

Then we have the junk pile of "internationalization" as currently AmigaOs is fixed to ISO-Latin-1 and it is utterly unclear (at least to me) how to address this. The ad-hoc solutions of using unused code points in ISO-latin is a very bad one, for reasons also explained in the RKRM-Dos.

There is really plenty of work left that is probably more important than eye-candy and boopsis.

[modrobert]

Originally Posted by Thomas Richter

Plenty. If you look into the RKRM DOS, it goes into quite some detail where defects are, and (partially) how to work around them, and that is only the dos.library and the system handlers and file systems. Just to name some: Assign and the assign functions have race conditions, the way how the assign wedge is working is that it is a "second class citizen" mirroring some os structures, System() from file (instead of a string) cannot be run synchronously, some Os functions do not set return codes... There are really plenty of issues left in the dos.library alone.

Then we have graphics, which is an entire mess of its own, sure there is P96 all the bitmap abstractions need to go into the system and not into a third party product, just to name another big construction side.

Then we have DefIcons, which is an entirely opaque and non-extensible system with a database structure that looks fine on paper, but it is too rigid to be easily maintainable.

Then we have the big junk pile called "PCI" I'm currently working on just to get a well integrated system, the entire junk pile of getting a straight documentation (not that I haven't worked towards it).

Then we have the junk pile of "internationalization" as currently AmigaOs is fixed to ISO-Latin-1 and it is utterly unclear (at least to me) how to address this. The ad-hoc solutions of using unused code points in ISO-latin is a very bad one, for reasons also explained in the RKRM-Dos.

There is really plenty of work left that is probably more important than eye-candy and boopsis.

Interesting, thanks for sharing.

With "RKRM DOS", I assume you mean this one?
https://github.com/thorfdbg/rkrm-dos

[Don_Adan]

Originally Posted by thomas richter

this address space area you cannot savely use for ram. First of all, by design of some os structures like kicktags and allocentry() which use bit 31 as a flag, second of all because there are already expansions that use this area for its own purpose, such as the grex reserving it for pci address space.

1. Of course CAN BE USED, for new kickstart 3.4 and new programs as streamed/data memory.
Two LVO's can be added to exec.library: AllocHiMem and FreeHiMem.

2. This is not problem, if something reserved/used already some space from HiMem area.
It will NON AUTOCONFIGURABLE MEMORY.
Perhaps you know that exist WB program called "AddMem"?
For HiMem program called "AddHiMem" can be created.
And Amiga/PiStorm user can decide if he want to add HiMem memory to AmigaOS system in startup-sequence.

they are already reserved for that, essentially cyberpatcher, oxypatcher and muredox mirror ram there, but this is not the issue with the lowest 32k, it is not repurposed for anything like that. The reason is that you want to provide users the freedom to use also larger page sizes on processors like the 68030, and *there* you need 32k. As a second reason beyond emulation and macos globals.

You know that absolute data/code can be relocated (without MMU) to other location?
If not, here is my old example:


https://whdload.de/games/LeaderBoardArcadia.html

And NO, Amigas with 68030 dont need extra 32 KB RAM from zero page address (chip area).
If you need 32 KB RAM use Fast Memory. Be smart.
For patching 6 or longer bytes commands you dont need zero page, you can patch these commands in Fast Memory.
Simple split code on 4 bytes patching and 6+ bytes patching.

[Don_Adan]

Originally Posted by Thomas Richter

You don't listen. That's the problem. First, the amount of lower chip RAM reserved increased, to avoid bad hacks and to have a more robust system. That's one thing. But there are other things that the Os in total apparently also needs a bit more chip ram for itself. That's neither a surprise. A new version implementing new features will take more RAM.



Every additional floppy you connect to the machine will take more RAM (or "wastes it"). Setting the default screen depth to a different size will take more RAM (or "wastes it").


The graphics cliprect cache takes probably more RAM as soon as windows are moved or resized. That RAM is relesead on an AVAIL FLUSH, but it also keeps the overall RAM fragmentation low.




Hardly. It's not that they aren't bugs, but not such bugs.




And I prefer a robust Os that is easy to develop from. You don't get that with hacks necessary.

What? Reserving 32 KB of zero page area avoid bad hacks for 68000/68020 users?
Only give much more free space for bad hacks and viruses.

About using memory kick 3.2.2 perhaps has bigger stack as default, then extra 4KB are perhaps used.
But available memory for Amiga 500 with 0.5MB chip and 0.5MB slow, is not good for me.
Looks like double stack allocation was used.

[Thomas Richter]

Originally Posted by Don_Adan

1. Of course CAN BE USED, for new kickstart 3.4 and new programs as streamed/data memory.
Two LVO's can be added to exec.library: AllocHiMem and FreeHiMem.

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.

Originally Posted by Don_Adan

And NO, Amigas with 68030 dont need extra 32 KB RAM from zero page address (chip area).

That depends on the configuration.

Originally Posted by Don_Adan

Simple split code on 4 bytes patching and 6+ bytes patching.

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.

[Thomas Richter]

Originally Posted by Don_Adan

What? Reserving 32 KB of zero page area avoid bad hacks for 68000/68020 users?

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