Retro/pcjs
Watch
1
0
Fork
You've already forked pcjs
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'next-release'

Browse source
This commit is contained in:
Jeff Parsons 2016-12-08 19:12:00 -08:00
commit 7095cbea87
1 changed files with 19 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

33
modules/pdp11/lib/rk11.js
View file

@ -1174,21 +1174,26 @@ RK11.prototype.writeData = function(drive, iCylinder, iHead, iSector, nWords, ad
break; break;
} }
/* /*
* TODO: Figure out why the WCHK commands fail during the 11/70 CPU EXERCISER diagnostic, * TODO: Figure out why certain WCHK commands fail during the 11/70 CPU EXERCISER diagnostic,
* once the test starts reading/writing with physical addresses > 177777. I think all the * once the test starts reading/writing with physical addresses > 177777. I think all the
* UNIBUS address calculations are fine, so I'm at a loss to explain how a WCHK operation * UNIBUS address calculations are fine, so I'm at a loss to explain how a WCHK operation
* is supposed to succeed when the diagnostic itself appears to alter the memory that it * can succeed when the diagnostic itself appears to alter the memory immediately after the
* just wrote. Is it possible that the controller buffers the data from the previous write, * preceding WRITE operation.
* and the WCHK operation is comparing against its own buffer instead of physical memory?
* *
* Turn on RK11 messages using the Debugger's "m rk11 on" command, and then take a look at * The following machine is already primed with the diagnostic, as well as the recommended
* the first RK11 operation that uses a UNIBUS address larger than 16 bits; eg: * breakpoints and messages:
*
* http://www.pcjs.org/devices/pdp11/machine/1170/panel/debugger/cpuexer/
*
* If you're not using that machine, turn on RK11 messages ("m rk11 on"), set a breakpoint at
* 033330 ("bp 033330") and then take a look at the first RK11 operation after that breakpoint;
* it should be the first one using a UNIBUS address larger than 16 bits:
* *
* RK11: WRITE(147:1:2) 00453610--00463610 @037772 * RK11: WRITE(147:1:2) 00453610--00463610 @037772
* *
* Use a breakpoint to halt the machine at 037772 and then use the Debugger's "da" command * Use a breakpoint to halt the machine at 037772, and then use the Debugger's "da" command
* to determine what UNIBUS address 00453610 is mapped to (make sure you specify it as a * to determine where UNIBUS address 00453610 is mapped (make sure you specify it as a physical
* physical address using the % prefix): * address using the % prefix):
* *
* >> da %00453610 * >> da %00453610
* 00,101,011,110,001,000 00453610 * 00,101,011,110,001,000 00453610
@ -1196,7 +1201,7 @@ RK11.prototype.writeData = function(drive, iCylinder, iHead, iSector, nWords, ad
* OFFSET: 1,011,110,001,000 00013610 * OFFSET: 1,011,110,001,000 00013610
* PHYSICAL: 0,000,000,000,000,000,000,000 00000000 * PHYSICAL: 0,000,000,000,000,000,000,000 00000000
* *
* You can see that the starting address for the WRITE is perfectly calculated to start at * So, you can see that the starting address for the WRITE is perfectly calculated to begin at
* physical address 0. And the "da" command indicates virtual address 0 points to the same * physical address 0. And the "da" command indicates virtual address 0 points to the same
* memory: * memory:
* *
@ -1207,10 +1212,10 @@ RK11.prototype.writeData = function(drive, iCylinder, iHead, iSector, nWords, ad
* & MMUMASK: 1,111,111,111,111,111,111,111 17777777 * & MMUMASK: 1,111,111,111,111,111,111,111 17777777
* = PHYSICAL: 0,000,000,000,000,000,000,000 00000000 * = PHYSICAL: 0,000,000,000,000,000,000,000 00000000
* *
* Strangely, the diagnostic is storing its RKCS command register at 001570, which is right in * Strangely, the diagnostic (its interrupt handler to be exact) is updating the next RKCS command
* the middle of the first 2048 words of memory -- the same 2048 words that the diagnostic first * value at 001570, which is right in the middle of the first 2048 words of memory -- the same 2048
* WRITEs and then WCHKs. So obviously that value is changing between the time of the WRITE and * words that the diagnostic is about to WRITE and then WCHK. Since that value is changing between
* the WCHK, so how can WCHK succeed? * the WRITE and the WCHK, how can WCHK succeed?
* *
* For now, I just pretend that it does, by skipping the actual comparison. * For now, I just pretend that it does, by skipping the actual comparison.
* *