delaneyg@wnre.aecl.ca ("H. Grant Delaney") (04/27/91)
On a less than frequent visit to CIS i found some more info on multi switch which I thought might be of interest to you all ------------------------------------------------------ Hi, You will find here more info about MultiSwitch. If you need more, "link me". Best Regards, Louis van Proosdij BrainStorm Software ************************************* MultiSwitch bugged ? MultiSwitch cannot be consider as a bugged product. Actually it took almost three year for its development and numerous beta-testers have been working in the mean time. Concerning the applications if some of them make the re-execution impossible it doesn't mean that they are not compatible. Vincent Hemeury (the author) developed patches and what he call "re-execution resources" which are specific (or not) programs for an application to make it compatible with MultiSwitch. Lastly one has the option to launch the application like with a classic launcher. %%%JCompatibility of the applications with MultiSwitch, MultiTasks, The Manager and P8 Emulator. MultiSwitch 2.0 MultiSwitch is a Switcher (in my sense a very fast one). MultiTasks is a system software handling several applications at the mean time. The Manager is a MultiFinder) for the Apple II-GS. P8 Emulator allows Prodos 8 programs to be run under GS-OS. Any application developed under the standard Apple development rules' is compatible with MultiSwitch. The sole exception is the use of the User Pathname which cannot be handled by MultiSwitch nor by The Manager. In that case the prefix 8 has to be used. Apple computer was informed but refuses to offer a call which would allow the prefix to be modified ; this is against the development rules for it might be possible to modify a user prefix. This is stupid because a way to fix this problem does exist but it will idle the opening of the files. With this sole exception which - if it appears to be a problem for lot of II-GS users - will no more exist, MultiSwitch supports 100% of GS/OS's calls and is fully compatible with systems 5.0, 5.02, 5.03, and 5.04. It would have been also compatible with system 4.0 or even ProDOS 16 if I wouldn't have used some new features of system 5.0. But we hardly recommend to use GS/OS 5.04 for all the advantages (less bugs) it offers. In practice an application doing anything but the re-execution will run because MultiSwitch is very tolerant and even fixes some system's bugs. The applications will keep the data permanently in memory using the option "Send the True ID" from the configuration dialog of an application. In that case at the beginning of the execution of your application the heap will hold the true ID of your program and not the purgeable one returned by MMStartUp. Using this data to load your vital informations they will stay in memory until the program is purged by the user (or if you decide to erase one or more handles). The advantage of this system is that it is compatible by default with the Apple environment. Under the Finder you get the application's ID in the same way that under MultiSwitch thru register A. But the Finder erases your program when you quit. PICT2 Converter - which source code is joined - uses this technique. MultiTasks GS uses its true ID to load once all the system sounds. APW Shells, Merlin, ProSel can be executed directly thru MultiSwitch which allows to send a command line and adds the header of each development environment. The only assumption which has not to be done concerns the prefixes, they are not what they would be inside each development program but the default prefixes of the shells themselves. MultiTasks GS. It's a multi-applications, mutli-tasks integrator with multi-processor abilities. To date it is designed for only one user but a multi-user version is foreseen. As I don't have a network at home it was difficult for me to conceive something which I was not able to test. Although the II-GS has a sound coprocessor it is not a multi-processor machine and the 65816 has no Time Slicing like the 68030 or 80386. Such a device could be implemented by changing for each program the execution time versus the time initially allowed : inverting Program/Background Task on the VBL signal with Programs/Programs' Handler on the VBL signal. However the benefits of such a system are minimised because there is only one video output, one keyboard and one sound output. In practice several programs simultaneously running by time slicing are not faster that the same amount of applications of which only one is on the foreground and whose routines are working in background. MultiTasks handles the background work in a new way. It encloses the program in a kind of capsuleincluding a header which describes the different access way to the machine's resources (I/O access, memory,I) and the programming type used (auto-patchI). It looks a little bit odd but the aim is to allow the export of other back-ground tasks to other processors located on boards, network or even on the mother board if Apple - or somebody else - would decide to modify the II-GS. This particular background tasks handling comes before the supply of sorting routines, strings handling, calculation,I designed for the 65816 but also for existing 65802 or 6809 extension cards. The program calls MultiTasks to carry out an operation but it will not know who will handling it : to be usable no special re-programming of the multiprocessing must be required ; it must be user transparent and supposes the supply of numerous programming tools to the developers. Third aspect of the system, related with the above mentioned point : creation of virtual machines inside the II-GS. A developer obviously wishes to use available specific processors on extension boards at their maximum power, in that case he prevents the execution of the program on another II-GS which does not includes the same cards. So the back-ground tasks header indicates if the native code of a processor will be used and, if so, MultiTasks use execution or interpretation resources. Each processor will include a list of resources (Execution/InterpretationI) which will move the back-ground tasks to : - the processors - the machines - the direct execution of the code on the II-GS This is not really a novelty, Woz the Wiz already did the same in 1977. But the new idea is that entry points for interruptions and system calls will be available. This will allow the execution of true programs and even their tests, exactly as if one would be on the target machine. Sure the execution speed will be slightly reduced but one cannot get all at the mean time, can't he ? As a consequence of what is described above, MultiTasks perfectly supports GS/OS. It is possible to carry out some operations under interruptions and it is highly recommended - even it is not an obligation - to use MultiTasks' internal resources to handle the files for the waiting list cannot be handled by the applications. Concerning the development it is possible to develop an application which will work with both Finder and MultiTasks. It is more or less like merging two applications into one, it's not very productive and a little obsolete because MultiTasks make easier the programmation of an application using menus, windows, dialogs by handled all or most part by MultiTask systemUs. Only the use of pipe-lines and the multitasking are a little difficult. MultiTasks is compact - approximately 22Kb and 20Kb for the MultiSwitch's toolbox - and fast. Only 240 machine cycles are necessary for an application to execute the code for the new value taken by a control after its selection by the user. It's almost as fast as if you were handling yourself your application but MultiTasks returns a record with the new value of the control and its ID according to the dialog number, which is very simple. Nevertheless something has to be said concerning the multi-processors toolbox. Vincent might probably lack some time during the two coming monthes because of his military duty. France still favorizes the conscription... The Manager. This MultiFinder) for the Apple II-GS now works in a very stable way with numerous applications which comply with Apple's programming rules. Nevertheless one has to keep watchful with the prefixes and as a matter of safety it is recommended to use the full pathnames instead of the partial pathnames. The most sensitive problem for an application which complies with these restrictions is the amount of free memory available for the application in bank $00. Although MultiSwitch includes a virtual memory handler it is uneffective in bank $00. Consequently an application should allocate its working memory space in two stages. The first segment for page zero of the software and, if The Manager is absent, a segment for the stack and to initialise the tools. MultiSwitchs' toolbox includes calls to determine the activity stage of The Manager (and also of MultiSwitch). The application is able to react consequently. If there is a demand I might include another tools in the Xter.Box toolbox, to allocate a specific desktop for each application under The Manager. It might be necessary for programs working in the full-screen mode. Please let me know. P8 Emulator. This emulator allows the execution of ProDOS 8 programs while keeping all the advantages of GS/OS. A problem might appear if the programs are allocating to PrODOS 8 a memory space used by GS/OS. An application runs perfectly if it does not use the following memory space : * $0800-$9900 without SCSI driver * $A00-$9900 with Apple's SCSI driver. I mean that the application can freely transfer its data in side this memory space. On the other hand the application's code and the parameters tables can be resident anywhere inside $0800-$BEFF, the auxiliary RAM, inside the memory banks $00 and $01. In that case you have to indicate to P8 Emulator what are the portions necessary to make the program working fine. ThatUs why there is some dialog boxes appearing on screen before launching a P8 program with the P8 Emulator. Do not expect the first opened file to have 1 as RefNum. It will probably not be the case with this Emulator. APPLICATIONS COMMANDED BY RESOURCES. Introduction. MultiSwitch release 23 was introducing re-execution routines. A kind of patch grafted on the program owing to the Resource Manager. Release 26 adds a new Resource Code which allows MultiSwitch to warn the programs which are going to be purged. This program can avoid its memory erasing or warn the user that data are going to be lostI If the modular concept is very interesting and very powerful with a network or multi-processor environment ther is a problem to access the internal data of the application. This problem can be solved a priori only by the use of Message Center or a specific library. It's Ok but a little bit egoist because reserved for only one application. A better solution was used by the author (be honest). It consist of defining a header in the first program segment of the application which is a kind of communication center for MultiSwitchs, MultiTasks and The Manager. C Cube (Communication, Command,Control) is an optional entry point for re-execution resources, purges resources and any kind of other resources that might appear in the future. It's a kind of logical slot because one doesn't know what will be put inside it and there is no obligation to put something inside it, but if it exists it is the same program at the beginning. Organisation. C Cube MultiSwitch is made of a header which indicates its existence with a signature, a version number and an entry point to the C Cube Dispatcher. Header. It is located 10 bytes after the beginning of the program and begins with a signature. Why in offset #10 ? It is arbitrary but it keeps some room available for the programmer. Offset 10 ($0A): Word, Signature, ASCII code : "C3" Offset 12 ($0C): Word, Version number ($0100) Offset 14 ($0E): Word, Amount of supported commands (minimum 6) Offset 16 ($10): Long Word, Reserved, $00000000 Offset 20 ($14): Long Word, Reserved, $00000000 Offset 24 ($18): C Cube Dispatcher C Cube Dispatcher. It must begin in following way : C Cube Dispatcher Anop Cmp #Max_Command// full native mode Bcs Unknown_Command Phb Phd Asl A Tax Jsr (Command_Offset, x) pld plb Unknown_CommandAnop Rtl Command_Offset Anop do i'Ignore_Command'Reserved do i'ReExecution' do i'Purge_prog' do i'Ignore_Command'Reserved do i'Ignore_Command'Reserved do i'Ignore_Command'Reserved(System) Ignore_Command Rts ReExecutionAnop phk plb ... // code continuing rts Purge_prog Anop ... ... Rts Extensibility. WARNING, THIS IS JUST AN EXAMPLE, some commands may be added before MultiSwitch will be distributed. Resource/C Cube Dispatcher Interaction. It may appear redundant but this system includes the following advantages : - power of C Cube Dispatcher which access all the informations of the program - simplicity - opening of the Resources (adding of new commands, facility for updatingI) There is no obligation to use C Cube Dispatcher. The re-execution resource (or eventually MultiSwitch) will decide for this additional call to the manager (if it exists of course). To invoke it, A register must show #'C3' after the call to the resource. MultiSwich preserves the value of the carry. For instance the internal code handling the purging of the program knows whether the resource wants to purge the application or not. State of the system while calling the Dispatcher. Normally your application is not active except when ther is a call under The Manager. In that case I should advise to use the call _TheManagerStatus from the MultiSwitch's toolbox. Most of the time MultiSwitch's tools will be active. It means all the tools except those handling sound (including MIDI), TextEdit and eventually FontManager. For the latter one its state has to be tested. At this stage of MultiSwitch the applications have no numerical identifier or application type identifier like with MultiTasks GS (which is - concerning this very point - much more sophisticated than what can be encountered on IBM compatible or on Macintosh). In fact this will cause some troubles only when it will be necessary to convey informations tru high, medium or low flow channels (Central CPU, On board CPU, Network CPU) between applications. Conclusion. The Apple II is not technologically obsolete at all. It still has a lot of resources (this is not a bad joke !) it's just a matter of programming, if there is no hardware evolution, at least coming from Cupertino... Author: BRAINSTORM Author: BRAINSTORM