Newbie.... quick question
Steve2381
Posts: 94
Hello there
I am 'upgrading' from basic2 stamps to the Propeller chip, and so I am going to grab myself a development board and goodies to learn the ropes (any recommendations for a good starter kit?)
I kept on out-programming the stamps and I am building an Ipod controller.· Seeing as Propeller chips and Ipods are both 3.3v, it seems a good starting point.
My questions are...·· What size programs can you write for a Propeller, compared to a stamp?· I was always running out of variable space on the Stamps.
From a look around on here, the video function seems quite resource hungry, but what kind of video functions can be created with the Propeller.
Sorry for the questions, but I don't really want to jump into Propellers (so to speak) and they fall short of my requirements.
Thanks for your time
Steve
I am 'upgrading' from basic2 stamps to the Propeller chip, and so I am going to grab myself a development board and goodies to learn the ropes (any recommendations for a good starter kit?)
I kept on out-programming the stamps and I am building an Ipod controller.· Seeing as Propeller chips and Ipods are both 3.3v, it seems a good starting point.
My questions are...·· What size programs can you write for a Propeller, compared to a stamp?· I was always running out of variable space on the Stamps.
From a look around on here, the video function seems quite resource hungry, but what kind of video functions can be created with the Propeller.
Sorry for the questions, but I don't really want to jump into Propellers (so to speak) and they fall short of my requirements.
Thanks for your time
Steve
Comments
Each of the 8 cogs has its own 2K bytes of RAM. Normally this is occupied by the Spin interpreter or an I/O driver like one of the video drivers or a buffered serial I/O driver or a 32 servo controller or PS/2 keyboard controller.
So, the "bottom line" is that you can have much much bigger programs on the Propeller than on any Stamp. You can also have relatively huge amounts of memory used for variables.
The video buffers have to reside in this 32K byte area. If you want to do graphics, you can end up using most of the HUB memory just for the graphics buffers. If you want to do text only or text with some small areas of graphics, you can get by with a smaller video buffer. For VGA text, you'd typically use a 64 x 24 character screen which would be only about 1500 bytes. The video routines would take another 2K or so depending on how fancy you want to get. TV text takes less memory since the largest decent text display is about 40 x 16 characters.
If you want to use graphics, you'd need 2 bits per pixel. It may not seem like much, but adds up quickly. A 320 x 240 pixel graphics screen would require a minimum of 20K bytes for a bitmap. Once you add another 4K or so of code for the video and graphics drivers, you're already taking up 3/4 of the available space. You can still get quite a bit of program in the remaining 6-8K.
I read several reviews of the prop chip and many complained of lack of programming space.
My application would be purely TV text (graphics would be nice, but too resource hungry).
Thanks for your time
You mentioned mixing text and graphics to save on the memory buffer. I have been working on this tact, but I'm knee deep in trying to figure out the code. Is there an example of something that I can look at?
Look at all the sprite activities of some people..
Sorry, I am too lazy (or does one say: busy?) at the moment to look for the links myself
Back in the day when memory was scarce, the Apple II had a graphics mode where it has a split screen: half had graphics and the other had text. Seems to me that something like this could be done with the Prop. If anyone has a good understanding of how the graphics/text display drivers work perhaps they could comment.
I pointed you to the HiRes Driver with Cursor as it shows the technique how to overlay tiles and bitmap graphics....
If you had a Propeller running I could post a test program which showed exactly that splitting of text and pixels that you mentioned for a special case...
Post Edited (deSilva) : 1/6/2008 1:15:41 AM GMT
Anyway, if you could take the time to post an example of a graphics compromise, I would be eternally grateful.
If you have a simple testprogram it would be great if you could mail it to me as well.
gb@gblom.se
Thanks in advance.
Goran (Sweden)
It is one of the pieces with which I planned to form a video tutorial...
This MPE_GRATEX is not in a status you can easily understand what I am doing. But then... have a look and give me feedback please.
It works somehow and you can use the basic routines, which are
* start(videopin)
* out, str, dec, hex, bin for text, including positioning ($a, $b) and 2 text colors ("$c,1" and "$c, 2")
* having either a full non buffered graphics window (320x240) or a split screen with double-buffered graphics (160x240)
Change videoPin and crystal setting before you start the demo (it's preset for Hydra).
Eventually you should remove the demo part from the object and use it from your own program.
3k free at the moment.
Post Edited (deSilva) : 1/6/2008 7:07:28 PM GMT
It could be what I needed for my "Shooting target project" which is a project I intend to use myself. I am a hunter and needed some challenge to keep me busy. I am 64 years old and soon retired.
If and when I have my project working I will notice you.
Anyway the project now have been tested with real shooting and the accuacy is within 2 cm. For the moment I am using a PC with a VB program to present the result on a Graphic picture of the real target. But I want the presenting part to be a Prop with a small cheap videodisplay instead of a PC.
Attached is a picture of the PC screen
Regards, Goran
Post Edited (deSilva) : 1/6/2008 7:11:45 PM GMT
Many thanks for this. In looking at the code, the Prop graphics makes more sense and I think I have a good handle on how it works. Still would like more available RAM but then I'm hard to please ....
- Using the split screen WITHOUT double buffering: that will free 10kB
- Using 2-color mode, however that will need a modification in GRAPHICS and TV. I wonder why there are so few B/W applications.. The first MAC worked B/W only and was fine...
Do you think the two colors could be anything; white on blue perhaps ?? If this were the case it would be entirely acceptable. I'll look into the GRAPHICS/TV code to see what damage I can do there....
I agree with deSilva re: first Macintosh. I used one for years to do pcb layouts using Douglas layout tool (no schematic capture, router, etc.). For that only b/w worked fine, as did all the other apps like word processor. We're spoiled today with 'needing' thousands/millions of colors and GHz speeds, though nicer. But now with an Intel iMac, that pcb s/w is no longer usable; obsolete OS and micro it runs on. Technology is nice; obsolescence isn't. Blech!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
[noparse][[/noparse]quote]I'll look into the GRAPHICS/TV code to see what damage I can do there[noparse][[/noparse]/code]
Have fun! This is not such easy as you might think. It is one of the densest codes deSilva has seen, and it took him many evenings to understand it
TV has to be changed for the usage of the ROM font. As its allocation has been optimized for 4-color mode, each long containing glyph data has to be preprosessed in the display loop. I shortly had the idea to change between 4 and 2 color mode within a video line, but this is too tricky...
It could be arranged though to have 2 and 4 color lines during the same frame...
I briefly looked at the TV code and my hair started falling out, its quite a job. How much different is the VGA code from the TV ? Wouldn't it be easier ?
It might help you to firs look into the last chapter (I think it is the last..) of my Machine Language Tutorial which explains the working of VSCL, VCFG, and WAITVID