Bitmap Image Converter

[Tursi]

I thought I'd dip into the ColecoVision side here to pimp my bitmap graphics converter, Convert9918, in case anyone wasn't aware of it. To make it legit, the converter can now output sample Coleco ROM images.

 

You can find the software here: http://www.harmlesslion.com/cgi-bin/onesoft.cgi?102

 

It's designed to be quick and easy to convert most common image formats into the TMS9918A bitmap mode. It also supports multicolor (64x48), and a couple of flicker modes (which I called dual-multicolor and half-multicolor). The most recent update has experimental support for palettes on the F18A, but that's not proven to work yet. It also supports a simple RLE compression of the data.

 

 

I also have a thread discussing the Half-Multicolor mode with a video here: http://www.atariage.com/forums/topic/193307-half-multicolor/page__p__2453262__hl__+convert9918#entry2453262

[youki]

Very nice. It is pity that you can not generate coleco cart for Half-Multicolor mode.

 

And it would be nice if you could generate data for the 105 color mode.(flicker)

[Tursi]

I can, eventually, but it just takes a long time to test all the various formats. It seems to me that dumping a binary that displays a single image is just not as useful as getting the image data out for people to use it. Eventually, I'll have more sample programs for that instant gratification.

 

Half-multicolor /is/ a flicker mode. I don't know anything about the 105 color flicker mode, maybe it's the same thing if that's the MSX thing (though I don't limit to 105 combinations, you can set the flicker maximum difference percentage on the configuration dialog to whatever you can tolerate ).

 

 

[youki]

If you are interrested inthe 105 color mode. There is a nice description here :

 

http://vik.cc/dvik-joyrex/download/105Colors.ppt

 

and you can find a BMPTO105 tool here

 

http://vik.cc/dvik-joyrex/tools.html

 

What is like in your tool , is that you can see a preview result of the image generated in these "flicker" modes.

 

Of course it is more important to have the data than the rom cart. But in the way i work i do tons of graphic tests and rework permantly my image before having the definitve result that i like . Having the rom to test directly on the real console without having to recompile each is very usefull for me!.

[Tursi]

Makes sense enough!

 

The 105 image mode, I get it. Seems about half that Powerpoint is dedicated to the color matching algorithm, but through a few other web searches I put two and two together. A problem with this mode is that is can not provide a full-screen display, because it does the flicker by swapping the bitmap characters onscreen (so at best, you can get 50% screen coverage unless you can work out some shared tiles). A nice advantage of this mode is that it improves the color limitation some too, with the potential for up to 4 mixed colors in an 8x1 block.

 

I'm not entirely sure about supporting this. I can see some advantage for games and the like that may want only half a screen anyway, I guess, but it means adding configuration for how much screen to convert, orientation, not to mention trying to get clever and seeing if we can expand the screen real estate with shared patterns A lot of the tool is hard-coded to the screen size, but I guess that can be dealt with. I'll keep it in mind, anyway, the higher resolution is nice!

 

My tool's flicker mode ('half multicolor') flickers bitmap against multicolor (which was also a trick used in an MSX demo after the first 105 color one). This gives you the advantage of improved color with a full screen. The color limitation description is a lot more complicated, though... you have the 8x1 2-color limitation of bitmap mixed with a 4x4 pixel single color block of multicolor. It's a good thing the tool does the work because every time I sat down to to work out the math of what that means I got lost.

 

I'll also keep in mind the value of more Coleco sample images.

 

[Tursi]

Just a quick update, fixed a couple of bugs, verified the F18 modes work, added more sample code (TI only for now), revised the GUI to make experimentation more convenient: http://harmlesslion.com/software/convert9918

 

[Tursi]

Just a quick note for those who don't follow in the TI forum that I've updated my image converter (numerous times by this point) - the newest version has some fixes for Windows scaling (it was looking awful on my new monitor) and also a number of enhancements and options for better ordered dithers. http://harmlesslion.com/software/convert9918

[mr_gw454]

On 7/16/2012 at 12:57 AM, Tursi said:

Just a quick update, fixed a couple of bugs, verified the F18 modes work, added more sample code (TI only for now), revised the GUI to make experimentation more convenient: http://harmlesslion.com/software/convert9918

 

Hi Tursi - I know this is an older post, but recently started using your utility for the TI-99/4a and now trying it out for the Coleco Adam.  I have an F18A in both systems, so I'm interested in using those conversion modes.

The slideshow program you made for the TI is great!  Do you know if there is such a thing for the Adam?  I am not sure how to display the .HGRH image format on the Adam.

Thanks for any help you can provide!

[Tursi]

14 hours ago, mr_gw454 said:

Hi Tursi - I know this is an older post, but recently started using your utility for the TI-99/4a and now trying it out for the Coleco Adam.  I have an F18A in both systems, so I'm interested in using those conversion modes.

The slideshow program you made for the TI is great!  Do you know if there is such a thing for the Adam?  I am not sure how to display the .HGRH image format on the Adam.

Thanks for any help you can provide!

I don't know, no. I'm annoyed to see there is yet another file format for bitmap on the Adam, that's getting to the point of silly. I think I already support three in my converter.  I don't actually know much about coding for the Adam specifically, so I can't help a ton on writing a slideshow program for it.

 

The docs folder in the zip has a full description of each of the modes the converter outputs. Sample code is mostly TI centric, but the only one that's really going to be weird is the 'half multicolor' flicker mode, everything else assumes a standard table layout.

[Tursi]

I took a look through the code. I did find it difficult to find good documentation on the file formats I did implement support for, so let me dump what I learned here. I support PowerPaint, HGR and CVPaint. All formats assume a standard bitmap layout with the screen image table containing 0-255 three times. I believe this information to be correct:

 

CVPaint seems to like the file extention ".pc". It has no header. It is a raw dump of the pattern table (6k) followed by the color table (6k). Very straightforward.

 

Powerpaint (extension ".pp") 10k is a bit weird in that some of the screen appears to be unused (room for a toolbar?), but all the horizontal data appears to be there. Maybe it's okay for it to contain screen data? My tool assumes it's not and exports that area empty. There are also 40k (2 screens by 2 screens) and 80k (2 screens by 4 screens) that I don't support.

 

At any rate, it is only 20 rows tall instead of 24, and in the samples I saw (plus my converter output) the 2 leftmost columns are written as zeros. The rest is the normal data. Pattern table first, then color table.

 

HGR/HGRH - I don't know if there is meant to be a difference. It's very similar in that it only outputs 20 rows instead of 24. It also has a small 21 byte header. I don't know what the contents of the header mean, but for all images I examined they were the same. It's probably related to the BLOAD command, similar to Apple's HGR... This seems to work:

 

\x01\x00\x02\x6c\x6b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00

 

In this one the /color/ table is first, then the pattern table. (Maybe HGRH is the full 24 row screen?)

 

At any rate, so far as my converter goes, I would stick to CVPaint format or just deal with the raw files yourself, as the others crop the image. But I put them there in case they needed to be loaded into existing tools.
 

Edited November 1, 2023 by Tursi

[mr_gw454]

13 hours ago, Tursi said:

I don't know, no. I'm annoyed to see there is yet another file format for bitmap on the Adam, that's getting to the point of silly. I think I already support three in my converter.  I don't actually know much about coding for the Adam specifically, so I can't help a ton on writing a slideshow program for it.

 

The docs folder in the zip has a full description of each of the modes the converter outputs. Sample code is mostly TI centric, but the only one that's really going to be weird is the 'half multicolor' flicker mode, everything else assumes a standard table layout.

Hi Tursi -- I only mentioned the .hgrh format as it was one that was available in the convert9918 utility.  I can certainly use something else (like CVPaint as you mentioned).  Even though I'm working on an Adam, I'm guessing any regular Coleco(vision) program would be compatible.  I see you also have a Adam PowerPaint 10K format.  I'll look to see what is needed to display that, too.

 

Thanks for the speedy reply on this!

 

[Tursi]

yeah... if HGRH is different from HGR, Convert9918 unfortunately treats them the same. If someone can confirm or send me a couple of actual HGRH so I can confirm the difference between that and HGR, then I can fix it.

 

[NIAD]

On 11/1/2023 at 5:54 PM, Tursi said:

yeah... if HGRH is different from HGR, Convert9918 unfortunately treats them the same. If someone can confirm or send me a couple of actual HGRH so I can confirm the difference between that and HGR, then I can fix it.

 

I've never heard of an HGRH picture file format for the ADAM or a PC based conversion utility that supports ADAM formats.

 

The SmartBasic HGR screen is 256x160 for the graphics area with four lines of text at the bottom and SmartBasic HGR2 is 256x192... a full screen. Is HGR2 possibly what is being referred to here?

 

I feel your pain about ADAM picture file formats and the lack of good information, but supporting PowerPaint 10K binary, HGR and CVPaint should cover any possible needs and then one can save in PowerPaint format if they want to transfer it to a disk image or actual disk, PowerPaint can then be used to save this PP 10K binary into SmartPaint *.HRP and from there numerous SmartBasic programs are available (pix.mgr is included with PowerPaint) to convert to other formats such as SmartBASIC HGR that may be needed.

 

Thankfully there weren't a lot of graphics programs and therefore graphic file formats for the ADAM and probably a god send that PowerPaint was released early enough (in 1987) to supplant the couple others as the standard. The picture file formats that I'm aware of are as they became available chronologically:

 

- PaintMaster 240x160, 10K broken up into two 5K files (filename1, filename2)

 

- GraphicPainter/GraphixPix 256x192, 14K broken up into two 7K files (filename.H2c, filename.H2p)

when these are loaded in PowerPaint, which uses a 256x160 cell, cell #1 is filled and the overflow is loaded into cell #3 so that one can switch between the cells to see the entire picture.

 

- ShowOff I 256x160, 12K broken up into four 3K files (filename.HRP, .HR2, .HR3, ,HR4)

this file format was the most popular BITD and was supported by virtually every program and conversion utility made from this point on

Can be loaded and displayed on the SmartBasic HGR or HGR2 with pix.mgr program included with PowerPaint 

ShowOff I was then replaced by PowerPaint

 

- PowerPaint could load the above file formats and added three new formats

PP 10K Binary 256x160 (filename☹️ (sad face is a CONTROL B)) (1 work cell/screen)

PP 40K Binary 480x320 (4 work cells/screens)

PP 80K Binary 480x640 (8 work cells/screens requires a 256K Memory Expander or larger)

I preferred using the ShowOff I picture file format for saving especially for when using in SmartBasic and conversion utilities to HGR format

 

and a couple others that were very interesting, but never caught on

 

- daVinci 256 ? x 192 ?, 13K file (filenameH with H being the file type)

really neat graphics design program that I never spent the time to learn

 

- Coleco Graphics Processor (aka Project Name by Line)

I don't recall the details but used it a lot BITD as the cartridge version would capture the currently displayed screen when the Cartridge Reset was pressed.

 

 

 

[Tursi]

Thanks! Yeah, if I were to guess I'd bet HGRH is HGR2. Most of the documentation I found from old newsletters with little docs, and I pretty much just dumped the binary files into a conversion tool I wrote for Classic99 VDP dumps and fiddled with them till I worked out the data order. Luckily they weren't packed.

 

[NIAD]

15 hours ago, Tursi said:

Luckily they weren't packed.

 

Damn! I wish you would have asked me for some sample files back then. I would have sent you an HGR picture file that was compressed with the MultiMedia Utilities Kit program that Joe uses to create his slideshows. 😜

 

[Tursi]

36 minutes ago, NIAD said:

Damn! I wish you would have asked me for some sample files back then. I would have sent you an HGR picture file that was compressed with the MultiMedia Utilities Kit program that Joe uses to create his slideshows. 😜

I would have simply failed!

 

[jblenkle]

On 10/31/2023 at 10:20 PM, Tursi said:

I took a look through the code. I did find it difficult to find good documentation on the file formats I did implement support for, so let me dump what I learned here. I support PowerPaint, HGR and CVPaint. All formats assume a standard bitmap layout with the screen image table containing 0-255 three times. I believe this information to be correct:

 

CVPaint seems to like the file extention ".pc". It has no header. It is a raw dump of the pattern table (6k) followed by the color table (6k). Very straightforward.

 

Powerpaint (extension ".pp") 10k is a bit weird in that some of the screen appears to be unused (room for a toolbar?), but all the horizontal data appears to be there. Maybe it's okay for it to contain screen data? My tool assumes it's not and exports that area empty. There are also 40k (2 screens by 2 screens) and 80k (2 screens by 4 screens) that I don't support.

 

At any rate, it is only 20 rows tall instead of 24, and in the samples I saw (plus my converter output) the 2 leftmost columns are written as zeros. The rest is the normal data. Pattern table first, then color table.

 

HGR/HGRH - I don't know if there is meant to be a difference. It's very similar in that it only outputs 20 rows instead of 24. It also has a small 21 byte header. I don't know what the contents of the header mean, but for all images I examined they were the same. It's probably related to the BLOAD command, similar to Apple's HGR... This seems to work:

 

\x01\x00\x02\x6c\x6b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00

 

In this one the /color/ table is first, then the pattern table. (Maybe HGRH is the full 24 row screen?)

 

At any rate, so far as my converter goes, I would stick to CVPaint format or just deal with the raw files yourself, as the others crop the image. But I put them there in case they needed to be loaded into existing tools.
 

Your program supports .HGR? Is this only a "load" feature? Because I don't see it in the formats you can save a file to.

[Tursi]

Are you on the latest version? Last updated it back in June. I don't usually report the updates here cause nobody ever replies to updates in the ColecoVision forum

 

https://harmlesslion.com/software/convert9918/

 

[Captain Cozmos]

I just used this and, although it's cool that I can output it as a cartridge, where is the source listing?
I mean, I can disassemble the cartridge to get the info but I would have thought that this can output source code to use in your own work.
 

 

I'm such an egg head that I can engineer a bridge and not know how it functions.

 

edit:

 

The two table pointers are a few bytes from the header so I linked them and there is all the data.
pretty neat..

 

O3 Cozmos

Edited November 9, 2023 by Captain Cozmos

[Tursi]

Yeah.... simply displaying an image is pretty basic and the carts are produced as a quick demo rather than an example how to load a picture. There's a sample loader in examples.zip included in the archive, the only difference being it looks like I moved the RLE flag to a third entry in the cartridge header rather than an #ifdef.

 

Looks like that code predates libti99coleco.

Spoiler

 

#include "cv.h"
#include "cvu.h"

// addresses for the pointers
//
// load the address of the Color table here
#define GAMEC 0x80e0
// load the address of the pattern table here
#define GAMEP 0x80e2
// load the RLE flag here (0 = uncompressed, 1=RLE)
#define RLEF 0x80ff


// VRAM Usage:
// 0000 - 17FF - Pattern table
// 1800 - 1AFF - Screen image table
// 1B00 - 1B7F - Sprite attribute list
// 1B80 - 1FFF - free space
// 2000 - 37FF - Color table
// 3800 - 3FFF - sprite descriptor table

void RLEUnpack(cv_vmemp p, unsigned char *buf) {
	int cnt;
	unsigned char z;

	cv_set_write_vram_address(p);
	cnt=6144;
	while (cnt > 0) {
		z=*buf;
		if (z&0x80) {
			// run of bytes
			buf++;
			cv_vmemset_slow(*buf, z&0x7f);
			buf++;
		} else {
			// sequence of data
			buf++;
			cv_memtovmemcpy_slow(buf, z);
			buf+=z;
		}
		cnt-=(z&0x7f);
	}
}


// code starts
void main(void)
{
	unsigned char i,j;
	unsigned char *pCol, *pPat;

	// just display some bitmap pictures
	cv_set_screen_active(false);			// Switch screen off.
	cv_set_screen_mode(CV_SCREENMODE_BITMAP);
	cv_set_sprite_big(1);
	cv_set_sprite_magnification(0);

	// set the mode bits ourselves
	cv_set_read_vram_address(0x8206);		// SIT at >1800
	cv_set_read_vram_address(0x83ff);		// CT at >2000
	cv_set_read_vram_address(0x8403);		// PDT at >0000
	cv_set_read_vram_address(0x8536);		// SAL at >1B00
	cv_set_read_vram_address(0x8607);		// SDT at >3800

	cv_set_colors(CV_COLOR_BLACK, CV_COLOR_BLACK);

	cvu_vmemset(0x1b00, 0xd0, 128);				// disable all sprites

	pPat=*(unsigned char**)GAMEP;
	pCol=*(unsigned char**)GAMEC;

	// load screen to VRAM - check byte at 0x80ff to see if it's RLE (1) or not (0)
	if (*((unsigned char*)RLEF)) {
		RLEUnpack(0x0000, pPat);
		RLEUnpack(0x2000, pCol);
	} else {
		cvu_memtovmemcpy(0x0000, pPat, 6144);
		cvu_memtovmemcpy(0x2000, pCol, 6144);
	}

	// fill the image table with three sets of 0-255
	cv_set_write_vram_address(0x1800);
	for (i=0; i<3; i++) {
		j=0;
		do {
			cv_voutb(j++);
			cv_voutb(j++);
			cv_voutb(j++);
			cv_voutb(j++);
		} while (j != 0);
	}

	// finally, turn on the display
	cv_set_screen_active(true);

	// and spin...
	for (;;) ;

}

 

 

 

Not entirely sure where I got those header addresses from, this code predates my own libs by a lot and I haven't looked at it in over a decade.

 

But, for uncompressed, it's just a matter of copying the pattern table to VDP 0x0000 or 0x2000, the color table to the other one, setting up the VDP registers for bitmap mode, and copying 0-255 to the screen image table 3 times.

 

In your own software I'd recommend just including the image data in the build and access it directly, don't use indirect pointers like this program does. The reason it does this is to make it easy for convert9918 to patch the image data into it.

 

Edited November 10, 2023 by Tursi

[Captain Cozmos]

Is there any way you can coordinate with Tony Cruise to have the output of this be able to import into his Tile Editor?

I see the only thing he imports is ICVGM DAT, whatever that format is, and it's not an export that I can find in this program.

 

Thanks

[Tursi]

7 hours ago, Captain Cozmos said:

Is there any way you can coordinate with Tony Cruise to have the output of this be able to import into his Tile Editor?

I see the only thing he imports is ICVGM DAT, whatever that format is, and it's not an export that I can find in this program.

No, I don't see that happening.

[Tursi]

I should probably clarify - there's nothing to collaborate on. It's a memory dump. His tool can either read a bitmap image it or it can't, but there's nothing I need to be involved in.

 

[Captain Cozmos]

4 minutes ago, Tursi said:

I should probably clarify - there's nothing to collaborate on. It's a memory dump. His tool can either read a bitmap image it or it can't, but there's nothing I need to be involved in.

 

Darn, I would have hoped you guys make everything universal.

It's time for me to take a C++ and Direct X class

[Tursi]

1 hour ago, Captain Cozmos said:

Darn, I would have hoped you guys make everything universal.

It's time for me to take a C++ and Direct X class

You can't get any more native than the data layout that the chip itself uses.

 

You reverse engineer all these programs, surely it's not that hard for you to copy 6k from CPU memory to VDP memory?