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

[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.

[Lurch]

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....

WHDLoad is all I use to run older games/software. Works fine with the 060@80MHz on the A1200 and the 030@40MHz on the A500.

Worse comes to worse I can always use rekick or something similar via the Gotek and boot a really stubborn game or one I can't find under WHDLoad.

The only game I'm having to do that for at the moment is IK+ as its the only way to get sound effects to work on the bomb/ball levels.  Other than that I'm in Workbench all the time using WHDLoad/igame.

I don't see the issue here, it's going to be fine. Can't wait to prove the people wrong and post photos videos ;-)

[guest11527]

apparently you cant just "patch" the os that way to make it work with coldfire for example, which speaks for apollo core compatibility.

Well, actually, one could. Except that the result would be unbearably slow. The problem with the coldfires is that they only support 32-bit math, so every word-based or byte-based arithmetic instruction would require an emulator trap. And there are plenty of them, it's really a pretty common type of instruction on the Amiga.  

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.

Well, the (small) Phoenix core for the Vampire (and we're only talking about this core at the moment) does not support only instructions that are barely used anyhow. First, some 68020+ instructions like some 64-bit math (only 68020 anyhow), bitfield instructions (hard to do in pure hardware, slow anyhow, and 68020 and above only), MOVEP (rarely used, if ever, but available on 68000), BCD-arithmetics (ABCD,NBCD,SBCD - 68000, but rarely ever used) and the CAS2/CMP2 instructions, which are also rarely ever used, and 68020 and above only.

 Parts of the set  are already unsupported on the 68060 (parts of 64 bit math,CAS2,CMP2), some parts are new, but again usually not used (BCD arithmetic, MOVEP). Only bitfields are *sometimes* used, but they are really hard to do right. Especially, they need to read up to five bytes for a single instruction, and may not read or touch any byte outside of the requested range (to avoid side effects on hardware registers). Their emulation looks surprisingly complicated, and on a "real" CPU you probably want to do that stuff on microcode, and not in "gates".  

Whether the full Apollo core supports these instructions I don't know. But honestly, it is not really a loss, and providing a support library for that kind of stuff does not make the project any worse. It's mostly instructions you would microcode in a "real" hardwired CPU, but microcode is nothing that one can do elegantly in an FPGA, so it wasn't done.

[Fats]

Well, actually, one could. Except that the result would be unbearably slow. The problem with the coldfires is that they only support 32-bit math, so every word-based or byte-based arithmetic instruction would require an emulator trap. And there are plenty of them, it's really a pretty common type of instruction on the Amiga.  

Last I read was that some instructions were incompatible on the Coldfire that could not be trapped so the code basically has to be run under (JIT) emulation.

[psxphill]

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.

An FPGA allows you to load a 68000, 68010, 68020, 68030, 68040 or 68060 core depending on what you need at the time. AGA Amigas don't have a 68000 to fall back to, some Amigas don't have any CPU to fall back to.

At some point somebody that doesn't want to redefine the ISA will come along and do it right and we can all buy that one with confidence.

[biggun]

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.

Matt,

The Phoenix development team does meet every day in IRC channel.
The team members are therefore informed and have good overview.
Matt if you are never in IRC channel, you can not  know what is going on.
If you want to know more you need to participate.

The Phoenix development team has access to complete instruction decoding definition.
But you are not part of the development team,
therefore you have no access to this - so how can you know them?

The team members have hardware card and use Phoenix.
So the team members can speak from practical knowledge.
But if you have no card and never used Phoenix - then you have no practical knowledge.


Matt you look at the project from on outside view.
There is nothing wrong with this.

But don't you agree that from your outside view  you can not really know anything about Phoenix?

And do you not agree that as long you lack overview, and have no real knowledge - you can also spread rumours.
But spreading rumours and false information is really not helping the people at all.

[wawrzon]

if an amiga has not enough backward compatible cpu to satisfy your needs, it could fall back to, then its not gunnars fault. its likely that if if there will be hardware available, there may appear some alternative cores for it.
so far there always has been a lot of talking about fpga for years but very few people who actually did anything. not sure if there is an alternative for gunnars solution any soon, alas. which is uncomfortable, because there is a bit too much of what depends on one person for my taste but i dont see no option.

[biggun]

alas. which is uncomfortable, because there is a bit too much of what depends on one person for my taste but i dont see no option.

Just include me in your good night prayer and all willbe good.

[wawrzon]

@gunnar: who knows to whom i would be praying if i did;)

honestly i hope you wont get hit by a bus any soon;)

[alphadec]

Lets be happy there is some development for our dream computer - amiga.

[QuikSanz]

Indeed! Just keep it rolling Gunnar and we will back you up with money. Please start working on hard drive support, after all a fast CPU needs fast access.

Chris

[JimDrew]

The MacII (and later) all run in Supervisor mode, not user mode like the Amiga.  However, the Mac can jump back and forth.  Traps are used to get in and out OS calls.  Traps are also used on the Atari ST.

So, as we have learned with the FPGA Arcade Replay project, you just need to support every single 68020 instruction and addressing mode, and then everything works.  

[matthey]

The Phoenix development team does meet every day in IRC channel.
The team members are therefore informed and have good overview.
Matt if you are never in IRC channel, you can not  know what is going on.
If you want to know more you need to participate.

Your time zone is 7-8 hours different. A forum is better to provide information if it was correct.

The Phoenix development team has access to complete instruction decoding definition.
But you are not part of the development team,
therefore you have no access to this - so how can you know them?

Why make a public forum with partial and incorrect information posted by you and then keep the current "developer" information private? Use some logic, learn how to communicate and get organized.

The team members have hardware card and use Phoenix.
So the team members can speak from practical knowledge.
But if you have no card and never used Phoenix - then you have no practical knowledge.

Do you really think the majority of Majsta accelerator owners know what enhancements and encodings are in their card?

Matt you look at the project from on outside view.
There is nothing wrong with this.

But don't you agree that from your outside view  you can not really know anything about Phoenix?

And do you not agree that as long you lack overview, and have no real knowledge - you can also spread rumours. But spreading rumours and false information is really not helping the people at all.

I don't need hardware to see an ISA or encoding conflicts or what you have written on a forum (although maybe I need an interpreter because you have been anything but clear). I am only unable to test what I see. I would certainly consider buying the hardware if I could get good information and straight answers about the accelerator without wasting my time logging on to the IRC at inconvenient hours.

You called me out and everything but called me a liar but have not provided an answer, explanation or apology to what is probably your error.

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

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

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

Lets quickly sum up the available new instructions:
 
 We have two short encodings which reduce program size:
 
 
 ADDI.L #16bit,(ea)
 
 CMPI.L #16bit,(ea)
 
 
 The 16bit value is sign extended to 32bit before the 32bit operation is done.

Specifically,

ORI.L #d16, does not allow trapping of CMP2.B and CHK2.B
ANDI.L #d16, does not allow trapping of CMP2.W and CHK2.W
SUBI.L #d16, does not allow trapping of CMP2.L and CHK2.L
ADDI.L #d16,  no conflicts
EORI.L #d16, does not allow trapping of CAS.B
CMPI.L #d16, does not allow trapping of CAS.W and CAS2.W

While most of these instructions (with these operation sizes anyway) are likely to be rare even on the MacOS (and all should be deprecated IMO), I don't know if they are used on the MacOS so they could pose a problem. I wish Jim Drew had found his list of MacOS instruction frequencies he said he made years ago.

Here is the encoding map which shows the encoding conflicts.

http://www.heywheel.com/matthey/Amiga/68kF1_map.ods

OPI #d16,Rn has no conflicts in any case but there is little advantage when OP.L ,Dn using a new sign extended addressing mode (which who came up with?) allows OP.L #d16.W,Dn and the ISA documentation specifies to use the latter. Most instances of OPI.L #d16, are to a data register which can be converted to OP.L #d16.W,Dn with the exception of EORI.L because of the missing EOR.L ,Dn (uncommon enough that the 68k didn't support it).

Now instead of making me out to be an uninformed liar with your propaganda and falacies, how about letting us know how you performed the impossible of avoiding these encoding conflicts and allowing trapping for all possible 68020 integer instructions the MacOS could use. Are you willing to guarentee that there are no encoding conflicts when using MacOS emulation or you will allow the return of accelerators and personally refund the money of unhappy customers?

[wawrzon]

matt, he hasnt called you a liar. he simply suggested your info may not be up to date imho. that probably since they lack time to update online documentation, which would sure be more convenient than relaying on irc for communication, but then it all takes time.

[biggun]

Your time zone is 7-8 hours different. A forum is better to provide information if it was correct.



Why make a public forum with partial and incorrect information posted by you

Matt you to agressive here.
Can you just calm down?



Your problem is  that you misunderstand stuff and or misinterpret stuff.
There was nothing is incorrect about the old forum post.

Lets look at the fact first before we start to panic ok?

The forum post did show several instructions.
In fact only the instruction behavior and name was discussed there.
The encoding was never discussed in this posting.

This means the instruction where shown in NAME only not in ENCODING.
Is this correct - Matt?

So we can state here, that the encoding was not shown and not explained.
So in fact you do NOT know the encoding of the instruction.
Nevertheless you post here that the "unknown" encoding would clash with another instruction.

Please explain this.

[JimDrew]

ORI.L #d16, does not allow trapping of CMP2.B and CHK2.B
ANDI.L #d16, does not allow trapping of CMP2.W and CHK2.W
SUBI.L #d16, does not allow trapping of CMP2.L and CHK2.L
ADDI.L #d16,  no conflicts
EORI.L #d16, does not allow trapping of CAS.B
CMPI.L #d16, does not allow trapping of CAS.W and CAS2.W

While most of these instructions (with these operation sizes anyway) are likely to be rare even on the MacOS (and all should be deprecated IMO), I don't know if they are used on the MacOS so they could pose a problem. I wish Jim Drew had found his list of MacOS instruction frequencies he said he made years ago.

I looked through even my Syquest cartridge backups and I could not find that info.  

I can tell you that the MacOS uses ALL of the above instructions.

I will chat with Derek (emulators, inc.)  I might have given the instruction frequency info to him when I sold FUSION-PC to his company.