I don't understand what is happening here. I created the following .C file... int main(void) { asm("lda #$C1"); asm("jsr $FDED"); asm("clc"); asm("adc #$01"); asm("cmp #$DB"); asm("bne $0849"); // assumes $0800 will be the base address return 0; } it generated the following code .segment "CODE" lda #$C1 jsr $FDED clc adc #$01 cmp #$DB jne $0849 ldx #$00 ; I didn't put this here txa ; I didn't put this here rts .endproc It still works just fine. The problem is, however, if I BLOAD Sample.bin, A$800 then I actually have to go into the monitor as say 0847G. I don't understand what it's doing, but it is supposed to be executable at $0800, not $0847. I compile as follows: cc65 -O -t apple2 sample.c ca65 -t apple2 sample.s ld65 -t apple2 -o sample.bin apple2.o sample.o apple2.lib And then use applecommander to place it in the dos disk. I can't omit the apple2.o or apple2.lib or it won't compile. That's too bad, because I would like to create my own set of libraries for when I need compact code (just to see how well I can do it). Anyway, why does it start my code at $0847 and is there a way I can cause it to start at the address I intend ($0800)? Thanks, Shawn "Shawn B." wrote in message news:nnpeb.8104$UD2.6242@newssvr27.news.prodigy.com... > Greetings, > > Based on posts from other people in this NG I was able to compile the Hello > example for Apple in cc65. I have BLOADED it into A$800. If I BRUN it > there, it doesn't has problems. I realize the first 2 bytes and next 3 are > reserved. Then the next 1. So if I type in the monitor 806 G it doesn't > work, either. How am I supposed to execute this thing? > > BTW, I used Apple Commander to put the file into a DOS 3.3 image. I'm > hardly looking forward to doing this in ProDOS, it doesn't seem easy. > > > Thanks, > Shawn > > Okay, I've discovered that if I compile anything that requires any of the standard ansi headers, I can't execute them. They will all start their entry point at (Base+$47) bytes ($0847 is the default entry point) but if I use a standard header include (such as printf) it always locks up and goes into an endless loop. I'm using both Kegs32 and XGS32 and get the same results. If I create my own (as listed below in the quote) it works fine. Perhaps I'm doing something wrong? Thanks, Shawn "Shawn B." wrote in message news:F_seb.298$S33.48201041@newssvr21.news.prodigy.com... > I don't understand what is happening here. I created the following .C > file... > > int main(void) { > asm("lda #$C1"); > asm("jsr $FDED"); > asm("clc"); > asm("adc #$01"); > asm("cmp #$DB"); > asm("bne $0849"); // assumes $0800 will be the base address > > return 0; > } > > it generated the following code > > .segment "CODE" > > lda #$C1 > jsr $FDED > clc > adc #$01 > cmp #$DB > jne $0849 > ldx #$00 ; I didn't put this here > txa ; I didn't put this here > rts > > .endproc > > > It still works just fine. The problem is, however, if I BLOAD Sample.bin, > A$800 then I actually have to go into the monitor as say 0847G. I don't > understand what it's doing, but it is supposed to be executable at $0800, > not $0847. > > I compile as follows: > > cc65 -O -t apple2 sample.c > ca65 -t apple2 sample.s > ld65 -t apple2 -o sample.bin apple2.o sample.o apple2.lib > > And then use applecommander to place it in the dos disk. I can't omit the > apple2.o or apple2.lib or it won't compile. That's too bad, because I would > like to create my own set of libraries for when I need compact code (just to > see how well I can do it). > > Anyway, why does it start my code at $0847 and is there a way I can cause it > to start at the address I intend ($0800)? > > > Thanks, > Shawn > > > "Shawn B." wrote in message > news:nnpeb.8104$UD2.6242@newssvr27.news.prodigy.com... > > Greetings, > > > > Based on posts from other people in this NG I was able to compile the > Hello > > example for Apple in cc65. I have BLOADED it into A$800. If I BRUN it > > there, it doesn't has problems. I realize the first 2 bytes and next 3 > are > > reserved. Then the next 1. So if I type in the monitor 806 G it doesn't > > work, either. How am I supposed to execute this thing? > > > > BTW, I used Apple Commander to put the file into a DOS 3.3 image. I'm > > hardly looking forward to doing this in ProDOS, it doesn't seem easy. > > > > > > Thanks, > > Shawn > > > > > > "Shawn B." writes: >The problem is if I start it at any other memory address nothing gets >executed. So I don't know what I'm doing wrong, then. The first two >bytes are 00 08 so if I brun it BRUN X, A$800 the first byte is 00 and it >breaks. If I selectively try to execute from any other byte starting with >0801 until 0846 it fails. It only succeeds at 0847. Perhaps I'm not >compiling properly or linking, I don't know. If you have an extra start/length field showing up on your data, try loading it at $800 minus 4 equals $7fc. Then try 800G. -- David Wilson School of IT & CS, Uni of Wollongong, Australia "Shawn B." wrote in message news:F5Efb.7338$TE.6968@newssvr29.news.prodigy.com... > Yes, that worked. But it's annoying. Is there a way I can make this thing > compile without the lading 4 bytes? As I've mentioned before these 4 bytes should not be there (in memory) after you use "BLOAD" or "BRUN" under DOS 3.3. They must of course be in the file (on the disk). Since you are getting them in memory, something must be adding a second set of 4 bytes. As Chris Morse mentioned in his post, you may be importing it incorrectly by not setting your import to "RAW". Check your file with a hex viewer or hex editor to see if you have just a 4 byte header. Do this after you create it with cc65 but before you import it into a disk image. Then you will know if cc65 is adding an extra 4 bytes. After you import the file into the disk image but before you BLOAD or BRUN it again check it with a hex viewer to see if it is the same. I'm betting that Chris is right but in any case this should tell where things go wrong. > When I examine all the other files I've > bsaved I don't see these leading 4 bytes so I don't think they are > necessary. The 4 bytes are necessary in DOS 3.3 since it has no other way of determining where to load the program. The 4 bytes should NOT be in the file at all in ProDOS since it keeps that information in a "File Descriptive Entry" in the directory block(s). Charlie On Sat, 04 Oct 2003 23:27:57 GMT, "Shawn B." wrote: >Thanks for the replies. I have looked at the raw binary image. It does not >have a double header. > >http://www.visualassembler.com/cc65/cc65.gif > >That is a snapshot of what I see. > > >Thanks, >Shawn > It won't have a double-header on the PC side. It's when you IMPORT it into a disk image that the extra header is being pre-pended. If you boot your virtual Apple II and "BLOAD F,A$800" (where F is the name of your File), then do a "CALL -151" and then an "800L" and you see your file beginning with "00 08 97 01 .. .." then your importing tool is adding the extra header. Look for a "RAW" mode. I don't know what tool you are using, but I use A2TOOLS. The command is: a2tools in -r B WORKDISK.dsk HELLO2.BIN HELLO2.BIN The "-r" tells a2tools to import in RAW mode (don't add binary header) // CHRIS "Shawn B." wrote: > return 0; > ldx #$00 ; I didn't put this here > txa ; I didn't put this here You DID put that there. It is obviously the "return 0". -- Paul On Wed, 01 Oct 2003 00:39:47 GMT, "Shawn B." wrote: >Greetings, > >Based on posts from other people in this NG I was able to compile the Hello >example for Apple in cc65. I have BLOADED it into A$800. If I BRUN it >there, it doesn't has problems. I realize the first 2 bytes and next 3 are >reserved. Then the next 1. So if I type in the monitor 806 G it doesn't >work, either. How am I supposed to execute this thing? > >BTW, I used Apple Commander to put the file into a DOS 3.3 image. I'm >hardly looking forward to doing this in ProDOS, it doesn't seem easy. > > >Thanks, >Shawn You have to specify a "RAW" import into the disk image. Otherwise, your binary will end up with TWO "Load Address / Length" headers, and when you BLOAD it, you'll have an extra Address/Length header at the start of the program (4 bytes.) // CHRIS