Apollo core update (Vampire 600)

	Bottom Previous Topic Next Topic
Register To Post

orgin

Posted on: 2015/11/24 10:52 #1

Supreme Council

Small IRC update below.

Originally posted at safir.amigaos.se by Nickman. (Login may be required)

More information about Vampire 600 can be found at:
http://majsta.com


[11/22 23:30] <BigGun_> the core now supports all 8 bitfields instructions in HW

[11/22 23:31] <BigGun_> most need 1 cycle, some 2 cycle

[11/22 23:31] <BigGun_> Even when workiing on misaligned memory some only need 1 clock

[11/22 23:31] <BigGun_> Flip and me are testing them now.

[11/22 23:31] <BigGun_> For correct resutls and all flags always correct

[11/22 23:32] <BigGun_> the test will certainly take some more days

[11/22 23:32] <BigGun_> the core has mostly all in HW now



[11/22 23:50] <BigGun_> But I think most useful feature of the new core is the 64bit support

[11/22 23:59] <BigGun_> today many software expect 64bit hardware

[11/23 00:00] <BigGun_> Having full support for operations like ADD/SUB/MOVE/AND/OR/SHIFTS in full 64 bit

[11/23 00:00] <BigGun_> makes this easy now

[11/23 00:03] <BigGun_> also it improves performance a lot

[11/23 00:03] <BigGun_> Apollo also has special instructions like BSEL

[11/23 00:03] <BigGun_> BSEL A,B,C

[11/23 00:03] <BigGun_> makes masking operation like AMIGA Blitter

[11/23 00:04] <BigGun_> but with up to 3 operant each 64bit - in single clock :)

[11/23 09:55] <BigGun_> Instructions left out in the 68060 like 64bit Mul, 64bit Div etc are included in Apollo, are fast and working correct



[11/23 09:58] <BigGun_> for the FPU we did write several millions of calculcations

[11/23 09:58] <BigGun_> And they show that the FPU calculates correctly



[11/23 09:58] <BigGun_> Nevertheless we are not fully done yet.

[11/23 10:01] <BigGun_> The FPU calcs correctly,but of course to work in an OS system, more is needed

[11/23 10:01] <BigGun_> like save and restore of FPU state in interrupt etc.

[11/23 10:01] <BigGun_> Here we are still testing/devloping tests

[11/23 10:02] <BigGun_> There is one not fully understood problem that we have atm.



[11/23 10:02] <BigGun_> Besides this the Core looks pretty solid.

[11/23 10:03] <BigGun_> The ability to run software is good.

[11/23 10:03] <BigGun_> Workbench runs stable, we use the core daily, all kind of apps run fine.

[11/23 10:03] <BigGun_> and we played literally hundreds of games



[11/23 10:05] <BigGun_> We did develop many megabytes of testcases to test all instructions, including 020 ea modes

[11/23 10:06] <BigGun_> my testfolder is > 300 MB size

[11/23 10:06] <BigGun_> We have some not yet implmented opcodes

[11/23 10:06] <BigGun_> these are CAS2,CHK2,CMP2



[11/23 10:07] <rwo> I work on my 68k resource when i'm in the mood.. but all those 020 ea modes can give you a head eack

[11/23 10:07] <BigGun_> The 020 ea modes are pretty complex yes.

[11/23 10:08] <BigGun_> But Apollo includes support for them, we wrote many tests for them and so far they show no difference to a real Moto

[11/23 10:08] <rwo> thats good

[11/23 10:09] <BigGun_> We have one known and not yet understood bug.

[11/23 10:09] <BigGun_> We try to understand and fix this.

[11/23 10:09] <BigGun_> If this is done the core should be release ready.



[11/23 10:10] <BigGun_> We are not aware of cache bugs.

[11/23 10:11] <BigGun_> Apollo cache is pretty strong and supports stuff no other 68k did ever support

[11/23 10:13] <BigGun_> our caches work VERY different than any Moto did have them

[11/23 10:13] <BigGun_> On MOTOs a misaligned cache access did cost extra cycles

[11/23 10:13] <BigGun_> On our caches misaligned access is free.



[11/23 10:14] <BigGun_> And MOTO could die on selfmodifying code.

[11/23 10:14] <BigGun_> And to avoid dying - you needed to turn caches off- flush caches

[11/23 10:15] <BigGun_> APOLLO does not suffer from these problems

[11/23 10:16] <BigGun_> APOLLO has a hardware unit to automagically handle selfmodifying code