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.