Cyclone 68000 And Castaway

[pip]

Jeff, I am very much enjoying the Castaway emulator of yours. So I am curious if you are planning to improve it even further by applying the Cyclone 68000 ASM core?

Thank you.

 

[Daz_Genetic]

Yeah, I use castaway more than any other emulator on the GP32. Some of the greatest Amiga classics were also released almost unchanged on the ST.

I'm more anticipating chatboard support, as I've never felt that it ran that slow, but any optimisations would be nice. The more people who use this core, the more bugs will be found and the more optimum it will become.

 

[argon0]

Hear Hear!

If it supported Chatboard I'd be more than likely to get my one modded!

Argon0

 

[carlgeorge]

I second all of that, Castaway is my most used emulator too -- probably something to do with me having had a ST and Falcon previously.

 

[Squidge]

Don't forget though that Cyclone 68000 is an unfinished product, so may be less compatible than current interpreted cores (or at least that's the impression I get from the website).

We don't want to be throwing it into everything, although I agree we need to get it used so it can be debugged and improved.

 

[khephren]

Don't forget though that Cyclone 68000 is an unfinished product, so may be less compatible than current interpreted cores (or at least that's the impression I get from the website).

We don't want to be throwing it into everything, although I agree we need to get it used so it can be debugged and improved.

Very true Squidge, and I don't really know how fast this core is over a compiled C one, any ideas?

P.S. Now you may not be doing a Megadrive EMU, why not put a lot of that planning to use with an A500 emu? ;P

 

[Squidge]

Just because I said I would be working an an emu with a 68k core and possibly a few custom chips, doesn't mean it's an amiga

 

[Enslaved]

Sure it does!

 

[sebastian_insua]

lol

 

[Squidge]

wha?

 

[skeezix]

Its potentially possible to use some 68k cores; the one I've got in there now is a little integrated into the emu, but it should be possible to decouple 'em. I'll worry about it later when things are proven and mature though.. no time to lose with alpha stuff sadly

Chatboard support will come in a bit; I've moved my gp32 dev environment to my laptop, which is where I spend 99% of my time, so it'll be a lot easier now

jeff

 

[khephren]

Good news Skeezix, then maybe a more compatable mode mode for demo's? (i'm trying my luck tonight!) Here's something that's funny, the Amiga VS ST debate is continuing on the forums over here: http://www.atarilegend.com/news/news.php
it makes for amusing reading! Although most people admit (as I do) that they love them both.

 

[fdave]

Don't forget though that Cyclone 68000 is an unfinished product, so may be less compatible than current interpreted cores (or at least that's the impression I get from the website).

We don't want to be throwing it into everything, although I agree we need to get it used so it can be debugged and improved.

Hi folks,

There no may about it: Cyclone 0.064 is *currently* less compatible than current interpreted cores. This is because of two reasons:

1) A few opcodes are left to do. I did a couple last night. Left are ABCD, SBCD, EXG, TRAP, and ANDI/ORI CCR, that I can recall

2) There is (at least one) bug in one of the opcodes I've already done, (my best guess wouldbe something like EXT or ASL), causing Sonic to jump weirdly to the left


However once these are fixed (two weeks? a month or so?), Cyclone 68000 *will be* as compatible as all of the other 68000 cores out there. There is no reason that I currently know of why it shouldn't, and so that would make it merely a matter of completing the remaining tasks.


Dave.

 

[khephren]

Don't forget though that Cyclone 68000 is an unfinished product, so may be less compatible than current interpreted cores (or at least that's the impression I get from the website).

We don't want to be throwing it into everything, although I agree we need to get it used so it can be debugged and improved.

Hi folks,

There no may about it: Cyclone 0.064 is *currently* less compatible than current interpreted cores. This is because of two reasons:

1) A few opcodes are left to do. I did a couple last night. Left are ABCD, SBCD, EXG, TRAP, and ANDI/ORI CCR, that I can recall

2) There is (at least one) bug in one of the opcodes I've already done, (my best guess wouldbe something like EXT or ASL), causing Sonic to jump weirdly to the left


However once these are fixed (two weeks? a month or so?), Cyclone 68000 *will be* as compatible as all of the other 68000 cores out there. There is no reason that I currently know of why it shouldn't, and so that would make it merely a matter of completing the remaining tasks.


Dave.

Hi Dave,
Have you compared Cyclone to any C compiled Cores? If you have, how does it compare?

 

[Squidge]

It would be nice to have some 68k benchmark that you could run on an interpreted core and the new Cyclone, just so we know how much difference this asm core makes as a percentage.

 

[fdave]

It would be nice to have some 68k benchmark that you could run on an interpreted core and the new Cyclone, just so we know how much difference this asm core makes as a percentage.

Probably Rlyeh is the best one to talk to about that. For example he could run Sonic1 unthrottled using both Musashi and Cyclone, and count how long to get to the end of the level 1 demo or something, and that would give a ballpark figure.

(I've only got a dual compile of Cyclone and A68K, which obviously doesn't run on ARM.)

I think he though it might be about 4x, but we're not sure yet.


All I know is Cyclone will be close to the theorical interpreting limit on the ARM9. For example this is the code for move.w Dn,Dm:

;@ ---------- [3000] move.w d0, d0 uses Op3000 ----------
Op3000:
;@ EaCalc : Get register index * 4 into r0:
and r0,r8,#0x000f
mov r0,r0,lsl #2
;@ EaRead : Read register[r0] into r0:
ldrsh r0,[r7,r0]

adds r1,r0,#0 ;@ Defines NZ, clears CV
mrs r9,cpsr ;@ r9=NZCV flags

;@ EaCalc : Get register index * 4 into r0:
and r0,r8,#0x0e00
mov r0,r0,lsr #7
;@ EaWrite: r1 into register[r0]:
strh r1,[r7,r0]

ldrh r8,[r4],#2 ;@ Fetch next opcode
subs r5,r5,#4 ;@ Subtract cycles
ldrge pc,[r6,r8,asl #2] ;@ Jump to opcode handler
b CycloneEnd


I can't think of anything which could run that opcode any faster and still calculate flags, unless anyone has any cool ideas!
(Without blowing up the size of Cyclone beyond 500k!)
Without recompilation of some sort of course, and obviously that wouldn't slot into existing emulators.

 

[Squidge]

How does it recognise which opcode routine gets called? The fastest way I've always found is that to waste some memory, and have a 64kb*DWORD table which you can jump directly to the opcode without any parsing until you get there.

The " ldrh r8,[r4],#2" seems to do that, but I'm not sure from reading your code.