February 2008 - Oberon - mailman3.inf.ethz.ch

New BB/AOS release
by Stauber Sven Philipp 28 Mar '08

28 Mar '08

Dear Oberon Users, BB/AOS revision 763 has been released. Note that starting with this release, we won't provide detailed change logs on the Bluebottle website anymore. Instead, you can get read-access to the AOS/WinAOS source code repository if you want to see what exactly has been changed (see www.ocp.inf.ethz.ch for details). Releases will, however, always be announced on this list. Best Regards, Sven Stauber

2 3

RE: [Oberon] video configuration for a Toshiba 205CDS.
by Treutwein Bernhard 20 Feb '08

20 Feb '08

Hi Peter, [...] > Init=bb0501b8024fcd10 > Strings for other chips are noted at the end of > SVGA.Display.Mod. > How can the Init string for the CT65550 be constructed? some stuff on the following page might help you in contructing the init string: http://www.asiliant.com/65550.htm Especially what Asiliant calls the data sheet i.e. http://www.asiliant.com/pdf/ds177_5.pdf appears to contain the relevant information ... regards -- Bernhard Treutwein > -----Original Message----- > From: PETER EASTHOPE [mailto:peasthope@shaw.ca] > Sent: Wednesday, February 20, 2008 12:00 AM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] video configuration for a Toshiba 205CDS. > > > Folk, > > Native Oberon is installed on a Toshiba 205CDS laptop. > The video chip is a CT65550 which supports VESA 2.0. > The machine lacks a floppy drive; video must be > configured with config strings rather than with Config > in Oberon0. > > The last two sections of "http://www.oberon.ethz.ch/display.html" > seem pertinent but I miss a few details. > > Should these strings be set? > Display="Displays." > DDriver="SVGA" > Or just this one? > Display="SVGA" > [Documentation for DDriver along with Display > would be helpful.] > > The example in the Web page refers to an IBM 760ED > with this Init string. > Init=bb0501b8024fcd10 > Strings for other chips are noted at the end of > SVGA.Display.Mod. How can the Init string for the CT65550 be > constructed? > > Thanks, ... Peter E. > > > http://carnot.yi.org/ > > > >

1 0

video configuration for a Toshiba 205CDS.
by PETER EASTHOPE 19 Feb '08

19 Feb '08

Folk, Native Oberon is installed on a Toshiba 205CDS laptop. The video chip is a CT65550 which supports VESA 2.0. The machine lacks a floppy drive; video must be configured with config strings rather than with Config in Oberon0. The last two sections of "http://www.oberon.ethz.ch/display.html" seem pertinent but I miss a few details. Should these strings be set? Display="Displays." DDriver="SVGA" Or just this one? Display="SVGA" [Documentation for DDriver along with Display would be helpful.] The example in the Web page refers to an IBM 760ED with this Init string. Init=bb0501b8024fcd10 Strings for other chips are noted at the end of SVGA.Display.Mod. How can the Init string for the CT65550 be constructed? Thanks, ... Peter E. http://carnot.yi.org/

1 0

Re: AW: [Oberon] Re. cloning a filesystem or an OS.
by PETER EASTHOPE 15 Feb '08

15 Feb '08

Chris, Sven and others, Thanks for the comments. ss> ... there's a lot of metadata on a filesystem. ... ss> Bootfile: Currently, there is no operation that extracts the boot file from a partition, but this could be done. ss> Bootloader: ... In light of everything explained, only two methods are feasible. * If the two parts are the same size use part -> file -> part. * Otherwise do enough of the conventional installation to get at least the filesystem, bootloader and bootfile installed on the target. Then mount the source and target parts and copy files. For an OS, this is not strict cloning because the bootloader and bootfile are not cloned. Additional Remarks cg> ... the destination-partition would then just contain 1 file, albeit a big-file derived from a whole partitition. We are at crossed purposes. The image file must reside on a third part. Cloning of the source is not complete until the image is copied to the target with the second command. Partitions.FileToPartition IDEt#n ImageFile ~ cg> ... bootloader is not part of the Oberon clone. ... applicable to all the installd OSs? The experts can correct me. In Oberon, boot manager and bootloader are distinct. The boot manager is BootMan, written by Andr Fischer; bootloader is OBL, written by Pieter Muller. The same OBL is used for Aos. In Linux, manager and bootloader are combined; and there is more than one package to choose from. Lilo, Grub & etc. Ref. also http://www.oberon.ethz.ch/bootstrap.html (A glossary might help.) ss> Currently, there is no operation that extracts the boot file ... The old question of inverse procedures. Given the existence of Partitions.UpdateBootFile one might expect to find a Partitions.ExtractBootFile also. I understand partially why it wasn't written. Terminology: BootFile is really not a good name. Once installed it is not a file. BootCode, BootImage, BootProcedure or BootSequence would be better. Regards, ... Peter E. http://carnot.yi.org/

1 0

Re. cloning a filesystem or an OS.
by Chris Glur 15 Feb '08

15 Feb '08

PETER EASTHOPE wrote- > This should apply equally to NO and Aos and > at least partially to other systems. > > Back in February of 2002 Bernhard Treutwein > mentioned cloning a system; the primary focus > was on FAT filesystems. > > At the part level, provided both parts are > the same size and there is enough space for > an image file elsewhere, this works and is > documented. > Partitions.PartitionToFile IDEs#m ImageFile ~ > Partitions.FileToPartition IDEt#n ImageFile ~ > > If the source is smaller than the target, I'm not > sure the residual space on the target will be > useable. Yes useable, since the destination-partition would then just contain 1 file, albeit a big-file derived from a whole partitition. Since IDE's are so big lately, I've got a 'Configuration.DoText BakAll2Sgt80' script which copies all my 16 [except SYS:] partns to a BIG bakup-partn. as 16 files. > If the source is larger than the > target, the second command ends with a trap and > the target filesystem is likely broken. Well I guess that's like writing to a partn, which overflows; which has happened to me. But AFAIK only the last failed store was lost. And I then use the corresponding *.Bak. > Copying all files from one Aos filesystem to > another is easy using these commands. > System.Directory Source:* ~ > FileSystem.GenCopyFiles Source: Target: > ... > ~ And here too, if the target filled up before the sequnce of 'System.CopyFiles' completed, I guess that only the last one would be 'lost'. > But if the objective is to clone an OS, copying > files won't copy the bootloader and the inverse > of !Partitions.UpdateBootFile is not obvious. As I see it, the bootloader is not part of the Oberon clone. It's part of the 'computer' -- applicable to all the installed OSs? I've never graduated to using a [non-fd0, smart bootloader], [like I've never 'stabilised' to use linux as root: the continual changes needed means that I can't settle into using non-root permission] smart bootloader A single computer/disk-system can contain several OSs and clones of OSs. Only ONE of which is selected at boot time. My one box can boot [via grub] to 'a' linux and Wxx. All the other linux-es need fd0 booting. The theory of having [only] the latest is marketing garbage. Real life is that when you install the latest version [eg. of linux] you won't be able to do some thing that you occasionally did in version n-2, which task you will only need after 6 months. The reality is that you must 'drive without a bonnet & be prepared to slot-in other parts at any time'. I'll have a look at !Partitions.UpdateBootFile tomorrow; especially since I've now got a 'colour-each-block/construct -differently-to-help-analyse-code' and Partitions.Mod has got nice/clean code from what I've previously read/modified-extended. I'm guessing that a 'bootloader' is placed in the MBR. This is rather drastic ! > So can anyone help with these questions. > * In the partition method, can the problems of > differing source and target sizes be solved? > Ie., can the filesystem be extended in the first > discrepancy and terminated properly in the second? > sourceSize < targetSize ==> spare space available for other file[s] targetSize < sourceSize ==> expect a trap. Obviously it can't DO targetSize = sourceSize: perhaps achievable when both have the same number of [512 byte sized - I think] blocks. > * In the filesystem method, can the BootFile be > extracted from an executable part? I'll guess > that with the correct block numbers > Partitions.PartitionToFile dev#part file [block blocks] ~ > and some editing might work. > If there are any constructive answers, please > consider adding them to your Web based documentation. I've got a lot of documentation & some experience with x86-bootloaders. Let's first see some other contributors. Long ago I got no reply to my query about the 'disassembler tool' which had some bugs but was remarkable. Now "sem" finds nothing relevant in *.Tool We need to work at asm-level to analyse the MBR. There are other disassemblers available, but it's nice to be able to stay in ETH-oberon, to just paste the work-log for later emailing. == Chris Glur.

2 1

cloning a filesystem or an OS.
by PETER EASTHOPE 15 Feb '08

15 Feb '08

Folk, This should apply equally to NO and Aos and at least partially to other systems. Back in February of 2002 Bernhard Treutwein mentioned cloning a system; the primary focus was on FAT filesystems. At the part level, provided both parts are the same size and there is enough space for an image file elsewhere, this works and is documented. Partitions.PartitionToFile IDEs#m ImageFile ~ Partitions.FileToPartition IDEt#n ImageFile ~ If the source is smaller than the target, I'm not sure the residual space on the target will be useable. If the source is larger than the target, the second command ends with a trap and the target filesystem is likely broken. Copying all files from one Aos filesystem to another is easy using these commands. System.Directory Source:* ~ FileSystem.GenCopyFiles Source: Target: ... ~ But if the objective is to clone an OS, copying files won't copy the bootloader and the inverse of Partitions.UpdateBootFile is not obvious. So can anyone help with these questions. * In the partition method, can the problems of differing source and target sizes be solved? Ie., can the filesystem be extended in the first discrepancy and terminated properly in the second? * In the filesystem method, can the BootFile be extracted from an executable part? I'll guess that with the correct block numbers Partitions.PartitionToFile dev#part file [block blocks] ~ and some editing might work. If there are any constructive answers, please consider adding them to your Web based documentation. Thanks, ... Peter E. http://carnot.yi.org/

1 0

ANN: UnixAos rel. 0.71 (Linux, MacOSX, Solaris)
by Guenter Feldmann 13 Feb '08

13 Feb '08

Hi the Unix ports of Aos (release 0.71) are ready for download from http://www.informatik.uni-bremen.de/~fld The sources are not included this time but will be available soon form the svn repository at ETHZ (https://www.ocp.inf.ethz.ch/svn/aos) New in release 0.71: - Based on the Bluebottle sources of 11.02.2008 - Converted some low level modules to upper case keywords to reanable the the original fieldnames in the structure ModuleDesc (type, module, ... ). This made a couple of port specific modules superfluous. - Fixed BootLinker to allow active objects in core modules + code cleanup. (Unix/BootLinker.Mod, Unix/Objects.Mod, Unix/AosStarter.Mod) - Fixed Unix/AosUnixFiles.Mod. AosFS.Enumerate no longer delivers some files multiple times. If a filename exists in multiple directories of the environment variable OBERON the hidden ones get omitted. - It is now possible to create standalone Oberon applications. A small demo program is included (see StandaloneOberonAppl.Text ). -- Guenter

1 0