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

Mac Emulatorspage  1 2 3 4 5 6 

Jamie Chapman

Posts 69
08 Nov 2019 19:33


I had wondered how you lot got around the expensive digital out licensing.  I guess the answer is,  you didn't ?


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
08 Nov 2019 19:38


Jamie Chapman wrote:

I had wondered how you lot got around the expensive digital out licensing.  I guess the answer is,  you didn't ?

See vampire world premiere video and Igor will explain. He built alternative to ripping fee just for the name/logo.

Enjoy your small nasty persona. You don't see it?


M Rickan

Posts 177
08 Nov 2019 20:52


Olaf Schoenweiss wrote:

I do not know who is right or wrong but I do not think that this public fight motivates potential buyers to buy your product in future

And that applies equally to any product in the Amiga market - including the Vampire.

This forum was presumably set up to provide information on solutions for Mac emulation. There are a lot of other avenues for privately exchanging dirty laundry.




Mr Niding

Posts 459
08 Nov 2019 21:35


Sigh..

Ok. So he got history.

But if he releases a upgraded version that utilises core better, then great. It doesnt sound like that is in the card, beyond giving people a license. If people are so inclined; great.

if people wont part with $20 unless there are core spesific improvements, then fine.

No reason to encourage the endless back and forth of something that seems to have gone on for decades at this point.


Jim Drew
Learn who I am!
Posts 67/ 1
09 Nov 2019 04:08


Gunnar von Boehn wrote:

  we all recall your attacks Christian Bauer in the 90th.
  Many of your posts are still online in archives to read
  and everyone with technical knowledge can read them
  and will immediately see that your attacks include
  "technical nonsense", "bullshit", and "bladant lies".
 
  Christian is not here do defend himself.
 
  We do NOT accept any type of this slandering here in our forum.
 
  Please refrain from posting such attacks here!
 

It's not slander if it is true.

I am not sure what you are referring to.  Several very respected Amiga developers looked at the disassembly of code from EMPLANT's Mac emulation and Shapeshifter, and they concluded that many sections of the code were in fact byte for byte indentical.  Same memory locations, same register usage, etc.  This is also public record, posted on Aminet and other locations.  I have a complete disassemblies (using Resource) for every revision of Shapeshifter, documenting the history of theft and which programs (EMPLANT's Mac emulation or Amax IV) that the code came from.  I would love nothing more than this to become a legal action since the copyrights are still valid.  So, I stand by my statements.



Jim Drew
Learn who I am!
Posts 67/ 1
09 Nov 2019 04:11


sean sk wrote:

Jim Drew wrote:

  Really?  Care to state what these issues were?
 

 
  Please go jog your memory by visiting the "Stunt Track Racer" thread in your CBMStuff forum. I can't be stuffed explaining it all over again.

Yes, I remember.  You had a problem writing back the image file.  Did the image file work under WinUAE?




Jim Drew
Learn who I am!
Posts 67/ 1
09 Nov 2019 04:18


Vojin Vidanovic wrote:
If Fusion is not +20% on same hardware, its not worth 20$, even with PCx and CD ROM mounting.

There is not going to be some magic speed increase.  It's a 68K program.  There is absolutely nothing (short of a faster fully emulated CPU w/FPU/MMU) that is going to improve performance.  There is no way to "optimize" anything to make it run any faster than the MacOS was written to run. The MacOS under FUSION already runs much faster than the same speed real Mac because it uses the Amiga's multitasking capabilities to handle many Mac functions that are single-sequential threaded. The reason for the new release is primarily to make it available legally again.  There will be some improvements for functionality, but if you are expecting it to be somehow faster then are mistaken because it's not possible.




Jim Drew
Learn who I am!
Posts 67/ 1
09 Nov 2019 05:29


It seems that some still doubt whether the full IEEE compliant 80 bit precision for the FPU is really required for the Mac (or emulations).  Here is a video of WinUAE running FUSION with the 3 different FPU options - 64 bit, 80 bit host, and 80 bit soft-float.  The results speak for themselves.
 
  EXTERNAL LINK   

There are many issues like this through-out various parts of the Mac system software when not having the full IEEE compliant 80 bit precision FPU.  There are also cases where not having the full 80 bit compliant FPU will cause crashes.  But hey, what would I know... it's not like I did this for a living or anything.  :)

 
 


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
09 Nov 2019 07:01


Jim Drew wrote:

      There is no way to "optimize" anything to make it run any faster
   

   
    There is no way to optimize my wallet to give you 20 USD for no effort. No excuses!
   
  Look for the ways! Its 20% to your competition, not two Fusion versions. And You could squeeze even +20% between versions if you really abused Vamp to unoptimised m68k code.
 
  Also, you nailed competition to dust single-handed. There must be something that makes your product so superior?

Jim Drew wrote:

  If you have any questions about FUSION or PCx, or Mac emulation I can answer them here or on my forums (www.cbmstuff.com/forum)

Thanks for answers here, even I do find them to be passive excuses type.

On the wesbite of yours I fail to see any Fusion info or forum section.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
09 Nov 2019 10:15


Jim Drew wrote:

There is not going to be some magic speed increase.
It's a 68K program.

Yes, this answer is fully correct!
 
 
Jim Drew wrote:

There is absolutely nothing ... that is going to improve performance.

Luckily, this answer is NOT correct.
 
There is an option for a major performance boost.
GUI/GFX rendering right now is not optimally.
MAC OS could render fully native to SAGA without any indirection in Fullscreen mode. And MAC OS could also render fully native to SAGA in window mode - using SAGAs PIP feature.
The possible speedup potential here is big. 




Sean Sk

Posts 488
09 Nov 2019 14:31


Jim Drew wrote:

Yes, I remember.  You had a problem writing back the image file.  Did the image file work under WinUAE?

To cut a long story short:

1. I have a retail version (in very good condition) of Stunt Car Racer. It's one of a few games that I have that were manufactured without the write splice indexed (this does actually happen).

2. The image DOES work in WinUAE.

3. I cannot write a working copy back to a new disk, which is one of the main reasons why I got the SCP. It seems to be a common issue with those retail games that were written non-indexed.

4. I have tried reading and writing in both Indexed and Splice modes.

I'm one of the few people in this world that actually love using floppies disks and want to preserve my originals which are all in excellent condition.


Jim Drew
Learn who I am!
Posts 67/ 1
10 Nov 2019 01:07


Gunnar von Boehn wrote:

  Luckily, this answer is NOT correct.
 
  There is an option for a major performance boost.
  GUI/GFX rendering right now is not optimally.
  MAC OS could render fully native to SAGA without any indirection in Fullscreen mode. And MAC OS could also render fully native to SAGA in window mode - using SAGAs PIP feature.
  The possible speedup potential here is big. 

Umm... you do realize that the Mac renders directly to the frame buffer already for 256 color mode?  If you supported Cybergraphics then the "thousands" and "Millions" modes would also be rendered directly to the frame buffer.

If your P96 or Cybergraphics emulated the blitter functions that they have (private functions in the .card files) then there would be an automatic speed increase as my video drivers detect that and will use these blitter functions directly for QuickDraw routines.  The Picasso IV, Piccolo SD64, and Cybervision 64 all had this capability and the speed difference is many times faster for Quickdraw functions.  Otherwise, anything drawing directly into the video memory on the Mac is drawing directly into the frame buffer used by P96 or Cybergraphics, and as you have noted that is the fastest way to go (no indirection).



Jim Drew
Learn who I am!
Posts 67/ 1
10 Nov 2019 01:09


sean sk wrote:

  3. I cannot write a working copy back to a new disk, which is one of the main reasons why I got the SCP. It seems to be a common issue with those retail games that were written non-indexed.
 

 
  You can do a couple of things to write the image.... do it by hand, track by track using the editor/analyzer, or you can use HxC Floppy Drive Emulator to load the .scp image and then export it back as an .scp image.  That will index the tracks at which point you can use the SCP software to write the index'd version back out correctly.
 
 
 


Sean Sk

Posts 488
10 Nov 2019 21:57


Jim Drew wrote:

You can do a couple of things to write the image.... do it by hand, track by track using the editor/analyzer, or you can use HxC Floppy Drive Emulator to load the .scp image and then export it back as an .scp image.  That will index the tracks at which point you can use the SCP software to write the index'd version back out correctly. 

Unfortunately neither method works. Using HxC method does not index the tracks.


Jim Drew
Learn who I am!
Posts 67/ 1
10 Nov 2019 22:12


sean sk wrote:
 
Unfortunately neither method works. Using HxC method does not index the tracks.

   
Actually, it does.  I use this method frequently for creating AmigaDOS disks.  I read an AmigaDOS disk with SCP and create a .scp file.  I then load the .scp file into HxC and export it as a .scp file.  I then load that .scp file in the SCP copier, click on the OVERRIDE button, select INDEX as the copy type, and write the image to a real disk.  Stunt Track Racer is all AmigaDOS format except for the protection track.
   
You can ALWAYS copy a disk track by track manually using the editor/analyzer. It just takes a long time to do it this way.  To do this, you load the .scp image file into the editor/analyzer and set the start/end flux points and click the WRITE button and it will write the data to a disk.  Go to the next track/head and repeat.
 


Sean Sk

Posts 488
11 Nov 2019 12:54


Jim Drew wrote:

Actually, it does.  I use this method frequently for creating AmigaDOS disks.  I read an AmigaDOS disk with SCP and create a .scp file.  I then load the .scp file into HxC and export it as a .scp file.  I then load that .scp file in the SCP copier, click on the OVERRIDE button, select INDEX as the copy type, and write the image to a real disk.  Stunt Track Racer is all AmigaDOS format except for the protection track.

OK, let me clarify then: It doesn't work for Stunt Car Racer. I followed those steps exactly and the resulting re-written disk is not indexed and it refuses to load. I have analysed both the exported HxC .SCP image and the re-written disk and the splice is not indexed.

It could be that SCP is unable to copy the protection track. According to this thread: EXTERNAL LINK 
IFW states: "Stunt Car Racer must be written onto a DD disk.
It uses a very special protection that cannot be copied at all, only artificially generated - the protected signatures has "no flux transition" areas.
To generate such data you must use a DD disk."

Well I am using a DD disk to write to and still no success. Using a Sony MPF-920 connected to the SCP.


Jim Drew
Learn who I am!
Posts 67/ 1
11 Nov 2019 19:23


sean sk wrote:

OK, let me clarify then: It doesn't work for Stunt Car Racer. I followed those steps exactly and the resulting re-written disk is not indexed and it refuses to load. I have analysed both the exported HxC .SCP image and the re-written disk and the splice is not indexed.
 
It could be that SCP is unable to copy the protection track. According to this thread: EXTERNAL LINK   
  IFW states: "Stunt Car Racer must be written onto a DD disk.
  It uses a very special protection that cannot be copied at all, only artificially generated - the protected signatures has "no flux transition" areas.
  To generate such data you must use a DD disk."
 
  Well I am using a DD disk to write to and still no success. Using a Sony MPF-920 connected to the SCP.
 

 
LOL! The disk type does not matter.  I made copies of this disk on the Amiga using Supercard Ami II (SOFTWARE MODE) back in the day.  SuperCard Pro duplicates STRONG BITS (No Flux transitions) just fine.  Turracan, KickOff2, Nuclear War, and many other games used this same protection scheme.  If the protection was not captured correctly in the .scp image file then the game would not load under WinUAE, and it does.  The STRONG BIT protection can be duplicated on a stock Amiga without any special hardware.  You just have to know how to look for it and re-create it.
 
The issue with Stunt Track Racer is that the disks were either not commercially produced, or deliberately non-indexed.  My SPLICE routine does not always work because it relies on there being an actual write splice (smeared flux transition which occurs when turning off the writing of the head).  There are some cases where it just so happens to be that the smear perfectly overlaps the next bit cell so a write splice is not apparent.  I have to improve the SPLICE routine to actually look at the MFM structure like I did with Supercard Ami.  You can of course copy this manually track by track, but I think that HxC should have no problem re-indexing the disk.  I will take a look at it.



Gunnar von Boehn
(Apollo Team Member)
Posts 6197
19 Nov 2019 09:08


Jim Drew wrote:

  It seems that some still doubt whether the full IEEE compliant 80 bit precision for the FPU is really required for the Mac (or emulations).  Here is a video of WinUAE running FUSION with the 3 different FPU options - 64 bit, 80 bit host, and 80 bit soft-float.  The results speak for themselves.
 

 
 
Here we can see the following:
 
- MAC OS 8.1
- using 64bit FPU
- running with Shapeshifter
 
CLICK HERE     
 
So what do we see here?
MAC OS 8.1 Window sliders run perfectly well with 64bit FPU.
 

The same is true for Shapeshifter plus Vampire4
MAC OS 8.1 Window sliders run perfectly well with Shapeshifter and Vampire4.

MAC OS has no problem here.
To me it looks like Fusion has the problem and the easy fix is using Shapeshifter.



Kyle Blake
(Needs Verification)
Posts 108/ 1
19 Nov 2019 11:07


This all can be explained. When the internationally wanted criminal Christian Bauer stole the Fusion code from jim's house, he replaced it with inferior fake version that can't handle FPU properly. Here is a still of the culprit on jimdrewvision CCTV:
 
 
 
  photo of Bauer:
 
 
 
  Glasses and parrot, case closed.


Mr Niding

Posts 459
19 Nov 2019 20:44


@Kyle
 
:-) Thats great!
 
  Contender for this sites best forum post.

posts 105page  1 2 3 4 5 6