Re: 40x24 Resolution Question

["Bryan Parkoff" <BParkoff@satx.rr.com>]

David,

    It does provide me the information what I needed to know about text
resolution.  I want to say thank you very much for the help.  It is
difficult to understand what we communicate by writing in English while we
are patient to understand each other slowly.  Thanks again.

--
Yours Truly,

Bryan Parkoff
BParkoff@satx.rr.com
David Empson <dempson@actrix.gen.nz> wrote in message
1fa0acc.1pk1qj6oarkmoN%dempson@actrix.gen.nz">news:1fa0acc.1pk1qj6oarkmoN%dempson@actrix.gen.nz...
> Bryan Parkoff <BParkoff@satx.rr.com> wrote:
>
> > > The actual bitmaps of the characters are stored in a ROM in the video
> > > circuitry.  This ROM is not accessible to the 6502 and you cannot
> > > read it from BASIC or assembly language.  You can replace it
> > > with a custom-programmed EPROM.  One of my Apple IIe's has a double-
> > > sized EPROM so I can switch between unenhanced and Mousetext.
> >
> >     Yes, it is what I meant bitmaps of the characters are stored in
video
> > ROM that they are not stored in any memory address $0000-$FFFF.
> >     I am wondering how it works.  If you want to load 'A' character
before
> > store it in $400, it will appear in the first column and first row.  How
can
> > video ROM read $400 before prints bitmaps into screen?  I am curious.
>
> The video ROM doesn't read main memory (a ROM has no such capability).
>
> The video circuitry includes a "state machine" (effectively a very
> simple processor) which is responsible for fetching data from video
> memory and generating the video display.  The video ROM is used by the
> video circuitry.
>
> In the Apple II and II+, the video circuitry mainly consists of simple
> logic chips.  In the IIe and IIc, Apple made their own custom logic chip
> (the IOU, or "Input/Output Unit") which is responsible for generating
> the video signal: it still uses some external support logic and a
> separate video ROM.
>
> In the IIgs, there are two chips which are mainly responsible for video
> generation: the "Mega II", which incorporates the IOU, video ROM and
> other circuitry from the IIe motherboard, and the VGC ("Video Graphics
> Controller"), which is unique to the IIgs.  The Mega II deals with all
> of the original Apple II video modes, and the VGC is responsible for RGB
> colour output and the IIgs-specific super hi-res graphics mode.
>
> Getting back to the operation of the video circuitry:
>
> Several mode setting soft-switches ($C050-$C057) control the operation
> of the video circuitry, selecting the active video mode (text, lo-res
> graphics or hi-res graphics) with options for mixed text/graphics, and
> selecting whether to display page 1 or page 2.
>
> If operating in text or lo-res graphics mode, the IOU (or equivalent
> circuitry in the II and II+) is continuously scanning the memory area
> from $0400-$07FF (page 1) or $0800-$0BFF (page 2) to fetch data to be
> displayed on the video screen.  The interpretation of that data depends
> on whether lo-res graphics or text mode is active.  In hi-res graphics
> mode, the video circuitry is continuously scannign $2000-$3FFF (page 1)
> or $4000-$5FFF (page 2).
>
> The CPU and video circuitry operate from the same master clock source,
> and are in sync with each other.  Each CPU cycle (about 1.024 MHz) is
> divided into two "phases": during one phase, the video circuitry fetches
> a display byte from RAM; during the other phase, the CPU is able to read
> or write RAM (or other areas, such as I/O and ROM).
>
> The data in the video buffers is arranged into rows of 40 bytes,
> corresponding to each line on the screen.  Within each group of 128
> bytes, there are three rows of 40 bytes, plus 8 bytes which are not
> displayed by the video circuitry (these are known as the "screen
> holes").
>
> For the text screen, there are eight groups of 128 bytes within the 2KB
> buffer, so there are 8 * 3 = 24 rows of data, and 8 * 8 = 64 screen hole
> bytes.  The screen holes for page 1 are $0478-$047F, $04F8-$04FF,
> $0578-$057F, $05F8-$05FF, $0678-$067F, $06F8-$06FF, $0778-$077F and
> $07F8-$07FF.  Since these locations are not displayed, they can be used
> for other purposes, and are reserved for use by the firmware and by I/O
> cards.  If you are writing directly into screen memory, you should avoid
> changing the contents of any of these locations.  The screen holes for
> page 2 and for hi-res graphics are not used by the firmware, so it is
> safe to overwrite them.
>
> The screen rows are organised into a "strange" order.  The first display
> row is the first 40 bytes of the screen buffer, but remaining rows are
> interleaved in a "venetian blind" pattern.  If you access memory
> linearly, then the data in the second and third rows within each 128
> byte block are one third of the screen apart (8 rows in text mode, 64
> rows in hi-res graphics mode).  Each subsequent block of 128 bytes is
> one eighth of the screen lower than the previous one.  In hi-res
> graphics mode, the pattern repeats eight times, with each subsequent
> block of 2048 bytes being a repeat of the previous pattern, moving down
> one row.
>
> For text mode, this produces the following mapping from screen rows to
> memory locations for page 1, assuming I haven't made any typos.  (Add
> $0400 to get addresses for page 2.)
>
>  0  $0400-$0427
>  1  $0480-$04A7
>  2  $0500-$0527
>  3  $0580-$05A7
>  4  $0600-$0627
>  5  $0680-$06A7
>  6  $0700-$0727
>  7  $0780-$07A7
>  8  $0428-$044F
>  9  $04A8-$04CF
> 10  $0528-$054F
> 11  $05A8-$05CF
> 12  $0628-$064F
> 13  $06A8-$06CF
> 14  $0728-$074F
> 15  $07A8-$07CF
> 16  $0450-$0477
> 17  $04D8-$04F7
> 18  $0558-$0577
> 19  $05D8-$05F7
> 20  $0658-$0677
> 21  $06D8-$06F7
> 22  $0758-$0777
> 23  $07D8-$07F7
>
> The video hardware scans the display buffer in the order in which data
> is displayed on the screen.  Each byte read from memory is converted
> into 7 pixels which are to be displayed on the screen (lo-res graphics
> mode is a special case - it generates 14 pixels, allowing for better
> control over the colour).  The selection of the content of those pixels
> depends on the current video mode and on the value of the byte fetched
> from the display buffer.  Ultimately, the data ends up in a shift
> register, which is clocked out to the video display at about 7 MHz (14
> MHz in lo-res mode).
>
> In hi-res graphics mode on the II and II+, the contents of the low order
> 7 bits of each byte are used directly, with the high order bit being
> used to modify the timing of the output to shift the colours.
>
> In text and lo-res graphics modes, the byte fetched from memory is used
> as an index into the video ROM to fetch one byte of the pattern to be
> displayed.  An internal counter (from 0 to 7) is used to count the rows
> of each character, and this counter modifies the address used to access
> the video ROM.  Each of the memory locations for a text row is read
> eight times, with each read corresponding to one row of the text
> character.  Lo-res mode is similar, but there are different addressing
> rules for the video ROM to allow for the lower and upper four bits being
> used to display independent blocks.
>
> Here is an example of text screen output.
>
> At the top of screen, the top border is displayed.
>
> When the "video window" (first normal display line) is reached, the
> character row counter is set to zero, and the video hardware fetches
> location $0400.  Its content is used as an index into the video ROM to
> fetch the first row of the appropriate character.  This is stored in the
> video shift register, and 7 bits are shifted out over the next CPU
> cycle.  The video hardware then proceeds with location $0401, $0402,
> etc., through to $0427.  At this point, the screen has displayed the
> first row of each character on the first line.
>
> The video hardware then increments its character row counter to one,
> goes back and fetches location $0400 location, and uses it as an index
> into the video ROM to fetch the second row of the appropriate character.
> This is output through the shift register, and the pattern repeats for
> locations $0401 through $0427.
>
> The whole pattern is repeated eight times, with the end result being
> that all eight rows have been display for each of the characters on the
> first line.
>
> The video hardware then proceeds to the second line ($0480-$04A7) and
> repeats the entire process, with the character row counter advancing
> from 0 to 7.
>
> The pattern repeats for subsequent lines ($0500-$0527, $0580-$05A7),
> etc., until the last row has been displayed.
>
> The bottom border area is then displayed, followed by the vertical
> retrace, then the entire sequence repeats to refresh the screen.
>
> The screen is refreshed at 50 Hz or 60 Hz (depending on the country in
> which the machine was made, and mode settings in the case of the IIgs),
> so the entire process takes 20 ms (50 Hz) or 16.67 ms (60 Hz).
>
>
> Some additional notes:
>
> The high order two bits of the character in text mode are used to modify
> the display format: $00-$3F are inverse, $40-$7F are flashing and
> $80-$FF are normal characters.  In the IIe and later machines, the
> inverse characters are stored directly in the video ROM, but I'm not
> sure about the II+.  Flashing mode is implemented by a separate timer
> which modifies the lookup address in the video ROM, effectively toggling
> flashing characters between the $40-$7F and $C0-$FF ranges according to
> the current state of the flash timer.
>
> The video ROM is also used for hi-res graphics mode in the IIe and later
> machines, but the data patterns output are identical to the index value
> read from the screen buffer.  This mechanism was used to simplify the
> design of the video hardware.
>
> The IIe adds several features to video display, notably the "alternate
> display mode" (a different text character set), and double resolution
> modes (80-column text, double lo-res and double hi-res graphics).
>
> The double resolution modes work by using an identical buffer located in
> the same range of addresses in auxiliary memory.  The video hardware
> fetches bytes simulataneously from main and auxiliary memory, and the
> data is output to the video display at twice the normal rate (14 MHz).
> (I haven't looked into double lo-res mode in detail, so I'm not sure of
> the precise details, but it still operates at 14 MHz.)
>
> --
> David Empson
> dempson@actrix.gen.nz