C64 CBM ASM bug?

[Ed]

There appears to be a bug in the C64 CBM assembler:

TEST.S......PAGE 0001

LINE# LOC CODE LINE

00001 0000 * = $800
00002 0800 10 04 .WORD 16+1024
00003 0802 10 04 .WORD 1024+16
00004 0804 10 00 .WORD 16*1024
00005 0806 00 04 .WORD 1024*16
00006 0808 .END

ERRORS = 00000

END OF ASSEMBLY

Lines 4 & 5 produce different output. In theory they should
evaluate to the same number i.e. $4000.

It's possible I have a corrupt version of the assembler. Does
anyone else get the same results?

Also, the cross-reference generator seems to output many
pages of junk e.g.

CROSS REFERENCE......PAGE 1

* ÿÿÿÿÿ $FFFF 12336
* ÿÿÿÿÿÿ $FF00 12336
* $0000 12336
* $0000 12336
* $0000 12336
* $0000 12336
...

Again, maybe CROSSREF (or the asm) is corrupt :(

I'm running this on VICE 1.2. I don't know if CBM ever
released more than version of the assembler. This one
signs on as: 'CBM RESIDENT ASSEMBLER V080282'

I don't plan to use the CBM assembler for serious work;
just curious as to what's going on.

[rusure]

    TEST.S......PAGE 0001
    LINE# LOC   CODE        LINE
    00001  0000              *      = $800
    00002  0800  10 04              .WORD 16+1024
    00003  0802  10 04              .WORD 1024+16
    00004  0804  10 00              .WORD 16*1024
    00005  0806  00 04              .WORD 1024*16
    00006  0808                     .END
    ERRORS = 00000
    END OF ASSEMBLY
 Lines 4 & 5 produce different output.  In theory they should
evaluate to the same number i.e. $4000.
It's possible I have a corrupt version of the assembler.  Does
anyone else get the same results?
Also, the cross-reference generator seems to output many
pages of junk e.g.
CROSS REFERENCE......PAGE    1
    *  ÿÿÿÿÿ $FFFF 12336
    * ÿÿÿÿÿÿ $FF00 12336
    *        $0000 12336
    *        $0000 12336
    *        $0000 12336
    *        $0000 12336
    ...
Again, maybe CROSSREF (or the asm) is corrupt :(
I'm running this on VICE 1.2.  I don't know if CBM ever
released more than version of the assembler.  This one
signs on as: 'CBM RESIDENT ASSEMBLER V080282'
I don't plan to use the CBM assembler for serious work;
just curious as to what's going on.

After some preliminary play with your trivial source code, I can
report that I get exactly the same assembler listing as yours. I am
running my assembler on a C128D in C64 mode. My assembler lists the
same banner as yours. Before running the cross reference program, the
assembler generates 2 intermediate files containing cross reference
data. You can list the files in a directory by executing the
following DOS wedge command : @$xr??000?

The first file occupies 212 blocks. When I run the cross reference
program, I get 21 pages of gibberish. The program terminates with a
disk full diagnostic.

I originally bought the system disk and manual for this assembler at a
flea market, but you can download the macro assembler development
system (MADS) from here:

The MADS site is : http://www.haddewig.de/nogames64/tools.html
Click on the Commodore Assembler entry. The MADS files from
the WEB site are 1 byte longer than those on the original
Commodore system disk, except for the DOS WEDGE booting programs.
Both WEDGE booters appear to perform equivalent operations.
The MADS doc site is : http://project64.c64.org/misc/index.html

I have developed my code only with this assembler. It is tedious to
use but it's the only assembler I know that can generate symbolic
cross reference maps. Let me play with your code some more before I
comment further on your discovery.

[rusure]

    TEST.S......PAGE 0001
    LINE# LOC   CODE        LINE
    00001  0000              *      = $800
    00002  0800  10 04              .WORD 16+1024
    00003  0802  10 04              .WORD 1024+16

The addition processor seems to be working here. The only time I have
ever used the arithmetic processor is to calculate addresses that are
offset from a label. The only arithmetic operations I have needed is
addition and subtraction. I am unaware of any problems with the
limited arithmetic operations I have used with this assembler.

    00004  0804  10 00              .WORD 16*1024
    00005  0806  00 04              .WORD 1024*16

Clearly, the multiplication processor is faulty with this assembler

    00006  0808                     .END
    ERRORS = 00000
    END OF ASSEMBLY
 Lines 4 & 5 produce different output.  In theory they should
evaluate to the same number i.e. $4000.
It's possible I have a corrupt version of the assembler.  Does
anyone else get the same results?
Also, the cross-reference generator seems to output many
pages of junk e.g.

When I put a label in line 2 of your source, the cross reference
utility works properly. All files containing the cross reference data
were of reasonable size.

AFIK the cross reference utility can't handle programs with no labels.

[Ed]

Post by Ed
TEST.S......PAGE 0001
LINE# LOC CODE LINE
00001 0000 * = $800
00002 0800 10 04 .WORD 16+1024
00003 0802 10 04 .WORD 1024+16

The addition processor seems to be working here. The only time I have
ever used the arithmetic processor is to calculate addresses that are
offset from a label. The only arithmetic operations I have needed is
addition and subtraction. I am unaware of any problems with the
limited arithmetic operations I have used with this assembler.

Post by Ed
00004 0804 10 00 .WORD 16*1024
00005 0806 00 04 .WORD 1024*16

Clearly, the multiplication processor is faulty with this assembler

Post by Ed
00006 0808 .END
ERRORS = 00000
END OF ASSEMBLY
Lines 4 & 5 produce different output. In theory they should
evaluate to the same number i.e. $4000.
It's possible I have a corrupt version of the assembler. Does
anyone else get the same results?
Also, the cross-reference generator seems to output many
pages of junk e.g.

When I put a label in line 2 of your source, the cross reference
utility works properly. All files containing the cross reference data
were of reasonable size.

AFIK the cross reference utility can't handle programs with no labels.
---------------------------

Thanks for your investigation and confirmation.

Likely, the CBM assembler is treating '*' as the program counter
location and getting confused.

Given their likely MOS Technology origin, I wonder if the AIM,
SYM, KIM rom assemblers have the same bug!

Thanks for the tip on the cross-reference generator. I imagine
there wouldn't be too many asm files with no labels :)

[rusure]

On May 22, 11:36 pm, "Ed" <***@invalid.com> wrote:
.

Post by Ed

Post by rusure

Post by Ed
00004 0804 10 00 .WORD 16*1024
00005 0806 00 04 .WORD 1024*16

Clearly, the multiplication processor is faulty with this assembler

Likely, the CBM assembler is treating '*' as the program counter
location and getting confused.

I wonder if "/"s or "-"s confuse the assembler like "*"s do. There
are 2 parties that may be confused. One of the confused parties could
be the asembler. The other possible confused party may be the
assembler user.

[Pasi Ojala]

Post by Ed
Likely, the CBM assembler is treating '*' as the program counter
location and getting confused.

Did you try it with parenthesis, i.e. ".word (1024*16)" ?

-Pasi

[Greg King]

Post by Ed
Likely, the CBM assembler is treating '*' as the program counter
location and getting confused.

Did you try it with parenthesis, i.e. ".word (1024*16)"?

Parentheses cause a "can't eval expression" message.
Division seems to work OK. I ran this test:

LINE# LOC CODE LINE
00001 0000 F0 3F .WORD 16*1023
00002 0002 10 00 .WORD 16*1024
00003 0004 10 40 .WORD 16*1025
00004 0006 01 04 .WORD 1025*16
00005 0008 11 44 .WORD 1025*17
00006 000A .END

The assembler's multiplication code fails when only one of the multiplier's
bits is 1 (it thinks that the multiplier's _value_ is 1).

[iAN CooG]

Post by Greg King
Parentheses cause a "can't eval expression" message.
The assembler's multiplication code fails when only one of the
multiplier's bits is 1 (it thinks that the multiplier's _value_ is 1).

ok, time to upgrade to a "slightly" better assembler =)

[rusure]

Post by iAN CooG
ok, time to upgrade to a "slightly" better assembler =)

When I owned it, I was unable to find a way for BUDDY 128 to produe a
symbolic cross referene map. Unlike MERLIN or BUDDY, this assembler
is a Commodore product. Towards the end of the C64 / C128 product
run, Commodore released for sale a C128 assembler. I don't know if
the Commodore C128 assembler had a symbolic crossreference mapping
capability. For some strange reason, xmaps are now passe. I took a
course in C in 1998 and they never used xmaps. I desparately needed
xmaps when I was programming in FORTRAN in the 1970's and early 80s.
Although I cansider them crucial for my coding, I don't know of any
other assembler with an XMAP capability.

[Ed]

Post by Greg King

Post by Ed
Likely, the CBM assembler is treating '*' as the program counter
location and getting confused.

Did you try it with parenthesis, i.e. ".word (1024*16)"?

Parentheses cause a "can't eval expression" message.
LINE# LOC CODE LINE
00001 0000 F0 3F .WORD 16*1023
00002 0002 10 00 .WORD 16*1024
00003 0004 10 40 .WORD 16*1025
00004 0006 01 04 .WORD 1025*16
00005 0008 11 44 .WORD 1025*17
00006 000A .END
The assembler's multiplication code fails when only one of the multiplier's
bits is 1 (it thinks that the multiplier's _value_ is 1).

The mult code begins at $18AE. It may be possible to
patch over with good code if enough room.

--
While dumping the code I noticed there's an .IFE and
.IFN instruction. Presumably these are for conditional
compilation. They're not mentioned in the doc. Tried
to use them but can't find a working syntax. Perhaps they
were never actually implemented.

[Ed]

Post by Ed

Post by Greg King

Post by Ed
Likely, the CBM assembler is treating '*' as the program counter
location and getting confused.

Did you try it with parenthesis, i.e. ".word (1024*16)"?

Parentheses cause a "can't eval expression" message.
LINE# LOC CODE LINE
00001 0000 F0 3F .WORD 16*1023
00002 0002 10 00 .WORD 16*1024
00003 0004 10 40 .WORD 16*1025
00004 0006 01 04 .WORD 1025*16
00005 0008 11 44 .WORD 1025*17
00006 000A .END
The assembler's multiplication code fails when only one of the multiplier's
bits is 1 (it thinks that the multiplier's _value_ is 1).

The mult code begins at $18AE. It may be possible to
patch over with good code if enough room.
...

Here's a patch to fix the multiply bug.

Should anyone apply it, it's probably a good idea to alter
the sign-on banner to indicate the program has been
patched.

;
; C64 CBM ASSEMBLER MULTIPLY BUG FIX
;
; ORIGINAL (FAULTY) CODE

*= $18BC ; 'PRG' BINARY OFFSET = $10BD

LBL1 ASL $087C ; 0E 7C 08
ROL $087B ; 2E 7B 08
LSR $0853 ; 4E 53 08
ROR $0854 ; 6E 54 08
BCC LBL2 ; 90 13
CLC ; 18
LDA $087C ; AD 7C 08
ADC $086D ; 6D 6D 08
STA $087C ; 8D 7C 08
LDA $087B ; AD 7B 08
ADC $086C ; 6D 6C 08
STA $087B ; 8D 7B 08
LBL2 LDA $0853 ; AD 53 08
ORA $0854 ; 0D 54 08
BNE LBL1 ; D0 D7

;
; FIXED CODE
;
*= $18BC ; 'PRG' BINARY OFFSET = $10BD

LDY #16 ; A0 10
LBL1 ASL $087C ; 0E 7C 08
ROL $087B ; 2E 7B 08
ASL $0854 ; 0E 54 08
ROL $0853 ; 2E 53 08
BCC LBL2 ; 90 13
CLC ; 18
LDA $087C ; AD 7C 08
ADC $086D ; 6D 6D 08
STA $087C ; 8D 7C 08
LDA $087B ; AD 7B 08
ADC $086C ; 6D 6C 08
STA $087B ; 8D 7B 08
LBL2 DEY ; 88
BNE LBL1 ; D0 DC
NOP ; EA
NOP ; EA
NOP ; EA

; END

[Ed]

Post by Ed
...
While dumping the code I noticed there's an .IFE and
.IFN instruction. Presumably these are for conditional
compilation. They're not mentioned in the doc. Tried
to use them but can't find a working syntax. Perhaps they
were never actually implemented.

I did some more investigating. The CBM assembler has
conditional compilation, albeit undocumented. The syntax is:

.IFN expression <
asm statements
If 'expression' evaluates to true (non-zero) then the lines
between < ... > are assembled.

.IFE works similarly except the condition is reversed.