Intycolor - some experiments

[catsfolly]

I thought I would try a couple of experiments with Intycolor to see what kind of trouble I could get into...

 

First I started with the Match 5 title screen. The screen has no motion objects embedded in it, and uses less than 64 custom cards. It should have only 3 colors in it.

 

Here is my test bmp file:

 

 

 

 

titlepc.bmp

 

After converting it to a Foreground background basic program, I got tons of errors and this result:

 

 

I tried again in color stack mode, and I got this result:

 

 

Next I tried GroovyBee's "Terra 5" title screen, which may be using mobs inside it somewhere...

 

Here is the original image (scaled and converted to bmp):

 

 

terra5pc.bmp

 

Here it is as a foreground/background basic file:

 

 

And as a color stack basic file:

 

 

Finally, as the worst possible case, I tried this picture of Pauline Porizkova:

 

 

pp1_imagespc.bmp

 

In foreground/background mode, I got:

 

 

While in Color stack mode I got:

 

 

So it looks like these images are a bit too complex for Intycolor in it's current form. Maybe the program is very sensitive to the alignment of the pixels in the picture. I will have to keep experimenting with it....

 

 

Catsfolly

 

 

 

[intvnut]

If you're using screen shots from jzIntv, be sure to trim 4 pixels off the top and bottom. jzIntv pads its screen shots to 200 rows tall, adding 4 pixels of border color at top and bottom.

 

Also, it looks like IntyColor doesn't take advantage of GROM tiles still. That may be another source of "fun" in these experiments. :-)

[intvnut]

I just had a look at the Terra5 BMP up close. It appears to have JPEG encoding artifacts. I'm not sure how you captured the image, but the areas that look like they should be flat color are not flat color in the source bitmap. There are significant color fringes around color transitions. I didn't look at the others, but I suspect there could be similar issues also throwing a monkey wrench in the works.

 

EDIT: Looking at the Match5 BMP, it looks like it has re-sampling noise in it, so that the graph doesn't line up properly on the pixel rows. That might happen if you take a 200px tall image and resample it down to 96px, for example.

Edited April 7, 2014 by intvnut

[catsfolly]

I just had a look at the Terra5 BMP up close. It appears to have JPEG encoding artifacts. I'm not sure how you captured the image, but the areas that look like they should be flat color are not flat color in the source bitmap. There are significant color fringes around color transitions. I didn't look at the others, but I suspect there could be similar issues also throwing a monkey wrench in the works.

 

EDIT: Looking at the Match5 BMP, it looks like it has re-sampling noise in it, so that the graph doesn't line up properly on the pixel rows. That might happen if you take a 200px tall image and resample it down to 96px, for example.

Good catch. I resized the images from 320 by 200 down to 160 by 96, and it looks like this introduced some color artifacts. Maybe the clean way would be to reduce the size in half, and then crop the picture from 100 pixels high to 96 pixels high...

[GroovyBee]

Next I tried GroovyBee's "Terra 5" title screen, which may be using mobs inside it somewhere...

The Rescue on Terra 5 title screen is done in CS mode, uses 57 GRAM cards for the whole image and 8 of them are used as MOBs. Some GROM cards are thrown into the mix as well. The 7 remaining GRAM cards were saved just in case we want to knock out the built in Inty font for "Rescue on".

[intvnut]

Good catch. I resized the images from 320 by 200 down to 160 by 96, and it looks like this introduced some color artifacts. Maybe the clean way would be to reduce the size in half, and then crop the picture from 100 pixels high to 96 pixels high...

 

If you're using GIMP, you can do this exactly with zero artifacts introduced.

• Cropping:
  • Select the crop tool
  • Highlight a random rectangle in the image.
  • In the tool dialog box, manually set position to 0, 4, and size to 320, 192.
  • Re-focus the image window (ie. click on its title bar) and hit enter to crop.
• Resizing
  • Go to Image => Scale Image
  • Set Interpolation to "None"
  • Set image size to 160 pixels by 96 pixels and click Scale.

That should resize the image without introducing artifacts due to the rescaling.

 

As far as the color depth goes: The GIF screen shots generally load up in Indexed mode. You can set the image to "RGB" mode either before or after the above operations. Setting it after cropping and scaling ensures you do not introduce "new" colors into the image.

[catsfolly]

Attempt number 2.

 

I followed Intvnut"s instructions and reprocessed the image using gimp. I used the Match 5 title screen, and I even took out the grom characters.

 

Here is the original:

 

 

logoonly.bmp

 

When I ran it through Intvcolor and created a (foreground background) basic program, the result was:

 

 

Which is very colorful and abstract, but not what I expected...

 

It turns out that the Gimp program was putting some "color space" data in the bmp file that Intycolor wasn't expecting.

 

So I exported the graphic without the color space data:

 

logoonly2.bmp

 

And tried again. This time, the basic program produced this image:

 

 

Which looks like the original.

 

Looks like there is hope for this program yet, once I learn how to use it...

 

Thanks for the help, Joe.

 

Catsfolly

 

[intvnut]

When I ran it through Intvcolor and created a (foreground background) basic program, the result was:

 

shot0007.gif

 

Which is very colorful and abstract, but not what I expected...

 

 

You know, if you could animate that, say, rotating around, with the light blue areas shifting around, as if on a separate plane, it would have a very TRON feel to it. (I'm thinking "Flynn, just as he's about to rez up in the computer world" here.)

 

I'm guessing the sRGB colorspace fragment in the BMP decoder must've caused a hiccup? In any case, it looks like once you removed that, things started working nicely.

[intvnut]

 

 

You know, if you could animate that, say, rotating around, with the light blue areas shifting around, as if on a separate plane, it would have a very TRON feel to it. (I'm thinking "Flynn, just as he's about to rez up in the computer world" here.)

 

 

 

Ok, I spent too much time this evening having fun with the silly concept.

 

And in case you're wondering, I drew the graphics in a pretty old-school way, by hand, in VI.

match_5_tron.zip

[+DZ-Jay]

 

 

Ok, I spent too much time this evening having fun with the silly concept.

 

And in case you're wondering, I drew the graphics in a pretty old-school way, by hand, in VI.

 

Wow! That is very cool. I was half-expecting to hear Wendy Carlo's score with it.

[catsfolly]

 

 

Ok, I spent too much time this evening having fun with the silly concept.

 

And in case you're wondering, I drew the graphics in a pretty old-school way, by hand, in VI.

Cool. It looks good with the 3d glasses - the red "Match" floats above everything else...

[JohnPCAE]

Cool. It looks good with the 3d glasses - the red "Match" floats above everything else...

 

Oh, you just gave me a *very* off-the-wall idea. I don't know how possible this is, but it would be WAY cool if we could hack an Intv to drive a pair of Sega Master System 3D shutter glasses! The conector for the SMS card connector is a little hard to find, but not impossible. There are Japanese adapter cartridges (typically in noff-white plastic) that have the correct pinout -- I was able to snag one on Amazon. My understanding is that there have been PC parallel port hacks for those glasses around for years and they're apparently very easy to manipulate.

Edited April 15, 2014 by JohnPCAE

[intvnut]

 

Oh, you just gave me a *very* off-the-wall idea. I don't know how possible this is, but it would be WAY cool if we could hack an Intv to drive a pair of Sega Master System 3D shutter glasses! The conector for the SMS card connector is a little hard to find, but not impossible. There are Japanese adapter cartridges (typically in noff-white plastic) that have the correct pinout -- I was able to snag one on Amazon. My understanding is that there have been PC parallel port hacks for those glasses around for years and they're apparently very easy to manipulate.

 

If you have an ECS, you can set the I/O ports on the second PSG to output and then drive the LCD toggle via one of the two 9-pin connectors on the ECS. So, whatever folks are doing with the PC parallel port you could pretty easily do from the ECS's PSG I/O ports.

[+DZ-Jay]

 

If you have an ECS, you can set the I/O ports on the second PSG to output and then drive the LCD toggle via one of the two 9-pin connectors on the ECS. So, whatever folks are doing with the PC parallel port you could pretty easily do from the ECS's PSG I/O ports.

 

Aha! We tend to forget that the "O" in "I/O Port" stands for "output."

 

-dZ.

[intvnut]

 

Aha! We tend to forget that the "O" in "I/O Port" stands for "output."

 

:-)

 

And, they're dreadfully simple, but that's all you need. Basically bits 6 and 7 in location $F8 are the port direction bits for the two connectors. 0 is input, 1 is output. The ECS uses these to scan the ECS keyboard and the piano keyboard.

 

FUN FACT: The keyboard scanning matrix for both fits within 7 bits, so you could use the 8th bit for your own nefarious purposes, including driving 3-D glasses. :-)

 

If we could find a source for 100s of pairs of 3-D LCD shutter glasses, I'd entertain putting an interface off of JLP for a shutter-glasses based 3-D release. Until then, for these one-off hacks, the ECS I/O port seems like a low-barrier-of-entry starting point.

 

That said, anyone know how these bluetooth jobbies work? http://www.ebay.com/itm/Bluetooth-3D-Active-Shutter-LCD-Glasses-for-3D-Samsung-LG-HDTV-Blue-ray-Player-/181260818924?_trksid=p2054897.l4275

 

EDIT: Oh hai: some wired ones! http://www.ebay.com/itm/like/150924199237?lpid=82

Edited April 17, 2014 by intvnut

[+DZ-Jay]

 

:-)

 

And, they're dreadfully simple, but that's all you need. Basically bits 6 and 7 in location $F8 are the port direction bits for the two connectors. 0 is input, 1 is output. The ECS uses these to scan the ECS keyboard and the piano keyboard.

 

FUN FACT: The keyboard scanning matrix for both fits within 7 bits, so you could use the 8th bit for your own nefarious purposes, including driving 3-D glasses. :-)

 

If we could find a source for 100s of pairs of 3-D LCD shutter glasses, I'd entertain putting an interface off of JLP for a shutter-glasses based 3-D release. Until then, for these one-off hacks, the ECS I/O port seems like a low-barrier-of-entry starting point.

 

That said, anyone know how these bluetooth jobbies work? http://www.ebay.com/itm/Bluetooth-3D-Active-Shutter-LCD-Glasses-for-3D-Samsung-LG-HDTV-Blue-ray-Player-/181260818924?_trksid=p2054897.l4275

 

EDIT: Oh hai: some wired ones! http://www.ebay.com/itm/like/150924199237?lpid=82

 

You know, when I was a kid, a really cool project on the C=64 was hooking up some special parts to the Joystick ports and making little programs for driving servos in Capsela and Erector sets. What other fun applications could we have for this sort of idea, apart from just driving 3-D shutter glasses?

[awhite2600]

Driving external hardware through the I/O ports of a computer has so many possibilities. When I was in high school in 1985, a fellow student and I used a Commodore 64 to drive six Kodak Carousel slide projectors. Not only could the interface change the slides, it could turn the lamps on and off. We built an interface board that used 8 bits from the user port and 4 bits from one of the joystick ports. We even wrote a scripting language, compiler and runtime environment to allow us to create a complex slide show synced to music. I found the slideshow on an old Beta tape and uploaded it to YouTube. http://youtu.be/WbOrx0rczFk

[intvnut]

Driving external hardware through the I/O ports of a computer has so many possibilities. When I was in high school in 1985, a fellow student and I used a Commodore 64 to drive six Kodak Carousel slide projectors. Not only could the interface change the slides, it could turn the lamps on and off. We built an interface board that used 8 bits from the user port and 4 bits from one of the joystick ports. We even wrote a scripting language, compiler and runtime environment to allow us to create a complex slide show synced to music. I found the slideshow on an old Beta tape and uploaded it to YouTube. http://youtu.be/WbOrx0rczFk

 

Coolness. You could in theory port that to the Intellivision. :-)

 

The ECS has two 8 bit I/O ports. Each port is all-input or all-output, which is a bit different than the VIA chips in the Commodore as I recall. IIRC (and my memory is fuzzy), you could control I/O direction on a per-pin basis, rather than for the whole port. So, depending on what you were doing, you might need additional glue logic to get the combinations of inputs and outputs you need. I'm going to guess for the carousel operator, you just needed outputs.

 

The connectors on the ECS are standard 9-pin connectors with 8 data lines and a ground. The only issue is that they're recessed, and most 9-bit female connectors you can find these days have a flange on them that gets in the way. You'd either need to cut the flange off somehow, or do like I did and take the top off the ECS.