DirtyHairy

Just finished catching up. Thanks alot for your results! Do you get the lockups also at lower DRAM clock speed? The different RAM chips are interesting. My own unit has an unmarked chip, just like @fredtriestomakeretron77work's. However, mine is rock solid.

Thanks alot! A crash means that your DRAM is wonky, even without the red background 😏 However, if it is stable enough to play, then there is nothing to worry about. Looking forward to the results for your other two Retrons!

🤣 Thanks again for your assistance!

Please read the first post and stay on topic Have you tried any of the builds with reduced DRAM clock that I linked? Have you tried the memtester for them?

Hi folks! It's been over three years now that we first released an updated firmware for the R77 that runs Stella 6. While the firmware runs fine for me and many other people, we (the Stella team) have received a rising number of reports of R77s on which it crashes frequently over the last year or so. The suspicion always has been that this is caused by bad hardware, but none one of us have a crashing console, so we couldn't actually check what is going on. Well, this has changed as an extraordinarily helpful user on github has not only opened a bug report but also soldered a header to the UART on the board and attached a USB dongle. The result is not exactly encouraging, but at least we now have a culprit and can do some more systematic testing. What is the issue you ask? The lucky winner is.... faulty DRAM 😛 🙄 It seems some devices either contain bad DRAM chips, or have bad solder connections, or whatever, and this causes the device to crash hard if there is heavy load on the memory bus. And with crash hard I mean a hard kernel oops for those that are into Linux. Stella dies, the kernel oopses, and the SD slot switches and changes into a JTAG port. At this point the screen has frozen, and the system has to be power cycled. Basically a hardware crash. Why doesn't this happen with the stock firmware you ask? Stella 6 uses the GPU of the H3 SOC much more aggressively than the stock firmware did, and this is increasing the load on the memory bus (the amount of data transferred). It seams the faulty units run stable enough with the stock firmware (which doesn't use GPU acceleration at all), but crash under the heavier load caused by the new firmware. What can we do? Not much I am afraid. If you scour the web you'll find that DRAM issues are not uncommon with the Orange Pi design that the R77 is based on. One obvious screw to turn is DRAM clock speed, and indeed this makes divergentdeveloper's (the person on github) R77 run much more (although not 100%) stable. Of course, there is a limit to that, as setting the speed too low will cause frame drops. Another thing to try is cooling the DRAM. The chip has no heatsink in the R77, and adding one might improve stability. Other than that... sorry, you're out of luck. Changing the DRAM clock implies changing the bootloader, which is part of the SD image. I have prepared four different images of a build based of Stella 6.7 (not the final one though, there are still some paddle bugs that I need to work out). You can find those images on github here and here. There builds also contain a test program that was specifically created (not by me) to test for DRAM issues. In order to run the test create a file called "memtest" (the contents are irrelevant) at the root of the SD card and turn on the R77. You will see a spinning companion cube on a grey background. If your console has bad DRAM it will eventually crash, at which point the cube will stop spinning and the background will turn red. It would be awesome if the people with crashing R77s try those images at different DRAM clocks, check whether they improve the stability when running Stella and run the memtester to get a definitive answer on the system's stability at different clock speeds. Also, if you have a spare heatsink, try attaching at to the DRAM chip and check whether stability improves. Please report back here on your findings. While we won't be able to fix this issue we would like to know how widespread it is and how different clock speeds affect the buggy systems.

Reminds me that I fixed a shader bug last fall that caused ugly artifacts in TV emulation on apple silicon, but I forgot to update the embedded example at https://6502ts.github.io/stellerator-embedded/ . Fixed now.

I'd be happy to support this.

When I first appeared on this forum I was looking for feedback on my own emulator, 6502.ts. I got a lot of valuable feedback, and by suggestion of Thomas I joined Stephen and Thomas to port my TIA core to Stella. A lot of people tested the new core and helped perfecting it, and the result eventually became Stella 5. This was an awesome time, and a lot of fun. The next big thing that we added to Stella after that was cycle exact audio, which made Stella and 6502.ts the first software emulators to support this, and already there we got much less feedback. We added many more improvements to Stella, and the perceived interest in those declined with every release that we did over the last years. There are also other 2600 projects that I did, including the R77 port and contributions to the Unocart firmware, and interest in those also is a mixed bag. The R77 in particular attracted a lot of interest, but after the initial novelty subsided, what remains (naturally) are complaints about stuff that is broken at the hardware level and (rightful) complaints about event handling bugs. I have also done more work on 6502.ts, but interest in that has pretty much been zero. Now, I am not writing that because I want or need to be cheered at. My primary motivation in doing such projects is curiosity and the satisfaction of solving problems, and not fame (retrocomputing probably isn't the best way to rock stardom anyway ). However, this kind if intrinsic motivation is not a constant, but it comes and goes over time, and when it is low extrinsic motivation in the form of interest and feedback helps a lot. Currently, my intrinsic drive to work on 2600 projects is pretty low, and as the worst thing to do to something enjoyable is turning it into a chore I'll take a step back for some time. I definitely won't be going away, and I will resume doing 2600 related stuff sooner or later, but at the moment the spare time that I have (which currently is a scarce resource anyway) feels more rewarding when put into other projects. That said, there are a lot of people that have provided tons of constructive feedback, sparring and help over the years, and I am very much indebted to those. And then, there's also Stephen and Thomas who are doing an awesome job on keeping Stella alive and well even after decades of development, and who are an awesome team to work with. Thanks to all of you!

We were having regular issues with settings on the R77 that were corrupted because the device was switched off while a write to the settings file was still being flushed to disk. The same problem existed on other platforms, but less dramatic (as people usually don't switch them off while Stella is still running). That's why we introduced sqlite: it is designed to deal gracefully with incomplete writes.

Thanks alot for building, though As Thomas says, I still want to iron out a few issues with paddles attached directly to the R77, plus a switch to disable overclocking before I release. I guess I'll have a release ready sometime next week.

Och, I misread, thought only the ranger behaved like that.

I have a suspicion ? @Draxxon Do you experience a deadzone with the ranger on the old firmware? The video looks to me as if Hyperkin actually tried to work around the deadzone in the controller firmware and deliberately programmed it to "jump" over the deadzone that is enforced by the linux kernel. That would explain what you are experiencing.

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.

? Yeah, I somewhat suspected this.

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)?

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.

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!

Not to my knowledge. I think this is more a theoretical issue than anything else, and imo the pain of addressing it is not worth it.

TIASound.c does not emulate the noise generator of the TIA, it just reproduces the patterns generated by the generators. This means that the transitions and phase of the different signal patterns are off, and you notice this most if there are pronounced interference effects between both channels. I found that AVCSTec Challenge or the Homestar Runner demo demonstrate that effect well, in addition to the ROMs you mention above. Have a look at the audio implementation in Stella or 6502.ts, they are based on a C simulation of the noise generator circuit kindly provided by @Crispy, and they are much more correct. To my knowledge, the only missing detail is that volume changes are only applied when a new sample is generated (which is twice per scanline), while the change takes effect immediately on hardware.

Ups, sorry, typo, "browser" is what I wanted to write ?

Why? The CORS standard defines Origin for that: if the client sends Origin, you answer with Acces-Control-Allow-Origin. If there ist no Origin header in the request you can omit it. However, you are doing POST with a custom header, and I would expect that this implies a preflight OPTION request from the server that you have to answer with Access-Control-Allow-Origin and Acces-Control-Allow-Headers (in order to whitelist the header). You shouldn‘t have to worry about this yourself though, most web framework can handle CORS if configured for it.

@Al_Nafuur Are you going to switch? We are currently finalizing Pluscart support in Stella, and I wonder whether I keep the old header or send new one ?

Just don't include the nick field if someone has not registered. Otherwise, let's take the 1 char minimum then.

Why? To me that sounds like unnecessary optimization. If the packet fragments, so what? Besides, the request size will still be way below the MTU. Using an ESP connected via serial to an Atari 2600 already excludes high performance communication ? EDIT: Besides, now that I rethink this, an HTTP request larger than the MTU will not usually cause fragmentation at the IP level. Instead, afaik,socket transmissions that exceed the MTU will be split by the network stack into multiple IP packets that fit the lowest MTU on the path.