Busted !!!

I wouldn't even begin to know how to, or where to set the start and end flux points. I would much rather see this issue fixed so that it can be done conveniently.

Jim Drew wrote:

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.

I consider myself a reasonably patient person, but any chance I'm not going to have to wait another three years for you to look at this?

Noo..not three years man. Come on! Jeeze, get your calculation right! - slaps hand with the other hand - You cannot be spitting wrong data like that!

It is 8,500,210 years of waiting time. Get the figures correct! Please!

= Mumbles out of the room, "3 years! Huh! Some people miscalculate! I tell's ya!" =

What we see here is Shapeshifter using the lower accuracy Mac system resource.  Advanced PACK4 and PACK5 is not being used for FPU calculations by Shapeshifter.  FUSION replaces the PACK4 and PACK5 resources, per Apple's guidelines.  This *requires* 80 bit precision, and one of the reasons why FUSION's FPU benchmarks are so much faster than a real Mac (and Shapeshifter).  It's the very reason why Amiga/EMPLANT systems replaced real Mac systems used by Amblin Entertainment to run Avid Video Suites.  The rendering with my code is about 2.5 times faster than the same speed Mac.  When studios had to pay up to $25,000 per day for rendering time, it was far cheaper to buy an Amiga w/EMPLANT board and do it in house.  This is what several movie studios did.

I don't consider this an "issue" to fix since the image works in WinUAE and you can create a disk manually.  I know exactly why the image to disk does not work, but I was not too motivated to make the changes because I know that you don't actually own this program (you admitted to downloading the image from a repo).  I will see about implementing a quick change to see that works in all cases.  I am actually adding a feature right now to the editor/analyzer to be able to "rotate" a track by selecting a location and clicking on a button.  This would let you easily make a disk INDEX'd and so manually creating a disk would be quicker.

Jim the other day, you said this:

Jim Drew wrote:

Even with UAE (FS-UAE, WinUAE, etc.) it requires that "80-bit softfloat" be selected in order for any Mac emulator to work correctly.

You are contradiction yourself.

How is Vampirizing Fusion and PCx?
 

Jim Drew wrote:

What we see here is Shapeshifter using the lower accuracy Mac system resource.  Advanced PACK4 and PACK5 is not being used for FPU calculations by Shapeshifter.

This translates to:

Shapeshifter works because it does not use ludicrously high precision for very simple things.

Shapeshifter does not use PACK4 and PACK5. (This could mean that PACK4 and PACK5 are what demands ludicrously high precision to calculate very simple things).

FUSION replaces the PACK4 and PACK5 resources,

FUSION doesn't use PACK4 and PACK5 either but contrary to Shapeshifter shows buggy behaviour.

per Apple's guidelines.

Apple does not want anybody to use PACK4 and PACK5 (why?). Both Shapeshifter and FUSION follow these guidelines.

This *requires* 80 bit precision,

What "this"? Your replacement code? Previously you had stated that you don't know why the ludicrously high precision is needed and now it turns out it is your own code that requires it?

and one of the reasons why FUSION's FPU benchmarks are so much faster than a real Mac (and Shapeshifter).

(Marketing blabla deleted). You replaced Apple code with your own code but you don't know why your code does not work with less than 80bit precision. But you do know that it is much faster.

This reminds me of many patches to AmigaOS that are supposed to make it (crash) much faster.

BTW, your claim about FUSION being so much faster than Shapeshifter still requires verification. And even if it was, obviously your changes or optimisations make the code more susceptible for strange behaviour that do not seem to have any reasonable explanation (see above: more precision than required to calculate the number of human hair diameters covering the distance from here to the Moon, yet the precision is not enough to calculate window coordinates and slider positions in a lowres GUI).

His self modifying excuse for bad emulation aside, I'm very interested in how he says avid worked on an emplant. Avid on 68k macs required a lot of specialist nubus cards because editing video on an actual 68040 is completely impossible.

- What mac emu CURRENTLY works on Vampire ? ShapeShifter, Fusion, other ? (Basilisk? SheepShaver ?)

- On what Vampire model/core ? public one ?

I mean if I receive my vampire v4 stand alone in december then what mac emul will works on it ?

Note: I have seen shapeshifter works well at the Alchemy demo party but perhaps some little bugs remain...

Shapeshifter works very good.
I can greatly recommend it.
Its fast, totally stable,
MAC OS really runs super.

thellier alain wrote:

- On what Vampire model/core ? public one ?

Every Vampire

thellier alain wrote:

I mean if I receive my vampire v4 stand alone in december then what mac emul will works on it ?     Note: I have seen shapeshifter works well at the Alchemy demo party but perhaps some little bugs remain...

MAC OS runs super.

My son has played many MAC Games (e.g. Warcraft) for endless hours with it.

Jim, is this correct as of December 2019?
Any news of patched, updated Fusion and PCx?

Since GOLD2, Fusion and Shapeshifter don't work anymore (even with RsrvWarm/Cold or PrepareEmul).
What can I do ?
A:  Our exec.library reserves correct amount of memory the same way as RsrvWarm/Cold/PrepareEmul did.
Only thing it doesn't do is moving the VBR to FastRAM. We recommend use of tools like VBRControl
to move it to FastRAM.

Mailed the man, blames the Vampire exec

You can't just reserve memory.  There are steps that have to be done, including changing the VBR.
It MUST be done exactly like what RsrvWarm does or the Mac will never work properly... no
exceptions.  So, put the exec.library back to how Commodore made it and call it good.  There is
nothing I can do to fix your exec.library changes to work with FUSION.

Barana V wrote:

If Vox spoke to me the same way he spoke to that guy I would have wiped him too.

   
    No whips please
   
    Jim is no guy I feel pleasentry / convinience wasting is needed. I can be way more socially likable in flash and spirit :) In fact he is the one promising and not deliverying anything :)
 
  But, there is A NEW HOPE (yeah, like in Star Wars).Jim sais:
 
  "There will be new versions made available for sale in the near future.  I am working out some
  details with several different FPGA Amiga emulation authors."
   
 

Barana V wrote:

If I buy a vampire do I get turned into something that goes for the Jugular like everyone here did?     Yikes!

 
  I am no good example, I had this Serbian "direct approach" to problems, way before Vampires have arrived. Simple dislike of corporate bull.