<=<=<=<=

Source codes are available at the bottom of this page.


Part SEVEN: Explanations about the video display

The Oric is able to display informations using 2 totaly different modes.
The TEXT mode is used by default when you boot (!!!) the computer. But it can be called with the TEXT command in Basic. The modes LORES 0 and LORES 1 are some variations of TEXT.

From a memory point of view, TEXT mode requires 1120 bytes for display (28 lines of 40 rows), and 1920 bytes for storing the character set. This makes a total of 3040 bytes.

Example of TEXT mode
Some HIRES graphics The HIRES mode can be called by using the HIRES command in Basic.

In HIRES, we always have these 1920 bytes for the characters, but the display takes much more: 8000 bytes for the graphics part (200 lines of 40 bytes), and 120 bytes for the 3 text lines under the graphic screen. This makes a total of 10208 bytes.

An ORIC always use a monochrome display. The fact you can use 8 colors at the same times on the screen doesn't mean that you're not in monochrome.
I explain.
For the video chip (ULA: Undedicated Logic Array) or the Oric, a pixel is either a foreground pixel, or a background pixel. When you draw a line, a circle, a dot, put a letter on the screen, etc... you never have the opportunity to specify it's color. The only effect is that some pixels of the screen switch between the state OFF (meaning it's a background pixel) and the state ON (it's a foreground pixel).

By default, the colors on the screen are WHITE INK and BLACK PAPER. The Oric is able to display up to 8 colors at the same time, so here is how it works.
But before of that, I've to explain how the video memory works.

In TEXT mode, you can see the screen like a giant (!) array of 40 rows by 28 lines.
In general, the first line is reserved by the system, and is used for displaying infos like the file beeing loaded, the status of the CapsLock trigger, and stuff like that. It is called the status line.
In this array, you can put some values. If these values (bytes) are in the range 32-127, it means this is a character to display. It is standard ASCII codes. I said standard. Values above 127 are not ASCII values.
If the value is above 127, it means that the character is in Video Inverse. In that case, you substract 128, and you have the standard ASCII value, but displayed with different colors. As I'm talking about colors, here is a little table that shows the available colors, and the resulting inverted colors:

NUMBER STANDARD COLOR INVERTED COLOR
0 BLACK WHITE
1 RED CYAN
2 GREEN MAGENTA
3 YELLOW BLUE
4 BLUE YELLOW
5 MAGENTA GREEN
6 CYAN RED
7 WHITE BLACK

As you can see, the video inversion consist in an inversion of each component of the color.

Now, about the colors, you have to understand the principle of line attributes.
When you want to change a color, you have to insert an attribute that will say to the ULA, that now the colors are not WHITE or BLACK, but something else. An attribute is any value find by the ULA in the screen, with a value less than 32. Almost every attribute start it's effect at the position he was read, and this until another attribute changes something, or until we reach the end of the current video line. When a new line starts, the ULA resets all its internal attribute registers, set the background color (the paper) to BLACK and the foreground color (the ink) to WHITE.
This simplicity is cool. But the drawback is that when you put an attribute somewhere, you cannot put something else.
And this something else could have been character or graphics.
Before I continue, I now gives you the list of all available attributes:

Ink (foreground) attributes
VALUE EFFECT
0 Change INK to BLACK
1 Change INK to RED
2 Change INK to GREEN
3 Change INK to YELLOW
4 Change INK to BLUE
5 Change INK to MAGENTA
6 Change INK to CYAN
7 Change INK to WHITE


Paper (background) attributes
VALUE EFFECT
16 Change PAPER to BLACK
17 Change PAPER to RED
18 Change PAPER to GREEN
19 Change PAPER to YELLOW
20 Change PAPER to BLUE
21 Change PAPER to MAGENTA
22 Change PAPER to CYAN
23 Change PAPER to WHITE


CharSet modifier attributes
VALUE EFFECT
8 SingleSize NonBlinking Standard Charset
9 SingleSize NonBlinking Alternate Charset
10 DoubleSize NonBlinking Standard Charset
11 DoubleSize NonBlinking Alternate Charset
12 SingleSize Blinking Standard Charset
13 SingleSize Blinking Alternate Charset
15 DoubleSize Blinking Standard Charset
15 DoubleSize Blinking Alternate Charset


Video control attributes
VALUE EFFECT
24 60 Hz TEXT display
25 60 Hz TEXT display
26 50 Hz TEXT display
27 50 Hz TEXT display
28 60 Hz HIRES display
29 60 Hz HIRES display
30 50 Hz HIRES display
31 50 Hz HIRES display

With all these tables, you can now understand why it is impossible to access to the 2 first columns of the screen.
When you type PAPER 4, the first column of the screen is filled with the attribute 20, and when you type INK 6, the second column is filled with the attribute 6. If you try to poke something in these adresses, the text at the right is altered (meaning that the text become WHITE, or the background become BLACK).

For aesthetical reasons, I give you an advice: If you want to display text with colors, better try to put the INK attribute first, and then the PAPER attribute. The result is the same, except that the first column is black. So it look like if only ONE column where unusable. It's the same thing in HIRES, it reduces the shocking effect of graphics starting very far from the left of the screen.


It's possible to enable special effects for the display of text (and for graphics too with the blinking).
Attributes 8 to 15 changes the way the text is displayed at screen. You can select the alternate charset, display the text in double height mode, and at last, made the text blinking.
All theses specials functions can be used with only ONE attribute, so it don't take to much space on screen.
The Oric is able to use 2 different character-set for displaying text. The normal charset is copied from the ROM at the startup, while the second one is generated by a ROM routine. The second charset looks like a 2x3 blocs matrix. Each of these pixels is about 3x3 pixels, except the middle line that is only 3x2 pixels (because 3 blocs of 3 pixels makes 9 pixels ---> more than the 6x8 character size).

Note: most computers uses an 8x8 font size, but in the Oric, it is only 6x8. This explains the strange HIRES resolution. 240 pixels wide looks like 40x6 pixels. And as the video chip process HIRES a bit like TEXT, it's normal that the constraints looks the same. For the ULA a byte can contain only 6 displayable bits, because the 8th bit represents video inversions, and the 7th bit is used as an "attribute active" flag.

This charset can be useful for displaying pseudo-graphics since it's easy to compute the appearance of a block. The following table gives the values to use for activate one of the blocks: (Always add 32 to this value)


Coding of alternate charset
01 02
04 08
16 64
If you want to draw a character with the top-left ,middle-right, and bottom-left blocs activated, you have to display the character with the ASCII value of: 32 (Characters before 'space' are attributes) +01+08+16.
Perhaps you notice that the last value was 64 instead of 32 ? We need to force the 5th bit to ONE, so we're sure to never have to display an attribute. All of that is a little bit tricky, and hard to explain, but it's not so important to know it since nobody uses this mode :). If you really need to test how it works, just type LORES 1 on your ORIC, and type some things on screen. You will understand how it works. Ok ??? Fine.

Perhaps you were thinking that alternate charset was a bit tricky ? Hum, just read now about the Double Height feature !
Double height allows the video controler to display only one of the halves of a character with a vertical stretching effect. Since the attributes never specify if you want to display the top or bottom part of the character, the ULA most decides itself. The choices is based on the number of the text line beeing displayed. If the number is EVEN it will display the upper part, if it's ODD it will be the lower part. So, you have to be carefull when you use this feature. If you want to scroll the screen, you will see all your letters displayed uncorectly every two frames...

The last effect is the blinking. You cannot change the speed of the blinking, because it is based on an internal computation made by the ULA. I suppose that tricking with 50hz and 60hz attributes will change the speed of a 5/6 or 6/5 ratio, but the only sure result is that your TV display will jump. The only effect of blinking is to force foreground pixels (ink) to background when the blink is ON. The background color is never altered by a blinking effect. I don't remember the effect in the case of video inverse. But try it if you want.



Special video modes
On the Oric, it is not really possible to achieve hi-tech tricks for doing hardware-scrolling, fullscreen, using more colors, or even display pixels at the same locations than attributes. I hope that the future will prove me I was wrong, but for the moment take this as the Truth. (Note that if you manage to do things like that, I will be very happy !)
Anyway, it's possible to create mixed video modes.
When you are in Hires mode, you have 200 Hires video lines, and 3 Text lines. This is an example of mixed mode.

After you start your Oric, just type on the following keys:

ESC

SHIFT+ ]

you will see something like the screen at right. Strange no ?
Example of mixed mode
Now, just press on the RETURN key until you can see the cursor again. It seems that you only have a part on the screen scrambled with strange things ?
Ok, now let's extend the scrambled area !
Continue to press on RETURN, until the bottom of the screen, and continue to press it until the screen scrolls.
The wasted area start to expand to the upper part of the screen. And then finaly it disapears.

Example of mixed mode Perhaps you need an explanation ?

In fact, when you type ESC+], you just put a 50 Hertz graphics attribute at the position under the cursor. When the ULA reads this character, it switches to the HIRES drawing mode. If you don't believe me, just type HIRES:DRAW 239,199,1:TEXT
Now, if you type again ESC+], you will see a part of a line instead of the initial scrambling. It proves you that the video chipset starts to draw what is present in the HIRES memory when it encounters this special character.
But ok... That means that the video memory has 2 different starting adresses at the same time !
And why does the Hires display stops at the middle of the screen with some strange BLUE pixels ?
For more explanations, I have to introduce you to the cool world of the video memory organisation !


Video memory organisation
In LORES modes, the screen memory starts at the location $BB80.
In HIRES mode, this adress is $A000.
The ULA maintains a flag that indicates if the current drawing mode is HIRES or LORES.
An internal counter increments after each line drawned. This counter is used by ULA for computing the adress of the next line that must be displayed.
The fact that the adress is always computed and not only incremented explains why it is not possible to create hardware scrolling on the Oric. I explain:
In HIRES, the adress of a scan line is computed with the following formula:
PtrDisplay=$a000+(VideoLineCounter*40)
In TEXT, the formula is:
PtrDisplay=$BB80+((VideoLineCounter/8)*40)
So, if you switch from HIRES to LORES, or from LORES to HIRES (in the same frame of display !) the adress is always correctly computed. But, if the ULA instead of calculating adresses would have only incremented and offset (relative to the start adress of the video screen) after each readed scan-line, it would have been possible to create hardware scrolling by switching between HIRES lines (1 one scan line for one video line) and LORES lines (1 scan line for 8 video lines).

So, imagine you're displaying a HIRES screen. The start adress is $A000. In $A000+39, you put an attribute 26 that means "50 Hz TEXT mode". The next scan line will be a TEXT line. The adress of this line will be $BB80+(1*40) but, the ULA will display the 2nd line of each character of the screen so all letters on screen will have the upper line missing.
If you want to switch back to HIRES mode, you will have to put a 30 attribute (50 Hz HIRES mode) at the adress $BB80+(1*40)+39.

Using this method it is possible to program various screen mode with mix between HIRES and LORES. But there is a major drawback ! When you're in TEXT mode, the ULA decodes memory bytes as ASCII codes. These ascii codes are used for accessing the CharSet table that contains the patterns to display for drawing characters. The adress of theses CharSet tables are $B400 for the standard charset, and $B800 for the alternate charset. The trouble is that the adresses from $B400 to $BB80 are in the memory used by HIRES display (from $A000 to $BFE0) !!!

The screen shot at right shows you an example of text mode using HIRES mode for displaying rasters.
Text mode with Hires raster
Now, some simple calculations for knowing how many HIRES scan lines it is possible to display without interfering with the CharSet area:
$B400 (CharSet base adress) - $A000 (HIRES screen base adress) = 5120 bytes
5120 / 40 (size of a scan line) = 128 lines.

128 lines ???
It looks like a little bit more than half of the screen size ?

Now, examine closely the first split screen picture above. It looks exactly as if we have 128 HIRES lines followed by some scrambling (the BLUE pixels !). No idea ???
In fact, when we do the ESC+] operation we say to the ULA to starts an HIRES display, but we never say the ULA to switch back to TEXT mode. But when the ULA arrived at the 129th line, it starts to read the CharSet table, and unfortunately, one of the Character redefinition byte contains a value that is interpreted as a TEXT mode attribute. It's easy to verify this. Just try to redefine the Character appearance with the program of your choice (as the one in the Oric Atmos user manual), and try again the manipulation. You will notice that the scrambling is not identical.
Text mode with Hires window The picture at the left, is another example of how to insert a HIRES window in a standard TEXT mode.
Such a method can be usefull for plenty of applications ! Imagine you want to program a great Role Playing Game ? If you need to show inventory, or display the current equipment of your hero, it can be valuable !
You want to do a HTML viewer ? Perhaps it is possible to combine the speed of the TEXT display, with the graphix capabilities of HIRES mode (Ok, viewing HTML on an Oric can be pretty useless. But I suppose that my page is dedicated to useless applications of programming 8 bit machines !).


Some downloadable source codes !
And now, what you were all waiting for !
The source codes !
Yes, you will be able to do these wonderful (LOL) graphics, by your self !
The code is clear (I hope), fully documented (since I do it for you !), cleaned (I remove all the stupid testing stuff and useless instructions), and understandable by anyone who knows how to code in C.
Since I've added some explanation for BASIC programers, and since I'm using only FOR loops and POKE instructions, it is immediately portable in BASIC. Not even need to think for doing it !
Why using C ? Well. Plenty of reasons !

Get the RASTERS'in TEXT source code !
Get the HIRES WINDOW'in TEXT source code !


To be continued...
SOS !!!Contact...Informations...