exxos's Atari, Amiga & retro forum

Kochise wrote: 10 Sep 2026 20:55 ...

Blimey! You're faster at plugging my videos than I am!

Thanks :lol:

BW

I always appreciate watching your videos. Never knew this device existed. Too bad the company decided to go with a 286 and not something more period correct, like a 386 CPU.

Would be worthwhile testing games on this in the future (anything from Sierra or Commander Keen series) I wonder how it handles sound in DOS or joystick controls.

Maybe the cost and/or implementation difficulty of a 386 are significantly higher than of a 286.

To get basic x86 compatibility, a 286 is enough.

leonk wrote: 11 Sep 2026 04:43 I always appreciate watching your videos. Never knew this device existed. Too bad the company decided to go with a 286 and not something more period correct, like a 386 CPU.

Would be worthwhile testing games on this in the future (anything from Sierra or Commander Keen series) I wonder how it handles sound in DOS or joystick controls.

Many thanks.

I get the impression this was a bit of a testing of the water product. I suspect they didn't make enough money to convert the rest of their lines.

Outrun in CGA mode works very nicely. I think I tried Prince of Persia briefly, but then got stuck down a hard disc and windows rabbit hole. That's for the second part in the series!

Unfortunately from DOS only CGA graphics modes seem to be available. There is a windows driver for mono or dithered colour VGA. The software itself seems to be a significant restriction.

It would be really interesting if someone were able to reverse engineer the software side next. We could probably update it and get it doing something really useful.

It is quite impressive how few components are actually needed to get an emulator running, though. A lot of work must be going on in that software.

I need to decompile the GAL jeds and see what the equations are at some point.

Cheers,

BW

Badwolf wrote: 11 Sep 2026 09:41 It would be really interesting if someone were able to reverse engineer the software side next. We could probably update it and get it doing something really useful.

It is quite impressive how few components are actually needed to get an emulator running, though. A lot of work must be going on in that software.

I need to decompile the GAL jeds and see what the equations are at some point.

Have you looked at Atari's service manual STE+, which integrated a 286 onto the STe motherboard (along with IDE)? That gives some clues on how the STE+ worked:

AT-Mode allows the STE+ system to run DOS compatible software. It uses an 80286 processor attached to the 68000 bus. When the 68000 reads from location FFFC80, control logic generates a Bus Request (BREQ) to the 68000 and disables the HOLD to the 80286 causing the 68000 to relinquish control of the bus. When the 80286 disables the Hold Acknowledge (HLDA), the 80286 takes control of the bus and runs code directly out of the same system RAM area. The 80286 processor runs Intel compatible code that is byte swapped from the 68000 perspective. When any 80286 I/O instruction occurs, the HOLD is asserted to the 80286 thereby releasing BACK to the 68000 and relinquishing control back to the 68000 processor.

I'd be surprised if the (PC|AT|Falcon)Speed, worked any differently -- in fact, I'm sure I read somewhere that the STE+ basically integrated the ATSpeed into the motherboard…

Steven

SteveBagley wrote: 11 Sep 2026 12:33 Have you looked at Atari's service manual STE+, which integrated a 286 onto the STe motherboard (along with IDE)? That gives some clues on how the STE+ worked:

I was only vaguely aware of the STE+, so that's interesting in and of itself. Thanks.

AT-Mode allows the STE+ system to run DOS compatible software. It uses an 80286 processor attached to the 68000 bus. When the 68000 reads from location FFFC80, control logic generates a Bus Request (BREQ)

And sure enough there's an enormous 13-way NAND chip in the logic that would trigger on (at a minimum) F7F804. That would include FFFC84 (Although not 80...) and the PLD it feeds, which controls the bus arbitration signals, also listens on A1 and A9. I suspect A9 is being tested to be low (making FFFC a likely target) and there are feeds coming from the other PLDs that listen to more addresses.

It certainly sounds like that's the range at least.

I need to do some GAL work anyway. I think this may be the little diversion I need whilst waiting for my next project board to arrive. :)

BW

There had to be an Amiga remark in there...
I'm 100% sure that if Frontier was written to use the Amiga custom chips that it would run much better than the period correct Atari 520ST
(both with memory expansions to 1MB ofcourse)

Maximilian wrote: 11 Sep 2026 14:20 There had to be an Amiga remark in there...
I'm 100% sure that if Frontier was written to use the Amiga custom chips that it would run much better than the period correct Atari 520ST
(both with memory expansions to 1MB ofcourse)

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

Steven

Maximilian wrote: 11 Sep 2026 14:20 There had to be an Amiga remark in there...

😇