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

BFINS Instruction Bug?page  1 2 

Otto PS
(Needs Verification)
Posts 26/ 1
21 Jul 2020 21:54


Philippe Flype wrote:

  The 080 already integrates that specific behaviour. The gouraud fx works on vamp since a year. That Bit15 (Dn/An selector) is ignored like on the real 020/030.
 

  Correct, but my questions are conceptual on whether to keep certain bugs from the original CPUs or not and how to determine compatibility. Since the MC68000 documentation does not enable bit 15 with a value other than 0 for that instruction, would it be correct to raise an exception vector 4? I think so, but that would not be backward compatible ... Clearly the problem is not AC68080 or tg68k. Surely there is some other similar case.


Steve Ferrell

Posts 424
22 Jul 2020 01:02


Otto PS wrote:

Philippe Flype wrote:

  The 080 already integrates that specific behaviour. The gouraud fx works on vamp since a year. That Bit15 (Dn/An selector) is ignored like on the real 020/030.
 

  Correct, but my questions are conceptual on whether to keep certain bugs from the original CPUs or not and how to determine compatibility. Since the MC68000 documentation does not enable bit 15 with a value other than 0 for that instruction, would it be correct to raise an exception vector 4? I think so, but that would not be backward compatible ... Clearly the problem is not AC68080 or tg68k. Surely there is some other similar case.

Seriously?  Don't you think it's a bit ridiculous for the Apollo team to even consider modifying the 68080 core for the benefit of badly written demos that make up less than .01 percent of the total Amiga software base?  You could write patches for these poorly written demos and/or help update WHDLoad to run them properly.  The Apollo team has more important things to do than chase down every demo to ensure that it runs unmodified on a Vampire. 

There are already a number of ways of dealing with poorly coded demos, games and apps so it appears that you're trying to create a problem where one doesn't exist.



Gunnar von Boehn
(Apollo Team Member)
Posts 6197
22 Jul 2020 06:43


Otto PS wrote:

  Correct, but my questions are conceptual on whether to keep certain bugs from the original CPUs or not and how to determine compatibility. Since the MC68000 documentation does not enable bit 15 with a value other than 0 for that instruction, would it be correct to raise an exception vector 4? I think so, but that would not be backward compatible ... Clearly the problem is not AC68080 or tg68k. Surely there is some other similar case.
 

Actually Vektor-4 does not really match.
Vektor-4 is reserved for ILLEGAL INSTRUCTION.
Technically its an unsupported Parameter that this demo uses.
 
Maybe it makes sense to look at MOTOROLA?
 
Using illegal "parameters" was generally not tracked by Motorola CPUs. Motorola was very clear here how programs should behave
and doing such error will make programs suddenly break on future CPUs.
 
Regarding "bugs" from CPUs, the rule that MOTOROLA follows is very clear.
Of all Motorola CPUs several "MASK" version exists.
These MASK Versions were made do fix bugs.
For example of the 68060, there are 6 MASK Versions.
The first mask of the 68060 did contain many bugs.
Motorola created several MASK to fix all of them.
The goal was always to fix all bugs.
Never to be bug compatible.
 
And yes the different MASK versions of the 68000, 68010, 68020, 68030, 68040 and 68060 - do all behave differently.
 
And as you might know the first pre version of the 68000 CPU
even supported an instruction which was not in the official handbook. And which was removed in all later versions.



Philippe Flype
(Apollo Team Member)
Posts 299
22 Jul 2020 09:24


Steve Ferrell wrote:

Otto PS wrote:

 
Philippe Flype wrote:

    The 080 already integrates that specific behaviour. The gouraud fx works on vamp since a year. That Bit15 (Dn/An selector) is ignored like on the real 020/030.
   

    Correct, but my questions are conceptual on whether to keep certain bugs from the original CPUs or not and how to determine compatibility. Since the MC68000 documentation does not enable bit 15 with a value other than 0 for that instruction, would it be correct to raise an exception vector 4? I think so, but that would not be backward compatible ... Clearly the problem is not AC68080 or tg68k. Surely there is some other similar case.
 

 
  Seriously?  Don't you think it's a bit ridiculous for the Apollo team to even consider modifying the 68080 core for the benefit of badly written demos that make up less than .01 percent of the total Amiga software base?  You could write patches for these poorly written demos and/or help update WHDLoad to run them properly.  The Apollo team has more important things to do than chase down every demo to ensure that it runs unmodified on a Vampire. 
 
  There are already a number of ways of dealing with poorly coded demos, games and apps so it appears that you're trying to create a problem where one doesn't exist.
 

It's easy for you to tell that after the bug has been clearly identified. Once it's located it's 30sec time spend for gunnar. If i decide to chase a bug that also were under tracking by the tg68 team or the fpgaarcade team it is easy to understand that nobody was 100% sure if it was a more Serious bug in the Bitfield instruction set or anything else. Bugtracking is like fishing, sometimes you catch a big fish, sometimes you only fish false positives. Gunnar didnt lost time in this chase. So please such rude conclusion is actually the ridiculous point here. Also if the behaviour is proved to be same on 020/030/040/060, shouldnt it be mimic on the fpga ? My opinion is that it have to be same than legacy one.



Gunnar von Boehn
(Apollo Team Member)
Posts 6197
22 Jul 2020 09:31


Philippe Flype wrote:

Also if the behaviour is proved to be same on 020/030/040/060, shouldnt it be mimic on the fpga ?

 
For sure, one can have different opinions here.
 
I always try to ask myself : "What would MOTOROLA do?"
In my experience Motorola always tried to fix the CPU to the best and never tried to "inherit" bugs from one generation to the next.
 
Of every CPU model that Motorola produced they even produced many different versions so called MASK.

They produced new versions to fix bugs.
So if they found a wrong behavior they fixed it and made a new MASK version. This means the different version of the 68000 - do behave differently. As newer version of the 68000 are not bug compatible but have the bugs fixed and the behavior changed.
 
Every time Motorola encountered something being not right - the solution was FIXING it.
I believe that MOTOROLAs would never say that bug-compatible is the right way.



Philippe Flype
(Apollo Team Member)
Posts 299
22 Jul 2020 09:43


Actually on the 060 there are trap vector for unsupported Effective Address. In some way it is the case scenario we are here.
     
However, this thread was about understand the issue of one of the major early A1200 demos ('early' is what makes me think of a 020 assembler glitch, btw).
     
Now it is understood, it is no need that the thread slips in debates such 'is fpga is emulation' or 'is emulation should be 1:1 official doc or 1:1 official + undocumented'. It's always tight to personal opinions and vocabulary. The 080 implement this specific behaviour because it costed nothing, nor time, nor fpga room, nor harm to any extended plan inside the Bitfields instruction set.
     
     


Steve Ferrell

Posts 424
22 Jul 2020 20:04


Philippe Flype wrote:

 
  It's easy for you to tell that after the bug has been clearly identified. Once it's located it's 30sec time spend for gunnar. If i decide to chase a bug that also were under tracking by the tg68 team or the fpgaarcade team it is easy to understand that nobody was 100% sure if it was a more Serious bug in the Bitfield instruction set or anything else. Bugtracking is like fishing, sometimes you catch a big fish, sometimes you only fish false positives. Gunnar didnt lost time in this chase. So please such rude conclusion is actually the ridiculous point here. Also if the behaviour is proved to be same on 020/030/040/060, shouldnt it be mimic on the fpga ? My opinion is that it have to be same than legacy one.
 

If you want to spent the majority of your time on "fishing expeditions" chasing down illegal instructions in poorly written and obscure demos, then knock yourself out.  What you do with your time is your business, but with all the other issues with the Vampire and AROS that need to be addressed I consider such fishing expeditions to be a poor use of time or at the least an issue with misguided priorities.



Philippe Flype
(Apollo Team Member)
Posts 299
23 Jul 2020 07:06


You dont get it. How you know it's an illegal instruction before you started debug ? With a cristal ball ?


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
23 Jul 2020 07:09


Steve Ferrell wrote:

  If you want to spent the majority of your time on "fishing expeditions" chasing down illegal instructions
 

   
If you are not sure why a program crashes, then its nice if you debug it to understand the reason.
Yes this is effort but taking this effort shows that you care for the users.
I think people should be grateful for people doing this work.
 
 
Steve, I think you accidentally are hitting the wrong tone here.
Please stop attack Flype for nothing.


Dma Con

Posts 16
23 Jul 2020 18:54


Steve Ferrell wrote:
What you do with your time is your business, but with all the other issues with the Vampire and AROS that need to be addressed I consider such fishing expeditions to be a poor use of time .

Uhhhh, certainly not.
CPU core always first, because that‘s the common base for everything which needs to run reliably.

Everything else is secondary, and subject to anyones personal preference.


Steve Ferrell

Posts 424
24 Jul 2020 04:16


Gunnar von Boehn wrote:

 
Steve Ferrell wrote:

    If you want to spent the majority of your time on "fishing expeditions" chasing down illegal instructions
   

     
    If you are not sure why a program crashes, then its nice if you debug it to understand the reason.
    Yes this is effort but taking this effort shows that you care for the users.
    I think people should be grateful for people doing this work.
   
   
    Steve, I think you accidentally are hitting the wrong tone here.
    Please stop attack Flype for nothing.
 

 
I'm not attacking Flype.  I'm still wondering after 5 years what state the WiFi driver is in and when the Vampire will boot from the SD card slot?
 
 
 
@Dma con wrote:

 
Uhhhh, certainly not. CPU core always first, because that壮 the common base for everything which needs to run reliably.
 
Everything else is secondary, and subject to anyones personal preference.

 
Yes, the core should be the priority, not debugging and patching demos. So I agree with you.  Why does the core still lack the ability to boot from the SD card slot?  Why are users still waiting after 5 years for a WiFi driver and the ability to boot from the SD card slot?  Maybe because people are busy debugging and patching demos rather than working on the core or writing a WiFi driver?
 
A status update from time to time (maybe monthly) regarding the status of missing features is the least that is owed to Vampire buyers after paying over $600 USD, but updates rarely get posted at all.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
24 Jul 2020 06:09


Steve Ferrell wrote:

Yes, the core should be the priority, not debugging and patching demos. So I agree with you.  Why does the core still lack the ability to boot from the SD card slot?

 
You seem to misunderstand the topic.
Booting from SDCard has absolutely NOTHING to do with the Core.
This is a pure Software-OS feature!
 
And SDcard booting is actually supported and working fine.
Thanks has to go here to Alynnas helping on OS driver support for this.

Regarding AROS development.
Of course this will take long.
Finishing and polishing AROS is a huge task.
It should be clear to everyone that this task will long, and it will for sure take years to make AROS/APOLLO-OS absolutely perfect.
The Apollo Team works on this and does its best give the Amiga Community a free, good, new Amiga-OS. The Apollo-Team puts a lot effort in this but also support AROS developer with Vampire machines and money.

Don't you think that you do wrong?
If you try to blame on the Apollo-Team that after putting some month work into a year taking project - they are not fully finished.
My opinion is that the Apollo-Team rather deserves credit for working here hard for the Amiga community.

 
Steve, your post was not only incorrect also your tone was personal and insulting.
Several people are complained about your behavior.
Maybe you should rethink your behavior and maybe you should rather apologize to Flype and thank him for his effort instead blaming him.
 


Philippe Flype
(Apollo Team Member)
Posts 299
24 Jul 2020 10:39


Steve Ferrell wrote:

 
Philippe Flype wrote:

   
    It's easy for you to tell that after the bug has been clearly identified. Once it's located it's 30sec time spend for gunnar. If i decide to chase a bug that also were under tracking by the tg68 team or the fpgaarcade team it is easy to understand that nobody was 100% sure if it was a more Serious bug in the Bitfield instruction set or anything else. Bugtracking is like fishing, sometimes you catch a big fish, sometimes you only fish false positives. Gunnar didnt lost time in this chase. So please such rude conclusion is actually the ridiculous point here. Also if the behaviour is proved to be same on 020/030/040/060, shouldnt it be mimic on the fpga ? My opinion is that it have to be same than legacy one.
   
   

   
    If you want to spent the majority of your time on "fishing expeditions" chasing down illegal instructions in poorly written and obscure demos, then knock yourself out.  What you do with your time is your business, but with all the other issues with the Vampire and AROS that need to be addressed I consider such fishing expeditions to be a poor use of time or at the least an issue with misguided priorities.
   
 

 
Ok, Steve,
 
That you have wonderings about some missing/unfinished features, i can understand but this should have been smarter to do in an other topic because it have nothing to do with a) this thread b) myself.
 
About __majority__ of my time, i dont know where you imagine that. The BFINS bug here was no more than some hours of debug. It is a normal process which does not need to be judged nor justified. Yes my time is my own business.
 
Clearly, no-one have to tell anyone how he should spend his time! Free helpers (which i am) are not paid, nor under contract, they just help contribute to the project where they can (specific skill factor), when they can (time factor) and if they likes to (fun factor). In return, they certainly not have to support such blamings. You can not expect someone to work magically on other specific topics than the ones he have the skills to do it. For example, the Wifi driver, i'm very not qualified for this task, even if myself i'd love to use one.
 
I can feel easily the misunderstanding here, Steve, your tone was wrong but i understand the point. You think that all members of the team are involved in the project, by earning money from the sellings. It's of course true for the core members but please understand that many members are only free contributors. Those contributors could be anyone, welcomed to contribute on different topics if they feels qualified. There is the Slack channel community for that.


Renaud Schweingruber
(Apollo Team Member)
Posts 378
24 Jul 2020 11:11


Ok, guys. Flype explained things well and further answers won't add anything useful to this discussion.

Any next answer will be deleted (until Gunnar implement closing thread feature :P)


Ronnie Beck
(Apollo Team Member)
Posts 199
24 Jul 2020 11:48


Edit: Was already writing this when TuKo posted "next post will be deleted".  Sorry!  :-O

Steve Ferrell wrote:

  I'm not attacking Flype.
 

 
  Maybe you didn't intend to attack Flype but the aggressive tone when targeting your question at people makes it feel like an attack.
  I can tell you are frustrated and it is ok to express that in polite terms.  Actually, it is good to know what users want or when they are disappointed so we can steer our ideas and efforts.
 
 
Steve Ferrell wrote:

  I'm still wondering after 5 years what state the WiFi driver is in and when the Vampire will boot from the SD card slot?
 

 
  I don't know if WiFi was ever announced or if it was even promised but I can believe the possibility was at least discussed.  It certainly wasn't advertised as a coming feature in the last 3 years since I have been involved.  I imagine that there are A500 users out there love a WiFi module for their Vampire, but few have expressed interest in this in recent times.  The A600 and A1200 already have lots of cheap alternatives without us developing one.  The V500 has already a ethernet driver which we developed.  That said, any skilled developer could develop a driver independently.  It is just takes time and skills.  Volunteers?  :-)
 
 
Steve Ferrell wrote:

  Why does the core still lack the ability to boot from the SD card slot?
 

 
  The Core has this ability and has for a long time.  But the KickStart is a sticking point.  More recently an effort was made again to tackle this and with much success under Apollo OS (AROS).  On Amiga OS, this is still a WIP.  The developer, Alynna, who did the excellent work behind this is part of the team responsible for Apollo OS.
 
 
Steve Ferrell wrote:

  A status update from time to time (maybe monthly) regarding the status of missing features is the least that is owed to Vampire buyers after paying over $600 USD, but updates rarely get posted at all.
 

 
  We have this forum and also Slack for communicating between developers and the community.  You are free to (politely) pose your questions to us live in Slack.  But I agree, we need to do more regular official communication.
 
  Please understand that we are working on a volunteer basis.  Some of these topics are very time consuming and do take a long time.  Our reward and motivation for doing this work is having the best m68k Amiga ever and a happy community that shares that same passion.  So please don't make it personal when you are disappointed.  Express it in a polite and clear manner not only so that we understand you, but so others who are like minded will be more inclined to write in support your wishes.


Adam Polkosnik

Posts 30
24 Jul 2020 17:22


Philippe Flype wrote:

Detailed explanation of the bug :
... 
    So yes it s a bug of misuse of BFINS Opcode in the demo AND no trap'ing from Motorola. And maybe the assembler used by the demomakers. 

Just out of curiosity, which version of Gold 2.x fixed this one?


Philippe Flype
(Apollo Team Member)
Posts 299
24 Jul 2020 17:54


Adam Polkosnik wrote:

   
Philippe Flype wrote:

      Detailed explanation of the bug :
      ... 
        So yes it s a bug of misuse of BFINS Opcode in the demo AND no trap'ing from Motorola. And maybe the assembler used by the demomakers. 
     

     
      Just out of curiosity, which version of Gold 2.x fixed this one?
   

   
   
 
V2 Gold 2.11 is rev 58xx (year 2018)
V2 Gold 2.12 is rev 73xx (year 2020)
   
It was commited in revision 6751 (year 2019, july)
 
Since this demo is AGA only, the fix mainly target the V4, unless you trigger it with Bitfield assembly code.
 
 

posts 37page  1 2