Talk:File Formats: Difference between revisions
(PROG file format: Throwing in my notes for review or comments.) |
(Short answer) |
||
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) |
Revision as of 12:01, 2 August 2009
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).
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)