Video output?

[kc5tja]

candle wrote:

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

If you can still find one that works, that's fine. But now you have to fake an ISA bus.

Quote:

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?

How the heck do you 'solder' a BGA? The only method I've seen is with a toaster oven (for small PC boards) or with larger, pizza-oven-looking-things.

Quote:

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..

Are you confusing Bresenham's line-DRAWING with his line-SLICE algorithm? Though they are related, they are quite different. The slice is many orders of magnitude faster to implement in hardware, and arguably faster to implement in software as well.

Remember, the fastest way to set bits in memory is to just write the desired bit-pattern to memory, and advance to the next memory location. There's no thought involved. Line slicing is only marginally slower than this, especially on displays that use byte-per-pixel or wider layouts. Complex decisions are made only once, before any rendering is performed.

Please read Michael Abrash's book, "Graphics Programming Black Book." I think you'll find it quite helpful in comparing algorithms. If you think you have found a line-drawing algorithm that is faster than line-slicing, I'd sure like to see it. Note: relying on complex hardware like 3-D engines doesn't count! Deep-down inside those engines, at the transistor level, they all rely on Bresenham's algorithms to implement all sorts of effects, including rotation and scaling.

--
Samuel A. Falvo II

[GARTHWILSON]

The following is a little off the video subject, but may help someone anyway.

> 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.

For some of the surface-mount parts, you can get adapters to thru-hole. Aries is one manufacturer of such parts and their prices are far better than Ironwood's. Mouser and Digi-Key carry Aries parts. With these adapters, you can use standard IC sockets in breadboards with holes on a .1" grid. Soldering the SMT part to the adapter is much easier and quicker than you might think. Start by soldering a pin or two or three at each of two opposite corners to keep the IC positioned as you soler the rest. This is the most critical part, where it's important to make sure the pins are centered on the right pads. After that, you can just run down a row of pins with the solder and iron, with no concern for bridges. After all the pins are soldered (and it looks a mess), you hold the board or adapter up vertically and run the soldering iron down a row of pins and the excess solder will come off onto the iron and leave the pins soldered perfectly with no bridges. You don't need a tiny iron that can solder one pin at time, and you don't need ultra-small-diameter solder. Extra flux from a tube wouldn't hurt, but you can do it without it too. It's ok if the soldering iron tip covers three pins at a time. Just be careful not to bend the pins.

The other alternative is PLCCs, which can be put in sockets-- even wire-wrap sockets-- that fit into breadboards with the holes on a .1" grid. I got my McKenzie Berg PLCC wire-wrap sockets from Allied. I think PLCCs commonly go up to 84 pins, and then you're on to other packages for higher pin counts.

> 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.

True, but it can be done. You may need extra room between parts for vias. You can put lots of vias under the parts too. I don't think there are any board manufacturers anymore that charge extra for trace and space widths of .007". That's the smallest I've used, and lets you put at least three traces between pads that are on .100" centers, all on the same layer. Some board houses go quite a bit smaller before they charge extra. I think .012" is probably the tiniest via you can have without extra charges. We use .015" with a .035" pad the very few times we use vias.

Garth

[candle]

using positive mask is very easy to make proper adapters by oneself - especially if you can't buy them (poland) you just need "positiv 20" coated pcb, uv lamp, and laser printer. then goldpin connectors, or precise sockets

kc5tia: this is not very complicated to fake isa bus, you surely know that, and finding isa vga adaptor is matter of minutes - there are tons of such cards lying unused around here and there, all you need is ask around
for BGA's we use 2 step techniqe: firstly put "balls" using injection needles and soldering paste, then place firmly chip and heat up pcb board
hot air soldering stations prices starts from $125 in poland, normal temperature controlled 12V solder stations are from $60 - this is a lot for average mr smith, but still afordable
and i'm not escaping from line algorithm, i just have to dig a bit - this was 5 years ago and since then i didn't use any line algorithms (i'm computer graphics programmer, and most of things i'm having firstly implemented in software, hardware is not so fascinating, and i love optimalizations)
algo i'm speaking about uses shorten setup and one instruction less per loop, not much faster, but faster

[kc5tja]

candle wrote:

kc5tia: this is not very complicated to fake isa bus, you surely know that, and finding isa vga adaptor is matter of minutes - there are tons of such cards lying unused around here and there, all you need is ask around

That's the thing; they might be around "here and there," but there is no consistent source for them. Certainly not a viable solution for a project intended to be taken to production for sale.

Quote:

for BGA's we use 2 step techniqe: firstly put "balls" using injection needles and soldering paste, then place firmly chip and heat up pcb board
hot air soldering stations prices starts from $125 in poland, normal temperature controlled 12V solder stations are from $60 - this is a lot for average mr smith, but still afordable

I can't recall the website, but there is a company that uses this exact technique for soldering *every* SMT device on the card. You take your board's design, and submit it to them so they produce a mask sheet. When you receive the mask sheet, you set it up in a little gizmo that keeps everything nice and registered. Then you smear this solder paste over it, like a screen-printer would smear ink. The idea is the mask causes the solder paste to adhere to the board only where there are solder pads. Then, you place all the surface mount components on the board. The paste helps to keep them in place (though, I'm sure it's still a pretty delicate thing to do). Place the board into a toaster oven that's been preheated to somewhere around 360 degrees (IIRC), and after a few seconds, the board is complete, and all components are soldered.

Quote:

and i'm not escaping from line algorithm, i just have to dig a bit - this was 5 years ago and since then i didn't use any line algorithms (i'm computer graphics programmer, and most of things i'm having firstly implemented in software, hardware is not so fascinating, and i love optimalizations)

Take your time. I'm definitely interested in any algorithm which can promise additional speed, especially if it can be implemented nicely on an integer-only microprocessor.

Quote:

algo i'm speaking about uses shorten setup and one instruction less per loop, not much faster, but faster

That description makes me think of the slice algorithm.

[8BIT]

nelson wrote:

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

I did look into dual-port SRAM. I found it to be too expensive for my hobbyist budget. Upon reading the datasheets, I found that the majority of them had issues concerning simultanious access to the same address. There were semiphor protocols for some and others just let the one of the two ports have priority. Either way, there was a chance that the RAM might not be updated and/or displayed correctly.

In the end, since the video generator only needs access once every uS (roughly), I could just let the CPU have access to RAM in between the Video Gen without creating too many wait conditions.
Daryl

[candle]

i must say i don't see design concept here
what are goals? let go ram access, what you really need from crt controller?
bitmap graphics, fonts? how many colors, what resolution, what scan rates to support?
BUT WHAT YOU REALLY NEED, not what would be nice to have - surely 32bit color (rgba) and genlocking would be nice - especially in 1024x768, but what for?

don't act as old farts blabling around bingo machine

[greener]

Just as an FYI and to keep us on topic...

RGB Phase I: I ran the PIC18LF252 (32K program, 1536 data) to its max as a single chip solution. Because of memory limitations, I got approximately 64 across by 40 down. "Approximately" because there were some timing issues (a skewed upper portion of the screen). However, I couldn't push it beyond 64 horizontal pixels, I didn't chase it.

Interstingly, if the PIC had more memory, I could have run it to approximately 124 pixels across. That is two pixels per byte - or 16 color graphics. (PIC does have a handy SWAPF instruction along with its oddities that makes two pixels in a byte simple.)

RGB Phase II: Use external SRAM to achieve a two chip solution. I have switched to a PIC18LF4220 (4K program, 512 bytes data; 40 pins with 36 being input/output). This chip may not give me enough for an embedded character font, however. On the other hand, I do think this will get to about 240-250 pixels across by 100 down. (Could be 128 down, but that doesn't divide nicely into 400.)

I thought I had my memory tests working, but when I added video code, nothing was functioning. I pulled out the SRAM and am just running a test pattern. It is giving me 240 pixels horizontal resolution! When (If?) I get the external SRAM functional, that should be 240x100x256 colors.

I expect I'll map colors with XYRRGGBB with XY being shared across the colors - somewhat like a palette. I was thinking of XY being the high bits of each color, but will have to experiment to see if that washes out the actual colors.

Question: My experience with op-amps and DACs have been pretty poor. Any suggestions? I tried a R-2R latter - and it worked great! Except that I scaled from 0-2.5volts and RGB needs 0-5v. I tried an op amp and didn't get any further.

That was with an input of 2 lines. I now should have 4 lines - and I'd like to use a DAC if possible. My supply of resistors are just a sample set, so I don't have more than 5 of any size.

I find that I'm a digital guy in an analog world - and I get lost almost immediately!!

Thanks! I do intend to post pictures and code at some point. It may help others get started...

Oh yeah, I've noticed that these chips support I2C, SPI, and USART in hardware. My understanding at this point is that USART will essentially give me a 2-wire serial interface, and that's what I intend to use to drive the system.

[kc5tja]

greener wrote:

RGB Phase I: I ran the PIC18LF252 (32K program, 1536 data) to its max as a single chip solution. Because of memory limitations, I got approximately 64 across by 40 down. "Approximately" because there were some timing issues (a skewed upper portion of the screen). However, I couldn't push it beyond 64 horizontal pixels, I didn't chase it.

Can you give us more details about what it is you're doing here? Are you driving NTSC or VGA display? I'm assuming a VGA, since that is substantially easier to drive.

What clock speed are you driving the PIC at?

Quote:

RGB Phase II: Use external SRAM to achieve a two chip solution. I have switched to a PIC18LF4220 (4K program, 512 bytes data; 40 pins with 36 being input/output). This chip may not give me enough for an embedded character font, however. On the other hand, I do think this will get to about 240-250 pixels across by 100 down. (Could be 128 down, but that doesn't divide nicely into 400.)

In this circuit, does the data in SRAM get read by the PIC, then serialized to the video device, or does the PIC present the SRAM with an address, and the SRAM direct-feeds the video DACs?

Quote:

was functioning. I pulled out the SRAM and am just running a test pattern. It is giving me 240 pixels horizontal resolution! When (If?) I get the external SRAM functional, that should be 240x100x256 colors.

Congrats on the 240 pixel resolution. If you could only get that up to 256, then you can get an even 32 or 40 characters on the screen, and can compete with the TI9918 VDP chip (used in a number of home computers and game consoles back in the 80s -- was pretty well received).

But I'm curious as to why you only have 100 vertical lines? What is preventing you from achieving the full 400? (BTW, VGA monitors display 480 lines vertically, not 400; therefore, might it make more sense to display 120 lines instead of 100?).

Quote:

That was with an input of 2 lines. I now should have 4 lines - and I'd like to use a DAC if possible. My supply of resistors are just a sample set, so I don't have more than 5 of any size.

An input of 2 lines? What two lines? How does it expand to 4 lines? I'm confused.

Quote:

I find that I'm a digital guy in an analog world - and I get lost almost immediately!!

A common problem amongst digital electronics engineers is they lose site of their analog circuit background.

I would recommend the Art of Electronics, by Horowitz and Hill. It's an expensive book, but it's extremely invaluable. It's like two semesters of analog electronics trapped between the covers of a book. Well worth the money.

[GARTHWILSON]

> Question: My experience with op-amps and DACs have been pretty
> poor. Any suggestions? I tried a R-2R latter - and it worked great!
> Except that I scaled from 0-2.5volts and RGB needs 0-5v. I tried an op
> amp and didn't get any further.

What op amps and DACs have you tried, what were the problems, and what speed do you need?

[greener]

kc5tja wrote:

Can you give us more details about what it is you're doing here? Are you driving NTSC or VGA display? I'm assuming a VGA, since that is substantially easier to drive.

Yes, I'm driving a VGA signal.

kc5tja wrote:

What clock speed are you driving the PIC at?

40MHz (actually 10MHz in the PLL mode). On the PIC, that is 10 MIPS.

kc5tja wrote:

In this circuit, does the data in SRAM get read by the PIC, then serialized to the video device, or does the PIC present the SRAM with an address, and the SRAM direct-feeds the video DACs?

The latter. The PIC isn't fast enough to move data around. However, it should be fast enough to increment the memory location. Hopefully that is not a fatal assumption. (I have no training in the field what-so-ever.)

kc5tja wrote:

Congrats on the 240 pixel resolution. If you could only get that up to 256, then you can get an even 32 or 40 characters on the screen, and can compete with the TI9918 VDP chip (used in a number of home computers and game consoles back in the 80s -- was pretty well received).

Thanks! The memory layout would support 256 horizontal pixels, but if I stay honest with the timing, I only get 251 instructions for the display piece. Because of some setup and restore time, that eats into the display time a bit too.

kc5tja wrote:

But I'm curious as to why you only have 100 vertical lines? What is preventing you from achieving the full 400? (BTW, VGA monitors display 480 lines vertically, not 400; therefore, might it make more sense to display 120 lines instead of 100?).

My initial response is that I've just got one 32Kx8 SRAM chip. I'm using the lower 8 bits for the horizontal address and the upper 7 bits for the vertical address. 100 lines simply divides nicely, that's all. I should be able to do 128 vertical - or 256 vertical if I use two chips (or a bigger RAM chip).

I did forget about the 480 vertical. I'll have to check that out! IIRC, the timings change a little bit - but mostly the vertical sync pulse. If so, I think that's a great idea - thanks!

kc5tja wrote:

An input of 2 lines? What two lines? How does it expand to 4 lines? I'm confused.

Sorry about that...

In version one, I had two pixels per byte. That was 4 bits per pixel. I was going to map it as XRGB for the four bits. "X" was going to be a pallette select that applied to all color bits. Thus, the pixels were really XR, XG, and XB. That was the 2 lines of input for red, green, and blue.

In version two, I'm using a full byte. Primarily because I don't know how to swap the byte or bit using hardware. (Well, and the chip count stays at two.) Anyway, I end up with something like XYRRGGBB in the byte. This could map out in a similar fasion - XYRR, XYGG, and XYBB giving 4 bits of color resolution to each color. That's the 4 lines on input for red, green, blue.

kc5tja wrote:

A common problem amongst digital electronics engineers is they lose site of their analog circuit background.

I would recommend the Art of Electronics, by Horowitz and Hill. It's an expensive book, but it's extremely invaluable. It's like two semesters of analog electronics trapped between the covers of a book. Well worth the money.

... or they just don't have any background!

I think I've seen this book, and it's only 1000 pages! In reality, I do need something like this. I'll check it out.

[kc5tja]

greener wrote:

The latter. The PIC isn't fast enough to move data around. However, it should be fast enough to increment the memory location. Hopefully that is not a fatal assumption. (I have no training in the field what-so-ever.)

This technique is used more often than you think. The ever popular 6845 CRTC chip uses the same technique.

Quote:

My initial response is that I've just got one 32Kx8 SRAM chip. I'm using the lower 8 bits for the horizontal address and the upper 7 bits for the vertical address. 100 lines simply divides nicely, that's all. I should be able to do 128 vertical - or 256 vertical if I use two chips (or a bigger RAM chip).

Oh, I see. So you're just repeating the same scan-line four times then. That makes sense.

Your PIC experiments have given me an idea for my own video circuit that I'd like to build someday, where the PIC drives an external counter, so that I'm not restricted in address bits per se. True, it's a multi-chip solution, but it ought to not be overbearing either. Combined with a 512KB SRAM chip (typically the ones used for caches on computer motherboards), I could achieve a full 640x480 display with 256 colors or 320x480 with 65536 colors.

Quote:

I did forget about the 480 vertical. I'll have to check that out! IIRC, the timings change a little bit - but mostly the vertical sync pulse. If so, I think that's a great idea - thanks!

Oh, sorry -- it sounds like you're using the EGA video timings then. I forgot that VGA monitors supported the EGA timings.

Quote:

... or they just don't have any background!

Self-taught?

Quote:

I think I've seen this book, and it's only 1000 pages! In reality, I do need something like this. I'll check it out.

It's a heavy book too. But don't let the size of it scare you. It's a very well organized book, has lots of information in it, and is one of the easiest electronics books I've ever read. It covers both analog and digital electronics, and IIRC, the later editions even go into things like RF.

--
Samuel A. Falvo II

[candle]

whoa!
to all my knowledge vga rgb input is 0.7Vp-p, some monitors can handle 1Vp-p ant this is it.
i'm thinking now about 2 chips of sram (2x32k) wich are multiplexed, if one is used to write data in, other is used to draw screen
we waste half of memory, and complicating output (and limiting speed this way), BUT! this will allow to produce flicker free output using low cost components - even if realised in pure ttl logic
and.. if you're playing full screen animation this is not an issue at all
to keep all system happy you would use another 32k of system memory (previous 64k would be adapter memory) just as another frame buffer, and routine on interupt would copy all 32k - prefferably as dma

[greener]

GARTHWILSON wrote:

What op amps and DACs have you tried, what were the problems, and what speed do you need?

Well, I bought the op amp at Radio Shack. It's the LM324 Quad Op Amp.

The DAC is the DAC0808LCN from National Semiconductor.

I'm sure that half the problem is that I simply don't understand everything I'm supposed to do... I've been working with just 5V and ground. I also haven't fully read the spec sheet - I think I was messing with figure 7 (positive voltage). However, I was just using Vcc = +Vref = Vee = 5V. I have a hunch that that is what I messed up with.

Regarding speed - the horizontal line rate is 31.5KHz. If I do achieve 320 pixels across, I think that is 100ns. For 250, approximately 126ns. For my original goal of 40 pixels across, 793ns. Hopefully I didn't mess that up. I see now that the DAC0808 has a settling time of 150ns. Presumably, if I did get it to work, I'd be disappointed - something like a blurry or smeared image.

Anyway, what I've been trying is just hooking it up and plugging all inputs to +5V... In theory, I should get close to +5V on the other side - when I start to understand what I'm doing!!

My problem (besides being clueless) is that I never achieved anything close to +5V.

[kc5tja]

candle wrote:

whoa!
to all my knowledge vga rgb input is 0.7Vp-p, some monitors can handle 1Vp-p ant this is it.

As I understand it, VGA has always been 1V peak to peak. I don't have exact specifications in front of me, however.

That being said, you can drive a VGA with "5V" by using a resistive DAC. Remember that each VGA input constitutes a 75 ohm impedance. Hence, it behaves like a 75-ohm resistor. Therefore, with a sufficiently large resistor feeding it, a 5V digital output pin can create a 0.7V or 1V signal on the monitor, without any need for buffers or level shifters.

(see, this is where it's handy to know both digital AND analog electronics! )

Quote:

i'm thinking now about 2 chips of sram (2x32k) wich are multiplexed, if one is used to write data in, other is used to draw screen
we waste half of memory, and complicating output (and limiting speed this way), BUT! this will allow to produce flicker free output using low cost components - even if realised in pure ttl logic
and.. if you're playing full screen animation this is not an issue at all

I have a much, much better idea. Put a raster compare register in your circuit, capable of generating interrupts to the main CPU. This way, the CPU can wait for the video beam to reach the half-way point in the display before updating the top-half of the screen, and wait for the video beam to retrace before updating the bottom half of the screen. Voila -- flicker-free video *without* the expense of dual RAM banks and hardware supported double-buffering.

Implementing a raster counter is easy. You need a set of 8-bit comparators, a sufficiently large up-counter (e.g., a 480 pixel tall VGA display has 525 vertical total; hence, you need a 10-bit counter to hold the value up to 511), and some minor amounts of glue-logic to bundle it all together. Every HSYNC pulse increments the line counter. Every VSYNC pulse resets the line counter to zero. When the raster compare register's contents equals the value of the line-counter, an interrupt to the CPU is triggered (assuming it's enabled; even the "enable logic" can be automatic -- since the line counter never exceeds 525 in practice, just set the raster compare register to something like 600, and it'll never trigger an interrupt; a 10-bit raster compare register can handle up to 1023 line displays this way).

I imagine something like this could be implemented in a cheap PIC chip fairly easily. And, and this is what I find disturbing, this is a *critical* feature that is often found *missing* in most off-the-shelf video solutions. I could never, ever figure out why.

[greener]

kc5tja wrote:

Your PIC experiments have given me an idea for my own video circuit that I'd like to build someday, where the PIC drives an external counter, so that I'm not restricted in address bits per se. True, it's a multi-chip solution, but it ought to not be overbearing either. Combined with a 512KB SRAM chip (typically the ones used for caches on computer motherboards), I could achieve a full 640x480 display with 256 colors or 320x480 with 65536 colors.

I think I understand that the PIC would tell the counter to start counting, the counter would actually drive part of the address bits for RAM, but don't you need something move the counter? Do you just use an oscillator to drive it? Something like 20MHz would be close. (Sorry about the terminology.)

kc5tja wrote:

Oh, sorry -- it sounds like you're using the EGA video timings then. I forgot that VGA monitors supported the EGA timings.

Actually, it is VGA. If you look here, I've been using the middle column. Now that I look at the sheet, I see the horizontal timing is identical, no matter what the vertical resoltion. However, the vertical timing does change - once you hit 480 vertical, the vertical frequency drops to 60Hz. Actually, it looks rather simple to switch over to!

kc5tja wrote:

Self-taught?

Actually, more of a hack at this point. I grew up developing on an Apple II+ or //e, moved to DOS, then to Windows, and now on Java. A friend at work started talking about the PIC a couple of months ago, and now I'm having a blast! Then I started seeing the 6502-based computers here, and I thought it was a really cool idea. But, I wanted "real" video. 40x40 would be OK, but a more useable screen would be really nice. So, here I am, with more ideas and very little experience. Pretty fun, actually!!

kc5tja wrote:

It's a heavy book too. But don't let the size of it scare you. It's a very well organized book, has lots of information in it, and is one of the easiest electronics books I've ever read. It covers both analog and digital electronics, and IIRC, the later editions even go into things like RF.

Can I reference it by chapters of interest or will I just confuse myself? I don't have a good history with books over 300 pages, unless it's liesure reading...