Previous Thread
Next Thread
Print Thread
Page 1 of 2 1 2
#119257 05/26/21 06:26 AM
Joined: Mar 2007
Posts: 26
E
e5frog Offline OP
Member
OP Offline
Member
E
Joined: Mar 2007
Posts: 26
I program for Channel F and a few versions ago (Currently checking out MAME 0.231 (LLP64) ) a bunch of registers were removed from the debugger in the left part of the window.
R16-R63 are gone from the list which makes things harder if you want to look for bugs.

While doing so $hexnumber was replaced with H'hexnumber', I thought $ or possibly 0x was the go-to way of writing hexadecimal numbers?
I have documents from the 70's that uses H'xxx' notation, as well as B'xxxxxxx' for binary and O'xx' for octal numbers - I thought it was long gone...?

Who has the power to change it back?

Joined: Feb 2004
Posts: 2,291
Likes: 19
Very Senior Member
Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,291
Likes: 19
We tend to prefer the syntax used for examples in official documentation in our disassembly. The documentation used the hex string H'89AB' notation, so we go with that. IIRC the pseudoregisters you’re talking about are now represented as an address space, so you can view them in a memory window.

Joined: May 2004
Posts: 953
Likes: 14
D
Senior Member
Offline
Senior Member
D
Joined: May 2004
Posts: 953
Likes: 14

Joined: Mar 2002
Posts: 1,217
Likes: 2
H
hap Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: Mar 2002
Posts: 1,217
Likes: 2
I'm bad with reading octal notation. I don't mind reading hex with 0x, $, or H notation. But in the CPU cores I've written, I always go for $ for hex numbers, regardless of the official programmer manuals. IMO we shouldn't have to 'emulate' the official notation, asm readability for current developers is more important.

Regarding the debugger memory window, I always find myself having to count if i need to know the offset that's somewhere in the middle. I can imagine it's annoying since there is no horizontal header on top showing 0 1 2 3 4 etc. Nor any way to show offsets as decimal. At least in the default Windows debugger.

Joined: Mar 2001
Posts: 16,841
Likes: 45
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,841
Likes: 45
IMO, if people actually doing assembly programming on the system don't like the revised debugger semantics then it's a problem. The pseudo registers should be put back, at bare minimum.

1 member likes this: e5frog
Joined: Mar 2007
Posts: 26
E
e5frog Offline OP
Member
OP Offline
Member
E
Joined: Mar 2007
Posts: 26
Originally Posted by Vas Crabb
We tend to prefer the syntax used for examples in official documentation in our disassembly. The documentation used the hex string H'89AB' notation, so we go with that. IIRC the pseudoregisters you’re talking about are now represented as an address space, so you can view them in a memory window.

I wonder when the syntax changed, it has been $ since... way back, version 0.80 from 2004... is as far as I can go, guess it's a new thing wanting to type more, instead of less. ;-)

The registers held in the Fairchild 3850 CPU that are addressed using ISAR (should we call them pseudoregisters?) are used a lot - as it's the only default RAM in the machine. It was extremely convenient to have them listed.
I'm fine with H, K, Q now being listed as the full 16-bit versions instead of their valid 8-bit versions HU, HL, KU... etc - but skipping the majority of the registers - why, who will benefit from this? Was it a user request?

I see now that they are in the register space memory in the memory window - thanks.
Which is very handy if you want to change a register. It's not very handy if you want to check a value - the list that was shown in the debugger before was excellent (shown in decimal but still). You pressed the debugger button and it was there in a list on the left.

Now: debugger button, Ctrl+M, mouse, click selection table, select register space memory... then calculate what the register is in Octal (as it's always addressed in octal in the code) or decimal as is used in all the old code since 20 years back, then in the evenly spaced data (without an x-axle marker, chunk size doesn't help me much), count by stepping one hex number at the time pointing with the mouse pointer
It's a little bit more work, a little bit of time a lot of times that could be spent on other things.
It would be highly useful to have the list of the registers (R16-R63) where they were before, with decimal numbering as before - or preferably - octal which would be R20-R77, I mean R O'20' - R O'77'


I'm used to the list it being there, it's very helpful when programming, I'd like it to continue to be there, please.
I think we're four or five people programming for the Channel F - in the world - please don't make it harder.

Joined: May 2009
Posts: 1,980
Likes: 24
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,980
Likes: 24
Originally Posted by e5frog
I see now that they are in the register space memory in the memory window - thanks.
Which is very handy if you want to change a register. It's not very handy if you want to check a value - the list that was shown in the debugger before was excellent (shown in decimal but still). You pressed the debugger button and it was there in a list on the left.

Now: debugger button, Ctrl+M, mouse, click selection table, select register space memory... then calculate what the register is in Octal (as it's always addressed in octal in the code) or decimal as is used in all the old code since 20 years back, then in the evenly spaced data (without an x-axle marker, chunk size doesn't help me much), count by stepping one hex number at the time pointing with the mouse pointer
It's a little bit more work, a little bit of time a lot of times that could be spent on other things.
It would be highly useful to have the list of the registers (R16-R63) where they were before, with decimal numbering as before - or preferably - octal which would be R20-R77, I mean R O'20' - R O'77'

I'm used to the list it being there, it's very helpful when programming, I'd like it to continue to be there, please.
I think we're four or five people programming for the Channel F - in the world - please don't make it harder.

I completely agree with this.

On a technical level, it makes perfect sense to have the system RAM wired up under the hood as an address space, because that is in fact how the hardware operated. And sure, if someone wants to actually browse it through the memory window, they should be able to do so, even considering how the debugger memory windows lack certain basic niceties that have existed in hex editors for decades, like a header to indicate columnar offset, or at least a hyphen between the middle two values in a line in order to provide a convenient visual anchor-point.

But it doesn't make sense to trash the UX for the small handful of people who have been, and would like to continue to be, actually using MAME to debug Channel F code. Various CPU cores have various pseudo-registers that are shown in the register window if it makes things more convenient, and this same alternative representation of the tiny amount of RAM in pseudo-register form is appropriate.

In FOSS projects around the world, not just in MAME, developers all too often become laser-focused on completely niche, decades-old de jure standards, while rejecting the de facto standards that are actually in use. MAME should absolutely be as accurate as possible, but that doesn't (or, at least, shouldn't) impinge upon its utility for people who continue to keep knowledge of a system and development on that system alive. Otherwise we wind up with a proverbial nice plate, with nothing on it.

Joined: Aug 2004
Posts: 1,445
Likes: 6
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2004
Posts: 1,445
Likes: 6
I also agree with the above sentiments. I detest octal, but fortunately haven't needed to work with anything octal-based recently.

e5frog if you're able to compile MAME, in f8dasm.cpp change all occurrences of H'%04X' to %04X (or $%04X if you want a $ sign, or 0x%04X if you want it to say 0x), and then do a similar change for all occurrences of H'%02X' . This should make it easier for you.

You can see the complete change that was done here:
https://github.com/mamedev/mame/commit/ab6dc75cc21baf3f1bb855dd64e584d5010942f7

Joined: Oct 2020
Posts: 12
Likes: 3
Member
Offline
Member
Joined: Oct 2020
Posts: 12
Likes: 3
Could something like that be a Mame.ini option, machine config option, or even a command line switch? (please insert brilliant ideas here to make it easily selected by user preference)

just a thought

1 member likes this: e5frog
Joined: Mar 2007
Posts: 26
E
e5frog Offline OP
Member
OP Offline
Member
E
Joined: Mar 2007
Posts: 26
Originally Posted by Robbbert
e5frog if you're able to compile MAME, in f8dasm.cpp change all occurrences of H'%04X' to %04X (or $%04X if you want a $ sign, or 0x%04X if you want it to say 0x), and then do a similar change for all occurrences of H'%02X' . This should make it easier for you.

Cool, I can use an older version, no problem, but it would be nice to use new versions and not having to compile them yourself - if there are new updates. Sound emulation for example, which is probably the only thing that differs from the original machine apart from not being able to set RAM anywhere on cartridge and the size and position of visible VRAM.
So... if I can work it in at the source, problem solved.

EDIT:
If I make changes, will they stick to the official version?

I recall a long long time ago I added some of the PAL consoles (which are still in the official one) but I couldn't figure out how to edit all the details I wanted to regarding clock speed, color palette and sound.

Last edited by e5frog; 05/27/21 01:44 PM.
Page 1 of 2 1 2

Link Copied to Clipboard
Who's Online Now
0 members (), 19 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,993
Posts118,153
Members5,005
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com