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!

X86 Power !page  1 2 3 4 5 6 7 8 9 10 11 

Roger Andre Lassen

Posts 150
09 Nov 2019 20:55


Where did i put ANYONE down ? please point me to where i did that ? Coz i never did. All i said was that i dont have any interest in Atari or x86.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
09 Nov 2019 21:00


Roger Andre Lassen wrote:

Where did i put ANYONE down ? please point me to where i did that ? Coz i never did. All i said was that i dont have any interest in Atari or x86.

My friend,
to be honest no one cares what you or anyone not likes.

If you want do change something then do something positive.


Roger Andre Lassen

Posts 150
09 Nov 2019 21:05


My friend.
I find it strange that the boss of this wonderfull Amiga can say things like that on a forum. I am your customer.

I do. I support you and the Apollo Team by buying your products. I support kickstarter projects releated to Amiga. I buy every Amiga product and software that i need.




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
09 Nov 2019 21:09


Maybe it helps here to give some information.

Various development items need different skills.
For development on the CPU-Core, a certain HW skill is needed.
For improving the Video-Chip, a certain HW skill is needed.

For developing SAGA GFX drivers for ATARI OS, a SW coding skill is needed.

What does this mean?
This means people "helping" and writing ATARI GFX drivers - do NOT slow the development of the CPU or SAGA down.
They not steal our skills.
They help and not delay us.
There is no reason to be jealous of people do good development work.



Roger Andre Lassen

Posts 150
09 Nov 2019 21:14


And i understand that Gunnar. We are going off topic here. You got mad coz i said i dont need or want the Atari part of this beautiful new Amiga.

If i could code, i would love to contribute that way.. But i dont know how to. And i got 2 small kids and a full time job. So just "learning" to code late every night isnt gonna happen.

So, if we can talk in a civilized way and dont say things like " we dont care about your opinions" on a public forum, i´d be a happy camper.

All i want is for this Vampire to succeed. I bought the V2+ and pre ordered the V4 SA. That should tell you that i love this thing.

Peace and love Gunnar :-)


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
09 Nov 2019 21:24


Roger Andre Lassen wrote:

Peace and love Gunnar :-)

Peace and love to you too! :-D

Regarding x86.
If a new developer would improve the existing x86 emulator (e.g. PC-Task) - Then this would "ADD" something for all AMIGA users.

It will take nothing away and not delay the release of the next Gold-Core down.


Roger Andre Lassen

Posts 150
09 Nov 2019 21:27


Gunnar von Boehn wrote:

Roger Andre Lassen wrote:

  Peace and love Gunnar :-)
 

 
  Peace and love to you too! :-D
 
 
  Regarding x86.
  If a new developer would improve the existing x86 emulator (e.g. PC-Task) - Then this would "ADD" something for all AMIGA users.
 
  It will take nothing away and not delay the release of the next Gold-Core down.

Awesome Gunnar :-)



Mr Niding

Posts 459
09 Nov 2019 21:57


Sounds to me that Gunnar is suggesting that if people are like Jari that did work on SoftFPU, then great. It adds to the Vampire expirience, without stealing development time frome the Core team.
 
  Same would be regarding any other software feature, be it emulation or whatnot.
 
  If someone steps up and develop, using their own time, there is no reason for the team to object. Again, refrence Jari/fpu.
 
  "Demanding" said developments repeatedly without having anyone available to undertake said task(s), implies that the Core team are supposed to divert development-time, and thats where the feature creep and endless timesink argument comes in. And where Ferrels objections become valid.


Markus B

Posts 209
09 Nov 2019 22:56


Gunnar von Boehn wrote:

  Regarding x86.
  If a new developer would improve the existing x86 emulator (e.g. PC-Task) - Then this would "ADD" something for all AMIGA users.
 

 
  Hmm, "e.g."? Is the source code of PC-Task available?
  Otherwise this is a very theoretical approach.
 
  And there is PCx, but I don't have the feeling that Jim is going to release the source code, neither.
 
  Or did I miss something?

And for the x86->68k conversion: I would imagine this as something like a hardware assisted JIT compiler, right?
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
09 Nov 2019 23:35


Markus B wrote:

And for the x86->68k conversion: I would imagine this as something like a hardware assisted JIT compiler, right? 

 
 
Let me try to explain my thoughts more clearly.
 
Lets first clarify some namings:
 
What means "Emulation"?
Emulation means being able to execute programs meant for another CPU on your CPU.
For example running a C64 program for the C64-6510 CPU on your 68000 CPU.
 
A program is constructed by many instruction.
The emulation will "replace/emulate" them one by one.
 
There are 2 common type of how to "emulate" another CPU.
A) Interpretive
B) JIT
 
Interpretive Emulation will instruction per instruction first "detect with foreign" instruction the next instruction is,
and then execute some native instructions to "emulate" the behavior.
Cost = Detection + Emulated-Execution
 
Typical Cost for each foreign opcode is roughly
30 instruction clocks for detection
+ 1-10 instructions for execution.

The drawback for Interpreter execution is that again and again the "Detection" cost is paid.
 
 
 
JIT will detect and save new code,
this new code includes only the "Emulation-Instruction"
 
Cost for JIT is roughly 400 cycle for detection and code creation,
but for execution only 1-10 instructions.
 
Lets make a simple example
 
Lets say there is an x86 workloop of 3 instructions which gets executed 100 times.
Lets say the average Emulation cost per instruction is 6
 
Interpretation Cost
100 * (30+6)  == 3600 clocks
 
JIT Cost
400 + 100 *6  == 1000 clocks
 
You can clearly see for LOOP code.
JIT will become MUCH faster.
 
And all major work in programs is done in loops.
 
Now what the bottleneck for JIT performance?
The answer is the Execution Cost per instruction.
 
The Execution Cost per Instruction is influenced by the "capabilities" of the CPU.
 
If the foreign CPU can do stuff that our own CPU can NOT do with own instructions then emulating can not be done with 1by1 instruction but maybe we need 5 instruction or 10 instructions to do the work of the foreign CPU.
This is pretty obvious and logical.
 
 
Lets sum this up.
1) A JIT emulator will give better speed than Interpreters.
2) if our own CPU can natively do all "tricks" the foreign to be emulated CPU can do - then its easier and cheaper to emulate it.
 
From a CPU HW point of view this means.
If the x86 can do some "tricks" which the 68k can native not.
We can make emulation easier by adding those tricks to the feature list of the core.
 
All clear now?

Lets get back to our example:

Interpretation Cost
100 * (30+6)  == 3600 clocks
 
JIT Cost
400 + 100 *6  == 1000 clocks

Lets say we add more "tricks" and improve our cost ratio lets say from 6 to 2

This means our new cost will be
JIT Cost
400 + 100 *2  == 600 clocks



Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
09 Nov 2019 23:40


Gunnar von Boehn wrote:

  From a CPU HW point of view this means.
  If the x86 can do some "tricks" which the 68k can native not.
  We can make emulation easier by adding those tricks to the feature list of the core.
   
  All clear now?
 

 
  How much space in V4 core is left for such excess :)
e.g. some sort of Transmeta-like microcode assisted JIT?

That would be real nice 2025 goal (v6+ Vamps).

Its a blasphemy, but people forget A1000 started with SideCar "to expand software library to IBM MS DOS" :)

Hmmm ... Could we get ReactOS as high end target? A bit of love from Russia :) EXTERNAL LINK 
    RAM: at least 64 MB, recommended 256 MB, and even 2048 MB if you want to test large software suites or bundles.
    Processor: x86 or x64 architecture, Pentium/PentiumMMX or later and compatibles; for more information see ReactOS ports.
    HDD: IDE/SATA with minimum 450 MB of free space on the primary partition (please note that some SATA controllers may not work with ReactOS):
        FAT16/FAT32 primary boot partition.
    Video: VGA compatible video card (VESA BIOS version 2.0 or later).


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
09 Nov 2019 23:49


Vojin Vidanovic wrote:

  How much space in V4 core is left for such excess :)
 

 
Its important to understand what we really talk about.

We NOT talk about doing an x86 instruction decode in HW.
This would frankly eat a lot space and turn us into an PentiumPro.
Cost for a HW x86 decoder might be 5000 LE

We talk here about features which APOLLO already has - like LITTLE ENDIAN support. And which are not only useful for x86 emulation but can be used any normal programs on AMIGA too.
Cost for such general improvements might be small (e.g 100 LE each)
with the possibility that such feature might be useful for other AMIGA programs in general.
 


Sean Sk

Posts 488
10 Nov 2019 00:40


I don't see how a developer or a group of developers coming in and creating Mac, X86 or Atari emulators is diverting the Apollo Team's attention away from their primary goal of continuing development of the Amiga platform. What external developers do has nothing to do with the Apollo Team and if the team wish to encourage such development it is not going to slow them down or distract them from their primary goal, nor is it going to prevent other developers from creating Amiga native software. People are completely free to choose to create whatever software they like for the Vampire/Amiga.
 
@Steve Ferrell:
 
Whilst I respect what you are saying and understand your passion for the Amiga platform (that's the reason why I am here as well) I think it's important to put things into perspective here. Emulation, by THIRD PARTY developers, will broaden the scope of what can be used on the Vampire, not squash what can already be done on it and, by that, I mean creating and using Amiga native software. You're right! These things could probably be done better on other platforms, but I enjoy using my Amiga and look for every opportunity to do so.
 
Gunnar is free to provide support to all and everyone that desires to create Amiga software without diverting his attention away from development of the Apollo core.


Jim Drew
Learn who I am!
Posts 67/ 1
10 Nov 2019 00:51


Gunnar von Boehn wrote:
Also FUSION is NOT an emulator.

That is not true.  The *only* thing not being emulated with FUSION is the CPU core.  Everything else is emulated.  The Mac has a custom chipset, just like the Amiga, and those chips have to be emulated at a hardware level to be fully compatible.  NuBus video cards for video, SWIM for floppy, 53C80 for SCSI, 85C30 for serial, etc.  There is a ton of actual emulation going on.  When there is no MMU (like a stock A1200), the MMU (or PMMU) also has to be emulated.




Jim Drew
Learn who I am!
Posts 67/ 1
10 Nov 2019 00:57


Steve Ferrell wrote:
I'm pretty certain that even Dave Haynie, Jim Drew and Bernie Meyer will want a compiler that supports 080/AMMX if they plan to develop for the Vampire unless you expect them to code everything in 100% assembler.

I program *only* in assembly code (for all CPUs and microcontrollers that I work with).  So, this doesn't apply to me.  :)




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
10 Nov 2019 01:32


Jim Drew wrote:

When there is no MMU (like a stock A1200), the MMU (or PMMU) also has to be emulated.

Can you explain how to emulate the MMU?


Jim Drew
Learn who I am!
Posts 67/ 1
10 Nov 2019 05:43


Gunnar von Boehn wrote:

  Can you explain how to emulate the MMU?

 
Sure.  The MacOS has function calls for doing memory management, which uses the MMU for mapping everything.  The MMU is hard coded to use 4K pages no matter if a 68851, 030, or 040 is being used.  Basically, it's like everything in the MacOS where there is a 'driver', which is a library of routines (memory, video, floppy disk, HD, ADB, ASC, etc.) When there is an MMU, there is just a hand full of patches needed to make sure the Amiga side is not trampled on.  When there is no MMU present, the calls have to be emulated.  So, dirty pages have to be marked and handled (using a virtual MMU buffer), and pages copied/expunged.  Unfortunately, it's just too slow to do all of this manually via code, even if the CPU was 100x faster to allow virtual memory to work.  It's quite slow with a real MMU when VM is enabled because of the massive number of page swaps that are done - especially when dealing with a LOT more virtual memory than physical memory and something like Photoshop.
 
Oh, I also forgot that the ADB (Apple Desktop Bus), Apple Sound Chip (with 14 bit audio for PAULA and 16 bit audio for AHI, and direct support on Toccata and Prelude), dual 6522 VIAs, and some glue logic that also have to be emulated!  Literally, the only thing that FUSION does not emulate is the CPU in the case of the Amiga version.  This is why going from the Amiga to the PC version (FUSION-PC) required just writing the 68040 core in x86 assembly.  The rest of the code was left in 68K (emulated) and converted to x86 assembly in pieces after the emulation worked.  It made the port easy to do this way.
 
 


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
10 Nov 2019 07:00


Gunnar von Boehn wrote:

      This would frankly eat a lot space and turn us into an PentiumPro.
      Cost for a HW x86 decoder might be 5000 LE 
     

   
    One day, when it costs just few bucks more :)
     
      We are already "486 MMX"/Pentium OverDrive MMX to P5 MMX class CPU, so P6 is logical next step :) Even I like to feel us "Cyrix MMX style" :)
   
    OK "adding cheap similarities" to Apollo core, keep on  but with such description that helps developers to bring JIT. I am no developer, but very nice examples.
     
      And for Fusion - some of the "cheap" Mac hw could also go hw so it does not need to be emulated, same for Yamaha/Atari Blitter, if not to costy - and you get your real "launcher" :) And attention of e.g. Atarians.
     
 
Jim Drew wrote:

  I program *only* in assembly code (for all CPUs and microcontrollers that I work with).  So, this doesn't apply to me.  :)
 

 
      Its great if Jim is 100% ASM. Teaching him 080 instructions or if he could use VASM (download EXTERNAL LINK ) he could produce improved code of existing "Fusion 3.x/PC.x" and see if any speed improvement happen.

‘-m68080’
Generate code for the Apollo Core AC68080 FPGA CPU.


Geoff Wells

Posts 43
10 Nov 2019 16:49


Quick question.  Doesn't having a few extra features broaden the appeal of the Apollo core and as such make the chances of getting an ASIC that much better?

I love the Amiga but I also enjoy the idea of running the Atari or MAC OSes.  Also, either for emulation or embedded systems, if having different endian support allows a little bit bigger market that's great too.

If the team can generate interest from 1,000 people in each of those potential markets for Apollo + (Amiga SAGA, Atari ST Chipset, MAC Chipset, whatever) and it didn't significantly distract from the core team's focus that would seem to be great from my perspective.

I have a v2, the v4 is on pre-order and I'd love to have an ASIC version at some point in the future.  Unless the technology changes there is a large cost for creating the masks and the production run.  For that, we need more potential buyers, right?

Perhaps I'm thinking too far in the future but I don't think so.  Stabilizing what's there is important but so is a vision of the future.  As the retro community shrinks we need to be inclusive.


Tim Trepanier

Posts 132
10 Nov 2019 18:40


Geoff Wells wrote:

  If the team can generate interest from 1,000 people in each of those potential markets for Apollo + (Amiga SAGA, Atari ST Chipset, MAC Chipset, whatever) and it didn't significantly distract from the core team's focus that would seem to be great from my perspective.

My problem is that i've been waiting for years to put a Vampire with Gold 3 core in my A1200 and i'm out of patience. Health issues mean i likely won't live long enough to see it unless they speed up development.

posts 216page  1 2 3 4 5 6 7 8 9 10 11