4 Jan
2019
4 Jan
'19
5:15 p.m.
On Jan 4, 2019, at 6:21 PM, Fritz Mueller <fritzm
at fritzm.org> wrote:
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
On Jan 4, 2019, at 6:51 AM, Paul Koning
<paulkoning at 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