Doing pictures using Super IRG 2 and other ICE modes.

[Synthpopalooza]

Brand new experiment!

 

Mode M0 (called MIN 0 in the ICE CIN editor) is a blending of Graphics 0 with Graphics 9. Done properly, this yields 32 shades at roughly 320 pixel resolution.

 

This is not without problems, as you are having to blend the pixels at a 4 to 1 ratio.

 

This is a picture rendered in this mode. The Graphics 0 render was taken into GIMP, and reduced to two-bit (white black) mode, and dithered using Floyd Steinberg. The picture is then blended with a Graphics 9 render.

 

This picture is approximately 32 shades, though the Floyd Steinberg dither on Graphics 0 blurs the picture a bit. When viewed on a TV or RGB monitor, there will be artifacts introduced to the picture through the Graphics 0 render. It looks better when viewed in the emulator or on an S-video system.

 

Other GTIA modes (Graphics 11 and 10) should also look good when blended with Graphics 0 renders done in this manner.

 

bridge - m0.atr

Edited June 30, 2013 by Synthpopalooza

[Synthpopalooza]

A Floyd-Steinberg dithering experiment, only now using the ICE PC0 mode.

 

This mode, which I have shown earlier, is a blending of Graphics 0 and Graphics 10. You get about 18 colors here at 320 pixel resolution, with the necessity of altering the PF1 and PF2 registers every VBLANK to maintain the display, as well as doing HSCROL tricks to make sure the display lines up properly.

 

This is the original picture:

 

 

To render this properly requires two phases. First, for the Graphics 10 render, I had to take the picture into GIMP, and posterize it so that the color variance would show up well in the 9 colors of Graphics 10. For the graphics 0 render, I used GIMP again, and this time I reduced the picture to two colors and use Floyd Steinberg dithering. I also had to invert the picture, a necessary step for G2F to display the render correctly.

 

This is the result. Again, it looks better on a monitor equipped to display 320 pixel graphics without artifacting ... hi-res artifacts will muddy the picture a bit.

 

rainbow glasses - pc0.atr

Edited June 30, 2013 by Synthpopalooza

[Synthpopalooza]

One more PC0 picture.

 

The original:

 

 

PC0 render:

 

rainbow eye - pc0.atr

 

This time, I made a more even balance of the greyscales (there are 4) and the remaining 5 colors for the rainbow texture in the eye. The blend is really much better and shows off more what is possible. This time the Graphics 10 render was done in AIS, while the Graphics 0 render is still in GIMP using Floyd Steinberg

[Synthpopalooza]

One more ...

 

This time, I used C0 mode (or CIN 0 as it is called in the ICE editor) ... this time it is a blending of Graphics 0 with Graphics 11 (16-chroma) mode. One difference here, is that Graphics 11 has only black and 15 other chromas, so unlike PC0, C0 pictures do not lend themselves well to pictures depending on whites and greys.

 

The original:

 

 

C0 render:

 

rainbow roses - c0.atr

 

As before, the Graphics 0 render was done in GIMP using Floyd Steinberg dithering, but this time I put the PF settings to mid grey to better blend with the graphics 11 render.

Edited June 30, 2013 by Synthpopalooza

[Synthpopalooza]

Floyd Stinberg dithering also works well when using the DIN mode ... by blending Graphics 0 hi-resolution with Antic 4 (Graphics 12). This method tends to work best when you have source images that have a very limited number of source colors.

 

As always, the source image should be resized to 320x192 first. Make sure G2F is in normal mode, 2x2 pixels. For the Antic 4 render, you load the image into G2F, tick the Hresize, Sort Colors, and 2x2 dither options. You will also want to play around with the color settings until you get an image that looks nice. Check "Standard" under options, then click the icon on the top right to save .FNT and .SCR maps

 

For the Graphics 0 render, you load the resized image into GIMP, select Image: Mode: Indexed, and choose a binary palette with Floyd Steinberg dithering. Then after the dither, select Colors: Value Invert to render a negative image, this is necessary so that G2F will process the image correctly. In G2F select normal width, 1x1 pixels, and import the picture. Then export .SCR and .FNT files

 

Here are two pictures I did, themed for the 4th of July.

 

us flag - din.atr

 

statue of liberty - din.atr

[Synthpopalooza]

One more patriotic picture, which really demonstrates the ability of the PC0 mode when combined with Floyd Steinberg dithering. This eagle looks nearly photo quality.

 

eagle - pc0.atr

[Synthpopalooza]

My techniques are improving. PCIN and PC0 are, to me, the best two ICE modes for converting most pictures. I've tried some new techniques, with super results.

 

Here's the original picture.

 

 

I load this picture into GIMP, to start with.

 

My first step is of course to posterize this picture down to the Atari 128 colors. What I do is resize the picture to 160x192 (Graphics 12 resolution), then posterize using Floyd-Steinberg dithering. This makes the picture look less washed out. Then reduce the image to 5 colors. This is what you get:

 

 

For the Graphics 10 render, same as above but resizing the picture to 80x192 (Graphics 10 resolution) and reducing the image to 9 colors. The result:

 

 

For Graphics 0, the original picture is converted to 1-bit (2 color) mode using Floyd-Steinberg dithering. The result:

 

 

The image is negatived, because I had to do a value invert. This is necessary because of the funny way Graphics 0 handles the colors.

 

For the PCIN render, both the resultant images are loaded into G2F, resized, then the color palette has to be rearranged in Graphics 10 so that all the PF0-PF3 and BAK colors match the Graphics 12 render.

 

Here are the resultant pictures, plus executables.

 

dolphins-pcin.obx dolphins-pcin.asm

 

dolphins-pc0.obx dolphins-pc0.asm

 

The flicker on these is really not bad at all on NTSC. I'd be interested in seeing what results are gotten on a PAL Atari. The PC0 render will look better on an Atari without artifacting (S-video or other high res connection).

 

I really can't choose which one I like better. The PCIN has better coloring, but the PC0 render looks nice because of the high resolution.

[Synthpopalooza]

Did some hacking around in MADS, with some code that 1NG gave me awhile back, when he was doing an implementation of the ICE CIN mode ...

 

I now have MADS assembly code for generating .XEX from any hi-resolution .IPC (ICE PCIN Graphics 12+10) picture file.

 

It should be easy to modify this code to work with the other ICE picture file formats. the source code reads the font data for both screens, the color register data (9 colors), and also the Antic 4 screen map. Only one screen map is needed, a flip of the CHACT register to kill inverse on the Graphics 10 side completes the display.

 

Source code and .xex are below. Now you can display .IPC pictures in your own programs. Next step is to automate the creation of .IPC files from source G2F font data, screenmaps, and color data. Currently I have to do these by hand. Tedious work.

 

This is a picture from earlier in this thread, converted from Commodore 64

 

pilgrims2.asm

pilgrims2.obx

 

Edited March 1, 2014 by Synthpopalooza

[Synthpopalooza]

OK, here's an interesting demo: 1024 colors per scanline in Graphics 9.

 

How?

 

Well, the Super 9 mode in and of itself blends two Graphics 9 screens while changing the COLBAK register, making for 256 duotone shades. This much we know ...

 

However ... there is a quirk in Graphics 9, so that when you set the GTIA to combine the four PMG missiles into a single player, they all take on the color in PF3 (711). They ALSO blend with the playfield in Graphics 9 ...

 

So, if we also flip PF3 with two different values than what we are using for BAK, we then get two palettes of 256 colors onscreen (512). Cool.

 

But where am I getting 1024? Well, it seems, that if you add the HPOS registers for some of the missiles into the mix, and have them switch position each vblank, it essentially creates two flickering missiles. So when the switch on alternate frames, you are getting one of the colors for COLBAK, blending with PF3 on alternate frames. This gets you two extra 256 color palettes, making for a total of 1024 colors onscreen at once!

 

I have done a palette test demo below. A sample ICE font is printed to the screen. I have set the GTIA register to Graphics 9 with 5th player enabled, and all missiles set to maximum width. The first two missiles are set to flip horizontal positions while the last two remain stationary. You can see the extra colors generated in bands down the screen.

 

Combining this with DLI's to change the horizontal position of missiles down the screen, means that extra colors can be added to Super 9 screens virtually anywhere on the screen, with a limitation of coverage of 8 GTIA pixels per color band per horizontal line.

 

This is of course, full frame flicker, but on a modern LCD screen, I am told, there is no flicker.

 

Screenshot and demo is below. Run the program D:SUPER9.TUR

 

Next step: Try to incorporate this into an actual Super 9 picture. This will be tricky as there are lots of possible color combinations to choose from.

 

super 9 1024 colors demo.atr

[Synthpopalooza]

Did a little more work tonight, and we now have MADS .asm code for taking .IMN (ICE MIN Graphics 12+9) picture files, and converting into .XEX executables. As with the .IPC code a few posts above, it reads the font, screen, and color data from the appropriate places in the file. There is only one screen map, so a setting on CHACT kills inverse when the screen flips to Graphics 9.

 

Here is source code, plus executable and source .IMN file, in a zip file. A study of the ASM code should show how the .IMN file is structured. To compile your own, just replace "whales.imn" with your own .IMN filename.

 

whales3.zip

 

Still to work on, is a TurboBASIC program to automate the conversion process from G2F files into .IPC, .IMN, and the other ICE picture formats currently working. For PCIN files, I have worked out that I will need .FNT files from both Graphics 10 and 12 renders, a .COL file from the Graphics 12 render, a .PMG file from the Graphics 10 render, and the Graphics 12 .SCR screenmap. It seems that the .PMG file stores the first four PMG colors, repeating each one 256 times. Similar with the .COL file for the PF registers. This will prove helpful!

[Synthpopalooza]

Until I can get my IPC maker automated, I will give you my own TurboBASIC tool for making IPC files from G2F files. It is not totally automated, it will require entering in some data by hand.

 

So, basically, here are the steps to convert any picture to .IPC

 

First, find a source file. For IPC you maybe want a picture that uses about 35 to 40 colors. Anime screenshots, and Commodore 64 pictures seem to work well, as do Atari ST or Amiga pictures.

 

Next step, is to load the picture into your favorite picture editor, and scale it to 320x192 pixels, and save as a PNG to avoid color loss.

 

You will need to generate a Graphics 10 and a Graphics 12 render.

 

For Graphics 12, first select 2x1 pixels in G2F, and normal width.

 

Load the picture into G2F. On the box that comes up on the bottom, tick 5th colors, sort colors, and 2x2 dither. You may need to play around with the colors until you get a nice looking render.

 

 

Then do Options: Standard to make this into a standard .SCR render without optimizing. Save the G2F, choose a filename using "12" (I chose PILG12.G2F).

 

Click the "Save All" button to generate PILG12.SCR and PILG12.FNT files, these are what you will need for the TurboBASIC render program.

 

Next step is Graphics 10. There are two ways to do this, you can either load the picture into the GIMP, and use the indexing function to reduce the picture to 9 colors from the Atari palette, or you can load the picture into tebe's Atari Interlace Studio, choose Graphics 10, and play around with the colors until you get something that looks nice, then save a .G10 file. Remember, you want to have the same PF colors for this picture as you have in the Graphics 10 render.

 

 

Fire up another instance of G2F, select 9C, 4x1 pixels, normal width, and load the picture you just created. For this step, it is helpful to have the other G2F with the Graphics 12 render open, for comparison.

 

 

Now, go into Image: Change colors. A dialog box with all the colors in the picture comes up. You want to swap colors, so that COLOR0 to COLOR3 match the same colors in the Graphics 12 register. The same colors (or close) should be used in both renders for the PF registers. It will be helpful to go into the other Graphics 12 G2F render and do Edit: Colors to bring up the palette display so that you can be sure they match up.

 

Next, arrange the BG color through swapping, so that PM0 (background) matches the background color in the Graphics 12 render.

 

Once this is all done, as before, go to Options: Standard to make a standard SCR file. Save the G2F (here I chose PILG10.G2F). Save All, to make PILG10.FNT and PILG10.SCR files

 

You have the files you need, but keep both G2F instances open. Copy these files onto the folder you use for Altirra's H: device

 

Boot with the .ATR attached to this post and LOAD "D:IPCMAKER.TUR".

ipc maker.atr

 

 

 

These are the lines you will need to edit:

1019 OPEN #2,4,0,"H:FILE10.FNT":OPEN #1,4,0,"H:FILE12.FNT" 

... of course replace these with your .FNT files. The first one should be the PILG10.FNT render, the second should be PILG12.FNT

2001 OPEN #1,4,0,"H:FILE12.SCR":BGET #1,DPEEK(88),40*24:CLOSE #1
2002 OPEN #1,4,0,"H:FILE10.SCR":BGET #1,ADR(S$),40*24:CLOSE #1

The screen files go in here. Put the PILG12.SCR filename in line 2001, and the PILG10.SCR filename in line 2002

1200 POKE 1068,CB41:POKE 1069,CB42:POKE 1070,54:POKE 1071,0:POKE 1072,CB51:POKE 1073,CB52
1201 POKE 1074,CB61:POKE 1075,CB62:POKE 1076,CB71:POKE 1077,CB72
1202 POKE 705,160:POKE 706,38:POKE 707,58:POKE 708,62:POKE 709,40:POKE 710,2:POKE 711,14:POKE 704,54

This is where it gets tricky. You are going to need to go back to your G2F Graphics 10 render, do EDIT:Edit Colors, and click into each color bar to get the appropriate value to enter into the lines above.

 

 

 

 

If you are converting this to a NTSC machine, you will need to step your chromas up by one when figuring values (add 16 to your value) unless it is monochrome. This is easily done by clicking into the color below your current one on the G2F "SELECT COL*" dialog.

 

In line 1200, you will be putting the Background color (PM0) into register 1070, and Graphics 10 color #9 (BAK) into register 1071

In line 1202, put in the rest of the colors normally.

5000 OPEN #1,8,0,"H:FILENAME.IPC"

This is of course your output filename. Change this to whatever you want, with an .IPC extender. You can use D: if you want to write this to an .ATR

 

Once this is done, run your program. This will take awhile, so you will want to engage the Warp Speed on your emulator while it runs. It will load all the files, and then do an automatic dithering of the PF0-PF3 and BAK registers where they blend on both renders. It is this process which takes the most time. When it is finished, you will see disk access as the IPC file is being written to your H: device (or your floppy if you so chose). Once this finishes, you can hit F5 (RESET) to exit the program.

 

The dithering routine begins at line 3000. You can place a GOTO 5000 before this if you want to skip this routine.

 

The resulting IPC file can now be viewed in IPC viewer, or using the .asm code a couple of posts above, converted into .XEX:

 

 

I have also done programs for converting G2F's into most of the hi-res ICE formats, tho the steps will vary somewhat depending on which mode you use. These programs are mostly a modification of this one. A future step will be the total automation of this process, where the color data is read automatically from .PMG or .COL files generated in G2F.

Edited July 2, 2014 by Synthpopalooza

[Synthpopalooza]

Today, the same process as above, for MIN mode (.IMN) pictures.

 

These are remarkably easier to deal with than PCIN mode, for two reasons: First, no color registers have to be swapped, and you only have the PF and BAK registers (5 in total) to worry about. Second, is that no fancy tricks have to be done with HSCROL to get the graphics to line up properly, unlike PCIN, which has the Graphics 10 pixel shift quirk.

 

This mode is recommended for monochrome pictures, or for photographic quality pictures which have lots of shading, but only have about 5 chromas in them.

 

For this example, I will be using this picture from earlier in the thread:

 

 

(ignore the text at the bottom, it is in the original picture)

 

So, what is needed, again, is to load the picture in your favorite picture editor, crop out the text at the bottom, resize to 320x192 and export a PNG file.

 

Now, since we are doing MIN, we need a Graphics 12 render and a Graphics 9 render.

 

As before with Graphics 12 PCIN, you can either load the picture into G2F, or into the GIMP and reduce it to 5 greyscale before loading the picture into G2F. You may need to try both methods, but you are looking for a source picture that has good contrast with a minimum of PF2/PF3 conflicts.

 

 

As before, choose 2x1 pixels, and normal width. When you load the picture into G2F, in the dialog box, select greyscale, 5th colors, and 2x2 dithering. As this is a monochrome picture, you will need to play with both the "Sort Colors" setting, and the different color settings, until you come across something which looks decent.

 

One important note: It is CRUCIAL that you have the G2F so that the background color 0 is on BAK. If it is on PF0 or PF1, then you will need to swap the registers. If it is on PF2 or PF3, you cannot use that render, because swapping one of these with the BAk register will make ugly PF2/PF3 artifacts. In this case, you may need to either play with "Sort Colors", or re-render the picture in GIMP using more greyscales until you can get a G2F that allows you to place the background color on "BAK".

 

When you are happy with the result, do "Options: Standard" to turn off optimization, and save the G2F using an appropriate filename (I used "eye12.g2f"). Then, as before, SAVE ALL to write EYE12.SCR and EYE12.FNT. Keep this G2F window open.

 

Now for the Graphics 9 render. This is VERY easy. Select 4x1, normal width, and 16G settings, then load the picture.

 

 

In the dialog box that comes up, simply select "greyscale".

 

Then, Options: Standard, and save the G2F using a filename like EYE9.G2F. Do SAVE ALL to make EYE9.SCR and EYE9.FNT

 

Below is an ATR for IMN Maker. Boot this and RUN D:IMNMAKER.TUR

 

Here are the lines you will need to modify:

1018 OPEN #1,4,0,"H:FILE12.SCR":BGET #1,ADR(S1$),40*24:CLOSE #1
1019 OPEN #1,4,0,"H:FILE9.SCR":BGET #1,ADR(S2$),40*24:CLOSE #1
1020 OPEN #1,4,0,"H:FILE12.FNT":BGET #1,CHBAS,1024
1021 OPEN #2,4,0,"H:FILE9.FNT":BGET #2,CHBAS+1024,1024

Replace with EYE12.SCR, EYE9.SCR, EYE12.FNT, and EYE9.FNT respectively.

 

Next:

1202 POKE 708,10:POKE 709,14:POKE 710,4:POKE 711,8:POKE 712,0

As before, go back to the EYE12 g2f, and do EDIT:EDIT COLORS to bring up the color palette box:

 

 

You will need to go through, and copy the color settings into line 1202 where they go.

 

The next bit is tricky. Like in PCIN, you can dither the colors to reduce flicker, if you are making a monochrome render. How this works is, pairs of pixels in the Graphics 12 render can interchange when they mix with the same shade pixels in Graphics 9. This makes a checkerboard pattern (like in PCIN and Super IRG) that reduces flicker. This method ONLY works for monochrome MIN renders.

 

Here is the line you need to modify:

 

 

There are three variables here. The first one, G12$, contains the atascii representation of the pixel settings for each color. In this case, color patterns 0000 (background), 0101 (pf0), 1010 (pf1), 1111 (pf2 or pf3 when inversed). Leave this alone.

 

The changes we want to make are to the two instances of G10$ in line 4035. The first instance is for when PF2 is in use, and the second (after the IF-THEN statement) for when PF3 (inverse) is active. Like before, this contains the ATASCII representation of the pixel settings in graphics 9 that correspond with the color register in Graphics 12. In this case:

 

* The first character is always zero (heart) because the background in MIN is always of zero luminance.

* The second character is ATASCII 10. This is because the Graphics 12 render uses a luminance of 10 for Color 0 (PF0).

* The third character should be ATASCII 14, because again, in the Graphics 12 G2F, Color 1 (PF1) is 14

* The fourth character is ATASCII 4, as the corresponding value for Color 2 (PF2) is 4.

* The second instance of G10$ for inverse characters (after the IF-THEN statement) is the same as the first, except that you are changing the last character

to ATASCII 8, because PF3 in the Graphics 12 render is a value of 8.

 

If you want to skip this part of the program, put in a GOTO 5000 statement before line 3000. This should be skipped if you are doing a color MIN render.

 

The last line to modify, as before, is line 5000, with the filename you want to save to. Be sure to use a .IMN extender.

 

Make sure all the SCR and FNT files have been copied to your H: device, then run the program. Set your emulator to Warp Speed, as the computing of dither pairs takes awhile. When the disc access lights up again, your IMN file has been written. The FNT and SCR files have all been included on the ATR for you to examine.

eye min picture and code.zip

 

 

It can now be viewed in IMN viewer, or converted to .XEX using the asm code in the previous post. The ZIP file contains EYE.IMN, the XEX file, the ASM source, and also the two source G2F's that were used to make this picture.

 

A color counting algorithm shows that this picture has about 20-21 greyscale. While less than HIP mode pictures, the picture is more sharply defined.

(EDIT: GIMP reckons this picture has 42 greyscale. I don't know how accurate this is, I can count about 20 in this picture)

 

Again, a future verson of this program will automate this process. The only other external file needed will be a .COL file for the graphics 12 render, which has the color data for the 5 color registers.

 

For future posts, I will show the process for .ICN (CIN mode 70 colors), .IRG (Super IRG 15 colors) and .IR2 (Super IRG+ 25 colors).

Edited July 3, 2014 by Synthpopalooza

[Synthpopalooza]

A few more MIN pictures, made using the method above, along with source G2F's, XEX and ASM.

 

rocks and stream.zip

 

57 chevy.zip

 

mount rushmore.zip

 

The Mount Rushmore picture is not monochrome, and uses no dithering.

 

The dithering effect is really shown well on the 57 chevy picture. The dithering occurs in the clouds and on the door of the chevy car, which helps reduce the flicker considerably.

 

There are some artifact squares in the renders, which arise from PF2/PF3 conflicts. One can be seen in the clouds of the 57 chevy render, and some are visible in the stream picture, in the bottom center, middle of the stream.

 

It also seems I left IMN maker off the last post (oops). Here it is: imn maker.atr

 

 

Edited July 3, 2014 by Synthpopalooza

[Synthpopalooza]

Now, for CIN mode pictures.

 

The ICE CIN mode allows for 80 colors (16 chroma x 5 luma). It is excellent for pictures that require a lot of chromas, but it has the disadvantage of more flicker, plus it is difficult to get greys and whites in this mode, though not impossible.

 

 

To start, pick a picture (like this one) and resize it to 320x192 pixels

 

 

Next, load the picture into G2F. As before, you want 2x1 pixels and normal width. On the popup dialog, you will tick 5th Colors, HRESIZE, 2x2 dither, and Greyscale. You will need to play around with the color selection and color sorting, until you get a nice monochrome picture with black as the background. Like with MIN, it is crucial that you have black as your background. You may need to reorder your colors as before using Image:Change colors.

 

Again, choose Options:standard, save a G2F (I used rbow12.g2f) then save all to do fnt and scr files.

 

 

For Graphics 11, you must first generate a Graphics 11 bitmap. I use AIS, load the picture, use .CIN setting, then export a .g11 file. You will then need to go into windows explorer and rename your .g11 file as .dat, as this is the only way G2F can load a Graphics 11 bitmap

 

In G2F, select 16C, 4x1 pixels, normal width and load the .dat file.

 

From here, Options:Standard, save the G2F (I used rbow11.g2f) and SAVE ALL to do fnt and scr files

 

Copy your FNT and SCR files to the H: device, then LOAD D:ICNMAKER.TUR from this atr:

icn maker.atr

 

As before, lines 1018-1021 will be replaced with your font and scr filenames.

 

Line 5000 will be the .ICN that you will save.

 

In line 1202. you will as before, go back to the Graphics 11 G2F, do EDIT:Edit colors, and copy over the values for PF0 to PF3

 

There is one problem: When doing whites, the .g11 render puts in a magenta to substitute for the white. This makes the white have a purplish tinge to it in the final .ICN render. To fix this, you want to find the register that has 14 (in this case PF1, 709) and put a bright green in its place (206). When blending colors opposite the color wheel like magenta-green, you get greys and whites. You may need to do this for the other color registers to ensure you get all your whites and greys.

 

Finally, run the program. The result is a .ICN file which can then be converted to .XEX or viewed in ICN viewer.

 

rainbow2 source files.zip

 

The above zip file contains the .ICN, .XEX, .ASM source, and .G2F source files.

Edited July 4, 2014 by Synthpopalooza

[Synthpopalooza]

Now, to do pictures in ICE PCIN+ mode. For the example, we will use the famous box art from the Atari game Star Raiders:

 

This mode is a variant on PCIN, but with one crucial difference: The playfield registers PF0 through PF3 (708 through 711) are altered every VBLANK along with the fonts and display list. The purpose is to increase color resolution from PCIN, you get 45 possible colors here. The tradeoff is that the picture may flicker more, because you can't dither colors anymore where the PF registers pair up. This is also a mode which is at present unsupported in the ICE font editors, though this will change in the future.

 

The first step is of course to take the source picture into your favorite editor, and resize the picture down to 320x192.

 

The best way to do these pictures is to make a Graphics 10 g2f (just like you do with PCIN mode) and a monochrome Graphics 12 g2f (like you do in CIN mode) from the source picture. As with CIN, you want your Graphics 12 register set so that the background color on both pictures is identical. This keeps you from having a flickering background or border.

 

In the Graphics 10 render, it is not required here to make sure that the PF registers match up, as they change. You basically want the Gr. 10 render to be the color overlay while the Graphics 12 one is the monochrome, and provides the high resolution.

As with the others, you will save each G2F by doing options:standard, then save the G2F. For the two files, I used STRAID10.G2F and STRAID12.G2F. Then you SAVE ALL as before to make .scr and .fnt files, and put these on H: device

This is the .ATR for IP2 Maker. Boot and LOAD D:IP2MAKER.TUR

 

ip2 maker.atr

These are the lines which you change:

1019 OPEN #2,4,0,"H:STRAID10.FNT":OPEN #1,4,0,"H:STRAID12.FNT"

2001 OPEN #1,4,0,"H:STRAID12.SCR":BGET #1,ADR(SCR$),40*24:CLOSE #1
2002 OPEN #1,4,0,"H:STRAID10.SCR":BGET #1,DPEEK(88),40*24:CLOSE #1

In these lines, you of course will use the appropriate filenames for the .FNT and .SCR files you made

1200 POKE 1068,CB41:POKE 1069,CB42:POKE 1070,0:POKE 1071,52:POKE 1072,CB51:POKE 1073,CB52

The locations of interest in this line are 1070 and 1071. 1070 represents the BAK register for the Graphics 12 render, and it should be set to the picture's background color (which is zero). 1071 represents the Graphics 10 9th color, and should be set as above, to the BAK register color from the Graphics 10 render (here, 52).

1202 POKE 705,82:POKE 706,112:POKE 707,148:POKE 1079,2:POKE 1081,6:POKE 1083,10:POKE 1085,38
1203 POKE 704,0:POKE 1078,2:POKE 1080,14:POKE 1082,6:POKE 1084,8

In line 1202, of course, set the PM registers to the appropriate corresponding colors from the Graphics 10 G2F render as before.

 

The other registers of interest are 1078 through 1085. These represent the instances of PF0-PF3 (708 to 711) that are flipped in this mode. To clarify, the even numbered registers will reference the Graphics 12 render, the odd numbered registers will reference the Graphics 10 render.

 

So, firstly, you will want to put the monochrome settings from the Graphics 12 render, in order 708 to 711, into registers 1078, 1080, 1082, and 1084.

Then, put the corresponding color settings from the Graphics 10 render, in order 708 to 711, into registers 1079, 1081, 1083, and 1085.

5000 OPEN #1,8,0,"H:SRAIDERS.IP2"

This is of course the output .IP2 file you wish to save.

 

Once this is done, run the program. You now have an .IP2 file that can then be converted using the assembly code in the zip file below.

 

star raiders xex and source files.zip

 

It's a bit trickier to render these pictures in PCIN+ than in PCIN, and they will flicker a bit more, but will give you more colors to work with.

[Synthpopalooza]

A new experiment ... I have a new technique for doing pictures using the Super 10+ mode. This is probably the most complex of the ICE modes, in that 7 of the 9 Graphics 10 color registers (705 through 711) are altered each VBLANK, to increase the color resolution of the mode to 80 colors using 80x192 resolution. A similar technique is apparently being used in the upcoming RPC games release Centron 3D, albeit using a monochrome plus color Graphics 10 screen to get 72 colors at 80x48 resolution. Or so the theory goes.

 

As an example, here is a source picture for conversion:

 

 

This is a good candidate for conversion, as it has a reasonable number of colors, and the colors are very near to each other on the color wheel.

 

This is a very tricky mode to convert pictures for, because of the sheer number of color combinations possible. Sometimes, though, it is possible to narrow these down by hand. What I did here, was run ICE GTIA editor in Altirra, and design my own color palette. Here is a screenshot of the palette I used for this picture (from ICE editor):

 

 

What I did was to use the source colors of red, green, blue, and yellow. For each of the registers, I alternated the colors as follows:

 

VBLANK 1 registers (705 through 710): Reds and Blues

VBLANK 2 registers (705 through 710): Greens and Yellows

 

In both cases, I stepped up the luminance slightly as I went along.

 

For the last two flickering color registers (711a and 711b), I chose to reuse green and blue at their highest luminance setting, but this time I put blue on the VBLANK 2 instance, and green on the VBLANK 1. By alternating, I am able to gain a few extra chroma settings and widen out the color palette

 

In Super 10+, it is sometimes good practice to leave the last register 712 as a solid non-flicker color. This is sometimes useful if you wish to have PMG's on top of the screen for instance, and you want to softcode 712 as your background. Here, however, I made 712 solid white to use as the color of the moon in this picture.

 

I then took a screenshot of the resultant palette in Altirra (making sure Frame Blending is on) and saved it.

 

 

Next, load the screenshot in your favorite editors, and crop the screenshot until all you have is the 80 color palette as shown below:

 

 

Save this, then load GIMP.

 

In Gimp, you will load the color palette image, then go to Windows: Dockable Dialogs: Palettes, and you will then get a palette box as shown:

 

 

Right click in the palette box and choose Import Palette. This dialog comes up:

 

 

You will select "Image" which should show the image you have loaded. You will see the 80 color palette shown on the right. Choose a name for the palette, like Super 10+ 80 colors. Then click OK. The palette you created from ICE editor is now loaded into GIMP.

 

Next, load your picture into GIMP, and do Image: Mode: Indexed. Convert the picture to the 80 color ICE palette you saved. This is the result:

 

 

Export this as a PNG (I called it stream 80c.png).

 

Next step involves .AIS, and you will need to do this step twice. First, load the 80C render you just saved from GIMP. You will get this dialog:

 

 

For this, I chose to use the greens and yellows in this render. I also put in a black for the picture. AIS here insisted on putting a purple as the 704 color, so I had to live with it. The next step is to save a .g10 file

 

I then closed, reloaded AIS, then did a .g10 file using reds and blues:

 

 

I saved a second .g10 file. I then loaded each .g10 file in turn, into G2F, adjusting the color palette so that, in both renders, 704 (PM0) is black and 721 (BAK) is white. Then do Options: Standard, save each g2f, and SAVE ALL to get screen and fnt files.

 

The ATR below shows the result. I had to do some final tweaks to the colors to get them exactly right, but the results I think are very good.

 

stream super 10+.atr

 

What would be ideal, is a means to take any picture, and automatically reduce it to the most optimal ICE 80-color palette. This would possibly lead to a picture closer to the original render.

 

A future possibility is to also convert these font files to .ICE files to load into ICE editor, where further edits could be made to smooth out the colors and get the picture even closer to the original render.

 

This method could possibly work for the Super 10 and Super 9 modes as well. Super 10 would be the simplest as you only have 45 colors and 1 component 9 color palette to worry with.

 

Next step for these modes, is to make viewer programs aid picture file formats for the Super 10, 10+, 9, APAC, and HIP GTIA modes, followed by asm code to convert these to .xex ... A future possibility is to also convert these font files to .ICE Super 10+ files to load into ICE GTIA editor, where further edits could be made to smooth out the colors and get the picture even closer to the original render.

Edited July 9, 2014 by Synthpopalooza

[Synthpopalooza]

An addendum: here is the ideal picture conversion of the previous example for Super 10+, made using the 80 color ICE font pallete. I did this up in GIMP, by resizing the picture to 80x192 and reducing it to the 80 colors in the Super 10+ palette:

 

 

Currently no means yet exist to exactly translate this to Super 10+, but with accurate color translation, this is how the ideal conversion would look on a real Atari in Super 10+. Of course, there is always loading up ICE editor and designing the screen by hand using the color settings I documented above. Tedious work ... or maybe someone needs to make an interlace version of G2F that works with ICE modes. Or alternatively, this mode would be an excellent candidate for addition to Tebe's Atari Interlace Studio perhaps.

Edited July 9, 2014 by Synthpopalooza

[Synthpopalooza]

A bit of further work towards a better method of rendering Super 10+ pictures ... it may be possible to take the picture above (which has already been reduced to the 80 ICE Super 10+ colors), render it as a windows .BMP, at 80x192, and use that information to convert to a Super 10+ natively on the Atari. The color palette is stored already in a 256 color (16 bit) palette in this format, and the bitmap data should translate to the 8-bit format easily, as I believe the pixels are in 16 bit format.

 

Firstly, I am going to attempt to convert the picture above by hand, piel by pixel, using ICE GTIA editor. It will require looking up each of the 80 colors in a table, editing each characterpixel by pixel, and editing a total of 8 ICE fonts. Not an easy task by any means, but I have made up a lookup chart of the 80 color ICE palette used in the above GIMP render which should help:

 

 

The grid numbers represent the Graphics 10 color number, where color 0 is 704 (background) and color 8 is 712 (9th color). 7 of the registers will change each VBLANK instance, but 712 and 704 remain constant. In this instance, the background is black, and color 9-9 (solid white) is a non-flicker color. This is of course just one possible palette for Super 10+. Due to the VBLANK changes on 7 color registers, you actually have an extended blended palette of about 8,300 colors possible to choose from in Super 10+ to fill in your 80 color palette. A lot of subtle color gradients can be made.

 

As you can see above, a great color range can be had in the example palette, so I converted a couple of more pictures in GIMP to 80x192, using the same 80 color ICE Super 10+ palette:

 

 

 

This is how the pictures should appear on a real Atari, if the conversion is done accurately. A further study of the Windows BMP format may yield further clues.

Edited July 10, 2014 by Synthpopalooza

[Synthpopalooza]

The other project I am working on, is a means of natively converting Commodore 64 bitmaps to PCIN mode. Previously I had worked up a PCIN palette chart for displaying the C=64 palette:

 

 

 

Due to the fact that the GTIA mode 10 overlays mode 12 in the PCIN mode two pixels at a time, the Commodore 64 bitmap similarly has to be converted two pixels at a time. The method proposed, is to make a conversion lookup chart for all 256 possible pixel pairs, and replace them with the appropriate Graphics 10 pixels and Graphics 12 pixel pairs, as shown below:

 

 

For each color index, the top rectangle is the Graphics 10 GTIA pixel, while the bottom two boxes are the corresponding left and right Graphics 12 character pixels that are underlaid. For this table, PF0 is red, PF1 is yellow, and PF2 is grey. The 9 color groups in PCIN are on the right side of the chart.

 

This chart assumes we are only using normal non-inverse ATASCII<128 characters. If we throw Inverse into the mix, that opens up the teal color (PF3) in graphics 12, which may be able to get some color combinations closer to C=64. This means an averaging algorithm will be needed where there are PF2-PF3 conflicts, to determine if that character should be inversed.

 

The conversion should be straightforward, because like the character-based PCIN mode bitmaps, C=64 bitmaps are also organized one 4x8 character cell at a time, instead of in rows like normal Atari bitmaps.

[Synthpopalooza]

Some further mockups using GIMP and the Super 10+ palette. Again, if done correctly, these are how the pictures will look on a real Atari, albeit with some flicker.

 

 

I've also done a table of hex RGB values from this palette, sorted by their position in the ICE palette. It may be possible to read these from the PC bitmap and reorganize them for the ICE render, and generate two Graphics 10 bitmaps for rendering as a ICE Super 10 picture. Next task.

[Synthpopalooza]

I've had some moderate success with the C64 koala converter.

 

I've attached an .atr here:

 

c64 viewer.atr

 

RUN "D:C64VIEW.TUR"

 

When you run it on the emulator, it is advised to turn on Warp Speed as this will take a LONG while.

 

How this works: The program reads the c64 colormaps, then the bitmap one pixel at a time, and chooses the appropriate matching colors from the lookup table I posted a couple of posts up:

 

 

The colors on the left column represent the left pixel of a two pixel combination, and the colors on the top row are the right pixel. In each square is the corresponding graphics 10 color, and two graphics 12 pixels, these are also both represented in binary.

 

The conversion, for some reason, shifts the bitmap down a scanline on every character line. I have not yet been able to fix this.

 

It should, however, work with any .koa file from your Commodore 64. There is also a tool called ConGo which can generate .koa files for you to test out.

http://www.editorix.org/congo/congo5full.exe

 

To substitute your own .koa, change lines 11010 and 11060 in the program.

 

Here is a sample picture I converted:

 

C64 original

 

PCIN conversion

 

Some caveats: No inverse characters are used here. With the usage of inverse characters, this opens up PF3 (teal) for blending, which may be able to get some colors closer to the c64 original. An extra lookup table will be needed for inverse combinations.

 

Still needs a lot more work.

Edited July 16, 2014 by Synthpopalooza

[Synthpopalooza]

SUCCESS.

 

Seems I've solved the problem I was having with C64VIEW.TUR ... the .koa format has two extra bytes at the beginning, I am assuming these are the bg color and the border color.

 

Improvements:

 

* Picture is now correct, no striping

* Picture will now self-dither for anti-flicker in areas where the PF and BAK colors mix together.

* Picture is automatically converted to .IPC, for view in IPC viewer or conversion to .XEX

 

Here's the new .ATR... LOAD "D:C64VIEW.TUR"

c64 viewer.atr

 

Lines you need to alter:

11010 and 11060 should have the filename of the .koa you want to load and convert. For best results, put the files in your H: device

5000 should have the output .IPC filename

 

Then, run the program, turn on Warp Speed and Frame Blending in your emulator.

 

The conversion is straightforward because the native C64 multicolor mode, like the PCIN mode here, reads the bitmap data in character cells, one 4x8 character cell at a time.

 

Still to do: Support for PF3 (teal) inverse characters, these will improve the color quality of the conversion.

 

As no inverse characters are used, it is even possible to do these pictures in bitmap format with some reshuffling ... i.e. alternate between Antic F and E, and switch the GTIA every scanline between 0 (Graphics 15 no GTIA settings) and 128 (Graphics 10), as in the bitmap CIN mode. You would need to shift the bitmap data for Graphics 15 to the right one color clock to correct for the Graphics 10 pixel shift. Also the bitmap data will need to be linear, not character-wise as in the ICE PCIN font based mode I used here.

 

Here are some sample conversions, in .xex format:

 

ab.obx

 

astrnaut.obx

 

houkag64.obx

 

hourglas.obx

 

oldwest.obx

 

planet.obx

Edited July 17, 2014 by Synthpopalooza

[Synthpopalooza]

And for your pleasure, some more C64 conversions. I think my conversion table needs some work, it seems flesh tones (bright orange particularly) are not converting very well. Also, these may be issues which will improve when I add in the inverse (PF3) lookup table.

 

Listed below is the original C64, followed by the PCIN conversion, and the .xex

 

dropzone.obx

 

dworld.obx

 

dredd64.obx

 

ikp.obx

 

quinch.obx

 

nato.obx

 

mega.obx

 

leviatha.obx

 

savage.obx

 

fortune.obx

 

trantor.obx

 

 

 

[Synthpopalooza]

Slight tweak made to the viewer. I increased the luminance of the PF1 color group (grey) to 10, and the luminance of the PM2 color group (purple-magenta) up 2 steps. This seems to have fixed the flesh tone issues.

 

There are still some problem pictures, such as this one:

 

animal.obx

 

As you can see, there are a lot of black holes in the picture, some of the color pairs seem to have not converted out properly. This bears a lot of scrutiny, but it seems to happen only in very complex pictures like this one.

 

There is also this render:

 

elefli.obx

 

The green came out too dull in this render. Again, this is a problem which can be fixed with the addition of PF3 blending (teal + green).

 

There is also this render of the Robocop title screen:

 

robocop.obx

 

In this case, the text on the left with the copyright info is illegible. This might require taking the picture into IPC viewer, exporting ICE files, and editing each font set in ICE CIN font editor to make the text readable.

 

Lastly, there is this conversion of the Prince of Persia title screen:

 

persia.obx

 

It seems that the gradation of the sky from purple to orange didn't quite come off like I thought it would. This may require more tinkering with the color conversion table.

 

Here is the updated C64 viewer with color corrections: c64 viewer.atr

 

And also some more conversions. The quality is improving.

 

chinese.obx

 

commando.obx

 

concubis.obx

 

creators.obx

 

ninja1.obx

 

 

 

 

 

 

[Synthpopalooza]

Seems I figured out the problems with those pictures which had black holes in them: The problem is, those were FLI's, not normal C64 multicolor mode.

 

Ok, C64 newbie that I am, what in the heck is an .FLI? Answer below ...

 

Normally in Commodore 64 low res multicolor you are limited to 4 colors per character cell. FLI is an extended format which allows for all 16 C64 colors in the same char cell. When I tried to convert to koalapad, the ConGo converter put black holes into the picture where there were color conflicts.

 

So what will be needed is a native converter from .FLI to the ICE PCIN mode, my next task on this project.

 

Meanwhile, I was able to do a slightly better version of the animal realm picture. There are still some black holes in the picture though, but it looks better. Hopefully a native conversion from .FLI will eliminate this problem.

 

animal2.asm