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

7 posts / 0 new
Last post
Offline
Last seen: 8 years 3 months ago
Joined: Jul 16 2006 - 17:30
Posts: 81
Developing & emulating using CC65 -> AppleCommander -> AppleWin fails

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?

Offline
Last seen: 9 years 1 month ago
Joined: Apr 10 2006 - 20:01
Posts: 1013
I haven't tried the hello sam

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

Offline
Last seen: 8 years 3 months ago
Joined: Jul 16 2006 - 17:30
Posts: 81
Thanks, I realized that it w

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?

Offline
Last seen: 8 years 3 months ago
Joined: Jul 16 2006 - 17:30
Posts: 81
a2tools works better!

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

Offline
Last seen: 9 years 1 month ago
Joined: Apr 10 2006 - 20:01
Posts: 1013
Yes, the way you're invoking

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.

Offline
Last seen: 8 years 3 months ago
Joined: Jul 16 2006 - 17:30
Posts: 81
I'm confused. Do you mean

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.

Offline
Last seen: 9 years 1 month ago
Joined: Apr 10 2006 - 20:01
Posts: 1013
It depends on what you're usi

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. Smile

Log in or register to post comments