A2080 i.e. Vampire 500 V2 on an Amiga 2000

[psxphill]

The second problem is the cache granularity of 16 bytes per entry. The 68040 cannot see modifications of RAM in Zorro space only, and a dirty cache line is always written back completely, regardless of which individual entry is dirty. That is at least the source of the DMA problem and (one) source of the need for CachePreDMA/CachePostDMA().

That again can be solved by deviating from the 040/060 and having byte granularity in the write cache. My guess is that Gunnar can't see what we're making a fuss over. However I'd rather see the 68060 replicated warts and all, at least as a fallback option.

[wawrzon]

My guess is that Gunnar can't see what we're making a fuss over.

likely. but the fuss you are making is wasted with the uninvolved. get touch with the team and contribute if you think its worth. however if the problem doesnt show with non dma systems as a600 then it can be ignored for the time being. when vampire becomes available for zorro3 systems and problems appear the core can be adjusted.

However I'd rather see the 68060 replicated warts and all, at least as a fallback option.

you keep telling this. but this is a different construction i fear. you wont make it hapen simply insisting. as you may recall the team delivered most if not all features demanded on forums, such as movep (?) or bitfields in hardware, but they will do this on teir own schedule, i fear.

[psxphill]

likely. but the fuss you are making is wasted with the uninvolved.

Who knows where it will lead, it doesn't particularly waste my time.

I've not given up on Apollo yet, but I'm also looking at other fpga systems (not amiga targetted). It's not been announced yet and I'm still unsure whether that one will also be run by an unfriendly overlord..

[Iggy]

...I'm also looking at other fpga systems (not amiga targetted). It's not been announced yet and I'm still unsure whether that one will also be run by an unfriendly overlord..

hah! now that IS funny. :hammer: