KA10: Make Auxcpu talk to SimH PDP6 simulator.

[rcornwell]

Auxcpu should be able to connect to simH PDP6 simulator.

[larsbrinkhoff]

You should be able to assign me now.

[larsbrinkhoff]

I think I will add another unit to the existing ka10_auxcpu.c device. Agree/disagree?

[rcornwell]

You can call it pdp6_slave.c or something like that. Since it will only be for the PDP6.

Naming convention:

• pdp6_ for PDP6 specific.
• ka10_ for KA10 specific.
• ki10_ for KI10 specific (nothing yet).
• kl10_ for KL10 specific
• kx10_ for modules that are used by more then one model CPU.

[larsbrinkhoff]

I started this now. The branch is here:
https://github.com/larsbrinkhoff/ka10-simh/commits/lars/slave

[larsbrinkhoff]

I have been testing this. I now remember I had some problems last time I tried to make two SIMH instances talk to each other using TMXR.

From what I see, they do connect to each other. However, tmxr_rx_poll calls tmxr_read which returns -1 which shuts down the connection. This is because sim_read_sock returns -1, which is because recv returned 0. Why?!?

Maybe you can try this for yourself. I have this for pdp10-ka:

set debug stderr
set cpu its 1024k
set auxcpu ena debug base=700000
at auxcpu 6666;notelnet
dep 20 setom 700000
dep 21 halt 22
dep 22 jfcl
dep 23 jfcl
dep 24 jfcl
dep 25 jfcl
dep 26 jfcl
dep 27 jrst 20
go 21

And this for pdp6:

set debug stderr
set slave ena debug=dataio;cmd;trc
at slave 6667,connect=localhost:6666;notelnet
dep 20 jrst 20
go 20

Testing is:

1. Start pdp10-ka with above configuration. Send stderr to a file.
2. Start pdp6 with above configuration.
3. Single step pdp10-ka until it does SETOM 700000.
4. pdp10-ka goes crazy and has to be kill -9'ed.
5. Read the log file.

[larsbrinkhoff]

I'm unassigning myself until the TMXR problem has been solved.

[rcornwell]

@larsbrinkhoff How did the memory read/write work on the PDP6 side of things?

[larsbrinkhoff]

On real hardware, or in the simulator?

On real hardware, there was a 16K memory for the PDP-6. It was also attached to the PDP-10 memory bus. But the PDP-6 only had the 16K on its memory bus.

[rcornwell]

So all PDP6 memory should go through slave_write and slave_read should update memory. Should it subtract auxcpu_base before sending it over to PDP6?

[larsbrinkhoff]

Yes, it should subtract. The PDP-6 16K has historically moved around in the PDP-10 20-bit address space. But from the PDP-6 it's always starting from 0.

[rcornwell]

Will this break aap's PDP6 interface if I subtract auxcpu_base before sending packet and add it in after receiving the packet?

[rcornwell]

Is there any need for either auxcpu_read or slave_read? Shouldn't only modifies be sent over the shared link?

[larsbrinkhoff]

Hmm, on second thought subtracting probably isn't necessary since the PDP-10 side has it aligned to 16K anyway. The PDP6 masks the address.

auxcpu_read/write is for the PDP-10 to call into auxcpu, right? Which sends the access over the network. pdp6_slave is teh PDP-6 side.

[rcornwell]

Yes it is masked by 16K masks so no need to subtract.

Yes auxcpu_read/write reads/sends data to remote system. However if at connect the slave is synchronized to the master then only writes need be passed back and forth.

[larsbrinkhoff]

That's true, but that's not how the protocol to @aap's pdp6 is defined.

[rcornwell]

The protocol that he defined does not match that of pdp6_slave.c. The two devices are talking back to each other. If both simulators modify memory, they will both get protocol errors! Since auxcpu does not process DATO requests and ACK is an error to slave device.

I do not believe his system allows for the PDP6 to modify memory and have this get reflected in the PDP10.

[rcornwell]

I got PDP6 to act as a slave to PDP10. The PDP10 always reads from PDP6 so is very slow. If this works I will clean up the slave code and remove unused functions.

[larsbrinkhoff]

Good news! Regarding the protocol, the intent is that the PDP-6 should "own" its own memory, and the PDP-10 should make requests for every read and write. Yes, this will make memory slower on the PDP-10 side and faster on the PDP-6 side. There are also inter-processor interrupts, but they are not fully implemented yet. There is some stub code. Either processor can send a signal to interrupt the other. This is the only time the PDP-6 initiates a network transaction according to the protocol. My code in pdp6_slave.c isn't to be trusted as a perfect implementation of the protocol. It's a work in progress and has not been tested fully. slave_read and slave_write seem like they should go away. I don't see that they are used anywhere, nor should they.

[larsbrinkhoff]

Sorry, had to work on another thing. SUPDUP support for PuTT. Will check your changes tomorrow.

[larsbrinkhoff]

Running the above test case, the KA10 hangs on the SETZM instruction.

[larsbrinkhoff]

Log from KA10 side.

Step expired, PC: 000020 (SETOM 0,700000)
sim> s
DBG(32)> AUXCPU XMTPKT: 0000 01 00 00 00 FF FF FF FF 0F                      .........
DBG(32)> AUXCPU TRACE: Ln0:tmxr_putc_ln()
DBG(32)> same as above (10 times)
DBG(32)> AUXCPU TRACE: Ln0:tmxr_send_buffered_data()
DBG(32)> AUXCPU XMT: 0000 00 09 01 00 00 00 FF FF FF FF 0F                ...........
DBG(32)> AUXCPU TRACE: tmxr_poll_rx()
DBG(32)> AUXCPU TRACE: Ln0:tmxr_close_ln()  
DBG(32)> AUXCPU CONNECT: Ln0:tmxr_close_ln()
DBG(32)> AUXCPU TRACE: Ln0:tmxr_reset_ln_ex()
DBG(32)> AUXCPU TRACE: Ln0:tmxr_send_buffered_data()
DBG(32)> AUXCPU CONNECT: Ln0:tmxr_reset_ln_ex(TRUE)
DBG(32)> AUXCPU TRACE: Ln0:tmxr_set_get_modem_bits()
DBG(32)> AUXCPU MODEM: DSR1 CTS0 RNG1 DCD_ RTS0 DTR0  - Line 0 - 0x2035220
DBG(32)> AUXCPU TRACE: Ln0:tmxr_getc_ln()
DBG(32)> AUXCPU TRACE: tmxr_poll_rx()
DBG(32)> AUXCPU TRACE: Ln0:tmxr_getc_ln()
DBG(32)> AUXCPU TRACE: tmxr_poll_rx()
DBG(32)> AUXCPU TRACE: Ln0:tmxr_getc_ln()
DBG(32)> AUXCPU TRACE: tmxr_poll_rx()
DBG(32)> AUXCPU TRACE: Ln0:tmxr_getc_ln()

[rcornwell]

Make sure you are not getting any command errors. Some of your options are wrong!

[larsbrinkhoff]

The only thing wrong was TRC in debug, but fixing that doesn't change anything.

What's your test case?

[larsbrinkhoff]

KA and KL ITS builds went through with your latest master.

Restore gets me this: PAGE FAULT IN SYSTEM, PC=700000,,153472 PAGE=216
I looked at pager state, but I didn't find anything missing.

[rcornwell]

I am using the test case above. Make sure that you start PDP6 first, and that the KA connects before using continue to do test.

Interesting on KL restore works... on KA I get BUGHLT due to PI LEVEL 2 at system level. Trace shows that DPA disk did a read, then ITS decided that it should not be returning an interrupt then and promptly ignores it and tries to go back into operation but interrupt is still pending.

[larsbrinkhoff]

Yes, with the PDP-6 started first the test case does work. I was expecting it to work either way, but I dunno.

[rcornwell]

Not sure if it can work either way. The KA needs to connect to the 6, if the 6 aint running it can't connect.

[larsbrinkhoff]

It was getting late, so I didn't get a chance to try it with ITS yet. To be continued...

[larsbrinkhoff]

I pushed some updates here: https://github.com/larsbrinkhoff/ka10-simh/tree/lars/aux

[larsbrinkhoff]

How to test using ITS:

pdp6 configuration:

set slave enabled debug
set cpu 16k
at slave 6667,connect=localhost:10006;notelnet
dep 20 jrst 20
go 20

ka10 configuraton, edit "build/pdp10-ka/run"

set auxcpu enabled
set auxcpu debug
at auxcpu 10006;notelnet

Run simulators. Login to ITS. Type:

sys$j
$$^R
pdp6up/ -1

pdp6$j
100/ 42

The sys job is the ITS core image. Setting pdp6up to -1 makes ITS access the PDP-6 memory, or else it will refuse.

The pdp6 job is the PDP-6 core image. Read and write memory locations to check that shared memory data is transferred.