Coldfire AGAIN

[bloodline]

AeroMan wrote:
@ biggun

  Some posts ago, before the discussions about MP and related stuff, I´ve made a post asking about the feasibility to preview the use of many Coldfires connected together to speed up the things....
  The idea is to make it scalable, so it could go from a really small and cheap device up to a desktop with some software compatibility between then
  Do you think it is possible ? (please, check my post...)

I don't think Coldfire has support for Multiprocessing, so you'd have to build some complex arbitration hardware and software... Certainly AmigaOS doesn't support multiprocessor environments...

[bloodline]

wawrzon wrote:
@BigGun:

Full memory protection => No more direct access to blitter.
A Coldfire with SuperAGA will be very fast but
if you ask for MP then you it will crawl.

sorry to pickup it here one more time, but i suppose the access to blitter (if it went wrong) would not crash the system but ony produced corrupted graphic output. and even that only till the next refresh. the access to superaga (and other output periferials) could be treated as exception out of memory protection and in this case we would not need to sacrifice that much speed.

i am not at all familiar with hard and software engineering, so treat this post only like a noobs idea. no need to get upset about

No, the whole Chip RAM (which includes the custom chip resgister space) would have to be outside of any Task address space, only the OS would be allowed to that! The Alternative is to map the Chip RAM address space (which I believe is the lower 8meg) to every task, and that defeats the purpose of Memory Protection in the first place!

[bloodline]

Hans_ wrote:

biggun wrote:

This means no direct access to Blitter or any HW anymore!

This is the opposite direction of the original AMIGA and the NATAMI or Coldfire designs.

I don't think that direct access to the Blitter was what Commodore wanted. IIRC, they begged people to NOT bang the hardware directly (after giving them the HW reference manuals :lol:). I'd suggest creating APIs for the NatAMI hardware; not necessarily for MP purposes, but to avoid HW conflicts, and to save people from having to write duplicate code unnecessarily.

Hans

Why not simply have a CustomChip.library (obviously a better name would need to be chosen), which has functions for reading or writing to the chipset registers... that would act as a simple and suitable hal...

[bloodline]

biggun wrote:

Question was: Can trashing Chipmem trash the system


Answer: Yes.
There is more than pictures in chipmem.
For example, there are Copperlist in chipmem.
If you thrash the copper list then the copper couldeven  *fuck* up the Disk DMA.
In Chipmem could be IO buffers where disk-IO read/writes too.

Why not simply have a CustomChip.lbrary (obviously a better name would need to be chosen), which has functions for reading or writing to the chipset registers... that would act as a simple and suitable hal...

The problem is not the access alone.
Example:
You have programm which has a IO buffer at address $10000
The program calls an disk function to load data into this buffer the program has a typo in this call and ask to load to address $40000 instead.

"Kabunga !" Your IO-call now screws-up the program at this address.

Solution: The IO routine needs to have a list of all memory block belonging to your program it needs to compare your address and length with all entries in this list to verify that your DMA request will actually go to your block.
Will this be fast?
 
Same example:
You want to use the blitter to draw ONE! Char on the screen.
Same risk : Instead blitting into your buffer you could sénd a wrong adresss and the blitter will bit unto someoneelse memory.

Solution:
The blit function will now need to compare your address ptr and length will all memory blocks belonging to your programm.

Effect: Checking if the pointer are in legal ranges takes a lot of time. Much more time than using the blitter saves.

The orignal AMIGA allowed usage of DMA and Blitter to accelerate the system.
If you need to check ranges for each blitter call the overhead will be HUUGEE!

Yeah, I didn't mean for memory protection, as you already know and I already pointed out in my Email you would need the OS to mediate all hardware access if you want Memory Protection! What I was meaning as a simple software level arbitor to allow lowlevel access but with a bit more flexibility... locking registers, allowing a slight hardware changes without worrying about compatibilty problems etc. simple stuff... but I know, it goes against your hardware banging :-)