Jump to content
IGNORED

G2F question about inverse characters


Recommended Posts

I had a small question about G2F in regards to character sets and inverse characters/5th color

 

I've been doing some experiments, attempting to render pictures in my software text modes. So far I have been able to get pictures converted to APAC 0 (Graphics 0.9/0.11 apac mode), Super CIN (Graphics 12/0.11 80 colors), and Super MIN (Graphics 12/0.9 80 monochrome).

 

How I do this is, I use Jeff Potter's APACVIEW to render Graphics 9 and Graphics 11 bitmaps from any GIF, which I can then convert to character sets using a BASIC utility I wrote up.

 

As for the Graphics 12, I use G2F to generate character sets from the gif file. I so far, have only generated fonts using the 3 pf registers (708-710) ... if I saved a font file using "5th color" (711) is there a way to generate an inverse map from G2F that I can read, and use it to map inverse characters when I do my own displays in Super CIN/Super MIN?

Link to comment
Share on other sites

Have you tried to save as "G2F"? You will get a "myname.scr" containing the screen/char map.

 

 

I'll try that ... I can already get the char map pretty much, as for my text mode experiments I am choosing "standard" which just gives straight 3 rows (4 in narrow) of each char set.

 

What I am looking into is, how to read the inverse char map from antic 4 screens, if you save as G2F. Where in the file format is it and how can you read it?

 

The practical use of this is, I am working with a lot of software text modes based out of ANTIC 4 ... one in particular is Super CIN, which is a flip between Graphics 0.11 (GR0 set to GTIA 11) and ANTIC 4. I already have a means of converting any common format pic (JPG, GIF, etc.) to this mode and a few others.

 

How this works is, I can render a GR. 11 bitmap from Jeff Potter's APACview and convert it to GR 0.11 fonts. Which I then combine with the ANTIC 4 fonts in monochrome gotten by taking a greyscale of the same pic and loading it into G2F. Problem is I am stuck with the basic 4 colors in ANTIC 4. I can code an algorithm which will automatically correct the GR 0.11 font for inverse whenever the ANTIC 4 5th color gets used, but it's reading that inverse map from G2F which is the problem. I could do this by hand but I'd rather be able to just extract it from the G2F file.

 

Gonna post an ATR so you can see what I am going for here ...

 

post-23798-129559404627_thumb.png

 

rainbow parrot.atr

 

Attach the atr to D1: and boot without basic, then run RAINBOW.TUR

 

The above pic is in Super CIN, which has a maximum of 80 colors at 160 (or 128 in narrow) resolution. However, with no 5th color you lose out on 16 colors.

 

The R15?.FNT fonts were generated via G2F

The RCOL?.FNT files were generated from a BASIC program I wrote which will take a GR 11 (or any hires bitmap) and convert to fonts.

 

Original pic is here (admittedly the resolution has been squashed):

post-23798-1295594364_thumb.jpg

 

EDIT: Nevermind, I see what you are saying. G2F will automatically save the inversed characters if you choose .scr, right? Should be a simple matter of reading the .scr and making my own map of where the inverse characters are, then correcting the appropriate GR 0.11 font character for inverse (by subtracting 255 from each line of the char).

Edited by Synthpopalooza
Link to comment
Share on other sites

Are you doing this on Atari itself (only) or in some cross dev environment? In the latter case thismight be interesting for you, once I've finished it.

 

Well ... if you mean the code itself it is done entirely in the Atari emulator ... the only off atari program I have used is G2F and I have kinda done the interlacing of the two pictures by hand. The antic 4 part of the display is from G2F while the Graphics 11 part is a font coverted from the G11 bitmap, which I got through Jeff Potter's APACView

 

Your project looks interesting. Here's a request:

 

I want do some pics in these modes: Super IRG, Super IRG 2, and Super 10. These are modes which don't change the Graphics mode every vblank, just the character set and (in the case of Super IRG 2) color registers. The basic gist is, you get 160x192x14 colors in Super IRG, 160x192x23 in Super IRG 2, and 80x192x45 in Super 10.

 

The thing is, I want to be able to generate 2 atari bitmaps from any PC graphics format ... so there would need to be an algorithm that could take any picture, strip that picture down to 2 atari bitmaps with the appropriate component colors (4 in each pic plus a fifth color) ... with the added caveat of course that the inverse mappings on both files would need to match (i.e. register 710 and 711 cannot be in the same character grid on the picture). For Super IRG this totals to 4 colors, while super IRG 2 has 7 extra colors which rely on "fifth color" inverse mapping.

 

As long as I can at least get two component GIF files, I can probably run them through G2F and get font files which I can then use to interlace the pic.

 

So in essence, the end result of this will be a Super IRG, Super IRG 2, or Super 10 picture converted from a JPG or GIF or whatever, with as accurate color info as we can get given the display properties of these two modes.

 

I am also working up the specs on a new Atari file format called .ifp (interlaced font picture) ... basically it contains info such as the graphics mode it's in (any of 19 character flip modes), color register and VBI settings, character sets, and screen/inverse map) ... may actually try generating a file in this new format.

Edited by Synthpopalooza
Link to comment
Share on other sites

>appropriate component colors 4 in each pic plus a fifth color)

So normally this is just flipping two gr. 15 pictures right? The only reason for char mode would be the 5th color.

Can you PM me some sample pictures? From the description I'd say it rather hard to determine two sets of colors which result ing both proper color scheme and low-flickering. Of course you can flip black and white for medium grey, but it would surely look better if you really use medium grey ;-). Or are the luniances predetermined/fixed in this mode? This is an optimization task to determine the proper colors/character boundaries rather than a conversion (actualy this is the case for any kind of true color source picture).

Link to comment
Share on other sites

>appropriate component colors 4 in each pic plus a fifth color)

So normally this is just flipping two gr. 15 pictures right? The only reason for char mode would be the 5th color.

Can you PM me some sample pictures? From the description I'd say it rather hard to determine two sets of colors which result ing both proper color scheme and low-flickering. Of course you can flip black and white for medium grey, but it would surely look better if you really use medium grey ;-). Or are the luniances predetermined/fixed in this mode? This is an optimization task to determine the proper colors/character boundaries rather than a conversion (actualy this is the case for any kind of true color source picture).

 

This is actually a flip of ANTIC 4 with a graphics mode that I call Graphics 0.11 (Graphics 0 with POKE 623, 192). The luminances are controlled from the ANTIC 4 registers (708-710, plus 711 if you use the "fifth color") ... there is a vblank flip on register 712 between 0 and 6, the 6 is what controls the brightness of colors in Graphics 0.11. The result is you can get 80 colors (16x5 lum) in this mode. The character set grid is therefore 4x8 monochrome overlaid onto 2x8 chroma. Each pixel gets a 2 pixel wide color overlay.

 

What happens is, there are two source pictures. For the ANTIC 4 pic, I converted the original GIF into monochrome and then used G2F to render character sets. i have not used the fifth color yet, as I am still working up a means of mapping inverse characters without affecting the Graphics 0.11 picture.

 

 

For the Graphics 0.11 picture, I first render a Graphics 11 bitmap from Jeff Potter's APACVIEW. I then have a BASIC utility which will convert that Graphics 11 bitmap into Graphics 0.11 2x8 character fonts.

 

The screen itself is a combination characterset DLI and VBI. The DLI changes the character set 4 times, every 4 rows, giving you 20 rows of display. The VBI flips the GTIA register, the display list pointer, and COLBK, plus 5 lots of character sets (accessed through 756 and four of the DLI registers). This is a variation on the Super IRG mode in effect.

 

I can do up some other pictures in this mode to show you, just need to convert more pics. I did do this one though, which is a pic of the New Zealand coastline. Original, followed by the Super CIN pic.

 

post-23798-129583233212_thumb.jpg

 

original

 

post-23798-12958323004_thumb.png

 

Super CIN

 

Again, this is without the fifth color. Still working out how to map the inverse chars in this mode.

Link to comment
Share on other sites

I forgot to mention, the mode I want to do these pics in is Super IRG 2 (23 colors, 2 antic 4 screens with flipped color registers). Which means, as you say, its optimization to reduce the image down to 16 colors (plus 7 if you want to use register 711) and then creating 2 pictures from the original image, which have the component colors, then I can put the pictures into G2F and get fonts.

Link to comment
Share on other sites

>What happens is, there are two source pictures. For the ANTIC 4 pic, I converted the original GIF into monochrome and then used G2F to render character sets. i have not used the fifth color yet, as I am still working up a means of mapping inverse characters without affecting the Graphics 0.11 picture.

Ideas:

- You could simply use 2 diffent screen maps and flip the high byte of the LMS instruction of the DL

- You can just flip chactl/$d401/$2f3 to $02 (enable inverse char display) or $00 (disable inverse char display) and stay with 1 screen map

 

General question: Isn't there a lot a of flickering when you interlace/toggle between the GR.11 and the GR.12 screen? Maybe you can provide and executable I can run on my Atari.

 

On the last New Years Disk, Rybags had a picture with GR.11/GR.12 toggled per scanline using the VSCROL trick. Do you know it?

dfgtfgeg3rg.png

The VSCROL trick causes a reload of the screen every 2nd scan line, resulting in the GR.12 chars being only 1 line high - hence there is hardly any restriction regarding the 5th color anymore. The only restriction is that you cannot have color $03 and color $04 in the same "4x1" area. I think this is the best we can get at all, so why use lower resolutions?

If you really still want interlace, you can still flip the charsets for the luma/GR.12 lines.

Link to comment
Share on other sites

That's CIN+ (as I called it).

 

Uses Antic 4 and all the PMGs on the Luma scanlines to allow 6 lumas (with obvious restrictions). So, 96 colours in total in a 160 APAC-alike mode.

 

There's actually no restrictions on the Colour scanlines, it uses Mode F in GTIA Colour mode, so in effect Gr. 11.

 

The problem with using Antic 4 to provide the Colour scanlines is that you can't generate all of the 16 possibilities due to the way the AN0-AN2 data is streamed.

 

To get the "11" bitpairs you must use a character >$80, but then you get the problem of bitpair "10" not being available, and the other way around also.

 

And on the other hand, the problem with my CIN+ mode is that you're only using 2 out of 8 bytes within the character set (top and bottom, bottom byte by enabling upside-down chars in CHACT).

So, it's very memory-hungry and best suited to standalone pics or loading screens (and since it's DLI intensive, can only be a splash screen).

Edited by Rybags
Link to comment
Share on other sites

>What happens is, there are two source pictures. For the ANTIC 4 pic, I converted the original GIF into monochrome and then used G2F to render character sets. i have not used the fifth color yet, as I am still working up a means of mapping inverse characters without affecting the Graphics 0.11 picture.

Ideas:

- You could simply use 2 diffent screen maps and flip the high byte of the LMS instruction of the DL

- You can just flip chactl/$d401/$2f3 to $02 (enable inverse char display) or $00 (disable inverse char display) and stay with 1 screen map

 

General question: Isn't there a lot a of flickering when you interlace/toggle between the GR.11 and the GR.12 screen? Maybe you can provide and executable I can run on my Atari.

 

On the last New Years Disk, Rybags had a picture with GR.11/GR.12 toggled per scanline using the VSCROL trick. Do you know it?

 

Yes ... adding a chact flip would not be a real solution as that would decrease the number of lines displayable on the screen by four. Reason being: You can only flip 8 registers per vblank. So, you are already flipping GTIA, COLBK (for stability), and the display list (which is needed for Super CIN, so that you can get the maximum 80 colors). This leaves only 5 free registers which all get taken up with character set flips, one character set every 4 lines of screen display, for 20 lines. Adding a chact flip would decrease the display to 16 character lines.

 

As for different screen maps ... that might be handy down the road when I can optimize the character sets ... but keep in mind I am also having to change character set DLI's on the screen as well, so that might cause problems. Both screens would likely have to have DLI's in the same place in order to maintain the display. And again, it adds another register flip to the routine and decreses the display to 16 lines. Remembering of course, this is in character map mode, not bitmap.

 

As for flickering: There is a flip of COLBK (712) which helps reduce it, although not eliminate it completely. when the screen is in Graphics 0.11 COLBK is set to a value between 4 and 6 ... while in Graphics 12 (Antic 4) COLBK is set to zero. This maintains a flicker free black background while enabling the colors to blend better.

 

What I will likely end up doing, is probably generating by hand an inverse map for the ANTIC 4 character sets (that is, showing which ATASCII gets inversed), and writing a program to apply this map against the Graphics 0.11 font ... it helps if I can explain how the screen is set up. Here's a screenshot of the same pic, only with the character set pointers all set to 224 (the default atari font):

 

post-23798-12958589113_thumb.png

 

Here are the two composite screens from Antic 4 and Graphics 0.11:

 

post-23798-129585964155_thumb.png post-23798-129585965986_thumb.png

 

 

You will see 5 character sets here. DLIs on CHBAS get set before each character set, and it's these DLI pointers that get flipped every VBI, along with a flip on 756 to take care of the top 4 lines. So in essence, you have 5 double font files which make up the display. Each double font is 2048 bytes and contains two fonts, one for Antic 4 and one for Graphics 0.11.

 

The difference between Graphics 0.11 and Graphics 12 is, inverse will affect 0.11 differently than Antic 4. Because Graphics 0.11 is based off of ANTIC 2, inversing the character will simply reverse the bit order (color 15 becomes color 0, 14 becomes 1, etc.) ... so the solution would be to have a map on each section of character set showing which ones are inversed (ATASCII > 127), find the accompanying character in Graphics 0.11, and editing the font in memory by subtracting 255 from the value for each row of the character (inverting the bit order).

 

Rybags method is completely different from mine, specifically in that he is changing the display on scanlines and using PMG's. There are 96 colors but they are generated differently. And there is no display list change to ANTIC 2, so that means the display is in Graphics 12.11 ... As rybags explained, this reduces the number of chroma you can display(only 14), and the inverse characters reorder the palette in a similar way as Antic 4. You get 9 chromas each in the normal and inverse pallete.

 

There was an attachment at the beginning of the topic, rainbow parrot.atr ... attach that disk, boot without BASIC. The demo program was written in TurboBASIC but has a vblank and a dli routine in it, and it should demonstrate this for you on a real Atari. Keep in mind also, the flicker will be less on an NTSC machine because of faster refresh.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...