Ben from Plaion Posted January 21 Author Share Posted January 21 8 minutes ago, DirtyHairy said: The elegant solution would be to create a JavaScript flasher that uses WebUSB and runs in Chrome. Theoretically can this be possible for the Mainboard IMG and Dumper EXE, even if it was two seperate actions? Quote Link to comment Share on other sites More sharing options...
John Stamos Mullet Posted January 21 Share Posted January 21 I love following this thread just for the learning opportunity it presents. 7 Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted January 21 Share Posted January 21 39 minutes ago, DirtyHairy said: Good point. My chip just got slightly warm, not hot, so I didn't consider it, but I didn't check the temperature systematically. Maybe someone who has issues should open their device and check the temperature with their fingers. [root@rk312x:~]# cat /sys/class/thermal/thermal_zone0/temp cat: /sys/class/thermal/thermal_zone0/temp: Invalid argument Boo. I guess it's not enabled in the kernel? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 21 Share Posted January 21 29 minutes ago, karri said: My cart has no problems to provide data for F4, F6 and F8 carts. Supporting SC ram makes no difference. The SC RAM is quite slow. E.g. it is too slow to run code in it. Which means it cannot be even read at 1.19 MHz. Quote Link to comment Share on other sites More sharing options...
larsvonhier Posted January 21 Share Posted January 21 (edited) 51 minutes ago, Nathan Strum said: I'd like to second this request. Not anywhere near as high of a priority as sorting out compatibility and dumper issues of course. But it's something that would be nice to have down the road (and it would make the 2600+ more consumer-update-friendly than dealing with VMs and such). https://wiki.radxa.com/Rockpi4/install/rockchip-flash-tools Found this and right now compile the stuff on my M1. Let's see how far I can get with it... edit: Will this only work for RockPi(4) or is it a universal flash tool for other CPUs as well? edit2: darn, wrong type of chip and not universal, it seems. But how about this (correct RK3128 but different console): https://github.com/Ruka-CFW/rk3128-cfw/releases perhaps it could be adapted for the 2600+ ? Edited January 21 by larsvonhier Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted January 21 Share Posted January 21 (edited) 35 minutes ago, Ben from Plaion said: Theoretically can this be possible for the Mainboard IMG and Dumper EXE, even if it was two seperate actions? Sure, in the sense that people would use the same web page to first flash the Linux image, and then flash the dumper. Edited January 21 by DirtyHairy 2 Quote Link to comment Share on other sites More sharing options...
Maq Posted January 21 Share Posted January 21 Testing the AtariDumper1.1.0.9 version with 3 games that did not work for me, they are pal versions, Coleco's zaxxon, crossbow, karateka now they start perfectly with this version, good job, I hope they review why the tower toppler displays the towers poorly, greetings 3 Quote Link to comment Share on other sites More sharing options...
John Stamos Mullet Posted January 21 Share Posted January 21 21 minutes ago, Maq said: Testing the AtariDumper1.1.0.9 version with 3 games that did not work for me, they are pal versions, Coleco's zaxxon, crossbow, karateka now they start perfectly with this version, good job, I hope they review why the tower toppler displays the towers poorly, greetings The tower toppled issue is because the game was coded for a composite/coax RF input on a CRT TV. The emulator would need a filter to mimic a CRT display to display it correctly. you would see the same issue from a genuine 7800 if you used an s-video video mod through an HDMI scaler 1 Quote Link to comment Share on other sites More sharing options...
Ben from Plaion Posted January 21 Author Share Posted January 21 (edited) 35 minutes ago, Maq said: Testing the AtariDumper1.1.0.9 version with 3 games that did not work for me, they are pal versions, Coleco's zaxxon, crossbow, karateka now they start perfectly with this version, good job, I hope they review why the tower toppler displays the towers poorly, greetings Tower Toppler display has also been fixed very recently @Dr Karnov tested a build not yet released and made me a video. He can give you some feedback to how the test version played. VID_20240119_190835.mp4.fb5c6c5307ecbeecda4783349dd464a6.mp4 Edited January 21 by Ben from Plaion 9 Quote Link to comment Share on other sites More sharing options...
Maq Posted January 21 Share Posted January 21 22 minutes ago, Ben from Plaion said: Tower Toppler display has also been fixed very recently @Dr Karnov tested a build not yet released and made me a video. He can give you some feedback to how the test version played. VID_20240119_190835.mp4.fb5c6c5307ecbeecda4783349dd464a6.mp4 18.72 MB · 0 downloads Thanks for the information, every day everything gets better, thank you 2 Quote Link to comment Share on other sites More sharing options...
Ben from Plaion Posted January 21 Author Share Posted January 21 2 minutes ago, Maq said: Thanks for the information, every day everything gets better, thank you Dont thank me, thank @raz0red and @RevEng for their magic. 7 Quote Link to comment Share on other sites More sharing options...
MrChickenz Posted January 21 Share Posted January 21 49 minutes ago, John Stamos Mullet said: The tower toppled issue is because the game was coded for a composite/coax RF input on a CRT TV. The emulator would need a filter to mimic a CRT display to display it correctly. you would see the same issue from a genuine 7800 if you used an s-video video mod through an HDMI scaler I was wondering if the cause of the clicking sound in Pitfall is related to the HDMI some how. But there’s no clicking on the Retron. 77. Quote Link to comment Share on other sites More sharing options...
Bitsized Posted January 21 Share Posted January 21 2 hours ago, Albert said: I also use Macs as my primary machines, so I third this request. But I'm guessing that's unlikely, as the companies that make these devices usually only provide Windows software to update them. Because of this, especially for the many legacy flash and EPROM parts I have that require Windows software, I use Windows VMs and dedicated Windows machines for these purposes. But I know that's not an option (or at least an easy option) for many who only use Macs. ..Al I fourth this request - expecting not to have it granted, but hoping for the best. 1 Quote Link to comment Share on other sites More sharing options...
astroguy Posted January 21 Share Posted January 21 5 hours ago, karri said: Stargate / Defender II (8K) Crack'ed (16K) prototype Crystal Castles (16K) Dark Chambers (16K) Dig Dug (16K) - 1st SARA-enabled game Save Mary (16K) prototype Fatal Run (32K) The above work fine with my multi-cart, including Aardvark. I'll try to find some time to try the others you've listed. 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted January 22 Share Posted January 22 4 hours ago, karri said: My cart has no problems to provide data for F4, F6 and F8 carts. Supporting SC ram makes no difference. Currently I can run the cart at 400MHz and it keeps nicely up with the 7800 RType experiments. So I can assure you that the problem is not the dumper speed. Here is the code for the Aardwark cart emulation. Otaku-flash/build26romF4SC.py at main · karrika/Otaku-flash (github.com) I can assure you that the dumper speed is faster than a real 2600. That is the point I was trying to make here, not that it was too fast for any arbitrary cart. If a lot of carts work, that is great. But if we want *all* carts to work, including those that people already own, the dumper should not try to access data faster than a real 2600 does. 2 Quote Link to comment Share on other sites More sharing options...
Cody2000 Posted January 22 Share Posted January 22 @Ben from Plaion any stable releases newer than 1.1 that could be released to the public yet for testing? Quote Link to comment Share on other sites More sharing options...
Dr Karnov Posted January 22 Share Posted January 22 6 hours ago, Ben from Plaion said: Tower Toppler display has also been fixed very recently @Dr Karnov tested a build not yet released and made me a video. He can give you some feedback to how the test version played. VID_20240119_190835.mp4.fb5c6c5307ecbeecda4783349dd464a6.mp4 18.72 MB · 0 downloads If anyone wants to see any additional footage of Robot Tank (NTSC) or Tower Toppler (PAL) running on the new beta firmware, just let me know and I can record some later on 2 Quote Link to comment Share on other sites More sharing options...
John Stamos Mullet Posted January 22 Share Posted January 22 15 minutes ago, Dr Karnov said: If anyone wants to see any additional footage of Robot Tank (NTSC) or Tower Toppler (PAL) running on the new beta firmware, just let me know and I can record some later on Thankfully, Ben already shared the updated dumper that fixes Robot Tank! 1 Quote Link to comment Share on other sites More sharing options...
Dr Karnov Posted January 22 Share Posted January 22 16 minutes ago, John Stamos Mullet said: Thankfully, Ben already shared the updated dumper that fixes Robot Tank! Yes indeed. Not everyone has updated their machine, and not everyone has those carts so I just thought I'd offer 2 Quote Link to comment Share on other sites More sharing options...
+karri Posted January 22 Share Posted January 22 9 hours ago, Thomas Jentzsch said: The SC RAM is quite slow. E.g. it is too slow to run code in it. Which means it cannot be even read at 1.19 MHz. This explains why the cart occasionally works. If the writes don't get registered then the dumper dumps the data as a plain F4 cart. The RAM does not have time to work properly. The RAM in my cart works fast enough for running the display lists so it reacts immediately. But the real problem is that you have to invent a way to dump the RAM area reliably without writing random static in the RAM during the dump process. Quote Link to comment Share on other sites More sharing options...
+karri Posted January 22 Share Posted January 22 7 hours ago, astroguy said: The above work fine with my multi-cart, including Aardvark. I'll try to find some time to try the others you've listed. Wow! Could you share your code for the F4SC? I would like to understand why my implementation fails. Quote Link to comment Share on other sites More sharing options...
+karri Posted January 22 Share Posted January 22 6 hours ago, batari said: I can assure you that the dumper speed is faster than a real 2600. That is the point I was trying to make here, not that it was too fast for any arbitrary cart. If a lot of carts work, that is great. But if we want *all* carts to work, including those that people already own, the dumper should not try to access data faster than a real 2600 does. I misunderstood your post. All carts that work on a real 2600 should work. Matching the dumper speed with a real 2600 should not be difficult to do. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 22 Share Posted January 22 1 hour ago, karri said: This explains why the cart occasionally works. If the writes don't get registered then the dumper dumps the data as a plain F4 cart. The RAM does not have time to work properly. The RAM in my cart works fast enough for running the display lists so it reacts immediately. AFAIK the dumper doesn't detect RAM. So it won't write to RAM. The extra RAM is detected by Stella, but only if it is dumped identical for each bank. 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted January 22 Share Posted January 22 49 minutes ago, Thomas Jentzsch said: AFAIK the dumper doesn't detect RAM. So it won't write to RAM. The extra RAM is detected by Stella, but only if it is dumped identical for each bank. If the dumper reads any location of the ROM in the range 0...127 it is interpreted by the cart as a write and it will change the values in the locations 128...255 of the ROM. The problem here is that there is no RW pin connected to the cart so the cart cannot see the difference between a read and a write. If the dumper does a write to location 0 everything is fine and the value of the write goes to the location 128 of the ROM. If the dumper does a read to location 0 there is no chip outputting data to the databus and the dumper writes garbage to location 128. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 22 Share Posted January 22 1 hour ago, karri said: If the dumper reads any location of the ROM in the range 0...127 it is interpreted by the cart as a write and it will change the values in the locations 128...255 of the ROM. Ah yes, that's correct. 1 hour ago, karri said: The problem here is that there is no RW pin connected to the cart so the cart cannot see the difference between a read and a write. If the dumper does a write to location 0 everything is fine and the value of the write goes to the location 128 of the ROM. If the dumper does a read to location 0 there is no chip outputting data to the databus and the dumper writes garbage to location 128. Hm, but then why are SC RAM dumps reported to be working in the 2600+? @Ben from Plaion Or does the dumper detect extra RAM now? 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.