This will probably be a waste of time, but I'm curious to see how this will turn out. Obviously I don't expect it to run anywhere near the speed of a real 68000, but exactly how slow I don't know.
Just trying to figure out which opcode an instruction is, is going to be complicated. Below is a table of how each instruction is layed out. I can probably do a branch tree, where I narrow it down to instruction type.
http://www.markwrobel.dk/post/amiga-mac ... deep-dive/
I'm pretty sure you can emulate any CPU in any other CPU as long as speed isn't a concern and you have the memory for the entire state. Whether there's any use for a slow ass emulator is another issue.
The 65816 already has a hard time competing with the 68000 as it is, so I doubt you'd get anything usable (i.e. not horribly slow) by trying to make it simulate a 68000. I think this would be a waste of time, because you probably wouldn't be able to put this to use in any meaningful way. The novelty of it would wear off almost instantly, after all the hard work to get it done.
At least it'd let you unit-test subroutines for Genesis games on your IIGS.
IIRC/AFAIK emulation on the PC generally has ~10-30x overhead (e.g. take the host clock speed (4.4 GHz), divide by 30 (for bsnes), divide by guest clock speed (21.48 MHz), multiply by 60 (for NTSC) = 410 fps) just for the CPU emulation... Then divide by 3 for emulating the entire system.
So that'd be ~2 fps just for emulating the 68K CPU on the 65K, as a very rough ballpark figure.
I just did some experimenting with a hypothetical psuedo ASM code where the only addressing mode is absolute addressing, and I got 38 cycles per 3-operator 16-bit ADD, and 66 cycles for a 32-bit ADD. This looks like it can range anywhere between 2 to 6 times slower than real 65816 ASM, depending on what type of instructions.
I suppose you could use it to port a game with very slow game play. Mahjong. Go. Checkers.
I wouldn't. But you could.
dougeff wrote:
I suppose you could use it to port a game with very slow game play. [...] Go. Checkers.
Without an AI player though...
What's the practical purpose for this? Or is it just a personal "can it be done" project?
Some of the addressing modes of the 68K are what's going to kill performance, compounded by register sizes. The "Address Register Indirect with Displacement" and "Address Register Indirect with Index" addressing modes are going to really hurt given that the calculations are done at run-time. Things like this (and similar on the x86) are what make the CPU so powerful.
Lately I've been needing more and more mathy stuff in my game, and I've been thinking about making some kind of psuedo-ASM language to speed up development, when I have to deal with multiplication and division and signed numbers.
Yeah, I know 68000 ASM is a little too much for this type of thing.
I was messing with an approximate Riemann solver on SNES a while back, and I learned very quickly that using macros is far preferable to manually coding the whole math operation every time.
Tables for unary operations like inverse and square root are extremely helpful as well.
I assume you've seen this:
http://wilsonminesco.com/16bitMathTables/ It's for 6502, but the general idea is still relevant to SNES.
How powerful is ca65's macro support? Macros are such a blessing in Nasm; being able to generate different code based on the number and types of arguments passed is so useful. I even went and made macros that do nothing but move values into registers and call functions. It's easier to shoot myself in the foot and not think about what registers are being overwritten, but it makes the main code so much cleaner.
About your situation psychopathicteen, I would probably make multiplication a macro that writes to, then reads from the fast multiplication registers. It would be very easy to make this a macro because I think the code would stay the same regardless of where it's used.
What would you want to do with signed numbers? Addition and subtraction will result in the same numbers unless you want to implement saturation (values don't wrap around / no overflow). Do either multiplication units not support signed multiplication or division?
psycopathicteen wrote:
Lately I've been needing more and more mathy stuff in my game, and I've been thinking about making some kind of psuedo-ASM language to speed up development, when I have to deal with multiplication and division and signed numbers.
It's called C
I would say something about how C is prohibitively slow for the 65816, but this is the thread about emulating a 68000 with a 65816...
It's not so for the 6502, so why would it be for '816? If you find Little Medusa to not have enough action, perhaps MegaCat's next SNES title will be more to your liking
The problem with C, is that I would have to make it from scratch again.
If it makes you feel better emulating a cpu will probably take way longer and cause more headache. Also even optimized C isn't too bad as long as you don't use it in code that runs every frame.