As I've re-acquainted myself with BASIC, I've found myself getting more and more annoyed with how slow / restrictive it is, and while I've seen some really impressive BASIC games; all the best programs seem to be written in ASM, so I figured I'd give it a try. I'm making this thread to document my progress. So far, I've finished through Day 14 of "Learn TI-83+ Assembly in 28 Days", and made a program that fills the screen with "X" to practice. The code doesn't exit properly, so it just runs in an infinite loop.

Code:

I really like how fast ASM is, but I'm not a huge fan of registers so far; especially since the system seems incredibly picky which ones you can use with each instruction.

Nice, needs a ret nc instead of the jr nc, exit.

Have fun! Assembly can be challenging to learn, but also incredibly satisfying to have success with.


You'll get used to that It becomes more apparent over time that each of the registers have their own special use, eg. B as a counter, C for "in" and "out" instructions, etc.

I was able to create a program that prints the Fibonacci sequence up to the 16 bit integer limit. I had some difficulty because I forgot some BCALLs change HL; but I was able to fix the problem by using the stack. Unlike the last program, this one exits properly.


Code:

Nice work, a good tip is that you can use the stack to swap registers around too if you want:

Code:


You will notice how the order in which hl & de are popped from the stack is the opposite in which they were pushed which effectively swaps them.

I've been struggling to create a program to perform 8 bit addition. I have this so far:

Code:

Using the up and down keys to choose the values seems to work fine, but the calculator crashes after the second value is selected, sometimes displaying a large number as the answer. I know BCALLs change HL, but from using the debugger (a tool I've found myself getting quite familiar with as I've written this program), the correct values seem to be getting PUSHed to the stack. The problem seems to be that an incorrect value is being POPed into HL after RET Z is executed. I'm unsure how this is happening though since there aren't any PUSH instructions between the result being PUSHed and the problematic POP instruction.

Tracing it myself:

• start
  
• call numberSelection: pushes return address
  
• push hl
  
• assume key = enter; return, popping preserved HL as return address: probably crash

It looks like you're trying to store temporaries on the stack separately from return addresses but there's only one stack so that's not possible.

I managed to fix the issue, I'd forgotten that CALL pushes the return address to the stack, and I had to rewrite the program to work around that. This is really unoptimized, and the answer will wrap around if it's over 255, but frankly I'm just glad it's finally working after days of debugging.

Code:

Glad you got it working, a few tips:
CurCol and CurRow are only 1 byte each, so writing HL to them writes 2 bytes to each address. In the case of CurRow it's ok since CurCol follows it directly in RAM (so writing hl=0 to CurRow has the effect of zeroing out BOTH CurRow and CurCol). Writing 2 bytes to CurCol however will overwrite the memory after it, which is CurOffset by the looks. You could use A instead or you could take advantage of the 16-bit write and do something like ld hl,(5*256)+2 to write 2 in CurRow and 5 in CurCol at the same time.

Have a think about a way that you could use 1 function for 'numberSelection' instead of 2 very similar ones.

There are ways to utilise registers and only use the stack when needed. It's generally not good practice and difficult for debugging to have functions that rely on uneven stack usage, as I think you found out here since CALL uses the stack too. Usually you would use the stack to save registers around functions like:

Code:

I took a look at the problem and I was able to compress NumberSelection into 1 function (also getting rid of "increase2" and "decrease2" in the process), it was easier than expected as well. I think I'm slowly starting to get more comfortable with ASM, though I've gotten to Day 24 in Learn TI-83+ Plus Assembly in 28 days and interrupts / the graphics buffer have definitely re-humbled me. This is the new code:


Code:

Side note: are there standard conventions for ASM programs here (eg: using uppercase / lowercase for instructions, how to name labels, etc)? From what I've read there aren't really any for the Z80 in general, but I'm unsure if this community prefers any particular style / if there are any that are considered better.

I've now finished Learn TI-83 Plus Assembly in 28 Days. Overall, I found the tutorial really helpful, I came into it never having used any type of ASM and most days felt reasonably challenging / in-depth without getting too confusing. Some of the more technical parts (eg: Days 8, 9 and 15) tripped me up, but I feel like I have at least a decent basis to start looking at other people's programs and be able to figure out what they were going for.

As for ASM itself, the main challenge seems to come from the fact the syntax is so simple, most instructions are really bare-bones; but that means you have to construct stuff manually that BASIC has specific commands for, making sure you manage all your registers correctly lest you get a RAM clear. I really like how flexible that makes it though; even really simple programs feel like my own original creation instead of having to do things the TI-approved way, and of course the speed is insane compared to BASIC due to being assembled.

Going forward, I plan on downloading some simple Assembly programs and trying to add / remove small things as well as continuing to make progressively more complex stuff on my own. With a medium-term goal of mine (want to finish this before Jun. 31) being to port the Hangman game I wrote about a month ago to ASM without sacrificing any functionality. It was decently complex, which should provide a good challenge, but I also wrote it myself so I know exactly how everything works, an ASM port would also improve the sluggish speed. It's definitely pretty nerve-wracking knowing I've pretty much exhausted all the instructional material on the language, but I'm excited to continue learning.

In your last section of code above, I note that you still several instances of the memory-overwriting with curcol, such as:

Code:
Since your state can only be 0 or 1, you can make that be one byte and use a rather than hl to access it as well, saving a few bytes. And for that matter, you can then use xor a as a substitute for ld a,0, thus:
Code:
and later:
Code:
Finally, using appData as scratch memory is a good idea, but it's much more common to use the symbols (which also facilitate porting and updating) and to use offsets from previous equates, so that you can insert one later if needed without changing all the values:
Code:

That sounds like a perfect next step: reading and understanding others' code (an important prerequisite to modifying it, of course), and then a medium-difficulty project of your own. Please do keep the questions coming, and we'll be happy to help!

It happen the same thing with me, But in my case I dont know where to start or where I can learn.

It's been a while since I updated this thread, I originally intended to continue posting every few days like before, but my Spring Break happened and I figured I'd take a break since I was burned out. Then it ended and I became busy again, which made me even more burnt out, I put off doing ASM for a few days, which became weeks, which became months, the usual story. In any case, I graduated from HS on May. 21 and resolved to get back to ASM since I no longer had any excuses. I picked up a program idea from before I fell off and just forced myself to finish it to get myself back in the groove, and I'm finally done! The program is a simple 4-function calculator with key input, and to be honest making it was a ROUGH process, I was very out of practice and adding a prompt injected a ton of complexity (eg: handling the buffer, converting from ASCII to decimal, echo, how to distinguish between number and character input, etc). I ended up leaning heavily on the tutorial for the majority of the input stuff (Day 27 was a huge lifesaver) as well as the multiplication / division, though I did my best to rename stuff and try to understand everything so I wasn't just copy / pasting. Overall, I'm pretty happy with the result, multiplication and division are only 8 bit compared to the 16 bit addition / subtraction functions, and it's definitely not efficient at all, but just having everything display properly feels like a minor miracle. I'll probably continue with my previous plan on looking at other programs after this, and aim to finish a simple Pong game before Jun. 10. The source code for my calculator program is below.

Code:

Looks like I'm not going to hit my goal, I've made a substantial amount of progress (got graphics as well as the movement for the left paddle working), but the logic for the ball is really tripping me up, every time I fix one bug with it, another issue seems to pop up. Been slowly working through everything (thank god for being able to step the program, I would've quit ASM weeks ago if I had to just intuit what was going wrong), but it's going to take at least a few more days until everything is worked out. Here's what I have so far:


Code:

I've finally finished Pong, getting the ball to work was really annoying and I had to rewrite that whole section, but after that it was mostly smooth sailing. I'd say about 70% of the source code is my own work compared to 30% I copy / pasted from tutorials (eg: the "FetchPixel" and "RandomNumberGenerator" procedures). My ultimate assembly goal is to make a full-fledged RPG for the 83+, but this project taught me that I still have quite a while until I'll be good enough to tackle that. My code is below, and I'd really appreciate any feedback since it's a bit of a mess.


Code:

I've finished Snake! For this one, I wrote the game in BASIC first to get an idea of how it would work, which turned out to be a good choice since I struggled quite a bit to get the algorithm right (I've never made Snake and arrays aren't my strong suit). Having the solution massively helped since I knew any bugs were the fault of my implementation instead of the core functions, and I didn't have to tediously refactor to try new approaches all the time. It was still a pretty large undertaking though, no one part was particularly difficult, it was just a battle of attrition getting everything in and working properly together. I may start breaking up anything larger into separate files since it was annoying having to scroll all the way to the bottom to see my variables near the end. Overall, I'm pretty happy with how it turned out, everything seems to work without any major bugs, and I feel like I got a good amount of experience in dealing with ASM arrays. I'm considering remaking Space Invaders next, but I'm not 100% sure yet.

Code: