|
|
Acorn Arcade forums: 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 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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  |
| |
[ 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! 
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 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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 |
Posts: 187
|
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 |
Posts: 187
|
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 
[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 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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 
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 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 ] |
| |
|
Charles Justin Ferguson |
Message #121073, posted by gerph at 19:05, 13/9/2012, in reply to message #120194 |
Member
Posts: 48
|
Thanks for the useful info. I'm a bit loathed to code something that's almost guaranteed to break at some point!
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 ] |
| |
|
Charles Justin Ferguson |
Message #121080, posted by gerph at 14:02, 14/9/2012, in reply to message #121076 |
Member
Posts: 48
|
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 ] |
| |
|
Acorn Arcade forums: Programming: Software vectors | |
|
