AY-3-8915 to RGB adapter.

[MrPix]

10 minutes ago, mr_me said:

I don't think modifying the intellivision rom can help.  The intellivision video signal is created in the stic.  Maybe the ossc firmware can be improved to better handle the intellivision video signal.

Hehe, like I said, that's not my strong area

The OSSC problem "seems to be" the sample/sync IC loses sync, so the OSSC falls down before any firmware element is in play. It's technically easier to regenerate the sync fed to the OSSC than to modify the OSSC firmware to interpret the nonsense the sync IC is giving. Then again, I'm not an OSSC expert. I looked at the schematic and went "oh, they used that not great but not really terrible IC, eh?" That's the limit of my exploration from that side.

What I'll likely do is a quick and easy "doesn't work with OSSC" RGB, and then in a couple of months evolve that to fix the sync signals, and take the feedback from the plain Jane version to modify the colors a little.

I have had the idea of using a counter alongside the sync pulses, and using this to create a virtual CPU bus to feed data into a Pi Zero to create low cost HDMI output. Catch is, while that would be a wonderful, simple and quite economical product, it would need someone to modify one of the open bare metal framebuffer packages out there so there's a nice pre-configured upscaling/line tripling, frame doubling option out there. That would be very satisfying, if anyone wants to do the ARM side of it.

[ChildOfCv]

So, like I said, when does it quit sending sync?  During the blanking period?  And the STIC is not actually activating the SYNC mode at the time?

[MrPix]

I've set aside Monday/Tuesday to do some more work on this, and I'll grab some screen caps from my oscilloscope and logic analyzer and share them. That way I'll be able to give really specific timings and omissions. From casual observing it looks like the four HSYNC pulses before and four after the VSYNC. All during the blank lines.

[ChildOfCv]

10 minutes ago, MrPix said:

I've set aside Monday/Tuesday to do some more work on this, and I'll grab some screen caps from my oscilloscope and logic analyzer and share them. That way I'll be able to give really specific timings and omissions. From casual observing it looks like the four HSYNC pulses before and four after the VSYNC. All during the blank lines.

You mean the equalizing pulses?  (before and after the vertical sync pulses)

 

(see http://www.sxlist.com/techref/io/video/ntsc.htm for a fairly comprehensive summary of an NTSC field)

[MrPix]

I think it was the HSYNC pulses itself. Sorry, my mind's been on other stuff the past few days (you were there) so I didn't remember it as clearly as I should. I'll give a definitive answer from the scope and logic analyzer on Mon/Tues.

That said, I'm leaning towards the counter/framebuffer HDMI solution now anyway as the full fix, as that would cost 1/3rd what an OSSC does and give much more satisfying results.

[ChildOfCv]

On 7/3/2020 at 2:34 PM, MrPix said:

I think it was the HSYNC pulses itself. Sorry, my mind's been on other stuff the past few days (you were there) so I didn't remember it as clearly as I should. I'll give a definitive answer from the scope and logic analyzer on Mon/Tues.

That said, I'm leaning towards the counter/framebuffer HDMI solution now anyway as the full fix, as that would cost 1/3rd what an OSSC does and give much more satisfying results.

I looked at the other thread that was linked here (the designer of the original RGB mod even chimed in there) and yeah it appears to be missing the equalizing pulses.  At VBI there are 6 pre-equalizing pulses, then the duty cycle reverses and you have 6 wide pulses, then it reverses again and you go back to 6 equalizing pulses.  They are supposed to be double-time from the standard scan.  But the STIC doesn't do any of that.  Sounds like the sync counting strategy would be to count HSYNC pulses until you reach an extended sync pulse, and also get a time constant between HSYNC.  Then run that counter down and when it hits 0, begin inserting the equalizing pulses.

[MrPix]

Hmmmm.

Looking at my NTSC book, it might be better just to have a preprogrammed playback of the entire blanking period, and insert that when you count out the last frame or half frame - based off the first frame being the first to have a color burst after it. That reduces it to just counting 262 sync pulses from the first burst after the blanking period, play back the new blanking period, then cut back in to the STIC's control and reset the counter. The only wrinkle is the odd/even fields with the half/whole and whole/half first/last scan lines.

An incentive to do it this way is that it enables easier conversion to Pi Zero conversion for version 2.

I'll poke at it on Mon/Tues and see what falls out.

[cssgary]

I was hoping that my first post on Atari age was to have a working RGB adapter for the Intellivision, but alas it was not to be.  I have been working on this on and off for the past 6 months, but unfortunately I'm not an electrical engineer, but a humble AV guy who has been playing on the family Intellivision since 1982, when my father first brought it home.  I am very happy that people much smarter than me took a hold of this so I can play my Inty on something other than my very tiny BVM.  I studied all the information on RetroRGB available for Fred Kono's adapter, all the info I could find on the inner working of the Intellivision, and anything on how TV/NTSC really works (What a mess! Yuck!).  I basically was able to get the AY-3 on a logic analyzer, but as for getting any further I needed to get the LTO cart to see how the circuit behaves under various situations (I believe kinda like Kevtris does up the road from me).  While I have been waiting for that to come out, I saw this thread.  I took up the project, because I saw no one else working on it and I am very happy we have some people working on it that seem to know what they are doing and look forward to trying it out for myself.

[ChildOfCv]

6 hours ago, MrPix said:

Hmmmm.

Looking at my NTSC book, it might be better just to have a preprogrammed playback of the entire blanking period, and insert that when you count out the last frame or half frame - based off the first frame being the first to have a color burst after it. That reduces it to just counting 262 sync pulses from the first burst after the blanking period, play back the new blanking period, then cut back in to the STIC's control and reset the counter. The only wrinkle is the odd/even fields with the half/whole and whole/half first/last scan lines.

An incentive to do it this way is that it enables easier conversion to Pi Zero conversion for version 2.

I'll poke at it on Mon/Tues and see what falls out.

You may not need to worry about interlacing.  Many of the consoles don't.  They just always send "odd" frames because it doesn't have to chop start/end lines in half.  I guess you'd want to do a consecutive fields study of the Inty's output, but I think it does just odd frames.  I think the same is true for the TMS992x, 2600, and many others.

[MrPix]

ChildOfCv, thank you. You're giving me so many pointers that act as huge shortcuts. They will save me a lot of time working things out and searching for reference materials.

[emmanuelf]

Equalizing/serration pulse omission don't disturb OSSC sync and most console/electronic devices completely omit them an use plain hsync pulses (XNOR with vsync as needed)

A complete hsync pulse omission around vsync is the most coherent explanation of the problem.

We will see with the scope capture.

[MrPix]

I did some work on this on Tuesday but I forgot to make oscilloscope snapshots. I have more work planned and will try do capture this then, also photos.

 

’cos photos or it never happened.

[HARMIK]

Just found this I hope its still going would absolutely love one.

 

Thanks for all your hard work so far. ? 

[AlexandreSouza]

Any news? I am interested in the subject :)

[Walter Ives]

On 5/21/2020 at 5:33 PM, MrPix said:

Someone asked me about the possibility of designing an RGB adapter for the AY-3-8915. It looks almost trivially simple to do. What am I missing?

Nothing.

 

On 5/22/2020 at 9:46 AM, MrPix said:

Here's a little chart I derived of possible RGB values for the 16 8915 colors. I have looked at a bunch of screenshots and Youtube videos and approximated as best as I can. If you can look at them and suggest improved RGB codes, I'd appreciate the feedback

Gawd no! Make the colors match the names. Back in the day, users would play with the tint, color and brightness knobs until they got colors they liked. They'd even change the control settings for different games. If you're not going to give your users the ability to fiddle with the colors, use your judgment to pick out good ones. None of that meh or ewww stuff.

[+DZ-Jay]

On 12/3/2022 at 8:14 AM, Walter Ives said:

Nothing.

 

 

Gawd no! Make the colors match the names. Back in the day, users would play with the tint, color and brightness knobs until they got colors they liked. They'd even change the control settings for different games. If you're not going to give your users the ability to fiddle with the colors, use your judgment to pick out good ones. None of that meh or ewww stuff.

Yes! YES! A thousand times, yes!

 

    dZ.

[+-^CrossBow^-]

38 minutes ago, DZ-Jay said:

Yes! YES! A thousand times, yes!

 

    dZ.

On 12/3/2022 at 7:14 AM, Walter Ives said:

Nothing.

 

 

Gawd no! Make the colors match the names. Back in the day, users would play with the tint, color and brightness knobs until they got colors they liked. They'd even change the control settings for different games. If you're not going to give your users the ability to fiddle with the colors, use your judgment to pick out good ones. None of that meh or ewww stuff.

This is all pretty moot now with Crayon's current boards offering two different palettes that can be selected from game to game using a switch or just hard set a palette by jumpers or not.