Stella 6.6 released

[DirtyHairy]

Sooooo... better late than never ? I have finally released 6.6.0 for the R77. You can grab it on github. It has the following features:

• Deadzone is gone for good
• Dumping to SD now chooses different unique file names for each ROM (disambiguated by the ROMs MD5 sum)
• There is a new DONT_OVERCLOCK setting that disables overclocking. This may help consoles that fail to run properly, but at the expense of audio jitter and frame drops in demanding games
• The switch to gcc 10 squeezes some more performance of the R77.

I have uploaded updated build container images. This includes an aarch64 image that runs on apple silicon macs ?

 

Have fun!

[Rodney Hester]

Brilliant work as always - thank you!

[DirtyHairy]

4 hours ago, Rodney Hester said:

Brilliant work as always - thank you!

Thanks alot! I still am slightly confused though why building with gcc 10 didn't produce a working image for you. My only shot would be some issue with u-boot-tools, since those need to be installed on the builder and have a direct influence on the generated image.

[Capt Moore]

I downloaded a fresh copy of the new Retron 77 firmware.  I was able to verify both the deadzone bug and keyboard controller issues were fixed.

 

I think I have come across another bug however.

 

It appears that USB keyboard support isn't working anymore on the retron 77.

 

I attempted to set up a USB keypad (as a remote control), as I typically use that to select/reset/difficulty etc. rather than the controls on the retron itself.  I discovered I couldn't map any of the controls, it was like the usb keypad was broken.

 

I then switched to another full keyboard (wireless with usb dongle) and tried using the Function keys (which are predefined) to select/reset, but still no response at all.

 

To troubleshoot, I still had the previous stella 6.5.2 on the other SD card, so I used the previous version to test the keyboard/OTG hardware, and no problems at all using that version.

 

Could someone hook up a USB keyboard, and attempt to both:

 

1. Use the keyboard keys with the emulator (F1 to select, F4 to toggle color/b&w, keypad to navigate in Stella menus.)

2. Attempt to map other items to a keyboard key, for example map the fry key to /.

 

As far as I can tell, the buttons on USB devices that are NOT keyboards appear to work normally, it is just keyboards that are effected for some reason.

 

 

[DirtyHairy]

3 hours ago, Capt Moore said:

I downloaded a fresh copy of the new Retron 77 firmware.  I was able to verify both the deadzone bug and keyboard controller issues were fixed.

 

I think I have come across another bug however.

 

It appears that USB keyboard support isn't working anymore on the retron 77.

 

I attempted to set up a USB keypad (as a remote control), as I typically use that to select/reset/difficulty etc. rather than the controls on the retron itself.  I discovered I couldn't map any of the controls, it was like the usb keypad was broken.

 

I then switched to another full keyboard (wireless with usb dongle) and tried using the Function keys (which are predefined) to select/reset, but still no response at all.

 

To troubleshoot, I still had the previous stella 6.5.2 on the other SD card, so I used the previous version to test the keyboard/OTG hardware, and no problems at all using that version.

 

Could someone hook up a USB keyboard, and attempt to both:

 

1. Use the keyboard keys with the emulator (F1 to select, F4 to toggle color/b&w, keypad to navigate in Stella menus.)

2. Attempt to map other items to a keyboard key, for example map the fry key to /.

 

As far as I can tell, the buttons on USB devices that are NOT keyboards appear to work normally, it is just keyboards that are effected for some reason.

 

 

Sounds like an input mapping issue to me --- keyboard are handled differently and shouldn't be affected by any changes. Could you retry with the Stella settings moved away (all files in the stella directory that start with settings.sqlite)?

[Rodney Hester]

6 hours ago, DirtyHairy said:

Thanks alot! I still am slightly confused though why building with gcc 10 didn't produce a working image for you. My only shot would be some issue with u-boot-tools, since those need to be installed on the builder and have a direct influence on the generated image.

I still need to test it, but I think it was in fact 'working' and I was experiencing the too-long-of-a-message-in-whatsnew bug before that was addressed

[Capt Moore]

6 hours ago, DirtyHairy said:

Sounds like an input mapping issue to me --- keyboard are handled differently and shouldn't be affected by any changes. Could you retry with the Stella settings moved away (all files in the stella directory that start with settings.sqlite)?

I tried and couldn't find the files.  Maybe they are hidden on MacOS?  Anyway, I tried a new card, and everything worked including the USB keyboard.  I then reformatted the SD card, and tried again, still didn't work.  This time I has some weird extra directory in the file system.

 

The best I could tell, maybe the SD card was going bad and that caused the issue?  Very weird, but everything is working for me now.  (Except I dropped my fairly new $40 Best electronics paddles and broke the plastic case...)

 

Thanks again for fixing the deadzone/keyboard controller issues I had with the previous version.

[DirtyHairy]

6 hours ago, Rodney Hester said:

I still need to test it, but I think it was in fact 'working' and I was experiencing the too-long-of-a-message-in-whatsnew bug before that was addressed

? Yeah, I somewhat suspected this.

[DirtyHairy]

2 hours ago, Capt Moore said:

I tried and couldn't find the files.  Maybe they are hidden on MacOS?  Anyway, I tried a new card, and everything worked including the USB keyboard.  I then reformatted the SD card, and tried again, still didn't work.  This time I has some weird extra directory in the file system.

 

The best I could tell, maybe the SD card was going bad and that caused the issue?  Very weird, but everything is working for me now.  (Except I dropped my fairly new $40 Best electronics paddles and broke the plastic case...)

 

Thanks again for fixing the deadzone/keyboard controller issues I had with the previous version.

 You're welcome  The files are definitely visible on MacOS (I'm on a Mac, too). A corrupted settings DB together with a bad SD card *might* account fr the issue, although that's really a long stretch.

[+sramirez2008]

Testing Stella 6.6 with my trak-ball controllers (CX22 and CX80) and I can't seem to get either one of them to work properly with Missile Command TB or Missile Control TB.  I'm testing them via the 2600-dapter II and D9 versions as I have two of each.  I'm guessing that I need to set a configuration somewhere and appreciate any guidance you can offer.  Btw, both controllers work with the actual carts/hardware and I just used my CX80 with the A7800 emulator for Centipede TB. 

[+stephena]

Can you post the ROMs?  There are several things to do to get this working:

1. The ROMs have to actually support the TB   Easy enough, I guess you have this one worked out.
2. The 2600-daptor DIP switches need to be set to 'TrakBall' mode (see the 2600-daptor webpage for docs on how to do that).
3. Stella needs to be configured to use the TB for these ROMs in its Game Properties (if this is a common ROM, then this has already been done).

 

EDIT: Link to D9 hardware here: http://www.2600-daptor.com/2600-daptor D9.htm

Edited December 23, 2021 by stephena

[+sramirez2008]

ROMs attached.

 

6 hours ago, stephena said:

• The 2600-daptor DIP switches need to be set to 'TrakBall' mode (see the 2600-daptor webpage for docs on how to do that).

Dip switches are properly set.

6 hours ago, stephena said:

Stella needs to be configured to use the TB for these ROMs in its Game Properties (if this is a common ROM, then this has already been done).

Game properties were set for trak-ball

Missile Command TB CX22 NTSC.bin Missile Control - Atari Trak-Ball Hack v1.15 (NTSC).bin

[Thomas Jentzsch]

Is there any response to movement or firing? 

Edited December 23, 2021 by Thomas Jentzsch

[+sramirez2008]

16 minutes ago, Thomas Jentzsch said:

Is there any response to movement or firing? 

Movement is erratic, but it fires fine.

[Thomas Jentzsch]

Sounds like an incorrect TB setting.

[+sramirez2008]

Not sure what additional TB settings need to be checked.  Both ROMs were set to TB and the 2600-daptor dip switches are set correctly.  
 

Interesting…without changing any configurations, each game works with my Kensington Trackball Mouse (K64325).  I guess that will be my backup method of playing for now.

 

Anyone else out there with a trak-ball/2600-daptor setup that can confirm whether or not their TB works?

[Thomas Jentzsch]

Do you have a real console for testing?

[dualcam]

9 hours ago, sramirez2008 said:

Not sure what additional TB settings need to be checked.  Both ROMs were set to TB and the 2600-daptor dip switches are set correctly.  
 

Interesting…without changing any configurations, each game works with my Kensington Trackball Mouse (K64325).  I guess that will be my backup method of playing for now.

 

Anyone else out there with a trak-ball/2600-daptor setup that can confirm whether or not their TB works?

The trak-ball itself needs to set for native mode.  The 2600-daptor II will work as a USB mouse, and you can check it on the Windows/Mac desktop by seeing if you can move the cursor around with the trak-ball.

 

Tom

http://2600-daptor.com/

 

[firebottle]

Just in case anybody cares, looks like this version finally broke XP support. Dialog box says not a valid 32-bit app. And yes, I have the 2017 VC++ library. Strange that the installer program still runs.

[Trebor]

23 hours ago, firebottle said:

Just in case anybody cares, looks like this version finally broke XP support.

Very lucky a break wasn't experienced sooner. 

Per the changelog, official support for Windows XP was discontinued with the release of version 6.1 back on March 22, 2020.

 

 

 

 

Stella 6.0.2 from October 11, 2019 is the last release that still officially supported Windows XP.

[Sohl]

Stella is great, and I'm happy to report that the weird zoomed-out text boxes (in OpenGL rendering modes) I sometimes saw are gone!  Bravo.

 

However, one minor annoyance I had in the 6.5x and now 6.6, is that when I load a ROM with the .sym file for debugging (so I can get the tooltip popup for the symbolic names of each RAM location when I hover my mouse over the RAM display, and see the variable name in the broken-out display under the array of RAM cells), if I have any other constant value defined that has a value between $80 and $FF, it can mask the normal RAM name I've defined using "ds" directives in my DASM assembler source code file.  I tried looking through the DASM manual to see if there is a way to prevent some symbols from being output for the .sym file, but I did not see anything like that.  There is such a thing to control the listing file (LIST ON  |  LIST OFF), but that does not affect the .sym file.

 

Does anyone have any ideas short of filtering the .sym file?  I could write a little C program to strip out any symbols defined in all UPPERCASE that have numeric values from $80 to $FF, I suppose.

 

In the attached picture, I have a RAM variable I named 'InfectState' at RAM location 0xDE, but I also defined a constant for a color as 'ENERGY_MOL_CLR' (energy molecule color) that has a value of $DE, so Stella happens to chose the ENERGY_MOL_CLR symbol for the debugger UI displays instead of InfectState.  Reordering the definitions in my .asm source file did not help.  

 

Thanks if you can suggest a better way for me to work with symbols or attempt to change Stella to pick the more likely symbols for RAM.

Edited January 16, 2022 by Sohl
wording clarity

[Thomas Jentzsch]

Coding styles are varying. so I suppose there is not much we can do with Stella. Maybe DASM could be enhanced.

[Sohl]

17 hours ago, Thomas Jentzsch said:

Coding styles are varying. so I suppose there is not much we can do with Stella. Maybe DASM could be enhanced.

Certainly coding styles vary, but I wonder if Stella could have an option to prefer symbols with lower or mixed cases to take priority in the RAM range of 0x80 to 0xFF if there are multiple symbols for a same value (the other(s) being all UPPERCASE)?  Such an option could encourage programmers to use mixed case for variable names and labels for noteworthy locations in code while uppercase could be used for numeric constants and other data unrelated to a given address.  This seems natural to C programmers at least.  

Perhaps now, Stella just uses the first symbol it parses from the .sym file for a given RAM address and ignores later symbols for the same value?  I notice that the DASM .sym output file is sorted into alphabetical order, so in my example, the CONST symbol name is alphabetically earlier than the RAM variable address it matches in value.  Given this behavior, I suppose with clever naming, or consistent use of some special characters, one could ensure the RAM symbols are output first in the .sym file and therefore be the ones Stella will use in the debugger UI.

 

Yes, if Stella always does "use first instance of a symbol with a given value", perhaps DASM could be changed to organize the .sym file non-alphabetically to sort mixed-case symbols before uppercase-only ones, or output them in order of appearance in the source code, or something else the programmer can control in a more flexible manner.

 

Again, this is just an annoyance since I only have couple of conflicts like this.  I just wanted to make sure I was not missing some simple option to avoid it!  But perhaps it plants a seed for future Stella and/or DASM update ideas. 

 

[+splendidnut]

@Sohl  I ran into a similar issue:

 

 

Ultimately I ended up separating out my variables into their own file, building a symbol table from just that, and using it for debugging.  You could potentially do the same, and then append the original full symbol table after it.

 

OR resort to the good ole' printf method... Atari 2600 style:  using a score kernel as a three variable debugger! 

 

[Sohl]

1 hour ago, splendidnut said:

 

 

"OR resort to the good ole' printf method... Atari 2600 style:  using a score kernel as a three variable debugger!  "

Good thread, @splendidnut.  I had not noticed that one before or when I posted (I should have looked around a bit harder before I posted ). 

 

I hope I don't need to devolve that far in terms of debugging!  I think manipulating the .sym file based on symbol capitalization would work pretty well for me and not be too hard to implement... my build script could invoke the .sym file filter to re-order the symbols so upper-case symbols are moved to end of the file.  Hopefully Stella won't choke if I do that!