Keatah Posted February 26, 2021 Share Posted February 26, 2021 Documentation update/correction. The data isn't stored in the stella.pro file anymore is it? Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 26, 2021 Author Share Posted February 26, 2021 Right, that's something we're still working on. Eventually there may not be a stella.pro at all. So we won't change the docs for now, until we decide how it's going to work for the next release. Quote Link to comment Share on other sites More sharing options...
+wongojack Posted March 12, 2021 Share Posted March 12, 2021 Hey Stella heroes. I was searching around the boards for a joystick and paddle "test rom." Something tells me that such an image must exist, but I've never stumbled across it. I did find some references to test roms earlier in the thread, so I'm wondering if anyone on the team has a joystick/paddle test rom that they would be willing to share with me. Edit - I found this: Paul Slocum's website (qotile.net). (DL: https://atariage.com/2600/roms/Testcart.zip) Is that the best option? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 12, 2021 Share Posted March 12, 2021 I am not aware of anything better. 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted April 2, 2021 Share Posted April 2, 2021 Under Stella 6.5 in a binary I'm working on, I get the following error... I don't know if I'm doing something wrong, but thought I'd throw up the report just in case it's of interest. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 2, 2021 Share Posted April 2, 2021 Yes, that's the error message that you get when doing something wrong. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted April 2, 2021 Share Posted April 2, 2021 5 hours ago, Andrew Davie said: Under Stella 6.5 in a binary I'm working on, I get the following error... I don't know if I'm doing something wrong, but thought I'd throw up the report just in case it's of interest. Your code's trying to read memory location 0x30003ca4, but it doesn't have anything mapped to it. Memory is: 0x00000000 - 0x00008000 containing 32K ROM 0x40000000 - 0x40001FFF containing 8K RAM There's also some registers that are supported in Stella, such as T1TCR @ 0xE0008004 and T1TC @ 0xE0008008 to access one of the ARM's built in timers. The timer's used for NTSC/PAL/SECAM detection. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted April 2, 2021 Share Posted April 2, 2021 (edited) 37 minutes ago, SpiceWare said: Your code's trying to read memory location 0x30003ca4, but it doesn't have anything mapped to it. Memory is: 0x00000000 - 0x00008000 containing 32K ROM 0x40000000 - 0x40001FFF containing 8K RAM There's also some registers that are supported in Stella, such as T1TCR @ 0xE0008004 and T1TC @ 0xE0008008 to access one of the ARM's built in timers. The timer's used for NTSC/PAL/SECAM detection. Thanks. I was trying to declare a large (960 byte) array in the asm in the DISPLAYDATA segment, and write to it via the c code. The crash was on the write to the base address of the array.... effectively this... unsigned char *p = (unsigned char *)_BOARD; // _BOARD ds 960 ; in the asm file /// and then... *p = 0; // <-- this will crash In writing this, I think I now realise I need to do something like this... RAM[_BOARD] = 0; Edited April 2, 2021 by Andrew Davie Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted April 2, 2021 Share Posted April 2, 2021 32 minutes ago, Andrew Davie said: Thanks. I was trying to declare a large (960 byte) array in the asm in the DISPLAYDATA segment, and write to it via the c code. The crash was on the write to the base address of the array.... effectively this... this should work, and can make the code faster depending upon what you're doing: unsigned char *p = RAM + _BOARD; ... *p = 0; Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted April 2, 2021 Share Posted April 2, 2021 10 minutes ago, SpiceWare said: this should work, and can make the code faster depending upon what you're doing: unsigned char *p = RAM + _BOARD; ... *p = 0; Yes, thanks I have the hang of it now and all working OK. I was missing that the base address of RAM needed to be added to the value from the dasm variable 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted April 20, 2021 Author Share Posted April 20, 2021 Time for another bugfix release for the 6.5 series of Stella (I expect the next release will be 6.6). Changelog as follows: Added context-sensitive help. Improved support of multiple monitors with different resolutions. Improved analog input reading (Paddles, Keyboards...). Fixed QuadTari support for controller types other than Joysticks. Fixed palette and TV effects saving for Retron77. Fixed immediate disassembling when switching options in debugger. This fixes a few bugs reported in this thread. Specifically, paddle and keypad support is now more correctly emulated at a lower level (fixes a bug with "Alpha Beam" prototype). Also fixed is certain settings not being saved when rebooting the Retron77. New features include better support for multi-monitor setups, particularly those running at different resolutions. And a nice new UI feature; context-sensitive help in the UI. Click the '?' button or press F1 (Linux/Windows) or Shift-Cmd-/ (Mac) on almost any UI element, and you will be redirected to the Stella documentation specific to that item. Hopefully that means we get less questions, since you can read the manual yourself As usual, Stella can be downloaded from https://stella-emu.github.io/downloads.html, and donations are welcome at https://stella-emu.github.io/donations.html. Bugs can be reported here, or ideally at https://github.com/stella-emu/stella/issues. 6 1 Quote Link to comment Share on other sites More sharing options...
Rodney Hester Posted May 14, 2021 Share Posted May 14, 2021 Has there been some defaults change for the past couple builds for the RetroN 77? I've noted that OTG-attached joysticks with a 2600-daptor don't appear to be recognized at all, either in the UI or in-game. I've tested the adaptor on Windows, so I'm confident it's good, and it's behaving identically with three different OTG adapters (from different manufacturers), so I'm fairly confident ruling that out as the problem as well. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 14, 2021 Share Posted May 14, 2021 Have you tried defaulting the input settings? Quote Link to comment Share on other sites More sharing options...
Rodney Hester Posted May 14, 2021 Share Posted May 14, 2021 4 minutes ago, Thomas Jentzsch said: Have you tried defaulting the input settings? I burned a brand new SD card and put my carts on it...only to find out that, yes indeed, you *CAN* have _three_ problematic OTG adapters. I borrowed one from a neighbor just now and tried it because I couldn't make sense of this at all...and sure enough, it works just fine. Maybe my house was hit by an EMP? lol I dunno, but working now...sorry for the trouble! Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 14, 2021 Share Posted May 14, 2021 Shit happens. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 15, 2021 Share Posted May 15, 2021 @fdr4prez I got my Jakadapter today and did some testing with Combat. I can replicate your screenshots (and at least partially explain the bugs). But I cannot replicate that the controllers are not working. I can perfectly control both tanks with the two joysticks attached to the Jakadapter. Quote Link to comment Share on other sites More sharing options...
Rodney Hester Posted May 16, 2021 Share Posted May 16, 2021 So...I'm not crazy, nor was I hit with an EMP. It's a story probably worth telling to save others potential pain. The first OTG adapter I used was my tried-and-true spider cable that I used for early NES Mini hacking/development - which I think I ultimately just wore out, because it is just 100% unresponsive. It was 'Kirin' branded, and was (as irony would have it, since I already had it) recommended by several RetroN 77 owners as well. For as long as it worked (read: many years of abuse), it was solid. Once it failed, I bought some no-name, generic-photo OTG spider cable off eBay trying to save a few bucks - which works, conditionally. It depends on what you plug it into. You see, the male USB micro portion is unusually long - and just a hair TOO long for proper contact with the RetroN 77, which made it appear the cable wasn't working (which, to be fair, it wasn't). On other systems, it works fine. This was #2. #3 is FAR more interesting, and the reason for my post. It works...*initially*. If you use it actively, it will continue to work. But...if you stop using it, and there's no activity on the USB bus (because all I have plugged in is a 2600-daptor D9) for a long enough time (I've tried to sort-of measure it...it's hours, at least)...it appears the USB controller inside the OTG cable goes to sleep and never wakes back up. Hard-cycle power (to the OTG cable, and thus the RetroN 77), and you're back in business...until it goes to sleep again. That cable *replaced* the "good" one that was on Amazon for so long (same listing, different product), which is here and now branded 'Tusita': https://www.amazon.com/gp/product/B00LTHBCNM It was after this that I thought I'd flat-out lost my mind (and hadn't yet understood the 'timeout' problem with the Tusita OTG cable) and posted here for help, then had the good sense to ask a neighbor to borrow the still-working Kirin OTG cable he has for his mini Nintendos and lo and behold, it worked fine. Ugh. Not ready to give up and cry in my beer, I ordered a last (and probably the *only* remaining brand of multi-port OTG cable, at least that's Prime) one branded Leagway, which works just fine as well: https://www.amazon.com/gp/product/B075GFY7BG So, in summary - as multi-port OTG cables for the RetroN 77 go...don't trust eBay (why would you ever?), Kirin was/is awesome but now unobtainium, Leagway is a reasonable substitute, and something is *off* with Tusita and should be avoided (at least for this use case). Sorry for the rant, but thought the PSA might be helpful to others (at least on the US Amazon site) in the future. 1 Quote Link to comment Share on other sites More sharing options...
+fdr4prez Posted May 17, 2021 Share Posted May 17, 2021 On 5/15/2021 at 2:44 PM, Thomas Jentzsch said: @fdr4prez I got my Jakadapter today and did some testing with Combat. I can replicate your screenshots (and at least partially explain the bugs). But I cannot replicate that the controllers are not working. I can perfectly control both tanks with the two joysticks attached to the Jakadapter. I'll need to revisit this. At the time I could also replicate my issue using the Ultimate Flashback Interface Board, which is essentially two 2600-daptors D9 adapters built into one board (one USB) - this board is also made by Tom Hafner Quote Link to comment Share on other sites More sharing options...
Sohl Posted May 29, 2021 Share Posted May 29, 2021 Hi all. I mostly love Stella and it's been extremely useful to me in my homebrew development work, especially the debugger mode. With the current 6.5.3 version, however, I'm having some random sudden aborts, usually when I tap the backtick (`) key to resume running from the debug window, but sometimes the other way, from the running game when I tap backtick. The aborts tend to be "streaky" meaning that I can invoke and use Stella successfully for several iterations of debugging, then I get a bad streak where it will abort on me in use for a few invocations in a row before working normally again. I don't see any error messages or log files (at least where I looked) on my console, even when I use command-line options to increase the logging level. I start with the -debug command so it always first comes up in the debug GUI, and I run from there. I can't tell if Stella is crashing or thinks I requested to exit somehow. It's possible my keyboard is a bit flaky and my backtick key is bouncing and sending a few very closely-spaced keypresses, but I'm not sure. I'm running on Windows 10 and launching from the "cmd" command line. Any ideas on what I can do to avoid this or help you troubleshoot and fix it? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 30, 2021 Share Posted May 30, 2021 I noticed the problem on Windows 10 too. It could be the renderer, but we are not sure yet. I suppose you are using DirectX as renderer? Have you tried OpenGL? Does that help? 1 Quote Link to comment Share on other sites More sharing options...
Sohl Posted May 30, 2021 Share Posted May 30, 2021 8 hours ago, Thomas Jentzsch said: I noticed the problem on Windows 10 too. It could be the renderer, but we are not sure yet. I suppose you are using DirectX as renderer? Have you tried OpenGL? Does that help? @Thomas Jentzsch I was not aware that there is an option for this. Let me try it, and I will post my results. Quote Link to comment Share on other sites More sharing options...
Sohl Posted May 31, 2021 Share Posted May 31, 2021 (edited) @Thomas Jentzsch: Thanks for the help! My rendering option on Win10 was set to DirectX. I switched it to OpenGL. After a good bit of use, I had no unexpected aborts (?), but in debug mode, I did sometimes see the entire window show some small elements of the GUI expanded to fill the entire window, as shown in the attached jpeg. When it was in this state, the window flashed back to normal and this zoom image, alternating, and if I tabbed or moved the mouse, which graphic element that was zoomed could change. -- Mike Edited May 31, 2021 by Sohl added detail Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 31, 2021 Share Posted May 31, 2021 Ha, again I noticed the same problem with OpenGL. I have an old Core i5-3570K and use the built-in GPU. Do you have a similar one? 1 Quote Link to comment Share on other sites More sharing options...
Sohl Posted May 31, 2021 Share Posted May 31, 2021 9 hours ago, Thomas Jentzsch said: Ha, again I noticed the same problem with OpenGL. I have an old Core i5-3570K and use the built-in GPU. Do you have a similar one? @Thomas Jentzsch: Yes, similar. It's an HP 840 G1 laptop with a Core i5-4300U, 16 GB RAM, 64-bit Windows 10 Pro. No external GPU, so its just using what's built into the CPU (Intel HD 4400). Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 31, 2021 Share Posted May 31, 2021 Then I am pretty sure this is a driver problem and there is not much we can do. You can try the Software renderer. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.