Re: Double lowres graphics?

[Dennis Jenkins <dennis@usb.com>]

David Empson wrote:
> 
> 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.

Since I want my code to work on all Apple II's that have hardware
support for
double low-res, I'll write the pixel plotting code myself, instead of
calling 
Applesoft's implementation.  However, how to I programmatically turn on
and off
the 80 column firmware such that the output routine at $FDED will
understand what
I'm doing?  I know I can turn it on with a "jsr $c300", but how do I
turn it off?


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

Could I just set the aux_type flag on my file to $4000, if the decrease
in memory
is not a concern to me.  I can always try this tonight on my own.

-- 
dennis@usb.com                           Universal Savings Bank.

The three most dangerous things are a programmer with a soldering
iron, a manager who codes, and a user who gets ideas.