The vampire incompatiblity discussion thread

[Chucky]

Another thing you make up on the fly...

No hardware registers are changed, new registers for new functionality are being added.

Adding size of what the chip accepts IS a change of HW registers. there can be software that thinks tha the chipset masks away crapdata (ok we are talking about MICROSOFT bad type of coding here....)

For decades the x86 world was scorned for A20 gates and similar pointless legacy stuff. And now every new feature needs to be crippled or left away because of fear of some badly written demo breaking?

Your point of view boils down to that Commodore should never have made ECS let alone AGA because some shit software couldn't deal with the changes. And the compatibility level was much worse than what we are seeing now with the enhancements that the Vampire brings.

no. .that was WHEN the Amiga WAS in development.. but. now it isn't so I think that the chipset should be considered as STATIC. now we can try to squeeze every last bit of thibgs out of it. (this includes using bugs!)
just like on the C64.

Quite to the contrary the 080 even improves compatibility in many places beyond what we experience with 040 and 060 equipped Amigas due to some clever features:

- blitter serialised with the CPU such that the blitter cannot be overrun by too fast a CPU (most frequent problem of shitty demos and games)
- turtle mode (throttle CPU speed to roughly A1200 level)
- transparent caches (badly written self-modifying code doesn't break as it does on 040 and 060)

No ANY changes to how the CPU behaves makes it incompatible to ANY 68k CPU. as neither the 68k series or the Amiga chipset have been in development for a long time now. so now we use the Amiga as we have somewhat of strange love to what it offered. improvements are nice yes. but as ALL type of improvements WILL require new software to be rewritten (with a exception of most increasing of chipmemsize that would work for most stuff unless coder have made a strange maskting or so.. should be VERY uncommon)

however even by changing how much ram it can handle (welcome or not!) is a sign that there will be more stuff coming, especially when they did the "68080" with a mix of different cpus. so code that might check the cpu by doing "does this instruction excist but not this. ahh 060" might get confused meaning.. incompability.




So basically for a FPGA replacement (as the Vampire) they shold simulate (note that I do not use the word emulate.. but as it is not done from an EXACT blueprint of the real stuff it can only be a simulation) ONE motorola CPU (I would recomend the 060 as it is the newest.. EVEN if it lacks instrucions needed to be fixed by libraries etc) why this? well as then software doing stuff "knows" what to excpect.

and then a chipset (again AGA as it is the newest) and do it ***EXACT*** even including bugs etc. then all software working on that setup WILL still work. we all remember what issues we had when there was a new cpu/chipset. lets not introduce more stuff.
(my Vampire crashes as hell when I got 68040/68060.libs installed.. so that is just a sign that we have a new behaviour...)

new stuff? HELL YES! why not. but as this DO require new software to be rewritten.. why not do it as RTG (as SAGA is now), AHI or whatever. then software ALREADY can use it. it will work on future OTHER hardware and does not require one single chipsetregister to be changed. minimizing the risk of breaking compability!.

[grond]

Originally Posted by Chucky

Adding size of what the chip accepts IS a change of HW registers. there can be software that thinks tha the chipset masks away crapdata (ok we are talking about MICROSOFT bad type of coding here....)

This is entirely hypothetic. Setting chipmem to 8MB in WinUAE has not revealed any such problem in many years. There is no such software and there is no technical reason for writing a program like this. There was a tradition in increasing chipmem over Amiga generations so not even the most stupied c0d3r would have done something so stupid. In fact, you could use the same logic against having more fastmem than 16 MB (=24 bit addresses). I have not heard about any software that breaks with more than 16 MB fastmem in the system, either. This problem only exists in your imagination.

no. .that was WHEN the Amiga WAS in development.. but. now it isn't so I think that the chipset should be considered as STATIC.

Well, then here's the news, it is in development again. Not by some bogus legal entity that claims to be Commodore's heir but by some technically very apt hobbyists.

now we can try to squeeze every last bit of thibgs out of it. (this includes using bugs!) just like on the C64.

Well, nobody forbids you to do that if that's what you like, a mummified Amiga running the same lame demo effects all the time.

No ANY changes to how the CPU behaves makes it incompatible to ANY 68k CPU.

I have refuted this using technical arguments, you just contradict. You clearly have no clue how Amigas work because you fail to understand that programs that depend on cycle-exact behaviour are a thing of the C=64 but never were necessary in an Amiga which has always had lots of completely differently behaving types of 68k CPUs. No software will break because a bitfield operation now only takes 1 or 2 clock cycles instead of 20 or 30.

however even by changing how much ram it can handle (welcome or not!) is a sign that there will be more stuff coming, especially when they did the "68080" with a mix of different cpus. so code that might check the cpu by doing "does this instruction excist but not this. ahh 060" might get confused meaning.. incompability.

Show me such a program. And not one you just write now to break on purpose. Interestingly usually only people who do NOT have a Vampire talk about its assumed incompatibility, rarely the people who do own one.

they shold simulate ONE motorola CPU (I would recomend the 060 as it is the newest..

Your recommendation shows how little you know about the 68k line of CPUs. The 060 is the most limited CPU of all the 68k. In any case cycle-exact reimplementation still remains a totally unnecessarily limiting approach because higher clock rates than what existed back in the day could just as well confuse shitty programs. Hypothetically speaking, i.e. using your logic.

we all remember what issues we had when there was a new cpu/chipset.

Yes. This taught many programmers a lesson. It may come as a surprise to you but there don't seem to be any problems associated with adding new registers to addresses where no registers had been. Again your preference of not changing anything because it might theoretically break something shitty program just shows that you want a mummified Amiga. And then you recommend immitating an 060, the processor that causes the highest number of incompatibilities...

my Vampire crashes as hell when I got 68040/68060.libs installed.

I'd be surprised if it did. What Vampire is this supposed to be? What core version? This doesn't seem to make sense to me. The 040/060 libraries simply don't get called because there is no missing instruction that would cause a trap to the library. The libraries simply are a waste of memory. Anyway, incompatibility by not having a library installed seems to be a more serious problem (i.e. using an 060) to me than killing a system by installing a library on a system it isn't designed for.

why not do it as RTG (as SAGA is now), AHI or whatever. then software ALREADY can use it.

Are you sure you have actually used a Vampire v2? The RTG is there and any RTG program can use it. This doesn't depend on the RTG registers being in the Amiga register address range or not. The P96 driver deals with the registers and doesn't care in the least where they are located. It is a cool thing, though, to be able to program the chunky display with the copper. In any case, the Vampire may not be the right thing for everybody. It is not designed to be. It is designed to push the Amiga beyond where it got stuck in 1994. If you are the "vanilla A500/A1200" demo guy or just want to play the games you played 25 years ago, the Vampire is not for you (and an 040/060 isn't either, an 020 or 030 would clearly be a better and more compatible choice than that). But there is no need for accusing the Vampire of being incompatible when it is not.

[Chucky]

This is entirely hypothetic...

Yes it is VERY Hypothetic yes. as I told in the other thread that the only thing that actually would work is increasing the size it can handle giving a example of really bad code that would break it (like the bad code microsoft used in microsoft basic making it crash on 32bit addressmodecapable cpus)
but just the IDEA of breaking that, including the actual fact breaking motorola specs shows what plans are.. without showing the plans.

Well, then here's the news, it is in development again. Not by some bogus legal entity that claims to be Commodore's heir but
by some technically very apt hobbyists.

well give me ONE reason why they should change things that could introduce new problems? ONE single reason?

Well, nobody forbids you to do that if that's what you like, a mummified Amiga running the same lame demo effects all the time.

You clearly have not seem what is on the C64 now.

I have refuted this using technical arguments, you just contradict. You clearly have no clue how Amigas work because you fail to understand that programs
that depend on cycle-exact behaviour are a thing of the C=64 but never were necessary in an Amiga which has always had lots of completely differently
behaving types of 68k CPUs. No software will break because a bitfield operation now only takes 1 or 2 clock cycles instead of 20 or 30.

A tip: do not tell people they do not know how stuff works, and then totally fail to understand that Amigacoders actually sometimes DOES count cycles, even try to change the order they put instructions to optimize as much as possible to do demoeffects etc.
this about the 080 have been discussed in demosceneforums for a while. and most of them simply skipped the 080 with this as one big reason.

Your recommendation shows how little you know about the 68k line of CPUs.

I'd be surprised if it did. What Vampire is this supposed to be? What core version?

I have a Vampire for the 500 a early one, the non Plus version. (yes one of the few who actually got one)
I LOOVE the hardware it is totally awesome.. but its implementation made me go meh.
abd reading forums, people have crashes with 3.9 etc unless they remove the 68040/060 libs. (and other patches aswell as the vampire itself needs to patch those libs to work so to get fastmem etc.. you need to remove some patches)

I brought it to the Compusphere demoparty here in Sweden, 25th-27th November 2016 so that core what was avaible by then. we did some tests. but well. demos that worked with RTG etc, most crashed (well. no FPU so no surprised)

anyway. most ppl there was thinking: ok it can do doom and performancetests, cool but then?
I will sell it to a friend. a little sad as it is a lovely hardwareproject, but for sure not my cup of tea due to this.. sad actually.

Are you sure you have actually used a Vampire v2? The RTG is there and any RTG program can use it.

read what I wrote: "why not do it as RTG (as SAGA is now)"

so YES.. it is RTG.. but IU have heard that they plan do do AGA with improvements just like they did the 68k "with improvements" and this is totallyt FAIL!

It is designed to push the Amiga beyond where it got stuck in 1994.

still that is NO reason whatsoever to change ANY of the specs that can be considered Static.. not one single reason.

anyway.. going OUT of the specs it simulates to be (and this is important as the word "emulate" appetnlty is VERY VERY tabu) then it should be JUST LIKE one machine it want to be.. and if you want to do extras, you do extras just LIKE on that macihne. or you simple will not be compatible.

do not get me wrong saying that hte vampire etc is crap.. it isn't it is a really GREAT hardware. and would be EXACT what we needed.. if they didn't screw it up with this thing.

what I think we need is a way to replace our old hardware so we can use the stuff we like.. but doing it exact so it replaces it.

and as the amiga is such a womderful machine: improvements is possible other ways without breaking stuff:

RTG (P96) for graphics (like SAGA is now! yes!, so they only need to simlulate the AGA chipset older machines can run AGA stuff.. cool!)

AHI (or similiar) gives audiosupport. so no need to do any chipsetimprovements there aswell..

both of this will also remove the need for chipmem!

Warp3D for 3D graphics...

so there are possabilities without doing stuff that potentially will break things.

remember TECHINCALLY AGA would never ever break things either.. but it did.

the way C64 and Amigaguys usually coded back then was banging on the metal. and doing that.. you are in a riscy zone.

[grond]

Originally Posted by Chucky

but just the IDEA of breaking that, including the actual fact breaking motorola specs shows what plans are.. without showing the plans.

Then you cannot make any improvements to the platform at all because any change (and improvements require changes) could theoretically break some software.

well give me ONE reason why they should change things that could introduce new problems? ONE single reason?

Because the chance of a problem occurring and the significance of the problem is outweighed by the improved capabilities.

You clearly have not seem what is on the C64 now.

I know recent C64 demos and I know how most of them are done. Giant move-lists and code where the raster position registers form part of the instructions executed by the CPU. Visually impressive at first sight but technically boring when you know how it works.

A tip: do not tell people they do not know how stuff works, and then totally fail to understand that Amigacoders actually sometimes DOES count cycles, even try to change the order they put instructions to optimize as much as possible to do demoeffects etc.

I actually did quite a lot of cycle counting in my life. It's a totally pointless pasttime and surely not what would keep me from coding for a superior 68k platform. I'm bored to death by chunky to planar conversion, precalculated effects, giant tables and planar overlays.

this about the 080 have been discussed in demosceneforums for a while. and most of them simply skipped the 080 with this as one big reason.

That's not the gist of what I read. Most of the l337 c0d3rs reject the 080 because it is not a recognised demo category which are usually vanilla A500 or 1260 or because they consider redoing 15 to 20 years old PC-effects on Amiga lame. I can understand that. Incompatibility was not given as a reason in what I read.

abd reading forums, people have crashes with 3.9 etc unless they remove the 68040/060 libs. (and other patches aswell as the vampire itself needs to patch those libs to work so to get fastmem etc.. you need to remove some patches)

And that is a problem? When did patching and hand-selecting libraries in an Amiga installation become a problem?

I brought it to the Compusphere demoparty here in Sweden, 25th-27th November 2016 so that core what was avaible by then.

So we are talking about a core that is at least half a year old.

we did some tests. but well. demos that worked with RTG etc, most crashed (well. no FPU so no surprised)

Yes, no FPU. We all know that by now.

most ppl there was thinking: ok it can do doom and performancetests, cool but then?

Exploration, exploration. There is more and more new software for it, people have started working more on AROS because of it and generally it is far superior to any 000, 020 or LC30 out there. Lots of people are happy with those, so why not use a processor that is many times faster than that and on top has RTG? Why "but then"? Use it as you would use any Amiga.

so YES.. it is RTG.. but IU have heard that they plan do do AGA with improvements just like they did the 68k with improvements and this is totallyt FAIL!

Sure. SAGA now has 16 bit stereo sound on top of the normal Amiga sound, sprites with extended palettes (I'm not too hot about those) and probably some more I have forgot about. Furthermore SAGA makes chipmem accesses a hundred times faster than on AGA machines. Surely, this is nothing for computer-necrophiles but for people who are happy to see some technical progress.

anyway.. going OUT of the specs it simulates to be (and this is important as the word "emulate" appetnlty is VERY VERY tabu) then it should be JUST LIKE one machine it want to be.. and if you want to do extras, you do extras just LIKE on that macihne. or you simple will not be compatible.

You sound very much like people who separate the world into believers and heathen. The Vampire is a new Amiga which is able to run most of the existing Amiga software and some new software for which all previous Amigas are not powerful enough. This is what the project is about, not about reproducing what was already there. If you don't like this, it is not for you. The existence of anything you don't consider true to the faith doesn't have to bother you and does not entitle you to attach wrong attributes such as "incompatible" to it. It's not incompatible because it might break some program. It is compatible if it does run the vast majority of programs which it happens to do just fine.

and would be EXACT what we needed.. if they didn't screw it up with this thing.

What you want is not just "one thing", it would be an entirely different project and simply won't happen because a boring replication of what already exists is no motivation to the people who do all this work.

what I think we need is a way to replace our old hardware so we can use the stuff we like.. but doing it exact so it replaces it.

Well, then do that.

and as the amiga is such a womderful machine: improvements is possible other ways without breaking stuff: RTG (P96) for graphics (like SAGA is now! yes!, so they only need to simlulate the AGA chipset older machines can run AGA stuff.. cool!)

Why limit the implementation? Why not have the copper control chunky screens just as well as planar screens? Why not have a combined screen of hires 24bit colours (e.g. for game stats) and lores 8 bit colours (e.g. for game action)? You clearly fail to see what makes an Amiga more interesting than a PC.

AHI (or similiar) gives audiosupport. so no need to do any chipsetimprovements there aswell.

Both P96 and AHI care nothing about HOW the new capabilities are implemented. AHI can support 16 bit SAGA chipset sound just as well as some soundcard. And so does P96 which does not care at all about where the hardware registers are located it needs to access in order to set up a screen.

so there are possabilities without doing stuff that potentially will break things.

And you can live without potentially dying. Just avoid anything dangerous.

remember TECHINCALLY AGA would never ever break things either.. but it did.

And do we care now?

the way C64 and Amigaguys usually coded back then was banging on the metal. and doing that.. you are in a riscy zone.

Yes, and the bare metal coders should have learned their lesson with the appearance of KS1.2, fastmem extensions and ECS, i.e. 30 years ago.

[wawa]

Originally Posted by grond

what I think we need is a way to replace our old hardware so we can use the stuff we like.. but doing it exact so it replaces it.

that exactly what mikej principles are. you should get fpgaarcade instead of ranting here about a project that is obviously outside your scope.

honestly, vampire/apollo has never been advetised as a cycle exact replica. it was supposed to be an accelerator, which is exactly the opposite.

this attitude really fits within what im confronted with in all the aros topics. some people simply want to keep a cake and eat it. they want an updated system that works exactly like the original. as if just sticking to the original was something wrong.

[kolla]

This is great - we very much need a place to slash and bash the Apollo Core without alpha nerd Gunnar and his groupies of subordinate geeks editing and removing all critics.

[Chucky]

no I do not want slash and bash too much. anyway the Hardware is absolutley stunning.. but yes I do have big issies with 080 etc.

there is too much to quote here now. but nah. about demoscene. incompability is a big reason why the demoscene more or less say "mehh" I have heard people even thinking "lets detect 080 and just exit" joke or not.. interesting still..

and no. implementing extras like a "zorro card" or so would not make the machine incompatible. but the talk about implementing new chipset stuff WILL.

chunky copper etc etc. well. WHY? it would not work with ANY existing software anyway. so why not do someting else.. something that does NOT interfear with current chipset as the software needs to be written anyway. so why not do it "correct", for the programmer there will be NO difference. for compability it will be huge.

and do we care now that AGA wasn't supposed to break things? well YES as it sure DID break things. more changes like this will break even more. THAT is my point.

now people have patched and hacked most stuff so it works.. changing even more will create the need for even more patching and hacking and that is what I want to avoid.


I think it is sad that SO much effort is put into this great hardware and making it closed sourced and basically proprietary... (the cpu part. that is) anyway.. the software will still be needed to be coded, and I guess there will be just like the PPC. very few programs.

and implementing new chipset stuff, well you must make the programmers implement it. and by pissing off the demoscene as one example is with strange ideas of MMX instructions etc. ok the IDEA to implement the removed commands is good, but the result.. nah. on a platform like the PC today it would be possible as it is basically (not really true.. but close enough) are impossible to write "baremetal" programs, but on out old platforms where it more or less is how things are made it is different.

I read that the Vampire is "the most compatible accelerator ever" when it basically isn't.

then there are different views of "compatible" either like "all software runs.. even badly written crap" or "compatible to the specs of machine XXx"

and for me "compatible" is to the specs of one machine...

[wawa]

Originally Posted by Chucky

and for me "compatible" is to the specs of one machine...

sigh.. then get that "one machine" instead of looking for some substitute of it. what it is stopping you?

[idrougge]

AFAIK, the Vampire/Apollo/SAGA doesn't break things by adding things (except when they started adding registers in the space already occupied by the Indivision scandoubler). It's totally possible to add new modes without breaking the old ones.

What really breaks compatibility is having a processor that identifies itself as something which it doesn't implement. If it had a full 68020 implementation and made itself out to be a 68020, there would be no (grave) problems.

Refusing to support any known FPU or MMU breaks a lot of things, especially things needed by those developers who could have used the Vampire to develop new software.

[wawa]

Refusing to support any known FPU or MMU breaks a lot of things, especially things needed by those developers who could have used the Vampire to develop new software.

do you know for fact that apollo identifies itself as 040 with an fpu? according to what i read on aros dev ml pcr register has a bit for availability of an fpu, so maybe this bit is not set with apollo?

[Don_Adan]

Originally Posted by idrougge

Refusing to support any known FPU or MMU breaks a lot of things, especially things needed by those developers who could have used the Vampire to develop new software.

Right, this is very stupid idea. For all existed 68k programs (for all 68k platforms) Apollo Core will be equivalent of very fast 68EC040 CPU only. Seems that 68EC080 is correct name for current version of Apollo CPU. Full 68080 must have fully compatible 68040 MMU and 68040 FPU as minimum. Having fully compatible 68882 FPU is the best option for Apollo Core. Especially, if Gunnar target is not only Amiga market. Noone will be recompiled thousends of existed 68k software, which used 68040 MMU and FPU. For many old 68k programs dont exist source code or sources are unavailable. Of course Apollo Core can have enhanced MMU and FPU, called f.e AMMU and AFPU, but both units for new programs or new program versions only. Incompatible 68k core is very poor idea, which caused only many problems for 68k users. And is not good choice especially for ASIC version.

[grelbfarlk]

Originally Posted by Don_Adan

Right, this is very stupid idea. For all existed 68k programs (for all 68k platforms) Apollo Core will be equivalent of very fast 68EC040 CPU only. Seems that 68EC080 is correct name for current version of Apollo CPU. Full 68080 must have fully compatible 68040 MMU and 68040 FPU as minimum. Having fully compatible 68882 FPU is the best option for Apollo Core. Especially, if Gunnar target is not only Amiga market. Noone will be recompiled thousends of existed 68k software, which used 68040 MMU and FPU. For many old 68k programs dont exist source code or sources are unavailable. Of course Apollo Core can have enhanced MMU and FPU, called f.e AMMU and AFPU, but both units for new programs or new program versions only. Incompatible 68k core is very poor idea, which caused only many problems for 68k users. And is not good choice especially for ASIC version.

But weren't things so much better back in the day where we had an expansion board and one application to go with it? When we had for RTG options EGS, Prodev, Cybergraphics and Picasso96? Think of how much fun it was for someone to write Opalvision and EGS and Graffiti drivers for one application just to put pixels from a program into a framebuffer?

Or a sound card that had just one mixing and compositing application and a single program to play the output?

All this gibberish about hardware agnosticism is so 2000s and we remember the excesses of that era to show us what a disaster it was. It's so much better to research for days or weeks to find out what dongle worked with which gizmo in hopes that some day you might get your application to launch and move some ones and zeros (or occasionally a two if you had those ULTRA AWESOME INSTRUCTIONS) around. As the saying goes the best part about platforms is that there are so many of them, lets just as Amigans concentrate on inventing new platforms, all the time.

[meynaf]

Originally Posted by kolla

This is great - we very much need a place to slash and bash the Apollo Core without alpha nerd Gunnar and his groupies of subordinate geeks editing and removing all critics.

I'm still wondering if this is sarcastic or not...

Originally Posted by idrougge

What really breaks compatibility is having a processor that identifies itself as something which it doesn't implement. If it had a full 68020 implementation and made itself out to be a 68020, there would be no (grave) problems.

Indeed. And actually it is not even 68010 compatible, as it's not fully virtualizable anymore. Not a problem for Amiga, but it might be troublesome if it wants to invade other lands.

Originally Posted by idrougge

Refusing to support any known FPU or MMU breaks a lot of things, especially things needed by those developers who could have used the Vampire to develop new software.

For me the lack of an usable MMU makes it unsuitable for development.

Originally Posted by wawa

do you know for fact that apollo identifies itself as 040 with an fpu? according to what i read on aros dev ml pcr register has a bit for availability of an fpu, so maybe this bit is not set with apollo?

But not all software is well-behaved and sometimes programs make shortcuts (aka wrong assuptions).
How many 68060 demos accept running without aborting with an error message and then crash because lack of fpu ?

Originally Posted by Don_Adan

Right, this is very stupid idea. For all existed 68k programs (for all 68k platforms) Apollo Core will be equivalent of very fast 68EC040 CPU only. Seems that 68EC080 is correct name for current version of Apollo CPU. Full 68080 must have fully compatible 68040 MMU and 68040 FPU as minimum. Having fully compatible 68882 FPU is the best option for Apollo Core. Especially, if Gunnar target is not only Amiga market. Noone will be recompiled thousends of existed 68k software, which used 68040 MMU and FPU. For many old 68k programs dont exist source code or sources are unavailable. Of course Apollo Core can have enhanced MMU and FPU, called f.e AMMU and AFPU, but both units for new programs or new program versions only. Incompatible 68k core is very poor idea, which caused only many problems for 68k users. And is not good choice especially for ASIC version.

+1

In addition, back in the day even Coldfire compatibillity was advertised and now this is dead as well. There would have been useful instructions to add (mvz,mvs) but the door is now closed because the encoding space got used for things i'd politely qualify as not very useful.

Aside of compatibility problems there are other choices that are a little bit short sighted. Adding performance counters may seem good but it exposes the inner workings of the cpu and adds extra legacy. Same story for the currently undocumented mmu which, if i'm not mistaken, exposes memory interface details to the programming model. Additions such as ammx are difficult to use, obsoleted by sse or gpus, and make the 68k look like x86 (yuck).

But... should we expect people designing POWER and ARM cpus for a living, to fully understand the 68k's philosophy ?

[grond]

Originally Posted by idrougge

What really breaks compatibility is having a processor that identifies itself as something which it doesn't implement. If it had a full 68020 implementation and made itself out to be a 68020, there would be no (grave) problems.

The 080 is a full 020 implementation, there is nothing missing. And no 68k CPU identifies itself, they get identified by software which may do so correctly or incorrectly. You can easily overwrite exec's CPU flags with something you may consider more fitting but some programs will still misbehave. And there is also some software that will refuse to run on something it believes to be a meagre 020 disregarding the fact that it is a 500+ MHz equivalent of an 020. The problem is the software which needs patching, not the processor. If you don't want such problems, patching of programs, the 080 may not be for you. Just use what you have always been using (but better no 060 which has far more such problems than the 080).

[grond]

Originally Posted by meynaf

Indeed. And actually it is not even 68010 compatible, as it's not fully virtualizable anymore.

Care to explain? To my knowledge the 010 cannot be virtualized (if we are using the same words for the same thing).

In addition, back in the day even Coldfire compatibillity was advertised and now this is dead as well.

You are confusing the Apollo Core with the 080 in the Vampire. If you want to have a Coldfire compatible 080 variant, just ask Gunnar for the price.

There would have been useful instructions to add (mvz,mvs) but the door is now closed because the encoding space got used for things i'd politely qualify as not very useful.

MVZ and MVS are of very little use. They merely sign-extend a value that gets loaded to register size. This is commonly done using one of the EXTend instructions of the 68k. The 080 recognises all combinations of a MOVE and an EXT instruction and executes them internally as a MVZ or MVZ instruction equivalent in a single instruction taking one clock cycle in one pipeline. Same effect, no encoding space wasted. A good example how you are apparently not qualified to judge the 080 because you lack the required knowledge.

Aside of compatibility problems there are other choices that are a little bit short sighted.

Says the myopic MVS-man...

Adding performance counters may seem good but it exposes the inner workings of the cpu and adds extra legacy.

I don't understand the criticism in "it exposes the inner workings of the CPU" because that's precisely what they are there for. And it takes less than a minute to remove this feature from the core. It is a feature meant exlusively for developers testing code. It would obviously be a bad idea to use the clock cycle registers in release code.

Same story for the currently undocumented mmu which, if i'm not mistaken, exposes memory interface details to the programming model.

"undocumented" and assumptions don't go together well. Let's not discuss about undocumented stuff because clearly it is not open for programmers.

Additions such as ammx are difficult to use, obsoleted by sse or gpus, and make the 68k look like x86 (yuck).

AMMX may seem difficult to use to you, I have seen very capable programmers make great use of it. As for being "obsolete", this is a funny accusation to make in a discussion about a new addition to the 68k family. An MMX-type set of instructions is a very sensible extension for a processor in the 100 MHz range. An SSE-type extension is simply not viable in the consumer class FPGAs but may be added in a later core generation running on a higher-spec FPGA.

But... should we expect people designing POWER and ARM cpus for a living, to fully understand the 68k's philosophy ?

Apart from the fact that these people know everything about the 68k family of processors, contrary to you they understand that processors are not about "philosophy" or "believes".

[kolla]

Originally Posted by grond

And you should know that there is a load of EC and LC 040s and 060s in the Amiga world.

There is? News for me. The only ones I know of are those who overclock their 060s to the point where they start failing.

[kolla]

Originally Posted by Glen M

Wouldn't it be funny if we found out the FPGA was just running a copy of UAE.

FPGAs do not "run" software.

[meynaf]

Originally Posted by grond

Care to explain? To my knowledge the 010 cannot be virtualized (if we are using the same words for the same thing).

The 68010 is fully virtualizable and if you think it's not, tell why. For me it meets the virtualization criterions.

Originally Posted by grond

You are confusing the Apollo Core with the 080 in the Vampire.

What ? Aren't they the same thing ? If not, how do they differ ? Is this relevant anyway ?

Originally Posted by grond

If you want to have a Coldfire compatible 080 variant, just ask Gunnar for the price.

Yes, make a variant mess like in ARM world :/
Anyway, can't get a Coldfire compatible 080 variant, as it can't be done. It's either 080 compatible or Coldfire compatible, as they do conflict.

Originally Posted by grond

MVZ and MVS are of very little use. They merely sign-extend a value that gets loaded to register size. This is commonly done using one of the EXTend instructions of the 68k. The 080 recognises all combinations of a MOVE and an EXT instruction and executes them internally as a MVZ or MVZ instruction equivalent in a single instruction taking one clock cycle in one pipeline. Same effect, no encoding space wasted.

These are for code density and ease of programming, not for speed. But you must be a programmer to be able to understand that

Originally Posted by grond

A good example how you are apparently not qualified to judge the 080 because you lack the required knowledge.

Aside of the fact you're getting insulting again, what is that knowledge i'm supposed to not have ? Just tell me what informations i might be missing.

Originally Posted by grond

Says the myopic MVS-man...

Gunnar's hound wanting to bite, huh ? Why are you so aggressive ?

Originally Posted by grond

I don't understand the criticism in "it exposes the inner workings of the CPU" because that's precisely what they are there for. And it takes less than a minute to remove this feature from the core. It is a feature meant exlusively for developers testing code. It would obviously be a bad idea to use the clock cycle registers in release code.

It can be there for testing the cpu and removed in public core releases, i'd see no problem with that. But is it ?

Originally Posted by grond

"undocumented" and assumptions don't go together well. Let's not discuss about undocumented stuff because clearly it is not open for programmers.

If it's not open for programmers then it shouldn't be there at first place or at least, not there for public releases.

Originally Posted by grond

AMMX may seem difficult to use to you, I have seen very capable programmers make great use of it. As for being "obsolete", this is a funny accusation to make in a discussion about a new addition to the 68k family.

What great use ? There is ONE program actually using AMMX and it took MONTHS to do for a skilled programmer, all this for a modest gain - provided there is one at all !
And yes it's obsolete. Adding a steam engine to a horse-powered carriage does not make the steam engine less archaic.

Originally Posted by grond

An MMX-type set of instructions is a very sensible extension for a processor in the 100 MHz range.
An SSE-type extension is simply not viable in the consumer class FPGAs but may be added in a later core generation running on a higher-spec FPGA.

Yes, purely implementation-driven decision that will later turn into legacy.

Originally Posted by grond

Apart from the fact that these people know everything about the 68k family of processors, contrary to you they understand that processors are not about "philosophy" or "believes".

The 68k cpu has some design philosophy - nothing to do with "believes" - and you've just proven it's a concept you and all apollo team are unable to grasp.

Originally Posted by grond

The 080 is a full 020 implementation, there is nothing missing.

Does it have CALLM/RTM ? Does it have second trace bit ? Does it have MSP register and full master mode ? Does it implement 020 stack frame ?

[kolla]

Originally Posted by grond

There has been a lot of talk and lots of misunderstandings but I'm not sure I understand Gunnar's recent stance with regard to the FPU.

It is the greatest FPU, the best! Software could benefit bigly!

[KONEY]

I have used a Vampire for one year now and I can't even think of a single something which hasn't worked!

It's important to point out that requiring an FPU is a result of how a binary is compiled and not of how it is (badly) written. So if you try an FPU version of a program it simply won't start (but not break!) as it would on a vanilla A1200, for example.

The user must choose the right executable, like it's always been in Amigaland.