Thanks or persisting. Now I see what you mean. This is great. I had no
idea that interactive examine could be used this way. So, basically ie
-m examines the memory that you specify and allows you to change it,
with assembly language instruction mnemonics no less, who'd of thunk it!
id -m works too:
sim> id -m 0-16
0: inc 177560
4: tstb 177560
10: bpl 4
12: movb 177562,r0
16: halt
sim> g 0
HALT instruction, PC: 000020 (HALT)
sim>
SimH is a pretty amazing tool. It works great as a debugger, too.
Thanks,
Will
On 2/20/16 3:43 PM, Kevin Handy wrote:
You also have the option of running on the "bare" metal of the simh
emulator.
PDP-11 simulator V3.8-1
sim> ie -m 0-16
0: HALT inc 177560
4: HALT tstb 177560
10: HALT bpl 4
12: HALT movb 177562,r0
16: HALT halt
sim> run 0
HALT instruction, PC: 000020 (HALT)
sim>
Used halt instead of ,exit because not macro library here.
You also have "macro11" in simtools to assemble things. Don't know if
there is any way to feed its output directlt into simh though.
On Sat, Feb 20, 2016 at 10:48 AM, Paul Koning <[email protected]
<mailto:[email protected]>> wrote:
> On Feb 20, 2016, at 12:25 PM, Will Senn <[email protected]
<mailto:[email protected]>> wrote:
>
> Great answer and helpful. I'll give both approaches a shot. If I
understand my environment correctly, RT-11 is single user, single
job (well, most of the time anyway). So, it oughta be safe enough
to try this without messing things up beyond needing to restart if
I have logic errors? That is, the file system isn't involved or
caching or anything that would cause inconsistency as a result of
an infinite loop or crash? Not that I would ever code such things :)!
RT comes in several flavors, of which I know the SJ and FB
(foreground/background) flavors, V2 specifically. Both are
unprotected operating systems, so you can play with I/O devices at
will.
Also, in those there definitely is no caching in the file system.
For that matter, the file structure is simple enough that there
really isn't anything to go "inconsistent". A crash in
mid-operation might cause a file not to be there if it was being
written, but that's about it. The only exception I can think of
is the file system defrag operation, but then again that one may
be written in a fault tolerant manner, I don't know.
paul
_______________________________________________
Simh mailing list
[email protected] <mailto:[email protected]>
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
