Paul Edwards  wrote:   
   > On Monday, November 21, 2022 at 11:37:26 PM UTC+8, wolfgang kern wrote:   
   > > On 19/11/2022 20:09, Paul Edwards wrote:   
   > > > I have implemented TF (trap flag) for the 8086.   
   > > >   
   > > > But when I looked up RBIL, it doesn't say that TF   
   > > > also works for the 80386. INT 1 is complicated   
   > > > instead.   
   > > >   
   > > > So can I single-step an 80386 program?   
   > > >   
   > > > It looks like x'cc' still works on an 80386, invoking   
   > > > INT 3 (from my reading of RBIL).   
   > > >   
   > > > Anyone know for sure?   
   >   
   > > yes, CC work on all x86.   
   > > but any decent debugger use Traps instead:   
   > > a) by setting TF to single step one instruction w/o   
   > > the need for replace/insert a byte there.   
   > > b) by setting breakpoints [DATA or CODE or I/O] to   
   > > trap at occurrence (reason for debug-registers).   
   > > note: CC work different to the avoidable CD03.   
   >   
   > Ok, thanks for that information.   
   >   
   > I am interested in restricting myself to the same tools   
   > that Tim Paterson had when creating the precursor   
   > to MSDOS, with the difference that I am   
   > doing 32-bit C programming instead of 16-bit   
   > assembler programming, so when I debug at the   
   > assembler level, it is almost all generated code.   
      
   AFAIK CP-M was originally written in PL-M.  Then, to improve   
   performance it was routine-by-routine rewritten in assembly.   
      
   Concerning debugging, integrated debug support is relatively   
   late, but there were external circuits that could single   
   step the processor, stop it on access to some specific   
   address and similar.  High-end systems on this sort were   
   expensive, but established company could easily afford   
   them.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)