What is new in Workbench 1.3 **************************** by James Lawrence [Ed: This article covers some of the new features as far as the writer knows - however, we'll have to wait for the final release, said to be in mid-October, until we know the whole story.] Workbench 1.3 has been out on gamma test release now for a few months. There are a number of significant improvements which have been made, some of which I will describe here. Time and space and lack of information preclude a full discussion of all the changes, however I will try to at least mention all those I know of. In this article I discuss things in the order listed below. Not everything will be of immediate interest to everyone, so I have made headings that stand out, so you can browse more easily and read things in order of interest. Fast Filing System (FFS) Recoverable Ram Disk NEWCON: PIPE: Preferences and new Printer Drivers and printer.device (See "Print.Manual") Shell New Commands A note about compatibility with ARP Fast Filing System (FFS) ######################## At a grass roots level, there is a new hard disk filing system, called the Fast Filing System. As the name suggests, this speeds hard disk use. Without going into too much detail, the old filing system stored 24 bytes of header info and 488 bytes of data in each block. Because of this, the old system read data one block at a time, even though files were written in consecutive blocks wherever possible. By storing nothing but data in the data blocks, and allocating contiguous areas of the disk (ie areas with lots of free blocks in a row, with no breaks) wherever possible, Fast Filing System can read and write large amounts of data in one go. This speeds things up considerably. It is a little hard to say just how much it will speed up disk accesses, as this depends on the hardware and the fragmentation of the file being dealt with. This is in contrast to the older system, where a much faster drive did not necessarily give faster operation, and access is just as slow even if the file is in one contiguous chunk of disk. I have heard reports of a 5 to 20 times increase in the speed of your typical disk access, and a 40 times increase in the speed of validating a drive. This is because under the new system, the software can transfer data as fast as the hardware can, whereas under the old system, the software had to think and issue new commands between each block transferred, so the hardware bandwidth capability was never realised. Note that the fast filing system applies only to hard disks at present, though 1.4 will also apply to floppy disks. Also, the hard disk must be formatted under FFS, which is a major operation for someone who already uses a hard disk. I recommend that even if you have one of the gamma release versions, you wait for the official release. I have heard of people having problems with the gamma FFS to the extent that they have reverted to the old system until they get a more bug free version, which the official release will be. Hard disk problems can be a real hassle, so it is better to avoid them. Recoverable Ram Disk #################### [Ed: There are a couple of versions around of the RRD, one of which actually warm boots off itself - ie, you don't need a disk in the drive, very useful. The final form of the RRD is not yet clear, however so the comments below are as a guide only.] Have you ever put a whole lot of stuff in RAM: and then had to reboot? You lost it all, didn't you? Well, now there is a device called CARD: which is similar to RAM:, but doesn't disappear when you do a warm boot (ctrl-amiga-amiga). Before you read any further, let me warn you that it will only be useful to you if you have more than a megabyte of memory, as it is of a fixed size, not dynamic like RAM: (although you can change the size in the Mountlist, ie "highcyl"). Typically, it will take up 880k. The similarity between CARD: and RAM: is that they both reside in memory, but other than that, CARD: actually behaves more like a floppy disk. As far as I can ascertain, the system treats CARD: as if it really is a floppy disk. This means that you can do things like use DISKCOPY to copy the entire contents of the workbench disk onto CARD:, then run everything from there. I do just that, in my startup-sequence (see the article elsewhere in this issue dealing with startup-sequences), and every command I issue is executed with lightning speed. It also means I can get away quite comfortably using only one disk drive. Before I discovered CARD:, I used to do a similar thing with RAM:. However, because diskcopy does not work with RAM:, and I had to copy the disk file by file with every boot (ie I did a copy df0: to ram: all quiet in my startup sequence), a boot used to take about 4 minutes. I replaced this line with the following: mount card: if exists card:c then echo "card: found intact" else diskcopy df0: to card: endif Now a cold boot (turning the machine on) takes about 100 seconds, and a warm boot about 45 seconds, as all the stuff in CARD: is already there. As the code segment above suggests, CARD: must be mounted with each boot, but will still contain its old files after a warm boot. There are other uses for a recoverable ram disk, such as speeding disk duplication on a single floppy system. Doing a diskcopy (from CLI or workbench) from df0: to card:, then from card: to df0:, is faster and avoids all the disk swapping involved in a normal single drive diskcopy. With imagination, you could come up with other good uses. For the intrepid explorer, try having a look at the CARD: entry in the file devs:mountlist. It looks remarkably similar to a floppy disk entry. You can modify the size of the drive by varying the LOWCYL & HIGHCYL values. Of course, to see the effect of this, CARD: has to be mounted after you modify the file. If it is already mounted, you will have to reboot unless you know a way to dismount a device. I certainly don't. Only one CARD: may be mounted at once, which is a bit of a pity. The guys at the Commodore tech group tell me that you can mount one big CARD:, then put smaller partitions in it in similar style to partitioning a hard disk, but I have not had any success with this. If you have an A1000 and kickstart 1.3 then you will even be able to warm boot from CARD:. In case you were wondering, CARD stands for Commodore Amiga Ram Drive. NEWCON: ####### As the name suggests, this is a new version of CON:. It allows command line editing and keeps a command history, both done using the arrow keys. It is used by the Shell. Left and right arrows move over the text for editing. Shift-left and shift-right go to the ends of the line. Up gives you the previous command, more ups get you back earlier. Down gives later commands in case you go back too far (but of course can not give you the command you were about to type. If someone implements this feature, they will make a fortune!). Shift-up finds the latest command which starts with a partly typed string. Shift-down takes you straight to the bottom of the history buffer. Once you have found the desired command in the history, you may edit it using left & right arrow keys, then hit return. In other respects, NEWCON: resembles CON:, except that it must be mounted before use. This would normally be done in the startup-sequence. PIPE: ##### Unix buffs will be familiar with the concept of a pipe. The idea is that the output of one program can be redirected into the input of another, in a similar way that output can be redirected to a file. The method used is, however, slightly different from unix. One very typical use of a pipe is to use MORE (the text-displaying utility) to slow down the output of a program so it can be read. A typical example would be: mount pipe: (this only need be done once per boot. It could be in the startup-sequence.) Then, in one CLI: dir > pipe:a df0: opt a then in another CLI: more pipe:a The pipe can be considered as being like a file which can be written to by one program and read from by another simultaneously. As many pipes as needed can be invoked simultaneously by using a different name, for example pipe:b. In this way, many commands can be strung together with pipes between them. It is possible to write to a pipe from an application program (wordprocessor, etc) simply by specifying a pipe as the name of the file to write. Similarly, a pipe can be read in the same way. The way the pipe works (roughly) is that one program writes into a buffer, which the other program reads from. No permanent storage is done. The maximum size of the buffer is 4k, so if the writing program tries to write more than 4k past where the reading program is up to, then it is stopped until the reading program has read some more. Preferences and new Printer Drivers and printer.device ###################################################### Most of the changes to preferences relate to printers. There are now two printer graphic screens. These allow you to control density, horizontal centering, scaling, colour correction (to make the printer output look like the screen), left offset, dithering (making new colours by putting different coloured pixels next to each other),size, antialiasing (smoothing diagonal lines), and a couple of more esoteric things. There are a whole swag of new and rewritten printer drivers. Notable amongst them is the EpsonQ 24 pin driver, which allows printing at densities of 90, 120, 180, and 360 dpi. Have a look at the article "Print.Manual" on this disk for the full story about printing with the Amiga and 1.3. Shell ##### This replaces the CLI. There have been several enhancements, including resident commands, aliasing, putting the current directory into the prompt, and shell scripts. A resident command is one which is in memory permanently, so it does not need to be loaded each time it is called. It could be run several times simultaneously, with all invocations using the same piece of code in memory. This is described further in the next section. Aliasing allows you to type one thing when you really mean something completely different, but still have your Amiga understand what you are saying. It works like this: Imagine for a moment that you have a directory called sys:fred/john/mary/englebert/yet_another_one which you often want to CD to. You could set up an alias like alias yao cd sys:fred/john/mary/englebert/yet_another_one Then typing yao would be equivalent to typing cd sys:fred/john/mary/englebert/yet_another_one If you need to have a variable part in the alias, then enlose it in [] eg alias xcopy copy [] clone then typing xcopy fred john would be equivalent to copy fred john clone Typing alias yao removes the definition for yao. Typing alias by itself lists the current aliases. 1>alias xcopy copy [] clone newshell newcli newcon:0/0/640/256/AmigaShell By the way, those two are standard. Each shell will maintain its own independent set of aliases. It would be a good idea to set the ones you will use often in the s:CLI-startup file, which is a sequence which gets executed every time a CLI (shell) is invoked. The PROMPT command has been enhanced for use with the shell. The format is PROMPT where is the prompt desired, surrounded by quotes. Within the string, %N gives the CLI number, and %S gives the current directory. For example, prompt "%N.%S > " would give a prompt which might look like 3.SYS:fred/john/mary/englebert/yet_another_one> (there is a space after the >) This is the default setting. It is no longer necessary to use the EXECUTE command explicitly. Instead, use PROTECT to set the script bit of the protection field. For example, if we say protect scriptfile +s where scriptfile is some file containing CLI commands (a sequence), then at any time in the future, scriptfile is equivalent to execute scriptfile If you put the S: directory in the path, then things get even easier, as you can create scripts, store them in S:, then treat them just like any other command. This feature still uses EXECUTE, so to make it really fly, you could make EXECUTE resident as described below. New Commands ############ ASK Provides interactive execution control in the CLI. This is only really useful in sequence files. As an example, the following code segment in a sequence file: ask "Are you ready for this?" if warn then echo "OK, lets get under way!" else endcli end if will ask the user the question. If the answer is y or yes (in upper or lower case), then ASK sets a return code of 5 (warn), and the echo is done. Any other response will cause the ELSE section to be executed (in this example this terminates the sequence). [Ed: check SWITCH in the PROGRAMS drawer for a mouse-driven ASK.] AVAIL Gives memory usage & availability statistics. 1> avail Type Available In-Use Maximum Largest chip 366272 156960 523232 362416 fast 1452656 1161352 2614008 954472 total 1818928 1318312 3137240 954472 FF stands for FastFonts. Generally run in the startup-sequence. GETENV & SETENV Return or set the value of an environment variable. A couple of examples: 1> setenv number 25 1> getenv number 25 1> setenv fred_nurk "silly person" 1> getenv fred_nurk silly person 1> getenv number 25 where lines starting with a prompt ( ie 1> ) are input, and others are output. SETENV with only one argument removes that variable. Continuing from the above example: 1> setenv number 1> getenv number (nothing is returned) These commands are designed to use the ENV: device promised for V1.3. In the author's gamma version, they use a directory in RAM: which has been ASSIGNed the name ENV:. LOCK Sets and resets the write protect of a hard disk or partition using fastfilesystem. If you type LOCK "dh0,on,xxxx" where xxxx is an optional four letter password, then the drive will be write protected until you type LOCK "dh0:,off,xxxx" where xxxx is the same password (or absence of one), or until you reboot. You may need an extra comma after the 'on' and before the 'off'. RESIDENT Allows often used commands to be loaded permanently into memory, so subsequent calls just execute that bit of memory. More than one occurrence of the program may then use the same piece of code, which is just to say that if we made a command resident, and used it in two shells simultaneously, then both would actually run from the same code segment in the same memory. This saves both time and memory space. In another way, it wastes memory, as all resident commands are permanently in memory regardless of whether they are currently being used. This feature can only be used with the shell described above, it does not work with the old CLI. Also, to be able to be made resident, a piece of code must be both re-entrant and re-executeable, which essentially means that it must be pure code - code which uses no variables buried in the code (it may use the stack, or other schemes for keeping variables independent of code). This does limit the programs available. A pure code segment should have the PURE bit set in the protection field (>protect name +p). It is possible to test code for purity by using resident with the PURE flag. This would be done as follows: resident "name,file,add,pure" where name is what you want the command to be called, and file is the full pathname where it can be found. Then run the command simultaneously in two separate shells. If all is well, then the code is pure. If a guru happens, the code is impure. If the code is pure, you can set the PURE bit: protect name +p The full specification of the command is resident "name,file,action,pure" where name and file are as described above, action is one of add, delete, replace, and the pure is optional (not needed if pure bit of file's protection field is set). If no name is specified, then it defaults to the filename part of the full pathname. Normally you would set up all the resident commands in the startup-sequence. See the article on startup sequences elsewhere in this issue. resident called with no arguments lists the resident list: 1> resident Name UseCount Execute 1 CLI SYSTEM FileHandler SYSTEM Restart SYSTEM CLI SYSTEM SETALERT A mystery command. Possibly it helps to avoid gurus - but I can assure you it does not prevent them! In any case, this gets run during the startup sequence, and never goes away. XICON Runs a script file (a sequence) from the workbench. To use this, create an icon for the file, and set the default tool to c:Xicon by using the workbench INFO menu item. You may also set a WINDOW= specification (take a look at the SHELL (or CLI) icon for an example) to set the size & location of the window needed for input and output for the script. You may also set a DELAY= to delay the demise of the window after the script is finished. [Ed: Pete Goodeve tells me that Xicon is not working in the gamma release version of 1.3, and it certainly isn't his program - it's been rewritten and is smaller.] The following additions have been made to the SYSTEM directory: FASTMEMFIRST This organises the free memory list so that fast gets used first. This saves chip memory for things that must use it - such as the chips (surprise surprise) and a few older programs. FIXFONTS ??? The following additions have been made to the UTILITIES directory: CALCULATOR A four function calculator driven by mouse or keyboard. CLOCKPTR Turns the workbench pointer into a digital clock whenever the Workbench is selected. This shows the time in 24 hour format. If the pointer is against the left edge of the screen, the date is displayed. If it is in the top left corner, then minutes and seconds are shown instead of hours and minutes. This can be run from either CLI or workbench - the icon is in the utilities folder. Successive invocations of CLOCKPTR toggle between the clock and the default pointer. Alternatively, if you ran it from the CLI, you can stop it with ctrl-c or with the break command. CMD Redirects serial or parallel port output to a file. This is useful if, like me, you do not own a printer. You can use a print command in a word processor (or any application) and save the output on disk. Then off you go to your friend's place to use his printer. If you have a 5.25 inch drive and the appropriate driver, you could save the file on an MS-DOS disk and print it using one of those machines (perhaps take your disk to work and use the laser printer ...). CMD also makes it possible to inspect and edit printer or modem before it is sent to the device in question. The format is CMD -s -m -n The -s, -m, and -n are optional. -s skips any short initial write (usually a reset) -m captures multiple files until ctrl-c or a break -n gives progress messages (NOTIFY) CMD can also be used from the workbench. To set the options, use the workbench menu item INFO and set the tool types. The default settings for these are: DEVICE=parallel FILE=ram:CMD_file SKIP=FALSE MULTIPLE=FALSE NOTIFY=FALSE MORE Like a nice version of TYPE. Allows you to read files a page at a time, search for strings, etc. For a list of commands, type the letter h to the more prompt. The format is simply MORE filename MORE can be run from the workbench by selecting the file (click on it), then holding the shift key while you double click on MORE. SAY Pretty much like the current one. Many of the existing commands have slightly changed specifications, too many to list here. I can only suggest that you wait for official documentation, or if you are playing with the system, then you can at least find the templates by typing command ? For example, consider the humble COPY command: 1>copy ? FROM,TO/A,ALL/S,QUIET/S,BUF=BUFFER/K,CLONE/S,DATE/S,NOPRO/S,COM/S: The BUF= option sets the number of 512 byte buffers used by COPY. DATE, NOPRO, and COM allow the initial date, protection and comment respectively to be reproduced. CLONE does all three in one hit. Experiment with your favourite commands and see if they have changed! A note about compatibility with ARP ################################### [Ed: See review this issue and on previous issues.] The Amiga Replacement Project (ARP) is a set of Amigados commands written by a third party wth the following properties: they are compatible with WB1.2 they are written in assembler, which makes them faster and smaller than their Commodore V1.2 commands written in C they have a more consistent set of options a few other improvements over V1.2 Commodore's V1.3 commands are also compatible with WB1.2 written in assembler have a more consistent set of options have a significant number of improvements over V1.2 In addition, many of the V1.3 commands have features which are V1.3 specific. For example, PROTECT now gives access to the pure, script, hidden and archive flags. The pure and script flags are relevant only to resident commands and directly executeable shellscripts respectively, which are features of the new shell. What the hidden flag does is anybody's guess. More importantly, the V1.3 commands were written specifically to be pure code, so they can be made resident. I do not know whether the ARP people had this in mind when they wrote their commands, so ARP may or may not be pure. One way to find out would be to use the PURE option to RESIDENT, as described above. In any case, it would not be sensible to simply replace all the V1.3 commands without the ARP ones. Each command would have to be looked at on its own merit, and I strongly suspect that the performance gain available is very limited, and not worth the effort. This is in contrast to V1.2, where ARP is definitely an improvement. Mind you I have not looked at ARP in depth, so I could be completely wrong ... . If you have learned half as much by reading this article as I have by writing it, then you are well on your way to being able to utilise the full potential of your Amiga under WB1.3. Happy hacking, James. XXXXXXXXXXXXXXXXXXXXXXXXX END OF 1.3_SYSTEM XXXXXXXXXXXXXXXXXXXXXXXXXXXXX