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 

David Eriksson

Posts 8
13 May 2017 08:44


Okay, makes it a bit more cumbersome to try. Are there any plans to make some sort of "Give EmuTOS a partition it can use as a harddrive" support? Kinda like how it worked with ShapeShifter and partitions on the amiga.


Vincent Rivière

Posts 87
05 Jun 2017 23:21


EmuTOS is an operating system, not an emulator. So it needs real hard disks. There are no plans to make it cohabit with AmigaOS on the same hard disk, while this could theoretically be done.


Vincent Rivière

Posts 87
05 Jun 2017 23:24


FreeMiNT has just been patched to detect the Apollo 68080 as Motorola 68040, as advised by the Apollo Team:
EXTERNAL LINK     
As a result, PmDoom (Atari Doom) works fine on Vampire/Saga:
EXTERNAL LINK   
   
Latest FreeMiNT:
EXTERNAL LINK     
Latest PmDoom (use 68000 version):
EXTERNAL LINK


Stefan Niestegge

Posts 33
13 Jun 2017 11:15


Yesterday i got my Vampire. Setup was easy.

EXTERNAL LINK


Vincent Rivière

Posts 87
13 Jun 2017 16:03


Yeah! Exactly as expected :-)


Simo Koivukoski
(Apollo Team Member)
Posts 601
13 Jun 2017 16:37


Nice video!


Markus (mfro)

Posts 99
17 Jun 2017 09:45


Anyone knows why Kronos reports less than 40 MHz in the CPU diagnostics when it's supposed to be more like 80 at least?


Olivier Landemarre

Posts 147
17 Jun 2017 10:50


Markus (mfro) wrote:

Anyone knows why Kronos reports less than 40 MHz in the CPU diagnostics when it's supposed to be more like 80 at least?

Yes I know, I detect 68060 and this CPU is able to do 2 instructions per cycle (and I don't know why because I do what I can to not be able to do this but 68060 do it so as I not want to redesign a new test I divide the result by 2) while 68080 do only one (logical), so  68080 the frequency should be multiplied by 2! I'm going to add 68080 detection and fix this issue.

Olivier




Markus (mfro)

Posts 99
17 Jun 2017 12:47


I would assume that if you code your timing loop in a way that each instruction is dependend of the result of the previous one, you should be able to avoid it to go superscalar.
 
  Like:
 
  move.w    d0,d1
  add.w    d1,d2
  move.w    d2,d3
  ...
 
  if it's smart enough to overcome this, I guess it pretty much deserves the higher score ;)


Uros Vidovic

Posts 31
17 Jun 2017 12:56


Is this the same problem as with the FireBee and Coldfire CPU?
 


Markus (mfro)

Posts 99
17 Jun 2017 13:45


Uros Vidovic wrote:

Is this the same problem as with the FireBee and Coldfire CPU?

Not clear what you mean. Although advertised as such, ColdFires aren't really superscalar. They can do instruction folding on a limited number of certain move access patterns only.



Uros Vidovic

Posts 31
17 Jun 2017 15:17


Markus (mfro) wrote:

Uros Vidovic wrote:

  Is this the same problem as with the FireBee and Coldfire CPU?
 

 
  Not clear what you mean. Although advertised as such, ColdFires aren't really superscalar. They can do instruction folding on a limited number of certain move access patterns only.
 

If you run Kronos on the FireBee in FireTOS you get result of the 130,5 MHz Coldfire CPU. That is the half of the real value.



Olivier Landemarre

Posts 147
17 Jun 2017 20:22


Uros Vidovic wrote:

Markus (mfro) wrote:

 
Uros Vidovic wrote:

  Is this the same problem as with the FireBee and Coldfire CPU?
 

 
  Not clear what you mean. Although advertised as such, ColdFires aren't really superscalar. They can do instruction folding on a limited number of certain move access patterns only.
 
 

  If you run Kronos on the FireBee in FireTOS you get result of the 130,5 MHz Coldfire CPU. That is the half of the real value.
 

I detect coldfire but same issue, I don't know why I divide by 2 as for 68060, so it looks wrong.



Olivier Landemarre

Posts 147
17 Jun 2017 20:25


Markus (mfro) wrote:

I would assume that if you code your timing loop in a way that each instruction is dependend of the result of the previous one, you should be able to avoid it to go superscalar.
 
  Like:
 
  move.w    d0,d1
  add.w    d1,d2
  move.w    d2,d3
  ...
 
  if it's smart enough to overcome this, I guess it pretty much deserves the higher score ;)

This what I thought to do but too simple in my case I should rewrite it:

movel d1,d0
movel d0,d1
movel d1,d0
movel d0,d1
...



Henryk Richter
(Apollo Team Member)
Posts 128/ 1
17 Jun 2017 21:14


Olivier Landemarre wrote:

  This what I thought to do but too simple in my case I should rewrite it:
  movel d1,d0
  movel d0,d1
  movel d1,d0
  movel d0,d1
  ...

How about:
  add.l d1,d0
  add.l d2,d0
  add.l d1,d0
  add.l d2,d0
  ...
Will run in first pipe only on superscalar CPUs.


Markus (mfro)

Posts 99
18 Jun 2017 08:27


Olivier Landemarre wrote:

 
Markus (mfro) wrote:

    Anyone knows why Kronos reports less than 40 MHz in the CPU diagnostics when it's supposed to be more like 80 at least?
   

   
    Yes I know, I detect 68060 and this CPU is able to do 2 instructions per cycle (and I don't know why because I do what I can to not be able to do this but 68060 do it so as I not want to redesign a new test I divide the result by 2) while 68080 do only one (logical), so  68080 the frequency should be multiplied by 2! I'm going to add 68080 detection and fix this issue.
   
    Olivier
 

 
  Anyway, this is what I understand:
  - you divide your result by 2 because your timing loop gets executed on 68060 on both pipes in parallel
  - you do the same on the Apollo core because it's supposed to behave identical
  - you do the same on the ColdFire (where it's clearly wrong)
 
  Doesn't that mean the Apollo core isn't as superscalar (yet?) as it's supposed to be?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
18 Jun 2017 08:42


Markus (mfro) wrote:

Doesn't that mean the Apollo core isn't as superscalar (yet?) as it's supposed to be?

This only means that this code triggered our PARANIO broken code detection.


Markus (mfro)

Posts 99
18 Jun 2017 09:12


Gunnar von Boehn wrote:
... PARANIO broken code detection...
 

 
  You just made me really curious. What's that?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
18 Jun 2017 11:12


Markus (mfro) wrote:

You just made me really curious. What's that?

If you want to execute many instructions per cycle then use this code


MOVE.L D0,D1
ADD.L  D2,D1
MOVE.L D0,D4
ADD.L  D3,D4

With this code Apollo will give an IPC of 4

The Paranioa check forbids executing with cross operants.


move.l D0,D1
move.l D1,D0

This check can be disabled then the code will execute with IPC=2



Markus (mfro)

Posts 99
18 Jun 2017 18:45


Gunnar von Boehn wrote:

...
  The Paranioa check forbids executing with cross operants.
 

  move.l D0,D1
  move.l D1,D0
 

  This check can be disabled then the code will execute with IPC=2

Thank you. Now I know what it is, but not it's purpose.

I know what paranoia is ;), but if the sequence can be executed with IPC=2 _and_ yields correct results, why did you disable it first place (compromising 060 compatibility)?

posts 137page  1 2 3 4 5 6 7