Home » forums » Discussion » Apple II

Developing & emulating using CC65 -> AppleCommander -> AppleWin fails

Submitted by jaksel on April 4, 2008 - 10:54pm. Apple II

I tried installing CC65 (compiler), Apple Commander (disk image tool), and AppleWin (emulator). I went ahead and built the "tgidemo" and "hello" samples included in the CC65 package, then used Apple Commander to put the *.o-files into a disk image, which I then loaded in AppleWin. But the emulated Apple IIe crashes, with this message:
0803- A=01 X=60 Y=00 P=75 S=F8

I am guessing the problem is within the binary object file I put into the disk image, but I'm not sure what. Any help please?

» login or register to post comments | previous forum topic | next forum topic

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
david__schmidt's picture

I haven't tried the hello sam

Submitted by david__schmidt on April 5, 2008 - 1:38am.

I haven't tried the hello sample they supply. But you can't run a .o file directly - it needs to get linked. You should have an ld65 step in there somewhere...?

Head over to comp.sys.apple2.programmer and a google on 'ca65 hello':
http://groups.google.com/group/comp.sys.apple2.programmer/search?group=comp.sys.apple2.programmer&q=ca65+hello&qt_g=Search+this+group

»
login or register to post comments

Thanks, I realized that it w

Submitted by jaksel on April 5, 2008 - 9:07am.

Thanks,
I realized that it was incorrect to add the object file. I hadn't seen the binary oputput file from the linker. However it does not work with the binary file either! Sad
The binary (in the "hello" example) is also quite large, 2663 bytes. Is that reasonable?

When importing the file into a disk image, it is possible to change the file type and address. Is it correct to use type B and address 0?

»
login or register to post comments

a2tools works better!

Submitted by jaksel on April 5, 2008 - 5:11pm.

I tried using a2tools instead, when creating the disk image, and that works much better!

I looked at the disk image and realized that the difference between using Apple Commander and a2tools is that the binary file (i.e. my program) is 4 bytes LARGER on disk when using Apple Commander!

I suspect this is the DOS header that's added to the binary. But how can that mess up the emulator? I mean, there SHOULD be a DOS header in the binary, right?

The first 8 bytes of the binary is, when using Apple Commander:
00 08 3F 0A A2 FF 9A 20

and when using a2tools:
A2 FF 9A 20 43 08 A2 1E

»
login or register to post comments
david__schmidt's picture

Yes, the way you're invoking

Submitted by david__schmidt on April 5, 2008 - 5:38pm.

Yes, the way you're invoking AC is having it consume the header, rather than put in on disk. The first 2 bytes is the starting address ($0800). I can't remember what the next 2 bytes is for. The way I invoke AC:
AC -p HELLO bin 2048 MY.DSK
That'll put the binary file HELLO on MY.DSK, with a header to load it at $0800.

»
login or register to post comments

I'm confused. Do you mean

Submitted by jaksel on April 5, 2008 - 5:55pm.

I'm confused.

Do you mean the proper way of using AC is to NOT include the DOS header in the image file? As I said, when I use AC I do get a DOS header, and THAT is what seem to mess up the emulator.

When I use a2tools, there is no header. That disk image works perfectly.

BTW the second 2 bytes is the length of the file.

»
login or register to post comments
david__schmidt's picture

It depends on what you're usi

Submitted by david__schmidt on April 5, 2008 - 8:57pm.

It depends on what you're using to decide if the header is there or not. CiderPress will use the header to interpret what's going on. If you see the header, CiderPress has decided it isn't a BLOADable file, and it's showing you the first 4 bytes.

Just goof with code-generation options until it produces what you expect. :-)

»
login or register to post comments