[Simh] MOP header specs?

Fri Feb 23 08:39:29 EST 2018

You're asking for something that doesn't exist.

.SYS files can be anything.  When downloaded via MOP, can by any
architecure - not just the server's.

.SYS can be a pagefile.  Or a swapfile.  Or a pdp-11 task image.  Or a
standalone VAX image.  Or an accounting file.  Or 68000 code.  Or 8080
code.  Or Alpha code.  Or a bitmap destined for a graphics adapter.  Or
anything else.

There is no MOP header.  What you may be seeing, as I noted previously,
is a MOP secondary or tertiary loader.

There are specs for each usage; e.g. what Johnny provided is a program
that decodes an RSX task image.  But it's not really an RSX image; in
his example, the RSX task builder was used to link 68000 code.  So the
secondary loader code, to be functional, would be 68000 code.

A VAX download would have a different image header, and VAX code.  And
so on for ANY architecture.

All MOP knows is to request a specific program; load bytes to an
address; and jump to an address.  Any interpretation of the bytes is up
to the code that's loaded - and the client CPU.

That's why a MOP load normally consists of asking for a program - which
is the secondary loader.  It's the secondary (or tertiary) loader that
knows how to unpack an image and make additional requests.

The file that you mentioned is Alpha SRM console code.  The only reason
for it to have a MOP loader is so that a firmware update can be done by
booting from a network repo.  I don't know if it was supported; the
usual path was LFU from a CDROM or disk.  Note that you can't boot (or
run a MOP client, or do much or anything) without the SRM console
already in FLASH.  (Or the NT ARC console.)  It's the firmware that
knows how to negotiate MOP, and it's the firmware that provides the
instructions implemented in PALcode.  So that path is not useful for
bare hardware.

On 23-Feb-18 07:53, Tim Stark wrote:
> Johnny,
>
> Oh, I now got it.   I mean SYS specs, not MOP specs.  Is that TIN program available?
>
> Thanks,
> Tim
>
> -----Original Message-----
> From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Johnny Billquist
> Sent: Friday, February 23, 2018 4:31 AM
> To: simh at trailing-edge.com
> Subject: Re: [Simh] MOP header specs?
>
> On 2018-02-21 04:13, Tim Stark wrote:
>> Folks,
>>
>> Does anyone know any documentation provides some information about MOP 
>> header in SYS files?
> MOP headers no. But if you are referring to the .SYS files DEC distributed for things like DEC servers, which booted over MOP, those SYS files look like "normal" task files in RSX. Task files linked with no task header, though.
>
> Example:
> .tin sh1601ENG.SYS
> TIN V1.7
> Task name: SHAMRO Date: 21-MAY-96 Pri=0. Start=075000. EXTTSK=000000.
> Label block revision: 0.
> Task addresses - Low: 051000, W0 high: 177777, High: 177777 Load size: 02161400 Max size: 02161400 # of window blocks: 1.
> Task flags (040100): -HD -CHK
> Partition: SYSTEM Offset: 000000
> System ID: RSX-11M.
>
>
> TIN is a small program I wrote a long time ago to analyze task images under RSX.
>
> That file, for example, is for the DS300 (which has a 68000 CPU). And the RSX MOP server can service that file. VMS can serve it too. But this is totally outside the MOP protocol itself.
>
> The MOP protocol is documented in various places as well, so if you want that, you can find it. But the .SYS files are images that are served by MOP. They are not verbatim MOP data.
>
>    Johnny
>
>> Look at first 256 bytes of SYS files:
>>
>> 00000000: A8 00 30 00 44 00 58 00-00 00 00 00 30 32 30 35
>> |..0.D.X.....0205|
>>
>> 00000010: 01 01 00 00 FF FF FF FF-FF FF FF FF 00 00 00 00
>> |................|
>>
>> 00000020: 20 00 00 01 00 00 00 00-00 00 00 00 00 00 00 00  | 
>> ...............|
>>
>> 00000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>> |................|
>>
>> 00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>> |................|
>>
>> 00000050: 00 00 00 00 00 00 00 00-03 4D 4F 50 00 00 00 00
>> |.........MOP....|
>>
>> 00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>> |................|
>>
>> 00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>> |................|
>>
>> 00000080: 04 56 31 2E 30 00 00 00-00 00 00 00 00 00 00 00
>> |.V1.0...........|
>>
>> 00000090: 00 00 00 00 00 00 00 00-05 30 35 2D 30 35 00 00
>> |.........05-05..|
>>
>> 000000A0: 00 00 00 00 00 00 00 00-10 00 87 15 00 00 00 00
>> |................|
>>
>> 000000B0: 80 00 00 00 02 00 00 00-00 00 FF FF FF FF FF FF
>> |................|
>>
>> 000000C0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
>> |................|
>>
>> 000000D0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
>> |................|
>>
>> 000000E0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
>> |................|
>>
>> 000000F0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
>> |................|
>>
>> Thanks,
>>
>> Tim
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180223/329cd07c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180223/329cd07c/attachment.bin>