Previous Thread
Next Thread
Print Thread
Joined: Feb 2014
Posts: 676
Likes: 9
G
Senior Member
OP Offline
Senior Member
G
Joined: Feb 2014
Posts: 676
Likes: 9
I was fiddling with layouts, and it seems so hard to display something like a regular string.

It would be really neat if you could have an element that would show a saveitem, then it would be almost trivial to change the string displayed, just change the save item's variable.

Perhaps even a format string could be used to specify the format, %s %d or %x like

<item name="some_saveitem_variable_name" format="Current Position = %d steps">
</item>

Joined: Feb 2004
Posts: 2,277
Likes: 17
Very Senior Member
Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,277
Likes: 17
No, save state items are intentionally not exposed to layouts. They’re not guaranteed to be stable or to use any particular format for their names.

Joined: Mar 2001
Posts: 16,815
Likes: 36
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,815
Likes: 36
I'm increasingly of the opinion that save state items unconditionally appearing in the debugger was a mistake. It should be opt-in, so the things you (or a user) would actually want to see are easy to find.

Joined: May 2009
Posts: 1,970
Likes: 24
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,970
Likes: 24
Is it that the exposing of all items is a mistake, or that (as far as I know) there's no search function in any of the debuggers for named areas?

Joined: Mar 2001
Posts: 16,815
Likes: 36
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,815
Likes: 36
Both. A mechanism like we have for logging where you can temporarily enable the firehose for specific devices or drivers would be better, I think. A search field would also be nice, but right now a lot of things are shown there that aren't useful unless you're debugging that specific device.

Joined: May 2004
Posts: 1,679
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,679
I'd say the main issue (in the debugger) is that the presentation method is poor. An unrolled list of everything, without so much as the size listed next to it, means it's impossible to find the thing you want due to single byte variables being saved and listed in the drop down. Being able to view memory allocated by drivers etc. that isn't in CPU space is essential though, the hoops people were jumping through prior to that (fake regions in drivers etc.) were polluting the codebase badly (to this day some of those workarounds remain in untouched drivers)

A tree view would help, even just showing the sizes so you can see at a glance which ones are likely to be RAM areas would help.

A menu option to 'save region' when you have a view open would also be great, having to remember the syntax in the debugger and type it is a pain.

Joined: Mar 2001
Posts: 16,815
Likes: 36
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,815
Likes: 36
A tree view wouldn't help to any significant degree. There are 1000+ items by default when I run an Apple II. There's no way to make that many things usable.

RAM areas yes you would want shown at all times, but other stuff is very much a case-by-case basis if showing them is useful at all.

Joined: Dec 2015
Posts: 138
Likes: 1
A
AJR Offline
Senior Member
Offline
Senior Member
A
Joined: Dec 2015
Posts: 138
Likes: 1
I concur that dumping save items into the memory viewer is a crude low-level hack, and the selection menu is quite cluttered, though I've at times used it as a convenient debugging aid.

When device_state_interface was created roughly a decade ago, the idea may have been to enable that for non-CPU devices, but the OSD debugger UIs never actually implemented that. The state view as presently implemented for CPUs doesn't exactly have an ideal presentation either: it can get quite cluttered for highly integrated SoCs with half a dozen or more internal peripherals.

Joined: Mar 2001
Posts: 16,815
Likes: 36
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,815
Likes: 36
It definitely can be convenient, which is why I suggest making showing it in the memory viewer optional. That way you can see all the class members when you need to and just RAM regions/FIFOs/things of that nature when you don't.

Joined: May 2009
Posts: 1,970
Likes: 24
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,970
Likes: 24
I've discussed it with Vas, and I believe there's a good path going forward that should make everyone happy. Give me half a chance to look at it this weekend and we can go from there.

1 member likes this: Darkstar

Link Copied to Clipboard
Who's Online Now
3 members (Dorando, Cpt. Pugwash, 1 invisible), 31 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,981
Posts117,966
Members5,003
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com