@DATABASE RunLame documentation @AUTHOR Bilbo the first @(C) Bilbo the first @$VER: RunLame V 1.34 documentation (© by Bilbo the first of Hypenosis on 02.03.93) @TOC MAIN @INDEX NodeIndex @WIDTH 78 ##_____________________________________________________________________________## ## ## ## Static documentation nodes ## ##_____________________________________________________________________________## @NODE MAIN "RunLame documentation" ____________________________________________________________________________ @{B}@{U}RunLame@{UB}@{UU} Version 1.34 @REMARK @{" Beta release for beta testers only" LINK Remarks_for_ß-Testers.txt/MAIN} @{FG Highlight} Copyright 1992-1993 by @{B}Bilbo the first@{UB}@{FG Text} ____________________________________________________________________________ @{U}Table of contents@{UU} Prologue @{" Disclaimer " LINK Disclaimer} @{" PrayWare " LINK PrayWareLicense} Introduction @{" The aim of the game " LINK Introduction} @{" Features " LINK Features} @{" The bad news " LINK Disadvantages} Installation @{" Installing RunLame " LINK Installation} Operation @{" How to use RunLame " LINK OperationDescription} @{" Workbench tooltypes " LINK WorkbenchTooltypes} @{" AmigaDOS template " LINK ShellOptions} @{" Configuring RunLame " LINK Configuring} Hints @{" Problems - solutions - corner " LINK ProblemsSolutions} @{" Known bugs " LINK KnownBugs} History @{" History " LINK History} @{" Future plans " LINK FuturePlans} @{" Features not to come " LINK FeaturesNotToCome} Epilogue @{" Thanks, greetings " LINK ThanksAndGreets} @{" Contact " LINK ContactAuthor} @ENDNODE ##_____________________________________________________________________________ @NODE NodeIndex "Index table" @{U}Index@{UU} @{" About menu item " LINK GUI_About} @{" AGA " LINK AGA_Explanation} @{" API " LINK API_Explanation} @{" APPEND, NOAPPEND, APN, NAPN " LINK Option_APPEND} @{" APPICON, API " LINK Option_APPICON} @{" Beta testing " LINK BetaTesting} @{" BURST, NOBURST, B, NB " LINK Option_BURST} @{" CACHE, NOCACHE, C, NC " LINK Option_CACHE} @{" COMMANDLINE, CL " LINK Option_COMMANDLINE} @{" Configuring RunLame " LINK Configuring} @{" Contact the author of RunLame " LINK ContactAuthor} @{" COPYBACK, NOCOPYBACK, CB, NCB " LINK Option_COPYBACK} @{" CPU " LINK CPU_Explanation} @{" DATABURST, NODATABURST, DB, NDB " LINK Option_DATABURST} @{" DATACACHE, NODATACACHE, DC, NDC " LINK Option_DATACACHE} @{" DEFAULTS, NODEFAULTS, D, ND " LINK Option_DEFAULTS} @{" Disadvantages of RunLame " LINK Disadvantages} @{" Disclaimer " LINK Disclaimer} @{" ECS " LINK ECS_Explanation} @{" Enforcer " LINK Enforcer_Explanation} @{" Enter commandline menu item " LINK GUI_EnterCommandline} @{" EXTERNALCACHE, NOEXTERNALCACHE, EC, NEC " LINK Option_EXTERNALCACHE} @{" Features of RunLame " LINK Features} @{" Features that won't be implemented " LINK FeaturesNotToCome} @{" First public release " LINK Version_1.25} @{" Future plans " LINK FuturePlans} @{" GFXUSERINTERFACE, GUI " LINK Option_GFXUSERINTERFACE} @{" GUI " LINK GUI_Explanation} @{" GUIDE " LINK Option_GUIDE} @{" GUIDENAME " LINK Option_GUIDENAME} @{" HELP, H " LINK Option_HELP} @{" History " LINK History} @{" Index table " LINK NodeIndex} @{" Installation of RunLame " LINK Installation} @{" INSTBURST, NOINSTBURST, IB, NIB " LINK Option_INSTBURST} @{" INSTCACHE, NOINSTCACHE, IC, NIC " LINK Option_INSTCACHE} @{" Introducing RunLame " LINK Introduction} @{" Known bugs " LINK KnownBugs} @{" Lame " LINK Lame_Explanation} @{" Launch commandline " LINK GUI_Launch} @{" LOOP, L " LINK Option_LOOP} @{" MMU " LINK MMU_Explanation} @{" MUI " LINK MUI_Explanation} @{" OCS " LINK OCS_Explanation} @{" Open file requester " LINK GUI_OpenFReq} @{" Operation description " LINK OperationDescription} @{" Other Degraders " LINK OtherDegraders} @{" PATH, P " LINK Option_PATH} @{" PrayWare concept explanation " LINK PrayWareLicense} @{" Problems - solutions - corner " LINK ProblemsSolutions} @{" Quit RunLame " LINK GUI_Quit} @{" SCREEN, NOSCREEN, S, NS " LINK Option_SCREEN} @{" Second public release " LINK Version_1.28} @{" Shell/CLI usage " LINK ShellUsage} @{" Table of contents " LINK MAIN} @{" Template " LINK ShellOptions} @{" Thanks and greetings " LINK ThanksAndGreets} @{" Third public release " LINK Version_1.32} @{" TLA " LINK TLA_Explanation} @{" VBR " LINK VBR_Explanation} @{" VBRTOFAST, VBRTO0, VBRTO, VBR, NVBR " LINK Option_VBR} @{" VISIBLE, INVISIBLE, V, NV " LINK Option_VISIBLE} @{" Workbench tooltypes " LINK WorkbenchTooltypes} @{" Workbench usage " LINK WorkbenchUsage} @ENDNODE ##_____________________________________________________________________________ @NODE Disclaimer "Disclaimer" @{U}LICENSE and TERMS for software originating from Bilbo the first@{UU} @{FG Highlight} Copyright © 1993 @{B}Bilbo the first@{UB}@{FG Text} @{B}This software is NOT in the Public Domain, NOT Freeware and NOT Shareware.@{UB} This document overrides any former documents included with preceding versions of this software package, and is to be considered valid for those, as well as for the package with which it is included. There are @{B}NO@{UB} warranties, either expressed or implied, with respect to the software, its quality, performance, merchantability, or fitness for any particular purpose. This software is provided "as is" and the entire risk as to its quality and performance is with the user. The author of this software shall @{B}NOT@{UB} be liable for errors contained in the software or the software's documentation, or for incidental or conse- quential damages of any kind in connection with the performance, use or posession of this software. The use of undocumented features/commands is not permitted except with permission from the author, and the author is in @{B}NO@{UB} way responsible for consequences thereof. Anyone may use it for private purposes, and it may be given away for free, as long as it is @{B}NOT@{UB} part of any deal involving purchases; and fees for copying and/or distribution, and/or fees for disks exceeding the actual market price for an empty disk of the same brand/quality is to be considered as commercial exploitation of this software, and an infringement of the Copyrights (©) of the author. The right to use this software and/or its documentation for private purposes may or may not be restricted by additional copyrights and/or registration conditions. If given away under above (or below) conditions, the receiver in @{B}NO@{UB} way receives the ownership of the program itself, but may only be licenced to use it if above and below conditions are met. If these rules infringes the local law and/or rights of any area, political or geographical, this software is @{B}NOT@{UB} to be used and/or distri- buted in these areas. There may or may not be specific charges for the use and/or spreading of this(these) program(s), and if existant, these charges are to be honored following a free test period of either @{B}3@{UB} days or @{B}10@{UB} executions of the program, whatever comes first. The payment of these charges do @{B}NOT@{UB} in any way make the user/distributor entitled to any form of support and/or upgrades and/or does @{B}NOT@{UB} give him/her/them/it any rights regarding the software, or the use/distribution thereof, and the Author assumes @{B}NO@{UB} extra responsibility and will retain superior ownership and copyright of the code, parts of code, and/or source of code of all software. The executionable and/or non-executionable parts of this program or any package consisting of any or all of these parts are @{B}NOT@{UB} to be altered by any means (including editing, reprogramming, crunching, and recompiling), except de-archiving. Note that by changing any part of the software, you will resume all the responsibilities, but none of the rights of the author (Bilbo 1st). The author (Bilbo 1st) is in @{B}NO@{UB} way responsible for any changes made to any part of the package, or consequences thereof. The name of the executable file(s) may be changed at convenience, as long as this does @{B}NOT@{UB} infringe any copyright of any other author, and by changing the name(s), observe that all rights and/or restrictions given by this text, and/or by the software itself still applies. The documents contained in the software package contain proprietary information which is protected by copyright (©). All rights are reserved. No part of these documents may be photocopied, reproduced, electronically copied, or translated to another language without the inclusion of the software and other included files as part of a package. The executable files accompagnying this package may @{B}NOT@{UB} be reproduced or transferred outside a one-machine-environment without all these accompagnying files including this file. Any translation of any part of the package, to whatever language, has to be included as an additional text file, and should @{B}NOT@{UB} contain the signature of the Author, but @{B}MUST@{UB} be signed by the person(s) doing the translation. These documents are @{B}NOT@{UB} to be changed by any means, excepting Archiving, if the documents are extractable, and readable after extracting, and the name of the archive is directly spellable using letters "A".."Z", numbers "0".."9" plus punctuation ".", and does NOT contain more than eight (8) characters plus punctuation(".") plus three (3) characters. This is to ensure compatibility with the MS-DOS(TM) and PC-DOS(TM) file systems. @ENDNODE ##_____________________________________________________________________________ @NODE PrayWareLicense "PrayWare concept explanation" This package is `@{B}PrayWare@{UB}' @{U}Don't PAY, just PRAY!@{UU} This license is an addition to the disclaimer. All restrictions pointed out in the @{"disclaimer" LINK Disclaimer} keep their validity. The author (@{"Bilbo the first" LINK ContactAuthor}) doesn't intend to gain any profit from this production. Therefore the user does not need to pay any fees to the author. Though the author constantly suffers from lack of money (most people do, don't we?), but there is a much more valuable thing you can do for him. Something more valuable than cash money? Must be very expensive! Must be very difficult! Right? Wrong! The author just asks you for something very easy, something which doesn't cost you any money but some minutes of your time. Interested? Just get in contact with the Lord @{FG Highlight}Jesus Christ@{FG Text} and pray. Simply try it, talk to him like you would talk to a very private and good friend. Tell him what happened today, what you did feel like today. Tell him you received a software of the author which you use and like very much (of course only if you really do so :-). And tell him that the author is in need of help for he is often very weak and often fails to love his Lord and Lord's creatures the right way. Just talk with him about everything you like to. Thanks, that's the best thing you could do for me. Anyone feeling personally bothered by the concept of PrayWare may just ignore it. Nobody forces you to do things you don't want to do. Of course you though might use the software under the limitations expressed in the @{"disclaimer" LINK Disclaimer}. @ENDNODE ##_____________________________________________________________________________ @NODE Introduction "RunLame introduction" @{U}The aim of the game@{UU} Do you run your system using another screenmode than PAL or NTSC, for example EURO72, an AGA specific screenmode or even a screenmode produced by a graphics expansion board? Have you ever tried to start a game or demo from within this screenmode? Have you ever been angry about those programmers who do not stick to the guidelines of programming thus producing programs which are not aware of the screenmode they were started out of? Do you have an Amiga with 68010, 68020, 68030 or 68040 processor? Did you ever curse those socalled coders whose programs crash your computer when you didn't disable the processor's caches and forgot to move the vector base register back to $0.l? @{"lame" LINK Lame_Explanation} programming is the disease, RunLame is the cure! RunLame is a Kick2.04+ tool, it will NOT work under Kick1.0/1.1/1.2/1.3/1.4! RunLame is 100% reentrant Assembler code, so you can set the pure flag and make it resident. RunLame is startable from Workbench. RunLame considers some adjustments and a command line and executes the given command line, just after having degraded the display (optional) and the CPU (optional). When the command line has been executed the display and CPU state is restored to the same as before executing the command line. Summarizing we can say RunLame is a multitasking friendly temporary system degrader which may let some bad behaving programs run in your system's environment (but can't give any guarantee). If some of those @{"lame" LINK Lame_Explanation} programs don't run though RunLame has been used, they are on a higher lameness-level, which can't be fixed by RunLame (this is definitely not a bug of RunLame). I do write demos myself and you can believe, @{B}i do know@{UB} how to write a proper startup code. Consider RunLame beeing an external startup code. @ENDNODE ##_____________________________________________________________________________ @NODE Features "RunLame features" @{U}Features@{UU} The @{B}{}@{UB}'s inform you about the system configuration needed for a feature. ·Optionally disabling of each processor cache, burst or copyback mode. {68020, 68030[EC], 68040[EC]} ·Optionally moving @{"VBR" LINK VBR_Explanation} to location $0 or to a FAST memory location. {68010, 68020, 68030[EC], 68040[EC]} ·Optionally degrading display's screenmode to simulate @{"OCS" LINK OCS_Explanation}. This can optionally preserve or hide the current display's contents. Display degradation even works if the current active screenmode is produced by a graphics board (fi. Merlin © X-Pert). {@{"ECS" LINK ECS_Explanation}, @{"AGA" LINK AGA_Explanation}} ·Degrading sprite resolution to simulate @{"OCS" LINK OCS_Explanation} if display degrading is activated. {@{"AGA" LINK AGA_Explanation}} ·Turning off sprites in a system friendly manner if display degrading is activated. {@{"OCS" LINK OCS_Explanation}, @{"ECS" LINK ECS_Explanation}, @{"AGA" LINK AGA_Explanation}} ·Flexible and highly configurable fix for a wide variety of @{"lame" LINK Lame_Explanation} programs. ·Works under Kickstarts 2.04, 3.0 and 3.1. ·Due to 100% system conform and system friendly algorithms, future system compatibility is as high as possible. Furthermore the multitasking environment is not hurt or damaged by the code. All degrading is done as smart as possible, and the code did never crash during @{"beta testing" LINK BetaTesting}. ·verified, tested and safe (100% assembler) code resulted in a short binary. ·Impressive user friendlyness due to various possibilities of usage: ·A CLI/Shell interface with online help and OS2 conform parsing for quick and effective usage directly, or indirectly (fi. aliases, shell scripts, DirectoryOpus calls). ·Startable from Workbench, additionally a whole bunch of tooltypes is supported. ·A @{"GUI" LINK GUI_Explanation} in gadtools style of OS2+ for maximum convenience. Supports pull down menus, keyboard shortcuts, ASL filerequester (which of course is the most often patched system part :-), an application window which can be zoomed. Of course an ansynchroneous amigaguide help is available. ·An application icon which can be placed on the Workbench for intuitive and specialized usage. ·Detailed messages inform the user in failure situations. Messages are automatically directed to Shell window or to requesters, depending on operation mode. ·Output of the commandline is directed to Shell window or to an automagically opening window , depending on operation mode. Sounds great? YAH - Yet another hype? @{B}Hypenosis@{UB} - @{I}Better believe the hype!@{UI} But keep on reading, here come... @{"the bad news" LINK Disadvantages}. @ENDNODE ##_____________________________________________________________________________ @NODE Disadvantages "RunLame disadvantages" @{U}The bad news@{UU} ·RunLame cannot simulate a Workbench startup for @{"lame" LINK Lame_Explanation} programs. The execution of programs is equivalent to a call from a shell. Therefore some programs might not make use of their tooltypes. But be serious, have you ever seen a program which needs Workbench startup and RunLame support? ·The @{"GUI" LINK GUI_Explanation} is not font adaptive, nor is it localizable. ·Though the code worked very well during the @{"beta testing" LINK BetaTesting} phase, there might be nasty bugs. ·RunLame can't be used to run non-DOS trackloading demos, for I don't want to support this kind of loaders. I usally like to keep good demos on my harddisk, which is not directly possible with @{I}trackmos@{UI}. So I don't keep @{"lame" LINK Lame_Explanation} coded @{I}trackmos@{UI}. ·The icon of RunLame is not yet very original. If you would like to draw a better one, which I shall distribute in the next release, @{"contact" LINK ContactAuthor} me. Maybe someone is gifted enough to make a MagicWB-like icon for RunLame? ·The documentation often might use improper terms. Please excuse this, for I am not a native english speaker. If you want to improve the documentation, please @{"contact" LINK ContactAuthor} me. @ENDNODE ##_____________________________________________________________________________ @NODE Installation "Installing RunLame" @{U}Installing RunLame@{UU} Installing RunLame in your system is quite easy. There is no need for an Installer script. At first enter the directory, which contains the package. The name of the directory is @{B}RunLame_V#?.#?@{UB} (the #?.#? is the current release number). Then enter the @{B}Bin@{UB} directory and copy to the following files to a directory which is in your system path: ·RunLame ·RunLame.info That's it. You can now start RunLame from shell or from Workbench. For special operation topic refer the @{"operation description" LINK OperationDescription}. @ENDNODE ##_____________________________________________________________________________ @NODE OperationDescription "RunLame operation description" @{U}How to use RunLame@{UU} @{"Usage from Workbench" LINK WorkbenchUsage} @{"Usage from CLI " LINK ShellUsage} @{U}General notes@{UU} Both, Workbench @{"tooltypes" LINK WorkbenchTooltypes} and CLI AmigaDOS @{"template" LINK ShellOptions} control the configuration of RunLame. Those keywords are called @{B}switch@{UB}es to simplify the terminology. Of course some of the switches exclude each other, for example it is not possible to use @{"SCREEN" LINK Option_SCREEN} and @{"NOSCREEN" LINK Option_SCREEN} together, or @{"DATABURST" LINK Option_DATABURST} and @{"NOBURST" LINK Option_DATABURST}. Wrong usage of switches results in the appropriate error message. Though @{"COPYBACK" LINK Option_COPYBACK} only works on 68040 processors, no errormessage is prompted when this switch is used on another processor because this makes scriptfiles easier system portable. Same is to be said about @{"EXTERNALCACHE" LINK Option_EXTERNALCACHE} when there is no external cache available, as same applies to @{"VBRTOFAST" LINK Option_VBR} when the processor has no vector base register (68010+ have a @{"VBR" LINK VBR_Explanation}). @ENDNODE ##_____________________________________________________________________________ @NODE WorkbenchUsage "Using RunLame from the Workbench" @{U}General notes on usage from Workbench@{UU} To use RunLame from Workbench, simply double click it's icon. Depending on the supplied @{"tooltypes" LINK WorkbenchTooltypes} in the icon, RunLame is going to be configured. Furthermore it's possible to supply a @{"COMMANDLINE" LINK Option_COMMANDLINE} to RunLame without using the appropriate tooltype. If you want to do this, click first RunLame's icon, and then as many icons as u desire in the order you want to. The last needed icon is to be double clicked. If you want adapt RunLame's configuration to your own needs, read the section about @{"configuration" LINK Configuring} topics. Workbench users are advised to read about the possibilities given by the @{"application icon" LINK Option_APPICON} feature and the @{"path setting" LINK Option_PATH}. @ENDNODE ##_____________________________________________________________________________ @NODE WorkbenchTooltypes "RunLame configuration on Workbench using tooltypes" @{U}Workbench tooltypes@{UU} @{" COMMANDLINE " LINK Option_COMMANDLINE} @{" GFXUSERINTERFACE " LINK Option_GFXUSERINTERFACE} @{" APPICON " LINK Option_APPICON} @{" LOOP " LINK Option_LOOP} @{" DEFAULTS " LINK Option_DEFAULTS} @{" SCREEN " LINK Option_SCREEN} @{" VISIBLE " LINK Option_VISIBLE} @{" CACHE " LINK Option_CACHE} @{" INSTCACHE " LINK Option_INSTCACHE} @{" DATACACHE " LINK Option_DATACACHE} @{" BURST " LINK Option_BURST} @{" INSTBURST " LINK Option_INSTBURST} @{" DATABURST " LINK Option_DATABURST} @{" COPYBACK " LINK Option_COPYBACK} @{" EXTERNALCACHE " LINK Option_EXTERNALCACHE} @{" VBR " LINK Option_VBR} @{" APPEND " LINK Option_APPEND} @{" PATH " LINK Option_PATH} @{" GUIDE " LINK Option_GUIDE} @{" GUIDENAME " LINK Option_GUIDENAME} @ENDNODE ##_____________________________________________________________________________ @NODE ShellUsage "Using RunLame from a shell/CLI" @{U}General notes on usage from a shell/CLI@{UU} It's assumed, that shell/CLI users are advanced and more experienced users. If you don't userstand the explanations in this section, use RunLame together with the @{"Workbench" LINK WorkbenchUsage}. You can simply call RunLame using the command @{B}RunLame@{UB}. This opens the @{"GUI" LINK Option_GFXUSERINTERFACE} and configures RunLame according to it's @{"defaults" LINK Option_DEFAULTS}. If you don't need the @{"GUI" LINK GUI_Explanation}, call RunLame together with the needed @{"switches" LINK ShellOptions} and the desired @{"commandline" LINK Option_COMMANDLINE}. Since RunLame ignores the Workbench @{"tooltypes" LINK WorkbenchTooltypes} when started from a shell/CLI, shell users can only @{"configure" LINK Configuring} RunLame using aliases or script files. @ENDNODE ##_____________________________________________________________________________ @NODE ShellOptions "RunLame configuration on shell" @{U}AmigaDOS template@{UU} RunLame H = @{" HELP " LINK Option_HELP}/S, G = @{" GUIDE " LINK Option_GUIDE}/S, GUI = @{" GFXUSERINTERFACE " LINK Option_GFXUSERINTERFACE}/S, API = @{" APPICON " LINK Option_APPICON}/S, L = @{" LOOP " LINK Option_LOOP}/S, D = @{" DEFAULTS " LINK Option_DEFAULTS}/S, ND = @{" NODEFAULTS " LINK Option_DEFAULTS}/S, S = @{" SCREEN " LINK Option_SCREEN}/S, NS = @{" NOSCREEN " LINK Option_SCREEN}/S, V = @{" VISIBLE " LINK Option_VISIBLE}/S, NV = @{" INVISIBLE " LINK Option_VISIBLE}/S, C = @{" CACHE " LINK Option_CACHE}/S, NC = @{" NOCACHE " LINK Option_CACHE}/S, IC = @{" INSTCACHE " LINK Option_INSTCACHE}/S, NIC = @{" NOINSTCACHE " LINK Option_INSTCACHE}/S, DC = @{" DATACACHE " LINK Option_DATACACHE}/S, NDC = @{" NODATACACHE " LINK Option_DATACACHE}/S, B = @{" BURST " LINK Option_BURST}/S, NB = @{" NOBURST " LINK Option_BURST}/S, IB = @{" INSTBURST " LINK Option_INSTBURST}/S, NIB = @{" NOINSTBURST " LINK Option_INSTBURST}/S, DB = @{" DATABURST " LINK Option_DATABURST}/S, NDB = @{" NODATABURST " LINK Option_DATABURST}/S, CB = @{" COPYBACK " LINK Option_COPYBACK}/S, NCB = @{" NOCOPYBACK " LINK Option_COPYBACK}/S, EC = @{" EXTERNALCACHE " LINK Option_EXTERNALCACHE}/S, NEC = @{" NOEXTERNALCACHE " LINK Option_EXTERNALCACHE}/S, VBR = @{" VBRTOFAST " LINK Option_VBR}/S, NVBR = @{" VBRTO0 " LINK Option_VBR}/S, APN = @{" APPEND " LINK Option_APPEND}/S, NAPN = @{" NOAPPEND " LINK Option_APPEND}/S, P = @{" PATH " LINK Option_PATH}/K, GN = @{" GUIDENAME " LINK Option_GUIDENAME}/K, CL = @{" COMMANDLINE " LINK Option_COMMANDLINE}/F cmd @ENDNODE ##_____________________________________________________________________________ @NODE Option_HELP "HELP, H" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} HELP | H not supported @{U}Explanation@{UU}: Display a short summary of valid options in the current CLI window. If the window is too small to completely hold this information, you may redirect the output to a file (@{B}RunLame HELP >T:RunLame.olh@{UB}), which can be read using a text editor. @ENDNODE ##_____________________________________________________________________________ @NODE Option_GUIDE "GUIDE, G" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} GUIDE | G GUIDE | G = USE @{U}Explanation@{UU}: Open an @{"AmigaGuide" LINK AmigaGuide_Explanation} help documentation for RunLame. This happens directly at startup of RunLame and the form of the guide help depends on the setting of RunLame. If you use the @{"GUI" LINK Option_GFXUSERINTERFACE} and/or @{"API" LINK Option_APPICON} of RunLame, the guide help will be asynchroneous, allowing manipulation of the @{"GUI" LINK Option_GFXUSERINTERFACE}/@{"API" LINK Option_APPICON} while reading the guide. Otherwise the guide is synchroneous. @ENDNODE ##_____________________________________________________________________________ @NODE Option_GFXUSERINTERFACE "GFXUSERINTERFACE, GUI" @NEXT Option_APPICON @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} GFXUSERINTERFACE | GUI GFXUSERINTERFACE | GUI = USE @{U}Explanation@{UU}: The @{"GUI" LINK GUI_Explanation} is always invoked when the @{"COMMANDLINE" LINK Option_COMMANDLINE} parameter is omissed. Use the GUI option to force RunLame to open the GUI, even if @{"COMMANDLINE" LINK Option_COMMANDLINE} has been specified, whose argument in this case will appear in the command line string gadget. The GUI is going to appear centered to the mouse pointer on the default public screen, I just liked the behaviour of the ReqChange redirected requesters. The GUI is mainly divided in two parts: the menu, and the window. Both, menu and window gadgets correspond directly to each other. Both, menu items and gadgets support shortcuts. The shortcuts of the menu are the same as the shortcuts of the gadgets, but they need the left Amiga key qualifier pressed additionally. So both, `I'(or i') and LAMIGA+`I'(or `i') result in the same action as if the Instruction Cache gadget or menu item would have been clicked/selected. The shortcuts are not listed in this documentation for the user can directly determine them from the GUI. The menu shortcuts are shown right to the appropriate menu item if it supports shortcuts. The gadget shortcuts are case insensitive (like the menu shortcuts). The underlined character of the gadget description text is the corresponing shortcut key, not to be pressed with additional qualifiers except for optionally SHIFT. If the launched command line would produce any outputs to the CLI window, this output is redirected to a automatically on the default public screen opening CON: window, which can be closed asynchroneously (meaning that RunLame is not running any more, but the window remains on the default public screen and can be closed when not needed any more). In addition to be able to input the command line using the string gadget or the filerequester, it is possible to drop (multiselected) icons from the Workbench into the GUI window. The name(s) of the corresponding object(s) appear(s) in the command line string gadget added to the end of the previous contents (assuming @{"NOAPPEND" LINK Option_APPEND} has not been supplied). Using the @{"PATH" LINK Option_PATH} parameter makes it possible to set an initial drawer for the file requester (normally the file requester uses the current directory as initial drawer) One special shortcut is the `HELP' key. If pressed, the online @{"AmigaGuide" LINK AmigaGuide_Explanation} documentation is shown asynchroneously. This means you need not to close the guide before using the GUI again. If no guide appears, you should check if the documentation (@{B}RunLame.guide@{UB}) resides in the AmigaGuide path (defined in @{B}ENV:AmigaGuide/Path@{UB}). If you want to place the documentation outside the AmigaGuide path, you have to specify the location using @{"GUIDENAME" LINK Option_GUIDENAME}. The pull down menu (shortcuts not documented): @{U}main menu strip@{UU}: @{U}sub menu strips@{UU}: +======================+ +=============+ +=============+ +=============+ |RunLame | |VBR location | |Caches | |Burst modes | +======================+ +=============+ +=============+ +=============+ |@{"About" LINK GUI_About} | | @{"$0" LINK Option_VBR} | | @{"Instruction" LINK Option_INSTCACHE} | | @{"Instruction" LINK Option_INSTBURST} | |~~~~~~~~~~~~~~~~~~~~~~| | @{"FAST memory" LINK Option_VBR} | | @{"Data" LINK Option_DATACACHE} | | @{"Data" LINK Option_DATABURST} | |VBR location | +-------------+ | @{"External" LINK Option_EXTERNALCACHE} | +-------------+ |Caches | +-------------+ |Burst modes | | @{"Copyback mode" LINK Option_COPYBACK} | |~~~~~~~~~~~~~~~~~~~~~~| | @{"Screen" LINK Option_SCREEN} | | @{"Visible screen" LINK Option_VISIBLE} | |~~~~~~~~~~~~~~~~~~~~~~| |@{"Enter commandline" LINK GUI_EnterCommandline} | |@{"Open file requester" LINK GUI_OpenFReq} | |@{"Launch commandline" LINK GUI_Launch} | |~~~~~~~~~~~~~~~~~~~~~~| |@{"Quit" LINK GUI_Quit} | +----------------------+ @{U}application window@{UU}: +-----------------------+ |@{"·" LINK GUI_Quit} RunLame @{" " SYSTEM}@{" " SYSTEM} | +-----------------------+ |+---------------------+| ||@{" $0 " LINK Option_VBR} VBR location || |+---------------------+| ||@{" " LINK Option_INSTCACHE} Instruction Cache || ||@{" " LINK Option_DATACACHE} Data Cache || ||@{" " LINK Option_EXTERNALCACHE} External Caches || |+---------------------+| ||@{" " LINK Option_INSTBURST} Instruction Burst || ||@{" " LINK Option_DATABURST} Data Burst || |+---------------------+| ||@{" " LINK Option_COPYBACK} Copyback || |+---------------------+| ||@{" " LINK Option_SCREEN} Screen @{" " LINK Option_VISIBLE} Visible|| |+---------------------+| | @{" " LINK GUI_OpenFReq}@{" " LINK Option_COMMANDLINE} | | @{" Launch commandline " LINK GUI_Launch} | +-----------------------+ @ENDNODE ##_____________________________________________________________________________ @NODE GUI_About "About menu item" @PREV Option_GFXUSERINTERFACE @NEXT Option_GFXUSERINTERFACE @{U}Explanation@{UU}: A short copyright notice is shown in a requester. Same effect if you press `?'. @ENDNODE ##_____________________________________________________________________________ @NODE GUI_EnterCommandline "Enter commandline menu item" @PREV Option_GFXUSERINTERFACE @NEXT Option_GFXUSERINTERFACE @{U}Explanation@{UU}: Activate the commandline string gadget which enables you to specify a @{"COMMANDLINE" LINK Option_COMMANDLINE}. You may also press `ENTER',`RETURN' or `TAB' to activate the commandline string gadget. @ENDNODE ##_____________________________________________________________________________ @NODE GUI_OpenFReq "Open file requester" @PREV Option_GFXUSERINTERFACE @NEXT Option_GFXUSERINTERFACE @{U}Explanation@{UU}: Open an ASL file requester. You then may select a file whose path/name will be appended to the commandline, depending on the @{"APPEND" LINK Option_APPEND} switch. @ENDNODE ##_____________________________________________________________________________ @NODE GUI_Launch "Launch commandline" @PREV Option_GFXUSERINTERFACE @NEXT Option_GFXUSERINTERFACE @{U}Explanation@{UU}: This action ignites the execution of the command line. The current configuration of RunLame is active during the execution of the command line defined in the command line string gadget. After execution the changed settings of your system are reset to the state active before. So if you know that for example the demo called @{B}ObsoleteFX@{UB} will not run with active data cache, but an active instruction cache would speed it up, forthermore it won't run in burst mode and with VBR in another location than $0.l, use: @{B}RunLame GUI INSTCACHE NODATACACHE NOBURST INVISIBLE ObsoleteFX@{UB} You will see the correct setting reflected in the gadgets and the menu items. If you now launch the command line, the following will happen: assumed system settings before launching: data cache active | instruction cache active data burst mode active | instruction burst mode inactive VBR in Fast RAM at position p system settings during execution of ObsoleteFX (launched): data cache inactive | instruction cache active data burst mode inactive | instruction burst mode inactive VBR at $0.l system settings after execution of ObsoleteFX: data cache active | instruction cache active data burst mode active | instruction burst mode inactive VBR in Fast RAM at position p @ENDNODE ##_____________________________________________________________________________ @NODE GUI_Quit "Quit RunLame" @PREV Option_GFXUSERINTERFACE @NEXT Option_GFXUSERINTERFACE @{U}Explanation@{UU}: The RunLame task/process will stop existing, all held resources are given back to the system. The looping mode (activated by @{"LOOP" LINK Option_LOOP}) is stopped, too. You may quickly exit RunLame by pressing the `ESC' key. @ENDNODE ##_____________________________________________________________________________ @NODE Option_APPICON "APPICON, API" @PREV Option_GFXUSERINTERFACE @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} APPICON | API APPICON | API = USE @{U}Explanation@{UU}: The @{"API" LINK API_Explanation} supplies a comfortable method of immediate starting objects whose icons are dropped into it. It is possible to multiselect icons, so the command line consists of all objects in the order they have been selected. To quit RunLame, double click the API. When a command line has been supplied at the startup of RunLame, all icons/objects dropped into the API are appended to this command line, then the command line is executed (assuming @{"NOAPPEND" LINK Option_APPEND} has not been supplied). When too many icons are dropped into the API , the Workbench screen beeps before command line execution. Output produced by the command line goes to the CLI when RunLame was started not from the Workbench. The icon representing the API is the same as used for RunLame (if this is missing, the system default icon is used) , the name is the same as RunLame has on your disk. @ENDNODE ##_____________________________________________________________________________ @NODE Option_LOOP "LOOP, L" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} LOOP | L LOOP | L = YES @{U}Explanation@{UU}: The LOOP option can only be used together with @{"API" LINK Option_APPICON} and/or @{"GUI" LINK Option_GFXUSERINTERFACE}. When you want to start several command lines in a sequence, it is quite unconfortable to always start RunLame for each command line execution. LOOP works around this problem by forcing RunLame to pop up the @{"API" LINK API_Explanation} and/or @{"GUI" LINK GUI_Explanation} again after each command line execution, until it is quitted by double clicking the API or quitting the GUI. When the appropriate input object (API/GUI) pops up again, the initial command line given at startup of RunLame (@{"COMMANDLINE" LINK Option_COMMANDLINE}) is always inserted at front of the command line created using the input object. Furthermore all settings of the former command line execution are preserved. Example: @{B}RunLame APPICON LOOP dir@{UB} You can now drop icons of Workbech drawers into the application icon to list their contents. The @{B}dir@{UB} command is always assumed to be the first part in the command line. Same applies to startup from Workbench via (multi-)selected icons. @ENDNODE ##_____________________________________________________________________________ @NODE Option_DEFAULTS "DEFAULTS, NODEFAULTS, D, ND" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} DEFAULTS | D DEFAULTS | D = USE NODEFAULTS | ND DEFAULTS | D = NO @{U}Explanation@{UU}: If you specify DEFAULTS at startup of RunLame, the following options are assumed: @{"SCREEN" LINK Option_SCREEN}, @{"VISIBLE" LINK Option_VISIBLE}, @{"NOCACHE" LINK Option_CACHE}, @{"NOINSTCACHE" LINK Option_INSTCACHE}, @{"NODATACACHE" LINK Option_DATACACHE}, @{"NOBURST" LINK Option_BURST}, @{"NOINSTBURST" LINK Option_INSTBURST}, @{"NODATABURST" LINK Option_DATABURST}, @{"NOCOPYBACK" LINK Option_COPYBACK}, @{"NOEXTERNALCACHE" LINK Option_EXTERNALCACHE}, @{"VBRTO0" LINK Option_VBR}, @{"APPEND" LINK Option_APPEND} The DEFAULTS option is always assumed to be set. So if you want to disable all caches, the copyback mode and want to degrade the display, you need not to specify one of these options. Those options are really obsolete, but were implemented for completeness. Furthermore the specification of those options in script files (though leaving them out would have the same effect) increases the readability of the script file because every user not knowing which defaults are set by RunLame can see what really is going to happen. So the following usages of RunLame affect in the same: @{B} RunLame foobar RunLame D S NC NB NCB NEC NVBR CL foobar RunLame BURST NIC NOEXTERNALCACHE CL=foobar RunLame SCREEN NOINSTCACHE NODATACACHE NOINSTBURST NODATABURST NOCOPYBACK NOEXTERNALCACHE VBRTO0 DEFAULTS COMMANDLINE=foobar @{UB} The NODEFAULTS switch forces RunLame to configure itself to fit best the current system settings. So if you specify NODEFAULTS and don't override any of the settings, RunLame will change nothing in the system while executing the commandline. Furthermore specification of options overrides the DEFAULTS/NODEFAULTS settings of RunLame. So it's possible to start programs in your normal environment, with some parameters just changed, not all possible. The parameters changed are set to the same value each time you use this feature, but the rest of the settings are the built in defaults/the current system setting. Example: @{B}RunLame NODEFAULTS VBRTO0 SCREEN INVISIBLE ObsoleteFX@{UB} assumed system settings before RunLame usage: data cache active | instruction cache active data burst mode active | instruction burst mode inactive external caches inactive | copyback mode active VBR in Fast RAM at position p system settings during execution of ObsoleteFX: data cache active | instruction cache active data burst mode active | instruction burst mode inactive external caches inactive | copyback mode inactive VBR at $0.l screenmode changed to PAL, screen blanked, sprite resolution changed to lores and sprites turned off system settings after execution of ObsoleteFX: data cache active | instruction cache active data burst mode active | instruction burst mode inactive external caches inactive | copyback mode active VBR in Fast RAM at position p @ENDNODE ##_____________________________________________________________________________ @NODE Option_SCREEN "SCREEN, NOSCREEN, S, NS" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} SCREEN | S SCREEN | S = ON NOSCREEN | NS SCREEN | S = OFF @{U}Explanation@{UU}: Non system conform programmed software might cause problems when started from within another screen mode than PAL. This might effect in weird running bitplanes or anything else, but when it happens, you will become aware of it, believe me. To avoid these annoying problems, the default option called SCREEN opens a 2x2 pixels wide screen with depth 1 (this should eat up not very much memory :-) before starting the problematic program. Due to the existance of several screen mode promotion tools I have to point out that it is not very clever to allow promotion of the screen opened by RunLame. Furthermore some programs use an incorrect method to turn off sprites which results in running pixel patterns (similar to the above decribed bitplane effect). RunLame tries to avoid this problem when the SCREEN option is active. In favour to RunLame's multitasking abilities, the sprite DMA is not shut down, but redirected to a NULL sprite (which is the most effective method to turn off sprites). This method cannot avoid, that the pointer is reactived by any window becoming active after turning off the sprites (refer to @{"Problems - solutions - corner" LINK ProblemsSolutions}). @ENDNODE ##_____________________________________________________________________________ @NODE Option_VISIBLE "VISIBLE, INVISIBLE, V, NV" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} VISIBLE | V VISIBLE | V = YES INVISIBLE | NV VISIBLE | V = NO @{U}Explanation@{UU}: The VISIBLE option keeps the previous frontmost screen visible, but displayed in PAL. This is handy when the program you start with RunLame outputs to any window opened/opening on the previous frontmost screen. For programs that don't output anything to the previous frontmost screen, use the INVISIBLE option, so the current display contents are hidden. This option only makes sense together with the @{"SCREEN" LINK Option_SCREEN} option. @ENDNODE ##_____________________________________________________________________________ @NODE Option_CACHE "CACHE, NOCACHE, C, NC" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} CACHE | C CACHE | C = ON NOCACHE | NC CACHE | C = OFF @{U}Explanation@{UU}: This option controls all processor caches installed in the system. Refer to @{"INSTCACHE" LINK Option_INSTCACHE} and @{"DATACACHE" LINK Option_DATACACHE} for more detailed description. @ENDNODE ##_____________________________________________________________________________ @NODE Option_INSTCACHE "INSTCACHE, NOINSTCACHE, IC, NIC" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} INSTCACHE | IC INSTCACHE | IC = ON NOINSTCACHE | NIC INSTCACHE | IC = OFF @{U}Explanation@{UU}: This option allows you to control the instruction cache of the @{"CPU" LINK CPU_Explanation}. Some lame programs use self modifying code which can lead to inconsistency between cache contents and memory contents. The result in most cases is a system crash. In this case turn off the instruction cache. @ENDNODE ##_____________________________________________________________________________ @NODE Option_DATACACHE "DATACACHE, NODATACACHE, DC, NDC" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} DATACACHE | DC DATACACHE | DC = ON NODATACACHE | NDC DATACACHE | DC = OFF @{U}Explanation@{UU}: This option allows you to control the data cache of the @{"CPU" LINK CPU_Explanation}. Some @{"lame" LINK Lame_Explanation} programs modify memory data whilst it is read by a DMA channel, which can lead to inconsistency between cache contents and memory contents. The result in most cases is a weird display, a crash or other anomalies. In this case turn off the data cache. @ENDNODE ##_____________________________________________________________________________ @NODE Option_BURST "BURST, NOBURST, B, NB" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} BURST | B BURST | B = ON NOBURST | NB BURST | B = OFF @{U}Explanation@{UU}: This option lets you control the burst modes of the @{"CPU" LINK CPU_Explanation} caches all together. Refer to @{"INSTBURST" LINK Option_INSTBURST} and @{"DATABURST" LINK Option_DATABURST} for more detailed description. @ENDNODE ##_____________________________________________________________________________ @NODE Option_INSTBURST "INSTBURST, NOINSTBURST, IB, NIB" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} INSTBURST | IB INSTBURST | IB = ON NOINSTBURST | NIB INSTBURST | IB = OFF @{U}Explanation@{UU}: This option allows you to control the burst mode of the instruction cache of the @{"CPU" LINK CPU_Explanation}. Disabling might fix strange behaviour of programs. @ENDNODE ##_____________________________________________________________________________ @NODE Option_DATABURST "DATABURST, NODATABURST, DB, NDB" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} DATABURST | DB DATABURST | DB = ON NODATABURST | NDB DATABURST | DB = OFF @{U}Explanation@{UU}: This option allows you to control the burst mode of the data cache of the @{"CPU" LINK CPU_Explanation}. Disabling might fix strange behaviour of programs. @ENDNODE ##_____________________________________________________________________________ @NODE Option_COPYBACK "COPYBACK, NOCOPYBACK, CB, NCB" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} COPYBACK | CB COPYBACK | CB = YES NOCOPYBACK | NCB COPYBACK | CB = NO @{U}Explanation@{UU}: If none of the other option helps improving the behaviour of a @{"lame" LINK Lame_Explanation} program, try changing the state of the copyback mode of the @{"CPU" LINK CPU_Explanation}. @ENDNODE ##_____________________________________________________________________________ @NODE Option_EXTERNALCACHE "EXTERNALCACHE, NOEXTERNALCACHE, EC, NEC" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} EXTERNALCACHE | EC EXTERNALCACHE | EC = ON NOEXTERNALCACHE | NEC EXTERNALCACHE | EC = OFF @{U}Explanation@{UU}: This option should give you control over externally installed caches. Due to lack of such hardware, this could not be tested. Furthermore it seems not possible to check for existence of such caches in a system friendly manner. Therefore this option is not accessible. @ENDNODE ##_____________________________________________________________________________ @NODE Option_VBR "VBRTOFAST, VBRTO0, VBRTO, VBR, NVBR" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} VBRTOFAST | VBR VBRTO | VBR = FAST VBRTO0 | NVBR VBRTO | VBR = 0 @{U}Explanation@{UU}: This option gives you control over the @{"VBR" LINK VBR_Explanation} of the @{"CPU" LINK CPU_Explanation}. Most of old programs using interrupts don't consider the fact, that 68010+ CPUs have a VBR. Since Kickstart V36 the VBR is not granted to point to address $0 (which is located in CHIP memory). If such a @{"lame" LINK Lame_Explanation} program accesses CPU vectors which are offsets to the VBR, and the VBR doesn't point to $0, the CPU jumps to an undefined memory location. Most of the crashes can be fixed by moving the VBR to location $0. @ENDNODE ##_____________________________________________________________________________ @NODE Option_APPEND "APPEND, NOAPPEND, APN, NAPN" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} APPEND | APN APPEND | APN = YES NOAPPEND | NAPN APPEND | APN = NO @{U}Explanation@{UU}: The APPEND option is set by default, but can be overriden by NOAPPEND. APPEND is responsible for the appending behaviour of the file requester (or the application window feature and the @{"APPICON" LINK Option_APPICON} feature). If you specify NOAPPEND, the command line will always be overwritten by any new given filenames. This works for the application icon, the application window feature and the file requester. You see, when you use @{"APPICON" LINK Option_APPICON} and NOAPPEND together, it's senseless to supply a startup command line, because it's going to be overwritten by the objects you drop into the application icon. @ENDNODE ##_____________________________________________________________________________ @NODE Option_PATH "PATH, P" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} PATH | P = path PATH | P = path @{U}Explanation@{UU}: Using this option you may specify a default startup path for the file requester of the @{"GUI" LINK Option_GFXUSERINTERFACE}. This is useful if the program you want to execute is not located in the current directory. @ENDNODE ##_____________________________________________________________________________ @NODE Option_GUIDENAME "GUIDENAME, GN" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} GUIDENAME | GN = name GUIDENAME | GN = name @{U}Explanation@{UU}: Using this option you may specify a default path/name for the @{"guide" LINK Option_GUIDE} help document. This is useful, if you press the HELP key in the @{"GUI" LINK Option_GFXUSERINTERFACE} and no @{"guide" LINK Option_GUIDE} help appears. @ENDNODE ##_____________________________________________________________________________ @NODE Option_COMMANDLINE "COMMANDLINE, CL" @{U}CLI options @{UU} @{U}Workbench tooltypes @{UU} COMMANDLINE | CL = cmd COMMANDLINE | CL = cmd @{U}Explanation@{UU}: The command line may consist of same complex format as could be used in the AmigaDOS shell. The only thing you must pay attention to is that the COMMANDLINE option is always specified as the last one in the whole parameter line, or if not explicitely specified, the name of the program that shall be executed must be the last word in the parameter line. In-/Output redirection is possible. Examples of valid usage: @{B}RunLame NV VirtualIntelligence @{UB};a demo @{B}RunLame NS C B CB EC VBR CL list >RAM:foo SYS: @{UB};senseless, but works @{B}RunLame NOSCREEN CACHE B CL= C:dir RAM: @{UB};senseless, but works @{B}RunLame SCREEN VISIBLE COMMANDLINE XCopyPro @{UB};a copy program @{B}RunLame NS IC DC IB DB NCB COMMANDLINE=Resident @{UB};works ;(Resident is resident here :-) NOTE: when you use filenames containing blank characters, you have to enclose them into triple quotation marks: for AmigaShell from C=: @{B}RunLame """foo bar"""@{UB} for CShell (Unix port): @{B}RunLame \\"\\"\\"foo bar\\"\\"\\"@{UB} Otherwise the shell will strip away the quotation marks, and RunLame will never see them, thus executing the command line without quotation marks, which of course will interpret the blank characters as name delimiters. @ENDNODE ##_____________________________________________________________________________ @NODE Configuring "Configuring RunLame" @{U}Configuring RunLame@{UU} @{U}Configuring for shell@{UU}: At first the configuring procedure for shell users is going to be described. As you know you have the possibility to use the built in @{"defaults" LINK Option_DEFAULTS} of RunLame or the @{"current system settings" LINK Option_DEFAULTS} for some of the configuration parameters (@{"VBR" LINK Option_VBR}, @{"CACHE" LINK Option_CACHE},...). Those can be overridden by further specified @{"options" LINK ShellOptions} and parameters. Furthermore you placed the documentation (@{B}RunLame.guide@{UB}) outside the AmigaGuide path (defined in @{B}ENV:AmigaGuide/Path@{UB}). So when you want always to use another configuration than the defaults, just make an alias for the desired configuration. Example: @{B}Alias RunLame 'RunLame NODEFAULTS SCREEN INVISBLE VBR LOOP API GUIDENAME=Docs:RunLame.guide'@{UB} So when you now type @{B}RunLame@{UB}, it always opens the API, it loops and uses the current systems setting except for the display which is degraded and black, and the VBR is always moved to $0.l. Additionaly the guide is found. @{U}Configuring for Workbench@{UU}: Workbench users just can do the same, they need only to specify the appropriate @{"tooltypes" LINK WorkbenchTooltypes} for the icon. Now you can experiment a bit (follow the instructions below): ·@{B}MakeLink FROM RAM:DirLame TO RunLame@{UB} ·@{B}Copy RunLame.info@{UB} (which came with this distribution) @{B}TO RAM:DirLame.info@{UB} ·Edit the @{"tooltypes" LINK WorkbenchTooltypes} in this way: @{B}COMMANDLINE=dir APPICON=USE LOOP=YES DEFAULTS=NO@{UB} (the other @{"tooltypes" LINK WorkbenchTooltypes} keep the way they are) ·Now double click DirLame. Now an application icon named @{B}DirLame@{UB} should appear on the Workbench. Drop some drawer icons into this and watch what's happening. If you need such gimmicks very often, you may draw a special icon for this purpose. Using RunLame from Workbench often shows up the problem, that the default path of the @{"filerequester" LINK GUI_OpenFReq} (of the @{"GUI" LINK Option_GFXUSERINTERFACE}) is pointing to the directory where RunLame is located. This is annoying in the most cases. So if you have a special directory from where you are used to start the @{"lame" LINK Lame_Explanation} programs, set the @{"PATH" LINK Option_PATH} tooltype to this directory. @{U}Configuring for Directory Opus@{UU}: Directory Opus users may want to install RunLame as a button, which starts all highlighted files in the file listview. Enter the configuration module and the @{B}Buttons@{UB} section. Press one of the still unused buttons. Enter `@{B}RunLame@{UB}' for @{B}@{U}N@{UU}ame@{UB} string gadget. Make a @{B}New entry@{UB} which is @{B}AmigaDOS@{UB}. Enter `@{B}[path]RunLame [@{"options" LINK ShellOptions}] {f}@{UB}' in the @{B}entry@{UB} string gadget (replace [path] by the path where RunLame is located). Enter @{B}@{U}S@{UU}tack size@{UB} `@{B}4000@{UB}', @{B}@{U}P@{UU}riority@{UB} `@{B}0@{UB}', @{B}@{U}C@{UU}lose delay@{UB} `@{B}2@{UB}'. Uncheck all entries in the @{B}Flags...@{UB} listview gadget. Check @{B}Output window@{UB} and @{B}Do all files@{UB} in the listview gadget. Click @{B}Okay@{UB}. Click @{B}Okay@{UB}. Click @{B}Save@{UB}. Click @{B}Okay@{UB}. The new @{B}RunLame@{UB} button is now fully functional. Highlight a @{"lame" LINK Lame_Explanation} file and press the new button. Voilà. @ENDNODE ##_____________________________________________________________________________ @NODE ProblemsSolutions "RunLame `Problems - solutions - corner'" @NEXT KnownBugs @{U}Problems - solutions - corner@{UU} ·If you got this error message: @{B} Screenmode degrading failed! Forbid all promotion utilities to promote: "RunLame (© by Bilbo 1st of Hypenosis)" @{UB} Then you have probably installed one of the screenmode promotion utilities (fi. The Promotor, NewMode, ForceMonitor, PKludge). This promotion tool will then promote the compatibility screen too, what is a really stupid idea. You should prevent the promotion utility from promoting all screens with the title "@{B}RunLame (© by Bilbo 1st of Hypenosis)@{UB}". ·After having been degraded, the display snaps back to the normal previous mode when a window has been opened. This window might be owned by the @{"lame" LINK Lame_Explanation} program or any other task. The problem with this window is it's ability to bring it's underlying screen to the very front of all screens. The currently frontmost screen now forces the display to it's own screenmode, thus stopping the graphics hardware displaying a degraded display. This is multitasking, and this is Amiga - you cannot do anything against this without violating multitasking rules. Of course it is possible to avoid this problem by hardware hitting, but this works against the concept of multitasking and will therefore not be done. If you need this though, try @{"another degrading tool" LINK OtherDegraders}. ·The sprite DMA shows weird patterns, though you made RunLame degrade the display (which should turn off the sprites, too). If this happens, one of the currently open windows became active. All windows have an own pointer image, which becomes active on window activation. You may have installed an AutoPointer/SunMouse utility which activated a window after the sprites have already been turned off. Avoid this by disabling the appropriate application (the window-activating one). Another possibility is, that the launched program opened a window which became active. You can't easily work around the latter problem. ·The program you want to start is self-detaching and the settings of RunLame are only valid until the program has detached itself. If the program has an option to turn off detaching, then use this option at starting the program to prevent detach. Otherwise, bad luck. ·You have @{"Enforcer" LINK Enforcer_Explanation} running and your system always hangs when you start an Program using the @{"VBRTOFAST|VBRTO0" LINK Option_VBR} option. See the Knows Bugs section for an explanantion for this phenomenon. Quit @{"Enforcer" LINK Enforcer_Explanation} before you use the @{"VBRTOFAST|VBRTO0" LINK Option_VBR} option. ·You press `HELP' in the @{"GUI" LINK Option_GFXUSERINTERFACE}, but no online @{"guide" LINK Option_GUIDE} opens. Probably the documentation (@{B}RunLame.guide@{UB}) is not located in the @{"AmigaGuide" LINK AmigaGuide_Explanation} path (defined in @{B}ENV:AmigaGuide/Path@{UB}). You may add the location of the documentation to the AmigaGuide path (which should increase search time of AmigaGuide applications). Another possibility is, to use the @{"GUIDENAME" LINK Option_GUIDENAME} option to specify the path/name of the documentation guide. ·When you use filenames containing blank characters, you have to enclose them into triple quotation marks: for AmigaShell from C=: @{B}RunLame """foo bar"""@{UB} for CShell (Unix port): @{B}RunLame \\"\\"\\"foo bar\\"\\"\\"@{UB} Otherwise the shell will strip away the quotation marks, and RunLame will never see them, thus sending the command line without quotation marks to System(), which of course will think that the blank characters are name delimiters. Let me point out that this is @{B}NOT@{UB} a bug of RunLame, learn to live with it. ·When starting RunLame from CShell, and you ask for the error cause using the @{B}why@{UB} command, you will always get the message that no error occured, even if really an error occured. This is @{B}NOT@{UB} a bug of RunLame, but of the CShell V5.31-. If you rely on those error codes, use the AmigaShell of C= instead of the CShell. ·You start RunLame with the intention to display the CLI template using @{B}RunLame ?@{UB}. The template is displayed, but the shell does not allow any CLI input. Instead of waiting for input, RunLame immediately opens the GUI. It is probable that you are using CShell V5.20+ and RunLame resides in the script path defined in the _path variable of the shell. This is @{B}NOT@{UB} a bug of RunLame. I reported this problem to the current developer of CShell, so this might be fixed in future. In the meantime fix the problem by placing RunLame somewhere in your DOS path which is defined by the AmigaDOS command @{B}path@{UB} (fi.: @{B}Path Work:BestToolEver ADD; Rename RunLame Work:BestToolEver/RunLame@{UB}) or specify the full path of RunLame's location in the filesystem each time you want to use it (this might happen in an alias like this: @{B}alias runlame Work:BestToolEver/RunLame@{UB}). ·You tried everything, but you didn't manage to run a @{"lame" LINK Lame_Explanation} program properly. RunLame is not able to fix very @{"lame" LINK Lame_Explanation} programming bugs, so you can assume, the programmer of the program is @{"lame" LINK Lame_Explanation} himself, or didn't have enough time to do a proper code. But nobody is perfect :-) Your last chance might be to try @{"other degraders" LINK OtherDegraders} available in the Amiga world. @ENDNODE ##_____________________________________________________________________________## ## ## ## Explanation nodes ## ##_____________________________________________________________________________## ##_____________________________________________________________________________ @NODE Lame_Explanation "What or who is lame?" In terms of Amiga scene users the word @{B}lame@{UB} is used upon persons and objects (programs, tunes, pictures,...) and can mean very different things. Lame persons are people who have their Amiga for a certain time and cannot be called beginners any more. A lamer has not learned anything while the whole time he/she uses his/her Amiga. The thing a lamer can do best is using autobooting software. Secondly some people who get a very high rate of new software call other users who don't have access to the latest programs lamers, too. But in this case the lamer is the one who is proud on getting the latest software (@{I}yOoOo ya'r so 3lIté@{UI} :-), in my eyes. Third possible approach for defining a lamer is the person's coding abilities. Some people name others lamers, due to the fact that their programming abilities are more advanced than the ones of the others. Very often do programmers call others lamers because they think they are themselves very @{I}kewl@{UI} and unbeatably the best. In most cases the code of such @{I}superc00ld00dz@{UI} turned out to crash on non-Amiga500-$C00000 models. Decide yourself who is lame here. The latter definition leads us to the subject of lame productions, of maybe lame people. In the case of RunLame only lame programs are of an interest, other kinds of lame objects are not considered here. Some people call it lame to use system functions in programs and therefore program everything themselves. The makers of trackloading demos seem to think in this track. Poorly the people who think to be able to make it always better than the operating system fail to test their code thoroughly and often their programs don't work on advanced hardware or operating system improvements. Other people like their demos to be run out of the Amiga's multitasking environment and turn off the multitasking. Some of them are so smart to think after a single Disable() the multitasking is shut down properly and they might do what they want (fixed address code, assuming screenmode/resolution is set properly, assuming there are no caches, or VBR). The demo may run, and if, it might never return to multitasking. Others return to multitasking, which is totally trashed then. This seems to be worth called lame, doesn't it? Most kinds of demo effects or game effects cannot be programmed satisfactory using the system functions, so shutting down the system is not a bad idea, but shutting down a multitasking system requires a high level of understanding how multitasking works on an Amiga. So if people think they can code like kings, make a lot demos that crash all sorts of Amigas, they ridicule themselves and just do show that they try to jump around before they have learned to walk stably. In my eyes this is really lame and childish. It is simply annoying to have to reboot the machine, just because having watched a demo or having played a game. This must seem very ridiculous to an IBM-compatible PC user, whom you try to impress by showing demos that always force your machine down to it's knees. Seriously, we all laugh about the lame PCs and PC programs, but most of the brill' Amiga demos are less compatible. So if MSDOS/WINDOWS PCs are lame (and they are), don't be as same as lame! Think twice, what is the difference between Amigas and PCs! @ENDNODE ##_____________________________________________________________________________ @NODE TLA_Explanation "What a TLA is" A @{B}TLA@{UB} is a @{"TLA" LINK TLA_Explanation} for the word @{B}T@{UB}hree @{B}L@{UB}etter @{B}A@{UB}cronym. @ENDNODE ##_____________________________________________________________________________ @NODE CPU_Explanation "What a CPU is" @{B}CPU@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}C@{UB}entral @{B}P@{UB}rocessing @{B}U@{UB}nit. The CPU is the hardware which reads and executes programs instruction by instruction. @ENDNODE ##_____________________________________________________________________________ @NODE VBR_Explanation "What the VBR is" @{B}VBR@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}V@{UB}ector @{B}B@{UB}ase @{B}R@{UB}egister. The VBR points to the memory address, which is the base for several vector offsets (f.i. interrupt vector offsets). @ENDNODE ##_____________________________________________________________________________ @NODE MMU_Explanation "What a MMU is" @{B}MMU@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}M@{UB}emory @{B}M@{UB}anagement @{B}U@{UB}nit. A MMU is a very powerful memory mapping hardware. It allows f.i. mapping addresses generated by the @{"CPU" LINK CPU_Explanation} to another hardware address. If no hardware address can be associated, an interrupt can be triggered. This both allows implementation of virtual memory. @ENDNODE ##_____________________________________________________________________________ @NODE OCS_Explanation "What OCS is" @{B}OCS@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}O@{UB}riginal @{B}C@{UB}hip @{B}S@{UB}et. The graphics abilities available under OCS are the lowest possible on any Amiga Model. @ENDNODE ##_____________________________________________________________________________ @NODE ECS_Explanation "What ECS is" @{B}ECS@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}E@{UB}nhanced @{B}C@{UB}hip @{B}S@{UB}et. The graphics abilities available under ECS are a superset of the graphics abilities of @{"OCS" LINK OCS_Explanation}. @ENDNODE ##_____________________________________________________________________________ @NODE AGA_Explanation "What AGA is" @{B}AGA@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}A@{UB}dvanced @{B}G@{UB}raphics @{B}A@{UB}rchitecture. The graphics abilities available under AGA are a superset of the graphics abilities of @{"OCS" LINK OCS_Explanation} and @{"ECS" LINK ECS_Explanation}. @ENDNODE ##_____________________________________________________________________________ @NODE GUI_Explanation "What a GUI is" @{B}GUI@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}G@{UB}raphical @{B}U@{UB}ser @{B}I@{UB}nterface. A GUI should even unexperienced users enable to access a utility without being confused by a variety of new objects and operation methods. Standardized GUIs like supported by gadtools.library give programs based on it a similar look. All operations are accessed by the same objects and their behaviour is standardized (objects are checkboxes, cycle gadgets, listviews, pull down menus, drop-in-icons, drop-in-windows,...). @ENDNODE ##_____________________________________________________________________________ @NODE MUI_Explanation "What MUI is" @{B}MUI@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}M@{UB}agic @{B}U@{UB}ser @{B}I@{UB}nterface. MUI is a very powerful class oriented @{"GUI" LINK GUI_Explanation}. MUI is © by Stefan Stuntz. @ENDNODE ##_____________________________________________________________________________ @NODE API_Explanation "What an API is" @{B}API@{UB} is a @{"TLA" LINK TLA_Explanation} for @{B}Ap@{UB}plication @{B}I@{UB}con. An API is an icon into which you can drop other icons. Normally application icons are located on the Workbench and icons of any file can be dropped into it. @ENDNODE ##_____________________________________________________________________________ @NODE AmigaGuide_Explanation "What is AmigaGuide" @{B}AmigaGuide@{UB} is a hypertext system for the Amiga. You are using it right now. This text is displayed by an application supporting AmigaGuide documents. @ENDNODE ##_____________________________________________________________________________ @NODE Enforcer_Explanation "What is Enforcer" @{B}Enforcer@{UB} is a tool written by Michael Sinz. It helps developers to find some kind of bugs. The symptoms of such bugs are called @{B}Enforcer hits@{UB}. @ENDNODE ##_____________________________________________________________________________ @NODE OtherDegraders "Other Degraders available" @{U}Other system degrading software@{UU} By time several other degraders with different facilities are available in the Amiga world. I will not give a rating for them, but you should beware which you use, some are in fact of minor quality and might crash your system (and crashing the system is indeed a poor idea while you are write-accessing any form of disk). All degraders known to me are listed below and are available from AmiNet (lowest required Kickstart release in @{B}[]@{UB}s): Degrader V1.30 [V1.2 - V3.0, depends on used features] EmbedderII V1.0 [V2.04 - V3.0, depends on used features] KillAGA V2.0 [V3.0] RunIt V1.4 [V1.2] RunShit V1.06 [V1.2] WBKillAGA V1.0 [V3.0] (needs KillAGA) I doubt that you will have more luck using those programs, but if so, @{"contact" LINK ContactAuthor} me and let me know. Ah, and let me point out, that Degrader was the first degrader published. Degrader just lacks the capability of restoring the system to it's previous state, so RunLame was born. All other degraders known were released after RunLame, hence any resemblance to RunLame is probably not only a coincidence. Nevertheless RunLame is the only Degrader available to me, that was able to switch the display into PAL mode when a screenmode of a graphics board was active (tested with a Merlin graphics board © by X-Pert). All other Degraders just left the graphics board's screenmode active. @ENDNODE ##_____________________________________________________________________________ @NODE BetaTesting "Beta testing of RunLame" @{U}How RunLame has been ß-tested@{UU} At first RunLame is tested by the author who has access to several Amiga computer models (his own and computers of friends of him). So RunLame is instantly tested on the following configurations: ·Amiga 2000 (68000, ECS, Kickstart 2.04, Workbench 2.1) ·Amiga 3000 (68030, ECS, Kickstart 2.04, Workbench 2.0) ·Amiga 3000 (68030, ECS, Merlin, latest available Kickstart and Workbench) When RunLame works o.k. on above models, it is sent to several people (ß-testers) on the internet computer network. Because the author has no quick access to an AGA model, he relies on bug reports from his ß-testers. Many of the ß-testers have an AGA machine, so RunLame will be tested under this environment. Because the author often receives AGA bug reports some days after spreading the latest ß-versions of RunLame, the turn-around times for bug fixing are enormous (no direct feedback if the bug is really gone after having modified RunLame). So after adding a new feature, the author has to wait for rather a long time after spreading the ß-version to ensure no bugs were embedded. After this certain time interval, RunLame theoretically is ready to go to a public audience. So, when the ß-testers are lazy and don't send a bug report when they find a bug, a buggy version will be spread to a wide audience. The bugs in it will only affect AGA machines though. This problem has shown up on version 1.28 which used to crash on AGA models, but the author didn't recognize the bug, because RunLame worked very normal on the above mentioned machines. The author asks the AGA users of RunLame for their understanding and forgiving if a version of RunLame doesn't work on their configuration. All known bugs will of course be fixed as fast a possible. If someone desires to send me a bug report or wants to become ß-tester, feel free to @{"contact" LINK ContactAuthor} the author. @ENDNODE ##_____________________________________________________________________________## ## ## ## Version-dynamic Nodes ## ##_____________________________________________________________________________## @NODE KnownBugs "Known bugs in RunLame" @PREV ProblemsSolutions @{U}Known bugs@{UU} ·If @{"Enforcer" LINK Enforcer_Explanation} is running while RunLame is trying to move the @{"VBR" LINK VBR_Explanation} to $0.l, the machine hangs. Of course this should not happen - I guess this happens because some system configurations redirect the Enforcer output to a window, and when RunLame copies the $0-$400 page this causes a whole bunch of @{"Enforcer hits" LINK Enforcer_Explanation}. I guess this is a bit too much for the Enforcer window, but I am not sure about this. Normally there should be reported several accesses to the addresses $0-$400, because RunLame @{B}MUST@{UB} save vectors that it is going to change, in order to restore them when leaving (should cause some more Enforcer hits). I can't work around these Enforcer hits, RunLame @{B}MUST@{UB} access these vectors on low level, sorry if this is annoying you. @ENDNODE ##_____________________________________________________________________________ @NODE FuturePlans "Future plans with RunLame" @{U}Future plans@{UU} ·When pressing `Help' key show the appropriate node to the element the pointer points to (f.i. the node for the filerequester gadget if `Help' is pressed while the pointer points to this gadget.) ·Emulation of fake fast RAM at $C00000 on systems which have a @{"MMU" LINK MMU_Explanation} installed. For this purpose I rely on information about @{"MMU" LINK MMU_Explanation} programming, which is not yet available to me. If you want to help me, send me information. Especially I am in need of 68030 MMU code. ·NoFastMem, 1mb/.5mb chip mem memory reduction features. ·Gio suggested that a config file parameter would be handy. I will do this someday (will I? :-) ·I would like to distribute a really funny icon together with RunLame. So if you want to draw one, feel free to @{"send it" LINK ContactAuthor} to me. ·I still need a native english speaker to correct my lousy english in the documentations for RunLame. ·Shall RunLame's window become font adaptive in future? ·Does anybody need an ARexx port for RunLame? ·Is it useful to localize RunLame? ·Do you have any suggestions (to improve RunLame or the documentation)? @ENDNODE ##_____________________________________________________________________________ @NODE FeaturesNotToCome "Features that won't be implemented in RunLame" @{U}Features not to come@{UU} ·Someone asked for a bootblock intro removal feature. This has in no way anything to do with system degradation, so why the heck should it make it's way into a degrader? ·@{"MUI" LINK MUI_Explanation} instead of gadtools @{"GUI" LINK GUI_Explanation}. RunLame is intended to be a short program, to allow selfmade intro compilation disks without eating up too much disk space. @{"MUI" LINK MUI_Explanation} itself is a disk space killer, understand? @ENDNODE ##_____________________________________________________________________________ @NODE History "RunLame history" @{U}History@{UU} Version 1.1 ·Public release named `@{B}RunPal@{UB}'. No features except for screen degrading. @{" Version 1.25 " LINK Version_1.25} ·First public release named `@{B}RunLame@{UB}'. @{" Version 1.28 " LINK Version_1.28} ·Second public release. ·@{B}WARNING!!@{UB} This release @{B}crashes@{UB} on AGA machines. Read about @{"beta-testing" LINK BetaTesting} to understand why. @{" Version 1.32 " LINK Version_1.32} ·Third public release. @{" Version 1.34 " LINK Version_1.34} ·Fourth public release. @ENDNODE ##_____________________________________________________________________________ @NODE Version_1.25 "First public release" V1.2ß: ·Not released. ·Corrected the version string to be displayed OS3+ conform using the CLI "Version" command. V1.3ß: ·Not released. ·Disables caches, burst modes and copyback mode now. V1.4ß: ·Not released. ·Added the template switches for screen, caches, burst, copyback and VBR moving (VBR moving is not yet implemented). ·Online help available now via HELP. V1.5ß: ·Not released. ·RunPal is renamed to RunLame due to many enhancements that were added to the program, which now doesn't only open a PAL screen, but is able to run many more lame programmed software. ·VBR is only moved when nescessary, it is enclosed in Disable() Enable(), Caches will be flushed and overwritten data is saved before moving and restored after restoring VBR. V1.6ß: ·Not released. ·The screen has been minimized and can be in-/visible now. ·RunLameInfiltrator is now distributed with the package. ·FileLinker and FileUnlinker are now distributed with the package. V1.7ß: ·Not released. ·Due to improved system conformity the little PAL screen has a name now. V1.8ß: ·Not released. ·Graphical user interface added. V1.9ß: ·Not released. ·Performed some improvements of GUI. ·When having used GUI all possible CLI window output of the commandline executed is redirected to an automatically opening CON: window, which can be closed asynchronously to termination of RunLame. V1.10ß: ·Not released. ·Added file requester gadget and ASL file requester to GUI. ·When a further window (any requester for example) is opened by the GUI, the menu is disabled totally. ·It is now impossible to launch an empty commandline from within GUI. V1.11ß: ·Not released. ·When a further window (any requester for example) is opened by the GUI, the gadgets are all disabled (except for the GENERIC_KIND). ·Fixed a spelling error: `modi' -> `modes' V1.12ß: ·Not released. ·Window now has a zoom gadget and is aware of resizing (DragIt), try to resize the window with a resizing patch program, it will allways snap back to it's old size. Nobody should try to resize a window without sizing gadget, Bilbo's windows will strike back :-) ·The settings can be chosen now. You may use the default settings of RunLame, or you can force RunLame to configure to the current system settings. ·The above mentioned settings can be overridden by using options. ·The resulting configuration of RunLame is reflected by the GUI now. V1.13ß: ·Not released. ·The RunLame GUI now is an application window when the Workbench is opened, hence (even multiselected) icons can be dropped in to fill the commandline string gadget. ·RunLame may now be started from Workbench. The icon may contain various tool types. V1.14ß: ·Not released. ·If RunLame has to inform the user of an error, this will happen depending on where it has been started from: Has RunLame been started from the CLI, all error messages go to the default output of RunLame, hence it can be redirected (needed for script files, maybe). Has RunLame been started from the Workbench, all error messages appear in requesters, providing full comfort. ·Dropping icons into RunLame's window now adds the path/name of the appropriate object to the commandline string gadget (gadget is not cleared, as in previous version). ·Usage of the file requester now adds the path/name of the appropriate object to the commandline string gadget (gadget is not cleared, as in previous version). ·When launched from Workbench, all multiselected icons' (objects) path/name will appear added to the commandline string gadget. V1.15ß: ·Not released. ·Bug fixed: Previous versions did try to get the path/name of RunLame into a 30 bytes buffer. When both together was bigger, the starting from Workbench would fail (only V1.14). The buffer is now 128 bytes bigger, and the path is not retrieved any more when started from Workbench, in no case the path will be prompted. Hoooray, this was the first bug found in RunLame! V1.16ß: ·Not released. ·When any additional requester is opened by RunLame itself, in the meanwhile all input to RunLames's main window is blocked and the pointer changes to busy image. V1.17ß: ·Not released. ·Bug fixed: Previos versions failed on pathes/filenames including space characters, because Execute() couldn't find them when they are not enclosed in "'s. Now a " is pre-/appended if pathes/filanames contain space characters. ·A seperating space is only inserted in the string gadget when nescessary. ·When commandline string gadget overflows while using the application window feature or the filerequester or the startup multiselect feature, a DisplayBeep() is generated to alarm that not all selected names are reflected in the string gadget. ·Application icon feature added. This is not yet working as stand alone, but in combination with the GUI it is fully functional. V1.18ß: ·Not released. ·APPICON feature now fully functional. Double click the application icon to quit RunLame. ·LOOP option added. RunLame will pop up again after having executed a commandline, until it is definitely quitted by the user. This feature has been suggested by Milano. ·Bug fixed: Launch menu item is enabled now when a commandline is given at RunLame startup when using the GUI. ·Bug fixed: It was possible to launch an empty commandline from GUI when clearing the string gadget, not pressing Enter, but selecting the Launch menu item. V1.19ß: ·Not released. ·Bug fixed: The PAL screen tag list was not terminated with TAG_DONE. I wonder why this worked:-) ·The PAL screen now is in PAL:Low Res (non interlaced). ·PATH parameter implemented. Supply a path with PATH to set the initial drawer of the file requester. This feature again has been suggested by Milano. V1.20ß: ·Not released. ·The gb_MemType is set to BANDWIDTH_1X now on AGA machines. This has been suggested by ID of Sphinx. The tip came originally from Randell Jesup. ·Now System() is used to execute the commandline, instead of Execute(). Thus now it's possible to break all breakable runlamed programs. Furthermore the error number generated by the commandline is returned by RunLame now. V1.21ß: ·Not released. ·Bug fixed: Since V1.19ß there has been an Enforcer hit to $0 when PATH has not been specified. This didn't hurt, because at $0 normally a 0 byte is located, so the PATH was considered as empty string, and this is what we wanted it to be when we don't specify a PATH. ·The output window now will open with full width on all Workbenches (it did formerly open in maximal 720 pixels width). ·Changing and restoring gb_MemType is now safer (no task switching in meanwhile). When another task changes gb_MemType after we did, the old value is not going to be restored, so we don't kill the environment of the other task (BTW, nobody had problems, but I think it's just smarter this way). ·Some internal improvements (now setting the secondary error code, too, though it seems this is not nessesary). V1.22ß: ·Not released. ·This version is somewhat experimental, I have to wait for the results of my ß-testers, because I don't own an AGA model. gb_MemType is only changed during the opening of the little PAL screen. Both happens while only interrupts are allowed but no taskswitching, thus reducing the chance another task can open a screen with the wrong bandwidth. This would be the smartest way to do this all, but I don't know if this works. Furthermore all screens opened by programs in the execution commandline will have the former system bandwidth, but these programs should be aware of that when they are systemfriendly (I know only 2 demos which do open a screen using OpenScreen(TagList)()). V1.23ß: ·Not released. ·Bug fixed: NOVBRTOFAST switch didn't work. ·Bug fixed: VBRTOFAST did hang the system when the VBR was originally located at $0.l (WHY do I always have to find these nasty bugs myself, I thought I had beta testers :-). This bug has been in RunLame for a rather long time, but I don't know exactly since which version. ·Heavy internal changes to the processor degrading/restoring code. It is now much more safer and no inconsistencies in multitasking with other tasks changing the same registers should occur (though nobody reported any problems). ·When LOOP and GUI is used, the GUI pops up first time centered under the mouse pointer, but the next times it pops up always where it was located before disappearing. This feature has been requested by Milano. V1.24ß: ·Not released. ·The file requester now remembers the last entered directory when OKAY has been selected (not if CANCEL has been pressed). Again a suggestion by Milano. ·When using menu item `Enter commandline' while window is zoomed, the window will be brought to full size. ·Bug fixed: When the height of font used for RunLame's GUI window drag bar differed from 8, the zoom gadget did still zoom the window to a height of 8 pixels, which resulted in an awful looking window drag bar. The zoomed height of the window now depends on the height of the font used for the window's drag bar. (Does none of my ß-testers use a font with another height than 8 ? Or do they never zoom the window ?) V1.25: ·Released to the public for the first time. ·It's now possible to turn off the commandline appending feature with NOAPPEND. I really can't see why anybody could need this, but I added this for Milano. I might reference this mode by `dumbnosemode' :-). @ENDNODE ##_____________________________________________________________________________ @NODE Version_1.28 "Second public release" V1.26ß: ·Not released. ·The PAL screen name is now identical for all forthcoming versions, so it is not needed to update any databases where the screen name has been registered (NewMode, Domino promotion system, ...). ·The windows drag bar height in zoomed state is now calculated as proposed in the include files of C=. V1.27ß: ·Not released. ·When screen degradation is activated (SCREEN option), the sprite resolution for that PAL screen is explicitely reset to low resolution. This might not be needed, because the sprite resolution for a that PAL screen should be lores anyway. In case of false promotion of that PAL screen, at least the sprites will be set to lores now. V1.28: ·Second public release. ·When screen degradation is activated (SCREEN option), the sprite DMA of the mouse pointer will point to a NULL graphic, thus reducing the chance of sprite flicker if the lame program does just disable the sprite DMA in the wrong moment. This does only work if the user doesn't activate any window in the launch phase, because all windows keep their pointer for greater convenience. ·The CLI option NOVBRTOFAST has been renamed to VBRTO0. The Workbench tooltype VBRTOFAST has been renamed to VBR. ·Checking if the PAL screen opened really in PAL lores. Results in an error message if a promotor did change the screen mode. ·Bug fixed: mutual excluding Workbench tooltypes didn't produce an error message. @ENDNODE ##_____________________________________________________________________________ @NODE Version_1.32 "Third public release" V1.29ß: ·Not released. ·Bug fixed: The cleared mouse pointer was defined to be 0 pixels wide. Now the width of it is set to 16 pixels. V1.30ß: ·Not released. ·Bug fixed: When restoring the sprite resolution, a wrong address register has been referenced. This might have caused the system crashes on AGA models. V1.31ß: ·Not released. ·Changed the `VBR to fast' gadget to a cycle gadget, which is more intuitive. Furthermore changed the appropriate menu item into two mutex submenu items. V1.32: ·Third public release. ·Bug fixed: `VBR location' submenus were incorrectly reflecting the startup configuration of RunLame (VBRTOFAST, VBRTO0). ·Bug fixed: RunLame did crash on Kickstarts lower V2.04. CLI and Workbench start of RunLame under pre 2.04 Kickstarts is now possible without crash and memory loss. RunLame will then exit with an error beep but no error message. ·Some minor internal improvements. ·All new AmigaGuide documentation replaces plain ASCII docs. @ENDNODE ##_____________________________________________________________________________ @NODE Version_1.34 "Fourth public release" V1.33ß: ·Not released. ·Some minor internal improvements. V1.34: ·Fourth public release. ·Pressing the `Esc' key now quits RunLame. ·It's possible to activate the string gadget by pressing the `Return', `Enter' or `Tab' key. ·The documentation guide will show if HELP key is pressed in the RunLame GUI. @ENDNODE ##_____________________________________________________________________________ @NODE ThanksAndGreets "Thanks and greetings" @PREV History @{U}Thanks, greetings@{UU} ·Thanks, @{FG Highlight}Jesus Christ@{FG Text} for being the god who cares about us all. ·Thanks and love to my girlfriend for being such a patient person, may the lord bless thee and protect thee. ·Greets to Zaphod Beeblebrox of Hypenosis (letz do the hype :-). ·HOARS to ALFred, a legend is back home @ IRC, letz have a nice time! ·U4ia, may the Lord show you, that he'll never forget about you. This is no hype, you got the vibe, man. Good luck for MDMA! ·Thanx to Delirium for their help. Without you it would have taken me much more longer to implement my first GUI. Keep up good work on DeliTracker! ·Thanx to Mjoelnir and his friend to supplying me with 040 MMU code. ·Thanx and greets to the brave beta testers (did I forget someone?): Zap, ALFred, Savage, Dense, Sphinx, Milano, Slammer, Kryss, Andemar, Mnemo, Skull, Ikke, Trooper1, VAG, Mjoelnir, Gio, SteveVai, Starfox, Gimli, KicStart, Tirreg, Xed, Exolon, Martin, Dizolve. (list in no specific order) ·Greets to all the nice pals on IRC (Netrunner, XS, Zop, Gucky, Outland, Gateway, Janne, Juggi, Advance, Goldrnr, Shocker, Mag, and all I know but forgot now (list in no specific order) ·Thanx to Jean-Guy Speton and all contributors for the AmigaDemoList, which contains valuable compatibility information about various demos. ·Last but not least, I send encouragement to all those who made these despicable lame programs, thus forcing me to spend lots of time writing RunLame. Try to do a better job about compatibility, next time. Using RunLame to make work your own written programs should be a shame for you! One time diskmags will contain compatibility ranking lists, I hope. @ENDNODE ##_____________________________________________________________________________ @NODE ContactAuthor "How to contact the author of RunLame" @NEXT MAIN For bugreports, ideas, suggestions, improvements, questions and all other concerning RunLame meet me on IRC on channel @{B}#amiga@{UB} or @{B}#amigager@{UB}. @ENDNODE ##_____________________________________________________________________________ ## End of the documentation for RunLame