RFC - please dissect my design on a 6502 + VGA

[ThePhysicist]

That's how quick a month goes by....

Being able to copy between both video RAMs in one page refresh seemed to be simple, but as usual everything takes longer. I had to replace the control logic with one more GAL - and naturally if a board is already so messy a small change can have unexpected side consequences - in this case a hunt over several days which wire I accidentally moved. Here is the final schematic:

v07.pdf

(725.49 KiB) Downloaded 84 times

And the source code for the GAL:

Code: Select all

Name     video_control ;
PartNo   00 ;
Date     4/24/2021 ;
Revision 01 ;
Designer Engineer ;
Company  private ;
Assembly None ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN  1  = !CPU_VIDA               ; /*                                 */ 
PIN  2  = !CLK_VIDA               ; /*                                 */ 
PIN  3  = !CPU_VIDB               ; /*                                 */ 
PIN  4  = !CLK_VIDB               ; /*                                 */ 
PIN  5  = !COPY                   ; /*                                 */ 
PIN  6  = !EXT_VIDA               ; /*                                 */ 
PIN  7  = !EXT_VIDB               ; /*                                 */ 
PIN  8  = !spare                  ; /*                                 */ 
PIN  9  = !WR_CPU                 ; /*                                 */ 
PIN 10  = !VIDRAM                 ; /*                                 */ 
PIN 11  = !WR_CLK                 ; /*                                 */ 
PIN 13  = !WR_EXTA                ; /*                                 */ 
PIN 14  = !WR_EXTB                ; /*                                 */ 

/* *************** OUTPUT PINS *********************/
PIN 16  = !COPY_AB                ; /*                                 */ 
PIN 17  = DIR_AB                  ; /*                                 */ 
PIN 18  = !VIDB_cnt               ; /*                                 */ 
PIN 19  = !VIDB_RW                ; /*                                 */ 
PIN 20  = !VIDB_CS                ; /*                                 */ 
PIN 21  = !VIDA_cnt               ; /*                                 */ 
PIN 22  = !VIDA_RW                ; /*                                 */ 
PIN 23  = !VIDA_CS                ; /*                                 */ 

VIDA_CS = !CPU_VIDA 
	 # VIDRAM ;
VIDB_CS = !CPU_VIDB
	 # VIDRAM ;

VIDA_RW = CPU_VIDA & WR_CPU				/* write under CPU control */ 
	 # EXT_VIDA & WR_EXTA 			/* write under external control */ 
        # COPY_AB  & CLK_VIDB & WR_CLK;		/* write if copy enabled */ 

VIDB_RW = CPU_VIDB & WR_CPU
	 # EXT_VIDB & WR_EXTB 
        # COPY_AB  & CLK_VIDA & WR_CLK;

COPY_AB = COPY;

DIR_AB  = !CLK_VIDA;

VIDA_cnt = CLK_VIDA # COPY_AB ;

VIDB_cnt = CLK_VIDB # COPY_AB ;

I think there will be no more feature creep. Next step is creating a board and building this for real.

[ThePhysicist]

Here is a render of the PCB made with KiCAD

now waiting for the PCB to arrive

[BigEd]

Fingers crossed! (A couple of unsolicited observations: I don't see any per-chip bypass caps, and I see several 8-way connectors which might ideally have had a couple of ground wires too.)

[ThePhysicist]

I plan to put the capacitors on the back. Also that's a "Rev 0" that I want to develop further down the road. The corresponding connectors on the computer will need ground wires too, one more thing I need to improve

thanks!

[ThePhysicist]

update time

the board worked out pretty well. I just had forgotten

• there was a difference in wiring between the GALs doing the counting and the GALs responsible for generating the sync signals. I had done that to make the routing easier, but forgotten to update the GALs to match the hardware

• I have 2 bits per color. The LSB needs to be connected to the bigger resistor (creating a smaller voltage drop on the 75 Ohm resistor internally to the monitor), and naturally I had them wired the other way round....

• my board was designed to use a 14dip wide oscillator - and my 25.15 MHz part was half width ....

So after fixing those issues, and upgrading the firmware a bit, I got this:

First row shows the "pure colors" (3 blue, 3 green and 3 red tones), then I have the 64 shades.
The copy process between both RAM chips is not working yet, more debugging needed.... not so bad for my fourth PCB.
But man, I love the tools that you can use nowadays (Kicad and FreeRouting)
BTW - I have 4 more boards, if anyone wants one send me a PM

[ThePhysicist]

copy is now working as well. I must have mixed up the connections between memory chips and and the 74F245 (U38) between them. A small change in the controller GAL fixed that

[Dr Jefyll]

Glad to see the progress. But I can't help remarking... 74F245 ?? The 74F Series is very power-hungry! Maybe that doesn't matter to you. But 74AHCT245 would be worth a try. (Or 74ACT245, but its very fast output transition times may well cause you grief, given the construction techniques I see in the photo.)

-- Jeff

[ThePhysicist]

All the 74F parts are on the red PCB. All the connections happen on slow 500kHz. I wanted to keep all the chips on a single family, and I did not want to fight additional problems due to slow gates. Power was absolutely not my concern here - and now that it's working, I can try slower chips at leisure (everything is socketed).
But actually that's not my main concern. The next step would be to add a character driven screen mode. I thought that the pixel driven approach would be easier, that's why I started with it.

[GARTHWILSON]

At 500kHz, any logic family would work except maybe CD4000 series.

[BigDumbDinosaur]

Dr Jefyll wrote:

But I can't help remarking... 74F245 ?? The 74F Series is very power-hungry!

Also, the 74F family has TTL-compatible outputs, which may or may not work with CMOS devices. Hence Jeff's recommendation of 74AHCT and 74ACT parts. I use 74AC (and some 74ACT) gates in my POC units. V1.2 is stable at 20 MHz, so clearly the 74AC(T) family of parts is more than fast enough. 74AHCT's performance is comparable, but the output transition times are slower, which makes PCB layout a less-critical thing.

[BigDumbDinosaur]

GARTHWILSON wrote:

At 500kHz, any logic family would work except maybe CD4000 series.

...and those might work if the operating voltage is high enough.

[ThePhysicist]

yes, but for both AHCT as well as ACT I did not really find a lot of selection if I limit myself to through-hole chips. My SMD soldering skills are completely untested
Please be aware - the 6502 and all connections are on 500kHz - everything on the VGA circuit is running at 25MHz! So 74LS is probably to slow there.

[BigDumbDinosaur]

ThePhysicist wrote:

My SMD soldering skills are completely untested

As were mine when I built POC V1.0, whose RAM was in an SOJ32 package. I didn't let that stop me—the first one I built worked after I fixed a PCB layout error.

[ThePhysicist]

second problem - without building it first on a breadboard it would never have worked. My first design was a moderate disaster......

[ThePhysicist]

Now that 640x480 graphics are displaying nicely I'm working on getting Text display to work. 640x480 maps to 80x30 screen with a 8x16 font. So my first step was a small program to convert the VGA font from the bdf file into a complete pixel map usable in a ROM (see "create_fontrom.py" in the attached zip file).

The big problem from my perspective was the question how to map 2400 byte of char ram (one byte per character) to the 640x480 pixels on the screen. I came up with a scheme with 3 counters and a register. The register would load at the end of a character line the current address of the 0-2399 counter, so that the next 16 scan lines can start of the correct pointer.

From the already working graph part we take these inputs:

• HSYNC

• VSYNC

• Pixel Clock

• 10 bit X address

• 9 bit Y address

The basic ideas of this scheme are:

• A VSYNC pulse resets all counters and registers, because we are starting a new page

• The lowest 3 bit of the X-Address (B) are fed into a comparator (C). Each character is 8 pixel wide, whenever all bits are 0 we increase the "Char Counter D" (characters in a line) as well as the overall "Ram Address counter E".

• The "Char Counter D" is reset both on VSYNC as well as HSYNC (aka resets both at the start of a new page and at the end of a line).

• The lowest 4 bit of the Y-Address (G) are fed into the "Line Counter H". Whenever The lowest 4 bit of the Y-Address (G) are all set (=0xf), we've reached the last scan line.

• If "Char Counter D" equals 80, and "Line Counter H" equals 15, we have displayed all 16 scan lines of a single line of characters. At that point the "Register L" is loaded with the current value of "Counter Ram Address E".

• "Register L" will also be loaded into "Counter Ram Address E" with each HSYNC pulse at the end of a scan line.

• After a VSYNC signal "Register L" will be 0. After 16 scan lines the register will contain 80, after 32 scan lines it will hold 160, and so on.

• The 8 bit output from "Counter Ram Address E" are combined with the lowest 4 bits from the "Y Address G" to form an 12 bit address in the "Character Rom I". The output from the Rom is loaded at the start of a character into an "8 bit shift register J".

• With each Pixel Clock one bit of the "shift register J" is shifted out and contains the bit information for each pixel on the screen.

I've simulated the whole scheme using Logisim evolution

The actual Logisim circuit is attached in the zip file.