วีดีโอ

1) What native 6502 instruction lets you copy a whole page at a time? 2) For the purposes of the demo, I could have put the source and destination values directly into zero page, but then it's a zero page constant not a variable and I was thinking ahead to the next video when SRCADR and DSTADR are going to be used several times with different values. 2a) In a side note, I DID try to set SIZE as a constant in zero page, but MAC/65 did not like that for some reason and overwrote my constant even though the compiler said it compiled OK. I'm going to investigate that later. As mentioned in the video, the MAC/65 manual is unclear about its own usage of the top half of zero page locations. 3) My first version of this DID use a decrement method for MVRMDR, but I wasn't happy with my explanations being as clear as they were for the way I ended up doing it. As mentioned in reply to some other comments, I'm not always looking for the fastest or most efficient way to do something, but rather something I can clearly explain the concepts and reasoning and then hopefully inspire people to try their own ways. It was also easier to explain the DDT testing part doing it that way and giving examples of testing was another goal here. I did try to make a point that there are plenty of examples of this code you can find a lot of places (especially since this logic is not Atari-specific) of how to code this subroutine and that I was sure someone could find a better way out there with just a little effort. A goal of the series though is not to tell people how to write code by telling them a certain way, but how to explain things so they can write their own code. Someone commented with a working example of the decrement way for MVRMDR and that made me feel great because that's what I'm hoping for in the end. I get you started, you think up better ways or your own ways on your own!

Right. I thought I mentioned that was one of the reasons she didn't go for them but I probably was thinking of saying it but never did. Thanks for catching that. Once I saw those 7 League Boots that's all I had eyes for! LoL

Yeah, watching it back I realized I didn't really need 430 and if I don't need that then your suggestion is the best way. Those are the things you clean up AFTER you make sure it's working and you have a bunch of tests to test it. Or when you're watching it back LOL

@@davidarlington1206 On a similar note, the loop for the reminder could be: iny cpy size bne move

The loop for the reminder would also be shorter and faster if the X register was used to count how many elements are left to copy, instead of using the Y register to compare if it’s equal to the contents of the size variable. Maybe something like this? ldx size beq mvdone ldy #0 move: lda (srcadr),y sta (dstadr),y iny dex bne move

@@STN-t5k going that route you can reverse the copying order for the sub page portion. However, I think it was thought to be a smidge less clear.

@@STN-t5k I toyed around with using a DEX method but as Alex suggests and I've mentioned in the past, sometimes the decisions on a particular way to do something is more tied to make the code clear and understandable rather than teaching efficiency. That's also why I made a point to say in the video that I hope people are taking my explanations about what the code is doing and why as inspiration to write and find their own ways to do things. (Which you did which is exactly what I'm hoping for with these videos!) I want to show a way I think I can make clear to all levels and then let folks take the car out for a spin on their own. Alex's suggestion was more efficient than what I had but it doesn't lose any clarity either.

Thanks for the kind words. I've been having fun rediscovering the things that got me started as a developer in the first place, long ago!

@@davidarlington1206 Yeah, this series is great. I love how you take the time to go into the subject in detail, 80 minutes seems about the right length for it.

@@STN-t5k I can't seem to get away from that 80 minutes length despite my best plans LoL

nevermind, I just realized you hit enter before going back down :)

@@og_dagr8hoodoo Ahhh! Sorry I missed this comment before this! Glad you figured it out. I know there's plenty of instances where I forget to hit Enter when I change a line. I'm glad I remembered on this one. A pretty big mistake happens in a later video because of me forgetting to hit Enter after changing something!

@@davidarlington1206 I hope some muscle memory will eventually develop for me ;) Having fun following along with you! Thanks!

@@nickfolino8228 That happens a lot for me too! In the morning the brain is clear! In this case, I actually had already set up an intentional mistake to show DDT breakpoints and then didn't even have to use it because of the real mistake! LoL

Right? Except even then I'd probably forget to hit Enter on 50 of them! 😊

@@nickfolino8228 Yes, agreed there. That's coming up soon.

@@nickfolino8228 Great point! I'll change that tonight when I finish up.

I think I might have looked at that series before but too much PC and not enough real Atari for my tastes. I DO appreciate the folks though who have used new IDEs like this to provide us with so many new modern Atari games.

Could renumbering have been improved in later versions of MAC/65? I'm not sure which version you are using, I think you mentioned early on that you have several of them.

Can you also elaborate a bit on why you don't use the Num command? I think this is also something you mentioned early on, but I don't think I got the explanation. To me, it feels rather tedious to enter a line number every time, so automatic line numbers feel like a nice feature to have.

I'm going to answer all three comments in one reply if that's OK. I do have three different versions of MAC/65, 1.01, 1.02 and 3.6. I can't really tell a difference between any of them so far to be honest. Certainly the renumbering utility getting improved wasn't one of the enhancements. It's the same in all three versions. I don't know if I'd call it a major omission since at least there's SOMETHING there, but I would have no problem saying it seems like it was an afterthought. I'm thinking maybe because of packing DDT and all the other features like supporting Macros, the utility package was probably very low on their list of feature importance? It's a shame too, because the Editor that came later in their Action! language cartridge is superb! It certainly was laborious and a big part of my worry about how the video would be received to watch me renumber and stitch those pieces back together again. That was a trap of my own making though. When I was putting together the different examples of how to do Graphics, Plot, Setcolor etc, I wasn't thinking about using them again later (at that moment). It was only later when I was going to start piecing together a real program and setting out a code framework, did I realize that "Oh, why am I going to write those again? I just use them as they are in the big program." But then I wouldn't have had room to fit the new code in where I wanted it. I thought about just typing it all over again, but I was guessing/hoping that the renumber method would be faster? Either way, I put myself in my own pickle there. Which is all the more reason I'm glad I set up a framework now. In the future, there should be much less of that and when I am doing new examples, I will number them with the idea in mind that I might be reusing them again. Also, later in this series of videos I'll talk about even yet another way to avoid this problem I gave myself. As far as the NUM command goes, I'm afraid the real reason I don't use it (I forget what I said about it in the earlier video now) is that I am a very clumsy typist at times (which I'm sure you've witnessed plenty already!) and I can't seem to enter more than four or five lines in a row with NUM before I do something to knock myself out of it like arrowing up to a previous line to overtype some mistake I made Or deleting some characters and hitting Enter when I didn't mean to. Things like that. Maybe I'll try it again now I've been doing more editing than ever in MAC/65 and see if I can make it work any better for me. If I do, you'll get first credit! :)

I am in the process of uploading the next video and I think you'll like the fact I gave NUM another try and actually used it quite a bit!

I appreciate your viewership and your comments, but this is unlikely to be changed in the future for a few reasons. 1) Some versions of MAC/65 have a bug (feature?) that it cannot properly assemble forward references to zero page locations. So they can't be put at the end. 2) When you say it is common to put all data at the end of assembly code, that may be true for assembly language code in general but that's not true for Atari assembly code. I went through a bunch of assembly listings from old Atari magazines looking for any kind of consistent coding practices. The one thing that WAS consistent, ironically, is that they put variables and equates at the top of the listings, not at the end. Nothing else was really consistent except this. :) The things that generally went at the end were like the things I mentioned, custom display lists, player/missle shape tables, strings, etc. 3) It could be bleed over from my years programming Action! or Java, but it's always been a practice for me there for DEFINES, variables etc to be declared at the top. They're referenced a lot and I want them together where I can find them easily. I mentioned this in a response to Alex, and I'll make this more clear in the next video. Any programming practices I recommend are not intended to be meant for coding assembly language in general, or for coding even just 6502 Assembly and not even meant for Atari assembly with the Assembler Editor cartridge. It's very specifically meant for programming the Atari 6502 with the MAC/65 development environment.

@@davidarlington1206 I'm not sure what you mean by this: 1) Some versions of MAC/65 have a bug (feature?) that it cannot properly assemble forward references to zero page locations. So they can't be put at the end. I'm not talking about zero-page locations, I'm talking about the location inside your program that you are reserving for data. When you use .ds or .byte it reserves a location in memory at the specific location within your program area. If you add another data byte at the top of your program, it shifts where your program will live in memory. That's why your start location keeps changing and you have to look to see what it's changed to. If you put it all at the end your code will always live at the same locations and not get shifted around in memory. Once you start coding larger projects, that moving around of the code location could cause issues.

@@nickfolino8228 As long as the start of the executable code is labeled properly, it doesn't matter where it actually starts. That's totally arbitrary. I only care about needing to know the address during debugging and it's always captured in the Symbols table where it moved to. Once it's finished the DOS run address takes care of it in its final form. You'll have to trust me on this but I'm not going to run into any issues. It's perfectly fine and acceptable and how people have been coding Assembly programs on Ataris for 45 years. What I'm doing is not new or radical.

@@davidarlington1206 I myself have been writing 6502 assembly for over 30 years, on Atari, Commodore, Apple and things I designed myself that use the 65xx family of chips. You have already had issues (not knowing where your data ends and code starts), that's why I brought this up to begin with. Everything you are doing is fine for simple programs, if you get into writing more involved code you'll see the benefits.

@@nickfolino8228 I guess we'll just agree to disagree on this one.

@@takingbytes1265 Thanks! That's actually great to hear since I was sure people would find it maybe boring or pretentious. I'm sure I'll have more to say and will refine things as we go.

The assembler, when it assembles the code, does maintain a difference in the assembly listing between a label that equates to a memory address versus pointing to a memory location that holds a value. That's what I was trying to point out there. Anyone can code the way they like, as I mentioned, but any confusion they generate for themselves (or not if that's what works for them) is up to them.

@@davidarlington1206 the thing is that this style isn't practical on some other assembly languages. If someone is used to programming for CPUs other than the 6502, it isn't helpful. If you find it helpful, do it. Your way is more confusing to me because I see reserved space and first think variable, not constant especially if it is only one or two bytes.

@@AlexEvans1 Ahh that's probably the disconnect. I'm not doing this series for other CPUs or other assembly languages or even other computers that use a 6502. In fact, I'm not even doing a series on Assembly Language on the Atari in general. It's specifically for Atari's Assembly Language with a specific Assembler/Editor IDE. I actually am in total agreement with you that my directions here probably do NOT and should not apply to other assembly languages or other processing chips. In that case, I am sorry and apologize for any confusion I'm making for you in that regard in this series.

That's me from here on out! LOL

@@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.

@@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.

@@caseycbenn yes, the whole game is here in several videos!

@@chriscription My new Atari 130XE I'm pretty sure has a 65C02 but the 800 does not. The MAC/65 documentation notes additional addressing modes for BIT for 65C02 but does not mention supporting immediate mode just absolute,X and zero page,X.

1) not in the source code as a assembler directive, but you can use the SIZE command from the MAC/65 Editor to get the last address used by MAC/65 and the top of memory. You just want to give yourself some room over what MAC/65 uses/needs, and under the top of available memory, keeping in mind MAC/65 also needs space for a symbols table past its shown usage. So far, we haven't had to worry about memory issues on a 48K machine! :) 2) You're right, all my lengths are off by one, but the relative savings are the same. 3) Ah, good catch. My issue was the position on the screen was coming out wrong, printing in screen memory 1-12 instead of 0-11. But I needed change the LDY #$0C (which was OK when we were counting up and that was our stopping point) to LDY #$0B so it prints from positions 11 back to 0. I'll mention this in a future video. Thanks for your comments and viewership!

Ooh thanks! Very possible. I'll correct that.

Yep, you're right. I've corrected it and will mention it at the start of the next video.

@@AlexEvans1 You'll see that as I go on, I catch most of these already especially the 11 and 12 B/C thing. I go back and forth on the # key thing LoL. What it was called contemporaneously back in the 80s or what are most people thinking today in 2024 when they see that symbol.

octothorpe

​@@y00t00b3rLOL. Perfect! Just don't expect to hear me say that in a video for the next hundred years or so! 😊

@@FelipeBalbi let me know because it hasn't worked for me so far

@@FelipeBalbi I'm guessing when you left this comment, you hadn't finished watching the video yet. 😊

@@nickfolino8228 As I've mentioned in previous videos, I'm still finding my coding style for Assembly. I may start moving things around later but for now I like all the code in one place and all the non code together as well. As long as you're using labels and writing the code properly it won't really matter where the code actually starts.

@@davidarlington1206 You may try moving your data to a different location. You can add another *=[DATA ADDRESS] to the top of your program, then *=$5000 right before your code starts. That way your program always starts at $5000 and you won't need to worry that adding more data will move the starting location of your program. I like keeping all data in a separate file then just including it in the main program where I want it.

@davidarlington1206 You may try moving your data to a different location. You can add another *=[DATA ADDRESS] to the top of your program, then *=$5000 right before your code starts. That way your program always starts at $5000 and you won't need to worry that adding more data will move the starting location of your program. I like keeping all data in a separate file then just including it in the main program where I want it.

While it's true you can test the Accumulator value with BIT without changing the value in the accumulator, the big drawback with using BIT is that it does not support Immediate Mode. You can't do BIT #$02 or whatever, which makes it more awkward to use. (And would've distracted from the roundabout point I was trying to make about why and when you might need to use your own variables to stash things away.)

@@davidarlington1206 cool I never use bit just was a thought. Thanks for letting me know

@@brianwild4640 I think I'm going to show how to use it though now in the next video lol

@@davidarlington1206 that would be good for me

@@brianwild4640 These 4 in 1 cartridges are readily available it appears and are just as good as an original cart. Not everyone and especially me, can make their own carts.

@@davidarlington1206 those cartridges are a shared project at pcbway. One can order the pcbs for about $5 USD.

@@FelipeBalbi A thing with the Atari though is that you need a case to hold the dust cover flaps open on the cartridge port. Or rather you need that with an XL as it has metal flaps that would short things on the PCB if you use a bare PCB in tbe cartridge slot. With the original 400/800 a bare PCB would work (I think?). Not sure about the XE models.

@@JamesGraham-f7y Hopefully the videos make it seem a little easier for you to pick up now.

Hoping to record that tonight

The problem with the Cavern tile is not actually its placement but the placement of the Ledges next to it which should be rotated one hexside to the right. That would ensure all six clearings in the Ledges connect back to the Borderlands AND make the Cavern tile placement OK. What happens is I set up the map on an empty table and then do my best to rotate the whole map by hand to make room for the Setup Card etc. Sometimes when I'm hand rotating the entire map, a tile gets missed or shifted wrong like what happened with the Ledges here. It ends up not mattering in the end for this game because the Amazon never ended up getting close to either the Ledges OR the Cavern. If she had, I probably would have spotted this. Good catch! That's what happens when you don't have RealmSpeak to make sure it's legal! :)

Such are the perils of coding live! But I wouldn't do it any other way. I think it's healthy for people to see mistakes and how to find them and fix them rather than being perfect all the time!

@@davidarlington1206 so true