Amiga cpu architecture/patchability question

[Angus]

I had always thought that if you fitted an accelerator card to an an Amiga, say an 030 to a 1200 (or indeed to a 500/600) then you lost all ability to access the original cpu 68020/68000. Is that correct?


But if that's the case, is it absolutely impossible for the Amiga to reach it?


Scenario: A team of Amiga WHDLoad patchers are in a spaceship (attempting to avoid a barrage of slave requests from rabid Amiga flightsim fans). En route to their destination world the ship is damaged by a meteor and the Nav computer is completely destroyed. However, one of the patchers has brought a 1200 with him, with an 030 fitted. With their characteristic skill and determination, the Navigation program code is converted to 68K machine code by the team. Unfortunately despite their best efforts at optimisation, the 030 can only complete 90% of the jump trajectory before the ship's tachyon trace system loses it's reference points and needs to reset and restart the process from scratch. It might as well be 9% - They've hit a brick wall.

At this point, the ship's janitor walks past and mutters, "Couldn't you access the 020, farm out some of the calculations to that, to push it over the line?"


Should they:


a)Dismiss it as impossible


b)Attempt it with renewed vigour


c) Space the mouthy twat for having the audacity to talk to his betters.

[Thomas Richter]

Originally Posted by Angus

I had always thought that if you fitted an accelerator card to an an Amiga, say an 030 to a 1200 (or indeed to a 500/600) then you lost all ability to access the original cpu 68020/68000. Is that correct?

Depends on what you mean. For the running system, yes. The turbo board typically requests the bus from the on-board CPU, and never releases it, so the on-board CPU is "in limbo". It cannot fetch data or react on anything that is happening because it is suspended.


Some boards have the option to disable themselves, upon a reboot, and then of course the main CPU takes over.

[Angus]

Thanks, but what I'm trying to say, is there any conceivable way of getting them to work together, even if one of them is doing a tiny amount of work?

[S0ulA55a551n]

Originally Posted by Angus

Thanks, but what I'm trying to say, is there any conceivable way of getting them to work together, even if one of them is doing a tiny amount of work?

No, because they would be sharing the same memory, chip access etc etc. System would just crash. Even if you could somehow make the system use both and some how organise which cpu is accessing what when both cpu would just be able to do less.

[Thomas Richter]

Originally Posted by Angus

Thanks, but what I'm trying to say, is there any conceivable way of getting them to work together, even if one of them is doing a tiny amount of work?

As said, the Turbo Board locks the main CPU, and it has to, so the answer is "No".

[Samurai_Crow]

If a board was specially designed to run in parallel eg. with separate memory like the PPC PowerUp boards from Phase5, the context switches killed the performance boost because AmigaOS wasn't designed for parallel processing. AmigaOS 4.1 still can't use both cores on a dual-core AmigaOne x5000. On the same hardware, Linux can use both cores.

The problem isn't just on the hardware side. It's a shortcoming of Exec.library. you'd need a different OS. Even MorphOS can't use both G5 PPC chips on the dual G5 PowerMacs it runs on.

[Locutus]

Originally Posted by Angus

Scenario: A team of Amiga WHDLoad patchers are in a spaceship (attempting to avoid a barrage of slave requests from rabid Amiga flightsim fans). En route to their destination world the ship is damaged by a meteor and the Nav computer is completely destroyed.

Is this 'Destination: Void' with Amiga's?

[Angus]

I had to research that to understand your question, as I'm only familiar with Frank Herbert's Dune books. But which patcher would represent Organic Mental Core? :-)

[meynaf]

No 68k accelerator board i know of will allow running both cpu at once. Only thing that might be doable is to make the 030 disable itself by touching some board i/o, having the 020 take over. On a Blizzard 1230 i could do this but it's then impossible to bring the 030 back by pure software.

While running two cpus at once is in theory possible, it would require to specifically design a board to achieve it and then do everything "by hand" as the OS isn't made for that. Would give some kind of asymmetric multi-processing, like 68000+z80 in the megadrive. Not sure the extra processing power is worth the trouble, though.

[defor]

My guess (and my personal view): On A1200, not possible. Alice, responsible for handling the internal (chip RAM) bus access, assigns bus slots according to a device priority. What priority level the second CPU would have? There is no mechanism to assign/re-assign any such priority. Both CPUs would compete for the same bus slots = crash. Even if the second CPU would use only its own RAM (fast RAM), what would be the point of it all if the result of any computation cannot be transferred to the chip-RAM where the first CPU (or any other device) could access it? On any Amiga equipped with ZorriII/III bus, it's possible -- the second CPU board would be a new device (in fact, isn't it already available in a form of some gfx board with programmable GPU, or an emulator board?). However, on a system level the multiprocessing is not supported as stated in previous posts.

[Niklas]

Originally Posted by Angus

Thanks, but what I'm trying to say, is there any conceivable way of getting them to work together, even if one of them is doing a tiny amount of work?

I don't see why it wouldn't be possible.

The bus arbitration protocol (BR/BG) would be used so that only one of the processors can access the memory and chipset at any one time.

In an A2000 it is the Buster chip that does bus arbitration. In an A500 the accelerator would have to implement bus arbitration.

If at least one of the processors is executing long running instructions, such as divisions, then the two processors could perform more useful work together than one of them could alone.

As maynaf points out, the architecture would be some kind of asymmetric multiprocessing, with a main processor and a co-processor, rather than symmetric multiprocessing (SMP).

[Angus]

Originally Posted by defor

My guess (and my personal view): On A1200, not possible.

Okay, forgive my ignorance, I know very little about this stuff (as will become clear) but, in theory, could you write a new, very basic OS that partitioned the memory so the 030 just uses the fast ram, the 020 just the chip ram, except for scheduled necessary exceptions, which were handled safely by a governing system in your new OS?

Or if there are hardware reasons that make it impossible for 2 cpu's to share resources, then a system that enabled resources to be switched to one cpu while the other either paused or continued with working on tasks that didn't require those resources?

[Photon]

Niklas, it's very difficult and expensive to do. This is why no such computer has emerged in the last 30 years. Not only that, both the software to run and the OS must be completely restructured and re-thought to take advantage of the 100x slower CPU. Not just patched.

Typically, parallelism is done by transferring data to a separate "computer" (e.g. GPU) for it to process uninterrupted. An unaccelerated Amiga and an accelerated Amiga can certainly compute in parallel and add the computational result together.

[Samurai_Crow]

Originally Posted by Photon

Niklas, it's very difficult and expensive to do. This is why no such computer has emerged in the last 30 years. Not only that, both the software to run and the OS must be completely restructured and re-thought to take advantage of the 100x slower CPU. Not just patched.

Typically, parallelism is done by transferring data to a separate "computer" (e.g. GPU) for it to process uninterrupted. An accelerated Amiga and an accelerated Amiga can certainly compute in parallel and add the computational result together.

Linux supports NUMA and RasPi has compute modules that can run in parallel on a third-party rack-mount host board.

[Angus]

What about if you created a "portable" multitasking calculator that was designed to run purely on the 020 just doing calculations in the background, and recieved tasks and delivered results to the "master" cpu at specified intervals? Like an emulated fpu co-processor kind of deal?

[Niklas]

Originally Posted by Angus

What about if you created a "portable" multitasking calculator that was designed to run purely on the 020 just doing calculations in the background, and recieved tasks and delivered results to the "master" cpu at specified intervals? Like an emulated fpu co-processor kind of deal?

A314, https://github.com/niklasekstrom/a314/, is an expansion that lets a raspberry pi be used as a co-processor to the 68k processor. However, it sits on the DRAM memory bus and not on the processor bus, and so may not be what you are looking for.

[Samurai_Crow]

Originally Posted by Angus

What about if you created a "portable" multitasking calculator that was designed to run purely on the 020 just doing calculations in the background, and recieved tasks and delivered results to the "master" cpu at specified intervals? Like an emulated fpu co-processor kind of deal?

You only need a new OS. The hardware problems are easy. Software, not so much.

A non-uniform memory architecture (NUMA) can do it easily but then you need a different OS than AmigaOS to manage the message passing because the Amiga message passing assumes shared-memory accesses. AmigaOS is not NUMA capable.

[Niklas]

Originally Posted by Samurai_Crow

You only need a new OS. The hardware problems are easy. Software, not so much.

Do you really need an entirely new OS though? What if you keep AmigaOS intact and run it on the main processor, and then give the co-processor it's own chunk of memory where it can run without interfering with the main processor or the OS? The co-processor it's initially halted and is allowed to start running only after the environment has been prepared, and then immediately jumps to code that controls the co-processor. The processors can communicate through shared memory and perhaps interrupts.

I agree about the hardware being the easy part.

[Samurai_Crow]

The tristate buffers in the CPU allow an I/O bridge via DMA. That's the only way that two processors can share memory. One has to shut down during the DMA but it can be reactivated.

The best option for cross-bus communications IMO is the dual-port memory of an FPGA or CPLD. This block memory can be read from and written to at the same time by two different busses.

For what they amount to today, you could just as well replace most of the Amiga chipset with an FPGA and customize the design while you're at it. Maybe get a large one and implement your own CPU based on the open-source WF68K30L core. (That's a 68030 compatible core with a 4-stage pipeline.)

[grelbfarlk]

Don't get me wrong I'm quite biased, but I'm pretty happy with the WarpOS PPC acting as a co-processor. It's plenty fast when it needs to be. If it was integrated better with the 68k side of things it could be a lot better.