Home Page
Posted By: e5frog Channel F debugger crippled - 05/26/21 06:26 AM
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?
Posted By: Vas Crabb Re: Channel F debugger crippled - 05/26/21 06:31 AM
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.
Posted By: Duke Re: Channel F debugger crippled - 05/26/21 09:07 AM
See also https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=118580
Posted By: hap Re: Channel F debugger crippled - 05/26/21 09:26 AM
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.
Posted By: R. Belmont Re: Channel F debugger crippled - 05/26/21 11:23 AM
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.
Posted By: e5frog Re: Channel F debugger crippled - 05/27/21 12:28 AM
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.
Posted By: Just Desserts Re: Channel F debugger crippled - 05/27/21 06:30 AM
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.
Posted By: Robbbert Re: Channel F debugger crippled - 05/27/21 10:18 AM
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
Posted By: MrBogi Re: Channel F debugger crippled - 05/27/21 11:53 AM
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
Posted By: e5frog Re: Channel F debugger crippled - 05/27/21 01:14 PM
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.
Posted By: e5frog Re: Channel F debugger crippled - 05/27/21 01:36 PM
Originally Posted by MrBogi
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)

... or in the channelf.ini but I understand if programmers don't want a bunch of special cases? It could be in the debugger window itself, there's the "Option" menu in the debugger or as an option you can start on the debugger command line - which it would then save in a settings file. Maybe a debugger settings that can be saved in a file, to customize things.

channelf.ini could also contain ROM/RAM settings and visible VRAM area. Maybe I'm building a half/half ROM/RAM cart and not just Chess RAM, would help if it could be emulated.


I digress, viewing the registers is my main reason for whining, it's too complicated compared to the way it was before.
Posted By: e5frog Re: Channel F debugger crippled - 05/28/21 10:19 PM
When saying you tend to use syntax from official documentation, when did that start?
Isn't this official documentation, a majority of it has been up since at least 2012:
http://channelf.se/veswiki/index.php?title=Main_Page
... or are valid documentation for a 1976 video game only from 1976 or earlier?

I started using MESS for Channel F development in 2004, the debugger had a nice black background with colorful chars, disassembly to the left, two memory areas in a column on the right, no register list.
The disassembly used $ for hexadecimal numbers.
[Linked Image from i.postimg.cc]

Debugger was changed at some time, felt unfamiliar and more grey but soon realized it was functionally better - it had a list of all registers to just scroll through - nice!
Disassembly use $ for hexadecimal numbers.
It was like this for many years, newest version I currently have is 0.146b (2012)
[Linked Image from i.postimg.cc]

Then... somewhere before 0.220?
List removed and hidden away - gone from view. I stuck with 0.146b because of the missing register list.
Disassembly use $ for hexadecimal numbers.
[Linked Image from i.postimg.cc]

Now:
$ gone as well, not really an improvement.
[Linked Image from i.postimg.cc]
The debugger can't be meant for people 70+ y-o to reminisce their youth?


So... maybe... change it back? For the current community?
Posted By: Just Desserts Re: Channel F debugger crippled - 05/28/21 11:17 PM
Bror, för fan, work with me here.

Nobody is or has yet argued that what you're saying is invalid. On the contrary, most of the replies are agreeing with you.

It's just that it takes a little bit of time to walk back any given change. It hasn't been helgen until just these past six hours, and I've been busy with other things.

I'll make the necessary changes (re-adding the pseudo-registers, changing the relevant read-outs back to the expected form) for the F8 CPU when I get up tomorrow - I've had a bit too much from my latest Systemet run to really be doing coding tonight - and I'll submit a pull request.

Just please don't go off the deep end just because there isn't an instant fix, okay?
Posted By: AJR Re: Channel F debugger crippled - 05/29/21 02:05 AM
As the developer primarily responsible for this situation, I want to break my silence on this matter. I've been working on additions to the debugger that might at least partially address the complaints.

One (mostly implemented in https://github.com/mamedev/mame/pull/8101) is an option for the memory view to display decimal addresses instead of hexadecimal addresses, since decimal addressing was also commonly used with a few other architectures, e.g. 6502 with Applesoft BASIC. Ideally there would also be the ability to get a hint displaying the address in whatever format was selected when hovering over a memory location, but I don't know enough about any of the windowing APIs MAME's OSD layer uses to implement that part. (The memory view doesn't use column headers since its number of columns per line is fully adjustable; 16 is merely the default.)

The other is a more ambitious idea: allowing debug commands to define "equate" symbols as aliases for memory locations which can be seen in state views and used in debugger expressions. With this feature, which would clearly be useful for many other architectures, it would be a simple matter to make a debugger script that would add the rest of the F8 register file as R20 through R77 or R16 through R63. (By the way, HU, HL, KU, KL, QU and QL were not actually removed; their names were merely hidden.) I have a mostly working implementation of this, which extends the concept to also allow user-defined symbols for arbitrary bitslices of memory locations, but the code is a bit rough at the moment. (Real life also precludes substantial work on it during this weekend.)

The use of octal addresses with hexadecimal data on F8 is highly unusual, and seems to be entirely an artifact of the instructions used to control ISAR (which provides the only means of accessing the upper 48 registers). I don't think it's worth octalizing the F8 data space beyond that register, whose values were quite consistently documented as octal. (There's still no way to load an immediate value into all 6 bits of ISAR with a single instruction.)

In my opinion, MAME's disassembler architecture could perhaps be made more flexible, but I don't think any one format is ever going to please everyone. The memory view, on the other hand, suffers from so many ingrained limitations that its implementation and interface deserve some sort of drastic overhaul.
Posted By: e5frog Re: Channel F debugger crippled - 05/29/21 05:37 PM
Sorry for stressing, didn't want this to die out as it seems to have done the last time I asked (in February), so I tried to motivate my concerns with a few images as well to explain the "problem".



@AJR
Having H, K, Q as it is displayed right now is actually better than the H and L for each, good one, thanks!.

Yes octal numbers are just used for the ISAR but handled a lot. When optimizing for speed you just want to change high or low octal digit and not use the option to first load a number and set that to ISAR. It's often done in 1 cycle instead of 2 or 3 - it adds up - especially with the slowest graphics update for any color videogame ever(?). Using cartridge SRAM is at least 2,5 cycle for any read or write.

To be able to work with it I have used a register list at the top of the code document - with a translation list in octal, decimal and hex.
Reason for this is that coding is done with octal numbers, the debugger registers are listed in decimal and register selection in ISAR is shown in hex.
If "IS" displays "34" in the debugger - which register is it, what is set in the code? (value can be viewed in R52 and it's set as the octal number 64 in the code).
It's important for speed as well as keeping track as an increase or decrease (with this system) doesn't use carry. Increase 67 and you get 60, decrease 50 and you get 57 - the individual octal digits matter, it's an octal banks of registers. You can toggle circular in eight banks.

If a register list is reintroduced and instead got names with hex numbers - it would save the extra decimal translation (for me at least). I'm sure there are people doing this translation in their heads - I do too, some decimal vs hex - but octal... it's a bit odd, only a few values have stuck.

Ideally would be to see the same information in the debugger as is used in the code - octal numbers in the register names and octal numbers shown in "IS" but I understand it's odd and perhaps difficult to include as it's a special case.

I like the "Registers as memory" it's great to be able to watch it that way as well.
© Forums