12 Apr
2015
12 Apr
'15
3:47 a.m.
On 2015-04-12 03:41, Dave McGuire wrote:
Ok. Memory shortage is the one thing I can imagine could cause something
like this. If a program runs out of memory, the programmer could just
have thrown a BPT in there as a way of crashing out.
Otherwise I'm not coming up with any good ideas here...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 04/11/2015 09:37 PM, Johnny Billquist wrote:
I thought that was the case, but I wasn't sure. BPT is breakpoint
trap, isn't it??
Yes, it is. And T-bit is when the T-bit in the PSW is set. That is how
debuggers single step code. So T-bit and BPT are very much just two
sides of the same coin.
Do
you really suspect hardware? I have an XXDP pack that I can boot
up, but I am so short of time...even slogging through the XXDP
documentation will take half the night.
It's just that T-bit trap or BPT is not something you'd normally get here.
Are you
running the baseline system, or have you done some previous
SYSGEN? If you run RMD, what can you see sitting in memory?
I'm running the baseline system. I am booting the "BL" disk in DL0:,
with "EXCPRV" in DL1:. I have made three attempts, so there are files
around from previous sysgens, but I answered "Y" when I'm asked if I
want sysgen to clean those up. I haven't done anything else on these
packs; I created them from disk images this afternoon.
I have started another attempt; I assume it will crash in the same
manner in a few minutes. When it does, I will run RMD and let you know
what else is hanging around.
Thank you for your help Johnny. I am stressing bigtime about my exhibit.