[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 40x24 Resolution Question
I forgot to ask one more question. Are Apple I's text resolution and
Apple II/II+'s text resolution the EXACT same with all uppercase, inverse,
and flash? Is white solid box like hex 0x7F the EXACT same for Apple
I/II/II+?
I understand that //e and later have only one difference with hex 0x7F
that shows dotted box instead of white solid box and also lowercase support
is added for II+, but I don't know if II does support lowercase unless ROM
is switched.
--
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