stephena

It's not a 'Stella' thing. It's a 'using space for fire with other keys for direction gives a keyboard issue' thing. If you use the Left Control key in Stella to fire (like in z26), then it will probably act the same way.

It almost definitely won't work out of the box, since I don't think we compile NFS support into the kernel. And Samba definitely isn't there at all. Perhaps using the kernel CIFS filesystem, and mounting the share that way will work? You can definitely connect to the R77 using SSH. That's how we do testing for the most part. File sharing is another matter, though. Technically not impossible, but will require work on the kernel in the R77. And the kernel is a 3.x series, so I don't know if that's recent enough to do what you want. Personally, I'd try first with CIFS, so you can get a mount without needing to run daemons (like normal NFS or Samba would require).

Yeah, it actually is called PlusROM in the Stella code; I just had a brain fart. Memory is not always the best ...

Keyboards are Evil

Not yet. We hope to have PlusCart support in the next release of Stella.

I think we can bypass udev, and just modify the kernel driver to always eliminate the deadzone. That's all that app is doing anyway; calling a kernel function to zero out the deadzone area.

I should say first of all that I'm not entirely sure this is the problem. But it seems very likely. We will need to do a little research. The deadzone can affect various paddles games differently, since some games use more of the range of motion (and some less), and hit the deadzone (or not).

This happens in Linux due to the way analog controllers are set up by the OS. As the R77 is based on Linux, I suspect it is the same situation. I helped develop a solution for this at https://stella-emu.github.io/evdev-joystick.tar.xz, but this is only for standalone Linux. I guess we should see if we can integrate that functionality into the R77 port.

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.

Except for an extension forcing a specific scheme, or a TV format embedded in the name. I'm assuming that it's properly autodetecting the SB scheme, but I can't say for sure, as I don't have access to the ROM.

Options -> Input Settings -> Devices & Ports -> Autofire rate: Make sure it is 'Off'.

WRT Combat and R77, weren't there reports of some 2K carts not working because of missing pins (or something) in those carts. And the R77 uses the presence of these pins as part of the cart reader functionality? Sorry, forget the details now, but as @Thomas Jentzsch says, the cart reader is very unreliable.

The 6.x Stella core in libretro does indeed disable all post-processing effects. No time/resources is spent on emulating that part; it is already disabled when building as a libretro module. It is working exactly as you suggest; just feed raw video and audio data to libretro, and let it handle all other rendering options.

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.

Yes, what's this in reference to (ie, why are you showing us this)?