Vampire 600 boards for the Amiga 600 on the way

[matthey]

I dont have a 600 (only a500 & a1200) -- but i cannot wait to see what happens now these are about to get in the hands of people!

They will be in the hands of developers. It's not much different to many of the fpgaArcade boards going to developers and testers. The time and cost to solder and test the boards is disappointing. It seems that the Vampire and fpgaArcade are both having problems in this regard.

[matthey]

As far as I know anyone can order a board, not just developers. Looking forward to see first user tests.

True. The regular orders shouldn't be too far behind but the people at the end of the list will probably have to wait a bit.

[matthey]

i think for starters and for a600 in particular a limited softcore without fpu is enough. good news though that the apollo features fpu.

The current FPU is sparse like the ColdFire FPU but with fp immediates and maybe pre-decrement and post-increment for FMOVEM. I would like to see a more robust and 68k compatible FPU. Some think an SIMD will replace the FPU as happened with the x86/x64. Some of that happened because of limitations of the x86 FPU and it's sharing of the registers with the SIMD. In our case, the FPU is needed to do the more common double precision operations that compilers need as an SIMD would be single precision float only.

 are there any vector instructions or what?

There is an SIMD unit but it's also not complete.

 im not sure what would be the gain of adding coldfire instructions. by all means do not create another incompatible target software would have to be compiled for. the different versions for different 68k cpus are already annoyance enough. we need unity and common goals, not another split.

The ColdFire and other CPU enhancements are mostly aimed at improving code density and modernizing functionality. Defining a new ISA also allows some old instructions and addressing modes that slow a modern CPU to be deprecated so slow CPU traps/exceptions are avoided in new code. The 68000 or 68020 would still be a compatible base and the more common compiler target. There isn't much point in the mini-Apollo (Phoenix) CPU having CF instructions as there will be no ISA to support them but they are practically free. Maybe some support code will be able to make use of them.

Majsta's future hardware creations (probably for AGA) will likely have a significantly larger fpga. It's a tight squeeze fitting a fully pipelined CPU with caches into a Cyclone 2. A larger fpga would allow for a much more powerful CPU with FPU and SIMD.

[matthey]

It sounds like they are creating a low-end variant called Phoenix to cater for the Vampire A600 that will be far more 68K-like than Apollo. I agree that getting ISA compatibility is the most important, either 68020 or 68060, before new instructions that might be great, but will be unused by classic software.

There are no user level ISA changes to the 68060 from the 68020 that a compiler would use or target except an FPU ISA which the 68020 did not have. In other words, the 68060 ISA=68020 ISA for almost all purposes.

TBH if they get it working, and if they get 20 MIPS out of it in the end (on the Vampire) I will be impressed.  I'm glad they have a development target too, that always helps motivate people.

I too am skeptical of the performance increases over the TG68k given the limited resources. The MIPS test will probably give good results if the code fits in the ICache but the Phoenix will have smaller caches than the 68060 or even the 68040. Many of the timings are better than the 68040 but I expect overall performance similar to a 68040. There isn't any way a Cyclone 2 is going to outperform a 68060. Perhaps SysInfo will give 100MIPS result but that is meaningless.

[matthey]

Why is Majsta using such an old and slow FPGA?
Is it tremendously cheaper?

Cost. The Cyclone 2 was cheap and adequate for prototyping and proof of concept although Majsta might have switched to a Cyclone 3 earlier if he had known the difficulties of such a small fpga. He has been 100% successful in his original goals. There hasn't been enough time to upgrade to a bigger fpga for production of the Vampire 600. I think he is looking at a Cyclone 5 for the AGA machines.

The Apollo needs a complete rewrite to be squished down into the Cyclone 2.

That means it has to be re-debugged all over again.  This takes time.

Then it will need to be rewritten again when someone makes a version for a newer, bigger and faster FPGA chip.  Which means it will need to be redebugged all over again.  Jens will have really a lot of work to do

Much of what you say is true. It is a significant amount of work to shrink the Apollo and then it has less advantage over the TG68k which performs adequately with minimal resources. There are significant parts of the Apollo core that can be reused so some of the debugging would improve both cores. It should be a good learning experience and may be interesting for embedded applications.

[matthey]

68060 has a few less instructions than the 68020, so to be 100% compatible it shouldn't have them either.

You must be referring to the integer 68060 ISA only. Do you really want to drop the integer 64 bit MULS/MULU instructions in hardware just to be 100% compatible with the 68060? This is silly. Maybe a 68060 version of the TG68k will be made to be as close as possible to a 68060 (a waste of time and cycle exact is not possible with <$1000 fpga) but I expect it would be a fraction of the speed of an enhanced 68k like the Apollo that should be 99.9% compatible. How many people turn off JIT and select all the most compatible settings in UAE? Without the compatibility settings, UAE provides instructions that didn't exist on the real processors and uses 64 bit instead of 80 bit floating point among other incompatibilities. Some of the UAE less compatible settings give a more tolerant and stable system like turning off alignment restrictions on the 68000 emulation. The 68060 is a great processor but we should not limit ourselves to it's bounds.

FPU & MMU are also required for 100% compatibility. I don't believe gunnar is going to take over the soft core market, which is what he intends to do. What he's created doesn't really fit the requirement of getting us all access to 68060 accelerators either.

I will be pushing for a more 68060 compatible but further enhanced FPU. An updated FPU ISA would benefit the FPU more than a 68k integer ISA update. I believe a 25%-50% speed and code density improvement of FPU code is possible with hardware and ISA changes. I would like to make the FPU 64 bit to improve timings but if it causes too many compatibility problems then 80 bits has the advantage that it could do reasonably fast 64 bit integer math with more efficient conversion instruction enhancements (a hardware and ISA change).

An MMU is not planned in the near future. The 68060 has a Cadillac of an MMU that would be expensive and difficult to duplicate and test. A simpler MPU would be more likely at first.