Shop OBEX P1 Docs P2 Docs Learn Events
Machine Language Tutorial! - Page 2 — Parallax Forums

Machine Language Tutorial!

2

Comments

  • deSilvadeSilva Posts: 2,967
    edited 2007-08-26 02:46
    Joe, you can advertise your (and my) work wherever you want smile.gif
    I understand this language issue very well. This is where my work started, when persons in a German Forum - asked why they do the most astonishing things - answered: "We didn't understand the (official) documentation." or even plainly "We cannot read English".

    You may ask: And why do they use the Prop in the first place, and not one of the thousends fancy Siemens chips? Well, don't ask ME smile.gif

    A fact is, that the Propeller is prohibitively expensive in Germany. So the community is small and will stay small - that is the main reason why I post here!

    Parallax is obviously aware of language issues, otherwise they wouldn't offer translations into Spain, Chinese and Russian!

    Though I should question the effectivity of that task: A professional can and does read English - he would be lost otherwise! For the "hobby market", a Datasheet or Manual is not enough; these persons shy things like that and work on the "trial and error" route, with help from some (national!) forum.

    I think I have lost my thread now....
    What I wanted to say: When you have a local language forum or a sub-forum, this will be most likely "second class". All arguments hold that were given against the "newbies" sub-forum.
  • parts-man73parts-man73 Posts: 830
    edited 2007-08-28 03:17
    I just posted (by permission) a copy of the Machine Language Tutorial on my site - ucontroller.com/

    Click on the "Tutorials" button.

    Any suggestions for other tutorials to add....I'm all ears, I'd like to host a repository of Propeller information.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Brian

    uController.com - home of SpinStudio
  • mcstarmcstar Posts: 144
    edited 2007-08-31 14:42
    Thank you deSilva for your great ASM manual! I'm not sure exactly why or how, but reading it has helped me tremendously in understanding the assembly language for the propeller. Now I actually have the confidence to write assembly instead of spin! I've been using Gear with a deeper sense of understanding (great for protyping and learning what the COGs and Hub acutally do).

    I have one techincal correction I'd like to point out. This is not related to the propeller directly, but the scanning of the TV screen as discussed in the chapters on video regarding the need for the blanking signal. To be direct, the reason for blanking is not because of the slow speed of electrons. There is a different reason for this. To understand, think of the the electron gun as a water hose... the water spraying out of the hose are the electrons. You are holding the hose and spraying it back and forth (against a fence or something). You start at the top and spray back and forth till you reach the bottom (ignore gravity and the water's tendency to run and dribble and you have something very like the electron gun in a TV). Now the question is, what moves the stream (of electrons) back and forth in the electron gun? It's a magnetic field (look at a TV tube and you'll see copper windings on the outside of the tube that create this field for us. That field bends the electron streams (and focuses it etc). That magnetic field must be quickly brought from one extreme orientatation to the other between each scan (the TV's video processor only generates the proper signals in the right-to-left ). It is the speed at which the magnetic field collapses that determines how fast the electron stream can be brought back to the right side of the screen, not the speed of the electrons themselves! The electrons are actually being accelerated by a differential potential between the base of the gun and the front of the screen. This potential is around 20kv -30kv and is the reason tubes must be discharged before being worked on.
    IF the magnetic field could be collapsed instantly, or before the "next" electron was emitted from the base of the tube, then there would be no need for the blanking signal. But, just like our water hose example, the electrons are being emitted at a rate far greater than the speed at which the controlling field can be moved back to the other side of the screen, and without blanking you end up with extra bright lines retracing back across the screen.

    This isn't really important to your documentation, but I thought I'd point it out just in case someone finds it interesting.
  • deSilvadeSilva Posts: 2,967
    edited 2007-08-31 16:04
    @mcstar: Thank you for all you said smile.gif

    You are absolutely right with your vivid description; I just wanted to stress, that when things work "electronically" this need not necessarily mean "with the speed of light". And there have been CRTs on the market - and I think they still are - for high speed 'scopes that worked with electrostatic deflection rather than electro-magnetic.

    I think your example is also interesting in two other ways:

    (1) What if the transversal movement (of the hose or the electron beam) is faster than the speed of the electrons (or the water) itself? You move hither and thither but the electrons (or the water) has not enough time to reach the fence or the screen!
    It would not so much change for the water, flying more or less independently when having left the hose. But the electron will still be influenced by the current magnetic field, tugging at them with light speed... There is no escape!

    (2) Now we change to photons... Take one of your well focused high power voltage controlled laser guns, connect it to the Prop with an appropriate driver, and send your video in the direction of the Andromeda nebula. All right, it will arrive there a little bit later but to our current knowlegde you should be able to project some photons over the whole nebula within 1/60 second... Obviously, SOMETHING has to move faster than light then, or hasn't it?
    Keep cool! Nothing MOVES faster than light. It is just your imagination, that when you MOVE the "hose" you move the water. Try to "move" a ping-pong ball from left to right with your water beam - it will not work. And there is also no matter or information transferred from "left to right", thus Einstein was right again!
  • bozobozo Posts: 70
    edited 2007-09-01 01:01
    deSilva said...
    Keep cool! Nothing MOVES faster than light.
    well..., not strictly true ... the correct sentence is "nothing moves faster than light in a vacuum" :-)
    http://en.wikipedia.org/wiki/Cherenkov_radiation
  • Mike GreenMike Green Posts: 23,101
    edited 2007-09-01 01:16
    mcstar and deSilva,
    Regarding the blanking pulse ... I'm not sure if this was stated, but the electron beam is modulated by the video signal. The blanking pulse is intended to cut off the flow of electrons while the deflection coils (and their magnetic fields) are moving quickly to (effectively) the other side of the screen. When the electron beam is again emitted, the electrons will be deflected starting at the beginning of the scan line. The electrons are not really present in the space between the electron gun and the screen during the blanking interval. They're repelled by the control grid in the electron gun and are reabsorbed there (in the electron gun assembly).
  • Fred HawkinsFred Hawkins Posts: 997
    edited 2007-09-01 02:26
    About the blanking pulse and much of the rest of the video electron dance -- all those things were figured out by engineers using big honking tubes and indiscreet components. With sliderules. They are in our software and hardware (and tv monitors) for the sake of backwards compatibility. It's all analog, morphed lately into digital. If you toss out the history and started fresh the blanking pulse and much else wouldn't be there.
  • Ken PetersonKen Peterson Posts: 806
    edited 2007-09-01 03:10
    Isn't that half the fun? ..working with old technology and making it do new things? Kind of like chopping an old Deuce Coup! [noparse];)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-01 17:16
    @Mike, @Ken, @mcstar: It seems I did not think deeply enough before writing my article smile.gif I was commenting the oscillogram of a video signal and fell into the old habit of "visualizing".
    It should in fact be more interesting to discuss the timing of the porches, as they are used and needed with TFT also - and especially for Propeller drivers!

    Nevertheless, the reasoning should consider the inertia of the magnetic field, not the speed of the electron beam! I shall change some phrases shortly - Thank you all!
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-09-04 21:30
    deSilva,

    Finally got some alone time, was actually less work than I imagined, I've marked a few areas in red which you may want to take a look at otherwise I just changed the odd word, you can still tell its you [noparse]:)[/noparse]

    Another thing I noticed were some tags to set the font bold here and there and also some upside down speach marks. I think I got most of them but it might be worth searching.

    Graham
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-04 21:43
    Thank you Graham! I had hoped you would still need some time smile.gif But I have also some updates here, and it will be enough to post a version 1.3 during the next days....
  • epmoyerepmoyer Posts: 314
    edited 2007-09-05 07:36
    This block of code


    :w
      LOCKSET semaNumber WC
      IF_C JMP :w
      RDLONG a, countAddress
      ADD a, delta
      WRLONG a, countAddress
      LOCKCLR semaNummer
    
    



    has some errors

    the jump needs a '#', and semaNummer should be semaNumber
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-05 19:01
    Damn! When translating it I was was quick with the editor. Some variable names were German and I changed them to Englisch - well most at least smile.gif
    The label bug - well, I think it had never been waiting smile.gif
  • epmoyerepmoyer Posts: 314
    edited 2007-09-07 01:12
    One thing that would be helpful to put in your doc (I did not check to see if it was already there; forgive me [noparse]:)[/noparse] is a table of >, <, =< etc. implementations in asm. For beginners those things are often hard to figure out, and for myself I always have to think through the math when I code them.

    For instance...

              cmp  A, B  wc wz
    
    if_c      jmp #label1             ' if(A<B)
    if_nc     jmp #label2             ' if(A=>B)
    if_z      jmp #label3             ' if(A=B)
    if_nz     jmp #label4             ' if(A <> B)
    if_c_nz ...
    
    
    



    ...but fill the whole table out for all the flag combinations (if_c_nz, if_nc_z, etc.). Having it in one simple table would be so handy I'd print it out and use it myself [noparse];)[/noparse]
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-07 06:10
    Good suggestion! I'll do!
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-09-07 07:28
    I have been meaning to make a table like that for my own use! Because although I know there is a logic to it all I can never remember what it is.

    Graham
  • rjo_rjo_ Posts: 1,825
    edited 2007-09-07 14:33
    deSilva,

    This lights up an LED attached to pin 4. Why?

    Rich
    180 x 126 - 10K
  • potatoheadpotatohead Posts: 10,261
    edited 2007-09-07 15:07
    Isn't the first pin numbered zero?

    Are you counting pins from zero?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
  • rjo_rjo_ Posts: 1,825
    edited 2007-09-07 15:22
    Dear Mr. Potatohead,

    yes sir... but I don't understand how this works.

    If I add another long 0 to the end and substitute a "4" for the "3" it also works.

    I'm missing a concept here[noparse]:)[/noparse]

    Rich
  • rjo_rjo_ Posts: 1,825
    edited 2007-09-07 15:27
    It also lights up an LED on pin 5 but not on pin 6... AND there are others, but my board is so full of odds and ends that I can't get an exact fix on exactly what is happening ;>)
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-09-07 15:59
    mov outa,#3

    Graham
  • rjo_rjo_ Posts: 1,825
    edited 2007-09-07 16:09
    Graham,

    I wasn't asking how to do it. I was wondering why it works[noparse]:)[/noparse]

    I understand: mov outa, 3

    to mean: move the contents of register 3 into outa

    ... but register 3 is empty.

    Rich
  • mcstarmcstar Posts: 144
    edited 2007-09-07 16:52
    rjo_ to answer your question, I saved the code you posted to a binary and loaded it up into Gear.· With this you can see that the short answer to your question is that register 3 is not empty, but infact contains the value $35088734, which is written to the outa and is responsible for the various pins lighting up.· What's very interesting is that your entire program fits into only 3 longs 00-02 and register 03's value is set to the instruction IF_NC_AND_Z.· There are several other codes in 05-07 that seem extra as well.·The real question is why are those codes there if your code did not set them? I assume the compiler added them, but I don't know what for...confused.gif very curious.· Does anyone else·know why·these instructions are added after his code?

    Post Edited (mcstar) : 9/7/2007 5:06:27 PM GMT
    540 x 137 - 28K
    215 x 82 - 6K
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-07 16:57
    COG cells start with zero, so it's not 3 or 4 you want, but 2 or 3.
    Have a look into the memory dump ("F8"); you will see what's allocated behind your LONG 0 smile.gif
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-07 17:00
    mcstar said...
    r..... why are those codes there if your code did not set them? I assume the compiler added them, but I don't know what for... confused.gif very curious. Does anyone else know what these instructions are for

    No. This has been explainined many times before.

    Loading a COG is a hardware feature. It loads 512 words (with some tricks wrt to the last 16) whatever may be there in the HUB....

    It has some meaning wrt SPIN for the SPIN loader
  • mcstarmcstar Posts: 144
    edited 2007-09-07 17:07
    Ah, right, I suppose I do remember that now. The moral then is not to assume that any register beyond your code is initialized then.
  • rjo_rjo_ Posts: 1,825
    edited 2007-09-07 17:40
    I knew it was one of those things that lights up in my brain... and then drains out again.

    I was just thinking about that process last night (no sleep). But when I got to a question that required recalling that fact... it was gone.

    I knew you would see it.

    Thanks again deSilva.

    Rich
  • rjo_rjo_ Posts: 1,825
    edited 2007-09-07 17:42
    But where do the exact values come from?... shouldn't everything be empty after that?
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-07 17:51
    deSilva said...
    Have a look into the memory dump ("F8"); you will see what's allocated behind your LONG 0 smile.gif
  • mcstarmcstar Posts: 144
    edited 2007-09-07 18:13
    So, for the example rjo_·posted, anything after cell/register 0018 (four bytes per·long register)·is free and initialized to 00, thus you should be able to use it freely right? BTW, deSilva, I feel so enlightened since reading your manual!
Sign In or Register to comment.