Overview Features Coding Performance Forum Downloads Products OrderV4 Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Questions and Answers for using ATARI TOS / FREE MINT

Current EmuTOS Status

Peter Persson

Posts 10
03 Aug 2022 08:34


Friends,

Olivier and I have been working a bit on the EmuTOS implementation. Since things are changing rapidly I thought I'd summarise the current state of it.

- Falcon-compatible modecodes for VsetMode/VsetScreen/VgetSize/VcheckMode().
- SAGA resolutions are set using ditto calls by setting modecode bit #14 of the modecode.
- VsetRGB/Setpalette now set the palett through colorpt/VBL like TOS does.
- Physbase() operates on the actual register rather than a shadow variable like TOS does.
- Amiga vectors are now located at 0x01C0.w instead of 0x0000.w. This allows Atari applications to alter these vectors (some do) without the risk of things exploding. Atari applications typically won't touch the VBR anyway (I only know of a single application that would cause trouble, and it's highly Falcon-specific).
- Xbtimer(), Mfpint(), Jdisinit(), Jenabint() are emulated using the CIA. HBL and SDMA are not considered yet though.

This improves compatibility with Atari applications quite a bit. Any hardware access to 0x00ffnnnn or 0xffffnnnn will end up in ROM, which is kind of fortunate for writes. Reads may obviously cause confusion for the application - or not. A lot of things, like MFP interrupt handlers that need to acknowledge an interrupt, won't care.

Your mileage may vary, but there are a few positive surprises:

  - the HD-patched version of Dungeon Master works out of the box. No sound, obviously.
  - STOS (grand daddy of AMOS) seems to work but has no mouse (depends a bit on which version you're using). STOS is notoriously nasty and expects certain internal OS variables/states at a certain place. Not the documented ones.
  - Frontier Elite 2 starts, but can't reach the keyboard/mouse (it installs a kbdsys, which normally needs access to the IKBD ACIA).
  - Leisure Suit Larry 2 works (!). No sound though. Other SCI/Sierra games most likely works too, but I haven't tried it.

Most of these things loads into STRAM/chipram by default (i.e. turtle mode), but that can probably be fixed.

Frankly I didn't expect any of the above to be possible, and with some more work (I need more documentation for the Shield and MMU registers) I think compatibility can be quite good also for non-GEM applications.

All this is based on EmuTOS 1.0, and the intention is to port the changes to the upcoming EmuTOS 1.2.


Olivier Landemarre

Posts 129
04 Aug 2022 11:46


Peter Persson wrote:

  Friends,
 
  Olivier and I have been working a bit on the EmuTOS implementation. Since things are changing rapidly I thought I'd summarise the current state of it.
 
  - Falcon-compatible modecodes for VsetMode/VsetScreen/VgetSize/VcheckMode().
  - SAGA resolutions are set using ditto calls by setting modecode bit #14 of the modecode.
  - VsetRGB/Setpalette now set the palett through colorpt/VBL like TOS does.
  - Physbase() operates on the actual register rather than a shadow variable like TOS does.
  - Amiga vectors are now located at 0x01C0.w instead of 0x0000.w. This allows Atari applications to alter these vectors (some do) without the risk of things exploding. Atari applications typically won't touch the VBR anyway (I only know of a single application that would cause trouble, and it's highly Falcon-specific).
  - Xbtimer(), Mfpint(), Jdisinit(), Jenabint() are emulated using the CIA. HBL and SDMA are not considered yet though.
 
  This improves compatibility with Atari applications quite a bit. Any hardware access to 0x00ffnnnn or 0xffffnnnn will end up in ROM, which is kind of fortunate for writes. Reads may obviously cause confusion for the application - or not. A lot of things, like MFP interrupt handlers that need to acknowledge an interrupt, won't care.
 
  Your mileage may vary, but there are a few positive surprises:
 
    - the HD-patched version of Dungeon Master works out of the box. No sound, obviously.
    - STOS (grand daddy of AMOS) seems to work but has no mouse (depends a bit on which version you're using). STOS is notoriously nasty and expects certain internal OS variables/states at a certain place. Not the documented ones.
    - Frontier Elite 2 starts, but can't reach the keyboard/mouse (it installs a kbdsys, which normally needs access to the IKBD ACIA).
    - Leisure Suit Larry 2 works (!). No sound though. Other SCI/Sierra games most likely works too, but I haven't tried it.
 
  Most of these things loads into STRAM/chipram by default (i.e. turtle mode), but that can probably be fixed.
 
  Frankly I didn't expect any of the above to be possible, and with some more work (I need more documentation for the Shield and MMU registers) I think compatibility can be quite good also for non-GEM applications.
 
  All this is based on EmuTOS 1.0, and the intention is to port the changes to the upcoming EmuTOS 1.2.
 

 
  Very impressive job Peter, we have better and better Atari clone computer!

EXTERNAL LINK 
  Thanks
 


Peter Persson

Posts 10
09 Sep 2022 14:05


Thought I'd post a small status update.

By emulating IKBD/ACIA keyboard interrupts, and implementing more of the IKBD protocol, some more stuff started working, notably:

  - STOS (grand daddy of AMOS) now works (!) with the exception of some minor palette glitches which can probably be fixed. This is pretty cool.
  - TurboAss, a great assembler and editor, no longer locks up (it was very picky about the IKBD implementation).

In addition, I experimented a bit and monitored the Atari ST palette registers, and that adds color to Frontier Elite 2 (still no raster support though, so the lower part of the screen is a mess).

The cool thing is that this is all unmodified binaries, and Frontier expects hw at 0xfffffc00. Since interrupts are processed before jumping through the corresponding Atari vector location, this can be faked provided that we've got write/read access to 0xffffnnnn/0x00ffnnnn, which is the case on FPGA firmware <= 7.4.

Now, this is all highly experimental, and since I have no idea where writes/reads to 0xffffnnnn actually end up, this things shouldn't be used on an everyday basis. At least not until there's some firmware support for what we're doing.

I managed to get Apex Media (a paint program) running, which is pretty cool. All it needs is to be able to set the screen address and video mode by accessing the hw, and while that can't be faked in a good way right now, setting the screen resolution prior to starting the binary (and temporarily monitoring the Atari frame buffer address regs) was enough to get it running (where 'running' == it starts, I can paint, but the application gets a bit confused later on).

EXTERNAL LINK ... x.jpg?dl=0
EXTERNAL LINK ... m.jpg?dl=0
EXTERNAL LINK ... s.jpg?dl=0
EXTERNAL LINK ... s.jpg?dl=0



Peter Persson

Posts 10
09 Sep 2022 14:19


I think the next major issues are:
  - interrupt priorities are different (perhaps I could improve this by swapping some stuff between CIA A and B)
  - hw registers can only be faked under some circumstances. It's very useful to use RAM for this stuff, but having a mechanism based on exceptions would probably improve this a lot further (and allows for emulation of non-memory-mapped behaviour, e.g. stuff that gets triggered on bus access).


Peter Persson

Posts 10
09 Sep 2022 14:22


EXTERNAL LINK 
Flicking is, as I mentioned, because I don't emulate rasters (yet), and there's some funny thing with the FPGA in 1-4bpp interleaved bitplane modes and certain screen resolutions. Also, David Braben doesn't wait for VBL in the intro, what an arse.

But it's an unmodified binary (!).


Niclas A
(Apollo Team Member)
Posts 219
09 Sep 2022 22:22


I don't post that much any more, but some things just needs a comment. Your progress is very impressive. Keep up the excellent job!.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
15 Sep 2022 16:00


Thanks for progress. I have great love for MacOS Classic and EmuTOS/MINT side of V2 cards (and hope it works on V4 too).

Questions is simple - where to get latest FreeMINT/EmuTOS for V2, if possible bundled with all apps that work? Is there an easy way to install it to separate partition?

Does press FIRE magic still works on boot?
EXTERNAL LINK 
And last, but not least, when sound and net drivers work and will I be able to utilise PCMCIA Wi Fi card under MINT?

Thanks.

P.S.
Can we expect some ST/TT emulator bundled, preferably transparent like JanusUAE, that would enable some DTP software, Atomix, Strip poker etc. :)


Peter Persson

Posts 10
15 Sep 2022 19:13


The most recent stuff I've done haven't been released yet, since it relies on a little side effect of the memory map on firmware 7.2 and 7.4. Before this can be released, we need to know that the memory map functions a certain way (or can be made to function a certain way).

This thing isn't really an Atari emulator; it's a port of EmuTOS with some compatibility tweaks.


Olivier Landemarre

Posts 129
15 Sep 2022 19:58


Vojin Vidanovic wrote:

Thanks for progress. I have great love for MacOS Classic and EmuTOS/MINT side of V2 cards (and hope it works on V4 too).
 
  Questions is simple - where to get latest FreeMINT/EmuTOS for V2, if possible bundled with all apps that work? Is there an easy way to install it to separate partition?
 
  Does press FIRE magic still works on boot?
  EXTERNAL LINK 
  And last, but not least, when sound and net drivers work and will I be able to utilise PCMCIA Wi Fi card under MINT?
 
  Thanks.
 
  P.S.
  Can we expect some ST/TT emulator bundled, preferably transparent like JanusUAE, that would enable some DTP software, Atomix, Strip poker etc. :)

There is an quite old configuration ready to boot provide by Willem I have done a bit long time ago.
I'm preparing a more advanced configuration, but now it is available for developper for do our stability test.

To boot on Emutos press fire button still work as I know
To boot you need a first partition in Fat16 but not too big to work correctly with Emutos, I have a partition of 128Mb this partition can be read by Emutos to boot. Then I have a far bigger partition in FAT32 but you can have ext2 partition too that can work with freemint but not by Emutos (FAT32 too can't be read by Emutos)

This partition can be on PCMCIA card or on SD card

For moment not expect have emulator for Atari ST in it, this is possible but efficient one not exist for the moment and we not have any plane for this.

Olivier



Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
15 Sep 2022 20:19


Olivier Landemarre wrote:

  This partition can be on PCMCIA card or on SD card
 
  For moment not expect have emulator for Atari ST in it, this is possible but efficient one not exist for the moment and we not have any plane for this.
 
  Olivier
 

Merci becoup, great instructions. Will help my software setup.
Can you mail me link to this dev arch, I like being ginny pig from user side, free beta tester :)

Which STE/TT *Falcon? emulator is best for OS3? Is there a Jag emu :)



Cyprian K

Posts 23
22 Sep 2022 08:53


Peter Persson wrote:

Thought I'd post a small status update.
 
  By emulating IKBD/ACIA keyboard interrupts, and implementing more of the IKBD protocol, some more stuff started working, notably:
 
  - STOS (grand daddy of AMOS) now works (!) with the exception of some minor palette glitches which can probably be fixed. This is pretty cool.
  - TurboAss, a great assembler and editor, no longer locks up (it was very picky about the IKBD implementation).
 
  In addition, I experimented a bit and monitored the Atari ST palette registers, and that adds color to Frontier Elite 2 (still no raster support though, so the lower part of the screen is a mess).
 
  The cool thing is that this is all unmodified binaries, and Frontier expects hw at 0xfffffc00. Since interrupts are processed before jumping through the corresponding Atari vector location, this can be faked provided that we've got write/read access to 0xffffnnnn/0x00ffnnnn, which is the case on FPGA firmware <= 7.4.
 
  Now, this is all highly experimental, and since I have no idea where writes/reads to 0xffffnnnn actually end up, this things shouldn't be used on an everyday basis. At least not until there's some firmware support for what we're doing.
 
  I managed to get Apex Media (a paint program) running, which is pretty cool. All it needs is to be able to set the screen address and video mode by accessing the hw, and while that can't be faked in a good way right now, setting the screen resolution prior to starting the binary (and temporarily monitoring the Atari frame buffer address regs) was enough to get it running (where 'running' == it starts, I can paint, but the application gets a bit confused later on).
 
  EXTERNAL LINK ... x.jpg?dl=0
  EXTERNAL LINK ... m.jpg?dl=0
  EXTERNAL LINK ... s.jpg?dl=0
  EXTERNAL LINK ... s.jpg?dl=0
 

well done

thanks for your support


posts 11