Andromeda Stardust Posted July 28, 2018 Share Posted July 28, 2018 It should work with any cable. I am using just a random one I had laying around that was longer and it is fine.I even used "random old hdmi 1.2 cable" (instead of the one included in the box) to connect my 4k UltraHD Bluray player to my TCL 4k LCD HDTV, and it works without issue. I believe the current playback setting is 2160x3840@24Hz, a good bit higher bandwidth than 1.2 allows. Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted July 28, 2018 Share Posted July 28, 2018 Tearing causes visible "rifts" in the picture... It has nothing to do with performance. It has everything to do with performance that's why only games that really push the envelope on the TIA trigger the bug. I can't find any other games that tear besides mine and the tearing is always commensurate with the performance of the underlying hardware; much worse on slower systems. The Retron77 hardware is so fast that the tearing is minimal and only intermittent - it often doesn't happen at all for extended periods, looks like a routine runs periodically (possibly a housekeeping routine, maybe even another system routine outside of Stella) that creates too big a total load; when that intermittent process isn't running there is no tearing at all. Using OpenGL resolves the problem because low level drivers are still written in optimized Assembly for performance. C produces relatively slow and inefficient machine language. Anything written in C could be optimized in Assembly and anything in Assembly can be optimized further if you put the time in and have the ability. A fun way to learn how to optimize Assembly is to start writing Atari games, but it's a really big learning curve to get to the point where you can flush rendering bugs like that or attempt to correct them. Quote Link to comment Share on other sites More sharing options...
tremoloman2006 Posted July 28, 2018 Share Posted July 28, 2018 See post 2100: http://atariage.com/forums/topic/266544-retron-77/page-84?do=findComment&comment=4074223 Use Win32DiskImager to install the image: https://sourceforge.net/projects/win32diskimager/ Thank you. Unfortunately I lack the part that states "assumes general Linux knowledge" so it is of no help to me. I use Linux Mint but that's as much as I know about the OS. Sorry if I'm making a mountain out of a molehill. I truly appreciate all help that you and everyone else has offered. I'm sorry I'm too dumb to figure it out. Trem Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 That part is only mentioned if you want to build the firmware yourself. For the general end user that just wants to "get on with it", simply download the zipped SDcard.img, unzip it, and then use Win32DiskImager to write it to the sd card. I don't know how to put the image onto the SD card from Linux (even though I use Linux myself ). Someone else will have to help with that part, or perhaps you can find a Windows machine to do it? Quote Link to comment Share on other sites More sharing options...
+Karl G Posted July 28, 2018 Share Posted July 28, 2018 Something like: dd if=SDcard.img of=/dev/sdcarddevice should work on Linux, I think? Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 Yep, 'dd' will work, but I think you need a blocksize as well. DirtyHairy listed the actual command somewhere in this thread; no time to look for it right now. Quote Link to comment Share on other sites More sharing options...
Atari Pixel Posted July 28, 2018 Share Posted July 28, 2018 I don't know how to put the image onto the SD card from Linux (even though I use Linux myself ). Someone else will have to help with that part, or perhaps you can find a Windows machine to do it? Hi. I am not a linux expert but in Ubuntu I right-click on the sdcard.img file then choose "Open with->Disk Image Writer". I've been experimenting with the 0.9-3 hyperkin build with limited success. I can create the sdcard.img and fire it up on the retron fine. However I got this quirk where stella freezes after pressing the aspect ratio button twice. Doesn't matter if I am using the included 3.7.5 source or the 3.9.3 source provided by stephena on post #2100 in this thread. No alterations on the source code yet from my part. I guess it's something about the libraries I am using? I really don't know. I am using a fresh install of ubuntu desktop 16.04.4 with current updates. Only manual tweaks were installing uboot tools and the device tree compiler. The menu loads up as well as the dumper and stella (so as long as I don't press the aspect ratio button twice). It's not a big deal but seeing that stephena's stella on his community build doesn't have this problem makes me wonder what I am doing wrong. Quote Link to comment Share on other sites More sharing options...
Flojomojo Posted July 28, 2018 Share Posted July 28, 2018 Thank you. Unfortunately I lack the part that states "assumes general Linux knowledge" so it is of no help to me. I use Linux Mint but that's as much as I know about the OS. Sorry if I'm making a mountain out of a molehill. I truly appreciate all help that you and everyone else has offered. I'm sorry I'm too dumb to figure it out. Trem Etcher is a nice easy way to write SDcard images. https://www.ev3dev.org/docs/getting-started/#step-2-flash-the-sd-card 2 Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted July 28, 2018 Share Posted July 28, 2018 I've been experimenting with the 0.9-3 hyperkin build with limited success. I can create the sdcard.img and fire it up on the retron fine. However I got this quirk where stella freezes after pressing the aspect ratio button twice. Doesn't matter if I am using the included 3.7.5 source or the 3.9.3 source provided by stephena on post #2100 in this thread. I just built the 0.9-3 Hyperkin release with the Stella 3.9.3 source and it is working - yay! I don't seem to have that issue you are describing with Stella freezing though, and I've pressed the aspect button a bunch of times running a cart and running off of SD. When is that happening for you? Quote Link to comment Share on other sites More sharing options...
Coolcrab Posted July 28, 2018 Share Posted July 28, 2018 So from what I read here the hardware should be able to run the newest Stella? I was afraid that it would be too weak, but this helps a bit. I'm getting mine in soon. (Hopefully monday!) Quote Link to comment Share on other sites More sharing options...
Atari Pixel Posted July 28, 2018 Share Posted July 28, 2018 (edited) I just built the 0.9-3 Hyperkin release with the Stella 3.9.3 source and it is working - yay! I don't seem to have that issue you are describing with Stella freezing though, and I've pressed the aspect button a bunch of times running a cart and running off of SD. When is that happening for you? I sort of figured it out. Turns out I was using a modified version of dumper.c. Now everything is back to normal. It's a bummer cause I can't test for process id's or existence of files while the cart monitoring loop is running. E.g. the dumper code ignores my calls to access() or stat() (or at least I think it is). Without hardware to connect to the orangepi directly I am as blind as a bat. Edited July 28, 2018 by Atari Pixel Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 So from what I read here the hardware should be able to run the newest Stella? I was afraid that it would be too weak, but this helps a bit. The hardware is capable (at least preliminary it is; one won't know for sure until testing is done). However, there is much work to do to get to that state. See "The Future" at https://github.com/stella-emu/stella/wiki/Retron-77 for more info on this. Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 I sort of figured it out. Turns out I was using a modified version of dumper.c. Now everything is back to normal. It's a bummer cause I can't test for process id's or existence of files while the cart monitoring loop is running. E.g. the dumper code ignores my calls to access() or stat() (or at least I think it is). Without hardware to connect to the orangepi directly I am as blind as a bat. The hardware you'd need it described at the bottom of the page https://github.com/stella-emu/stella/wiki/Retron-77. Basically a serial converter module to connect to the serial port on the device. All the info is in the wiki. 2 Quote Link to comment Share on other sites More sharing options...
thetick1 Posted July 28, 2018 Share Posted July 28, 2018 The hardware is capable (at least preliminary it is; one won't know for sure until testing is done). However, there is much work to do to get to that state. See "The Future" at https://github.com/stella-emu/stella/wiki/Retron-77 for more info on this. Seems very wasteful to spend the time to upgrade for this old hardware. Mali400 is basically end of life and a newer SOC architecture that already supports hardware acceleration could be used. 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 Seems very wasteful to spend the time to upgrade for this old hardware. Mali400 is basically end of life and a newer SOC architecture that already supports hardware acceleration could be used. I agree, but if anyone ever wants to get the latest Stella on this hardware, this is what would be required. I agree that better hardware could have been picked, but it wasn't; what's there is what one has to deal with. 1 Quote Link to comment Share on other sites More sharing options...
Keatah Posted July 28, 2018 Share Posted July 28, 2018 (edited) Would better hardware (making stella 5.x easier to port) have been much more expensive? More than an additional $10? I believe everyone here whom has purchased an R77 wouldn't have been swayed not to buy one by a $10 increase to cover that better hardware. Edited July 28, 2018 by Keatah Quote Link to comment Share on other sites More sharing options...
Coolcrab Posted July 28, 2018 Share Posted July 28, 2018 People here yes, but the casual buyers probably not. Imo it's already expensive, this should be a 40-50$ console. If you wanna target the people here then they should make a 200+$ Atari on a chip console that does everything. But I doubt that more than a few hundred people would buy it, making it hard to make a profit. 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted July 28, 2018 Share Posted July 28, 2018 I sort of figured it out. Turns out I was using a modified version of dumper.c. Now everything is back to normal. It's a bummer cause I can't test for process id's or existence of files while the cart monitoring loop is running. E.g. the dumper code ignores my calls to access() or stat() (or at least I think it is). Without hardware to connect to the orangepi directly I am as blind as a bat. There is a UART header on the board and, with a bit of soldering and a UART-to-USB dongle, you can get a terminal. As Stephen writes, the process is documented in the wiki. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted July 28, 2018 Share Posted July 28, 2018 Yep, 'dd' will work, but I think you need a blocksize as well. DirtyHairy listed the actual command somewhere in this thread; no time to look for it right now. Yeah. The blocksize determines he size of the chunks transferred; bs=1048576 (1MB) should work fine. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted July 28, 2018 Share Posted July 28, 2018 Seems very wasteful to spend the time to upgrade for this old hardware. Mali400 is basically end of life and a newer SOC architecture that already supports hardware acceleration could be used. Why? The hardware is more than capable of running Stella 5, and the GPU is supported both by closed source and by open source drivers. With open source drivers integrated in the kernel and mesa, Linux will support the GPU for years to come. The 128MB of RAM are a bit flimsy, but they are sufficient for the task it was set to do as well. The obstacle to running Stella 5 is getting SDL2 to run without a X11 stack, and that wouldn‘t be easier with more recent hardware - if anything, it would be harder as proper hardware support on linux usually lags years behind hardware release. Quote Link to comment Share on other sites More sharing options...
Keatah Posted July 28, 2018 Share Posted July 28, 2018 Pardon if it's an elementary & basic question. But. Is there a reason Stella had to switch to SDL2? Was it for some required functionality? Ease of compiling? Ease of development? Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 The reasons are many and varied, but basically software rendering died many years ago, and I would argue it should have died 10+ years ago. All 2D systems today are actually using 3D hardware acceleration. So you get things for free, like smooth vsync'ed display, stretching to desktop resolution, transparency effects, etc. All of this would have been impossible with software rendering and SDL1. And all are basically 'free' with SDL2. When I say free, I mean in terms of CPU usage on any hardware built in the last 10 years or so. vsync'ed display allows rendering without tearing, which is one of the major issues in the version of Stella on the R77; not possible with software rendering stretching allows to scale the internal 160x200 TIA image to any resolution you want (ie, 4K for my main development system); for software rendering @ 4K, you'd have to be moving 1.8GB/s to the video card, for hardware rendering it's 7MB/s transparency allows scanline modes And the biggest reason; SDL1 was discontinued, obsolete, and no longer supported. The move to SDL2 isn't the issue here. The issue is getting the hardware/OS updated from a 2010 software stack to something more recent. 3 Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 Would better hardware (making stella 5.x easier to port) have been much more expensive? More than an additional $10? I believe everyone here whom has purchased an R77 wouldn't have been swayed not to buy one by a $10 increase to cover that better hardware. As several people have already mentioned, it's not a matter of the hardware not being up to the task; it is more than sufficient. The extra costs would have been from extra development time to get SDL2 working on this system. I've already outlined how to do it; now Hyperkin needs to actually get to doing it. 4 Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 28, 2018 Share Posted July 28, 2018 The larger dd block size is only a performance thing here - it's the same end result with or without it. The performance difference is likely negligible here also. The only time you get functional differences with dd and different block sizes, is when you use arguments that reference specific block amounts. i.e. skip, seek, count Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 28, 2018 Share Posted July 28, 2018 I'd also add that if the R77 is ever updated with SDL2 and Stella 5, it could probably also be upped to 1080p output. I suspect the current 720p limit is again because of software rendering and no acceleration. If hardware acceleration became available, for Stella jumping from 720p to 1080p would be a minuscule difference of CPU/GPU usage. On my systems, there is no difference in CPU usage when running Stella at 800x600 vs. 3840x2160. Video output is a solved problem; use the 3D acceleration present in every piece of hardware released in the past 10+ years. 6 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.