Can someone explain this assignment statement?
Carl Hayes
Posts: 841
I'm attempting to understand the workings of the tv.spin module provided with the Propeller editor.· I hope to use it, but not without understanding it.
Early on, the following statement appears, written in the Spin language:
···okay := cog := cognew(@entry, tvptr) + 1
I infer, but am not certain, that this sets both cog and okay to some value, but the rest of the statement baffles me.· I can't figure out what is meant by an apparent attempt to use an executable statement as a value to be assigned.
Eh?· Wozzat?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Early on, the following statement appears, written in the Spin language:
···okay := cog := cognew(@entry, tvptr) + 1
I infer, but am not certain, that this sets both cog and okay to some value, but the rest of the statement baffles me.· I can't figure out what is meant by an apparent attempt to use an executable statement as a value to be assigned.
Eh?· Wozzat?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Comments
then one is added for a range of 1-8 so okay will always have a non-zero value when a cog was available to start and 0 when no cogs were available
for IF THEN statements and other boolean checks of ok/cog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
for example:
if cog ' do something if a cog was created else ' do something is cog was not createdSome people love this kinda stuff, others (like myself) find that clarity is better than cleverness.
Far out.
Thank you, gentlemen.· I do not think this syntax is documented in the manual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
·
No use referring me to C; I've never used it.
The Propeller, I'm learning, is a really neat piece of hardware.· But I'm appalled at the documentation.· Surely this must cripple the commercial success of this otherwise fine product.
I've been futzing with tv.spin for several hours now, with not a speck of light from the NTSC broadcast monitor I've got hooked up to the Professional Development Board.· So far I haven't deciphered the comments that putatively define which four pins I should use for NTSC.· When I figure out what is meant, then I guess I'll have to figure out the order of those four pins by experiment, since nothing in the comments even pretends to define it.· Not admirable.· I may just blow off the whole idea of using an NTSC monitor.· A shame; it'd be neat if it worked., and tv.spin appears to be a nice, though most inarticulately commented, piece of work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Take a look at the schematic for the Propeller Demo Board, as that one is (if I'm not mistaken) using the same pins as the default settings for TV.Spin. (From memory) the TV object assumes 4 pins (technically 4, but the 4th is the audio sub-carrier) in order, and you specify the lowest pin.
Your best bet is to look at TV_Terminal.spin or one of the other objects that uses the TV.spin object. These have a little more documentation in them, and are (slightly) easier to decypher.
From TV_Terminal.spin:
'' basepin = first of three pins on a 4-pin boundary (0, 4, 8...) to have
'' 1.1k, 560, and 270 ohm resistors connected and summed to form the 1V,
'' 75 ohm DAC for baseband video
From what I remember, the TV.Spin code is the lowest level of display driver, simply outputting the tiles to the TV. The 'higher level' objects are the ones that set up the tile array, format, palette, etc. You may also want to start with TV_Text.spin, as that file uses the Propeller ROM font, instead of a vector font, so it doesn't need character tile memory, is faster to update, etc, etc.
Jason
Actually, I'd rather write my own code than use tv.spin anyway, but no printed document I've seen gives any hint of how to program whatever video hardware is concealed under the covers of the Propeller.· I had hoped to acquire some knowledge of it through study of tv.spin.· No fear of that happening soon.
Apparently the video hardware can be programmed without knowing much about NTSC signals.· The manual (on page 140) speaks of creating 60 frames per second, which surely no NTSC monitor could display if you did it.· NTSC is an interlaced standard; there are 60 fields per second, but 30 frames per second.· That's very basic.
All I want to do is dispay a heading as a slanted bright line from the middle of the screen to the edge, in one of 360 directions, along with three three-digit decimal numbers along the bottom.· I've got an old Furuno small-boat radar lying around in the garage; maybe I'll just modify it instead.· I'm sure its details will be easy to learn in comparison.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
You and the murky comments in tv.spin both speak of tiles.· What's a tile?· Perhaps a rectangular area of the screen, considering the screen as a tesselated surface?· From which I would infer that you can't get full NTSC resolution, poor as that is, from a Prop.
I infer also that the Demo Board has permanently-wired connections between the Prop and the RCA plug.· The PDB doesn't.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Post Edited (Carl Hayes) : 2/18/2009 2:14:27 AM GMT
The default "return" value of 0 is in the manual, I just looked.
TV.spin is very complex, there's no two ways around it. It took me a few months to get a good handle on it. I wouldn't recommend trying to decipher that one to anyone.
But, using TV.spin is pretty easy. Using TV_Text.spin is even easier. I would highly recommend that to the beginner.
Nitpicking ... If you're doing non-interlaced video, a field is the same as a frame and the frame rate is usually 60 per second. Maybe that's not standard NTSC, but it is often accepted by video monitors and is easier to produce (and a bit higher quality for text and graphics).
You could easily produce the image you want using the TV object and the graphics object if your intention was just to make it happen using what's available.
Yes, I've read the scant four pages on VCFG and VSCL, and WAITVID too.· Maybe I'll blow off tv.spin and work with that directly.· I suspect it may be easier that way.· But even those pages don't·specify an order for the four pins -- merely how to select a group of four.· Must I try 24 different permutations?· Nor do those pages hint at what Jason said, that one of them is for audio.· Such failure to document is simply unrofessional.
Anything that isn't interlaced isn't NTSC.· It may be better, but it isn't NTSC.· But I can see how it might be accepted by some video monitors, if the vertical sync circuits were versatile enough.· Hadn't occurred to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
From the Prop Manual v1.01, page 189:
Page 191 also shows usage for converting the return into true or false.
I agree that documentation for the pins is lacking.
Tiles: square chunks of bits that make up pixels. In the case of TV_Text.spin, the square chunks are 16x32, with pairs of characters interleaved together to simplify addressing, since the prop works with 32 bit quantites. (The manual explains that part, at least). There's a 'tile pointer array', which contains, per-tile, the information about which palette entries that tile uses and an offset to its tile data.
The various graphics drivers do not use 'convenient' layouts, like a single byte per pixel or color. The tile array format is typical of older video game consoles or character-map displays, so if you're familiar with those you'll have an easier time. In the case of a text display, each 'tile pointer' is probably the base address of (or offset of) that tiles character data in ROM, as well as some color info. In the case of the 'graphics oriented' TV displays, the character tile array is set up so that each on-screen 'character' has unique tile data, allowing for pixel-addressable graphics.
The default pin values I spoke of were in the demo files that ship with the TV objects. Yes, the demo board is hard-wired, though I don't remember the base pin index off the top of my head.
I myself haven't ever delved into the innards of the TV driver itself, but it's trivial to make use of the TV_Text object, and even the Graphics.spin object is pretty straightforward to use. If all you want is to display characters on a screen, wire pins 0 to 2 (or any 3 consecutive pins, starting with a multiple of 4 of your choosing) and call the Start() method of the TV_Text object with the low pin number. If you actually want to modify the existing driver, or write your own, I suspect we're in for a few more earfuls from you on your journey there. [noparse]:)[/noparse]
Jason
I did just now actually get graphics_demo working, after divining where it specifies which pins to use, and then swapping wires around within the four pins I modified it to specify.· At first it was all black-and-white, but ultimately it was dancing around in color.· So I know it works.· It can do what I want, but it speaks ancient Etruscan and I have only English and a little bit of Japanese, German, Spanish, and French.· A very little bit.· Plus classical Latin.· Thus I can't tell it what I want.· Alas, that there's no professional-level documentation.· By professional-level I mean complete, articulate, written at an appropriate level of usage.
Don't misunderstand; I think the Propeller and its editor are quite impressive achievements.· There are a few things I woud do differently (like that asinine colon before the equal sign in assignment statements), but those are matters of preference and not of substance.· Nevertheless, after four careers (design engineer, systems programmer, manager, consultant), I can say absolutely that no product, however intrinsically wonderful, is ever better than its documentation.· Period.· In this the marketplace nearly always agrees.
I think graphics_demo is using at least two cogs -- maybe more, not sure --·to do that for which·I'm unwilling to give up more than one.· Most extravagant.· So I may just blow off the whole graphics thing anyway, for this century at least.· I spent decades doing extremely complex things using only the supplied docuentation of hardware and software, without ever having to ask the sort of kindergarten questions I've been asking about Propellers.
The documentation that exists often is unclear.· For example, under PUB and other places too, we read Rvalue must be globally unique, but other methods may also use the same symbol name.· That's really obtuse, poorly written.· I eventually figured out what they were trying to say.· A skillful writer would have written something more like, All occurrences of the label represented here by "Rvalue" must refer to the same storage location.· Other code may refer to this·location by the same label, but the label must be globally unique; it cannot be applied elsewhere·to some other storage location.
Ah, well.· The Propeller is a neat toy.· It will remain a toy until professionally documented, at which time it will become the superior professional tool that its brilliant design ought to make it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Jason
As a programming manager (which I never was -- I was a systems programming manager, an altogether different thing) I would likely forbid use of many of those operators.· Who needs a zillion ways to say A=A+1?· No harm in it, except that some programmers will prefer the fancy ones, and other programmers won't bother to learn them -- which is OK until the fancy guy quits and the stolid guy has to try to maintain the fancy guy's programs.· Then he quits, and the manager has a problem.· In the world of commercial and governmental data processing (my world), maintainability is almost more important even than proper working.· If it's got bugs and is maintainable by the people you have, you can fix it.· If it works OK but is unmaintainable, you're toast as soon as IRS comes out with new tax rules, or the company comes out with a new product line, or the salary bonus structure changes, or Congress decides to change the date on which Daylight Saving starts.· Or whatever.· On the other hand, as a consultant I made a very nice income because many companies couldn't maintain their own 370 assembler language.· I could.
But, you know what?· The Propeller is wacky some ways, but I like the darned thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
NTSC standard is interlaced 60 fields per second, interlaced in two ways:
1. Scanlines are interlaced every other frame.
2. Color is interlaced every other scan line.
A full, to spec, signal then has four different permutations that together build the image you see. It's a complex affair, and the Parallax reference TV drivers do generate a full, proper NTSC signal. (there is lots of good learning in that driver, but it's not easy)
There is a subset of the NTSC standard that's been in common use for a long time. Most early computers used it, and that's the NON Interlaced NTSC signal.
Like the standard there are two levels of this.
Non-Interlaced scanlines are very frequently seen. The half scan is omitted, thus turning each field into a frame, and that display does, in fact, update 60 times per second. Game consoles, home computers and lots of other things generate this type of signal. Vertical resolution is one half of the possible resolution. However, speed is doubled.
This is significant because frame rates below 60 Hz are a problem when looking at detail material, unless the display being used has a high persistence, and even then, motion artifacts are a problem. The non-interlaced signal more or less solves both of those, seeing wide use as a result.
Given non-interlaced scanlines, it's still possible to choose either interlaced or non-interlaced color. The Parallax driver is capable of generating either interlaced scanlines or not, but it only produces interlaced color signals.
If you look at a screen with two contrasting colors, say red on top of blue, you will see dot crawl on the display. This is the interlaced color, where subtle phase shifts are done every other scan line to increase the color resolution of the device.
Non-interlaced color uses a fixed color timing every scan line, and that too was often seen in home computers and game systems. Animated objects can suffer significant degredation when combined with interlaced color. Objects in motion see the same, and both can get very ugly.
Fixed color timing has an upper limit of 160 pixels of horizontal resolution in color, in the NTSC safe area. This can be pushed at bit as most newer devices will perform well up to about 256 pixels. Above 160 pixels, again in the safe area, some color artifacts will be seen as the luma information is seen as color information, due to the 3.58 Mhz color reference signal period.
There are a number of drivers here that use the simpler encoding, and they are easy to understand. Bamse, CardboardGuru and myself have written drivers that use the simple NTSC encoding. A quick look through one of those will teach you about the video generator, without also having to learn complex propeller code, and complex signal encoding at the same time! SIMPLE_NTSC, written by Cardboard Guru is a great place to start. I've built both character and bitmap drivers off of that.
search.parallax.com for SIMPLE NTSC, or 8x8, or 50 line video driver. propeller.wikispaces.com has a graphics driver section, with most of those things linked in, as well as a discussion on color for the simpler NTSC encoding. You might also find AiGeneric, a color text driver, initially written by me, significantly added to by Hippy, and bundled into something pretty damn useful, with SPIN ports of most all of TV TEXT by Oldbitcollector useful as a drop in replacement for TV Text. In addition to the simple video encoding, it's got fonts and all the advantages that encoding brought to the table then, now for the Propeller. That one uses an 8x8 font, and delivers 40x25. Nice for TV. IMHO, nicer than TV text, because of the simpler encoding and smaller overall character size are both better aligned to what a TV can display.
Most people that build a driver, either work from the core spec forward, or derive something built already, modifying it to suit their purpose.
That's as good as it gets right now on the state of Propeller video development documentation. Kind of a black art, but a FUN one!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 2/18/2009 11:29:25 AM GMT
I do have a problem with "A := B == C" where things start to look confusing and error prone as in the C language "if (a = B == c)..."
Yep, I'm unlikely to remember precedence rules if there are more than two[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But I'm going to bag the whole idea for the moment.· Perhaps after my RDF is working without it I'll come back to add·it.· I've provided for that in the hardware design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Glad you are here Carl. There have been some GREAT discussions that fall out of your queries.
I like A := (B == C), but only when the parenthesis are used to delineate the conditional. There are times when it's good to capture the state for use later. Also good for limits on counters and other simple constructs that normally would see an if then else to realize. Good old Atari basic permitted these, and it was faster then to use them! So... I did!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
You've come to the heart of the continuing argument between efficiency and simplicity and transparency. It's not as simple as you present. It may be very important to have several different ways to write A = A + 1 because they may superficially appear to be the same, but may, in fact, be different. I've worked on large, heavily managed programming projects and the typical management style is very rigid. It produces code that usually works and, with the right management, can be reliable, but is rarely innovative, usually inefficient. As has been shown with Lockheed's "Skunk Works", it is indeed possible to produce high quality, reliable, cutting edge stuff whether hardware or software. It's difficult, requires a small team of unusually talented technical and managerial talent that's highly motivated to produce quality products. I've been on such projects and they do work (including the production of accurate, detailed documentation). The costs are similar because of the larger infrastructure and lower efficiency of the "traditional" project management. On the other hand, there are higher risks involved with a "Skunk Works" type of structure. You may not be able to get the people you need. You may have meddling from higher up. The project itself may be intractable.
I could write I := 1 << N
Or I could write I := |< N
The 2nd case is simply shorthand for the first, but is also a less general form, probably uses only a single stack argument (N) instead of two arguments (1, N). An optimizing compiler could recognize the first form into the 2nd, but the Prop tool doesn't even do constant expression folding without being told to, so it probably doesn't do much code optimizing either.
I could write N := N + 1
Or I could write N++
In this case, the ++ can become a single increment op, requiring just one argument, as opposed to a general 'add' operation requiring two arguments and a result. Again, the compiler could figure that out, but if it doesn't, it's nice to be able to specify it to improve the efficiency of the code.
As for the precedence rules, I pretty much always use parenthesis so I don't need to remember them, or require anyone else to when reading my code.
Jason
I wish it were documented how the compiler figures things out.
I believe programmers either have PascalBrains or C_Brains, Pascal people wear out the middle of the keyboard first and C people wear out the keys around the edge. Spin seems kinda bipolar to me.
A = (--B && ^C++) ? B : C
C code like that makes me want to act out violently. Spin has a few quirks that have had a similar effect on me until I realized what was going on. I still get tripped up by the difference between >= and =>, but I'm getting used to it. I also find myself inadvertently typing := into my C++ at work, which is beginning to get annoying. [noparse];)[/noparse]
Jason
I wear out Pgup/Pgdn, delete, backspace, arrows, and enter far sooner than anything else.
·
For those not familiar,
Value := x < 5 ? 7 : b + 4
is equivalent to
IF (x < 5)
··Value := 7
ELSE
··Value := b + 4
-Phil
The center of my keyboard is shiny ... don't do much browsing.
I like chains of tertiary conditionals [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Jason