Implement TRAP

[marhel]

Please implement the instruction for Trap. For more information, please read the instruction contribution guidelines

[emoon]

Regarding this one.

Would it be possible to have some custom trap handling from the outside? For example if you want to allow Rust code being called when the 68k emulator wants to call a "syscall" (or library on Amiga for example) you want to run regular code for loading files for example.

I'm not exactly sure how this would look but something like it would be needed.

[marhel]

I haven't thought much about this, but have you read https://github.com/kstenerud/Musashi/blob/master/example/example.txt ?

(simulated) external devices can trigger interrupts in the CPU, which then needs to be programmed to handle them.

[emoon]

Alright. Interrupts should be fine also (as long as they leave all the registers in a valid state) but still there need to be some way to register a interrupt handler then.

[marhel]

Perhaps I'm misunderstanding you, but what you are describing falls outside r68k, I think.

You'll provide r68k with the ROM image (or set it all up as RAM, whatever you like) and you'll need to configure pointers to exception handlers for interrupts, TRAP, Illegal instruction, address error, etc in the exception vector (the first KB of memory), see M68000 Programmer's Reference Manual appendix B, for example.

If the exception handlers leave all registers in valid state or not, is up to the code you provide in ROM/RAM (and of course indirectly it depends on if the m68k emulation is in fact correct)

[emoon]

I guess this is what I'm talking about

https://github.com/kstenerud/Musashi/blob/master/m68kcpu.h#L841

It's the possibility to allow r68k to call host code in some cases.

[emoon]

Also it's not super important to have this early on but something similar would be great.

[marhel]

Ah! Ok, I guess that is perfectly fine to have such "notification callbacks", in order to let the process hosting r68k act on various events. If i remember correctly, this is something you set up via various defines in Musashi, so we'll have to find the properly Rust-y way to define that the host wants such callbacks .

[emoon]

Yeah having a proper Trait for this would be good.

[emoon]

I can take this one. We can investigate callbacks and such later on how that should be handled imo

[marhel]

Yes, that can wait, I agree. However, please note that ops such as TRAP, TRAPV and STOP, at least, are a bit different than SUB, as they need to trigger interrupts and other non-standard behaviour. Please allow commits 8df366cf and 3d48fe8d to provide some guidance. And feel welcome to discuss any other design issues you might have, if these ops you've picked needs additional infrastructure.

[emoon]

Due to having less time (and the amount of instructions that needs to be implemented is getting short) maybe it's better if you take this one?

[marhel]

Sure, I'll take that as well. Please feel no obligation to contribute stuff if you have other things on your mind.

[emoon]

Yeah.. some other stuff ha been brewing lately :/ I will finish of the unlk op-code at least.