robespierre wrote:the Crime chip (CRM) is like the "northbridge" of the O2. it accepts requests from the CPU and the other I/O chips and buffers them to the memory. It also contains the OpenGL accelerator component, unimaginatively called the "Rendering Engine", which is like the Indy's XL graphics (no geometry engine).
the VICE chip sits on the same bus as the CPU (SysAD bus), which limits its usefulness somewhat, since they both share the same path to main memory. Furthermore, they are not cache-coherent with one another.
I wouldn't class the O2 graphics as just another XL. Clearly it doesn't have a fully accelerated 3D pipeline, but there are compelling differences from the XL. MRE being able to do color space conversions is one of them. The VICE is available to perform some pretty substantial imaging calculations is another. I think that really the O2 is a memory controller with some coprocessors, just look at the diagram in the technical report. This is great when you are using VICE or fully utilizing the rendering engine, but not so great when you want maximum CPU speed. Hence the well documented underperformance of the R10/12k in the O2.
The VICE and the CPU are not cache coherent but I don't think that is really necessary for their purposes. If your MSP is processing GBs of data sequentially do you really want to keep a cache coherent?
I think what limits the VICE is not a shared bus but the sheer complexity of making it work. A driver and library would already handle loading ucode and allocating buffers, but you'd be writing two different bits of assembly, both of which need to be less than 4k and both of which are different dialects of MIPS. Furthermore, each chip has loads of quirks and probably bugs.