Home   Forum

Welcome to the Apollo Forum

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



All TopicsNewsPerformanceGamesApolloVampireReleases
The team will post updates and news here

EmuTOS for Amiga and Vampirepage  1 2 3 4 5 6 

Nixus Minimax

Posts 147
07 Mar 2017 10:27


Markus (mfro) wrote:
while I'm sure Vincent's numbers are correct

Actually that seems questionable. As pointed out above, chances are that he didn't enable superscalar processing in the 68080 making it execute a maximum of one instruction per cycle which basically cripples the 080 to an 040.




Markus (mfro)

Posts 61
07 Mar 2017 11:11


Nixus Minimax wrote:

... chances are that he didn't enable superscalar processing in the 68080 ...

How would you do that?

Is this the very same bit (SR[11]) that enables the Apollo instruction set extension?



Gunnar von Boehn
(Apollo Team Member)
Posts 2547
07 Mar 2017 11:25


Markus (mfro) wrote:

   
Nixus Minimax wrote:

    ... chances are that he didn't enable superscalar processing in the 68080 ...

   
    How would you do that?
   
    Is this the very same bit (SR[11]) that enables the Apollo instruction set extension?
   
   

  You can DISABLE / ENABLE Super-Scalar
  the same way for 68060 and 68080 using the same Bit in PCR register.
 
 
  68080 will boot with Super-Scalar on.
  But our MAPROM example code will turn SS off.
  So in case you use our MAPROM example.
  Then you will need to turn SS on afterwords.


Philippe Flype

Posts 154
07 Mar 2017 11:31


@Vincent

"Please note that, at bootup, the Vampire card displays a Vampire logo in 640x480, and that one stays displayed on the HDMI output until software uses SAGA by itself. If I understand correctly, SAGA still runs behind the scenes in this case. Video mode used to display the logo might be lower than 16-bit, though."

Yes it is 640x480x8bits (clut mode). So a low impact.
However, best is to disable it = SAGA DMA Off! = MOVE.W #0,$dff1f4
 
About SuperScalar, just use this (in supervisor), early, in your initialisation code :

  MOVEC PCR,d0
  BSET #0,d0
  MOVEC d0,PCR

Or make sure the maprom code do not clear the bit.

Or even better, make sur the maprom do _set_ the bit.

I just verified this on my side.
MapROM works well with SuperScalar On.
So that new host after 'RESET' instruction
benefits of SuperScalar immediately.


Markus (mfro)

Posts 61
07 Mar 2017 12:32


Gunnar von Boehn wrote:

  You can DISABLE / ENABLE Super-Scalar
  the same way for 68060 and 68080 using the same Bit in PCR register.
 
 
  68080 will boot with Super-Scalar on.
  But our MAPROM example code will turn SS off.
  So in case you use our MAPROM example.
  Then you will need to turn SS on afterwords.

I just had a quick look into EmuTOS and it appears the PCR register is only read once to detect a 060/080. So if Super Scalar Mode is active on reset, it should be active in EmuTOS as well.



Philippe Flype

Posts 154
07 Mar 2017 15:10


Yes, better force enable ESS some lines before RESET.

My thinking is that EmuTOS and any maprom'ed rom isn't (do not have to be) responsible of how the host state was before the RESET, hence it is better force default PCR (ess on) and default CACR (icache+dcache) some lines before the RESET (So in _MapROM_ code ; not in _EmuTOS_ itself). All this, in case a user modified them for any other purpose (a game that needed turtle mode, or so). Also, of course the AC68080 resets the default value at power Off/On only, not at warm reboot.


Markus (mfro)

Posts 61
07 Mar 2017 15:37


Philippe Flype wrote:

Yes, better force enable ESS some lines before RESET.

Just to be safe on that one (it might appear a dumb question, but I'm not an Amiga guy and pretty much clueless on how the boot process works there): my understanding from Vincent's message is that the Kronos measurements have been done using the EmuTOS Amiga boot disk which is a "native" (Amiga standard) one.

From the sources, I conclude that pretty much all it does on the Amiga side is to pull the memory configuration from there, forward that to EmuTOS and replace AmigaOS with EmuTOS cold booted.

I'd understand that in this configuration, there isn't anything to do regarding ESS?

MapROM is code to load a replacement ROM into Vampire RAM, right?


Vincent Rivière

Posts 69
07 Mar 2017 16:53


For my tests, I used the EmuTOS boot floppy. No MapROM is used (it is unavailable in GOLD2, anyway), no RESET instruction is used (I had trouble with that long ago with WinUAE). So the boot floppy is only used to load EmuTOS into RAM and jump to it, as Markus detailed. Initial status is the one which was active when Kickstart loaded the bootblock.

Then at startup, EmuTOS initializes the CPU like a 68040. I don't remember if this had really been tested on real 68040 hardware, some initialization bits (CACR...) may be missing. I will carefully check that.

Longer answer later.


OneSTone O2o

Posts 100
07 Mar 2017 18:59


On top in Vincent's comparison I can read, his Vampire reaches 80% of a 100 Mhz overclocked 68060.

Gunnar writes: Vincent's Vampire runs at 78 MHz, that is very close to 80% of the 060 clock.

So I think if clocking that Falcon down to 80 Mhz, both machines should show very similar performance.

I think, this is already not bad. Everyone who loves Amiga and/or ST can have a Vampirized machine as fast as an equally clocked 060. With non optimized software. For all existing software on both platforms this already a good message. Adding a real 68060 to any existing Amiga / ST series is much more difficult and more expensive. (I currently wait on the arrival of my ct60e, 250€ for the board, 100€ for the 060, and if one has no Falcon, 600++ for that beast.) And 68080 has future potential, like AMMX, like faster FPGA in the future. Looking forward to this, a Mega ST is already reserved for that.


Philippe Flype

Posts 154
07 Mar 2017 19:28


@markus
 
  "MapROM is code to load a replacement ROM into Vampire RAM, right?"
 
  Yes it is. Well it is a small routine that does some core switch and copies the data and then execute the commodore amiga advised _coldreboot routine.
 
  EXTERNAL LINK 
  So i wrote a maprom code demonstration for Vincent and he tested it and reported it works ok, but for the upcoming Gold3 only. In this program i put superscalar off, was just a test but maybe Vincent still used it.


OneSTone O2o

Posts 100
07 Mar 2017 19:37


So it would be interesting to see superscalar results...


Markus (mfro)

Posts 61
07 Mar 2017 19:52


oneSTone o2o wrote:

  So it would be interesting to see superscalar results...
 

 
  above _are_ superscalar results. Vincent clearly stated (to everybody who's able to read) he's not using the MapROM thing but a normal boot floppy.


OneSTone O2o

Posts 100
07 Mar 2017 20:21


Markus (mfro) wrote:

oneSTone o2o wrote:

  So it would be interesting to see superscalar results...
 

 
  above _are_ superscalar results. Vincent clearly stated (to everybody who's able to read) he's not using the MapROM thing but a normal boot floppy.

Markus, you should read carfully what Phillipe wrote, here is the quote:

  So i wrote a maprom code demonstration for Vincent and he tested it and reported it works ok, but for the upcoming Gold3 only. In this program i put superscalar off, was just a test but maybe Vincent still used it.

Can you see it?


Markus (mfro)

Posts 61
07 Mar 2017 20:24


Vincent Riviere wrote:
No MapROM is used




Vincent Rivière

Posts 69
07 Mar 2017 20:25


I have just made a quick dump of supervisor registers from EmuTOS.
As told before, I ran the official EmuTOS floppy for Vampire. So EmuTOS runs in FastRAM, it is loaded from bootblock. Then EmuTOS startup might contain some 68040 initialization, to be checked.

Gunnar von Boehn wrote:

  1st At what clock do you run your 68080?

It is official GOLD2. You said here that it was running at 78 MHz.

Gunnar von Boehn wrote:

  2nd Did you enable SuperScalar on the 68080? What value is the PCR?

I didn't touch to SuperScalar stuff.
PCR = 0x04400003

Gunnar von Boehn wrote:

  3rd What is your CACR setting?

CACR = 0x80008000

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.
Also, EmuTOS has no disk cache (FreeMiNT has).
I didn't try to enable Fast-IDE on the Vampire.

Gunnar von Boehn wrote:

  5th What Screen resolution do you run in parallel?

In my reference test, SAGA runs at 1024x768 @ 60 Hz, 16-bit.
In the same time, the standard Amiga output uses a 640x400 display, 1 plane, interlaced.

Gunnar von Boehn wrote:

  6th Do you use VBR in chip or Fastmem?

VBR = 0, because Atari software wouldn't like to put the VBR elsewhere. So CPU vectors are located in Chip RAM, as well as TOS system variables. This can't be moved. But they are not accessed much, I don't think this can cause significant performance loss.

Are the above PCR/CACR settings OK?


Philippe Flype

Posts 154
07 Mar 2017 22:10


Vincent, CACR/PCR is all OK, thanx for feedback and for all those scores reports!

Seems to me compare fairly 68060@100 to Vampire would require a x13. Would be very interesting comparison.


Olivier Landemarre

Posts 12
07 Mar 2017 22:27


Hello

to compare performance CPU performance you should look at result you can find in "Hardware info" window named "Motherboard perf.", this is nice test based on the opengl test, independant of resolution to display and can't be replaced by accelerated plugin. I think quite realist as it use CPU, memory and FPU (not in your test as you use 68000 version but good to compare CT60 with same option (you have the result in .abh file)).
CT60 100MHz give a result of 239 under Mint and 269 under TOS 4

CPU are very small tests some are even design to not pipline instruction, except memory transfer (but if memory is very fast it even not true) it is highly dependant of CPU frequency.

Disk results depend highly to the system as some tests are only open/close file, some other copy/read of blocks in file but Kronos don't know if blocks are contiguous or not on the disk and it can change result. Cache can change result too.

Results display are harmonic average not arithmetic average

There is no interruption disabled during tests, performance are as if it was any classical program. I know for example moving mouse during test reduce higly results!


Vincent Rivière

Posts 69
07 Mar 2017 22:43


BTW, for the first time I tried Turtle Mode by disabling the Instruction Cache bit in CACR. For sure this works, everything is *much* slower! But still not as slow as ST: EXTERNAL LINK 
Note that the reference uses NVDI, which is a highly optimized VDI (graphics) driver. But CPU comparison should be accurate.


Vincent Rivière

Posts 69
07 Mar 2017 23:24


And finally, a test wish SuperScalar turned off (bit 0 of PCR).
EXTERNAL LINK  Reference is plain EmuTOS with SuperScalar enabled (the default), "Your computer" is the same with SuperScalar disabled.
As expected, we can see that results with SuperScalar Off are significantly slower. About 83% of full power, according to CPU, soft-FPU and OpenGL tests.

This is one more proof to show that SuperScalar was indeed enabled in all my previous tests, and that it matters.

NB: Third line is still that CT60 at 100 MHz, with Radeon, and soft-float FPU tests. Contrary to previous references which were on FreeMiNT, this one is on plain TOS. I'm really not sure that the comparison is fair (as Radeon speed poisons at least VDI test).

Anyway: I don't trust benchmarks very much. Real test case would be to run a slow CPU intensive program on 2 computers, and compare times.

Now I'm quite fed up with those benchs, I would like to switch to other stuff.


Markus (mfro)

Posts 61
08 Mar 2017 06:56


Vincent Rivière wrote:
So CPU vectors are located in Chip RAM, as well as TOS system variables. This can't be moved. But they are not accessed much, I don't think this can cause significant performance loss.

I think I've read here elsewhere (but can't find it anymore right now) that in the Amiga, ChipMem access is completely uncached with the Vampire.

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

If above assumption is correct, maybe there is some headroom for speedup?

I imagine EmuTOS would happily run with ChipMem/ST RAM caches in write through as well (and probably faster since chances are exception vectors could be kept in cache at least for reads). That's how we do it on the ColdFires.

I assume this would need a change on the MPU/MMU config? How would this be done?

posts 101page  1 2 3 4 5 6