Stella 3.2 released

[+stephena]

Stella 3.2.2 has been released, which fixes a bug reported in version 3.2.1 (centering the application window when it was larger than the desktop resulted in completely hiding the window instead).

[supercat]

Stella 3.2.1 has now been released, fixing a number of issues that slipped past version 3.2. Please try to keep all discussion and bug reports in this thread, as it's much easier for me to watch responses if they're all in the same place.

 

I tried to load it into VC++express 2008, and it can't find SDL.H and other SDL-related files. Is that another package I need to download?

[cd-w]

I tried to load it into VC++express 2008, and it can't find SDL.H and other SDL-related files. Is that another package I need to download?

 

I believe you need to download libsdl.

 

Chris

[+stephena]

I tried to load it into VC++express 2008, and it can't find SDL.H and other SDL-related files. Is that another package I need to download?

 

I believe you need to download libsdl.

 

Chris

Yes, and then you need to configure Visual Studio to use the SDL files. Basically, you have to point VS to the SDL 'lib' and 'include' directories.

[+batari]

I just noticed a bug in the debugger disassembly - it looks like branch instructions are showing the wrong operands. This screenshot shows an example:

The highlighted instruction (BNE) has the correct opcode (D0) but all 6502 branches have just one operand, which is a single byte that is a two's compliment distance from the next

instruction, not a two byte literal address as shown here.

 

EDIT: I thought I'd add that there is no longer a way to see all of the actual addresses in the left column - only the addresses that are actually detected as labels by the disassembler are shown, and in some cases this column may be completely blank. I found myself firing up an older version of Stella so I could get this column back.

Edited September 30, 2010 by batari

[+stephena]

I just noticed a bug in the debugger disassembly - it looks like branch instructions are showing the wrong operands. This screenshot shows an example:

The highlighted instruction (BNE) has the correct opcode (D0) but all 6502 branches have just one operand, which is a single byte that is a two's compliment distance from the next

instruction, not a two byte literal address as shown here.

I'll look into this. I don't suppose you have a test ROM and a specific address where this happens? Since this output is directly from Distella, I suspect that it also generates the wrong output.

 

BTW, what should that highlighted instruction look like??

 

EDIT: I thought I'd add that there is no longer a way to see all of the actual addresses in the left column - only the addresses that are actually detected as labels by the disassembler are shown, and in some cases this column may be completely blank. I found myself firing up an older version of Stella so I could get this column back.

This is easy enough to add back as a configurable option. In fact, I was considering doing it anyway for the next release.

[+stephena]

I just noticed a bug in the debugger disassembly - it looks like branch instructions are showing the wrong operands. This screenshot shows an example:

The highlighted instruction (BNE) has the correct opcode (D0) but all 6502 branches have just one operand, which is a single byte that is a two's compliment distance from the next

instruction, not a two byte literal address as shown here.

When I turn on actual addresses, I see that the BNE instruction correctly takes up two cycles; 1 for the opcode, and another for the operand. So the processing is being done correctly. I guess your issue is with the naming of the label? You need to specify how it should look, since this is the same output as generated by Distella, and it does correctly output code that can be recompiled again.

[+SpiceWare]

The part on the right where it shows D0 ED F4 is the issue - it should only show 2 bytes, D0 xx.

[Omegamatrix]

EDIT: I thought I'd add that there is no longer a way to see all of the actual addresses in the left column - only the addresses that are actually detected as labels by the disassembler are shown, and in some cases this column may be completely blank. I found myself firing up an older version of Stella so I could get this column back.

This is easy enough to add back as a configurable option. In fact, I was considering doing it anyway for the next release.

 

 

You know, I really hated this when it was first introduced. Since then I've gotten used to just seeing the labels in the disassembler, and now I really like it. A configurable option would be perfect though. I personally could see myself flipping it on/off for the same game depending on what I'm doing.

[supercat]

You know, I really hated this when it was first introduced. Since then I've gotten used to just seeing the labels in the disassembler, and now I really like it. A configurable option would be perfect though. I personally could see myself flipping it on/off for the same game depending on what I'm doing.

 

For some bank-switching schemes (e.g. Parker Brothers, 4A50, the upcoming JX10, etc., I would think one would want to show both the 6507 address and the mapped address (since each physical address in a Parker Brothers cart can be mapped into three or four different places). As for the question of showing labels, I think it might be helpful to show small and/or dimly-colored addresses for every instruction, and labels for those which seem to be branch targets.

[+stephena]

The part on the right where it shows D0 ED F4 is the issue - it should only show 2 bytes, D0 xx.

OK, sorry to be obtuse, but what should the 'xx' be? Currently the output bytes are 'D0 ED F4'. When this is fixed, what exactly should the output bytes be? As you can probably tell, my knowledge of 6502 is very rusty, so feel free to explain in as much detail as you like.

[+stephena]

EDIT: I thought I'd add that there is no longer a way to see all of the actual addresses in the left column - only the addresses that are actually detected as labels by the disassembler are shown, and in some cases this column may be completely blank. I found myself firing up an older version of Stella so I could get this column back.

This is easy enough to add back as a configurable option. In fact, I was considering doing it anyway for the next release.

You know, I really hated this when it was first introduced. Since then I've gotten used to just seeing the labels in the disassembler, and now I really like it. A configurable option would be perfect though. I personally could see myself flipping it on/off for the same game depending on what I'm doing.

I just added this a few hours ago, and it will be in the next test release.

 

For some bank-switching schemes (e.g. Parker Brothers, 4A50, the upcoming JX10, etc., I would think one would want to show both the 6507 address and the mapped address (since each physical address in a Parker Brothers cart can be mapped into three or four different places). As for the question of showing labels, I think it might be helpful to show small and/or dimly-colored addresses for every instruction, and labels for those which seem to be branch targets.

For now, I just append a '$' to actual addresses, and indent 2 spaces. This allows to quickly visually differentiate between labels and addresses. I agree colour would be nice, and I experimented with that a little. However, it will require a new colour scheme to be added to the debugger, so I'm leaving this for now. Colourizing the disassembly was always my intention anyway; I just need to find time to do it ...

[Nukey Shay]

The xx should be the exact value that exists in the binary which follows the branching opcode. This value points out the destination which is relative to the starting position which is the address immediately following the branch argument. If, for example, the branching argument was zero...that branch would seemingly have no effect at all (other than burning an extra cycle) - it's branching to the next instruction in memory. If the branch argument is positive, the destination address is forward. Negative = backward. A branch BEQ $FE (-2) is an infinite loop when taken. Going backward 2 bytes from the address immediately ahead of the argument puts the program counter at the same instruction.

Edited October 3, 2010 by Nukey Shay

[Omegamatrix]

The part on the right where it shows D0 ED F4 is the issue - it should only show 2 bytes, D0 xx.

OK, sorry to be obtuse, but what should the 'xx' be? Currently the output bytes are 'D0 ED F4'. When this is fixed, what exactly should the output bytes be? As you can probably tell, my knowledge of 6502 is very rusty, so feel free to explain in as much detail as you like.

It is a one byte signed value, which is the offset that is added to the program counter. So a branch is limited to jumping within a -128 to +127 range. If you invoke DASM to do a list file, you can see all of these values. Alternatively you could also use a program like HOM3 to look at the value following the branch operand.

[SeaGtGruff]

The part on the right where it shows D0 ED F4 is the issue - it should only show 2 bytes, D0 xx.

OK, sorry to be obtuse, but what should the 'xx' be? Currently the output bytes are 'D0 ED F4'. When this is fixed, what exactly should the output bytes be? As you can probably tell, my knowledge of 6502 is very rusty, so feel free to explain in as much detail as you like.

The machine code area should always show the hex values for the pure machine code. In this case, the hex value of the hex branch instruction should be followed by the hex value of the offset for the branch, not the lo-byte/hi-byte of the destination address. Following is an example from Demon Attack, with Stella's disassembly versus DIS6502's disassembly. There are five branch instructions in this section of code-- I've numbered them to help them stand out better. In the machine code area, Stella (incorrectly) shows the address of the destination, whereas DIS6502 shows the value of the offset-- which is what is actually there in the ROM.

 

Michael

[+stephena]

Thanks for the detailed explanations of the BNE issue. The problem was indeed that the output wasn't the signed offset, but the address which it resolved into. This has been fixed, and will be included in the next version of Stella.

[+Nathan Strum]

There's a display glitch in Stella with the homebrew Yahtzee.

 

There's an extra die shown at the top left of the screen:

 

Which isn't present on real hardware:

[+stephena]

There's a display glitch in Stella with the homebrew Yahtzee.

 

There's an extra die shown at the top left of the screen:

 

Which isn't present on real hardware:

Yes, this is a duplication error in the TIA emulation. Note the the first die is a duplicate of the second, and shouldn't be there. This was reported a few releases back, but unfortunately I haven't had a chance to fix it yet.

[+stephena]

Stella 3.3 has been released, which addresses some of the bugs mentioned in this thread. Please move all discussion and bug reports to the Stella 3.3 release.