I am planning to build my own homebrew console.
I have some idea about 6502/RAM/ROM workings. I know about assembly programming and quite a bit of electronics.
However I do not know much about audio/video generation.

Well, my question is, where to begin for this project?
I can come up with working CPU/RAM/ROM model. Now where to go next? I have tried to look at NES/Famicom PPU working, but it does not explain internals of PPU chip (as in block diagram). Most of the posts explain the IC working, but not how it is done internally. My goal is to build a replacement for PPU using other easily available/understood (internal working available) chips.

Does anyone has any pointers to any online material? Or any specific topics I should study?

Edit: I have gone through http://wilsonminesco.com/6502primer/index.html
It is a really great resource. However it goes into many advanced things. I need to understand functionality of a NES PPU.

You might be in the wrong forum?
But, as far as your video generation question, I think I can give a reasonable answer since I'm experimenting is this area presently with FPGA and high speed RAM: Video Generation is presently done by FPGA's.
For the big companies/professional EE's, they use ASIC's to achieve higher clock speeds, but I would almost guarantee they also use FPGA for initial experimentation stages of their project before they spend the tens of thousands of dollars on their proprietary ASIC.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Thanks for quick reply.
Well I just put NES PPU since, that is the only 6502 based system I understand.
Basically, my objective is to generate graphics on screen and move it as per user inputs.

Well I haven't studied any FPGA for video generation.

But Is it even with worth spending time trying to design my own PPU?

How would you start designing your own PPU? Discrete components?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

well to start with
1. generate an interrupt signal per 1/60 sec and send to 6502 NMI
2. Handle this NMI (in a program), update some memory (RAM) with current graphics to be displayed
3. then enable a certain circuitry to generate video signal based on the contents in that RAM
4. convert this video signal to TV/monitor signal

This is some rough idea I have. I don't know if I am over simplifying this.
But if this approach is right I can dig deeper for each step.
Please let me know if you have any suggestions about this.

Your goals seem reasonable. But my question is how do you plan to implement your design in hardware?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Well, that's the part I'm clueless about.
Probably using basic gate ICs, clock frequency dividers, some generic IC (not sure if there exists such a thing) to generate video signals..
Maybe I'll have more idea if I find some PPU design somewhere..

Real hardware or HDL?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Real Hardware... at least it should work (to some extent) in theory first.. then I can buy and actually build it...

You might want to look at schematics for old school video arcade games.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Well a certain Mr. Wozniak did video generation and DRAM refresh using simple ICs and a few discrete components for the Apple I and Apple II, so there is some prior art that you could study, using your favorite search engine. The Atari 2600 was even more primitive, but very popular. The old analog standards are fading away, but you shouldn't have much trouble generating an industry-standard signal like VGA, using similar techniques. Here is an impressive example.

There are many ways to go about generating a display ... you simply have to ask yourself how much you want to engineer for yourself, and what kinds of capabilities you wish to incorporate.

Atari 2600s used software to 'race the beam", and Apples used bit-maps with minimal software support needed (but rather limited options). C64s and Atari 800s used custom-built smart chips to do complex video and sound generation without stealing too much CPU time. There are many other systems with which I am not as familiar, but you should be able to study an existing design that appeals to you, and go from there.

Best of luck,

Mike

Very true, the desired resolution must be the starting point for the pixel clock. From this the HSYNC & VSYNC frequencies are derived...
or maybe a minimum and a maximum pixel clocks?
I always shoot for max speed, that way the lower resolutions can easily be accommodated.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

You would be interested in Jeff Laughton's (Dr Jefyll on this forum) page on getting good, cheap video performance by fooling the 6502:
http://www.laughtonelectronics.com/Arca ... aster.html


and I don't get into video much at all there, since my applications require very little human I/O, especially graphical output.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks Mike and Wilson!
I am having a look at Apple I and ][, atari 2600 systems. Also Laughton link Wilson provided.

I'll study this and come up with my own design and post it here for review!

fsakura probably knows most of this, but here is a little PPU primer for others as I understand it.

Making a discrete video generator for a "toy" 6502 console is something I've batted around in my head recently as well. From what I understand, the purpose of the NES PPU was to save bandwidth and space by only being able to control the position of 8x8 pixel tiles, which carry information about palette entries. This saves bandwidth by only needing to upload indices into specific tiles to the PPU, which then uses it's internal digital logic to figure out which pixel within the tiles is to be displayed on screen.

I would argue that tile format graphics, instead of a full VGA framebuffer, serves the 6502 well to save space and bandwidth. However, it seems a bit overkill to mimic an entire PPU in discrete components. You would need some way to convert the tile format (which is obviously not a linear framebuffer) in VRAM (preferably dual port) for the background and sprites to linear format, figure out priority (which sprites and BG tiles are in front of which?), create a separate line buffer of RGB components, and then iterate through the RGB components within the line buffer and convert to composite.

The NES PPU cheats at NTSC- it uses a lookup table of ones and zeros to figure out which color/hue is at which phase relative to colorburst. Here is a contrived example:

If you clock out each bit of the LUT at a constant frequency, you get a square wave output. If the clocking frequency is the some multiple of the colorburst frequency (I think it's 12 times colorburst 3.58*12= ~42MHz), the bits at which the ones begin and end determine the phase; the pattern loops a number of times until the electron beam has moved a sufficient amount. In fact one of these LUT entries is in fact used to generate the colorburst signal! Consequently, the output color information is a square wave instead of a sine wave. The magnitude/saturation is calculated using the high nibble of an internal register- I'm not sure how the value is converted to analog. I would suggest skipping that step and use an RGB encode such as the AD725 to generate the NTSC video.

If you defer the NTSC encoding to an external chip, I suspect you would have some luck doing PPU emulation in a microcontroller. Start tile conversion and priority calculations one scanline before Vblank ends, like the real PPU, VERY QUICKLY output the calculated RGB values to display to a RAM linebuffer, and have a counter IC iterate through that RAM and upload to a DAC. The DAC feeds into the NTSC encoder. The microcontroller should also provide sync, although I recall Daryl/8BIT talking about a 7400 series TTL chip that can output encoding signals (which is still made!).

TLDR: Probably can be done, but not easy, and not minimal component.