The vampire incompatiblity discussion thread

[Chucky]

Originally Posted by kev

yes i know people decapping 68060 as we speak with FPU

me too. rev5 and rev6 (rev5 is a better option for decapping.. but rev6 "for fun")

[Chucky]

Jens cards no FPU.. well. that is "semitrue" as the "latest" version can have a FPU. (I have one soldered on the 1233 I test machines with to check if timingfix is needed..

Anyway. FPU in a 020/030 solution is kind of pointless. while many programs written for 040/060 more or less expects the fpu to be present. (and is a reason why so many 040/060 programs crash on the vampire (especially demos)

[matthey]

@kev and Chucky
Who is doing the decapping? What is the purpose?

1) Preservation of history
2) Recreating a synthesizable 68060 to use as is in an FPGA
3) Use the 68060 design to create an enhanced and more modern 68k CPU

@all
Gunnar's philosophy is certainly different than mine which is why I left his "team". His philosophy includes...

o only do what gives maximum theoretical performance
o add more registers, more registers, share registers
o hyper-optimize for an FPGA and even particular kind of FPGA
o don't plan for a path forward into the future
o work free for me while I make all the decisions

[kev]

Originally Posted by matthey

@kev and Chucky
Who is doing the decapping? What is the purpose?

1) Preservation of history
2) Recreating a synthesizable 68060 to use as is in an FPGA
3) Use the 68060 design to create an enhanced and more modern 68k CPU

@all
Gunnar's philosophy is certainly different than mine which is why I left his "team". His philosophy includes...

o only do what gives maximum theoretical performance
o add more registers, more registers, share registers
o hyper-optimize for an FPGA and even particular kind of FPGA
o don't plan for a path forward into the future
o work free for me while I make all the decisions

option 2 at the moment and hope for 3 after

[matthey]

Originally Posted by kev

option 2 at the moment and hope for 3 after

Is there anywhere where I can read up on progress? Any contact info?

I worked on an enhanced 68k ISA before someone decided they were going to make all the "team" decisions for the Apollo Core. I would like to connect with sane people who would like to enhance the 68k.

[kev]

Originally Posted by matthey

Is there anywhere where I can read up on progress? Any contact info?

I worked on an enhanced 68k ISA before someone decided they were going to make all the "team" decisions for the Apollo Core. I would like to connect with sane people who would like to enhance the 68k.

just a friend of mine who is doing this on his free time but when i see him ill let him know im sure thats not a issue help is always welcomed

[Chucky]

Simply option 2.

to make a cycleexact fpga version of the 68060.
if option 3. well. then you have the "080" and my feared incompability.

so.. no. just a exact implementation of the 060 in FPGA. simple.

[matthey]

Originally Posted by Chucky

Simply option 2.

to make a cycleexact fpga version of the 68060.
if option 3. well. then you have the "080" and my feared incompatibility.

so.. no. just a exact implementation of the 060 in FPGA. simple.

First off, a cycle exact implementation of the 68060 in an affordable FPGA may not be possible. Some things are probably slower in an affordable FPGA than even a decades old CPU. Parts of the CPU may need reworking. Second, there is no need for a cycle exact 68k CPU on the Amiga. Each new 68k CPU was not cycle exact with the last so why does a new 68k CPU need to be cycle exact when Motorola didn't think it was necessary? Third, other than bugs and poor ISA decisions, the Apollo Core is more compatible with earlier 68k CPUs than the 68060.

[kev]

matthey i sent you a link to his webpage check your email

[meynaf]

Originally Posted by matthey

I worked on an enhanced 68k ISA before someone decided they were going to make all the "team" decisions for the Apollo Core. I would like to connect with sane people who would like to enhance the 68k.

I have my own advanced 68k ISA as well. Enhancing the (already great but sometimes insufficient) asm programming flexibility is my goal - count me in if this makes sense to you.

Originally Posted by Chucky

if option 3. well. then you have the "080" and my feared incompability.

Incompatibility problems of the "080" do not come from making the cpu faster, nor do they come from adding new instructions (even though they were added any old how).
Aside of possible bugs they come from :
- being identified as some 68k cpu which is expected to have mmu+fpu, while they're not there
- adding new registers which forces exec patches to save them on context switches
- stealing opcode space of callm/rtm
- resurrecting old 68000 move sr bug without being identified as 68000

[wawa]

Originally Posted by Chucky

just a exact implementation of the 060 in FPGA. simple.

why dont you go out and simply buy yourself a 060 instead of complaining and demanding on forums that someone develops a drop in replacement in fpga just for you?

[wawa]

@ matthey, kev, meynaf

good luck with your plan. even if its probably lightyears behind apollo core, but alternatives would be very welcome. especially open ones, which i do not even dare to expect.

[kolla]

Originally Posted by wawa

why dont you go out and simply buy yourself a 060 instead of complaining and demanding on forums that someone develops a drop in replacement in fpga just for you?

LOL, I am quite confident that Chucky got his personal needs covered when it comes to 060 chips. As someone who spend an awful lot of time repairing Amiga systems and upgrading 040 systems to 060, he has pretty good insight into the demand for good replacement solution for 68060.

[wawa]

Originally Posted by kolla

LOL, I am quite confident that Chucky got his personal needs covered when it comes to 060 chips. As someone who spend an awful lot of time repairing Amiga systems and upgrading 040 systems to 060, he has pretty good insight into the demand for good replacement solution for 68060.

well, then vampire proposal may actually limit the demand on his offer.
one way or the other i dont see anyone else going about one particular 68k cpu model replacement and on forums. if he is a skilled developer he could start or contribute to such a project himself. its hard to expect that people who actually have a succesful project running will make a u-turn, remove features and limit their own concepts just because of objections voiced by one person on some forum.

[Chucky]

my Diagrom takes too much time already.. but yes.. as I got like 20+ rev6 060s in stock, 060s is no issue. also got 060 in both my 4000 and 1200. and I am not negative as it "competes" with my upgrades etc. nah. the issue is that I am not happy on the path it is going..
Anyway.. there will pop up other FPGA solutions. and also other 060 alternatives. so I guess I will manage.

[kev]

Originally Posted by Chucky

my Diagrom takes too much time already.. but yes.. as I got like 20+ rev6 060s in stock, 060s is no issue. also got 060 in both my 4000 and 1200. and I am not negative as it "competes" with my upgrades etc. nah. the issue is that I am not happy on the path it is going..
Anyway.. there will pop up other FPGA solutions. and also other 060 alternatives. so I guess I will manage.

damn wish i known that few months ago lol i had to risk ebay on 1 still need 2 thoughi have a few 040 boards that need them would u happen to have any extra 060 adapters?

[matthey]

Originally Posted by kev

matthey i sent you a link to his webpage check your email

Thanks. That guy looks smart enough and has quite the lab.

Originally Posted by meynaf

I have my own advanced 68k ISA as well. Enhancing the (already great but sometimes insufficient) asm programming flexibility is my goal - count me in if this makes sense to you.

We care and have been able to cooperate and share ideas. Most people just don't care, want the 68k to stay in the past or are too busy until it is too late. It takes time to create, document and evaluate enhancements and standards. We need more smart people with different backgrounds and perspectives to take part though.

Originally Posted by meynaf

Incompatibility problems of the "080" do not come from making the cpu faster, nor do they come from adding new instructions (even though they were added any old how).

This is true for the most part although there is software which breaks when the CPU is faster. On a scale of 1 to 10 with 10 being the most incompatible, this might be a 2. Adding new instructions is less likely to cause problems and might be a 1. Newer 68k processors like the 68040 and 68060 have already dealt with these problems and most newer 68k Amiga software will not have problems.

Originally Posted by meynaf

Aside of possible bugs they come from :
- being identified as some 68k cpu which is expected to have mmu+fpu, while they're not there

The problem here is because early 68k processors didn't have an ISA with hardware configuration query. The 68060 added the Processor Configuration Register (PCR) but it is necessary to know or detect that the CPU is already a 68060. The early 68k CPU detection means vary and some will fail. This is the fault of Motorola for making inadequate ISAs. The AmigaOS did add a CPU detection mechanism in exec and ThoR's CPU libraries add more robustness to CPU detection and querying.

Originally Posted by meynaf

- adding new registers which forces exec patches to save them on context switches

Adding new registers isn't really a problem unless the new registers are used with an old version of the AmigaOS which isn't aware of them. I don't see any need to add more integer registers and little advantage if more can't be added in an orthogonal way which compilers can easily take advantage of. CISC processors don't need as many registers and a smaller register file is more energy efficient. I believe it would be worthwhile to increase the FPU registers from 8 to 16 and create a new register argument ABI. The registers can be added in an orthogonal way usable by compilers and the FPU register file could be gated (turned off when not used) to save energy if it was not shared. I am in favor of adding a separate SIMD unit with 128 bit wide registers (upgradeable to 256 bit wide) with their own gated register file (not shared like the Apollo Core). The extra registers would need support from the OS but lack of 68k AmigaOS development should have no effect on a 68k CPU design or ISA+ABI.

Originally Posted by meynaf

- stealing opcode space of callm/rtm

This would be really low on the incompatibility scale (easily a 1). I don't have any plans to reuse this encoding space but I would not be opposed if there was something really compelling.

Originally Posted by meynaf

- resurrecting old 68000 move sr bug without being identified as 68000

It wasn't a bug as this was the intended behavior of the 68000 as designed. Most Amiga software stopped using this instruction a long time ago. I doubt much software is affected by this and it would be difficult to do anything malicious with only reading the SR. It would be nice to have a bit only accessible from supervisor mode which would turn on such compatibility though.

I see your point that the "080" is a doppelganger of existing 68k designs rather than having a true identity of itself. This makes sense to some extent for compatibility but then you claim it doesn't have enough compatibility. In a perfect world, a new 68k like CPU would have its own identity (defined by an ISA) and the 68k AmigaOS would add support or it. I am not so eager to criticize here considering the circumstances. Getting the old software running is one of the highest priorities and an FPGA CPU design can be changed.

[Chucky]

Originally Posted by kev

damn wish i known that few months ago lol i had to risk ebay on 1 still need 2 thoughi have a few 040 boards that need them would u happen to have any extra 060 adapters?

Just send me a PM

[meynaf]

Originally Posted by matthey

This is true for the most part although there is software which breaks when the CPU is faster.

I doubt any software running fine on existing '060s would break if ran on something faster.

Originally Posted by matthey

The problem here is because early 68k processors didn't have an ISA with hardware configuration query. The 68060 added the Processor Configuration Register (PCR) but it is necessary to know or detect that the CPU is already a 68060. The early 68k CPU detection means vary and some will fail. This is the fault of Motorola for making inadequate ISAs. The AmigaOS did add a CPU detection mechanism in exec and ThoR's CPU libraries add more robustness to CPU detection and querying.

Yeah but now it's too late and we're left with programs which expect to have an fpu if the cpu is a 060. No amount of configuration registers, exec cpu detection or cpu libraries, will change that.

Originally Posted by matthey

Adding new registers isn't really a problem unless the new registers are used with an old version of the AmigaOS which isn't aware of them.

Do not underestimate people's will to stick with their particular kickstart version or build.

Originally Posted by matthey

This would be really low on the incompatibility scale (easily a 1). I don't have any plans to reuse this encoding space but I would not be opposed if there was something really compelling.

Low, but enough to make some 68020 detection routines to fail (the one and only possible use of that instruction pair).

Originally Posted by matthey

It wasn't a bug as this was the intended behavior of the 68000 as designed.

Not an implementation bug, but certainly a design mistake.

Originally Posted by matthey

I doubt much software is affected by this and it would be difficult to do anything malicious with only reading the SR.

Actual software probably not, but future software maybe.
While one can't do really malicious code by just reading the SR, the supervisor of a sandboxed system must believe it's in supervisor mode while this is not technically true, otherwise the virtualization system will be unable to emulate his SR properly.

Originally Posted by matthey

I see your point that the "080" is a doppelganger of existing 68k designs rather than having a true identity of itself.

The 080 can have its own identity, it's just that it must be detected as something that's close enough to some previous member to not cause compatibility issues too much, like 68060 initially detected as being 68040 (usually this works).

[apex]

So many useless comments from people who have no card. Go out, get some fresh air, it is summer...