Ok, but I think that's not what I meant.

Suppose I have APR6 = 177777 and length > 1.  That means VA 140076 maps to 
physical address 17777776, and VA 140100 maps to physical addres 20000000 which 
when masked with 22 bits would end up at 0.  The offset within the page is <= 
the page length.

Meanwhile, I discovered that RSTS actually rejects attempts to map things this 
way.  :-(

        paul

> On Nov 17, 2023, at 2:24 PM, Martin Bishop 
> <mjd.bis...@emeritus-solutions.com> wrote:
> 
> EK-DCJ11-UG-Pre DCJ11 Microprocessor User's Guide says it will abort [the 
> first processor guide on the shelf]
> 
> $4.5.2.2 (p4-7) Page Length Field ... "The block number of the virtual 
> address is compared against the page length field to detect length errors" ...
> 
> $4.7.1 MMR0 <14> Abort Page Length Error
> 
> $4.7.1.1.2 Abort -- Page Length 
> 
> When descriptors exist as they do in the PAR / PDR pair it is usual to police 
> them.  A QL at the manual indicates no exception behaviour for kernel mode or 
> an override.
> 
> The behaviour may be model dependent, but if MMR0<14> is populated I should 
> expect an abort -- you could code the abort ISR for desired behaviour and 
> return
> 
> It would be easier to build hardware without the checking, but harder to 
> debug the system.
> 
> Martin
> 
> -----Original Message-----
> From: Paul Koning via cctalk [mailto:cctalk@classiccmp.org] 
> Sent: 17 November 2023 18:16
> To: cctalk@classiccmp.org
> Cc: Paul Koning <paulkon...@comcast.net>
> Subject: [cctalk] Address wrapping in PDP-11 MMU
> 
> I'm working on some code where it would be handy to map the top of the I/O 
> page along with the bottom of physical memory.  An obvious hack is to point 
> the APR to the I/O page address needed, then set the length so that the 
> address modulo 2^22 also covers the low memory range.
> 
> It seems from the architecture manual that this would work, and SIMH seems to 
> do this (since it adds VA and PAR then masks with a 22 bit mask).  Would this 
> work on real hardware?
> 
>       paul
> 

Reply via email to