monitor

[[e-mail]]

MSDOS (or its predecessor) was developed with the
aid of a monitor, specifically this one:

http://www.bitsavers.org/pdf/seattleComputer/firmware/Mon86_v15_c16.asm

(Joe pointed me to this).

I'm not sure which of these "disambiguations" is the
correct one for the above:

https://en.wikipedia.org/wiki/Machine_code_monitor

https://en.wikipedia.org/wiki/Resident_monitor

The first one says:

"The general decline of scratch-written assembly language software has made the use of a machine code monitor somewhat of a lost art."

I think this is something that is missing from my repertoire.

There are a few points.

One is that I always expect to debug at the assembler level.

Although I want my assembler to be generated from C90
code, mostly, I still ultimately expect to take that assembler,
and a listing, and a link map, and debug a body of assembler
code, looking for stack corruption or whatever.

From reading the above code, I found out that the 8086,
and presumably the 80386 even in PM32, has the ability
to execute a single instruction and then do an INT 1. This
is done by setting the "trap flag" (TF).

I also found out from that code that you can set a
breakpoint by putting an x'CC' in the code, and then an
INT 3 will be executed (and you will need to subtract
1 from the IP to get the relevant instruction).

The above code is designed to allow operation via a
serial port. But since my laptop doesn't have a serial
port, I'm thinking instead of switching display buffers
between OS and monitor.

I'm also thinking that I can use BIOS INT 16 AH=02H
to see if the right shift key is depressed on bootup
and if so, run the monitor before running PDOS.

It looks to me like most of the monitor can be written
in C.

I'm thinking that in the field I would need two PDOS
laptops. One is used for debugging with the monitor
and the other is used to view assembly listings to
know where to set breakpoints.

Tedious but honest.

I want to make sure that PDOS/386 could be developed
and debugged the same way MSDOS was. I just want to
switch processor.

BFN. Paul.

[[e-mail]]

The other thing I would like to reconcile is MVS's slip
trap for storage alter.

I think the same thing could be done with the 80386
by trapping every instruction and checking the storage
to see if it has been altered.

I wonder if the S/3X0 had some special hardware
feature to detect alteration of storage.

BFN. Paul.

[Scott Lurndal]

Post by ***@gmail.com
The other thing I would like to reconcile is MVS's slip
trap for storage alter.
I think the same thing could be done with the 80386
by trapping every instruction and checking the storage
to see if it has been altered.
I wonder if the S/3X0 had some special hardware
feature to detect alteration of storage.

Without a doubt.

Most modern intel and arm CPU's have similar capabilities
such as hardware watchpoints.

[a***@math.uni.wroc.pl]

Post by ***@gmail.com
The other thing I would like to reconcile is MVS's slip
trap for storage alter.
I think the same thing could be done with the 80386
by trapping every instruction and checking the storage
to see if it has been altered.
I wonder if the S/3X0 had some special hardware
feature to detect alteration of storage.

That looks like trap on page fault. All modern processors
can do this. On 486 (and some other processors) there is
also another possibility: you can use debug registers
to trap access to specific address. Debug registers
have advantages:
- you can trap on specific address
- there is choice, you can trap when storage changes, but
also on reads or in case of execution (normal breakpoints
do not work on ROM).

Disadvantage is that some processors have no debug registers
and usually number of debug registers is quite small.

[Joe Monk]

Post by ***@gmail.com
I wonder if the S/3X0 had some special hardware
feature to detect alteration of storage.

It's called storage keys.

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
I wonder if the S/3X0 had some special hardware
feature to detect alteration of storage.

It's called storage keys.

Brilliant!

BFN. Paul.