I've just started trying to un-cripple a small text editor that I want to
use (with, I repeat, the written permission of the author).
My expertise in this matter is zilch -- it isn't something I've wanted to
do before :-)
The crippling consists only of a ten-minute time-out, after which the
program allows me to save before quitting.
Can anyone suggest how the author does it, please?
It can't be a simple counter, cos it was (presumably) written for 68000,
and still takes ten mins on my 68060.
The obvious (to me) way is to look at the clock. I've tried starting off
an edit, then putting the clock forward 9 mins to see if it dies after
another min (are you with me?), but it still takes 10 elapsed minutes.
Am I misunderstanding how the clock works? Or is there a way of counting
the ticks?
I'm still on WB3.0, and I don't have the expensive books, so I don't know
what's in what library. I know the ordinary clock-read function is (or
was) in dos.library, but he doesn't seem to open that. Is it opened
automatically by the system? If so, where's the pointer to it, and does
anyone know the offset(s) for the clock function(s)?
Any suggestions gratefully received, as always.
DaveB
> DB> I'm still on WB3.0, and I don't have the expensive books, so I don't
> DB> know what's in what library. I know the ordinary clock-read function
> DB> is (or was) in dos.library, but he doesn't seem to open that. ...
>
> He probably uses the timer device, which counts either vertical
> blanking intervals or the 8520 timer. VBLANK would be the more
> sensible choice, except that the time interval would then be
> affected if you use a graphics card.
I *do* use CyberVision. But the ordinary video port is still operable,
bypassing the CV -- won't the "old" blanking still be available?
> Look for 'timerequest' and 'TR_ADDREQUEST'. The timer event would
> be requested by a 'DoIO'. Commenting out the 'DoIO' call would then be
> enough to disable the timer.
>
> Does the code have any comments in it?
Er ... all I have is the binary, disassembled.
That's why I asked about offsets, so that I could look for lines like
JSR -<offset>(An)
I know where he puts the pointers to all the libraries that he opens, so I
can tell which library he's looking at with each JSR, so if I knew the
actual offset value for (eg) the "what's the time" routine, I could easily
find where he called it from. Except that he doesn't open dos.library, as
I said.
But you seem to be suggesting that he's not using library routines at all.
What would the sort of thing that you are suggesting look like in
assembler? Or isn't that a meaningful question :-(
Thanks for taking an interest. You may regret it :-)
DaveB
This was exactly (most of) what I needed to know :-)
Dave Sparks wrote:
> >>>>> "DB" == Dave Beames <da...@beames.demon.co.uk> writes:
>
> DB> Dave Sparks wrote:
> >> >>>>> "DB" == Dave Beames <da...@beames.demon.co.uk> writes:
> >>
> DB> I've just started trying to un-cripple a small text editor
>
> >> Does the code have any comments in it?
>
> DB> Er ... all I have is the binary, disassembled.
>
> That does make things rather difficult.
>
> You need to look for a call to OpenDevice (execbase-1bc) where A0
> contains the address of a string "timer.device". Note where A1 is
> pointing when this call is made - this is the timer request block.
OK, found those.
> The you need to find the call to DoIO (execbase-1c8) where this
> request block (or a copy of it :( ) is used to set up the time
> request.
This is strange. There is only *one* occurrence of "-$1C8" in the whole
(disassembled) program, and that doesn't use 4 as an address. I wondered
if it might be a copy of 4, but I've tried to trace the palce where he
set tha address up, and it ain't simple.
> CMD_NONSTD (9) will have been moved to the 16-bit word
> at offset 94 (decimal) of the structure, and the time interval in
> seconds will have been moved to the 32-bit word at offset 98 (I
> don't guarantee that these offsets have been calculated
> correctly).
The offsets seem to be $1C & $20 (dec 28 & 32), but apart from that it
appears as you say. He puts the addr of the request block in A0, then
MOVE.W #$9,$1C(A0) and MOVE.L #$258,$20(A0)
$258 is 600 (10 mins), so it seems that he's doing it with a literal,
which *should* make it easy for me.
> Patch out this DoIO call, and hope for the best.
As I said, I can't find one. Maybe the disassembler got confused. Maybe
it doesn't matter.
> Try changing the timeout to 20971520 seconds, or thereabouts.)
I don't know how many bits I'm allowed to do with a literal, but even
FFFF should serve my purpose adequately -- I don't often do edits for
more than 18 hours :-)
But now I've hit a wall.
I have a "guide" to 68K assembler, but though it tells me what all the
instructions are and how to use them, the damn thing says nothing
whatsoever about what they look like after assembly.
So, I know that the instruction that I need to alter is the MOVE.L above,
and that it occurs approx halfway between F11C and F1B8, but my
disassembler *only* gives addresses which are addressed (IYSWIM), so I
don't know the addresses of the individual instructions between those two
labels. I've looked at the area with NewZAP till I'm blue in the face,
but I can't see anything helpful.
Can anyone PLEASE tell me what the instruction MOVE.L #$258,$20(A0) would
look like in hex after assembly?
> Since OpenLibrary is in exec.library , exec.library can't be
> opened (its base address has to be fetched from absolute address
> 4). Apart from this, exec.library follows all the normal calling
> conventions.
Of course. I knew 4 held something important, but forgot what.
Many thanks -- I'm nearly there :-)
DaveB
You want a program called deksid. It works like newzap - allows you to
view the contents of a file in hex/ascii and alter them plus it has a
built-in disassembler which will decode the instruction at the cursor.
It also lets you search for ascii/hex within the file.
Aminet:
Deksid210.lha disk/moni 92K 324 Deksid 2.10 - Disk/File editor
--
Chris Sumner
I'd have done that if I'd had an assembler :-)
But I haven't -- nor a book that actually works.
This leaves me looking even sillier than usual.
I'd searched everywhere (with NewZAP) for hex 258, and hadn't found it,
which is why I asked what the assembled instr would look like -- after
all, for all I knew the 258 might have been offset 1 or 2 or 3 bits.
What I *didn't* know was that NewZAP insists on being asked for 0258.
This strikes me as unreasonable -- the search requester says clearly that
it is looking for hex, not bytes, so *why* does it insist on bytes?
Never mind .... :-)
Many thanks, Dave, all fixed now, and it works. I still need to get rid
of a startup requester asking me to register, but that can wait.
Thanks, too, to Chris for the Deksid suggestion. It's quite good, isn't
it, with the built-in converter an' all. A bit fragile -- click in the
wrong place and it hangs -- but worth keeping alongside NewZAP.
Cheers ... DaveB