Chronocolour Enhancement

[chjmartin2]

Hi all,

 

I have been having a lot of fun with the Greeting Card utility that Andrew put out years ago, and in looking at it, it got me wondering. I believe that instead of using just red, green and blue as the color base, you could get a much broader color palette. My first thought was to pick three colors from the 128 color palette that optimized to the best 8 colors for the given 48x128 picture. (Actually, 96x128 picture limited to a single color for 2 successive pixels or 48x128 with a pixel aspect ratio of 2:1.)

 

Anyway, I was diving right into to coding a converter to output a new greetingcard.asm and bank00.asm (which by the way, if you make a really simple PNG file for each RGB file then Andrew compresses the image to take up fewer sprites, neat) using the 18 sprite/3 frame configuration but instead of RGB using 4 colors of the 128 palette optimized for the source image. Chronocolour provides a total of 8 colors, every combination of 4 colors, R000, 0G00, 00B0, RG00, R0B0, RGB0, 0GB0, 0000 or Red, Green, Blue, Yellow, Magenta, White, Cyan and Black. If you were to use other colors from the palette what you would get as a resulting color is the RGB average of the 4 colors you picked. This is why an absolutely red square in chronocolor is actually darker than what you would see for a standard sprite of the same color. If the red RGB values were 255,0,0 (which they aren't because that color isn't available in the 128 color palette) and you had Red in frame 1, black in frame 2 and frame 3 then what you get is Red+black+black = dark red. Effectively, it would be (255+0+0)/3, (0+0+0)/3, (0+0+0)/3 = 85,0,0 - which is why the red in chronocolor is so dark. What I was going to do was take an image and convert it down to the best 8 colors for that image, then go ahead and calculate every possible 8 color palette using every 128 color combination (not too processor intensive if you do it once and store it in an array) and then go ahead and compare the 8 colors I want with the best set of 8 colors I have available.

 

But when I looked at the program it occurred to me that you should be able to pick any individual color per line for each of the three frames. This means you could have eight unique colors per line rather than just the 8 for the total image. You'd only need another 384 bytes to store the colors. I think you'd have a massive palette, but of course limited only to the 8 colors. Frankly, I think if you had just two frames you may be able to make a really great image. You'd still have 4 colors per line (frame 1, frame 2 and the background) from a 16,384 color palette (which is a subset of a 2 million color palette, depending on the background). It may even reduce flicker.

 

So here is my problem. I can write the program to convert an image down to three (or two) frames of black and white and select the appropriate Atari colors. What I can't do is modify the greeting cart program to add in a color for each line in the bank file. Any thoughts on how we could get from here to there faster?

[chjmartin2]

Hi all,

 

I have been having a lot of fun with the Greeting Card utility that Andrew put out years ago, and in looking at it, it got me wondering. I believe that instead of using just red, green and blue as the color base, you could get a much broader color palette. My first thought was to pick three colors from the 128 color palette that optimized to the best 8 colors for the given 48x128 picture. (Actually, 96x128 picture limited to a single color for 2 successive pixels or 48x128 with a pixel aspect ratio of 2:1.)

 

Anyway, I was diving right into to coding a converter to output a new greetingcard.asm and bank00.asm (which by the way, if you make a really simple PNG file for each RGB file then Andrew compresses the image to take up fewer sprites, neat) using the 18 sprite/3 frame configuration but instead of RGB using 4 colors of the 128 palette optimized for the source image. Chronocolour provides a total of 8 colors, every combination of 4 colors, R000, 0G00, 00B0, RG00, R0B0, RGB0, 0GB0, 0000 or Red, Green, Blue, Yellow, Magenta, White, Cyan and Black. If you were to use other colors from the palette what you would get as a resulting color is the RGB average of the 4 colors you picked. This is why an absolutely red square in chronocolor is actually darker than what you would see for a standard sprite of the same color. If the red RGB values were 255,0,0 (which they aren't because that color isn't available in the 128 color palette) and you had Red in frame 1, black in frame 2 and frame 3 then what you get is Red+black+black = dark red. Effectively, it would be (255+0+0)/3, (0+0+0)/3, (0+0+0)/3 = 85,0,0 - which is why the red in chronocolor is so dark. What I was going to do was take an image and convert it down to the best 8 colors for that image, then go ahead and calculate every possible 8 color palette using every 128 color combination (not too processor intensive if you do it once and store it in an array) and then go ahead and compare the 8 colors I want with the best set of 8 colors I have available.

 

But when I looked at the program it occurred to me that you should be able to pick any individual color per line for each of the three frames. This means you could have eight unique colors per line rather than just the 8 for the total image. You'd only need another 384 bytes to store the colors. I think you'd have a massive palette, but of course limited only to the 8 colors. Frankly, I think if you had just two frames you may be able to make a really great image. You'd still have 4 colors per line (frame 1, frame 2 and the background) from a 16,384 color palette (which is a subset of a 2 million color palette, depending on the background). It may even reduce flicker.

 

So here is my problem. I can write the program to convert an image down to three (or two) frames of black and white and select the appropriate Atari colors. What I can't do is modify the greeting cart program to add in a color for each line in the bank file. Any thoughts on how we could get from here to there faster?

 

Nobody seemed to think this was a neat idea, but I am still working on it. I have a good bit of code written to calculate the precise RGB values for each combination of the Atari 2600's 128 color palette (including background.) For those interested, there are over 268 million possible color palettes of 8 colors each if you include the background color. The approach I am taking is that I have stored in an array expal(128,128,128,128,8,3) or expal(Mix Color 1, Mix color 2, Mix Color 3, background, Color #, RGB[1,2,3]) and then I am going to cycle through each palette and take the aggregate RGB vector color distance (I already have a better color distance formula to use, but it will be trivial to change that calculation) for the entire picture versus the bet fit color for each pixel. That means I have to perform 49,152 (48*128* comparisons per each palette across 268 million palettes (128*128*128*128) or a total of 13.2 quadrillion pixel color distance calcs. This seems like an awful lot and I would imagine it would take HOURS to do. Any thoughts on a better algorithm to determine which 2600 8 color palette is the best match for the image?

[the.golden.ax]

I think it's cool, but don't know enough to help. :thumbsup:

 

AX

[Thomas Jentzsch]

Nobody seemed to think this was a neat idea, but I am still working on it.

 

Probably due to the data posted.

 

I have a good bit of code written to calculate the precise RGB values for each combination of the Atari 2600's 128 color palette (including background.) For those interested, there are over 268 million possible color palettes of 8 colors each if you include the background color. The approach I am taking is that I have stored in an array expal(128,128,128,128,8,3) or expal(Mix Color 1, Mix color 2, Mix Color 3, background, Color #, RGB[1,2,3]) and then I am going to cycle through each palette and take the aggregate RGB vector color distance (I already have a better color distance formula to use, but it will be trivial to change that calculation) for the entire picture versus the bet fit color for each pixel. That means I have to perform 49,152 (48*128* comparisons per each palette across 268 million palettes (128*128*128*128) or a total of 13.2 quadrillion pixel color distance calcs. This seems like an awful lot and I would imagine it would take HOURS to do. Any thoughts on a better algorithm to determine which 2600 8 color palette is the best match for the image?

 

 

I suppose that also depends on how you calculate the color distance vector. I suppose there must be some algorithms already existing. Searching the web should help here.

 

 

 

 

 

 

 

 

[chjmartin2]

My converter is finished. It is very derivative of Andrew's Chronocolor greeting cart program, but should make it easier for users to make carts on their own. All you need is a 48x128 bitmap file, no other editing, or splitting into channels is required. Any 48x128 BMP file can be converted. Also, the aspect ratio of the file is 2:1, so if you resize an image to 96x128 and then allow the aspect ratio to change and resize to 48x128, then you'll have the perfect aspect ratio.

 

The first thing the program does, regardless of options chosen, is to downconvert the image into the best 8 colors possible (diversity algorithm) to limit the number of color distance calculations.

 

The program has 4 output options all of which can be set to dither or no dither:

 

A) The basic palette and tries to optimize to Andrew's original colors as best as possible. It also assumes that the output colors are pure RGB in spite of the 2600 not having those colors - it results in pretty good approximations of what you would see from a greeting cart today. It is also a great mode if you want to make a picture using eight colors (black, white, red, blue, green, yellow, magenta, cyan) and have it displayed. This mode is good to use for cartoons.

 

B) Gray scale - it tries to use a good grey only palette and optimizes the image to it.

 

C) Optimized Palette - this option chooses black as the background, white (well, Atari's closest white) as one color and then cycles through all of the other colors calculating color distances to determine the best colors. You may wonder why I choose black and white and only cycle through two other colors - well, every time I cycled through more colors, it always PICKED white as one color and black as the background. Choosing them ahead of time just makes the calculations faster.

 

D) Custom Palette - Hey, maybe you want to make sure that the background is red, or want to experiment, anything goes in this option, you pick the background color and the three mix colors. Dither or not - YOUR CHOICE!

 

Once the program has run, go ahead and run make.bat and you'll have a cart.

 

LIMITATIONS:

 

1. The input file has to be a BITMAP 48x128

2. The input file has to be in the same directory as Chrono2.exe

 

I hope you guys enjoy the program. If you have any ideas on how to make it better then I'm all ears. I have also attached a package of output cart .bin's to show off the various modes for those who just want to see the results. Also, here is a screenshot:

 

 

I have spent a lot of time on this, so would really love it if people can post some of their results! I know that if I could figure out how to store an additional 768 bytes of individual colors per line and how to set it, then we could have images that use 8 different colors per line and therefore a much larger potential set of colors. I don't know if I will work on it. Depends on if anybody likes this tool or not.

 

Thanks,

 

Chris

Chrono2.zip

MarilynPack.zip

[LS_Dracon]

Hey, it's works great!

Thnx for sharing it

 

Creating interlacing images is very time consuming, this program help alot and I like the options to select the best colors.

sms.BIN

Edited January 18, 2011 by LS_Dracon

[chjmartin2]

I was playing with my program and here is another gallery of images...

Gallery.zip

[+Andrew Davie]

I was playing with my program and here is another gallery of images...

 

Enjoying watching your work on this topic. I especially like the concept of a separate palette for each line. BUT... I've had a look at the gallery and I think that there's an important part of the original system that you're overlooking. Basically, I THINK that I can produce an "original" chronocart which will look way better than any of these samples. Could you send me one or two of the images you used, so that I can compare like with like?

 

I'll post my results on this thread.

 

 

Thanks

A

[chjmartin2]

I was playing with my program and here is another gallery of images...

 

Enjoying watching your work on this topic. I especially like the concept of a separate palette for each line. BUT... I've had a look at the gallery and I think that there's an important part of the original system that you're overlooking. Basically, I THINK that I can produce an "original" chronocart which will look way better than any of these samples. Could you send me one or two of the images you used, so that I can compare like with like?

 

I'll post my results on this thread.

 

 

Thanks

A

 

The gallery BMP files are attached. If you use my program and choose the basic palette, it essentially makes an original chronocart - it uses the same RGB values (NTSC) and assumes that the colors made are all the absolute values. 255,255,255 for white, 255, 0,0 for red, 0,255,0 for green, etc. The dithering is different because it is Floyd-Steinberg, but very close. One thing you get with the original chronocart is a very wide range of colors, but all of them are a bit dark. When you mix frames - like Red, Black, Black, you effectively get 1/3 the brightness. On the flip side, when you use the color distance method to pick a palette it always defaults to much higher brightness colors because it is averaging with the dark black background - so you get a more limited variation of colors. In the Marilyn archive, you can look at the non-dithered basic palette example and it looks very good - inspite of having a great color distance than the optimized palette.

 

I agree with you that the original chronocolor images can look very good. The results of the optimizer were not as good as I expected, but the color distances are lower for the resulting image. In the chrono2 archive I have a mario based on your initial image, and the result is a much brighter mario, but it sacrifices color depth. If you experiment with the custom palette option you can get some really interesting effects. So, maybe enhancement isn't the right word, maybe, alternative is better. I'd still like to attack trying to pick a custom palette per line. I can optimize the color selection, but I'm just not skilled enough in ASM (on Atari especially) to figure out where to dump the chromo/luma bytes to load per line instead of the NTSC_RED, etc.

 

Still interested to see what part of the system I am overlooking. I do see now that if I have too much variation between colors that I end up with a very apparent flicker. Another thought is to use two sprite sets and have 4 colors per line, this would allow for a much broader color range in the given 4 colors because you wouldn't be dragging the brightness down so much. Red+Black+Black even at a 255 value for red would be 85,0,0 - which is pretty low. In a two flicker system you'd have 128 which would be twice as bright. (Realizing of course that Atari doesn't have a 255 red option, but you get my point.)

GalleryBmp.zip

[chjmartin2]

Taking on Andrew's challenge that the original chronocolor could create images that are way better than what Chrono2 could do, I decided to revamp my program and add some options. I don't want to release it yet because I have one more mode I want to implement. The new program now will allow you to prioritize palette usage diversity versus absolute color distance. It also allows for an option to cycle through both a black and a white background because I found there were some lower color distances when accounting for diversity with a white background. Here are some gallery examples.

 

cleavage.BIN

fredflint.BIN

homer.BIN

mario.BIN

papa.BIN

smbboss.BIN

sonic.BIN

thongass.BIN

[+Andrew Davie]

Taking on Andrew's challenge that the original chronocolor could create images that are way better than what Chrono2 could do

 

Nice to see you rising to a challenge OK, take the mario.bin as we've both done that one.

Attached is a chronocolour one from wayback.

 

Now look at the colouration subtlety around (say) the chin. The ear. In the new one there is no chin. No neck. Maybe an ear...?

Look at the colouration of the face, detail around the eye. Look at the shading around the shoes. In the original, they look 3D. In the new version they look very flat-shaded. I think the custom palette is a great idea/challenge. I just don't think you're doing the dithering right. I spent a lot of time finding a good method, and I think that's the crucial step that your system is falling down on. Maybe. That's the item I think you were missing, but you say you are dithering. If that's the case, something is going very wrong. In any case, I think of the two marios, the original is way better.

Maybe that's just me Keep up the good work! It's great fun to play and try to get the best images possible.

Cheers

A

mario2.bin

[chjmartin2]

Taking on Andrew's challenge that the original chronocolor could create images that are way better than what Chrono2 could do

 

Nice to see you rising to a challenge OK, take the mario.bin as we've both done that one.

Attached is a chronocolour one from wayback.

 

Now look at the colouration subtlety around (say) the chin. The ear. In the new one there is no chin. No neck. Maybe an ear...?

Look at the colouration of the face, detail around the eye. Look at the shading around the shoes. In the original, they look 3D. In the new version they look very flat-shaded. I think the custom palette is a great idea/challenge. I just don't think you're doing the dithering right. I spent a lot of time finding a good method, and I think that's the crucial step that your system is falling down on. Maybe. That's the item I think you were missing, but you say you are dithering. If that's the case, something is going very wrong. In any case, I think of the two marios, the original is way better.

Maybe that's just me Keep up the good work! It's great fun to play and try to get the best images possible.

Cheers

A

 

Here is your source image mario run through my converter using the basic palette. It is very close to your original. The difference I think would be that I am using Floyd Steinberg and you used Stucki. Anyway, you can see that the dithering is working. Chrono2 tries to account for brightness and absolute color distance. Because you have a very diverse palette with original Chronocolour you get a much more diverse resulting image, but you sacrifice brightness. The second cart is a slightly modified mario, but it still shows some of the effects you are describing with the flatness in the ear and face. It is because there are only so many 8 color palettes available. Right now, I downconvert the image to an optimized 8 color palette and then use that result to compare to all of the available mix palettes, calculate the total color distance (reward diversity if that is turned on) and then redither the original image to the new palette. In the mario example, the lowest color distance that rewards diversity happens to only have one good redish color - hence the flatness. I am working on a new algorithm that dithers every mix palette and then compares to the original image - it may take longer to convert but should result in a better image. One solution to the mario flatness issue would be 8 colors per line instead of an optimized 8 color single palette, which will take me a lot longer. So, in short, original chronocolour probably creates a better image, or more complete image in the mario example, but take a look at the Fred Flintstone - I would bet that it would be very difficult to achieve that level of fidelity with the original color map.

mario.BIN

mario2.bin

[+Andrew Davie]

Here is your source image mario run through my converter using the basic palette. It is very close to your original. The difference I think would be that I am using Floyd Steinberg and you used Stucki.

 

Yes, but to me that is all the difference in the world. It's close, but it looks noisy, with odd colours all throughout the image. I've seen exactly this sort of thing before when I was originally playing with dithering. I think the dithering method used causes effects which are quite noticeably bad. I do want to see your technique work better than Chronocolour... but I don't think it's quite there yet.

 

One thing I do like is your use of different non-black background colours. I assume you're incorporating that into your distance algorithm. It's something I played with but only for fun, not something useful. By the way, Boulder Dash (2600) uses tri-colour line triplets (without rolling) to get multi-colour background graphics. That works pretty well, too. The neat thing about that system is that it doesn't stick with RGB; any three colours are suitable to produce other-colour combinations.

 

Check out the youtube videos atari 2600 boulder dash if you're interested.

 

Cheers

A

[chjmartin2]

Here is your source image mario run through my converter using the basic palette. It is very close to your original. The difference I think would be that I am using Floyd Steinberg and you used Stucki.

 

Yes, but to me that is all the difference in the world. It's close, but it looks noisy, with odd colours all throughout the image. I've seen exactly this sort of thing before when I was originally playing with dithering. I think the dithering method used causes effects which are quite noticeably bad. I do want to see your technique work better than Chronocolour... but I don't think it's quite there yet.

 

One thing I do like is your use of different non-black background colours. I assume you're incorporating that into your distance algorithm. It's something I played with but only for fun, not something useful. By the way, Boulder Dash (2600) uses tri-colour line triplets (without rolling) to get multi-colour background graphics. That works pretty well, too. The neat thing about that system is that it doesn't stick with RGB; any three colours are suitable to produce other-colour combinations.

 

Check out the youtube videos atari 2600 boulder dash if you're interested.

 

Cheers

A

 

I have a Stucki algorithm coded, but the Floyd-Steinberg worked better for optimized images. What is odd is that I have cycled through the background colors for the distance algorithm, and it always picks black or white. I think that is because other background images create palettes that are slight variations of the background. It would probably choose a blue background for an image with only blue shades - I haven't tried that yet. I am still trying to code a brute-force dither that mixes every palette, dithers it and calculates the total color distance - I think then I can beat the mario image. Once I am done with that, then I have to dig hard into trying to get a palette per line - and that has a big learning curve for me. At 8 colors per line from a massive palette - the images should be breathtaking. We'll see... I will check out boulder dash.

[chjmartin2]

Here is the latest version of the converter. It has two new features, first, in the Optimized Palette mode you can now choose to reward diversity, what this does is gives more weight to mix palettes that utilize more colors. So the overall color distance for a given picture may be lower if it uses 6 of the mix colors, but with reward diversity turned on, it finds the lowest color distance that uses the most number of colors in a given palette. Also, the greyscale mode now cycles through all of the possible grey scale palettes. Lastly, there is a brute force mode that goes through EVERY combination of colors AND dithers each mix palette from the original, it is not for the faint of heart though, as it takes HOURS for one image to convert and the result is not much better than the Optimized mode - use it at your own risk.

 

I am going to take a break from this for a bit - as the next step will require a lot of learning on my part. I have to get back to a mattel aquarius program for a bit, but I will be back to this after that.

 

Thanks,

 

IQ1

Chrono2V2.zip

[chjmartin2]

I already finished my Mattel Aquarius stuff... I am looking at this code now and trying to figure out how to load a palette into the program is really heavy stuff for me. I do not know where to start as the only assembler I have done is on the Aquarius and with lots of help. I am not going to beg for programs, but any hints on where to store the color matrix would be helpful. I think I could modify the program to load Red, Green and Blue from an incrementing value. The problem is that I would need a counter, but somehow the sprites are loaded in order, so there has to be some kind of counter or pointer to a memory location to use. You would think I could store the two bytes for each color in a memory location that is an exact amount from the memory location of sprite. This is my thinking - but then in the code it says it has to be 76 cycles, well surely loading the color from somewhere else would mess up THAT timing!

 

Worse off... I need 6 bytes per line... that is only 768 bytes, which I have ... 1768 bytes free still. I could add a matrix to bank.asm that has the colors in it. But I'd still be at a loss to figure out how to load them at the right time. It is just such a large uphill slope... much well beyond my understanding, but I know how cool it is... oh well.. if anyone has any words of encouragement that would be good... ha!

[chjmartin2]

Andrew,

 

Ok... I am coming back to this project now for a bit - I hope.

 

In your Greeting Cart code you do this before you start drawing the interleaved images:

 

.S1         SET SPBASE
.S2         SET SPBASE + 2
.S3         SET SPBASE + 4
.S4         SET SPBASE + 6
.S5         SET SPBASE + 8
.S6         SET SPBASE + 10

 

Could I just add a .S7 SET SPBASE + 12 in order to find a place to store the color byte to load for the line?

 

Then modify each of the line drawings routines, these:

 

.LABG       lda #GREEN          ; 2
           sta COLUP0          ; 3
           sta COLUP1          ; 3

           ldy LoopCount       ; 3

           lda (.S1),y         ; 5
           sta GRP0            ; 3
           lda (.S2),y         ; 5
           sta GRP1            ; 3
           lda (.S3),y         ; 5
           sta GRP0            ; 3

           lda (.S6),y         ; 5
           sta Temp            ; 3
           .byte $b3,.S5       ; 5  --> lax (.S5),y
           lda (.S4),y         ; 5
           ldy Temp            ; 3
           sta GRP1            ; 3
           stx GRP0            ; 3
           sty GRP1            ; 3
           sta GRP0            ; 3
           
           dec LoopCount       ; 5
           bpl .LABB           ; 3
   
           bmi EndDraw

 

Then replace the #GREEN with (.S7)? My question then is, where in the bank00.asm would I put the byte values for the colors I want per each line, wouldn't they just be an added decimal value at the end of each line? Problem with that is that each line in BANK00 goes up from the bottom, and one byte per line would be that I want to change color for each sprite, but you don't draw it that way. You go ACROSS to draw an entire line at once.

 

What I want to do is to store an extra byte per line per frame, not an extra byte per sprite.

 

I am feeling like maybe I should just write some ASM from scratch that doesn't have the extra code for animation and such, and work out how to display the three frames on my own, then maybe I would have a shot. But you've already done the work. If you were me, where would you try to store the extra byte per line?

[+Andrew Davie]

Andrew,

Could I just add a .S7 SET SPBASE + 12 in order to find a place to store the color byte to load for the line?

 

Well, those equates are just for convenience in reading the code. They're two-byte pointers to the location of the sprite data.

So yes, you could add a .S7, and have the two-byte value pointing to the location of the colour data.

 

 

Then replace the #GREEN with (.S7)?

 

 

Well the REAL question is; how are you going to find the cycles to do the colour load?

The (.S7),y load would take 5 cycles. This is adding 3 cycles to each line (as the immediate colour load currently used is 2 cycles long). The cycles-per-line is already at 76 cycles, so you're over-budget. The real problem is... how do you find additional time on each scanline to change to a variable colour?

My initial thoughts are you either use clever bank-switching so you can change the (),y addressing to abs,y (saving 1 cycle each?) OR you use some sort of self-modifying code so that the colour values are pre-written to the code before execution.

Either way, fun and games.

Cheers

A

[chjmartin2]

 

Well the REAL question is; how are you going to find the cycles to do the colour load?

The (.S7),y load would take 5 cycles. This is adding 3 cycles to each line (as the immediate colour load currently used is 2 cycles long). The cycles-per-line is already at 76 cycles, so you're over-budget. The real problem is... how do you find additional time on each scanline to change to a variable colour?

My initial thoughts are you either use clever bank-switching so you can change the (),y addressing to abs,y (saving 1 cycle each?) OR you use some sort of self-modifying code so that the colour values are pre-written to the code before execution.

Either way, fun and games.

Cheers

A

 

I could change over to a 30 Hz Flicker instead of a 15 Hz one and just use two images instead of three. I would be limited to 4 colors per line, but still out of a really huge palette. If I do that then I get back 25 cycles which is more than enough to load the color. I would still have two foregrounds and one background, so you would have 8,256 colors per background color (128+127+126+...) or a total palette of just over 1 million colors, but only 4 colors per line (f1+f2,f1+b,f2+b,b+b). Maybe not as fancy as 8 colors per line, but 4 colors per line is still pretty good.

[chjmartin2]

Also... with that many extra cycles, I may be able to seperate each line into two zones, so switch colors in the middle of the line, so back to 8 colors per line, but only 4 colors in the first 24 pixels and another set of 4 colors in the last 24 pixels!!!

[+Andrew Davie]

I could change over to a 30 Hz Flicker instead of a 15 Hz one and just use two images instead of three. I would be limited to 4 colors per line, but still out of a really huge palette. If I do that then I get back 25 cycles which is more than enough to load the color.

 

Eh? Not so! Each scanline has 76 cycles, full-stop. Currently the scanlines have a single colour load/store, followed by 6 sprite load/stores and finally a branch. These take 76 cycles. Removing a FRAME isn't going to make any difference/saving to the cost of each scanline. Go back to the source code, trace a single scanline. Count the cycles. Now, where are you going to get any cycles back from that scanline? Because you need a cycle or two to have a non-hardwired colour. OR, you need self-modifying code or clever bankswitching. Or some other code rewrite.

 

CHeers

A

[chjmartin2]

I could change over to a 30 Hz Flicker instead of a 15 Hz one and just use two images instead of three. I would be limited to 4 colors per line, but still out of a really huge palette. If I do that then I get back 25 cycles which is more than enough to load the color.

 

Eh? Not so! Each scanline has 76 cycles, full-stop. Currently the scanlines have a single colour load/store, followed by 6 sprite load/stores and finally a branch. These take 76 cycles. Removing a FRAME isn't going to make any difference/saving to the cost of each scanline. Go back to the source code, trace a single scanline. Count the cycles. Now, where are you going to get any cycles back from that scanline? Because you need a cycle or two to have a non-hardwired colour. OR, you need self-modifying code or clever bankswitching. Or some other code rewrite.

 

CHeers

A

 

Ugh... Well... Could go down to 40x128 instead of 48x128... ugh... but that would be really small. I was considering writing code from scratch, because I haven't written a stitch of code for the Atari anyway. Clearly I don't understand it well enough. I'll keep chugging along.

[+SpiceWare]

Have you looked at DPC+? With the FastFetch mode I wrote a kernel that does 29 TIA updates every 2 scanlines.