Assemble HelloWorld with Ca65
regi...@retronym.de
at http://www.cc65.org/doc/intro-6.html.
...
cl65 -O -t apple2 hello.c text.s
...
a2tools in -r b cc65.dsk TEST hello
...
Is there something equivalent for using the ca65 for HelloWorld in
assembly?
MSG: .ASCIIZ "Hello, world!"
LDX #0
LDA MSG,X ; load initial char
@LP: JSR $FDED ; cout
INX
LDA MSG,X
BNE @LP
RTS
--Dietmar
markw...@yahoo.com
http://www.geocities.com/mmphosis/apple2/contest/2008/retrochallenge.net.html
> Is there something equivalent for using the ca65 for HelloWorld in assembly?
Huh? Are you asking for an equivilent assembler, an equivilent
HelloWorld program? What?
regi...@retronym.de
> Here are some 6502 assember HELLO WORLD programs for the Apple-1:http://www.geocities.com/mmphosis/apple2/contest/2008/retrochallenge....
>
> > Is there something equivalent for using the ca65 for HelloWorld in assembly?
>
> Huh? Are you asking for an equivilent assembler, an equivilent
> HelloWorld program? What?
Sorry
How can I assemble a simple program with ca65 and make it runable.
David Schmenk
You have to use the linker/loader to create a binary that can be run.
You also need a configuration file to map out the different segments in
memory. Sounds harder than it is. Here is my makefile and config file
used for HBCC 3D:
makefile:
---------
AFLAGS =
LFLAGS = -C apple2bin.cfg
BINFILE = escape.obj.bin
OBJS = main.o player.o render.o raycast.o sfx.o math.o
$(BINFILE): $(OBJS)
ld65 $(LFLAGS) $(OBJS) -o $(BINFILE)
main.o: main.s global.inc
ca65 $(AFLAGS) $<
player.o: player.s global.inc
ca65 $(AFLAGS) $<
render.o: render.s global.inc
ca65 $(AFLAGS) $<
raycast.o: raycast.s global.inc
ca65 $(AFLAGS) $<
sfx.o: sfx.s global.inc
ca65 $(AFLAGS) $<
math.o: math.s global.inc
ca65 $(AFLAGS) $<
config file apple2bin.cfg:
--------------------------
MEMORY {
RAM: start = $6000, size = $8E00, file = %O;
}
SEGMENTS {
CODE: load = RAM, type = ro;
DATA: load = RAM, type = rw;
BSS: load = RAM, type = rw;
}
This builds the binary to run at address $6000. In your case, typing
this should build your binary from source (hello.s):
ca65 hello.s
ld65 -C apple2bin.cfg hello.o -o hello
Now, you need to transfer the binary to a ProDOS disk image and run from
an emulator or copy to a real floppy to run on hardware.
You would run by typing:
BRUN HELLO, A$6000
from BASIC.SYSTEM under ProDOS. The A$6000 is needed to force the load
address to match where the binary was built from the cfg file. Under
DOS 3.3 things are a little different as the load address and size are
embedded in the first 4 bytes of the binary. I would try it using an
emulator running ProDOS first, just to make sure you have the process down.
Hope that wasn't too confusing.
Dave...
regi...@retronym.de
Thank you for the info and the config file.
>Under
> DOS 3.3 things are a little different as the load address and size are
> embedded in the first 4 bytes of the binary. I would try it using an
> emulator running ProDOS first, just to make sure you have the process down.
It's too bad that I want to use it for assemble DOS 3.3 programs (the
cc65 C-Compiler HelloWorld example makes a runable DOS 3.3 program).
>
> Hope that wasn't too confusing.
>
It's confusing, but your contribution helps. Thanks again.
Michael J. Mahon
>
> Thank you for the info and the config file.
>
>
>>Under
>>DOS 3.3 things are a little different as the load address and size are
>>embedded in the first 4 bytes of the binary. I would try it using an
>>emulator running ProDOS first, just to make sure you have the process down.
>
>
> It's too bad that I want to use it for assemble DOS 3.3 programs (the
> cc65 C-Compiler HelloWorld example makes a runable DOS 3.3 program).
The only thing that's required is getting the address and length in
front of the data in the file, and cc65 has to cope with that, too.
One simple way using standard tools is to create the object file on
a ProDOS image, then use Copy II Plus to copy the file to a DOS 3.3
binary file--that will automatically do the job.
A general cross-tool would be handy, too, but since I don't use them,
I don't know what they are. I'd guess that the cc65 includes one, if
it can make DOS binary files.
-michael
NadaPong: Network game demo for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
David Schmenk
> regi...@retronym.de wrote:
>>
>> Thank you for the info and the config file.
>>
>>
>>> Under
>>> DOS 3.3 things are a little different as the load address and size are
>>> embedded in the first 4 bytes of the binary. I would try it using an
>>> emulator running ProDOS first, just to make sure you have the process
>>> down.
>>
>>
>> It's too bad that I want to use it for assemble DOS 3.3 programs (the
>> cc65 C-Compiler HelloWorld example makes a runable DOS 3.3 program).
>
> The only thing that's required is getting the address and length in
> front of the data in the file, and cc65 has to cope with that, too.
>
CC65 will create an additional memory segment for the apple2 that gets
linked at the beginning of the binary which contains the start address
and size. From what I can tell, cc65 is really set up for ProDOS, but
has some very basic DOS 3.3 support. I think the file io library is
pretty much ProDOS only.
> One simple way using standard tools is to create the object file on
> a ProDOS image, then use Copy II Plus to copy the file to a DOS 3.3
> binary file--that will automatically do the job.
>
This is the approach I use. Foolproof and easy. Especially since
Virtual ][ will mount a directory as a ProDOS volume.
> A general cross-tool would be handy, too, but since I don't use them,
> I don't know what they are. I'd guess that the cc65 includes one, if
> it can make DOS binary files.
>
> -michael
>
> NadaPong: Network game demo for Apple II computers!
> Home page: http://members.aol.com/MJMahon/
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."
Probably the biggest hassle is getting the built binary into a disk
image to test it. With Virtual ][ its easy as noted above. CiderPress
would be the way to do it by hand under Windows, but a2tools might work
better in a makefile to automate the whole procedure.
Dave...
a2retro
Which host platform are you running the cc65 tool suite on and where
will you run the target binary - emulator or real hardware?
Glenn
--- Synchronet 3.14a-Win32 NewsLink 1.85
A2Central.com - Your total source for Apple II computing.
regi...@retronym.de
> will you run the target binary - emulator or real hardware?
>
> Glenn
> --- Synchronet 3.14a-Win32 NewsLink 1.85
> A2Central.com - Your total source for Apple II computing.
My host platform is Win32 (in the moment, Linux or Mac OS X are
possible alternatives ). I want to run it in the AppleWin emulator and
later on a real Apple //e enhanced.
--Dietmar
a2retro
If we update your example like this (one way to do it) and call it hello.s
-------------------------------
.import __STARTUP_LOAD__, __BSS_LOAD__ ; Linker generated
.segment "EXEHDR"
.addr __STARTUP_LOAD__ ; Start address
.word __BSS_LOAD__ - __STARTUP_LOAD__ ; Size
.segment "RODATA"
MSG: .ASCIIZ "Hello, world!"
.segment "STARTUP"
LDX #0
LDA MSG,X ; load initial char
@LP: JSR $FDED ; cout
INX
LDA MSG,X
BNE @LP
RTS
------------------------------------
issue
ca65 -t apple2 hello.s
then
ld65 -t apple2 -o hello hello.o
you will have a binary hello that has the load address and length of the
binary as a file header.
Since your on Windows, get your self a copy of Ciderpress -
http://ciderpress.sourceforge.net/index.htm - and add the binary to an
existing DSK image or create a new one.
You can use ADTPro - http://adtpro.sourceforge.net/ - to transfer the
DSK image to a real apple when you are ready.
regi...@retronym.de
wrote:
> To: register
>
>
>
> register wrote:
> > There is a nice cc65 C-Compiler HelloWorld example for the Apple II
> existing DSK image or create a new one.
>
> DSK image to a real apple when you are ready.
>
> Glenn
> --- Synchronet 3.14a-Win32 NewsLink 1.85
> A2Central.com - Your total source for Apple II computing.
Thank you for the contribution.
I've changed and simplified my program (showa.s) to:
.import __STARTUP_LOAD__, __BSS_LOAD__ ; Linker generated
.segment "EXEHDR"
.addr __STARTUP_LOAD__ ; Start address
.word __BSS_LOAD__ - __STARTUP_LOAD__ ; Size
.segment "STARTUP"
LDA #$C1 ; load A char
JSR $FDED ; cout
RTS
And assembled it with:
ca65 -t apple2 showa.s
And linked it with:
ld65 -t apple2 -o showa.bin showa.o
And transferred it with a2tools in the raw mode:
a2tools in -r b CC65.DSK SHOWA showa.bin
Now I can run it in AppleWin with BRUN SHOWA.
It shows an A (hurrah!), but the program stucks and does not return to
DOS.
The file inspected with ciderpress:
0800- A9 C1 LDA #$C1
0802- 20 ED FD JSR $FDED F8ROM:COUT
0805- 60 RTS
If I transfer it with a2tools in the normal/non raw mode:
a2tools in b CC65.DSK SHOWA showa.bin
BRUN SHOWA does not work. It ends in the Monitor.
The file has now a 4 byte header (again with ciderpress):
2000- 00 BRK
2001- 08 PHP
2002- 06 00 ASL $00
2004- A9 C1 LDA #$C1
2006- 20 ED FD JSR $FDED F8ROM:COUT
2009- 60 RTS
Is it now a problem with the transfer? Transfering with ciderpress
does not help either. I get the monitor and the following content:
0000- 00 BRK
0001- 08 PHP
0002- 06 00 ASL $00
0004- A9 C1 LDA #$C1
0006- 20 ED FD JSR $FDED F8ROM:COUT
0009- 60 RTS
--Dietmar
a2retro
I played around with Ciderpress and found these steps will work.
link your program without the bin extension.
Add the file to a disk image with Ciderpress
it will add it as a file with a F2 file type.
Edit the file attributes and change it to bin then click okay (do not
change the aux type). You will get a dialog box that wants you confirm
the change, accept it.
You will notice the aux type has changed now to the programs start
address. This file can now be bloaded and run with a call 2048 or brun
from the prompt
Modified source
import __STARTUP_LOAD__, __BSS_LOAD__ ; Linker generated
.segment "EXEHDR"
.addr __STARTUP_LOAD__ ; Start address
.word __BSS_LOAD__ - __STARTUP_LOAD__ ; Size
.segment "RODATA"
MSG: .ASCIIZ "Hello, world!"
.segment "STARTUP"
LDA #$8D ; next line
JSR $FDED
LDX #0
LDA MSG,X ; load initial char
@LP: ORA #$80
JSR $FDED ; cout
INX
LDA MSG,X
BNE @LP
LDA #$8D ; next line
JSR $FDED
JMP $03D0 ; warm start
regi...@retronym.de
difference:
.import __STARTUP_LOAD__, __BSS_LOAD__ ; Linker generated
.segment "EXEHDR"
.addr __STARTUP_LOAD__ ; Start address
.word __BSS_LOAD__ - __STARTUP_LOAD__ ; Size
.segment "STARTUP"
LDA #$C1 ; load A char
JSR $FDED ; cout
JMP $03D0 ; warm start
Assembled it with:
ca65 -t apple2 showa.s
Link it with:
ld65 -t apple2 -o showa showa.o
Transfer it with a2tools:
a2tools in -r b CC65.DSK SHOWA showa
Now run it in AppleWin with BRUN SHOWA.
It shows an A (hurrah!), and return to
DOS.
Thanks again
--Dietmar
Oliver Schmidt
On Sun, 27 Jan 2008 22:12:24 GMT, David Schmenk
<dsch...@YUCH.gmail.com> wrote:
>CC65 will create an additional memory segment for the apple2 that gets
>linked at the beginning of the binary which contains the start address
>and size. From what I can tell, cc65 is really set up for ProDOS, but
>has some very basic DOS 3.3 support. I think the file io library is
>pretty much ProDOS only.
The binary created with the default linker configuration file is a DOS
3.3 file with 4-byte header. So from that perspective cc65 is closer
to DOS 3.3.
The file I/O library supports ProDOS 8 only. The same is true for
interrupt handling. Everything else is supposed to work equally well
under DOS 3.3 and ProDOS 8.
There are two reasons why I opted for the DOS 3.3 output file although
the cc65 C-library supports ProDOS 8 better:
1. ProDOS 8 simply has no way to embed the start address into the
file.
2. Tools for injecting files into a disk image tend to support DOS 3.3
rather/better than ProDOS 8.
>> One simple way using standard tools is to create the object file on
>> a ProDOS image, then use Copy II Plus to copy the file to a DOS 3.3
>> binary file--that will automatically do the job.
>>
>This is the approach I use. Foolproof and easy. Especially since
>Virtual ][ will mount a directory as a ProDOS volume.
Given the fact that the linker generates a DOS 3.3 in the first place
it seems to me the opposite of easy to go through ProDOS 8 to put the
file onto a DOS 3.3 disk (image)...
Best, Oliver
David Schmenk
> Hi,
>
> On Sun, 27 Jan 2008 22:12:24 GMT, David Schmenk
> <dsch...@YUCH.gmail.com> wrote:
>
>> CC65 will create an additional memory segment for the apple2 that gets
>> linked at the beginning of the binary which contains the start address
>> and size. From what I can tell, cc65 is really set up for ProDOS, but
>> has some very basic DOS 3.3 support. I think the file io library is
>> pretty much ProDOS only.
>
> The binary created with the default linker configuration file is a DOS
> 3.3 file with 4-byte header. So from that perspective cc65 is closer
> to DOS 3.3.
>
> The file I/O library supports ProDOS 8 only. The same is true for
> interrupt handling. Everything else is supposed to work equally well
> under DOS 3.3 and ProDOS 8.
>
> There are two reasons why I opted for the DOS 3.3 output file although
> the cc65 C-library supports ProDOS 8 better:
>
> 1. ProDOS 8 simply has no way to embed the start address into the
> file.
>
> 2. Tools for injecting files into a disk image tend to support DOS 3.3
> rather/better than ProDOS 8.
>
OK. I guess I'm still unclear as to what the build target is. Are you
supposed to copy the binary from a DOS image to a ProDOS image?
>>> One simple way using standard tools is to create the object file on
>>> a ProDOS image, then use Copy II Plus to copy the file to a DOS 3.3
>>> binary file--that will automatically do the job.
>>>
>> This is the approach I use. Foolproof and easy. Especially since
>> Virtual ][ will mount a directory as a ProDOS volume.
>
> Given the fact that the linker generates a DOS 3.3 in the first place
> it seems to me the opposite of easy to go through ProDOS 8 to put the
> file onto a DOS 3.3 disk (image)...
>
> Best, Oliver
Personally, I see no benefit to using the built-in apple2 configuration
when writing an assembly language program using the ca65. That is why I
posted my configuration file I used. But, whatever works for the
situation. Again, I've been spoiled by Virtual ]['s directory mounting.
Once I BSAVE a binary with the proper address, Virtual ][ will retain
the AUX bytes (containing the start address) for that file until it is
deleted.
Dave...
a2retro
ol.sc wrote:
> Hi,
>
> On Sun, 27 Jan 2008 22:12:24 GMT, David Schmenk
> <dsch...@YUCH.gmail.com> wrote:
>
>> CC65 will create an additional memory segment for the apple2 that gets
>> linked at the beginning of the binary which contains the start address
>> and size. From what I can tell, cc65 is really set up for ProDOS, but
>> has some very basic DOS 3.3 support. I think the file io library is
>> pretty much ProDOS only.
>
> The binary created with the default linker configuration file is a DOS
> 3.3 file with 4-byte header. So from that perspective cc65 is closer
> to DOS 3.3.
That is correct for a 'C' program as it has crt0.s to setup the start
address and length of the generated binary ... correct?
One needs to do something similar for just straight assembler .. at
least that is what I found ....
Glenn
<snip>
Oliver Schmidt
>> The binary created with the default linker configuration file is a DOS
>> 3.3 file with 4-byte header. So from that perspective cc65 is closer
>> to DOS 3.3.
>
>That is correct for a 'C' program as it has crt0.s to setup the start
>address and length of the generated binary ... correct?
>
>One needs to do something similar for just straight assembler .. at
>least that is what I found ....
Yes, that's exactly true - as you already described in this thread.
Sorry if my statements above caused confusion.
Best, Oliver
Oliver Schmidt
>> There are two reasons why I opted for the DOS 3.3 output file although
>> the cc65 C-library supports ProDOS 8 better:
>>
>> [...]
>
>OK. I guess I'm still unclear as to what the build target is. Are you
>supposed to copy the binary from a DOS image to a ProDOS image?
That's exactly the process I had in mind - and that I'm following
myself:
- Inject the binary into a DOS 3.3 image
- Use an emulator to copy the DOS 3.3 file to a ProDOS 8 file.
That way one never has to deal with start addresses.
>Personally, I see no benefit to using the built-in apple2 configuration
>when writing an assembly language program using the ca65. That is why I
>posted my configuration file I used.
Sorry for causing confusion. You're exactly right.
I was just that the thread kind of drifted towards general statements
about cc65 - and there I wanted to clarify.
Best, Oliver
David Schmenk
Thanks for the clarification. Did you ever consider doing separate
memory configurations for DOS and ProDOS? I initially wondered why
cc65 didn't build a .SYSTEM file. It always loads at $2000, so the
start address wouldn't be an issue. Stack or file buffers could be
allocated between $C00 and $2000. Just curious.
Thanks,
Dave...
Oliver Schmidt
<dsch...@YUCH.gmail.com> wrote:
>Did you ever consider doing separate
>memory configurations for DOS and ProDOS? I initially wondered why
>cc65 didn't build a .SYSTEM file. It always loads at $2000, so the
>start address wouldn't be an issue. Stack or file buffers could be
>allocated between $C00 and $2000. Just curious.
I surely considered that. In my opinion the $2000 for SYS files was
choosen because it is the hires buffer. That means this is the
location where a graphics program for sure doesn't want to load code
to. So it's the best place for bootstrap code that loads the actual
code - and get's overwritten on initalizing the hires buffer. This led
me to the conclusion that SYS files are supposed to be bootstraps, at
least for large programs - and cc65 C programs tend to become large.
Another thought is about the cc65 memory layout that starts with code,
followed by readonly data and initialized data (which all get's loaded
from disk) and then zeroed data (which get's programatically
initialized). After those statically defined things there comes the
dynamically located things like the heap and the software stack. So
most cc65 C-programs should have the code starting at $800 to have as
much memory available as possible. One option would be have a SYS file
relocating itself from $2000 to $800 but if it is large - and cc65 C
programs tend to become large - than this takes quite some time. It is
simply much faster to have a small bootstrap code loading the actual
code straight to the final location.
The result from these thoughts is to have the cc65 linker generate a
single BIN file that serves several scenarios eaqually well:
- Loaded from DOS 3.3 BASIC prompt
- Loaded from ProDOS 8 BASIC.SYSTEM
- Loaded by bootstrap SYS file
In fact I implemented such a bootstrap SYS file. Its primary features
are:
- Smaller than 512 byte (seedling file)
- Relocates itself to $300
- Maps ProDOS 8 startup file to main(argv[1])
- Modifies ProDOS 8 memory map and sets himem
- Maps DOS 3.3 quit ($3D0/$3D3) to ProDOS 8 quit
Check out this page for info how to get it:
http://www.cc65.org/doc/apple2-2.html
Best, Oliver
David Schmenk
Again, thanks for the great info.
Dave...
Sir Fart A Lot
even finding the source and the copy I did managed to locate does not
accept the options your using, makes me wonder if I am running the
newest verison.
Oliver Schmidt
The cc65 docs contain a page that describes the necessary steps and
that contains a link to a2tools which works for me:
http://www.cc65.org/snapshot-doc/intro-6.html
Best, Oliver
michael....@gmail.com
- - - 8< barebones.s - - -
COUT = $FDED
.macro ASC text
.repeat .strlen(text), I
.byte .strat(text, I) | $80
.endrep
.endmacro
__MAIN = $1000 ; Apple DOS 3.3 binary file 4 byte prefix header
.word __MAIN ; 2 byte BLAOD address
.word __END - __MAIN ; 2 byte BLOAD size
.org __MAIN ; .org must come after header else offsets are wrong
LDA MSG,X ; load initial char
INX
LDA MSG,X
BNE PRINTCHAR
RTS
MSG:
ASC "Hello world, Apple!"
.byte $00
__END:
- - - 8< barebones.s - - -
You'll need a linker script that doesn't include all the C library cruft, and makes all RAM available.
- - - 8< apple2linkbin.cfg - - -
MEMORY {
RAM: start = $0, size = $10000, file = %O;
}
SEGMENTS {
CODE: load = RAM, type = rw;
BSS: load = RAM, type = rw;
}
ca65 --cpu 65c02 -o barebones.o barebones.s
ld65 -C apple2linkbin.cfg -o barebones.bin barebones.o
Then use a2tools to copy onto a .DSK image in "raw" format:
a2rm barebones.DSK BAREBONES
a2in -r b barebones.DSK BAREBONES barebones.bin
You can simple this by moving this boiler plate to a file called: dos33.h
- - - 8< dos33.h - - -
.word __MAIN ; 2 byte BLAOD address
.word __END - __MAIN ; 2 byte BLOAD size
.org __MAIN ; .org must come after header else offsets are wrong
- - - 8< dos33.h - - -
Then your main program is simplified:
__MAIN = $1000
.include "dos33.h" ; Apple DOS 3.3 binary file 4 byte prefix header
More details and files at my fork of the repo:
https://github.com/Michaelangel007/cc65
P.S.
Someone *really* needs to update that ancient cc65 docs with a *working* link to AppleWin
http://www.cc65.org/snapshot-doc/intro-6.html
Remove: Available at http://applewin.berlios.de/:
Replace: Available at https://github.com/AppleWin/AppleWin
Oliver Schmidt
>You'll need a linker script that doesn't include all the C library cruft, and makes all RAM available.
>ca65 --cpu 65c02 -o barebones.o barebones.s
>ld65 -C apple2linkbin.cfg -o barebones.bin barebones.o
cl65 -t apple2enh -C apple2enh-asm.cfg -u __EXEHDR__ barebones.s
>Someone *really* needs to update that ancient cc65 docs with a *working* link to AppleWin
>http://www.cc65.org/snapshot-doc/intro-6.html
>
>Remove: Available at http://applewin.berlios.de/:
>Replace: Available at https://github.com/AppleWin/AppleWin
Regards,
Oliver