Difference between revisions of "F.A.Q."
From MorphOS Library
(Created page with '''I'm installing MorphOS and the installation script requires that I create and format two partitions: one very small FFS partition for the boot.img file, and one larger, bootabl…') |
(Reintroduced italic, and updated a bit the content of the first answer to reflect support of minis requiring again the small partition) |
||
| Line 1: | Line 1: | ||
| − | ''I'm installing MorphOS and the installation script requires that I create and format two partitions: one very small FFS partition for the boot.img file, and one larger, bootable, possibly SFS, partition for system files. You said only one is necessary.'' | + | ''I'm installing MorphOS and the installation script requires that I create and format two partitions: one very small ''FFS'' partition for the ''boot.img'' file, and one larger, bootable, possibly ''SFS'', partition for system files. You said only one is necessary.'' |
| − | This behaviour of MorphOS installation procedure is justified by the necessity to be compatible with the past. Old versions of the HAL/OF were able to manage only FFS partitions. So the boot.img was put in a FFS partition to let the HAL/OF be able to run it. On the other hand, it was/is better to put system files on a SFS partition, due to its higher reliability. New versions of the HAL/OF can read SFS partitions, and PFS partitions as well, so you can put everything on a single reliable partition. | + | This behaviour of MorphOS installation procedure is justified by the necessity to be compatible with the past. Old versions of the HAL/OF were able to manage only ''FFS'' partitions. So the ''boot.img'' was put in a ''FFS'' partition to let the HAL/OF be able to run it. On the other hand, it was/is better to put system files on a ''SFS'' partition, due to its higher reliability. New versions of the HAL/OF can read ''SFS'' partitions, and ''PFS'' partitions as well, so you can put everything on a single reliable partition. A notable exception is the installation of MorphOS on a supported Apple Mac machine. The Open Firmware of these machines only supports booting from ''HFS'' or ''HFS+'' partitions, therefore the creation of a very small partition for the ''boot.img'' file is again mandatory, as explained in the [[Dual-boot MorphOS and MacOS X on a Mac Mini G4]] guide. |
| − | ''You said that Quark and other low-level software are compressed in the boot.img file. Compressed?'' | + | ''You said that ''Quark'' and other low-level software are compressed in the ''boot.img'' file. Compressed?'' |
| − | The boot.img file is a gzip archive, the real image file (e.g. bootpegasos2rom.img) is inside and is extracted and run by the HAL/OF. | + | The ''boot.img'' file is a gzip archive, the real image file (e.g. ''bootpegasos2rom.img'') is inside and is extracted and run by the HAL/OF. |
| − | ''You said that in earlier versions of this article that Quark supports memory protection and virtual memory, but it seems these features are not active.'' | + | ''You said that in earlier versions of this article that ''Quark'' supports memory protection and virtual memory, but it seems these features are not active.'' |
| − | Memory protection did not exist in the AmigaOS, and is not implemented within the ABox of MorphOS for compatibility reasons (almost all the legacy applications would not be able to run correctly with memory protection). On the other hand, memory protection is usable within the QBox and might be available for future applications especially designed for QBox in case a migration of hardware drivers from ABox to QBox will take place. Virtual memory was implemented in the beginning of MorphOS development, but its upgrade is currently halted, due to very low priority. In fact, the maximal RAM requirements of MorphOS and native/legacy programs are very small in comparison with the usual RAM sizes currently available. | + | Memory protection did not exist in the AmigaOS, and is not implemented within the ''ABox'' of MorphOS for compatibility reasons (almost all the legacy applications would not be able to run correctly with memory protection). On the other hand, memory protection is usable within the ''QBox'' and might be available for future applications especially designed for QBox in case a migration of hardware drivers from ''ABox'' to ''QBox'' will take place. Virtual memory was implemented in the beginning of MorphOS development, but its upgrade is currently halted, due to very low priority. In fact, the maximal RAM requirements of MorphOS and native/legacy programs are very small in comparison with the usual RAM sizes currently available. |
Latest revision as of 18:45, 7 December 2009
I'm installing MorphOS and the installation script requires that I create and format two partitions: one very small FFS partition for the boot.img file, and one larger, bootable, possibly SFS, partition for system files. You said only one is necessary.
This behaviour of MorphOS installation procedure is justified by the necessity to be compatible with the past. Old versions of the HAL/OF were able to manage only FFS partitions. So the boot.img was put in a FFS partition to let the HAL/OF be able to run it. On the other hand, it was/is better to put system files on a SFS partition, due to its higher reliability. New versions of the HAL/OF can read SFS partitions, and PFS partitions as well, so you can put everything on a single reliable partition. A notable exception is the installation of MorphOS on a supported Apple Mac machine. The Open Firmware of these machines only supports booting from HFS or HFS+ partitions, therefore the creation of a very small partition for the boot.img file is again mandatory, as explained in the Dual-boot MorphOS and MacOS X on a Mac Mini G4 guide.
You said that Quark and other low-level software are compressed in the boot.img file. Compressed?
The boot.img file is a gzip archive, the real image file (e.g. bootpegasos2rom.img) is inside and is extracted and run by the HAL/OF.
You said that in earlier versions of this article that Quark supports memory protection and virtual memory, but it seems these features are not active.
Memory protection did not exist in the AmigaOS, and is not implemented within the ABox of MorphOS for compatibility reasons (almost all the legacy applications would not be able to run correctly with memory protection). On the other hand, memory protection is usable within the QBox and might be available for future applications especially designed for QBox in case a migration of hardware drivers from ABox to QBox will take place. Virtual memory was implemented in the beginning of MorphOS development, but its upgrade is currently halted, due to very low priority. In fact, the maximal RAM requirements of MorphOS and native/legacy programs are very small in comparison with the usual RAM sizes currently available.