log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Drag'N'Drop Autumn edition now available (News:)
- !DualHead puts 2 screens in one (News:)
- RISC OS London Show 2017 - Notes from the talks (News:6)
- November News (News:)
- !Organizer 2.28 reviewed (News:2)
- !OBrowse reviewed (News:10)
- Aemulor (Gen:16)
- DDE reaches release 28 and above (News:)
- Elesar quicks dispels stormy clouds (News:2)
- RISC OS London Show 2017 (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
The Icon Bar: Programming: Software vectors
 
  Software vectors
  sirbod (09:35 25/4/2012)
  Phlamethrower (12:56 25/4/2012)
    sirbod (14:13 25/4/2012)
      Phlamethrower (14:23 25/4/2012)
        sirbod (14:35 25/4/2012)
          qUE (23:18 25/4/2012)
            sirbod (05:14 26/4/2012)
              qUE (11:29 26/4/2012)
      gerph (19:05 13/9/2012)
        sirbod (19:40 13/9/2012)
          gerph (14:02 14/9/2012)
            sirbod (21:12 14/9/2012)
    sirbod (11:04 10/5/2012)
      Phlamethrower (12:28 10/5/2012)
        sirbod (12:46 10/5/2012)
 
Jon Abbott Message #120190, posted by sirbod at 09:35, 25/4/2012
Member
Posts: 563
How do you find out where a software vector is currently pointing and it's R12 value?

I've come across a watermark protection module that hijacks all the IO vectors, removing the watermark as IO is performed. The trouble is, it doesn't check where the file is coming from, so all HD IO is corrupt on reads.

This screws up in-game disc changing in ADFFS, so I need to check for this and temporarily re-instate the original vector claimant before performing any IO to the HD.

I can use OS_AddToVector / OS_Release to re-instate, but how do I find out the values to pass?

Vectors in question are:

FileV - OS_File
ArgsV - OS_Args
BPutV - OS_BPut
GBPBV - OS_GBPB
FindV - OS_Find
  ^[ Log in to reply ]
 
Jeffrey Lee Message #120192, posted by Phlamethrower at 12:56, 25/4/2012, in reply to message #120190
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
There's no official way of finding out where a vector is currently pointing. However, you probably could peek/poke the vector claimant list directly.

The base of the vector claimant table is at &7D8. The table is indexed by the vector number, and each table entry is three words long (next ptr, workspace ptr, code ptr). For vectors with multiple claimants you just follow the 'next' ptr to get to the next three-word entry (which would be allocated from some heap block somewhere). The next ptr will be null once you've reached the end of the list.

Obviously the above information is subject to change in later OS versions smile
  ^[ Log in to reply ]
 
Jon Abbott Message #120194, posted by sirbod at 14:13, 25/4/2012, in reply to message #120192
Member
Posts: 563
Thanks for the useful info. I'm a bit loathed to code something that's almost guaranteed to break at some point! laugh

Another glaring OS omission! I think we need an SWI for this in the OS and a module for backward compatibility to keep it clean - CallASWI style.

It should probably even go into CallASWI as the software vectors are mostly SWI related.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #120195, posted by Phlamethrower at 14:23, 25/4/2012, in reply to message #120194
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
Another glaring OS omission! I think we need an SWI for this in the OS and a module for backward compatibility to keep it clean - CallASWI style.
But under what situations would a program need to know what the claimants of a particular vector are? The problem you're facing isn't a deficiency in the vector claim/release system, it's a deficiency in the nasty hacky copy protection which people have been putting on their code. And if the OS had an easy way of examining the software vectors, which makes it easy to bypass the copy protection, then the software authors would have just found some nastier way of protecting their code instead.
  ^[ Log in to reply ]
 
Jon Abbott Message #120196, posted by sirbod at 14:35, 25/4/2012, in reply to message #120195
Member
Posts: 563
I think the point I'm making is that the OS provides methods to claim, release and add to - but no complimentary way of asking who the current claimant is.

Agree, its unlikely it would be used much - but that's not the point.
  ^[ Log in to reply ]
 
qUE Message #120197, posted by qUE at 23:18, 25/4/2012, in reply to message #120196
qUE

Posts: 168
If you're just trying to poach a call from an OS Vector, AddToVector should insert your routine before the existing routine, and they get chain called.

If you're trying to wedge a routine before the floppy handler, you'll need to change the hardcoded FIQ Vector entry at the start of memory (&1C) and then call the existing routine at the end of yours and hope it returns properly (it should). But be careful, IIRC the FIQ routine actually exists at &1C rather than it being a jump to it, so you'll need to grab what ever mnemonic at &1C, replace it with a jump to your routine and stick that mnemonic (probably STMFD r13!) at the end of your routine and then jump back to &20.

Would probably be best to test if the mnemonic at &1C is either an LDR pc/MOV pc/ADR or something else and take action appropriately.

It would probably be easier to add an instance into the Filecore and feed it the info it's expecting mind.


[Edited by qUE at 00:21, 26/4/2012]
  ^[ Log in to reply ]
 
Jon Abbott Message #120198, posted by sirbod at 05:14, 26/4/2012, in reply to message #120197
Member
Posts: 563
I need to do the following:

1. Store the values of all software IO Vectors needed to load a disc when asked - via * command probably.

When a disc change is scheduled in-game:
2. Check if any these vectors have been modified, reinstate any that have via OS_AddToVector
3. Perform the disc load
4. Remove any vector(s) we modified via OS_Release
5. Exit back to game

As there's no official way to perform (1), I'll have to hardcore it as Jeffrey has suggested - the risk being, it may break with a future OS.
  ^[ Log in to reply ]
 
qUE Message #120202, posted by qUE at 11:29, 26/4/2012, in reply to message #120198
qUE

Posts: 168
I need to do the following:

1. Store the values of all software IO Vectors needed to load a disc when asked - via * command probably.

When a disc change is scheduled in-game:
2. Check if any these vectors have been modified, reinstate any that have via OS_AddToVector
3. Perform the disc load
4. Remove any vector(s) we modified via OS_Release
5. Exit back to game

As there's no official way to perform (1), I'll have to hardcore it as Jeffrey has suggested - the risk being, it may break with a future OS.
Why not emulate the ADF image as something like IDEFS, then get the user to merge the floppies with the HD merge util normally supplied with games. That way you'd eliminate the need to swap disc entirely.

Cus' you'll have hell of a job trying to figure out if a game is just loading from disc or checking for a disc change, since most games will just look for a certain entry on the disc whether it be label, folder or file.

P.S. Disc change indicator is unreliable on floppy drives since the IR sensor gets gunked up over time and says the disc is always there.

[Edited by qUE at 12:31, 26/4/2012]
  ^[ Log in to reply ]
 
Jon Abbott Message #120319, posted by sirbod at 11:04, 10/5/2012, in reply to message #120192
Member
Posts: 563
The base of the vector claimant table is at &7D8. The table is indexed by the vector number, and each table entry is three words long (next ptr, workspace ptr, code ptr).
Is this documented anywhere? In the source code perhaps?

I'm looking at the table and it doesn't look like three words per entry, it also seems to start at &790 and there's not enough entries for the official 36 (RISC OS 3 PRM's) software vectors.

EDIT: Looking at Kernel/s/ArthurSWIs "CallVector", its one word pointer per entry at "VecPtrTab" pointing to three words (R10, R12, PC)... I'm manually counting the bytes to figure out what VecPtrTab is, as the table (Kernel/hdr/KernelWS) is dynamic. I note the address will change if the kernel is a debug build indiff

[Edited by sirbod at 12:34, 10/5/2012]
  ^[ Log in to reply ]
 
Jeffrey Lee Message #120326, posted by Phlamethrower at 12:28, 10/5/2012, in reply to message #120319
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
Is this documented anywhere? In the source code perhaps?
If it was documented I probably wouldn't have got it wrong when I described it to you wink

I'm manually counting the bytes to figure out what VecPtrTab is, as the table (Kernel/hdr/KernelWS) is dynamic. I note the address will change if the kernel is a debug build indiff
Hmm, really? The DebugTools module seems to assume it's at &7D8. I think I've used it to look at vectors in the past without any issues. However the VecPtrTab location has never been "officially" exported via Kernel/hdr/PublicWS, so it's possible that it has changed location over the years (either before or after DebugTools came to be).
  ^[ Log in to reply ]
 
Jon Abbott Message #120329, posted by sirbod at 12:46, 10/5/2012, in reply to message #120326
Member
Posts: 563
Hmm, really? The DebugTools module seems to assume it's at &7D8. I think I've used it to look at vectors in the past without any issues. However the VecPtrTab location has never been "officially" exported via Kernel/hdr/PublicWS, so it's possible that it has changed location over the years (either before or after DebugTools came to be).
Assumption...the mother of all f**k ups!

Looking at the Kernel header, there are several variable length areas above VecPtrTab - so it wouldn't surprise me if it changes build to build. It also changed locations in '91 according to the header above it - I'm guessing that was with RISC OS 3.

EDIT: You were correct, it turns out to be &7D8. Code is working, just need to check if it breaks on later versions of RISC OS

[Edited by sirbod at 16:27, 10/5/2012]
  ^[ Log in to reply ]
 
Justin Fletcher Message #121073, posted by gerph at 19:05, 13/9/2012, in reply to message #120194
Member
Posts: 9
Thanks for the useful info. I'm a bit loathed to code something that's almost guaranteed to break at some point! laugh

Another glaring OS omission! I think we need an SWI for this in the OS and a module for backward compatibility to keep it clean - CallASWI style.

It should probably even go into CallASWI as the software vectors are mostly SWI related.
Setting aside the fact that there are approximately zero times that you need to manipulate the vector table outside of a debugging tool, there /is/ an API for reading such information. OS_ReadSysInfo 6, 23 and 24.

But stop what you're doing immediately and think again, because if you're thinking you need access to the vector table outside of the OS or a debugging tool, you are most likely wrong.
________
--
Gerph
  ^[ Log in to reply ]
 
Jon Abbott Message #121076, posted by sirbod at 19:40, 13/9/2012, in reply to message #121073
Member
Posts: 563
But stop what you're doing immediately and think again, because if you're thinking you need access to the vector table outside of the OS or a debugging tool, you are most likely wrong.
You should probably take a look at ADFFS, to understand where all my questions were coming from.

The above was required to get protection working, that was used on Equilibrium and Pandora's Box. The protection hooks into the IO vectors and descrambles data as its read from the disc.

EDIT: OS_ReadSysInfo is useful info, but only applicable to RO3.8+. This needs to work on RO3.1+

[Edited by sirbod at 20:48, 13/9/2012]
  ^[ Log in to reply ]
 
Justin Fletcher Message #121080, posted by gerph at 14:02, 14/9/2012, in reply to message #121076
Member
Posts: 9
But stop what you're doing immediately and think again, because if you're thinking you need access to the vector table outside of the OS or a debugging tool, you are most likely wrong.
You should probably take a look at ADFFS, to understand where all my questions were coming from.
No thank you. If you want a question answered, provide the necessary information rather than requiring responders to hunt for what your real intention is.

The above was required to get protection working, that was used on Equilibrium and Pandora's Box. The protection hooks into the IO vectors and descrambles data as its read from the disc.

EDIT: OS_ReadSysInfo is useful info, but only applicable to RO3.8+. This needs to work on RO3.1+
If you only need it to work on RO3.1 then it's not a problem to use the fixed address. If you want the software to work on anything after RO3.5 you need to start using the correct calls and removing any special reliance on 'knowing' how things work. Remove the protection completely and then you don't need to work around it in awkward ways on future systems.

In particular the vector tables DO NOT BELONG TO YOU. They're owned by the kernel, and shouldn't be manipulated without knowing everything about how they are used and what they do - and you can guarantee that they may change between versions both in address and implementation. Removing any reliance on knowledge about such systems should be the goal of any protection removal. Making legacy software work on more modern versions of the system is a laudable goal, but you should do it in a way that they work with modern systems and continue to do so long after you've finished.

If you don't want to take my advice then that's up to you, but there's a small amount of 'been there, done that' to my comments. Honest.
________
--
Gerph
  ^[ Log in to reply ]
 
Jon Abbott Message #121084, posted by sirbod at 21:12, 14/9/2012, in reply to message #121080
Member
Posts: 563
You should probably take a look at ADFFS, to understand where all my questions were coming from.
No thank you. If you want a question answered, provide the necessary information rather than requiring responders to hunt for what your real intention is.
Quite, hence the opening question. Jeffrey answered it, there is no way to find out where a vector is currently pointing without directly looking at the vector table.

Unfortunately, the OS extension to find the vector table address is only in the ROL branch and doesn't exist in prior or later branches. The workaround I used in the end, was to setup an environment variable in !Boot, with the address of the vector table. This way it can easily be changed between OS versions.

My preference would have been to add an SWI to the OS and code a backward compatible module for previous OS, but as has already been pointed out, there aren't many requirements to find out where a vector is currently pointing.
  ^[ Log in to reply ]
 

The Icon Bar: Programming: Software vectors