@Gunnar

Quote:

Gunnar wrote: @matthey Quote: The AC68k V2 FPGA is packed like a sardine. It doesn't even have room for full 68020 integer support let alone a FPU. Without at least FPU registers, Matthey for the record. 1) You are claiming the 68080 V2 would have no full 68020 integer instructions support? Your post is absolutely wrong. The 68080 CPU in V2 and V4 is complete covering all 68K integer instructions. You can nicely run with it Amiga OS 1/2/3/../3.2 .. ApolloOS, MAC-OS and even Emutos / AtariOS. You can enjoy Amiga 060 demos using FPU and also play 3D games like Quake. There is nothing missing in the Apollo 68080 CPU. And claiming it would miss 020 EA modes is not the trust but a lie. The Apollo 68080 CPU has 100% all integer instructions including all instructions of 68000/68010/68030/68040/68060 and so on. You can read this here yourself: http://www.apollo-core.com/documentation/AC68080PRM.pdf

He's right: you haven't implemented some instructions. You also stated that CALLM and RTM aren't implemented.

You can give whatever YOUR personal reason, but the pure fact is that they aren't implemented, so you can NOT claim the above.

You stated the same in your site as well: http://apollo-core.com/index.htm?page=features
68 ISA is full green for the 68020. Which is clearly false and misleading: you're selling a product which is not compliant to what you're advertising, which is cheating...
Quote:

2) You are claiming the 68080 V2 would have no hardware FPU registers and no hardware FPU? Your post is again absolutely wrong. The 68080 in the V2 has not only all register it also has a very potent hardware FPU. The V2 happily scores 74 MFlops in Sysinfo test - which is a lot higher than 68040 and 68060 score. http://www.apollo-core.com/gfx/vampire_sysinfo.gif

Have you implemented the full FPU instructions of the 68k ISA, or do you miss some?
Quote:

Gunnar wrote: @Karlos Quote: [quote]@Gunnar Quote: The Apollo 68080 CPU has 100% all integer instructions including all instructions of 68000/68010/68030/68040/68060 and so on. Interesting. What do CALLM and RTM do on the 68080?

I can tell you this. As you might know according to Motorola himself, CALLM and RTM were mistakes in the 020 CPU.[/quote]
According to Motorola? Source for this claim?
Quote:

Motorola did removed them from the 68K family for good reason: No later 68K CPU therefore supports!

Motorola removed a lot of stuff: all for good reason? Then why you've implemented the full 68k ISA instead of just the 68060 one?
Quote:

68030 does not support them, 68040 does not support them, 68060 does not support them, and Apollo 68080 does not support them either.

Only because YOU decided to don't support them.

Like the FPU, right? How many times to removed comments on your site when people were asking for the FPU implemented, and you even banned them. It was rarely used, not needed, and there was no space in the FPGA, as you clearly stated it several times.

But one day you woke-up and decided to implement the FPU: it suddenly became important and magically some space in the FPGA was found...

Coherence? It's a word not found on your vocabulary.
Quote:

As we all know Motorola recommend to never use CALLM/RTM and the Commodore coding guides forbid using them. Apollo 68080 follow the Motorola guideline.

Source for both claims?
Quote:

Matthey posted the 68080 would not support MVZ. And this claim is incorrect too. The Apollo 68080 does support MVZ and MVS but we call them MOVZ and MOVS, because our coders think these names sound better.

Those instructions were added only recently, as you published them just some days ago (as well as the other instructions that you've mentioned on the other comment).

Maybe Matt was simply not up to date with your latest, fresh mindset change.

BTW, are the encodings the same as the ones for Coldfire, or new ones?
Quote:

Gunnar wrote: @Karlos CALLM makes no sense. This is crystal clear and there is not doubt here for me (no one doubts this).

It's crystal clear only that you haven't implemented them because YOU decided that. But this decisions makes your 68080 not 100% compatible, as you're falsely claiming.
Quote:

---------------------------------------------------------------------------------- The Apollo 68080 CPU focuses in adding useful instructions. For example: 68080 offer the best code density of all 68K family CPU members.

Is the same true for the 64-bit mode?
Quote:

68080 offers for this a number of instructions that make code shorter. For example: ADDIWL CMPIWL MOVIWL MOV3 MOVZ MOVS PERM BRA.B2 BSR.B2 BCC.B2 DBRA.L These instruction all help to make more compact code and shorter programs. Apollo 68080 also offers some very useful FPU enhancements. For example : FMOVERZ and FMOVEURZ These instruction fix gabs in the 68K instruction set for operations where compilers needed to insert a number instructions before. Therefore they hep to reduce code size and improve performance. You can find a complete overview of all 68080 instruction online: http://apollo-core.com/index.htm?page=coding&tl=1

The .B2 are missing.

@Karlos

Quote:

I don't know how much I agree, but what I will say is that things like rendering in HAM may still require AGA to act as a dumb framebuffer and take more CPU to do, but so what? That's exactly where we are. Thanks to things like the PiStorm we now have more CPU power than we know what to do with, so why not have some fun see what the original hardware is capable of without the CPU limitations? Isn't that the whole point?

Sure it's cool to have the ability to do it now. But it's also redundant. The PiStorm offers RTG out of the box. So the HAM novelty wears off when you not only can have 16 bit modes to beat HAM6 but have 24 bit modes to beat HAM8. So there is doing it to be nostalgic because it uses an Amiga feature. And I admit a Workbench HAM hack would be cool to see.

However, that's only if you treat the bitmap like a dumb framebuffer. Or even a dump framebuffer since you just dump all the pixels to it. So just a software rendered display device with no hardware acceleration. This is what Doom is on the Amiga, it dumbs down the Amiga, because it just used old fashioned software rendering and didn't use any Amiga features. So running Doom an an Amiga is dumb.

This all changes if you combine hardware features. HAM with copper and sprites. Now your talking. BOBs are a point of contention, since they used blitter, but CPU can shift data faster. At that point you have DOBs. Dumb OBjects. Or Dump OBjects even.

@agami

Quote:

The same cannot be reasonably said for any PPC hardware intended for AmigaOS 4 and its catalogue of apps.

That's because it's held back by the intended market. Which was Amiga users. So AmigaOS 4 is designed to run as an AmigaOS machine with backwards compatibility. Even though the purpose was to move the OS forward it took with it all the legacy cruft that prevents the core design from upgrading to 64 bit, SMP and being portable. Though it likely would have had as much in common with AmigaOS as AmigaDE did, the Amiga Inc portable AmigaOS4 x86 and AmigaOS 5 ideas would have been more future proof.

@Kronos

Quote:

And even in 94 noone was gaming Doom in HAM because it didn�t look that much better than 256 colors to justify the piss poor performance even on elite priced HW.

No one was running Doom in HAM because an A500 HAM port was pointless. That's worse than even expecting Doom to run on an A500. I say A500 because it can only display a max 64 colour palette so for ECS using HAM6 would a way to get close to those 256 colours. Now AGA, this already had a 256 colour mode, so HAM8 is pointless. Doom was a 256 colour game so a virtual 18 bit pixel mode is rather more pointless, using the same amount of bitplanes, as well as needing more live pixel conversion, unless you wanted to match the 18 bits to match 18 bit VGA, since the Amiga could [slowly] display 256 colours in full 24 bit precision.

@cdimauro
Quote:

Quote: Gunnar: CALLM makes no sense. This is crystal clear and there is not doubt here for me (no one doubts this). Commodore Programming guidelines forbid using them. Motorola removed them and advice people to not use them. Of course : No Amiga software, No Mac Software and No Atari Software uses this instruction. All new 68K CPUs do not support this instruction The 68030 CPU does not support it. The 68040 CPU does not support it. The 68060 CPU does not support it. The Apollo 68080 CPU does not support it. It's crystal clear only that you haven't implemented them because YOU decided that. But this decisions makes your 68080 not 100% compatible, as you're falsely claiming.

You need to read more careful: As written the 68080 is 100% compatible to 030/040/060 ..
The 68080 does not support CALLM, and this is good
as its the "demanded" behavior for any 68K CPU as by Motorola.

You need to understand that No Amiga software, No Mac Software and No Atari Software uses this instruction. And No new 68K CPU does support this instruction. So all is good.


Cesare, you misunderstand the topic that Matthey was referring too:
Matthey was NOT talking about CALLM.
Matthey is not an idiot. Only an idiot would think supporting CALLM is needed.


What Matthey was talking about were the 68020 EA modes.
The 68020 introduced major improvements and enhancements on the EA = address modes
These 020 EA modes support Index * Scale - which is very nice.
And the 020 EA modes support ([]) double indirect memory access.
The double indirect mode is accessing data over a pointer to a pointer in a single ASM instruction.
The 020 EA modes are pretty strong and allow make shorter code.
The 68080 does of course support them - as you also see in the GCC assembler output posted above.
The GCC used for the 68080 an double indirect mode automatically.
Supporting these 020 - EA modes is absolutely crucial for compatibility.


Historically the "phoenix" core which was use in the around one hundred Beta-V1 cards,
did miss some features - as it had to be stripped to fit in the tiny small FPGA of the V1.

The Vampire 1 was produce 10 years ago.
If you read the Apollo Website then you can see this information:


You see its very clearly stated that the Phoenix core in the Vampire
was limited in features and was not 100% compatible.
This was because of the tiny FPGA of the V1.



The problem with Matthey is that he mixes up the 100ish cards of the 10 year old Vampire 1
with the over ten thousand cards of the Vampire2 and Vampire4 - and mixes up their capabilities and features. And his mixup makes Matthey talk a lot of bollocks since years about the Vampire2/4



Quote:

Quote: 68080 offer the best code density of all 68K family CPU members. Is the same true for the 64-bit mode?

Yes absolutely - the Apollo 68080 has the best code density by far.


Code density is a very nice feature.
Code density makes programs smaller.
Smaller code allows you get more code in the Kickstart Rom
Smaller programs load quicker and better fit into caches = which makes them run faster.


Quote:

Quote: You can find a complete overview of all 68080 instruction online: http://apollo-core.com/index.htm?page=coding&tl=1 The .B2 are missing.

B2 is included in the "normal" instruction.
B2 allows that short branches jump twice as far.
This means the compiler/assembler can more often use .S/.B distance
and needs to use less the .W distance.
This helps programs getting smaller and better fit into cache = makes them run faster.

This is an automatic feature that Assemblers as GNU-AS, AsmONE, VASM, do support.

Last edited by Gunnar on 07-Feb-2024 at 05:44 AM.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: It's crystal clear only that you haven't implemented them because YOU decided that. But this decisions makes your 68080 not 100% compatible, as you're falsely claiming. You need to read more careful: As written the 68080 is 100% compatible to 030/040/060 ..

http://apollo-core.com/index.htm
Today, 680x0 is still used by industrial machines, planes industry, cars vendors and is still used by retrocomputing fans around the world.

Apollo Core 68080 is the natural and modern evolution of latest 68000 processors. It's 100% code compatible, corrects bugs of 680x0 designs and adds on top most of the cool features which were invented the years after.

http://apollo-core.com/index.htm?page=features
Apollo Core 68080 is not only the fastest 68000 series CPU ever, it also is the most fully featured.

68 ISA 68000 68020 68030 68040 68060

All green...

And I haven't even talked about the PMMU instructions here...
Quote:

The 68080 does not support CALLM, and this is good as its the "demanded" behavior for any 68K CPU as by Motorola.

Again, source for this claim?
Quote:

You need to understand that No Amiga software, No Mac Software and No Atari Software uses this instruction. And No new 68K CPU does support this instruction.

That's ok, I've no problem accepting it...
Quote:

So all is good.

...but not this, if the claim is to be 100% compatible, because this is clearly not the case.
Quote:

Cesare, you misunderstand the topic that Matthey was referring too: Matthey was NOT talking about CALLM. Matthey is not an idiot. Only an idiot would think supporting CALLM is needed.

Motorola's engineers were the idiots that not only designed, but even implemented CALLM/RTM...

Anyway, this isn't the point: see above.
Quote:

What Matthey was talking about were the 68020 EA modes. The 68020 introduced major improvements and enhancements on the EA = address modes These 020 EA modes support Index * Scale - which is very nice. And the 020 EA modes support ([]) double indirect memory access. The double indirect mode is accessing data over a pointer to a pointer in a single ASM instruction. The 020 EA modes are pretty strong and allow make shorter code. The 68080 does of course support them - as you also see in the GCC assembler output posted above. The GCC used for the 68080 an double indirect mode automatically. Supporting these 020 - EA modes is absolutely crucial for compatibility.

Absolutely. I've used them a lot in my 68020+ code (especially my 80186 emulator).

However, the problem with double-indirections was about performance. How work the 68080 in this case?
Quote:

Historically the "phoenix" core which was use in the around one hundred Beta-V1 cards, did miss some features - as it had to be stripped to fit in the tiny small FPGA of the V1. The Vampire 1 was produce 10 years ago. If you read the Apollo Website then you can see this information: You see its very clearly stated that the Phoenix core in the Vampire was limited in features and was not 100% compatible. This was because of the tiny FPGA of the V1. The problem with Matthey is that he mixes up the 100ish cards of the 10 year old Vampire 1 with the over ten thousand cards of the Vampire2 and Vampire4 - and mixes up their capabilities and features. And his mixup makes Matthey talk a lot of bollocks since years about the Vampire2/4

I've no problem accepting them, but I leave to Matt clarify his position on this.

Quote:

Quote: Gunnar: 68080 offer the best code density of all 68K family CPU members. Is the same true for the 64-bit mode? Yes absolutely - the Apollo 68080 has the best code density by far. Code density is a very nice feature. Code density makes programs smaller. Smaller code allows you get more code in the Kickstart Rom Smaller programs load quicker and better fit into caches = which makes them run faster.

I know it very well, and that's the reason why I've decided to design my ISAs to have great code density.

This happens with any kind of code: either in 32 or 64 (or 16 bit) mode, by using the full set of 32 GP registers and/or the 32 SIMD/Vector registers. There's no difference, because the opcodes are substantially the same.

However with the 68080 it's different, because of the prefix that it's needed to enable the 64 bits and for accessing the new registers (besides the AMMX, which uses the normal Line-F opcodes, where all of this was already packed there).
So, I expect a great loss of code density in this case.

I mean: 32-bit code and using the regular 68k registers is no problem. You get even better code density with the new instructions. But other than that, I expect a loss in code density.
Quote:

Quote: The .B2 are missing. B2 is included in the "normal" instruction. B2 allows that short branches jump twice as far. This means the compiler/assembler can more often use .S/.B distance and needs to use less the .W distance. This helps programs getting smaller and better fit into cache = makes them run faster. This is an automatic feature that Assemblers as GNU-AS, AsmONE, VASM, do support.

OK, so my understanding is that you used the unused odd (bit #0 = 1) encodings in the 8-bit offset to double the branch range.

Nice move. I did the same with my architectures since day 0.

P.S. No time to read again. Work time now...

@cdimauro

Quote:

OK, so my understanding is that you used the unused odd (bit #0 = 1) encodings in the 8-bit offset to double the branch range. Nice move. I did the same with my architectures since day 0. P.S.

When we talk about architectures,

Then I understand you talk about the 68080 CPU.
* The 68080 is on the market over 10 years.
* The Apollo 68080 is very popular both in Amiga and Atari world.
* The Apollo 68080 has over ten thousand customer using it since nearly a decade now.
* The Apollo 68080 is running any version of Amiga OS from 1.1 to 3.9
including the new ApolloOS, Mac OS 7 and 8 and AtariOS/Emutos.
* And the Apollo 68080 running many programs and also ApolloOS compiled using new instructions...


What is your architecture again?
Remind me again, your "architectures" only exists on paper, right?
How many programs did your architecture ever run?
Did it ever boot Mac OS?
Did it ever boot AtariOS?
Did it ever run any Amiga OS 1.x, 2.x, or 3.x?
How many programs did you write using your new architecture?
Did you ever use "your fantasy CPU" it the real world ?
Did you ever proof that your architecture even works and is not broken by design?

Please help me understand this better.
I had the impression that your architecture is only "on paper" and in your fantasy
and it was never proven that its encoding are even working.

@cdimauro

Being the math genious, how do you define 100% anyways?
At what point do you round up? 99,9% 99,99%

And then there "compatible" - nobody should need to care if a new cpu is 100% compatble with an old cpu, what’s important is that the new cpu is 100% compatible with existing software.

AC 68080 is compatible with nearly 100% of existing Amiga software - that’s what the advertising should say, the current claim is both inaccurate and somewhat nonsensical.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

And then there "compatible" - nobody should need to care if a new cpu is 100% compatble with an old cpu, what’s important is that the new cpu is 100% compatible with existing software.

I agree.
This is the point.
You want to be compatible to software - not to a removed instruction.


No 68k software uses CALLM - so no CPU needs to support it.


Dropping an not used instruction is nothing new.
People understanding the 68K architecture, will know that early 68000 chips
did include instructions that are not supported anymore with later 68000 chips..
and that these instructions are also not supported by 68010 / 680020 or later chips.
And that no software uses these instructions.
So this is all good and no problem.

When I asked what CALLM does, the only person who responded appropriately was Hans.

Come on guys, it was a comic relief shitpost! All this argument

Though I still think it would be cool if it were implemented as a means I'd calling runtime supplied hardware modification (ime. hacking fun) of the FPGA itself. Assuming that's even possible.

Last edited by Karlos on 07-Feb-2024 at 09:40 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

When I asked what CALLM does, the only persons who responded appropriately was Hans.

I agree.
Hans post was funny and smart.


I have the feeling that for some people this forum is an alternative reality ...
in which they dream or fantasize about being an Amiga coder ..

@Hammer

Quote:

John Carmack is aware of the A4000/040 with RTG card capability, but his argument is the installed base with Amiga's 68040+RTG specification.

I came across this original discussion where John talks about using planar to write the Doom screen. Which is then misinterpreted as being [Amiga style] bit planar. I thought it was funny.

https://groups.google.com/g/alt.games.doom/c/3tMB2UmEBK0/m/m1VR6LiJRQMJ

In my experience, which is using an A4000/060, I found there was only about a 1-2 difference in frame rate. RTG was slightly faster. And in most cases, the screen needed rendering in fast RAM, then copying to the framebuffer for greater speed. Of course an 060 wasn't an average build back then. An 030 was more likely if that.

Even with RTG, the framebuffer tended to be a linear pixel map. But VGA doesn't always use a linear layout since it's byte planar based. And Doom used VGA tricks for parallel pixel writes. So even RTG wouldn't be fully there. Since it really needed direct VGA access for most efficient rendering.

@agami

Quote:

For Commodore, a company that was in debt and struggling to find meaningful profitability, the A1200 was about as logical/practical a move as they come

The A1200 was obviously late. And failed to fix problems like supporting standard HD floppies and faster serial/parallel ports. But it came too late after the A500 as an A500 follow up. Even to this day gamers and game programmers still treat the A500 as king. And the A1200 like a speck of dust on glass.

Quote:

Alas it and subsequent CD32 gambit did not pay off. And I'd go as far to say the world was poorer for it.

The CD32 was an Amiga game console for Amiga gamers sold in public. Though it was sold along other consoles it didn't belong there. It was made for Amiga users. On top of this was that ridiculous XOR patent. I don't know if Cadtrak targeted Commodore over the C64, Amiga or what. But holding back the CD32 was even more ridiculous since the pointer sprite wasn't a soft cursor as an XOR cursor would be. Though AmigaOS would likely have used XOR for text cursor. In any case, Commodore should have taken the cut and paid them, instead of defending their honour. It didn't mean they was guilty, it was all business in the end, but they seemed to treat it as personal. Oh well.

@NutsAboutAmiga

The closest I could compare the AmigaOne/XE G4 too would be an eMac. I prefer to compare like for like as comparing direct with a PC will always fall short on price and power by comparison. Where as with a Mac both were running a PPC and with an eMac, IIRC, the basic model also ran at 800Mhz. However, an eMac was a limited all in one solution, costing $1500 AUD. My A1 setup, which I built myself, cost $2000 AUD for my setup. But it was terrible at running OSX if you could convince it to.

I can recall 1.8 Ghz PCs but it was a time after I bought my A1. And at the time I thought it would be cool to have an AmigaOne that had a 1.8Ghz CPU. Eventually the X1000 arrived and had a dual core 64-bit CPU running at that 1.8 Ghz! Unfortunately by the time that arrived 1.8 Ghz wasn't exciting for me any more.

@agami

Quote:

Yeah, in respect to the AmigaOS 4 drivers (queue rim shot).

Actually I was thinking with the hardware itself. Only DDR2, USB2, SATA was ok, 8 or 16GB limit on RAM but no one knows. Firmware was too slow and too easy to crash.

But, drivers, yes. On my A1/XE, a VIA USB2 card kept crashing, while other people with one sharing same PCI ID worked fine. Latest OS4 update freezes my R7 250 but it was fine before the update. The X1000 ethernet, runs too slow, and barely meets 200KB/s while connection can do 1.5MB/s. My XE running OS4 and my X1000 running Linux both max the ethernet port. X1000 needs RTL8139 as OS4 lacks stable onboard driver. But OS4 driver is crippled. Shouldn't be too hard and shouldn't need to fiddle with technical settings. Internet on X1000 OS4 sucks even without the browser.

@Karlos


Quote:

: Damn, that made me laugh. Really cheered up my day.

Well I didn't mean it as funny but glad it gave you some cheer.

It was a nice looking board with the trendy red theme. Made green look so last century. But a hardware designer I knew critiqued my board and said if it was a PC board, with that soldering job, it would be thrown out. I'm no expert but the soldering didn't look too bad to me. Some people just don't understand PPC and how expensive they can be.

Quote:

"Designed" is a strong word when talking about the Teron. It was knackered from the get go. Don't get me wrong, I had one and while it worked it was fun. I am sure there are probably some that still work, but all the indications are they are mostly dead now, killed by any number of serious flaws in their implementation (I hesitate to use the word design.

Dare I say, mine is still going. Needed battery since I stopped using it as often. And I almost ruined it when I cleaned out the case with a blower. Unfortunately my server RAM sitting near by and I lost 1GB in the winds of change.

@BigD

Quote:

No one is going to buy a £1000+ PPC AmigaOne from outside the elitist "Classes not the Masses" AmigaOne fanboydom.

The Amiga post dated the "Classes not the Masses" Commodore era. It was expensive. Even the C64 cost a bit but the Amiga made it look cheap.

@Hypex

Quote:

Internet on X1000 OS4 sucks even without the browser.

Can be interesting monitor it with WireShark and see what it does differently.

MC680x0 Amiga uses the same old Sana2 API, so has all the issues MTU etc, RoadShow is considered a good TCP/IP stack on Amiga, because Maimi does not even have working DHCP client. AmiTCP is even older.

https://www.linkedin.com/advice/0/what-best-practices-mtu-discovery-negotiation

funny it uses ICMP, as ICMP is so often disabled this days to avoid ping of death.
I think that spy on network traffic to sniff the MTU be better approach, of it can be put in ARP packet, sense its used during IP assignment.

Your router should be able split up network packers if needed, you should not need to set small MTU.

I won’t be surprised if bsdsocket.library in WinUAE bypasses the SANA2 low level API.

Its really up to the SANA2 driver to copy network packets, I expect that its not memory aligned, perhaps is not coping the data with fastest possible methods. Smaller memory blocks is slower if you use DMA transfer, but I expect of driver use 32bit copy routines not 64bit ones, or AltiVec as its up to the drivers.

Because IRQ was mess on AmigaONE-XE, it can be that IRQ is not used or something like that well. If the drivers is generic, and not written for AmigaONE-X1000.

Last edited by NutsAboutAmiga on 07-Feb-2024 at 05:26 PM.
Last edited by NutsAboutAmiga on 07-Feb-2024 at 05:12 PM.
Last edited by NutsAboutAmiga on 07-Feb-2024 at 05:03 PM.
Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:59 PM.
Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:56 PM.
Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:45 PM.
Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:43 PM.
Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:38 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Gunnar

Quote:

Gunnar wrote: @kolla Quote: And then there "compatible" - nobody should need to care if a new cpu is 100% compatble with an old cpu, what’s important is that the new cpu is 100% compatible with existing software. I agree. This is the point. You want to be compatible to software - not to a removed instruction.

So will you fix your website to reflect reality? It currently claim 100% code compatibility without specifying that what you mean is compatibilty with nearly 100% of Amiga software.

I have tons of 68k software that for various reasons can not run on AC68080, however this is not Amiga software and hence will never enter your calculations. You simply fix your compatibility numbers by ignoring all software that isn’t compatible. 100% code compatibility with software that is 100% compatible.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

Quote:

Hypex wrote: @agami That's because it's held back by the intended market. Which was Amiga users.

So in a way, you're saying that "Amiga users", the intended market in the original plans for AmigaOS 4, are not interested in the "right tool being half the work", and are somewhat masochistic in subjugation to a tool which demands that humans do 80%+ of the work, and furthermore pay a premium for their digital S&M sessions.

_________________
All the way, with 68k