Needing info on c=64 graphics formats.

[Synthpopalooza]

I was wondering if anybody could direct me to information about the file structure and format of C=64 low res bitmap graphics files. The idea is, I was looking to create a program that would load c=64 low res bitmaps, and display them in the PCIN (12+10 35 color) mode used in my .IPC viewer.

[Heaven/TQA]

codebase64.org for general information... and ask TMR as he has already written c64 gfx converters

[José Pereira]

C64 bitmap multicolour mode it's simple to understand but not simple to translate to A8.

Normally used on the game 160x loading screens but also on some games almost all static screens like Last Ninja, Stormlord, Cybernoid,...

It works exactly like our VBXE where you have [00] on all screen and then 3 different colours on each cell for the other bit-pairs.

C64 even in bitmap mode always think like in char-mode: that 1common + 3 own colours per each char/cell normal size 1Byte x 8scanlines (only the diference is that in bitmap mode, of course, you don't have charsets maximum n# of chars limit).

On bitmap you cannot mix 160x with 320x resolution like they could done if using their more common in-game playing char-mode Colour-Map (only if they add hi-resolution hardware sprites).

Edited January 3, 2013 by José Pereira

[Synthpopalooza]

I think low res multicolor c=64 should translate well to PCIN ... you get 35 colors at the same resolution, it'd be a manner of finding the right mix of colors to achieve a close match to the C=64 palette.

 

In PCIN mode you get 9 color groups of 4 colors each ... with a fifth replacing the fourth when using inverse chars, and antiflicker dithering possible if you use the PF0-PF3 and BAK color groups. So the limitations would be, every two pixels in the display has to be the same color group, and you can't have PF3 and PF2 in the same 4x8 char cell on the Antic 4 side of the display. Otherwise, any of the 35 colors can be put in a character cell.

 

The post below has a sample render of a C=64 picture I did in this mode, using G2F renders in Graphics 10 and Antic 4. I'm sure there is a better algorithm though, to convert to the C=64 palette.

 

http://www.atariage.com/forums/topic/188370-doing-pictures-using-super-irg-2-and-other-ice-modes/page__st__75#entry2539022

[Synthpopalooza]

I think I have a basic set of colors that can be used for C-64 conversions. The following are two ICE editor screenshots:

 

 

Example C-64 color palette

 

 

Entire 35-color PCIN palette.

 

These colors are from the NTSC palette, the PAL palette will require a chroma adjustment of -1 on each color register (not counting the two greyscale registers).

 

The top screenshot shows 16 selected colors from the palette of 35 that closely match c-64 (look in the font display, top two rows) ... the bottom shows the entire 35 palette from the color tuner screen ... top pallet shows 30 colors, while inverse on the bottom provides an extra 5. Many of these colors also closely match the c=64 palette, and may be used as alternates.

 

The idea for the c-64 conversion algorithm is, read two pixels from the c-64 bitmap, and find the color group in PCIN which closely matches these two pixel colors. Preference given to solid and dithered PF colors where possible, followed by other colors which don't flicker too much. Keeping in mind you can use inverse colors too as necessary.

 

Attached is ICE editor ATR, load the "D:C64PCIN.ICE" font file to see the example colors shown above.

 

icecin64.atr

Edited January 4, 2013 by Synthpopalooza

[Synthpopalooza]

Ok ... so bitmap data in C=64 is read like charset data ... first 8 bytes are for the 4x8 spot in the top left, and so on ...

 

This actually translates well into PCIN mode, because the 8 double charsets are laid out the same way.

 

The big question is, how does the color data work? That is, what determines the four c-64 colors that inhabit each char cell?

[sack-c0s]

on the C64 you have a chunk of colour nybbles at $d800 - normally this will determine the colour of the characters in character mode, and another block of character memory, which can be relocated within certain constraints. In multicolour bitmap mode the colour can either come from the background colour, colour ram or the character memory.

 

00 - background colour ($d021)

01 - High nybble of character memory

10 - low nybble of character memory

11 - colour memory at $d800

 

I might have the character memory nybbles the wrong way around though, so TMR will be along shortly to pull me up on that one if that's the case

 

How that's stored in a file depends on how the coder felt at the time- it's pretty much going to be some sequential combination of those in a format that can just be dumped into the right bits of memory. A quick google shows for koala format it's:

 

(relative to beginning of file)

 

Bitmap: $0000-$1F3F

Videoram: $1F40-$2327

colourram: $2328-$270F

Background: $2710

 

http://www.editorix....ts__part_i.html seems to have a list of various file layouts

Edited January 4, 2013 by sack-c0s

[TMR]

I might have the character memory nybbles the wrong way around though, so TMR will be along shortly to pull me up on that one if that's the case

 

Don't look at me, i sent a PM to him and got 'em backwards! Not enough caffeine this morning it seems... =-)

[Synthpopalooza]

I think I have gotten what I needed. Now to program the thing ... thanks everyone.