|
Some changes I want to submit
#142867 - 02/18/08 03:56 AM
|
|
|
Longtime MAME user, first time I want to submit MAME modifications and would appreciate some feedback so I do not waste the time of MAME devs: 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".
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?
Why is the brk opcode output as brk_m6502?
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?
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.
Thanks!
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9716
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Some changes I want to submit
[Re: Franklin Bowen]
#142957 - 02/19/08 12:51 AM
|
|
|
> 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. > 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. > 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. > 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.
|
|
|
|
Re: Some changes I want to submit
[Re: R. Belmont]
#143167 - 02/20/08 08:33 PM
|
|
|
> > 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!
|
|
|
Stiletto |
They're always after me Lucky ROMS!
|
|
|
Reged: 03/07/04
|
Posts: 6472
|
|
|
Send PM
|
|
|
Re: Some changes I want to submit
[Re: Franklin Bowen]
#143191 - 02/20/08 10:07 PM
|
|
|
> Noted! > > Thanks for the informative reply!
FWIW, the MAMETesters board gets a little more MAMEDEV traffic, although I expect most regulars here to be viewing the most recent posts anywhere.
- Stiletto
|
|
|
|
Re: Some changes I want to submit
[Re: R. Belmont]
#143322 - 02/21/08 02:32 PM
|
|
|
> > 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.
I think there are collisions between undocumented opcodes and other 6502 chips with extra documented instructions. So if the disassembler is shared then it shouldn't be, or it should at least switch itself.
smf
|
|
|
|
Re: Some changes I want to submit
[Re: Franklin Bowen]
#143323 - 02/21/08 02:37 PM
|
|
|
> 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?
I suspect that we wouldn't accept a patch that allowed you to disable disassembling undocumented instructions that were valid for the current cpu core, just because you don't want to see them.
If there are instructions that are disassembled incorrectly, because they are for a different member of the 6502 family, then they should be fixed.
IIRC there were 6502's that were manufactured without something like ROL A ( I can't remember what, it's been over 20 years ). I doubt we support those properly either.
smf
|
|
|
|
Re: Some changes I want to submit
[Re: ]
#143350 - 02/21/08 06:47 PM
|
|
|
> I suspect that we wouldn't accept a patch that allowed you to disable disassembling > undocumented instructions that were valid for the current cpu core, just because you > don't want to see them.
I'd be fine with a patch that limited the disassembly to the current incarnation of the 6502. That is, if you are running a 6502, only display 6502 instructions and not those of other related CPUs.
|
|
|
|
Re: Some changes I want to submit
[Re: ]
#143470 - 02/22/08 08:24 AM
|
|
|
> IIRC there were 6502's that were manufactured without something like ROL A ( I can't > remember what, it's been over 20 years ). I doubt we support those properly either. > Yes, ALL 6501s, 6502s, 650x where x is 3-9, manufactured before the ?25?th week of 1975 had the ROR and ASR instructions non-functional (I'm not entirely certain what they did but they didn't do what they were supposed to). Mess does not yet emulate this, and it is significant for the earliest KIM-1's. The KIM-1's built-in cassette routines depend on these opcodes, and would NOT work on early machines!
LN
|
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
Re: Some changes I want to submit
[Re: AaronGiles]
#143649 - 02/23/08 12:44 PM
|
|
|
> > I suspect that we wouldn't accept a patch that allowed you to disable disassembling > > undocumented instructions that were valid for the current cpu core, just because > you > > don't want to see them. > > I'd be fine with a patch that limited the disassembly to the current incarnation of > the 6502. That is, if you are running a 6502, only display 6502 instructions and not > those of other related CPUs.
I said that, but you didn't quote that bit :-)
"If there are instructions that are disassembled incorrectly, because they are for a different member of the 6502 family, then they should be fixed."
|
|
|