ca65 weird problems.....has anyone ever experienced this???

[reifsnyderb]

Hello,

 

I've been successfully using ca65 for almost a year and never had problems until today.  To make a long story short, and only after hours of extremely frustrating troubleshooting, I discovered that the 1090 80 column code no longer compiled properly.  Only after looking at the resulting hex, and comparing it with the 6502 instruction code, did I figure out that it was no longer compiling code that would work on a 6502.  I have no idea why, was using source code that previously worked, and compile scripts that were unmodified from when it did work.  I am running a Linux system and my wild guess, at this time, is that a system update blew up a dependency somewhere.  Has anyone ever seen anything like this before?  Did you have a solution?

 

Thanks!

 

Brian

 

[invisible kid]

Hmm, no direct solution, no. Are you using a debian based distro? If so, that should only update if given a command or if something else you are installing requires a newer version, but I'm not 100% sure, I only use debian here and there. I don't use ca65 much or at all, but could it be a command line argument? Maybe you inadvertently started leaving out something? Sorry, just spitballing without concrete examples.

 

You can also try one of the other assemblers. Atasm and Mads come to mind, you would probably need to massage the source a bit for syntax variations.

Edited January 5 by invisible kid

[sanny]

> Only after looking at the resulting hex, and comparing it with the 6502 instruction code, did I figure out that it was no longer compiling code that would work on a 6502.

 

How did you come to that conclusion? What are the command line arguments to ca65? What do you mean with "hex" file?

[TGB1718]

1 hour ago, sanny said:

What do you mean with "hex" file?

I believe he's using a "Hex" editor of some sort to compare the actual bytes in the object files (.XEX, .BIN, .COM, .OBJ),

in Windows, I use Hex Editor Neo to manipulate the hex values in binary files.

 

7 hours ago, reifsnyderb said:

Has anyone ever seen anything like this before?  Did you have a solution?

Can you post an original and the new binary files, it's impossible to really help without seeing what's different, also

maybe the source too, could try compiling for you under Windows.

[reifsnyderb]

6 hours ago, sanny said:

> Only after looking at the resulting hex, and comparing it with the 6502 instruction code, did I figure out that it was no longer compiling code that would work on a 6502.

 

How did you come to that conclusion? What are the command line arguments to ca65? What do you mean with "hex" file?

 

For example, let's take the following code:

 

            LDA  SHPDVS
            ORA  PDVMSK
            STA  PDVMSK

 

Changing out SHPDVS and PDVMSK, we get:

 

            LDA  $248
            ORA  $247
            STA  $247

 

Which then should be:

 

          $AD $48 $02

          $0D $47 $02

          $8D $47 $02

 

Instead, the bytes would be something else entirely.  (I didn't save an example as I have been trying to get this working.)

 

I am setting up a development environment, on a Windows machine, to give this a try.

 

I never changed the compile script from the time it worked until it didn't work.  The main script is:

 

ca65 -t atari -l source.lst xep80.s
ld65 -C xl.cfg xep80.o
mv a.out xep80.rom
chmod 664 xep80.rom
chown reifsnyderb:reifsnyderb xep80.rom

 

 

I did get better results after downloading ca65, compiling it, installing it in the same directory as the source files, and changing the script to use the local files.  It still isn't working, but the compiled code is almost right.  Below is the script with this change.

 

./ca65 -t atari -l source.lst xep80.s
./ld65 -C xl.cfg xep80.o
mv a.out xep80.rom
chmod 664 xep80.rom
chown reifsnyderb:reifsnyderb xep80.rom

 

 

Basically, to sum everything up, the code compiled and ran fine.  Six months later, and after changing nothing, it no longer compiled into code that even relates to 6502 code.  The only thing I can think of that might have changed anything is that I recently let Ubuntu update the system.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[invisible kid]

So if it is generating different opcodes could it be building for a different cpu? Even though -t atari should cover it, maybe add --cpu 6502 just to see if it makes an impact?

Edited January 5 by invisible kid

[reifsnyderb]

I tried the --cpu 6502 and was able to compile code that compared exactly to the read of the working chip.  Then, I programmed a chip and it worked.  Finally!  I've also started using a copy of the compiler that I installed in the same directory as the source files.

 

Next, I tried programming another chip.  This chip programmed and read correctly in the burner.  It then failed in the card.  After investigating this chip, a pin is loose.  So, there were two problems.  I think it's finally working.

 

 

[Ray Gillman]

Maybe try going back to working under an older Linux flavor like an old Backbox 4.x or 5.x from a few years back. Those worked very well no NEED to upgrade to newer versions. That is why they have oldversion.com because newer versions are not always consistently "better"