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
The team will post updates and news about our project here

Vampire V2 Is Now AmigaOS 3.1.4 Readypage  1 2 3 4 5 6 7 8 9 

Stefano Briccolani

Posts 586
11 Aug 2019 08:09


Nailed the problem to VampireMaprom314 when is active (no difference between the standard a1200 3.1.4 rom or a custom one), the FPU disappears.
  VampireMaprom314 on cold boot gives also a guru-meditation. (Then restarts ok on subsequent soft-boots).
  If I boot a 3.1 standard floppy (on cold boot, without maprom) sysinfo sees the FPU, so the issue is with maprom because everytime I activate it FPU disappears..

Tried it on v600 with core 2.12RC2 on a fresh install of 3.1.4 (updated 3.1.4.1) and Bestwb 1.2
 


Stefano Briccolani

Posts 586
11 Aug 2019 09:01


I noticed that even in this video by Apollo team member Simo showing maprom function of vampire, witchamiga showed no FPU. If I remember correctly core 2.7 had the FPU so witchamiga should have detected it..
  EXTERNAL LINK   
[GOLD2.7] (02.03.2018)
* Added fully pipelined hard FPU with peak 78 MFlops
* Added native support for all 68882 FPU operations without need of extra libraries


Stefano Briccolani

Posts 586
11 Aug 2019 09:54


Update: I tried even the VampireFlashrom314. Same results as maprom. Guru meditation at the first boot (then at successive boots runs ok), and no FPU detected.
So it seems that maprom and flashrom share the same code as Henryk Richter said..


Stefano Briccolani

Posts 586
11 Aug 2019 21:15


Update: problem solved (for now) is that MMULib.lha that causes the problem of guru at start. Then the old commodore 68040.library 37.30 activated the fpu.
I don't know if it's the optimal solution for vampire, but it works.
Problem is that even BestWB installs the MMULib, but that's another story..



Henryk Richter
(Apollo Team Member)
Posts 128/ 1
12 Aug 2019 19:57


Stefano Briccolani wrote:

Update: problem solved (for now) is that MMULib.lha that causes the problem of guru at start. Then the old commodore 68040.library 37.30 activated the fpu.

Oh, dear. My thanks to you for digging into this matter and finding the culprit. As it turns out, the 68080 is quite probably mis-detected as 68060 in some place(s) by the combination of tools involved, leading to crashes on one side and disabled FPU on the other side.

In a technical sense, the disabled FPU saved your Amiga from a reboot-crash loop caused by inappropriate attempted 060 fixes/hacks (whatever you'd like to call them). Short Explanation and history notes: AmigaOS versions up and including 3.9 were not 68060 compatible by themselves - or in other words the 68060 changed the supervisor level FPU stack frame layout in an incompatible fashion compared to the 68040. The predominant fix consisted of a ROM hook ("F0 ROM" or BOOTROM) that disabled the FPU to have it re-enabled by SetPatch later on. The 060 Library then patched all active Tasks with a 68060 stack frame and custom task switching code such that the FPU would work from that point on.

But all of that is not necessary for the 68080. It's FPU stackframe is the same as the 68040, hence implicitly supported by Exec. The FPU doesn't have to be disabled while booting. Furthermore, the software assisted parts are part of the Core firmware and don't require a support library.

The bottom line is the following:
The 68040.library from Commodore may be installed and doesn't harm a running system but serves only one purpose: to stop  the scarecrow (c:cpu) in the 3.1.4 startup-sequence from squealing.

The most efficient course of action (in terms of performance and RAM usage) would be skip installation of a disk-based 68040.library and just commenting out c:cpu by a ";" prepended to the respective line in s:startup-sequence. Btw. Commodore's (and later) 68040.library will not only provide FPU support (that's never called) but also patch several places in the Kickstart with safeguards that have absolutely no bearing on 68080 (i.e. slightly slow down some functions).

The 68040.library scheduled to be shipped with the Gold 2.12 ROM is customized for the 68080 and it's internal properties. I'll update the MapROM314 and Flash314 tools will once it's tested well enough for general deployment.

For now, MMULib and any 68060.library have to be avoided in any Vampire installation. They can't and won't bring any benefit to Vampire owners, quite on the contrary.


Mike Kopack

Posts 268
12 Aug 2019 21:34


Interesting. This would be really good stuff to pass on to the maintainer of BestWB so it can check for the vampire and not mess things up on install.


Kamelito Loveless

Posts 260
12 Aug 2019 23:27


I guess it has been tested on Amigas.


Stefano Briccolani

Posts 586
13 Aug 2019 22:04


Bestwb1.2 installer is just a batch file that unzip some zip files. The mmulib is on fourth disk on a file named 4.zip
So a solution could be to unzip this file, remove mmu.library, 680x0.library, 68060.library, 68040.library, 68030.library, 68020.library, env/mmu-configuration and re-zip the file as 4.zip and put it back on the fourth BestWb floppy. If someone is in contact with the author(gulliver) can ask him to make an optional install of these libs,instead of an automatic one..


Mike Kopack

Posts 268
14 Aug 2019 02:42


Stefano Briccolani wrote:

Bestwb1.2 installer is just a batch file that unzip some zip files. The mmulib is on fourth disk on a file named 4.zip
  So a solution could be to unzip this file, remove mmu.library, 680x0.library, 68060.library, 68040.library, 68030.library, 68020.library, env/mmu-configuration and re-zip the file as 4.zip and put it back on the fourth BestWb floppy. If someone is in contact with the author(gulliver) can ask him to make an optional install of these libs,instead of an automatic one..

I'm trying over on EAB to ask but I'm getting the impression he and some others are Anti-Vampire based on the responses.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
14 Aug 2019 03:00


Stefano Briccolani wrote:

Bestwb1.2 installer is just a batch file that unzip some zip files. The mmulib is on fourth disk on a file named 4.zip
  So a solution could be to unzip this file, remove mmu.library, 680x0.library, 68060.library, 68040.library, 68030.library, 68020.library, env/mmu-configuration and re-zip the file as 4.zip and put it back on the fourth BestWb floppy. If someone is in contact with the author(gulliver) can ask him to make an optional install of these libs,instead of an automatic one..

From BestWB author:

Hi,

Well, it seems there is some demand for VampireV2 support. Then I will do something about it to please them.

Give me a couple of days and I will probably re-release BestWB 1.2 with Vampire support.

I will keep you updated,
Best Regards,
Ignacio (a.k.a Gulliver)



Stefano Briccolani

Posts 586
14 Aug 2019 04:53


Excellent!!!


Sean Sk

Posts 488
14 Aug 2019 05:32


Mike Kopack wrote:

I'm trying over on EAB to ask but I'm getting the impression he and some others are Anti-Vampire based on the responses.

Maybe, but I tend to agree with Thomas Richter when he points out that perhaps the Vampire's FPU could benefit from emulation of extended precision that could be offered by such libraries. That's what I "think" he is saying, but I am by no means an expert. Perhaps there could be co-operation between the two teams in this regard.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
14 Aug 2019 07:49


sean sk wrote:

Maybe, but I tend to agree with Thomas Richter when he points out that perhaps the Vampire's FPU could benefit from emulation of extended precision that could be offered by such libraries. T

 
This is nonsense.
The libraries offer absolutely nothing which APOLLO 68080 does not have already.
 
APOLLO 68080 does NOT need the 68060/68040 libraries.
These libraries will not improve the FPU on APOLLO.

Do not use MMU.lib and 68060.lib.
The best advice I can give you is to delete MMU.Lib and 68060 Lib on your system.

For those interested, the technical explanation behind this:

The 68881 FPU came with buildin ROM code to calc several math operations. SIN(), COS() etc.

The 68040 FPU did not have the ROM core to calc these functions -
it needed a software library to calc them. The 68040.lib does this job.

Apollo 68080 comes with buildin ROM code to calc COS(), SIN() etc.
This means no library from disk is needed for us!

Moto did remove several other instructions like MOVEP in the 68060 CPU. The 68060 did change the stackframe at some places.
This means the 68060 is not fully compatible to the 68040 and other 68K.
The 68060 lib is needed to emulate these instructions.
Several games like e.g. the original SPEEDBALL 2 will crash on 68060 because of the missing instructions.
WHDLOAD comes with extra patches for those games to emulate the instructions.

APOLLO 68080 does include all instructions.
This means the original games will run on APOLLO without patches.

The 68060.lib is NOT useful for us.
Installing this library will not improve your system at all.

The same is with MMU.lib.
MMU lib will patch the system /install some hacks
to avoid some bugs in older CPUs.
APOLLO 68080 is not suffering from these bugs.
Installing "hacks" is not good and not needed.
My advice: Do not use this library!




Sean Sk

Posts 488
14 Aug 2019 08:22


Gunnar von Boehn wrote:

This is nonsense.
The libraries offer absolutely nothing which APOLLO 68080 does not have already.
     
APOLLO 68080 does NOT need the 68060/68040 libraries.
These libraries will not improve the FPU on APOLLO.
     
The best advice I can give you is to delete MMU.Lib and 68060 Lib on your system.

   
Ok fair enough, but what was Thomas talking about then? Because he seemed to be focusing on the precision of the 68080 FPU and felt there could be a benefit.
   


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
14 Aug 2019 08:47


sean sk wrote:

  Ok fair enough. Are you able to offer an explanation as to what Thomas might be talking about?
 

 
My experience with Thomas is that he sometimes talks bad about some projects. Thomas sometimes talks against Cloanto, Aros, Open Source, etc.
 
 
If I look at AMIGA at the bigger picture, then I see this:
 
There is Hyperion. Hyperion clearly wants all improvements for AMIGA happen in PPC-land only.
Hyperion states clearly that they hope that all 68K users move to PPC.
Any new 68k CPU or any improvement in 68K land is not matching Hyperions goals.
 
Then there are HW-vendors like Individual, which sell old-style 68030 accelerators. New much better 68K-CPUs with improvements like AMMX are competition to them.
 
I know that Thomas is very good friend to both Individual and Hyperion.
 
As matter of fact, Thomas does not have a Vampire, he does not have a 68080 CPU.
Thomas does not code on APOLLO 68080, all his "knowledge" about the 68080 CPU is 2nd hand, old, hearsay level.
 
Based in this "setup", I would take all what he says about Vampire with a grain of salt.


Gildo Addox

Posts 31
14 Aug 2019 09:21


Ahhhh, sooo, is Thomas = ppcamiga1 ?

Now things become clearer to me


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
14 Aug 2019 10:57


Gildo Addox wrote:

  Ahhhh, sooo, is Thomas = ppcamiga1 ?
   
  Now things become clearer to me
 

   
I can not verify this.
Please no rumors. Lets talk facts only.
   
   
Facts:
   
APOLLO 68080 should be identified by the OS with attention flag $A (A=Apollo)
The Attention flag for the 68060 should NOT be set on any 68080 system.
   
The 68060 flag will indicate to some tools
"help me, I'm an 060. I miss instructions and needs software patches to work."
   
The OS should never set 060 flag on 080 core!
The 68060.lib should never be loaded on an 080 system.
The old 060 missed many instructions.
Not only SIN() COS(), but also Integer instructions like MUL64 and DIV64 - therefore the 68060 needs software patches to avoid or emulate those instructions in existing software.

The 68080 does support all these instructions native.
The 68080 does NOT need these software hacks.

If the 060.lib gets loaded this indicates a bug in the workbench/os.

The 68080 also needs no MMU hacks to run AMIGA OS.
Do not try to run MMUlib, it will not help you!

That Apollo 68080 should be clearly identified in OS 3.1.4 with flag $A. This was discussed and agreed this way with Olaf Barthel (Hyperion).
APOLLO clearly show its core version to the OS in the PCR Register.
 
Gulliver claiming that Apollo is not identified by OS 3.1.4,
is either indicating a bug in OS 3.1.4 or is just wrong claim.

 


Gildo Addox

Posts 31
14 Aug 2019 12:25


@Gunnar

You are right. But the guy "ppcamiga1" is constantly writing factually wrong things in forums about APOLLO 68080.

Now, I always wanted to talk to him, because I really don't know why he is doing that. Why is he telling lies? I really don't like that ppcamiga1 is constantly putting wrong information into forums about the Vampire accelerators.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
14 Aug 2019 12:39


Gildo Addox wrote:

@Gunnar
 
  You are right. But the guy "ppcamiga1" is constantly writing factually wrong things in forums about APOLLO 68080.
 
  Now, I always wanted to talk to him, because I really don't know why he is doing that. Why is he telling lies? I really don't like that ppcamiga1 is constantly putting wrong information into forums about the Vampire accelerators.

Market competition is a simple reason.

Lets talk facts:
- VAMPIRE is about 20 times faster than a 68030 Accelerator.
- VAMPIRE is over 20 times faster than MIST / FPGA ARCADE.
- VAMPIRE is faster than 68060 accelerators.

This means VAMPIRE is a big competition for people selling any of those.

Also PPC people see Vampire as "menace".
Companies like Hyperion want that people abandon the 68K and buy PPC systems. So every happy VAMPIRE owner is making these people less happy.




Kamelito Loveless

Posts 260
14 Aug 2019 15:35


They’re “saying” also Incompatible MMU, does not anounce it’s cpu properly to the system, does not use AutoConfig etc. About the fpu  :  do not use extended mode even if requested so it is using below double precision check the EAB thread  about BestWB 1.2 so is this true? If true what are the reasons behind these choices.

posts 167page  1 2 3 4 5 6 7 8 9