Jump to content
mthompson

--gfx-palette flag

Recommended Posts

So it would be possible for a programmer to make their own palette for their game and distribute it with their rom, yeah? 

 

So for example, if someone wanted to make a game in greyscale with up to 16 shades of grey, this should allow them to do it, no? 

 

Granted it would be a jzintv only game, but it still opens up some imagination with custom palattes. 

Share this post


Link to post
Share on other sites
1 hour ago, fdr4prez said:

So it would be possible for a programmer to make their own palette for their game and distribute it with their rom, yeah? 

 

So for example, if someone wanted to make a game in greyscale with up to 16 shades of grey, this should allow them to do it, no? 

 

Granted it would be a jzintv only game, but it still opens up some imagination with custom palattes. 

 

I believe someone's already doing something like that for the Intellivision Baseball League.    But yeah, sky's the limit on 16-color palettes if that's what you want to do.

  • Thanks 1

Share this post


Link to post
Share on other sites

Okay, new random crazy game idea!

 

Somebody could make a port of the Atari Lynx game Dracula: The Undead.  It used the Lynx's 16-color palette to have shades of brown, resulting in an art style resembling an old illustrated "pulp fiction" book.  Plus, this type of game (graphical adventure) hasn't been done yet on the Intellivision to my knowledge.

  • Like 1

Share this post


Link to post
Share on other sites
On 11/29/2019 at 9:01 AM, Zendocon said:

Okay, new random crazy game idea!

 

Somebody could make a port of the Atari Lynx game Dracula: The Undead.  It used the Lynx's 16-color palette to have shades of brown, resulting in an art style resembling an old illustrated "pulp fiction" book.  Plus, this type of game (graphical adventure) hasn't been done yet on the Intellivision to my knowledge.

That is a great idea. A "noir style" game would be really cool with a horror theme for this coming Halloween 2020. Hmmm...

  • Like 1

Share this post


Link to post
Share on other sites
On 11/27/2019 at 10:11 AM, fdr4prez said:

So it would be possible for a programmer to make their own palette for their game and distribute it with their rom, yeah? 

 

So for example, if someone wanted to make a game in greyscale with up to 16 shades of grey, this should allow them to do it, no? 

 

Granted it would be a jzintv only game, but it still opens up some imagination with custom palattes. 

If there is developer interest in having this as a feature, we'd be interested in implementing it in our emulator too.

 

I could also see it as a cool option for IntyBASIC to be able to specifiy that in the project and/or for your code to know if it is supported or not at runtime.

Share this post


Link to post
Share on other sites

Ok, time to revive this thread.

I'm a hardware developer, and I'm making an AY-3-8915 replacement that produces RGB. I'll be using a modest CPLD to do this, and right now I am creating a V1-V4 color to RGB reference table. My restriction is the number of bits I can allocate to the R, G and B channels. I'll also use the V5/2/1 bits to create correct timing, and use logic to derive hsynch and vsynch too. That should be enough to get the board working with most OSSC-type converters, SCART TVs and etc. Obviously, getting in at the bitwise input level means all the timing is ready sorted and all the colors are absolutes and not opinions (I'm looking at you, NTSC!) So this board would work on both NTSC and PAL configurations and give "valid" RGBHV (and C!) output.

From there I can feed that clean RGB into an AD725 to get crisp S-Video with minimal dot crawl, and as clean as can be had composite.

I came here looking at the color tables, to help me with semi-accurate color conversion.

Let me explain the limitations of my board:

I have to use three R2R ladders to do digital to analog conversions of the R, G and B channels. Mattel used a lot of very made up color names and used some weirdly similar and dissimilar colors. For example, it could be argued there are four variants of something that could be called green, and three or four variants of something that could be called brown. I guess at the time, the state of game design was that most games were against a background of grass or dirt, so adding detail there was desirable.

No matter, my color profiles will symbolically follow these colors within the limitation of the bit depth I define for each color channel.

8 of the colors really sort themselves out, in that they are the classic all or nothing RGB colors black, blue, red, green, cyan, magenta, yellow, white. (rgb, rgB, Rgb, rGb, rGB, RgB, RGb, RGB)
It's the other 8 colors that make it fun. If I limit myself to 3 bits per channel that gives us 8 levels of intensity for R, G and B.

dec: 0, 32, 64, 96, 128, 160, 192, 224.

hex: 00, 20, 40, 60, 80, A0, C0, E0.

Attached is my current working table, based on 2-bit per channel limitations, before I went from 2:2:2 to 3:3:3. I have the pins to go to 4:4:2 or 4:4:3 if necessary.

Feedback/commentary/pitfalls sought.

 

Screen Shot 2020-05-22 at 2.07.35 PM.png

Share this post


Link to post
Share on other sites
6 minutes ago, MrPix said:

8 of the colors really sort themselves out, in that they are the classic all or nothing RGB colors black, blue, red, green, cyan, magenta, yellow, white. (rgb, rgB, Rgb, rGb, rGB, RgB, RGb, RGB)
It's the other 8 colors that make it fun.

Some observations I've made over the years:

  • Intellivision has different NTSC and PAL color sets.  In particular, Mattel computed what the chroma values should be from what they thought the NTSC was doing, and sent that to Radofin for the PAL units.  The videos I've seen of PAL systems match the colors I get when I use the numbers in that document, but they're different from what I see on NTSC.  (I forget which scan it is, but it's in the huge archive at PapaIntellivision.com.)
  • Intellivision NTSC "Red" has a lot of green in it.  It's more "unripe tomato."  I discovered it was more than I realized when working with the ChromaDepth 3-D glasses.
  • The NTSC Magenta, Purple, and Yellow-Green seem to be "out of gamut" for RGB, so these will never look quite right on RGB.  They just don't "pop" like they should.
  • Congo Bongo's first level makes a great litmus test to determine if you balanced tan, "brown," orange, and yellow properly.

Also, several folks have pointed out that 80s fully analog CRTs may have displayed Intellivision's colors a bit differently than modern TVs, so it's worth setting up an old TV if you have access to one.  I ditched all of my CRTs a long time ago, unfortunately.

  • Like 2

Share this post


Link to post
Share on other sites

Which is why I'm not *too* hung up on accurately matching the NTSC colors - because there aren't any. ;) I know that's a very lassaiz faire attitude to display, but once I get the basic system working it's a single chip swap or reprogram to remap the colors.

One thing I *could* do is use a small 16-bit EPROM or flash IC as a palette converter. Just have the logic in a GAL or very small PLD, and pass through the 4 bits of color selection into as the address on the ROM, which brings up a 16 bit (6:6:4?) value to input into the R2R ladders. People could then create their own color tables to meet their preference and just burn an EPROM?

I do keep a CRT around, but it won't be terribly helpful for this project.

Share this post


Link to post
Share on other sites

I don't know if the EPROM idea will work since some are too slow for video signal speeds.

 

A slightly more advanced (uhhm, complicated) design would be to use a 16-bit SRAM that stores the active color table.  Have a microcontroller that loads the SRAM at boot.  Additionally, the microcontroller could have a serial port that lets users change the colors table.  Since many microcontrollers include on-board EEPROM, any user configured colors could be stored there when power is off.

Share this post


Link to post
Share on other sites
1 hour ago, Lathe26 said:

I don't know if the EPROM idea will work since some are too slow for video signal speeds.

The pixels are 280nS and my standard EPROMs are 55nS. The 200nS ROMs in the console are fast enough ;) The important thing to consider is that the data is being latched by the 8915, so as long as the ROM meets the set-up time requirement it will work.

1 hour ago, Lathe26 said:

A slightly more advanced (uhhm, complicated) design would be to use a 16-bit SRAM that stores the active color table.  Have a microcontroller that loads the SRAM at boot.  Additionally, the microcontroller could have a serial port that lets users change the colors table.  Since many microcontrollers include on-board EEPROM, any user configured colors could be stored there when power is off.

The 8915 is a latching combinational logic device. It's in essence very, very simple. Its functionality could literally be replaced by a GAL16V8. I need a few more outputs and logic gates than a 16V8 to manage enough levels of RGB, so I selected a 44 pin ATF1502.

  • Like 1

Share this post


Link to post
Share on other sites

Going to user programmable (which is great) complicate things fast.

Going from initial ATF150X, you need to add a sram and a microcontroller.

You could perhaps collapse the microcontroller and the CPLD with a microchip or atmel µC with sufficient CLC cells.

Or try to go single chip with a PSoC 5200.

Next is the FPGA way ...

Share this post


Link to post
Share on other sites

The Eprom way is a good compromise to stay on a very simple but user customisable design. And the CPLD could switch bank/palette with a simple push button.

Edited by emmanuelf

Share this post


Link to post
Share on other sites

I have played with PSoC 5LP, and could use them as a later project to capture the data and upscale it to VGA resolution and frame rates....

But for now, I'd like to make a pure 8915 replacement that offers RGB output just as a proof of concept and to get RGB out to those that desperately need it.

  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, MrPix said:

The 8915 is a latching combinational logic device. It's in essence very, very simple. Its functionality could literally be replaced by a GAL16V8. I need a few more outputs and logic gates than a 16V8 to manage enough levels of RGB, so I selected a 44 pin ATF1502.

Yes, GAL or ATF1502 are very simple.  That is their advantage but also their flaw.  Once such a simple device is shipped to end-users, the colors are not customizable by the end-user; the colors are instead locked in.  If the user doesn't like the colors, the end-user doesn't have any options.  A fast EPROM is better in that a handful of folks can reprogram them to differ color shades, but only a handful of people can do that.  Going to an SRAM with a microcontroller gives maximum color flexibility, though likely at higher cost due to the complexity

Share this post


Link to post
Share on other sites

The ATF1502 is in circuit programmable. It can be reprogrammed just as easily as an EPROM. 
 

I do plan to do something more advanced later, involving a true frame buffer. To me, SRAM and a microcontroller are just a side distraction from the simple and the advanced options. But my mind isn’t completely closed to the idea. I’m aiming for nearer a $20-30 prize zone than a $50-75 price zone with the first RGB board. 

Share this post


Link to post
Share on other sites
11 hours ago, MrPix said:

The ATF1502 is in circuit programmable. It can be reprogrammed just as easily as an EPROM. 
 

I do plan to do something more advanced later, involving a true frame buffer. To me, SRAM and a microcontroller are just a side distraction from the simple and the advanced options. But my mind isn’t completely closed to the idea. I’m aiming for nearer a $20-30 prize zone than a $50-75 price zone with the first RGB board. 

Yes, the AFT1502 is programmable.  I own several.

 

The point is that it isn't programmable by end-users to change the color table.  This would avoid customer complaints that "the colors are wrong", even if you've worked hard to pick the best colors.

 

In regards to the feature where users are able to change the color table:

  • A SPLD or CPLD is the simplest but the table is fixed.  Maybe a few spare pins could be used for jumpers to let users pick from a handful predetermined color tables.  However, the average end-user can't create their own custom color tables.
  • A fast EPROM is has incrementally more flexibility.  Probably could use the unused address lines for the jumpers, similar to above.  A handful of people can create their own custom color tables with EPROMs, but they can be counted on your fingers in the Intellivision community.  Maybe one of them would offer custom EPROM color tables as a service, though I'm not certain if there is a practical mechanism for an end-user to be able to effectively communicate the shades they want on their own TV to someone else who writes the values to the EPROM.
  • A microcontroller with SRAM is the most advanced option for color table configurability.  End-users can change the colors at will.  Either the menu program would be in the microcontroller (i.e. a text menu via a terminal program) or a GUI executes on the host system (Windows, Mac, Linux?).  The downside is that this solution is also the most complex by far.  It might fit in the $20-$30 budget but that isn't certain.

Of course, there is a big question to ask in all of this: what is the right amount of configurability of the color table to offer the end-user?  Too little and you have to deal with complaints (but design and user setup is easier).  Too much and it might just be "rope to hang themselves" in that some end-users might just mess up the colors or find changing the colors too hard (may need a "restore defaults" menu option for the users to recover).

 

  • Like 1

Share this post


Link to post
Share on other sites
23 minutes ago, Lathe26 said:

Yes, the AFT1502 is programmable.  I own several.

Cool devices. I like them.

23 minutes ago, Lathe26 said:

The point is that it isn't programmable by end-users to change the color table.  This would avoid customer complaints that "the colors are wrong", even if you've worked hard to pick the best colors.

This is true. I would like to present a "perfect defense" for doing it this way, though.

I want to do something quick and easy, do demonstrate a working replacement for the 8915. It is important that it is functionally compatible, and that people will look at the output and recognize it as an improvement in terms of objective signal quality if not of subjective color purity. The reason for this is simple - to produce a quick, simple and low cost board that can be used to repair or upgrade consoles non-destructively now. 

With 3:3:2 RGB encoding this means I or anyone else can add in a fast EPROM/flash or RAMDAC/palette IC to map any color to any notional color. That said, I want to use it and a simple counter to turn the sequential pixel writes into address and data combinations that can be read into a Pi Zero, placed in a frame buffer, and then rescaled perfectly to HDMI, with the user able to load/save/create custom color tables. With an incremental hardware cost of $5, this is cost comparable with the more complex suggestions here, but offers far more utility and flexibility.

23 minutes ago, Lathe26 said:

In regards to the feature where users are able to change the color table:

  • A SPLD or CPLD is the simplest but the table is fixed.  Maybe a few spare pins could be used for jumpers to let users pick from a handful predetermined color tables.  However, the average end-user can't create their own custom color tables.
  • A fast EPROM is has incrementally more flexibility.  Probably could use the unused address lines for the jumpers, similar to above.  A handful of people can create their own custom color tables with EPROMs, but they can be counted on your fingers in the Intellivision community.  Maybe one of them would offer custom EPROM color tables as a service, though I'm not certain if there is a practical mechanism for an end-user to be able to effectively communicate the shades they want on their own TV to someone else who writes the values to the EPROM.
  • A microcontroller with SRAM is the most advanced option for color table configurability.  End-users can change the colors at will.  Either the menu program would be in the microcontroller (i.e. a text menu via a terminal program) or a GUI executes on the host system (Windows, Mac, Linux?).  The downside is that this solution is also the most complex by far.  It might fit in the $20-$30 budget but that isn't certain.

Of course, there is a big question to ask in all of this: what is the right amount of configurability of the color table to offer the end-user?  Too little and you have to deal with complaints (but design and user setup is easier).  Too much and it might just be "rope to hang themselves" in that some end-users might just mess up the colors or find changing the colors too hard (may need a "restore defaults" menu option for the users to recover).

 

This was my thought process and breakdown of the problem precisely. I decided to tackle the first element, and if there is enough interest (aka sales) to cover the development and manufacturing cost then I would tackle the third option, skipping the second option. Only difference is the 'microcontroller' would be a Broadcom ARM chip that happens to have spectacularly good framebuffer and rescaling capabilities with very minimal lag.

I'd say we're in violent agreement.

My fear is that if I focus too much on the latter option people will fail to express interest by supporting the simpler, quick and easy board that would be good enough for most people. So I'd like to focus on the simpler board here for now, then start a new thread to discuss more advanced options once that is completed.

Usually, I release the item and then publish all the design files, JEDECs, equations and etc. after three months, just to ensure that I can recover my development and warranty costs. All my work is open hardware.

  • Like 2

Share this post


Link to post
Share on other sites

Just my opinion: going further than the original analog signal and Tv resolution is falling down the rabbit hole.

RGBS is the format format which could simply bridge us to to digital world.

At minimal cost as many device are still able to get analog RGBS or with a few buck HDMI converter with reasonable result.

Going further is a never ending story and there is already a (open source/hw) solution for that : OSSC and the future OSSC Pro (with the latest and perhaps last top of the art integrated analog front end).

Even more personal opinion: I will never give Broadcom a cents for one of their ARM chip.

 

The ATF way of MrPix is the way to go and will not be only a proof of concept but will be better than what or had exist(ed). So one step after another 😌

  • Like 1

Share this post


Link to post
Share on other sites

Hehe.

Which is why I posted here in the first place. To find a color palette that most people would find at least not objectionable. I have an ability to add extra bits to add more color depth/resolution to the R, G and B channels once the basic logic is done and would be able to get very close to the NTSC or (preferably) PAL colors.

So far, the only real challenge in this project is working out sync reconstruction for missing HSYNC that trips up OSSC. If I can build a registered counter inside the CPLD, that would be optimal.

It's my own fault really. I should never have talked about hardware design in front of a bunch of programmers :P :D

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, MrPix said:

...


With 3:3:2 RGB encoding this means I or anyone else can add in a fast EPROM/flash or RAMDAC/palette IC to map any color to any notional color. That said, I want to use it and a simple counter to turn the sequential pixel writes into address and data combinations that can be read into a Pi Zero, placed in a frame buffer, and then rescaled perfectly to HDMI, with the user able to load/save/create custom color tables. With an incremental hardware cost of $5, this is cost comparable with the more complex suggestions here, but offers far more utility and flexibility.

This was my thought process and breakdown of the problem precisely. I decided to tackle the first element, and if there is enough interest (aka sales) to cover the development and manufacturing cost then I would tackle the third option, skipping the second option. Only difference is the 'microcontroller' would be a Broadcom ARM chip that happens to have spectacularly good framebuffer and rescaling capabilities with very minimal lag.

I'd say we're in violent agreement.

My fear is that if I focus too much on the latter option people will fail to express interest by supporting the simpler, quick and easy board that would be good enough for most people. So I'd like to focus on the simpler board here for now, then start a new thread to discuss more advanced options once that is completed.

Usually, I release the item and then publish all the design files, JEDECs, equations and etc. after three months, just to ensure that I can recover my development and warranty costs. All my work is open hardware.

Sounds smart to have a 2 phase approach to reduce risk.    

 

Regarding the Broadcom ARM chip for the later option, which one are you looking at?  I'm assuming the chip has a hardware RGB input mechanism (unless you are planning to skip using a preemptive OS and write bare metal assembly).  It's understandable if the later option a back-burner design and details are still in flux.

Share this post


Link to post
Share on other sites
23 minutes ago, Lathe26 said:

Regarding the Broadcom ARM chip for the later option, which one are you looking at?  I'm assuming the chip has a hardware RGB input mechanism (unless you are planning to skip using a preemptive OS and write bare metal assembly).  It's understandable if the later option a back-burner design and details are still in flux.

It has memory mapped IO, suited to bare metal, and a neat framebuffer that does hardware transformations to the specified standard HDMI format. It's also super cheap and pre-licensed for HDMI - which is a huge simplification.

Pi Zero for the win!

Share this post


Link to post
Share on other sites

Though I'm also intrigued by the idea of building a VGA engine (adapted from an existing design I've done) in a PSoC 5LP, and then adding a sync circuit to reconstruct the missing sync cycles that cause the OSSC to stumble. That board would be cheaper than the Pi Zero board, but you'd also need an OSSC, and it seems a lot of people have one already.

Share this post


Link to post
Share on other sites

I have a suggestion in regards to the two board approach, use the same cable connector for connecting the new boards to the Intellivision board.  I'm already doing something similar to make it easy to swap between the various existing composite mods.

 

By having a common cable connector for both boards, it's easy for someone who buys the 1st board to later upgrade to the 2nd one.  I don't recall if all Intellivisions put the AY-3-8915 in a socket or if some boards solder the chip straight in.  If the former is the case, then a DIP-18 ribbon cable adapter or something similar would do the job nicely.  If the latter is the case, then installing the 1st board would require solder work.  Of course, simply getting the big metal shield off is a pain.

 

Since only some folks can solder and other can't, there are folk in the community that offer video upgrading as a small service (at least from time to time).  Once there is a modest number of folks with the 1st board installed (including users with no solder skills), it would be easier for them to upgrade to the 2nd board later.

 

Anyways, this is just a suggestion.

  • Like 1

Share this post


Link to post
Share on other sites

A suggestion well taken. I plan to have the board fit in place of the 8915 and have a socket for the 8915, and would include a socket to put in its place if it needs desoldering.

  • Like 1

Share this post


Link to post
Share on other sites

I've looked at the missing sync signals a little more.

If anyone here is DEEPLY familiar with the inty ROM, could they look at the section that manages the manual handling of the V1 thru 5 generation and see if the lack of those 8 sync signals is simply a BIOS bug? Being able to include a replacement ROM image would be much simpler than building a sensitive PLL circuit. Cheaper too.

Share this post


Link to post
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...