Newsgroups: comp.sys.apple2.programmer
Path: info.curtin.edu.au!uniwa!munnari.oz.au!comp.vuw.ac.nz!actrix.gen.nz!dempson
From: dempson@swell.actrix.gen.nz (David Empson)
Subject: Re: Hi-res Graphics
Organization: Actrix Information Exchange
Date: Tue, 19 Oct 1993 15:40:00 GMT
Message-ID: <CF5I6p.HHy@actrix.gen.nz>
References: <29s4ot$dn6@crcnis1.unl.edu> <CF3E03.Gv2@actrix.gen.nz> <29uheu$jng@crcnis1.unl.edu>
Sender: dempson@actrix.gen.nz (David Empson)
Lines: 120

In article <29uheu$jng@crcnis1.unl.edu> gberigan@cse.unl.edu (Greg Berigan) writes:
> dempson@swell.actrix.gen.nz (David Empson) writes:
>
> So I take it it is a feature of the card which patches DOS on the fly
> rather than DOS itself recognizing the existence of RAMdisks.  Is this
> true of all/most non-aux RAM cards?

At least Apple's (I assume) and the RamFactor.  The PC Transporter
doesn't support DOS 3.3.

> >The blocks are not mapped linearly into auxiliary memory.  I haven't
> >looked into the internals of the /RAM driver to see how it works.
> 
> From BSAVEing the DHGR aux page directly from Page 2 it appears to map
> linearly.

Sorry, I wasn't quite clear.  The bytes are mapped linearly within
each 512 byte block, but the blocks are _not_ allocated in ascending
order in auxiliary RAM.  They are carefully arranged so that the first
16 data blocks will be saved at $2000-$3FFF and the next sixteen at
$4000-$5FFF, with the two index blocks elsewhere (probably $1000 and
$1200).

I really meant "not allocated in ascending order".

> >Since it is documented in the ProDOS-8 technical reference manual, I
> >think it can be relied on to work with all Apple II models with
> >auxiliary RAM (IIe, IIc, IIc+, IIgs, Mac LC card).
> 
> But then that would imply that blocks 8 to 16 are mapped linearly to the
> DHGR aux page.  But then where does it toss the block pointer table to
> the file?

There is a table in the RAM driver which handles the block mapping.  I
don't think it behaves the same way all the time - it depends on the
order in which you save files and size of the files.  It has some
quite clever code in there.

> >You must save two 8k files to have this work properly, and they must
> >be the first files saved to /RAM.
> 
> I never had problems with using only 1 8K file.

I meant if you want to protect page 1X and 2X.  The first 8k file
protects 1X, so there is no problem there.

> I've never seen page 2x displayed, so never had reason to use it,
> although someone claimed it was possible.  Is this done in the same
> manner that allows FLASHing text in 80 columns?

Que?  That is quite simple - turn off the alternate character set to
get flashing characters in 80-column mode.

To display 80-column versions of page 2, you must turn off the 80STORE
soft switch (write $C000) then use the PAGE1/PAGE2 switches to select
the appropriate screen.

I can't recall what happens if you re-enable 80STORE while page 2 is
displayed.  I think it switches back to displaying page 1.

> Now I'm interested in trying the same trick but this time with GS SHR
> graphics and memory ghosting.  I understand there is a way to write
> information into the aux page and have the effects take place in bank
> $E1.  How is this done, and could /RAM be used in this manner?  How much
> of the file would need to be juggled to get the first part of it in
> $01/1000?

Since the block allocation of /RAM is not documented past the first
16k, you can't safely reserve the entire Super Hi-res buffer by saving
a file to /RAM.  You could try saving a file which occupied the entire
RAM disk, as the index block would almost certainly be near the start
of auxiliary memory.

Accessing the IIgs super hi-res screen can be a little tricky.  You
have to fiddle with a few softswitches.

Most of it is controlled by the top two bits of I/O location $C029.
You have to be very careful when accessing this location - all the
bits are defined, and some of them do very nasty things if you
accidentally change them.  I would recommend using some machine code
to change this register rather than PEEK and POKE.

Bits 7 and 6 behave as follows:

7  6

1  x     Display Super hi-res, with linear memory
0  1     Super hi-res display off, but linear memory still active
0  0     Non-linear memory (required for using double hi-res mode)

I have tried to work out what the linearization actually does to the
ordering of the RAM locations, but it is very complicated.

If you're dealing with the super hi-res screen, you basically have to
make sure the screen is "linearized" before trying to write data into
it (if you're setting up the screen data while the screen is hidden).

The screen memory occupies $E1/2000 through $E1/9FFF.  The last two
pages are the palettes ($9E00-$9FFF), 32 bytes each, with two bytes
per colour (first byte is GREEN:BLUE, second is 0000:RED).

The $9D00 page contains the scan-line control bytes (first 200 bytes),
which are defined as:

7 6 5 4 3 2 1 0
* . . . . . . .  1 for 640 mode, 0 for 320 mode
. * . . . . . .  1 to enable scan-line interrupt for this line
. . * . . . . .  1 to enable fill mode (320 mode only)
. . . * . . . .  reserved (0)
. . . . * * * *  palette number for this line


To be able to access the shadowed video buffer in bank $01 ($01/2000
through $01/9FFF), you have to enable super hi-res shadowing, by
clearing bit 3 of location $C035 (as before, make sure the other bits
are not changed).
-- 
David Empson                                                               
dempson@swell.actrix.gen.nz                                                
Snail mail: P.O. Box 27-103, Wellington, New Zealand 

