Jump to content
  • 0

Understanding graphics rendering


6502Builder
 Share

Question

I’m building my own cpu (6502 clone out of TTL chips) and with all the amazing buzz around the commander x16 I’d like to expand this goal to a whole machine. Maybe even borrow some kernel code 😉 as I plan to support the same assembly instructions as the  6502 (assuming decimal isn’t used) 

Anyway, I’ve been trying to learn how vga works and have produced a 640x480 display, but don’t know how to drive the image. At this resolution I can’t realistically store a bitmap in memory, let alone two, so can’t draw the image to memory at my own pace.

So was wondering how Vera does this. 
* Is it just so fast that it has the luxury of time to do this?
* does it know how to render a line of sprit pixels as the scan line passes by?

I’ve tried to look through the forum for details but typically find assembly instructions for controlling Vera, but not how Vera processes these instructions. Any info or links to documentation would be very much appreciated.

Thank you in advance,

jason

Edited by 6502Builder
Link to comment
Share on other sites

6 answers to this question

Recommended Posts

  • 0

I'm not sure about the internal workings of VERA, but in general, all a VGA display needs to do is have a range of memory that it can dip into for pixel color data and then dump it to the screen at the correct timing. Ben Eater did this with some basic address decoding being done by a gaggle of binary counter ICs.

I saw in the beneater subreddit where a guy actually made a clone of the NES PPU on breadboards! 🤯
If you want some insight as to how a chip like the PPU does its job, go watch OneLoneCoder's series on writing his own NES emulator from scratch. He covers how pixel buffers work in gory detail. Granted, it's from a software perspective, but the procedure is what counts here, right?
If you want to show a bitmap, you're going to need sufficient RAM to hold it. If you want indexed pixel data (e.g. 8bpp, 4bpp, whatever) then the colors those values reference can either be done by hard-wiring your palette (like Ben Eater did using a resistor ladder) or else having a block of palette data that the chip uses to convert the indexes into RGB values (which then get written to the display using a hardwired circuit like Ben Eater's resistor ladder).
If you do tiles / sprites, your chip will need to cycle through the various objects that may be on the pixel row, and write them into the pixel buffer. The pixel buffer would be the data getting written to the screen by the dot clock.

Link to comment
Share on other sites

  • 0

As x86 wasn't initially meant to be a "home" or "gaming" computer, its graphical cards were relatively simple. You had a set of registers allowing you to change the video mode and a set of BIOS routines simplifying even that process. VGA at its best was giving you 64K of video memory mapped in four banks. You could set your palette and then just put pixels by addressing memory with CPU doing all the job. Only in 1990s in SVGA era, when first 3D accelerators appeared some chips were allowing you to use such stuff as double-buffering and some acceleration like bitblt, lines, circles and maybe polygons.

Commodore, Amiga and lots of consoles were totally different. They had relatively weak CPU with small amount of RAM and lots of the quite autonomous chips with plenty of features. So yes, VERA is powerful enough to do everything by its own. 

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

Guest
Answer this question...

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

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use