Only a couple mistakes here I think... 1) at 15:00 I say something about 3 colors in graphics modes 3 to 11, obviously that depends on the graphics mode, but you're not limited to 3. 2) at 31:30 I say Graphics 1 has 23 columns and 19 rows, which is a double mistake in that it's 20 columns and 24 rows. I mixed rows and columns and was counting from zero like the computer would do. EDIT: Couple other notes: The code is now up (fully commented) on GitHub. I DID change two things from the recorded version which I will catch up with in the next video. 1) I DID swap out CLC, ADC LUMNCE for ORA LUMNCE to save a byte! The low byte in the hue in the accumulator was cleared by the ASLs and the high byte in LUMNCE empty so OK to merge them with ORA. 2) To make it runnable from DOS, the last line was changed from .WORD START to .WORD BEGIN to reflect the new starting run address label I'm using now.
Hi Dave, these videos are great, thanks for taking the time to make such quality content. And I love that you are writing the code on the 800 itself instead of cross-assembling, gives us a glimpse of how programs were written back in the day. Keep up the good work!
@@davidarlington1206 Yes, definitely, I'm not very familiar with the Atari computers, but they seem very capable and a lot of fun. I've been using Altirra to follow the videos, looks like a great emulator, but makes me wish I had the real deal.
One thing that I'm not sure if understand is why constants like OPEN, CLOSE and PUTCHR are defined using .BYTE. I would expect them to be equates, as in OPEN=3, and then refer to it as LDA #OPEN. That would make both the instruction faster and the program shorter.
@@STN-t5k As I really get more into variables, I plan on explaining this in the next video. Saying OPEN=3 would mean the label OPEN refers to memory location 3 not the literal value of 3. Whereas .BYTE reserves a memory location and puts the literal value of 3 in that location which is what we want. These are only going to be referred to once (except PUTCHR) so not too worried about overhead here There are going to be some variables we do want in Zero Page for speed/efficiency also coming up next video.
@@davidarlington1206 But doesn't an equate like OPEN=3 means that every time it sees the word OPEN it will be substituted by a 3? If so, LDA #OPEN is equivalent to LDA #3, which is what is now being done in an indirect way by storing the value somewhere else when it could be put in the instruction. Is there a more appropriate way to define constants in MAC/65 then?
I'll discuss this more in depth in a future video but two things to note here. First, I think you're missing the point in why I created a label here in the first place. It was to make the program more readable. We only ever use that OPEN once and it's clear what it does. If it was a matter of making the program faster or smaller, I would have just used LDA #$03 not a label. Secondly, it is important to me to not just teach HOW to write code but also how to write code well and how to write code that is hopefully clear to understand, and to maintain. And while I see that even the System Equates in the Mac/65 manual use OPEN=3. But as far as I'm concerned, that's not good programming practice. In the business, it's what we would call a 'code smell'. My problem with it is if I'm looking at this code, what does OPEN=3 mean? It's ambiguous. Is it a memory location? A numeric constant? Either? Both? Depending on context that you have to look somewhere else in the code to figure out. In my code that I will be demonstrating Label=value will ALWAYS refer to a memory location. Label = .BYTE value will ALWAYS refer to a constant. Variables will either be Label .DS num (if I don't care where in memory it is) OR Label=value indicating a memory address There's no ambiguity there. You don't have to look at any other part of the program to figure out the proper context. Of course, everyone is free to code their own code the way that feels best to them, but if I'm teaching, especially at this early point, I'm going to show the examples of what I consider to be best programming practices.
@@davidarlington1206 You bring up a good point by stating that it is unclear if an equate refers to a memory address or a constant value. Ending up using an immediate as a zero page address by forgetting to add the "#" is a very easy mistake to make. I am still trying to find my own coding style, but I think equates will be addresses by default, and I'll add a prefix to indicate that they are constant values instead, maybe something like K_OPEN=3. Thanks again for taking the time to provide such detailed explanations, I've learned so much from you already and there is so much more to learn. Looking forward to the next video!
Only a couple mistakes here I think...
1) at 15:00 I say something about 3 colors in graphics modes 3 to 11, obviously that depends on the graphics mode, but you're not limited to 3.
2) at 31:30 I say Graphics 1 has 23 columns and 19 rows, which is a double mistake in that it's 20 columns and 24 rows. I mixed rows and columns and was counting from zero like the computer would do.
EDIT: Couple other notes: The code is now up (fully commented) on GitHub. I DID change two things from the recorded version which I will catch up with in the next video.
1) I DID swap out CLC, ADC LUMNCE for ORA LUMNCE to save a byte! The low byte in the hue in the accumulator was cleared by the ASLs and the high byte in LUMNCE empty so OK to merge them with ORA.
2) To make it runnable from DOS, the last line was changed from .WORD START to .WORD BEGIN to reflect the new starting run address label I'm using now.
Love it!
All good 👍🏻
Hi Dave, these videos are great, thanks for taking the time to make such quality content. And I love that you are writing the code on the 800 itself instead of cross-assembling, gives us a glimpse of how programs were written back in the day. Keep up the good work!
@@STN-t5k Yeah, I'm a big believer in true old school hands on 8-bit coding! Thanks for the support!
@@davidarlington1206 Yes, definitely, I'm not very familiar with the Atari computers, but they seem very capable and a lot of fun. I've been using Altirra to follow the videos, looks like a great emulator, but makes me wish I had the real deal.
One thing that I'm not sure if understand is why constants like OPEN, CLOSE and PUTCHR are defined using .BYTE. I would expect them to be equates, as in OPEN=3, and then refer to it as LDA #OPEN. That would make both the instruction faster and the program shorter.
@@STN-t5k As I really get more into variables, I plan on explaining this in the next video. Saying OPEN=3 would mean the label OPEN refers to memory location 3 not the literal value of 3. Whereas .BYTE reserves a memory location and puts the literal value of 3 in that location which is what we want. These are only going to be referred to once (except PUTCHR) so not too worried about overhead here
There are going to be some variables we do want in Zero Page for speed/efficiency also coming up next video.
@@davidarlington1206 But doesn't an equate like OPEN=3 means that every time it sees the word OPEN it will be substituted by a 3? If so, LDA #OPEN is equivalent to LDA #3, which is what is now being done in an indirect way by storing the value somewhere else when it could be put in the instruction. Is there a more appropriate way to define constants in MAC/65 then?
I'll discuss this more in depth in a future video but two things to note here.
First, I think you're missing the point in why I created a label here in the first place. It was to make the program more readable. We only ever use that OPEN once and it's clear what it does. If it was a matter of making the program faster or smaller, I would have just used LDA #$03 not a label.
Secondly, it is important to me to not just teach HOW to write code but also how to write code well and how to write code that is hopefully clear to understand, and to maintain.
And while I see that even the System Equates in the Mac/65 manual use OPEN=3. But as far as I'm concerned, that's not good programming practice. In the business, it's what we would call a 'code smell'.
My problem with it is if I'm looking at this code, what does OPEN=3 mean? It's ambiguous. Is it a memory location? A numeric constant? Either? Both? Depending on context that you have to look somewhere else in the code to figure out.
In my code that I will be demonstrating
Label=value will ALWAYS refer to a memory location.
Label = .BYTE value will ALWAYS refer to a constant.
Variables will either be
Label .DS num (if I don't care where in memory it is) OR
Label=value indicating a memory address
There's no ambiguity there. You don't have to look at any other part of the program to figure out the proper context.
Of course, everyone is free to code their own code the way that feels best to them, but if I'm teaching, especially at this early point, I'm going to show the examples of what I consider to be best programming practices.
@@davidarlington1206 You bring up a good point by stating that it is unclear if an equate refers to a memory address or a constant value. Ending up using an immediate as a zero page address by forgetting to add the "#" is a very easy mistake to make. I am still trying to find my own coding style, but I think equates will be addresses by default, and I'll add a prefix to indicate that they are constant values instead, maybe something like K_OPEN=3. Thanks again for taking the time to provide such detailed explanations, I've learned so much from you already and there is so much more to learn. Looking forward to the next video!
@@STN-t5k That's a good way to get around the ambiguity issue as well.