Page 1 of 1

LORES: different between ROM 1.0 and ROM1.1?

Posted: Thu Jul 18, 2019 3:16 am
by Symoon
Maybe this has been spotted and discussed before, but anyway... Did anyone notice that LORES 1 modes, which display the 2nd character set, have a different shape between Oric-1 and Oric Atmos?
Noticed that when testing an unknown little game which runs in LORES.
Lores1_Atmos.png (1.05 KiB) Viewed 4043 times
Lores1_Oric1.png (1.04 KiB) Viewed 4043 times

Re: LORES: different between ROM 1.0 and ROM1.1?

Posted: Thu Jul 18, 2019 5:57 pm
by mikeb
Yes, this is a long standing feature :)

The character cells are supposed to be an equal 2 x 3 grid for teletext/viewdata blocks

For Oric this means 3 pixels left, 3 pixels right, as there are only 6 bits in a character that become visible pixels (the other 2 bits are for attributes etc.)

xx 000 000
xx 000 111
xx 111 000
xx 111 111

But I think the routines that generate the codes for Oric-1 forgot this, and used the full 8 bits.

0000 0000
0000 1111
1111 0000
1111 1111

Meaning the shapes onscreen are wrong :-

00 0000
00 1111
11 0000
11 1111

So the left hand lo-res cell is too small, the right hand is too big. Off by one pixel.

Re: LORES: different between ROM 1.0 and ROM1.1?

Posted: Thu Jul 18, 2019 7:34 pm
by Symoon
Ha ha thanks!
What's curious thought, is that the character generation routine seems to be the same for both ROMs ($F7E0 / $F816)? But I've checked quickly, maybe I'm not looking at the right place.

Re: LORES: different between ROM 1.0 and ROM1.1?

Posted: Fri Jul 19, 2019 5:58 pm
by mikeb
No idea how it was fixed, $F263 is the highest address that "Rambling In The ROM" got to in OUM, so that would be where I would look for details.

There must be a subtle difference between the routines (a stray ROL or something) hidden in there that fixes it.

Edit to add: I just compared Leycester Whewell's commented ATMOS ROM disassembly (from the Advanced User Guide) with Bob Maunders un-commented Oric-1 disassembly.

You're right, the routines are the same and are both correct, the problem is GIGO -- Garbage In, Garbage Out.

Code: $F816 to $F860

$F861 Four Data Bytes used by the routine :-
$00 (00 000 000)
$38 (00 111 000)
$07 (00 000 111)
$3F (00 111 111)

These are correct and make allowances for the two first bits being non-visible pixels, so the cells are 3+3 pixels/bits wide.

Code: $F7E0 to $F82A

$F82A Data :-
$00 (00 00 0000)
$F0 (11 11 0000)
$0F (00 00 1111)
$FF (11 11 1111)

These are wrong, and assume that all bits are treated as visible, simply cleaving the byte into 2 nybbles. I've spaced them to show the 2 bits left, 4 bits right offset.

The fix for Oric, (as a post-ROM generation, user correction), is to just ROR every location down one bit, and clear the top two bits just for neatness (AND with $03F)