in case you are interested to test new fpga accelerators for a600/a500

[guest11527]

So Mac emulators are no go, I wonder what else of proprietary software that will end up as "no go" because the Phoenix CPU core is (will be) too incompatible and needs dedicated support. I would love to participate with my A600, but wont be able until fall. What is the time frame for these developer boards anyways?

No, why? For the same reasoning, one could never had run shapeshifter on a 68060 because it has unsupported instructions that require emulation. No difference. Once the software emulation layer is loaded, there is no problem.

[kolla]

And this emulation is done in a library akin to 68040.library? Or by PhoenixInit that also loads FastRAM? What's the deal with OS3.9 and PhoenixInit, considering that initial boot of 3.9 is in fact a 3.1 before SetPatch loads all 3.9 stuff and resets. Does PhoenixInit have to be run on every single warm boot? That is kinda inconvenient for games that boot off their own media.

[guest11527]

And this emulation is done in a library akin to 68040.library? Or by PhoenixInit that also loads FastRAM?  

I don't know how Gunnar currently handles that. Ideally, it should be a library. Currently, I deliver a run-alone binary I deliver that installs everything. There is no support for the Phoenix core in SetPatch, so you have to use an additional command to load the support functions anyhow.  

What's the deal with OS3.9 and PhoenixInit, considering that initial boot of 3.9 is in fact a 3.1 before SetPatch loads all 3.9 stuff and resets.

I don't know - what do you mean by "deal"? Somehow, the stuff must be loaded, right?    

 Does PhoenixInit have to be run on every single warm boot? That is kinda inconvenient for games that boot off their own media.

Does the 68040.library have to be loaded on every warm start? Yes, of course. Does the absense of the 68040 library break some games? Probably, I never tried. It is more likely that bad software does not run on the 68040 in first place, especially software that bypasses the Os. Did that stop people from using the 68040 or 68060?

In a sense, you cannot have everything. P96 support requires 68020 support. Some games break on a 68020. Fast execution requires higher clock rates. Some games break on faster processors. At some point, you probably just have to say, ok, I'll boot this game with the plain old 68000 in the system. If software is so badly written that it cannot run with SetPatch kicking in, or so bad that it does not run on anything but raw 68000 speed at 7MHz... well - I'm just saying "bad luck", that's not the right hardware for this game.

[xboxOwn]

I don't know how Gunnar currently handles that. Ideally, it should be a library. Currently, I deliver a run-alone binary I deliver that installs everything. There is no support for the Phoenix core in SetPatch, so you have to use an additional command to load the support functions anyhow.    I don't know - what do you mean by "deal"? Somehow, the stuff must be loaded, right?    

Does the 68040.library have to be loaded on every warm start? Yes, of course. Does the absense of the 68040 library break some games? Probably, I never tried. It is more likely that bad software does not run on the 68040 in first place, especially software that bypasses the Os. Did that stop people from using the 68040 or 68060?

In a sense, you cannot have everything. P96 support requires 68020 support. Some games break on a 68020. Fast execution requires higher clock rates. Some games break on faster processors. At some point, you probably just have to say, ok, I'll boot this game with the plain old 68000 in the system. If software is so badly written that it cannot run with SetPatch kicking in, or so bad that it does not run on anything but raw 68000 speed at 7MHz... well - I'm just saying "bad luck", that's not the right hardware for this game.

One word: Whdload.

[guest11527]

One word: Whdload.

Well, even that cannot clock down a 68060 to 7Mhz or change the exception stack frame for a 68040. It can at best perform a live patch on broken software. How good or bad that works depends of course on the software and WHDLoad. One way or another: If you need absolute compatibility to a 1MB 68000@7Mhz on an Amiga 500, your best bet is to get an unexpanded Amiga 500....

[xboxOwn]

Well, even that cannot clock down a 68060 to 7Mhz or change the exception stack frame for a 68040. It can at best perform a live patch on broken software. How good or bad that works depends of course on the software and WHDLoad. One way or another: If you need absolute compatibility to a 1MB 68000@7Mhz on an Amiga 500, your best bet is to get an unexpanded Amiga 500....

This is why the vampire 500 is awesome. Anytime you can disabled and get that 100% compatibility since you run it on an unexpected A500 anyways

[kolla]

Well, it should be possible to let regular SetPatch do it the same way it does 68060.library, via a dummy 68040.library, but I suppose it then would had to act like a 68040 to trigger SetPatch to load it. Most convenient of all, for users, would be if phoenix core could be compatible enough to not need patching of the OS, isn't that the greatness of FPGA? Also, that the FastRAM is not autoconf is rather inconvenient.

I am curious how it will play out.

[xboxOwn]

Well, it should be possible to let regular SetPatch do it the same way it does 68060.library, via a dummy 68040.library, but I suppose it then would had to act like a 68040 to trigger SetPatch to load it. Most convenient of all, for users, would be if phoenix core could be compatible enough to not need patching of the OS, isn't that the greatness of FPGA? Also, that the FastRAM is not autoconf is rather inconvenient.

I am curious how it will play out.

Only way to figure it out if BigGun start distributing tomorrow the card for people who said they are interested! Then we can start playing :laugh1: with card and say how the entire thing works out.


Right now I am exercising extreme control and patience of not buying ACA1233 but that means my A500 is crippled for what I need to do with it. I do hope it comes out soon.

[guest11527]

Well, it should be possible to let regular SetPatch do it the same way it does 68060.library, via a dummy 68040.library, but I suppose it then would had to act like a 68040 to trigger SetPatch to load it.

Actually, that's a bad idea since the Phoenix is not an 68040, and even if it would emulate one, the 68040.library should be reserved for the original 68040. A well-designed system should boot no matter what the CPU is, and SetPatch should pick up the right library in first place - there should be no need for a dummy. One way or another, this could be solved by making the code an autoconf module and bootstrap it this way.  

Most convenient of all, for users, would be if phoenix core could be compatible enough to not need patching of the OS, isn't that the greatness of FPGA? Also, that the FastRAM is not autoconf is rather inconvenient.

Actually, it does not require patching the Os. The support code is only there to provide emulation code for the instructions it does not support. The emulation code does not patch the Os - what for?  The reason why there are unsupported instructions in the Phoenix is simply because the FPGA is too small to include them. Regularly, you don't need them anyhow, it only affects a minority of programs in first place.  Other than that, the Vampire can be bought right away, though unfortunately it is not "easy enough" for the average user to get it, install the core and get it running, i.e. it is not "a product". For that, the core would have to be pre-installed, and it should be available in larger quantities. It is currently too much of a "hobby project" to make it feasible for the average user.

[matthey]

Truth is good.
Can you start posting the truth instead spreading false rumours?

What you say is not true.
CAS and CAS2 are supported.

Matt, you lack overview about Phoenix.
I've noticed that you very often post wrong and untrue stuff.
Posting wrong info does help no one.

What is the truth? Can you tell us when you change your mind again and update your documentation (the only documentation I find is N68050 encoding maps)? The truth can change especially where you control it. The last truth (or lie from your posts) was that you were using OPI.L #.W, which would partially overwrite encodings of some other instructions like CAS, CAS2 and CMP2.

http://www.apollo-core.com/knowledge.php?b=4¬e=2732

Did you finally listen to ThoR after arrogantly running Meynaf and me off for suggesting the same thing? You finally caved to adding all the 68020 addressing modes after Meynaf and I told you having them would provide best compatibility and keep some heavy using programs from crawling due to traps. I would like to support your project but I won't put up with your arrogance and abuse.

[kolla]

That falls under "patching" in my eyes, but details. I agree that putting everything in a autoconf module would be best, so everything is available from coldboot. Some flash memory to also hold kickstart image would be great. Btw, how is the "SYS:Expansion" drawer used, if it all? I never saw it used for anything.

[wawrzon]

That falls under "patching" in my eyes

if adding library for few unsupported instructions is patching the os, then 040/060 require this as well. apparently you cant just "patch" the os that way to make it work with coldfire for example, which speaks for apollo core compatibility.
this is one thing. another is, that the more instruction a cpu doesnt provide without a library support, the less it is compatible for "nodos" software, that not accept being run from the operating system. of course it is usually only old games, that do not require acceleration in first place, its nice though staying compatible even with these as far as possible.

[wawrzon]

What is the truth? Can you tell us when you change your mind again and update your documentation (the only documentation I find is N68050 encoding maps)? The truth can change especially where you control it. The last truth (or lie from your posts) was that you were using OPI.L #.L, which would partially overwrite encodings of some other instructions like CAS, CAS2 and CMP2.

http://www.apollo-core.com/knowledge.php?b=4¬e=2732

Did you finally listen to ThoR after arrogantly running Meynaf and me off for suggesting the same thing? You finally caved to adding all the 68020 addressing modes after Meynaf and I told you having them would provide best compatibility and keep some heavy using programs from crawling due to traps. I would like to support your project but I won't put up with your arrogance and abuse.

even if discussion is heated, if it leads to a positive result and reconsideration in the end, i find it a rather positive sign. i am accustomed to completely different behaviour in this scene.

[Lurch]

By the way, when I had the indivision ECS scandoubler on my A500 before I lost it...I did not like it. I mean I like the idea that I can hook my A500 in a monitor anytime...I just did not like the quality (ignoring the fact the board was defective and the image came gibberish).....it felt worse than WinUAE. TOOO...pixilated, WinUAEish...I do not know. But ones I hooked my A500 back in TV it felt the good old days again. I rather treat my A500 the same way I treat Commodore 64...composite or rf and TV.

This argument over composite/RF is better than a 100% working Indi is silly. Colour bleeding and blurred pixels vs picture perfect crisp screen.

I don't think it's a quality thing, more misplaced nostalgia. Either that or a faulty Indi.

Who doesn't want an A500 with 800x600@256 colour workbench? Switching is also seamless between playing an WHDLoad game and coming back to workbench unlike my A1200T where I have a switch to do that.

Also enjoying playing Doom 640x480 with 256 colours :-)

Playing old school games is also amazing, no tearing and look great on my 27" monitor. Colours seem to pop more too, actually some games I notice more detail than back in the day.

I'm like a kid in a candy shop everytime I fire up igame when the full colour thumb nails, 1000 games down 1900+ to go through.

[Lurch]

Can't wait to see what happens if I do get the opportunity to test the faster accelerator, I believe that with the extra speed I could push workbench further :-)

Fingers crossed :-) :-) :-)

[guest11527]

That falls under "patching" in my eyes, but details.  

Well, a "patch" is - as the regular meaning of the word in the English language suggests - a piece of fabric (or code) placed on top of a hole on a piece of sheet (or Operating System, for that matter). So my meaning of the word "patch" is that you replace some instruction or function in a program or the Os. That does not happen here, i.e. the Os remains unaffected. Except for installation, the Phoenix support code does not even require the Os. Anyhow, let's not be hairsplitting here.  

Btw, how is the "SYS:Expansion" drawer used, if it all? I never saw it used for anything.

It's used by "BindDrivers". This command scans the autoconf-database, i.e. "expansion.library", checks for unconfigured expansions, and if so, gets its vendor and product ID. It then scans for an icon in SYS:Expansion whose product and vendor ID matches, and loads the corresponding binary. In other words, SYS:Expansion contains firmware for autoconf hardware that does not contain driver code. Typical examples are serial or parallel port expansions. It does not make sense to make their hardware more complicated than necessary and include an EPROM there because you do not want to boot from them in first place, so the firmware sits on disk in SYS:Expansion.