From another picture at Andrew's site, he had connected GND and +5V of a chip to one of the capacitors between the sheets.
BTW: nice Dilbert cartoon !

After I did an internet search, it appears that the trick of using sheet metal in the power supply isn't new:



...the interesting question when using sheet metal is, how to pull chips out of their sockets later if neccessary
without resorting to special tools.

Would say, that two pieces of sheet metal connected to GND and +5V running in parallel might form up a neat high frequency capacitor.

Placing Teflon foil between two metal sheets probably won't be a good idea, because wikipedia mentions
that pyrolysis of PTFE is detectable at 200°C, and our soldering iron would have around 350°C.

Hmm... now this somehow reminds me a little bit to the pictures from that 'LDS prototyping'
marketing brochure at the LPKF homepage.

Printing PCB traces with a Laser and some fancy chemicals:
http://www.lpkf.com/_mediafiles/3435-brochure-lpkf-lds-prototyping-en.pdf

I was not speaking of wire diameter, just the number of GND / VCC connection points.

By having a set of solderable GND / VCC rails cross every IC in both the X and Y direction, I will void all potential ground loop problems.

I can't see this being any less effective than a real 4 layer PCB with inner VCC and GND planes.

I found a 12x12 piece of 1.6mm lexan, and will probably make a simple test board to see how it goes together.

Brad

_________________
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?

This is why a multi-layer PCB with internal power and ground planes is the ideal for high speed digital work. Of all the things that could go wrong with my POC units, poor signal quality, ground bounce and instability were not a concern. Building on a four-layer PCB was key. I also was meticulous about bypassing every device on the board, other than reset generators.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ok clear and thanks for the clarification. I follow this thread only every now and then. I have started a simpler project (here), but because I don't want to use any CPU, not even our beloved 6502, I think I shouldn't post about it here. (The other reason is that this forum bans my office's IP address, I have no idea why, and that is annoying). My project got derailed when I stumbled upon the Vulcan and Brad's earlier VGA hack. So now I will aim for VGA output instead of the 8x8 color LED matrix I originally planned for to play tic-tac-toe on...

I have used the '163 in my own VGA concept testers (described on he same site linked above, look for my other projects there) specifically for the synchronised reset. If you hook up the /CLR to ENP, you basically have created a single command line for synchronised "count up or go back to 0". I now realize you use them differently.

In fact I like the idea of using counters as registers and it got me thinking. I now might want to use them as my accumulator, if only to get a free "AC == -1" test, so after "AC + NOT BUS" I can use RCO as an AC==BUS equality input to the "compare" instruction that is still missing in my current design...

_________________
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?

Where are you located?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Or, perhaps someone was sitting outside in their car, logged into an unsecured wireless router in his office. I've run into that now and then.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It has been a busy month, but I did get a day to work on the board last week.

Since the new Sync Generator is fully software programmable, I decided to experiment with different video modes.
At 640x480, these are somewhat limited, since it is only the vertical resolution that can be altered.
So, at 25MHz, 640x480 or 640x240 are really the only options, but that aspect ratio is not much good.

I have also been battling some serious capacitance issues with my clock routing at this speed.
So much so that, I had to "tune" some of the clock lines using a variable resistor!
A non-breadboard layout would certainly work later on, but these glitches will make testing very difficult.

During my latest experimentation, I went back to 20MHz, and revisited the 800x600 VGA mode.
At 20MHz, the horizontal resolution is fixed to 400, but there are decent vertical options available.
The system can now do 400x600 (default mode), 400x300, or even 400x200.
Actually, the vertical can be divided to any number whatsoever.

Just like the Amiga, multiple modes can be delivered on one screen.
A demo may have a 400x600 title at the top, but then do fast graphics at 400x300 in the center screen.

At 400x600 with 4096 colors, the images looks as good as 640x480, but there are no clock speed issues at all.
Seems that 20MHz is the "safe" zone for my giant breadboard, with 25Mhz being right at the razor's edge!

During my testing, I had to rewire most of the address lines, and alter a lot of once tidy wiring...


This is what it looks like before I clean up the wires.

So now I am working out the details on the new Graphics Generator, which will command 4 MB x 16 Bits of fast SRAM.
This will be my most complex version yet, and I am hoping for 10 MHz or better performance. (I had 4 MHz last time).

Having such limited time, it is easy to forget what the hell I was doing, so I have started making schematics.
Here is the VGA Output Stage, which is just a simple circuit that aligns everything on the Master Clock...


VGA Output Stage.

VBUS : 12 Bit Video Data Bus
CKM : Master Clock (20MHz)
BK : Blanking Signal
HS : Horizontal Sync
VS : Vertical Sync

I originally used 74HC08 AND gates to sync the data to the clock, but I was bullied into trying 163 counters instead.
... and whadda ya know, it saved one extra chip! Kudos Jeff!

I will drill downward on the other parts of the schematic and post them when I have the time.
The Graphics Generator is only in "I think it will work" stage, so it will be wired up soon.

Notice all of the SRAM taking up the right side of the board. 16 chips in total (512K x 8).
At 400x300 resolution, a bitmap could be 34 screens in size! That's a HUGE scrolling background.
This memory will contain all Sprites as well as Background Images, but it's still a lot of room to work.

I have also come up with a proposed Cartridge Loading System, which will use a clocked 8 Bit input system.
Loading of the first 64K segment will happen automatically on startup, and then the 6502 will do the rest.
Once the 6502 Boot Program is loaded, the CPU can then access over 4 gigs of storage space.
Yeah... I am including a 32 bit address system to the cartridge!

Just think of the crazy power I am handing out to the 6502 now...

- 400 x 600 VGA with 4096 simultaneous Colors
- 4 MB of ultra high speed Graphics / Sprite Memory
- High speed "transparent aware" Blitter System
- 4 Voice digital stereo sample Sound System
- 4 Gigabyte capable external Cartridge Loader
- Super Nintendo compatible dual Joystick Ports

It's kind of like dropping a Model-T Ford engine into a Testarossa, but the 6502 deserves it!

Cheers!
Radical Brad

I was contemplating the video DAC stage as well. I have a similar design in my project and I'm pretty sure I learnt about it from your Quark-85. There is something nagging me: the resistor network feeds directly into the VGA plug. Doesn't this mean that the resulting voltage levels depend on the monitor characteristics? Or are these standardised in some way?

If I unplug the monitor, my signals jump into the Vcc range. If I plug-in the monitor, they drop to sub-1V, where the should be. It feels uncontrolled to me, and I was wondering if the right way to go about this is to insert op-amps. (As in, for example, your audio DAC)

Am I missing something and worry about something irrelevant? (My project uses 74LS, so that might be different as well.)

PS: I apologise if this has been addressed in the past. The thread is so long...

VGA has a 75 Ohm termination resistor on each of the R,G and B inputs inside the monitor as standard. Plenty of commercial FPGA boards get away with a simple resistor DAC with no adverse effects so I think you're fairly safe.
Technically, to comply with the spec, the R,G and B lines should have 75 Ohm termination at both ends, monitor and your board. You could use op-amps to drive properly (both ends) terminated lines but in general, for a hobby project, I don't see the need.

How many colors do you want, and what is your voltage?
I will post 2 different DAC versions you can use... R2R and Ladder.

Thanks,
Brad

I have 64 color RRGGBB at the moment. Experimentally I have arrived at 330 Ohm + 680 Ohm combos, but in one circuit this gives an 800mV signal, while in another it is 700mV. I might go one step up on the E12 ladder to 390 Ohm and 820 Ohm. It also depends on the actual voltage the last chip gives. For 74LS this should be around 3.5V.

More importantly, now that I understand what happens in the monitor with the terminating resistor, I have more confidence an opamp stage will not be necessary.

Wow, half a year can slide away like nothing when you live the homesteading lifestyle.
Cutting and stacking wood for the impending deep freeze has taken all of my lab time away.

But one day soon I shall remove the dusty cover from my giant circuit board and fire it back up.

When I last worked on the board, I managed to get 400x300 or 400x600 resolution, and had 4MB of graphics memory. Going to 400x600 was a compromise as I could not get the timing to hold up to the 25MHz clock required to drive a 640x480 screen. 400x600 runs at 20MHz as it is half of the clock required to drive 800x600. That last 5MHz was too much for a breadboard design.

What??!?!?
I hate to loose.

I have decided to try again for 640x480 native resolution at 25.175MHz, and plan to start completely over.
Having time to think while doing yard work made me realize I gave up, and that just ain't me!

So I have decided that I will have 640x480 resolution, and it will be done with a 4096 color palette.
The new reboot will also have 8MB of graphics available to account of the increase in screen size.

I understand that the foes that beat me last time will still be present... Mr. Propagation and Sir Capacitance.
In this iteration of the design, I am going to use a fully asynchronous design, and control all pathways.
All of the 74HC574 buffers will be removed so that all bits just travel from one end of the board to the other freely.

Now, you might think this would be akin to removing all traffic lights in the middle of New York during rush hour, and then expecting something other than total chaos, but I do have a plan.

By controlling the propagation through all pathways using the same ICs, I can expect bits that need to arrive synchronously to do so with great accuracy. So rather than using my current 5 level bucket brigade register approach, I will allow there to be 4 signals on the line at all times, but have them all arrive at the same time by knowing the propagation delays through each IC.

An example would of this the arrival of 12 color data bits to the blanking mixer (74HC08 AND Gates x 12) along with the actual blanking signal. The color bits are clocked from SRAM, and then through the dual buffer switch, so their path looks like this...

74HC163 : 16ns
74HC245 : 10ns
74HC08 : 8ns
Total Trip : 34ns

The blanking signal is sent from a different SRAM (SyncMem), and its path looks like this...

74HC245 : 10ns
74HC163 : 16ns
74HC08 : 8ns
Total Trip : 34ns

The initial 74HC245 is added to the clock line driving the counter to force another 10ns of delay to the path, making it exactly equal to the path of the color bits so that the blanking signal and the color bits enter the AND gates at precisely the same time to avoid any thin of fat pixels at the start and end of the frame.

Yes, an error of 1ns is very visible on the monitor!
Since I am using all of the same exact date coded and manufacturer number parts on all similar gate ICs, this should work.

So now instead of 5 traffic lights all controlled by the master clock, it's just a free for all.
The key factor being that everyone is driving the same model car and doing the same distance and speed.

As a "just in case" option, I have devised an adjustable delay line using 245 buffers that I can tap at the very end of the line if I need to re-synch the signals and then clock them through a final 574 register. Hopefully, this won't be necessary.

My design is only on paper at this point, and I have a lot more yard work to deal with this year.
Just wanted to drop by and proclaim that this project is far from dead.

See y'all when the snow flies!

Cheers,
Radical Brad