Video output?

keith · Post by **keith** » Mon Jun 16, 2003 11:40 am

http://www.howell1964.freeserve.co.uk/l ... roject.htm

It is pretty much a "system-on-a-chip".
Plug in a TV and a keyboard, type in a BASIC program and away you go.
The BASIC is well tested and has on-line manual.
Pixel and Line-drawing commands already in there.

It does PAL/NTSC video, up to 320x240.
Text or 4-colour graphics.
Software-driven 1-bit beep goes to TV speaker.

The 512K RAM and 256K Flash ROM are not in the FPGA.
The CPU is a real one for now (so that if a problem appears, it isn't due to a VHDL CPU bug) but I think there is room for it to fit.

There are 3 x 8-bit video DACs but if you use 6 or less bits per colour gun then you could use R/2R ladders.

I reckon it is a decent feature list.
Suggestions for new ones are welcome!

8BIT · Post by **8BIT** » Wed Jul 02, 2003 8:52 pm

keith wrote:

http://www.howell1964.freeserve.co.uk/logic/acorn_atom_project.htm

It is pretty much a "system-on-a-chip".
Plug in a TV and a keyboard, type in a BASIC program and away you go.
The BASIC is well tested and has on-line manual.
Pixel and Line-drawing commands already in there.

It does PAL/NTSC video, up to 320x240.
Text or 4-colour graphics.
Software-driven 1-bit beep goes to TV speaker.

The 512K RAM and 256K Flash ROM are not in the FPGA.
The CPU is a real one for now (so that if a problem appears, it isn't due to a VHDL CPU bug) but I think there is room for it to fit.

There are 3 x 8-bit video DACs but if you use 6 or less bits per colour gun then you could use R/2R ladders.

I reckon it is a decent feature list.
Suggestions for new ones are welcome!

Keith,

VERY COOL!!!!!!!!!!

You are where I'd like to be in creating a low parts count SBC packed with features! Purhaps someday I'll get there! Keep up the great work!

Daryl

8BIT · Post by **8BIT** » Wed Jul 02, 2003 8:57 pm

8BIT wrote:

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.
[snip]
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.
[snip]
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

OK. 2nd daughter is here and doing well. I've update my web site with the schematic for my phase 2 circuit. Check it out under the IO DEVICES tab.

Daryl

http://65c02.tripod.com/

kc5tja · Post by **kc5tja** » Mon Jul 21, 2003 2:50 am

GARTHWILSON wrote:

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.

Steamer16 -- http://www.stringtuner.com/myron.plichota/steamer1.htm

Nightmaretony · Post by **Nightmaretony** » Mon Jul 21, 2003 6:02 am

In terms of a video output, I like the TMS34010 which there IS an Apple 2 card made but never released by TI inhouse years ago with it. It would make a very low chip count video system, methinks. The only problem is availability these days, I dont know what it is.

A good example of a game using this chip is Hard Drivin byAtari., or the Mortal Kombat series, from 1-2. Great single color polygon engine or quasi sprite setup.

Does anyone know of what other xchips would be recomemnded for a low chip count video system to a simple RGB output, with standard NTSC frequencies?

8BIT · Post by **8BIT** » Tue Jul 22, 2003 4:41 pm

infoequipt wrote:

I'm looking for a company that will sell 1 or 2 STV5730 (or STV5730A). I've found a couple of places using www.findchips.com but neither has responded to my RFQ or they advertise a minimum quantity that is far higher than what I need.

If you know of an outfit that sells this chip, please let me know at doug@infoequipt.com.

If you're interested in getting ahold of one of these, maybe we should take up a collection any buy a few!

I ran across this site this morning while looking for an ethernet interface. They sell the STV5730A for $12. Check them out.
http://www.edtp.com/ (go to the bottom of the page)

Daryl
http://65c02.tripod.com/

vbriel · Post by **vbriel** » Wed Aug 27, 2003 9:15 pm

For those that read the Apple 1 replica post and anybody who is interested in the schematics, here is the layout of the 3 chip video.

http://home.comcast.net/~vbriel/video.jpg

40 X 24 scrolling text only, no graphics, screen clears, or X,Y character placement. Still overall it's nice to use a monitor vs. a pc or terminal screen.

If you are interested in this design, the programmed ATMEGA8's will run $25 and if there is interest I will run a set of boards just for the video.

greener · Post by **greener** » Tue Sep 30, 2003 6:10 pm

Hi!

I've been snooping this forum for quite a bit. I'm a software guy who'd like to understand hardware better than I do - that leads to the obvious conclusion of designing and creating my own small computer, right?

Per the topic, I've been playing with a PIC16F252 to generate RGB output. As has been stated elsewhere in the forum, it's a digital signal and, just "makes more sense" to me.

Because of limitations in my approach (software is too slow as well as the PIC chips do not contain enough memory), I'll be limited to something like 64x64 and 16 colors until I grok a hardware approach. But, this is good enough for now.

The question I have is interfacing the PIC with the 6502 bus. I have enough pins to setup an 8 bit data latch, a chip enable (CE) pin, a R/W pin, as well as a few pins for address decoding (if I need it).

My initial thought was to just poll these pins. The video software is all interrupt-driven, so I didn't want to muck with high and low priority interrupts. The more I think of it, the more I have a hunch that using CE as an interrupt pin is the only workable methodology. Any hints for a real neophyte? Yes, it's a stab in the dark, but it's worth an ask.

Where are others in the video department? I've seen Daryl's output and it really looks nice. I didn't understand the hardware - but now that I've workout how the software functions, maybe that will help.

If anyone is interested in my code, I'm willing to make it available. It's of limited use, as it doesn't scale too far. I *do* have fonts, bitmapped images, as well as the conventional plot, horizontal line, and vertical line drawing routines. It's setup for 4MIPS right now (giving me 38x40x16) - I still need to scale it to 10MIPS...
-Rob

GARTHWILSON · Post by **GARTHWILSON** » Tue Sep 30, 2003 7:42 pm

Others on the forum know a lot more about video than I do, but I have plenty of experience with PICs. Their interrupt performance is just miserable compared to that of the 65c02, and having a higher-priority interrupt interrupt the servicing of a lower-priority one on a PIC is a real mess. It should work out better to have the PIC interrupt the 65c02 when it needs to, instead of vice-versa.

The 65c22 has lots of features you can take advantage of for your interfacing. Although it's definitely not the perfect last word on general interfacing, it does live up to its name, versatile interface adapter, or VIA. If you use one of the microcontrollers like the 65134 or 65265, you'll have more. They have interface buses that would allow you to even use them as smart peripherals with their own processor.

I can tell you from lots of code comparisons that 4 MIPS on the PIC is approximately the equivalent of only 2MIPS on the 65c02, which requires about 8MHz, or about half of what the currently manufactured parts will do. There's an even greater difference when it comes to interrupt response.

You could also synthesize a bus with the PIC to access more memory. Since you don't have nearly 30 spare pins on it, you'll need some other support ICs, whether parallel latches, shift registers, or whatever.

8BIT · Post by **8BIT** » Wed Oct 01, 2003 3:18 pm

greener wrote:

Because of limitations in my approach (software is too slow as well as the PIC chips do not contain enough memory), I'll be limited to something like 64x64 and 16 colors until I grok a hardware approach.

That's the problem I'm having too. trying to find a simple microcontroller with enough RAM. For a 320x200 display, you need 8000 bytes for B&W, and 24000 for RGB color. If you keep it as a text only display, then you need 1000 bytes for character ram (40x25) and another 1024 bytes for the font (8x128). For color characters, you'll need another 1000 bytes. Also, if you intend to shift the bits from within the microcontroller, you'll need to be able to fetch the data byte and shift it at 7-8MHz, and monitor counters, requiring fast processing speed. Doing it externally would save in the speed department, but add to hardware complexity.

So far, the ATMEL ATMega162 looks the most promising. It has 1k of SRAM and 16k Flash. Font data can be stored on the FLASH. It also has enough I/O to allow external shifting and host PC I/O.

Quote:

Where are others in the video department? I've seen Daryl's output and it really looks nice. I didn't understand the hardware - but now that I've workout how the software functions, maybe that will help.

The hardware is actually not too hard. The heart of the system is 74ACT715. It provides all the timing to generate the sync pulses and also generates two signals, called Hgate & Vgate. You use hgate to enable a single line of video. Vgate is used to start/stop the display of horizontal lines.

Code: Select all

    _____________
___|             |___   Hgate

---------------------
|   _____________   |     |_
|  |             |  |       |
|  |             |  |       |  Vgate
|  |             |  |       |
|  |_____________|  |      _|
|                   |     |
---------------------

In a nutshell, vgate clears the counters and hgate is used to enable the counters. The counters step through RAM sequentially, providing the necessary dot data to the shift register. The hardest part was enabling a way to update the RAM from the host in between the necessary access to keep the shift register moving dots.

The my biggest hurdle is trying to reduce the chip count while adding features such as auto incremental addressing to speed RAM updates and color support.

Daryl

kc5tja · Post by **kc5tja** » Wed Oct 01, 2003 5:02 pm

8BIT wrote:

For a 320x200 display, you need 8000 bytes for B&W, and 24000 for RGB color.

If you're willing to make a subtle compromise, you can stick with 65536 colors and get away with 16000 bytes. For 99% of the applications you might want to run, it'll look the same.

Quote:

So far, the ATMEL ATMega162 looks the most promising. It has 1k of SRAM and 16k Flash. Font data can be stored on the FLASH. It also has enough I/O to allow external shifting and host PC I/O.

Folks, don't forget that powerful bit- or nybble-serial interfaces can be made too. For bit-serial devices, you can use a VIA's serial port with a very high baud rate. True, obviously parallel is better, but the lack of direct access to the video RAM can be exploited to your benefit by transferring medium-level to high-level graphics commands instead of raw bitmaps. You basically get a graphics coprocessor for free.

Even if you don't have the resources to support a complete set of high-level commands, you can get by quite nicely with a set of medium-level commands. For example, you can implement Bresenham's run-slice line drawing algorithm in software, and the actual mechanism to draw the lines in the coprocessor. A single byte to the graphics controller can not only draw up to 64 contiguous pixels in whatever color you want, it can optionally advance the Y-coordinate up or down as needed for the next slice. Statistically, the worst-case line you'll ever draw will be a diagonal, 45-degree inclined line, where the number of bytes sent to the controller will be equal to the number of pixels wide or high of the line. For all other lines, the number of bytes sent to the controller is guaranteed to be less than its major dimension.

The run-slice command would look like this:

Code: Select all

  Bit 7-6: Command bits
    00: Other commands
    01: After drawing the slice, advance the minor axis coordinate by 1.
    10: After drawing the slice, retard the minor axis coordinate by 1.
    11: After drawing the slice, do nothing.
  Bits 5-0: Number of pixels in vertical or horizontal slice.  0=64 pixels.

Obviously, the controller would need to know in advance whether horizontal or vertical slices are needed, and another set of commands would need to be sent to set the initial (x,y) coordinate, drawing color, and line pattern, if any. Some hypothetical examples:

Code: Select all

Set pen's X coordinate:
  CMD XL XH

Set pen's Y coordinate:
  CMD YL YH

Set pen's foreground or background color:
  CMD ColorL ColorH (or ColorR ColorG ColorB if needed)

Set pen's line pattern:
  CMD PatternL PatternH

Set pen's transparency mode:
  CMD

If you're thrifty enough, you could even get it to support sprites in a higher-level than most video subsystems do. So even though the bandwidth between the video system and the main CPU is restricted, you might still end up with a net performance gain due to the parallel processing that results (e.g., while the graphics processor is drawing the current slice, the 6502 is likely to have already figured out how long the next slice will be).

Quote:

The hardware is actually not too hard. The heart of the system is 74ACT715.

Even then, that chip can be replaced with custom counter arrangements and such. It looks complicated because there are so many chips you have to deal with. But the circuit concept is actually very, very simple. The 74ACT715 just replaces a lot of chips with a single chip.

Quote:

In a nutshell, vgate clears the counters and hgate is used to enable the counters. The counters step through RAM sequentially, providing the necessary dot data to the shift register. The hardest part was enabling a way to update the RAM from the host in between the necessary access to keep the shift register moving dots.

Another advantage of taking the frame buffer off-line from the CPU: this problem disappears entirely, enabling the CPU to run at full speed, all the time, everytime.

--
Samuel A. Falvo II

nelson · Post by **nelson** » Sat Oct 04, 2003 8:52 pm

Daryl,

This is just out of curiosity, since I am really not an expert on electronics design (though I am really interested in starting with one of your SBCs).

You said:

Quote:

The hardest part was enabling a way to update the RAM from the host in between the necessary access to keep the shift register moving dots

Wouldn't it be easy to just use a DUAL-PORT RAM for your video RAM? I mean, since you would be only writing to one port, you really wouldn't care too much about the timing issues.

Or maybe it is too expensive or the chip is too large?

Nelson

candle · Post by **candle** » Sat Oct 04, 2003 11:35 pm

kc5tja: wouldn't it be easier to implement whole brasenham algoritm in such coprocessor? there are better algoritms also...

anyway.. dual port ram is answer to evry problem with this
video controllero working on phase 1 instead of phase 2 would also save the day. in most 8bit computers (if not in all) this was realized by simplier techniqe called cycle stealing (procesor was halted when video controller accessed memory) it enables smooth graphics, but limits cpu time
other possibility is that cpu halts video controller (as in cga) but this leads to jitter cuts when cpu accesses part of memory which is currently drawn

anyway

AFTER 3 page long discussion have you came up with something?

kc5tja · Post by **kc5tja** » Sun Oct 05, 2003 12:33 am

candle wrote:

kc5tja: wouldn't it be easier to implement whole brasenham algoritm in such coprocessor? there are better algoritms also...

Such as? Bresenham's line-slice algorithm is about as fast as things get.

Remember that the goal is to strike a balance between speed and cost. The more the coprocessor has to do, the more expensive it is to support the coprocessor.

Quote:

video controllero working on phase 1 instead of phase 2 would also save the day.

For monochrome work, remember too that the video processor need fetch memory from RAM only once every eight dot-clock cycles. This leaves 7 dot-clocks worth of time to let the 6502/65816 access video memory. For four-color work, it'd need to fetch data from memory twice as fast (once per four clocks), etc.

If more time for the CPU is needed, you can widen the graphics memory to 16- or 32-bits.

Quote:

in most 8bit computers (if not in all) this was realized by simplier techniqe called cycle stealing (procesor was halted when video controller accessed memory) it enables smooth graphics, but limits cpu time

This was used primarily in the 16-bit home computers. Most 8-bits used the phase1/phase2 multiplexing technique. Interestingly, the Commodore 64 used *both* techniques. Most video modes were able to fetch enough graphics data without having to halt the microprocessor. However, the VIC-II chip would halt the 6510A while fetching sprite data, or to cache the next line of text in the character map (it fetched character font information at full bandwidth; hence, the CPU would be slowed only on those lines that contained sprites, or on every eighth video line).

Still, the RDY line does exist on the 6502 for a reason, and it's precisely this application (e.g., asynchronous device access) they had in mind when designing that into the bus. Ph1/Ph2 multiplexing works well with relatively low clock speeds; as soon as you start splitting buses, or start driving the CPU at faster rates, it becomes a major pain in the rear (especially if the slave device's clock is not synchronized with the CPU's). RDY is the only viable solution for this problem.

Quote:

anyway

AFTER 3 page long discussion have you came up with something?

No, because it's not something one generally has the resources to implement easily in discrete components. With programmable logic, things become somewhat easier. However, programmable logic is not hacker friendly -- lots of surface mount components, many with 80 or more pins to solder, and tiny pins at that. PCB routing becomes a major issue then as well, as it's difficult to route an 80-pins worth of signals on a 2-layer board.

I'd wager it's even a challenge on a 4-layer board.

Still, I enjoy the discussion.

Unless YOU have a better idea...

--
Samuel A. Falvo II

candle · Post by **candle** » Sun Oct 05, 2003 12:49 am

well it wont be a breakthrough but i'm thinking on using isa vga card
won't produce tv output - that's true, but surely solves output problem

for low res and tv output i would use dual port ram and aproperiate clock/counters - this is best i can think of now, but - i cant buy dual port ram around here (poland)

we all may reconsider using that vic vic-ii antic/gtia shifter agnus/densie chips 8 and 16bitters used
and - i think it was maxim/dallas ic - i saw video controller with 2mb of address space and capability of overlaying its display with tv/cvbs broadcast
package was discouraging - 100pin tqfp, but everything is for people, so if mortals can solder and unsolder nokia cellphones cpu (BGA) why not to solder such monsters?

and kc5tja - belive me - there is better algo - i've bet once that i bring shoes in my mouth to someone who show me better algo than bransenham - don't make the same mistake i did

for prof you will have to wait - it is 3:00 a.m. around here..

Video output?

Re: Where to purchase STV5730?

Text Video

RGB video

Re: RGB video

Re: RGB video