[LMH]DPMT state at startup?

[Steve Krueger]

Allastair,

I've been looking at SSDN2 and at the microcode listings.  I think what 
you are seeing is the wired pages.  The boot loader code reads the first 
three pages into the first three pages of physical memory and then uses 
parameters from them to determine the following actions.  One important 
parameter in the system communication area is the number of wired pages. 
 This is the number of pages in the lowest page frame numbers that are 
to be read directly from the disk into memory.  They cannot be paged off 
of the load band.  The DPMT should be in those pages.  The wired pages 
aren't mapped in the DPMT because they should not be handled by the 
paging code at all since they are loaded at boot time and never swapped 
out or deleted.  The offset into the wired area is %SYS-COM-WIRED-SIZE.

The disk save microcode does produce the DPMT to be saved and a comment 
there says that the DPMT entries for wired pages are not initialized to 
point to the load band.  I think the whole DPMT is initialized to 
block-not-assigned, so this makes sense with what you are seeing.  

I hope this helps.  If need be, I can dig a bit more.

    -Steve


Nyef wrote:

>Hello all.
>
>SSDN2, section 6.4 says:
>
>% When the system is first booted,  the  DPMT  indicates  that  all
>% virtual  pages  reside in the read-only load band associated with
>% Device B.
>
>Does anyone know if this is arranged by the band-save code, or does the
>microcode fix up the DPMT on startup? If the latter, what sort of fixup is
>it?
>
>I ask because, in exploiter, both N928.LOAD and EXP1.LOAD are presently
>running into a page that is set to device A (the swap device) with a
>status code of 3 (disk block not yet assigned) during a read operation.
>
>---------------------------
>All programming can be viewed as an exercise.
>---------------------------
>Alastair Bridgewater
>e-mail: nyef@softhome.net
>
>http://lists.unlambda.com/mailman/listinfo/lispm-hackers
>
>  
>