July 2002 - Oberon - mailman3.inf.ethz.ch

Native Minimal Reqmts
by Michael A. McGaw 29 Jul '02

29 Jul '02

Pieter: I understand your comments regarding 640X480 displays, yet, these are still very useful. I use the revised textframes to which you refer, and this helps a great deal. I would come at this with a bit of a different bent than most of what I have been reading, as my use for Native is for embedded work. As such, it is desireable to keep to as simple a set of common hardware as possible. Some of the things I've thought of: 1. Retain 640X480 display capability 2. Expand memory handling to beyond 128 MB 3. Add carefully to the list of supported Network Interface Cards I like the idea of a very minimal set of sources; here, I am thinking of the file set of the original Oberon system- on of the great virtues of Oberon, in contradistinction to other OSes of today is that one can get one's arms around it and know it (and therefore expand/extend/adapt it) with reasonable effort. Other systems are simply too large and byzantine for this to be the case. In this connection, I seem to recall a project known as Straw Hat that seemed to have this goal (a common root module set, deriving all other versions therefrom). What has become of this? My two cents. Mike

1 0

Re (2): [Oberon] test/confirm alpha 2001
by muller＠inf.ethz.ch 29 Jul '02

29 Jul '02

Felix Friedrich <friedrich(a)gsf.de> wrote: > In TextGadgets.FrameHandler replace the line > > ELSIF (beg < F.org) (FindStyle(F.text, F.org) # > F.trailer.next.obj) THEN > by > ELSIF (beg < F.org) & (F.trailer # NIL) & (F.trailer.next # NIL) & > (FindStyle(F.text, F.org) # F.trailer.next.obj) THEN How clean is the above fix? Did you take time to understand the code? It would be great if someone could get familiar with the internals of TextGadgets0 TextGadgets and fix some of the problems. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

2 1

Re: [Oberon] connect to ISP via dialup PPP with BlueBottle, how ?
by Edgar Schwarz 29 Jul '02

29 Jul '02

> Is there any plan to provide BlueBottle with a "wizard" that will, by > examining the environment in which it finds itself and asking the user, > be able to figure out everything it needs to know to establish a dialup > ppp connection with the user's ISP? Should at most be a matter of a day to provide for the basic functionality. This would mean getting some data in text fields of a panel and then merge it in Oberon.Text. Also naturally for changing an existing connection it should be possible to read data from Oberon.Text. Perhaps when I'm fed up with a serious problem I would do something easy for a while. OTHO if somebody would write such a panel I would happily include it in a new release. If you want the existing stuff for Bluebottle have a look at http://www.edgarschwarz.de/oberon. There you will find esaos.PPP.1.0.a.zip (63K). Any feedback welcome. Cheers, Edgar

2 1

Re: Re. [Oberon] New Oberon users bootstrap improvement project
by peter_easthope＠gulfnet.sd64.bc.ca 28 Jul '02

28 Jul '02

Chris & others, cg> That the vital F8 mouse-mode-toggle info is hidden inside of UserGuide.Text is problematic for old-time users. Are they really going to read the handbook for the fourth time ? Addendums or other special mechanism are appropriate ? Change logs. "http://www.oberon.ethz.ch/native/WebBeta.html" is titled "Beta version change log". At 04.12.00 is this note. "* Oberon.Mod - F8 toggles Oberon.New mouse handling. Oberon.New mode is default when two-button mouse is configured." So F8 has been documented on the Web since the beta release, 08.12.00, or so. Ideally, old-time users should be following the change logs as hawks, although I am certainly not diligent about it. Regards, P. Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Re (2): [Oberon] hardware requirements
by peter_easthope＠gulfnet.sd64.bc.ca 28 Jul '02

28 Jul '02

Pieter & others, pjm> search for "SYSTEM.Pentium" in *.Mod with Find.Panel . Digression: I get error messages when extracting Source1.zip and Source2.zip for the latest alpha, 23.06.2002. Retrieved a 2nd copy of each and still got errors. Source3.zip extracts OK. Is this problem specifically here? pjm> search for "SYSTEM.Pentium" in *.Mod with Find.Panel . OK; I see at least some of the occurences. Months ago there was discussion of documenting the operation of the cpu and Andre collected some draft commentary. Without this hypothetical document, adapting the kernel would be a daunting task for me. This isn't a complaint; merely an observation. In case any more work has been done on the cpu document I would be happy to study and submit new comments and questions. Thanks, Peter Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Re (2): [Oberon] hardware requirements
by peter_easthope＠gulfnet.sd64.bc.ca 28 Jul '02

28 Jul '02

Pieter & others, pjm> search for "SYSTEM.Pentium" in *.Mod with Find.Panel . Digression: I get error messages when extracting Source1.zip and Source2.zip for the latest alpha, 23.06.2002. Retrieved a 2nd copy of each and still got errors. Source3.zip extracts OK. Has anyone extracted these two zip files successfully? Thanks, Peter E. Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Re. [Oberon] New Oberon users bootstrap improvement project
by cglur＠onwe.co.za 28 Jul '02

28 Jul '02

Edgar Schwarz wrote: > Hi, > I followed the discussion abaout the problems of new Oberon users for a > while. > Now my view: > - If you successfully have installed an NO you will probably have a > tiled system with the following somewhere on your screen: > Script.Open System.Text > click middle mouse button (or double left) > on Script.Open above for introductory text > - This should be clear enough. In System.Text you find rather in the > beginning: > Script.Open UserGuide.Text > - This gives you the important hint: > <== Click left/right mouse button in bar to scroll up/down. > - Perhaps this already should be mentioned in the beginning of System.Text. > Another idea for the first page of System.Text could be something like: > If you have installed the Gadgets system and Documentation (?) (see > below) with > Desktops.OpenDoc OberonCompanion.Tool (aka Book.Tool) you can > access the electronic > version of 'The Oberon Companion', the book on Oberon System3. > > So, did I describe the status quo correctly ? > What's the problem with the existing stuff ? > What do you think of my proposals ? Yes the sequence seems to be well thought out. But writing a tutor is more problematic than writing software, because for every test run you need a new (set of) ignorant user(s). You can't reuse the 'test-users'. OK, so the sequence is like this: boot installation -> see prompt to: Script.Open System.Text -> see prompt to: Script.Open UserGuide.Text The new-user who manages this has got a vast amount of info available. Perhaps too much - overwhelming ? If for some reason there is an extra viewer open when (s)he does: Script.Open UserGuide.Text ; then the all important <== Click left/right mouse button in bar to scroll up/down. will be off-screen. The contents of UserGuide.Text should be very well familiar to the new user, before dealing with System.Text . The present sequence of a nested/stacked approach, could perhaps be replaced by a simple linear sequence structure ? I.e. go immediately to the UserGuide.Text. Perhaps put the "Keyboard , special key interpretations" after "Mouse Keys" and "Text Editing" ? It's much easier to analyse/criticise a tutorial than to write one. You don't need to be a chicken to appreciate an omlette ? One should not do what I did in trying to guide 'ghost': * get wound up and out of control because of clowns (even claimed long time users) who advocate killing mouse cording. * put attention/effort to an inividual instead of to the system/orginisation-of-global-users. ----------- The way forward is the way we got here: incremental well considered improvements. IMO the tweaks and additions made from Ver 2.3.6 up to alpha are excellent. That I got hysterical about the 'ape-MS mouse mode' of version alpha, is because no one would confirm (or deny) my belief that the developers would never have been so crazy. The F8 toggle facility is again a nice solution. {BTW this needs to be at the beginning of the user's tutorial.} That the vital F8 mouse-mode-toggle info is hidden inside of UserGuide.Text is problematic for old-time users. Are they really going to read the handbook for the fourth time ? Addendums or other special mechanism are appropriate ? -- Chris Glur. PS. I don't like this wording: "..the old style three-button commands, press the F8 key.."; unless it is understood as per: " your old style of walking before you became crippled".

1 0

Re: [Oberon] hardware requirements
by muller＠inf.ethz.ch 28 Jul '02

28 Jul '02

"Peter Easthope" <peter_easthope(a)gulfnet.sd64.bc.ca> wrote: > What are the advantages in excluding the 386? A 386-based system normally doesn't have a floating-point coprocessor. This is not a big problem, since Native Oberon has an emulator that seems to work reasonably well. The module just has to be linked with the boot file. You could try adding FPA after Kernel in the BootLinker.Link command in Native.Tool and then link and install a new boot file. > Alternatively, what are the disadvantages of > allowing Oberon to continue to operate on a 386? There is some ugliness required in the kernel to handle floating point exceptions on the 386, but it is not too serious. > The analogous questions apply to BlueBottle. > Is the requirement of a Pentium processor for a > specific technical requirement of the OS or is it > simply for a policy of encouraging use of current > hardware? The current floating-point emulator is not re-entrant and can not be used directly in Bluebottle. All Pentiums have the floating-point instructions built in. Otherwise, Bluebottle's kernel relies on the timing and caching instructions available on a Pentium. To see where, search for "SYSTEM.Pentium" in *.Mod with Find.Panel . It shouldn't be too difficult to adapt. "Yuri M. Skripkah" <yurix(a)i.com.ua> wrote: > I'm in deep sorrow what n-o (and bluebottle) not support wide range of hardware. > But really I can't make drivers or donate this work. Because I'll be > patient until someone make sort of HAL which can accept windows(tm) > drivers or I'll use hosted version. Unfortunately this won't change until more programmers start contributing to the project. Lisias Toledo <lisias(a)unforgettable.com> wrote: > Well, I still use a laptop with a 486dlc, VGA Monochrome and 4 megabytes > of memory... 8-P Native should work on this. Bluebottle potentially could (without the window manager), but the floating-point emulator would have to be ported. If anyone is interested in trying this, start with FPA.Mod from Native. Some interaction with Bluebottle's AosActive.Mod would be required, in the context switching code. > I know things will be a bit slow, but frankly : can't be worst than > Minix or even Linux 2.0 (Good Lord... 8-) I had tried before. If you stick to the basic Oberon system (TextFrames), it should work quite well. Even TextGadgets should be useable. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Displaying the current directory
by muller＠inf.ethz.ch 28 Jul '02

28 Jul '02

"Ghost in the Machine" <cangelich(a)famvid.com> wrote: > A "CWD" button wouldn't kill the looks of Oberon and might be a good > thing? Here's how to build it with Gadgets: 1. Click ML in a text gadget to set a caret. 2. Execute: Gadgets.Insert TextField CurrentDirectory ~ This generates a textfield gadget that has the current directory as an underlying model. It will always display the current directory. 3. Select the field with MR (it is shaded gray) and execute: 4. Columbus.Inspect ~ (this opens the columbus object inspector). 5. Enter "Dir" in the "Name" field. 6. Enter "System.ChangeDirectory &Dir.Value" in the "Cmd" field. 7. Click on "Apply". The text field will now execute the System.ChangeDirectory command every time you change the directory displayed in it. Copy the text field to your main .Tool text and store. A more advanced exercise would be to create the textfield in the System.Log menu bar. (Hint: requires editing TextDocs.Lib). > I think I can rewrite the > V24.Mod to support all 4 comports but I can't read the docs to learn how > to use the compiler. This would not be necessary, since André has already done it. It is in the latest Alpha version. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re: BlueBottle CD
by muller＠inf.ethz.ch 28 Jul '02

28 Jul '02

Hi Doug "Douglas G. Danforth" <danforth(a)greenwoodfarm.com> wrote: > I followed the CD download instruction with Nero and was not successful. > Booting from the created CD started with the cursor flashing in the > upper left hand corner and then a very brief message "loading oberon" (?) > before the screen went black (several shades of black seemed to occur). If the screen goes black, at least the video mode seems to work. > I have a Mitsubishi flat panel display which probable is one source > of difficulty. Should be ok since the boot CD uses a standard VESA mode initialized by the BIOS. > All I really want to do at this point is simply to "see" what Bluebottle > looks like. Is there any other way to view it without having to > "partition" some disk? The boot CD would be the best way to do it. There are some screenshots at http://bluebottle.ethz.ch/wm/gallery.html, but this does not really give you a "feel" of the system. Of course you can also boot the normal Oberon environment on Bluebottle, either in a window, or full-screen. To find the booting problem, you could try tracing the booting: 1. Connect a null-modem cable between your PC and another PC or serial terminal, configured to 19200 bps, 8 bits, no parity, 1 stop bit. 2. Hold down shift during booting so you get the OBL> prompt. 3. Enter: TraceMode=4 4. Enter: c (to continue booting) The serial terminal should show trace output from the boot process, and perhaps a trap which can indicate the problem. cheers -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0