Talk:File Formats: Difference between revisions

From NDWiki
Jump to navigation Jump to search
(→‎Boot loaders: new section)
m (boot loaders. Octal load)
 
Line 64: Line 64:


<references/>
<references/>
:I have only seen octal load (or octal format load, as it's sometimes written) in the NORD-10 and NORD-12 documentation. It's not mentioned in the NORD-1 ref manual. But we may just be missing out on documentation. -- [[User:TArntsen|TArntsen]] ([[User talk:TArntsen|talk]]) 13:34, 21 April 2019 (UTC)

Latest revision as of 13:34, 21 April 2019

The :PROG file format

As far as I know the layout is as follows:

H1: 1 256-word (512-byte) header block
N : N 256-word blocks, up to a maximum of 255 blocks
H2: 1 256-word (512-byte) header block, starting at 
      file byte offset 0x20000 (or 131072)
M : M 256-word blocks, starting at file byte offset 0x20200, 
      up to a maximum of either 255 or 256 blocks (TBD).

The 'H2' and 'M' sections are optional (used for 2-bank programs only).

Header block layout

Start address    : 16-bit word, big endian
Restart address  : 16-bit word, big endian
First address B1 : 16-bit word, big endian
Last address  B1 : 16-bit word, big endian
First address B2 : 16-bit word, big endian
Last address  B2 : 16-bit word, big endian

First address is where in the memory map of the (bank1/bank2) segment the image data (N or M) should be loaded, and the number of words to load is:

(Last address - First address) + 1

For 1-bank programs First address B2, Last address B2 are always 0xffff 0x0000, indicating no data. In this case there will be no H2/M sections in the :PROG file.

2-bank programs will often have a hole (unallocated disk pages) in the :PROG file, after end of N and start of H2, because H2 always starts at byte offset 0x20000. Also note that because of this, and the header block, a :PROG file cannot have a bank 1 larger than 256 words less than the maximum ND-100 virtual memory size (64Kw). Bank 2 can be a full 64Kw.

(Because of the possibility for a hole in 2-bank :PROG files, care must be taken when copying such files over from a Norsk Data system to somewhere else. The FTP program, for example, will mishandle the file.)

Example: 2-Bank program

(this is actually a version of the BRF-LINKER)

Start address    : 026111
Restart address  : 026111
First address B1 : 0
Last address  B1 : 071560
First address B2 : 0
Last address  B2 : 024263

This is a 2-bank program. To load the file, prepare two 64-kiloword areas (the first shall be accessed through the normal page table, the second through the alternative page table. The application will call Mon ALTON early on, to enable the alternative page table.) Copy ((071560 - 0) + 1) * 2 bytes from byte offset 512 in the :PROG file into area 1, at offset 0 and onwards. Copy ((024263 - 0) + 1) * 2 bytes from byte offset 131584 (which is 131072+512) in the :PROG file into area 2, at offset 0 and onwards. The application shall start execution from address 026111.

Example: 1-Bank program

Start address    : 0177777
Restart address  : 0177775
First address B1 : 0145000
Last address  B1 : 0177777
First address B2 : 0177777
Last address  B2 : 0

This is a 1-bank program. Prepare a 64-kiloword area. Copy ((01777777 - 0145000) + 1) * 2 bytes from byte offset 512 in the :PROG file into the area, at offset 0145000 and onwards. Nothing is loaded into low memory (below address 0145000) in this case. The application shall start execution from address 0177777 (and that will have to be a JMP instruction with negative displacement, as it is the last word in the address range). TArntsen 20:56, 31 July 2009 (UTC)

Sounds great! I have nothing to add and I think it should be included in the main article. Oh, I have one thing to add, I just saw that :PROG files often is indexed so that there is a large offset to the 2-bank program start does not mean that there is a lot of wasted space on the disk. Unused pages in indexed files doesn't need to be allocated.
Gandalf 12:01, 2 August 2009 (UTC)
That's right, that's what I meant by the "hole" I mentioned :-) Maybe that could be addressed in a clearer way.
TArntsen 12:14, 2 August 2009 (UTC)

I found an error in my first description. For 2-bank programs the first 256 words in the part of the file that holds the second bank data will also be a header (dummy header in this case). So the actual second bank data starts at file offset 131072 + 512, not 131072. I have updated my original description to reflect this, and also mentioned unallocated disk pages. There are one or two more things I want to confirm too before this is ready to be moved to the main article. TArntsen 12:10, 9 August 2009 (UTC)

I removed a TBC after verifying with the BRF linker that bank 2 can indeed be a full 64 kilowords. I'm ready to copy the info into the main article (with some improvements, e.g. 'Header 1, Bank 1' instead of 'H1, N'). But it's a bit long, should it be in its own page, perhaps? With a link from the File Formats page? TArntsen 16:24, 26 April 2011 (CEST)

Boot loaders

The section about boot loaders[1] states: "Octal load is not implemented in ND-100". Which machines had octal load? Only NORD-10? Torfinn 21:01, 20 April 2012 (UTC)

  1. Norsk Data Document ND–06.015.02 ND-100 FUNCTIONAL DESCRIPTION Chapter 7.2.5
I have only seen octal load (or octal format load, as it's sometimes written) in the NORD-10 and NORD-12 documentation. It's not mentioned in the NORD-1 ref manual. But we may just be missing out on documentation. -- TArntsen (talk) 13:34, 21 April 2019 (UTC)