HIRES ghost line ?

The Oric video chip is not an easy beast to master, so any trick or method that allows to achieve nice visual results is welcome. Don't hesitate to comment (nicely) other people tricks and pictures :)
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

HIRES ghost line ?

Post by Symoon »

Hi,

The HIRES drawing screen ends in BF3F.
The 3 TEXT lines at the bottom range from BF68 to BFE0.

What happens between BF40 and BF67? Is this wasted RAM space?
Is this line invisible because something like it holds an attribute to switch from HIRES to TEXT?
Do you think thiese bytes can be used to store some routine, knowing it might be affected by TEXT/HIRES/CLS commands?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: HIRES ghost line ?

Post by Dbug »

That's actually a very good question.

I've not tested, but I would assume that these 40 bytes are free to use, like the bytes from BFE0 to BFFF :)
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: HIRES ghost line ?

Post by Symoon »

Dbug wrote: Thu May 24, 2018 3:12 pm I've not tested, but I would assume that these 40 bytes are free to use, like the bytes from BFE0 to BFFF :)
It seems so! It's initialized as the following TEXT lines, just not displayed. This rings a bell with one of your pages where you explain the TEXT/HIRES mix mode and in an example, the higher line of the TEXT characters is not displayed by the ULA.

Anyway, 40 bytes available! In Hires mode only though...
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: HIRES ghost line ?

Post by Symoon »

Actually that's funny. That means that by adding and saving a JMP $BF40 right before the Hires screen (in 9FFD), you can make a Hires screen self-executing some code. For instance loading the next part, which avoids a small loader.
Other option, adding this JMP at the start of the Hires screen (4C 40 BF in $A000) only displays a small glitch of two white pixels (that you can fix when executing the code in $BF40) and leaves the rest of the 1st line black.

I tried to fix the glitch with attibutes (10 00 for black paper and ink translating into BPL 00 which is neutral), but 40 and BF are graphically the exact opposite so when one is invisibe, the other appears in inverse video mode ;)
User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: HIRES ghost line ?

Post by NekoNoNiaow »

What an interesting coincidence that this space is exactly one text mode line long.

I wonder if this has to do with how the video scanning addresses are generated by the ULA.
Do mi-screen mode changes modify the behavior of the address generation? That is, do HIRES and TEXT addresses continue to increment normally even when changing mode mid screen or are there additional offsets added at each switch?

It could also be that the machine designers initially wanted to have 4 lines of text at the bottom of the screen but realized that this would be too many pixels to render, and that it was simpler for them to simply insert an adder of +40 Into the address generator at the hardware HIRES/TEXT boundary than to modify the circuitry dedicated to determining the end of address generation. Intuitively, though, this seems like this would have been harder but maybe the ULA was so badly designed that this was a simpler solution.;)
Symoon wrote: Fri May 25, 2018 1:09 am Actually that's funny. That means that by adding and saving a JMP $BF40 right before the Hires screen (in 9FFD), you can make a Hires screen self-executing some code. For instance loading the next part, which avoids a small loader.
Other option, adding this JMP at the start of the Hires screen (4C 40 BF in $A000) only displays a small glitch of two white pixels (that you can fix when executing the code in $BF40) and leaves the rest of the 1st line black.
I do not understand what would be gained by using these 40 bytes as code rather than as simply for data. Could you elaborate on the advantages of jumping to these 40 bytes? I kinda like the idea but I fail to picture how this helps.
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: HIRES ghost line ?

Post by Symoon »

NekoNoNiaow wrote: Fri May 25, 2018 7:03 am
Symoon wrote: Fri May 25, 2018 1:09 am Actually that's funny. That means that by adding and saving a JMP $BF40 right before the Hires screen (in 9FFD), you can make a Hires screen self-executing some code. For instance loading the next part, which avoids a small loader.
Other option, adding this JMP at the start of the Hires screen (4C 40 BF in $A000) only displays a small glitch of two white pixels (that you can fix when executing the code in $BF40) and leaves the rest of the 1st line black.
I do not understand what would be gained by using these 40 bytes as code rather than as simply for data. Could you elaborate on the advantages of jumping to these 40 bytes? I kinda like the idea but I fail to picture how this helps.
That was just me having no-so-good ideas late in the night.
The idea for instance, is a slideshow. If you load a HIRES screen that self-contains the loading command for the next one, then you don't need a loader.
Except you have to be sur to be in Hires mode, so a loader is required anyway for the 1st screen :lol:
User avatar
ibisum
Wing Commander
Posts: 1643
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: HIRES ghost line ?

Post by ibisum »

I like the idea of self-executing image files on Oric! But not just using 40bytes .. what about putting it all in the images too .. ;)
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: HIRES ghost line ?

Post by Symoon »

ibisum wrote: Fri May 25, 2018 1:41 pm I like the idea of self-executing image files on Oric! But not just using 40bytes .. what about putting it all in the images too .. ;)
Yep, having data that can be both drawing and executable code is quite a challenge, but could be done? ;)
User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: HIRES ghost line ?

Post by NekoNoNiaow »

Symoon wrote: Fri May 25, 2018 2:03 pm
ibisum wrote: Fri May 25, 2018 1:41 pm I like the idea of self-executing image files on Oric! But not just using 40bytes .. what about putting it all in the images too .. ;)
Yep, having data that can be both drawing and executable code is quite a challenge, but could be done? ;)
Well, just put these two tables side by side and compare. ;)
6502 opcodes : http://www.oxyron.de/html/opcodes02.html (illegal/undocumented ones use a grey background).
Oric serial attributes (from http://osdk.defence-force.org/index.php ... RT9#title7).

Code: Select all

Byte value | Oric Serial Attributes      | 6502 opcodes (increasing value order)
           |                             | $_0  $_1  $_2  $_3  $_4  $_5  $_6  $_7 
-----------------------------------------------------------------------------------
$00 to $07 | ink color changes           | BRK  ORA  KIL! SLO_ NOP_ ORA  ASL  SLO_ 
$08 to $0F | character set modifiers     | PHP  ORA  ASL  ANC_ NOP_ ORA  ASL  SLO_
$10 to $17 | paper color changes         | BPL  ORA  KIL! SLO_ NOP_ ORA  ASL  SLO_
$18 to $1F | mode change attributes      | CLC  ORA  NOP_ SLO_ NOP_ ORA  ASL  SLO_
$20 to $FF | pixels (0 = paper, 1 = ink) | <way too many to cover>

Legend:
- illegal/undocumented opcodes end in ! or _:
- ! opcodes kill the CPU (power cycle needed)
- _ opcodes are harmless and _can_ produce useful results
This table above does not cover all interrelations between opcodes and Oric graphic attributes but we can still learn a few things from the first 32 ones:
  • All the KIL! opcodes must be avoided at all costs since they stop the CPU dead and require a power off/on cycle.
    This means that one color can never be used for paper nor ink : green (values $02 and $12).
  • There is one branching instructions in the "non pixel" serial attributes: BPL.
    This means that it could be used to allow graphical data which comes right after the branch to be freely used for graphics without restrictions.
    This could be useful to protect some areas of the HIRES ram to not be executed, though the instruction is a conditional so one would need to make sure the negative flag is not set to ensure the branch is taken.
  • The BRK instruction maps directly to "set ink to black" and will obviously jump to the interruption vector so careful modification of the return pointer on the stack could also allow to skip some graphical data untouched.
Overall, the first 32 opcodes do very little: only one conditional branch, BRK but no register loading or storing, so they could be used as graphic data and code without too much damaging consequences as long as the KIL instructions are carefully avoided.

The fact I find the funniest about a mixed code/HIRES screen is that it requires to avoid the green color or to be quite clever with branches to allow it intermittently. :lol:

Now, dealing with pixel data is probably a much more difficult and perilous task. I will leave it to others. ;)
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: HIRES ghost line ?

Post by Symoon »

There are also all the "invert" bytes values that could be used... But I mean, technically it can be achived, but for a human brain this seems a bit complicated ;)
To anyone willing to dig this subject, another way to begin with could be checking existing known HIRES pictures, and see if they already hold some bytes sequences that could be considered as valid executable as code (or could be with little changes not affecting the picture).

Good luck with that :mrgreen:
User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: HIRES ghost line ?

Post by NekoNoNiaow »

Symoon wrote: Sun May 27, 2018 8:00 am There are also all the "invert" bytes values that could be used... But I mean, technically it can be achived, but for a human brain this seems a bit complicated ;)
To anyone willing to dig this subject, another way to begin with could be checking existing known HIRES pictures, and see if they already hold some bytes sequences that could be considered as valid executable as code (or could be with little changes not affecting the picture).

Good luck with that :mrgreen:
Finding actionable executable code inside arbitrary data - here an Oric HIRES picture, is actually a technique commonly applied in Return Oriented Programming (ROP: see this for an example and the Wikipedia ROP page for the general explanation).

There are already tools used to find and extract usable pieces of code inside some existing executable code that one can chain to execute almost any possible action (as long as the existing data offers enough variety) and they would just need to be adapted slightly to look for usable 6502 sequences of instructions inside Oric graphic data. ;)

Doing it manually would indeed be quite maddening. :lol:
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: HIRES ghost line ?

Post by Symoon »

Back to the "ghost line"... I was thinking it could be used to save/restore, on ROM 1.0, the line that is destroyed by the status line (displayed in the middle of the HIRES screen, when Loading/saving for instance).
This brought a thought... Could all this be the remains of an old memory map?

I mean, imagine this map, compared to the real map:

Code: Select all

40000-47999    HIRES screen         

48000-48039    Status line
                (our "ghost line", hidden in Hires so status messages don't appear!)

48040-49119    TEXT screen
                (only 3 lines visible in HIRES)
This would explain the ROM 1.0 status line display bug in HIRES: initially, the line right after the HIRES screen would have been hidden by the ULA in HIRES, thus hiding the status line, so there was no need to handle the status line display in HIRES.

But after the ULA was designed, they decided to change the memory map, to avoid wasting the unused TEXT memory in HIRES, or HIRES memory in TEXT. So they implemented the moving of the whole HIRES display and chars areas according to the display mode.

Consequences: the "ghost line", managed by the ULA, couldn't be changed and remained after the HIRES screen, useless... And here comes the statuts line display bug in HIRES!

Does it make sense?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: HIRES ghost line ?

Post by Dbug »

I've stopped trying to figure out how they came up with a bunch of ideas in the machine, mostly because I don't know enough about the background story, how they designed stuff, the budget constraints, etc...
Post Reply