GravityWorm Posted May 13 Share Posted May 13 2 minutes ago, MrFish said: The problem with a SAM Coupé is that the software library is next to nothing compared with the Atari 8-bit computers (unless your goal is 48K Spectrum software); and good luck getting your hands on one; and if you do, make sure you've got plenty of spare cash on hand. The problem with a Atari 800/400 is that the software library not so perfect compared with the Commodore 64 and not all games from C64 are also on Atari... Quote Link to comment Share on other sites More sharing options...
+MrFish Posted May 13 Share Posted May 13 1 minute ago, GravityWorm said: The problem with a Atari 800/400 is that the software library not so perfect compared with the Commodore 64 and not all games from C64 are also on Atari... What does that have to do with a SAM Coupé? Quote Link to comment Share on other sites More sharing options...
GravityWorm Posted May 13 Share Posted May 13 56 minutes ago, Beeblebrox said: If cheap carts with the right tech could give all the benefits then it would be great to have them available, but I don't think they'd replace the other options out there. Thing is, most of the RAM upgrades either aren't that expensive, or are way more than just a simple Ram uprade. Multicarts, especially the likes of SIDE3, AVG and SUBAVG - offer so much more. For example - a Rambo XL 256k upgrade for a stock 800XL will maybe cost £40 all in, maybe even cheaper. A 320k upgrade for an XE might cost £20 all in. True - you have to have the skills to install them, and they are per machine. U1MB is around £90, but is way more than just an ram upgrade. Brian's plug in PBI upgrade boards for the 800XL and 600XL can be switched between stock machines. Same goes for his 400 and 800 ram boards: https://www.tindie.com/stores/5cfab/ On balance - for most people a plugin Multicart like AVG or SubAvg, which can be moved between the XL/XE lines (where extra cabling is required depending on whether an XE or XL), is a good balance. I agree with most what you wrote, but using a cartridge is more like metal fans would say "trü"... Important benefit of cartridges - faster load time than disk... And the pictures from RC are big. Making a huge games could be more easy to make... Like RPG, Adventure... Porting PC (EGA) Sierra games would be easier... Quote Link to comment Share on other sites More sharing options...
Beeblebrox Posted May 13 Share Posted May 13 (edited) 21 minutes ago, GravityWorm said: I agree with most what you wrote, but using a cartridge is more like metal fans would say "trü"... Important benefit of cartridges - faster load time than disk... And the pictures from RC are big. Making a huge games could be more easy to make... Like RPG, Adventure... Porting PC (EGA) Sierra games would be easier... I totally agree with the use of the cart format in general. I am so glad that Atari saw fit to include them with the 8bit computer line. What I am meaning to say though is that we have the cart tech already in the form of some of the multicarts. Sure, they can be expensive, but they offer way more that just a basic way to load games. So, I suppose what I mean was your idea of a super cheap cart, where, if it were able to do what you suggest and grant ram to a stock machine, it would still not give you the benefits of the established multicarts. Plus, of course, as FJC says above, it's rather moot as, for a lot of existing A8 games, because of memory locations, clashes, etc etc, it's not viable. I think, given a large amount of A8 owners will have at least 64k machines, and many of us have 128k or higher machines already, having the wide range of flash and multi carts already available is enough. It's so much easier these days to find an path to upgrading your A8's ram. Edited May 13 by Beeblebrox Quote Link to comment Share on other sites More sharing options...
+gnusto Posted May 14 Share Posted May 14 On 4/25/2024 at 2:50 PM, ilmenit said: Beta10 has been released: https://github.com/ilmenit/RastaConverter/releases/tag/Beta10 * pthreads dependency removed (laoo) * Added thousands separator in statistics * Added command line parameter to window title * Changed default auto-save to "auto" to save SSD disks life Hey @ilmenit, Edit a day later: The very low performance seems to be related to using ciede as the distance comparison (in creating the image, not pre-compute). If I switch to YUV/Euclid I get much higher rates, in the hundreds of thousands even, but I need to test different thread counts to see if I get the same falloff behavior. If I can do a full set of tests I'll add that here for posterity. I think something is up with the threading/distribution model in RastaConverter (using this Beta10 that you posted, but I believe this behavior goes back). Please note I am not complaining, I just thought I would just supply this info as maybe it is news to you. I downloaded source to take a look after I found this, but need to go back and download/install all the dependencies and set up includes etc so I can fully locally compile and experiment. In short what I see on a high core/thread machine is not just diminishing returns but negative performance past a few threads. Here's how I compared: Machine 1 is an AMD 7950X3D (base clock 4.2Ghz), which is 16 physical cores, 32 threads, big piles of cache. Machine 2 is Proxmox container running on an Intel N305, 8 cores/8 threads, 3.8Ghz, but the container is 4 threads. I wanted a stark difference - this processor is VERY under powered in comparison, with a very small cache, and I'm taking away half of its cores Both machines are benchmarked in different ways (Geekbench, 3dMark) to establish they are working correctly and close to or above expectation in the general case. I am treating evaluations as the primary metric between the examples. Rate is fairly volatile from update to update so I take a general read of what I think the average of that is when I note it here. I am using the same image as input, no dithering, all the settings the same (color distance ciede, initial state empty so they all do the same workload, number of solutions 10000, auto save off). Then I vary the threads on Machine 1 to test. I let the image generation run for three minutes on stopwatch and then take a read of the values, so each of these is a snapshot at 3 minutes other than rate which is an eyeball average. Machine 2 w/04 threads: ~8000 rate, norm distance 4.2, 1.536M evaluations Machine 1 w/01 threads: ~14000 rate, norm distance 2.3, 2.488M evaluations Machine 1 w/02 threads: ~18000 rate, norm distance 2.3, 3.235M evaluations Machine 1 w/04 threads: ~15000 rate, norm distance 2.8, 2.975M evaluations Machine 1 w/08 threads: ~10000 rate, norm distance 4.4, 1.984M evaluations Machine 1 w/16 threads: ~7500 rate, norm distance 6.5, 1.452M evaluations Machine 1 w/32 threads: ~9000 rate, norm distance 6.9, 1.885M evaluations In all cases the threads are definitely doing something, as I can see them at 100% in process monitor. It seems a bit confusing to sort out what is actually performance here, am I wrong to treat norm distance as an overall quality indicator? The lower it gets the closer you are to the original image, with short term variation of course. By that measure as near as I can tell 2 threads helps, and it actually goes downhill from there - I don't expect efficiency to be linear, but this appears to be a net negative past 2 threads. Edit: Forgot to mention, this is all under Windows. Would be easy to run the same comparison on the same hardware using Linux though. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 14 Share Posted May 14 If you run with just one solution, the image will very quickly converge. On my system (i9 12900) when the image is almost "done", I can get around 385,000 per second. But, sometimes when the conversion starts, I am only getting 50,000 or so. I am not sure if this info helps you at all, but you may want to check that. I have not tried changing from 1 thread up to XX - I can go up to 24. Let me run some tests, and I will either edit, or reply to this post. Quote Link to comment Share on other sites More sharing options...
+gnusto Posted May 14 Share Posted May 14 Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate. 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 14 Share Posted May 14 4 minutes ago, gnusto said: Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate. Oh - I always run high solutions (8192) - the results are worth it. Just wasn't sure if you would get different rates per thread doing it that way, as it may be the hill climbing part of the code causing the behaviour you are seeing. Quote Link to comment Share on other sites More sharing options...
GravityWorm Posted May 14 Share Posted May 14 3 hours ago, Stephen said: Oh - I always run high solutions (8192) - the results are worth it. Just wasn't sure if you would get different rates per thread doing it that way, as it may be the hill climbing part of the code causing the behaviour you are seeing. 8192 is high? My highest is about 34 567 Oh. I'm doing something wrong? Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 14 Share Posted May 14 8 minutes ago, GravityWorm said: 8192 is high? My highest is about 34 567 Oh. I'm doing something wrong? no, your images and atarimans look good 1 Quote Link to comment Share on other sites More sharing options...
Beeblebrox Posted May 14 Share Posted May 14 I tend to run 25000 solutions as standard, always with yuv/yuv and always a mask, sometimes dithering. 2 Quote Link to comment Share on other sites More sharing options...
GravityWorm Posted May 14 Share Posted May 14 16 minutes ago, _The Doctor__ said: no, your images and atarimans look good I'm doing images for Atari man now I did set: 12 345 Quote Link to comment Share on other sites More sharing options...
Sheddy Posted May 14 Share Posted May 14 (edited) 6 hours ago, gnusto said: Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate. Interesting but 3 minutes is barely started! If you run your tests multiple times you should see very varied norm distances as everything about RastaConverter is the randomness of solutions. Edited May 14 by Sheddy Correction 1 Quote Link to comment Share on other sites More sharing options...
GravityWorm Posted May 14 Share Posted May 14 2 hours ago, Beeblebrox said: I tend to run 25000 solutions as standard, always with yuv/yuv and always a mask, sometimes dithering. i did 10 000 but then i drooped having a standard Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 14 Share Posted May 14 13 hours ago, gnusto said: Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate. Here's some results of a quick test I did, from 1 to 24 threads. It was a pretty linear increase in processing rate vs # of threads. Threads Rate 01 24,000 02 52,000 03 51,000 04 115,000 05 112,000 06 132,000 07 145,000 08 125,000 50% CPU 16 224,000 100% CPU 4.47GHz 24 370,000 100% CPU 4.49GHz 1 1 Quote Link to comment Share on other sites More sharing options...
+gnusto Posted May 14 Share Posted May 14 1 hour ago, Stephen said: Here's some results of a quick test I did, from 1 to 24 threads. It was a pretty linear increase in processing rate vs # of threads. Threads Rate 01 24,000 02 52,000 03 51,000 04 115,000 05 112,000 06 132,000 07 145,000 08 125,000 50% CPU 16 224,000 100% CPU 4.47GHz 24 370,000 100% CPU 4.49GHz Thanks for comparing - Did you happen to note norm distance? Were the higher thread counts "better" in the same amount of time? And all of these were sampled at the same amount of time passed? Could be some AMD specific thing, I suppose. But if it is it's weird because the cores are definitely active. I have high core Intel machine to test on as well, so I'll do that. Quote Link to comment Share on other sites More sharing options...
Atari8man2004 Posted May 14 Share Posted May 14 Coffee time Colors: 38 scr /na Atari8man_Coffee_time.xex 5 1 Quote Link to comment Share on other sites More sharing options...
Atari8man2004 Posted May 14 Share Posted May 14 Old Coins colors: 66 plus src Atari8man_Old_Coins.xex 6 1 Quote Link to comment Share on other sites More sharing options...
Atari8man2004 Posted May 14 Share Posted May 14 Apple Pc colors: 55 scr: /na Atari8man_Apple_Pc.xex 2 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 14 Share Posted May 14 53 minutes ago, gnusto said: Thanks for comparing - Did you happen to note norm distance? Were the higher thread counts "better" in the same amount of time? And all of these were sampled at the same amount of time passed? Could be some AMD specific thing, I suppose. But if it is it's weird because the cores are definitely active. I have high core Intel machine to test on as well, so I'll do that. I only let these run for about a minute each to get the rates. But yes - the normal distance improved at a correspondingly faster rate, as the rate increased. Not to say the normal got better when more threads were used. But, let's say the best that could be achieved was a normal of 10, the more threads I use, the faster I approach 10. Quote Link to comment Share on other sites More sharing options...
GravityWorm Posted May 14 Share Posted May 14 (edited) My black tea looks similar Edited May 14 by GravityWorm 2 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 14 Share Posted May 14 Continuing my theme of old Mopar ads, here is a 61 colour version of a Dodge Super Bee ad. I'm working on a few more. Stephen_DodgeSuperBee.xex 4 Quote Link to comment Share on other sites More sharing options...
GravityWorm Posted May 14 Share Posted May 14 3 hours ago, Atari8man2004 said: Coffee time Colors: 38 scr /na Atari8man_Coffee_time.xex 22.09 kB · 4 downloads @Beeblebrox, You are from UK, that looks like black tea? Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 14 Share Posted May 14 21 minutes ago, Stephen said: Continuing my theme of old Mopar ads, here is a 61 colour version of a Dodge Super Bee ad. I'm working on a few more. Stephen_DodgeSuperBee.xex 22.1 kB · 1 download Subtitle text for ' Dodge introduces a new model Super Bee 'would be nice. 1 Quote Link to comment Share on other sites More sharing options...
+gnusto Posted May 14 Share Posted May 14 I was curious so looked it up: $3074 from 1968 inflation adjusted is $27600 today. However, the average salary in 1968 was $4786, so $3074 was 60+% of that salary. The average US salary now is $63,795. Since there is no Super Bee in modern times (they actually brought back the name but dropped it again 10 years ago, we'll ignore that), a closely related Dodge equivalent might be a V8 R/T charger, which goes for around $45K. $45K is about 70% of $63,795. More expensive in a pure buying power sense to be sure, but not as bad as I thought it would be. Amusingly, the starter price v8 Super Bee was a 117 inch wheel base sedan with 335bhp, weighing about 3500lbs. A starter v8 Charger is a 120 inch wheel base sedan with 370bhp (the Hemi is 485bhp though), weighing about 4370 lbs. The modern car has worse horse to weight but clocks in faster, probably because of better suspension, transmission. 0-60 in 1968 was ~6 seconds, 0-60 on an R/T is 5.2. The older car looks approximately 1,068.2% better though. Around there somewhere. 1 1 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.