[UserReview] Vampire V2-128 received and it's just pure p0rn.

[amiman99]

ADoom on 320x240x8
https://youtu.be/4DeJ66A-Aeo

WOW! ADoom is fast!

[grond]

Ok, ram performance is >10 higher then a Cyberstorm 060, but the Vampire 2 cpu, with current core is <2 times faster.
Higher memory benchmarks does not gain any higher perfomance of the Vampire cpu ?

RAM performance only affects stuff that is not cached. Typical Amiga benchmark programs fit entirely into the cache so you don't see much effect of the RAM performance. However, if you look at e.g. the little fire demo effect flype coded, you'll notice that the vampire does something like sixty fps in hires. Just try doing half of that on a cyberstorm... :lol:

[Niding]

A podcast interview with BigGun;

http://amicast.ppa.pl/podcast/AMIcast_Episode_10.mp3

http://www.amigapodcast.com/2016/02/amicast-episode-10-biggun-apollo-team.html

[psxphill]

RAM performance only affects stuff that is not cached. Typical Amiga benchmark programs fit entirely into the cache so you don't see much effect of the RAM performance.

I would hope that busspeedtest would be doing enough to avoid being affected by the data cache. Setpatch hasn't been loaded, so it shouldn't even be active.

As Apollo is super scalar then how fast it runs depends on the program you are running, it's entirely possible that it can run busspeedtest faster than real world programs. I've not looked at whether instructions take a variable number of clocks, but that could also favour one program over another.

Comparing benchmarks between different cpus is often a pointless exercise. The only thing you can take away from it is the speed the benchmark runs at, it would be a mistake to infer any other performance characteristics.

[grond]

I've not looked at whether instructions take a variable number of clocks

Except for some bitfields (2 cycles), movem (1 cycle for each word to be moved), mul (2 cycles) and div (many cycles) all 68k instructions take 1 cycle on apollo. Some instruction combinations can be fused or bonded which makes the second instruction effectively take 0 cycles. EA modes are free (except for braindead double-indirect). As far as I remember all pipelines can execute all single-cycle instructions.

Pretty strong compared to an 68060 that could execute two instructions in one cycle only if they fit into four bytes.

[psxphill]

Pretty strong compared to an 68060 that could execute two instructions in one cycle only if they fit into four bytes.

Yeah, so you can't take how fast one program runs compared to a 68060 and infer how fast another program will run.

A performance analyser that can show you how full the instruction pipelines are and how much time is spent waiting for memory accesses would be awesome.

[carvedeye]

I Really hope that they make the Vampire 1200 as those speeds are amazing

[Niding]

http://apollo-core.com/knowledge.php?b=6¬e=499&z=SZnEUD

[Gulliver]

http://apollo-core.com/knowledge.php?b=6¬e=499&z=SZnEUD

As I understand that is a P96 driver for Apollo developed by Jason McMullan. Why does it also exist another P96 driver by Thomas Richter dated 27/12/2015 ?

What happened? I am a bit confused. Two P96 drivers? Why?
Could anyone shed some light on this matter?

[Niding]

From EAB, a post by wawa.

here you go:
http://apollo-core.com/knowledge.php...e=499&z=SZnEUD
the new rtg driver is obviously aros based and runs on amiga kickstart. thats what needs to be done instead of stupid arguing. hope some of you will now understand and consider what is this "aros fanboyism runining your threads" about.. sigh..

@Gulliver

Seems like its AROS based, which is founded on the whole AROS and AOS3.x discussions, and potential limitations "enforced" upon Vampire from the operating system as it is without patches.

I copypasted it to here cause it highlits some of the issues if you want to evolve hardware based on Amiga legacy. I personally enjoy AOS3.x as it is (with Boingbag patches), but I have no problem understanding that its viewed as a limited foundation since BigGun (and others) have a roadmap regarding Vampire capabilities that cant be utilized within the current structure.
Then we enter into the whole licensing discussion, and pre-paying licensing, where you have to recoup the cost thru selling a unknown amount of Vampires.
Additionally, it comes at a cost, without any guarrantees of the OS in question will be futher developed.

I generally agree with Thomas's points of view, but I have no problem agreeing with BigGun's hesitation to build upon AOS since its not really being supported/developed, and paying license would just be throwing money into a hole that doesnt provide any guarrentees for advances.

[Gulliver]

Seems like its AROS based, which is founded on the whole AROS and AOS3.x discussions, and potential limitations "enforced" upon Vampire from the operating system as it is without patches.

So if it is Aros based, then it is free from absurd licensing schemes.

And I certainly think, that if it is not a retro project, but  more of a project that will be further developed in the future, it is definately understandable why the Apollo Team chose Aros. Whilst AmigaOS 3.x is what I nowadays use, I understand it has little to no future, so choosing Aros was the right desition if you are not relying on nostalgia, but on future.

[Niding]

Not sure you listened to BigGuns podcast regarding the future of Vampire.

And the Apollo-Team havent really given alot of information regarding what they plan to do with regards to AROS or AOS, or which way they are going.

But BigGun did follow a train of thought during the podcast that if you want to stick to AOS on Vampire, knock yourself out, but for future ADVANCES AOS could be a problem due to its limitations.
Many will be more than content with the original, AOS, coupled with 060++ level speed and ram. Ive seen many comments along the line of "I use and love C64, Spectrum, Amiga etc with its inherit limitations, and use mainstream PCs for everything else".
BigGun acknowledges this clearly, but also looks at what Vampire potentially CAN do, and then concludes AOS, for its strenghts and weaknesses, will be too limited for his plans.
Listening to the podcast, BigGun seemed inclined to prefer AOS if it could be developed more freely, I guess opensource, but capitulates more or less to the realisation that this will most likely never happen.

Enter AROS.

[psxphill]

Listening to the podcast, BigGun seemed inclined to prefer AOS if it could be developed more freely, I guess opensource, but capitulates more or less to the realisation that this will most likely never happen.

Enter AROS.

The only downside I can see with this is that they have been pretty clear that they aren't too bothered with 100% compatibility (especially MMU) and using AROS rather than AOS will make that easier.

If they committed to 68060 MMU compatibility then I would be less cynical. I find it morally annoying that Apollo is and never will be opensource, so nobody else can make it compatible either and making it incompatible is made easier by the work put into AROS for free. I suppose one day someone will reverse engineer their FPGA bitstream and fix it.

[Niding]

Well, they provide an affordable accelerator that will raise many/most users into 060++ performance range. Ontop of that its new hardware that are not liable to break any second due to age. Not sure whats "more moral"; selling anicent hardware for 100s or 1000s of dollars for that 1% more authenticity, than affordable hardware at a fraction of the price...?

As far as MMU and FPU; they are focusing on the core functionality for the moment. The question "do we want MMU" was raised in Apollo-Team IRC channel last week, and I think only 1 of the people in there showed any real intrest in it (im fully aware that the 56 people on average) that idle there are probarly not representative).

Regardless, there are plenty of software test demostrations released by users that demostrates rather good compability. 100% compability to what tho? I remember many programs I had on A500 didnt work on my A1200. Most issues could be fixed using Relokick or changing parameters in bootup menu, but 100% compability seems like a farfetched goal when the issue could be poorly written programs.

[kolla]

As far as MMU and FPU; they are focusing on the core functionality for the moment. The question "do we want MMU" was raised in Apollo-Team IRC channel last week, and I think only 1 of the people in there showed any real intrest in it (im fully aware that the 56 people on average) that idle there are probarly not representative).

Do these people even know what an MMU can be used for?

[kolla]

The only downside I can see with this is that they have been pretty clear that they aren't too bothered with 100% compatibility (especially MMU) and using AROS rather than AOS will make that easier.

If they committed to 68060 MMU compatibility then I would be less cynical. I find it morally annoying that Apollo is and never will be opensource, so nobody else can make it compatible either and making it incompatible is made easier by the work put into AROS for free. I suppose one day someone will reverse engineer their FPGA bitstream and fix it.

I would find it highly ironic if Apollo core is to depend on AROS because of compatibility issues. The entire point of Apollo should be to provide a compatible 68k core, right? If it is incompatible to the point where running existing operating systems becomes a hassle, then why bother? We can run AROS on much, much faster and cheaper hardware anyways