in case you are interested to test new fpga accelerators for a600/a500

[ChaosLord]

I suspect you'll find that in practise it will, but time will tell eh.
 
 Zorro 3 is flakey as hell, I don't envy anyone trying to make something compatible with everything (unless that too is not a priority).

What exactly does the MMU do to the Zorro bus?

[ChaosLord]

All the MMU could possibly do to the Zorro bus is 1 or more of the following:
1. Mark memory ranges as copyback cacheable.
2. Mark memory ranges as write-through cacheable.
3. Mark memory ranges as noncacheable.
4. Mark memory ranges as write-protected.

I don't know if kickstart requires an MMU to be present on Zorro III or not.  It is certainly possible.  Due to design or just by accident.

[psxphill]

What exactly does the MMU do to the Zorro bus?

Essentially RAM is marked as cacheable, IO is marked as non cacheable.
 
 Zorro has a cache inhibit line, but if you've already started a cache line burst then it's a bit late. You can probably design around it and live with any performance/compatibility issues.
 
 Given some zorro 3 cards don't like 060 accelerators or even any gvp accelerators, I wouldn't say it was a particularly good idea to come up with too much deviation from existing access methods.

[guest11527]

All the MMU could possibly do to the Zorro bus is 1 or more of the following:
1. Mark memory ranges as copyback cacheable.
2. Mark memory ranges as write-through cacheable.
3. Mark memory ranges as noncacheable.
4. Mark memory ranges as write-protected.

I don't know if kickstart requires an MMU to be present on Zorro III or not.  It is certainly possible.  Due to design or just by accident.

Well, Kickstart itself does not touch the MMU, only the transparent translation registers. It marks the entire Z-II space including the ROM as non-cachable, and the entire Z-III/32-bit expansion area as cacheable, "and hopes the best", i.e. that the board vendor took all precautions to make this a workable configuration. In general, you are right that this will likely go wrong if I/O ends up in the Zorro-III space, or if certain burst/caching configurations are not supported by the hardware, let it be by CPU bugs or board designs, but that's not really the fault of the Zorro bus. It is rather "by the lack of proper support of the CPU".  Let it be as it is, yes, some I/O configurations that involve Zorro-III likely require the MMU to be enabled. So yes, I believe one can say "Zorro-III requires an MMU", somehow. A strange way of putting it, though. It's really the CPU that does.

[ChaosLord]

Does the Phoenix core you have been working with, have all 4 TTR registers?
Are they compatible with 68060?

I think PsxPhill would be perfectly happy as long as the mini-MMU that is contained in ALL 68060 chips was included in the Phoenix/Apollo/68070/WhateverItIsCalled.

[guest11527]

Does the Phoenix core you have been working with, have all 4 TTR registers?
Are they compatible with 68060?

No, the mini version does not have TTx registers at all. It has all the cachable areas hard-coded in the core AFAIK, so you cannot change anything at this time.

[psxphill]

I think PsxPhill would be perfectly happy as long as the mini-MMU that is contained in ALL 68060 chips was included in the Phoenix/Apollo/68070/WhateverItIsCalled.

No, I want a full 68060 MMU as well. It can also support larger page sizes and I wouldn't be unhappy. I think a mips style mmu where you do table walking in code would be horrible, no other major cpu designer ever thought it was a good idea either.

[guest11527]

No, I want a full 68060 MMU as well. It can also support larger page sizes and I wouldn't be unhappy.

Actually, now I'm confused about your wishes, because if you want to be *fully* compatible, then 4K and 8K pages would be sufficient because that is all the 68060 does support. In fact, the only page size that is currently used is 4K, and this is because (only) the lowest 4K remain unused by the Os. Thus, if you want to use something like MuFastZero, 4K is the only usable page size anyhow.  

I think a mips style mmu where you do table walking in code would be horrible, no other major cpu designer ever thought it was a good idea either.

That is not so much different for PPC, i.e. it has a fixed size ATC (address translation cache) and if a page descriptor does not fit in there, you need to remove another descriptor. I.e. it is necessary that the Os maintains the page descrptors. That's not specifically horrid, it means that the CPU design can be made much simpler. Given that you should actually never touch the MMU directly, I don't see why this is a problem.

[psxphill]

Actually, now I'm confused about your wishes, because if you want to be *fully* compatible, then 4K and 8K pages would be sufficient because that is all the 68060 does support.

Why are you confused? I'm being pragmatic. 4k & 8k pages gives compatibility, larger pages gives you more functionality. I may never use the larger pages but if they can be added without harming compatibility then I'm not going to argue against them. Obviously if an extension turns out to cause compatibility issues then it should be reworked, that is the commitment that is missing.

Given that you should actually never touch the MMU directly, I don't see why this is a problem.

Why should I never touch the MMU directly? That sounds elitist. I definitely wouldn't help fund a project with that kind of ideal

[kolla]

So far, any touching of an MMU is higly hypothetical anyways, lol

[guest11527]

Why are you confused? I'm being pragmatic. 4k & 8k pages gives compatibility, larger pages gives you more functionality.

Which type of functionality do you get with larger pages? They are only larger pages, after all. With typical memory sizes as found in the Amiga, 4K is actually quite good. For some debugging features actually even too large.  

Why should I never touch the MMU directly?

Why would you? If you do, you program is more or less "bound" to the hardware it runs on. This is quite a bad idea. The MMU is a "system level" tool, and the system provides you with interfaces to abstract from the hardware. Otherwise, you'll have to write your program (currently) at least four times, and run into a lot of compatibilty issues - given that the Os also requires the MMU for DMA or debugging. Hence, if there is an abstraction level to access a feature, use it.

[kolla]

But AmigaOS has no such abstraction, all tools and utilities that support MMU are third party AFAIK. And frankly I personally don't care much about MMU in context of AmigaOS, I just want it for Linux and *BSD. Only exception is paging to disk, which is very useful and almost a must when doing animation work within the limits of 128MB RAM.

[NorthWay]

IIRC it is not possible to boot any Amiga with a 68060 and any published Kickstart version only.

You need a bootrom at $F00000 or make your own modified Kickstart to not guru through the startup. MY Cyberstorm came with such a bootrom, and I expect all other solutions did too.
The 68060 simply came too late for C= to officially support it.

[kolla]

And this is different from 68040? There are people upgrading their 3640 cards with 68060 CPUs, wonder how that works out in that case, maybe with modified kickstart too.

Edit: so I heard with someone doing such upgrades, and except for the usual hoopla to load 68060.library, there are no changes done, the 3640 with adapter and 68060 boots up with unmodified kickstart. But maybe 68040 has same requirements, and bootrom is already present on 3640?

[NorthWay]

But maybe 68040 has same requirements, and bootrom is already present on 3640?

No, the 68040 is handled by Kickstart.

The missing bit is (I think - been a long time) to clear the "DFP—Disable Floating-Point Unit" bit in the PCR register and execute an FNOP before that.
IIRC it is the FPU tests that go wrong if this isn't done.
The 68040 does not have the PCR register.
If it simply works on a non-FPU 68060 I don't know.

[guest11527]

IIRC it is not possible to boot any Amiga with a 68060 and any published Kickstart version only.

Well, yes and no. You cannot reliably boot the system with the 68060 because the FPU stack frame is different, not because the MMU is diffferent. The little bit of MMU exec uses for its initialization is actually identical between the 040 and 060. The system would (probably) run up to the point where someone tries to use the FPU (and would then crash), but that I do not remember. The boot ROM that disables the FPU until the 68060.library hooks in is currently the savest alternative.