.LM 8;RM 72;CE 3 FUNNELWEB Vn 4.40 BUGS & PROBLEMS --------------------------------- .FI (1) Bugs and Mods ~~~ ~~~~~~~~~~~~~ The bug report is being zeroed out at the time of first issue of Vn 4.40 of FUNNELWEB, but new bugs are being created all the while. That's the price of progress! Fixes and changes since that release are listed in chronological order below. Minor changes in associated document files may well be made without explicit mention, or other non-functional changes. .LM +3;RM -3 Bug ..... After use of Myart file View from DR80, the XB RUN from DR80 engages XB but then locks. is still there though. The cause is not yet obvious. System bug ..... Anomalous error recovery behavior may occur with SD and the DRs in systems with 80-track Myarc FDCs. See FWDOC/DR41 or /DR81 for details. May/30/91 ... First issue of Vn 4.40. Jul/26/91 ... Fixes for LOAD's XB user list program loading, and for ED80

Dir function from SD. FILENT routine in FW/LOAD now clears the last char in the window with . ML40 repaired. Oct/30/91 ... Back to programming with renewed vision !! Read/Write failure indicators added for DR file copies. DSKU notes handling revised and corrected. FWDOC files /DR40,1, /DR80,2, /PSRV updated. Dual 80/40 Editor, files ED80 & ED81, now windows correctly in 40 col mode. Cause of error recovery bug in DR narrowed to Myarc 80-Tk FDCs. .LM -3;RM +3 If you come across a later version of FUNNELWEB, use it, but it is a good idea to update ALL files. Significant changes are indicated in the update notices. Use CF/CG and your SYSCON file to re-customize the LOAD and FW files if these have been updated. (2) Programmers' reference ~~~ ~~~~~~~~~~~~~~~~~~~~~~ The FUNNELWEB program has to interact with a number of external programs which (to TI's eternal shame) were never intended to work together, so its internal structure is an ad hoc response to many independent pressures. As the scope of FUNNELWEB grew it became necessary to define an interface so that other parts of the program could call on routines or data in the main body of the program. This has grown somewhat haphazardly, but at this stage in the history of the 99/4a (and level of fairware support) it is unlikely to be reorganized. Details which may be relied on by external programmers are given in the supplemaentary file FWDOC/PSRV. A set of articles "Living with Spiders" appeared in the HV99 Newsletter and on some BBSs, which goes into coding details, and is still relevant. The FUNNELWEB LOAD program is composed of 4 parts, the Extended Basic code, the XB user list data, and 2 pieces of machine code tucked between the XB code and the top of memory. DSRLNK (TI-Forth form - you handle the errors) and GPLLNK are in a >FA byte block immediately above the XB program code. These are shifted to follow the normal XB Utilities and the memory pointer updated, and are available for use by XB programs loaded from the XB User List (BLWP at >24F4 and >24F8 respectively) provided CALL INIT or CALL ILR are not invoked. This is followed by code and data used only while XB is still preserved. This same area is used later by UL, ML, FSAVE, and the ScriptLoad error handler. When FW/UTIL1 is prepared the C2 character set and FW/UTIL1's entry code are tucked between the entry point (>E006) and the actual FUNNELWEB code to speed up loading. The end of the program is kept fixed at >FFD7 so the interface block items are at known addresses. The >FFD7 limit is compatible with E/A and XOP 1 which is not used by FUNNELWEB (but it does make transient use of the area above >FFD8, without altering the Load Interrupt vector at >FFFC). (3) GPLLNKs with FUNNELWEB ~~~ ~~~~~~~~~~~~~~~~~~~~~~ From Vn 4.40 onwards GROM address setting from within the program and DiskReview calls a reference block routine which uses GPL workspace R13 as base value (see FWDOC/PSRV). Whenever the central menu screen is displayed the following conditions have been established. .LM +3;RM -3 (a) The GROM address is left pointing to an XML instruction in cartridge GROM, else in console GROM 0, and this address is also saved in the program. (b) The GPL stack is dropped to just one entry which is this value copied to >8380. (c) The table address pointed to by the XML instruction is loaded with the FUNNELWEB re-entry address. For maximal compatibility with existing software the XB return is at >2000 and the E/A return is at >2002. All others use PAD (>8300). .LM -3;RM +3 With these preparations it was possible to write a GPLLNK to fit invisibly in the E/A utilities without altering the FFALM pointer. In any event the E/A GPLLNK cannot be used because it branches to E/A module GROM code. Programs run other than from E/A or XB under FUNNELWEB may give trouble if not written to preserve the contents of location >8300. (4) Returns ~~~ ~~~~~~~ The easiest returns to FUNNELWEB are when FUNNELWEB is still all there unmolested, from >EBC8 to >FFD7. FUNNELWEB always hands over with R11 loaded with the return address. Any of the standard returns to GPL will return to FUNNELWEB provided that the XML table entry is preserved for B at >70 returns. If FUNNELWEB is overwritten the simplest return is to the Title Screen. If your program doesn't make extensive use of VDP memory, it may be possible to stash FUNNELWEB (from >E9B0 to cover UL or else from >EBC8 to >FFD7) there below the disk DSR buffers and to restore it to CPU RAM after an irrevocable decision to exit has been made, and then a normal exit as if to GPL may be used. If memory usage is too complete to allow this, FUNNELWEB may be reloaded from disk as the program file FW or UTIL1. Only a very simple loader is needed as there is only a single file and the memory location and start address, (>E006) and the length (through >FFD7) are prior knowledge. Strictly, only Atrax Robustus can get away with not deriving the start address and length from the file header, but given the present level of fairware support and future of the 99/4a system, it is unlikely there will ever be enough new developments to change this. It is recommended that the loader first try to load the file under name FW and if this is not found then to try it as UTIL1 before taking error action. If the application program is such that disks may have been swapped around, prompts should be issued for the primary and secondary disk numbers or the original drive or pathname assumed, as appropriate. The flag to turn on boot disk tracking in FW is at BTFLAG EQU >FF1A. A null word here disables the tracking, in which case primary and secondary system drive numbers in ASCII form must be provided in the bytes at RDISK EQU >FF18 and >FF19. Rewrite the drive numbers after loading but before handing over if these have been changed. It is always necessary to suppress boot disk tracking when split T-W and E/A access is needed. The flag for a hard pathname is at HDFLAG EQU >FF02 and the pathname is at the address pointed to by the value at >FF58. The length byte includes the standard 2-character system filename length as well. This flag should be checked first and used by program reloaders before checking the other paths. The DM-1000 supplied in earlier issues followed this prescription. Programs intended to work only with FUNNELWEB may re-enter it at the Central Menu Screen by LWPI of the FWB main workspace at FWREGS EQU >FF7C, SETO of R13, and CLR or SETO of R4, followed by a branch to the address contained in location CMSRET EQU >FF5C. Do not alter R8 and R9 of this workspace. A program (Opt 1-3) can tell that it was loaded from FUNNELWEB by comparing R11 at entry with the word at LDR11 EQU >FF9C. (5) Filename transfers ~~~ ~~~~~~~~~~~~~~~~~~ FUNNELWEB has a standard way of transferring the DV/80 workfile name from one utility to another. The file name is stored on final exit from a component program at MLBOX EQU >A000 without any length byte, and padded with spaces out to >A050. This is the "mailbox". A file name so stored will survive OLD or RUN of an XB program or passage through the Title Screen. The utility entry routines inspect this location for the 2 ASCII characters "DS" or "RD" or "WD" or "HD" and if found the block as far as the first space is written to the appropriate buffer in the utility program, and the rest of the block is filled with blanks. If utility programs are not to destroy the resident file-name then they should not overwrite this area, or else should restore it before exit, or load the file name to be passed back. Test with Formatter and Editor to see if this has been done properly. Modification of existing programs not available as source code may require a little ingenuity, and is not always possible. (6) Standard Utility Loading ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In contrast to versions of FUNNELWEB earlier than 4.30, the loads of the Editor, Assembler, and Formatter files are now just normal program loads, Option 1 for the Editors and Option 2 for Formatter and Assembler. This means that other files may be substituted for these if desired, as long as the same leading name is used, eg FO for Formatter. Test and/or correct for proper returns (see (4)) using one of the configurable menu slots first. (7) Problems ~~~ ~~~~~~~~ Various problems have been observed by users of FUNNELWEB. Many of these are intrinsic to the programs being loaded, and these we can't do anything about. If you have commercial programs which you would like to use with FUNNELWEB but can't for one reason or another, particularly because of protection schemes, you should contact the sellers or originators of these programs to make your problem known. Good luck Charlie Brown! Other problems are associated directly with use of FUNNELWEB. .LM +3;RM -3 (a) Loading difficulties Lockup during file loads occurs because some part of FUNNELWEB has been overwritten. The code for program file loads is located close to the top of high memory and will be destroyed if overwritten by a file that is not the last one to be loaded in normal E/A sequence with the last byte incremented for each successor file. Altering the file sequence to put the overwriting file last in a multiple load will usually solve the problem. Use DiskReview to correct the load flag in the first word of the files being interchanged (>0000 for the last file, >FFFF for all others) and DiskReview or other DM program to interchange file names. File lengths of >2000 in 33 sector files, such as produced incorrectly by E/A SAVE, may need to be corrected to >1FFA if the changed order would result in overwriting of previously loaded code. Load/Run of object files is handled by the Loader in the E/A utilities. Autostarting of files is by a direct branch from the Loader to the program code, so that a autostarting object file may overwrite FUNNELWEB. Files that are too long may refuse to load. Unsuitable absolute file addresses may destroy the code for DEF table entry. (b) Running difficulties The program file loader gives a fair approximation to GPL or E/A module environment. If problems are observed they are usually associated with key unit choice and key response in the program loaded, particularly with programs that set a key-unit of 0 instead of choosing the one they really want. The cartridge loaders now reset the GPL stack pointer at >8373 to >7E which seems to help. Programs that sense which module they are running with and adjust their action accordingly can cause problems. Since the point of FUNNELWEB is to make all sorts of programs work with modules they weren't intended for or even no module at all, it has already taken the necessary actions and must not be second-guessed by programs it has loaded. The only solution is to modify the programs or else not use FUNNELWEB. Running from the E/A module gives the easiest way to switch back and forth between FUNNELWEB and a standard environment. Some programs in E/A program format contain code to unload the standard utilities from the E/A GROM because the E/A module does not do this for Run Program File. The c99 memory image files prepared with the original unmodified C99PFI use this method to force the utility load. Running or return from such programs may not be graceful if FUNNELWEB was loaded from E/A. c99 is smart enough not to try getting code from non-E/A GROMs, but other programs may need revision. FUNNELWEB has also adjusted the E/A XML object file loader path for its own purposes. If an assembly program needs to load an object file it should use a direct BLWP at LOADER to the E/A routine. Error returns may need special attention. (c) Exit difficulties Read (4) above on returns. Opt. 2 loads will be necessary for program files that overwrite the E/A utility area in low-mem but still use a GPL return via the contents of R11 as would be acceptable for a Opt. 2 (or E/A 5) program file load. Some programs which do not appear from their load size to overwrite FUNNELWEB may in fact corrupt it while running. Some particular cases of pre-existing programs may be helped with minor changes, as a return to the title screen is usually preferable to a lockup. An example of this kind is the Dragonslayer Spellchecker. An early version inspected of this commercial program runs normally under FUNNELWEB with load parameter 2, but crashes the machine on exit. This is improved by changing the words 0460 0070 to 0420 0000 to return to the title screen. Use HEX string search in DiskReview to find this exit. Another example needing modifications to exit code is DSKU which leaves interrupts on, the interrupt hook loaded and pointing to an address overwritten by the incoming FW. .LM -3;RM +3 €†€­‹•ŸĠĠĠĠĠĠĠĠĠĠĠĠ€†