Coldfire AGAIN

[FrenchShark]

@BigGun, AJCopland

Hello,

the software is intended for the 5282 coldfire which has a USP and SSP like the V4 even if it is a V2 core.
The CPU only has 60 MIPS of computing power.

My idea is to emulate all the instructions for maximum compatibility and to rewrite the OS in native ColdFire.
Then, the memory must be divided in two : one part for 68k application (running with the emlator), one part for the CF application. The CF and 68k areas are created by using the special debugging registers, no need for an MMU.
I already rewrote exec.library and partly timer.device in native ColdFire (exec multitasking needs timer to work).
As I said in some previous posts, the biggest issue seems to be the non-atomic access with a CF to IDNestCnt (TDNestCnt is not an issue since it is updated by the taskswitching routine).

I do not want to take any commitment about helping since I do not have a lot of time.

I am also doing some FPGA development, I have a nice idea to make a killing 2D video pipeline with up to 8 independant layers, colorspace conversion, fully configurable DMA scheduler, etc...

Regards,

Frederic

[biggun]

FrenchShark wrote:
@BigGun, AJCopland

Hello,

the software is intended for the 5282 coldfire which has a USP and SSP like the V4 even if it is a V2 core.
The CPU only has 60 MIPS of computing power.

I think you and we are working in the same direction, to the same goal.

Our goal is to integrate the SuperAGA and a CPU into one single Chip.
This single chip will reduce cost and enable people to again produce real cheap AMIGAs.

We are evaluating the Coldfire right now.
If we are happy with the Coldfire evaluation then we want to combine the SuperAGA + a new Coldfire with (700 MIPS) into one chip.

Thanks to Genesis help we have relative fast V4 development systems that we use for testing right now. The Natami will come shortly. You can "cludge" the Coldfire board ontot the Natami - then it will look like a CPU exypansion card to the Natami. This makes a good system to evaluate AMIGA OS running on Coldfire combined with a very high performing AGA chipset.

If you are interested in joining this project then tell us.
We could get you a V4 board.

Cheers
Gunnar

[jj]

@ FrenchShark

Let me see if I understand what you are saying.  You are planning to re-write AOS natively for coldfire ?

[Louis Dias]

JJ wrote:
@ FrenchShark

Let me see if I understand what you are saying.  You are planning to re-write AOS natively for coldfire ?

If so, I don't think he could sell it...  Otherwise he could license the 'C' sources that Hyperion own and just and just recompile for CF.

Why not recompile AROS for CF and see how that runs native 68k apps...    and I don't mean on Amiga hardware but on these CF developer boards...

[wawrzon]

@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

[wawrzon]

@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

[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!

[Hans_]

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

[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...

[biggun]

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!

[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 :-)

[Louis Dias]

call it DirectAGA, lol

Anyway, I don't think the goal of NatAmi is to move the OS forward, but to move the hardware forward.
The goal is to have a fast 3.9 system...  All this talk of memory protection is OT imho...

[HenryCase]

@all

I am sorry for the mess I instigated in this thread. I will be making further MP comments in the designated thread, and I recommend everyone else does the same. You can still quote from this thread if you wish.

Back to the Coldfire discussion. I think we should be looking to get help with implementing full 68k compatibility on Coldfire. FrenchShark obviously has skills in this area, and I'm sure Oli-HD has useful knowledge too. Thomas and Gunnar are busy enough without adding more to their workload. I've been looking at projects on the Internet where people have tried to move operating systems from 68k to Coldfire. The two projects I've found so far are:

Debian/68k
http://www.nabble.com/debian-68k-f12565.html

Atari Coldfire Project
http://acp.atari.org/

Would anyone object to me attempting to make contact and getting others involved with CFNatami?

[minator]

biggun wrote:

For "proper" protection you need to sandbox and abstract all and everything.

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.

Asking for memory protection makes only sense for people and systems that are willing to trade a lot of performance for abstraction.

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.

I don't think this is true.  It is entirely dependant on how you organise the system.

What you want to do is allow both an MP system and a classic system to run side by side but not allow the Classic OS to wreck the rest of the system.  You can use the MMU to contain Classic within a fixed area, you can also give it direct access to the chipset - the cost of going through the MMU is basically zero so it may as well be direct.

The only real problem is what happens if the Classic OS writes to the chipset while you are using the non classic OS.  It could then mess up your display.

This however can be fixed by making the new chipset "modal", that is you restrict certain features depending on which OS you are using.  Classic will see the chipset, the MP OS will see something slightly extra.

Basically what I'm thinking of setting aside a memory area specifically for the use of the MP mode, the MP OS's display port gets put in there and the Classic OS can't use the chipset to write to it - this should be pretty easy to implement in the FPGA (a control bit, a comparator and a couple of address registers which hold the range you don't want it to write to).

There is the matter of other I/O ports but these are slow anyway so abstracting them will make no difference.

It's not a perfect solution but it'd give you full graphics speed in both modes.

[Fats]

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.
 
...

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!

You could do the same trick in the copperlist, DMA and blitter as was done by the MMU. You could design the SuperAGA chipset in such a way that the OS can say to the chipset what actions are allowed by certain tasks like the MMU allows to limit access to certain memory areas. This would normally not impact speed as it is done in parallel. Only when some non-allowed action is asked an exception is raised, just like an exception is raised by the MMU when a wrong memory address is accessed.
This would work best when the SuperAGA and CPU are integrated in one chip.

greets,
Staf.

[minator]

You could do the same trick in the copperlist, DMA and blitter as was done by the MMU. You could design the SuperAGA chipset in such a way that the OS can say to the chipset what actions are allowed by certain tasks like the MMU allows to limit access to certain memory areas. This would normally not impact speed as it is done in parallel. Only when some non-allowed action is asked an exception is raised, just like an exception is raised by the MMU when a wrong memory address is accessed.
This would work best when the SuperAGA and CPU are integrated in one chip.

Don't even have to do that - address range restrictions could be imposed by including an MMU of sorts in the FPGA.  Hit specific memory areas and an exception could be raised on the Coldfire, the MP OS would then kick in and handle it - i.e. the MP OS could handle things like the disc I/O.

BTW it doesn't need to necessarily be an MP OS, it could be say AROS, the aim is just to ensure the Classic OS couldn't mangle the second OS's memory or display without effecting the speed of Classic OS.