(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.
Video output?
Re: A very basic question...
greener wrote:
I had the thought that I'd solder everything together, but that'll be a mess.
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.
Re: Some lunch-time responses...
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.
No I won't! My next generation design splits responsibilities between two PIC chips - one of which should be able to interface with the bus directly. I had a revelation a couple of weeks ago when I realized that I would probably need another support chip between my 65c02 and the PIC that handles the serial communication... plus I'm not familiar enough with any of the serial protocols to handle bit-banging. As an after-thought, having multiple sources of interrupts on one microcontroller could be confusing as well as mess up timing should that prove to be critical. Hopefully, by separating my interrupt sources (video from CPU interfacing), I don't have this issue anymore.
Quote:
Quote:
I know you're gonna hate me for this greener - but I would look for another PIC with more pins and keep it parallel rather then serial for graphics.
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.
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
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
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
> 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
Code: Select all
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: www.baltissen.org
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?
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.
> ... 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.
Code: Select all
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: www.baltissen.org
henrik51 wrote:
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.
Quote:
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?
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