apple2.cfg)
apple2-system.cfg
apple2-hgr.cfg
apple2-overlay.cfg
apple2-asm.cfg
This file contains an overview of the Apple ][ runtime system as it comes with the cc65 C compiler. It describes the memory layout, Apple ][ specific header files, available drivers, and any pitfalls specific to that platform.
Please note that Apple ][ specific functions are just mentioned here, they are described in detail in the separate function reference. Even functions marked as "platform dependent" may be available on more than one platform. Please see the function reference for more information.
The standard binary file format generated by the linker for the Apple ][ target is an AppleSingle file. The default load address is $803.
AppleCommander 1.4.0 or later (available at
https://applecommander.github.io/) includes the option -as that
allows to put AppleSingle files onto disk images containing DOS 3.3 as well
as ProDOS 8.
In the standard setup, cc65 generated programs use the memory from $803 to $95FF, so 35.5 KB of RAM are available.
Special locations:
The C runtime stack is located at HIMEM and grows downwards, regardless of how your linker config file is setup.
The C heap is located at the end of the program and grows towards the C runtime stack.
While running main() the Language Card bank 2 is enabled for read access.
However while running module constructors the Language Card is disabled.
Enabling the Language Card allows to use it as additional memory for cc65
generated code. However code is never automatically placed there. Rather code
needs to be explicitly placed in the Language Card either per file by compiling
with --code-name LC or per function by enclosing in #pragma code-name
(push, "LC") and #pragma code-name (pop). In either case the cc65 runtime
system takes care of actually moving the code into the Language Card.
The amount of memory available in the Language Card for generated code depends on the linker configuration parameters. There are several useful settings:
For plain vanilla ProDOS 8 which doesn't actually use the Language Card bank 2 memory from $D400 to $DFFF. This is the default setting.
For ProDOS 8 together with the function rebootafterexit(). If a program
doesn't quit to the ProDOS 8 dispatcher but rather reboots the machine after
exit then a plain vanilla ProDOS 8 doesn't make use of the Language Card bank
2 at all.
For plain vanilla DOS 3.3 which doesn't make use of the Language Card at all.
The ld65 linker comes with a default config file for the Apple ][,
which is used via -t apple2.
The apple2 package comes with additional secondary linker config files, which
are used via -t apple2 -C <configfile>.
apple2.cfg)
Default configuration for a binary program.
Parameters:
STARTADDRESS: Program start addressDefault: $803. Use -S <addr> to set a different start address.
__EXEHDR__: AppleSingle executable file headerDefault: Yes. Use -D __EXEHDR__=0 to omit the AppleSingle header.
__STACKSIZE__: C runtime stack sizeDefault: $800. Use -D __STACKSIZE__=<size> to set a different
stack size.
__HIMEM__: Highest usable memory address presumed at link timeDefault: $9600. Use -D __HIMEM__=<addr> to set a different
highest usable address.
__LCADDR__: Address of code in the Language CardDefault: $D400. Use -D __LCADDR__=<addr> to set a different
code address.
__LCSIZE__: Size of code in the Language CardDefault: $C00. Use -D __LCSIZE__=<size> to set a different
code size.
apple2-system.cfg
Configuration for a system program running on ProDOS 8 and using the memory from $2000 to $BEFF.
Parameters:
__EXEHDR__: AppleSingle executable file headerDefault: Yes. Use -D __EXEHDR__=0 to omit the AppleSingle header.
__STACKSIZE__: C runtime stack sizeDefault: $800. Use -D __STACKSIZE__=<size> to set a different
stack size.
__LCADDR__: Address of code in the Language CardDefault: $D400. Use -D __LCADDR__=<addr> to set a different
code address.
__LCSIZE__: Size of code in the Language CardDefault: $C00. Use -D __LCSIZE__=<size> to set a different
code size.
apple2-hgr.cfg
Configuration for a program including a hires page. See testcode/lib/apple/hgrtest.c
for an example of such a program.
Parameters:
STARTADDRESS: Program start addressDefault: $803. Use -S <addr> to set a different start address.
__EXEHDR__: AppleSingle executable file headerDefault: Yes. Use -D __EXEHDR__=0 to omit the AppleSingle header.
__STACKSIZE__: C runtime stack sizeDefault: $800. Use -D __STACKSIZE__=<size> to set a different
stack size.
__HIMEM__: Highest usable memory address presumed at link timeDefault: $9600. Use -D __HIMEM__=<addr> to set a different
highest usable address.
__LCADDR__: Address of code in the Language CardDefault: $D400. Use -D __LCADDR__=<addr> to set a different
code address.
__LCSIZE__: Size of code in the Language CardDefault: $C00. Use -D __LCSIZE__=<size> to set a different
code size.
apple2-overlay.cfg
Configuration for an overlay program with up to nine overlays. The overlay files
don't include the AppleSingle header. See samples/overlaydemo.c for more
information on overlays.
Parameters:
STARTADDRESS: Program start addressDefault: $803. Use -S <addr> to set a different start address.
__EXEHDR__: AppleSingle executable file headerDefault: Yes. Use -D __EXEHDR__=0 to omit the AppleSingle header.
__STACKSIZE__: C runtime stack sizeDefault: $800. Use -D __STACKSIZE__=<size> to set a different
stack size.
__HIMEM__: Highest usable memory address presumed at link timeDefault: $9600. Use -D __HIMEM__=<addr> to set a different
highest usable address.
__LCADDR__: Address of code in the Language CardDefault: $D400. Use -D __LCADDR__=<addr> to set a different
code address.
__LCSIZE__: Size of code in the Language CardDefault: $C00. Use -D __LCSIZE__=<size> to set a different
code size.
__OVERLAYSIZE__: Size of code in the overlaysDefault: $1000. Use -D __OVERLAYSIZE__=<size> to set a different
code size.
apple2-asm.cfg
Configuration for an assembler program that doesn't need a special setup.
Parameters:
STARTADDRESS: Program start addressDefault: $803. Use -S <addr> to set a different start address.
__EXEHDR__: AppleSingle executable file headerDefault: No. Use -u __EXEHDR__ apple2.lib to add the AppleSingle header.
ProDOS 8 system programs are always loaded to the start address $2000. For cc65 programs this means that the 6 KB from $800 to $2000 are by default unused. There are however several options to make use of that memory range.
The easiest (and for really large programs in fact the only) way to have a cc65
program use the memory from $800 to $2000 is to link it as binary
(as opposed to system) program using the default linker configuration
apple2.cfg with __HIMEM__ set to $BF00
and load it with the LOADER.SYSTEM utility. The program then works like a system
program (i.e. quits to the ProDOS dispatcher).
Using LOADER.SYSTEM is as simple as copying it to the ProDOS 8 directory of the
program to load under name <program>.SYSTEM as a system program. For
example the program MYPROG is loaded by MYPROG.SYSTEM. The right
AppleCommander option to put LOADER.SYSTEM on a ProDOS 8 disk image is -p.
If the cc65 program can be successfully linked as system program using the linker
configuration
apple2-system.cfg, but
uses the heap either explicitly or implicitly (i.e. by loading a driver) then
the memory from $800 to $1FFF can be added to the heap by calling
_heapadd ((void *) 0x0800, 0x1800); at the beginning of main().
ProDOS 8 requires for every open file a page-aligned 1 KB I/O buffer. By default
these buffers are allocated by the cc65 runtime system on the heap using
posix_memalign(). While this is generally the best solution it means quite
some overhead for (especially rather small) cc65 programs which do open files
but don't make use of the heap otherwise.
The apple2 package comes with the alternative ProDOS 8 I/O buffer allocation
module apple2-iobuf-0800.o which uses the memory between $800 and
the program start address for the 1 KB I/O buffers. For system programs (with
start address $2000) this results in up to 6 I/O buffers and thus up to 6
concurrently open files.
While using _heapadd() as described in the section above together with the
default I/O buffer allocation basically yields the same placement of I/O buffers
in memory the primary benefit of apple2-iobuf-0800.o is a reduction in code
size - and thus program file size - of more than 1400 bytes.
Using apple2-iobuf-0800.o is as simple as placing it on the linker command
line like this:
cl65 -t apple2 -C apple2-system.cfg myprog.c apple2-iobuf-0800.o
Programs containing Apple ][ specific code may use the
apple2.h header file.
The functions and variables listed below are special for the Apple ][. See the function reference for declaration and usage.
In addition to those, the accelerator.h header file contains three functions
to help determine whether the program is running on a IIgs, and change the IIgs
CPU speed. See the
function reference for declaration and
usage.
There's currently no support for direct hardware access. This does not mean you cannot do it, it just means that there's no help.
The names in the parentheses denote the symbols to be used for static linking of the drivers.
a2.lo.tgi (a2_lo_tgi)This driver features a resolution of 40×48 with 16 colors.
The function tgi_apple2_mix() allows to activate 4 lines of text. The
function clears the corresponding area at the bottom of the screen.
a2.hi.tgi (a2_hi_tgi)This driver features a resolution of 280×192 with 8 colors and two
hires pages. Note that programs using this driver will have to be linked
with -S $4000 to reserve the first hires page or with -S $6000
to reserve both hires pages.
The function tgi_apple2_mix() allows to activate 4 lines of text. The
function doesn't clear the corresponding area at the bottom of the screen.
In memory constrained situations the memory from $803 to $1FFF
can be made available to a program by calling _heapadd ((void *) 0x0803, 0x17FD);
at the beginning of main(). Doing so is beneficial even if the program
doesn't use the heap explicitly because loading the driver (and in fact
already opening the driver file) uses the heap implicitly.
a2.auxmem.emd (a2_auxmem_emd)Gives access to 47.5 KB RAM (190 pages of 256 bytes each) on an Extended 80-Column Text Card.
Note that this driver doesn't check for the actual existence of the memory and that it doesn't check for ProDOS 8 RAM disk content!
a2.stdjoy.joy (a2_stdjoy_joy)Supports up to two standard analog joysticks connected to the game port of the Apple ][.
a2.stdmou.mou (a2_stdmou_mou)Driver for the AppleMouse II Card. Searches all Apple II slots for an AppleMouse II Card compatible firmware. The default bounding box is [0..279,0..191].
Programs using this driver will have to be linked with -S $4000
to reserve the first hires page if they are intended to run on an
Apple ][ (in contrast to an Apple //e) because the
AppleMouse II Card firmware writes to the hires page when initializing
on that machine.
Note that the Apple ][ default mouse callbacks support text mode only.
a2.ssc.ser (a2_ssc_ser)Driver for the Apple II Super Serial Card. The SSC is an extension card for the II, II+, IIe; the Apple //c and //c+ have the same hardware and firmware integrated. It supports up to 9600 baud, supports no flow control and hardware flow control (RTS/CTS) and does interrupt driven receives. Speeds faster than 9600 baud aren't reachable because the ROM and ProDOS IRQ handlers are too slow. Software flow control (XON/XOFF) is not supported.
Note that because of the peculiarities of the 6551 chip transmits are not interrupt driven, and the transceiver blocks if the receiver asserts flow control because of a full buffer.
Note that using the driver at SER_BAUD_115200 will disable IRQs. It will be up to the users to use the serial port, either by re-enabling IRQs themselves, or by directly poll-reading the ACIA DATA register without the help of ser_get().
The driver defaults to slot 2. Call ser_apple2_slot() prior to
ser_open() in order to select a different slot. ser_apple2_slot()
succeeds for all Apple II slots, but ser_open() fails with
SER_ERR_NO_DEVICE if there's no SSC firmware found in the selected slot.
In the Apple //c and //c+, slot 1 is the printer port, and slot 2 is the modem port.
Never call ser_apple2_slot() after ser_open().
a2.gs.ser (a2_gs_ser)Driver for the Apple IIgs serial ports (printer and modem). It supports up to 9600 baud, supports no flow control and hardware flow control (RTS/CTS) and does interrupt driven receives. Speeds faster than 9600 baud aren't reachable because the ROM and ProDOS IRQ handlers are too slow. Software flow control (XON/XOFF) is not supported. Note that transmits are not interrupt driven, and the transceiver blocks if the receiver asserts flow control because of a full buffer.
The driver defaults to opening the modem port. Calling ser_apple2_slot()
prior to ser_open() allows to select the printer port (1) or the modem
port (0).
Never call ser_apple2_slot() after ser_open().
Although the standard binaries generated by the linker for the Apple ][ generally run both on DOS 3.3 (with Applesoft BASIC) and on ProDOS 8 (with BASIC.SYSTEM) there are some limitations for DOS 3.3:
There's no disk file I/O support. Any attempt to use it yields an error with
errno set to ENOSYS. This implicitly means that loadable drivers
are in general not functional as they depend on disk file I/O. Therefore the statically
linked drivers have to be used instead.
There's no interruptor support. Any attempt to use it yields the message
'FAILED TO ALLOC INTERRUPT' on program startup. This implicitly means that
mouse and RS232 device drivers are not functional as they depend on interrupts.
The Apple ][ has no color text mode. Therefore the functions
textcolor(), bgcolor() and bordercolor() have no effect.
The random number seed is generated from the time the program waits for user input. Therefore it is necessary to wait for at least one user keypress either via Standard I/O or via Direct console I/O before initializing the pseudo random number generator.
There are several types of realtime clocks. It's not desirable to have specific code
for all of them. As ProDOS 8 supports file timestamps, realtime clock owners usually
use ProDOS 8 drivers for their realtime clock. Those drivers read the realtime clock
and write the result to the date/time location in RAM ($BF90 to $BF93).
ProDOS 8 reads the date/time from that RAM location. If there's no realtime clock the
RAM location keeps containing zeros. ProDOS 8 uses those zeros as timestamps and the
files show up in a directory as <NO DATE>.
There's no common interface to set realtime clocks so if a realtme clock IS present there's just nothing to do. However, if there's NO realtime clock present, the user might very well be interested to "manually" set the RAM location in order to have timestamps. But he surely doesn't want to manually set the RAM location over and over again. Rather he wants to set it just once after booting ProDOS 8.
From that perspective it makes most sense to not set both the date and the time but
rather only set the date and have the time just stay zero. Then files show up in a
directory as DD-MON-YY 0:00.
So clock_settime() checks if a realtime clock is active. If it is then
clock_settime() fails with ERANGE. Otherwise clock_settime()
sets the date - and completely ignores the time provided as parameter.
clock_getres() too checks if a realtime clock is active. If it is then
clock_getres() returns a time resolution of one minute. Otherwise
clock_getres() presumes that the only one who sets the RAM location is
clock_settime() and therefore returns a time resolution of one day.
Command line arguments can be passed to main() after BLOAD. Since this is not
supported by BASIC, the following syntax was chosen:
]CALL2051:REM ARG1 " ARG2 IS QUOTED" ARG3 "" ARG5
main is the program name.The runtime for the Apple ][ uses routines marked as
.INTERRUPTOR for ProDOS 8 interrupt handlers. Such routines must be
written as simple machine language subroutines and will be called
automatically by the interrupt handler code when they are linked into a
program. See the discussion of the .CONDES feature in the
assembler manual.
The readdir and stat function return ProDOS timestamps in their file creation/modification time attributes. You can convert them to more portable time representations using either:
struct tm* __fastcall__ gmtime_dt (const struct datetime* dt);
Converts a struct datetime into a struct tm. Returns NULL in case
of error and sets errno.
time_t __fastcall__ mktime_dt (const struct datetime* dt);
Parses a struct datetime and returns a UNIX timestamp. Returns 0 on error and
sets errno.
The function
dio_open() has the single
parameter device to identify the device to be opened. Therefore an
Apple II slot and drive pair is mapped to that device according
to the formula
device = slot + (drive - 1) * 8
so that for example slot 6 drive 2 is mapped to device 14.
The function
dio_query_sectcount() returns
the correct sector count for all ProDOS 8 disks. However for any non-ProDOS 8
disk it simply always returns 280 (which is only correct for a 140 KB disk).
This condition is indicated by the _oserror value 82.
ProDOS 8 associates a file type and an auxiliary type with each file.
These type specifications are separate from the file's name, unlike
Windows which uses the file name's suffix (a.k.a.
extension) to specify the file type. For example, .exe,
.doc, or .bat.
The ProDOS 8 Machine-Language Interface (MLI) function for creating a
file require these types to be specified.
In contrast, the ISO C function fopen() and the POSIX function
open() have no parameter to specify either a file type or an
auxiliary type. Therefore, some additional mechanism for specifying
the file types is needed.
There are two global variables provided that allow the file type
and auxiliary type to be specified before a call to fopen()
or open(). They are defined in apple2_filetype.h:
extern unsigned char _filetype; /* Default: PRODOS_T_BIN */
extern unsigned int _auxtype; /* Default: 0 */
The header file apple2_filetype.h also defines many values
that can be used to set these variables. It is included in
apple2.h.
The global variable _datetime allows the file creation date/time
to be set before a call to fopen()
or open() that creates the file. It is defined in apple2.h:
extern struct datetime _datetime;
A text file cannot be created with just the
standard C functions because they default to the binary type
PRODOS_T_BIN. The _filetype variable must be set to
PRODOS_T_TXT to create a text file.
For a text file,
_auxtype specifies the record length. A zero record
length text file is referred to as a sequential text file.
This is equivalent to text files on
other operating systems, except that the line terminator is a
carriage return instead of a line-feed (Linux/BSD/MacOS) or
carriage return, line-feed pair (Windows).
The 'sequential' text file terminology is in contrast to a 'random-access' text file which would have a fixed-length, non-zero record length, so that the file position of any individual record can be calculated.
For this example, the
_auxtype does not need to be set because it defaults to
the desired value, which is zero. To be more explicit,
_auxtype can also be set to PRODOS_AUX_T_TXT_SEQ
which is defined as zero.
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <apple2.h>
void main(void)
{
FILE *out;
char *name = "MY.FAVS";
/*-----------------------------*/
_filetype = PRODOS_T_TXT;
_auxtype = PRODOS_AUX_T_TXT_SEQ;
/*-----------------------------*/
if ((out = fopen(name, "w")) != NULL) {
fputs("Jorah Mormont\r", out);
fputs("Brienne of Tarth\r", out);
fputs("Daenerys Targaryen\r", out);
fputs("Sandor Clegane\r", out);
if (fclose(out) == EOF) {
fprintf(stderr, "fclose failed for %s: %s", name, strerror(errno));
}
}
else {
fprintf(stderr, "fopen failed for %s: %s", name, strerror(errno));
}
}
This software is provided 'as-is', without any expressed or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: