Bryan Parkoff 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 Bryan Parkoff wrote: > 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? I cannot answer that question, as I haven't seen enough detail about the Apple I to know how its text screen is implemented (let alone the character mapping). > 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. The ][ and ][+ have identical video ROMs - neither contains any lower case characters (unless you replace the ROM). I don't have a real machine here, but the Apple ][ reference manual (1981 edition, which covers the ][ and ][+, but only the "revision 0" and "revision 1" motherboards) claims that the $E0-$FF characters are duplicates of $A0-$BF (digits and symbols). The manual's description of the video circuit says that only the lower order six bits of each byte read from the text screen are used to look up the video ROM. This means that it is not possible to display more than 64 unique characters on early revisions of the ][ and ][+. Some additional research in the "differences between the ][ and IIe" appendix of "Understanding the Apple IIe" reveals that my Apple II Technical Reference manual is somewhat out of date. Does anyone know if there was a later edition of this manual before the IIe was released? On revision 7 of the Apple ][ motherboard, Apple replaced the 2513 character generator (probably a mask programmed ROM) with a standard ROM, and allowed 7-bit characters to be supplied to the ROM in NORMAL mode (i.e. $A0-$FF can be distinct characters). As supplied by Apple, the characters in the $E1-$FA range (lower case letters) were the same as $C1-$DA (upper case letters). I'm not sure about $E0 (reverse quote) and $FB-$FF (left brace, vertical bar, right brace, tilde and DEL). The end user can replace the video ROM with a custom EPROM which contains arbitrary characters. Installing a "lower case" EPROM was a popular modification. This tallies with my recollection of the late model Apple ][+ machines ("Europlus" models) I used at school in 1981 and 1982. In 1983, the school upgraded to the Apple IIe, which I used extensively and became intimately familiar with its details, courtesy of much experimentation and poring through manuals. In earlier revisions of the Apple ][, character $7F would be a flashing question mark, and $FF would be a normal question mark. I don't know off-hand what character appears for $FF in an unmodified revision 7 Apple ][ or ][+, but it isn't a checkerboard. (The flashing space used by the ][ and ][+ as a cursor is actually character $60, or possibly a software-timed alternation between $20 and $A0.) As for the IIe: The major change in the character set is the addition of lower case as a standard feature. In addition, character $FF is a checkerboard symbol, which the IIe uses as a cursor. The IIe adds a second character set, which can be selected under software control. The "primary" character set is designed to be compatible with the ][+, and is used by default when in 40 column mode. The "alternate" character set eliminates FLASH support, but allows the display of inverse lower case characters, and is used by default when the 80-column firmware is active (even if it is being used to display 40 columns). The unenhanced IIe's alternate character set has two sets of inverse upper case characters, in the $00-$1F and $40-$5F ranges. The $00-$1F range is the standard one, compatible with inverse upper case in the ][ and ][+. In the IIgs, IIc and enhanced IIe, Apple replaced the $40-$5F characters with "mousetext" symbols, which can be used to draw elements of a windowed user interface on the text screen, and for special symbols such as Open-Apple and Solid-Apple. Applications are supposed to use $00-$1F to display inverse uppercase, but some used $40-$5F, causing display problems due to unexpected mousetext characters when the software is used on an enhanced IIe or later machine. -- David Empson dempson@actrix.gen.nz