Re: [Simh] RK Word Count register question

[Johnny Billquist]

On 2015-12-26 22:56, Johnny Billquist wrote:

Short, obvious question. Is simh expecting 16-bit addresses, and running
all addresses through the mmu in the command mode, or does it actually
use 18-, or 22-bit addresses, in which case you commands are accessing
memory, and not the I/O page, which is actually 17 777 777 410, if we
talk 22-bits.


Doh! Too many bits in there. 22 bit address should be 17 777 410 of 
course. :-)


Johnny



 Johnny

On 2015-12-26 21:28, Will Senn wrote:

All,

I am looking at code that puts data into the RKWC register (177410). I
am getting some interesting results and I would like to know what y'all
think about the results.

The code I am analyzing is the RK05 bootloader code from "Setting up
Unix - Sixth Edition" and I have completed the analysis and am satisfied
with the understanding I have gained from that process. However,
whenever I try to examine the contents of the RK buffers after executing
instructions that modify them, they always appear to be 0. Is this
normal?

I set out to see if the behavior was consistent.

I wrote some machine code (comments added after sim run) to put a value
into the RKWC location and HALT.

PDP-11 simulator V4.0-0 Betagit commit id: 0f43551d
sim> d 1 012737 ; MOV 1,(PC)+
sim> d 10002 177440 ; -340
sim> d 10004 177410 ; RKWC RK word counter register
sim> d 10006 00 ; HALT

sim> g 1

HALT instruction, PC: 010010 (HALT)

Then I examined the buffer:

sim> ex 177410
177410:00

Shouldn't 177410 contain 177440?

Next, I added an instruction to move the contents of 177410 into R0
before HALTing:

Add an instruction to move the contents of 177410 into R0
PDP-11 simulator V4.0-0 Betagit commit id: 0f43551d
sim> d 1 012737
sim> d 10002 177440
sim> d 10004 177410
sim> d 10006 013700
sim> d 10010 177410
sim> d 10012 00
sim>
sim> g 1

HALT instruction, PC: 010014 (HALT)

I examined RKWC and R0:

sim> ex 177410
177410:00
sim> ex r0
R0:177440

Well, 177410 still contains 0, but R0 contains 177440, some improvement.

Finally, I tried loading the memory location directly:
sim> d 177410 030303
sim> ex 177410
177410:030303

Huh? That was totally unexpected. What is going on?

Thanks,

Will
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh






--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RK Word Count register question

[Will Senn]

On 12/26/15 4:26 PM, Johnny Billquist wrote:

On 2015-12-26 22:56, Johnny Billquist wrote:

Short, obvious question. Is simh expecting 16-bit addresses, and running
all addresses through the mmu in the command mode, or does it actually
use 18-, or 22-bit addresses, in which case you commands are accessing
memory, and not the I/O page, which is actually 17 777 777 410, if we
talk 22-bits.


Doh! Too many bits in there. 22 bit address should be 17 777 410 of 
course. :-)


Johnny

Johnny,

Well. You were right (and others offline) about the address needing to 
be 1410:


PDP-11 simulator V4.0-0 Betagit commit id: 0f43551d
sim> d 1 012737
sim> d 10002 177440
sim> d 10004 177410
sim> d 10006 00
sim> g 1

HALT instruction, PC: 010010 (HALT)
sim> ex 1410
1410:177440

I don't really understand what you are saying about the mmu and 18 or 22 
bits other than getting that there are PDP-11's with 16, 18 and 22 bit 
memory sizes. I am guessing that the reason it's 1410 in this case 
is because the default machine in SimH is 22 bits and the IO space is 
reserved in the top 4k on this machine. If I had been more specific and 
limited SimH to a smaller memory footprint, less bits would be needed 
(the upper 4k would be addressable with fewer bits).


Ah, well, off to read Chapter 6 - Memory Management out of the Processor 
Handbook, again... I have to admit to barely skimming this chapter the 
first few times through because it didn't really make any sense, without 
context and I didn't think I needed to know. Now that it's relevant, and 
with a bit more background, I'm sure it'll make a lot more sense and be 
that much more interesting.


Thanks,

Will
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh