(I need to build the
EEPROM programmer, after all, and then add a 6502 to test the video interface. I've only got so
much breadboard space.)

Modern EEPROMs program themselves pretty much like writing to
any other RAM except it takes longer.

Perhaps a mess, but it works great. It's used by ham radio homebrewers, and the technique is called dead-bug, because when you're done, it looks like everything is a dead bug. Dead-bug has a unique advantage: a single, large, flat, contiguous ground plane. E.g., it has nearly ideal shielding properties.

Another possibility is to use what's called Manhatten-style. In this technique, you layout the components on the board, then cut out (e.g., with a Dremel mototool) trenches in the copper. The resulting pattern on the board is you have a lot of copper blocks with little fiberglass "streets" running through it, making the circuit's copper 'traces' look like an aerial view of a big city -- hence the name Manhatten style.

Just some food for thought. Some Google searches should reveal more information.

Hello, I was wondering if anybody has read a book called "Cheap Video Cookbook" and if so would they recommend it as a refrence for designing video ccts?

I know this is a responce to an old message, but a sutible pic would be the PIC18F252, and it has 32k flash, supports SPI ect.

Ok, would someone who's done one of these TTL video circuits post the schematic somewhere and leave it up?

Yes, I know much better displays can be obtained by using PIC chips or other microcontrollers, but I have NEVER understood how people squeeze framing into 6 TTL chips! And all the pages describing such seem to be down or disabled or redone and the old circuits not posted.

I mean, if I was going to start, let's start with the horizontal line. 2 8-bit counters for the front porch, 2 comparitors so we know when we get there. That's four chips. 4 more for sync, 4 more for back porch. Plus, say, a shift register to function as the state machine to run each counter. Plus the demux logic to send the dot clock pulses to the right counter. Plus the logic on the other end to combine the hblank pulses.

Needless to say, this is the WRONG design. But since this thread is full of people saying, "I did it in 15 chips! No, I did it in 6 chips! No, I did it with two resistors and a hair from my head!", I figured I'd ask. I followed all of the links, and everyone seems to have updated their website with, "Since the old design did bad graphics, here's the PIC implementation to make good graphics."

Yes, if I do my own project, I probably WILL use a PIC or something else that can go really fast. Maybe even get sprites and stuff with that method. But just out of personal curiosity, I'd love to see how it REALLY works.

I kept a copy of the Z-80 based video display created by SpeccyBob.

Its broken down into three gif files. For the clock section, I also kept the html file containing a description of the circuits.

I've uploaded them to my old web site.

Here's the link:

http://65c02.tripod.com/z80.html

I studied this circuit in detail and took some ideas from it when I first started experimenting in video. Yes, I moved on to an AVR-based display but this was the best example of standard TTL video generation that I could find.

I hope this helps!

Daryl

Thanx! That's EXACTLY what I was looking for!

See, I'd be really happy if I got a "VGA, Composite, and LCD signals for dummies" page.

Like, "this is the front porch, this is the back porch, and, oh yeah, if you do this and that, you'll have burnt monitor with a side of smoke"

Hallo henrik51,

> Ok, would someone who's done one of these TTL video circuits post the
> schematic somewhere and leave it up?

Maybe this helps a bit as well:
http://home.micros.users.btopenworld.com/zx80/zx80.html
http://www.funet.fi/pub/cbm/schematics/ ... index.html
http://www.funet.fi/pub/cbm/schematics/ ... index.html

_________________

Hmmm, so I've been doing some thinking, and come up with a few questions.

I got some pointers on an earlier project (that I have yet to do anything about), as to how to work with some of the smaller CPLDs. So, I've been toying with the idea of using a CPLD coupled to a 74ACT715 video sync generator.

If the 14MHz dot clock is sent simultaneously to the '715 and to the CPLD, and (from the data sheet) there is about a 15ns delay from clock to HBLANK, then wouldn't there be a problem at the end of the scan line where the counter would increment (to the next scan line), and draw about 15ns of the first pixel of the next scan line before the HBLANK signal cuts it off? Of course, the whole pixel would be drawn the next time around, I'm just thinking about a 'bleed' effect at the end of the lines.

Another question. Looking at the data sheet for the 62256 SRAM (yes, I'd need a bigger one, but I was just experimenting with #s), the fastest it goes is 45ns. While that is fast enough for the 70ns response to a dot clock, it would appear that my best option is to tie OE and CE low during the video output, because tying either of them to the dot clock itself would leave them enabled for only 35ns, not long enough to read the data from the chip. If I do that, is the change from one address to the next clean, or does the output of the SRAM need to be latched to get around any 'jitter' as the new address is selected?

Hallo henrik51,

> ... 62256 SRAM .... the fastest it goes is 45ns.

Find yourself some old PC 486 boards. Most of them have 15, 20 or 25 ns. cacheRAMs onboard. Although smaller the pinout is the same.

_________________

Mmm, good suggestion!

Tho, I was more wondering if my understanding of the timings given was correct.....

In my implementations, I connected the ram output to a shift register. After the last clock, a zero would be shifted to the output. This would have eliminated any 'bleed'. It sounds like you are planning on sending a whole byte per clock, so you may see the bleed effect. Can you affort the memory to fill an extra byte at the end of the line with an all-zero byte?



Again, the use of the shift register took care of the latching. In your case, yes, you'll want to latch the SRAM to allow even dot widths.

In case you didn't know, I had encountered some trouble with the ACT715 in that it would quit counting on its own. I suspected some sort of noise (ground bounce, CMOS-TTL intermixing, etc), but I just wanted to let you know about it.


Good luck!

Daryl