Yes it is and in a better way but with just a note, I would have preferred a more anonymous name...

If we wishes to increase the attractiveness of the platform, then the software development must be helped and the previous uses of the term "anachronism" confirms the urgency of this need.

This minor addition is not directly intended for current and former programmers but it is mainly for programmers of other platforms whose contributions have always been beneficial.

Well, there are several issues here. First, to answer your question whether it is possible to construct the memory such that the CPU has preference over the custom chip bus arbitration, my answer would be "not in general". There is custom chip DMA which requires a certain minimum bandwidth and which cannot be delayed - screen DMA, copper DMA, audio DMA, disk DMA. If there is not enough bandwidth because the CPU takes it all, then you would get screen, audio or data corruption, none of which is acceptable.

There is also blitter DMA, which is not critical. Though for that we already have a mechanism to control the DMA priority (not exactly, but it could be used for that) - namely the "blitter nasty" flag.

I also don't quite see why the priority should be dependent on the memory type. This type of coupling is not exactly correct - priority is task dependent, not memory dependent.

That said, I don't see why the memory should not consist of several banks, such that custom chip access to bank A does not interfere with CPU access to bank B. But I don't see a good justification why custom chip access to bank B should be forbidden completely (as it is now - FAST MEM as bank B, and CHIP MEM as bank A) nor why there should be two banks.

A much saner system would be one where we had a couple of memory banks and custom chip and CPU would not interfere or block each whenever the access goes to different banks. This would be a much more novel, more flexible and more forwards oriented system than the one we have.

Next I hope Thomas uses a simple register where during boot up the address is written where the chipmem stops.(This could make it byte exact, if needed to!)

Further more what SID proposed should be to some extend embedded in the memory controller in such a manner a programmer cannot access it.
Why?
Because they do not need to determine priority to memory access this is pure a part of the memory controller!!!

I do mean: Memory appears as a continuous overall region to custom chips and the CPU with no need to distinguish between them. However, internally, memory is segmented into banks (each of which x K large) that can be addressed independently and have independent busses. If the custom chips access bank Y, no bandwidth limitations arise for bank X, if X != Y.

So in other words, there is no need for "fast mem" and "chip mem", which is quite an anachronsim. In the simplest case, there are two banks (call them low and high, if you like, and identify low with chip and high with fast, if you like), but custom chips and CPU can access both. If the custom chips DMA from the low memory, memory transfer to the high memory is unconstraint and fast. If the custom chips access memory from the high region (new feature!) CPU access to the low region is fast and not hindered by DMA.

Extend this from two banks to N banks,without having the need of storing or telling the hardware which bank you want to map in (as said, I'm speaking of a continuous addressing space) and you have a flexible system within which CPU and chips see a continuous memory region, can access the full region at once, but still do not block each other most of the time.

Well, at least audio and disk DMA appear to me to be good examples for DMA that may be delayed (i.e. buffered). Their priority could depend on their buffer's fill level. Thus, if the buffer needs to get flushed (read access) or is almost empty (write access), the priority of the DMA will get promoted to above CPU priority and will remain lower than CPU priority else.

I agree with the two of you that all this is a matter of hardware and should not be visible to the programmer.

I think that is what many modern CPUs do: they have more than one memory bus (e.g. "HyperTransport") and thus can do several independent memory accesses at the same time. If you now have two or more CPU cores, you get exactly what you describe for a pair of CPU and a custom chip. And yes, this would be the best mode of implementation because it shows the least amount of hardware limitations to the programmer.

SID no offense intended.
the more i read it over the more MDRAM comes to mind for me read it up and read ThoR's post again.