Current snapshot of Stella debugger

[+stephena]

Just wanted to update everyone on the status of the debugger that will be in Stella 2.0. We hope to release it in the first week of September, and it looks like we'll make the target. Anyway, I'm attaching a snapshot as taken from todays CVS code. The large empty space to the bottom right will be for the source-level debugger (ie, it will show your source code and comments, and trace through the program, highlighting the line at PC).

 

Steve

[vdub_bobby]

Just wanted to update everyone on the status of the debugger that will be in Stella 2.0.  We hope to release it in the first week of September, and it looks like we'll make the target.  Anyway, I'm attaching a snapshot as taken from todays CVS code.  The large empty space to the bottom right will be for the source-level debugger (ie, it will show your source code and comments, and trace through the program, highlighting the line at PC).

That looks really cool! Great to see that you fit everything on screen at once.

Edited August 10, 2005 by vdub_bobby

[+stephena]

Just wanted to update everyone on the status of the debugger that will be in Stella 2.0.  We hope to release it in the first week of September, and it looks like we'll make the target.  Anyway, I'm attaching a snapshot as taken from todays CVS code.  The large empty space to the bottom right will be for the source-level debugger (ie, it will show your source code and comments, and trace through the program, highlighting the line at PC).

That looks really cool! Great to see that you fit everything on screen at once.

908535[/snapback]

Almost everything. The 'TIA' tab will need to be selected to see TIA info, but the "I/O" part of the RIOT will probably need to go into another tab. And of course, if you want to type commands, you have to switch to the prompt. So some tabbing will still be required, but that's all we can do.

 

There really is a crapload of stuff in the 2600, and it's just impossible for everything to fit on the screen at the same time. I know PCAE does it, but it also doesn't include half the things in the debugger that Stella does/will.

 

Steve

[potatohead]

Just gave this a go tonight. Thanks for all your hard work guys.

 

I had a lot of fun stepping through my game, watching what happens exactly when. Learned a ton already. Having everything integrated sure is nice. GUI sharp, clean and responsive.

 

Whoever chose the color scheme and overall layouts --thank you for that. Easy on the eyes and very easy to process what is happening. Can't wait for the source level debugger.

 

Was playing with the step, scanline and frame functions. Very nice display of in-program action. The cycles make sense to me, while on a scanline. Is the graphical display supposed to reflect actual on-screen changes when step is being used? I didn't see any updates until I chose either scan or frame.

 

[Thomas Jentzsch]

Looking great!

 

Some "nice to haves" for the display from me:

- display the registers (A,X,Y) in binary and decimal format too (changed bits /values should be highlighted)

- display the current read/write TIA values (e.g. ------1- for ENAxy)

- add a hint inside the RAM-values, where the stack-pointer points too

- show on the game screen where we currently are (e.g. by a marker or by making the display from the previous frame a bit darker)

- the current timer value (and intervall) would be nice

 

I haven't tested the dbugger at all yet, so maybe some of my suggestions are already there.

[+stephena]

Whoever chose the color scheme and overall layouts --thank you for that.

Thank the ScummVM guys for the color scheme; the GUI widgets are based on their code. Thank the Stella list guys for wanting most everything on the screen at once. I agree that it looks much better than what I started with (having to use tabs for everything).

Was playing with the step, scanline and frame functions.  Very nice display of in-program action.  The cycles make sense to me, while on a scanline.  Is the graphical display supposed to reflect actual on-screen changes when step is being used?  I didn't see any updates until I chose either scan or frame.

Yes, all changes to the TIA should be shown. You've encountered a small bug that I'll fix sometime today. I'll also be adding a small visual indicator on where the electron beam currently is.

 

Steve

[+stephena]

Looking great!

 

Some "nice to haves" for the display from me:

- display the registers (A,X,Y) in binary and decimal format too (changed bits /values should be highlighted)

- display the current read/write TIA values (e.g. ------1- for ENAxy)

- add a hint inside the RAM-values, where the stack-pointer points too

- show on the game screen where we currently are (e.g. by a marker or by making the display from the previous frame a bit darker)

- the current timer value (and intervall) would be nice

 

I haven't tested the dbugger at all yet, so maybe some of my suggestions are already there.

908961[/snapback]

1) The infrastructure is there to show registers in decimal or binary, but a button hasn't been added yet to make the change. The change can be made from the command prompt, though. Currently, the register is highlighted if it changed since last update (same is true of RAM). We don't go to the bit level of detail though; if a value changes, the cell is highlighted, not specific bits in the value.

 

2) This will be in the TIA tab. Methods already exist that expose that info, I just need to add widgets so one can see it.

 

3) Will have to look into this one. Seems easy enough.

 

4) Already mostly done. See my post above for a description.

 

5) Have to look into this one. Probably the methods already exist to do it, and I just need to display it onscreen.

 

Steve

[Luigi301]

WOW! That could really help me figure out why my Batari Basic games don't work!

[mos6507]

This is making me feel better about proctrastinating on Death Derby, to know that when I do get back to it I'll have the holy grail of source-level debugging.

 

I think the big deal for me is being able to display ram and register values as decimal, hex, or binary, and to be able to preserve those settings in the state file or some other mechanism--even if it doesn't have that scroll window approach I was proposing.

 

The binary is important for graphics and when I've got lots of different flags stored in a single byte. I wouldn't want to have to rollover and/or click a box every time I wanted to see the decimal or binary value.

[xucaen]

Where will this debugger be available for download? It looks darn nice!

 

 

Jim

[+stephena]

Where will this debugger be available for download? It looks darn nice! 

910179[/snapback]

The debugger isn't standalone, but is actually part of the Stella emulator. And that can be downloaded from http://stella.sf.net. We hope to do a release including the debugger in a month or so. This will be the first official release of Stella with an integrated debugger.

 

Steve

[mos6507]

How is the debugger going to handle carts with RAM in them like the Supercharger?

 

Will the debugger be able to track writes to cart RAM? The emulator itself has to, although the opcodes that make the write happen is dependent on the cart type (for instance, Supercharger does it with CMP).

[+stephena]

How is the debugger going to handle carts with RAM in them like the Supercharger?

For the 2.0 release, it won't handle that RAM at all. Remember, this is the first time that Stella has ever included a debugger, so there are some things we had to leave out. We'll trying to include support for debugging common games, but the more esoteric the game, the more likely that Stella 2.0 won't be able to handle it. Of course, we'll be expanding the debugger support until it's complete, but we have to draw the line somewhere and do a release.

Will the debugger be able to track writes to cart RAM?  The emulator itself has to, although the opcodes that make the write happen is dependent on the cart type (for instance, Supercharger does it with CMP).

We'll deal with that issue when we add support to the debugger for it. And at that point, the RamWidget may have to be modified to be a scrolling list, just as you suggested. But it won't happen for the 2.0 release.

 

Steve

[mos6507]

BTW, how does the emulator portion of Stella currently handle Supercharger multiload games? Do the loads have to have a naming convention or something?

[+stephena]

BTW, how does the emulator portion of Stella currently handle Supercharger multiload games?  Do the loads have to have a naming convention or something?

911034[/snapback]

Stella expects just a single ROM. So if it has multiple parts, they'll need to be combined into one binary. Using 'cat' in Linux/OSX or similar in DOS to do this. Once you have the single binary, it will work like any other ROM.

[mos6507]

BTW, how does the emulator portion of Stella currently handle Supercharger multiload games?  Do the loads have to have a naming convention or something?

911034[/snapback]

Stella expects just a single ROM. So if it has multiple parts, they'll need to be combined into one binary. Using 'cat' in Linux/OSX or similar in DOS to do this. Once you have the single binary, it will work like any other ROM.

911666[/snapback]

 

What would happen if a game called for a load out of sequence?

 

Does Stella just blindly call the next sequential load regardless of the value of the load ID or does it interrogate the ROMs to try to find the right load?

 

This is very important for future games because the Supercharger can theoretically support random access loads. The Cuttle Cart made that practical for the first time by displaying the load ID (otherwise you'd be running blind unless a game manually displayed it before jumping to the BIOS ROM).

[+stephena]

BTW, how does the emulator portion of Stella currently handle Supercharger multiload games?  Do the loads have to have a naming convention or something?

911034[/snapback]

Stella expects just a single ROM. So if it has multiple parts, they'll need to be combined into one binary. Using 'cat' in Linux/OSX or similar in DOS to do this. Once you have the single binary, it will work like any other ROM.

911666[/snapback]

 

What would happen if a game called for a load out of sequence?

 

Does Stella just blindly call the next sequential load regardless of the value of the load ID or does it interrogate the ROMs to try to find the right load?

 

This is very important for future games because the Supercharger can theoretically support random access loads. The Cuttle Cart made that practical for the first time by displaying the load ID (otherwise you'd be running blind unless a game manually displayed it before jumping to the BIOS ROM).

912715[/snapback]

I'm not sure. If you can provide such sample ROM(s), I can test it and possibly add support for it before the next release.

[mos6507]

I'm not sure.  If you can provide such sample ROM(s), I can test it and possibly add support for it before the next release.

913073[/snapback]

 

Okay, I hope to have a demonstration of random access multiloads within the next two weeks maximum. Bob Colbert's going to be working on some new tutorial materials for the Supercharger so I'm work with him on this. He's much more of an expert on it than I am right now.

[Eckhard Stolberg]

What would happen if a game called for a load out of sequence?

 

Does Stella just blindly call the next sequential load regardless of the value of the load ID or does it interrogate the ROMs to try to find the right load?

 

This is very important for future games because the Supercharger can theoretically support random access loads.  The Cuttle Cart made that practical for the first time by displaying the load ID (otherwise you'd be running blind unless a game manually displayed it before jumping to the BIOS ROM).

912715[/snapback]

I'm not sure. If you can provide such sample ROM(s), I can test it and possibly add support for it before the next release.

913073[/snapback]

I'm pretty sure that Stella already supports random access loads (as does z26). The additional loads for all the games have individual load numbers, so you'll have to check the load number byte in the headers to find out if the requested load is included in the binary anyway. And "Escape from the Mind Master" is skippping loads when you lose all your lives in an early level and then need to go to the evaluation screen in the last load.

 

But if you want to try out if it really works, you could create a new binary for "Escape of the Mind Master" where all the additional loads are in reversed order. If you could still play through several loads normally, then random access loads are working.

 

 

Ciao, Eckhard Stolberg

[+stephena]

I'm pretty sure that Stella already supports random access loads (as does z26). The additional loads for all the games have individual load numbers, so you'll have to check the load number byte in the headers to find out if the requested load is included in the binary anyway. And "Escape from the Mind Master" is skippping loads when you lose all your lives in an early level and then need to go to the evaluation screen in the last load.

Semi-confirmed from looking at the CartAR class. It seems to do a linear search when looking for a certain load. But Stella still expects everything to be concatenated into one ROM file; it seems to figure out the load position automatically.

But if you want to try out if it really works, you could create a new binary for "Escape of the Mind Master" where all the additional loads are in reversed order. If you could still play through several loads normally, then random access loads are working.

I'd be willing to fully confirm this if someone can provide such a modified ROM.

[+stephena]

Just an update on the Stella debugger, including a new snapshot. The TIA tab is almost completely finished (sound and I/O stuff will probably have to go in another tab). Note that the GRP0, GRP1 and PF registers are shown in bitmap form, drawn in the current color for the specific register. Also notice the top of the TIA image, where in scanline step mode the bottom half of the image represents the old frame data and is greyed out. I turned off PF reflect for a few scan lines and then turned it on again, just to illustrate that it works

[Thomas Jentzsch]

[mos6507]

Just an update on the Stella debugger, including a new snapshot.  The TIA tab is almost completely finished (sound and I/O stuff will probably have to go in another tab).  Note that the GRP0, GRP1 and PF registers are shown in bitmap form, drawn in the current color for the specific register.  Also notice the top of the TIA image, where in scanline step mode the bottom half of the image represents the old frame data and is greyed out.  I turned off PF reflect for a few scan lines and then turned it on again, just to illustrate that it works

915151[/snapback]

 

This is almost everything I could have hoped for for the TIA panel. However, if you could, please show the backup registers for (GRP0/1a as they have been called on Stellalist) also, and the ball. Indicating whether VDEL is on or not is nice, but being able to see the data move through the backup registers and how this interacts with VDEL is an important tool in understanding VDEL. So you'd have the "effective" data that it uses to draw with, and the backup value. You can then put an outline or some other indicator around the register that is actually being used by TIA to draw with.

 

Logically this would be visualized best by stacking the display on top something like this:

 

XXXXXX GRP1

>XXXXXX GRP1a

 

 

>XXXXXX GRP0

XXXXXX GRP0a

 

 

 

I think you can free up some space for this by moving your definition for some of your fields from next to the field to on top of the fields like a column header. This would free up some space in the missile zone for sure and you could move it around.

[+stephena]

This is almost everything I could have hoped for for the TIA panel.  However, if you could, please show the backup registers for (GRP0/1a as they have been called on Stellalist) also, and the ball.  Indicating whether VDEL is on or not is nice, but being able to see the data move through the backup registers and how this interacts with VDEL is an important tool in understanding VDEL.  So you'd have the "effective" data that it uses to draw with, and the backup value.  You can then put an outline or some other indicator around the register that is actually being used by TIA to draw with.

Sounds like a good idea, but it will have to wait until 2.1 (which already has a growing list of TODOs). We have to concentrate on the source-level debugger and TIA zoom image stuff for now.

[mos6507]

We have to concentrate on the source-level debugger and TIA zoom image stuff for now.

 

The source-level debugger is definitely a higher priority. That is going to rock bigtime.