My first foray into ASM. Advice?

[devninja89]

I am new to 8 bit computing (I missed the era by a few years). I studied computer science in college and work as a software engineer, but I feel like my program was really lacking in terms of low level coding/operating system fundamentals/memory management, etc. I found the C16 project because I thought that going back to the 8 bit era that spawned some of the greatest minds in the industry felt like a good way to really shore up my fundamentals.

I use mostly Java and C# for my day job and am familiar with intermediate level C, which until is the lowest I've gone.

As a gamer and hobbyist game dev (unity engine), I really want to reach a point where I can make games and other applications for the C16. I started learning assembly using matt H's videos on youtube. I'm currently on video 2.

I wanted to give myself a little bit of an assignment based on some of the things I learned in his videos. I wrote a small program to copy an array of chars ("hello!!!") from one memory location to another, and then reverse the string.

Code: Select all

.org $080D
.segment "STARTUP"
.segment "INIT"
.segment "ONCE"
.segment "CODE"

SRC_PTR = $30
DEST_PTR = $32
TEMP1 = $34
TEMP2 = $36
FIRST = $38
LAST = $40

    jmp start

source:
.byte $48, $65, $6C, $6C, $6F, $21, $21, $21

destination:
.byte 0,0,0,0,0,0,0,0


start:

    ldy #0
    
    lda #<source
    sta SRC_PTR
    lda #>source
    sta SRC_PTR + 1
    
    lda #<destination
    sta DEST_PTR
    lda #>destination
    sta DEST_PTR + 1 
    
    loop:
        lda (SRC_PTR), Y
        sta (DEST_PTR), Y
        iny
        cpy #8
        bne loop

    jmp do_reverse

do_nothing:
    rts  ; 

do_reverse:
    ldx #0
    ldy #7

    reverse_loop:
        stx FIRST
        sty LAST


        lda (DEST_PTR), Y
        sta TEMP2

        ldy FIRST

        lda (DEST_PTR), Y
        sta TEMP1

        ; each value is temporarily stored, now we can switch

        lda TEMP2
        sta (DEST_PTR), Y

        ldy LAST
        lda TEMP1
        sta (DEST_PTR), Y

        ;both values have been switched, set up next run

        tya
        dec
        tay

        txa 
        inc
        tax

        cmp #4
        bne reverse_loop
    rts

I think it came out OK. Some of the things that tripped me up where I don't know a lot branching and looping strategies yet, so this solution is very verbose. Also, since I am using zero page pointers for the source and destination addresses, I couldn't figure out how to efficiently utilize the indirect address mode. It only works with the Y register, so that meant I had to constantly juggle around values to and from the other registers to Y.

Overall, if I look at this program, there are some dead giveaways that the person who wrote it comes from a higher level language. I feel like some of the writes to memory that I made could have been things that could have been juggled around in the registers without needing to persist to memory. I noodled on this for hours and couldn't figure out the best way to move forward.

I might actually try and see if I can re-write this to not use pointers and open myself up to indexing with X and Y registers and see how far I get, but honestly I am not sure. Matt's videos are great but I feel like this is going to be trickier to learn than anything I've learned before.

Any advice? Can one of you veterans show me the proper, idiomatic way to do something like this?

[unartic]

About a year ago I found myself in exactly the same position as you. Assembly somehow felt like another world entirely.

Now, a year in, I’ve developed complicated and large programs in assembly for x16 of which the biggest achievements are XFM (Norton commander style file manager) and nxtBASIC (basic language compiler for x16).

Learning assembly for x16 is also about learning about x16 itself from a hardware and kernal perspective.

My advice: set an achievable goal. For example develop a text mode long game in assembly Dedicated some hours to it and learn along the way.

And go to the x16 discord server as you often get instant replies on questions.

[unartic]

This is a more optimized, yet still readable version.

Code: Select all

.org $080D
.segment "STARTUP"
.segment "INIT"
.segment "ONCE"
.segment "CODE"


    jmp start

source:
.asciiz "hello!"    ;last byte will be $00
source_end:

destination:    .res (source_end-source)     ;reserves  a piece of memory same length as 'source'

CHROUT = $FFD2    ;kernal routine to print out a byte


start:
    ldy #0
    Loop:
        lda source,y
        sta destination,y
        iny
        cmp #$00    ;compare accumulator with $00
        bne Loop    ;if is not $00 (last byte), keep looping
    
    ;y contains index of last byte
    dey
    ldx #0
    Loop2:
        lda destination,y
        sta source,x
        jsr CHROUT   ;print out reversed result
        inx
        dey
        cpy #$FF
        bne Loop2   ;if y is not yet zero, keep looping        
    

    
rts

[DragWx]

Comment, comment, comment. Never say "I'll remember what this does" or "I'll remember why I did it this way"; that's the Code Gremlin lying to you.

More specifically, comment as though you'll need to re-teach yourself what your code does a year from now, and it sometimes helps to leave a comment about why you chose to implement it a particular way.

Especially if you have a subroutine that does a long, complicated calculation; it helps to comment what the goal (or equation(s)) of the calculation is. This helps because a one-line equation in C/Java/etc can end up being a huge spread of opcodes and subroutine calls in assembly, and keeping a running summary of what's going on can help you revisit it later.

It's also good practice to "document" your subroutines; summarize what it does, what the inputs are, what the outputs are, and more importantly, say which CPU registers and memory locations get "clobbered" by it. This helps when you need to make several calls to several subroutines to transform some data; you'll know what you need to save on the stack first.

[paulscottrobson]

Don't do it on the X16. Initially.

There's a reason for this. There are countless C64 tutorials, books and tools available for nothing (there are for the X16 just fewer) which gives you a big choice at all levels, depending on how much knowledge you have ; everything from absolute basics through to crash courses. (There are some very good X16 tutorials out there but the more choice you have the more likely you'll find one which fits your learning style)

This sort of thing for example http://8bitworkshop.com/ or https://www.assemblytutorial.com/

The machines at this level are very similar ; same processor (almost), similar hardware and interfaces. Once you've learnt how to program the 6502 and written some reasonable programs transitioning to the X16 and its specific hardware (or any other 6502 machine) is easier.

[mortarm]

Another reason to document your code is so that others can understand what you're doing, should you decide to share it.

[Ed Minchau]

Don't do it on the X16. Initially.

There's a reason for this. There are countless C64 tutorials, books and tools available for nothing (there are for the X16 just fewer) which gives you a big choice at all levels, depending on how much knowledge you have ; everything from absolute basics through to crash courses. (There are some very good X16 tutorials out there but the more choice you have the more likely you'll find one which fits your learning style)

This sort of thing for example http://8bitworkshop.com/ or https://www.assemblytutorial.com/

The machines at this level are very similar ; same processor (almost), similar hardware and interfaces. Once you've learnt how to program the 6502 and written some reasonable programs transitioning to the X16 and its specific hardware (or any other 6502 machine) is easier.

I disagree. The X16 is meant to be a tool for teaching programming. And if they ever stop making breaking changes, then someone can write a book.

[ahenry3068]

Don't do it on the X16. Initially.

There's a reason for this. There are countless C64 tutorials, books and tools available for nothing (there are for the X16 just fewer) which gives you a big choice at all levels, depending on how much knowledge you have ; everything from absolute basics through to crash courses. (There are some very good X16 tutorials out there but the more choice you have the more likely you'll find one which fits your learning style)

This sort of thing for example http://8bitworkshop.com/ or https://www.assemblytutorial.com/

The machines at this level are very similar ; same processor (almost), similar hardware and interfaces. Once you've learnt how to program the 6502 and written some reasonable programs transitioning to the X16 and its specific hardware (or any other 6502 machine) is easier.

I disagree. The X16 is meant to be a tool for teaching programming. And if they ever stop making breaking changes, then someone can write a book.

We are now on r48. I haven't seen any breaking changes since r44 (and actually only a couple easily fixed ones between 42 & 44)

[Ed Minchau]

Well, since r44 they've announced a second processor as a drop in replacement. So now the book needs to be twice as long.

[ahenry3068]

Well, since r44 they've announced a second processor as a drop in replacement. So now the book needs to be twice as long.

That's still an option and non-breaking. Fulgen and MooingLemur efforts have made it fairly certain that software written for the 65c02 will run on either processor. Of course there is now the choice of using 65816 code but that's a choice not something you have to do.