New project for the benefit of all classic computing!

[Karlos]

2GB of RAM would be the absolute safe limit for OS3.x, simply due to the signed pointer / size arithmetic that goes on here and there as mentioned by matthey.

Of course, the only reason to include such a large amount would be because you can and it's probably not that expensive to do so. There's not a lot of 68K software that would be able to make a serious dent in it. Sure you might be able to get away with much larger images in say ImageFX, but performing any realistic image processing on images that large on even a fast 060 isn't going to be much fun.

If you are going to integrate any sort of RTG, don't listen to the 4MB suggestion. Give it 256MB or so, so that it can handle modern resolutions and it's not likely to page BitMaps. It would also justify all that RAM, if you went for some sort of unified solution.

[Karlos]

If we had a 1GB RAM card we could run
Web Browser
Image FX
7zip
a game

BAM!
?Out of Memory Error

Its easy to use a smeasly 1GB of RAM.

Don't get me wrong, more RAM is always good and as long as it's not a factor in the price of hardware, the more the merrier. However...

There are a million things we can do with 3GB of RAM.

You'd need to do more than write an additional allocator. The moment anything allocated above the 2GB boundary, you can't guarantee it won't end up being passed by reference off to something that will assume it can't have been and do something stupid thanks to signed 32-bit arithmetic.

[Karlos]

What you are saying is completely true.

I am just not convinced that the potential bug you describe is anything more than an extremely rare phenomenon.

Millions of people have 32-bit computers and I have never heard of any of them having problems when they added the 3rd GB of ram.

Have you ever had a 32-bit computer start malfunctioning when adding the 3rd GB of RAM?

It's not a bug specific to 32-bit systems per se, it's a bug resulting from the inconsistent interpretation of 32-bit address values (when performing arithmetic on them )within different parts of AmigaOS and software that runs on it. Other operating systems may not be affected.

[Karlos]

No.  The hardware limit of an address register is 4GB.  That is because each bank has 4GB in it.

Or another way to say it is:
There is only 4GB of directly addressable RAM but 32GB of indirectly addressable RAM.  You remember bank switching from the C64 and Intel days, right?


Who says there are only 32 address lines?

You are forgetting about the 3 lines that select what bank you are in.

Motorola thought waaaaaaaaaaaaaay ahead.

Wait, are you referring to FC0-FC2 function code pinouts? They aren't for "banks" in any conventional sense, they are used to indicate to any external hardware that cares (eg external MMU) what class of memory access is being made.

From the 68K documentation:

0 0 0 (Undefined, Reserved) *
0 0 1 User Data Space
0 1 0 User Program Space
0 1 1 (Undefined, Reserved) *
1 0 0 (Undefined, Reserved) *
1 0 1 Supervisor Data Space
1 1 0 Supervisor Program Space
1 1 1 CPU Space
* Address space 3 is reserved for user definition

I don't think you can arbitrarily hijack them for your own nefarious bank select *especially* on processors where the MMU is already on board.

[Karlos]

But what is the purpose of the pins on 68000.  u r saying they are like for an external MMU to write protect the CODE bank and that would be about it.

Well, I believe the 68551 can be interfaced to the 68000 (but requires software support, it's designed for 020*). I'm not sure if it actually uses these lines, but it would seem obvious that the CPU telling the outside world what kind of bus access it is attempting would make a lot of sense for any external hardware trying to map the address to some particular physical memory ranges. But I imagine there are all sorts of other external peripheral devices that might care too.

I say if the pins exist on an 060 then they can be wired up on the ram card as extra address lines.  And the MMU could still do its thing.  I don't see any reason why one must conflict with the other.

I really don't think it's that simple. Consider the implications. First of all, the internal MMU might use those bits to determine which address translation tables to look up. Even if it didn't, depending on which side of the MMU the CPU's caches are (and it's different between 020/030 and 040/060 IIRC), when flushing a cache line, it would probably just go to whatever bank was last asserted by fiddling with the FC bits via the (privileged) moves instruction. Same with reads. I'm pretty sure that isn't desirable and the only alternative would be to run with caches disabled.

*Note that the FC0-FC2 pins are present on the 020 too, of course.

[Karlos]

We will never know if it works because they took the pins off the 68060.  Why would they put pins of awesomeness on 68000 and chop them off on 68060?

Or did they just rename them?

I suspect once they added internal MMUs, their intended use was superceeded.