I got it to work. I missed two important things.

My *= variable was not quite correct and I was missing a flag with 64tass. It's working now.

So, I've encountered a strange issue with 64tass. When I use labels with jmp and jsr these opcodes don't get pointed to the memory location I expect. Passing labels to branch instructions, example bcc , works just fine. I've checked and I don't see any obvious cases of double-defining a label or any ...

So I'm learning... the hard way.
Cool! Do you have a link to some of these? I'd like to read them over.

Even if the answer comes near an year later, you should use JC64dis for this task (https://iceteam.itch.io/jc64dis).
Version 1.0 else will support cartridge loading directly.

I reverse enginnering many music players over the years for having a commented source code that can compile back to binary ...

I found the culprit! CJS is indeed correct: petcat has the right linked-list value. My manually created BASIC header was wrong. I think it only worked because there wasn't a second for the bad linked-list pointer to have to deal with.

I manually re-checked as much as I could. I got very suspicious ...

Okay, so I did quite a lot of digging after my previous post. I fixed one issue and ran into another one. The "I'm off by 2 bytes" issues was my own fault. I'll spell out my screw-up before launching into the current problem.

For my "known good" code looks like this:


; vim: cursorline columns ...

I'm using 64tass as my assembler. I'm running unexpectedly into a situation where my labeled branches are getting treated as TARGET_OFFSET -2. I could swear I have run into some version of this issue before and got things working. I've checked my notes and forum post history. If it's there, I can't ...

The 6502 isn't exactly C friendly. Neither is the Z80, really. Both chips have C compilers that target their architecture. Some of them are native compilers, like Power C on the 6502. Others, like cc65 are cross-compilers. So, it is possible to target the 6502 it's just that the processor requires ...

Once I've disassembled a game and successfully re-assembled it, I'm no longer sure what the best git workflow is. In an ordinary project taking the common "feature branch" approach makes sense once you've got the essence of your project committed to code. But, reverse engineering games to ...

This article is not 6502 related, but it's an early 8-bit CPU from the 1970's, but I think this crowd will enjoy it. This is a fairly in-depth article about an HP processor that can't even add: http://www.righto.com/2020/09/inside-hp-nanoprocessor-high-speed.html . It could count, but not add. I ...

Will this eventually get merged into the mainline LLVM codebase? Or, will it remain a fork?

Here's a ranged table for converting petscii to screen codes: https://sta.c64.org/cbm64pettoscr.html Of course, this presumes that your macro can read the petscii code of the source code character passed into it. I'm not familiar with 64tass, but if that's a cross-assembler, then you have to figure ...

I have a segment of code that copies CHARGEN glyphs from ROM into RAM. This initialization code takes a couple of different forms. I'm trying to create an abstract macro to handle all of the cases.

Here is an example segment, one of several similar cases:


ldx #$d0 ; +208 / 8 = 26, because we're ...

The .assert and .check directives in 64tass are not for code testing purposes as outlined above.


Soci, thanks for clearing that up. In other languages "assert" gets used a lot to mean "throw an error if this condition [which should never happen] actually occurs."

Your assembler is rock solid ...

Yeah, as someone who's been using Bourne shell since the '80s, Perl since the '90s, Ruby from the early 2000s onwards, and, over the last few years, Python, I can say you definitely should simply start with Python. I frequently ignore my own advice and use Bash to get something started and most of ...