> > 1) 6502 disassembly: op6502 in 6502dasm.c contains a lot of opcodes not supported > by > > a 6502 CPU. Does it make sense to submit a "fixed" op6502 or is someone using it in > > current form? If so, I could add a basic_op6502 and switch between the current form > > and the basic form with a menu choice like "Basic Opcodes". > > I believe that function is also used by other 6502 family members (especially in > MESS), so removing the extra opcodes is a non-starter.
OK. I will create a new structure called documented_op6502 and implement a mechanism for the user to choose this variant. It will need to work within the debugger windows and also the dasm command. Anything else I need to watch out for?
> > Also, the string for illegal opcodes "ill" is hard for me to pick out in > disassembly. > > I want to change it to "???" Is this submittable or just a style preference I need > to > > compile in my version of MAME? Or a configuration that can be set somewhere? > > There's no specific rule on illegal opcodes in disassembly, although most CPU cores > output "ill" or "illegal" so I guess that's a pseudo-standard.
OK. I will see if I can add a way to set this through configuration.
> > 2) If I find a bug, do I need to submit a bug and then a fix? Or is it easier for > > everyone involved if I just submit a code change with the fix? > > It's extremely unlikely there are any bugs in the M6502 - it runs probably tens of > thousands of ROMs correctly across various MAME and MESS systems. That said, if one > comes up and you can prove it (ideally vs. real hardware) submit the actual fix.
Sorry for the confusion. I have not found bugs in the M6502. Just minor UI and some things that I do not understand. I will submit fixes or post questions as I encounter things I do not understand.
> > 3) Is someone "directing" or in charge of architecture of the MAME debugger? I have > a > > change I want to make but would prefer to discuss it with someone. > > The debugger is Aaron's baby.
Noted!
Thanks for the informative reply!
|