Re: Double lowres graphics?

[dempson@actrix.gen.nz (David Empson)]

Dennis Jenkins <dennis@usb.com> wrote:

> Mike Pfaiffer wrote:
> > Dennis Jenkins wrote:
> >         Oddly enough, for the machines you mentioned, double lores is
> > implemented in Applesoft.

It is supported by Applesoft in the IIgs, but not for the IIe (nor the
IIc).  I don't know about the IIe emulation card for the Mac LC.

Hardware support is available in all of these machines.

For the IIgs, you get double lo-res graphics from Applesoft by having
80-column mode active (PR#3), setting annunciator 3 to the correct state
(reading either $C05E or $C05F - I can never remember which) and doing a
GR.  You will get 80x40 mode, or 80x48 if you switch to full screen
mode.

For the IIe or IIc you would have to implement it yourself, as the
lo-res graphics routines only know about 40-column mode.

> Do any of the older machines NOT support double low res?  Is it safe to
> assume that ALL Apple II's with 128K ram have double low res capability?

I'm not sure about the revision A motherboard for the Apple IIe, which
doesn't support double hi-res graphics (it might not support double
lo-res either).

>   Why does prodos have to load $SYS programs into the highres memory
> area?

The quit code (program selector) is copied into main memory at
$1000-$12FF, and it needs to be able to use at least $400 bytes for
buffer space, so $2000 seems a natural location.

I can't think of any particular reason why they did it this way.  For
example, the quit code could have been at $0800 and the SYS program
loaded at $1000.

It wouldn't be reasonable to load the SYS program higher in memory,
because that would limit its maximum size accordingly.  As implemented,
the maximum size for a SYS file is $9F00 bytes (just under 40 KB).

> I want to write a program as a prodos-8 native .SYS program AND use
> highres graphics.  Writing a relocated is not easy right now, esp. since I
> use the CC65 cross compiler...  For now, I'll just stick to .BIN files
> that load at either 800h or 4000h.  Argh!

The easiest solution is usually to build the program for its ultimate
location, and throw a small machine code relocator on the front, which
can do a simple memory move.

If this isn't easy given the tools available in the development
environment, you should be able to write the relocator separately and
use BLOAD and BSAVE commands to hack the SYS file into one piece.