Re: [cc65] rebuilding libraries - generated program crashes

Date view Thread view Subject view

From: jimsymolon (jsymolon01_at_attbi.com)
Date: 2003-06-07 21:15:44


jimsymolon wrote:

> Ullrich von Bassewitz wrote:
>
>> On Fri, May 30, 2003 at 12:20:05AM +0200, Groepaz wrote:
>>  
>>
>>> mmmh i dont think this is a windows cr/lf related problem (ofcoz, 
>>> still check
>>> it! :=)) ... i'm using a simelar setup for the c64 (one linux box, one
>>> windoze box, and because i havent really bothered looking into 
>>> cbm4linux yet
>>> the 1541 is hooked to the windoze pc) and never had problems related 
>>> to cr/lf
>>> conversion. (only tools that expect a "text" file would have this 
>>> problem,
>>> and none of the tools involved does that).
>>>   
>>
>>
>> All similar problems that have been reported were caused by 
>> corruption when
>> transfering files. And Samba is able to do some sort of "auto 
>> conversion". So
>> it's really worth to check it.
>>
>> Regards
>>
>>
>>        Uz
>>
>>
>>  
>>
> I'll take a look into the samba angle.
>
>
>
>
> ----------------------------------------------------------------------
> To unsubscribe from the list send mail to majordomo_at_musoftware.de with
> the string "unsubscribe cc65" in the body(!) of the mail.
>
I've started from scratch.  Deleted the windows and linux installs and 
re-installed.

The original library and the re-build on linux are the same size.  I 
really don't think that it is a compiler or assembler problem.

The windows install is on the local C: drive.  It is not using Samba as 
a file server.

Both systems produce the same binary files.

How I build:
cl65 -t apple2 -l -o hello hello.c
ld65 -t apple2 -o hello hello.o /usr/lib/cc65/apple2.o apple2.lib

This consistantly builds the same binary file.

I've installed a linux apple2 emulator (with svgalibs ...).  Using this 
and the applewin emulator produce the same results.

I load the binary file into a Dos3.3 disk using a2tools and load that 
"disk" into an emulator.

"Boot" the apple2 and BLOAD the file into memory at location $800
    ]BLOAD HELLO,A$800
    ]CALL-151
    *800L
    0800-00        BRK  
    0801-08        PHP
    0802-C4 09     CPY $09
    0804-A2 19     LDX #$19
    0806-B5 00     LDA $00,X
    0808-9D 98 11  STA $1198,X
    080B-CA        DEX
    080C-10 F8     BPL $0806
    080E-20 F1 0E  JSR $0EF1
    0811-BA        TSX
    0812-8E C4 11  STX $11C4
    0815-A5 73     LDA $73
    0817-85 00     STA $00
    0819-A5 74     LDA $74
    081B-85 01     STA $01
    081D-20 34 0F  JSR $0F34
    0820-A9 FF     LDA #$FF
    0822-85 32     STA $32
    0824-20 08 10  JSR $1008
    0827-20 08 10  JSR $1008

This the start of the crt0 from the library.  The program will BRK 
immediately, so I tell it to start at $802.  It usually BRKs at $100A, 
but I know that all the JSRs are resolved to the wrong addresses.  For 
example:  the jsr $ef1 is the zerobss function call.  If I dump the $EF1 
memory it looks like so:

    0EF1-AE B6 11 LDX $11B6
    0EF4-60       RTS
    0EF5-A9 C4    LDA #$C4
    0EF7-85 08    STA $08
    0EF9-A9 11    LDA #$11
    0EFB-85 09    STA $09
    0EFD-A9 00    LDA #$00
    0EFF-A8       TAY
    0F00-A2 00    LDX #$00
    0F02-F0 0A    BEQ $0F0E
    0F04-91 08    STA ($08),Y
    0F06-C8       INY
    0F07-D0 FB    BNE $0F04
    0F09-E6 09    INC $09
    0F0B-CA       DEX
    0F0C-D0 F6    BNE $0F04


  Starting from $0EF5, I would say that's the zerobss code.  It's pretty 
close to what the assembler listing.

000000r 1               zerobss:
000000r 1  A9 rr            lda    #<__BSS_RUN__
000002r 1  85 rr            sta    ptr1
000004r 1  A9 rr            lda    #>__BSS_RUN__
000006r 1  85 rr            sta    ptr1+1
000008r 1  A9 00            lda    #0
00000Ar 1  A8               tay
00000Br 1
00000Br 1               ; Clear full pages
00000Br 1
00000Br 1  A2 rr        L1:    ldx    #>__BSS_SIZE__
00000Dr 1  F0 0A            beq    L3
00000Fr 1  91 rr        L2:    sta    (ptr1),y
000011r 1  C8                  iny
000012r 1  D0 FB               bne    L2
000014r 1  E6 rr            inc    ptr1+1
000016r 1  CA               dex
000017r 1  D0 F6            bne    L2


But the main program JSRs to 4 bytes before ??  I've produced a verbose 
map and this is part of the Exports List:

_vcprintf                 000EC1 RL
zerobss                   000EF1 RL
addysp1                  000F14 RL
addysp                    000F15 RL

Taking a quick look at the code at $F14:
0f10-f0 05   BEQ $0F17
0F12-91 08   STA ($08),Y
0F14-C8      INY
0F15-D0 F7   BNE $0F0E
0F17-60      RTS
0F18-C8      INY
0F19-48      PHA
0F1A-18      CLC
0F1B-98      TYA
0F1C-65 00   ADC $00
0F1E-85 00   STA $00

If my theory is correct - addysp and addysp1 should be at 0F18 and 0F19:
000000r 1                          .export        addysp1, addysp
000000r 1                   .importzp    sp
000000r 1
000000r 1               addysp1:
000000r 1  C8               iny
000001r 1  48           addysp:    pha                   ; Save A
000002r 1  18                clc
000003r 1  98                tya                   ; Get the value
000004r 1  65 rr             adc    sp               ; Add low byte
000006r 1  85 rr             sta    sp               ; Put it back

And it looks pretty close.

What I think is happening, is the EXEHDR is not being stripped off. 
 What can be done to supress the EXEHDR from the output file ?

I've just checked by "stripping" the 1st four bytes off by loading "low".
   ]BLOAD HELLO,A$7FC

and it runs fine.  Damn....



----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2003-06-07 21:28:36 CEST