exxos's Atari, Amiga & retro forum

SteveBagley wrote: 11 Sep 2026 14:25 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

SteveBagley wrote: 11 Sep 2026 14:25 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..

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.

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

Badwolf wrote: 11 Sep 2026 15:04 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

Hi,

Congratulations Badwolf - at last you have own Falconspeed!

You made nice video - thank you :)

tOri

SteveBagley wrote: 11 Sep 2026 17:11 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.

True, but Falcon Speed relinquishes the bus every 18ms or so anyway (albeit for a very small time). Presumably to service interrupts? I would have thought event checking for window actions would have been possible at that rate.

I'm not saying it should magically multitask, but no thought is given to much Atari software about anything else running. Even being able to return to the desktop would be nice. Falcon Speed only uses 8MB for the PC, so even a clean exit rather than a reboot might have been nice as it ought not have to trash the OS.

Anyway, 'tis but a small gripe about a trend. :)

But wouldn't a PC in a window as a desk accessory have been cool? 8-)

SteveBagley wrote: 11 Sep 2026 14:25 The interesting question is how well the 286 would compare :)

Bah. Tried it. Needs a 386!

BW

Badwolf wrote: 11 Sep 2026 20:41 True, but Falcon Speed relinquishes the bus every 18ms or so anyway (albeit for a very small time). Presumably to service interrupts? I would have thought event checking for window actions would have been possible at that rate.

I started taking a look at the FalconSpeed and ATSpeed software in Ghidra earlier today, they definitely work in different ways. The ATSPEED software definitely uses $FFFC40/$FFFC80 to communicate as per the Atari STE+ service manual, but FalconSpeed seems to be mapped in a different way, which wasn't entirely clear. It almost looked like it was using similar memory locations to the IKBD/MIDI ACIAs to communicate (using the odd bytes as opposed to the even).

I'm not saying it should magically multitask, but no thought is given to much Atari software about anything else running. Even being able to return to the desktop would be nice. Falcon Speed only uses 8MB for the PC, so even a clean exit rather than a reboot might have been nice as it ought not have to trash the OS.

Don't forget that TOS and DOS will both be fighting over memory locations (they share the same address space), so it's a non trivial problem to switch between the two. Ideally, you'd want to be able to remap the x86's memory accesses to an arbitrary block allocated by TOS, but the logic to do that (without an MMU on the CPU) would be complex. I suspect IC6 is doing something interesting with the high byte of the addresses to help, though. My disassembly of the FalconSpeed (and ATSpeed) software suggests the Atari loads the BIOS in at $38000, although the 286 will (IIRC) access it at F000:FFF0, so something must be happening. The decoded equations will be interesting,

Interestingly the reason that FalconSpeed can only access 8MB is because A23 is grounded by the 74HC573 at IC10.

It's quite amazing it actually works at all :)

But wouldn't a PC in a window as a desk accessory have been cool? 8-)

Oh definitely, I think the Supercharger could do things like that? It was more like the Amiga Bridgeboards, a complete PC in a box which talked over ACSI to the ST.

Steven