Trying to boot an FNP.
load_fnp has assembled the gicb and core image and the address to the DIA.
Part of the gicb listing:
00364 0 00736 ind .rtrn. spring loaded interrupt vector
00365 0 00736 ind .rtrn. spring loaded interrupt vector
00366 0 00736 ind .rtrn. spring loaded interrupt vector
00367 0 00736 ind .rtrn. spring loaded interrupt vector
00370 0 00736 ind .rtrn. spring loaded interrupt vector
00371 0 00736 ind .rtrn. spring loaded interrupt vector
00372 0 00736 ind .rtrn. spring loaded interrupt vector
00373 0 00736 ind .rtrn. spring loaded interrupt vector
00374 0 00736 ind .rtrn. spring loaded interrupt vector
00375 0 00736 ind .rtrn. spring loaded interrupt vector
00376 0 00736 ind .rtrn. spring loaded interrupt vector
00377 0 00736 ind .rtrn. spring loaded interrupt vector
assm 01 01-07-16 21.261 mcs/fnp intercomputer bootload routine page 22
datanet fnp hardware communication region
176 eject
177
178 i n t e r r u p t c e l l s
179
00400 000000 180 dec 0 level 0
00401 000000 181 dec 0 level 1
00402 000000 182 dec 0 level 2
00403 000000 183 dec 0 level 3
00404 000000 184 dec 0 level 4
A dump of the data from the DIA code in the dps8m simulator: (Note that 2 dn355 words are packed into a dps8m word, so the offsets are halved; and the buffer
has a PCW word at the start, moving the offsets up by one. So offset 400 in the gicb would be 201 in the dps8m buffer)
000154 000736000736 000736000736 000736000736 000736000736
000160 000736000736 000722000736 000736000736 000736000736
000164 000736000736 000736000736 000736000736 000736000736
000170 000736000736 000722000736 000736000736 000736000736
000174 000736000736 000736000736 000736000736 000736000736
000200 000736000736 000000000000 000000000000 000000000000
000204 000000000000 000000000000 000000000000 000000000000
000210 000000000000 000000000000 000000000000 000000000000
000214 000000000000 000000000000 000000000000 000000000000
We see that the interrupt cells starting at 400 in the gicb appear at 201 in the dunp; all is good.
Now we are sending the data over to the FNP, one word at a time:
00010172:000736000736
00010173:000736000736
00010174:000574657220
00010175:000474710220
The buffer is corrupt….
Perhaps load_fnp timed out?
Yep; the corruption happens at different locations on different runs. My scheme takes too long.
I can make a local copy and send that, but the way that the bootload completion is supposed to be signaled is that the dn355 signals that it is up and running. Copying the buffer
solves the data corruption problem, but that won't stop load_fnp from timing out.
