> On Jan 4, 2019, at 6:21 PM, Fritz Mueller <fri...@fritzm.org> wrote:
>
>
>> On Jan 4, 2019, at 6:51 AM, Paul Koning <paulkon...@comcast.net> wrote:
>>
>> Plan B: set a breakpoint at "ERL" (040672 in your map) which is the entry
>> point to the error logging code. That's where the display register is
>> incremented as part of logging an error. On entry, R0 is the EMT code (a
>> LOG$xx code, because these are EMTs in kernel mode). Many of those codes
>> are fixed and defined in KERNEL.MAC which is in the kit. The ones that are
>> configuration-dependent are in the RSTS.MAP listing, for example LOG$KB.
>> The log code would tell us which device or component is unhappy.
>
> Okay:
>
> BE125652
> _040672;B
> _P
> 0B:040672
> _$0;$7L
> $0 /000000 000400 001764 000000 000000 000000 001730 040672
>
> _$S/004340
> _777400;777412L
> 177400 /004713 000000 000344 000000 014000 001260
Well, this is VERY interesting.
The error code is LOG$CK, which is "run time system reported error". There are
a couple of possibilities. That code is logged from within the kernel if a
pseudo-vector (pointer to code in the runtime system) is invalid. It is also
generated if the runtime system issues a .ERLOG EMT. BASIC does so if the .BAC
file it wants to run has a bad checksum.
So the likely answer is that either your INIT.BAC program, or your BASIC.RTS,
is damaged. If you can rename INIT.BAC to something else, you can then try to
start and you'd expect to see startup messages like this:
...You currently have crash dump enabled.
04-Jan-99?
08:09 PM?
?Can't find file or account
?Program lost-Sorry
Ready
If so, then reload INIT.BAC. Or if you have the source (INIT.BAS) just say
"old init" and "compile".
If you still get a loop, then I'd suspect [0,1]BASIC.RTS.
Can you read the RK05 from the machinery you used to fill it originally? It
might make sense simply to read parts of it, or all of it, and verify the
contents are correct.
paul