Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #161224 > unrolled thread

Debugging Adventure using Address Break

Back to article view | Back to alt.folklore.computers

Contents

  Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-19 13:23 +0000
    Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-20 06:46 +1100
      Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-20 13:56 +0000
        Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-21 04:51 +1100
          Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-21 12:24 +0000
            Re: Debugging Adventure using Address Break Morten Reistad <first@last.name.invalid> - 2016-03-21 13:53 +0100
              Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-22 04:23 +1100
                Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-22 13:40 +0000
                  Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-23 05:01 +1100
              Re: Debugging Adventure using Address Break Rob Doyle <radioengr@gmail.com> - 2016-03-22 01:50 -0700
                Re: Debugging Adventure using Address Break Morten Reistad <first@last.name.invalid> - 2016-03-22 13:22 +0100
                Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-22 13:40 +0000
              Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-22 13:40 +0000
                Re: Debugging Adventure using Address Break usenet@only.tnx (Questor) - 2016-03-26 07:32 +0000
            Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-22 04:24 +1100
            Re: Debugging Adventure using Address Break "Charles Richmond" <numerist@aquaporin4.com> - 2016-03-22 10:20 -0500
              Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-23 13:23 +0000
    Re: Debugging Adventure using Address Break scott@slp53.sl.home (Scott Lurndal) - 2016-03-21 13:58 +0000
    Re: Debugging Adventure using Address Break scott@slp53.sl.home (Scott Lurndal) - 2016-03-21 14:00 +0000
      Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-22 13:40 +0000
        Re: Debugging Adventure using Address Break "Charles Richmond" <numerist@aquaporin4.com> - 2016-03-22 10:24 -0500
    Re: Debugging Adventure using Address Break usenet@only.tnx (Questor) - 2016-03-22 07:19 +0000
    Re: Debugging Adventure using Address Break usenet@only.tnx (Questor) - 2016-03-22 07:19 +0000
      Re: Debugging Adventure using Address Break Morten Reistad <first@last.name.invalid> - 2016-03-22 13:20 +0100
      Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-22 13:40 +0000
        Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-23 04:55 +1100
        Re: Debugging Adventure using Address Break usenet@only.tnx (Questor) - 2016-03-26 07:32 +0000
          Re: Debugging Adventure using Address Break Morten Reistad <first@last.name.invalid> - 2016-03-26 09:55 +0100
            Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-26 13:24 +0000
              Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-27 04:11 +1100
                Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-27 13:26 +0000
                  Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-28 04:25 +1100
                  Re: Debugging Adventure using Address Break "Charles Richmond" <numerist@aquaporin4.com> - 2016-03-28 15:58 -0500
                    Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-29 13:55 +0000
                      Re: Debugging Adventure using Address Break Morten Reistad <first@last.name.invalid> - 2016-03-29 17:17 +0200
                        Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-30 13:58 +0000
                      Re: Debugging Adventure using Address Break scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 16:17 +0000
                        Re: Debugging Adventure using Address Break Ahem A Rivet's Shot <steveo@eircom.net> - 2016-03-29 17:57 +0100
                      Re: Debugging Adventure using Address Break Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-29 17:14 +0000
                        Re: Debugging Adventure using Address Break Huge <Huge@nowhere.much.invalid> - 2016-03-29 17:17 +0000
                        Re: Debugging Adventure using Address Break scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 17:48 +0000
                          Re: Debugging Adventure using Address Break Ibmekon <Ibmekon> - 2016-03-29 21:35 +0100
                          Re: Debugging Adventure using Address Break Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-29 23:20 +0000
                            Re: Debugging Adventure using Address Break Andrew Swallow <am.swallow@btopenworld.com> - 2016-03-30 05:33 +0100
                              Re: Debugging Adventure using Address Break "764hho" <764hho@nospam.com> - 2016-03-30 17:23 +1100
                        Re: Debugging Adventure using Address Break Ibmekon <Ibmekon> - 2016-03-29 19:28 +0100
                          Re: Debugging Adventure using Address Break "Charles Richmond" <numerist@aquaporin4.com> - 2016-03-31 11:10 -0500
                            Re: Debugging Adventure using Address Break Ibmekon <Ibmekon> - 2016-03-31 19:20 +0100
                        Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-30 13:58 +0000
                          Re: Debugging Adventure using Address Break Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-30 16:32 +0000
                            Re: Debugging Adventure using Address Break scott@slp53.sl.home (Scott Lurndal) - 2016-03-30 16:55 +0000
                              Re: Debugging Adventure using Address Break "764hho" <764hho@nospam.com> - 2016-03-31 04:09 +1100
                                Re: Debugging Adventure using Address Break Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-31 06:22 +0000
                                  Re: Debugging Adventure using Address Break "Charles Richmond" <numerist@aquaporin4.com> - 2016-03-31 11:13 -0500
                                    Re: Debugging Adventure using Address Break JimP. <blue@cwahi.net> - 2016-03-31 21:00 -0500
                          Re: Debugging Adventure using Address Break "764hho" <764hho@nospam.com> - 2016-03-31 03:49 +1100
                      Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-30 05:29 +1100
                        Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-30 13:58 +0000
                          Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-31 03:41 +1100
                            Re: Debugging Adventure using Address Break jmfbahciv <See.above@aol.com> - 2016-03-31 12:41 +0000
                              Re: Debugging Adventure using Address Break "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-04-01 05:03 +1100
                  Re: Debugging Adventure using Address Break usenet@only.tnx (Questor) - 2016-04-15 08:34 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#161224 — Debugging Adventure using Address Break

Subject says it all.  There is a caveat:  Since all debugging steps are
dependent on the feedback of the last n steps, I cannot be precise
and I will try to document the assumption I make based on a fictional
feedback with each debugging steps.

The first step is to find out how and where ADVENT keeps track of
points.  There are many, many ways to do this.  Note that the
maximum number of points is 256 which suggests 256 bits are assigned
to keep track of which point in the game action has been achieved.

First,

SET WATCH FILES VERSION
R ADVENT

The versions are interesting and may help.  The FILES will tell me
how ADVENT writes its data to keep track of points.

If ADVENT writes into a data file, then I'd do a FILCOM
of a new data file without any points with a file which
has all the points sans the 256th one.  that will give me
the address of the words where the bits are set.  Then
it's easy to set a breakpoint using the SET BREAK command
with a mask whenever that bit is referenced.

So a MIC file should be created to play the entire game and a
break will occur whenever that bit is referenced.  thus, one
would find the room and items required to get the last point.


If the data is kept in the EXE (this is a snarly method of
programming but people do it), then that implies that the
EXE has to be writtable.

I would then play the game until the first point is about
to be achieved.  Exit the game.  Write-lock the EXE file.
Then either RUN or CONT the game, depending on how the
write-lock was done.  Now try to get the point.  An error
message from the monitor (can't recall the precise format)
will complain giving data about the locations which couldn't
be written.

Another possible method of determining where the points are
written is to FILCOM a virgin ADVENT.EXE with a completed,
sans one point, ADVENT.EXE.

These last two methods may take some examining of the EXE
files.  You can do that by running FILDDT and looking at
the addresses which are interesting.

There are many other ways to debug the program.  You can
put in a patch  with FILDDT which will do stuff
depending on the code.  One does not need DDT loaded with
the EXE to do any of the debugging.  I probably would not
want DDT in my address space because it's extra code
to ignore and it does strange things with one's adddress space.

If you did think you needed DDT, then you would have to go
to a TOPS-20 system,  and type:

GET ADVENT
DDT
^C
SAVE ADVENT

Then you can look using DDT commands but there won't be
symbols with this program.  After playing around on the -20,
you can go to a TOPS-10 system, verify that the addresses
you are interested in are the same or determine the offset
from the -20 core copy.  Then you can set the appropriate
address break and run the MIC game playing file to determine
the objects and rooms you need for the 256th point.

Now, these techniques are just from the top of my head.
There are a lot more, including watching the game
being played from the POV of the monitor, but this is
considered "cheating" ;-).  (I guess noone here would
understand the cheating reference but JMF and TW would.)

/BAH

[toc] | [next] | [standalone]

#161239

jmfbahciv <See.above@aol.com> wrote

> Subject says it all.  There is a caveat:  Since all debugging steps are
> dependent on the feedback of the last n steps, I cannot be precise
> and I will try to document the assumption I make based on a fictional
> feedback with each debugging steps.
>
> The first step is to find out how and where ADVENT keeps track of
> points.  There are many, many ways to do this.  Note that the
> maximum number of points is 256 which suggests 256 bits are assigned
> to keep track of which point in the game action has been achieved.
>
> First,
>
> SET WATCH FILES VERSION
> R ADVENT
>
> The versions are interesting and may help.  The FILES will tell me
> how ADVENT writes its data to keep track of points.
>
> If ADVENT writes into a data file, then I'd do a FILCOM
> of a new data file without any points with a file which
> has all the points sans the 256th one.  that will give me
> the address of the words where the bits are set.  Then
> it's easy to set a breakpoint using the SET BREAK command
> with a mask whenever that bit is referenced.
>
> So a MIC file should be created to play the entire game and a
> break will occur whenever that bit is referenced.  thus, one
> would find the room and items required to get the last point.
>
>
> If the data is kept in the EXE (this is a snarly method of
> programming but people do it), then that implies that the
> EXE has to be writtable.

And this method won't work if they don’t.

> I would then play the game until the first point is about
> to be achieved.  Exit the game.  Write-lock the EXE file.
> Then either RUN or CONT the game, depending on how the
> write-lock was done.  Now try to get the point.  An error
> message from the monitor (can't recall the precise format)
> will complain giving data about the locations which couldn't
> be written.
>
> Another possible method of determining where the points are
> written is to FILCOM a virgin ADVENT.EXE with a completed,
> sans one point, ADVENT.EXE.
>
> These last two methods may take some examining of the EXE
> files.  You can do that by running FILDDT and looking at
> the addresses which are interesting.

So you don’t in fact find the last point using SET BREAK, as we said.

> There are many other ways to debug the program.  You can
> put in a patch  with FILDDT which will do stuff
> depending on the code.  One does not need DDT loaded with
> the EXE to do any of the debugging.  I probably would not
> want DDT in my address space because it's extra code
> to ignore and it does strange things with one's adddress space.
>
> If you did think you needed DDT, then you would have to go
> to a TOPS-20 system,  and type:
>
> GET ADVENT
> DDT
> ^C
> SAVE ADVENT
>
> Then you can look using DDT commands but there won't be
> symbols with this program.  After playing around on the -20,
> you can go to a TOPS-10 system, verify that the addresses
> you are interested in are the same or determine the offset
> from the -20 core copy.  Then you can set the appropriate
> address break and run the MIC game playing file to determine
> the objects and rooms you need for the 256th point.
>
> Now, these techniques are just from the top of my head.

Pity that you STILL haven't shown how SET BREAK can be
used to work out the last point.

> There are a lot more, including watching the game
> being played from the POV of the monitor, but this is
> considered "cheating" ;-).  (I guess noone here would
> understand the cheating reference but JMF and TW would.)

That last is even sillier than you usually manage. 

[toc] | [prev] | [next] | [standalone]

#161248

Rod Speed wrote:
> jmfbahciv <See.above@aol.com> wrote
>
>> Subject says it all.  There is a caveat:  Since all debugging steps are
>> dependent on the feedback of the last n steps, I cannot be precise
>> and I will try to document the assumption I make based on a fictional
>> feedback with each debugging steps.
>>
>> The first step is to find out how and where ADVENT keeps track of
>> points.  There are many, many ways to do this.  Note that the
>> maximum number of points is 256 which suggests 256 bits are assigned
>> to keep track of which point in the game action has been achieved.
>>
>> First,
>>
>> SET WATCH FILES VERSION
>> R ADVENT
>>
>> The versions are interesting and may help.  The FILES will tell me
>> how ADVENT writes its data to keep track of points.
>>
>> If ADVENT writes into a data file, then I'd do a FILCOM
>> of a new data file without any points with a file which
>> has all the points sans the 256th one.  that will give me
>> the address of the words where the bits are set.  Then
>> it's easy to set a breakpoint using the SET BREAK command
>> with a mask whenever that bit is referenced.
>>
>> So a MIC file should be created to play the entire game and a
>> break will occur whenever that bit is referenced.  thus, one
>> would find the room and items required to get the last point.
>>
>>
>> If the data is kept in the EXE (this is a snarly method of
>> programming but people do it), then that implies that the
>> EXE has to be writtable.
>
> And this method won't work if they don’t.
>
>> I would then play the game until the first point is about
>> to be achieved.  Exit the game.  Write-lock the EXE file.
>> Then either RUN or CONT the game, depending on how the
>> write-lock was done.  Now try to get the point.  An error
>> message from the monitor (can't recall the precise format)
>> will complain giving data about the locations which couldn't
>> be written.
>>
>> Another possible method of determining where the points are
>> written is to FILCOM a virgin ADVENT.EXE with a completed,
>> sans one point, ADVENT.EXE.
>>
>> These last two methods may take some examining of the EXE
>> files.  You can do that by running FILDDT and looking at
>> the addresses which are interesting.
>
> So you don’t in fact find the last point using SET BREAK, as we said.

From a previous post of mine and the text above, you have the address,
the mask and can break when any of those bits are referenced.
>
>> There are many other ways to debug the program.  You can
>> put in a patch  with FILDDT which will do stuff
>> depending on the code.  One does not need DDT loaded with
>> the EXE to do any of the debugging.  I probably would not
>> want DDT in my address space because it's extra code
>> to ignore and it does strange things with one's adddress space.
>>
>> If you did think you needed DDT, then you would have to go
>> to a TOPS-20 system,  and type:
>>
>> GET ADVENT
>> DDT
>> ^C
>> SAVE ADVENT
>>
>> Then you can look using DDT commands but there won't be
>> symbols with this program.  After playing around on the -20,
>> you can go to a TOPS-10 system, verify that the addresses
>> you are interested in are the same or determine the offset
>> from the -20 core copy.  Then you can set the appropriate
>> address break and run the MIC game playing file to determine
>> the objects and rooms you need for the 256th point.
>>
>> Now, these techniques are just from the top of my head.
>
> Pity that you STILL haven't shown how SET BREAK can be
> used to work out the last point.

You haven't understood what I wrote.
>
>> There are a lot more, including watching the game
>> being played from the POV of the monitor, but this is
>> considered "cheating" ;-).  (I guess noone here would
>> understand the cheating reference but JMF and TW would.)
>
> That last is even sillier than you usually manage.

So you don't want to learn.  that's fine with me.

/BAH

>

[toc] | [prev] | [next] | [standalone]

#161251

jmfbahciv <See.above@aol.com> wrote
> Rod Speed wrote
>> jmfbahciv <See.above@aol.com> wrote

>>> Subject says it all.  There is a caveat:  Since all debugging steps
>>> are dependent on the feedback of the last n steps, I cannot be
>>> precise and I will try to document the assumption I make based
>>> on a fictional feedback with each debugging steps.

>>> The first step is to find out how and where ADVENT keeps track
>>> of points.  There are many, many ways to do this.  Note that the
>>> maximum number of points is 256 which suggests 256 bits are assigned
>>> to keep track of which point in the game action has been achieved.

>>> First,

>>> SET WATCH FILES VERSION
>>> R ADVENT

>>> The versions are interesting and may help.  The FILES will
>>> tell me how ADVENT writes its data to keep track of points.

>>> If ADVENT writes into a data file, then I'd do a FILCOM
>>> of a new data file without any points with a file which
>>> has all the points sans the 256th one.  that will give me
>>> the address of the words where the bits are set.  Then
>>> it's easy to set a breakpoint using the SET BREAK
>>> command with a mask whenever that bit is referenced.

>>> So a MIC file should be created to play the entire game and
>>> a break will occur whenever that bit is referenced.  thus, one
>>> would find the room and items required to get the last point.

>>> If the data is kept in the EXE (this is a snarly method
>>> of programming but people do it), then that implies
>>> that the EXE has to be writtable.

>> And this method won't work if they don’t.

And that game doesn’t. So this bit of yours is a complete
irrelevancy to what is being discussed, whether SET BREAK
can be used to determine the end point in that particular
game. It can't.

>>> I would then play the game until the first point is about
>>> to be achieved.  Exit the game.  Write-lock the EXE file.
>>> Then either RUN or CONT the game, depending on how
>>> the write-lock was done.  Now try to get the point.  An
>>> error message from the monitor (can't recall the precise
>>> format) will complain giving data about the locations
>>> which couldn't be written.

>>> Another possible method of determining where the
>>> points are written is to FILCOM a virgin ADVENT.EXE
>>> with a completed, sans one point, ADVENT.EXE.

>>> These last two methods may take some examining
>>> of the EXE files.  You can do that by running FILDDT
>>> and looking at the addresses which are interesting.

>> So you don’t in fact find the last point using SET BREAK, as we said.

> From a previous post of mine and the text above, you have the address,
> the mask and can break when any of those bits are referenced.

Yes, but that only helps if the player actually gets that point.
If the player gets that point, you don’t need SET BREAK on
where the points are stored to see how to get that point
and in fact it's useless to see how to get that point.

>>> There are many other ways to debug the program.  You can
>>> put in a patch  with FILDDT which will do stuff depending on
>>> the code.  One does not need DDT loaded with the EXE to do
>>> any of the debugging.  I probably would not want DDT in my
>>> address space because it's extra code to ignore and it does
>>> strange things with one's adddress space.

>>> If you did think you needed DDT, then you would have to go
>>> to a TOPS-20 system,  and type:

>>> GET ADVENT
>>> DDT
>>> ^C
>>> SAVE ADVENT

>>> Then you can look using DDT commands but there won't be
>>> symbols with this program.  After playing around on the -20,
>>> you can go to a TOPS-10 system, verify that the addresses
>>> you are interested in are the same or determine the offset
>>> from the -20 core copy.  Then you can set the appropriate
>>> address break and run the MIC game playing file to determine
>>> the objects and rooms you need for the 256th point.

All irrelevant to whether SET BREAK alone
can be used to find the last point.

>>> Now, these techniques are just from the top of my head.

>> Pity that you STILL haven't shown how SET BREAK
>> can be used to work out the last point.

> You haven't understood what I wrote.

Usual hoary old line from you when you can't actually
substantiate the claim you made which is just plain wrong.

>>> There are a lot more, including watching the game
>>> being played from the POV of the monitor, but this is
>>> considered "cheating" ;-).  (I guess noone here would
>>> understand the cheating reference but JMF and TW would.)

>> That last is even sillier than you usually manage.

> So you don't want to learn.

Nothing to learn there. I knew all that stuff
LONG before you ever said anything.

> that's fine with me.
 

[toc] | [prev] | [next] | [standalone]

#161268

Rod Speed wrote:
> jmfbahciv <See.above@aol.com> wrote

>>> And this method won't work if they don’t.
>
> And that game doesn’t. So this bit of yours is a complete
> irrelevancy to what is being discussed, whether SET BREAK
> can be used to determine the end point in that particular
> game. It can't.

The facts are that a person did figure out the last point
using the address break feature of TOPS-10.

/BAH

[toc] | [prev] | [next] | [standalone]

#161274

In article <PM00052E8E3263F463@aca43280.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>Rod Speed wrote:
>> jmfbahciv <See.above@aol.com> wrote
>
>>>> And this method won't work if they don’t.
>>
>> And that game doesn’t. So this bit of yours is a complete
>> irrelevancy to what is being discussed, whether SET BREAK
>> can be used to determine the end point in that particular
>> game. It can't.
>
>The facts are that a person did figure out the last point
>using the address break feature of TOPS-10.
>
>/BAH


The way I would go about this, given a tops10 system, read+execute
access to the binary but no source is to make a binary with
DDT; look at where the data output'ed by the points write came
from, and set a break on access to that data. This is a read/write
break; not an execute break. For that I would probably have to exit
to the command prompt and use the SET BREAK command, but I would
get all the data (addresses) from DDT. I would then see where the
points accesses came from. I would probably have to search in the 
binary for that. Possibly manually.

This assumes I have no symbols. Once symbols are in place this becomes
a lot easier to find.

So, yes, the SET BREAK command would be instrumental, but I would
be totally lost without DDT too.

So, this is a minor verification of Barb's claim. 

-- mrr

(I don't know how to set the read/write breaks directly in DDT, if that
is at all possible. I mostly dealt with tops20, which has different syntax
for this)

[toc] | [prev] | [next] | [standalone]

#161282

Morten Reistad <first@last.name.invalid> wrote
> jmfbahciv  <See.above@aol.com> wrote
>> Rod Speed wrote
>>> jmfbahciv <See.above@aol.com> wrote

>>>>> And this method won't work if they don't.

Have the data in the EXE.

>>> And that game doesn't. So this bit of yours is a
>>> complete irrelevancy to what is being discussed,
>>> whether SET BREAK can be used to determine
>>> the end point in that particular game. It can't.

>> The facts are that a person did figure out the last
>> point using the address break feature of TOPS-10.

> The way I would go about this, given a tops10 system, read+execute
> access to the binary but no source is to make a binary with DDT;

She denied that that is how the last point was found.

> look at where the data output'ed by the points write came
> from, and set a break on access to that data. This is a read/write
> break; not an execute break. For that I would probably have to
> exit to the command prompt and use the SET BREAK command,
> but I would get all the data (addresses) from DDT. I would then
> see where the points accesses came from.

You can't do that with the last point because by definition
no one could work out how to get the last point and so
you couldn’t use a data break on the achievement of the
last point, because no one would get it.

> I would probably have to search in
> the binary for that. Possibly manually.

Yes, you could certainly search the binary to see where that
last point is added. But that isnt use SET BREAK ALONE to
find where that happens.

> This assumes I have no symbols. Once symbols
> are in place this becomes a lot easier to find.

> So, yes, the SET BREAK command would be instrumental,

No it would not be except in the sense that it can
be used to work out where the points are stored.

> but I would be totally lost without DDT too.

> So, this is a minor verification of Barb's claim.

No it is not. You can't use SET BREAK ALONE to work out what
gets you the last point, because unless the player can get the
last point, you can't see the conditions under which the last
point is won. You have to do that by examining the code in
some way, either using DDT or some form of reverse assembler.

> (I don't know how to set the read/write breaks directly in DDT,
> if that is at all possible. I mostly dealt with tops20, which has
> different syntax for this) 

[toc] | [prev] | [next] | [standalone]

#161335

Rod Speed wrote:
> Morten Reistad <first@last.name.invalid> wrote
>> jmfbahciv  <See.above@aol.com> wrote
>>> Rod Speed wrote
>>>> jmfbahciv <See.above@aol.com> wrote
>
>>>>>> And this method won't work if they don't.
>
> Have the data in the EXE.
>
>>>> And that game doesn't. So this bit of yours is a
>>>> complete irrelevancy to what is being discussed,
>>>> whether SET BREAK can be used to determine
>>>> the end point in that particular game. It can't.
>
>>> The facts are that a person did figure out the last
>>> point using the address break feature of TOPS-10.
>
>> The way I would go about this, given a tops10 system, read+execute
>> access to the binary but no source is to make a binary with DDT;
>
> She denied that that is how the last point was found.
>
>> look at where the data output'ed by the points write came
>> from, and set a break on access to that data. This is a read/write
>> break; not an execute break. For that I would probably have to
>> exit to the command prompt and use the SET BREAK command,
>> but I would get all the data (addresses) from DDT. I would then
>> see where the points accesses came from.
>
> You can't do that with the last point because by definition
> no one could work out how to get the last point and so
> you couldn’t use a data break on the achievement of the
> last point, because no one would get it.
>
>> I would probably have to search in
>> the binary for that. Possibly manually.
>
> Yes, you could certainly search the binary to see where that
> last point is added. But that isnt use SET BREAK ALONE to
> find where that happens.
>
>> This assumes I have no symbols. Once symbols
>> are in place this becomes a lot easier to find.
>
>> So, yes, the SET BREAK command would be instrumental,
>
> No it would not be except in the sense that it can
> be used to work out where the points are stored.

No.  YOu use the break to determine when the bit was
accessed in the program.  that's gives you the items
and the place which sets the last it.  The address
break will happen and stop the program.  By watching
the ADVENT MIC commands you can identify the two items
required to set the last bit.  You can also determine
which room the actions need to happen.

/BAH

[toc] | [prev] | [next] | [standalone]

#161362

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00052EA3168C0A6B@aca410ea.ipt.aol.com...
> Rod Speed wrote:
>> Morten Reistad <first@last.name.invalid> wrote
>>> jmfbahciv  <See.above@aol.com> wrote
>>>> Rod Speed wrote
>>>>> jmfbahciv <See.above@aol.com> wrote
>>
>>>>>>> And this method won't work if they don't.
>>
>> Have the data in the EXE.
>>
>>>>> And that game doesn't. So this bit of yours is a
>>>>> complete irrelevancy to what is being discussed,
>>>>> whether SET BREAK can be used to determine
>>>>> the end point in that particular game. It can't.
>>
>>>> The facts are that a person did figure out the last
>>>> point using the address break feature of TOPS-10.
>>
>>> The way I would go about this, given a tops10 system, read+execute
>>> access to the binary but no source is to make a binary with DDT;
>>
>> She denied that that is how the last point was found.
>>
>>> look at where the data output'ed by the points write came
>>> from, and set a break on access to that data. This is a read/write
>>> break; not an execute break. For that I would probably have to
>>> exit to the command prompt and use the SET BREAK command,
>>> but I would get all the data (addresses) from DDT. I would then
>>> see where the points accesses came from.
>>
>> You can't do that with the last point because by definition
>> no one could work out how to get the last point and so
>> you couldn’t use a data break on the achievement of the
>> last point, because no one would get it.
>>
>>> I would probably have to search in
>>> the binary for that. Possibly manually.
>>
>> Yes, you could certainly search the binary to see where that
>> last point is added. But that isnt use SET BREAK ALONE to
>> find where that happens.
>>
>>> This assumes I have no symbols. Once symbols
>>> are in place this becomes a lot easier to find.
>>
>>> So, yes, the SET BREAK command would be instrumental,
>>
>> No it would not be except in the sense that it can
>> be used to work out where the points are stored.
>
> No.  YOu use the break to determine when
> the bit was accessed in the program.

And the program NEVER DOES THAT WITH THE LAST
POINT BECAUSE THE PLAYER DOESN’T KNOW HOW
TO GET THE LAST POINT.

> that's gives you the items and the place which sets the last it.

Only if the player gets the last point and by definition
when the player doesn’t know how to get the last point,
the SET BREAK on that last point never happens.

> The address break will happen and stop the program.

ONLY if the player GETS THE LAST POINT and by definition that
will never happen because the player doesn’t know how to do that.

> By watching the ADVENT MIC commands you can
> identify the two items required to set the last bit.

No you can't when the player never gets the last point.

> You can also determine which room the actions need to happen.

ONLY by examining the code, NOT by using SET BREAK on the
last point data. Because by definition the player never gets the
last point because they don’t know how to do that. 

[toc] | [prev] | [next] | [standalone]

#161320

On 3/21/2016 5:53 AM, Morten Reistad wrote:
> In article <PM00052E8E3263F463@aca43280.ipt.aol.com>,
> jmfbahciv  <See.above@aol.com> wrote:
>> Rod Speed wrote:
>>> jmfbahciv <See.above@aol.com> wrote
>>
>>>>> And this method won't work if they don’t.
>>>
>>> And that game doesn’t. So this bit of yours is a complete
>>> irrelevancy to what is being discussed, whether SET BREAK
>>> can be used to determine the end point in that particular
>>> game. It can't.
>>
>> The facts are that a person did figure out the last point
>> using the address break feature of TOPS-10.
>>
>> /BAH
>
>
> The way I would go about this, given a tops10 system, read+execute
> access to the binary but no source is to make a binary with
> DDT; look at where the data output'ed by the points write came
> from, and set a break on access to that data. This is a read/write
> break; not an execute break. For that I would probably have to exit
> to the command prompt and use the SET BREAK command, but I would
> get all the data (addresses) from DDT. I would then see where the
> points accesses came from. I would probably have to search in the
> binary for that. Possibly manually.
>
> This assumes I have no symbols. Once symbols are in place this becomes
> a lot easier to find.
>
> So, yes, the SET BREAK command would be instrumental, but I would
> be totally lost without DDT too.
>
> So, this is a minor verification of Barb's claim.
>
> -- mrr
>
> (I don't know how to set the read/write breaks directly in DDT, if that
> is at all possible. I mostly dealt with tops20, which has different syntax
> for this)

Is the SET BREAK command just a interface to the PDP10 Address 
Breakpoint hardware?   (using the DATA0 APR opcode)

I was reading the bottom page C-5 of:
<http://bitsavers.org/pdf/dec/pdp10/1982_ProcRefMan.pdf>

... just curious.

Rob.

[toc] | [prev] | [next] | [standalone]

#161327

In article <ncr114$re4$1@gioia.aioe.org>,
Rob Doyle  <radioengr@gmail.com> wrote:
>On 3/21/2016 5:53 AM, Morten Reistad wrote:
>> In article <PM00052E8E3263F463@aca43280.ipt.aol.com>,
>> jmfbahciv  <See.above@aol.com> wrote:
>>> Rod Speed wrote:
>>>> jmfbahciv <See.above@aol.com> wrote
>>>
>>>>>> And this method won't work if they don’t.
>>>>
>>>> And that game doesn’t. So this bit of yours is a complete
>>>> irrelevancy to what is being discussed, whether SET BREAK
>>>> can be used to determine the end point in that particular
>>>> game. It can't.
>>>
>>> The facts are that a person did figure out the last point
>>> using the address break feature of TOPS-10.
>>>
>>> /BAH
>>
>>
>> The way I would go about this, given a tops10 system, read+execute
>> access to the binary but no source is to make a binary with
>> DDT; look at where the data output'ed by the points write came
>> from, and set a break on access to that data. This is a read/write
>> break; not an execute break. For that I would probably have to exit
>> to the command prompt and use the SET BREAK command, but I would
>> get all the data (addresses) from DDT. I would then see where the
>> points accesses came from. I would probably have to search in the
>> binary for that. Possibly manually.
>>
>> This assumes I have no symbols. Once symbols are in place this becomes
>> a lot easier to find.
>>
>> So, yes, the SET BREAK command would be instrumental, but I would
>> be totally lost without DDT too.
>>
>> So, this is a minor verification of Barb's claim.
>>
>> -- mrr
>>
>> (I don't know how to set the read/write breaks directly in DDT, if that
>> is at all possible. I mostly dealt with tops20, which has different syntax
>> for this)
>
>Is the SET BREAK command just a interface to the PDP10 Address 
>Breakpoint hardware?   (using the DATA0 APR opcode)
>
>I was reading the bottom page C-5 of:
><http://bitsavers.org/pdf/dec/pdp10/1982_ProcRefMan.pdf>

Yep. ISTR it could be invoked from inside DDT as well, but I never
did that. I always used the shell command.

-- mrr

[toc] | [prev] | [next] | [standalone]

#161338

Rob Doyle wrote:
> On 3/21/2016 5:53 AM, Morten Reistad wrote:
>> In article <PM00052E8E3263F463@aca43280.ipt.aol.com>,
>> jmfbahciv  <See.above@aol.com> wrote:
>>> Rod Speed wrote:
>>>> jmfbahciv <See.above@aol.com> wrote
>>>
>>>>>> And this method won't work if they don’t.
>>>>
>>>> And that game doesn’t. So this bit of yours is a complete
>>>> irrelevancy to what is being discussed, whether SET BREAK
>>>> can be used to determine the end point in that particular
>>>> game. It can't.
>>>
>>> The facts are that a person did figure out the last point
>>> using the address break feature of TOPS-10.
>>>
>>> /BAH
>>
>>
>> The way I would go about this, given a tops10 system, read+execute
>> access to the binary but no source is to make a binary with
>> DDT; look at where the data output'ed by the points write came
>> from, and set a break on access to that data. This is a read/write
>> break; not an execute break. For that I would probably have to exit
>> to the command prompt and use the SET BREAK command, but I would
>> get all the data (addresses) from DDT. I would then see where the
>> points accesses came from. I would probably have to search in the
>> binary for that. Possibly manually.
>>
>> This assumes I have no symbols. Once symbols are in place this becomes
>> a lot easier to find.
>>
>> So, yes, the SET BREAK command would be instrumental, but I would
>> be totally lost without DDT too.
>>
>> So, this is a minor verification of Barb's claim.
>>
>> -- mrr
>>
>> (I don't know how to set the read/write breaks directly in DDT, if that
>> is at all possible. I mostly dealt with tops20, which has different syntax
>> for this)
>
> Is the SET BREAK command just a interface to the PDP10 Address
> Breakpoint hardware?   (using the DATA0 APR opcode)
>
> I was reading the bottom page C-5 of:
> <http://bitsavers.org/pdf/dec/pdp10/1982_ProcRefMan.pdf>
>
> ... just curious.

I think so.  We used it alot for debugging TOPS-10.

/BAH

[toc] | [prev] | [next] | [standalone]

#161332

Morten Reistad wrote:
> In article <PM00052E8E3263F463@aca43280.ipt.aol.com>,
> jmfbahciv  <See.above@aol.com> wrote:
>>Rod Speed wrote:
>>> jmfbahciv <See.above@aol.com> wrote
>>
>>>>> And this method won't work if they don’t.
>>>
>>> And that game doesn’t. So this bit of yours is a complete
>>> irrelevancy to what is being discussed, whether SET BREAK
>>> can be used to determine the end point in that particular
>>> game. It can't.
>>
>>The facts are that a person did figure out the last point
>>using the address break feature of TOPS-10.
>>
>>/BAH
>
>
> The way I would go about this, given a tops10 system, read+execute
> access to the binary but no source is to make a binary with
> DDT; look at where the data output'ed by the points write came
> from, and set a break on access to that data. This is a read/write
> break; not an execute break. For that I would probably have to exit
> to the command prompt and use the SET BREAK command, but I would
> get all the data (addresses) from DDT. I would then see where the
> points accesses came from. I would probably have to search in the
> binary for that. Possibly manually.
>
> This assumes I have no symbols. Once symbols are in place this becomes
> a lot easier to find.

On TOPS-10, you wouldn't have symbols.  That's why you use TOPS-20's
debugging features, then move to TOPS-10 to use the command.

>
> So, yes, the SET BREAK command would be instrumental, but I would
> be totally lost without DDT too.
>
> So, this is a minor verification of Barb's claim.
>
> -- mrr
>
> (I don't know how to set the read/write breaks directly in DDT, if that
> is at all possible. I mostly dealt with tops20, which has different syntax
> for this)

The break on TOPS-10 isn't in DDT.  It's a monitor command.

/BAH

[toc] | [prev] | [next] | [standalone]

#161491

On 22 Mar 2016 13:40:39 GMT, jmfbahciv <See.above@aol.com> wrote:
>Morten Reistad wrote:
>> In article <PM00052E8E3263F463@aca43280.ipt.aol.com>,
>> jmfbahciv  <See.above@aol.com> wrote:
>>>Rod Speed wrote:
>>>> jmfbahciv <See.above@aol.com> wrote
>>>
>>>>>> And this method won't work if they don’t.
>>>>
>>>> And that game doesn’t. So this bit of yours is a complete
>>>> irrelevancy to what is being discussed, whether SET BREAK
>>>> can be used to determine the end point in that particular
>>>> game. It can't.
>>>
>>>The facts are that a person did figure out the last point
>>>using the address break feature of TOPS-10.
>>>
>>>/BAH
>>
>>
>> The way I would go about this, given a tops10 system, read+execute
>> access to the binary but no source is to make a binary with
>> DDT; look at where the data output'ed by the points write came
>> from, and set a break on access to that data. This is a read/write
>> break; not an execute break. For that I would probably have to exit
>> to the command prompt and use the SET BREAK command, but I would
>> get all the data (addresses) from DDT. I would then see where the
>> points accesses came from. I would probably have to search in the
>> binary for that. Possibly manually.
>>
>> This assumes I have no symbols. Once symbols are in place this becomes
>> a lot easier to find.
>
>On TOPS-10, you wouldn't have symbols.  That's why you use TOPS-20's
>debugging features, then move to TOPS-10 to use the command.

Whether the .EXE has symbols included has nothing to do with being on TOPS-10 or
TOPS-20.  It is determined at LINK time.

[toc] | [prev] | [next] | [standalone]

#161283

jmfbahciv <See.above@aol.com> wrote
> Rod Speed wrote
>> jmfbahciv <See.above@aol.com> wrote

>>>> And this method won't work if they don’t.

>> And that game doesn’t. So this bit of yours is a complete
>> irrelevancy to what is being discussed, whether SET BREAK
>> can be used to determine the end point in that particular
>> game. It can't.

> The facts are that a person did figure out the last
> point using the address break feature of TOPS-10.

Calling it a fact doesn’t make it a fact and you still
haven't shown how SET BREAK can be used to do that.

It isn't even possible to use SET BREAK alone to do that. 

[toc] | [prev] | [next] | [standalone]

#161342

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00052E8E3263F463@aca43280.ipt.aol.com...
> Rod Speed wrote:
>> jmfbahciv <See.above@aol.com> wrote
>
>>>> And this method won't work if they don’t.
>>
>> And that game doesn’t. So this bit of yours is a complete
>> irrelevancy to what is being discussed, whether SET BREAK
>> can be used to determine the end point in that particular
>> game. It can't.
>
> The facts are that a person did figure out the last point
> using the address break feature of TOPS-10.
>

/BAH, speedo does *not* want to learn anything.  He just wants to spout 
explitives and be disruptive.  Explaining anything to him is a complete 
waste of time.  Someday you will learn this and stop encourging this troll.

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#161401

Charles Richmond wrote:
> "jmfbahciv" <See.above@aol.com> wrote in message
> news:PM00052E8E3263F463@aca43280.ipt.aol.com...
>> Rod Speed wrote:
>>> jmfbahciv <See.above@aol.com> wrote
>>
>>>>> And this method won't work if they don’t.
>>>
>>> And that game doesn’t. So this bit of yours is a complete
>>> irrelevancy to what is being discussed, whether SET BREAK
>>> can be used to determine the end point in that particular
>>> game. It can't.
>>
>> The facts are that a person did figure out the last point
>> using the address break feature of TOPS-10.
>>
>
> /BAH, speedo does *not* want to learn anything.  He just wants to spout
> explitives and be disruptive.  Explaining anything to him is a complete
> waste of time.  Someday you will learn this and stop encourging this troll.
>
I understand.  However, there are others who don't intend to learn
anything either.  You know who they are.  Replying to speedo
takes care of them all.

/BAH

[toc] | [prev] | [next] | [standalone]

#161272

jmfbahciv <See.above@aol.com> writes:
>Subject says it all.  There is a caveat:  Since all debugging steps are
>dependent on the feedback of the last n steps, I cannot be precise
>and I will try to document the assumption I make based on a fictional
>feedback with each debugging steps.
>
>The first step is to find out how and where ADVENT keeps track of
>points.  There are many, many ways to do this.  Note that the
>maximum number of points is 256 which suggests 256 bits are assigned
>to keep track of which point in the game action has been achieved.
>
>First,
>
>SET WATCH FILES VERSION
>R ADVENT
>
>The versions are interesting and may help.  The FILES will tell me
>how ADVENT writes its data to keep track of points.
>
>If ADVENT writes into a data file, then I'd do a FILCOM
>of a new data file without any points with a file which
>has all the points sans the 256th one.  that will give me
>the address of the words where the bits are set.  Then
>it's easy to set a breakpoint using the SET BREAK command
>with a mask whenever that bit is referenced.
>
>So a MIC file should be created to play the entire game and a
>break will occur whenever that bit is referenced.  thus, one
>would find the room and items required to get the last point.
>
>
>If the data is kept in the EXE (this is a snarly method of
>programming but people do it), then that implies that the
>EXE has to be writtable.
>
>I would then play the game until the first point is about
>to be achieved.  Exit the game.  Write-lock the EXE file.
>Then either RUN or CONT the game, depending on how the
>write-lock was done.  Now try to get the point.  An error
>message from the monitor (can't recall the precise format)
>will complain giving data about the locations which couldn't
>be written.
>
>Another possible method of determining where the points are
>written is to FILCOM a virgin ADVENT.EXE with a completed,
>sans one point, ADVENT.EXE.
>
>These last two methods may take some examining of the EXE
>files.  You can do that by running FILDDT and looking at
>the addresses which are interesting.
>
>There are many other ways to debug the program.  You can
>put in a patch  with FILDDT which will do stuff
>depending on the code.  One does not need DDT loaded with
>the EXE to do any of the debugging.  I probably would not
>want DDT in my address space because it's extra code
>to ignore and it does strange things with one's adddress space.
>
>If you did think you needed DDT, then you would have to go
>to a TOPS-20 system,  and type:
>
>GET ADVENT
>DDT
>^C
>SAVE ADVENT
>
>Then you can look using DDT commands but there won't be
>symbols with this program.  After playing around on the -20,
>you can go to a TOPS-10 system, verify that the addresses
>you are interested in are the same or determine the offset
>from the -20 core copy.  Then you can set the appropriate
>address break and run the MIC game playing file to determine
>the objects and rooms you need for the 256th point.
>
>Now, these techniques are just from the top of my head.
>There are a lot more, including watching the game
>being played from the POV of the monitor, but this is
>considered "cheating" ;-).  (I guess noone here would
>understand the cheating reference but JMF and TW would.)
>
>/BAH

[toc] | [prev] | [next] | [standalone]

#161273

jmfbahciv <See.above@aol.com> writes:
>Subject says it all.  There is a caveat:  Since all debugging steps are
>dependent on the feedback of the last n steps, I cannot be precise
>and I will try to document the assumption I make based on a fictional
>feedback with each debugging steps.
>
>The first step is to find out how and where ADVENT keeps track of
>points.  There are many, many ways to do this.  Note that the
>maximum number of points is 256 which suggests 256 bits are assigned
>to keep track of which point in the game action has been achieved.

Given that the maximum number of points is 350[*], the rest of the
post seems to not be relevent.

[*] See source code posted in Message-ID: <56ec937f.654481@nntp2.rawbw.com>

[toc] | [prev] | [next] | [standalone]

#161334

Scott Lurndal wrote:
> jmfbahciv <See.above@aol.com> writes:
>>Subject says it all.  There is a caveat:  Since all debugging steps are
>>dependent on the feedback of the last n steps, I cannot be precise
>>and I will try to document the assumption I make based on a fictional
>>feedback with each debugging steps.
>>
>>The first step is to find out how and where ADVENT keeps track of
>>points.  There are many, many ways to do this.  Note that the
>>maximum number of points is 256 which suggests 256 bits are assigned
>>to keep track of which point in the game action has been achieved.
>
> Given that the maximum number of points is 350[*], the rest of the
> post seems to not be relevent.
>
> [*] See source code posted in Message-ID: <56ec937f.654481@nntp2.rawbw.com>

That was the second rendition of the program.

/BAH

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web