30 Oct
2025
30 Oct
'25
6:37 p.m.
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 <
cctalk(a)classiccmp.org> 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 <paulkoning(a)comcast.net>
wrote:
reach a
execution
On Oct 30, 2025, at 2:43 PM, Peter Ekstrom via
cctalk <
cctalk(a)classiccmp.org> 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
> 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
and run your program. Then dump the trace buffer
to see what actually
happened.
paul