Chad's topic on VGA and Dual port RAM design has inspired me to take another look at Apple II style of multiplexing video RAM access with 6502 access. Apple II is 1MHz but we now have much faster W65C02 and faster RAM so this design uses 25.175MHz VGA clock and divides it by 2 to drive W65C02 with 12.6MHz. W65C02 can access the video RAM at high phase of the 12.6MHz clock while VGA controller has access at low clock phase.

The schematic is drawn in Altera Quartus tool. The top half of the schematic is similar to Chad's design where horizontal sync and vertical sync are formed from cascaded divided-by-800 and divided-by-525 counters. The bottom half is new, consists of a bank register that selects which one of the 32 banks will be accessed when write to memory window $C000-$CFFF; and a data multiplexer that presents high nibble of data to the video display at high phase of 12.6MHz clock and low nibble at low phase of 12.6MHz clock. The display format is 512x480 with 3 bits representing RGB colors.

The reason the video RAM is accessed via a 4K windows is because 512x480 3-bit data takes 122K bytes of memory. It will consume twice W65C02's available memory space if the entire video RAM is directly accessible like Apple II. So a 4K graphic window is a reasonable solution. The graphic data byte is packed so upper nibble data 7 to data 5 represent red, green, blue values of one pixel and lower nibble data 3 to data 1 are RGB value of next pixel. There is one more bit available, but I'm not sure what to do with it. It can possibly serve as 50% intensity control.

The design is simple to implement, just a fast (25nS) 128KB RAM and a modest CPLD, EPM7128S. The design needs significant number of I/O pins that's why CPLD in 100-pin QFP is needed. It plugs into a RC6502 backplane controlled by a 6502 SBC.

Topics I want to explore with this hardware are:
* Combined text-based VGA with graphic VGA
* More color depth, e.g., 3-bit red, 3-bit green, and 2-bit blue
* Reduced resolution, e.g., 320x240 for faster screen repaint.
* How to add sprites.
Bill

If the RC6502 backplane runs at a different (presumably slower) clock, how do you manage that? (Sorry, no chance to look at your schematic yet.)

Hmmm, I don't think RC6502 has a defined clock frequency. I know experimentally it can not run at 29.5MHz, but 22MHz is certainly do-able. My nominal frequency for RC6502 is 14.7MHz.
Bill

Oh, I see - the video card sits in the backplane, as does a 6502 CPU card, everything runs at 12.6MHz, and all should be well. (Except, do you also have peripheral chips which need to run at that speed? Perhaps your design uses RDY?)

This is a picture of my setup right now (I moved the 6502 SBC to the foreground to get a clear picture). As you may know, the so-called RC6502 is just RC2014 with few signals redefined, so the backplane is a 5-slot RC2014 backplane. The on-board 14.7MHz oscillator of the 6502 SBC is removed and instead powered by the 12.6MHz clock from the graphic board.

I don't have many other RC6502 boards, a text-based VGA card, a quad serial board, and a display board. They all run fast enough not to need RDY signal up to 22MHz. This particular graphic card also does not use RDY signal.
Bill

Oh that's great - full speed ahead!

Damn the torpedoes!

Charming! Just like a little family.

And for their portrait they posed the tall folk in the back row!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Haha, y'all are funny

Bill, I love this idea! Let me get it straight and see if I'm seeing it correctly:

You have 32 different banks of 4K RAM. To choose what bank, you write to $EEA8 to $EEAB. For data within that 4K bank you write to $C000 to $CFFF. Each byte is broken down into 2 nibbles which is the color data for 2 pixels, sorted by using some glue logic and those flip-flops. Correct?

Your horizontal size is only 512 out of the 640. Are you planning on panning it a bit to center it? If so, would you be using the preset feature on the '161, or some other method? If it's already in the schematic then I guess I overlooked it.

Doing the math, would each RAM bank be 16 lines essentially? 4096 bytes in each bank / 512 bytes per line * 2 pixels per byte = 16 lines.

Sprites would be super awesome! There is so much that goes into that, lots of math. At the same time, I want to say that one reason sprites were used back in the day was because of limited RAM. Just like text based systems, if you only have to store smaller images in RAM, and then just recall those on the fly, you would not be using as much memory. Of course, it is also good for changing positions and frames of the sprite, if the hardware is set up for that.

One thing to think about, however unconventional it may be, is layering. I don't know it's specific name, something similar to "frame buffer" (can't remember), but in a way it's like sprites, but bigger. In many 2D games that want to show something that looks real, even in NES Mario games, you have the foreground, the character/enemy layer, and the background, and various other layers in between. I've both used and created my own game engines, and for 2D games this is very important. Also important, a way to turn transparency on or off, though you can often do this with just 0/0/0 black (if you have enough colors to go around and can create a "black" without it actually be full 0/0/0 black). Not sure if you are wanting to go that far or not. I certainly cannot! Just some input from a video game programmer

I really like the idea of using the high/low clock to read and write data to the RAM. That allows you to write to the video RAM at any time without interrupt or checks or shift registers. Very cool. I also like the idea of banking the RAM as you did. Since my boards are being printed, and I can no longer change anything (that's a good thing!), I've already been thinking of the next VGA project using a similar design to what you have here.

Looks great Bill, good job! Thanks for inspiring me!

Chad

Chad,
You are correct that each 4K windows will draw 16 lines on the screen. I have not centered the image, yet. I just want to make it work first without muddying the water.

Attached is an animated GIF of three test patterns. I can write the video image anytime, but it still takes a while to fill 128KB of image with 12.6MHz 6502, about 1/2 second per pattern. This is where smaller sprites can produce smooth moving picture.

I'm also looking into the "snowing" effect as the images are updated. I believe the correct image is written into RAM and there are no conflict with VGA controller's read access, but I'm dealing with an analog system so digital noises can cause the snowing effect. This is where 4-layer PC board with separate analog section may be necessary to get best image.

Sprites, layering, mixing text & image, I predict I'll be spending lots of time playing with the video card.
Bill

I continue to work on Apple II style of multiplexing video access with 6502 access. This is the pc board version of the prototype board with additional text-to-VGA dual-port RAM (not populated in the picture) and PS2 keyboard connector. I use a larger-than-normal CPLD, EPM7192S, to give me more room for experimentation. I believe I can overlay text over graphic background, but I'm also thinking about using the dual-port RAM as buffer for sprites that overlay the graphic background. The connector at bottom is for RC6502 bus and designed to interface with CRC65 SBC. In this configuration CRC65 is operating at 25.175/2=12.6MHz. The graphic memory is 128K with 512x480 display area. The color depth is limited to RGB plus 50% intensity bit.

Good thing about multiplexing video access with 6502 access is the graphic RAM can be access any time at full 12.6MHz speed. Below is a video of CRC65 @ 12.6MHz writing test patterns to 64KB out of 128KB of graphic memory. I want half of the graphic display stay in blue background while writing, as fast as possible, other half with test patterns to look for "snow effect". I'm happy to report that there is no "snow effect".
Bill

I see a lot of interesting development on the graphic display area so I want to refresh my memory on my implementation which is 640x480 RGBI. Attached is schematic of the board; instead of adding intensity, my approach was to take away intensity with 3 Schottky diodes. The top half of the attached photo is the 16 colors except the "light black" is indistinguishable from "black". The bottom half is data file from sburrow's Finch file "demo-sixteen.asm".

What I need is a program to convert 640x480 picture to hex file that I can load into memory.
Bill

I use python for that, I could send an example if it helps? I've also used gimp to do the colour depth reduction to custom palettes. Python Imaging Library's palette handling can be temperamental.

Yes, I would like to see your Python example. I know there are online image converter as well. I can also tweak the CPLD design to be compatible with the image conversion output.
Bill

The glitch on the left can be fixed by referencing a 1 cycle delayed copy of the pixel clock during the active display area.