Need hardware informations on Orics (Was: Oric Hardware Revision)
Manoël Trapier
I posted here a few month ago
(archive here :
http://groups.google.fr/group/comp.sys.oric/browse_thread/thread/1ba423453829e80b/7184714ba6c0b3f5?#7184714ba6c0b3f5
)
and after some month on inactivity, I finaly take pictures of my 48k
atmos with a 16k board :
http://www.yaronet.com/mirari/1Un5
http://www.yaronet.com/mirari/2n0B
http://www.yaronet.com/mirari/5EPz
http://www.yaronet.com/mirari/g1Qp
http://www.yaronet.com/mirari/T5jH
http://www.yaronet.com/mirari/dQCA
(I found the latest really artistic :-D )
Anyway I have some question about the hardware of the Orics
I found a lot of documentation about the 6502, or some about the VIA,
or any chips that are standard, but the ULA there is no real
information (execpt some timing or things electrical functions) but I
didn't found any informations about how it use exactly it's memory how
to switch in hires etc.. I known that I can take the ROM and read
instructions sources like for Hires, but even if 6502 is not the most
difficult assembly to read, it will be simpler, if there is
documentation about it.
I try poking hires code (50/60hz) to some area (like the first
character on line 0, col 0) but nothing will make something like HIRES
do.
Thanks
Manoel
Steve Marshall
"Manoël Trapier" <godzil at godzil net> wrote >
> Anyway I have some question about the hardware of the Orics
>
> I found a lot of documentation about the 6502, or some about the VIA, or
> any chips that are standard, but the ULA there is no real information
> (execpt some timing or things electrical functions) but I didn't found any
> informations about how it use exactly it's memory how to switch in hires
> etc.. I known that I can take the ROM and read instructions sources like
> for Hires, but even if 6502 is not the most difficult assembly to read, it
> will be simpler, if there is documentation about it.
>
> I try poking hires code (50/60hz) to some area (like the first character
> on line 0, col 0) but nothing will make something like HIRES do.
You may get a lot of answers from Geoff Phillips book. You can download it
from his website. The link is on my Links Page www.48katmos.freeuk.com
After that the Advanced User Guide may help with its ROM disassembly. You
can get that from Amazon.co.uk. and then there is the Hicks book Getting
More from Your Oric may also be useful. It turns up on Ebay occasionally.
Steve M
Andre Majorel
> I found a lot of documentation about the 6502, or some about the VIA,
> or any chips that are standard, but the ULA there is no real
> information (execpt some timing or things electrical functions) but I
> didn't found any informations about how it use exactly it's memory how
> to switch in hires etc..
For the ULA each byte in the video RAM has two functions :
- determines the colour of the next six pixels,
- potentially interpreted as a command.
If the value of the byte is between 00h and 1Fh or 80h and 9Fh,
it is a command (an "attribute").
- 00..07 (0000 0ccc) change the foreground colour to 0..7,
- 08..0F (0000 1bdc) change the charset (c), double height (d)
and blink (b) attributes
- 10..17 (0001 0ccc) change the background colour to 0..7,
- 18..1F (0001 1hfx) switch to hires (h = 1) or text (h = 0) and
50 (f = 1) or 60 Hz (f = 0).
For bytes 00h..1Fh, the colour of the next six pixels is the
background colour. Byte values 80h..9Fh have the same effect
except that they are rendered as inverse video, i.e. the colour
of the next six pixels is 7 minus the background colour.
Switching to hires mode takes effect on the next byte. You can
switch to hires in the middle of a text line : the part of the
line before the command will be rendered as text and the part of
the line after the command will be rendered as graphics. If the
bytes that follow do not contain a command to switch back to
text, the following raster lines will also be rendered as
graphics unless the ULA reaches line 200. The last 24 raster
lines are always rendered as text, regardless of the current
mode. The first byte of the next frame will be rendered as
graphics, however, because the ULA "remembers" it is in hires
mode from one frame to the next.
An additional complication comes from the fact that the ULA uses
different addresses for the video RAM depending on the mode. In
text mode, the first byte of raster line y is at BB80h + 40 x (y
/ 8). In hires mode, it is A000h + 40 x y. The same goes for
character data (B400h/B800h in text mode, 9800h/9C00h in hires
mode).
For example, assuming the ULA is in text mode and about to start
rendering a frame, suppose you poke 1Eh at BB81h.
The first address the ULA reads is BB80h. That takes care of the
first six pixels of the first raster line.
The second address the ULA reads is BB81h. This is a command so
the next six pixels are background pixels. The ULA switches
to hires mode.
The next byte the ULA reads is not BB82h but A002h because the
ULA is now in hires mode. Any garbage there is between A002h and
BF3Fh will be displayed as graphics, or interpreted as commands
as the case may be. Chances are somewhere in there will be a
command that switches back to text mode, giving you a
half-hires, half-text display. That's why you want to fill
A000h-BF3Fh with non-command byte values before switching to
hires. The HIRES routine in the ROM fills that area with 40h
bytes (0100 000 = six background pixels).
And don't forget to copy the character data in B400h..BB7Fh to
9800h or the three lines of text at the bottom will look funny.
Hope this helps somewhat. Holler if it's not clear (I'd be
surprised if it was).
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: ak...@aberrate.com efa...@affidavit.com)
"I drink, I smoke, I gamble, I chase girls--but postal chess is
one vice I don't have." -- Mikhail Tal
Andre Majorel
> "Manoël Trapier" <godzil at godzil net> wrote >
>
>> any chips that are standard, but the ULA there is no real information
>
> from his website. The link is on my Links Page www.48katmos.freeuk.com
>
> After that the Advanced User Guide may help with its ROM disassembly. You
> can get that from Amazon.co.uk. and then there is the Hicks book Getting
> More from Your Oric may also be useful. It turns up on Ebay occasionally.
And of course the bible, "L'Oric à nu" by Fabrice Broche.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: adis...@cofactor.com ob...@clubhouse.com)
Manoël Trapier
>
> You may get a lot of answers from Geoff Phillips book. You can download it
> from his website. The link is on my Links Page www.48katmos.freeuk.com
>
> After that the Advanced User Guide may help with its ROM disassembly. You
> can get that from Amazon.co.uk. and then there is the Hicks book Getting
> More from Your Oric may also be useful. It turns up on Ebay occasionally.
>
Ok thank you, I found (elsewhere) this book thanks, It will be helpfull
On 2008-02-05 08:23:53 +0100, Andre Majorel <che...@halliburton.com> said:
>
> And of course the bible, "L'Oric ą nu" by Fabrice Broche.
It seems difficult to find.. But if found it, I will without hesitation
take it :-)
On 2008-02-05 01:36:26 +0100, Andre Majorel <che...@halliburton.com> said:
> On 2008-02-04, Manoėl Trapier <> wrote:
>
>> I found a lot of documentation about the 6502, or some about the VIA,
>> or any chips that are standard, but the ULA there is no real
>> information (execpt some timing or things electrical functions) but I
>> didn't found any informations about how it use exactly it's memory how
>> to switch in hires etc..
>
> For the ULA each byte in the video RAM has two functions :
> - determines the colour of the next six pixels,
> - potentially interpreted as a command.
>
> If the value of the byte is between 00h and 1Fh or 80h and 9Fh,
> it is a command (an "attribute").
> - 00..07 (0000 0ccc) change the foreground colour to 0..7,
> - 08..0F (0000 1bdc) change the charset (c), double height (d)
> and blink (b) attributes
> - 10..17 (0001 0ccc) change the background colour to 0..7,
> - 18..1F (0001 1hfx) switch to hires (h = 1) or text (h = 0) and
> 50 (f = 1) or 60 Hz (f = 0).
Ho, I didn't think to present this like this! Thanks!
>
> For bytes 00h..1Fh, the colour of the next six pixels is the
> background colour. Byte values 80h..9Fh have the same effect
> except that they are rendered as inverse video, i.e. the colour
> of the next six pixels is 7 minus the background colour.
So if bit 8 or 7 are set to 1, the foreground and background color a
reversed? So if I am correct, thats the way the BASIC rom use to blink
the cursor ?
>
> Switching to hires mode takes effect on the next byte. You can
> switch to hires in the middle of a text line : the part of the
> line before the command will be rendered as text and the part of
> the line after the command will be rendered as graphics. If the
> bytes that follow do not contain a command to switch back to
> text, the following raster lines will also be rendered as
> graphics unless the ULA reaches line 200. The last 24 raster
> lines are always rendered as text, regardless of the current
> mode. The first byte of the next frame will be rendered as
> graphics, however, because the ULA "remembers" it is in hires
> mode from one frame to the next.
Humm I start to understand where I get false..
>
> An additional complication comes from the fact that the ULA uses
> different addresses for the video RAM depending on the mode. In
> text mode, the first byte of raster line y is at BB80h + 40 x (y
> / 8). In hires mode, it is A000h + 40 x y. The same goes for
> character data (B400h/B800h in text mode, 9800h/9C00h in hires
> mode).
>
> For example, assuming the ULA is in text mode and about to start
> rendering a frame, suppose you poke 1Eh at BB81h.
>
> The first address the ULA reads is BB80h. That takes care of the
> first six pixels of the first raster line.
>
> The second address the ULA reads is BB81h. This is a command so
> the next six pixels are background pixels. The ULA switches
> to hires mode.
>
> The next byte the ULA reads is not BB82h but A002h because the
> ULA is now in hires mode. Any garbage there is between A002h and
> BF3Fh will be displayed as graphics, or interpreted as commands
> as the case may be. Chances are somewhere in there will be a
> command that switches back to text mode, giving you a
> half-hires, half-text display. That's why you want to fill
> A000h-BF3Fh with non-command byte values before switching to
> hires. The HIRES routine in the ROM fills that area with 40h
> bytes (0100 000 = six background pixels).
Ok, by the way it make me think about (maybe) a silly question, but If
I understand well the ALU work on a scanline basis even in textmode ?
So if we do 'nasty' things in sync with the scanlines, we can modify
some attributes and render text with a different color for each line of
pixel ? :-D
Sounds funny!
>
> And don't forget to copy the character data in B400h..BB7Fh to
> 9800h or the three lines of text at the bottom will look funny.
Yes that's right :-D
>
> Hope this helps somewhat. Holler if it's not clear (I'd be
> surprised if it was).
It was a bit unclear, but there are some of the informations that I
already known and anyway I think I understand what I wanted to known.
Big thanks to you :-)
Manoel
Andre Majorel
> On 2008-02-05 01:36:26 +0100, Andre Majorel <che...@halliburton.com> said:
>> For bytes 00h..1Fh, the colour of the next six pixels is the
>> background colour. Byte values 80h..9Fh have the same effect
>> except that they are rendered as inverse video, i.e. the colour
>> of the next six pixels is 7 minus the background colour.
>
> So if bit 8 or 7 are set to 1, the foreground and background color a
> reversed?
The Oric is an 8-bit byte machine and bits are numbered from 0
so there is no bit 8. :-) If bit 7 is set, both foreground and
background pixels have their colour inverted, yes.
> So if I am correct, thats the way the BASIC rom use to blink
> the cursor ?
Correct. Try setting the foreground and background to non-
complementary colours, for example PAPER 4 : INK 6 (4 + 6 != 7).
The background is dark blue, the foreground is cyan. Move the
cursor over a character. The character appears red (the
complementary of cyan) on yellow (the complementary of dark
blue).
> Ok, by the way it make me think about (maybe) a silly question, but If
> I understand well the ALU work on a scanline basis even in textmode ?
Absolutely. In text mode, each address in the video ram is
scanned 8 times (because characters are 8 pixel high).
> So if we do 'nasty' things in sync with the scanlines, we can modify
> some attributes and render text with a different color for each line of
> pixel ? :-D
In theory, yes. Unfortunately, the Oric lacks any way to sync to
the horizontal or vertical retrace (no vertical blanking IRQ).
You would have to tweak your routine so that it executes in
exactly the same number of cycles it takes for the ULA to output
a scan line. That's 64, if I recall correctly.
> It was a bit unclear, but there are some of the informations that I
> already known and anyway I think I understand what I wanted to known.
It can be a bit much to wrap your head around.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: uby...@whitehorse.com se...@befogging.com)
Andre Majorel
> On 2008-02-06, Manoël Trapier <godz...@yahoo.fr> wrote:
>
>> Ok, by the way it make me think about (maybe) a silly question, but If
>> I understand well the ALU work on a scanline basis even in textmode ?
>> some attributes and render text with a different color for each line of
>> pixel ? :-D
>
> In theory, yes. Unfortunately, the Oric lacks any way to sync to
> the horizontal or vertical retrace (no vertical blanking IRQ).
> You would have to tweak your routine so that it executes in
> exactly the same number of cycles it takes for the ULA to output
> a scan line. That's 64, if I recall correctly.
Note that you don't have to rely on timing. The serial nature of
the ULA allows you to do the same thing statically. One
attribute in the text video RAM to switch to hires. Two
attributes at the right place in the hires video RAM to change
the foreground colour and switch back to text.
100 C = 1
110 FOR TL = 0 TO 24 ' EACH TEXT LINE
120 TA = #BB80 + 40 * TL
130 FOR CL = 0 TO 7 ' EACH SCAN LINE
140 HA = #A000 + 40 * (8 * TL + CL)
150 IF HA >= #B500 THEN PRINT "ABOUT TO CLOBBER CHARGEN, STOP !" : END
160 POKE HA + 2, #1A ' SWITCH TO TEXT
170 POKE HA + 1, C ' FOREGROUND CLR
180 C = C + 1
190 IF C > 7 THEN C = 1
200 NEXT
210 POKE TA, #1E ' SWITCH TO HIRES
220 NEXT
These are the addresses the ULA will read :
BB80=1E A001=01 A002=1A BB83=xx ... BBA7=xx # Text line 0, scan line 0
BB80=1E A029=01 A02A=1A BB83=xx ... BBA7=xx # Text line 0, scan line 1
BB80=1E A051=01 A052=1A BB83=xx ... BBA7=xx # Text line 0, scan line 2
BB80=1E A079=01 A07A=1A BB83=xx ... BBA7=xx # Text line 0, scan line 3
BB80=1E A0A1=01 A0A2=1A BB83=xx ... BBA7=xx # Text line 0, scan line 4
BB80=1E A0C9=01 A0CA=1A BB83=xx ... BBA7=xx # Text line 0, scan line 5
BB80=1E A0F1=01 A0F2=1A BB83=xx ... BBA7=xx # Text line 0, scan line 6
BB80=1E A119=01 A11A=1A BB83=xx ... BBA7=xx # Text line 0, scan line 7
BBA8=1E A141=01 A142=1A BBAB=xx ... BBCF=xx # Text line 1, scan line 8
...
When you understand this, you know more about the ULA that 99%
of Oric programmers did in the day.
That's more than you wanted to know, but I'm having too much fun
to stop. :-)
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: t...@cowhand.com z...@bluebird.com)