Talk:File Formats - Revision history

TArntsen: boot loaders. Octal load

2019-04-21T13:34:02Z

boot loaders. Octal load

← Older revision		Revision as of 13:34, 21 April 2019
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)

Tingo: /* Boot loaders */ new section

2012-04-20T21:01:02Z

Boot loaders: new section

← Older revision		Revision as of 21:01, 20 April 2012
Line 58:		Line 58:
	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. [[User:TArntsen\|TArntsen]] 12:10, 9 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. [[User:TArntsen\|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? [[User:TArntsen\|TArntsen]] 16:24, 26 April 2011 (CEST)		: 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? [[User:TArntsen\|TArntsen]] 16:24, 26 April 2011 (CEST)

			== Boot loaders ==

			The section about boot loaders<ref>{{ND-doc\|06.015.02\|Chapter 7.2.5}}</ref> states: "Octal load is not implemented in ND-100". Which machines had octal load? Only NORD-10? [[User:Tingo\|Torfinn]] 21:01, 20 April 2012 (UTC)

			<references/>

TArntsen: Q: Moving to main article?

2011-04-26T14:24:41Z

Q: Moving to main article?

← Older revision		Revision as of 14:24, 26 April 2011
Line 57:		Line 57:

	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. [[User:TArntsen\|TArntsen]] 12:10, 9 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. [[User:TArntsen\|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? [[User:TArntsen\|TArntsen]] 16:24, 26 April 2011 (CEST)

TArntsen: Removing TBC.

2011-04-26T14:15:40Z

Removing TBC.

← Older revision		Revision as of 14:15, 26 April 2011
Line 23:		Line 23:
	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.		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 ~~in principle~~ be a full 64Kw ~~(TBC)~~.		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.)''		''(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.)''

TArntsen: Correction for 2-bank progs

2009-08-09T12:10:49Z

Correction for 2-bank progs

← Older revision		Revision as of 12:10, 9 August 2009
Line 1:		Line 1:
	==The :PROG file format==		==The :PROG file format==
	As far as I know the layout is as follows:		As far as I know the layout is as follows:
	1 256-word (512-byte) header block		H1: 1 256-word (512-byte) header block
	N 256-word blocks, up to a maximum of 255 blocks		N : N 256-word blocks, up to a maximum of 255 blocks
	M 256-word ~~blocks~~, starting at file byte offset 0x20000 (or 131072),		H2: 1 256-word (512-byte) header block, starting at
	up to a maximum of 256 blocks		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 'M' ~~section is~~ optional (used for 2-bank programs only).		The 'H2' and 'M' sections are optional (used for 2-bank programs only).

	===Header block layout===		===Header block layout===
Line 19:		Line 21:
	(Last address - First address) + 1		(Last address - First address) + 1

	For 1-bank programs '''First address B2''', '''Last address B2''' are always 0xffff 0x0000, indicating no data. ~~1-bank programs don't have a section~~ '''M''' in the :PROG file ~~either~~.		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 in the :PROG file, after end of '''N''' and start of '''M''', because '''M''' always ~~start~~ 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.		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 in principle be a full 64Kw (TBC).

	''(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.)''		''(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.)''
Line 34:		Line 36:
	Last address B2 : 024263		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 131072 in the :PROG file into area 2, at offset 0 and onwards.		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.		The application shall start execution from address 026111.

Line 53:		Line 55:
	:: That's right, that's what I meant by the "hole" I mentioned :-) Maybe that could be addressed in a clearer way.		:: That's right, that's what I meant by the "hole" I mentioned :-) Maybe that could be addressed in a clearer way.
	::[[User:TArntsen\|TArntsen]] 12:14, 2 August 2009 (UTC)		::[[User:TArntsen\|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. [[User:TArntsen\|TArntsen]] 12:10, 9 August 2009 (UTC)

TArntsen: Quick reply/indexed files

2009-08-02T12:14:17Z

Quick reply/indexed files

← Older revision		Revision as of 12:14, 2 August 2009
Line 46:		Line 46:

	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).		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).

	[[User:TArntsen\|TArntsen]] 20:56, 31 July 2009 (UTC)		[[User:TArntsen\|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.		: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.
	:[[User:Gandalf\|Gandalf]] 12:01, 2 August 2009 (UTC)		:[[User:Gandalf\|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.
			::[[User:TArntsen\|TArntsen]] 12:14, 2 August 2009 (UTC)

Gandalf: Short answer

2009-08-02T12:01:26Z

Short answer

← Older revision		Revision as of 12:01, 2 August 2009
Line 48:		Line 48:

	[[User:TArntsen\|TArntsen]] 20:56, 31 July 2009 (UTC)		[[User:TArntsen\|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.
			:[[User:Gandalf\|Gandalf]] 12:01, 2 August 2009 (UTC)

TArntsen: PROG file format: Throwing in my notes for review or comments.

2009-07-31T20:56:46Z

PROG file format: Throwing in my notes for review or comments.

New page

==The :PROG file format==
As far as I know the layout is as follows:
1 256-word (512-byte) header block
N 256-word blocks, up to a maximum of 255 blocks
M 256-word blocks, starting at file byte offset 0x20000 (or 131072),
up to a maximum of 256 blocks

The 'M' section is 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. 1-bank programs don't have a section '''M''' in the :PROG file either.

2-bank programs will often have a hole in the :PROG file, after end of '''N''' and start of '''M''', because '''M''' always start 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 131072 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).

[[User:TArntsen|TArntsen]] 20:56, 31 July 2009 (UTC)