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.
Atmos:
Oric-1:
LORES: different between ROM 1.0 and ROM1.1?
- mikeb
- Flight Lieutenant
- Posts: 282
- Joined: Wed Sep 05, 2018 8:03 pm
- Location: West Midlands, UK
- Contact:
Re: LORES: different between ROM 1.0 and ROM1.1?
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.
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?
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.
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.
- mikeb
- Flight Lieutenant
- Posts: 282
- Joined: Wed Sep 05, 2018 8:03 pm
- Location: West Midlands, UK
- Contact:
Re: LORES: different between ROM 1.0 and ROM1.1?
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.
ATMOS
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.
ORIC:
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)
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.
ATMOS
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.
ORIC:
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)