fluxit
-
Posts
588 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by fluxit
-
-
Without modifications, the wico doesn't speak the trak-ball 'language.'
-
Try cleaning the contacts or use a different reader if you can. A read-only sd card usually is usually an indication of a connector issue in my experience.
-
I think that the door looks great, although it does remind me more of a chest than a door.
Is it my imagination, or does the player character accelerate faster in the 7800 version?
-
15 hours ago, Bucket said:
I have a MOGA Power controller that I've been using with RetroArch on my smartphone. It works great; it connects via Bluetooth, has both Xinput and Dinput modes, has a mount for my phone, and also acts as a battery charger.
https://www.amazon.com/PowerA-MOGA-Hero-Power-Electronic-Games/dp/B00FB5R9OY/
So... the battery in it is on its last legs. Can anyone recommend a replacement that has most if not all of the same functionality?
Why not replace the battery? Does the controller have other wear related problems?
-
O'Sheas had Jungle Hunt. Mine was dead out of the box.
-
-
Currently, the trak-ball does not work on the Retron 77 without using a 2600-daptor or similar device.
-
-
13 hours ago, John Saeger said:
I also use linux mint. I'm using 19.1. When I ask for properties and it tells me it's a shared library. So I guess it's weird, but I don't know why. The problem with linux is there are so many distros and so many repositories that trying to get it packaged so that things make sense looks difficult. Even getting into the system at the major distros is a little bit political and I don't personally think it's worth the trouble. I've been thinking about packaging the linux app as an appimage which might help things make more sense. But there's something to be said for installing the latest libraries and compiling from source on linux. So I guess I'm still debating what to do. Anyway, hopefully you eventually begin to enjoy the command line prompt.
Thanks!
Apparently, it's a bug. But the issue is controversial(like so many things linux related.) Adding the linker option "-no-pie" does produce a working z26 binary here that is detected correctly by nemo. IMO, PIE executables should be able to be identified by reading the ELF header. Oh well.
I'm not really new to linux, I've been using unix-likes since 1993 IIRC. I just haven't been compiling anything on a regular basis lately, and I switched flavors just a couple of weeks ago as well.
-
Sorry for the noobish question. I built z26 on Mint Cinnamon "bionic." I also changed js1 fire to spacebar(horrors.)
I just ran make, and after setting the resulting binary to executable, it runs fine from a terminal, but isn't recognized as an executable(other than in "Properties") and will not run from nemo.
Any ideas about what is strange about my executable?
-
That's entirely up to you. Many people keep the original card with its software unmodified as a way to easily restore the system to its 'stock' condition.
There's no technical reason why you can't write the new firmware to your original card. That's what I've done.
-
Per Dirty Harry's Wiki for the R77 firmware updates, this should work, assuming the listing is accurate.
The reviews seem to indicate that the above linked NIC is probably not actually RTL8152 based. There are many listings on ebay for rtl8152 chipset usb NICs though. It shouldn't be hard to find one that works.
I was curious, and wasn't adverse to having an extra USB NIC around, so I tried the above linked lan adapter.
The one that I received _does_ actually** have an RTL8152 chip, and it works with the R77. However, it didn't work for me when plugged directly into the OTG cable, only when plugged into an(unpowered, for what it's worth) hub. I've noticed this with a few devices, that the R77's USB doesn't seem to like to negotiate directly with some USB devices if they have been powered up before the R77, as they are when plugged directly into the OTG.
So, in other words- if you have a USB device that 'should' be working with the R77 but isn't, try plugging it in directly(if through a hub,) or through a hub if direct before giving up.
** note that I'm not guaranteeing that purchasing the linked adapter will get you one that is compatible with the R77, just that it worked for me.
-
1
-
-
The cart plays nicely on my 7800 and Retron 77.
One small thing- if you want to share your score with someone, you'd better be quick. It's only displayed for ~20 seconds, and pause doesn't work on the end screen if you are using a 'real' 2600 compatible.
-
3
-
-
Open it up and take a look.
-
It's a 500k trim pot. Almost anything in this range can be made to work.
You'll probably want to choose something of the vertical adjustment type similar to the original.
-
Nice challenge.
I'm not sure that I'd have crashing into a drone kill the player, as it leads to instant deaths when you are unlucky enough to be entering a screen at exactly the same time that an enemy drone is leaving it which seems a bit unfair.
The ship 'engine' and motion sounds do not cease when all player ships have been destroyed.
-
1
-
-
That sounds like a valid theory and I am looking forward to your results.
Could this be also the reason for the other problem, that one paddle is influencing the other one? So that one paddle drains the power of the other one? But then, why only in one direction?
I don't actually think that the two problems are directly related, although that remains to be seen. I'm thinking that the ADCs are not actually physically separate circuits(in as far as that's possible) inside the MCU, and that is what is causing the interaction that we're seeing. Fixing it on Hyperkin's part might have been as simple as using different sets of inputs for the paddle lines, or it could be simply that this was not a good choice of a chip for this particular use.
One of the tests that I'll run will be to provide separate voltage reference sources for paddles in a pair, to see how that affects the noise level. Sadly, I can't use different inputs on the MCU without butchering the board or modifying the firmware, which I'm not willing to do at this time.
At most I'll power the MCU separately from the main board if my scope shows that to be potential issue, though I hope it doesn't, because I don't really want to get into that either.
-
From what I can see, it appears as though the paddle jitter problem may be caused by noise that's being picked up by the ADC inputs of the MCU on the controller daughterboard. Said inputs appear to be directly connected to the pins of the front joystick ports.
I'm going to approach this from the hardware side.
Assuming that this 'noise' is not being generated internally by the MCU, and is not a bug in the MCU's firmware(sample size/bittedness conversion error, buffer under/overrun, etc.,) it may be due to an unstable reference voltage source.
The notes that come with the firmware source code claim that the paddle reference voltage is 5 volts, but when I probed the front ports, I never saw anything over 3.4(which I'm guessing is coming directly from the 3.3v vrm, I haven't traced it out yet,) so that seems to be a discrepancy to begin with, unless the note was referring to an original 2600 port, rather than the R77. To date I haven't had a scope connected to the R77 while paddles were connected, so I'm not certain at this point.
I'm currently all out of male db9 connectors, so I have some on order which should arrive in a couple of weeks at which point I will begin testing this hypothesis.
-
1
-
-
Does the Bodnar box display a number on the display that's been tested? I like how the Cnet review that mentions using the tester says that it's "dead simple," but doesn't bother to tell what the box does.
-
1
-
-
The biggest unresolved beef I have with the Retron77 is that the built in controller ports have terrible support for the official paddles. I dont know about anyone else but they are unusably jittery for me, which is not the case when I use them with my 2600. Ideally Id like Hyperkin to release a new controller board firmware to go along with this, because its a shame I dont have the ability to use the original paddles without using a 2600dapter over USB. Im going to get one anyway because itll make playing the 2600 library so much easier, but Id still like the option of using the original hardware.
A new controller board firmware would be nice, but deploying it may not be a straightforward process. I don't think that anyone has looked into this thoroughly, but assuming the MCU allows itself to be reflashed, it may not be as simple as running a flasher program on the R77 via the sdcard. You may have to attach a programmer to the board itself. Hyperkin would most likely want people to send in their R77 for service if such a fix became available rather than arranging for a board swap, but I wouldn't hold my breath on either of those possibilites.
On the other hand, I seem to recall someone reporting that they did send their Retron to Hyperkin, and the paddle jitter issue was fixed as a result. It's too bad that Andrew the Hyperkin rep stopped posting on AtariAge before the initial release of the Retron 77.
-
Did this work on beta 1? If I remember the code correctly, saving per-game preferences currently suffers from the same problem as savekey data: it only happens at certain points (maybe even only on shutdown), and chances are that you switch off the device before the data is saved (if it happens on shutdown, you'll never execute this code path unless you kill Stella via SSH). This will change in the next beta when we move per-game preferences to SQLite, too.
I don't know. I tried to check it for you, but I can't access the 'Controller Options' tab in beta 1. Shift-arrow keys no longer works in beta 1 so long as I can tell, and Thomas' controller mappings weren't available yet. It doesn't seem to be a keyboard issue as shift-tab still works to cycle backwards between options or buttons. I never came across this issue during testing, as I was just using the 'Input' section to temporarily change bindings.
How do you access another dialog tab in beta 1?
-
On another topic — is there a preferred location to put the ROMs so that they show up right when the system boots? Or is there a way to set the default directory where Stella looks for the ROMs? I didn't see anything in the options, and having to navigate a directory tree with a joystick makes my family less interested in using the machine.
/games should work.
-
Whether hotplugging works or not depends on how the driver interfaces with the evdev subsystem of Linux. Tbh, I am surprised that hotplug works for any device at all.
The deeper issue is that the R77 does not run udev (and most likely never will, unless anyone has the nerves to set it up). Thus, SDL2 will only scan for joystick devices on startup (and even this is a hack I had to add to the source). Any device node that belongs to a device that was plugged in after Stella has started will not be picked up by SDL2. I guess that any device that can be hotplugged uses the existing evdev device nodes instead of adding new ones.
That's exactly the conclusion that I came to after checking the dev/input/* node of a device that never worked when hotplugged(and apparently I left out 'cold-boot' testing, as it isn't wireless) on the R77. It did generate a working 'js2' node(active output,) but after unplugging it, none of the compatible devices would generate working nodes.
During my testing this confused me, as devices that could be successfully unplugged and replugged multiple times and even swapped for each other would suddenly stop working. This was apparently due to the order in which they were tested during a single boot.
-
Both the Mayflash and JYS dongles claim to support wireless PS3 controllers. I don't have a PS3, so I can't test one.
Thanks!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Retron77 Compatibility List
in Atari 2600
Posted
Try deleting /stella/settings.sqlite3* so that Stella will recreate them. The current beta release has a bug that will eliminate paddle mappings under certain circumstances, and "defaults" will not restore them for you. I found that starting from scratch does restore working paddle defaults, however. Mappings can also be set manually, but it's a fiddly process for paddles.