Why Stella over Z26?

[+stephena]

Will this finally fix the Solaris takeoff glitch?

Yes, it is supposed to. Of course, I haven't actually tested the code yet, but this bug is on the TODO list.

I've always used Z26 with the X26 frontend, but I've noticed a lot of people on here prefer Stella. I'm curious why?

 

Maybe I'll convert.

 

The biggest factor for me is the remapping of "everything" is possible as well as mapping multiple inputs to one Atari/Emulator setting.

 

For instance, I can map Joypad Hat Up, Joystick Up, Arrow Up, Num Pad 8, all to perform the same function as Player 1's joystick up on the Atari.

 

MESS has the same advantage as well (Being able to map multiple devices/inputs to one Atari/Emulator setting).

 

-Trebor

 

That's something that bugs me about Stella also. The classes that handle control are too literal and they set up a needless barrier. It really should be more low level so you can map whatever physical controller parameter to whatever virtual 2600 controller signal. Then you'd be able to simulate custom controllers. Otherwise you have to wait for Stella to come up with a specific controller type for every custom controller idea. I ran into this problem with Death Derby because Stella has a dedicated "driving controller" simulation but doesn't let you also map any extra buttons which are possible on the real thing.

You mentioned that in the past, but I've always had trouble understanding how to do this in a user-friendly and easy to code fashion. AFAIK, no emulator in existence does this; most work on the assumption of several different built-in controllers types, and allow you to map to different buttons/axes, etc to those controllers. What you seem to need is a way to create a custom controller in software (ie; a controller that hasn't been compiled into Stella). I'd really need to think about how to do this.

 

As for going lower level, I don't think that's a good idea for the general user. Most people would want to map, for example, joystick button 2 to 'Fire'; they wouldn't be thinking of controller pins or signals, and nor should they have to. What you really need is a 'CustomController' class, with the ability to completely define its functionality at runtime, not compile time. Again, I really need to think about how to do this. Does anyone know of another emulator that works this way??

[DEBRO]

So you're saying it would be better to show the scanline count on the screen while in emulation mode (like -n in z26)? Or that the trace file in general is more useful for finding things?? The current debugger is more geared to 'immediate mode' debugging, while a trace file is a 'run and inspect later' type of thing. There's nothing to prevent us from adding such a mode to Stella; in fact, there's already code there to do that (but it's commented out). I just figured it was easier to find things in immediate mode. But I'll definitely look into adding a trace mode as well, as it doesn't seem too difficult to do.

The frame count on the screen is nice. The trace file is more suitable for finding why a screen may be unstable.

 

I like immediate mode so I can break into a specific routine to see what's going on. Actually I've found that I've been "spoiled" by Stella because I can do this. None of the 7800 emulators do this and it's causing me more work. But that's also because my code wasn't correct so it always falls back to me

 

Trace mode is good for things like finding the culprit for the screen to output too many scan lines. When looking at Pacman4K, I could find the frame that had too many scan lines and trace up in the log to find the routine in question that needed to be optimized better for speed.

[+stephena]

This may not apply to the most recent versions of Stella, but I prefer Z26 on Windows because the last time I used Stella, it would always end up switching to 320x240 at some point, even though I would tell it to use my desktop resolution. I have a particular problem with 320x240; when using the DVI connection, my video card outputs a small, vertically-stretched picture that doesn't fill the entire screen.

 

It would be nice if I could tell Stella exactly what resolution to use.

Yes, this bug has been fixed. Windowed modes are now specified by their 'zoom level' (ie, 1, 2, 3), and fullscreen modes are specified by actual resolution (1024x768, 800x600, etc). I suggest you try the latest version (2.4.2).

[+stephena]

So you're saying it would be better to show the scanline count on the screen while in emulation mode (like -n in z26)? Or that the trace file in general is more useful for finding things?? The current debugger is more geared to 'immediate mode' debugging, while a trace file is a 'run and inspect later' type of thing. There's nothing to prevent us from adding such a mode to Stella; in fact, there's already code there to do that (but it's commented out). I just figured it was easier to find things in immediate mode. But I'll definitely look into adding a trace mode as well, as it doesn't seem too difficult to do.

The frame count on the screen is nice. The trace file is more suitable for finding why a screen may be unstable.

 

I like immediate mode so I can break into a specific routine to see what's going on. Actually I've found that I've been "spoiled" by Stella because I can do this. None of the 7800 emulators do this and it's causing me more work. But that's also because my code wasn't correct so it always falls back to me

 

Trace mode is good for things like finding the culprit for the screen to output too many scan lines. When looking at Pacman4K, I could find the frame that had too many scan lines and trace up in the log to find the routine in question that needed to be optimized better for speed.

I was planning to add the onscreen scanline counter for the next release, once I find a suitable font. As for the trace mode, I'll definitely look into it. There's also the possibility to view such a trace file in the debugger itself, but perhaps I'm getting ahead of myself.

[+batari]

The frame count on the screen is nice. The trace file is more suitable for finding why a screen may be unstable.

 

I like immediate mode so I can break into a specific routine to see what's going on. Actually I've found that I've been "spoiled" by Stella because I can do this. None of the 7800 emulators do this and it's causing me more work. But that's also because my code wasn't correct so it always falls back to me

 

Trace mode is good for things like finding the culprit for the screen to output too many scan lines. When looking at Pacman4K, I could find the frame that had too many scan lines and trace up in the log to find the routine in question that needed to be optimized better for speed.

I was planning to add the onscreen scanline counter for the next release, once I find a suitable font. As for the trace mode, I'll definitely look into it. There's also the possibility to view such a trace file in the debugger itself, but perhaps I'm getting ahead of myself.

I will agree that something like trace mode would be nice. When a game occasionally takes too many scanlines, the debugger will catch this only when it's already too late (i.e. using breakif {_scan == #263}.)

 

This may sound silly, but I never really liked z26 trace mode, as poring over a 100+ MB file that z26 creates in a few seconds that may or may not contain your bug was always less than pleasant.

 

So for Stella, another solution may be a special mode where Stella does an automatic savestate at the beginning of every frame, so you can literally go back in time by one frame and analyze in detail what happened to send you over the limit.

 

EDIT: For this to work, Stella would also need to remember the state of the controllers and console switches during the previous frame, but that shouldn't be too complicated (I think).

Edited September 21, 2007 by batari

[SeaGtGruff]

I'm still working on 4A50 support, but I don't know if it will be ready for the next major release (hopefully it will). As for the second issue, where can I get that ROM? I've never tested it before, so I don't know if it can be made to work or not.

Unfortunately, you can't, because it hasn't been released. But there may be a similar ROM that would behave the same way; I'll see if I can find one.

 

Michael

[SeaGtGruff]

I actually still use Z26. Maybe out of habit. I've got Textpad setup to run both but I generally send my binary through Z26. When I need to step through code though I send it through Stella for it's debugger which is great. Sometimes though the debugger doesn't give me what I need so I send it through Z26 with a trace. Overall...I still use Z26.

It's good to hear that both are working with your development setup. But it would be nice to hear what debugger stuff you're not getting, because that's probably a bug that should be fixed. I know you posted a message about this a while back, but it would be nice to get a more detailed report (especially by someone who's doing active development).

I don't know about anyone else, but one thing I'd like to see added to the debugger screen is the RIOT chip. You have a tab that shows the TIA registers, and there's the area that shows the zero-page RAM contents, and the 6502 registers, etc., but there are no RIOT registers shown.

 

Another possibility might be a second RAM window for the SARA chip or Superchip RAM (if applicable).

 

Michael

[+stephena]

I'm still working on 4A50 support, but I don't know if it will be ready for the next major release (hopefully it will). As for the second issue, where can I get that ROM? I've never tested it before, so I don't know if it can be made to work or not.

Unfortunately, you can't, because it hasn't been released. But there may be a similar ROM that would behave the same way; I'll see if I can find one.

 

Michael

Then how do you know it works in z26?

[+stephena]

I actually still use Z26. Maybe out of habit. I've got Textpad setup to run both but I generally send my binary through Z26. When I need to step through code though I send it through Stella for it's debugger which is great. Sometimes though the debugger doesn't give me what I need so I send it through Z26 with a trace. Overall...I still use Z26.

It's good to hear that both are working with your development setup. But it would be nice to hear what debugger stuff you're not getting, because that's probably a bug that should be fixed. I know you posted a message about this a while back, but it would be nice to get a more detailed report (especially by someone who's doing active development).

I don't know about anyone else, but one thing I'd like to see added to the debugger screen is the RIOT chip. You have a tab that shows the TIA registers, and there's the area that shows the zero-page RAM contents, and the 6502 registers, etc., but there are no RIOT registers shown.

 

Another possibility might be a second RAM window for the SARA chip or Superchip RAM (if applicable).

 

Michael

The RIOT and extended RAM debugger stuff are still on the TODO list. The debugger itself is still missing some important features; those are two of them. Perhaps it's time to start hounding Brian Watson again.

[+stephena]

The frame count on the screen is nice. The trace file is more suitable for finding why a screen may be unstable.

 

I like immediate mode so I can break into a specific routine to see what's going on. Actually I've found that I've been "spoiled" by Stella because I can do this. None of the 7800 emulators do this and it's causing me more work. But that's also because my code wasn't correct so it always falls back to me

 

Trace mode is good for things like finding the culprit for the screen to output too many scan lines. When looking at Pacman4K, I could find the frame that had too many scan lines and trace up in the log to find the routine in question that needed to be optimized better for speed.

I was planning to add the onscreen scanline counter for the next release, once I find a suitable font. As for the trace mode, I'll definitely look into it. There's also the possibility to view such a trace file in the debugger itself, but perhaps I'm getting ahead of myself.

I will agree that something like trace mode would be nice. When a game occasionally takes too many scanlines, the debugger will catch this only when it's already too late (i.e. using breakif {_scan == #263}.)

 

This may sound silly, but I never really liked z26 trace mode, as poring over a 100+ MB file that z26 creates in a few seconds that may or may not contain your bug was always less than pleasant.

 

So for Stella, another solution may be a special mode where Stella does an automatic savestate at the beginning of every frame, so you can literally go back in time by one frame and analyze in detail what happened to send you over the limit.

 

EDIT: For this to work, Stella would also need to remember the state of the controllers and console switches during the previous frame, but that shouldn't be too complicated (I think).

Something like this is still on the TODO list as well. In fact, that requirement is also shared by movie support and network support, two other highly antipated features. It will be added eventually. I suspect that when all this starts to 'gel' together in my brain, all those features will quickly follow.

[vdub_bobby]

I use both very frequently when coding and Stella almost exclusively when "just" playing.

 

z26's emulation is *very* accurate, really only inaccurate on the most extreme margins. Stella's emulation is much less accurate, I run into inaccurate emulation frequently when coding. Plus the onscreen, realtime scanline count (in z26) is very helpful. I use the Stella debugger a lot, much more than z26's log files, but the z26 logging still comes in handy (just used it yesterday, actually).

 

But for ease of use when I just want to play a game, Stella takes the cake.

Edited September 21, 2007 by vdub_bobby

[Trebor]

That's something that bugs me about Stella also...

 

I didn't mean to imply it was a feature that bugged me about Stella, but actually one of its main strong points. Again, MESS allows for remapping of multiple devices/inputs to nearly everything as well. Z26 does not support this feature (Unfortunately).

 

-Trebor

[mos6507]

The RIOT and extended RAM debugger stuff are still on the TODO list. The debugger itself is still missing some important features; those are two of them. Perhaps it's time to start hounding Brian Watson again.

 

Does that mean we'll be able to step-debug through disassembled zero-page code?

 

As it is now when any of the contents of cart ROM change (either through bankswitching or RAM writes) the debugger does or doesn't show it?

[SeaGtGruff]

I'm still working on 4A50 support, but I don't know if it will be ready for the next major release (hopefully it will). As for the second issue, where can I get that ROM? I've never tested it before, so I don't know if it can be made to work or not.

Unfortunately, you can't, because it hasn't been released. But there may be a similar ROM that would behave the same way; I'll see if I can find one.

 

Michael

Then how do you know it works in z26?

It was released to *me* to see if I can tweak it a bit. I can play the original BIN-- or recompile the source and play the recompiled BIN-- on z26 without a problem, but it gets hung up when I try it on Stella. I'm not sure what the problem is, but if I can figure anything out, I'll let you know. It uses the Tigervision bankswitching, so I may write a simple Tigervision test program and see if it works.

 

Michael

[SeaGtGruff]

Does that mean we'll be able to step-debug through disassembled zero-page code?

That would be nice!

 

As it is now when any of the contents of cart ROM change (either through bankswitching or RAM writes) the debugger does or doesn't show it?

If I'm not mistaken, the disassembly/code window does show the instructions from the correct ROM bank when bankswitching occurs, and it also shows you which bank you're in.

 

Michael

[supercat]

I was planning to add the onscreen scanline counter for the next release, once I find a suitable font. As for the trace mode, I'll definitely look into it. There's also the possibility to view such a trace file in the debugger itself, but perhaps I'm getting ahead of myself.

 

I'd like a 'rolling graph' that would show the scan line count on a per-frame basis (with 262 or 312 being the vertical center, scaled so even a +/-1 deviation would be noticeable. If a program occasionally misses the target, that may be hard to see on Z26's counter.

[supercat]

This may sound silly, but I never really liked z26 trace mode, as poring over a 100+ MB file that z26 creates in a few seconds that may or may not contain your bug was always less than pleasant.

 

I'd like to see an ability to keep a 'rolling log' file which keeps the last meg or so in RAM but can be written out to disk when triggered. Further, it may be useful to have the log file simply store memory accesses, tagged by type (opcode fetch, other read, or write) and--when meaningful--cycle, frame, and scan line counts along with TIA state (do a full dump once/frame, and update things at other times when relevant). A viewer utility could reconstruct a more detailed trace from that.

[+stephena]

This may sound silly, but I never really liked z26 trace mode, as poring over a 100+ MB file that z26 creates in a few seconds that may or may not contain your bug was always less than pleasant.

 

I'd like to see an ability to keep a 'rolling log' file which keeps the last meg or so in RAM but can be written out to disk when triggered. Further, it may be useful to have the log file simply store memory accesses, tagged by type (opcode fetch, other read, or write) and--when meaningful--cycle, frame, and scan line counts along with TIA state (do a full dump once/frame, and update things at other times when relevant). A viewer utility could reconstruct a more detailed trace from that.

I think Bataris suggestion was basically the same; generate a savestate once per frame, with the ability to roll back when necessary (aka, a rewind). Seeing how the typical state file is ~1KB (except for carts with huge amounts of RAM), that would be about 60KB per second, or 3600KB per minute. So 1 minute of state could be done in ~3.6MB, or 10 minutes in 36MB. I think 10 minutes would be more than enough to detect a problem. And since state files are currently sent to a buffered stream, writing them internally or to an external file is basically the same thing. Once you determine which frame caused the issue, you could issue a 'save to external file' command to save detailed information about the frame. I really think this could replace all the functionality of a trace file. Because even with a trace file, you need to manually search through it. Why not do that in immediate mode directly in the debugger?

[+SpiceWare]

I think 10 minutes would be more than enough to detect a problem.

I had some screen jitter issues in MM that took longer than 10 minutes before they'd show up.

[+stephena]

I think 10 minutes would be more than enough to detect a problem.

I had some screen jitter issues in MM that took longer than 10 minutes before they'd show up.

Well, that '10 minutes' would be the most recent 10 minutes, not 10 minutes from when the game started (ie, it would be a rolling log). And the 10 minutes was just an example number I picked. It would depend on the amount of RAM and/or disk space you have. There could be a setting stating how long to keep saving state (ie, the amount of RAM you want to commit, or the number of seconds/minutes/frames/whatever to use). So the '10 minutes' would really be the size of the buffer 'window'. In theory, if you were watching the emulation and immediately stopped when you saw a glitch, a 1 minute buffer would be sufficient. I'm actually getting kind of excited about this feature, since I think I have a fairly clear picture of how it would work.

 

In fact, this feature could be used with the breakif function. For example, you could do a 'breakif {_scan > 262 }', and just let the emulator run until it happens. Then, once it breaks, there could be a 'rewind' command that goes back the specified number of frames. Then you could single-step through the frame to determine exactly what caused the overrun. Hmm, exciting stuff

Edited September 22, 2007 by stephena

[supercat]

In theory, if you were watching the emulation and immediately stopped when you saw a glitch, a 1 minute buffer would be sufficient. I'm actually getting kind of excited about this feature, since I think I have a fairly clear picture of how it would work.

 

Even a one-second buffer would often be sufficient if the operator was attentive. When used with breakpoints, even a two-frame buffer would be adequate in most cases.

[+stephena]

In theory, if you were watching the emulation and immediately stopped when you saw a glitch, a 1 minute buffer would be sufficient. I'm actually getting kind of excited about this feature, since I think I have a fairly clear picture of how it would work.

 

Even a one-second buffer would often be sufficient if the operator was attentive. When used with breakpoints, even a two-frame buffer would be adequate in most cases.

You're right of course, but if (when!) I add this feature, it will also be very useful to the general end-user. I know of at least one emulator that has a rewind feature for general game playing. Both of these are classes of the same problem. The only thing that changes is the granularity of the saves (developer would want it per-frame, while end user would want it per-second, or even per-minute). The easiest thing to do is simply make it all configurable (how often to save, how large a buffer, etc). The only possible issue would be performance in the case of saving once per frame. But when you're using advanced debugger features, I guess some slowdown should be expected.

[Eckhard Stolberg]

It was released to *me* to see if I can tweak it a bit. I can play the original BIN-- or recompile the source and play the recompiled BIN-- on z26 without a problem, but it gets hung up when I try it on Stella. I'm not sure what the problem is, but if I can figure anything out, I'll let you know. It uses the Tigervision bankswitching, so I may write a simple Tigervision test program and see if it works.

Which version of the Tigervision 3F bankswitching does the Tron Man Picture Cart use? There is one version where the last 2K in the binary are used for the fixed bank at $f800-$ffff, because this is how a normal 3F cart would work. But z26 also supports a 3F mode where the 4th 2K page in the binary is used for the fixed bank at $f800-$ffff. This was added because it's how the original Cuttle Cart works with Tigervision games up to 64K.

 

I think Stella only supports the first 3F bankswitching method but not the second one. And IIRC Andrew Davie's ChronoColour picture demos were developed on a Cuttle Cart using 3F bankswitching. So if the Tron Man Picture Cart is based on this code, it might be the reason why it doesn't work in Stella.

 

 

Ciao, Eckhard Stolberg

[supercat]

The only possible issue would be performance in the case of saving once per frame. But when you're using advanced debugger features, I guess some slowdown should be expected.

 

How big is the game state? 33K max, even for 4A50 I'd think. So buffering that 60x/second would be about two meg/second. Use a 4 meg rolling buffer in RAM and I wouldn't imagine any slowdown.

 

Though actually it's not necessary to save game states that often. It should suffice to simply log the initial system state and all controller changes along with the times they were sampled (number of cycles from start). With proper handling, that data would probably total less than a K per second at most, even with games that heavily poll the controllers. So for many scenarios, one could log continuously even for hours on end. If one didn't have intermediate save states, it may take a little while to recreate the system state an hour into the emulation, but even a save state once per minute should make things practical.

[+stephena]

It was released to *me* to see if I can tweak it a bit. I can play the original BIN-- or recompile the source and play the recompiled BIN-- on z26 without a problem, but it gets hung up when I try it on Stella. I'm not sure what the problem is, but if I can figure anything out, I'll let you know. It uses the Tigervision bankswitching, so I may write a simple Tigervision test program and see if it works.

Which version of the Tigervision 3F bankswitching does the Tron Man Picture Cart use? There is one version where the last 2K in the binary are used for the fixed bank at $f800-$ffff, because this is how a normal 3F cart would work. But z26 also supports a 3F mode where the 4th 2K page in the binary is used for the fixed bank at $f800-$ffff. This was added because it's how the original Cuttle Cart works with Tigervision games up to 64K.

 

I think Stella only supports the first 3F bankswitching method but not the second one. And IIRC Andrew Davie's ChronoColour picture demos were developed on a Cuttle Cart using 3F bankswitching. So if the Tron Man Picture Cart is based on this code, it might be the reason why it doesn't work in Stella.

 

 

Ciao, Eckhard Stolberg

Yes, only the first method is supported in Stella. So if someone could provide a ROM that demonstrates this second scenario, I'm sure it could be easily fixed.