Very cool

[emoon]

Hi,

Just wanted to say that it's great that you are doing this! I'm working on this thing https://github.com/emoon/open_depacker which needs to run a very tiny Amiga emulator to run some Amiga problems.

It's written in Rust but currently uses Musashi as emulation core but my plan has always been to replace that with something written in Rust in the long run.

So this comes as a welcome surprise :)

[marhel]

Cool!

If you want to contribute some opcode-implementations, that'd be great! I assume it would be quite straight forward - almost a copy paste job - to implement "duals" to the ops already implemented, such as adding all variants of SUB (based on the existing ADD ops), or more logic ops; EOR, OR (based on AND), SBCD (ABCD), more shift ops LSL/LSR, ROL/ROR etc (ASL/ASR). I've just done them in alphabetical order. The infrastructure is set-up to run A/B-tests comparing your op-implementation with Musashi with almost no extra work on your part, so it's almost trivial to find out if the implementation is correct.

Take a look at for example this or this commit, to get a feel for the amount of code required.

I'd be happy to walk you through the process in more detail, if you (or anyone else) are interested.

[emoon]

Yeah that looks very straightforward.

Dunno if you consider it too much overhead but otherwise creating an github issues for a range of opcodes and then mark each "inprogress" when being worked or something similar would be nice as then I could work on some now and then when I have time to make sure we don't do double work.

[marhel]

No that seems like a good way to coordinate. I'll write up some instructions, and create a number of issues.

[emoon]

Thanks!

[marhel]

Please take a look at https://github.com/marhel/r68k/wiki/contributing and I'll get some issues up within a day or two.

[emoon]

Looks good. The link to https://github.com/marhel/r68k/wiki/musashi-ops.txt doesn't seem to have anything in it yet.

[marhel]

Yes, it was meant to point to the source code, not the wiki, fixed now.

[emoon]

Another question I come to think of is that some instruction has different cycle count depending on the input. For example the shift instructions. So I guess it will be hard to to set a fixed cycle count then for the impl_op!(-, cmp_32, cmp_32_di, ay_di_32, dx, 6+12); and the last part

[marhel]

Well, yes, the implementation needs to handle shift ops differently, which it does where it adds 2*shiftdistance to the constant specified as the last part of the impl_shift_op-macro...

[emoon]

Ah I see. Thanks! No more questions :)

[marhel]

So, I created issues for the remaining opcodes. Feel free to pick one. I'll probably add some placeholders to the source code, which will possibly minimize PR-merge conflicts.

[emoon]

Sounds good. Can you assign all SUB issues on me?

[marhel]

Sure!

[marhel]

Hmm, I cannot add you as an assignee without making you a collaborator, which seems to give you push access. :) I'll have to look into setting this up further, but that'll have to wait until a little bit later. Sorry :)

[emoon]

Np. I just write a comment on those I will start with.

[emoon]

And you can flag that one as in-progress or something like that (with a label)

[marhel]

I labelled all 6 SUB-issues as "In progress", thank you for playing along!

[emoon]

Thanks! I added a comment to all of them in case someone else peaks at them.

Thanks for doing this project :)

[emoon]

Think we can close this one now :)