Seeking Advice on Using Both NTSC and VGA Output in a Project
Duane Degn
Posts: 10,588
Dave Hein's recent question about using a Propeller as dumb terminal reminded me of a question I've had regarding using the Propeller as a terminal.
Is it possible to use both a VGA display and a NTSC display at the same time?
I would like to use a Propeller powered terminal instead of using a PC as an interface to a Propeller running Don Starkey's CNC controller. The Propeller running the CNC software is on a separate daughter board inside the enclosure. The Propeller running the terminal software is on the Propeller Protoboard seen the photo below.
It looks like there's a nice selection of terminal emulators to choose from in the thread Dave Hein started. My question is if there is one object which would be better to use with both VGA output and TV output?
Here's a picture of my Propeller terminal so far.
It has one of these 2.5" NTSC monitors mounted in the enclosure. The green PCB sticking out the side is the controller board from the display (I'm still figuring out how to mount everything inside the enclosure). As you can see, I have a VGA connector on the Propeller Protoboard.
I'd like to be able to use the terminal either connected to a VGA monitor or with the included TV screen. Are there any concerns I should be aware of in trying to use two displays?
I figure worst case, I'll need to have one program or another started from a SD card depending on which display is to be used. I think it should be possible to change monitors without restarting the Propeller but I'm not sure if there will be a problem with reusing buffer space or not.
I know from past experience, adding a video display eats up a lot of the Propeller's RAM. I doubt there would be enough memory to use two video drivers at one time unless there's a way for the display buffer to be shared between drivers.
Is it possible for the VGA and TV drivers to use the same display buffer? I assume, if it's possible, the VGA driver would need to be set to a very low resolution in order to match the resolution of the TV display.
If it is possible to use both displays at once, I'd also like an option of leaving the small TV screen idle in order to use a high resolution VGA driver.
I realize I'll need to do a lot of experimenting myself but I'm hoping some of you with more video display experience would give any tips or suggestions you may have on where I should start my experimentation.
I was interested to read the following comment from Dr_Acula in the other thread:
Dr_Acula's experience gives me hope the terminal objects aren't too hard to modify.
I have used several different VGA objects in the past. I've also used the basic TV objects and I have several projects with Rayman's touchscreens. So I do have some concept of the way a program interacts with a video driver. But from my reading of the forum, I know there are a lot of variations on the way video drivers deal with colors and text. I'm hoping for guidance on selecting drivers which would lead themselves to being used with both VGA and TV output (hopefully at the same time).
Any suggestions?
Edit(2/1/20): Fixed links.
Is it possible to use both a VGA display and a NTSC display at the same time?
I would like to use a Propeller powered terminal instead of using a PC as an interface to a Propeller running Don Starkey's CNC controller. The Propeller running the CNC software is on a separate daughter board inside the enclosure. The Propeller running the terminal software is on the Propeller Protoboard seen the photo below.
It looks like there's a nice selection of terminal emulators to choose from in the thread Dave Hein started. My question is if there is one object which would be better to use with both VGA output and TV output?
Here's a picture of my Propeller terminal so far.
It has one of these 2.5" NTSC monitors mounted in the enclosure. The green PCB sticking out the side is the controller board from the display (I'm still figuring out how to mount everything inside the enclosure). As you can see, I have a VGA connector on the Propeller Protoboard.
I'd like to be able to use the terminal either connected to a VGA monitor or with the included TV screen. Are there any concerns I should be aware of in trying to use two displays?
I figure worst case, I'll need to have one program or another started from a SD card depending on which display is to be used. I think it should be possible to change monitors without restarting the Propeller but I'm not sure if there will be a problem with reusing buffer space or not.
I know from past experience, adding a video display eats up a lot of the Propeller's RAM. I doubt there would be enough memory to use two video drivers at one time unless there's a way for the display buffer to be shared between drivers.
Is it possible for the VGA and TV drivers to use the same display buffer? I assume, if it's possible, the VGA driver would need to be set to a very low resolution in order to match the resolution of the TV display.
If it is possible to use both displays at once, I'd also like an option of leaving the small TV screen idle in order to use a high resolution VGA driver.
I realize I'll need to do a lot of experimenting myself but I'm hoping some of you with more video display experience would give any tips or suggestions you may have on where I should start my experimentation.
I was interested to read the following comment from Dr_Acula in the other thread:
. . . But with experience it is possible to see the propeller in a different light, and to look at the obex as a library of building blocks. For example, the standard pocketterm software was VGA text with one color scheme per line. There are different VGA drivers out there that can do different colors per character. Or you could change it to a pixel based graphics driver. . . .
Dr_Acula's experience gives me hope the terminal objects aren't too hard to modify.
I have used several different VGA objects in the past. I've also used the basic TV objects and I have several projects with Rayman's touchscreens. So I do have some concept of the way a program interacts with a video driver. But from my reading of the forum, I know there are a lot of variations on the way video drivers deal with colors and text. I'm hoping for guidance on selecting drivers which would lead themselves to being used with both VGA and TV output (hopefully at the same time).
Any suggestions?
Edit(2/1/20): Fixed links.
502 x 612 - 152K
Comments
If the displays are the same, then you probably want to stick with the basic TV.spin and VGA.spin and then it should be possible to share some of the RAM usage. I'd recommend using a 320x240 resolution for the 2.5" display. You will need to set up the color tables so you have the same output color for the same color number.
With one cog, you could make a combined TV/VGA driver that switched outputs
With two cogs, you could have simultaneous mirrored displays (or even different displays with two display maps)
I'll let you all know how it turns out (and probably ask for more help along the way).
It's good to know TV and VGA can use the same buffer.
Some people use a lot of pins to access a small LCD pin through its interface, others use expensive VGA. I personally love those 2.5-3.5" TVs (usually sold for car back-up camera systems). They display great, are cheap and all that good stuff.
Very nice looking project. I have a need here for serial term similar to this. My question is where did you get the case you used??
Thanks!
Thanks guys. If I knew people were going to comment on how the project looked I would have taken some time to stuff the guts inside the case.
I'm planning on using a keyboard and possibly a mouse with the project but I also wanted a way to input some data without a keyboard. I'm hoping the keypad will allow me to keep much of the functionality of the device when I don't have a keyboard attached.
I plan to use this interface project with more than just the CNC router. I think the 16 button keypad will make the device a useful portable interface device to use with other projects like oven control and sprinkler system control.
Ah yes, though I'm not aware of any demos which use both displays at the same time. If/when I get both displays working at once, I ought to make sure and post a demo version people can try on the Propeller Demo Board.
I have a bunch of parallel LCD displays myself, but I haven't yet used one. I purchased a few serial LCD displays early in my microcontroller education and I've always just used those when I needed a LCD display.
I use a nice 19" VGA monitor in my chemistry lab. I lets me display a lot of data at once. I'm using the 1280x1024 VGA driver on the Propeller board controlling the display. It seems kind of strange to have such a large monitor connected to a Propeller.
I also like small NTSC displays. I purchased five of the 2.5" displays from Mark when he was selling them for $10 each. One of the things I like about using NTSC displays is they can be used to display both data and a live image from a video camera. The Propeller Backpack make overlaying data on an image pretty easy.
This is the enclosure I'm using. I also purchased the keypad from MPJA.
I don't have anything to say about your question, except that if you run your displays from a serial feed you should be fine. I know that you know that:)
What I am most excited about is that you are taking up Don Starkey's work and trying to turn it into a functional machine, which I have been hoping for.
I write my own G-code and use Mach 3 to run a very nice, inexpensive CNC machine http://www.mib-instruments.com/servlet/the-CNC/Categories
In addition to running the G-code, Mach 3 has a graphical interface that let's you step through the code, which I find to be indispensable. I wouldn't dream of running my code, without looking at the "unintended consequences."
This kind of interface is not exactly trivial, but is well within your reach, but it absolutely demands a Prop2.
I certainly hope you are on Parallax's short list:)
Rich
4
I may end up going the PC route but I'd like to see how much a Prop (or two) could do.
Thanks, me too.
I may try displaying the G-code with a Prop1. When I get to that point I'll want to take a look at this thread discussing using the graphics object with a VGA display (broken link). I figure the thread will be easier to find if I post a link here.
Most of my work so far has been to modify the various commands from displaying output to a VT-100 terminal to displaying the output to a TV. I have not added any VGA code yet.
I have written code to read the 4x4 keypad using shift registers. In hindsight the shift registers probably weren't the best way to read the 4x4 keypad.
I'm not sure I'll keep the small TV screen as a display for the CNC project. The TV looks cool in the enclosure but it may end up being too small to display all the information required to monitor the CNC.
If I use a different display, I'll need to use a different enclosure. I'm sure I'll find another use for this enclosure if I don't use it with the CNC controller.
Edit: Fixed one link (can't find the other).
I reentered my CNC-mill-project.
- Axis driven by steppermotors are moving now with a small test-code
- I mounted inductive aproximation sensors which I use for reference-moves
- I made some basic tests with read/write from / to SD-Card
- a longer time ago I started coding a string-parser that separates the parts of a g-code line
So I'm in the middle of the way putting these parts together.
I have not decided yet If I use Don Starkey CNC-PRG or if I write one on my own. This will highly depend upon
getting to run the original code with my DIY-Prop-Board.
So were you able to run the original CNC-propeller-code from Don Starkey including SD-Card with all functions?
If Yes we could collaborate in finishing the code-modifications to get a two-propeller stand alone CNC-Control
best regards
Stefan
While I didn't run the original program with the proper terminal installed on my PC, I'm pretty sure I did run it using PST as the terminal. IIRC, the SD portion of the software worked correctly.
Have you run a FAT demo program using the same SD driver? I know some of Kye's later objects were very picky with the way the cards were formatted. I had cards that worked with some SD drivers but not others until I reformatted (the slow way) the SD card.
What sort of I/O devices were you thinking of using with the slave Propeller?
One problem I could see in collaborating is the mismatch in our hardware.
I was kind of hoping I could have the option between two interface systems with the slave Propeller. One interface would have a VGA screen, keyboard and possibly a mouse. But I'd also like the option of controlling the machine with just the keypad and small TV as the display.
If one of these interface systems matches up with the hardware you'd like to use, then maybe I could start with the system we would both use and then I could add the other interface later on.
You might not like the way I've been modifying the original program to use with a second Propeller.
Since Don's program uses most of the the Propeller's RAM, I've been looking for ways of reducing the size of the program. One trick I had worked on was to move the various message strings to the slave Propeller. Instead of the master Propeller sending the string for the slave to display, it would send a number to indicate which message should be displayed. The slave would then display the appropriate message based on the number received.
I'm not sure if this software change would work with the way you were hoping to have the two Propellers work together.
I'll find my latest version of code and post it to the forum within the next couple of days. You can take a look at it and see if it looks like a system you would want to use.
One of the problems I ran into when I tried running the original code was not having VT-100 terminal software on my PC. Do you have a suggestion on which terminal software I should install on my Win7 (64-bit) machine? If I can get the appropriate software to work on my PC, I'll try to run the original program again. It would be helpful to know how the various "message box" and other formatting tools are supposed to work.
my latest SD-Card tests were succesfull with Keys engine and with fswr.
I ran 3 differnet demos and they all worked.
I bought a VGA-Display just display with backlight and PCBs for 30 Euros.
(by the way used PC-Monitors are available for 20 Euros)
But as long as I'm testing I will use a serial terminal (not VT100 PST or Br@y's Terminal
So While developing Input will be via PC-Keyboard.
In the end I haven't decided anything yet. I tend to use a PS2-Keyboard
I haven't looked into TV- and VGA-code for a long time. If I remember right the commands are similar but not identical.
Therefore make a suggestion what YOU would like to start with f.e. TV. Then I would adapt the VGA-code that VGA uses
the exact same method names with same parameter-sequence. Then you can change just the objects name to use TV or VGA.
Or is your Idea to have both at the same time? If there is enough memory for the "graphic-carc-Prop" this would be god too.
I'm pretty sure that I can accept your code modifications. I could live with using a VT-100 Terminalsoftware but I like it more to be PC-independent.
Moving message-textes to the Display-prop is a good Idea. If you haven't coded all numbers with selfexplaining constants that's something I can do.
If you have more than 10 messages it's hard to remember the textes. So all my variables methods and constants have selfexplaining names.
(not only unique but cryptic identifiers)
For the terminalsoftware itself it should be no problem to run on a 64bit system. Did you have trouble using a terminalsoftware caused by 64bit?
I did a quick search with google and found this side.
http://www.x64bitdownload.com/64-bit-vt100-c-122-terminal-telnet-clients-downloads.html
I haven't tested any of these terminalprogramms but I guess they should work.
The only thing is to have a 64bit DRIVER for your serial-to-USB-Adapter. But If you can download to the propellers RAM and EPROM this part is working.
So where else is the problem?
If this is really a problem. Do you habe to have an older PC running 32bit?
best regards
Stefan
This is my inclination as well. I added a two port serial driver to the main Prop's program so it can send data to the slave Prop as well as send debug info to the PC. The four port driver I tried was too large so I trimmed it down to two ports so it would fit in available RAM.
I would very much like to be PC-independent as well. My main interest with the VT-100 software is to see how the various message boxes and text are displayed.
I'm hoping the small TV can display enough information to be useful. I think I'll try to start with the TV display and move to the VGA display if the needed information won't fit on the TV. I think it would be nice if I could have both displays going at the same time but that's not a high priority for me now.
I'm big on having self explaining constant names.
I generally only abbreviate when I have to keep the name within the 30 character limit (or if I'm using one of Don's names).
These are some constants from a shared header file.
CON ' Shared Constants DEBUG_BAUD = 115_200 PROGRAM_NAME_LIMIT = 16 POSITION_H_FLAG = "H" CLEAR_FLAG = "J" CLEAREND_FLAG = "K" HIDE_CURSOR_FLAG = "l" SHOW_CURSOR_FLAG = "h" TEXT_COLOR_FLAG = "m" 'PROGRAM_NAME_FLAG = "P" WAIT_FOR_CURSOR_FLAG = "?" SINGLE_BYTE_COMMAND = "B" TERMINAL_LINES = 25 EDITOR_LINES = 23 PROGRAM_WINDOW_TOP = 7 TERMINAL_LINES_VGA = 25 EDITOR_LINES_VGA = 23 PROGRAM_WINDOW_TOP_VGA = 7 TERMINAL_LINES_TV = 25 EDITOR_LINES_TV = 23 PROGRAM_WINDOW_TOP_TV = 7 ESC = 27 SAVE_CURSOR_POSITION = "7" RESTORE_CURSOR_POSITION = "8" TWO_BYTE_COMMAND = "B" ' first byte of TWO_BYTE_COMMAND, command enumberation #0, BOX_MSG, OP_MSG, POS_STR_MSG, POS_NEW_MSG, OTHER_MSG ' Second byte of TWO_BYTE_COMMAND will be from one of these lists. ' BOX_MSG enumeration #0, SPLASH_BOX, ONE_BOX, TWO_BOX, THREE_BOX, OVERWRITE_BOX, GOODBYE_BOX, OVERLAY_BOX, { } PRESS_ANY_BOX, BAD_NAME_BOX, SAVE_FILE_BOX, JOG_01_BOX ' OP_MSG enumeration #0, IDLE_OP, AUTO_OP, MDI_OP, SINGLE_BLOCK_OP, FINISHED_MOVING_OP, FEEDRATE_MISSING_OP, { } OVERTRAVEL_OP, EMERGENCY_STOP_OP, ERASE_OP ' POS_STR_MSG enumeration #0, PROMPT_POS, MAIN_11_POS, MAIN_12_POS, JOG_21_POS, JOG_22_POS, JOG_61_POS, { } JOG_62_POS, JOG_63_POS, JOG_64_POS, JOG_65_POS, JOG_66_POS, NUM_ON_POS, { } NUM_OFF_POS, HOLDING_POS, CONFIG_READ_POS, CONFIG_WRITE_POS, PROGRAM_NAME_POS ' POS_NEW_MSG enumeration #0, PROGRAM_NAME_NEW ' OTHER_MSG enumeration #0, FILL_OTHER ' wait enumeration #0, NO_WAIT, YES_WAITI'm not sure what my exact problem was with the VT100 software was. I think I just didn't find one I trusted enough to install on my PC (which isn't behaving well as it is).
I have no particular desire to use a VT100 type terminal window but I think one is needed to properly display the output from Don's original code.
A lot of Don's original code deals with displaying information. I've found in some of my more complicated projects, it can take a lot of effort to display data in a useful fashion. My plan it not to worry much about how the output looks to begin with but I think getting the output to display in a useful way will be a challenge.
It looks like the last time I worked on this project was in November. My latest files don't even compile. I'm not one to wait until my code is pristine before I'll post it to the forum but I would like to clean up my code enough to get it to compile before posting it.
I'll work on my code a bit in the next day or two and have something to post by/on Tuesday.
I have several robot remote projects in progress and I think I'll use the same communication protocol with this CNC project as I'm using with my robot remote projects.
Here's part of the header file from one of my robot remote projects.
COM_ATTENTION = $7E ' offset enumeration #0, START_TRANSMISSION_OFFSET, MESSAGE_COUNT_OFFSET, DESTINATION_OFFSET, { } TRANSMISSION_LENGTH_OFFSET, TRANSMISSION_TYPE_OFFSET, SUB_TYPE_OFFSET, { } BEGINNING_OF_PARAMETERS_OFFSETThe above offset give some clue to the type of protocol I plan to use.
Just to be clear, the attached code it pretty much useless. It presently does not allow Propeller to Propeller communication.
I'm pretty much just posting it since I said I would not because I think it will be useful to anyone else.
If anyone is interested in using the Propeller to control a CNC machine I recommend the check out the original code by Don Starkey in the OBEX.
I do plan to continue to work on this code and get a proper communication protocol up and running (I have done Prop to Prop communication successfully many times). While I've done many Prop to Prop communication projects, this one is more complex than my other projects. I've also recently switched to using a transmission length parameter in the header to indicate transmission size rather than using my previous method of using an end of message character. Not using an end of message character allows me to send the raw data over the com line instead of having to convert the data to ASCII characters and back.
Hopefully I'll have something useful to post soon.
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.