💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › Z80.CPM › A2.CPM.files › apbd… captured on 2023-03-20 at 23:39:52.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Customizing BDS-C for the Apple ][
Jeff Martin 10/24/81
The Softcard-equipped Apple runs a pretty standard CP/M 2.2, and so in most
respects supports the BDS C package without modification. Problems arise only
if C programs invoke certain standard library functions involved with physical
input/output. Specifically, the standard library is incompatible with the
Apple in the following two areas:
The plotting functions (setplot, clrplot, plot,
txtplot, and line) don't apply to the Apple, being
oriented towards an S-100 VDM1-like video board.
The inp() and outp() functions assume the
processor does its input and output via I/O ports.
The Apple's I/O is strictly memory-mapped, so the
standard inp and outp functions won't work.
A third potential problem is the csw() function, but it's so blatantly
non-portable that I assume nobody ever uses it. Letting it sit there and read
an unequipped port seems as good an approach as any.
The solution to the first problem is simply to disable (undefine) the plotting
functions, so accidental invocation won't do horrible things to RAM. (The
default initialization done by C.CCC sets the plotting base at CC00H, which for
56K Apple CP/M points a loaded gun at the BDOS).
The second problem requires a little more thought. First it should be noted
that programs that use these functions can hope at best for near-portability at
the C-source level. Even among CP/M systems that use I/O ports, there is
little standardization of the port assignments. It is expected that programs
using inp and outp will need easily-modified defines for the ports. On that
basis, the best inward portability for the Apple can be achieved by changing
inp and outp to do memory reads and writes, respectively. Then the only
required change to a source program will be changing the "port" definition
value to the appropriate memory address. This scheme also allows for outward
portability, with one caveat: Apple programmers must resist the temptation to
do I/O via pointers or the peek() and poke() functions and instead use the
"redundant" (for the Apple) inp() and outp().
Now for the nuts-and-bolts of making the required mods. Changes must be made
to five source files, and the order of the changes is sometimes important.
1. Make the following changes to CCC.ASM:
a. Change the DMAVIO equate to 0.
b. Insert a new equate, MEMMAPIO EQU 1.
c. Surround the iohack initialization code in "init" with an
IF NOT MEMMAPIO...ENDIF conditional assembly directive.
d. Similarly "feature out" the iohack ds directive.
e. Feature the ds's for pbase through psize as a function
of DMAVIO.
2. Assemble CCC.ASM, noting the new locations of "ram" and "setdma". Load
the result of the assembly, and rename it as your new C.CCC.
3. Make the following changes in BDS.LIB:
a. Change the equates for ram and setdma to the values
noted above.
b. Add equates for MEMMAPIO (1) and DMAVIO (0).
c. "Feature" the ds's for iohack and pbase-psize
the same as you did in CCC.ASM.
4. Make the following changes in DEFF2.ASM:
a. Change the "inp" function to generate code identical to
that of the "peek" function if MEMMAPIO is 1.
b. Change the "outp" function to generate code identical
to that of the "poke" function if MEMMAPIO is 1.
5. Change DEFF2A.ASM so functions "setplot" through "txtplot" are not assembled
if DMAVIO is 0. Note that directives must also be put in the "direct" area.
6. Assemble and load DEFF2.ASM and DEFF2A.ASM, and merge them with CLIB to
create a new DEFF2.CRL.
7. Finally, change the "port" definitions (and other attributes) in BDSCIO.H
to the correct memory addresses and masks for your console and modem.
Just so you won't think I missed the obvious, I'll point out that the inp() and
outp() problems could have been "solved" in most cases by adding the following
two lines to BDSCIO.H:
#define inp peek
#define outp poke
I just don't think it's good to have unusable and potentially dangerous code
lying around in libraries.
To be \really/ specific, what follows are UNIX-style "diff" outputs that
indicate the specific changes made to V1.44 sources. The BDSCIO.H changes
are for a CCS serial card in slot 3 (for the console) and a MICROMODEM ][
in slot 2.