Commodore Gemini dual 030 card and Buster magic

[PurpleMelbourne]

Originally Posted by Gorf

So the Busters take only care of the transaction from 030-bus to ZorroIII and back again.

Dave Haynie's comments about a computer full of these cards makes more sense if you are right. SO you are probably right!

What do you think about the idea of doing the same thing via PCI instead of Zorro 3?
Someone with some good FPGA talent could make a lot of cool stuff!

68040fe33's are pretty cheap. How about one FPGA hooked up to eight of those CPU's...

Hmmm I suppose for serious moving forwards we'll need to jump to a much faster processor. But until we have that opportunity we need to do a bit of innovating to keep Amiga going on 68K a bit longer. And we'd need SMP eventually anyway...

Apollo68080 / TG68 with four or eight cores would be nice

[PurpleMelbourne]

Originally Posted by Juz400

I think you missunderstand my usage case for the CPU,
The Amiga should not see it as a CPU, its the translation layer between Amiga and the new peripherals and RAM
They `share` Zorro3 bus, one or the other has Master as required, the Coldfire should be fast enough that the Amiga does not wait for for it.
It would not matter that has missing instructions as it is NOT running the Amiga OS, It will run its own limited `OS` to watch and respond to which ever BUS wants to move data.
With CPU on both sides of the Zorro we should be able to fine tune the Coldfire OS push Zorro3 bus to its limit.

The price range is from £30 to £60 per chip, DDR Ram is peanuts from ebay making the Idea pretty wallet friendly
Coldfire with Ram slots on each PCI slot?
The `Interface` Coldfire could identify a CPU on each PCI slot and `upload` a small OS to each to again watch the BUS and work on data modules sent to spare/idle slots.

So you mean like a Coldfire WarpUp card type thing?
Its late here so I'm picking up pretty slow. But this sounds like an interesting idea. With FPGA all sorts of things can be done. Like how about getting two similar CPU's and gluing them together with the FPGA which can also contain extensions (like adding FPU to 030 type thing). I was thinking 68360 (which is full of dual port ram) and 68060, but Coldfire would also be an interesting choice. How about PPC, Coldfire and fill in the gaps with cache, aMMX and some kind of TG68 type "poly-filler".
Like I said, its late, I'm probably talking nonsense... can't tell right now

You have a point. A 400MHz Coldfire would probably do 68k emulation pretty nicely. I think that's the route the Atari people were looking at.

[Fastdruid]

Originally Posted by PurpleMelbourne

Dave Haynie's comments about a computer full of these cards makes more sense if you are right. SO you are probably right!

What do you think about the idea of doing the same thing via PCI instead of Zorro 3?
Someone with some good FPGA talent could make a lot of cool stuff!

IIRC Dave Haynie is on record as saying he would have used PCI back in the day if it had existed instead of AMI bus in the Acutiator design and that was designed to be multiprocessor.

Originally Posted by PurpleMelbourne

68040fe33's are pretty cheap. How about one FPGA hooked up to eight of those CPU's...

Might be worth looking to some of the earlier dual/multiple socket PC designs to see how they they did it. Essentially it's the same problem and more applicable than the multi-core processors.

Originally Posted by PurpleMelbourne

Hmmm I suppose for serious moving forwards we'll need to jump to a much faster processor.

Well the logic with Gemini was always that the software and logic would remain the same, you'd just drop in faster processors. The same really goes for messing with 030 vs 040 or 060.

Originally Posted by PurpleMelbourne

But until we have that opportunity we need to do a bit of innovating to keep Amiga going on 68K a bit longer. And we'd need SMP eventually anyway...

It's a very interesting concept but Gemini was only ever an experiment and was a closely coupled system acting as loosely coupled system rather than an SMP type. It would have been in effect a "beowulf cluster in a box". Which would have been awesome from a rendering farm perspective but not _particularly_ useful for a single user.

The biggest issue really is that you need some OS support to really do much with it and AIUI going SMP with Exec is going to be tricky without breaking everything (hell even on PPC where there are already multiple core processors AmigaOS4 isn't there yet).

[Gorf]

Originally Posted by Fastdruid

The biggest issue really is that you need some OS support to really do much with it and AIUI going SMP with Exec is going to be tricky without breaking everything (hell even on PPC where there are already multiple core processors AmigaOS4 isn't there yet).

AROS on x64 does support SMP.

[Gorf]

Originally Posted by PurpleMelbourne

What do you think about the idea of doing the same thing via PCI instead of Zorro 3?
Someone with some good FPGA talent could make a lot of cool stuff!

well: the CyberstormPPC with GRex does provide PCI. So it is definitely possible without going through ZorroIII like Prometheus.

So a FPGA could certainly provide a 680XX-bus-to-PCI interface. ... what one does with it is a different question...

If the goal is to have a (cluster-like) multiprocessor machine, I guess it makes more sense to stay as close as possible to the actual processor bus.

So for multiple 68040s the simplest and fastest solution would be a 040-bus-arbiter with full address- and datalines. In functionality similar to what the original Zorro2-Buster does for the 68000 bus, or what the NuBus in the Mac-II does.

Actually it would have been possible to make Zorro2 cards with a 68000 and RAM on them back in 1987...

Apple did this for the A/ROSE NuBus-cards (and they had a preemptive multitasking kernel running on this card...)
https://en.wikipedia.org/wiki/A/ROSE

[Fastdruid]

Originally Posted by Gorf

AROS on x64 does support SMP.

Not much use on 68k though.

[Fastdruid]

Originally Posted by Gorf

Actually it would have been possible to make Zorro2 cards with a 68000 and RAM on them back in 1987...

Just use multiple A2620/30 cards with a buster type arbitrator basically.

[Gorf]

Originally Posted by Fastdruid

Not much use on 68k though.

well - it shows how it can be done and what changes to Exec are necessary.

The problem with 68k is the missing support for SMP in any model but the 68060.
(But that would be less a problem if we talk about FPGA-accelerators, where the desired support can be implemented.)

But in terms of this thread (Gemini) it would come down to a cluster as you pointed out already - so each CPU would have its own RAM and an independent kernel would run on each..

[Gorf]

Originally Posted by Fastdruid

Just use multiple A2620/30 cards with a buster type arbitrator basically.

more like A3640s, since you wouldn't want to go down to a 16-bit bus with a 32-bit CPU.

[Fastdruid]

Originally Posted by Gorf

well - it shows how it can be done and what changes to Exec are necessary.

Yes and no. Yes it's long been known _how_ to do SMP, the issue is that it breaks everything.

If you break everything that came before it makes sticking to 68k kind of pointless.

The SMP in AROS doesn't work with 68k.

Originally Posted by Wawa

aros smp is is not compatible with m68k, it is ifdeffed since some structures had to be extended as such, if it was enabled for m68k it would reneder existing software unusable.

[Gorf]

Originally Posted by Fastdruid

Yes and no. Yes it's long been known _how_ to do SMP, the issue is that it breaks everything.

does it?
AFAIK on AROS x64 the binaries can be totally unaware of the SMP-kernel.

The SMP in AROS doesn't work with 68k.

because no one ported it to Exec and the scheduler on 68k yet

the Apollo-core (Vampire) has hyper-threading and it is used for cpu-blitting - the scheduler is unaware of a second core in this case, but still it is put to work.

[PurpleMelbourne]

We need more speed. Maybe what is really needed is a Coldfire primary CPU and 68K as backup which would run all the "other than OS" SW except what has been compiled for Coldfire, which obviously is nothing at the moment. But software which needs a lot more speed can be recompiled.

So how would an 060 and ColdFire play well together?

If Apollo succeed , then they can add the extra instructions to make a dual core system where both cores can run both 68K and Coldfire code, and of course the new hybrid.

I've thrown the Coldfire compatibility suggestion over to the AmigaOS 3.2 developers. They will of course reply "ON WHAT HARDWARE!". So it needs to be built... so how?

Compatibility is going to be a bit wobbly, so we need enough in return to be worth the bother. Perhaps a quad system with two two coldfire and two 68k would be better?

This process would be able to act like a splint for the Amiga, till we can get over Motorola dumping us.
Help me build it and I will

I'm betting the OS guys will support it when it becomes a reality. Plenty of pandemic development time right now!

[Fastdruid]

Originally Posted by Gorf

does it?
AFAIK on AROS x64 the binaries can be totally unaware of the SMP-kernel.

AROS on x64 is massively different from running SMP on multi-socket 68k. AROS itself is also rather different to AmigaOS.

As one of the actual developers said

Originally Posted by Ezrec

AROS SillySMP is *not* targeted for m68k. It is only for *existing* processors with *actual* SMP hardware

RJ Michel made lots of compromises in Exec that give better speed on limited hardware but have come to bite us later with hindsight and the way hardware has changed.

Same can be said about the hardware, there are design decisions made that in 1984 were totally correct for the best performance but in hindsight adding an extra feature or two would have made things massively easier. Like the Amiga display being planar only rather than chunky or having a choice of chunky or planar. Planar was the best choice for low memory usage and the ability to do fantastic 2D effects (see the classic Boing ball for example) but far harder to do 3D etc.

AmigaOS is open with no memory management and freedom to access any system structures, this is great for some things, terrible for others.

SMP on 68k is not impossible, or even particularly tricky (as in most of the issues have solutions out there) but what is very tricky is implementing it _without_ breaking all the API's and everything that was written for AmigaOS. If you don't _care_ about backwards compatibility and just want to do it "just because" there are easier and cheaper ways than using 68k.

AROS x86 does not have that issue because there _is_ no legacy software. The few bits of software that have been written already don't use the macros that make things such an issue for legacy 68k AmigaOS software.

Originally Posted by Gorf

because no one ported it to Exec and the scheduler on 68k yet

Because the physical hardware doesn't exist to do what they're doing in x86 land. I don't know the state of "multi-core" in FPGA/Vampire but it's not _just_ as simple as throwing in another core. It's how memory is handled, cache consistency etc. These are handled in _hardware_ in modern multi-core CPU's.

Going back to Gemini, it probably helps more if you imagine it joining 3 A1200's together by their trapdoor expansion port. All of them running their own copy of AmigaOS but with one in charge and that one is the only one fitted with a hard drive.

I suspect that the beauty of the system would have been it would AmigaOS friendly because it would have only been taken advantage of by software written to use it.

[Gorf]

Originally Posted by Fastdruid

AROS on x64 is massively different from running SMP on multi-socket 68k.

I did not claim it would be the same - please read my posts again.

As I pointed already out: the 060 is the only classic CPU in the 68K family, that has some support for SMP.
So IF AmigaOS/AROS is going to implement SMP-support the target is more likely to be a FPGA-core, where the necessary hardware support for it can be implemented.

AROS itself is also rather different to AmigaOS.

How is AROS-68k so different? What exactly do you mean?

RJ Michel made lots of compromises in Exec that give better speed on limited hardware but have come to bite us later with hindsight and the way hardware has changed.

I doubt that, since he is not the author of Exec - Carl Sassenrath is.

Same can be said about the hardware, there are design decisions made that in 1984 were totally correct for the best performance but in hindsight adding an extra feature or two would have made things massively easier. Like the Amiga display being planar only rather than chunky or having a choice of chunky or planar.

that has absolutely nothing to do with Exec.
That is only a matter of the gfx.library and Intuition - and AmigaOS has been proven to be quite modular and flexible in this regard over the years.
Much more so, than most contemporary OSs from that time, like MacOS, DOS, and even Windows.
(MS needed so put abstraction layer over abstraction layer and keeping several APIs in parallel to move forward - a convoluted mess...)

AmigaOS is open with no memory management

Of course it has memory management. Exec allocates memory for a task, can set it private or public, can give you Chip or Fast and so on.
But it has no memory protection implemented.

But you actually CAN use a MMU to provide (some) protection - the reason this is not really used is not so much the OS itself, but that legacy applications are not expecting it and many are not really programmed with the guidelines in mind...

But the same is true for classic MacOS and DOS and Windows before NT....

SMP on 68k is not impossible, or even particularly tricky (as in most of the issues have solutions out there) but what is very tricky is implementing it _without_ breaking all the API's and everything that was written for AmigaOS. If you don't _care_ about backwards compatibility and just want to do it "just because" there are easier and cheaper ways than using 68k.

AROS x86 does not have that issue because there _is_ no legacy software. The few bits of software that have been written already don't use the macros that make things such an issue for legacy 68k AmigaOS software.

There are a quite simple solutions for this:
hide the fact of more then one CPU from the (old) application - new ones can use them.
Also:
we already have a fairly good sandbox with WHDload, that has some MMU support already - it should be possible to run multiple WHDload-instances on a multi-core system ...

I don't know the state of "multi-core" in FPGA/Vampire but it's not _just_ as simple as throwing in another core. It's how memory is handled, cache consistency etc. These are handled in _hardware_ in modern multi-core CPU's.

that is exactly what the Apollo core does in this case.

Going back to Gemini, it probably helps more if you imagine it joining 3 A1200's together by their trapdoor expansion port. All of them running their own copy of AmigaOS but with one in charge and that one is the only one fitted with a hard drive.

don't know, why you think I would need help here...
I was saying that Gemini is a cluster approach the whole time

I only mentioned SMP, because you claimed it would be next to impossible to support it for the OS. That is why I showed you two examples (AROSx64 and Vampire), where it is already reality...
I am fully aware, that the Gemini approach has nothing to do with SMP

I suspect that the beauty of the system would have been it would AmigaOS friendly because it would have only been taken advantage of by software written to use it.

I quite like the idea as well.
Actually I am a more a fan of MPI (cluster) and not so much OpenMP (SMP), when it comes to parallel programming...

[Fastdruid]

Originally Posted by Gorf

But you actually CAN use a MMU to provide (some) protection - the reason this is not really used is not so much the OS itself, but that legacy applications are not expecting it and many are not really programmed with the guidelines in mind...

But the same is true for classic MacOS and DOS and Windows before NT....

Which in part is why none of those did SMP and why MS abandoned the Windows 9x kernel to move to the Windows NT.

No one is claiming you _cannot_ do SMP but pointing to AROS is an irrelevance because as I and many people have said it _BREAKS_ everything that went before.

Originally Posted by Kalamatee (AROS)

Sorry to be the bearer of bad news - but there won't be support for smp in the m68k build ever. The m68k platform has no provision for working in an smp-like environment, and changes would make it binary incomparable with existing amigaos/aros for m68k.
If the vampire/apollo team create some "smp like" m68k core, it would need its own custom n68k flavour of aros, and most m68k apps won't work on it.

Who is Kalamatee?
https://github.com/orgs/aros-development-team/people
https://github.com/Kalamatee

[Gorf]

Originally Posted by Fastdruid

Which in part is why none of those did SMP and why MS abandoned the Windows 9x kernel to move to the Windows NT.

No one is claiming you _cannot_ do SMP but pointing to AROS is an irrelevance because as I and many people have said it _BREAKS_ everything that went before.

certainly not "everything" but many things, if there ist no functional sandboxing, that even might include a dummy-kernel in that sandbox....

he m68k platform has no provision for working in an smp-like environment...

as I already said, this functionality would be needed to be implemented in an FPGA-core

If the vampire/apollo team create some "smp like" m68k core, it would need its own custom n68k flavour of aros, and most m68k apps won't work on it.

see above - a mechanism to ensure compatibility with legacy apps needs to be provided.
Now the Apollo-core DOES provide hyperthreading, which looks as two CPUs to the software - but Exec and existing software is happily unaware or this and simply ignores it. Just a few routines (blitting) make use of it and are bypassing the OS in this case.

One can argue, that this is not really SMP.
Nevertheless: this approach could be used for e.g. a sandbox to run a certain legacy-task on a second CPU.

With some more work the silly-SPM approach from AROS could be adapted for such a core at least for new/modified programs, while old software keeps ignoring it.

Who is Kalamatee?

He is well known and his work is appreciated.
In this case however he simplified things too much.

[PurpleMelbourne]

So multi processor OS is off the table for us?
Well it's a good thing there is a new technology to pretend to combines cores back as one. I don’t know what it's called and don't know when it will hit the public. But by the sounds of things it is the only way AMIGAOS will ever run many cores?

That would be very disheartening.

Surely we could at least give ShapeShifter it's own CPU!
I'd think each CPU could have its own sandbox of ram and run programs entirely separate from the other CPU's except that whichever is CPU would be the conductor running the OS and making the decisions for CPU1, CPU2,... And in this model CPU would not even need to be 68k as long as the OS is compiled for it.
Like a Coldfire with a pair of 060's to throw tasks at...

[Gorf]

Originally Posted by PurpleMelbourne

So multi processor OS is off the table for us?
Well it's a good thing there is a new technology to pretend to combines cores back as one. I don’t know what it's called and don't know when it will hit the public. But by the sounds of things it is the only way AMIGAOS will ever run many cores?

as said in the comments above: it depends largely on what you mean by it and how you expect it to work.

Under some circumstances an Amiga-like OS can e.g. provide SMP like AROSx64 (sillySPM).
An other way is how the Vampire team made use of a second CPU, via bypassing the OS.

A third way wound be a cluster. That is what the Gemini would have provided.
And to some degree ist is, what the PPC cards in the 90s provided:

a separate kernel has to run on every CPU. Some libraries provide a way to communicate.

This is not a bad choice per se: all supercomputers work this way.

Like a Coldfire with a pair of 060's to throw tasks at...

Coldfire is dead.
The compatibility issues are so big, that it makes no real difference to use a completely different and much faster architecture instead.
A ARM CPU e.g. like on the A314 or the ZZ9000.

[Jope]

Originally Posted by Gorf

This is not a bad choice per se: all supercomputers work this way.

But what makes a supercomputer from this architecture is blazing fast communications between the compute nodes. Zorro III is not it. :-)

[Gorf]

Originally Posted by Jope

But what makes a supercomputer from this architecture is blazing fast communications between the compute nodes. Zorro III is not it. :-)

As I said earlier: the bus should be as close as possible to the native CPU bus...

But in defense of Gemini: for a cluster of 030s @25MHz ZorroIII is not that bad (even if it needs to multiplex address and data), especially if every CPU has it own memory.