@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?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Interesting. What do CALLM and RTM do on the 68080?

- CALLM - calls M, and reports on 007's latest rogue shenanigans
- RTM - tells you politely, to Read The Manual



Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

I mean they may as well do :)

But seriously, I'm intrigued to know. I can imagine it could be used for lots of shenanigans with all the custom hardware in there.

_________________
Doing stupid things for fun...

@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.
Motorola did removed them from the 68K family for good reason: No later 68K CPU therefore supports!
68030 does not support them, 68040 does not support them, 68060 does not support them,
and Apollo 68080 does not support them either.
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.


But has this anything todo with Matthey post?
No

Matthey was claiming that the EA and Instruction set support would be incomplete.
His claim is not correct.

Matthey was claiming the 68080 in the V2 would have no FPU.
This again again is false.

The Apollo 68080 in the V2 not only has a hardware FPU it even has a full 64bit SIMD AMMX unit.

Matthey was posting many false posts here.
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.




Matthey I think you do not have an Apollo 68080 CPU. Neither a V2 nor a V4.
Is this correct that you do NOT have any of those systems?
And that you have not coded on any of them?


Can you explain us on what knowledge do you base all your false posts here?
* You don't have these systems.
* You never coded them.
* And you obviously have no knowledge about them.

@Gunnar

They weren't mistakes, they are a mechanism for calling a co-processor (not explicitly FPU or MMU) function. There's a big chunk in the 68020UM in section 9 about what it is for. It was removed because it's a lot to maintain and nobody used it.

Quote:

But has this anything todo with Matthey post? No

Nope. It was a reply to your statement:
Quote:

The Apollo 68080 CPU has 100% all integer instructions...

which you appear to have edited to remove the 68020 from the list - or I misread originally - whichever.

I was hoping you had implemented it (sans the extreme clock cycle overhead) as part of some secret sauce Apollo extensions to allow calling some funky new runtime synthesisable hardware operations using partial bistream rewrites to the FPGA or something.

Last edited by Karlos on 06-Feb-2024 at 12:56 PM.

_________________
Doing stupid things for fun...

@Karlos

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

----------------------------------------------------------------------------------

The Apollo 68080 CPU focuses in adding useful instructions.

For example:

68080 offer the best code density of all 68K family CPU members.

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

@Karlos

Quote:

Nope. It was a reply to your statement: Quote: The Apollo 68080 CPU has 100% all integer instructions including all instructions of 68000/68010/68030/68040/68060 and so on.

I did write this very clear.And 100% correct. And I did not edit this.
Maybe you right better before next time?



My question here:

Why is it so important for some people to post "fake news" here?

If I look at Matthey posts of the lasts month then I see so many "incorrect" posts.

Matthey why do you do this? Please help me understand this!


So many of your posts about 68080 - are totally wrong.

Do you post on purpose "lies" ?
Why do you do this?

What benefit do you have by posting dozens of false claims?
Why do you spend so much time on lying and on rubbish the 68080?


Or do not lie on purpose but just talk bullshit without having any clue?

@Gunnar

I could be super pedantic and say the statement 100% all integer instructions means every integer instruction ever implemented in the 68K ISA and that the remainder "including 68000/030/040/060" is superfluous as they are already covered by the superset of 100%. I could and it would mean I'm technically correct, which is the best kind of correct....

I could... I must resist...

Last edited by Karlos on 06-Feb-2024 at 01:26 PM.

_________________
Doing stupid things for fun...

@Gunnar

Presumably you also mean only the "user mode" 68K instructions here. Excluding CALLM/RTM of course. After all, the supervisor state instructions are typically implementation specific.

Tangentially, how feasible is it to rewire (some unused part of) the FPGA while running? I have read that this is supported functionality of some FPGA models at least.

Back in the day we had the spectacle (and horror) of self modifying code, but self modifying hardware (well, code modifying the hardware it runs on) is a new level of wizardry and misuse to aspire to.

Last edited by Karlos on 06-Feb-2024 at 01:44 PM.

_________________
Doing stupid things for fun...

@Gunnar

Quote:

Matthey why do you do this? Please help me understand this!

I think it's because you kicked his dog in the nuts by making a hardware solution for 68K that isn't his preferred ASIC one, maybe because it has extra features that aren't backwards compatible and maybe you ignored his sage advice when designing it

Last edited by Karlos on 06-Feb-2024 at 01:54 PM.

_________________
Doing stupid things for fun...

This thread really has turned into something a little extra special.

I'd suggest sealing it so all those it contains can't escape, but in the process some innocent people would become trapped in hell.

Last edited by fishy_fis on 06-Feb-2024 at 02:09 PM.

@Karlos

Quote:

Quote: Matthey why do you do this? Please help me understand this! I think it's because you kicked his dog in the nuts by making a hardware solution for 68K that isn't his preferred ASIC one, maybe because it has extra features that aren't backwards compatible and maybe you ignored his sage advice when designing it

Some of the things that Matthey says, e.g. that 68K has excellent code density.
This is true.
Some of the things he says about PowerPC are true.


On the other hand many of the things which Matthey says about Apollo 68080 are absolutely _NOT_ correct.

If you know the history of the Apollo 68080 CPU, then you know that we started the 68080 development many years ago for the Natami.

For Igor tiny Vampire1 card - we made a super slimmed, super skinny version of it .
We had to drop many features to make the CPU fit in the tiny FPGA of the Vampire1.

That the 68080 needed to be crippled for the Vampire1 is clear to see
if you mind that the NATAMI FPGA for which the Apollo 68080 has designed for
was 7 times bigger than the Vampire1.
Luckily of the Vampire1 only a handful were produced ...

The Vampire2 and Vampire4/Icedrake/Firebird/Manticore/..
of which many thousands are produced : they all use many times bigger FPGAs
and in their bigger FPGA all the 68080 features can be enabled again.

I wonder if Matthey does not understand this history...?
And he thinks that the limited features of the Vampire1 is what the Vampires are now?

Matthey so much what you say about the Apollo 68080 is NOT correct.
Why is this?

Is this because you mix up the Vampire1 "mini-080" with the real Apollo 68080 CPU?

@Gunnar

I refer you to my hypothesis above.

_________________
Doing stupid things for fun...

@fishy_fis

Thread vitrification.

_________________
Doing stupid things for fun...

Hans Quote:

- CALLM - calls M, and reports on 007's latest rogue shenanigans - RTM - tells you politely, to Read The Manual

lol. You are certainly funnier than MEGA_RJ_MICAL, aka Gunnar.

Gunnar Quote:

The Apollo 68080 CPU focuses in adding useful instructions. For example: 68080 offer the best code density of all 68K family CPU members. 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.

The integer instructions above don't match the instructions you gave in the following link.

http://www.apollo-core.com/documentation/AC68080PRM.pdf

CMPIWL, MOVIWL, MOV3, MOVZ and MOVS are not listed in the documentation. Maybe the ColdFire MOV3Q, MVS and MVZ instructions are supported and not documented (the documentation has been horrible and changes more than the ISA). The real Gunnar may have implement MVS, MVZ and MOV3Q in early AC cores and then taken them out. Maybe not MOV3Q though as neither of us were fans of MOV3Q and where it was encoded (A-line encoding could interfere with Mac emulation).

It's entirely possible I'm mixing up AC core versions as they were renamed often as well.

N68050 (Jens original 68k core using the name he chosen)
N68070 (superscalar Natami core)
Phoenix
AC68080 V1-V4

Phoenix may be AC68080 V1. I don't know as the real Gunnar would erase/remove documentation and deliberately be vague about information. He even wiped the forum at least once. The real Gunnar is bad enough without counter productive MEGA_RJ_MICAL deliberately confusing things more. At least the real Gunnar tries to be productive in his special way. Even if the AC68080 core ends up being useless, SAGA with its continued debugging could end up being useful for other projects. The Amiga chipset in an affordable FPGA works today better than emulation of the Amiga chipset.

@matthey


Fact is that you posted a lot of wrong, false misinformation.

As you incorrectly claim that the V2 would have no FPU register,
and you falsely claimed it would not have any hardware FPU instructions.
Which is both wrong.
You can easily see in Sysinfo the FPU
http://www.apollo-core.com/gfx/vampire_sysinfo.gif
And thousands of V2 users happily run Amiga AGA 68060 3d demos using the FPU.


Please answer the question:

Where does your "information" come from?


Is it correct that you NOT own any Vampire yourself?
Neither a V2 nor a V4 System?

And that you never coded on them either?

So all your "information", or "misinformation"
can you please tell us on what is it based on?

@matthey

Quote:

The real Gunnar may have implement MVS, MVZ and MOV3Q in early AC cores and then taken them out.

Please explain us: Why do you invent this untrue stories?


Matthey do you know that you can download GCC compiler for Amiga
from the Apollo-Team, that will use these instruction on 68080?

Also Bebbos 6.5 GCC Cross Compiler will use 68080 instructions like
ADDIWL
CMPIWL
MOVIWL
MOV3
MOVZ
MOVS
MOVE2
CLRQ
DBRAL

When you select 68080 target.



Matthew do you see how silly your story is ?

@Matthey

Are you aware that your "invented" stories are so easy to proof wrong?

Everyone one here can go online and use Bebbos 6.5 Compiler to compile for 68080.
And everyone will see that you stories are fake/nonsense.




You can go here:

https://franke.ms/cex/


You can write some C like:

unsigned int givenumber(int * ptr) {
*ptr=1;
return 0x123;
}


you can select code for 68080
-O2 -fomit-frame-pointer -m68080 -m68881

And you will get this result:

_givenumber:
mov3q.l #1,([4,sp])
moviw.l #291,d0
rts

--





Everyone sees that not only the Apollo 68080 does support these instructions
but that there is not only Assembler but even C-Compilers support for them.




Matthey do you think you can stop inventing stories in the future?

@matthey

Quote:

It's entirely possible I'm mixing up AC core versions as they were renamed often as well.

Do you just admit, that you posting dozens of "wisdom" posts that were total bullshit
and that you bashed since years about the 68080 - without having any clue what you talk about?


Matthey how can we do this better in the future?
Will you continue to talk trash, and then I need to tell the public that you post BS only?
Or can we do this better?

What can we do to get over this?
Maybe you will even start to love the 68080 when you understand it?

@agami

Quote:

agami wrote: @Deniil715 Quote: Deniil715 wrote: Get a life dudes! DO something! We are. This is part of our life. We're doing this. There's more than one way to live.

Good point!
It just feels so unproductive arguing about CPUs in the past
But watching netflix or running in the woods are just as unproductive, and less social, so you're right.
Keep it up! Whatever keeps us off the streets, right

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.