ok,

Had 512mb on this powerbook a1139 with morph os 3.1.
I took out the 512mb stick and I put in two 1GB sticks and Morph reports 1537mb of ram.

Where did my other 512mb go?

Sometimes a pair of ram sticks must match?

Doesn't MOS only use 1.5GB of RAM? If so that explains what you are seeing. Mac OS 9 can only use 1.5GB of RAM regardless how much the Mac G4 has installed.

Yep, MorphOS uses 1.5GB in max, so that's normal and no danger to use it that way.

Thanks.
I thought that was what the problem was.
Too bad about the 1.5gb limit.
I will take as much ram as I can get.
Amiga is big on ramdisk usage.

You cannot use more memory with any Amiga like system.

MorphOS is 32Bit, so it could handle 4GB, but old software is misusing the upper bit of address pointers, so 2GB is max. Then address space is required for accessing pci cards (onboard stuff, too) and some other stuff.

On original Amiga thats the custom chipset, 1MB for the kickstart ROM and of course Zorro cards eat space. The A2000 for example can only deal with 16 MB of address space. After subtracting all the non accessable memory you end up with 2MB Chipmem, 8MB Fastmem and 1.8 MB Rangermem. And when using a graphics or IO card the 8MB fast memory is shrinking, because you need that area for the gfx/io memory.

Thats all. So it is not a freely set limitation, but a limit composed due hardware and compatibly, which is effecting all amiga like systems (beside AROS).

This is also the reason why virtual memory is bullshit on most amiga like NG systems. You cannot have more virtual than possible physical memory, so if you reach the limit by inserting RAM bars, you cannot multiply its size by software. You can only fill up e.g. 512MB, when only one 1GB bar is inserted, but this makes no sense speed wise.

The only way around this is drop entire backward compatibliy and implement all limiting stuff from scratch.

Since it is not useful to break compatibly more than once, it should be noted that this step would also include 64bit support, multi core and architecture change (ARM/G5/x86,...)

Geit

> You cannot use more memory with any Amiga like system. [...] it is
> not a freely set limitation, but a limit composed due hardware and
> compatibly, which is effecting all amiga like systems (beside AROS).

To explain the difference to other readers here, this limitation is affecting only systems that are binary compatible with AmigaOS. That's why AROS is not affected, as it's only source compatible.

> The only way around this is drop entire backward compatibliy and
> implement all limiting stuff from scratch. [...] this step would also
> include [...] architecture change ([...]G5[...])

MorphOS running in 32-bit mode of G5 will not drop AmigaOS binary compatibility:

"When it comes to user mode differences, the G5 is lacking CPU instructions which are widely used throughout MorphOS' 68k emulators. Luckily Piru did some changes there and the emulators should work fine on the G5 now"
http://morphos.pl/423

Thanks for removing information of my post in your quote to make it look wrong. There clearly was 64 bit support mentioned, which implies real G5 support, when I say platform change and compatibly break.

Somehow your brain seems to hate, not being the last posting person, so you make up stupid post just to say something, like Mercedes drivers always overtake for no reason to be first on next traffic light.

In the past you posted tons of useless crap, so the interested users cannot even find the important information anymore.

Geit

> Thanks for removing information of my post in your quote to make it
> look wrong. There clearly was 64 bit support mentioned

Sorry for misreading. I thought that the content of the bracket only referred to the "architecture change". Now that you clarified that it refers to the two other characteristics as well, can we conclude that 32-bit ARM wouldn't be an option for MorphOS while upcoming ARM64 would?

> you make up stupid post just to say something [...]. In the past you posted tons of useless crap

I'm okay with your opinion about my posts.

> so the interested users cannot even find the important information anymore.

I don't think that's true. In fact, I believe the opposite to be true as I often find (and link to) the important information for the interested users who are searching for them.

Andreas, can I borrow your Mercedes?

geit,
Quote:

Not completely true.
There is ASMP, multiple boxes, and a few other ways around this (including allowing only native apps to address higher memory).
This is no different then supporting higher memory with the old 640K DOS limit.

> Andreas, can I borrow your Mercedes?

Yes, but only in exchange for your hot-air balloon.

>> MorphOS is 32Bit, so it could handle 4GB, but old software is misusing the upper bit
>> of address pointers, so 2GB is max. Then address space is required for accessing
>> pci cards (onboard stuff, too) and some other stuff. [...] The only way around this
>> is drop entire backward compatibliy and implement all limiting stuff from scratch.

> Not completely true. There is ASMP, multiple boxes, and a few other ways
> around this (including allowing only native apps to address higher memory).

I don't see how ASMP could be a means to lift the current 31-bit restriction. And multiple boxes would mean to keep the current ABox with its 31-bit limitation for old software and to develop a new 32-bit box for which you'd have to "drop entire backward compatibliy and implement all limiting stuff from scratch", just as geit said.

Andreas_Wolf,
Quote:

Good point, but since I would expect a dual box system to have a common graphic shell and the ability to exchange threads, I don't see this as dropping backward compatibility.
More like limiting backward compatibility.