Stella 5.0 released

[Thomas Jentzsch]

A few people even said that "why wouldn't we want to trap on mirrors?

That was me thinking too short only about TIA, RAM etc.

[alex_79]

What about a conditional trap command using the existing stella functions and pseudo_ops?

The syntax could be something like this:

trapif 		<condition> 	<address or range>
trapwriteif 	<condition> 	<address or range>
trapreadif 	<condition> 	<address or range>

So you could use

trapreadif _bank==1 BE00 BEFF

to stop emulation on read from addresses $BE00 to $BEFF (and mirrors), only if bank 1 is active.

The reason to still check all mirrors is that it's in theory possible to use different mirrors in the same bank, just like using the same addresses in different banks.

Edited August 12, 2017 by alex_79

[Thomas Jentzsch]

Very good suggestion. Many multi bank ROMs have all their banks assembled to the same ORG, so this would definitely help debugging them. Please create an "Enhancement" issue for this.

 

It is more accurate that way.

Edited August 12, 2017 by Thomas Jentzsch

[RevEng]

The conditions make me think of the MAME debugger, which may have some ideas that would be worth poaching. Here are the docs on setting a watchpoint.

 

 

 

wpset,

wp[{d|i}][set] <address>,<length>,<type>[,<condition>[,<action>]]

Sets a new watchpoint starting at the specified <address> and extending for <length>. The
inclusive range of the watchpoint is <address> through <address> + <length> - 1. The 'wpset'
command sets a watchpoint on program memory; the 'wpdset' command sets a watchpoint on data
memory; and the 'wpiset' sets a watchpoint on I/O memory. The <type> parameter specifies
which sort of accesses to trap on. It can be one of three values: 'r' for a read watchpoint
'w' for a write watchpoint, and 'rw' for a read/write watchpoint.

The optional <condition> parameter lets you specify an expression that will be evaluated each
time the watchpoint is hit. If the result of the expression is true (non-zero), the watchpoint
will actually halt execution; otherwise, execution will continue with no notification. The
optional <action> parameter provides a command that is executed whenever the watchpoint is hit
and the <condition> is true. Note that you may need to embed the action within braces { } in
order to prevent commas and semicolons from being interpreted as applying to the wpset command
itself. Each watchpoint that is set is assigned an index which can be used in other
watchpoint commands to reference this watchpoint.

In order to help <condition> expressions, two variables are available. For all watchpoints,
the variable 'wpaddr' is set to the address that actually triggered the watchpoint. For write
watchpoints, the variable 'wpdata' is set to the data that is being written.

Examples:

wp 1234,6,rw
Set a watchpoint that will halt execution whenever a read or write occurs in the address
range 1234-1239 inclusive.

wp 23456,a,w,wpdata == 1
Set a watchpoint that will halt execution whenever a write occurs in the address range
23456-2345f AND the data written is equal to 1.

wp 3456,20,r,1,{printf \Read @ %08X\\,wpaddr; g}
Set a watchpoint that will halt execution whenever a read occurs in the address range
3456-3475. When this happens, print Read @ <wpaddr> and continue executing.

temp0 = 0; wp 45678,1,w,wpdata==f0,{temp0++; g}
Set a watchpoint that will halt execution whenever a write occurs to the address 45678 AND
the value being written is equal to f0. When that happens, increment the variable temp0 and
resume execution.

 

 

The optional conditions and actions are very useful sometimes. I've used them, for example, to create a log of addresses traversed and banks switched, to auto-determine which parts of a ROM are code. (yeah, I know. Stella's disassembly functionality fabulously does this on it's own )

[alex_79]

Please create an "Enhancement" issue for this.

Done: https://github.com/stella-emu/stella/issues/187

 

I don't know how to add a label to an issue (probably I don't have the rights to do that)

[+Omegamatrix]

What about a conditional trap command using the existing stella functions and pseudo_ops?

The syntax could be something like this:

trapif 		<condition> 	<address or range>
trapwriteif 	<condition> 	<address or range>
trapreadif 	<condition> 	<address or range>

So you could use

trapreadif _bank==1 BE00 BEFF

to stop emulation on read from addresses $BE00 to $BEFF (and mirrors), only if bank 1 is active.

The reason to still check all mirrors is that it's in theory possible to use different mirrors in the same bank, just like using the same addresses in different banks.

 

This is what I was after. There will be cases where I want to break on all the mirrors, and cases where I don't. Also alot of games RORG to the same address so incorporating the bank you are in gets around false triggers.

[alex_79]

I was testing the various "Diagnostic Test Cartridges", and in particular the 2.0 prototype rom.

On real hardware (PAL 7800 and 2600 consoles) the rom gives me an error "6" (joysticks, according to the atariprotos page), while it gives different errors codes in emulators (Mame seems to match real hardware):

Stella 5.0.1 8 (Collisions)
6502.ts 1 (Switches)
Javatari 1 (Switches)
Mame 6 (JOysticks)

I have built the "SALT test plugs" (following the diagram posted here), that work on version 2.6 and 2.6P, but version 2.0 still gives an error 6 with them plugged in, so maybe it requires different plugs, or maybe the schematic is wrong/incomplete.

According to the Atariprotos article, the rom works on real hardware (so it should return a code "9") and it doesn't mention the plugs.

While trying to figure out what the rom was doing, I found out that it causes Stella to freeze most of the time if started with the -debug option (I use Linux, BTW). It usually happens right at the start, while sometimes I can step through the code for a few frames.

Once about every 10 or 15 tries, it works fine.

When it hangs, the only way to stop it is by a "kill -9" from the terminal.

This only seems to happen with this particular rom.

Can someone try starting it in debug mode to see if the problem is with my setup?
DOM2_0.bin

[Thomas Jentzsch]

Same freeze problem here with Windows 10, 64 Bit

 

Please create an issue.

[+stephena]

I was testing the various "Diagnostic Test Cartridges", and in particular the 2.0 prototype rom.

 

While trying to figure out what the rom was doing, I found out that it causes Stella to freeze most of the time if started with the -debug option (I use Linux, BTW). It usually happens right at the start, while sometimes I can step through the code for a few frames.

 

The freezing is fixed in https://github.com/stella-emu/stella/commit/193da6c845cfb2eff9d6412c2ec70d92ecd8f005. The issue of ROM output (6 vs. 8 ) is a regression from Stella 4, and is being looked at.

[+Omegamatrix]

I noticed that trackballs have no firebutton checkboxes in the debugger. Please see if this can be added as I was trying to debug a game but couldn't activate fire in the debugger for the trackball control.

[+stephena]

It doesn't allow movement either, not just the buttons. There's already a request for this in https://github.com/stella-emu/stella/issues/73.

[Thomas Jentzsch]

Making SWCHA ® editable would help for future controllers too.

[JL]

Been asleep the past 3 weeks not realizing this was out. Huge thanks for all your time and effort on Stella 5 !

[zzip]

I've kept the TV Phosphor and Jitter/Roll Effect at their defaults.

 

Right now, I like "Bad adjust" because it adds some fuzz into the image. Lest you are tempted to call me a hypocrite for enjoying this feature, the thing I like MOST about it is that you can TURN IT OFF and enjoy super crisp graphics, too. All without having a nasty-ass cathode ray tube. I was playing this on my silly little plastic blue basically-a-toy HP Stream laptop.

I'm with you on this. The old games were designed to look good on CRTs with their scanlines and other quirks. They often look subpar on LCD, so I appreciate good CRT emulation to make them look like what they are supposed to look like

 

But I have zero desire to go back to real CRT

[Keatah]

I think it's important to use the TV effects. But not to overdo it on the scanlines, or any other setting for that matter. I keep the scanlines just barely visible. 10% maybe.

[Thomas Jentzsch]

I use both worlds:

1. My computer with monitor and Stella and keyboard plus mouse (for development, TV effects only for testing)
2. My computer connected to my TV with Stella and 2600-daptor and real controllers (for playing, with and without TV effects)
3. My 2600 with a CRT and real controllers (for testing and playing)

Edited August 14, 2017 by Thomas Jentzsch

[+splendidnut]

Just downloaded the new version... I'm really liking the new phosphor emulation mode. The flicker (with phosphor mode on) definitely looks closer to what I see on my 1997 CRT TV.

 

Thanks for all your hard work!

[alex_79]

 

I'm really liking the new phosphor emulation mode.

 

Me too. In fact I set it to be enabled for all roms by default.

 

The other settings I'm using are:

Tia Palette: z26

Tia interpolation: linear

TV effects: S-VIDEO

[+Omegamatrix]

Hey Stella Team:

 

1) Is there a way to dump ram to a text file? I tried dump and it shows in the debugger. I would like to be able to export it or at least be able to copy paste it.

2) Stella recently caught a bug for me where I had a cmp ($F7,X) command reading an somewhere that must have had some undefined bits. I am thankful for that, but it was extremely hard to pin down that one line of code. The problem was I once I saw it happen in the debbuger I would rewind and go forward again scanline by scanline, but the undefined value would not be the same when I hit that line of code so it would work. I had the same issue with trying to locate it with savestates.

3) It looks like strobes are now working in the debugger, thank you very much!

4) I made use of "X" and "Y" in the terminal command set by using a breakif statement for pc==address and y==some value. The listing in the debugger seems to imply to me that X an Y can only be used to set a value, but obviously and to our benefit that is not the case. Can this info please be updated to be more clearer?

5) I ran into glitch in Stella with a rom that changes from a splash screen to instruction screen. The first few frames of instruction screen the bottom line of text is unchanged, but as soon after it rises up a few lines. Looking in the debugger the scanline those graphics appear on is the same. I am just taking a guess, but maybe this is some code that automatically adjusts the Y pos start of the display? Something that has been tweeked so that Stella can handle games that change the display count (i.e. PAL --> NTSC) on the fly with a menu?

 

I will PM the rom to you stephena and DirtyHairy.

 

Thanks again for all the hardwork. I know that I am listing a lot of problems here, but I only want to make Stella better.

[Keatah]

Does the architecture of Stella permit the addition of more video effects? We have new phosphor. Maybe we could get more bloom and more edge mixing?

Edited August 18, 2017 by Keatah

[Thomas Jentzsch]

Does the architecture of Stella permit the addition of more video effects? We have new phosphor. Maybe we could get more bloom and more edge mixing?

We are using the Blargg library here. It has some presets and a custom mode where you can play with all available parameters as you like. So if you just want "more" of something already existing, maybe you can do so already.

[Thomas Jentzsch]

1) Is there a way to dump rom to a text file? I tried dump and it shows in the debugger. I would like to be able to export it or at least be able to copy paste it.

2) Stella recently caught a bug for me where I had a cmp ($F7,X) command reading an somewhere that must have had some undefined bits. I am thankful for that, but it was extremely hard to pin down that one line of code. The problem was I once I saw it happen in the debbuger I would rewind and go forward again scanline by scanline, but the undefined value would not be the same when I hit that line of code so it would work. I had the same issue with trying to locate it with savestates.

 

1. saveses should work, no? Or do you want to save the disassembly? Then use savedis

2. A savestate would help here too. I think the random bits are really randomly generated and not reproducible (yet). Probably the current random value is not saved for each debugger step.

Edited August 18, 2017 by Thomas Jentzsch

[Thomas Jentzsch]

@Omega: I suppose you have randomizing unused bits enabled, correct.

[+Omegamatrix]

1. saveses should work, no? Or do you want to save the disassembly? Then use savedis

2. A savestate would help here too. I think the random bits are really randomly generated and not reproducible (yet). Probably the current random value is not saved for each debugger step.

1) Sorry, I meant save RAM to a text file, but I wrote ROM. I just updated my post.

2) That is the problem I found. I am super glad Stella can randomized unused bits, but if I can't step back and forth in the debugger it becomes tough to isolate where the problem occurs.

[+stephena]

Saving the random number from the RNG is supposed to happen on each step. It wasn't, so that is a bug (which I just fixed, BTW). Going backwards in the debugger after exiting the debugger is basically https://github.com/stella-emu/stella/issues/71. I can say with certainty that this won't happen for a while, since there are more pressing issues ATM. We (now that there is a 'we' in the Stella team) will discuss after this upcoming release what should take priority for the release after that.