The ULA actually generates most of the difficult bits of the system, such as screen forming, CPU and Memory timing. The CPU runs at 1 Mhz, but only acts (Reads or writes to memory) on the positive edge of the Clock input (01). This enables the screen and character memory to be read by the ULA on the negative (02) edge of the clock (1Mhz).

Screen memory uses serial attributes. This means that for every Colour change or special character required, the system will generate a character cell to represent the change.

This places great restraints on colour screens or sprites. On the other hand, it consumes only the size of memory neccesary to generate the actual visible screen. Other systems use further screen maps to represent colour changes.

The ORIC can generate two screen modes, HIRES (Graphics) or TEXT. Both have a virtual resolution of 240 by 224 but TEXT is more generally considered to be a resolution of 40*28.

Each byte interpreted for screen memory is split into groups of bits, depending on the screen mode.


Description (TEXT) Table 1

Table 1 shows the format that bytes are interpreted in TEXT mode whilst Table 2 is for HIRES. Note the close simalarities between the two modes. The main difference is that in TEXT, a byte is read, and if that byte is a character, then this is used to index a particular character in another area of memory.

HIRES is more direct, with a bit map 'character' being sent straight to the screen. The bottom three lines remain as TEXT.

A TEXT character is 6*8 pixels. A HIRES bit map byte is just 6*1 pixels.


0-31: Attributes (32)


32-127: Character (96)


Normal (0) or Inversed (1)


Description (TEXT) Table 2


Data (0-63)


Attribute(0) or Bit map (1)


Normal (0) or Inversed (1)


The link between TEXT and HIRES does not stop here. To select each mode, specific attributes are placed in screen memory to switch to HIRES (30) and back to TEXT (27).

This in turn shifts character memory according to which screen mode is present since even in HIRES, the bottom three lines of text must have character memory available for them.






Note the different sizes of character memory between screen modes. This is just the 'nature of the beast' and is not a bug as such.

Also, there appears to be too much memory assigned for the character


Character Memory




TEXT screen





Character Memory




HIRES screen




set! Since if up to 96 characters exist, and each character consumes 8 bytes, thats #300 for a character set, so the question might remain, where does the other #600 bytes go?

Well, the Nice people at ORIC gave us TEXT characters but also gave us a further mode, ALTERNATE characters. These map in another #300 bytes of character memory. Also, since character memory starts at #B400 in text mode, this would be for Character 0, which does not exist. Characters start from 32 (Space character), so the memory that is allocated to attributes is not actually used. This is #100 bytes (eg. 8*32).

This is all well and good, but TEXT characters, as shown in Table 3 consume just #780 bytes. The missing 16 characters are the ALTERNATE set and overflow into part of the TEXT screen!

In HIRES, this is not a problem.

Also, another discrepancy exists in HIRES memory. The resolution of the actual HIRES portion of the screen is 240 * 200 pixels, this is 40 bytes across. So the memory consumed should be 40 * 200 which is #1F40. Add to this the bottom three lines of text (40*3) and one gets 1FB8 bytes!

But HIRES consumes #1FE0 bytes, that's 40 bytes difference. The difference actually sits in between HIRES and the bottom 3 lines of text, with one byte of the 40 to switch the mode back to TEXT!

Since the switch is made here, at the bottom most point of HIRES, the Hardware automatically switches the screen mode back to HIRES on the next screen refresh.

The switch to HIRES can actually take place on any part of the screen, this enables some very colourful displays whilst still retaining TEXT mode for speed.


 This site is under construction... please be patient or... have a tantrem!!