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
Information about the Apollo CPU and FPU.

Debug Tools to Fix Vampire Incompatibilities?

Otto PS
(Needs Verification)
Posts 26/ 1
07 Jul 2020 15:26


I have found several compatibility problems in my v1200 7389b 2.12 core (tested on r55 coffinos and 3.1 amigaos) mostly related to whdload demos (Example: spaceballs steateoftheart) also with friendly amigaos apps (Example: Envoy).
I understand that the Apollo team does not want to address those issues right now.
Most of the problems found do not happen with accelerators with real 68020/30/40/60 or winuae.

With this in mind, it occurred to me that the apollo team could give tools to the community to debug with the apollo vampire hardware considering that it has a proprietary MMU that could be useful.
With this tool, incompatibilities could be detected and could even be taken into account to perform specific whdload slaves to solve the problems. Patches could also be made on existing binaries where there is no access to the source code.

I personally have not worked in ASM 68k for several years, but I usually do it daily for x86, x64 and ARM. I would have no problem refreshing my memory a bit to face this task;)

Apollo Team: This would be a good opportunity for the community to help. And deal with the claims about compatibility of your products.

Thanks,
Otoo


FRAXINOUS Eric
(Needs Verification)
Posts 48/ 1
07 Jul 2020 19:36


It's funny. I've a lot of incompatibility with V1200 on whdload demo but not with stateOfTheArt. My experience show that v1200 can be very motherboard sensitive... The last beta core works mostly well on my 1A motherboard but for most users, the system doesn't even boot... On my 1B and 1D4, i can't use pcmcia CF card reader... It might be very useful to enumerate all the incompatibilities with motherboard revision and fixes to know if it can be hardware or v1200 core problems...


Sean Sk

Posts 488
08 Jul 2020 01:00


Hi Otto,

Sounds like a good idea. There are several WHDLoad games that simply do not work on the Vampire and the WHDLoad team doesn't seem to be terribly interested in looking into them.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
08 Jul 2020 09:17


Otto PS wrote:

  I have found several compatibility problems in my v1200 7389b 2.12 core (tested on r55 coffinos and 3.1 amigaos) mostly related to whdload demos (Example: spaceballs steateoftheart) also with friendly amigaos apps (Example: Envoy).
  I understand that the Apollo team does not want to address those issues right now.

 
I very much like your proposal that more people should work on AMIGA  programs, and develop for Amiga!
 
   
At the same time I see that your conclusions seem technically incorrect.
And I find your claim about the Apollo-team really insulting.
   
Can you please explain where do you think to know what the APOLLO-TEAM wants and works on?
How can you make false claims that the Apollo team would not care address this?
   
To make this clear, the Apollo-Team works on addressing _ALL_ problems.
 
 
   
Let us look at this in detail:
WHDLOAD issue like you describe, are in my experience often problems of WHDLOAD but can fixed by a correct install and correct setup of your system.
   
Lets give more information to better understand this.
Its just a matter of fact that many AMIGA demos, and games are unclean.
To say it clear: many AMIGA demos have bugs in them.
Many of these bugs show on faster CPUs.
A typical bug is missing "WAIT BLIT" calls.
WAITBLIT is needed for coding AMIGA.
Its important to keep the BLITTER and the CPU in sync.
A missing WAITBLIT might cause no problem if the CPU is slower than the Blitter.
This is why coders only coding on slow 68000 CPU sometimes forgot WAITBLITs - as forgetting this causes no harm on the slow CPU and will only show up as problem an faster CPU accelerators.
   
So lets say this again.
Many demos are bugged with such problems.
WHDLOAD follows here often 3 directions:
1) If the bug not shows on the system used by the WHDLOAD slave coder  ....  - then its sometimes ignored!
2) Sometimes these bugs are fixed/patched
3) Sometimes the WHDLOAD slave tries to slow down the CPU to make these bugs be less potent.
 
UAE runs the Blitter in an autosync mode - called immediate - to circumvent some of these coding bugs. 
 
Lets repeat "Often these bugs are NOT fixed by the WHDLOAD slaves"
This means these bugs show up for you - if you have a faster CPU.
Or these bugs will show up - if WHDLOAD fails to slow down the CPU.
   
A common trick that WHDLOAD does is turning caches OFF to make the CPU slower to "avoid" some code bugs which show if the CPU runs faster.
   
Now Turning CPU caches OFF works different on each 68K CPU.
This was stupidly done by Motorola.
So for correctly turning the CACHES off its critical that WHDLOAD identifies the CPU correctly to use the matching instruction to turn the cache of this CPU model.
   
APOLLO 68080 is the newest CPU, and offers a mix in features of 68040 and 68060 CPU. This mix can confuses old WHDLOAD slaves.
If an old WHDLOAD slave miss detect the CPU and uses the wrong instruction to turn the cache then this has no effect - and these problems will happen as you describe.
   
So lets make this clear - This is not a compatibility problem of the CPU. What you have here is the problem of WHDLOAD to identify what APOLLO 68080 is - and use the right instruction.
But actually the problems are buggy old demos. 
   
Also lets make clear here that this is also NOT related to the MMU and having or not having an MMU will make no difference in this problem - and also an MMU makes no difference in debugging this.
 
 
How can you best fix this in your install?
Fixing the CPU detection in 1000 old WHDLOAD slaves would be one options - But this is a lot of work.
Easier would be to set the CPU into the right state BEFORE starting the WHDLOAD slave. Unfortunately this not works with normal CPU instructions reliable - as WHDLOAD completely ignores the system CPU caches settings of the system - and will reset them.
 
To solve this the Apollo Team uses here a mode called Turtle-Mode when your WB install is correctly setup then the CPU-Mode will be set the turtle mode before starting WHDLOAD to fix this.
 


Kamelito Loveless

Posts 259
08 Jul 2020 16:46


Without talking about software compatibility, what is the % of compatibility With the Amiga chipset in on part and the compatibility with the range of 68k Motorola CPU?


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
08 Jul 2020 16:50


Kamelito Loveless wrote:

Without talking about software compatibility, what is the % of compatibility With the Amiga chipset in on part and the compatibility with the range of 68k Motorola CPU?

Thats a strange question.
Maybe you can help me first to understand how you mean this,
by telling me, what is the percentage of compatibility of the 68040 CPU with the 68030 CPU?


Otto PS
(Needs Verification)
Posts 26/ 1
08 Jul 2020 16:58


Gunnar:

I've reread my message and the only hard part has been that the apollo team does not want to solve certain compatiblity issues.
It is hard but it's not an insult, I do not perceive predisposition to solve them at the moment.

Maybe you have not read my comment about the MMU correctly or there are some translation problems, I will try to say it in a more detailed way: a debug tool that works with the custom MMU of the 68080 would be useful to find the program crashes. Also an RT debugger that uses the 68080 registers and special features would be great.

Regarding the tests with whdload, I have done it with CoffinOS r55 and with AmigaOS 3.1 with and without RTG. I've also tried disabling caches manually (via 68040 CCR, disabling superscalar instruction processing and vampire turtle mode). Many problems persist.

Regarding tests with winuae. I NEVER test compatibility by activating immediate blitter, why do you assume that?

I'm not interested in taking this to the personal level or hurting susceptibilities. I just wanted specific tools for 68080 and to provide solutions, generating information to make new whdload slaves and app binary patches so they can work properly in apollo 68080.
Assuming it is not possible, I am going to make a list of incompatibilities asking other users for help to verify my tests. I have a lot of free time thanks to COVID19.
I hope to get a Warp 1260 sometime so I can compare the collected compatibility data from my V1200. That would be interesting.

Thank you very much for your answer!


Kamelito Loveless

Posts 259
08 Jul 2020 18:17


I meant at the HW level. I guess you’ve a range of automated tests to verify the compatibility against the Motorola CPUs and the range of Amiga chips. So say your tests cases are complete (everything is covered) you run them each time you change something to avoid régressions, are all the tested OK when you release a stable core?
In one sentence if you test every programs/games/demos...that are properly written they’ll work properly on the Vampire right?


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
08 Jul 2020 18:52


Kamelito Loveless wrote:

  I meant at the HW level.
 

I think I know what you want to hear.
And our test show 100% success

But if one is very very nitpicking then your question is completely 
look at percentages in an absolute correct way then this question is in impossible question.

As each MOTOROLA CPU is different.
And if you compare different Motorola chips with each other then
none of the Motorola chips will reach 100%.
 
As the 68020 is not 100% compatible to the 68040
and the 68040 is not 100% compatible to the 68030
and the 68060 is not 100% compatible to the 68040.
 
So you conclude there is never a 100%.
And how do you measure percentage?
What percentage would a 68040 have - when you compare it with an 68030?


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
08 Jul 2020 19:11


Otto PS wrote:

I do not perceive predisposition to solve them at the moment.

You are obviously not informed on what the team works
neither do you have access to the teams internal Workitem and todos list.

There is nothing wrong with you not knowing on what the team works.
But do you think making claims about what the team does is correct then?

Otto PS wrote:

  Maybe you have not read my comment about the MMU correctly or there are some translation problems, I will try to say it in a more detailed way: a debug tool that works with the custom MMU of the 68080 would be useful to find the program crashes. Also an RT debugger that uses the 68080 registers and special features would be great.

I agree fully with you.

 
Otto PS wrote:

Regarding the tests with whdload, I have done it with CoffinOS r55 and with AmigaOS 3.1 with and without RTG. I've also tried disabling caches manually (via 68040 CCR,...

As I explained before this has zero effect as WHDLOAD will by itself overwrite this.
 

If you are interested in participate in the development and further improvement of the debug tools then contact us on Slack.

But please refrain from making post about what the team want todo or not wants to do - as long you have no clue about what the teams does.


Otto PS
(Needs Verification)
Posts 26/ 1
08 Jul 2020 20:30


Gunnar von Boehn wrote:

Otto PS wrote:

  I do not perceive predisposition to solve them at the moment.
 

  You are obviously not informed on what the team works
  neither do you have access to the teams internal Workitem and todos list.
 
  There is nothing wrong with you not knowing on what the team works.
  But do you think making claims about what the team does is correct then?
 
 
Otto PS wrote:

  Maybe you have not read my comment about the MMU correctly or there are some translation problems, I will try to say it in a more detailed way: a debug tool that works with the custom MMU of the 68080 would be useful to find the program crashes. Also an RT debugger that uses the 68080 registers and special features would be great.
 

  I agree fully with you.
 
 
 
 
Otto PS wrote:

  Regarding the tests with whdload, I have done it with CoffinOS r55 and with AmigaOS 3.1 with and without RTG. I've also tried disabling caches manually (via 68040 CCR,...
 

  As I explained before this has zero effect as WHDLOAD will by itself overwrite this.
 
 
  If you are interested in participate in the development and further improvement of the debug tools then contact us on Slack.
 
  But please refrain from making post about what the team want todo or not wants to do - as long you have no clue about what the teams does.

I think we have a communication problem here, I understand that eventually the Apollo team will review some reported issues, but in the case of Envoy (one of my original examples) you have answered "We would like to do this - but lets not create false hopes - the team is very busy working on major updates at the moment. So there is today not much free time for this disasm this tool." CLICK HERE 
Whenever I referred to what the apollo team wants to do about certain issues, I did it in a temporary term "right now" (you can verify it in my original post) and what you have previously answered. I have also started my original sentence with "I understand" (you can check it in my original post too) since it is a conclusion based on answers in similar topics in this forum.

I do not want to magnify this situation, but I think it is appropriate to clarify it.

I would like to help with reports and debugging problems. We will surely continue exchanging messages in slack and this forum.

Thanks!


Kamelito Loveless

Posts 259
14 Jul 2020 15:16


This is true for Amigas too, check this thread for some explanations.
EXTERNAL LINK


Kamelito Loveless

Posts 259
01 Aug 2020 14:49


What is missing  IMO is a debugger that support all 68080 features for now to the best of my knowledge there is none which is really disturbing.
Asmpro 1.18 was on the right track but development halted a longtime ago which is sad.
Gunnar any work on that direction? The best path seems to be Asmpro1.18.


posts 13