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
Documentation about the Vampire hardware

Vampire 1200 V2page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 

Matthias Hampel

Posts 2
17 Jan 2020 19:38


My V1200 arrived today :)
 
  Unfortunately I can not get it running. In 3 boards I have the same problem. Only the blue LED is on, the Vampire Logo is off. IDE does not start, VGA does not start. After a few seconds the kickstart image of the used 3.1.4 ROMs appears, so the internal CPU is probably working.
  As I said, I tried 3 different mainboards, all working with other accelerator cards.
  I also tried not to plug in the vampires completely, but to pull out 1mm.
 
  Any ideas?



Igor Majstorovic
(Apollo Team Member)
Posts 406
17 Jan 2020 21:32


OK we are dealing over mail this problem now. I will report here what was the problem and what was solution for it.

EDIT:
Matthias Hampel, with my instructions, did some measurements with multimeter and found out that instead of 1.2V needed for FPGA power he sees only 0.3V. Since we found problem he fixed it on its own by soldering several cold solder joints on expansion connector and card is now working. We will see how this goes and if this repeats I ll just replace the card. It seems to me that I didn't see this before packing and testing the card and in future I ll have to take closer look on that specific area where 1.2V is generated.


Kyle Blake
(Needs Verification)
Posts 108/ 1
19 Jan 2020 15:14


Simo Koivukoski wrote:

  V1200 Gold 2.12RC3 r7258x12 AmiQuake2 AGA
 
 
 
  YouTube: EXTERNAL LINK   
 

 
  Much slower than V4SA in this task, interesting.
 
  In youtube comments chipram bus saturation is mentioned, but I don't know how true that could be. Doom gets much higher framerate on AGA 060 so the speed problem here can't just be writing the framebuffer...
 
  Something I've always wondered about is the effectiveness of turbo cards in adapting different CPUs to the amiga bus. From personal experience 030 cards perform a lot better than 060s do when it comes to using gayle IDE, PCMCIA etc. Must be a big speed penalty to "speak through a translator".


Igor Majstorovic
(Apollo Team Member)
Posts 406
19 Jan 2020 23:45


@Kyle Blake in this case comparing other CPU is not so relevant in the terms of communication to the other parts of chipset(Gayle) since in this core we are using our own IDE logic not related to onboard Gayle so there are no penalties. Also PCMCIA is not enabled yet, we don't use onboard IDE. As for 030 or 060 it all comes to bus logic and how's done. Accelerator with 060 can be badly designed in that area to the point to become exactly the same as MC68K in terms of performance because skipped clock or bus cycles. It is not just about CPU, it is also about bus access or how precise it is.
There is one of my work back in 2013. who shows that CPU is much slower because badly done bus access. Same goes for any accelerator made on any CPU.
EXTERNAL LINK 
  Regarding our core and its performance we are still in beta stage and lot of things needs to be polished before publishing official core upgrade. Right now, most important thing is to get cards to the people. 


Sebastian Blanco

Posts 148
20 Jan 2020 02:40


when the board and card are installed inside an amiga 1200, does the hdmi port allow for room to fit an hdmi cable ?


Kyle Blake
(Needs Verification)
Posts 108/ 1
20 Jan 2020 06:24


igor majstorovic wrote:
As for 030 or 060 it all comes to bus logic and how's done. Accelerator with 060 can be badly designed in that area to the point to become exactly the same as MC68K in terms of performance because skipped clock or bus cycles. It is not just about CPU, it is also about bus access or how precise it is.
  There is one of my work back in 2013. who shows that CPU is much slower because badly done bus access. Same goes for any accelerator made on any CPU.
  EXTERNAL LINK 

Yeah, that's my point. No doubt v1200 will improve in this


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
20 Jan 2020 07:57


Kyle Blake wrote:

Much slower than V4SA in this task, interesting.

 
Which is expected. Lets look at some numbers:
 
AMIGA 500 chipmem speed is 3.5 MB sec.
 
AMIGA 1200 chipmem speed is 7.0 MB sec peak (with 16bit code 3.5 MB)
 
V4SA chipmem speed is 700 MB sec.
 
 
 
Kyle Blake wrote:

In youtube comments chipram bus saturation is mentioned, but I don't know how true that could be. Doom gets much higher framerate on AGA 060 so the speed problem here can't just be writing the framebuffer...

 
Yes, of course DOOM and Quake is not the same game.
Quake 2 is a lot more complex game and will by design always reach much less FPS than DOOM.
 
Lets make a "simplified" example to explain this.
Lets say the chipmem copy take 30% copy time of A1200, this means you loose 30% of FPS.
On V4SA the copy might only need 5% time == you have 25% more time for FPS.

I think this is very easy to understand.
 
Kyle Blake wrote:

Something I've always wondered about is the effectiveness of turbo cards in adapting different CPUs to the amiga bus. From personal experience 030 cards perform a lot better than 060s
 

This can be easily explained:

68020 and 68030 speak the same bus language (protocol).

68040 and 68060 speak a different bus language (protocol).

The AMIGA mainboard on A1200 and A4000 all speak 68020/030 Language.

This all what an  68030 CPU accelerator card needs to connect is connect the wires one to one. This is very simple.

On the other hand an 040 card or 060 cards needs to do a real time translation of the protocol.
This makes is very easy to understand that a 060 card has always a disadvantage on the bus.
 
Btw the APOLLO 68080 CPU can speak natively 68020/30 bus language. :-) This means no real time translation is needed for the Vampire cards.
 
 


Kyle Blake
(Needs Verification)
Posts 108/ 1
20 Jan 2020 08:49


Gunnar von Boehn wrote:

  Yes, of course DOOM and Quake is not the same game.
  Quake 2 is a lot more complex game and will by design always reach much less FPS than DOOM.
   
  Lets make a "simplified" example to explain this.
  Lets say the chipmem copy take 30% copy time of A1200, this means you loose 30% of FPS.
  On V4SA the copy might only need 5% time == you have 25% more time for FPS.
 
  I think this is very easy to understand.

 
  In my sleep deprived state I forgot that it has to complete chipmem copy before it can carry on to do something else.
 
  Maybe offloading chipmem copy to a coprocessor would help a little - but then it becomes a matter of such a blitter and main cpu fighting over custody of fastram and maybe a small cache. So one problem is replaced by another one.
 
  To be honest, it's not very satisfying because obviously I want the fastest possible 68k Amiga, and the V4SA is that, but the V4SA is also missing old fashioned stuff like floppy drive and serial port. I use that stuff everyday, but I also understand 90% people now don't.
 
 
 
Gunnar von Boehn wrote:
Btw the APOLLO 68080 CPU can speak natively 68020/30 bus language. :-) This means no real time translation is needed for the Vampire cards.

 
  Sounds like something you'd do. Your explanation of the bus differences and the speed penalty confirms that I thought about Amiga design in general. It's why I never liked A4000 with the 3640
 
  Is 080 exclusively speaking 030bus, or does it in V4SA have it's own?


Nixus Minimax

Posts 416
20 Jan 2020 09:06


Kyle Blake wrote:
In my sleep deprived state I forgot that it has to complete chipmem copy before it can carry on to do something else.
 
  Maybe offloading chipmem copy to a coprocessor would help a little

This would require changing the code to make it use the coprocessor. Why not just use the RTG version instead and skip the copying to chipmem altogether?




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
20 Jan 2020 09:13


Kyle Blake wrote:

  In my sleep deprived state I forgot that it has to complete chipmem copy before it can carry on to do something else.
   
  Maybe offloading chipmem copy to a coprocessor would help a little - but then it becomes a matter of such a blitter and main cpu fighting over custody of fastram and maybe a small cache. So one problem is
  replaced by another one.
 

 
Yes on old AMIGA systems 3D games were coded in chunky mode,
and then for display copied to AGA doing a C2P conversion.

So yes your idea to do this C2P parallel is a very good idea.
 
And actually APOLLO 68080 can do such C2P copies in parallel if you program it the right way.

68080 has 2 fully independent memory busses and could do such copy in parallel - while calculating the next screen.

So if a coder wanted he/she could tweak such old games and get another 5 FPS more.
 
On the other hand you can just the game on RTG/chunky right away and save the copy altogether ... :-)
This always works on all games.
QUAKE2 will run faster if using Chunky mode on the Vampire1200

 
 
 
Kyle Blake wrote:

Sounds like something you'd do.
Your explanation of the bus differences and the speed penalty confirms that I thought about Amiga design in general. It's why I never liked A4000 with the 3640
   
Is 080 exclusively speaking 030bus, or does it in V4SA have it's own?

 
Apollo 68080 has 2 busses.
Both busses can operate fully in parallel at the same time.
This makes the 68080 CPU very special - as "normal" CPU has only 1 bus.
 
Apollo 68080 is also multilingual.
One bus it can speak 68000/68010/68020/68030 Bus protocol.
This means it speaks natively the language of all AMIGA mainboards from Amiga 1000 to AMIGA 4000.
 
The other bus the APOLLO CPU can speak natively SDRAM and DDRAM language. This means it can directly talk to all modern memory chips
  on the market - which not other 68K can do.
 
Both busses of the 68080 CPU can operate fully in parallel.
This bus design is one of the reasons of APOLLO 68080 high performance.


Andy Hearn

Posts 374
20 Jan 2020 09:28


great stuff! i have some other thoughts regarding bus protocol etc, but i won't go off topic.

So, if this is the performance of the game on the native chipset, with a C2P routine and chip ram copy. then what is this going to be like running this through RTG using a direct chunky frame buffer? was my next thought.

quake2 on AGA. QUAKE2! is the HL2 source engine open source yet? :D

i remember loading up a coverdisk demo of alienbreed3D on stock 1200 with a 4meg ram board and just walking around staring at a "real time pool of water" not being able to figure out what i was looking at. but i liked it.


Roy Gillotti

Posts 517
20 Jan 2020 11:03


Andy Hearn wrote:

  is the HL2 source engine open source yet? :D
   

    No, but the open-sourced Xash3d engine is pretty much a spot on rewrite of the whole engine and just needs the Half-Life data files to play.
   
    It plays well on even some 12 year old Ti OMAP3 SoC, so maybe with a lot of work?
   
    EXTERNAL LINK


Kyle Blake
(Needs Verification)
Posts 108/ 1
20 Jan 2020 12:39


Roy Gillotti wrote:

Andy Hearn wrote:

  is the HL2 source engine open source yet? :D
   

    No, but the open-sourced Xash3d engine is pretty much a spot on rewrite of the whole engine and just needs the Half-Life data files to play.
   
    It plays well on even some 12 year old Ti OMAP3 SoC, so maybe with a lot of work?
   
    EXTERNAL LINK 

That's goldsrc not source engine, not so impressive achievement imo.

Of course source engine doesn't have much good games, so no loss really.


Roy Gillotti

Posts 517
20 Jan 2020 15:28


Kyle Blake wrote:

   
    That's goldsrc not source engine, not so impressive achievement imo.
   
    Of course source engine doesn't have much good games, so no loss really.
 

 
  My mistake, thought you mentioned regular HL, not HL2 in the comment... Regular Half-life is much more reasonable of a request for the current vampire capabilities, but still would likely be a serious undertaking to get running well.


Michael AMike

Posts 152
21 Jan 2020 15:01


Yesterday I've got my V1200 and it's an impressive piece of hardware. First tests were flawless and I am looking forward to the weekend to play with the new config.


Manuel Jesus

Posts 155
21 Jan 2020 17:06


Congrats I await mine with baited breath!



Michael AMike

Posts 152
21 Jan 2020 20:27


Does the Indivison work with the V1200? I've tried it but got only a black sreen...D520 works without issues.


Stefano Briccolani

Posts 586
21 Jan 2020 20:46


In this video from Oufparty BigGun had an indivision on v1200, so I think indy works ok on v1200 (I don't have one for test)
  EXTERNAL LINK


Kyle Blake
(Needs Verification)
Posts 108/ 1
21 Jan 2020 21:10


No reason for indivision not to work. It's only a flickerfixer, even if it's a smart one. Amiga sees only a lisa.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
22 Jan 2020 08:39


Kyle Blake wrote:

  No reason for indivision not to work. It's only a flickerfixer, even if it's a smart one. Amiga sees only a lisa.
 

 
One could assume this.
But reality is different.
 
The In-division uses some new-invented registers in the AGA chipset range. These registers are not fully documented.
So access to these registers might be prohibited by SAGA.
 
On the V2 users did had the same problem.
Jens Schönfeld gave us at this time incomplete information.
Therefore the first generation of Indivision could never work.
Jens only gave us enough information to make his 2nd Version of Indivision working and not cared about customers using the 1st version.

We took the effort to dis-asm his drivers to also enable the his first generation of cards.
I doubt that we have time to do this again.

posts 306page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16