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

[Badwolf]

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?

The interesting question is how well the 286 would compare

Bah. Tried it. Needs a 386!

BW

[SteveBagley]

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?

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

[Badwolf]

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

Ooo, if you're looking at Ghidra (I still must learn to use that -- the few attempts I've had so far to play with it have ended in ignominy), let me know if you see anything related to IDE. Seems to be a big weak point. I suspect it struggles with modern devices for a couple of reasons. Timing may be one (there are a *lot* of lockups with my CF card) but the biggest hurdle is it doesn't seem to accept any *drive* over a figure between 64 and 256 MB. Perhaps cylinder count is stored as a byte?!

My quick bit of debugging with Hatari agrees with your ACIA discovery. Without any hardware the software will spin in a loop setting the MIDI ACIA's byte and the one above it to zero (via a word clear) then testing the keyboard+1 byte for ($e0 >> 5). Mysterious.

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.

Yes, that's a very fair point. With so little logic on the board itself it does kind of preclude playing nicely with anything else in RAM, I suppose.

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,

I attach what I have so far. I think the PAL ones are wonky as the pins don't line up. I've tried to name the GAL ones appropriately, however.

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

It's certainly an exercise in minimalism and, with the hard disc limitations (coming in part two), it might be argued it doesn't really.

Cheers,

BW

[SteveBagley]

Ooo, if you're looking at Ghidra (I still must learn to use that -- the few attempts I've had so far to play with it have ended in ignominy), let me know if you see anything related to IDE.

Yep, there's definitely some IDE reading code in there… I need to look at in more detail…

My quick bit of debugging with Hatari agrees with your ACIA discovery. Without any hardware the software will spin in a loop setting the MIDI ACIA's byte and the one above it to zero (via a word clear) then testing the keyboard+1 byte for ($e0 >> 5). Mysterious.

How the heck this doesn't break MIDI software I don't know…

This is probably the code you saw?

Code: Select all

                             LAB_00011ff6                                         XREF[2]:     00011ff0(j), FUN_00013548:000141b0(j)  
        00011ff6 42 78 fc 04     clr.w           (DAT_fffffc04).w
        00011ffa 4e 7a 20 02     movec           CACR,D2
        00011ffe 08 c2 00 0b     bset.l          #0xb,D2
                             LAB_00012002                                         XREF[1]:     FUN_0001455e:00014c5c(R)  
        00012002 4e 7b 20 02     movec           D2,CACR
                             LAB_00012006                                         XREF[1]:     FUN_0001455e:00014c5e(R)  
        00012006 14 38 fc 05     move.b          (DAT_fffffc05).w,D2b
                             LAB_0001200a                                         XREF[1]:     FUN_0001455e:00014c60(R)  
        0001200a eb 4a           lsl.w           #0x5,D2w
                             LAB_0001200c+2                                       XREF[0,1]:   FUN_0001455e:00014c62(R)  
        0001200c 0c 02 00 e0     cmpi.b          #E0h,D2b
                             LAB_00012010+2                                       XREF[0,1]:   FUN_0001455e:00014c5c(R)  
        00012010 66 00 18 6a     bne.w           LAB_0001387c
        00012014 eb 5a           rol.w           #0x5,D2w
                             LAB_00012016                                         XREF[1]:     FUN_0001455e:00014c5e(R)  
        00012016 02 42 00 01     andi.w          #0x1,D2w
                             LAB_0001201a                                         XREF[1]:     FUN_0001455e:00014c60(R)  
        0001201a 84 38 fc 07     or.b            (DAT_fffffc07).w,D2b

which fits with the BIOS startup code I extracted:

Code: Select all

                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                               undefined __stdcall16far BiosEntry()
             undefined         <UNASSIGNED>   <RETURN>
                             BiosEntry                                       XREF[1]:     f000:fff0(c)  
       f000:9309 fa              CLI
       f000:930a 90              NOP
       f000:930b 90              NOP
       f000:930c b0 8f           MOV        AL,0x8f
       f000:930e e6 70           OUT        0x70,AL
       f000:9310 eb 00           JMP        LAB_f000_9312
                             LAB_f000_9312                                   XREF[1]:     f000:9310(j)  
       f000:9312 e4 71           IN         AL,0x71
       f000:9314 8a e0           MOV        AH,AL
       f000:9316 80 fc 09        CMP        AH,0x9
       f000:9319 75 1a           JNZ        LAB_f000_9335

If you take 0x8F and shift to the left 5 bits, you get 0x11E0 the low byte of which is 0xE0. This suggests that $ffffc05 might be reading the value from the 286 data bus directly (although the byte swapping on the data bus, coupled with the different endianness of the processors is confusing me somewhat!), which would suggest $ffffc07 is reading from the 74HC753 in IC2 (so would contains the port number)?

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,

I attach what I have so far. I think the PAL ones are wonky as the pins don't line up. I've tried to name the GAL ones appropriately, however.

Thanks, I'll take a look. The schematic suggests IC6 is probably the key one…

It's certainly an exercise in minimalism and, with the hard disc limitations (coming in part two), it might be argued it doesn't really.

Steven