@cdimauro

Quote:

- PMMU (usable from the existing software) is missing;

note:
The PMMU instruction set is 68851 only
No 68K CPU supports them.

The 68030/40/60/80 have an MMU.
But not the funky PMMU instructions.

Cesare Di Mauro you talk without knowing.



Cesare Di Mauro,

we can all see that you are butt hurt.
Because your TINA hoax history got mentioned.
You want people to believe that you are a hardware expert.
What expert is this who is not able to read the FPGA manual ?

Last edited by Gunnar on 17-Mar-2024 at 07:53 AM.

@cdimauro

Quote:

See above: it wasn't a hoax. It was a project which wasn't materialized despite the efforts. As many others. As it happens on the industry. It's... life!

In industry you start with reading the FPGA manual.
Then you know what is possible and then you plan and start working.
When you make a schematics then you assigning the real hardware pins-
this means in industry a schematic with 128 IO pins on this FPGA could never been done.


You obviously not read the FPGA manual - or you not understood anything of the manual.
Your schematic was FAKE, you not connected the pins ... as that the bus are impossible would have shown right away.




Why did you guys put stolen PCB pictures on the TINA website?
Is this not very dishonest?

Why did you make a fake schematics with impossible bus?
Did you guys not know how a schematic are done? = clueless
Or did you guys do this fake on purpose

@bhabbott

Quote:

No. Like all companies they made some good decisions and some bad ones, and some that would have been good but for circumstances.

I agree.
In my opinion trying to put all blame on "stupid" managers - is naiv.


Quote:

Buying and developing the Amiga was a good decision IMO, but some of the things they did with it (A3000, CDTV, A600) were not.

I agree buying the Amiga was smart.

Regarding the A600 was it really such a bad idea?

What was the idea of the Amiga 600?
I think the idea was to make a smaller formfactor A500 replacement,
adding new and more features
and for a very low price.

In general these ideas do not sound bad to me.
Do they sound bad to you?


I think the only problem is that Commodore could not produce the machine for the low price they planned.
If the machines would have cost not $500 but as planned much less
e.g. $300 then it could have been a great entry level system.

@Gunnar

Quote:

Gunnar wrote: Regarding the A600 was it really such a bad idea? What was the idea of the Amiga 600? I think the idea was to make a smaller formfactor A500 replacement, adding new and more features and for a very low price. In general these ideas do not sound bad to me.

Introducing the A600 as a cost reduced version of the A500 with features like HD and a PCMCIA sounds as a good idea for someone who is looking to the Amiga market from the perspective of an outsider.

But for Amiga users it meant:

- A500 expansions doesn't work any more.
- ECS games using number keys doesn't work any more
- AOS 2.0x isn't so compatible with AOS1.3 any more
- PCMCIA expansions where expensive and not very useful (this changed much later)
- For A500 users it should have been something more than just another A500

I don't know if C= could attract some new users with this machine, it had some small advantage over the A500 but nothing that made A500 owners buying it.

Wikipedia:
The managing director of Commodore UK, David Pleasance, described the A600 as a "complete and utter screw-up"
Dave Haynie, who worked as a senior engineer for Commodore, described the new features the A600 provided as bloat and noted its compatibility issues with A500 peripherals and lack of numeric keypad.
Ars Technica considers it to be the worst of Commodore's Amiga models, citing its higher price and fewer features compared to the Amiga 500, while also noting that markets were overstocked with A600 units at the same time that the more popular A500 and A1200 models were under-manufactured.

in Germany, it became the second best selling Amiga model, with 193,000 units sold but less than 1.081.000 units of A500 but still more than 79.500 units of A500+

Numbers from here:
https://www.c64-wiki.com/wiki/Amiga

@OneTimer1

for me A600 was a epic failure. At that time PCs were becoming more and more superior with better graphics (VGA cards) and more resources (processor, ram. hard drive). people did not want a cost reduced A500, they wanted something that was on the level of PCs at that time. A600 was one of the final coffin nails that destroyed commodore. They produced A600s in large numbers, then announced AGA (A1200). Of course noone wanted A600 anymore so they sold it with high losses.

@OlafS25

Quote:

people did not want a cost reduced A500

Well that's not what it mutated into anyway! The original A300 idea would have been cheaper but they kept adding stuff but not where it counted with upgrades to the graphics and sound and floppy drive!!!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

falsely posted.

Last edited by OneTimer1 on 17-Mar-2024 at 01:08 AM.

@OlafS25

Quote:

OlafS25 wrote: for me A600 was a epic failure. At that time PCs were becoming more and more superior with better graphics (VGA cards) and more resources (processor, ram. hard drive). people did not want a cost reduced A500, ...

That's what I tried to tell, the management may have planned a cost reduced A500, that was not really cheaper but incompatible, maybe they wanted to attract newcomers that where kept away by rumours about incompatibility and the lack of expansions interfaces.

People who already had an A500 would have opted for an A1200 like system, maybe a A1200 big enough for a standard 3,5" HD (desktop case?) and sockets for fastram would have been a possibility.

But all this discussions about 'what if' are useless today.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: I think that it's true and it applies to TINA as well: too high expectations that were disappointed when the project was implemented, which led to its closure. TINA was hoax Did you ever do a PCB of it? No you did not But you showed PCB pictures on the TINA website. And these pictures where stolen from other project in the internet. Why did you guys steal pictures from other websites? The advertised numbers of the project were completely technically impossible. This has nothing to do with to high expectations. This means you have no clue about hardware and you not cared to look in the FPGA manual. The TINA was advertised with 128bit memory and with 400MHz clock. Both values are impossible. The FPGA does not have enough IO pins to connect 128 Bit of memory. And the FPGA can not reach 400MHz. What does this show us? You guys made a nice looking website, with stolen pictures from the internet. With schematics with 128bit bus you painted and with 400MHz. If you read the FPGA manual than you see immediately that both values ARE IMPOSSIBLE. Do you say that you guys did all the website work and painted the schematics without anyone of you reading the FPGA handbook?

Quote:

Gunnar wrote: @cdimauro Cesare Di Mauro, we can all see that you are butt hurt. Because your TINA hoax history got mentioned. You want people to believe that you are a hardware expert. What expert is this who is not able to read the FPGA manual ?

Quote:

Gunnar wrote: @cdimauro Quote: See above: it wasn't a hoax. It was a project which wasn't materialized despite the efforts. As many others. As it happens on the industry. It's... life! In industry you start with reading the FPGA manual. Then you know what is possible and then you plan and start working. When you make a schematics then you assigning the real hardware pins- this means in industry a schematic with 128 IO pins on this FPGA could never been done. You obviously not read the FPGA manual - or you not understood anything of the manual. Your schematic was FAKE, you not connected the pins ... as that the bus are impossible would have shown right away. Why did you guys put stolen PCB pictures on the TINA website? Is this not very dishonest? Why did you make a fake schematics with impossible bus? Did you guys not know how a schematic are done? = clueless Or did you guys do this fake on purpose

And here, as usual, Gunnar entered **moderated** Propaganda of Lies mode: continuously repeating the same lies, pretending to sell them as the truth, and without giving a single fact supporting it, of course: people should trust him only by his word, because he's "BigGun".

Well, as I've said before, I've already rebutted every single thing on the previous thread, so I just copy & paste my writings (like you did).

Oh, poor Gunnar: you are so desperate that you aren't able to sustain the discussion that you entered again the **moderated** propaganda of lies to defend your crappy 68080, miserably trying to avoid talking about it and moving everything towards me.

As usual, because you've already done it here:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44169&forum=17&start=100&viewmode=flat&order=0#855068
and continued all over the thread.

However I've already punctually and precisely replied to all your pile of LIES starting from here:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44169&forum=17&start=100&viewmode=flat&order=0#855074
and all over the thread until my last comment:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44169&forum=17&start=240&viewmode=flat&order=0#855444

After that you disappeared, as it happens with you when you recognize that you're able to sustain the PURE LEIS that you report to sully what you identified as your enemy.

And you repeated it again like a PARROT even after I've fully clarified everything about TiNA here:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=43687&forum=2&start=300&viewmode=flat&order=0#869122

And here you start with your personal attacks offending your "enemy" to discredit his reputation, with the clear purpose of invalidation his statements.

Needless to say, it's a very well know logic fallacy, the Poisoning the well: https://en.wikipedia.org/wiki/Poisoning_the_well

But you've already proved several times that logic is not your friend, and there's PLENTY of proof in the links that I've provided above.

Last edited by amigakit on 28-Mar-2024 at 07:37 PM.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: - FPU is only supporting up to double-precision and is lacking extended precision. Nevertheless, nothing was changed even after that this was highlighted so MANY TIME. You are simply not able to read. The website clearly states that the FPU is 64bit. Quote: Apollo Core 68080 advantages: Fully Pipelined Superscalar Executes up to 4 instructions per clock cycle Two address calculation engines Two integer execution engines Market leading code density Optimal cache utilization Separate data and instruction caches, supporting concurrent fetch/read/write per clock cycle Automatic memory prefetching Memory stream detection Store buffer Branch prediction Fully pipelined, 64bit SIMD AMMX Vector unit Fully pipelined, double precision FPU

You've changed your site, but it's too late now:
https://web.archive.org/web/20230617052549/apollo-core.com/index.htm?page=features
Quote:

Apollo Core 68080 advantages: Fully Pipelined Superscalar Executes up to 4 instructions per clock cycle Two address calculation engines Two integer execution engines Market leading code density Optimal cache utilization Separate data and instruction caches, supporting concurrent fetch/read/write per clock cycle Automatic memory prefetching Memory stream detection Store buffer Branch prediction Fully pipelined, double/extended FPU

You tried to hide your swindle, crook. But, as I've said, it's too late now.

You got a warning. You decided to ignore it and continue your propaganda of lies. You'll get what you deserve now.
Quote:

Gunnar wrote: @cdimauro Quote: - PMMU (usable from the existing software) is missing; PMMU instructions are 68851 only No 68K CPU has them. Cesare Di Mauro you talk without knowing.

Playing with the words will not save you: it only shows how much desperate you are.

Anyway, I'll give full (technical) details about that as well, and I leave to the readers to draw their conclusions.

@cdimauro

https://amigaworld.net//modules/newbb/viewtopic.php?topic_id=37651&forum=25#706346

Cesare DI Mauro:
Posted An AmigaWorld About the Tina:
Quote:

It's difficult to think about an A500 clone with more than 3GB/s (at least; we are working hard to get MUCH more) of memory bandwidth.

Please explain us again how your TINA system reaches 3 GB/sec?

And please tell us where you worked hard to get more than 3GB/sec?
Was your work in "PowerPoint"?


Cesare DI Mauro
The schematics you showed were flawed - and fake.
The PCB fotos you showed were stolen from other projects.

And the 3 GB/sec that you posted in Amigaworld forum - never existed.

Last edited by Gunnar on 17-Mar-2024 at 07:57 AM.

@cdimauro

Quote:

We know that 68030 (not castrated versions like EC) provides a PMMU which you have NOT implemented. We know that 68040 (not castrated versions like EC) provides a PMMU which you have NOT implemented. We know that 68060 (not castrated versions like EC) provides a PMMU which you have NOT implemented.

Cesare you sound confused.
The 68080 has an MMU.
You can use the tool APOLLOSHIELD to active the MMU.



If you refer to the PMMU instruction set with PSAVE PDBRA PTRAP PBcc and so on
This instruction set is not supported by ANY 68K CPU
Only the 68851 chip has the PMMU instruction set and NO 68K CPU has them.


CESARE:
Quote:

Even the BCD instructions? Are they fully implemented in hardware? Or are some of them implemented in software?

Yes the Apollo 68080 CPU has all BCD instructions in hardware.

Yes the Apollo 68080 CPU has all BitField instructions in hardware in single cycle.
The Motorola 68060 need often 9-12 cycle for them.

Yes the Apollo 68080 CPU also has MOVEP - which the Motorola 68060 CPU misses.
This means games using it like Speedball run on the 080 - while crash on the 060!

Yes the Apollo 68080 CPU has hardware support for MUL64 and DIV64 in hardware - which the Motorola 68060 CPU misses.

Yes the Apollo 68080 CPU has also FINT in hardware - which the Motorola 68040 CPU misses.

Yes the Apollo 68080 CPU has FDBRA, FTRAP and FSCC implemented in hardware - all these are missing in the Motorola 68060 CPU

Yes the Apollo 68080 CPU has full hardware support for all instructions of type FOP.X #imm,Fp - all them them again are missing in the Motorola 68060 CPU

Yes the Apollo 68080 CPU has full hardware support for "FMOVEM #list ,controlregs" - which is missing again in the Motorola 68060 CPU


In opposite to the 040 and 060 you not need install any software support libraries for the 68080 CPU.
The Apollo 68080 CPU can execute all instructions alone.


That you can run on the APOLLO 68080 CPU any OS like MAC OS, ATARI TOS/EMUTOS and all AMIGA OS version from 1.0 to 3.9 - shows very clearly how compatible the CPU is.

It goes without saying that if instructions would be missing - then MAC OS, or AMIGA OS or ATARI OS would not run.


The Apollo 68080 MMU is different in design to older MMUs and this is on purpose.
Our design goal are: more features in the MMU and higher performance in big memory scenarios.
This has been explained in detail.

Last edited by Gunnar on 17-Mar-2024 at 10:32 AM.
Last edited by Gunnar on 17-Mar-2024 at 08:57 AM.
Last edited by Gunnar on 17-Mar-2024 at 08:37 AM.

@OlafS25

Quote:

for me A600 was a epic failure.

The A600 which originally named A300 as the original plan was to produce and sell it as very low price - much cheaper than the A500.

Could that have worked? I think it could ..


Quote:

They produced A600s in large numbers, then announced AGA (A1200). Of course noone wanted A600 anymore so they sold it with high losses.

I think the original plan always was to offer the A600 as low end entry level system with a price much below the A1200.

@Gunnar

Quote:

Gunnar wrote: @cdimauro https://amigaworld.net//modules/newbb/viewtopic.php?topic_id=37651&forum=25#706346 Cesare DI Mauro: Posted An AmigaWorld About the Tina: Quote: It's difficult to think about an A500 clone with more than 3GB/s (at least; we are working hard to get MUCH more) of memory bandwidth. Please explain us again how your TINA system reaches 3 GB/sec? And please tell us where you worked hard to get more than 3GB/sec? Was your work in "PowerPoint"? Cesare DI Mauro The schematics you showed were flawed - and fake. The PCB fotos you showed were stolen from other projects. And the 3 GB/sec that you posted in Amigaworld forum - never existed.

And here, as usual, Gunnar entered **moderated** Propaganda of Lies mode: continuously repeating the same lies, pretending to sell them as the truth, and without giving a single fact supporting it, of course: people should trust him only by his word, because he's "BigGun".

Well, as I've said before, I've already rebutted every single thing on the previous thread, so I just copy & paste my writings (like you did).

Oh, poor Gunnar: you are so desperate that you aren't able to sustain the discussion that you entered again the **moderated** propaganda of lies to defend your crappy 68080, miserably trying to avoid talking about it and moving everything towards me.

As usual, because you've already done it here:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44169&forum=17&start=100&viewmode=flat&order=0#855068
and continued all over the thread.

However I've already punctually and precisely replied to all your pile of LIES starting from here:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44169&forum=17&start=100&viewmode=flat&order=0#855074
and all over the thread until my last comment:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44169&forum=17&start=240&viewmode=flat&order=0#855444

After that you disappeared, as it happens with you when you recognize that you're able to sustain the PURE LEIS that you report to sully what you identified as your enemy.

And you repeated it again like a PARROT even after I've fully clarified everything about TiNA here:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=43687&forum=2&start=300&viewmode=flat&order=0#869122

And here you start with your personal attacks offending your "enemy" to discredit his reputation, with the clear purpose of invalidation his statements.

Needless to say, it's a very well know logic fallacy, the Poisoning the well: https://en.wikipedia.org/wiki/Poisoning_the_well

But you've already proved several times that logic is not your friend, and there's PLENTY of proof in the links that I've provided above.

Last edited by amigakit on 28-Mar-2024 at 07:38 PM.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: We know that 68030 (not castrated versions like EC) provides a PMMU which you have NOT implemented. We know that 68040 (not castrated versions like EC) provides a PMMU which you have NOT implemented. We know that 68060 (not castrated versions like EC) provides a PMMU which you have NOT implemented. Cesare you sound confused. The 68080 has an MMU. You can use the tool APOLLOSHIELD to active the MMU. If you refer to the PMMU instruction set with PSAVE PDBRA PTRAP PBcc and so on This instruction set is not supported by ANY 68K CPU Only the 68851 chip has the PMMU instruction set and NO 68K CPU has them.

I'm NOT confused. You should CAREFULLY read what I write and pay DEEPER attention of the WORDS that I've used.

Anyway, and as I've already said, I'll write down everything on this topic. It "just" requires some time, because I like to be very precise.
Quote:

CESARE: Quote: Even the BCD instructions? Are they fully implemented in hardware? Or are some of them implemented in software? Yes the Apollo 68080 CPU has all BCD instructions in hardware. Yes the Apollo 68080 CPU has all BitField instructions in hardware in single cycle. The Motorola 68060 need often 9-12 cycle for them. Yes the Apollo 68080 CPU also has MOVEP - which the Motorola 68060 CPU misses. This means games using it like Speedball run on the 080 - while crash on the 060! Yes the Apollo 68080 CPU has hardware support for MUL64 and DIV64 in hardware - which the Motorola 68060 CPU misses. Yes the Apollo 68080 CPU has also FINT in hardware - which the Motorola 68040 CPU misses. Yes the Apollo 68080 CPU has FDBRA, FTRAP and FSCC implemented in hardware - all these are missing in the Motorola 68060 CPU Yes the Apollo 68080 CPU has full hardware support for all instructions of type FOP.X #imm,Fp - all them them again are missing in the Motorola 68060 CPU Yes the Apollo 68080 CPU has full hardware support for "FMOVEM #list ,controlregs" - which is missing again in the Motorola 68060 CPU

So, can I assume that you've implemented ALL instructions in hardware AND that there is absolutely NO instructions which are executed via the trap & emulate emulation layer that you've realized for the FPU instructions (when they were first introduced with software emulation)?
Quote:

In opposite to the 040 and 060 you not need install any software support libraries for the 68080 CPU. The Apollo 68080 CPU can execute all instructions alone.

Yes, no libraries are required because and AFAIR you've an emulation layer that is already mapped in memory and that it's called without any handler to be installed.
Quote:

That you can run on the APOLLO 68080 CPU any OS like MAC OS, ATARI TOS/EMUTOS and all AMIGA OS version from 1.0 to 3.9 - shows very clearly how compatible the CPU is. It goes without saying that if instructions would be missing - then MAC OS, or AMIGA OS or ATARI OS would not run.

This is only about OSes. Applications are also very important and in this case you can't run all of them.
Quote:

The Apollo 68080 MMU is different in design to older MMUs and this is on purpose. Our design goal are: more features in the MMU and higher performance in big memory scenarios. This has been explained in detail.

Yes, I know, but that's not my problem: it's your problem if some existing software for the above OSes can't run or take benefit of it.

@cdimauro

Quote:

We know that 68020 has CALLM/RTM instructions which you have NOT implemented.

The 68080 does not support them. But the 68080 is code compatible to 68020 software.

Motorola states :

The MC68030 is upward object code compatible with previous CPUs like 68020.
The MC68030 does not support CALLM/RTM.
Neither do the 68040 nor the 68060.

By Motorola own definition
A CPU labelled fully code compatible
does not need to have these "removed" instruction.



If you want to argue about this : talk to Motorola

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: We know that 68020 has CALLM/RTM instructions which you have NOT implemented. The 68080 does not support them. But the 68080 is code compatible to 68020 software. Motorola states : The MC68030 is upward object code compatible with previous CPUs like 68020. The MC68030 does not support CALLM/RTM. Neither do the 68040 nor the 68060. By Motorola own definition A CPU labelled fully code compatible does not need to have these "removed" instruction.

This I'll clarify on my writing, as I've already stated.
Quote:

If you want to argue about this : talk to Motorola

I argue about this as well since YEARS, because Motorola always produced processors which aren't backward-compatibile.

Anyway, that wasn't the point. Again, I'll clarify it on my article.

Which, BTW, I'm writing to the best of my knowledge. Which means: all posts written in the forum and the documentation available on the web site (and before asking: no, I'll not join the discord channel).

If some important is missing then it's not my problem (because I expect it to be available on the website): it's in YOUR interest documenting YOUR product on YOUR site (for example, the ApolloShield command: there are just TWO lines with a very short description of what it's supposed to do with NO details at all of how it works and, hence, how the MMU works).

@cdimauro

Cesare Di Mauro:
Quote:

We know that 68020 has CALLM/RTM instructions which you have NOT implemented.

Gunnar:
Quote:

The Apollo 68080 does not support CALL/RTM. But the 68080 is code compatible to 68020 software. Motorola states : The MC68030 is upward object code compatible with previous CPUs like 68020. The MC68030 does not support CALLM/RTM. Neither do the 68040 nor the 68060. By Motorola own definition a CPU labelled fully code compatible does not need to have these "removed" instruction. If you want to argue about this : talk to Motorola

Cesare:
Quote:

I argue about this as well since YEARS, because Motorola always produced processors which aren't backward-compatibile.

That you argue about this and attack a CPU for being incompatible for not supporting CALL
does only show that you NOT understand the CPU instruction set - but only want to argue.


It happens from time to time that a CPU vendor does add
an instruction to a CPU which is then found out - to be not good.

This is nothing exceptional. This is normal.

The first 68000 CPU did have this too!
Do you wondered why there is a big encoding "gap" in the $7 line in 68K?
The 68000 did had there a today "lost" instruction.
With the encoding $71xx you had an instruction which they found not
that useful and which they removed in the later 68000 revision and not support in any later 68K model.
And this instruction is not anymore mentioned in todays instruction manuals.


Removing a not good instruction and forbidding to use it, is nothing special.

The story with the CALL instructions is the very same.
Motorola removed it from the instruction set.
No compiles should ever create. No programming language should use it.
And no other 68K CPU shall support this.

This is logical and this makes sense.

What makes no sense, it that you argue about this.

Last edited by Gunnar on 18-Mar-2024 at 07:02 AM.

@cdimauro


CESARE:
Quote:

Which, BTW, I'm writing to the best of my knowledge. Which means: all posts written in the forum...

We all know this.

- You not have any such system.
- You never used such system.
- You never coded any such system.
- Your not talk from experience and not from knowing

Funny is that you tell Hammer that his googled wisdom is useless ...

But of course for you this is different, your googled "wisdom" is better

@Gunnar

Quote:

Gunnar wrote: @cdimauro Cesare Di Mauro: Quote: We know that 68020 has CALLM/RTM instructions which you have NOT implemented. Gunnar: Quote: The Apollo 68080 does not support CALL/RTM. But the 68080 is code compatible to 68020 software. Motorola states : The MC68030 is upward object code compatible with previous CPUs like 68020. The MC68030 does not support CALLM/RTM. Neither do the 68040 nor the 68060. By Motorola own definition a CPU labelled fully code compatible does not need to have these "removed" instruction. If you want to argue about this : talk to Motorola Cesare: Quote: I argue about this as well since YEARS, because Motorola always produced processors which aren't backward-compatibile. That you argue about this and attack a CPU for being incompatible for not supporting CALL does only show that you NOT understand the CPU instruction set - but only want to argue.

You're mixing two things here, which are similar, and both deserve complaints.

As I've already stated, I'll clarify this in my article, providing technical details. This will show if I understand ISAs or not.
Quote:

It happens from time to time that a CPU vendor does add an instruction to a CPU which is then found out - to be not good. This is nothing exceptional. This is normal. The first 68000 CPU did have this too! Do you wondered why there is a big encoding "gap" in the $7 line in 68K? The 68000 did had there a today "lost" instruction. With the encoding $71xx you had an instruction which they found not that useful and which they removed in the later 68000 revision and not support in any later 68K model. And this instruction is not anymore mentioned in todays instruction manuals. Removing a not good instruction and forbidding to use it, is nothing special.

Undocumented instructions were quite common.

But as long as they never officially went in production, I've absolutely nothing to say if the company decides to remove them starting from some revision.
Quote:

The story with the CALL instructions is the very same. Motorola removed it from the instruction set.

That's a completely different story, since the CALLM/RTM instructions went in production and they were, and are still, documented by the company.
Quote:

No compiles should ever create.

I have no information about this, but at least assemblers can assemble them. For example:
http://sun.hasenbraten.de/vasm/index.php?view=relsrc

"callm",    {QI,CT},      {{EL8,SEA},        {0x06c0,0},2|UNS|S_NONE,m68020},
"rtm",      {R_},         {{RL4},            {0x06c0,0},1|UNS|S_NONE,m68020},

But of course for you this is different, your googled "wisdom" is better