Cyclone Bugs

[Shirohagen]

Hi

With the release of the new DrMD, a lot is being said about the Cyclone bugs which prevent it from being perfect, and also mean CaSTaway hasn't benefitted from it yet. As a non-coder, I was wondering what the Cyclone bugs are exactly and what are the implications for the resulting projects.

Wondered if a techie could fill us mortals in on it in simple terms.

®

 

[fade]

I'd like to know a bit more about this as well

 

[Squidge]

I'm not very good at describing technical things in simple terms, but I'll have a go.

The cyclone bugs are basically faults in the emulation of the processor (the 68000 chip). For each instruction that it passed to this processor, it will set certain flags telling the program about the current status of what just happened inside the chip. One of these flags is called 'Z', and will be set to a '1' if the result of the instruction produced a zero result. (Eg. as a result of subtracting 1 from a register that was at 1). Other flags are called C (Carry occured, and can happen if you add a number which overflows the maximum number the register can hold), N (Result is a negative number), and others. I'd say most of the bugs were due to these flags being set incorrectly in certain conditions.

Other things that can cause problems are 'addressing modes' - basically different ways to fetch data into the processor's registers from memory (or storing data from the processors register into memory). If, for a certain instruction, these are guessed wrongly (eg. the emulator assumes a value is a memory address rather than a literal number), then the wrong result can be produced, which can cause the wrong result, or the program to crash, or for the program code itself to be overwritten.

Other problems could be that the instructions themselves are not be faithfully emulated, but this is more rare, as the instructions are normally quite simple.

 

[Shirohagen]

That's pretty clear Squidge, where did we get the Cyclone emulation core from and consequently what hope is there of further development? What GP32 emulators use it and so would benefit from it's progression? What are the main manifestations of the bugs in any GP32 projects that curently use it? I'm curious if they throw up similar behaviour, but I guess a small amount of bugs in the core can produce a huge amount of different symptoms when the instructions are executed from project to project.

What has your experience been of implementing the core into CaSTaway?

I'm not a coder, but that doesn't mean I'm not curious and interested in understanding what all you coders get up to, I often feel kind of left out when it gets all technical around here! This is my attempt to blend in...

®

 

[skeezix]

fDave is the author of cyclone; AFAIK no one's heard much from him in a few months. he ust vanished HEs doing work on Pocket PC and Symbian as well as GP32, so he might be focusing more on one of those (And if so, perhaps Cyclone has advanced for them, which is fine sinc ethey're all ARM based..) .. or maybe hes just not touched Cyclone in awhile. Lets just hope all is well for the guy

I futzed with it in CaSTaway for a bit, and it numerous issues that made it crash before the OS had booted up (ie: Before GEM desktop came up.) As such, I didnt' work very hard on it, since it seams cyclone is incomplete and I've not the tiem to be working on cyclone itself :/

jeff

 

[Shirohagen]

Hi Jeff, sorry, got my "coders beginning with S" mixed up! I'm not nagging for progress with Cyclone, what we have is great, I'm just too curious for my own good!

Great work with CaSTaway, it's one of the best for the GP32!

®

 

[skeezix]

Thanks I hope to do some more with CaSTaway/GP (named save slots instead of numbered, auto skip, maybe fancier menus and such..) but so little time right now :/

jeff

 

[johncross85]

As I remember, fDave wanted to make Cyclone a 100% complete 68000 core that could be used on various ARM platforms. He kind of appeared from nowhere with Cyclone mostly finished, was very active with updates to it, was chuffed when it started getting used in things like fGen32, said there was just a few bits left to do and he was working on them, then vanished.

Anyone know if Cyclone is opensource? If it's as near to finished as fDave seemed to think it was, perhaps some sort of ARM genius (he said looking towards Squidge) could fix the bugs? Ryleh says on his site that the lack of recent updates to Cyclone is one of the reasons he's not touched fGen32 for a while... an update to Cyclone would benefit quite a few projects actually!

J(ohn)

 

[Squidge]

Cyclone is (was?) open source. There is still the source code flying around which anyone can hack. However, the original download from fDave's webpage also included several C files that actually built the asm file to make the whole thing a lot more readable, and a lot easier to modify. These seem to have gone missing when fDave removed Cyclone from his website.

If anyone has the latest version of Cyclone (not just the assembler file as used in open source emulators), then could you upload it somewhere?

 

[look]

How generic is the Cyclone 68000 in terms of its use in emulation and what is A68K which can aparently be used as an alternative to cyclone?

 

[Reesy]

In order to confirm what games have "Cyclone bugs" and what games just have "DrMD bugs" I have created another version of DrMD. This version of DrMD has the MUSASHI M68K cpu core in, its very slow and makes you realise just how fast Cyclone really is. But loads of the games that don't work using the Cyclone cpu core do work on this new version, they just run slowly.

My plan is to build a debug version of DrMD that will two emulators in it. I will then run both emulators one instruction at a time and look for differences between them, this may shine a light on some of the cyclone bugs. I have no idea if this will work or not but its worth a try.

Reesy

 

[johncross85]

Actually, I've just realised I was talking out of my arse - fDave posted as recently as 2nd Dec. He's also been known as being very much in favour of opensource - I quote:

"So I can highly recommend releasing your source code whereever possible!"

...so god knows what's going on.

J(ohn)

 

[Goity]

yeah, I saw him too, I was gonna report on that but I forgotted

 

[Shirohagen]

So the development of Cyclone is not related specifically to the GP32, and we may well benefit from activity in other ARM based environments such as Zodiac etc...? I didn't realise that, that's good news, maybe we will see the back of the bugs after all...

®

 

[johncross85]

Cyclone was used in LJZ on the Zodiac and (I think) in all the versions of PicoDrive, fDave's Genesis emu, which he ported to loads of things (GP32, bunch of Nokia phones, N-Gage, Pocket PC etc).

So signs are good that someone somewhere on some platform will finish Cyclone off and given what Reesy said this could be sooner rather than later :lol:

J(ohn)

 

[Squidge]

Any progress on this Reesy? Just as I'd like to do a proper Genesis emu for the Zodiac (LJZ is far too slow, but the Zodiac is my most used handheld).

I don't want to use the Cyclone core simply because of the numerous bugs, so may end up writing my own, as the Cyclone source looks like a complete nightmare to debug to me (unless you do like you say, so you can pinpoint the exact instructions which are incorrect).

Hmmm, actually, it may do some good to have some competition in the 68K emu world

In order to confirm what games have "Cyclone bugs" and what games just have "DrMD
[...]
My plan is to build a debug version of DrMD that will two emulators in it. I will then run both emulators one instruction at a time and look for differences between them, this
[...]

​

 

[trooper]

Hmmm, actually, it may do some good to have some competition in the 68K emu world

Yeah Squidge, Sounds good to me , fdave has done an excellent job with cyclone and things would not be this far without it. A bit of heathy competition never hurt anyone . It may even spur fdave (what does that f stand for ?) into tackling the bugs in cyclone .

Trooper

 

[Reesy]

Well I made a start. The problem I'm finding is that Cyclone will take interupts at different times than the Musashi core. So it's very hard to run them together and keep them in sync, plus I'm finding the timings for opcodes are different. Basically it was a nice idea but I don't think its going to work.

But your right debuging cyclone is going to be a nightmare. In order to keep the size of the core down fdave has had to re-use lots of code here there and every where, which makes it hard work trying to track exactly whats its doing.

There's nothing like writing your own cpu core, though because you know exactly how it works and how best to use it. I was thinking about writing my own M68k core as well, but I still have a lot of reading to do on the M68K cpu.

Good luck writing your own though, I'll let you know if I get anywhere debuging cyclone.

Reesy

 

[DaveC]

Well I made a start. The problem I'm finding is that Cyclone will take interupts at different times than the Musashi core. So it's very hard to run them together and keep them in sync, plus I'm finding the timings for opcodes are different. Basically it was a nice idea but I don't think its going to work.

But your right debuging cyclone is going to be a nightmare. In order to keep the size of the core down fdave has had to re-use lots of code here there and every where, which makes it hard work trying to track exactly whats its doing.

There's nothing like writing your own cpu core, though because you know exactly how it works and how best to use it. I was thinking about writing my own M68k core as well, but I still have a lot of reading to do on the M68K cpu.

Good luck writing your own though, I'll let you know if I get anywhere debuging cyclone.

Reesy

​

Hey Reesy,

Have you tried to contact fDave? I know that he was asking for help with the cyclone bug, and he knew exactly what was going wrong, he just couldn't figure out why it was bugging out. Maybe if he explained the exact part of code that he was having trouble with it would help narrow it down and save some time. There maybe something that you think of that he didn't. He still visits this board once in a while so if you PM him you may be able to work things out. Just a thought.

 

[Squidge]

Thanks, I'll let you know if I get something up and running and in good condition. No point distributing a 68K emu that isn't at least as good as Cyclone.

The way I want to do it is describe every opcode carefully in a text file, and then use a C program to convert that text file into arm assembler code. So hopefully, most changes and bug fixes will only occur in the text file. Whether it actually works this way is another thing however