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
Performance and Benchmark Results!

World Record ATARI FreeMiNT Kronos 68080-FPUpage  1 2 3 4 5 6 

Olivier Landemarre

Posts 147
03 Dec 2017 15:43


oneSTone o2o wrote:

Gunnar von Boehn wrote:

  So the 68080 is basically an 68060B++ ...
 

 
  ... currently still without 68k compatible PMMU ...

It's only an issue if you want replace 68060 by 68080 on existing hardware to run TOS, in fact same problem in the past with CT60, Hades60 or coldfire to run TOS with this hardwares. With standalone V4 Emutos is already able to manage this.



Olivier Landemarre

Posts 147
03 Dec 2017 19:52


Account for sale wrote:

Olivier Landemarre wrote:

  With standalone V4 Emutos is already able to manage this.
 

 
  EmuTOS provides memory protection using the MPU?

Emutos as TOS not do any protection memory. This is to Mint to do this, source code is available, fix this is quite more easy and clean than patch TOS, there is for 68060 there will have for 68080.
Strange to be focus on this point, nobody complain 68060 was not compatible with 68040. Today for sure find someone to patch TOS for 68080 is probably difficult to find, Didier Mequignon left Atari scene, but find someone to add 68080 in Mint is quite more realist.




Markus (mfro)

Posts 99
04 Dec 2017 21:07


Account for sale wrote:

 
Olivier Landemarre wrote:

  With standalone V4 Emutos is already able to manage this.
 

 
  EmuTOS provides memory protection using the MPU?
 

 
  No. I think what Olivier wanted to say that - being open source - it's quite easy to adapt EmuTOS to any reasonably m68k-compatible machine. It is available for plain 68000, 020-04, 060 and ColdFire. It's also quite easy to adapt it for non-Atari and not (fully) Atari-compatible hardware (like the Hades, the CT60, Milan and the ColdFires. It's a lot simpler and faster to (re-) write a few lines of code in a stable, proven source base than to binary patch an existing OS (as Vincent already impressively showed for the Vampire).
  With FreeMint, we have a true preemptive multitasking system (available as Open Source as well) that can run on top of original Atari TOS (or EmuTOS). It "just" (in quotes, because this is a sacre resource nowadays) needs a reasonably talented coder to get this up and running.


Markus (mfro)

Posts 99
05 Dec 2017 06:40


Account for sale wrote:

... I was confused over how fast it went from "without 68k compatible PMMU" to "only an issue when replace 68060 by 68080 on existing hardware to run TOS" and to "standalone V4 Emutos is already able to manage this", as if all Atari related MMU issues are already solved with EmuTOS...

EmuTOS contains code for basic initialisation of the MMU (where this isn't done by firmware already like on the FireBee or m5484lite) for all Motorola/Freescale CPUs it supports. It however just does whats necessary to make the memory contiguously accessible to provide an Atari compatible memory map.

There is no attempt to actively *use* the MMU, however (as in paging or memory protection). That's left to FreeMiNT.


Thierry Atheist

Posts 644
05 Dec 2017 10:47


Markus (mfro) wrote:
It however just does whats necessary to make the memory contiguously accessible to provide an Atari compatible memory map.

Hi Markus (mfro),

What is the maximum addressable RAM by TOS?


Markus (mfro)

Posts 99
08 Dec 2017 17:58


Thierry Atheist wrote:

  Hi Markus (mfro),
 
  What is the maximum addressable RAM by TOS?
 

 
I'd say 2^32-1. You could build an Atari with close to 4 GB RAM.


Vincent Rivière

Posts 87
11 Dec 2017 21:49


TOS functions return error codes as negative numbers. Pointers in the 2GB-4GB area would be misinterpreted at some places. So we can safely assume that TOS can address 2 GB of RAM, but no more.


Stefan Niestegge

Posts 33
13 Dec 2017 18:12


Hi folks,
   
  i made this screenshot with a Gold 2.7 beta with partial HardFPU.
   
  Remember this is a beta core from development.
  As features still get added, final scores could be lower or higher.
   
  All FPU commands needed by Kronos FPU test are implemented. The 3D OpenGL test would still fail, so i ran it with 68000 mode (no FPU)
   
 

full size: EXTERNAL LINK


Olivier Landemarre

Posts 147
13 Dec 2017 21:29


Hello, looks like memory access is low compare to CT60 while CPU and FPU tests are fast, it was not what I remember from previous tests.
 
  Could we have hardware result screenshot? like this:
  EXTERNAL LINK 
  I have a corrected value for frequency, it is in test on real Atari since yesterday computer to fix issues.
 
  Thanks
  Olivier
 
  Olivier
 
 
Stefan Niestegge wrote:

  Hi folks,
     
    i made this screenshot with a Gold 2.7 beta with partial HardFPU.
     
    Remember this is a beta core from development.
    As features still get added, final scores could be lower or higher.
     
    All FPU commands needed by Kronos FPU test are implemented. The 3D OpenGL test would still fail, so i ran it with 68000 mode (no FPU)
     
   
 
  full size: EXTERNAL LINK 

 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 21:33


Olivier Landemarre wrote:

  Hello, looks like memory access is low compare to CT60
 

 
Actually to memory speed of the VAMP is many times faster.
 
 
But KRONOS is not a pure CPU test.
KRONOS does a mix of CPU, operating system benchmark, and driver benchmark.
 
KRONOS does not compare memory speed here, but also included chipmem speed, for the GFX speed  also measures the quality of the software Video driver.

Of the 68060 and the VAMP would be measured with the same OS version, then result would be much clearer to compare.
 
 


Vincent Rivière

Posts 87
13 Dec 2017 21:47


Stefan Niestegge wrote:

    i made this screenshot with a Gold 2.7 beta with partial HardFPU.

Very good :-)

Gunnar von Boehn wrote:

  KRONOS does not compare memory speed here, but also included chipmem speed, 

Strangely, proper memory tests are only given on the "hardware result" page. This is why Olivier asked for that screenshot.


Olivier Landemarre

Posts 147
13 Dec 2017 22:05


Yes and not depending what you are looking

For example small opengl like test, is cut in two, one is pure CPU + FPU + memory use something quite more realistic than any CPU test and the second test is same thing but with video dependant.

The first case is represented in this example:
EXTERNAL LINK 
in the reference "mothercard perf", this is quite interesting because CPU, FPU looks very nice but opengl comparison looks quite low but as it's video dependant it's not very usefull why I would like to see hardware info, but looks memory acces is reduced compare with CT60 (there is probably a reason) on CT60 TTram acces is directly proportional with CPU frequency (100MHz -> 100Mb/sec in read and write), and Vincent results as you can see in the link on vampire memory acces was very nice (120 - 150 Mb/sec).
But here looks not so I was interested on this result, and perhaps have an idea of this change (propably simple difference of cache setting).

Really nice job.

Hope be able to buy V4 standalone to work a bit on it!

Thanks again for this great job.

Olivier

Gunnar von Boehn wrote:

Olivier Landemarre wrote:

    Hello, looks like memory access is low compare to CT60
   

   
  Actually to memory speed of the VAMP is many times faster.
   
 
  But KRONOS is not a pure CPU test.
  KRONOS does a mix of CPU, operating system benchmark, and driver benchmark.
 
  KRONOS does not compare memory speed here, but also included chipmem speed, for the GFX speed  also measures the quality of the software Video driver.
 
  Of the 68060 and the VAMP would be measured with the same OS version, then result would be much clearer to compare.
   
   




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 22:09


Olivier Landemarre wrote:

  Yes and not depending what you are looking
   
  For example small opengl like test, is cut in two, one is pure CPU + FPU + memory use something quite more realistic than any CPU test and the second test is same thing but with video dependant.
   
  The first case is represented in this example:
 

 
Salut Olivier,
 
Is it possible to get the ASM  / DISASM of these tests?
To see and better understand what is done?
 
Do I understand this correct?
I see here 3 columns : TTRAM  / STRAM / VIDEO RAM
and then the rows READ and WRITE?
So we have 6 results.
What code block is executed for each of them?


Olivier Landemarre

Posts 147
13 Dec 2017 22:40


Hello Gunnar,

test is quite simple, it not try to give fastest result except for video it do simple move.l from register to memory or from memory to register, it not use even movem that not exist under coldfire.

For memory it is driver dependant using VDI vro_cpyfm the recommended way to copy to/from memory hardware acceleration are take into account and some target (I'm thinking to Aranym emulator) are not to directly acces to video memory.

Kronos is designed to compare computer to computer and not try to have the fastest result, so probably never give maximum memory speed using 68080 extension instructions, but probably one day there will have opengl target for 68080 when Tinygl will be adapted to this new features as it is interesting to have 68080 capacity idea in real life.

Olivier
Gunnar von Boehn wrote:

Olivier Landemarre wrote:

    Yes and not depending what you are looking
   
    For example small opengl like test, is cut in two, one is pure CPU + FPU + memory use something quite more realistic than any CPU test and the second test is same thing but with video dependant.
   
    The first case is represented in this example:
   

   
  Salut Olivier,
 
  Is it possible to get the ASM  / DISASM of these tests?
  To see and better understand what is done?
 
  Do I understand this correct?
  I see here 3 columns : TTRAM  / STRAM / VIDEO RAM
  and then the rows READ and WRITE?
  So we have 6 results.
  What code block is executed for each of them?




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 22:48


Olivier Landemarre wrote:

Hello Gunnar,
 
test is quite simple, it not try to give fastest result except for video it do simple move.l from register to memory or from memory to register, it not use even movem that not exist under coldfire.

Ok thanks.
To better understand it - it would help me a lot to see
some real ASM lines, and to know what EA modes are used.
Can you show me some real ASM please?

Also for the Video speed, its worth to note that the video mem has the same speed on the Vampire as the fastmem = this means if you can write to fastmem with 150 MB/sec the same score should be possible for the video mem.


Stefan Niestegge

Posts 33
14 Dec 2017 19:00


Hello Olivier,

here: EXTERNAL LINK 



Olivier Landemarre

Posts 147
14 Dec 2017 21:06


Hello Stefan,

very very nice results in fast ram (TT Ram), it is very fast memory waouh!

But opengl test is very slow compare to result I have on CT60 100Mhz, motherboard speed value is around at 1130

STram I think is abnormaly slow (slower than CT60 accessing to host memory ram on slow bus of the Falcon!) but this memory should not be used for the opengl test.

Perhaps you stay on 68040 option as Kronos detect 68040 processor, while if you select manually 68881 results should probably faster.

I not understand why opengl test is slow as CPU, FPU and memory looks fast individually. Perhaps you could share .ABH file of your results?

Thanks, nice to see this

Olivier

Stefan Niestegge wrote:

Hello Olivier,
 
  here: EXTERNAL LINK 
 




Stefan Niestegge

Posts 33
14 Dec 2017 21:23


Olivier Landemarre wrote:

  Hello Stefan,
 
  very very nice results in fast ram (TT Ram), it is very fast memory waouh!
 
  But opengl test is very slow compare to result I have on CT60 100Mhz, motherboard speed value is around at 1130
 
  STram I think is abnormaly slow (slower than CT60 accessing to host memory ram on slow bus of the Falcon!) but this memory should not be used for the opengl test.
 
  Perhaps you stay on 68040 option as Kronos detect 68040 processor, while if you select manually 68881 results should probably faster.
 
  I not understand why opengl test is slow as CPU, FPU and memory looks fast individually. Perhaps you could share .ABH file of your results?
 
 

 
 
  Hi Olivier
 
  the slow ST-RAM is understandable, because Falcon STRAM access is 16MHz while Amiga chipmem is ~8MHz.
 
  The OpenGL test of Kronos will crash with an illegal instruction, because the hardFPU core i used does not yet support EVERY FP instruction an 040 FPU has. Therefore i had to run that particular OpenGL test with choosing "68000" instead of the detected "68040"
 
  The Atari has no soft-FPU like MacOS for 68k has or FEMU for AmigaOS.
 
  Or is there something to enable Ataris with 68EC0x0 (which are FPU-less) run code compiled for 68040-060?
 
  If so, it could be modified to just emulate the missing opcodes.
  Otherwise, for a complete OpenGL test in full speed, we need to wait for a complete 040 hard FPU in Apollo Core.
 
  It would help to know which FPU instructions the OpenGL test uses.
  I don't know, is there some source of Kronos available?
 
  Regards,
  Beetle


Olivier Landemarre

Posts 147
14 Dec 2017 21:24


Hello Gunnar,

Video read, write is different from other test at several point

Read and write are from/to video memory to/from fastram (TT Ram)
and memory to memory is from video memory to video memory

So in theory we should have similar value in your case to value found to copy from memory to memory and looks we have around the half I fully agree with you, but this test rather directly copy memory to memory use VDI function vro_cpyfm to copy an area of video screen somewhere else. Probaly routine is not optimized, I'm sure with optimized routine we should have perhaps even better result than my own simple linear copy routine. It depend of Emutos, not Kronos.

memory copy is quite simple it copy a bloc on itself reversing memory with 32 move.l (a1)+,-(a0) in a loop to move 65536 bytes

Olivier

Gunnar von Boehn wrote:

Olivier Landemarre wrote:

  Hello Gunnar,
 
  test is quite simple, it not try to give fastest result except for video it do simple move.l from register to memory or from memory to register, it not use even movem that not exist under coldfire.
 

 
  Ok thanks.
  To better understand it - it would help me a lot to see
  some real ASM lines, and to know what EA modes are used.
  Can you show me some real ASM please?
 
  Also for the Video speed, its worth to note that the video mem has the same speed on the Vampire as the fastmem = this means if you can write to fastmem with 150 MB/sec the same score should be possible for the video mem.




Olivier Landemarre

Posts 147
14 Dec 2017 21:37


So Ok no surprise as you use 68000 version, I have found a result on CT60 using 68000 test, in this case CT60 100Mhz give around 270 so a bit better but difference is small.

I can't answer on instruction used it is tinygl C code compiled with GCC, you can perhaps disassemble dynamic library in folder kronos/dynamic/opengl/tiny_40.ldg for example

Olivier

Stefan Niestegge wrote:

Olivier Landemarre wrote:

  Hello Stefan,
   
    very very nice results in fast ram (TT Ram), it is very fast memory waouh!
   
    But opengl test is very slow compare to result I have on CT60 100Mhz, motherboard speed value is around at 1130
   
    STram I think is abnormaly slow (slower than CT60 accessing to host memory ram on slow bus of the Falcon!) but this memory should not be used for the opengl test.
   
    Perhaps you stay on 68040 option as Kronos detect 68040 processor, while if you select manually 68881 results should probably faster.
   
    I not understand why opengl test is slow as CPU, FPU and memory looks fast individually. Perhaps you could share .ABH file of your results?
   
 

 
 
  Hi Olivier
 
  the slow ST-RAM is understandable, because Falcon STRAM access is 16MHz while Amiga chipmem is ~8MHz.
 
  The OpenGL test of Kronos will crash with an illegal instruction, because the hardFPU core i used does not yet support EVERY FP instruction an 040 FPU has. Therefore i had to run that particular OpenGL test with choosing "68000" instead of the detected "68040"
 
  The Atari has no soft-FPU like MacOS for 68k has or FEMU for AmigaOS.
 
  Or is there something to enable Ataris with 68EC0x0 (which are FPU-less) run code compiled for 68040-060?
   
  If so, it could be modified to just emulate the missing opcodes.
  Otherwise, for a complete OpenGL test in full speed, we need to wait for a complete 040 hard FPU in Apollo Core.
 
  It would help to know which FPU instructions the OpenGL test uses.
  I don't know, is there some source of Kronos available?
 
  Regards,
  Beetle



posts 109page  1 2 3 4 5 6