OK. I've been bitten by the video bug. I've spent some time learning about the NTSC composite video signal and have discovered its no all that complicated. I've taken some hints from a few PIC programmers and have come up with a basic D-A circuit that is driven completely by software. All you'll need is a 65C02 running at 2.0MHz and two I/O lines on a 65C22 or compatible device. My display will NOT generate text, it just gives 24 vertical bars alternating between grey, white, and black. But, it does give a basic example of what it takes to build a working video signal generator.
With some further refinements and more hardware, it should be relatively simple to build a basic 40x24 display. Who knows, maybe even with color!
Check it out under the I/O Devices tab on my web site.
Daryl
http://65c02.tripod.com/
Video output?
what you need is few simple counters and piece of eprom to store characters
there are two technics for video, or rather DMA transfers of video buffer
first thing first
if you have system with HALTor BE line (atari 6502i, wdc w65c02 and others cmos devices) it will be simpler to do cycle stealing method
gpu is telling processor to get out of line, and overtakes the bus
second option is to run gpu in paralel with cpu - this is done by feeding phase 1 output from cpu to gpu clk, but you will need special circuity to write anything to gpu registers
anyhow..
gpu:
assume that you have to display 40 chars, 8 lines width, and you using PAL (sorry i'm not that familair with ntsc, but still all of information apply)
so your pal display is 25fps, 768x626 interlaced, or 768x313 on 50hz - that was used as base for 8bit machines
frame frequency will be 50hz, line frequency 15.625khz
you need to display 40*8 pixels per line, and probably want them all to be visible without any modification to tv - you have to add border 40 pixel each side should be sufficient
now you have 400 pixels per line and have to divide your 64us by 400
this is your pixel clock, and probably system clock
your vertical resolution is 192 (24*8) lines, your display resolution is 312 lines - so you need another border...
basic idea:
new frame:
start counting
is v_counter=60?
if yes then start displaying data:
displaying data:
get byte from memory
h_counter=40? -> data to shift register, output to video out (1V for white 0.3V for black, 0 for sync, no color burst)
if 8 bits send fetch next byte and send it
this repeats till hcounter=360
when h_counter=400 you put sync signal, and reset counter to 0
as you can see your display will be only b/w and also it will be "graphical"
so you need to put characters as pictures - this may be slow, and time consuming for cpu, but this is simpler to build
basically all video is few counters and nothing more
sory for such chaotic explanations, but.. well..i'm not native english speaker, and i'm doing my best
candle
there are two technics for video, or rather DMA transfers of video buffer
first thing first
if you have system with HALTor BE line (atari 6502i, wdc w65c02 and others cmos devices) it will be simpler to do cycle stealing method
gpu is telling processor to get out of line, and overtakes the bus
second option is to run gpu in paralel with cpu - this is done by feeding phase 1 output from cpu to gpu clk, but you will need special circuity to write anything to gpu registers
anyhow..
gpu:
assume that you have to display 40 chars, 8 lines width, and you using PAL (sorry i'm not that familair with ntsc, but still all of information apply)
so your pal display is 25fps, 768x626 interlaced, or 768x313 on 50hz - that was used as base for 8bit machines
frame frequency will be 50hz, line frequency 15.625khz
you need to display 40*8 pixels per line, and probably want them all to be visible without any modification to tv - you have to add border 40 pixel each side should be sufficient
now you have 400 pixels per line and have to divide your 64us by 400
this is your pixel clock, and probably system clock
your vertical resolution is 192 (24*8) lines, your display resolution is 312 lines - so you need another border...
basic idea:
new frame:
start counting
is v_counter=60?
if yes then start displaying data:
displaying data:
get byte from memory
h_counter=40? -> data to shift register, output to video out (1V for white 0.3V for black, 0 for sync, no color burst)
if 8 bits send fetch next byte and send it
this repeats till hcounter=360
when h_counter=400 you put sync signal, and reset counter to 0
as you can see your display will be only b/w and also it will be "graphical"
so you need to put characters as pictures - this may be slow, and time consuming for cpu, but this is simpler to build
basically all video is few counters and nothing more
sory for such chaotic explanations, but.. well..i'm not native english speaker, and i'm doing my best
candle
Thanks for the overview Candle!
I'm already venturing down that route. I have five 74LS163 Synchronous counters, one 74LS165 shift register, a 28256 EEPROM (with a test image preloaded), and a 14.318MHZ Oscillator.
For those who may be interested, I'll post the circuit details and firmware on my web site when I'm done.
As far as updating the video RAM, I've chosen a method that will gate access to the RAM for the CPU in between the shift register loads (while the shift register is shifting a byte). This will provide a 50% duty cycle for RAM access between the Video controller and CPU with 550nS access for each. During the blanking interval, full access for the CPU is available.
I still have to work out the interface, but hope to have it nailed down soon.
And yes, having a hardware character generation (EPROM) would reduce the CPU demand greatly.
Cheers!
Daryl
I'm already venturing down that route. I have five 74LS163 Synchronous counters, one 74LS165 shift register, a 28256 EEPROM (with a test image preloaded), and a 14.318MHZ Oscillator.
For those who may be interested, I'll post the circuit details and firmware on my web site when I'm done.
As far as updating the video RAM, I've chosen a method that will gate access to the RAM for the CPU in between the shift register loads (while the shift register is shifting a byte). This will provide a 50% duty cycle for RAM access between the Video controller and CPU with 550nS access for each. During the blanking interval, full access for the CPU is available.
I still have to work out the interface, but hope to have it nailed down soon.
And yes, having a hardware character generation (EPROM) would reduce the CPU demand greatly.
Cheers!
Daryl
if i finnnd some time to do serious book digging in the library i'll scan some ready "device" for text mode output - it is from polish book about z80 family, but still basic idea is the same...
only if i hadn't lost my own copy... eh...
and btw - why can't you just use 6545 crt controler? it can be found in many acient, ehem graphics cards for pc - full size 8bit isa most probably... or use mga/cga gfx card instead...
on both you can find 6545 crt controller, but only on oldest it will be as it was designed - 40 pin dip...
best regards
candle
only if i hadn't lost my own copy... eh...
and btw - why can't you just use 6545 crt controler? it can be found in many acient, ehem
graphics cards for pc - full size 8bit isa most probably... or use mga/cga gfx card instead...on both you can find 6545 crt controller, but only on oldest it will be as it was designed - 40 pin dip...
best regards
candle
Before you get too involved you may want to look at:
http://www.speccybob.2y.net/
check on speccybob lite and the video circuit - it may offer some ideas that reduce design time.
Granted it's for an rgb monitor, but converting from rgb to composite is a lot easier then going from nothing to composite
http://www.speccybob.2y.net/
check on speccybob lite and the video circuit - it may offer some ideas that reduce design time.
Granted it's for an rgb monitor, but converting from rgb to composite is a lot easier then going from nothing to composite
candle wrote:
if i finnnd some time to do serious book digging in the library i'll scan some ready "device" for text mode output - it is from polish book about z80 family, but still basic idea is the same...
only if i hadn't lost my own copy... eh...
and btw - why can't you just use 6545 crt controler? it can be found in many acient, ehem graphics cards for pc - full size 8bit isa most probably... or use mga/cga gfx card instead...
on both you can find 6545 crt controller, but only on oldest it will be as it was designed - 40 pin dip...
best regards
candle
only if i hadn't lost my own copy... eh...
and btw - why can't you just use 6545 crt controler? it can be found in many acient, ehem
graphics cards for pc - full size 8bit isa most probably... or use mga/cga gfx card instead...on both you can find 6545 crt controller, but only on oldest it will be as it was designed - 40 pin dip...
best regards
candle
The solution adopted by the Amiga and Atari 8-bit platforms makes a whole lot more sense, where you had simple counters doing the timing generation, and brutally simple DMA for video data fetching. It was so simple, in fact, that the CPU itself (or the Copper list in some models, and definitely in the Amiga) was responsible for resetting the video fetch pointer(s) during vertical sync.
--
Samuel A. Falvo II
Tancor wrote:
Before you get too involved you may want to look at:
http://www.speccybob.2y.net/
check on speccybob lite and the video circuit - it may offer some ideas that reduce design time.
Granted it's for an rgb monitor, but converting from rgb to composite is a lot easier then going from nothing to composite ;)
http://www.speccybob.2y.net/
check on speccybob lite and the video circuit - it may offer some ideas that reduce design time.
Granted it's for an rgb monitor, but converting from rgb to composite is a lot easier then going from nothing to composite ;)
My end result here is to have a simple (i.e. low part count/low cost) interface that acts similar to an LCD display but uses a standard TV. This provides a simple 8 bit interface to a 40x25 character display.
Daryl
http://65c02.tripod.com/
Re: SBC video
TonyR wrote:
Would it be too much to just steal the circuit from an Atari or C64? Schematics are available, and you KNOW the circuit works.
Just an idea....
Tony
Just an idea....
Tony
Also, for me, half the fun of experimenting is finding new ways to do something and then doing it. I've been able to create a 320x200 B&W composite signal with just 6 74LS series IC's, a TTL oscillator, and an EEPROM. This is a static display, but with a few more IC's I can replace the EEPROM with SRAM and have a working video generator.
The next move would be to incorporate the entire circuit, minus RAM and the TTL Oscillator, into a single FPGA IC. You could easily create NTSC and PAL versions along with versions for VGA computer monitors.
Since I've never programmed an FPGA, this will present yet another opportunity for me to learn something new and to apply it to something useful.
However, there are dozens of existing circuits available, as well as newer technology such as LCD displays, for those who just want an end result.
If anyone has any inputs on easily programmable FPGA's, I'd be glad to hear from you. I don't really want to make a major investment in a universal programmer if I can avoid it.
Daryl
-
GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
> If anyone has any inputs on easily programmable FPGA's, I'd be glad to
> hear from you. I don't really want to make a major investment in a
> universal programmer if I can avoid it.
Daryl,
I think you want a CPLD, not an FPGA. Check out Cypress's 37000 family or even their older 370i family. I believe you can still get the whole thing, including the software, the programmer, and their seminar (if you live near one of the cities they occasionally give them in) for about $200. Check out their website www.cypress.com . They definitely offer some good attractions.
Garth
> hear from you. I don't really want to make a major investment in a
> universal programmer if I can avoid it.
Daryl,
I think you want a CPLD, not an FPGA. Check out Cypress's 37000 family or even their older 370i family. I believe you can still get the whole thing, including the software, the programmer, and their seminar (if you live near one of the cities they occasionally give them in) for about $200. Check out their website www.cypress.com . They definitely offer some good attractions.
Garth
GARTHWILSON wrote:
> Daryl,
I think you want a CPLD, not an FPGA. Check out Cypress's 37000 family or even their older 370i family. I believe you can still get the whole thing, including the software, the programmer, and their seminar (if you live near one of the cities they occasionally give them in) for about $200. Check out their website www.cypress.com . They definitely offer some good attractions.
Garth
I think you want a CPLD, not an FPGA. Check out Cypress's 37000 family or even their older 370i family. I believe you can still get the whole thing, including the software, the programmer, and their seminar (if you live near one of the cities they occasionally give them in) for about $200. Check out their website www.cypress.com . They definitely offer some good attractions.
Garth
Daryl
-
GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Well if you want to put the processor in there too, maybe you won't want just a CPLD. The main difference between a CPLD and an FPGA is not just in the number of gates and macrocells, but in how they're interconnected. I guess I've heard of a microprocessor being implemented in a CPLD, but that's stretching things.
If you do get into the HDLs though (like VHDL or Verilog) and start with a free '02 HDL source code, it'd be great if you could take the oportunity to not only fix the NMOS bugs and expand it to do the CMOS op code set, but maybe also implement some new instructions that would be nice. (We did discuss which ones would be nice somewhere else on this forum-- I'll have to do a search.) Then it'd be great if you'd make it public. I don't think I've heard of any free 65c02 ones so far, and definitely no 65816's.
Unless you really want megabytes of RAM, SRAM generally comes much faster than DRAM and has gotten too cheap and dense to turn away for the old reasons.
Garth
If you do get into the HDLs though (like VHDL or Verilog) and start with a free '02 HDL source code, it'd be great if you could take the oportunity to not only fix the NMOS bugs and expand it to do the CMOS op code set, but maybe also implement some new instructions that would be nice. (We did discuss which ones would be nice somewhere else on this forum-- I'll have to do a search.) Then it'd be great if you'd make it public. I don't think I've heard of any free 65c02 ones so far, and definitely no 65816's.
Unless you really want megabytes of RAM, SRAM generally comes much faster than DRAM and has gotten too cheap and dense to turn away for the old reasons.
Garth
For those interested, I've successfully completed the second phase of my project.
I have a 320x200 pixel B&W display working on a breadboard. Its using 15 74 series IC's, one 32kx8 Static RAM, and a 14.318MHz TTL Oscillator. I've also written the basic code to initialize the counters for both NTSC and PAL formats as well as write data to the Video RAM. The PAL version can display 320x240 with no hardware change needed. (I verified it on my older multi-system TV)
Its in graphic mode, needing software to generate the character fonts. I can add an EPROM and two more 74 series IC's and have the a hardware character generator for a 40x25 line display using an 8x8 pixel font. I haven't tested that yet (phase 3). I have a 70ns EPROM and a 15ns Static RAM. I will need to verify they are fast enough to properly display each pixel.
I have both ports of a 65C22 connected to the board. One port is the data port, the other the control port. The write sequence involves checking a busy status bit, writing a High address to the data port, stobing the control bit, writing a low address to the data port, strobing the control bit, and writing the data byte to the data port and strobing its control bit. The byte will be buffered and then written into the RAM in between each shift register load access, so the wait time for the Busy status is no more than 1.2uS per byte.
Phase 3 might also include a combination latch/counter to automatically increment the address to increase data transfer rate.
I'll put some pictures up on my web site soon. My 2nd daughter is due to enter the world on Tuesday, so please be patient if I don't get it done right away!
Daryl
http://65c02.tripod.com/
I have a 320x200 pixel B&W display working on a breadboard. Its using 15 74 series IC's, one 32kx8 Static RAM, and a 14.318MHz TTL Oscillator. I've also written the basic code to initialize the counters for both NTSC and PAL formats as well as write data to the Video RAM. The PAL version can display 320x240 with no hardware change needed. (I verified it on my older multi-system TV)
Its in graphic mode, needing software to generate the character fonts. I can add an EPROM and two more 74 series IC's and have the a hardware character generator for a 40x25 line display using an 8x8 pixel font. I haven't tested that yet (phase 3). I have a 70ns EPROM and a 15ns Static RAM. I will need to verify they are fast enough to properly display each pixel.
I have both ports of a 65C22 connected to the board. One port is the data port, the other the control port. The write sequence involves checking a busy status bit, writing a High address to the data port, stobing the control bit, writing a low address to the data port, strobing the control bit, and writing the data byte to the data port and strobing its control bit. The byte will be buffered and then written into the RAM in between each shift register load access, so the wait time for the Busy status is no more than 1.2uS per byte.
Phase 3 might also include a combination latch/counter to automatically increment the address to increase data transfer rate.
I'll put some pictures up on my web site soon. My 2nd daughter is due to enter the world on Tuesday, so please be patient if I don't get it done right away!
Daryl
http://65c02.tripod.com/
-
Mike Naberezny
- Site Admin
- Posts: 296
- Joined: 30 Aug 2002
- Location: Northern California
- Contact:
65Cxx FPGA Cores
GARTHWILSON wrote:
I don't think I've heard of any free 65c02 ones so far, and definitely no 65816's.
Check out the T65 CPU Core at OpenCores.org:
http://www.opencores.org/projects/t65/
It supports the 65C02 and 65C816 instruction sets but is still in development.
Ruud Baltissen and Gideon Zweijtzer are developing a new 32-bit 65Cxx-like core, the "65GZ032". I haven't seen much information about this one yet, however they do have a working prototype. Here's a picture:
http://commodore-gg.hobby.nl/processor32.htm
Regards,
Mike
- Mike Naberezny (mike@naberezny.com) http://6502.org