Assembly programming
Re: Assembly programming
BTW, for 65C02 benefits, and other benefits, Acorn's BBC Master is a good machine to choose: it's bigger and heavier than the Beeb, but has a 65C102 and (in various ways) more RAM, and a faster Basic.
Re: Assembly programming
...and the BASIC in the original Beeb wasn't exactly slow to begin with.
Re: Assembly programming
@Kris1978 - even though you don't enjoy it, it is one of the noble professions and I am sure you have the thanks of many 
If I understand right, you are looking to learn assembly as an intellectual challenge in something you have an interest in - good reasons. I agree with whartung's observation that having a problem to solve would give some objective to the new knowledge you will be acquiring.
I learnt assembly language in the early 80s when still at school - I had outgrown the BASIC language that my Oric-1 computer provided as it was not fast enough. I started writing in hex because I couldn't afford an assembler which limited the complexity of what I could do. Anyway to cut a long story short, after having written my own assembler in BASIC, I was able to write chunks of machine code that were called from BASIC such as screen and sprite drawing routines.
I moved on through Atari (still 6502 based) to Amiga which was 68000 - what I found was that many of the structured thinking required for programming, especially at assembler level, were still relevant on a much more complex CPU. I am sure you will find the same, and so the learning is re-usable.
So to my main point related to whartung's post - I have also programmed in high level languages such as C, C++, Java and C#.net. Whenever I tried to learn a new language, I set myself a task of creating a simple game such as space invaders, pac-man or tetris!
Why a game? Because it is fun to play once working
Why not a different game? Because I already know the overall logic and structure of the program, I simply need to apply that to my target platform and language.
Of course if you are also new to progamming then you need to take smaller steps - but sounds like you may have had programming exposure already, if so build on that.
Good luck with your adventure, I really think you will enjoy it
If I understand right, you are looking to learn assembly as an intellectual challenge in something you have an interest in - good reasons. I agree with whartung's observation that having a problem to solve would give some objective to the new knowledge you will be acquiring.
I learnt assembly language in the early 80s when still at school - I had outgrown the BASIC language that my Oric-1 computer provided as it was not fast enough. I started writing in hex because I couldn't afford an assembler which limited the complexity of what I could do. Anyway to cut a long story short, after having written my own assembler in BASIC, I was able to write chunks of machine code that were called from BASIC such as screen and sprite drawing routines.
I moved on through Atari (still 6502 based) to Amiga which was 68000 - what I found was that many of the structured thinking required for programming, especially at assembler level, were still relevant on a much more complex CPU. I am sure you will find the same, and so the learning is re-usable.
So to my main point related to whartung's post - I have also programmed in high level languages such as C, C++, Java and C#.net. Whenever I tried to learn a new language, I set myself a task of creating a simple game such as space invaders, pac-man or tetris!
Why a game? Because it is fun to play once working
Why not a different game? Because I already know the overall logic and structure of the program, I simply need to apply that to my target platform and language.
Of course if you are also new to progamming then you need to take smaller steps - but sounds like you may have had programming exposure already, if so build on that.
Good luck with your adventure, I really think you will enjoy it
Re: Assembly programming
Chromatix wrote:
...and the BASIC in the original Beeb wasn't exactly slow to begin with.
Re: Assembly programming
dolomiah wrote:
Sophie Wilson is in my view in the same league as Woz - or maybe even beyond considering she was a key designer of the ARM chips which are in nearly all our mobile phones and IoTs...
Re: Assembly programming
dolomiah wrote:
Whenever I tried to learn a new language, I set myself a task of creating a simple game such as space invaders, pac-man or tetris!
At the time, for the life of me, I couldn't figure out how to identify what alien got hit, so each alien had it's own distinct letter in the middle of it. When my shot "hit something", it would "look around" to try and find the middle character to identify the alien.
Later, I was dabbling in assembly language (same machine). I was working on the routine to move the base back and forth.
I fired it up and when I went left, just went to the left edge. When I went right, to the right edge. I couldn't understand why it was just jumping!
After much tracing and head scratching, I figured it out. It was working perfectly, it was just too fast!
Re: Assembly programming
@BigEd - Okay, okay, okay...I will try an emulated BBC Master!!!! Okay BigEd! Viva the UK! Viva England! 
@dolomiah - "If I understand right, you are looking to learn assembly as an intellectual challenge in something you have an interest in"
YES!!!!! EXACTLY THAT'S WHAT I HAD IN MIND!!!!
(English is not my native language, so I'm trying my best to "translate" my greek thoughts into english sentences. Sorry for any misconfusion)
Although, a minor reason would be to make a game on my own. I'm leaning towards game development. It was my child dream. It's the field of technology that I like most. (I already wrote that I've tried to make classic point'n'click adventure games [Sierra On-Line style] with the help of the AGS engine and I failed after many attempts. Scripting language [with a C-like syntax I think] on AGS is very simple if you want to do simple things, like I did. I didn't dive into learning it, to it's full. Time consuming tasks were also drawing, animation loops, a bit of dialogue, puzzles and many other things).
"I agree with whartung's observation that having a problem to solve would give some objective to the new knowledge you will be acquiring."
So, you're suggesting me, while learning assembly language, start making a computer game, at least a simple one.
Guys!!! I'm on page 90 of Rodnay Zak's book and page 56 on Randal Hyde's book.
I feel that I'm still learning the basics!!! How graphics are made on the screen is still a HUGE UNSOLVED MYSTERY for me! How the heck am I supposed to sit down and write a simple(?) game on my own....from scratch, even a clone of the Asteroids or Pac-Man or Tetris?
My initial message on this topic had to do with the need for guidance in practising all that information I've read so far on the books. Because obviously programming is not only reading, it's mainly practising/writing-creating programs.
P.S. I knew GW-BASIC [MS-DOS era] when I was 15 years old [25 years ago] though my knowledge level was sub-intermediate. Plus, I forgot almost everything.
P.S1. I work, as I said for 8 hours everyday. I'm single, living on my own. That means I have to care about cooking, cleaning, ironing, paying the bills, sleeping/relaxing, etc. Besides I want to have fun, like going outside, meeting friends, playing video games, reading books, watching movies, listening to the music, etc. I don't have 24 hours free, just focusing on learning assembly language. Actually, even if I could, I wouldn't like to do something like that.......
@dolomiah - "If I understand right, you are looking to learn assembly as an intellectual challenge in something you have an interest in"
YES!!!!! EXACTLY THAT'S WHAT I HAD IN MIND!!!!
(English is not my native language, so I'm trying my best to "translate" my greek thoughts into english sentences. Sorry for any misconfusion)
Although, a minor reason would be to make a game on my own. I'm leaning towards game development. It was my child dream. It's the field of technology that I like most. (I already wrote that I've tried to make classic point'n'click adventure games [Sierra On-Line style] with the help of the AGS engine and I failed after many attempts. Scripting language [with a C-like syntax I think] on AGS is very simple if you want to do simple things, like I did. I didn't dive into learning it, to it's full. Time consuming tasks were also drawing, animation loops, a bit of dialogue, puzzles and many other things).
"I agree with whartung's observation that having a problem to solve would give some objective to the new knowledge you will be acquiring."
So, you're suggesting me, while learning assembly language, start making a computer game, at least a simple one.
Guys!!! I'm on page 90 of Rodnay Zak's book and page 56 on Randal Hyde's book.
I feel that I'm still learning the basics!!! How graphics are made on the screen is still a HUGE UNSOLVED MYSTERY for me! How the heck am I supposed to sit down and write a simple(?) game on my own....from scratch, even a clone of the Asteroids or Pac-Man or Tetris?
My initial message on this topic had to do with the need for guidance in practising all that information I've read so far on the books. Because obviously programming is not only reading, it's mainly practising/writing-creating programs.
P.S. I knew GW-BASIC [MS-DOS era] when I was 15 years old [25 years ago] though my knowledge level was sub-intermediate. Plus, I forgot almost everything.
P.S1. I work, as I said for 8 hours everyday. I'm single, living on my own. That means I have to care about cooking, cleaning, ironing, paying the bills, sleeping/relaxing, etc. Besides I want to have fun, like going outside, meeting friends, playing video games, reading books, watching movies, listening to the music, etc. I don't have 24 hours free, just focusing on learning assembly language. Actually, even if I could, I wouldn't like to do something like that.......
Re: Assembly programming
It's a great goal, and it's certainly possible. I think you need to start with the simplest games: pong, breakout, snake. Even tetris is probably a second-level game.
But I'm sure as soon as you start to light up pixels on the screen the process will be very rewarding!
But I'm sure as soon as you start to light up pixels on the screen the process will be very rewarding!
Re: Assembly programming
For low-resolution "graphics", use text characters instead of drawing graphics. On most micros, they can easily be placed on a regular grid on the screen; that's sufficient for simple games like Pong and Breakout. In the old days, there were many "adventure" games that didn't even do that, and could technically be played on a line printer.
The BBC Master gives you much more sophisticated graphics facilities through the VDU interface, which can easily be driven with repeated calls to OSWRCH at &FFEE. BASIC exposes these using MOVE, DRAW and PLOT keywords, as well as giving you direct access through the VDU keyword. Or you can just use Teletext low-res graphics: https://bitshifters.github.io/jsbeeb/?d ... del=Master
The BBC Master gives you much more sophisticated graphics facilities through the VDU interface, which can easily be driven with repeated calls to OSWRCH at &FFEE. BASIC exposes these using MOVE, DRAW and PLOT keywords, as well as giving you direct access through the VDU keyword. Or you can just use Teletext low-res graphics: https://bitshifters.github.io/jsbeeb/?d ... del=Master
Re: Assembly programming
The suggestion is that you write a computer game that happens to use assembly language.
Appreciate the contrast. Assembly language programming encompasses some arbitrarily large domain of knowledge (opcodes, addressing modes, assembles, linkers, computer architecture).
A computer game is a set of discrete tasks that come together to make up the game. You have the problems of getting input from the user, creating output (text, graphics, blinking lights, sounds, whatever). You have the problems of implementing the games logic, and scoring, and all the other mechanics.
As you focus on the game, on the components of the game, they give you a specific little subset to work on without distraction from everything else. Reading a character from a keyboard, for example, doesn't have anything to do with making a speaker beep. "How do I make a speaker beep!!??" Doesn't matter. You don't care. All you want is a character from the keyboard.
Now, what instructions and tools and what not do you need to from the wide array of assembly language are necessary to read a character from the keyboard? Well, that's your task for the day. Find the overlay between the two to finish that one task.
In the end you have accomplished two things. One, you've read a key from the keyboard. Two, you've done it in assembly language.
You are now closer to your game being finished, and now more adept in your knowledge of assembly language.
Tools are useless in a vacuum. Only when applied do they make sense, so it's best to have something to apply them against. As with most programing languages, there are no doubt more than one way to "read a key from the keyboard" in assembly language. But for your case, you need only one. With experience, you may later come back and say "Ya know, it would be better if I did it this way instead".
But right now, you don't have the experience to say that. So, anything will work.
When you game is done, you will have something in assembly language. You may well find that you are quite comfortable with a distinct subset of the entirety of the assembly language toolset in order to get your game finished. It's striking how many tools are NOT in my garage, yet, somehow, despite my best efforts, the house has not, yet, collapsed on itself.
So, by writing a game, and finishing the game, you will find at the end that you will have just the amount of tools you needed to complete the project, but now you will have a lot more experience for when you start on your next one, and you can use that experience to decide if the toolset you used the first time will be adequate for the next time.
And I suggest writing a game, because writing financial or healthcare software is dull and boring.
Appreciate the contrast. Assembly language programming encompasses some arbitrarily large domain of knowledge (opcodes, addressing modes, assembles, linkers, computer architecture).
A computer game is a set of discrete tasks that come together to make up the game. You have the problems of getting input from the user, creating output (text, graphics, blinking lights, sounds, whatever). You have the problems of implementing the games logic, and scoring, and all the other mechanics.
As you focus on the game, on the components of the game, they give you a specific little subset to work on without distraction from everything else. Reading a character from a keyboard, for example, doesn't have anything to do with making a speaker beep. "How do I make a speaker beep!!??" Doesn't matter. You don't care. All you want is a character from the keyboard.
Now, what instructions and tools and what not do you need to from the wide array of assembly language are necessary to read a character from the keyboard? Well, that's your task for the day. Find the overlay between the two to finish that one task.
In the end you have accomplished two things. One, you've read a key from the keyboard. Two, you've done it in assembly language.
You are now closer to your game being finished, and now more adept in your knowledge of assembly language.
Tools are useless in a vacuum. Only when applied do they make sense, so it's best to have something to apply them against. As with most programing languages, there are no doubt more than one way to "read a key from the keyboard" in assembly language. But for your case, you need only one. With experience, you may later come back and say "Ya know, it would be better if I did it this way instead".
But right now, you don't have the experience to say that. So, anything will work.
When you game is done, you will have something in assembly language. You may well find that you are quite comfortable with a distinct subset of the entirety of the assembly language toolset in order to get your game finished. It's striking how many tools are NOT in my garage, yet, somehow, despite my best efforts, the house has not, yet, collapsed on itself.
So, by writing a game, and finishing the game, you will find at the end that you will have just the amount of tools you needed to complete the project, but now you will have a lot more experience for when you start on your next one, and you can use that experience to decide if the toolset you used the first time will be adequate for the next time.
And I suggest writing a game, because writing financial or healthcare software is dull and boring.
Re: Assembly programming
Okay, last question!!!!!
Between all the game developers/programmers of the late 70's | early 80's, there's something in common.
(At least this is what I've noticed from what I've read on the various interviews and articles on the net)
All of them started in Basic at a very early age and 2-3 years later (after mastering Basic) they moved in to assembly language.
Back then, books and colleges about programming didn't even exist, so the only help tools for learning to program in assembly language were the various reference manuals of each machine (home micros), ready-made listings in computer magazines and a LOT of passion & courage for "adventure".
BUT, there's something more.....
All of them, (besides that they were trying to reproduce famous commercial computer games (something that you suggest me), took those commercial games (made obviously in assembly), disassembled them and after that, they were tweaking the source code, in order to see what would happen, something like a learning process.
What is your opinion about that? Do you believe it's a good -intermediate- step, before trying to write subroutines from scratch, for my simple game or it's not important nowadays (maybe a waste of time), since there is a plethora of books and on-line documentation, free educational videos, on-line help, forums, countless ready-made subroutines, etc.?
Between all the game developers/programmers of the late 70's | early 80's, there's something in common.
(At least this is what I've noticed from what I've read on the various interviews and articles on the net)
All of them started in Basic at a very early age and 2-3 years later (after mastering Basic) they moved in to assembly language.
Back then, books and colleges about programming didn't even exist, so the only help tools for learning to program in assembly language were the various reference manuals of each machine (home micros), ready-made listings in computer magazines and a LOT of passion & courage for "adventure".
BUT, there's something more.....
All of them, (besides that they were trying to reproduce famous commercial computer games (something that you suggest me), took those commercial games (made obviously in assembly), disassembled them and after that, they were tweaking the source code, in order to see what would happen, something like a learning process.
What is your opinion about that? Do you believe it's a good -intermediate- step, before trying to write subroutines from scratch, for my simple game or it's not important nowadays (maybe a waste of time), since there is a plethora of books and on-line documentation, free educational videos, on-line help, forums, countless ready-made subroutines, etc.?
Re: Assembly programming
I think it does help to read code - either listings or disassemblies. It's essential to write code too, but you can learn a lot from others. Probably, like in many subjects of study, there are different styles of learning, so you will find something which works for you.
I think there have long been things to read: the Apple I came with a ROM listing, or at least a hex dump, I think. Zaks' book was there for me in the late 70s when I got my UK101. By the early to mid 80s there were magazines with listings.
But programming is a puzzle, and assembly language especially so - the sorts of minds which are attracted to that puzzle are probably also attracted to solving the puzzle of how some existing programs work.
Certainly though it's easier to figure out a self-contained routine like a multiplication or a pixel plotting routine, than it is to sit down with 12k of game code and say "I'm going to figure this out." Especially as game code is likely to contain tricky code.
I think there have long been things to read: the Apple I came with a ROM listing, or at least a hex dump, I think. Zaks' book was there for me in the late 70s when I got my UK101. By the early to mid 80s there were magazines with listings.
But programming is a puzzle, and assembly language especially so - the sorts of minds which are attracted to that puzzle are probably also attracted to solving the puzzle of how some existing programs work.
Certainly though it's easier to figure out a self-contained routine like a multiplication or a pixel plotting routine, than it is to sit down with 12k of game code and say "I'm going to figure this out." Especially as game code is likely to contain tricky code.
Re: Assembly programming
Just write code. The more you write, the better you get.
Programing is a very "learn by failure" type of craft. Sure, you can learn stuff by reading other peoples code, but you learn more by struggling and failing. You're not a professional programmer trying to meet a deadline by copy and pasting something off the internet.
Just work the problem, flail, a lot, and push on. When the game gets uninteresting, stop, and start another. Failure is cheap with computers. Fail early, fail often, fail fast.
It took me at least a year of "messing with computers" to understand Arrays in BASIC, as I never needed something that needed arrays.
My first attempts at assembly language used self modifying code to handle loops. Why? Because that's how I figured out that it could work. Is that a good way to do loops in assembly language? Not necessarily. But I had my graphic block move routine on the Pet working, with "horrible code" vs a routine that didn't exist. So, completion has a quality of it's own.
With the bounty of the internet, it's very easy to get paralyzed by choice, by idioms, by theories, blog posts, books, etc. etc.
But running code is running code. You can always fix it later, and you're not going to kill anyone or send $100 Billion worth of space craft plummeting in to the planet or racing toward the sun.
I also like to cite my definition of an "expert". An expert isn't someone who knows what to do. It's someone that can fix the problems that show up. Because fixing the problems is not in the instructions.
Finally, if you ever do find code, never "cut and paste it". Type it in, and try to explain each line you're entering as you key it in. Your mind is all slowed down and its easier to try "why am I typing this in, right now, this way" as you're doing it rather than just scanning some code, pasting it it, "calling it", and "hey it works!" yet you have no idea why.
Early on, you need to be able to explain everything you do to your own satisfaction, because the reason why you do what you do is as important as what you're doing. And programming is all about the reasons why, not the what. The "what" is mechanical. Just because the lady from data entry is typing in a Fortran program we asked her to do (yes we did this, she was very fast), doesn't mean she has any idea what it does, how it does it, or why it's done the way it is. The "why" is what applies across machines, languages, systems, etc.
I assume you want to be a programmer and not a typist.
Programing is a very "learn by failure" type of craft. Sure, you can learn stuff by reading other peoples code, but you learn more by struggling and failing. You're not a professional programmer trying to meet a deadline by copy and pasting something off the internet.
Just work the problem, flail, a lot, and push on. When the game gets uninteresting, stop, and start another. Failure is cheap with computers. Fail early, fail often, fail fast.
It took me at least a year of "messing with computers" to understand Arrays in BASIC, as I never needed something that needed arrays.
My first attempts at assembly language used self modifying code to handle loops. Why? Because that's how I figured out that it could work. Is that a good way to do loops in assembly language? Not necessarily. But I had my graphic block move routine on the Pet working, with "horrible code" vs a routine that didn't exist. So, completion has a quality of it's own.
With the bounty of the internet, it's very easy to get paralyzed by choice, by idioms, by theories, blog posts, books, etc. etc.
But running code is running code. You can always fix it later, and you're not going to kill anyone or send $100 Billion worth of space craft plummeting in to the planet or racing toward the sun.
I also like to cite my definition of an "expert". An expert isn't someone who knows what to do. It's someone that can fix the problems that show up. Because fixing the problems is not in the instructions.
Finally, if you ever do find code, never "cut and paste it". Type it in, and try to explain each line you're entering as you key it in. Your mind is all slowed down and its easier to try "why am I typing this in, right now, this way" as you're doing it rather than just scanning some code, pasting it it, "calling it", and "hey it works!" yet you have no idea why.
Early on, you need to be able to explain everything you do to your own satisfaction, because the reason why you do what you do is as important as what you're doing. And programming is all about the reasons why, not the what. The "what" is mechanical. Just because the lady from data entry is typing in a Fortran program we asked her to do (yes we did this, she was very fast), doesn't mean she has any idea what it does, how it does it, or why it's done the way it is. The "why" is what applies across machines, languages, systems, etc.
I assume you want to be a programmer and not a typist.
-
commodorejohn
- Posts: 299
- Joined: 21 Jan 2016
- Location: Placerville, CA
- Contact:
Re: Assembly programming
whartung wrote:
Just work the problem, flail, a lot, and push on. When the game gets uninteresting, stop, and start another. Failure is cheap with computers. Fail early, fail often, fail fast.
Re: Assembly programming
Agree with typing in and not pasting.