Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
The team will post updates and news about our project here

EmuTOS for Amiga and Vampirepage  1 2 3 4 5 6 7 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
08 Mar 2017 07:28


Hi Vincent,
  thanks for the details.
  The PCR and CACR look all OK.
 
 
Vincent Rivière wrote:

 
Gunnar von Boehn wrote:

    4th The Disk IO is surprisingly low? Did you enable Fast-IDE?
 

  EmuTOS IDE driver is not very fast. It uses PIO transfers and polling, interrupt is not used.
 

 
  Vampire support FAST-IDE on read.
  For safety reason we only allow fast-IDE on read atm.
  (Better safe than sorry)
  Read errors should easily be catched by the filesystem CRC and then no harm is done.
 
  Turning FAST-IDE on is pretty simple.
  You only need 1 instruction.
  MOVE.w #$8000,$DD1020
 
FAST-IDE runs PIO6 timings on READ access. All CF should support this.
With FAST-IDE setting we saw 11MB/sec - 14MB/sec read speed.
Another small trick you could do if using MOVE.L to transfer from to the IDE data register.
The 16bit data register is mapped two times after each other.
This means you can savely use MOVE.L for reading or writing to it.
Please note that 68080 can do misaligned memory reads for free.
This means very simple copy code like this:
MOVE.L (A0)+,Datareg
Will run very good.

AMIGA OS does come without filesystem cache.
So cranking up raw read speed makes a clear difference for AMIGA.
For AMIGA OS turning FAST-IDE on makes the Workbench load and run much faster. Also for big video files it gives a nice improvement.
 
Cheers
Gunnar


Markus (mfro)

Posts 99
08 Mar 2017 08:17


Gunnar von Boehn wrote:
... Read errors should easily be catched by the filesystem CRC and then no harm is done...

 
  Unfortunately, FAT16 filesystems (as used by EmuTOS) don't support CRC (and I'm actually pretty astonished about AmigaOS doing that?).
 
  Could you say something about my previous question regarding write-through caching of the ChipRAM?


Vincent Rivière

Posts 87
08 Mar 2017 10:30


Markus (mfro) wrote:
In EmuTOS, we usually know when STRAM got accessed by other bus masters (DMA) and do a cache invalidate then (currently, if I remember correctly, primarily on disk reads).

Exactly. We made big efforts to do proper cache management in EmuTOS. Now it works perfectly on ColdFire/FireBee, with full instruction/data/branch cache enabled in ST-RAM, even in copy-back mode. So I believe we reached optimal speed on the FireBee, even in ST-RAM.

Cache management is handled with classic CINVA/CPUSHA instructions. They are also currently used on Vampire, as the CPU is detected as 68040.

The only place where EmuTOS does not flush the data cache (when in copy-back mode) is in video RAM. The FireBee/BaS specifically puts the cache in write-through mode for the ST-RAM section used as video RAM, so it still works fine.

So if Vampire enables Chip RAM caches, EmuTOS will continue to run fine, maybe with some (little) additional speed.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
08 Mar 2017 21:17


Vincent Rivière wrote:

So if Vampire enables Chip RAM caches, EmuTOS will continue to run fine, maybe with some (little) additional speed.

OK I see.
Please help me real quick to understand what data is held in Chipmem all together.


Vincent Rivière

Posts 87
08 Mar 2017 21:36


As I already told, special EmuTOS optimized for Vampire does not leave much data in Chip RAM:
- CPU vectors (between 0 and 0x400)
- TOS system variables (between 0x400 and 0x800)
As Atari programs expect to find that data at fixed addresses, they can't be moved.
But compared to a segments of user programs, there are very few accesses to those areas, so I don't expect any significant boost if the data cache was enabled there.


Markus (mfro)

Posts 99
08 Mar 2017 21:41


Gunnar von Boehn wrote:

   
Vincent Rivière wrote:

    So if Vampire enables Chip RAM caches, EmuTOS will continue to run fine, maybe with some (little) additional speed.
   

   
    OK I see.
    Please help me real quick to understand what data is held in Chipmem all together.
   

   
    briefly (and not necessarily complete):
   
    - EXTERNAL LINK exception vector table
    - EXTERNAL LINK TOS system variables
    - video RAM (if not redirected elsewhere with fVDI, etc)
    - in "real Ataris": the "fast RAM buffer" (an intermediate disk buffer as ST-compatible DMA for floppy and hd cannot reach fast RAM)
    - in most games and demos: basically everything. Only very few games can use fast RAM. STs had _STRAM_ only and it's pretty common to execute code from there.
   
    and anything else I forgot to mention, of course ;)


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
08 Mar 2017 21:50


Vincent Rivière wrote:

As I already told, special EmuTOS optimized for Vampire does not leave much data in Chip RAM:
  - CPU vectors (between 0 and 0x400)
  - TOS system variables (between 0x400 and 0x800)

OK I see.
I see that caching chipmen can improve a little..
But on the other hand you can not ensure its kept in cache.
So it could be pushed out and needs to be reloaded then.

And chipmem is really 100 times slower than fastmem.
So keeping such data in fastmem would be much better.



OneSTone O2o

Posts 159
08 Mar 2017 22:43


Due to software compatibility these vectors and system variables have to stay there. Otherwise a lot of software would not run anymore.


Markus (mfro)

Posts 99
08 Mar 2017 23:21


Actually, with FPGA based hardware, there is no reason why STRAM would need to be slow or why it even needs to stay on the base ST.
 
  Basically the only constraints STRAM has is that it has to start at address 0x0 and (if you want compatibility with the original ST - which is essential, of course) that you can overlay the video memory there, that it has a max size of 14 MByte and that bus master custom chips can access it.
 
  In the ColdFire machines (i.e. FireBee), for example, physical ST RAM starts at 0x4000000 and is not connected directly to the ColdFire, but "behind" the FPGA. The MMU ensures a virtual address mapping to 0x0.
  Even better, the exception vector table does not reside in SD or FPGA RAM at all, but in the ColdFire's internal single-cycle SRAM and the OS doesn't even know about that.
 
  This can be done, but makes things a lot more complex. I would strongly recommend to start simple, but there are opportunities ...


OneSTone O2o

Posts 159
09 Mar 2017 06:35


I think when running the Vampire in an ST(E), so not standalone machine, then it's not possible to use Vampire RAM as direct ST RAM replacement, at least as long as ST(E) shifter is used for output, and DMA-Controller serves for ACSI harddisk and floppy drive, and STE-DMA-Sound is used, and blitter is used by some software. It would slow down the whole thing, because these three chips, and probably a blitter need to access this ram. And I even don't know if these chips would be able to access memory on a Vampire card. Maybe one can think if it is possible to use Vampire's RAM as a kind of CPU-Cache for ST-RAM, then CPU can access it fast, but you will need all the logics stuff to monitor real ST RAM activities to syncronize ST-RAM and the part of Vampire-RAM which represents ST-RAM for the CPU at least for DMA-controller and blitter activities. Note, that Shifter, DMA and STE-DMA-Sound only can access the lower 4 MB of this adress area due to limitations of GLUE/MMU-chipset. (all kind of "altram" extensions between 4 and 14 MB should be taken out of an ST running with a Vampire, that makes no sense) (in a Falcon-Vampire the whole lower 14 MB must be synced with ST-RAM on the card)


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
09 Mar 2017 10:24


Markus (mfro) wrote:

  Even better, the exception vector table does not reside in SD or FPGA RAM at all, but in the ColdFire's internal single-cycle SRAM and the OS doesn't even know about that.
 

 
Yes, this is not complex at all.
We did this also many years ago on the NATAMI 68060 CPU card.
The CPU card did offer extra caches, also a decicaded cache for the Vectortable.
As long you do not do stuff like using the Blitter to write to Vector table this works just fine.
 
Of course there are several options.
One could also just MMU map the Vector table into fastmem.
 


Markus (mfro)

Posts 99
09 Mar 2017 11:40


Gunnar von Boehn wrote:

      Yes, this is not complex at all.
   

   
    I would think (not really verified, so this is more of a theoretical "fooling around") that with the relatively simple ST design, it should be possible to maintain an always-current shadow of the ST RAM in the Vampire's fast RAM at _no_ extra cost (performance-wise).
   
    To my knowledge (apologize upfront if I write something wrong about things Amiga I don't know about), original Amiga and Atari designs are somewhat similar in both using the "free" RAM access cycles of the 68000 (while this is contemplating about the instruction it just fetched).
   
    On the Amiga, all custom chips more or less compete for these "free" cycles while they are reserved exclusively for the Shifter in the Atari (creating some kind of poor man's dual ported memory this way).
   
    All the other Atari bus mastering custom chips are "respectable citizens" of the m68k bus protocol and behave exactly the same as the CPU itself. The only thing that shortcuts the bus protocol (directly accessing memory) is the Shifter and that does just reads.
    This means that everything that writes to ST RAM uses the same bus signals and protocol available at the CPU socket. This should make it easy to maintain a 1:1 copy of ST RAM in Vampire memory by just snooping the bus (even when the CPU is not bus master) and act accordingly on the FPGA side at no extra costs (besides a few extra gates).
   
    Not sure if it would be worth the effort, but at least it should be possible if needed.
   
   


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
10 Mar 2017 22:48


Markus (mfro) wrote:

Gunnar von Boehn wrote:

      Yes, this is not complex at all.
     

     
      I would think (not really verified, so this is more of a theoretical "fooling around") that with the relatively simple ST design, it should be possible to maintain an always-current shadow of the ST RAM in the Vampire's fast RAM at _no_ extra cost (performance-wise).

Actually wee have this feature (optionally)


Vincent Rivière

Posts 87
12 Mar 2017 10:35


You may have noticed that my FreeMiNT screenshots were very basic. This is because I wanted to debug things step by step. And so far, everything worked fine. So I tried something more interesting.

The most complete and user-friendly FreeMiNT distribution nowadays is the excellent BeeKey by Philippe Noble: EXTERNAL LINK  More than FreeMiNT stuff, it is actually a bootable media for PC, Mac and Raspberry Pi. It contains a bootable GNU/Linux, the ARAnyM and Hatari Atari emulators, and actual FreeMiNT distribution named EasyAraMint. It includes many useful programs.

To give a try on Vampire, I extracted the FreeMiNT distribution from BeeKey, made minor changes to deal with partitions, replaced FreeMiNT kernel with newer one, and added my fVDI driver for SAGA.

Result: EXTERNAL LINK  I used 840x525 resolution as it is the most comfortable for my monitor, other ones would have worked equally well.
You can see that it is completely similar to the BeeKey screenshot on the download page.

Basically, it just works fine, with the following exceptions:

- BeeKey is provided with NVDI (extended graphics driver, mainly useful for printing when combined to fVDI). While it works fine with WinUAE, it hangs on Vampire. This is certainly due to some incompatibility with the SAGA fVDI driver. As this stack of VDI stuff is not really clean, I'm not really worried. This could be debugged later, if it is worth (IMHO: it is not).

- BeeKey contains many recent programs, such as NetSurf, zView, etc. Included binaries are compiled with GCC 4.x and optimized for 68030. But for many years, those binaries have also checked for the presence for FPU at startup. They refuse to run if no FPU is present, even if they don't use the FPU themselves. This is why many binaries included in BeeKey don't start on Vampire (they do on WinUAE + FPU)

Regarding to the Apollo 68080: everything just work as expected, as usual :-)


Wawa T

Posts 695
12 Mar 2017 18:30


as just a side note, appears to me that atari community is much better at adopting open source standards and working together on system replacements with a certain perspective, rather than insisting on some stupid names and trademarks. well done and good luck, guys. makes me wish i have became an atari fan in the first place ;).


OneSTone O2o

Posts 159
13 Mar 2017 13:38


Wawa, you still can start to be... EmuTOS even works on Amiga. You can start with a highend atari compatible now, based on your Amiga. And a 1040 as a gaming/scene-demo machine isn't expensive, too (but you might find some games and demos quite poor compared to similar on Amiga).
   
  The point is that we had some big luck that Digital Research Inc. (DRI) which developed GEM was later bought by Caldera and they put all the DRI software (CP/M, MP/M, GEM, DR-DOS, ...) to Open Source. Additionally, Eric Smith's multitasking OS (MiNT, MiNT is not TOS, MiNT is now TOS, "MultiTOS") was Open Source from beginning and is mostly compatible to GNU sources. With that the community started to construct an open source alternative for TOS, specially for use in emulators, that's EmuTOS which is also capable to run on the original machines (it does not support some TT and Falcon hardware, like their SCSI controller, DSP hardware, etc. until now). And MiNT is also still alive, supported by some engaged developers, they even took over many interesting things from GNU/Linux to MiNT, mot of the GNU utilities, additional file system drivers (ext2, fat32, minixfs), TCP/IP networking, X-Window, ...). Also something similar to your Picasso96 middleware is there, but Open Source, that's fvdi about what you can see Vincent talking here often.
   
  But meantime, since some years we have even access to the original TOS 2.06/3.06 sources, but initially nobody understood what it is*, and now some guys managed in the last year to be able to compile this (with quite old compiler), so we are even able to compile byte by byte identical TOS files from these sources as ATARI did by themselves in about 1992. Next step would be to rework that to use modern compiler, but then, that's clear, it will not be byte by byte identical to original ROM files. This also would mean that we can add new functionality to orignal TOS now. But it's still unclear if this is legal, nobody has an idea if the ATARI "fork" of GEM falls also under GPL as DRI GEM does. (Medusa computer even has the full source code of TOS 4.04 (Falcon), but they can't hand it out due to licence agreement with ATARI Corp in the mid 90's)
   
  * Note: In the same archive circuit diagrams of ST-Blitter chip, never released Panther Console, Blossom chip (graphics chip of Panther and ATW 800 transputer workstation), circuit board files for STE+ (with additionally 286 chip, never released), Falcon 030, Falcon Microbox, etc. have been discovered recently.


Vincent Rivière

Posts 87
29 Apr 2017 13:04


EmuTOS 0.9.8 has just been released.
It contains all Amiga improvements and Vampire support which had previously been available in development snapshots.

The most significant feature is a full-featured EmuTOS floppy for Amiga. It allows to run EmuTOS from floppy, in RAM, just like a game. Then it disappears on reset. Do not fear to lose your beloved AmigaOS ;-)

This new release is available there:
EXTERNAL LINK 
Download emutos-amiga-floppy-0.9.8.zip.
Then extract emutos-vampire.adf. This floppy image is optimized for Vampire, mainly it runs in FastRAM. It is significantly faster than the other one.

You can write this ADF on a real floppy, or better use a Gotek or HxC floppy emulator.

Enjoy!


Kolbjørn Barmen
(Needs Verification)
Posts 219/ 2
29 Apr 2017 22:05


Just tossing out a crazy idea here...

EmuTOS launched from WHDLoad.


David Eriksson

Posts 8
12 May 2017 13:41


This is really cool! Is it possible to install EmuTOS + MiNT on an Amiga partition or how does the harddisk support work?


Vincent Rivière

Posts 87
12 May 2017 23:11


Currently, Amiga partitions are completely unsupported by EmuTOS. You need a dedicated mass storage (CompactFlash or IDE hard disk) formatted in PC way with a FAT16 partition. Additionally, FreeMiNT also supports FAT32 and ext partitions.

posts 137page  1 2 3 4 5 6 7