DataMuseum.dkPresents historical artifacts from the history of: CR80 Hard and Floppy Disks |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CR80 Hard and Floppy Disks Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - download
Length: 4872 (0x1308) Types: TextFile Names: »RELDESCR.T«
└─⟦e0c43619c⟧ Bits:30005797 CR80 Disc pack ( Vol:FNJ1 861029/EC CR80 S/W Package II+III+IV+V+VII ) └─ ⟦this⟧ »CSP005_V0501.D!CSS305.D!RELDESCR.T«
Release description. ==================== Module id number: CSS/305 CSS/360 CSS/307 Module name: ROOT ( + MEMMGR, + RTC) Actual release: 1001 Release date: 820501 Previous release: 0901 Release date: 810801 New facilities: >> Release 1001 << Support of XAMOS. The RANGE field, defined in vs.0901 as part of the process header, must now be given to MEMMGR as word 5 of the ALLOCATE message. If this field is zero, #0F00 (page #0) is assumed for program allocation, and #3F00 (any page) is assumed for date allocation. If the field is non-zero, but the actual CPU is not an XAMOS CPU, program allocation is still done in page 0. The allocation strategy is now: - allocation is tried outside page 0, in the memory of the specified CPU if not successfull - allocation is tried in page 0, in the memory of the specified CPU if not successfull - allocation is tried outside page 0, in the memory of any CPU if not successfull - allocation is tried in page 0, in the memory of any CPU if not successfull - a bad completion code is returned Allocation is considered successfull, if at least one hole is found in the given range, from which the wanted memory can be allocated. If more than one such hole is found, the smallest is selected. Memory is allocated from the start of this hole. >> Release 0901 << This release is composed of the versions 0501 of the standard ROOT, and 0600, 0700, 0800 of the CR801 ROOT . Highlights : * The code parts of a boot module are packed in section zero. This means that there is no waste of code space, from loading a boot module. * Memory allocation is performed in chunks of 128 words. (In Release 0501 the chunk size was 256 words). This implies that the memory table occupies 2K of data space. (Release 0501, 1K) However, if there are more than 16 processes in the system, some space is gained. * Program version numbers are output in decimal. * A possibility to specify a range in which a process must be laid out, is implemented. The purpose of this facility is to help the layout of processes with special memory demands, e.g CDC Disk drivers, File System etc. The facility is used in the following way : Location 18 of a process header may define a range of 4K modules in which the process must be laid out. The upper byte of this location defines the top limit, and the lower byte defines the bottom limit. The range is defined as : Lower-byte * 4K .. ((Upper-byte + 1) * 4K) - 1 If there is not enough free space in the range to lay out the process, ROOT gives the error message 3 and terminates by loading the AMU process. Example : Location 18 of process header : ---------------- | 1 7 | 1 0 | ---------------- top bottom This contents implies that the process must be laid out somewhere in the lower 32 K of memory section 1. At present the only way to insert the value into the process header, is to patch▶16◀▶16◀▶16◀ it. >> Release 0501 << ROOT prepared for execution outside page zero. RTC process included into ROOT, and created directly by ROOT, so RTC module should not be used in boot modules containing this version of ROOT. Changes: >> Release 1001 << The memory fill pattern is changed from #A7A7 to #E1E1, as the former pattern is a legal XAMOS instruction. >> Release 0901 << Some of the facilities from the CR801 versions have been disabled : * It is not possible to disable the initial print from ROOT. * Setting of baud rate to 1200 baud is disabled. * The process 'FILSYS' is not forced to lie in memory section 3. Errors corrected: >> Release 0901 << * If the ROOT process was running in section one, and there were too many Message buffers, Process Control Blocks or Region Control Blocks in the system, process layout would terminate in error. This error has only been a problem to the DORA project group. * When the RTC was started, it would destroy 4 locations outside its own process space. * In the CR801 versions (0600, 0700, 0800) it was not possible for ROOT to layout processes in memory section zero. >> Release 0501 << RTC module : At reception of messages, even the global RTC is updated Reported errors, not corrected: Comments: