Video Output Problem

Vega256 · 2011-02-09 04:01

Hey Guys,

My Propeller has recently come and I established a very basic breadboard circuit to output composite video. What happened was I received a fuzzy and faint video signal. The circuit is set up as it depicted in the Propeller manual with the exception of the Prop Plug, therefore, nothing is connected to pins 40, 39, or 11. I have the resistor network set up correctly. Does anyone know how to resolve this issue?

potatohead · 2011-02-09 07:27

Please post your code and schematic, ideally a photo of the setup.

Are you using composite, or broadcast? The broadcast is fickle at best. Possible, but not too practical. The same circuit can do composite video very well. Use a RF modulator, or VCR, if you need to for your display.

Oldbitcollector (Jeff) · 2011-02-09 07:36

Will this help?

OBC

Cluso99 · 2011-02-09 17:49

Try placing a 191R (or 180R - 220R or higher) across the connector (i.e. from the junction of the 3 resistor outputs to ground) as the prop circuit does not give a proper 75 ohm impedance. This has been Phil's idea. Let us know if this helps.

Vega256 · 2011-02-11 16:40

Sorry guys for the delay; the Internet was down for two days. I was running the TV Text Demo and I think that I had the wrong pins connected. I had the resistor network set up correctly but I connected the video out from I/O pins 1, 2, and 3.

Vega256 · 2011-02-11 17:17

Now, I am receiving a signal from the Prop however, the display is heavily distorted.

potatohead · 2011-02-11 18:35

Looks to me like pin configuration might still be at issue. The blanking should be dark, not bright as shown in the middle of the picture. The text is dark on bright too. Signal appears to be inverted.

If it were me, I would build the Demo Board video circuit exactly, and run the standard 80Mhz clock with 5Mhz xtal, if possible. Do not use a resonator, because it's not accurate enough. Once you have that circuit outputting a stable signal, move to the pin configuration you desire, change nothing else and debug until you get a good signal on that setup.

You are very close!

Vega256 · 2011-02-11 22:04

Is this the correct image? There seems to be some missing text. "TV Text Demo" is supposed to be printed before "OBJ and VAR...".

potatohead · 2011-02-11 23:10

Not sure why you are not seeing the text. Double check that it's the as shipped demo program. Examine TV_Text.spin to see what the various control characters do. Screen position, color, etc... can be set with those, and there are some between the text you see and the text you don't.

That said, the TV cog is operating properly. Should be able to run graphics_demo.spin, and graphics_palette.spin now.

Toby Seckshund · 2011-02-12 00:22

On your cct is the 270K Ohmn resistor value just a typo ?

Vega256 · 2011-02-12 10:20

@ Potatohead,

I now have a clear signal. I believe you mentioned some drivers that commands the Prop to accept tile information from I/O. One of which is the driver you wrote. You said that I had to initialize communications. Is your driver based on TV.spin?

potatohead · 2011-02-12 11:19

Well, that's a long discussion.

Here's what I can say. There are drivers written off of TV.spin that can deal with data scan line by scan line. Some of the games use them. There are a lot of drivers honestly, and they all work different ways. TV.spin can be modified to take data one line at a time. Most of the drivers can. That's not the core problem though.

A great first project is to get the Prop talking to the other CPU somehow, and once that's done, how that goes will determine what graphics options are possible. You kind of need to work backward up to the graphics driver level, because how that part works depends a lot on how fast the communication is, and what kind of communication it is. Google 6502 laptop propeller for one example of how that kind of thing can work. You might also look at the AVR + prop projects to see how that was done too.

IMHO the easiest thing is to use high speed comms between the prop and the other CPU, using the Prop like a terminal. Mapping it into the other CPU memory, like a graphics chip is a lot harder, and I'm not a lot of help in that area. Learning about that myself right now as time permits.

Vega256 · 2011-02-12 11:35

potatohead wrote: »

Well, that's a long discussion.

Here's what I can say. There are drivers written off of TV.spin that can deal with data scan line by scan line. Some of the games use them. There are a lot of drivers honestly, and they all work different ways. TV.spin can be modified to take data one line at a time. Most of the drivers can. That's not the core problem though.

A great first project is to get the Prop talking to the other CPU somehow, and once that's done, how that goes will determine what graphics options are possible. You kind of need to work backward up to the graphics driver level, because how that part works depends a lot on how fast the communication is, and what kind of communication it is. Google 6502 laptop propeller for one example of how that kind of thing can work. You might also look at the AVR + prop projects to see how that was done too.

IMHO the easiest thing is to use high speed comms between the prop and the other CPU, using the Prop like a terminal. Mapping it into the other CPU memory, like a graphics chip is a lot harder, and I'm not a lot of help in that area. Learning about that myself right now as time permits.

I see. I suppose I could have entire images (background images, etc.) stored in RAM and have the Prop issue a HOLD on the CPU to go and fetch scan line data an address at a time, somehow. The issue is that the Prop's internal video hardware deals in LONGs and my RAM is only 32Kx8; that would be 4 data fetches per scan line.

potatohead · 2011-02-12 12:41

Most video systems I've seen do from 20 to 160 fetches per scan line, depending on color depth, resolution, display list / sprites, and other options. That's bytes, and the need for prop pins to be free probably means that or words are what you can fetch, IMHO.

Having the prop halt the CPU during the memory access is what was done with a lot of systems.

BTW: The internal hardware in the COG works with longs, but the HUB works on bytes, words and longs.

Take a look at that 6502 laptop project. Dennis used some latch buffer type chips, and a 8 bit wide data path on the prop to address the ram for the CPU. His implementation sat between the CPU and the RAM, using the Prop to clock the CPU. Worth thinking about.

Edit: So that involved putting the MSB of the address on the bus, selecting the latch chip, then put the LSB of the address on the bus, select that chip, finally, select the chip that has the data on it, reading that from the propeller pins to store in the HUB, or putting some data on the bus, and selecting a different line to write it to the RAM. The code included in that project will tell you a lot about how this stuff can work.

As far as the video goes the Prop will need to halt the CPU to fill the scan line buffer, which the video cog will read from. Use two buffers, so that one can be filled while the other one is being displayed, for example. Or, the prop needs to get data from the CPU to direct it to display data that is already in the propeller, or that gets loaded in some other way.

In general, video drivers operate on simple data. Colors and pixels get buffered somehow, frame, sprite, scan line, whatever. Render / data fetch / build sprite cogs can be in charge of formatting the data for the video cog.

The big thing is to sort out how the data moves, and how much data can move, and when it can move. From there, the video options can be sorted out.

Say you can get 20 bytes per scan line. That would boil down to something like 160 pixels at 2 color, or 80 pixels at four color.

Video Output Problem

Comments