Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
27 crawler(s) on-line.
 47 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 matthey:  19 mins ago
 agami:  1 hr 47 mins ago
 OlafS25:  1 hr 59 mins ago
 eliyahu:  2 hrs 41 mins ago
 NutsAboutAmiga:  2 hrs 42 mins ago
 DiscreetFX:  3 hrs 8 mins ago
 Marcian:  3 hrs 48 mins ago
 michalsc:  3 hrs 49 mins ago
 vox:  5 hrs 8 mins ago
 OneTimer1:  5 hrs 25 mins ago

/  Forum Index
   /  Classic Amiga Hardware
      /  News about Vampire and Apollo
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 Next Page )
PosterThread
NutsAboutAmiga 
Re: News about Vampire and Apollo
Posted on 21-May-2020 19:11:33
#2021 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12791
From: Norway

@matthey

Quote:
The slowdown was not due to context switches because there were none.


Memory consistency, problem with data was not flushed to RAM because was stuck in CPU's data cache. having to flush DATA cache to sync data between 680x0 and PPC.. was real issue. Way Hyperion ignore the MC680x0 CPU even when it was available, on classic computers.

Last edited by NutsAboutAmiga on 21-May-2020 at 07:14 PM.
Last edited by NutsAboutAmiga on 21-May-2020 at 07:12 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Fl@sh 
Re: News about Vampire and Apollo
Posted on 21-May-2020 21:25:03
#2022 ]
Regular Member
Joined: 6-Oct-2004
Posts: 253
From: Napoli - Italy

@matthey

Quote:
Let's take a look at 68060 vs PPC 604e code for a simple strlen() function.

size_t d0=strlen(*str a0)
;inline start
strlen:
lea (1,a0),a1
.loop:
tst.b (a0)+
bne .loop
sub.l a1,a0
move.l a0,d0
;inline end

or smaller code but not as readable...

size_t d0=strlen(*str a0)
;inline start
strlen:
move.l a0,d0
.loop:
tst.b (a0)+
bne .loop
sub.l a0,d0
not.l d0
;inline end

Example 68060 execution using the string "test" and assuming everything is cached.
move.l a0,d0 ; pOEP 1
tst.b (a0)+ ; sOEP 1
bne .loop ; predicted correctly as taken
tst.b (a0)+ ; pOEP 2
bne .loop ; predicted correctly as taken
tst.b (a0)+ ; pOEP 3
bne .loop ; predicted correctly as taken
tst.b (a0)+ ; pOEP 4
bne .loop ; predicted correctly as taken
tst.b (a0)+ ; pOEP 5
bne .loop ; predicted incorrectly as taken 12
sub.l a0,d0 ; pOEP 13
not.l d0 ; pOEP 14
Total: 14 cycles, 10 bytes

size_t r3=strlen(*str r3)
;inline start
strlen:
subi 4,3,1
.loop:
lbzu 0,1(4)
cmpwi 0,0
bne .loop
sub 3,4,3
;inline end

Example PPC 604e execution using the string "test" and assuming everything is cached.
subi 4,3,1 ; 1
lbzu 0,1(4) ; 1
2 cycle load-use bubble
cmpwi 0,0 ; 4
bne .loop ; predicted correctly as taken
lbzu 0,1(4) ; 4
2 cycle load-use bubble
cmpwi 0,0 ; 7
bne .loop ; predicted correctly as taken
lbzu 0,1(4) ; 7
2 cycle load-use bubble
cmpwi 0,0 ; 10
bne .loop ; predicted correctly as taken
lbzu 0,1(4) ; 10
2 cycle load-use bubble
cmpwi 0,0 ; 13
bne .loop ; predicted correctly as taken
lbzu 0,1(4) ; 13
2 cycle load-use bubble
cmpwi 0,0 ; 16
bne .loop ; predicted incorrectly as taken 20
sub 3,4,3 ; 21
Total: 21 cycles, 20 bytes

I'm no expert in PPC assembler so feel free to point out any mistakes or optimizations. Good luck unrolling the PPC code to remove the load-use bubbles. The PPC code is already twice the size and significantly more cycles. A little more complex function like strcpy() gets even worse for the PPC. I don't think many people will agree with you that the PPC code is easier to read than the 68k code either. Where were you during the x86 vs PPC wars when x86 trounced PPC due in large part to x86 assembler optimizations. Assembler coders preferred ugly x86 assembler to cryptic PPC assembler too.


you are just taking an example were 68k and all old cpu are advantaged.. you are testing some bytes in sequence
..Even a 6502 is advantaged doing this!

Maybe could be useful a 64bit example simply because 64bit are standard now and all calculations and memory addressing take advantage from 64bit support.
..Really we want compare a powerpc with a 68k?

I have to say I like 68k assembler and it's architecture a lot.
It was really simple to understand and develop, especially if compared to x86 or others old isa archs.
So I will never say something against 68k
Simply it did its era and was dropped in favor of more modern and future proof architecture. Sure it could be supported and extended too but we could have come back today to the same x86 issues. All us knows arm is more powerful at same power consumption and apple is really near for another switch.

I appreciate what Vampire team is doing, extending ISA and old custom chips.
It's a really fun job and could lead to some interesting results, but sadly it will remain in a retrocomputing world.

But coming back to ppc instead I haven't any doubt to say it's much better in most cases.
All ppc have an mmu, fpu and start from a base of 32bit strong isa with 3 operands and powerful muladd instructions, with 32 cpu gpr registers and 32 fpu registers, plus other internal renaming registers and more recently out of order execution.
Add 64bit extensions was relatively simple; even add SPE and Vector units did not lead to any incompatibility. Both solutions made history with CELL and G5 cpus.
Even the way Altivec was created has made school and even AVX2 has something to learn from motorola implementation.
Both today can still compete with recent x86 single cores (at same clock speed).
Powerpc gained even Little Endian support with minor compromises, and LE is the standard for next gens, still maintaining compatibility with old code. If the base project wasn't genuine it could be never be possibile..

However today we need to look at Power 9 and next (Power 10) with smp (4 threads per core) and other important features in encryption, letting them to compare against others recent cpus.

Coming back (again) in topic with Vampire, IMHO it could be really fun to have a much more powerful v5 with aros and modern rtg graphics/sound chips, dropping all obsolete and non sense custom chip compatibility.
If needed everything could be emulated via software in a relatively simple way because the cpu is the same and so should not be emulated in software loosing performances
More than emulations it could be a hardware virtualization just like QEMU does with KVM.

Last edited by Fl@sh on 21-May-2020 at 09:43 PM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

 Status: Offline
Profile     Report this post  
bison 
Re: News about Vampire and Apollo
Posted on 22-May-2020 1:16:13
#2023 ]
Elite Member
Joined: 18-Dec-2007
Posts: 2112
From: N-Space

@matthey

Quote:
The most likely culprit to Martin's problem was the EGCS compiler which was scrapped for the GCC compiler

I'm really rummaging through the back room of my memory, but I seem to recall that EGCS *was* GCC. It was a fork that Red Hat did because development on the main branch stalled, and it was later merged back into GCC. Or something like that.

_________________
"Unix is supposed to fix that." -- Jay Miner

 Status: Offline
Profile     Report this post  
kolla 
Re: News about Vampire and Apollo
Posted on 22-May-2020 5:48:21
#2024 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2852
From: Trondheim, Norway

@matthey

Quote:
How many RISC architectures have died during the life of x86/x86_64?


One - DEC Alpha, which was bought and killed on purpose to promote Intel Itanium.

Last edited by kolla on 22-May-2020 at 05:49 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
utri007 
Re: News about Vampire and Apollo
Posted on 22-May-2020 9:43:40
#2025 ]
Super Member
Joined: 12-Aug-2003
Posts: 1073
From: United States of Europe

@thread

I have understand that there is news about ACT's Apollo accelerators, what kind of news?

It also seems that SAGE RTG software development has been restarted? https://en.wikipedia.org/wiki/SAGE_Computer_Technology

 Status: Offline
Profile     Report this post  
sTix 
Re: News about Vampire and Apollo
Posted on 22-May-2020 10:40:39
#2026 ]
Regular Member
Joined: 22-Oct-2003
Posts: 138
From: Lund, Sweden

@kolla

Quote:
One - DEC Alpha, which was bought and killed on purpose to promote Intel Itanium.


And CRIS.. must not forget that one, major player

https://en.wikipedia.org/wiki/ETRAX_CRIS

_________________

 Status: Offline
Profile     Report this post  
matthey 
Re: News about Vampire and Apollo
Posted on 22-May-2020 23:44:33
#2027 ]
Super Member
Joined: 14-Mar-2007
Posts: 1964
From: Kansas

Quote:

Fl@sh wrote:
you are just taking an example were 68k and all old cpu are advantaged.. you are testing some bytes in sequence
..Even a 6502 is advantaged doing this!


I was just looking for very simple functions as examples. The 68k can handle 8, 16 or 32 bit arrays just as well. The 6502 is an accumulator architecture created with the primary goal of requiring minimal logic to implement. As transistors space on chips expanded, register-memory architectures came along which were better at accessing and conserving memory. Load-Store architectures were created to simplify processor designs and save transistors but the latter was often sabotaged by high cache and memory requirements.

Quote:

Maybe could be useful a 64bit example simply because 64bit are standard now and all calculations and memory addressing take advantage from 64bit support.
..Really we want compare a powerpc with a 68k?


Amiga software is practically all 32 bit. We have ports of some advanced and large programs. How is that possible with all the work required to convert 64 bit programs? Most 64 bit CPUs are using mostly 32 bit integers (LP64 or LLP64 data model) because 64 bit integer calculations are sometimes slower and waste space when storing. Larger caches and more memory are needed for 64 bit. Performance is sacrificed with 64 bit just to gain more address space.

Quote:

I have to say I like 68k assembler and it's architecture a lot.
It was really simple to understand and develop, especially if compared to x86 or others old isa archs.
So I will never say something against 68k
Simply it did its era and was dropped in favor of more modern and future proof architecture. Sure it could be supported and extended too but we could have come back today to the same x86 issues. All us knows arm is more powerful at same power consumption and apple is really near for another switch.


Actually, x86_64 CPUs lead in doing more work for the electricity used. That is why they dominate the server market. ARM is rarely "more powerful" but can reduce power consumption further than most CPUs.

Quote:

I appreciate what Vampire team is doing, extending ISA and old custom chips.
It's a really fun job and could lead to some interesting results, but sadly it will remain in a retrocomputing world.


Likely, as they are not planning for anything beyond Pentium MMX technology from the late '90s in an affordable FPGA.

Quote:

But coming back to ppc instead I haven't any doubt to say it's much better in most cases.
All ppc have an mmu, fpu and start from a base of 32bit strong isa with 3 operands and powerful muladd instructions, with 32 cpu gpr registers and 32 fpu registers, plus other internal renaming registers and more recently out of order execution.


Which PPC ISA? The original or the embedded (they have different incompatible MMUs)? The Tabor CPU doesn't have a standard FPU with FPU registers. Instructions and mis-alignment support varies from CPU to CPU. The PPC architectures really haven't been that great for standardization (standards allowed too much variance in CPU designs).

Quote:

Add 64bit extensions was relatively simple; even add SPE and Vector units did not lead to any incompatibility. Both solutions made history with CELL and G5 cpus.


CELL and the G5 were both expensive disappointments. The PPC low end was disappointing with the 603 and now the high end G5 designed by the heavyweight IBM was just as disappointing. All PPC had was a pretty good mid-performance G3/G4 design which was copied with minor improvements until the end. CELL was just a high clocked but weak PPC core bolted on to some exotic vector processor.

Quote:

Even the way Altivec was created has made school and even AVX2 has something to learn from motorola implementation.
Both today can still compete with recent x86 single cores (at same clock speed).


Altivec is descent considering it is simpler than modern x86_64 SIMD standards but there is no contest which one is more powerful.

Quote:

Powerpc gained even Little Endian support with minor compromises, and LE is the standard for next gens, still maintaining compatibility with old code. If the base project wasn't genuine it could be never be possibile..


Better LE support helps to port software from lazy programmers who assume LE but that doesn't help an Amiga much running in BE mode.

Quote:

However today we need to look at Power 9 and next (Power 10) with smp (4 threads per core) and other important features in encryption, letting them to compare against others recent cpus.


The problem is the lack of user base to create software at a more expensive entry point. PPC Amigas are not selling well at their current price.

Quote:

Coming back (again) in topic with Vampire, IMHO it could be really fun to have a much more powerful v5 with aros and modern rtg graphics/sound chips, dropping all obsolete and non sense custom chip compatibility.
If needed everything could be emulated via software in a relatively simple way because the cpu is the same and so should not be emulated in software loosing performances
More than emulations it could be a hardware virtualization just like QEMU does with KVM.


Custom chip compatibility isn't a big kludge nor does it take much logic using today's technology. The Amiga custom chips were designed at a time where every transistor counted. They would probably be a few hundred thousand transistors worth of logic which isn't much today.

68000 - 68,000 transistors
68020 - 190,000
68060 - 2,500,000
Pentium - 3,100,000
Core2Duo - 230,000,000
Core i7 - 1,170,000,000
POWER9 - 8,000,000,000

You could have 117,647 68000 cores using the transistor count of a POWER9.

 Status: Offline
Profile     Report this post  
matthey 
Re: News about Vampire and Apollo
Posted on 23-May-2020 0:07:06
#2028 ]
Super Member
Joined: 14-Mar-2007
Posts: 1964
From: Kansas

Quote:

kolla wrote:
@matthey

Quote:
How many RISC architectures have died during the life of x86/x86_64?


One - DEC Alpha, which was bought and killed on purpose to promote Intel Itanium.


Alpha, 88k, PA-RISC, i860, i960, PPC, SPARC, MIPS, SuperH, MCORE, CRIS

How quickly we forget history. I expect I missed a few with this quick list too.

Last edited by matthey on 23-May-2020 at 12:24 AM.

 Status: Offline
Profile     Report this post  
kolla 
Re: News about Vampire and Apollo
Posted on 23-May-2020 7:07:16
#2029 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2852
From: Trondheim, Norway

@matthey

Your list is only valid by your own definition of “died”, as many of them are very much still alive, and those that aren’t didn’t die because of x86 (but rather ARM and Itanium) or never really “lived” at all.

One can also ask how many CISCs “died” in the lifespan of ARM... and how many RISCs and CISCs are there... and do these numbers tell us much at all, other than a story about companies buying and selling each other?

Last edited by kolla on 23-May-2020 at 07:59 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: News about Vampire and Apollo
Posted on 23-May-2020 8:51:56
#2030 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12791
From: Norway

@matthey

Favoritism towards the Vampire team?

You talk far too little crap to make the MC68080, look good, MC68080 is 100-200 Mhz range cpu no matter what crap you throw at PowerPc. Nothing changes that.

x86 and ARM Is irrelevant its not 680x0 cpu’s so it can’t run 680x0 native, you have same problem being force to use slow UAE.

Last edited by NutsAboutAmiga on 23-May-2020 at 08:54 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
kolla 
Re: News about Vampire and Apollo
Posted on 23-May-2020 9:19:42
#2031 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2852
From: Trondheim, Norway

@NutsAboutAmiga

You don’t need UAE to emulate 68k, and emulation of 68k isn’t really what slows down UAE.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
matthey 
Re: News about Vampire and Apollo
Posted on 24-May-2020 0:35:44
#2032 ]
Super Member
Joined: 14-Mar-2007
Posts: 1964
From: Kansas

Quote:

kolla wrote:
Your list is only valid by your own definition of “died”, as many of them are very much still alive, and those that aren’t didn’t die because of x86 (but rather ARM and Itanium) or never really “lived” at all.


Dead or almost dead, not much difference unless you know Miracle Max. I consider dead to include the ISAs which change hands often, become more open too late, have little to no market share of any market, any new designs are for niche markets or for compatibility reasons, etc. I never said x86 killed these RISC architectures just that it survived them. The ancient dinosaur did adapt and turned out to be more powerful than any of the newer challengers.

Quote:

One can also ask how many CISCs “died” in the lifespan of ARM... and how many RISCs and CISCs are there... and do these numbers tell us much at all, other than a story about companies buying and selling each other?


The 68k is the biggest CISC architecture which went away during ARMs lifetime. This was mainly because Motorola/Freescale shoved embedded PPC designs down customers throats and they left for ARM. I think the 68k would still be a major player in the embedded market if newer and more powerful designs were brought to market with features customers want. Not only was fat PPC a flop for the embedded market but so was the too minimalist MCORE architecture and ColdFire was created more incompatible than necessary. CPU32 was a reasonable simplification for embedded 68k but that wasn't continued either. It didn't look like there was any real strategy or understanding of the embedded market as the mass exodus to ARM occurred.

 Status: Offline
Profile     Report this post  
matthey 
Re: News about Vampire and Apollo
Posted on 24-May-2020 1:04:57
#2033 ]
Super Member
Joined: 14-Mar-2007
Posts: 1964
From: Kansas

Quote:

NutsAboutAmiga wrote:
Favoritism towards the Vampire team?


No. Some people would even say I have tried to sabotage them.

Quote:

You talk far too little crap to make the MC68080, look good, MC68080 is 100-200 Mhz range cpu no matter what crap you throw at PowerPc. Nothing changes that.


Do you mean the AC68080? What frequency do you think PPC designs achieved in FPGA?

Quote:

x86 and ARM Is irrelevant its not 680x0 cpu’s so it can’t run 680x0 native, you have same problem being force to use slow UAE.


ARM and x86_64 are relevant if the Amiga tries to do anything post PPC, which is now.

 Status: Offline
Profile     Report this post  
ErikBauer 
Re: News about Vampire and Apollo
Posted on 24-May-2020 6:52:18
#2034 ]
Super Member
Joined: 25-Feb-2004
Posts: 1141
From: Italy

@CosmosUnivers

My 2 cents about the "Division" Apollo/SAGA is creating.

What did happen when AGA came out? Evolution, an yes, division.
AGA machines used an evolution of the original chipset, that was able to do things it's predecessors could'nt do (8Bitplane GFX, HAM8, ecc...).
On top of that AGA machines came with at least a 020 Processor, that again was an evolution of the 68000 used in classic Amigas.
So, if you wanted to create an AGA game/software, it would not run on an ECS/OCS machine, you had to purposely write and compile 2 different versions of the same game/software (Or use OS libraries, but let's take this aside for the moment).
That seemed (and indeed was) cool at the time. And programmers adapted.

Then Commodore promised a Super AGA chipset of sort, that was OFFICIALLY totally INCOMPATIBLE with AGA/ECS/OCS, remember?
And YET everyone got excited by the news.

Then commodore went bankrupt, and we all kissed goodbye to such a new Amiga Concept.

Now a small team is doing it's best (yes, admittedly they are not the best in communication science, that's true) to not only bring us something that has comparable potential to the never released chipset, but that is somewhat COMPATIBLE to the classic ones.
Of course, as with ECS -> AGA, there is some Evolution and, of course, some Division:
SAGA and 68080 have some functions that legacy HW can't handle so writing a SAGA specific game/application means it can't run on previous HW but hey... this is Computer Science, evolution means that the former HW can't run the new software.
But you always can write a legacy software and know it would run faster and better on the new HW because it is retro compatible.
Can't see what all this fuss is about : want to stick coding for 040+AGA/RTG? Do that, your software will run on most (not all) legacy HW and it will also run on Vampire.
You are bothered because Vampire specific software can't run on Legacy HW? Well, that's evolution.
See.. nobody complained when NVidia introduced RTX in their new GFX cards, even if everybody well knows that RTX could not be run on previous chipsets. It's a well accepted thing.



Last edited by ErikBauer on 24-May-2020 at 07:47 AM.

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

 Status: Offline
Profile     Report this post  
ErikBauer 
Re: News about Vampire and Apollo
Posted on 24-May-2020 7:49:52
#2035 ]
Super Member
Joined: 25-Feb-2004
Posts: 1141
From: Italy

@OlafS25

Quote:

OlafS25 wrote:
@Lou

That is a strange attitude

I buy a product because I want to have and use something, not because I like the person or team behind

Even if you dislike Gunnar the Vampire is not becoming better or worse

Either the Vampires are worth the money for you or not

If you have several comparable products personal attitudes towards companies can become important, I f.e. dislike apple for its behavior so I would never buy something from them

That is easy possible because there are alternatives everywhere

But vampire is unique, at least for what it is offering


Amen to that

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

 Status: Offline
Profile     Report this post  
kolla 
Re: News about Vampire and Apollo
Posted on 24-May-2020 12:52:28
#2036 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2852
From: Trondheim, Norway

@ErikBauer

Well, so far, the issue has rather been that noone is coding for SAGA+AC68080...

But what is SAGA:
* open-source to be, “promised” like so many things (3 years ago now)
* work in progress
* relies on RTG/P96 for “super” screenmodes
* relies on dedicated support in audio software
* does not (as far as I have seen) improve performance of legacy screen modes
* many AGA/ECS modes are not (yet) available or usable on SAGA (interlaced, productivity modes etc)
* started on V2, but moved to V4, might very well end up being a V4-only chipset, with a “limited” variant for V2?
...

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
Fl@sh 
Re: News about Vampire and Apollo
Posted on 24-May-2020 13:48:30
#2037 ]
Regular Member
Joined: 6-Oct-2004
Posts: 253
From: Napoli - Italy

@all

Instead of new hw registers to poke to improve aga features I’d like to see from vampire new api compatible with aos4/mos, so ti unify AmigaOS developments.
In this way with one source we could have extended compatibility with all amiga like os and all cpu, 68k, ppc, x86, arm.
Is this in some way planned by vampire team?

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

 Status: Offline
Profile     Report this post  
DiscreetFX 
Re: News about Vampire and Apollo
Posted on 24-May-2020 15:03:41
#2038 ]
Elite Member
Joined: 12-Feb-2003
Posts: 2477
From: Chicago, IL

Hopefully no one wants to pick an online fight with someone with a kick ass name like Gunnar. He’s gunning for you if you fight him.

_________________
Sent from my Quantum Computer.

 Status: Offline
Profile     Report this post  
matthey 
Re: News about Vampire and Apollo
Posted on 24-May-2020 17:10:29
#2039 ]
Super Member
Joined: 14-Mar-2007
Posts: 1964
From: Kansas

Quote:

Fl@sh wrote:
Instead of new hw registers to poke to improve aga features I’d like to see from vampire new api compatible with aos4/mos, so ti unify AmigaOS developments.


Different AmigaOS flavors are using different incompatible APIs (usually provided by software). This is not the fault of hardware. The Vampire hardware tries to be backward compatible which is not true of most AmigaNG hardware. New hardware registers can usually be added with minimal affect on compatibility. Hardware drivers can be used to provide more abstraction from the underlying hardware.

Quote:

In this way with one source we could have extended compatibility with all amiga like os and all cpu, 68k, ppc, x86, arm.
Is this in some way planned by vampire team?


Supporting many different CPU architectures is a lot to ask for. Maybe you thought you were in the Amiga Nowhere thread?

Last edited by matthey on 24-May-2020 at 11:43 PM.

 Status: Offline
Profile     Report this post  
ErikBauer 
Re: News about Vampire and Apollo
Posted on 25-May-2020 10:36:03
#2040 ]
Super Member
Joined: 25-Feb-2004
Posts: 1141
From: Italy

@Fl@sh

Quote:

Fl@sh wrote:
@all

Instead of new hw registers to poke to improve aga features I’d like to see from vampire new api compatible with aos4/mos, so ti unify AmigaOS developments.
In this way with one source we could have extended compatibility with all amiga like os and all cpu, 68k, ppc, x86, arm.
Is this in some way planned by vampire team?


IT's simply not the scope of the project.
Their aim is clearly to create an improved 68k + Improved Chipset Amiga.

This is a different path from the NG Amiga concept, thus is realized in a different way.

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle