🚀 go-pugleaf

Dave Sparks  wrote:
> >>>>> "DB" == Dave Beames <dave@beames.demon.co.uk> writes:
>
>   DB> I've just started trying to un-cripple a small text editor

>   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

Sorry for the delay -- I've been away for 4 days.

This was exactly (most of) what I needed to know :-)

Dave Sparks wrote:
> >>>>> "DB" == Dave Beames <dave@beames.demon.co.uk> writes:
>
>  DB> Dave Sparks wrote:
>   >> >>>>> "DB" == Dave Beames <dave@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

In article <200005152120.0psp@beames.demon.co.uk>, Dave Beames
<dave@beames.demon.co.uk> writes
>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.

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

Dave Sparks (Dave.Sparks.doesnt-want-junk-mail.$@sisyphus.demon.co.uk) wrote:
> >>>>> "DB" == Dave Beames <dave@beames.demon.co.uk> writes:
>
>   DB> Can anyone PLEASE tell me what the instruction MOVE.L #$258,$20(A0)
>   DB> would look like in hex after assembly?
>
> After assembling and disassembling two lines of code:
>
>	 217C 0000 0258 0020   MOVE.L #00000258,0020(A0)
>
>	 217C 0140 0000 0020   MOVE.L #01400000,0020(A0)
>
> (I would have looked it up in the book, but assembly/disassembly
> was quicker and more reliable.)

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