The vampire incompatiblity discussion thread

[grond]

Originally Posted by Chucky

I jumped off the vampire train as they seems to want to go for incompability :-(

What incompatibility? That word seems to have a different meaning to everybody but all the meanings are bad. Yes, there is some software that only runs on the 080 but that doesn't mean it's incompatible. It just means that all other Amigas are incompatible to new capabilities of new hardware which is a natural thing. The same thing happens all the time with 020+ binaries.

[Chucky]

It doesn't behave like any 68k cpu == incompatible. (as it is a bizarr mix of them all)

and now with AGA \o/!. and they add more chipmem etc. /o\ why? well ANY changes introduces more possabilities of stuff not wokring. and I cannot se ANY point with it. but THAT is however off topic here..

[emufan]

there was never a 68060 machine by commodore, but everyone wants one - this was a hack by some 3rd party, remember this ?
about the chip ram - i run my emulation allways with 8MB chip ram - another hack , but not a single app refused to work - regarding that hack.

[Chucky]

the 68060 was still from MOTOROLA.. anyway. they seem to want to break any of those specs I think is static now. for no reason. so. too bad . LOVE the HW but not my path!..
THIS however is out of topic here

[grond]

Originally Posted by Chucky

It doesn't behave like any 68k cpu == incompatible. (as it is a bizarr mix of them all)

According to this the 040 was incompatible as it didn't behave like any 68k CPU before it. And so was the 060 because it didn't behave like any 68k CPU before it.

The 68080 supports all 68k instructions and thus is far more compatible than the 060. Motorola left away several instructions in the 060 because of the constraints on die size and transistor count at the time. Do you really believe they would have chosen to trap those instructions in a later generation 68k processor? That's what I would consider bizarre, to not support all valid 68k instructions without trapping and 680x0.library in place if you can support the instructions in hardware.

and now with AGA \o/!.

Yes, I guess this threatens your investments in an AGA machine but don't you think that even Commodore would have offered this update if it had been feasible at the time? The accelerator board manufacturers surely would have done that.

and they add more chipmem etc. /o\ why?

Because some programs can use that extra chipmem for useful things, e.g. DPaint. Running out of chipmem is one of the most common plagues in daily Amiga use. Don't you know that Commodore prepared the A4000 for 8MB chipmem?

well ANY changes introduces more possabilities of stuff not wokring.

This is just FUD and shows that you don't know much about how an Amiga actually works. A badly coded demo or game cannot bork because of the presence of memory in a place where it doesn't even look for it. It can only break because of memory NOT being there. It cannot break either by running on a CPU that supports more instructions than it expects. A system friendly program doesn't care at all about the memory configuration. It allocates mem and has a problem if it does NOT get the mem it requested. Just because it's different, it's not incompatible. 8 MB of chipmem is a standard setting in WinUAE that never has caused any trouble with software.

[grond]

Originally Posted by Chucky

the 68060 was still from MOTOROLA.

So an AMD processor is not an x86?

[Daedalus]

The problem with the 68060 comparison is that the 680x0 series in general is backwards compatible. I can run a 68000 executable on a 68020, I can run a 68030 executable on a 68040, and I can run a 68040 executable on a 68060. All of this is transparent to the user and the application. Some of the features, e.g. missing FPU opcodes in the 040/060, are handled by software traps, which is slow, but works transparently to the user and the application, meaning on my 060 I can run any executable compiled for an 000, 010, 020, 030 or 040, with or without an FPU. This also means that only a minimum CPU ever has to be checked for; if your CPU is <whatever> or higher, the software will work.

The 68080 changes this, and it means that the rule that higher CPUs are backwards compatible can no longer be made. Not being able to transparently run executables for all previous CPUs in the series breaks the sequence, meaning that incompatibilities that were always downwards only are now facing the other way.

While this isn't a problem for "future" software that can be compiled with the 68080 in mind, it doesn't fix 30+ years of existing software that uses this rule, and likely vastly outnumber any current and future 68080-specific programs. Until I can take any 68040 or 68060 executable and run it on the 68080, it's not fully compatible. This compatibility could come from an updated core or perhaps a 68080.library-style setup, but executables for any previous 68k CPU should just work from the users' point of view.

[grond]

Originally Posted by Daedalus

The 68080 changes this, and it means that the rule that higher CPUs are backwards compatible can no longer be made.

This is WRONG! The 080 supports ALL 68k instructions and thus can run any software compiled for 000, 010, 020, 030, 040 and 060. It is currently an LC-variant, though, meaning that it can't run FPU or MMU software.

Is this really so hard to comprehend? Do you really think that the professional CPU designers making the 080 are too stupid to make their 080 backwards compatible?

[Daedalus]

Nope, I wasn't calling you or anyone else involved stupid, so stop trying to find some reason to be offended and defensive. You know as well as anyone else that in Amiga terms, 68040 and 68060 systems have FPUs and MMUs as standard. Yes, that may be a silly assumption on the part of developers 20 years ago, but barring a very minor and uncommon exception, it holds true, and 040- and 060-specific compiles of software make that assumption. Until they can be patched to work in real-time via replacement 680x0 and mmu libraries, any software that looks for a CPU and finds a 68080 can and often will assume that it has a FPU, MMU or both, and will fall over as a result.

[grond]

Well, then clearly say "it currently hasn't got an FPU nor MMU" instead of creating the impression there was a general backward compatibility problem. The lack of the FPU and MMU is not a problem of the 080 as such but rather of the fact that we are seeing a work in progress. And you should know that there is a load of EC and LC 040s and 060s in the Amiga world. Bad software is just that, bad software.

[AJCopland]

Sorry to continue the derailing but, Gunnar has also made it clear that there won't be a compatible MMU of FPU for the Apollo Core (68080) either. So it's a dead end for existing demos and some software that expects at least an FPU in 040/060.

[Glen M]

Maybe someone should start a new thread to discuss this.

I'm not exactly knowledgeable on Amiga hardware, I know some stuff and I fully admit a little knowledge is a dangerous thing but...

To my mind and with reading the addition of AGA support to none AGA machines the Vampire must essentially be its own full amiga and all you are doing is placing a new computer within your old case leeching power and peripheral signals from the main board. By this I mean that from my understanding it is absolutely impossible to add AGA support to a none AGA machine as the complete chipset and bus pathways are not designed for it. Only way to add them is to completely replace them and after doing this what is left of your original Amiga but an i/o interface for peripherals. Its only a matter of time I think before the Vampire becomes a stand alone piece of hardware and essentially a new minimig.

In many ways the name Vampire is most fitting.

I would also go so far as to suggest that this is a key reason why we haven't seen a vampire for the 1200 as they haven't yet developed a new AGA core, if i am correct the Vampire 1200 will follow very quickly once the AGA upgrade for the 500/600 comes along. Wouldn't it be funny if we found out the FPGA was just running a copy of UAE.

[Daedalus]

Originally Posted by grond

Well, then clearly say "it currently hasn't got an FPU nor MMU" instead of creating the impression there was a general backward compatibility problem.

The problem is that the FPU and MMU are taken as present when it comes to 040s and 060s in Amiga-land. Rightly or wrongly, that is the case and there's a legacy of software running on that assumption that the vampire is incompatible with. Perhaps if it declared to the system as a "68035" or something instead of 68080, it would trip fewer of the old applications up. Petunia, for example, declares as a 68020, even though it supports the full 68040 instruction set.

The lack of the FPU and MMU is not a problem of the 080 as such but rather of the fact that we are seeing a work in progress.

And impressive work it is too. Does this mean that at some point it will have a 680x0-style FPU and MMU?

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

I can think of one such accelerator for the A1200, and it is very rare these days, probably due to the fact that it was not very popular at the time despite being the fastest commercial accelerator ever released. At least part of that lack of popularity is surely down to the incompatibilities it exhibited due to the lack of FPU.

Bad software is just that, bad software.

Indeed. But when it's not going to be fixed as it is 20 year old commercial bad software, it also defaults to being *the* software. The end user doesn't care that FPU software always hits the hardware rather than using the maths libs, they just want their software to work when they double-click it.

[grond]

Originally Posted by Glen M

Maybe someone should start a new thread to discuss this.

I support this motion.

To my mind and with reading the addition of AGA support to none AGA machines the Vampire must essentially be its own full amiga and all you are doing is placing a new computer within your old case leeching power and peripheral signals from the main board.

This is true and I can see that some people don't like it. But I think once you saw a Vampire inside an A600 or A500 in action, you won't mind any more. If it looks like a duck and quawks like a duck... Personally I don't care much about the stand-alone because it will have less of the "look like a duck" appeal. To me the wedge-style Amigas are where my heart is and I don't see me using a tiny PCB inside some micro-ATX or whatever case connected to a PC keyboard even if it runs all my Amiga software. It is also true that the AGA implementation is a priority now because of the stand-alone that's been mostly ready for some time. But you draw the wrong conclusion with regard to the v1200. The v1200 is the hardware that least needs on-board chipset functionality because it is all there already. The v1200 is simply delayed because everything else regarding the hardware is delayed. The stand-alone will come before the v1200, that seems to be set in stone already. But after that there surely will be a v1200, too.

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

That's not how FPGAs work. FPGAs are reconfigurable logic arrays, not general-purpose processors like an x86 processor. That is also why FPGAs are much better in doing stuff in parallel and why Intel is adding FPGAs to their CPUs.

Originally Posted by Daedalus

The problem is that the FPU and MMU are taken as present when it comes to 040s and 060s in Amiga-land. Rightly or wrongly, that is the case and there's a legacy of software running on that assumption that the vampire is incompatible with.

This is true. With an 080 it is a good idea to look for 020 binaries whenever prompted with a choice. The task of choosing software that will run on the 080 in its current state isn't much different from what any 020 or 030 owner with no FPU and MMU has to deal with.

Does this mean that at some point it will have a 680x0-style FPU and MMU?

I have to admit that I don't know for sure. 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. The way I understand it his point of view is that anyone is free to port a soft-FPU solution to the Amiga and he'd happily support it from the core. This would basically mean that there might be some very limited FPU support like fp0-fp7 registers and FMOVE in hardware and all the instructions would be trapped and emulated in software. Gunnar seems to be of the opinion that this would be fast enough to run existing FPU software more or less like on the original hardware. He doesn't seem to consider an FPU that is simply a bit faster than the originals of such high importance to justify the enormous work of implementing it in hardware and testing it thoroughly. As pointed out, there is the possibility of a soft-FPU and if people consider FPU-support that important, they can do it themselves. (He seemed quite pissed off about the subject). For next-gen floating-point heavy software he seems to prefer a completely new unit in the style of some SSE unit as known from the x86 world, i.e. a single-precision vector-FPU able to crunch 8 or 16 single-precision numbers per clock cycle and thus would be hundreds of times faster than any existing 68k FPU. Please note that this latter unit would not be possible in the currently used FPGAs but only in new hardware that has native support for FP-numbers like FP-adders and FP-multipliers. So at the time being this is just a vision or perhaps an indication of where he would like to take the 68k architecture. As for the MMU, the 080 does have an MMU but it is very different from the other 68k MMUs because the 080 has two memory buses while all the other 68k only have one. MMUs have always been incompatible in both directions throughout the various 0x0 generations. MMU software in general is system software and not expected to work on a different generation of 68k processors unless programmed for each generation in parallel. I think there will be a time when the 080-MMU will be opened to programmers and perhaps some features that may be lacking now may be added. This seems to be rather low-priority at the time being.

The end user doesn't care that FPU software always hits the hardware rather than using the maths libs, they just want their software to work when they double-click it.

Yes, you are right but I don't see the big problem. It's precisely the same as for most of the ACA owners, many of the blizzard owners and in general a vast majority of Amigans. FPUs have always been a rather rare resource in the Amiga world. There is some simple software that sets the AttnFlags in exec to report an 020 instead of 040, 060 or whatever it is you want to hide from the software. If the software itself runs some test routines to figure out what processor it is running on, well, there is always the possibility of patching the binary. If you ever hit on such a program, please tell me and I might find the time to patch it.

[Chucky]

According to this the 040 was incompatible as it didn't behave like any 68k CPU before it. And so was the 060 because it didn't behave like any 68k CPU before it.

well as I said: "like ANY 68k". as the 68k are no longer in development. stick to ONE and make it behave like THAT cpu. but the 080 does not behave like any of the 68k avaible.

this is however still out of topic. so this will be last answer in this thread about this. and nees of libs etc. YES. but how hard is it? we now knows how to do it. still to stop have to think about YET ANOTHER cpu. do a replica of one existing and STICK TO IT!

Because some programs can use that extra chipmem for useful things, e.g. DPaint. Running out of chipmem is one of the most common plagues in daily Amiga use. Don't you know that Commodore prepared the A4000 for 8MB chipmem?

yes. they DID put in a jumper for a "push it in" replacement of the LISA. but this however never really happend..

This is just FUD and shows that you don't know much about how an Amiga actually works. A badly coded demo or game cannot bork because of the presence of memory in a place where it doesn't even look for it. It can only break because of memory NOT being there. It cannot break either by running on a CPU that supports more instructions than it expects. A system friendly program doesn't care at all about the memory configuration. It allocates mem and has a problem if it does NOT get the mem it requested. Just because it's different, it's not incompatible. 8 MB of chipmem is a standard setting in WinUAE that never has caused any trouble with software.

I must say: now seing the issue with changing ANY of the chipset specs tells you how little you know how software can work. ok the memorything is the smallest issue. yes. but still. even thinking of the idea to change ANY of the chipsetspecs show that they are not interested in making a compatible machine. do it EXACT as any chosen chipset work and stick to it. (my recomendation is the AGA chipset being the latest one) ANY expansions shuold be reached via RTG, AHI, Warp3D or similiar solution.
as changing the chipsetspecs is anyway pointless as software needs to be rewritten anyway.

Systemfriendly software. yes. but thing is: we are using a really old OBSELETE macine (for fun) with a lot of software doing lot of crazy things, absolutley not within the specs. and lets not introduce more things that can make this break.

more discussion aboit this? please start another thread.. to just. eh keep it on topic?

this thread is about A4000 loosing its possability to show AGA modes in WB, this due to batteryleakage from a neglected machine. (sorry. but that is what i call machines with lekageissues..)

[grond]

Originally Posted by Chucky

well as I said: like ANY 68k as the 68k are no longer in development.

As a matter of fact they are in development. The 080 is the outcome of this development. It is done by people who design POWER and ARM CPUs for a living.

[Chucky]

I do not say that the ppl behind 080 are bad on what they are doing. but the 68k is not in development. and THAT was my point.
however.. EOD just wanted to make it clear what I was pointing out. so in short:

The Motorola 68k series can be considered STATIC.
The Amiga Chipset can be considered STATIC.

Let them be. STATIC. do improvments like addons . reachable via RTG, AHI whatever. as software needs to be rewritten ANYWAY so do not introduce a chanse to break anything as there ARE badly written software out there. As there are anyway NO point of changing specs (due to software not being written anyway)

a new thread anywhere maybe?

[grond]

Well, if you think that the Amiga has to be mummified / remain mummified, the Vampire cards definitely are not for you. The whole project is about making the Amiga enjoy at least some of the general progress in the technical field that it failed to experience due to Commodore's demise.

[Chucky]

Nothing to do with mummified.. as addons would require software to be rewritten anyway. introducing more possible issues by changing HW registers etc is just plain stupid as you still have to rewrite stuff..

080 will be the new ppc.. a few software.. nothing more. love the HW but implementation.... :-/

[grond]

Originally Posted by Chucky

by changing HW registers

Another thing you make up on the fly...

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

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.

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)