Require alpha/beta testers for new version of Stella

[e1will]

Not sure if this is a bug or by design, but I thought I would mention it...

 

I was trying to trap whatever code was modifying the memory in $F4, and neither "watch $F4" or "trapwrite $F4" would cause the debugger to break, even though it kept getting changed.

 

It turns out it was a stack-too-deep problem, and the return addresses getting pushed onto the stack were trashing the value in $F4. Is there any way to trap modifications to memory addresses that are due to stack activity?

 

--Will

[+stephena]

Not sure if this is a bug or by design, but I thought I would mention it...

 

I was trying to trap whatever code was modifying the memory in $F4, and neither "watch $F4" or "trapwrite $F4" would cause the debugger to break, even though it kept getting changed.

 

It turns out it was a stack-too-deep problem, and the return addresses getting pushed onto the stack were trashing the value in $F4. Is there any way to trap modifications to memory addresses that are due to stack activity?

 

--Will

The main question would be: how do you detect whether a memory modification is due to stack activity? I can probably add any type of condition to the debugger as long as there's a logical way of actually detecting that behaviour. in other words, from the point of view of Stella, under what conditions does stack 'bashing' occur?

[GroovyBee]

It turns out it was a stack-too-deep problem, and the return addresses getting pushed onto the stack were trashing the value in $F4. Is there any way to trap modifications to memory addresses that are due to stack activity?

Don't forget the stack is always in page 1 not page 0. It exists between $0180 and $01FF on the 2600. Its only the hardware's address decoding that folds it into $0080 to $00FF range. Maybe you should see if trapping a write to $1F4 works.

[e1will]

Don't forget the stack is always in page 1 not page 0. It exists between $0180 and $01FF on the 2600. Its only the hardware's address decoding that folds it into $0080 to $00FF range. Maybe you should see if trapping a write to $1F4 works.

 

Interesting, I hadn't considered that. So that raises the question that if I had a bit of code that writes to $0180 (for example), would that change the contents of $0080 but not trigger a trapwrite or condition on $80?

 

--Will

[e1will]

The main question would be: how do you detect whether a memory modification is due to stack activity?

 

I suppose I wasn't so much concerned with Stella telling me why the memory modification occurred (since I could figure that out based on what the code is doing) as long as it would break when the modification occurred for addresses I'd set up watches/trapwrites for, which it wasn't doing.

 

I can get around the problem by putting in a "breakif { *$F4 != 0 }" since I know the value should be zero unless it gets tromped by the stack or by some other bug elsewhere in the code, but it just seemed odd that the watch and trapwrite diddn't catch the modification.

 

--Will

Edited August 9, 2009 by e1will

[+stephena]

The main question would be: how do you detect whether a memory modification is due to stack activity?

 

I suppose I wasn't so much concerned with Stella telling me why the memory modification occurred (since I could figure that out based on what the code is doing) as long as it would break when the modification occurred for addresses I'd set up watches/trapwrites for, which it wasn't doing.

Yes, but for me to actually code such a condition into the debugger, I need to know why/how it happened. The debugger will trigger a breakpoint when it happens, but I still need to create code that checks for that condition. Thats' what I'm looking for: a description of the code/algorithm required to detect stack bashing.

 

EDIT: I should probably add that I'm not that familiar with what you're talking about. So ideally I'd like to get a test ROM with the error occurring, a description of how to reproduce the error, and a description of how you'd like it to work.

Edited August 9, 2009 by stephena

[+selgus]

Yes, but for me to actually code such a condition into the debugger, I need to know why/how it happened. The debugger will trigger a breakpoint when it happens, but I still need to create code that checks for that condition. Thats' what I'm looking for: a description of the code/algorithm required to detect stack bashing.

Maybe I am missing something here, but couldn't you just abstract reading/writing memory which each of your emulated instructions would call? Once you have that abstraction, the read/write routines could scan any watch-point addresses and/or condition tables that user has set up in the debugger.

 

Granted, you are introducing some overhead on each instruction, but you are also debugging at the time, so this is sort of implied. I have also setup read and write vectors in the past, and when debugging, replace the functions to do the more intensive checking (so normal execution wouldn't have the same overhead).

--Selgus

[e1will]

So ideally I'd like to get a test ROM with the error occurring, a description of how to reproduce the error, and a description of how you'd like it to work.

 

Sure, no problem. I'm attaching the version of the bin (in-progress homebrew) where I noticed this.

 

Load the bin, then press reset. Enter the door on the left.

 

A new screen will appear: the player will be carrying two objects, a lightning bolt and a flashlight. At this point you can see in the debugger that memory location $F4 (which holds a pointer to what object(s) the player is carrying) contains $E3. Put a trapwrite for $F4.

 

Toggle out of the debugger and press the fire button to drop the two objects. Dropping the objects resets the "carrying" pointer at $F4 to zero, and triggers the trapwrite.

 

Toggle back out of the debugger, and then press Select. The trapwrite will again trigger as the STA $00,X in the "clear all variables" logic is called. It's essentially replacing the zero in $F4 with another zero.

 

Toggle back out of the debugger. Toggle back in, and you'll see $F4 now contains $B5, even though the trapwrite was never triggered for that change.

 

--Will

DUCKNTSC.BIN

[+batari]

The main question would be: how do you detect whether a memory modification is due to stack activity?

 

I suppose I wasn't so much concerned with Stella telling me why the memory modification occurred (since I could figure that out based on what the code is doing) as long as it would break when the modification occurred for addresses I'd set up watches/trapwrites for, which it wasn't doing.

 

I can get around the problem by putting in a "breakif { *$F4 != 0 }" since I know the value should be zero unless it gets tromped by the stack or by some other bug elsewhere in the code, but it just seemed odd that the watch and trapwrite diddn't catch the modification.

 

--Will

A stack write would modify location $1F4. It is mirrored at $F4, but trapping seems to only trap the literal address and not all of the mirrors.

 

EDIT: from a programming perspective, it would be nice to be able to trap all mirrored locations as an option, but I wouldn't want that to be the default behavior.

Edited August 9, 2009 by batari

[e1will]

A stack write would modify location $1F4. It is mirrored at $F4, but trapping seems to only trap the literal address and not all of the mirrors.

 

EDIT: from a programming perspective, it would be nice to be able to trap all mirrored locations as an option, but I wouldn't want that to be the default behavior.

 

I put in a trapwrite for $01F4, and that caught the writes to $F4 that were from the stack. So this might just be a case of the user (i.e. me, in this case) needing to trap for both $nn and $01nn when trying to catch modification of those zero-page RAM locations.

 

But I agree, it would be a handy option to trap all writes that end up changing zero page memory, whether it's the stack or some errant code that's trying to store to some weird address that ends up mirroring to $80-$FF.

 

--Will

[+stephena]

The main question would be: how do you detect whether a memory modification is due to stack activity?

 

I suppose I wasn't so much concerned with Stella telling me why the memory modification occurred (since I could figure that out based on what the code is doing) as long as it would break when the modification occurred for addresses I'd set up watches/trapwrites for, which it wasn't doing.

 

I can get around the problem by putting in a "breakif { *$F4 != 0 }" since I know the value should be zero unless it gets tromped by the stack or by some other bug elsewhere in the code, but it just seemed odd that the watch and trapwrite diddn't catch the modification.

 

--Will

A stack write would modify location $1F4. It is mirrored at $F4, but trapping seems to only trap the literal address and not all of the mirrors.

 

EDIT: from a programming perspective, it would be nice to be able to trap all mirrored locations as an option, but I wouldn't want that to be the default behavior.

OK, this is the info I wanted to know. It's basically an issue of literal addresses vs. mirrors. I'll add this to the TODO list.

[+stephena]

Just wanted to let everybody know that I had to take a somewhat extended break due to real life issues mentioned previously in the thread. I hope to do the next alpha (beta?) release next week. The illegal HMOVE stuff is essentially finished; I'm still working on writes to NUSIZx while a player is being drawn. And I've implemented several suggestions from earlier in the thread. So work is still proceeding, just slower than expected ...

[Thomas Jentzsch]

So work is still proceeding, just slower than expected ...

...but still way faster than I do.

[+stephena]

So, I missed yet another Friday, but I'm here with an update for the next alpha release and beyond.

 

OK, first of all, I feel the 'illegal' HMOVE emulation is about 99% complete, and is basically finished for 3.0. Any remaining issues with it will be taken care of in 3.1. Second, I had to revert the changes that 'fixed' Bumper Bash and Pole Position. I say 'fixed' in quotes, since fixing those ROMs broke dozens more. The issue is writes to RESxx and NUSIZx while graphics are currently being drawn. I still don't fully understand how these work, and rather than tying up the release for another month or two, I'm going to move that to 3.1 as well. So I've basically reached my goals for TIA stuff wrt 3.0; many ROMs are now fixed, and no regressions were introduced.

 

Now, on to the debugger stuff. I've already mentioned debugger rewind, which is complete and will be in the next alpha. Now I'm looking at the 'fixed debug colours' feature in nocash 2600 emulator. My question is, would it be sufficient to have fixed colours for P0/M0, P1/M1, PF/BL and BK, or would you prefer separating the colours that share a register? The latter is probably more informative, but it requires quite a bit of reworking to the TIA core (since it doesn't model 7 colour registers, only 4).

 

After that I'll be looking at adding disassembly of RAM (both zero-page and SC) to the debugger UI. The hardest part of this is actually figuring out how its UI should work; the disassembly itself is trivial. After that, I'll be integrating distella and in general improving the disassembly results.

 

Last (but certainly not least), there are some CRT emulation improvements in the pipeline. The Georgia Tech Atari Team have implemented Blargg filtering, which gives similar (and in some cases superior) results to the current CRT OpenGL effects, without requiring OpenGL 2.0, or OpenGL at all for that matter. So it should work better for those people with older systems.

 

Anyway, if I can accomplish all this in the next month or so, I think a jump to version 3.0 is well justified

[Trebor]

Everything sounds great, stephena. I'm really looking forward to the 'official' 3.0.

 

Furthermore, I'm really happy to read this: "The Georgia Tech Atari Team have implemented Blargg filtering..."

 

That should really look sweet for the 2600 games. While the 'initial' filtering that is applied from the Georgia Tech team was definitely an improvement over the raw output, the Blargg filtering is really the way to go. I am glad to see this will be implemented in Stella!

 

-Trebor

Edited August 22, 2009 by Trebor

[e1will]

My question is, would it be sufficient to have fixed colours for P0/M0, P1/M1, PF/BL and BK, or would you prefer separating the colours that share a register? The latter is probably more informative, but it requires quite a bit of reworking to the TIA core (since it doesn't model 7 colour registers, only 4).

 

IMO 7 would be neat but 4 is probably sufficient if the ability to toggle each one on and off individually remains. (And is available from 'pause' mode.)

 

Unrelated, is there a way to "unfreeze" the CPU after it runs over a "KIL" opcode (e.g. $02)? 'reset' sends the program counter back to where the reset vector points but I can't figure out if there's a command to "really" reset the CPU and get the PC moving forward again without exiting and reloading the ROM.

 

--Will

[+stephena]

Thread bump to indicate that alpha three was just announced with some nice debugger improvements.

[Trebor]

Hi stephena,

 

I appreciate this new release, thanks. All the improvements sound great. I'm looking forward to trying it out later. I'm curious, I saw no mention of any changes to the NTSC filter (I.E. using blargg's work), has this been implemented in this latest 3.0 Alpha, or should we expect to see it in 3.1?

 

Thanks,

Trebor

Edited August 25, 2009 by Trebor

[+stephena]

Hi stephena,

 

I appreciate this new release, thanks. All the improvements sound great. I'm looking forward to trying it out later. I'm curious, I saw no mention of any changes to the NTSC filter (I.E. using blargg's work), has this been implemented in this latest 3.0 Alpha, or should we expect to see it in 3.1?

 

Thanks,

Trebor

I'm hoping it will be there for 3.0, but I don't actually have the code yet. It's being done by the Georgia Tech team, so I'll have to contact them to see how it's going. I did see a test build a few weeks ago, so I know they're fairly far along with it.

[+stephena]

I've decided against another alpha release, and just released the final version of 3.0 instead. I didn't get time to implement the revamped disassembly system or Blargg filtering, so that will have to wait until 3.1. Sorry for those who were waiting on these features, but I've already committed myself to completing programming apps for KrokCart and Harmony cart for the next several weeks. It made sense to release 3.0 now, rather than pushing it to October and not working on it at all in the interim.

 

Anyway, I've created a thread for the 3.0 release. You can report general bugs there, but I'd still like reports in this thread WRT TIA emulation bugs; it will still be very useful for 3.1/3.2.