MrPix

I just received the latest design from Falonn, and it's good enough that I have decided to assemble his board instead of re-implementing it in 4 layers. He's done a spectacular job of managing signal quality in two layers, and brought his A game on the ground and power fills - so I feel confident his 2-layer design would perform as well as any 4-layer design. We're just in final clean up and optimisation now. Crossing the I's and dotting the T's I've started ordering components.

I suspected PAL would work outright due to the suppression of the color burst, which causes severe color shifts. The real variance comes in the conversion to UHF, and the different frequency offset in UHF for the color carrier - later stages in signal processing. That said, there may be small differences between the B-Y and R-Y signals on the 9928 and 9929, as the 9929 might be tuned to the wider PAL color gamut. If observable, they could be corrected by recalculating the resistor dividers after U3. On which note, have you measured the current being sunk by those resistor dividers? You could multiply those resistances up to reduce current to ground, as 150 ohms is quite low and it will cause a little additional heating in U3. Every little bit helps.

Another Brit reporting for duty! Expat in Austin, TX! That was my experience too. In the 80s I was busy designing expansions for the Sinclair QL, and the Sam Coupe was designed by some bloke called Bruce on my electronics workbench - which I was evicted from and had to do my work on the packing bench. Great times.

I’m almost there on the single board ADE card, too. The hold up there is that I incorporated some features that the ADE creator has decided to not support. I was faced with removing the features or forking the code. I’m not going to fork the code because that would harm the community. The RAM card is working now. I have an 8MB card in my Adam right now. It just needs some clean-up and it’s done.

It got slowed up severely by world events. Mostly, key parts I ordered from suppliers in Feb/Mar aren't here yet. Still working on it, though Just, nothing to report.

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.

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!

And it's just as easy to make a cart that decodes RAM into the unmapped space in the CV too.

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

Cool devices. I like them. 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. 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.

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.

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.

Fair enough.

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. 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.

I’m planning to downrange with the very minimal ATF150X family. Super cheap and more than up to the task. If you want, we can combine projects. If not, that’s fine too.

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.

Here's how I plan to solve that problem. I will set up a counter that measures the time between the synch signal rising edges. This would be half clock accurate as the output is clock /2. When the sync is present I would use it to reset the counter. When the sync is absent, the counter will generate the synch signal. This way, the synch signal will always be present and the OSSC should be able to lock onto it. This gives us a counter generated, /2 clock accurate clean synch. Boom! This will work automatically for NTSC and PAL timings too.

Excellent links. Thank you both.

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.

That's true, but the white high res video signal is at the 8915 socket and isn't available at the STIC. I'm not aware of anything that uses it in the Intellivision, but the 8915 was used in other systems so I have to account for those that might have used high res white. Looking at the schematic, that signal can come from the cartridge port. My board will not care about the format of what's being input. It's good to know that some PAL systems might not have a PAL socket, and I might need to make a little adapter board to pick up those signals. Thanks for the heads up. I love when knowledgeable people in the community save me from pitfalls and traps like this Excellent info. Thank you. Snagged and archived in my dev folder. You folks are awesome!

The 8915 has 280nS pixels. It also has a video input pin to overwrite white text at 120nS pixels. I'm incorporating this logic, so this will work correctly. I don't know if anything used it either.

The module I am designing will work on NTSC or PAL models, as long as they have an AY-3-8915 IC. My project will be open hardware, and I will release all files, JEDECs and PCB files. I normally do this about three months after I release items, so I have a bit of time to recover my development cost. So yes, all this info will be public.

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

Well, of course! The sync and color burst system is beyond ridiculous. I'm not targeting a console as much as a device - the AY-3-8915. If that's in the console, my proposed board will create crystal clear RGB at the same timings, which then is the ideal source signal to create clean S-Video or new composite. Most of the improvement in video quality comes from using 'modern' components on a 4-layer board. *grins* I've experienced this problem - which is why I bypass the whole thing and just find video ICs where I can effectively replace the IC's functionality rather than reforming its outputs. Luckily, the 8900 and character ROMs etc. do their thing and the video generation on the 8915 is a simple 5-bit code with a "white overlay" - I can use a small CPLD to re-implement the logic entirely and output clean 3:3:2 RGB to make the 16 colors and all sync signals. Frankly, the hardest part of this is that each user has experienced different colors so they have their own fixed ideas of what the colors should be. That's why I posted here asking for help to create an RGB conversion table *nods* That's my goal. Consistent, crisp, bright but not over-saturated video, no dot crawl, no ripples or ghosting or jailbars, but that meets the original frame rates and resolutions.

This isn't about adding video standards. It's about this board fitting in many different systems and each community has their own ideas about what a 'standard' connector is It'll be available without a connector, or with two or three of the top choices requested pre-wired. I just want a handle on what connectors are being requested so I can have the right parts in hand at the best prices.