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

[psxphill]

May I ask which software you currently use that goes down to the MMU directly?

I don't have a 68060 currently, assume that when I do then I want to be able to run all software that runs on a 68060 and don't want to have to run new versions. I hoped that this would meet my needs, but it appears it won't.

I want the confidence that if I submit a bug report that it won't get closed as a won't fix because the software isn't popular enough & right now I don't have that confidence because the stated goal isn't to run all software.

[psxphill]

No, that's just a regular Kickstart, or - in case of the RAM-based kickstart - a patched version thereof that runs from a different start address.

No, zorro 3 requires an mmu to work properly when Kickstart is in rom too. But you know that.
Exec uses the transparent translation registers, which are arguably part of the mmu even though they exist on parts that don't have an mmu (enabled at least). Then 68040.library/SetPatch/whatever takes over to make it fast (as long as you have an mmu).

http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0161.html

Quite what will happen if the mmu isn't compatible but you use the standard 68040.library is anyones guess. What happened when 68060's turned up and people only had commodores 68040.library?

The a600 is the simplest Amiga, the only expansions possible are on the other side of gayle & IIRC there is no fast ram dma. Dealing with zorro 2/3 is going to be much more complex.

[psxphill]

Excuse me, but: No. Zorro III is just a bus technology. It does not require an MMU.

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), especially if you're going to deviate from all the established methods.

[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.

[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.

[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

[psxphill]

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.

The only rational argument I heard for coming up with a different MMU was that the page size was too small. It was a concession, but I don't particularly care. If 4k is fine then it's another argument for keeping the MMU exactly the same.

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.

So there is only one operating system allowed and you get to do the MMU code for it? I don't like that kind of lock in, when a compatible MMU would allow you to run BSD or Linux. You might not want to do it, but your arguments seem more about you getting to provide the MMU support.

[psxphill]

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.

The only rational argument I heard for coming up with a different MMU was that the page size was too small. It was a concession, but I don't particularly care. If 4k is fine then it's another argument for keeping the MMU exactly the same.

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.

So there is only one operating system allowed and you get to do the MMU code for it? I don't like that kind of lock in. "bug closed, won't fix, not running amigaos".

Honestly, if I want to run Linux (and I am running it right now) there are plenty better alternatives on much faster hardware.

This is sounding more and more like a dictatorship. I get the impression that you want an incompatible MMU solution so everyone has to run MMULib.

[psxphill]

The current MMU design of the 68K cores is pretty much "high level" and calls for microcode, but that's exactly what FPGAs are not designed for, so I understand Gunnar's hesitation to exactly re-implement that.

I'd like to see a technical explanation of why you can emulate a CPU but not an MMU with an FPGA. AFAIK his hesitance to adding an MMU was the latency. Using a MIPS (and apparently PPC) style MMU is not going to do much for latency when you run out of registers. But the exact same cache could be done using an MMU that is compatible and the slow path would still be faster than using the CPU.

[psxphill]

I'd rather disable the FPGA expansion in first place, and run the software by the native CPU. I don't need an FPGA to do that.

Only on an a500/a600/a1000/a2000. Anything else and you don't have a 68000, some of them will only have the fpga and to use the original cpu would require you to swap cards.

[psxphill]

Kind of silly to expect an FPGA accelerator card to give your A1200, A3000 or A4000 compatibility with A500 - go buy a minimig already.

It's silly to think that an FPGA can't be used to run a 68000 core.
 
 A minimig doesn't give you the real Amiga keyboard, real Amiga floppy drive etc.
 
 Your suggestion is silly.

[psxphill]

It can, but why? New 68Ks can be bought for cents, so if you really want a 68K only, why not just get one?

I didn't say I wanted a 68000 only. A 68000 on it's own doesn't really help, how do you suggest fitting it into an A4000 that also has an FPGA card in?

Well, good luck doing much usefull with a 68000 core on any of A1200, A3000 or A4000 - they were buildt for other CPUs than 68000, I would be surprized if they manage to boot into a useful state with a 68000.

It would boot fine. I ran kickstart 3.0 from an a1200 on an a500 back in the day. Plus it would be trivial to load a different kickstart anyway. If you think the motherboard would get upset because the FPGA is emulating a 68000 rather than an 030/040/060, then how do you think it will know??

[psxphill]

I would not suggest fitting that at all.

You quite plainly did, or did you think that buying a 68000 and placing it next to a A4000 would magically empower it with the ability to run unmodified 68000 code?

 The only other option I can come up with is that you're just randomly saying crazy things hoping to "win" an argument, but I hope that is not the case.
 

The A4000 is by that definition not compatible in first place because it does not have an 68K in it.

One way or another, I don't quite get your demands.

I think you're trying too hard not to, but I'll play along.

If you have an fpga in your a4000 then it could easily have a 68000 core loaded into it that would run at 7mhz, it would be useful because of what you said. "The A4000 is by that definition not compatible in first place because it does not have an 68K in it. ", what I'm suggesting would make it more compatible for booting old disks than soft kicking and disabling caches.

[psxphill]

When is the last time in your memory that you had one device that "did everything"?

I'm not talking about doing everything, I'm talking about specific things which it should be capable of. It's field programmable, why wouldn't you be able to load a different cpu core into it? If you're saying that it's going to be locked down so only gunnars core can be used then there is no way I'd buy it.
 

Gunnar has also said, 512 bazillion times that 68070/Apollo would be 100% compatible.

The last postings I saw from gunnar here about the FPU & MMU doesn't suggest that is the case. But I guess it depends what you're claiming it's going to be 100% compatible with. It appears to be a mix of instructions and functionality from various 680x0 cpu cores, with his own additions and changes. It's likely the 100% will get downrated, especially if people start actively looking for ways to make software work on real hardware and not Apollo.

[psxphill]

So because kickstart 3.0 works on an A500, a 68000 will work in an A1200? Brilliant logic.

It's the only problem you'd face, not insurmountable either as with an fpga you can jam in another rom and ignore the one on the motherboard.
 
 Assuming it won't work because of some magic that the a1200 will reject a cpu core that is only running 68000 instructions is insane.
 
 You're obviously trolling.