More changeable values in debugger

[thrust26]

Some tabs do not allow changing (all) values (TIA Collisions, I/O INPTx and INTIM, Audio).

Also Trak-Ball controllers allow no input at all. Fire should be easy to add. And changing the two bit values for X and Y axis (like for the Driving Controller) doesn't seem like a big problem too.

[sa666666]

The first part of this is related to #15. In fact, I have some questions for @DirtyHairy about this very soon.

[DirtyHairy]

Fire at will 😏

[sa666666]

I actually have several questions relating to #15, which is why it is still open. For now, though, I'll stick with the topic of this issue.

I'm wondering what it means to change some stuff in the TIA tab, and how to implement it with the new core. For example, take the widgets in the TIA tab that change each sprites' position. In the old core, I simply updated a single variable that indicated position, and that was it. Now that the sprites move one tick at a time, would a 'set position' be a loop to move the object to the desired position (by ticks), or can we just simply move it directly. For example, consider the code to set the position of P0:

uInt8 TIADebug::posP0(int newVal)
{
if(newVal > -1)
myTIA.myPOSP0 = newVal;
return myTIA.myPOSP0;
}

How would this work with the new core?

Also, consider the collision registers. What does it mean to 'turn on' a collision when the objects in question aren't actually colliding?

I guess I'm not asking about code, per-se, but about what does it logically mean to do these things. Once we have the logic figured out, the code should follow relatively easily.

[sa666666]

@thrust26 , the sound registers will remain as-is until I complete #80, which in turn will show much more info in the TIA sound tab. Adding the other stuff for Trak-ball, etc will probably come with #70.

[DirtyHairy]

Positioning should work by warping the corresponding sprite's draw decode counter to the desired value. Determining the value depends on the sprite in question (and on NUSIZ in the case of a player), so it should go into the sprite classes imho. For example, the value would be (x + 156) % 160 for ball and missiles (from the top of my head, this might be off by one). Similarily, x can be calculated from the draw decode counters.

Concerning collisions, I think that the best way to model "turning on/off a collision" is to set/clear the corresponding collision latch, which is represented by a bit on 32 bit mask.

What is more tricky (and I guess that echoes your last paragraph, @sa666666) are the semantic subleties of these operations. For example, what does "setting x" mean for a draw decode that is already in progress? The operation that I sketched above would just let the decode continue, meaning that the object is displayed at its old position in the current line. Once we have clarity on these points, the implementation should be quite straightforward.

[sa666666]

Yep, and until we have clarity, I can't close this issue or #15 😃

[sa666666]

Other than the changes we've added to the debugger TIA tab so far, I'm pushing this to post-5.0 release, so we can get the 5.0 release done soon.

[thrust26]

Added trackball controllers to debugger with 00cb377

[thrust26]

Closed until someone find more missing values.