Oh. That trick. It loops until the loop its in gets loaded from the disk and halts... this stops the cpu racing the disc for the rest of the sector. Continue then boot, iirc.
Warner On Thu, Oct 30, 2025, 5:28 PM Peter Ekstrom via cctalk < [email protected]> wrote: > Paul, > > Thank you for that. I enabled the history and then loaded and ran my > initial test program: > > 1 .enabl AMA > 2 000000 .asect > 3 014000 .=14000 > 4 014000 012706 002000 start: mov #2000,sp > 5 014004 000240 loop: nop > 6 014006 000776 br loop > 7 014010 000000 halt > 8 .end > > And it ran for quite a few iterations through the loop, and then: > > 014004 002000 000000| 000000 NOP > 014006 002000 000000| BR 14004 > 014004 002000 000000| 000000 NOP > 014006 002000 000000| BR 14004 > 014004 002000 000000| 000000 NOP > 014006 002000 000000| BR 14004 > 014004 002000 000000| 000000 NOP > 014006 002000 000000| BR 14004 > 005266 001774 000014| HALT > sim> > > - Peter > > On Thu, Oct 30, 2025 at 5:12 PM Paul Koning <[email protected]> > wrote: > > > > > > > > On Oct 30, 2025, at 2:43 PM, Peter Ekstrom via cctalk < > > [email protected]> wrote: > > > > > > If I single-step, it doesn't seem to happen. But I have been playing > > around > > > with my test program and I added a loop in the beginning that clears > > 0-377. > > > That loop uses a bne instruction which seems to work fine. When I > reach a > > > br or jmp instruction, the program fails. I saw in the opcode test for > > > macro11 > > > in the simtools package, the br instruction is tested with 'br .' so > I > > > used that in my program and it failed too. > > > > This sure is strange. > > > > The CPU trace feature could be helpful here. Set it up to trace > execution > > and run your program. Then dump the trace buffer to see what actually > > happened. > > > > paul > > > > >
