FOR THOSE OF WHO ARE NOT CODE WIZARDS
pilot0315
Posts: 910
in Propeller 2
I know that may of you like @"Dave Hein" and @msrobots and others who are wizards in coding know this stuff in a fenominal to us who just simply code.
Would it be possible that you could give us links to better understand operating systems, loaders, and compilers so that we can better understand the basics of
what you are working with.
I and many others would be most interested so we can better understand what we are working with.
I wrote some mini tutorials from a teacher standpoint for my self and put them on the forums. I think if you could supply some links, that I would be able to better understand and
later impart that to the wizards in making.
thanks.
More of how it works so I can translate it to myself and others. So we do not get so dizzy and pass out.
Thanks again
Martin
Would it be possible that you could give us links to better understand operating systems, loaders, and compilers so that we can better understand the basics of
what you are working with.
I and many others would be most interested so we can better understand what we are working with.
I wrote some mini tutorials from a teacher standpoint for my self and put them on the forums. I think if you could supply some links, that I would be able to better understand and
later impart that to the wizards in making.
thanks.
More of how it works so I can translate it to myself and others. So we do not get so dizzy and pass out.
Thanks again
Martin
Comments
I could not afford the FPGA boards and jumped in with the ES. But I am following the P2 since its beginning 8-10 years ago almost religiously, and barely miss any posts.
So I have basic understanding why things are done like there are done. That helps to understand the two Google docs better. Else I just use try and error and lots of post in the very helpful forum.
As of what I am using - Windows 10 and fastspin. That uses p2load as loader.
My P1 projects and playground was the PropTool and since I play with the P2 my P1s are in a box. But I will try fastspin on the P1 soon.
As of tutorials, hmm - not really my world. I read other persons code and try to document mine heavily to avoid the following
Enjoy!
Mike
OS design/build is a very open ended matter. There is no end to how big it can go. Or it can be contained in the language and a bunch of libraries that you compile into your target binary.
The loaders/programmers aren't anything huge usually. Just getting the hardware/OS to play ball is the challenge there. Compatibility issues tend to show up a lot.
Point is, is that for me anyway, a flow chart is a way to easily visualize critical points of a program in a rough draft sort of way. My mind can work through a flowchart much easier than line after line of code. Even when I go to bed at night, I can run through a flowchart in my head much more efficiently than I can with lines of code. In a way visually, that's sort of what "BlocklyProp" and other similar programing structures do, but it's no flowchart. I prefer to have more control over my programming.
...And to put a plug out there to one of our forum members. I owe a lot of my programming style and structure techniques to Jon Williams.
I am an amateur. Have written some code on just about everything. Many people pick this stuff up by example, but that can be hard and time consuming. There is a method I was shown long ago that I want to share with you. It's useful. For me, it is what I always return to when faced with something new.
What you can do is compartmentalize. It's best to focus on a thing at a time. Having a working example is also best. It can be anything. We've got some example code, and that's where you can start. Starting simple is better.
So, get yourself ready. This is prep.
First thing: (If you have a pre-built binary)
Make it run.
Second thing: (If you just have example code)
Build it yourself, and then make it run.
Third thing:
Begin reading it.
You want to make sure it runs, so you eventually can test what you know by changing it. And when you change it and it does not work, you can know it's what you did, not some silly thing that may have happened otherwise.
If you want to go old school, print it out. Shorter programs are better. New school is to open a copy of the code in your favorite text editor / word processor. Does not matter which one you do.
Here is where the magic begins:
No matter what the kind of program is, BASIC, PASM, C, SPIN, you want to break it down into five rough categories. If you are working old school, get yourself a few highlighters. Colors.
The categories are:
Program flow and control: IF, THEN, BRANCH, FOR, NEXT, etc... Your loops, decision points, and all that get one color.
Computation: Math, bit operations (XOR, AND, NOT), these get another color, and you get the idea here. Colors.
Data operations: Indexes to arrays, fetches, writes, reads, and other things that get done with or to data
Data: This is not code, but the stuff code works with. Yes, they can be one and the same, but baby steps here first. Strings, pictures, initial values, constants, all givens, essentially. This can include data the program generates too.
Configuration: System level stuff, smart pin modes, pin directions, clocks, and all the spiffy hardware bits in the chip count.
Start with the program flow and control. Look through the program to identify places where flow changes. Highlight those. Keep going, until you have a good idea of the overall flow. I really like looking at flow first because that tends to suggest where the parts of the program are. At the low level, like assembly language, it's a big deal. At the higher level, parts are more clear, but flow always helps me.
As you run into the others, mark them too. You can be opportunistic, but critical. If you don't know, don't color it.
If you don't know, skip it. You can return later when you understand better. Focus on what you do know.
At some point, things will become obvious, or you get questions. Either is fine. They both are progress! Where you believe you understanding something, write a comment. If old school, use pencil for these. If you have a question, write that down too.
For bonus points, where the same comment or question comes up, tag it with a marker. I use brackets and numbers / letters.
eg:
'why does this need to be here? [1]
That way, you can consolidate some of what you are working with. And if you are not sure, don't do it. Again, focus on what you know, and that includes better understanding what you don't know! Both are high value.
Continue writing comments. And continue coloring things too. This is all incremental. It takes many passes to really grok a new program. We often forget how intense that process is when we are comfortable, or have been doing it for ages. I personally will go some longer periods of time between programming. It's the nature of my work personally. I do return to this method when I have been away. Gets me back in the game fairly reasonably.
Good comments come from pretending you are writing them to your good friend. Take that style. It's super helpful, and in a way, you are doing exactly that. Today you is helping future you, and you are great friends with you. See?
Over time, you will be familiar with a lot of the program. Future you will be super happy about that.
Test what you know. Change a thing. Did it do what you expect? Change it again. Trace that thing back to other related things, make comments. Wash, rinse, repeat.
For the questions, you can start asking things here, like all of us do. But, sometimes it's not enough, or it's hard for others to understand where you might be at. That's fine.
This process should lead you to good questions. If anything, others can point you to stuff you can read, or watch and take it in at your own pace. Or maybe you can get answers.
I would continue, until you are pretty sick of the program you are looking to understand. The end game is you can say something meaningful about every single line in it.
I really struggle with easy ways for others to pick up on all those things. Here's an example:
This book on linkers and loaders is awesome: http://index-of.co.uk/Exploit/Linker&Loaders.pdf
I consider it a very good reference. But, it's a full treatment too! If you plow through that one, I assure you your understanding of those things will improve, but so will the number of questions you have! Collecting references is worth it. Just don't get fully absorbed in them, unless you have lots and lots of time.
And that is where compartmentalization gets you through. Getting a sense of priority, what you can ignore, accept today as magic, knowing tomorrow you may dig into it, matters. This all adds up, and soon you will be taking pretty big steps. However, in my experience, and I've done this a ton of times, there is no getting around just chugging through the basics.
Truth is, what most of us need is a working compiler, assembler, loader. If you can open up sample code, hit the button and see your P2 do what that program intended, then you have a working setup.
If you don't see that, then you need a working setup.
Priority?
Get a working setup.
That setup can remain magic for a while. That leaves you free to focus on the program. Understand it, change it, then maybe write one of your own.
That applies to this whole process in general. Keep your scope small. Take the magic for what it is, until you are ready to get after it.
And that brings me to the last bit of advice:
What are you wanting to do? Does not matter what it is, just that you have nailed it down some.
It could be you have some goal, specific, control something, or whatever. That's fine. It could also be that you don't even know what is possible too. All good.
Worst case, take your sample program, look at what it can do, and make a project for yourself that you think might be possible given the bits in your sample.
Then do that.
In general, it's possible to keep the scope of stuff you are struggling with small. The stuff you know is your base. Work from your base, even if some of it is monkey see, monkey do magic. The stuff you don't know needs priorities to keep it from overwhelming you and from getting confusing, discouraging.
Hope this helps.
(Super excited to know we've got MicroPython running on P2. I like it so far.)
And that brings me to one last bit:
Libraries and dependencies.
In the end, you can't ignore those. You will need to have some understanding. But, for early learning, take them at face value, just magic black boxes and focus on the program. At some point, and you will know when, you will realize full understanding of the main program just can't happen without digging into that library or dependent piece.
On P2, for example, a video display is a dependent piece. Best move is to understand what it does and just accept that it does it for now. Whatever program is doing cool stuff on the display is likely what you are interested in. Compartmentalize. Same can be said for serial comms, or other things.
What I will do fairly early on is write a small program to test my basic understanding. Maybe put a line on a display, or write out the numbers from 0 to 1000 over the serial, whatever. Just enough to know I get it, how it's used, but not so much that it takes over my focus on the main program at hand.
Again, hope this helps.
I think we all need to jump on IRC or setup a Discord for chatter. It would be kind of awesome to have some peeps to talk to in the moment.
If nobody else does this, when I get free here soon, I will.
Until then, the forum is best.
Only on occasion, like camping, etc...
Well, I suppose I could have teed up on Publison... good few paragraphs, but that's not nice. I kind of like nice.
While there are some good points in your post I don't agree about printing it out (do I use dot-matrix and fan-fold?) and highlighting it "old school" method. My code develops and changes way too rapidly but certainly a good code highlighter mode helps as does a hires screen to display a good section of your code that is clearly readable and then to have another pane side by side. That way you can follow the high level code across from one pane back into the other showing the lower levels. I also have a terminal screen where I try that stuff out a the same time.
Comments? - yes, but well written code can be self-commenting so comments should clarify, rather than obscure and bury the code.
Flowcharts and such? meh.
Since I interact with my systems in Forth I can try out ideas and methods instantly. So the ideas themselves flow, rather than the chart
Some of my stuff starts off as less than elegant, but it works. It's important to get the foundations solid before you build.
From an ugly but working proof-of-concept "breadboard" I can then make it clean, simple, and elegant.
Look for it. Let's have a chat.
Or, start it. Either is fine.
@potatohead . When y'all refer to binaries "First thing: (If you have a pre-built binary)" I am thinking of zeros and ones. Please explain.
I do try to follow a single track until I get it. Writing tutorials so that, because assm language is so different so I can refer back. Got fairly good at P1 asm and since I now have the p2 I am retooling and fleshing out the differeces.
So again thanks for the help.
Please expect more dumb questions from me.
I teach aircraft mechanics and flying so I know there is no such thing as the dumb question.
You guys rock.
Martin and thanks for the support.
I looke carefully at your post. You took some serious time in writing it.
Thanks
Source code --> Assembler -->binary -->loader -->P2
Could also be:
Source code -->Compiler say FastSpin -->binary -->Loader --P2
Uhm, Peter, were you implying that Parallax has their very own Mr. Popiel?
(For those to young to be enlightned, https://en.wikipedia.org/wiki/Ron_Popeil)
Enjoy!
Mike
The few computers used commercially were banks and govt.
Likewise, there were no microprocessors, and certainly no Micros. Minicomputers were just starting to appear.
So, back then, almost all programmers were self-taught. A few years later, the computer companies offered fairly cheap programming courses on how to program their computers.
How did I learn? I dumped the first 100 disk sectors and printed them out (like hex but the mini I learnt on was 6-bit ASCII) and decoded it. Learnt a lot!!!
No one ever wanted to see it,
Mike
I internet-know some people who wrote some code to connect IRC channels and Discord channels together (so when you say something in either, it gets repeated in the other by a bot user). I could dig that up if there's interest.
Thanks I now understand the binarie thing.
I am writing a new pasm tutorial like the one I was working on for the P1 about passing parameters between spin and pasm. Will be posting the first draft soon.
Would appreciate any critiques.
Thanks
Always good.
As time permits, I will participate.