NTSC video out library

Wow, that's cool... PAL-Support!!!

Ok, if I understood right, you need much as possible SRAM, to get the most resolution possible?

So you think Sanguino btw. AtMega644p is the right Device to improve Resolution?

Because of Sanguino, 644p is arduino-compatible mcu. So far as I know, it's the "biggest sram" Dip/Dil mcu on the market and avaiable also.
It runs on 20Mhz so, this could be an improvement too.

I know, there are mcu's with much more sram, but in Dil/Dip Formfactor 644p is the choice of simple handling... maybe i am right.... mmh....

I am no expert... whart do you think about using 644p?

Greetings ChrisS

yes the sanguino(ATMega644p) would work well, however do note that it would require a quick modification the the library. This is because the OC1A pin is not on PORTB1, it is on PORTD5, the required modifications would be setting PORTD5 to be output, and connect the sync resistor to that pin (i don't know what it is on the sanguino).

The arduino mega would be even better resolution wise as it has 8k sram.

As far as the best DIP chip to use the ATMega1284p would be best, if it can be found. it is the bigger brother to the 644, with 16k sram! (@20mhz 320x240 would be possible)

clock speed really isn't an issue with this frame buffer method because unless we have about 8k of SRAM 16mhz is fast enough to output the buffer.

I am no expert... whart do you think about using 644p?

At that point, you might look into the Uzebox:

:slight_smile:

mdmetzle, this is fantastic. I did not hesitate to cut an RCA cable and start using your library. Very, very nice!

This may be a simplistic question but is there a way to output colour at all, or possible with a future version, or is this beyond the scope of the arduino?

Color with a composite signal and no added hardware not going to happen. Color over component(RGB) is possible, and may happen, it all depends on how ambitious I feel. If i or someone else adds RGB color then a RGB to composite IC(such as the AD624) can be used to convert it to component. I am planning a tile rendering engine that would use 2bit gray-scale(4shades of gray).

Color composite without a special IC(at least for PAL??) is possible but beyond what I am interested in:

What lft did there makes my library look absolutely pathetic....

Oh, that's the guy of CRAFT Demo... I think he's really bright mind....

I found something like the opposit of your atempt.... maybe it is possible to adapt something of that to use with better an less hardware... looks crazy... scroll down....

http://www.lazarus64.com/

http://www.lazarus64.com/demo1.wmv

Specs are a little bit better.. but wiring makes headaches :wink:

Greetings ChrisS

i love this lib!!

i am trying to add a function but no luck.. some help please.

unsigned char TVout::get_pixel(unsigned char x, unsigned char y) {
//each line has 18 bytes
//calculate i based upon this and x,y
// the byte with the pixel in it

int i = (x/8) + ((int)y*16);
return (screen >> x) & 1;
}

I found something like the opposit of your atempt.... maybe it is possible to adapt something of that to use with better an less hardware... looks crazy... scroll down....

That is one scary looking piece of breadboarding - amazing output, though. I might even have the parts to replicate it! The thing with it, though, is to recreate it you would have to track down a bunch of parts which may or may not be easily available. It would be nice to see a stripboard or PCB version.

I also noticed that it seems to have better output than most of the systems of that era (late 70s - early 80s); while the resolution was there on such systems, the number of sprites, speed, and number of colors generally were not that high (with the exception of the Amiga and the few systems that had 256 color boards, which cost a fortune).

If you wanted to do something like this with the Arduino, it would be better to use the video chip used by by the UzeBox I mentioned before (actually, just use an UzeBox). I wish I had time to play with these retro systems...!

:slight_smile:

gijs,
Thank you.

Ill add this to the next release, as its a rather obvious feature to have...
Ill use the same syntax as you proposed.

for now though change this line:
return (screen >> (x & 7)) & 1;
The problem with what you were doing is that x a pixel on some line, and what you need is the bit in a byte on that line. i contains the index to the byte we are looking for but now we need to modify x to contain the bit we want, so we can do that by ignoring anything past the number 7(we count the bits in a byte 0 to 7 not 1 to 8) since 7 in binary is 0b0111 we can simply bitwise and x with 7.
this "should" work
As far as when the next release occurs, it should be soon i have been fixing lots of bugs with changing the rendering resolution. I also have added mega support(i think i cant test it).
cr0sh,
The Uzebox is awesome, and for developing nice retro games on an AVR it cant be beat. I'm creating this library simply because I am more interested in the low level video generation and simple shape rendering than actually developing any games. Now if anyone can use this library to make a game thats awesome.
However to use an AD725 like the uzebox does we still need to generate valid sync pulses and feed the RGB signal into it. Although I really don't think I will ever do anything past gray scale with this.
There is also this: http://avga.prometheus4.com/ for generating a RGB signal. It however would need to ported over to the arduino environment as it uses native assembly files (i really wish the arduino environment did, it would make things much easier for me).

thanks! now it works (-:

Maybe you are interessted in this:

http://www.glyn.com.au/downloads/documents/4D%20Systems/uVGA-PICASO-MD1_Serial_Users_Manual_Rev1.2.pdf

http://www.mercateo.com/p/108A-426(2d)623/Embedded_Graphik_Engine_PICASO_VGA_SVGA_Herst_Teile_Nr_UVGA_PICASO_MD1.html

Greetings ChrisS

Update:
-Added horz_res(), vert_res(), char_line(), get_pixel(x,y)
-horz_res/vert_res gets resolution of screen
-char_line gets the number of characters that will fit on a line
-get_pixel gets the status of x,y returns 1 for white 0 for black.
-rewrote the line render functions
-fixed bugs preventing changes in resolution and pixel scaling
-automatically centers the screen vertically
-added arduino mega support, untested
-Sync pin: pin11
-Video pin: pin12
-changing the redering resolution is now supported.
to do so change the virtical and horizontal resolution in video_properties.h
-Note:
(_RESOLUTION_HORIZONTAL/8)*_RESOLUTION_VERTICAL
must be less than the amount of memory the arduino has.

I don't have a mega so i cant test the support. All i can say is the changes compile fine...

I tried the demo sketches on my mega and they worked just fine :slight_smile:

stimmer,
Thats good to here, with a mega there is a lot more space for the frame buffer so a higher resolution display is easily possible.

I tried increasing the resolution and that's working fine too. All the way up to 152x216 in NTSC and 152x255 in PAL. Beyond that the pixels are either off the edge of the screen or it is out of range of a byte (and 255 lines in PAL is almost at the bottom of the screen anyway)

I have a question about the resistors used. How far away from 1k ohm and 330 ohm can they be and they still work? Just wondering what tolerances are needed? I don't want to blow up my tv :slight_smile:

Strimmer,
Thats good to here, I left things as bytes just to save time on calculations, and like you said it about fills the screen so i really dont see myself switching to integers to track the number of display lines.

Crook,
I have seen other similar implementations of composite video use 900ohm and 450ohm resistors. So there is a little bit of wiggle room as far as that goes.

how would i use your lib to output data from a ds18b20 temp sensor? here is the code i have but it wont compile

#include <TVout.h>
#include <OneWire.h>
#include <DallasTemperature.h>
float tempc , tempf;
// Data wire is plugged into port 2 on the Arduino
#define ONE_WIRE_BUS 2

// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
TVout TV;
unsigned char x,y;

void setup()  {
  x=0;
  y=0;
  TV.start_render(_NTSC);
   sensors.begin();
}

void loop() {
  sensors.requestTemperatures(); // Send the command to get temperatures
  tempc = sensors.getTempCByIndex(0);
  tempf = tempc*1.8+32;
  TV.delay_frame(60);
  TV.clear_screen();
  TV.print_str(0,0,tempf);
  TV.delay_frame(60);
}

Very cool.. testing... 8)