Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > 64tass v1.45 bug
2006-04-16 16:42
ready.

Registered: Feb 2003
Posts: 441
64tass v1.45 bug

Using 64tass v1.45 or earlier by Breeze and Singular (64TASS V1.45), I can't compile the illegal op code ANC. I need:

....
lda ($2e),y
anc #$ff
ror
....

I have managed 64tass to compile the ANC op code in this way:
....
lda ($2e),y
.byte $0b, $ff
ror
....

In this way it works fine. Hope this can be helpful for a new version of 64tass.

BR,
Ready.
2006-04-16 17:48
WVL

Registered: Mar 2002
Posts: 902
did you use the option -i while compiling?

i, --m6502 NMOS 65xx
Selects NMOS 6502. Enables extra illegal opcodes. Useful for demo coding for C64, disk drive code, etc.
2006-04-16 17:57
ready.

Registered: Feb 2003
Posts: 441
Thanx man, now it works fine!

Ready.
2006-04-17 01:05
The Phantom

Registered: Jan 2004
Posts: 360
Hmph.. So that's how it's done...
Was always afraid to ask why the illegal opcodes never worked in my code, only because most of you guys come down hard on newbie old schoolers as myself...
2006-04-18 10:27
ready.

Registered: Feb 2003
Posts: 441
Glad my "silly" question helped you. Sometimes newbies like me need to put aside their ego and be careless about other people bad comments or insults. But I'm glad there are still people who are always ready to help newbies even in their most "simple and silly" problems!!
2006-04-18 12:30
TNT
Account closed

Registered: Oct 2004
Posts: 189
Yes, it's stupid to give important files names like "readme" or "readme.html". Who in their right mind would guess that searching "illegal" in either of those files would reveal the sacred secret of -i switch!


;)
2006-04-18 14:24
ready.

Registered: Feb 2003
Posts: 441
I must admit I'm always too lazy to go through the readme files. Too lazy even to to a search for "illegal". Mea culpa
2007-02-11 17:54
ready.

Registered: Feb 2003
Posts: 441
Hello,
back again on another problem with TASM, but this time I read the readme file, still it did not help.

I get the following message while compiling:

Ooops! Too many passes...

I can't find it into the error lists in the readme.txt

It is strange since it does not seem to be caused by the excessive length of my source code. In fact cutting a certain part of it does not eliminate the message, but simply deleting a single instruction in the right place fixes the problem.

Any sugestion?

thanks,
Ready.
2007-02-11 18:07
Scout

Registered: Dec 2002
Posts: 1570
Quote: Hello,
back again on another problem with TASM, but this time I read the readme file, still it did not help.

I get the following message while compiling:

Ooops! Too many passes...

I can't find it into the error lists in the readme.txt

It is strange since it does not seem to be caused by the excessive length of my source code. In fact cutting a certain part of it does not eliminate the message, but simply deleting a single instruction in the right place fixes the problem.

Any sugestion?

thanks,
Ready.


This sounds like a bug alright but maybe you can solve this using the .align $0100 command.
Put it somewhere near the area where it goes wrong.
2007-02-11 18:26
WVL

Registered: Mar 2002
Posts: 902
U-oh.. that's a real bug somewhere, yes :) I had it happen sometimes too, but could never pinpoint where it was coming from. I contacted SoCi about this once, and (iirc) he said he was aware of it, but wanted some sources that would reproduce the error.

Unfortunately, I just kept adding code and the error disappeared by itself again, so I couldnt send a source that had problems. (You might try switching to v1.44 or earlier, that helped me out anyway).

If your source still has problems, why not send it in to Soci?
2007-02-11 18:48
ready.

Registered: Feb 2003
Posts: 441
Hi,
I experienced the same situation as you, WVL, while coding the plotting part of Aurora for Level64. The message popped out, then after adding some code it went away.

Now I have just fixed it thanks to Scout's hint. I did not use .align $0100, but he made me think about some branch problem. I had:

...
cmp dx
bpl label1
...
...
label1
...

and it gave the problem. Then I tried:

...
cmp dx
bmi label2
jmp label1
label2
...
...
label1
...

and 64TASS compiled it fine. I guess you can try the same, by chaning branch codes into jump codes while developing your code, then once it is done, try to change each jump back to branch.

In case I have more about it, I'll write it here.

Ready.
2007-02-11 18:54
Scout

Registered: Dec 2002
Posts: 1570
Quote:
Now I have just fixed it thanks to Scout's hint. I did not use .align $0100, but he made me think about some branch problem.


Nice!

Maybe reading the manual might be an option because:

To avoid branch too long errors the assembler also supports long branches, it can automatically convert conditional relative branches to it's opposite and a JMP. This have to be enabled on the command line using the "--long-branch" option.
	bcc veryfar	;compiled as "bcc veryfar" or
			;	bcs sk
			;	jmp veryfar
			;sk




:D
2007-02-11 22:20
WVL

Registered: Mar 2002
Posts: 902
Quote: Quote:
Now I have just fixed it thanks to Scout's hint. I did not use .align $0100, but he made me think about some branch problem.


Nice!

Maybe reading the manual might be an option because:

To avoid branch too long errors the assembler also supports long branches, it can automatically convert conditional relative branches to it's opposite and a JMP. This have to be enabled on the command line using the "--long-branch" option.
	bcc veryfar	;compiled as "bcc veryfar" or
			;	bcs sk
			;	jmp veryfar
			;sk




:D


this is not really the bug that Ready is experiencing.

Too many passes error is a weird bug, and sometimes you can get rid of it by some simple things :

like swapping

LDA #$xx
LDX #$xx

to

LDX #$xx
LDA #$xx

which should make no difference, but still it can get rid of the bug.

In short, there's something wrong with 64tass v1.45.
2007-02-11 22:27
Scout

Registered: Dec 2002
Posts: 1570
Quote: this is not really the bug that Ready is experiencing.

Too many passes error is a weird bug, and sometimes you can get rid of it by some simple things :

like swapping

LDA #$xx
LDX #$xx

to

LDX #$xx
LDA #$xx

which should make no difference, but still it can get rid of the bug.

In short, there's something wrong with 64tass v1.45.


True, it is still a bug.
I forgot to mention that in my response to make that clear.
I was just pointing to the long branches commandline option.

I found also a small bug.
Not a nasty one because it only gives a warning (thank <fill in your entity of choice>);
if you have data/code that ends at $ffff, the compiler warns that the top of memory has exceeded (or something like that).

Like i said, not a real bug but i guess some internal tweaking has to be done inside the compilercode.
2007-02-12 08:57
WVL

Registered: Mar 2002
Posts: 902
Quote: True, it is still a bug.
I forgot to mention that in my response to make that clear.
I was just pointing to the long branches commandline option.

I found also a small bug.
Not a nasty one because it only gives a warning (thank <fill in your entity of choice>);
if you have data/code that ends at $ffff, the compiler warns that the top of memory has exceeded (or something like that).

Like i said, not a real bug but i guess some internal tweaking has to be done inside the compilercode.


/me has code ending at $ffff too ;D
2011-07-02 14:36
Hermit

Registered: May 2008
Posts: 208
Now I can confirm that this ´OOOPS, Too Many Passes´ is really coming from something related to branches.
At least this time I had to change an address of a BNE.
After playing around for nearly half an hour to get this solved.
As I´m working on a bigger project (SID tracker), I faced this message many times. Usually writing something randomly or continuing the code solved the situation most of the times, but now I couldn´t go forward without modifying the BNE address.

I assume that this message comes when there´s a branching somewhere near the $7f..$80 boundaries. But as it didn´t compile I couldn´t exactly check how much bytes the branch wanted to jump.

I hope this helps some of you to get rid of this annoying bug.

hermit
2011-07-02 18:15
WVL

Registered: Mar 2002
Posts: 902
Maybe you can send a non-compiling source to Soci? Everytime i stumbled upon that bug I just swapped some opcodes and continued, before thinking about saving the source and submitting it to soci so he could have a look at it and trace what's going wrong. (I will next time ;))
2011-07-02 18:52
Hermit

Registered: May 2008
Posts: 208
I found this error message in 64tass source code:

The extract from (ver1.46) 64tass.c line 2020:
....
    do {
        if (pass++20) {fprintf(stderr,"Ooops! Too many passes...\n");exit(1);}
        set_cpumode(arguments.cpumode);
	address=l_address=databank=dpage=longaccu=longindex=0;low_mem=full_mem;top_mem= 0;encoding=0;
        current_provides=0xffffffff;current_requires=0;current_conflicts=0;macrecursion= 0;
        fixeddig=1;waitfor[waitforp=0]=0;skipit[0]=1;sline=0;procname[0]=0;conderrors=wa rnings=0;freeerrorlist(0);
        /*	listing=1;flist=stderr;*/
        enterfile(arguments.input,0);
        sline=0;
        compile(arguments.input,0,0,"",-1,NULL);
        exitfile();
        if (errors) {status();return 1;}
        if (conderrors && !arguments.list && pass==1) fixeddig=0;
    } while (!fixeddig || (pass==1 && !arguments.list));
....

I wonder what causes the do while loop run more than 20 times increasing 'pass' variable.
2011-07-03 07:47
Hermit

Registered: May 2008
Posts: 208
Regarding source code that causes 'Oops, too many passes.'

I played around with branching to prove my assumption. Here is a code which recalls the bug, wherever you place it in memory:
loop	beq jploop 
		.rept $80
		NOP
		.next
jploop	jmp loop

As you can see, this would be a 'branch too far' normally, but the 2 byte bne xx isn't taken into account. That's why, writing .rept $81 of NOPs also causes the 'Oops', while .rept $82 and more calls 'branch too far'. The latter should be the case with $80 and $81 too. .rept $7f of NOPs and below is the safe area, where no error message at all.
Maybe I'll find in 64tass source where this can be fixed. At least we catched this bug, time to destroy it ;)
-I didn't experience this bug with backward-branching, because there 2 byte of BNE xx doesn't count into amount of max. jumping.
2011-07-03 09:54
Hermit

Registered: May 2008
Posts: 208
Here's an extract from 64tass.c 1.46 row 1767. It seems to calculate relative address by subtracting logical address (l_address) from absolute address value (val). And it substracts that 2 too (the 2 byte that bne/beq allocates). The problem must be in this if-else structure, because $80 and $81 branching both goes to the point where the normal (below $80) branches go. I restructured lookout of this code a bit to better see the hierarchy...

			 if (cnmemonic[ADR_REL]!=____) 
			 {
			  if (d) 
			  {
			   if (fixeddig && (l_address >> 16)!=(((unsigned)val) >> 16)) {err_msg(ERROR_BRANCH_TOOFAR,NULL); break;}
			   val=(val-l_address-2) & 0xffff;    //hermit: maybe this '2' should be handled in other way
			   if (val<0xFF80 && val>0x007F)      // hermit: checks BNE boundaries here. 
			   {
			    if (arguments.longbranch && (cnmemonic[ADR_ADDR]==____) && ((cnmemonic[ADR_REL] & 0x1f)==0x10)) 
			    {//branch
			     longbranch=0x20;val=0x4C03+(((val+l_address+2) & 0xffff) << 16);
			     if (fixeddig) err_msg(ERROR___LONG_BRANCH,NULL);
			    } 
			    else 
			    {
			     if (cnmemonic[ADR_ADDR]!=____) 
			     {
			      val=(val+l_address+2) & 0xffff;
			      opr=ADR_ADDR;w=1;ln=2;goto brancb;
			     }
			     else if (cnmemonic[ADR_REL_L]!=____) 
			     {//gra
			      val=(val-1) & 0xffff;
			      opr=ADR_REL_L;w=1;ln=2;goto brancb;
			     }
			     else if (fixeddig) {err_msg(ERROR_BRANCH_TOOFAR,NULL); break;}
			    }
			   }
			   opr=ADR_REL;w=0;// bne  -hermit: bne with safe 00..$7f jump comes here ------BUT WHY $80 and $81 too?
			  } else fixeddig=0; if (longbranch) ln=4; else ln=1;
			 }
2011-07-03 13:18
soci

Registered: Sep 2003
Posts: 480
Should work now.

svn co https://tass64.svn.sourceforge.net/svnroot/tass64/trunk tass64
2011-07-03 13:51
WVL

Registered: Mar 2002
Posts: 902
soci : do you also have a compiled version available? :) (somehow the official version is always 10x smaller and faster than any that i can compile myself)
2011-07-03 14:04
soci

Registered: Sep 2003
Posts: 480
http://sourceforge.net/projects/tass64/files/binaries/

Here's a win32 binary, I haven't tried it, maybe it does not even execute. Mac donations or hints how to cross compile on Linux are accepted ;)
2011-07-03 17:55
Hermit

Registered: May 2008
Posts: 208
Hi there Soci

It was fast, thank you very much for the effort.
I compiled it in Puppy Linux, works perfectly, 82kbyte, little bit more than previously. And the binary should work fine on the other Linux distros too.
If you don't mind I shared the linux binary here, in a zip with the license texts, just as with your .exe verison:
http://hermit.netne.net/c64prog/64tass-1.46-r38.zip

Cheers, You made my day even better with this fix :)
2011-07-03 19:18
chatGPZ

Registered: Dec 2001
Posts: 11386
"somehow the official version is always 10x smaller and faster than any that i can compile myself"
strip -s to the rescue =)
2011-07-04 18:46
Hein

Registered: Apr 2004
Posts: 954
Quote: http://sourceforge.net/projects/tass64/files/binaries/

Here's a win32 binary, I haven't tried it, maybe it does not even execute. Mac donations or hints how to cross compile on Linux are accepted ;)


Thanks.
2011-07-04 22:32
Kaizen

Registered: May 2009
Posts: 24
Hi,
tried now to compile on Mac OS X.


The first makefile returns some errors:

gcc -c -o 64tass.o 64tass.c
gcc -c -o opcodes.o opcodes.c
gcc -c -o misc.o misc.c
misc.c:25:18: error: argp.h: No such file or directory
misc.c:601: error: array type has incomplete element type
misc.c:628: error: syntax error before 'parse_opt'
misc.c:628: warning: 'struct argp_state' declared inside parameter list
misc.c:628: warning: its scope is only this definition or declaration, which is probably not what you want
misc.c: In function 'parse_opt':
misc.c:668: error: 'ARGP_KEY_ARG' undeclared (first use in this function)
misc.c:668: error: (Each undeclared identifier is reported only once
misc.c:668: error: for each function it appears in.)
misc.c:668: error: dereferencing pointer to incomplete type
misc.c:669: error: 'ARGP_KEY_END' undeclared (first use in this function)
misc.c:669: error: dereferencing pointer to incomplete type
misc.c:670: error: 'ARGP_ERR_UNKNOWN' undeclared (first use in this function)
misc.c: At top level:
misc.c:675: error: variable 'argp' has initializer but incomplete type
misc.c:675: warning: excess elements in struct initializer
misc.c:675: warning: (near initialization for 'argp')
misc.c:675: warning: excess elements in struct initializer
misc.c:675: warning: (near initialization for 'argp')
misc.c:675: warning: excess elements in struct initializer
misc.c:675: warning: (near initialization for 'argp')
misc.c:675: warning: excess elements in struct initializer
misc.c:675: warning: (near initialization for 'argp')
make: *** [misc.o] Error 1


Instead the makefile2 returns only some warnings:

gcc -Wall -DWIN32 -c -o 64tass.o 64tass.c
64tass.c: In function 'compile':
64tass.c:2047: warning: format '%06x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
64tass.c:2055: warning: format '%04x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
64tass.c:2055: warning: format '%06x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
64tass.c:2071: warning: suggest parentheses around comparison in operand of ^
64tass.c:745: warning: unused variable 'filestat'
64tass.c:740: warning: unused variable 'fflen'
gcc -Wall -DWIN32 -c -o opcodes.o opcodes.c
gcc -Wall -DWIN32 -c -o misc.o misc.c
gcc 64tass.o opcodes.o misc.o -o 64tass


Could this second version works well?
Sorry for my question, but I don't know C and so I cannot understand what means this several warnings.
THX. ;-)
2011-07-05 09:18
WVL

Registered: Mar 2002
Posts: 902
I recompiled Pearls for Pigs with v1.46, no problems, everything went ok and the demo runs fine ;)
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
MWR/Visdom
Mike
ΛΛdZ
encore
WVL/Xenon
grennouille
deetsay
Guests online: 114
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Musicians
1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.083 sec.