Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 134967 times)

Description:

0 Members and 4 Guests are viewing this topic.

Offline kamelito

Re: Os 3.2 development preview
« Reply #299 from previous page: November 25, 2019, 09:38:25 PM »
Maybe you could make a debug version of the KS that include a Romable Cop that could be triggered using an NMI (using a key or combination of keys) and that trap all exceptions and trigger the monitor during a crash.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #300 on: November 26, 2019, 07:43:47 AM »
Maybe you could make a debug version of the KS that include a Romable Cop that could be triggered using an NMI (using a key or combination of keys) and that trap all exceptions and trigger the monitor during a crash.
You don't need a custom ROM for that. You can do that right away. COP is triggered during a crash all fine, and the custom key combination is the decimal dot on the numeric keypad. So all you need is available at this point. (-:
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #301 on: November 26, 2019, 08:56:15 AM »

Another episode: System-Startup

This is a new ROM component. It can be roughly compared to the init process on Unix machines as it is the first process created by the dos.library. Formerly, the dos.library created the shell, and the shell had to fiddle out what to do with a rather mysterious and undocumented process, and then had to call CliInit(). Now, System-Startup is created right away, and everything that was in CliInit() is now part of System-Startup. At the end of its doing, System-Startup creates the "Initial CLI" and thus boots the system.

So what does Sytem-Startup do?

It first creates and initializes intuition (but see below) and places its library vector in the dos.library and the GlobVec (yuck, we still have it). It then initializes some structures of the dos.library and creates the initial task table (the list of CLIs, none at this point), and then creates the device nodes from the mounted devices that left boot nodes in expansion, i.e. those expansion boards the system can boot from.

Then, it initializes the filesystem and places it in the dos.library. Here is the first difference: If a newer file system has been loaded from RDB, it will be used instead and replace the ROM file system. Thus, if you have an FFS 47 on harddisk, FFS 47 will also be used for your floppy.

It then creaets mount entries for PRT:, PAR: and SER: which go to "L:Port-Handler", as ever. As a new activity, it *also* creates a mount entry for "PIPE:" which goes to "L:Queue-Handler", so you don't have to mount the queue handler manually and can use the "|" (pipe symbol) already in  the initial CLI without mounting PIPE: first.

It then starts the file system of the boot volume and creates all the standard system assigns, L:, FONTS:; DEVS:, LIBS:, S:, C:, SYS: and ENVARC:, and then starts all other volumes that have been recorded in expansion.

After that, it mounts CON:, the con-handler, and creates the mount entries for CON: and RAW:. A new feature is that it checks whether the boot volume or any other volume contains a newer version of L:con-handler, and if so, uses that instead. Thus, the con-handler for the initial CLI may come from disk.

The same goes for RAM: and RAM-Handler, which may also reside on disk as a newer version and then replaces the ROM version, and for the Shell, which is either taken from ROM, or from L:Shell-Seg if one of the volumes mounted so far contains a newer version of it.

For the shell, it then creates the resident-entries "Shell", "BootShell" and "CLI", corresponding to the default user shell with C entry, the boot shell C entry, and the BCPL entry of the shell. They all point to the same shell at this point.

Then, the system checks for available updates on disks, which is a new feature. Thus, for every ROM module not yet initialized System-Startup now checks whether there is a corresponding module on disk that could replace it because it has a newer version. I.e. "DEVS:audio.device" would replace the ROM-based audio.device if it is newer.

For intuition, we have to use a special trick because it is already initialized. 3.2 will come with intuition 47 in ROM. For those that need to use CyberGfx, System-Startup checks the boot volume - and only there - for intuition v40 in LIBS:, or a newer version of intuition everywhere else. If a newer intuition or intuition v40 is found, the exiting copy of intuition is expunged from memory - intuition V47 can be made shutdown, a new feature - and a new intuition is build and installed.

If the boot monitor was DBLPAL or DBLNTSC, System-Startup "enlightens" now the system to use AGA modes, such that the boot shell can also use these new resolutions. This was done by SetPatch before.

Finally, all remaining ROM modules flagged as "AutoInit" are initialized.

The code then opens the CON: window for the boot shell, and S:Startup-Sequence. If flagged in the boot menu, System-Startup initiates another new module, "syslog". I will talk about "syslog" later.  Last but not least, it creates the boot shell with System(), the new functionality I talked about yesterday:

Code: [Select]
SystemTags(NULL,       
SYS_Input,consolestream, /* CON:///-1/AmigaDOS/Auto/NoClose/Smart */
SYS_Output,NULL,
SYS_CmdStream,cmdstream, /* :S/Startup-Sequence */
SYS_Asynch,TRUE,    /* this is the trick */
SYS_UserShell,TRUE, /* use "Shell" as shell */
NP_Name,"Initial CLI",
NP_CopyVars,TRUE,
TAG_DONE);

and thus boots the system, and then dies away. The above "System()" call is the 3.2 equivalent of "newcli", just less mysterious.
 
The following users thanked this post: Tygre

Offline CBH

Re: Os 3.2 development preview
« Reply #302 on: November 26, 2019, 03:14:03 PM »

For intuition, we have to use a special trick because it is already initialized. 3.2 will come with intuition 47 in ROM. For those that need to use CyberGfx, System-Startup checks the boot volume - and only there - for intuition v40 in LIBS:

Ah, so everyone's first thought on 3.1.4 release
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #303 on: November 27, 2019, 08:35:09 AM »
So, another component: The shell.

The major news is that the shell has now a history, and TAB expansion, a feature long waited for. By "the shell has a history" I mean exactly that: The history function moved from CON: into the shell. In fact, what happens here is that the shell places the console into a new console mode within which the line editing of CON: remains unaltered, just if TAB or any history related keys are pressed, the console reports to the shell by means of a special CSI (control) sequence that includes the search pattern and the key. It is then up to the shell to parse the pattern, scan the path or its history, and bring it back to the screen. The latter works by the already existing ACTION_FORCE packet of the console that was documented before, but did not work quite right in 3.1 according to its specifications as it should insert data into the keyboard buffer. For 3.1, it inserted data into the output buffer, which was not quite intended.

For the records, ACTION_FORCE comes from the WShell, and the new console mode comes from ViNCEd, so ViNCEd supports the new shell right away along with the v47 CON: handler.

The TAB expansion and history functions can be turned off by a shell variable, "set simpleshell on" resets the shell back to 3.1, but then you do not have any history at all because CON: doesn't have it anymore.

Then we have a couple of bug fixes as well: The $? operator that checks for the presence of a variable only worked for environment variables, but not for local variables.

We also have now "&&" as a new shell operator which sequences commands, but does not concatenate outputs. That is, || is a "concatenating pipe", and "&&" is sequential execution of commands.

As the dos.library has now a stderr stream, error output redirection with *> makes now sense, and all the shell internal commands and the commands in C: have been reworked to make use of it.

If you had two variables near each other such as $foo$foo, the shell failed to expand the second variable if there was no space between them. This was due to a mixup in the parser state machine that has been fixed.

The Execute command became a shell internal. There is no longer the need to make it resident to allow recursive execution as it is already part of the shell. An old version of execute as stand-alone will ship on the Install3.2: disk.

The input stream of shell scripts can now be redirected with "<filename" as well, i.e. if "S:foo" is a script "S:foo <bla" pipes the file "bla" into the stdin of the commands in S:foo. This never worked before. In fact, input and output redirection of scripts never worked before.

Input redirection with << did not work for some shell commands due to a mixup in the BCPL buffered IO.

The shell accepts a new shell variable,  "debug". If "debug" is set to "on", the shell prints all the commands it executes through the serial port, at 9600 8N1, for debugging purposes. Usually, however, then the new kickstart component "syslog" sits there and picks them up, and redirects them to RAM: so you can see what happened. There will be more to say about "syslog" and the new boot menu in another episode.




 
The following users thanked this post: Tygre

Offline kolla

Re: Os 3.2 development preview
« Reply #304 on: November 27, 2019, 08:36:40 AM »
COP is triggered during a crash all fine, and the custom key combination is the decimal dot on the numeric keypad. So all you need is available at this point. (-:

Unless your Amiga is an A600.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Os 3.2 development preview
« Reply #305 on: November 27, 2019, 08:46:07 AM »
A new feature is that it checks whether the boot volume or any other volume contains a newer version

Is it really smart to just load any "newer version" from any (randomly) available volume?

If you have multiple partitions with different versions of Amiga OS installed, some include components that are "newer" (as in higher number version string) than those you wish to use from the partition you boot from... how do you prevent those from being loaded? Remove the pure flag on all relevant files?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #306 on: November 27, 2019, 01:21:52 PM »
Unless your Amiga is an A600.
In which case you read the bloddy manual. Which is the recommended cause of action for COP anyhow.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #307 on: November 27, 2019, 01:22:56 PM »
If you have multiple partitions with different versions of Amiga OS installed, some include components that are "newer" (as in higher number version string) than those you wish to use from the partition you boot from... how do you prevent those from being loaded? Remove the pure flag on all relevant files?
Boot partition first. Then any other partition. Not any different from the logic by which the workbench and icon libraries are loaded. Actually, since A4000T times.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #308 on: November 28, 2019, 06:47:36 AM »
Boot partition first. Then any other partition. Not any different from the logic by which the workbench and icon libraries are loaded. Actually, since A4000T times.

On A4000T it was already quick&dirty work-around, and back then it was not an issue as those two components either were in kickstart, or they weren't, in which case they could be loaded from disk.

The case now is different, we are now not just talking about components that may or may not be in kickstart, but about updating just about any components that are in kickstart, with rather randomly available components existing on available file systems.

So if you boot from floppy on a system that has a hard drive with several boot partitions that have different versions of workbench.library and icon.library - what can one expect?

Does it check other bootable filesystems first, using boot priority?
Does it just pick the first version it finds that is an "update", or does it continue to scan and pick the one with highest version string?
Does it care about pure flags, like LoadModule now does?
Does it do any validation, or will it blow up if it "by accident" finds non-native modules from available on AROS, OS4 or MorphOS partitions?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Os 3.2 development preview
« Reply #309 on: November 28, 2019, 06:50:47 AM »
In which case you read the bloddy manual. Which is the recommended cause of action for COP anyhow.
Right, but why not just use a more available and less obscure hotkey as default in the first place.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #310 on: November 28, 2019, 08:07:46 AM »
More components: The bootmenu.

Actually, we haven't found any new or old bugs here, just added features. The "boot options" page gets now three new checkbox gadgets. We already had "Disable CPU Caches" as workaround feature for some broken software.

A new gadget is "Update ROM Modules", which is normally checked. If this is not checked, System-Startup will not look for new modules and will operate with the ones in ROM. This may help in case the system modules got somewhat trashed.

We also have "Trace startup-sequence". If this button is checked, the "Initial CLI" gets the "Interactive" variable set to "on", so you can trace through the startup-sequence and check every command executed.

Finally, "Enable System log". This loads and initiates a new module, "syslog", which either sits in ROM, or in LIBS:modules/syslog. If it is enabled, it grabs all data going through the serial port and redirects it to RAM:syslog. It also sets the Shell variable "debug" to "on". If so, the shell will log each executed command through syslog. Thus, you will be able to see what the shell is actually executing, and the debug output of any other program that would normally go through the serial port.
 
The following users thanked this post: Tygre

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #311 on: November 28, 2019, 08:08:26 AM »
Right, but why not just use a more available and less obscure hotkey as default in the first place.
Such as RETURN probably? Come think about it, would you?
 
The following users thanked this post: Tygre

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #312 on: November 29, 2019, 04:14:28 AM »
Is there or will be a way to find all local variables? Will “set” list all variables that affect shell?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #313 on: November 29, 2019, 08:51:28 AM »
Is there or will be a way to find all local variables? Will “set” list all variables that affect shell?
A list of all local variables is available with "set", as always. The Shell.guide (to be updated) will also provide a list of the variables that impact the shell.

We currently have "echo" which will echo commands if set to "on", "interactive" which will prompt for commands before execution, "debug" which enables logging, "simpleshell" which disables TAB expansion, and "oldredirect" which requires that shell redirection is a positional argument.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #314 on: November 29, 2019, 08:57:55 AM »
Next episode: trackdisk.device.

Actually, one probably wouldn't expect much news from such an old device, but yet there is. The trackdisk.device suffered from two bugs which remained undetected in 3.1.4.

One is that with a properly crafted sector layout, the trackdisk device will overwrite memory beyond the track buffer because it does not check the sector index fully.

Another is that the device uses a busy-loop to time the step motor frequency, though this loop is not throttled by any type of hardware register access. This means that on fast hardware, floppy seeking becomes unreliable because the stepping frequency becomes too high. Now the loop is throttled by a hardware register access, so the timing should be (more) reliable.
 
The following users thanked this post: Tygre