That was also what I read elsewhere - but you tell it with nicer words :-)

So what is the current status of the soft-CPU? In the short time I have been on this forum I read some status update from Thomas on the hardware features. It seemed to me that at least a functional AGA-reimplementation in a current hardware environment wasn't too far away. This together with the statement that final hardware will not include a CPU-daughterboard creates some kind of internal conflict. I can understand that nobody would be willing to produce 060 boards that eventually will be useless but then this situation automatically gives rise to the question whether the soft-CPU will or does cause a delay when some people (like me) would be willing to spend the extra money for an 060 daughterboard and to content oneself with just AGA-functionality for the time being. I am by no means an FPGA/VHDL expert (I've done a few small projects, though) but perhaps I could fix some smaller things when there is a solid basement already. I believe that the system even in the current state would be interesting for quite a few people who rather witness incremental progress than wait for a final product complying with announced ambitious specs.

Cheers

Depends. You can also optimise a specific part while others aren't even implemented at all.

I guess all the waiting would be much easier to endure if the progress being made was more visible to the humble bystander.

Premature optimization is the root of all evil!

Further more if Thomas needs production, the market is going slow enough to hijack a production line at the place i work. :D

I couldn't agree more. The people who can't stand producing something suboptimal are the people who never get anything done.

That is what is usually meant with premature optimization.

In case of the CPU caches needs to be as fast as they can be.

OK, I understand... I think, I need to get out a short outlook of the near future:

Currently I am in the middle of the layout rework of the PCB. The changes made in the layout do not have great influence on features, but are quite urgently needed to be able to get more than five to ten boards done. Mainly power generation/distribution and connector arrangement is changed. Nevertheless this is very much detail work so it is not done on an afternoon.

Along with that there are some smaller bug fixes ongoing to the chipset. Of course there are still several open issues which may take some time to deal with. But I am quite pleased that none of them are severe system and stability problems. This is - of course - one of the highest priorities, the system reliability. Features are of lower priority than stability and reliability.

I was wondering, does stability and reliability in this case also mean compatibility with the classic hardware?

A very interesting topic! The bus arbitration in the Amiga was one of the weakest links because IIRC it used a fixed scheme where chip cycles and CPU cycles alternated making chipmem awfully slow even when there was very little real demand for memory bandwidth from the custom chips (or the CPU for that matter). So the arbiter you are implementing would have been one of the most important improvements on the way from AGA to something beyond.

Do you think that the arbiter could be tweaked by the user like in many PCs memory settings can be tweaked via BIOS? It might be interesting to have an interface for controlling the arbiter, i.e. some chip register for configuring the arbiter. It might be fun to change the arbitration rules using the copper, e.g. giving the CPU priority during a certain part of the screen drawing and the custom chips during others. I would understand, though, that something like this would be almost impossible to test thoroughly... :)

The best thing I can come up with would also be the most simple test: copy loads of data using both blitter and CPU while changing priority a lot and check whether the data is OK using hashes. Any data processing would be done in the blitter or the CPU and can hardly be affected by the arbiter so plain copying should be enough, no need to check other processing modes.

Some interesting arbitration aspects:

- CPU writes could have low priority because they are cached and nobody really needs to read the data back within a very short time

- blitter writes should have a higher priority because there is a chance that the result will be displayed soon

- priority of CPU reads could depend on how soon the data is needed to continue processing, e.g. priority could be high if one of the instructions in the pipeline require the data and low if not

- if cache-hinting is supported by the soft-CPU, such memory accesses could have a relatively low priority (we have a fast memory subsystem and probably quite a few cycles between cache hints and the point where the data is needed)

- priorities could also be changed on a per-task basis when certain tasks have shown to saturate the CPU memory bus