Images generated by RastaConverter

[Gunstar]

Greenpool Glade. 60 colors.

 

 

GreenPoolGlade.xex

Edited November 21, 2020 by Gunstar

[+MrFish]

That turned out nice.

[Gunstar]

2 minutes ago, MrFish said:

That turned out nice.

Thanks, it was only about a dozen attempts to finally achieve close to what I hoped for...

[+MrFish]

How many attempts does it normally take you?

 

[Gunstar]

With all my practice I can usually get a good conversion in three to six attempts on average. IIRC, my final attempt for 'The Repository' was the fifth or six. Some of my images I redid dozens of times before I was satisfied with the quality to post it. And probably only about 50% of images I attempt to convert make my cut, the other half I give up on and they are deleted and I move on.

 

Most of the images I post I have worked on for a week or more, starting the conversion process, let it run for for hours and hours, or overnight, come back to it, and if it isn't coming along as well as I like, I stop it change settings to what I think will work better than the previous, based on the results, and start it again. Rinse and repeat until I am satisfied with the results. 

 

But I can tell, if I come back and catch it soon enough, if an image will come out good by 50-100 million evaluations, which takes my computer an hour or two to get too, and I can stop it and start over at that point and not waste too much time. But the last few images I've posted were running all day or night before I can get back to them and see the results, as I've been busy with business lately as people get used to dealing with the pandemic and realize that life must go on and you can't just hide from the world forever. After all, there are plenty of ways any one of us could die every day, even just by crossing a road.

Edited November 21, 2020 by Gunstar

[zbyti]

1 hour ago, Gunstar said:

Greenpool Glade. 60 colors.

 

 

GreenPoolGlade.xex 22.03 kB · 2 downloads

Superb!

[+MrFish]

It definitely takes some tweaking to get an image that will process well -- not to mention the time it takes to procure a suitable image for making an attempt.

 

Greens are surely a strong suite for the Atari 8-bit computers...

 

[Gunstar]

One thing I have learned over the years and possibly hundreds of Rasta conversions, is that quite often, instead of trying to get Rastaconverter to convert an image as close to the original as possible, it is far better to tweak the original image, before and within Rastaconverter (mostly just within Rasta personally), to better fit the Atari's resolution and color palette. Allow Rasta to make the best use of the Atari's palette. What you end up with is a conversion that is a version of the original image, not necessarily a close-as-possible copy. Maybe a once blue sky ends up green on the Atari but so what, you now have and image of an alien world instead of ours, but it looks damn good and clear and the audience has no pre-concieved notion of how it is "supposed" to look and accept it for what it is. Only the person converting the image knows how different it may look from the original, the community only see an image that looks good on the Atari. Unless you post the original image too.

 

GreenPool Glade came from an original Amiga color-cycling image where you can choose the time of day and all the colors change in the image, the image gets brighter or darker, etc, but the original shapes of objects are still intact. What I do to make the best use of the Atari's strengths when converting an image is a similar process in some ways. I don't approach a conversion this way every time, much of the time I am attempting to make a copy of the original image, but if Rastaconverter is unsuccessful in it's attempt, then I change the image to better suit the Atari and Rastaconverter is more able to produce a better image. They become unique Atari images. These are usually the images that people comment on the most as being very well done and looking like it were made by a pixel artist on the Atari or even a superior machine (like was commented about The Depository image).

 

I never use masks because, as is intended, Rastaconverter give more attention to that area. Unfortunately it then falls short and struggles more outside of the masked area, so quite often you are trading detail in one area at the cost of the rest of the image. I want the entire image to have the best detail it can, so I fix the image instead, to make it easier for Rasta to capture more detail from it.

Edited November 21, 2020 by Gunstar

[ivop]

26 minutes ago, Gunstar said:

but it looks damn good and clear and the audience has no per-concieved notion of how it is "supposed" to look and except it for what it is. Only the person converting the image knows how different it may look from the original, the community only see an image that looks good on the Atari. Unless you post the original image too.

Exactly this. I have done that, too

 

[Gunstar]

For those who liked the lost-and-found .xex I posted a few pages back pages back of Star Trek's Gorn Commander, I found a later and superior conversion of it. Sorry, again there is no output.png image to accompany it.

 

 

GornCommander2.xex

[+JAC!]

Congratuations for the Cats, the Repository and the GreenPool - really fantastic results.

[drpeter]

15 hours ago, Gunstar said:

the audience has no pre-concieved notion of how it is "supposed" to look and accept it for what it is

One perhaps unexpected 'tweak' to consider arises when you have an image that requires many in-line horizontal changes in colour concentrated mainly on the left side.

 

The 6502 processor (and therefore the colour-changing screen kernel) spends much of its time on the left side of the screen 'frozen' by the ANTIC display chip while the latter accesses screen memory and performs dynamic refresh to RAM memory in general. Consequently, the kernel can make more and faster changes when freed up by ANTIC on the right side of the screen.

 

At the extremes, at the left margin of the image it takes 48 pixels of horizontal resolution to load and save a register, but only 12 pixels at the right margin.

 

If you have an image with a lot of colour detail on the left side that Rasta is struggling to resolve, it's worth considering horizontally flipping the image so that the detail is concentrated on the right.

Edited November 22, 2020 by drpeter

[Gunstar]

7 hours ago, drpeter said:

One perhaps unexpected 'tweak' to consider arises when you have an image that requires many in-line horizontal changes in colour concentrated mainly on the left side.

 

The 6502 processor (and therefore the colour-changing screen kernel) spends much of its time on the left side of the screen 'frozen' by the ANTIC display chip while the latter accesses screen memory and performs dynamic refresh to RAM memory in general. Consequently, the kernel can make more and faster changes when freed up by ANTIC on the right side of the screen.

 

At the extremes, at the left margin of the image it takes 48 pixels of horizontal resolution to load and save a register, but only 12 pixels at the right margin.

 

If you have an image with a lot of colour detail on the left side that Rasta is struggling to resolve, it's worth considering horizontally flipping the image so that the detail is concentrated on the right.

I don't quite understand why the 6502/Antic would have anything to do with the actual creation of the conversion since Rastconverter is a PC app running on a PC when it creates the image that an .xex is produced from. The only time the Atari and 6502/Antic is involved is after the image is completed on a different (PC) computer and then the .xex image is merely displayed on the Atari. This would make perfect sense to me if Rastaconverter was an app running and converting images on the Atari itself, but it makes absolutely no sense to me since it's all done on a modern PC computer. I'd would think could only show up as some sort of corruption when the image is displayed on a real Atari and would still occur once the image is flipped back the right way anyway. I also don't see how you could get the image flipped back to it's correct display orientation to create an .xex image that isn't upside down or mirrored? I can only think that I must be completely misunderstanding you or the way the PC Rastaconverter app works or something here, or you are...

Edited November 22, 2020 by Gunstar

[Rybags]

On the other hand, left side has an advantage that the colour registers can be preloaded during HBlank.  Also 6502 registers can be preloaded for the next required colour changes (though I'm not sure RC does preemptive optimisation such as that)

 

But still - it's worth a shot.

 

The creation process - where it runs isn't really relevant.  There's consideration of the DMA going on otherwise the timing wouldn't work.

Edited November 22, 2020 by Rybags

[Gunstar]

5 minutes ago, Rybags said:

 

The creation process - where it runs isn't really relevant.  There's consideration of the DMA going on otherwise the timing wouldn't work.

Now this I can understand, but then how do you flip the image back to correct orientation for proper display on the Atari with the created .xex file, and if done, wouldn't that totally screw up the DMA timing and you would get garbage on screen or the Atari would crash or freeze or when what was created on the right side of the screen is then flipped so it is back on the left for proper viewing? Or are we just supposed to view images that are flipped for Rasta to better handle the color changes upside down?

[Rybags]

No, I think the point he's making is that you just flip the image horizontally and leave it there for cases where more colour changes occur on the left.

 

For most types of pictures, you'd not notice the difference.  If there's text content, it could probably be edited to flip it around beforehand.

[Gunstar]

5 minutes ago, Rybags said:

No, I think the point he's making is that you just flip the image horizontally and leave it there for cases where more colour changes occur on the left.

 

For most types of pictures, you'd not notice the difference.  If there's text content, it could probably be edited to flip it around beforehand.

So a mirror-image flip and not upside down, and leave it as a mirror image for the .xex...OK, I understand all of it now, thanks. And thanks for the tip @drpeter ! I will start using this process in my conversions that need it.

Edited November 22, 2020 by Gunstar

[drpeter]

23 minutes ago, Gunstar said:

I don't quite understand why the 6502/Antic would have anything to do with the actual creation of the conversion since Rastconverter is a PC app running on a PC when it creates the image that an .xex is produced from.

The Rasta algorithm (apart from the notorious horizontal player positioning bug) is by necessity programmed to 'understand' the timing constraints produced on a real Atari by the interactions between 6502, ANTIC and GTIA when writing to graphics registers 'on-the-fly' to produce images supported by a 6502 screen kernel slaved to the raster display of the TV.  The algorithm 'knows' how long it takes the 6502 to write to a graphics register during horizontal blank and at various points as the raster beam moves across a scanline from left to right and operates within those constraints in producing the screen kernel program that generates the destination image on an Atari.  The algorithm is in one sense 'emulating' the Atari hardware although running on a PC, which is why the .xex images (a combination of bitmap, player data and the kernel program) turn out as intended when run on an Atari (or Altirra).

[drpeter]

1 hour ago, Rybags said:

On the other hand, left side has an advantage that the colour registers can be preloaded during HBlank.  Also 6502 registers can be preloaded for the next required colour changes (though I'm not sure RC does preemptive optimisation such as that)

That's all correct, and RC does this kind of pre-emptive optimisation, so I am overstating the case for sure. To be more precise about things, until the 70th horizontal pixel (from the left screen border) it takes 32 pixels of horizontal resolution to write even a pre-loaded colour update, but also by the time you get down to using exactly 12 pixels of 'time' to load and store a colour update you've actually reached the right border of the image and it's too late, but from the 70th pixel onward it takes  24 pixels to load and store a colour update (or 16 pixels to write a pre-loaded colour update) and this starts to fall further once you get to the 150th pixel.

 

Obviously, it's a problem with images that don't look right in left-right mirror-image (unless pre-processed to correct mirror-image text, for example) but it's a real effect and should help in rendering some images.

 

My 'Badger' (above) is a good example of an image with much more colour variation on the right of the image than the left.

Edited November 22, 2020 by drpeter

[Gunstar]

1 hour ago, drpeter said:

The Rasta algorithm (apart from the notorious horizontal player positioning bug) is by necessity programmed to 'understand' the timing constraints produced on a real Atari by the interactions between 6502, ANTIC and GTIA when writing to graphics registers 'on-the-fly' to produce images supported by a 6502 screen kernel slaved to the raster display of the TV.  The algorithm 'knows' how long it takes the 6502 to write to a graphics register during horizontal blank and at various points as the raster beam moves across a scanline from left to right and operates within those constraints in producing the screen kernel program that generates the destination image on an Atari.  The algorithm is in one sense 'emulating' the Atari hardware although running on a PC, which is why the .xex images (a combination of bitmap, player data and the kernel program) turn out as intended when run on an Atari (or Altirra).

Thank you for clearing that all up for me. I've always known that Rastaconverter has to work within certain restrictions that can be processed by the Atari when displaying an .xex image file, I just never realized that there were such huge fluctuations in processing cycles to make the changes from left to right on the screen. Not being a programmer, I wasn't aware of these facts in these timings within the screen kernel, etc. and that Rastaconverter had to work within them as well. Thanks again!

 

I am learning to program, in assembly, little by little, and I know of the basic concepts of the 6502 and other Atari processors now, including memory mapping and  Registers, Accumulator, Stack, Stack Pointer, and programming kernels, etc., but am, as of yet, little more than aware of their existance and why they exist.

 

Basically, I read the Hofacker paperback 'How to Program Your Atari in 6502 Machine-Language' but have yet to study it and other books and put to practical use and practice...

 

I also have Compute!'s 'Machine Language for Beginners' and ZAKS 'Programming the 6502' and 'Advanced 6502 Programming' as well as the usual Atari-only suspects like Mapping, De Re, etc. for learning and reference.

Edited November 22, 2020 by Gunstar

[drpeter]

16 hours ago, Gunstar said:

I wasn't aware of these facts in these timings within the screen kernel, etc. and that Rastaconverter had to work within them as well.

The best source I have found for referencing and understanding these matters is the Altirra Hardware Reference Manual, which also has nice colour maps showing where on the screen and why 6502 cycles are 'stolen' by ANTIC in all graphics modes, but specifically in our case in Rastaconverter's display list- which is ANTIC Mode E with a 'load memory' instruction on every line and, of course, player-missiles enabled.  This leaves the 6502 operating for only 57 machine cycles on each scanline out of a possible 114, but also those 57 cycles far from evenly distributed across the scanline- most available processing occurs on the right half of the screen and in horizontal blank.

 

I have become acutely aware of these constraints when trying to edit the RastaConverter kernel to remove artefacts caused by the player horizontal-positioning bug. The programmer has much more leeway when trying to make changes on the right half of the screen....

[drpeter]

Furthermore, if you want to see ANTIC's cycle-stealing 'in action', run a RastaConverter xex in Altirra then press Shift-F8.  Pale vertical bars/pixels indicate where the 6502 is 'frozen' by ANTIC, the remainder shows cycles when the 6502 is actually running, on each line of the display:

 

 

 

 

The vertical pale band far-left is (8 cycles) where ANTIC is loading display-list and player-missile data.  The 9 vertical bands in the 8 lines above the main screen display are dynamic RAM memory refresh cycles, which occur every scanline, even during vertical blank, on the left side of the screen. In the main display, these are added to by screen (bitmap) memory fetch cycles, which begin just before (to the left of) the image and (in Mode E) occur on alternate cycles until just before (to the left of) the right image border.

 

The consequence of this to RastaConverter is that it can only make changes to colour registers precisely on cycles where the 6502 is running- i.e. in the picture, those which are not 'greyed out'.  (In fact due to ANTIC/GTIA timing delays, any such changes appear not in the next pixel to be displayed (to the right) but the one after that.)

In practice, due to the way RastaConverter is programmed, it only ever makes changes on even cycle counts, so it is even more constrained, to making changes only on alternate cycle boundaries (alternate vertical bands as displayed in this image).

 

As mentioned previously, it takes 4 cycles of the 6502 to store even a colour value pre-loaded into the X,Y or A register, so looking at the image above you can see that even if the kernel saves a pre-loaded colour change at the first opportunity (the second vertical 'dark' bar from the left of the image above), by the time it has saved a further 2 colour updates from the remaining 2 registers (another 8 cycles) it has reached the 10th vertical 'dark bar' and is halfway across the screen (this third colour update will first display in the 76th pixel from the left border).

 

Thus even with optimal pre-loading of all 6502 registers with colour updates during horizontal blank, it is barely possible, and then only at very fixed points, to squeeze in 3 colour updates that appear within the left half of the screen. In practical terms, you can pretty much call it only 2.

 

Thanks as always to @phaeron for making and documenting such a fabulous tool for all of us.

Edited November 23, 2020 by drpeter

[drpeter]

Basilica di Santa Maria della Salute

 

Venice, 55 colours

 

Painting by Salvador Fuster Vercher

 

 

drpeter_Venice.xex

[www.atarimania.com]

Hope to see some pictures in honor of Diego Maradona, tried one but it didn't do him justice.

[a8isa1]

[NTSC]

 

-SteveS

 

[EDIT]

40 Colors

a8isa1_horses1.xex

Edited December 2, 2020 by a8isa1