cc65: ca65 + ld65 without all the library crap for "pure" assembly programs

[michael....@gmail.com]

aka: "ca65 for stand-alone Apple assembly projects"

Since all the cool kids are using cross-assemblers these days I figured I would get with the times and stop hand-assembling everything. (Hey it was good enough for Woz and Integer Basic! :)

I've put together a demo and bash shell script to automate these steps:
https://github.com/Michaelangel007/cc65/tree/master/apple2

What src2dsk.sh does:

* assemble a barebones.s file, producing barebones.o
* link it, producing barebones.bin
* use a2tools to copy it onto a DOS 3.3 disk, called BAREBONES

This lets you use cc65 without all the C library crap! Here are the steps involved that others might find interesting:

1. I used a dead simple linker script called: apple2bin.cfg

- - - 8< - - -
MEMORY {
RAM: start = $1000, size = $8E00, file = %O;
}
SEGMENTS {
CODE: load = RAM, type = ro;
DATA: load = RAM, type = rw;
BSS: load = RAM, type = rw;
}
- - - 8< - - -

2. Since we're not using any of the cc65 libraries, ld65 won't generate the 4-byte header for us. We need to do this manually, but this is trivial. Stick this at the top of your .s file to generate the 4-byte header for DOS 3.3

- - - 8< - - -
; 4 byte header for DOS 3.3 files
.word $1000 ; define 2 bytes, must match org
.word __END__ - * ; define 2 bytes, total size in bytes

.org $1000 ; .org must come after header else offsets are wrong

... your code ...

__END__:
- - - 8< - - -

3. Runs the assembler with:

ca65 --cpu 65c02 -o foo.o foo.s

4. Runs the linker with:

ld65 -C apple2bin.cfg -o foo.bin foo.o

5. We can verify the binary is truely barbones!

hexdump -C barebones.bin

00000000 00 10 1d 00 a2 00 bd 11 10 09 80 20 ed fd e8 bd |........... ....|
00000010 11 10 d0 f5 60 48 65 6c 6c 6f 2c 20 77 6f 72 6c |....`Hello, worl|
00000020 64 21 00 |d!.|
00000023


6. I used a2tools to copy the foo.bin onto foo.dsk with the filename FOO. I used awk to capitalize the filename, a2rm to delete the old binary off the .DSK, and a2in to "instal"" the new binary onto the .DKS.

A2FILE=`echo "${1}" | awk '{print toupper($0)}'`
a2rm ${1}.DSK ${A2FILE}
a2in -r b ${1}.DSK ${A2FILE} ${BIN}

7. You'll need to mount the (updated) disk in your favorite emulator but you're good to go !

I ran into one cc65 bug with version ca65 V2.15. Apparently the macro to is broken when setting the high bit -- it doesn't update the last 4 bytes of the string. I wasted enough time automating the whole assemble+link+copy that I didn't feel like tracking down what was broken with ca65.

Anyways, all the stuff is in my repo:

* apple2bin.cfg
* barebones.dsk
* barebones.s
* src2dsk.sh

https://github.com/Michaelangel007/cc65/tree/master/apple2

Enjoy!

Michael

[michael....@gmail.com]

Aaand I've already run into the dreaded linker "Range error" ...

; The operator '*' is buggy. This will generate a bogusBogus link error:
; ld65: Error: Range error in module `link_bug.s', line 3

__MAIN = $1000 ; Apple DOS 3.3 binary file 4 byte prefix header
.word __MAIN ; 2 byte BLOAD address
.word __END - * ; 2 byte BLOAD size
.org __MAIN ; .org must come after header else offsets are wrong
RTS
__END:


*sigh*

Here is how to fix it:

; Solution 1 is to a pad dummy byte onto the end
; __END:
; .asciiz ""
; Solution 2 is to not use the buggy '*' operator
; .word __END - __MAIN

__MAIN = $1000 ; Apple DOS 3.3 binary file 4 byte prefix header
.word __MAIN ; 2 byte BLOAD address
.word __END - * ; 2 byte BLOAD size
.org __MAIN ; .org must come after header else offsets are wrong
RTS
__END:

"Good news everyone!"

With the buggy '*' operator work-around we can finally use a macro to set the high bit on Apple text.

.macro ASC text
.repeat .strlen(text), I
.byte .strat(text, I) | $80
.endrep
.endmacro

i.e.

MSG:
ASC "Hello world, Apple!"
.byte $00

I've updated barebones.s documenting the bugs and work-arounds:
https://github.com/Michaelangel007/cc65/blob/master/apple2/barebones.s

[michael....@gmail.com]

Since cc65 is completely useless out-of-the-box for controlling text with the high-bit on / off, here are some macros to do this:

- - - 8< apple2text.inc - - -
; Force APPLE 'text' to have high bit on
.macro AS text

.repeat .strlen(text), I
.byte .strat(text, I) | $80
.endrep
.endmacro

; Force ASCII 'text' but last character has high bit on
; Will display as FLASHING characters
; NOTE: There is no lowercase flashinng characters - they will appar as gibbersh!
.macro AT text
.repeat .strlen(text)-1, I
.byte .strat(text, I) & $7F
.endrep
.byte .strat(text, .strlen(text)-1) | $80
.endmacro

; Force APPLE 'text' with high bit on but last character has high bit off
.macro AR text
.repeat .strlen(text)-1, I

.byte .strat(text, I) | $80
.endrep

.byte .strat(text, .strlen(text)-1) & $7F
.endmacro

; Force ASCII 'text' to be control chars: $00..$1F
; Will display as INVERSE characters
.macro AC text
.repeat .strlen(text), I
.byte .strat(text, I) & $1F
.endrep
.endmacro

- - - 8< - - -

Examples:

.include "apple2text.inc"

Foo:
AR "ABC" ; NORMAL : APPLE high-bit text, last char is ASCII (FLASHING)
AS "Hello world" ; NORMAL : APPLE high-bit text
AT "XYZ" ; FLASH : ASCII text, last char is APPLE high-bit (NORMAL)
AC "DEFM" ; INVERSE: Force to be control chars0 $0..$1F (INVERSE)

[Oliver Schmidt]

>2. Since we're not using any of the cc65 libraries, ld65 won't generate th=
>e 4-byte header for us.

Wrong. Using the linker script already coming with cc65 explicitly
targeting assemly language-only programs with using the - what you
like to call library "crap" - it simply means replacing

cl65 -t apple2enh -C apple2enh-asm.cfg myfiles.s

with

cl65 -t apple2enh -C appel2enh-asm.cfg -u __EXEHDR__ myfile.s

and the result is a binary with a DOS 3.3 header plus the generated
code - and nothing else.

I suggest that you first understand things before complaining about
things in the public !

PS: I's like to see your reaction on some nice posting of mine here on
the AppleWin debugger "crap" bloating the actual emulation core...

[michael....@gmail.com]

On Tuesday, January 19, 2016 at 11:36:13 AM UTC-8, Oliver Schmidt wrote:
> PS: I's like to see your reaction on some nice posting of mine here on
> the AppleWin debugger "crap" bloating the actual emulation core...

Wait, when did we switch over to comp.emulators.apple2.advocacy? I must have missed that memo. :-)

You made 3 mistakes:

1. You're under the delusion that my ego would be bruised. You won't get any argument from me! AppleWin's debugger (still) sucks, hopefully, just less over time.
2. I didn't even write the original code, and
3. Let's compare screenshots of how *horrible* it was before I got involved:

http://imgur.com/a/qEKOW

Ow my eyes!

Lastly, you haven't seen my "65d02" ideas providing a real-time heat map, inline sprite display, and other fun stuff. I'm quite well aware that debugging is a performance hog. One day users will be able to disable all the *debugger crap* for those that _don't_ need it, and the few that _do_ can enable it.

So go ahead and post your feedback & criticism (over in c.e.a2) It's the fastest way to help improve it. :-)

Michael

[michael....@gmail.com]

On Tuesday, January 19, 2016 at 10:54:09 PM UTC-8, michael....@gmail.com wrote:

> So go ahead and post your feedback & criticism (over in c.e.a2) It's the fastest way to help improve it. :-)

New thread for those interested, so we don't clog up this newsgroup:

"AppleWin's Debugger is still crap ... how do we fix it?"
* https://groups.google.com/forum/#!topic/comp.emulators.apple2/bNLbqDX5_KM