I tested just now using Rich Cornwell's SimH KL-10 and the twonky disks
(same as I used to test under KLH10). Doing a GET of an EXE file
followed by a SAVE to a new file results in a file with zero's in .JBSA
(as well as other JOBDAT words).

So it does look like an issue with Rich Cornwell's SimH KL-10
implementation.

This was with the latest version from https://github.com/rcornwell/sims,
and the 704non.exe configuration from the twonky disks.

- Nick

On Saturday, September 9, 2023 at 9:38:05 PM UTC-4, Nick Bush wrote:
> I tested just now using Rich Cornwell's SimH KL-10 and the twonky disks
> (same as I used to test under KLH10). Doing a GET of an EXE file
> followed by a SAVE to a new file results in a file with zero's in .JBSA
> (as well as other JOBDAT words).
>
> So it does look like an issue with Rich Cornwell's SimH KL-10
> implementation.
>
> This was with the latest version from https://github.com/rcornwell/sims,
> and the 704non.exe configuration from the twonky disks.
>
> - Nick
I am not sure what would be going on here. I know save works on 6.03, but did not work on 7.0x I thought it was something in Tops 10 7.0x rather then emulation.

Rich

On Sunday, September 10, 2023 at 5:36:16 PM UTC-4, kgx...@yahoo.com wrote:
> On Saturday, September 9, 2023 at 9:38:05 PM UTC-4, Nick Bush wrote:
> > I tested just now using Rich Cornwell's SimH KL-10 and the twonky disks
> > (same as I used to test under KLH10). Doing a GET of an EXE file
> > followed by a SAVE to a new file results in a file with zero's in .JBSA
> > (as well as other JOBDAT words).
> >
> > So it does look like an issue with Rich Cornwell's SimH KL-10
> > implementation.
> >
> > This was with the latest version from https://github.com/rcornwell/sims,
> > and the 704non.exe configuration from the twonky disks.
> >
> > - Nick
> I am not sure what would be going on here. I know save works on 6.03, but did not work on 7.0x I thought it was something in Tops 10 7.0x rather then emulation.
>
> Rich
I did some testing... Save works on KS10 Tops 7.03, but does not work on KL10. I don't see any extended addressing in use. Any suggestions on where to look?

Rich

On 2023-09-11 02:45, kgxxx10@yahoo.com wrote:
> On Sunday, September 10, 2023 at 5:36:16 PM UTC-4, kgx...@yahoo.com wrote:
>> On Saturday, September 9, 2023 at 9:38:05 PM UTC-4, Nick Bush wrote:
>>> I tested just now using Rich Cornwell's SimH KL-10 and the twonky disks
>>> (same as I used to test under KLH10). Doing a GET of an EXE file
>>> followed by a SAVE to a new file results in a file with zero's in .JBSA
>>> (as well as other JOBDAT words).
>>>
>>> So it does look like an issue with Rich Cornwell's SimH KL-10
>>> implementation.
>>>
>>> This was with the latest version from https://github.com/rcornwell/sims,
>>> and the 704non.exe configuration from the twonky disks.
>>>
>>> - Nick
>> I am not sure what would be going on here. I know save works on 6.03, but did not work on 7.0x I thought it was something in Tops 10 7.0x rather then emulation.
>>
>> Rich
> I did some testing... Save works on KS10 Tops 7.03, but does not work on KL10. I don't see any extended addressing in use. Any suggestions on where to look?

I don't really have any ideas, but just reading about things, could
there be something with the disk I/O parts causing the write to not work
exactly right under some circumstances? Like writing the wrong data, or
partial, or something?

Johnny

On Monday, September 11, 2023 at 9:54:10 AM UTC-4, Johnny Billquist wrote:
> On 2023-09-11 02:45, kgx...@yahoo.com wrote:
> > On Sunday, September 10, 2023 at 5:36:16 PM UTC-4, kgx...@yahoo..com wrote:
> >> On Saturday, September 9, 2023 at 9:38:05 PM UTC-4, Nick Bush wrote:
> >>> I tested just now using Rich Cornwell's SimH KL-10 and the twonky disks
> >>> (same as I used to test under KLH10). Doing a GET of an EXE file
> >>> followed by a SAVE to a new file results in a file with zero's in .JBSA
> >>> (as well as other JOBDAT words).
> >>>
> >>> So it does look like an issue with Rich Cornwell's SimH KL-10
> >>> implementation.
> >>>
> >>> This was with the latest version from https://github.com/rcornwell/sims,
> >>> and the 704non.exe configuration from the twonky disks.
> >>>
> >>> - Nick
> >> I am not sure what would be going on here. I know save works on 6.03, but did not work on 7.0x I thought it was something in Tops 10 7.0x rather then emulation.
> >>
> >> Rich
> > I did some testing... Save works on KS10 Tops 7.03, but does not work on KL10. I don't see any extended addressing in use. Any suggestions on where to look?
> I don't really have any ideas, but just reading about things, could
> there be something with the disk I/O parts causing the write to not work
> exactly right under some circumstances? Like writing the wrong data, or
> partial, or something?
>
> Johnny

Not sure. My KS and KL share a huge amount of code. From what I can see SAVE writes the header followed by zeros, where LINK writes correct .EXE file. On KS there is no issue, both work correctly. The KL and KS sure disk drives, and most of same CPU code. The RH11 and RH20 are different but talk to same disk devices. I am suspecting possible issue with MAP instruction.

Rich

On 9/10/2023 20:45, kgxxx10@yahoo.com wrote:

> I did some testing... Save works on KS10 Tops 7.03, but does not work on KL10. I don't see any extended addressing in use. Any suggestions on where to look?
>
> Rich

The twonky 704 KL-10 monitor (704MON) that I was running does run with
extended addressing. Using EDDT to step through the SAVE code (under
klh10) shows that it switches between section 0 code and section 1 code
and then back to section 0 code, although what is executed in section 1
seems minor, and does not include writing out the program data.

I was not able to step through the same SAVE code when running under
your simh: while I was able to boot into EDDT and set a breakpoint,
after the breakpoint was reached, I was not able to get any input to
EDDT for some reason, so I couldn't single step through the code. I
have no idea why. I didn't try using the KS10 configuration to see if
the same problem with EDDT occurred.

- Nick

On Monday, September 11, 2023 at 2:38:05 PM UTC-4, Nick Bush wrote:
> On 9/10/2023 20:45, kgx...@yahoo.com wrote:
>
> > I did some testing... Save works on KS10 Tops 7.03, but does not work on KL10. I don't see any extended addressing in use. Any suggestions on where to look?
> >
> > Rich
> The twonky 704 KL-10 monitor (704MON) that I was running does run with
> extended addressing. Using EDDT to step through the SAVE code (under
> klh10) shows that it switches between section 0 code and section 1 code
> and then back to section 0 code, although what is executed in section 1
> seems minor, and does not include writing out the program data.
>
> I was not able to step through the same SAVE code when running under
> your simh: while I was able to boot into EDDT and set a breakpoint,
> after the breakpoint was reached, I was not able to get any input to
> EDDT for some reason, so I couldn't single step through the code. I
> have no idea why. I didn't try using the KS10 configuration to see if
> the same problem with EDDT occurred.
>
> - Nick

Thanks for checking... Can you give me the labels where it switches sections? Not sure how to use EDDT so don't know how to test that.

Rich

On 9/11/2023 15:55, kgxxx10@yahoo.com wrote:

>
> Thanks for checking... Can you give me the labels where it switches
sections? Not sure how to use EDDT so don't know how to test that.
>
> Rich

Rich,

The switch to section 1 occurs at the instruction following GTFREP in
COMCON.MAC. This is called from GETDRP in COMCON.MAC which is setting up
a page for the directory of the .EXE file. This is the result of the
call to SAVEXE to create the .EXE file. Note that GETDRP is also called
when loading an .EXE file to allocate a page to load the .EXE file
diretory into.

In the twonky 704MON.exe file, GETDRP is address 374332 and GTFREP is
address 374616. GTFREP is just changing to section 1 to call GTPME, and
once if finds a page that is not in use in the user address space
(starting from page 777 and working down), it returns back to GETDRP in
section 1.

- Nick

PS. To use EDDT, a the BOOT prompt type 704non.exe/E (or whatever system
file your a loading plus the /E switch). You can then set breakpoints
using the <ESC>B command and start the monitor using DEBUG<ESC>G.

To single step, use <ESC>X. When I tried to use EDDT under your simh
pdp10-kl, setting the breakpoint and starting the monitor worked fine.
When EDDT stops due to the breakpoint being reached, nothing I type
seems to make it to EDDT.

Rich Alderson <news@alderson.users.panix.com> writes:

> whis292 <jeffgunter@usa.net> writes:

>> On Saturday, September 9, 2023 at 12:37:54=E2=80=AFAM UTC-4, Zach Z wrote:

>>> On Thursday, September 7, 2023 at 9:38:05=E2=80=AFPM UTC-4, Nick Bush wrote:

>>>> After posting earlier about seeing the failure on 7.04 on the living
>>>> computer museum (LCM) system, I built klh10 on a Raspberry PI and booted
>>>> 7.04 (from the twonky disks). A quick test showed the save command worked
>>>> properly: GET an existing EXE file, followed by a SAVE to a new file
>>>> resulted in an identical file. On the LCM 7.04 system the SAVE resulted in
>>>> many locations in JOBDAT being zeroed.

>>>> So, this might be a simulator specific issue, although it is hard to see
>>>> what type of simulator bug would cause this type of result without also
>>>> causing various other failures.

>>>> - Nick

>>> Maybe this should be posted as a bug in the Simh GitHub?

>> that seems pretty reasonable, but it might be nice if someone with the
>> necessarily facilities were to take the system.exe that you and LCM+L are
>> running and verify that it works properly on a klh10 system, and fails on a
>> simh system from whatever tree(s) you and/or LCM are using, to simplify the
>> work of the simh team. if the testing were done, you might conceivably find
>> it is a .SAVE bug after all (but my bet is simh). they'd appreciate details
>> of exactly what goes awry during the save too, if someone knew that.
>
> I've looked at the LCM+L menu, and it appears that they are running Rich
> Cornwell's SimH KL-10 instead of KLH10. I've asked the remaining staff member
> to confirm that, and to test against KLH10.
>
>> if i knew how to get your or LCM+L's system.exe (maybe a backup /TAPE file?)
>> onto my klh10 system, or if i knew how to get my simh to boot tops10 (a
>> LOADable boot file, or a .DSK file that is BOOTable), i'd help (well, i'd
>> *try* anyway).
>
> Hold off until I hear back from LCM+L.

OK, I worked with the folks keeping the lights on at LCM+L to see what I could
see. They provided me a copy of the disk images used by their simulated 2065
(running Rich Cornwell's SimH KL-10), for experimenting with KLH10 instead.

Long trials later, KLH10 cannot read their disk images, which appear to have
a slightly different format than I expect from SimH OR KLH10.

So instead, I simply ran the latest KLH10 against the decades old Twonky disk
images (still available via Tim Shoppa's klh10.trailing-edge.com).

The SAVE command works:

| 2020-iMac bld-kl> kn10-kl twonky.ini
| KLH10 2.0l (MyKL) built Sep 10 2023 16:58:51
| Copyright ? 2002 Kenneth L. Harrenstien -- All Rights Reserved.
| This program comes "AS IS" with ABSOLUTELY NO WARRANTY.
|
| Compiled for apple-darwin22.6.0 on x86_64 with word model USEINT
| Emulated config:
| CPU: KL10-extend SYS: T20 Pager: KL APRID: 3600
| Memory: 8192 pages of 512 words (SHARED)
| Time interval: INTRP Base: OSGET
| Interval default: 60Hz
| Internal clock: OSINT
| Other: MCA25 CIRC JPC DEBUG PCCACHE CTYINT EVHINT
| Devices: DTE RH20 RPXX(DP) TM03(DP) NI20(DP)
| [MEM: Allocating 8192 pages [os_mmcreate: shmget failed for 33554432 bytes -
| Invalid argument]
| private memory, clearing...done]
|
| KLH10# ; KLH10 configuration for TOPS-10 test system
| KLH10#
| KLH10# ; DTE requires ackdly to avoid T10 race condition
| KLH10# devdef dte0 200 dte master ackdly=5
| KLH10# devdef rh0 540 rh20
| KLH10# devdef rh1 544 rh20
| KLH10# devdef dsk0 rh0.0 rp type=rp06 sn=4747 format=dbd9 path=T10-RP06.0-dbd9
| KLH10# devdef dsk1 rh0.1 rp type=rp06 sn=1026 format=dbd9 path=T10-RP06.1-dbd9
| KLH10# devdef mta0 rh1.0 tm03 type=TU77
| KLH10#
| KLH10# ; NI: param "c3dly" to avoid T10 race.
| KLH10# ; NI: param "rdtmo" to avoid system hangups with OSF/1 V3.0
| KLH10# ;
| KLH10# ; Decnet node TWONKY, 9.429
| KLH10# devdef ni0 564 ni20 dedic=0 decnet=1 doarp=0 enaddr=aa:00:04:00:ad:25
| dpdelay=12 c3dly=2 rdtmo=3
| KLH10#
| KLH10# load klboot.exe
| Using word format "c36"...
| Loaded "klboot.exe":
| Format: DEC-PEXE
| Data: 0, Symwds: 0, Low: 01000000, High: 0, Startaddress: 0703667
| Entvec: 0 wds at 0
| KLH10# [EOF on twonky.ini]
| KLH10# go
| Starting KN10 at loc 0703667...
| BOOT V4(100)
|
| BOOT>704non.exe
| [Loading from DSKA:704NON.EXE[1,4]]
|
| TOPS-10 704 No Network 11-Nov-93
| Why reload: new
| Date: sep-13-1995
| Time: 1440
| Startup option: noinit
| [Rebuilding the system search list from the HOM blocks]
|
| [Rebuilding the active swapping list from the HOM blocks]
|
| [Rebuilding the system dump list from the HOM blocks]
|
|
| TOPS-10 704 No Network Wednesday 13-Sep-95 14:40:18
|
| .login 1,2/byp
| Job 1 TOPS-10 704 No Network CTY
| 14:40 13-Sep-95 Wednesday
|
| .dir hello.*
|
|
| HELLO BAK 1 <057> 13-Sep-95 DSKA: [1,2]
| HELLO REL 1 <057> 13-Sep-95
| HELLO MAC 1 <057> 13-Sep-95
| HELLO EXE 8 <057> 13-Sep-95
| Total of 11 blocks in 4 files on DSKA: [1,2]
|
| .type hello.mac
| title hello world
| search uuosym
|
| lab: asciz/hello world!
| /
|
| start: reset
| outstr lab
| monrt.
|
| end start
|
| .delete hello.rel
| Files deleted:
| DSKA:HELLO.REL
| 01 Blocks freed
|
| .delete hello.exe
| Files deleted:
| DSKA:HELLO.EXE
| 08 Blocks freed
|
| .load hello
| MACRO: hello
| LINK: Loading
|
| EXIT
|
| .save
| HELLO saved
|
| ..dir hello
|
|
| HELLO BAK 1 <057> 13-Sep-95 DSKA: [1,2]
| HELLO MAC 1 <057> 13-Sep-95
| HELLO REL 1 <057> 13-Sep-95
| HELLO EXE 8 <057> 13-Sep-95
| Total of 11 blocks in 4 files on DSKA: [1,2]
|
| .run hello
|
| hello world!
|
| ..r filddt
|
| File: hello.exe/data
| [Looking at file DSKA:HELLO.EXE[1,2]]
|
| 1120/ 146,,143
| 1143/ CALLI 0
| 1144/ TTCALL 3,140
| 1145/ CALLI 1,12
|
| 1140/ TLCE 2,@466336(15) $t;hello
| 1141/ worl
| 1142/ d!
|
| ^Z
|
| .

So it appears that this is really due to an issue in the SimH KL-10 emulation.

I think Rich is reading this, but I'll poke him directly.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Wednesday, September 13, 2023 at 2:55:34 PM UTC-7, Rich Alderson wrote:

(snip)

> So it appears that this is really due to an issue in the SimH KL-10 emulation.
One might guess that a hardware emulation bug would show up in many
places, and be easy to find. But maybe not.

The one big (at the time) contribution I made to Hercules was getting shifts right.

IBM S/360 shifts use the low six bits of the shift amount.

The C standard, and many other processors, only use 5 bits for 32 bit shifts.
It seems that somewhere in OS/360 IPL, it does a shift of more than 31.

As I remember, that was close to when OS/360 actually started to run.
I believe the next bug was using 4K storage keys instead of 2K.

That fails when different keys are set on halves of a 4K aligned block.

On Monday, September 11, 2023 at 2:38:05 PM UTC-4, Nick Bush wrote:
> On 9/10/2023 20:45, kgx... wrote:
>
> > I did some testing... Save works on KS10 Tops 7.03, but does not work on KL10. I don't see any extended addressing in use. Any suggestions on where to look?
> >
> > Rich
> The twonky 704 KL-10 monitor (704MON) that I was running does run with
> extended addressing. Using EDDT to step through the SAVE code (under
> klh10) shows that it switches between section 0 code and section 1 code
> and then back to section 0 code, although what is executed in section 1
> seems minor, and does not include writing out the program data.
>
> I was not able to step through the same SAVE code when running under
> your simh: while I was able to boot into EDDT and set a breakpoint,
> after the breakpoint was reached, I was not able to get any input to
> EDDT for some reason, so I couldn't single step through the code. I
> have no idea why. I didn't try using the KS10 configuration to see if
> the same problem with EDDT occurred.
>
> - Nick

if you want to use eddt with kl simh, try starting at DBGNPP instead of DEBUG.

On 9/18/2023 09:39, whis292 wrote:
> if you want to use eddt with kl simh, try starting at DBGNPP instead of DEBUG.

DBGNPP is not defined anywhere I can find in TOPS-10 7.04.

- Nick

On Monday, September 18, 2023 at 8:38:05 PM UTC-4, Nick Bush wrote:
> On 9/18/2023 09:39, whis292 wrote:
> > if you want to use eddt with kl simh, try starting at DBGNPP instead of DEBUG.
> DBGNPP is not defined anywhere I can find in TOPS-10 7.04.

DBGNPP falls into DEBUG. the only thing it does is set ST%NPP in CNFST2. that is, it sets the 2000,,0 bit in CNFST2.

if the bit is set, then STAPPC won't start primary protocol. this seems to prevent oddities with EDDT hanging later during system startup. maybe there are problems with switching protocol under some circumstances.

so,
load with /E from boot. then set 2000 in left half of CNFST2, then DEBUG$G - might help. it does for me. you could instead possibly also just neuter STAPPC with a POPJ

-jfg

On Wednesday, September 13, 2023 at 2:55:34 PM UTC-7, Rich Alderson wrote:

(snip)

> So it appears that this is really due to an issue in the SimH KL-10 emulation.

So, no answer to this one yet?

I was expecting it to be some unusual case in the emulation that someone
forgot, and only shows up in this case. One of those "oh, how did I miss that!"
problems.

On Thursday, September 21, 2023 at 2:24:11 PM UTC-4, gah4 wrote:
> On Wednesday, September 13, 2023 at 2:55:34 PM UTC-7, Rich Alderson wrote:
>
> (snip)
> > So it appears that this is really due to an issue in the SimH KL-10 emulation.
> So, no answer to this one yet?
>
> I was expecting it to be some unusual case in the emulation that someone
> forgot, and only shows up in this case. One of those "oh, how did I miss that!"
> problems.

I have looked through the instructions being executed during save, but can't see anything that looks wrong. If someone can point me to where it is going bad I can try and fix it. From what I can see, SAVE is writing the .exe header then zeros for file data. I suspected MAP, but that would break other things. I am pretty sure it is an instruction not behaving correctly in extended address mode, but not sure. I seriously doubt disk writes since that would break all kind of things.

Rich

On 9/22/2023 13:10, kgxxx10@yahoo.com wrote:
(snip)
>
> I have looked through the instructions being executed during save, but can't see anything that looks wrong. If someone can point me to where it is going bad I can try and fix it. From what I can see, SAVE is writing the .exe header then zeros for file data. I suspected MAP, but that would break other things. I am pretty sure it is an instruction not behaving correctly in extended address mode, but not sure. I seriously doubt disk writes since that would break all kind of things.
>
> Rich

Rich,

It appears that all the IO done for the SAVE is being executed from
section 1, and as far as I can tell the result is that page zero of the
user address space is being written as all zeros. Since it would be
extremely rare that anything other that a SAVE operation would be
writing page zero of a program out in dump mode, I would suspect an
issue in the mapping of user page zero for the IOWD used for writing the
page.

Page one and subsequent pages seem to be written correctly.

Note that I used a small test program that only had pages zero, one and
two in its address space, but the other programs I have tried saving
have tended to be much larger and the only differences have shown up in
page zero.

- Nick

On Friday, September 22, 2023 at 7:38:05 PM UTC-7, Nick Bush wrote:

(snip)

> It appears that all the IO done for the SAVE is being executed from
> section 1, and as far as I can tell the result is that page zero of the
> user address space is being written as all zeros. Since it would be
> extremely rare that anything other that a SAVE operation would be
> writing page zero of a program out in dump mode, I would suspect an
> issue in the mapping of user page zero for the IOWD used for writing the
> page.

I never learned extended addressing, as the Macro-10 programming
I did, years ago, was on a KA-10.

What I wonder, though, is if there is an at least slightly obvious
way to do extended addressing wrong.

As I wrote before, I found the Hercules bug from knowing
(many years ago) how S/360 shift instructions work, and how
C shift operators and many other processors work.

I wasn't running it, and especially not doing instruction by
instruction stepping.

When actually writing extended addressing code, what is the
thought, "this could happen if I did that", when doing it?

How do you get into, and out of, extended addressing mode?
What happens if you do that wrong?

On Friday, September 22, 2023 at 10:38:05 PM UTC-4, Nick Bush wrote:
> On 9/22/2023 13:10, kgx...@yahoo.com wrote:
> (snip)
> >
> > I have looked through the instructions being executed during save, but can't see anything that looks wrong. If someone can point me to where it is going bad I can try and fix it. From what I can see, SAVE is writing the .exe header then zeros for file data. I suspected MAP, but that would break other things. I am pretty sure it is an instruction not behaving correctly in extended address mode, but not sure. I seriously doubt disk writes since that would break all kind of things.
> >
> > Rich
> Rich,
>
> It appears that all the IO done for the SAVE is being executed from
> section 1, and as far as I can tell the result is that page zero of the
> user address space is being written as all zeros. Since it would be
> extremely rare that anything other that a SAVE operation would be
> writing page zero of a program out in dump mode, I would suspect an
> issue in the mapping of user page zero for the IOWD used for writing the
> page.
>
> Page one and subsequent pages seem to be written correctly.
>
> Note that I used a small test program that only had pages zero, one and
> two in its address space, but the other programs I have tried saving
> have tended to be much larger and the only differences have shown up in
> page zero.
>
> - Nick

I believe I have fixed it. The fix is available at my sims repository. I will push it to Open-SimH later this week. If you find other errors in future please post issue on my sims repo. Thanks for pointing out the issue of not writing page zero, it turned out to be error with MAP instruction.

Rich

On Monday, September 25, 2023 at 6:50:02 PM UTC-7, kgx...@yahoo.com wrote:

(snip)

> I believe I have fixed it. The fix is available at my sims repository.
> I will push it to Open-SimH later this week. If you find other errors in
> future please post issue on my sims repo.

> Thanks for pointing out the issue of not writing page zero, it turned
> out to be error with MAP instruction.
Is there an obvious, and easy to explain, reason why this only shows
up in SAVE?

On Tuesday, September 26, 2023 at 1:25:34 AM UTC-4, gah4 wrote:
> On Monday, September 25, 2023 at 6:50:02 PM UTC-7, kgx...@yahoo.com wrote:
>
> (snip)
> > I believe I have fixed it. The fix is available at my sims repository.
> > I will push it to Open-SimH later this week. If you find other errors in
> > future please post issue on my sims repo.
>
> > Thanks for pointing out the issue of not writing page zero, it turned
> > out to be error with MAP instruction.
> Is there an obvious, and easy to explain, reason why this only shows
> up in SAVE?
I'm am guessing but I think save is the only place where the monitor does a MAP 0. Extended addressing is very complex.

Rich

On Monday, September 25, 2023 at 9:50:02 PM UTC-4, wrote:
> On Friday, September 22, 2023 at 10:38:05 PM UTC-4, Nick Bush wrote:
> > On 9/22/2023 13:10, kgx...@yahoo.com wrote:
> > (snip)
> > >
> > > I have looked through the instructions being executed during save, but can't see anything that looks wrong. If someone can point me to where it is going bad I can try and fix it. From what I can see, SAVE is writing the .exe header then zeros for file data. I suspected MAP, but that would break other things. I am pretty sure it is an instruction not behaving correctly in extended address mode, but not sure. I seriously doubt disk writes since that would break all kind of things.
> > >
> > > Rich
> > Rich,
> >
> > It appears that all the IO done for the SAVE is being executed from
> > section 1, and as far as I can tell the result is that page zero of the
> > user address space is being written as all zeros. Since it would be
> > extremely rare that anything other that a SAVE operation would be
> > writing page zero of a program out in dump mode, I would suspect an
> > issue in the mapping of user page zero for the IOWD used for writing the
> > page.
> >
> > Page one and subsequent pages seem to be written correctly.
> >
> > Note that I used a small test program that only had pages zero, one and
> > two in its address space, but the other programs I have tried saving
> > have tended to be much larger and the only differences have shown up in
> > page zero.
> >
> > - Nick
> I believe I have fixed it. The fix is available at my sims repository. I will push it to Open-SimH later this week. If you find other errors in future please post issue on my sims repo. Thanks for pointing out the issue of not writing page zero, it turned out to be error with MAP instruction.
>
> Rich
someone, Nick Bush i think, mentioned they were having problems using EDDT - it wasn't accepting input. never used github before, but i dropped an explanation of what i think is happening
https://github.com/rcornwell/sims/issues/305 which i hope is the right place.

On 9/26/2023 08:58, kgxxx10@yahoo.com wrote:
> On Tuesday, September 26, 2023 at 1:25:34 AM UTC-4, gah4 wrote:
>> On Monday, September 25, 2023 at 6:50:02 PM UTC-7, kgx...@yahoo.com wrote:
>>
>> (snip)
>>> I believe I have fixed it. The fix is available at my sims repository.
>>> I will push it to Open-SimH later this week. If you find other errors in
>>> future please post issue on my sims repo.
>>
>>> Thanks for pointing out the issue of not writing page zero, it turned
>>> out to be error with MAP instruction.
>> Is there an obvious, and easy to explain, reason why this only shows
>> up in SAVE?
> I'm am guessing but I think save is the only place where the monitor does a MAP 0. Extended addressing is very complex.
>
> Rich

I agree that SAVE is probably the only time the monitor does a MAP for a
user context page zero. Certainly it seems clear that the only time the
monitor would try to write out page zero of a user job is when it is
doing a SAVE. Page zero of a user job is never paged out, and a user
program cannot write out page zero in dump mode.

- Nick

On Tuesday, September 26, 2023 at 4:38:06 PM UTC-7, Nick Bush wrote:

(snip)

> I agree that SAVE is probably the only time the monitor does a MAP for a
> user context page zero. Certainly it seems clear that the only time the
> monitor would try to write out page zero of a user job is when it is
> doing a SAVE. Page zero of a user job is never paged out, and a user
> program cannot write out page zero in dump mode.

I never got to use extended addressing, as my Macro-10 programming was on a KA-10.

I tried to read a little about it, but it isn't especially obvious.

Is there an obvious wrong way to do page zero MAP?

On Tuesday, September 26, 2023 at 11:32:58 PM UTC-4, gah4 wrote:
> On Tuesday, September 26, 2023 at 4:38:06 PM UTC-7, Nick Bush wrote:
>
> (snip)
> > I agree that SAVE is probably the only time the monitor does a MAP for a
> > user context page zero. Certainly it seems clear that the only time the
> > monitor would try to write out page zero of a user job is when it is
> > doing a SAVE. Page zero of a user job is never paged out, and a user
> > program cannot write out page zero in dump mode.
> I never got to use extended addressing, as my Macro-10 programming was on a KA-10.
>
> I tried to read a little about it, but it isn't especially obvious.
>
> Is there an obvious wrong way to do page zero MAP?

Yes because access to 1,,n where n < 20 octal is to a register. What I am curious about is how diagnostics did not catch this error.

On Wednesday, September 27, 2023 at 7:28:06 AM UTC-7, kgx...@yahoo.com wrote:

(snip, I wrote)

> > I never got to use extended addressing, as my Macro-10 programming was on a KA-10.
> > I tried to read a little about it, but it isn't especially obvious.
> > Is there an obvious wrong way to do page zero MAP?

> Yes because access to 1,,n where n < 20 octal is to a register. What I am curious about is how diagnostics did not catch this error.

That is why I keep asking about it.

It helps with completely unrelated debugging problems, to know how those occur.

Now reminds me of one I knew years ago, not that I was working on, but found the bug.

ORVYL/370, the time-sharing system that goes with WYLBUR, has a debugger.
You can set break point, and then continue on. When you do continue, it has to
emulate, in some way, the instruction that was at the breakpoint.

I set a breakpoint on a BR 0 instruction.
S/370 says that branches to register 0 don't branch.
The debugger did branch. So, in addition to debugging my program, I had to
debug the debugger.

With the M91 option, the compiler puts a BR 0 instruction between each statement.
That is the pipeline flush for the 360/91, such that messages will indicate the right
statement number. (And program probably run slower.)

Being between statements, they were convenient break points, but somehow that
hadn't been considered before.

So, I suppose I can see how someone writing that one would not remember to
special case page 0 and the registers.

Reminds me of another from about as long ago. A story that someone with a
PDP-10 had modified it not to special case instruction fetch from registers..
Since it is rare, it would slow down all other instructions.
(As well as I remember, it was MIT, but that was years ago.)

It seems that some programs load instructions into registers for a loop.
Those programs, and it might have been TECO, wouldn't run on that one.

Maybe someone else knows about that one.