AmigaOS 3.2 and beyond

[TCD]

This is like the worst remake of Groundhog Day.

[No.3]

Could we go back to "AmigaOS 3.2 and beyond" and someone split off all the off-topic stuff ?!

[aros-sg]

Originally Posted by Thomas Richter

The 32K you cannot because the kernel works from it

Comments and code in source code of ShapeShifter's PrepareEmul shows that it only reserves the first 8k.

[Don_Adan]

Originally Posted by aros-sg

Comments and code in source code of ShapeShifter's PrepareEmul shows that it only reserves the first 8k.

And it can be main problem.
ShapeShifter can needs 8KB of zero page.
Fusion can needs 4KB of zero page.
MuMove4K from Thor, perhaps move only 4K of zero page, then is not compatible with ShapeShifter.
Perhaps Fusion is better optimised/patched than ShapeShifter for zero page usage.
Jim Drew often wrote dont mix Fusion and Shapeshifter installs (installed MacOS and PrepareEmul with RsrvMem).

[zipper]

Thomas Richter:

Originally Posted by daxb View Post
Are you sure? ShapeShifter guide says something about the first 8K need to be free.
I am sure. MacOs globals are in the first 32K.

Quote:
Originally Posted by daxb View Post
MuMove4k: The guide isn't clear to me. Does it free/reserve 4K, 8K or another value?
That depends on how you run it. Without arguments, its moving chip/graphics data out of the first 4K. This functionality makes live easier for MuForce and friends as it allows to disable the first page, or allows MuFastZero to remap the first page to fast ram. With the prepareemul command line option, it keeps the first 32K free.

Quote:
Originally Posted by daxb View Post
Here on A1200, Apollo 1240, OS3.1, mmu.library, RemApollo with MAC option the first 16K are reserved. ShowConfig and Scout/XOpa show that chipram starts at $4000 (16K). Looks ok so far. MuScan shows that chipram starts at $1000 (4K) - $1FFFFF. My guessing is that MuScan can't detect the MAC patch by RemApollo. Do you know something about this?
No. The mmulib will map all memory from 0 up to the end of chip mem as non-cachable, regardless where chip mem starts. MuFastZero maps the first page (with ExecBase and the autovectors in them) to fast RAM, should that be necessary.


16K is *not* sufficient for shapeshifter and MacOs.

[Don_Adan]

ShapeShifter author dont know how many memory is necessary? I dont think so.
The easiest thing is SAVE this memory to file from 0 to $8000.
1. Before starting ShapeShifter with PrepareEmul.
2. After using some Mac programs.
And remember one thing ShapeShifter doesnt works with all MacOS systems , and MacOS system MUST BE INSTALLED FROM SCRATCH, not copied from other installs.

[Thomas Richter]

Originally Posted by zipper

MuMove4k: The guide isn't clear to me. Does it free/reserve 4K, 8K or another value?

It depends on the arguments, and the arguments depend on the purpose. Without arguments, it reserves 4K. This is only necessary for 2.x kickstarts, as 3.x kickstarts reserve 4K to begin with (surprise, surprise: As I said, this is not the first time chip memory is reserved for special purposes). With "PrepareEmul" it reserves 32K.


The problem with all that "reserving" business is that you cannot just move structures out of the chip mem once they have been allocated. Some people may have the idea that ColdCapture might do the trick - but, alas, it's not so easy. The issue are here installations with autoconfig memory where first exec is allocated "provisionally" in chip, then expansion configures itself, then the "final" exec is created, and unfortunately, you cannot reserve chip at the point the provisional exec is created. What the PrepareEmul does in this case is a really, really ugly bad hack I need to get rid of, and that hack depends on the precise code sequence of the bootstrap code that needs to be patched. As it is completely unclear whether that code sequence will remain unchanged over kickstart versions (why should it?) this hack needs to go.

[modrobert]

Originally Posted by JimDrew

A reboot is technically required because I install a kicktag and some other things that are required for a real Mac to run. Remember, FUSION is not "an Amiga program".. it is code that gives you a real Mac that just so happens to allow the Amiga to run in the background. It takes precedence over anything and everything and it's *requirements* (like using RsrvMem or RsrvKick, certain MMU setups, etc.) are not optional. There are a SLEW of problems that you will experience if RsrvMem or RsrvKick is not used. This was very evident when the Vampire tried to reserve the lower 4K of memory (which is all that the Mac needs - not 32K).

Doesn't seem to work like an "emulator", more like a custom ROM boot loader, but it's still running in parallel with AmigaOS, hence the name 'FUSION' I presume. Clever approach performance wise, and Mac (68k) uses traps which are pretty much unused on the Amiga.

As pointed out by Don_Adan several times, FUSION only requires 4k of zero page.

[meynaf]

Originally Posted by Thomas Richter

This is only necessary for 2.x kickstarts, as 3.x kickstarts reserve 4K to begin with (surprise, surprise: As I said, this is not the first time chip memory is reserved for special purposes).

Are you sure ? What is it supposed to be reserved for ? Under 3.0 i see expansion.library base located at $a6c, which doesn't look like $1000 was reserved. Also in memory lists chipmem has lower bound at $420.

[Thomas Richter]

This is processor dependent, and it is 4K for 68040 and 68060, and yes, the important application is Enforcer/MuForce, for which this change was made. That still nails you at 1K pages for 68030 and below, which is the "traditional" choice (though probably not even the best).

[Don_Adan]

From my memory kickstart 3.1 dont free first 4K of Amiga chip memory, but it was long time ago. I can remember wrong.
If someone want to check can f.e run Burntime AGA (WHDLoad version):

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

Run slave from CLI with CoreDump parameter.
After pressing quit button, memory dump will be saved to C: directory.
WHDLoad before starting, filled all chip memory with $CCCCCCCC ID then its easy to see (under FileMaster 2.2) what was changed (all writes, illegal too) for chip memory.

[Don_Adan]

Originally Posted by malko

How can you seriously call MoveLow an API ?

Strange results for this program.

For A600 only about 18kB chip memory is returned.
But for A500 about 34kB memory is returned, about 31kB chip memory.

If no tester fails, then for A500 is very useful.


https://www.ppa.pl/forum/amiga/46924...-ram/3#m822037

[Yulquen74]

For my A500+/68000 16KB chip is returned with MoveLow at top of startup-sequence.

[Don_Adan]

Yes, something is wrong with this program or kick 3.2.2.

Here are results for A1200 8MB fast.

https://www.ppa.pl/forum/amiga/46924...-ram/3#m822048

Less chip available if MoveLow was used, but about 200kB more fast ram.

[Thomas Richter]

Originally Posted by Don_Adan

Strange results for this program.

It is more likely that something is off with your measurements. All what this program does is that it instructs the kickstart to fall back to the previous chip ram allocation policy on the reboot. It does not require any hacks like PrepareEmul. There is nothing allocated nor made resident by MoveMemLow.

[Don_Adan]

But this is A500/A600 config from WinUAE only.
Also Yulquen74 tested on real A500+ too.
Of course for standard A500 (0,5MB chip and 0.5MB slow) it was visible previously (which I mentioned) that something is wrong with kick 3.2.2.
For me it looks like some startup resources was allocated twice, once for chip ram and once for slow ram.
And allocated for chip memory resources are not free, when are later allocated/moved to slow memory.
It can be any old kickstart bug.

Same for A1200, something was allocated in fast ram and not free later.
Of course, why no more chip ram for A1200, looks like program bug.

[Thomas Richter]

There is nothing allocated in fast. Actually, neither is anything allocated in chip ram as such. It is just the start address of the chip memory pool that changes. Nothing else is modified or has been modified in this regard.