Overview Features Instructions Performance Forum Downloads Products Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireCoffinReleasesLogin
Documentation about the Vampire hardware

Mac Emulatorspage  1 2 3 4 

Vojin Vidanovic

Posts 1337
07 Nov 2019 03:44


Beside whatever happened in removing Fusion from Coffin,
    Jim has history of "too strong words".
   
    As developer he should have a chance to prove othewise.
   
    As an example, same promise of "slightly updated" emulators can be found on EAB and is 2 years old.
 
  Back on track, how can Fusion be improved?
 
  - Utilization of native resolutions in Vamp h/w for MacOS display, similar to non emulated CPU
  - Better usage of v2 and v4 fpu
  - Better usage of more and faster RTG, RAM and IDE in kind of direct access, as much as emulator can do (Amithlon approach?)
 
  Speed is already acceptable, any gains are most welcome. Its easy when max enemy is 040, on x86 side we need every "mm of enemy territory"-


Kawsy P

Posts 2
07 Nov 2019 05:18


Software is what two and half decades old?

- Won't sell licenses
- Actively works to make sure nobody can get the software for free
- Actively trashes the only alternative and its author
- Has promised a new version for years
  EXTERNAL LINK  - Is very vocal about how great the product is compared to the alternative despite there being no legal way to use it.

Dude, three years ago I would have LITERALLY thrown money at you for this product. I had just gotten back into the Amiga game, having not owned once since 1992, and was excited about all the things I could do with my souped up A3000, including MAC emulation. Maybe Shapeshifter is horrible compared to Fusion, but I can't tell. Works great, plenty fast, looks like a MAC, smells like a MAC, runs everything I want. And best of all, I can obtain it.

I'm a software developer too. I get wanting to protect what you created, and that's your prerogative if you don't want to make it available. Considering what a unique piece of software, and history, it is though, to me at least this seems quite sad. Maybe you will release it some day; I moved on.


Mr Niding

Posts 381
07 Nov 2019 05:21


Im puzzled by this exchange.
 
  If someone is THIS bad, then Im wondering why he is allowed to even post here. Espesially considering the negativity it spurs in you.
 
  But since you allow him to post, I think we should let code and development speak for him, not words. If he delivers something worth $20, then great (worth is relative regarding Amiga vs mainstream products).
 
  Hell, I have reallife aquitences that have quite checkered history, but after xx years have proven they have changed their ways. So Im not into crusifying someone eternally.


Gerardo González-Trejo

Posts 25
07 Nov 2019 05:39


I sincerely believe that Jim shouldn't have published any link to his products without permission or have criticized FPU and graphics implementation, moreover knowing perfectly that any FPGA has a limited space.

  Defame Jim is not good idea too.

  Many of you have been tagged as not trustable or being developing "smoke" even when your product was already working. On Amigaland ® all is possible...

  Entrepreneurship is difficult, with many fails, disappointments, betrayals, and occasionally a joy.

If Jim wants to develop or enhance his products, I do not see any problem here. If he fails, he will be the only one losing here.


Mr Niding

Posts 381
07 Nov 2019 05:49


Links is just directions to information or products you can review.
More info is better than less.

We all know the FPGA is limited, and Jim (or anyone) can adress what they see as a limitation for their development cycle/product, and the Apollo team can adress those concerns objectively.

With the response from the platform provider, developers can look at what they can do to convert their software to utilize the platform to the best of their abilities.

Im sure Steve will respond/think "its not that easy! It will require quite a few manhours vs the value of sales of the endproduct!" :)

Again; let software speak for itself, and try to put bad history at the door.


Gerardo González-Trejo

Posts 25
07 Nov 2019 06:01


Mr Niding wrote:

  Links is just directions to information or products you can review.
    More info is better than less.
 

 
  I am agree with all your previous comments, and with this statement too. But here Apollo-Core forum is related to an specific product.
 
  Their owners have their own rules, disclaimer and targets. Posting your products on another´s company forum is not only not fair, it is not allowed by law... Same as defame...
 
  I am agree too that Jim or anyone can address whatever they want to address, but respecting others´ work.
 
  I still believe that a little empathy from everyone in Amigaland ® would improve everything.


Vojin Vidanovic

Posts 1337
07 Nov 2019 07:10


Let Jim deliver, if he does.
  I ll buy if it uses vamp well enough. Otherwise, shapeshifting etc.

What team could do is offer v2 and v4 to a developer.

In the end, reviving or supporting m68k os3 commercial products or any development, is a major + and sideeffect of vampirism.

Even if it was Amiga Inc I would support it. Would buy os 3.1.4-2 if it was more of new and using vamp, less of old and already fixed


Gerardo González-Trejo

Posts 25
07 Nov 2019 07:52


Collaboration is ever great, but on a win-win agreement.
 
  Giving access to hardware to some key developers allowing them better rates, renting options or free access during development period would be good if those developers let distribute the end software to the hardware developer with better rates, affiliate fees, or freely during a period or time. Win-win.
 
  I would buy OS 3.1.4 - 3.2 when judge determine if is it a legal software or not. I wouldn´t buy it before that.


Gunnar von Boehn
(Apollo Team Member)
Posts 4107
07 Nov 2019 09:20


Steve Ferrell wrote:

  Wow, that's a pretty bold and harsh statement, but then I know very little of what happened.  Do you think the Jim Drew account here on the Apollo forums is fake or are you saying that you really have serious trust issues with Jim?

   
Take the time and read about Jim Drew and built your own opinion.
EXTERNAL LINK
   
 
Jim Drew did attack Shapeshifter with the intention to destroy this product and prevent it sales.
 
Jim Drew did post a lot of untruth claims against the author of Shapeshifter for this.
   
 
Regarding Jim and Vampire:
Jim Drew did present himself as "The sole representative for Vampire product in the USA" and tried to bully Igor into giving him this status. After Igor did not give him this status, Jim Drew started in several occasions to post technical incorrect statement about Vampire. The list is very long.


Mr Niding

Posts 381
07 Nov 2019 09:48


Thanks for the link Gunnar.

That said; an endproduct in the form of ongoing developed software for Apollo core is desired.

Is Shapeshifter in active development?

In the end, emulation on the Apollo/Vampire isnt really a big thing for me, but given the lack of new/updated productivity software for AOS 3.x/AROS, a decent MAC 68k emulator might be plan B in that regard.


Joni Valtanen

Posts 12
07 Nov 2019 11:01


Mr Niding wrote:

  Is Shapeshifter in active development?

ShapeShifter is not in active development: EXTERNAL LINK 
Development should be possible. Sources are in Aminet. I'm not license expert, but I think it should be suitable:

"Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies."

BasiliskII has some updates two year ago: EXTERNAL LINK


Steve Ferrell

Posts 378
07 Nov 2019 18:26


Gunnar von Boehn wrote:

 
Steve Ferrell wrote:

    Wow, that's a pretty bold and harsh statement, but then I know very little of what happened.  Do you think the Jim Drew account here on the Apollo forums is fake or are you saying that you really have serious trust issues with Jim?
 

     
  Take the time and read about Jim Drew and built your own opinion.
  EXTERNAL LINK
     
   
  Jim Drew did attack Shapeshifter with the intention to destroy this product and prevent it sales.
   
  Jim Drew did post a lot of untruth claims against the author of Shapeshifter for this.
     
   
  Regarding Jim and Vampire:
  Jim Drew did present himself as "The sole representative for Vampire product in the USA" and tried to bully Igor into giving him this status. After Igor did not give him this status, Jim Drew started in several occasions to post technical incorrect statement about Vampire. The list is very long.
 

 
That made for some interesting reading.  With his propensity for lifting code and then selling it as his own, Jim would would fit in well at Hyperion!  Why does the Amiga platform attract so many charlatans, code thieves, and just plain weirdos?
 


Ronnie Beck

Posts 89
07 Nov 2019 19:38


Mr Niding wrote:

Im puzzled by this exchange.

Really?  The man spams BS.  He is asked to stop.  The exchange is quite straight forward.



Sean Sk

Posts 277
07 Nov 2019 22:48


Unfortunately, Jim Drew is quick to brag about his products and threaten legal action against others, but is slow in fixing issues with his products. I made mention of an issue I was having with his Supercard Pro over 3 years ago and nothing got done about it. Same with his WiModem232. All I got were some cock n' bull stories. I certainly won't be bothering to purchase anymore of his products.


Sebastian Blanco

Posts 127
08 Nov 2019 04:00


Rumors go around that a guy distributing copy's of shape shifter was catch by Jim tugs and got his balls hook to a truck battery. They where vaporized instantly and the screams where hear from a mile away.

Is very dangerous to do this remember Jim worked for NASA and have friends in the CIA.


Jim Drew
Learn who I am!
Posts 59
08 Nov 2019 07:27


Gunnar von Boehn wrote:

  OK I think I see now where your misunderstandings come from.
 
  Let my explain how the FPU control of original MOTOROLA 68060 works.
 
  The MOTOROLA 68060 has an internal register named "Processor Control Register".

  This register has control bits in it, to enable/disable CPU features.
 
  By setting here 1 Bit the FPU can be 100% turned off.
  Then each FPU instruction will TRAP like there is no FPU.
 
  This means with 1 MOVEC instruction you can turn off the FPU for the 68060. APOLLO 68080 behaves 100% the same as 68060 here.
 
  There is one thing you need to take care of here.
  We need to mind, that AMIGA OS will detect FPU first.
  If AMIGA OS detected FPU and "marked in Attenflags" that FPU is there. Then AMIGA programs and AMIGA libraries will of course use FPU instructions. So if you then just turn the FPU "off", then FPU using libraries will of course create Traps.

The problem with your thinking is that you believe that Mac thinks there could be an 060 present.  The real issue is that Apple never had an 060.  So, there no knowledge by the MacOS about the 060. There are no attention flags to look at with the MacOS.  The MacOS initialization (and various programs) bangs on the CPU directly without looking at the CCR.  The MacOS knows it is going to be either an 020, 030, or 040. To get the 060 to even work on the MacOS required literally hundreds of real-time OS patches, and basically the Mac is crippled.  Most everything requires that SuperScalar is turned off, along with branch prediction, otherwise self-modifying code crashes.  There are many MacOS routines that do self modifying code (even though Apple told everyone to not do it in their own code).  There are a ridiculous number of CacheClearU() calls that get inserted into the MacOS to even get it to work with an 060.  That kills the performance dramatically, but it is the only way to make it work.

So, the reality is that the MacOS accesses the 040 (which it thinks the Apollo core is) and checks for the FPU by setting up traps and issues 040 instructions.  It checks the results and then sets its own flags and loads separate resources for the 'LC040' version of the OS when the FPU is not found.  Otherwise, the MacOS absolutely, positively, requires the IEEE compliant 80 bit floating point.  It's easy to demonstrate what happens when you don't have 80 bit support.  The only two solutions that exist are to deliberately disable the FPU within the MacOS itself (which won't work for applications that do the same checking internally) or support 80 bits.



Jim Drew
Learn who I am!
Posts 59
08 Nov 2019 07:35


Nixus Minimax wrote:

Jim Drew wrote:
Apple's hardware check is rather exhaustive because they used LC040's in many of their Mac models, and often times CPUs from Motorola labeled 'LC' actually had partially working FPUs and were labeled this way due to not passing QC for the FPU.  So, Apple's check makes absolutely sure that the processor has a working FPU by setting exception handlers and doing a range of FPU related functions (from Pack 4 and Pack 5) like Transcendentals, matrices, etc.

 
  Tell me, if Apple does so many checks on the FPU to absolutely be sure it is a good one, why does the supposedly too imprecise 080-FPU pass the test only to then cause problems in trivial calculations like window coordinates and slider sizes which should require no more than perhaps twelve bits of precision while the 080-FPU offers more than 50 bits of precision?
 

Apple sets up traps and issues certain FPU instructions that are known to NOT pass on the LC040.  It was a real nightmare for Apple for a bit because Motorola was not deliberately making LC040 chips.  standard 68MC040 or 68XC040 chips that failed the FPU test were being labeled as 68LC040 chips.  Those chips could have parts of the FPU working. 

Why Apple's routine require 80 bits is really a bit of a mystery to me... but that's how they wrote their code and 80 bits is not optional as can be witnessed by the examples that I gave.  As I stated, you even have to enabled the 80 bit soft-float mode in WinUAE in order to have the FPU actually supported so it works.  Maybe Toni can answer this better.  He had to add this mode for several Amiga programs (rendering/ray tracing) and Mac emulations.



Jim Drew
Learn who I am!
Posts 59
08 Nov 2019 07:43


Mr Niding wrote:

@Gunnar
 
  I dont see a problem with Jim advertising his software, if it leads to development and better compability/utilization of the Apollo core features.
  Better performance can only be a good thing.
 
  And youre assuming people will blindly throw cash at a product without examining said performance, and if the improvements warrants a new version.
 
  Sidecomment: dont we want developers to support the platform?

The real reason why I am re-releasing the software is that people are constantly complaining to me that they can't buy it.

There is really nothing that I can do to improve performance with FUSION when using the Apollo core.  The Apollo core itself is a dramatic improvement over the 040 (the 060 was actually slower in most case than a 40MHz 040 with the MacOS because it had to be crippled so much to even run).  I can't magically add some feature that is going to make it any faster than it is.  It's a 68K program.  :)  The new version will have some new features, like ISO support for CD's which is really not an option at this point.  I don't think anyone is running an Apple CD-300 SCSI CD-ROM drive on their Amigas anymore!

I don't know the status of the video card support for the Apollo (I have been out of the loop for a couple of years).  If there is Cybergraphics or Picasso96 support, then the existing video drivers should work.  If not, then that would be something that I could make, but the performance is not going to drastically jump because of this and the MacOS itself is the limiting factor on the resolution, so I can't make some great 1980x1024 mode.  I am pretty sure that the max supported was 1440x1080.



Jim Drew
Learn who I am!
Posts 59
08 Nov 2019 07:44


Gunnar von Boehn wrote:
  I'm sorry to have to say it so clear, but after all what happened we have unfortunately very serious doubts that Jim Drew is trustworthy.

LOL!  That's quite funny.




Jim Drew
Learn who I am!
Posts 59
08 Nov 2019 07:58


Vojin Vidanovic wrote:
   
    Back on track, how can Fusion be improved?
   
    - Utilization of native resolutions in Vamp h/w for MacOS display, similar to non emulated CPU
    - Better usage of v2 and v4 fpu
    - Better usage of more and faster RTG, RAM and IDE in kind of direct access, as much as emulator can do (Amithlon approach?)
   
    Speed is already acceptable, any gains are most welcome. Its easy when max enemy is 040, on x86 side we need every "mm of enemy territory"-

As I stated, the MacOS itself is the limiting factor for resolutions.  You are stuck with what the MacOS (and applications) have setup.  For colors, it is not a problem as 1 bit through 32 bit (24 bit + alpha channel) is already supported.

The only improvement for the FPU would be to have 80 bit support.  This is a MacOS requirement.  There is nothing that I can about this, except for to make the MacOS think there is no FPU at which point integer versions of the MacOS routines are used... those are very slow compared to a real FPU.

"Direct" access to hardware (IDE, serial, printer, floppy, etc.) is already occurring.  Hardfiles have to be handled through a device driver. That is handled by the Amiga and it's superior multitasking OS!  100% of everything in FUSION is written in hand-optimized (cycle counted) assembly code.  This is an accumulation of 6 years worth of work reverse-engineering the Mac chipsets and every single version of the MacOS (each version has it's own unique set of patches).  Keep in mind that this was not a hobby for me.  This was my day job.  It's all I did 7 days a week, 12+ hours a day, from 1992 through 1998.

The biggest improvement to performance for FUSION would come from having a real MMU. Every single color Macintosh (Mac II and later) had a working MMU, and the OS uses it extensively to virtually move things around in memory, map regions, etc. constantly.  When there is no MMU present, I have to emulate everything that the MMU is doing.  I would say the emulation would probably see at least a 2x speed improvement if there was a real MMU.. and I mean 4K pages, the TLB, etc..  the real deal... something that I didn't have to patch to get to work.  We see that kind of improvement between the EC040 and standard 040 A4000s.

So again, besides maybe some native video driver that says "Apollo" in the info box, I don't think there is anything that can really be improved.



posts 78page  1 2 3 4