Assembly: Can bad programming damage hardware?
RedNifre
Posts: 84
Hello there!
I plan to learn propeller assembly language so I can write a video driver for my Hydra console. The thing is this: I'm a software-guy. I never did any low level stuff or anything hardware-related. So I guess I have a lot of superstitions about low level programming.
1. How hard is it to learn assembly language, if you already know high level languages?
2. Is it possible to damage the Hydra or my TV with bad programming/signal generation etc.? (My TV is relatively new)
3. Lets say I want to fill the entire screen yellow (just for practice). How hard would it be to write an assembly program that does this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Unterwelt (My first game for the HYDRA):
http://forums.parallax.com/showthread.php?p=696204
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788
I plan to learn propeller assembly language so I can write a video driver for my Hydra console. The thing is this: I'm a software-guy. I never did any low level stuff or anything hardware-related. So I guess I have a lot of superstitions about low level programming.
1. How hard is it to learn assembly language, if you already know high level languages?
2. Is it possible to damage the Hydra or my TV with bad programming/signal generation etc.? (My TV is relatively new)
3. Lets say I want to fill the entire screen yellow (just for practice). How hard would it be to write an assembly program that does this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Unterwelt (My first game for the HYDRA):
http://forums.parallax.com/showthread.php?p=696204
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·</Parallel Universe>
If you were driving a vector display (the kind of display where you have direct control over the electron beam) you can do potential damage by directing the beam at one location for an extended period of time and burning the phosphor in a small area. An NTSC monitor/tv doesn't give you direct control of the beam, so you can't make it do anything damaging. All you do with bad code is make ugly video, so fire away!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
LCDs can be really finicky about the timing of thier signals and the Prop's output·will look horrible, but I've never seen any situation where anything was damaged.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Also, from my experience with programming video, most new TV's (LCD and CRT)·don't care what you do during the vertial sync period.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·</Parallel Universe>
I suspect an electrical path has been created from a spark jump across dust or some other thing. That was probably from transient higher voltages, or somebody here who knows way more than I do can tell us, that exceeded the conductivity barrier normally good enough to prevent things like this from happening.
Probably time to whip out the silicone and try to close that path down, or just let the older CRT go die a peaceful death. I've used the silicone back a number of years ago, on older TV's to get a few more years out of what was otherwise a good set, but got too dusty...
So, I think stuff can happen through programming, but only for those devices where touchy analog elements are present. A newer LCD, or CRT very likely has these danger conditions filtered out before they do damage. Older gear was just trusting and really, there was little potential for bad signals anyway.
Plus an LCD just doesn't have those conditions inherent in it's design in the first place. Agreed on no harm done with poor / out of spec signals.
Edit: I kind of like older analog display devices, because they will just display what you send them, and they do it quick! That helps see problems and such, and that is a help when no scope is available. (One is on my xmas list, trust me! Video things are so much better with one, than without.) This experience was kind of a bummer...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Post Edited (potatohead) : 11/7/2008 6:22:41 PM GMT
As soon as I have time I'll learn how to write a graphics driver in assembly.
If you never hear from me again I probably made a programming mistake that made my Hydra create a black hole.
Wish me luck! [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Unterwelt (My first game for the HYDRA):
http://forums.parallax.com/showthread.php?p=696204
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Modern CRTs (And LCDs) are bomb proof; in fact the only things that aren't any more are raw LCD panels, which bad timing can cause to boil
It's an 80's era Zenith. Silicone worked and the thing is quiet again. I'll just be a bit nicer to it going forward. Don't know about others here, but I'll often go scrounging through the thrifties looking for stuff I can cannibalize, or just use. The Zenith is a little 7" CRT and it's got great color and a very nicely converged tube. I kind of liked it, and it was only $5. I did take it apart and modify the yoke position some to get a 5" square, full NTSC frame for testing. Don't think that was the cause, but it's why I snagged it in the first place. Many CRT's from that era are just easy to modify in that fashion.
That took a day of move the yoke, fiddle with the little inductive adjustments, then converge with patterns from the propeller to get done, but now I've got a nice little full-frame monitor that lets me see what is happening in the overscan.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
A scope is golden, get one of those if you can. They are not all that hard to learn to use. I think you can use a sound card software scope for video stuff too. Been wanting to try that actually.
Anyway, the capture devices do have a latency and do some processing on the image. That's tough for moving objects and such, but for the core driver dev, it's no biggie. Recording short movies can let you see frame glitches and other wierdnesses, and seeing the full overscan is nice too. The s-video option is good for seeing the video minus the color. It's possible to see the actual color sub-pixels and to tell if interlacing and such is working properly.
On my first driver project, I used a very tolerant SONY TV, and it worked well. It was a PITA to see transient effects though. When I started with a capture device, things progressed much faster, and I'm sure it came down to being able to just step through the frames to see what happened exactly, and when.
I like to use a real CRT for fine tuning. One example of this is keying motion to the vertical blank. My capture card never does show a solid moving object. There always seems to be some signal processing between me and the graphics. Not sure what that is. Probably de-interlacing and poor sync between the computer display and such. I find working with a nice, simple CRT to be clean and clear in this respect. Some newer LCD displays won't always display things too. One example seems to be non-vertically interlaced NTSC signals. The standard calls for a half-line to be displayed so that the vertical timing puts the scan lines of even frames in a different place on the display, compared to the odd frames. Most early computer gear used this kind of display to cut flicker and to make good use of limited RAM and overall graphics throughput.
Some of the LCD devices I own, have trouble with these displays. [noparse]:([/noparse] Others do it just fine.
I'm lucky enough to own a newer plasma set. (was an early Xmas gift) That thing does a lot of processing on analog NTSC signals, and it acts a whole lot like the capture card. I don't like it all that much, unless it's getting a digital display (HDMI, encryped to the max, closed $(*^&#@$(%*^$%!), making it somewhat lousy for this kind of thing. I've noted between frame pixel artifacts on what should be clean and clear images. Haven't had time yet to send it a bunch of test signals, but I'm going to someday. An example of this would be some text changing. Say it's the letter A on one frame, and the letter H, on another. What I end up seeing is the A, then A plus some of H, then H over maybe three frames. With DVD movies, this works ok, because the frame rate is only 24 frames / second. Don't notice it at all. On 60Hz non-interlaced displays, I see it clearly.
Dang, this post is getting long. Sorry!
To sum it up, I think there is a difference between the core driver functionality, which is sync, color, pixel size, etc... And what happens with that driver, which is the actual graphics over time. Better to use a CRT for the moving stuff, and the capture / LCD for the core signal, IMHO. I would add to that using a baseband (composite) input, not a rf-modulator. Those things can introduce artifacts at both the core signal level and the pixel level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net