Falcon Speed 286 emulator

[Badwolf]

The interesting question is how well the 286 would compare

I never thought about checking if Frontier had a CGA mode. Apparently it does!

BW

[Maximilian]

Not when its running at 90% of the speed of the ST 3D maths is CPU heavy, which the Amiga's chips don't really help with. The interesting question is how well the 286 would compare

Hmm, that would be interesting to find out, but I do not have the time to make such a version...
I do not think that the difference would be much in any case..

[Maximilian]

It seems there is enough data on this for AI to make an educated guess.

Scenario / Environment Amiga 500 (with Fast RAM) Atari 520ST (1MB Stock)
Deep Space (Empty) ~7 to 10 FPS -5 to 9 FPS
Approaching Space Stations ~4 to 6 FPS -3 to 5 FPS
Planetary Surfaces & Cities ~2.5 to 4 FPS -1.5 to 3 FPS

And that is still not using the Amiga custom chips.
If the Amiga uses slow ram the numbers are much worse, but that is only a cheap plug in expansion.

[Badwolf]

The poor old Amiga's inherent slowness aside for a minute, one thing that was left on the cutting room floor in my video was a rambling background thread about how restrictive the software for this is in the ST ecosystem.

I know it's not quite apples with apples, but the Amiga bridgeboard for example renders into a window on your desktop. Same with the Archimedes PC emulators.

I speculated this was inherently down to the default operating systems and what people therefore expected.

With AmigaOS being multitasking from the outset, folks might realistically expect software and hardware to be able to coexist with other processes and, for example, render into a window. Same on the Archie albeit with a co-operative system meaning you might take over the whole thing in full screen but normally you'd be offered a way back to the desktop.

Falcon Speed takes over the whole system and then the 'return to TOS' option just resets the computer. It's just a different ethos and it's not aged well.

BW

[SteveBagley]

The poor old Amiga's inherent slowness aside for a minute, one thing that was left on the cutting room floor in my video was a rambling background thread about how restrictive the software for this is in the ST ecosystem.

I think it's also a hardware implementation issue as well as software. The Amiga Bridge boards and the Acorn PC emulators (RISC PC excepted) both feature dedicated RAM for the x86 chip and so it is able to run concurrently with the 68000/ARM CPU except when transferring data (the screen, more likely instructions to draw on the screen).

Conversely, with the (PC|AT|Falcon)Speeds the x86 and the 68000 both address the same (ST) RAM and so only one CPU can access RAM at any one time, this effectively makes multitasking both CPUs impossible -- at best, you could have the CPU's take turns to execute instructions and run both at half speed. It's effectively the same as your DFB1, or any of the Amiga accelerator boards -- once the x86 kicks in, the 68000 is just waiting.

The same would be true if you had two x86 CPUs in a shared memory system, without a cache you would only get a marginal speed boost from the parallel processing since each processor would need to wait its turn to execute code and everything ends up serialised again across the multiple processors.

On the FalconSpeed, the 68030 does have a cache so if they'd built a small cache onto the FalconSpeed board then you could probably have managed to let the two CPUs run in parallel but I suspect the cost to design the system would have rocketed…

Steven

[tOriman]

Hi,

Congratulations Badwolf - at last you have own Falconspeed!

You made nice video - thank you

tOri