Closed jeffgunter closed 1 year ago
Can you create a test program and put it on a backup tape?
According to the Proc reference manual ADJBP does NOT update the byte pointer, but puts the results in AC,AC+1.
I can try. Again I am on the road so might take an hour +Sent from my iPhoneOn Sep 30, 2023, at 14:34, Richard Cornwell @.***> wrote: Can you create a test program and put it on a backup tape?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
I pointed out some things to @rcornwell on IRC which seems to have lead to finding a problem in the emulator.
I think I might have solved this, but a test program would be helpful. I am very surprised diagnostics did not catch this. But it appears to have fixed CC on Tops 20.
_do not know why i have some much trouble getting this readable. sorry.
...and now i see you needed a backup tape. i'm sure you don't care that much, but i'll try to get that done correctly...
-jfg
this_ is a user mode tops10 program to demonstrate.
title owp
owp: jfcl reset move 2,[710004,,53163] seto 1, adjbp 1,2 came 1,[710004,,53163] jrst [outstr [asciz .changed.] exit] outstr [asciz .no change.] exit
end owp
Pushed out a patch that should fix it.
i agree that my exec mode tops10 monitor code now works again.
however, i would note that the sc40 and klh10 allow the use of adjbp and owgbp even if the pc is running in section zero. i am almost certain the same was true for our kl10.
the klh10 comments in inbyte.c support my claim. the user mode demo program owp.mac.txt above runs on klh10 but fails even under the new simh. i'm not sure it is critical to me, as long as the kernel nzs code works, which it apparently does. i do have a couple of programs that use it in user mode from section 0, but i can live without or fix them to run in nzs.
-jfg
KLH10 is really a KN10 not a KL10B. According to the 1982 Processor Ref (page 2-85), "In section 0 the pointer is always of the above type (normal word) -- local and one word --- and P must be <= 36."
I will check the KL10 microcode tomorrow and see if it would handle OWGBP in section 0 but I think it will not.
KN10 isn't supposed to diverge in essentials from KL10B.
Here's a comment from KLH10 inbyte.c:
* The PRM claims that one-word global BPs are only legal in non-zero sections.
More recent info (Uhler) indicates they are now legal in all sections, altho
two-word BPs are still only valid in non-zero section contexts.
SO: Can OWGBPs in section 0 use global addresses and access memory in other
sections?
[Assuming yes.]
I pushed a fix to allow owgpb to be valid in section 0, along with fixes to allow same for extend instructions. Running testing now.
Is this working?
yes, i think so.
-jfg
------ Original Message ------ Received: 11:44 AM EDT, 10/03/2023 From: Richard Cornwell @.> To: rcornwell/sims @.> Cc: jeffgunter @.>, Author @.> Subject: Re: [rcornwell/sims] simh kl10 possibly does not know about OWGBP during (Issue #311)
Is this working?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
[ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "https://github.com/rcornwell/sims/issues/311#issuecomment-1745245682", "url": "https://github.com/rcornwell/sims/issues/311#issuecomment-1745245682", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
this code runs in exec mode in section 2, and references a byte pointer in section 4. (it's part of our equivilent of, er, scnser)
DELT1A: SETO T1, ;BACK UP BYTE POINTER ADJBP T1,TDBIPT(F) ;FOR INPUT PUTTER MOVEM T1,TDBIPT(F)
the byte pointer is a one-word-global-byte-pointer: 710004,,50574
the adjbp doesn't seem to change the byte pointer at all.
.abc $1B>>DELT1A/ SETO T1,0 $x <-- so i typed "abc" at the monitor dot, then typed rubout to make this happen T1/ -1 DELT1A+1/ IBP T1,JOBBLT+2(F) f[ 123501 jobblt+2+123501[ 710004,,53163 <-- byte pointer before adjbp $x T1/ 22&11 4,,53163 2,,TTYTDB+47/ 22&11 4,,53163 DELT1A+2/ MOVEM T1,JOBBLT+2(F) t1[ 710004,,53163 <-- byte pointer after adjbp
by my calculation, the byte pointer should have changed to 700004,,53163
-jfg