GL 3 BENEATH.ACOSZo"Beneath ACOS" V1.0 04/16/86 The Semi-definative guide to using some of the various ACOS routines inside your own ML (USE) programs. This file will breifly explain what is known about the ACOS machine-language calls you can make inside your own USE modules. This guide is by no means complete, and may not be entirely accurate, since this information was obtained by attempting to decipher Greg's USE modules and ACOS code. Notes on USE files: Before you attempt to use any of the routines listed below, you should know the general format of a USE file. ALL use files MUST reside and run at location $800, and cannot exceed 4k, since USE files are loaded into the 4k editor buffer. A typical USE file will read all of it's parameters from the program, act on them, and end with a RTS. This is not absolutely essential, but is a good idea. It is also not a good idea to mess around with too many zero-page locations, since I noted that ACOS makes extensive use of the Zero page. Be careful before you start messing around. Note that when ACOS jumps to a user USE routine, the current program pointer immediately follows the USE program filename. Thus, if your USE command has any parameters, the very first thing you should do is call the SKPCOM ACOS routine to jump over the first comma that would separate your parameters. When you get multiple parameters off the command line, don't forget to call SKPCOM before/after getting each parameter. ACOS ML calls: GETCHAR $23F7 Get a character from the code. This routine will return the next character found in the code in the A register. It also does several other things, such as update the "Quote mode" flag at $6C. If the quote status is "open" (1st quote found), $6C=#$22, otherwise it is $00. This routine also does other checks, such as checking for the presence of the high bit being set. STRIP $2498 Strip high bit off byte. This routine will remove the high bit off a character in the A register. It also performs some other checks for non-ASCII characters, and subtracts $20 from them. The full functioning of this routine is not fully know at this time. SKPCOM $241E Check for, and skip over, a comma in the code. This routine will call the GETCHAR routine ($23F7), check to make sure it is a comma, and return to the caller if so. If it does not check out, it will report a syntax error. ERROR $20C3 Report error and terminate. This is the routine ACOS calls when a compile or program error is encountered. The error message will be reported on the system console, and the "RESTART S,M,Q" message will be printed. The "error code" is passed in X. I'm not sure what all the error codes are, but I am pretty certian that error code #5 is a "Syntax error". GETNUM $2A78 Get a numeric expression This routine will evaluate a numeric expression and return the result in A (high), and X (low). GETSTR $2BC4 Get a string from the program code. This routine will get a string from the code, and place the pointers to it at $0D. The length of the string is stored at $0F. Note that this routine will NOT perform string concat- enation! GETNAME $3B61 Get and check for a valid ACOS filename. This routine calls GETSTR, then checks and converts the ACOS filename in the program. The valid Prodos pathname is placed at location $3C53 to the best of my knowledge. The PRODOS MLI parameters are placed starting at $3DD4. If this routine is entered at $3B64, it uses the string pointers at ($0D) as the filename. The filename length is stored at location $0F. PRSCRN $264C Print text string to local console screen. Immediately after you call this routine, you must define an ASCII (high bit off) text string that is to be displayed, terminated with a 0 byte. This text will be displayed on the local console screen, and will return to the code immediately following the 0 byte. PRCHAR $5E18 Print a single byte to the screen and current output device. This routine will send the byte in the accumulator to the local console and the current selected output device, usually the modem. I'm not sure if it will handle printers or disk files as well. There may be a string-print call similar to PRSCRN above, but I have not found it yet. This is by no means complete. If you happen to run into any other routines, or be lucky enough to get through to Mr. Schafer's line (303-745-3949) and get verification/additions/corrections to this, please let us know at Big Brother (715-345-6305). This file refers to what I beleive is the first release of the ACOS compiler for the Apple series, "Release One". The information contained herein may not apply to future versions. This list was researched and compiled by "Sargeant Schultz" (AKA Mark Schultz). GL% +FBINARY.II.DOCSZ Binary II --------- Apple II Binary File Format developed by Gary B. Little Version History --------------- November 24, 1986 : Initial release. Background ---------- Transferring Apple II files in binary form to commercial information services like CompuServe, Delphi, GEnie, and The Source is, to put it mildly, a frustrating exercise. (For convenience, I'll refer to such services, and any other non-Apple II systems, as "hosts.") Although most hosts are able to receive a file's *data* in binary form (using the Xmodem protocol, for example), they don't receive the file's all- important attribute bytes. All the common Apple II operating systems, notably ProDOS, store the attributes inside the disk directory, not inside the file itself. The ProDOS attributes are the access code, file type code, auxiliary type code, storage type code, date of creation and last modification, time of creation and last modification, the file size, and the name of the file itself. (All these terms are defined in Apple's "ProDOS Technical Reference Manual" or in the book "Apple ProDOS: Advanced Features for Programmers" by Gary Little.) It is usually not possible to use a ProDOS file's data without knowing what the file's attributes are (particularly the file type code, auxiliary type code, and size). This means ProDOS files uploaded in binary form to a host are useless to those who download them. The same is true for DOS 3.3 and Pascal files. Most Apple II communications programs use special protocols for transferring file attributes during a binary file transfer, but none of these protocols have been implemented by hosts. These programs are only useful for exchanging files with another Apple II running the same program. At present, the only acceptable way to transfer an Apple II file to a host is to convert it into lines of text and send it as a textfile. Such a textfile would contain a listing of an Applesoft program, or a series of Apple II system monitor "enter" commands (e.g., 0300:A4 32 etc.). Someone downloading such a file can convert it to binary form using the Applesoft EXEC command. The main disadvantage of this technique is that the text version of the file is over three times the size of the original binary file, making it expensive (in terms of time and $$$) to upload and download. It is also awkward, and sometimes impossible, to perform the binary- to-text or text-to-binary conversion. The solution to the problem is to upload an encoded binary file which contains not just the file's data, but the file's attributes as well. Someone downloading such a file, say using Xmodem, can then use a conversion program to strip the attributes from the file and create a file with the required attributes. To make this technique truly useful, however, the Apple II community must agree on a format for this encoded binary file. A variety of incompatible formats, all achieving the same general result, cannot be allowed to appear. It is proposed that the Binary II format described in this document be adopted. What follows is a description of the Binary II format in sufficient detail to allow software developers to implement it in Apple II communications programs. The Binary II File Format ------------------------- The Binary II form of a standard file consists of a 128-byte file information header followed by the file's data. The data portion of the file is padded with nulls ($00 bytes), if necessary, to ensure the data length is an even multiple of 128. As a result, the Binary II form of a file is never more than 255 bytes longer than the original file. The file information header contains four ID bytes, the attributes of the file (in ProDOS 8 form), and some control information. Here is the structure of the header: Offset Length Contents ------ ------ --------------------------------------- +0 1 ID byte: always $0A +1 1 ID byte: always $47 +2 1 ID byte: always $4C +3 1 access code +4 1 file type code +5 2 auxiliary type code +7 1 storage type code +8 2 size of file in 512-byte blocks +10 2 date of modification +12 2 time of modification +14 2 date of creation +16 2 time of creation +18 1 ID byte: always $02 +19 1 [reserved] +20 3 end-of-file (EOF) position +23 1 length of filename/partial pathname +24 64 ASCII filename or partial pathname +88 23 [reserved, must be zero] +111 1 ProDOS 16 access code (high) +112 1 ProDOS 16 file type code (high) +113 1 ProDOS 16 storage type code (high) +114 2 ProDOS 16 size of file in blocks (high) +116 1 ProDOS 16 end-of-file position (high) +117 4 disk space needed +121 1 operating system type +122 2 native file type code +124 1 phantom file flag +125 1 data flags +126 1 Binary II version number +127 1 number of files to follow Multi-byte numeric quantities are stored with their low-order bytes first, the same order expected by ProDOS. All reserved bytes must be set to zero; they may be used in future versions of the protocol. To determine the values of the attributes to be put into a file information header for a ProDOS file, you can use the ProDOS GET_FILE_INFO and GET_EOF MLI commands. Note: Some file attributes returned by ProDOS 16 commands are one or two bytes longer than the attributes returned by the corresponding ProDOS 8 commands. At present, these extra bytes are always zero, and probably will remain zero forever. In any event, place the extra bytes returned by ProDOS 16 in the header at +114 to +119. ProDOS 8 communications programs should zero these header locations. The "disk space needed" bytes contain the number of 512-byte disk blocks the files inside the Binary II file will occupy after they've been removed from the Binary II file. (The format of a Binary II file containing multiple files is described below.) If the number is zero, the person uploading the file did not bother to calculate the space needed. The "disk space needed" must be placed in the file information header for the first file inside the Binary II file; it can be set to zero in subsequent headers. A downloading program can inspect "disk space needed" and abort the transfer immediately if there isn't enough disk free space. The value of the "operating system type" byte indicates the native operating system of the file: $00 = ProDOS 8, ProDOS 16, or SOS $01 = DOS 3.3 $02 = Pascal $03 = CP/M $04 = MS-DOS Note that even if a file is not a ProDOS file, the attributes in the file information header, including the name, must be inserted in ProDOS form. Instructions on how to do this for DOS 3.3 files are given later in this document. Similar considerations apply for the files of other operating systems. The "native file type code" has meaning only if the "operating system type" is non-zero. It is set to the actual file type code assigned to the file by its native operating system. (Some operating systems, such as CP/M and MS-DOS, do not use file type codes, however.) Contrast this with the file type code at +4, which is the closest equivalent ProDOS file type code. The "native file type code" is needed to distinguish files which have the same *ProDOS* file type, but which may have different file types in their native operating system. Note that if the file type code is only byte long (the usual case), the high-order byte of "native file type code" is set to zero. The "phantom file flag" byte indicates whether a receiver of the Binary II file should save the file which follows (flag is zero) or ignore it (flag is non-zero). It is anticipated that some communications programs will use phantom files to pass non-essential explanatory notes or encoded information which would be understood only by a receiver using the same communications program. Such programs must not rely on receiving a phantom file, however, since this would mean they couldn't handle Binary II files created by other communications programs. The first two bytes in a phantom file *must* contain an ID code unique to the communications program. Developers must obtain ID codes from Gary Little to ensure uniqueness (see below for his address). Here is a current list of approved ID codes for phantom files used by Apple II communications programs: $00 $00 = [generic] $00 $01 = Point-to-Point $00 $02 = Tele-Master Communications System Developers of communications programs are responsible for defining and publishing the structures of their phantom files. The ID bytes appear in the first two bytes of the phantom file. Phantom files having a generic ID code of zero must contain lines of text terminated by a $00 byte. The text must begin at the third byte in the file. The "data flags" byte is a bit vector indicating whether the data portion of the Binary II file has been compressed, encrypted, or packed. If bit 7 (the high-order bit) is set to 1, the file is compressed. If bit 6 is 1, the file is encrypted. If bit 0 is 1, the file is a sparse file that is packed. A Binary II downloading program can examine this byte and warn the user, when necessary, that the file must be expanded, decrypted, or unpacked. The person uploading a Binary II file may use any convenient method for compressing, encrypting, or packing the file but is responsible for providing instructions on how to restore the file to its original state. This initial release of Binary II has a "Binary II version number" of $00. Handling Multiple Files ----------------------- An appealing feature of Binary II is that a single Binary II file can hold multiple disk files, making it easy to keep a group of related files "glued" together when they're sent to a host. The structure of a Binary II file containing multiple disk files is what you might expect: it is a series of images of individual Binary II files. For example, here is the general structure of a Binary II file containing three disk files: start end ------------------------------------------------------------------- | Header #1 | #1 Data | Header #2 | #2 Data | Header #3 | #3 Data | ------------------------------------------------------------------- +127 = 2 +127 = 1 +127 = 0 The data areas following each header end on a 128-byte boundary. The "number of files to follow" byte (at offset 127) in the file information header for each disk file contains the number of disk files that follow it in the Binary II file. It will be zero in the header for the last disk file in the group. Filenames and Partial Pathnames ------------------------------- Notice that you can put a standard ProDOS filename or a partial pathname in the file information header (but never a complete pathname). *Beware!* Don't use a partial pathname unless you've included, earlier on in the Binary II file, file information headers for each of the directories referred to in the partial pathname. Such a header must have its "end of file position" bytes set to zero, and no data blocks for the subdirectory file must follow it. For example, if you want to send a file whose partial pathname is HELP/GS/READ.ME, first send a file information header defining the HELP/ subdirectory, then one defining the HELP/GS/ subdirectory. If you don't, someone downloading the Binary II file won't be able to convert it because the necessary subdirectories will not exist. Filename Convention ------------------- Whenever a file is sent to a host, the host asks the sender to provide a name for it. If it's a Binary II file, the name provided should end in .BNY so that its special form will be apparent to anyone viewing a list of filenames. Identifying Binary II Files --------------------------- You can determine if a file is in Binary II form by examining the ID bytes at offsets +0, +1, +2, and +18 from the beginning of the file. They must be $0A, $47, $4C, and $02, respectively. Once you identify a Binary II file, you can use the data in the file information header to create and open a ProDOS file with the correct name and attributes (using the CREATE, OPEN and SET_FILE_INFO commands), transfer the file data in the Binary II file to the ProDOS file, set the ProDOS file size (with SET_EOF), then close the ProDOS file. You would repeat this for each file contained inside the Binary II file. Note: The number of 128-byte data blocks following the file information header must be derived from the "end-of-file position" attribute (EOF) not the "size of file in blocks" attribute. Calculate the number by dividing EOF by 128 and adding one to the result if EOF is not 0 or an exact multiple of 128. Exception: If the file information header defines a subdirectory (the file type code is 15), simply CREATE the subdirectory file. Do not OPEN it and do not set its size with SET_EOF. Ideally, all this conversion work will be done automatically by a communications program during an Xmodem (or other binary protocol) download. If not, a separate conversion program will have to be run after the Binary II file has been received and saved to disk. Gary Little has published a public domain program, called BINARY.DWN, that will do this for you. (A related program, BINARY.UP, combines multiple ProDOS files into one Binary II file which can then be uploaded to a host.) DOS 3.3 Considerations ---------------------- With a little extra effort, you can also convert DOS 3.3 files to Binary II form. This involves translating the DOS 3.3 file attributes to the corresponding ProDOS attributes so that you can build a proper file information header. Here is how to do this: (1) Set the name to one that adheres to the stricter ProDOS naming rules. (2) Set the ProDOS file type code, auxiliary type code, and access code to values which correspond to the DOS 3.3 file type: DOS 3.3 | ProDOS ProDOS ProDOS file type | file type aux type access -----------|----------- ---------- -------- $00 ( T) | $04 (TXT) $0000 $E3 $80 (*T) | $04 (TXT) $0000 $21 $01 ( I) | $FA (INT) $0C00 $E3 $81 (*I) | $FA (INT) $0C00 $21 $02 ( A) | $FC (BAS) $0801 $E3 $82 (*A) | $FC (BAS) $0801 $21 $04 ( B) | $06 (BIN) (*) $E3 $84 (*B) | $06 (BIN) (*) $21 $08 ( S) | $06 (BIN) $0000 $E3 $88 (*S) | $06 (BIN) $0000 $21 $10 ( R) | $FE (REL) $0000 $E3 $90 (*R) | $FE (REL) $0000 $21 $20 ( A) | $06 (BIN) $0000 $E3 $A0 (*A) | $06 (BIN) $0000 $21 $40 ( B) | $06 (BIN) $0000 $E3 $C0 (*B) | $06 (BIN) $0000 $21 (*) Set the aux type for a B file to the value stored in the first two bytes of the file (this is the default load address). (3) Set the storage type code to $01. (4) Set the size of file in blocks, date of creation, date of modification, time of creation, and time of modification to $0000. (5) Set the end-of-file position to the length of the DOS 3.3 file, in bytes. For a B file (code $04 or $84), this number is stored in the third and fourth bytes of the file. For an I file (code $01 or $81) or an A file (code $02 or $82), this number is stored in the first and second bytes of the file. (6) Set the operating system type to $01. (7) Set the native file type code to the value of the DOS 3.3 file type code. Attribute bytes inside a DOS 3.3 file (if any) must *not* be included in the data portion of the Binary II file. This includes the first four bytes of a B (Binary) file, and the first two bytes of an A (Applesoft) or I (Integer BASIC) file. Acknowledgements ---------------- Thanks to Glen Bredon for suggesting that partial pathnames be allowed in file information headers. Thanks also to Shawn Quick for suggesting the "phantom file" byte, to Scott McMahan for suggesting the compression and encryption bits in the "data flags" byte, and to William Bond for suggesting the "disk space needed" bytes. Finally, a big thank you to Neil Shapiro, Chief Sysop of MAUG, for supporting the development of the Binary II format and helping it become a true standard. Feedback and Support -------------------- Send any comments or questions concerning the Binary II file format to: Gary B. Little #210 - 131 Water Street Vancouver, British Columbia Canada V6B 4M3 (604) 681-3371 CompuServe : 70135,1007 Delphi : GBL MCI Mail : 658L6 Gary developed the Point-to-Point telecommunications program published by Pinpoint Publishing. He has also written several books on how to program Apple computers: "Inside the Apple IIe," "Inside the Apple IIc," "Apple ProDOS: Advanced Features for Programmers," and "Mac Assembly Language: A Guide for Programmers." He is currently a Contributing Editor for A+ magazine and writes A+'s monthly Rescue Squad column. Gary has also published articles in Nibble, Micro, Call -A.P.P.L.E, and Softalk. GL74kGBBS.AUTO.BOOTZ GL Ҩ$$BASIC.SYSTEM.QQZHvZBASIC.SYSTEM  Ar !#"C$&%('V*)R+-,/.1032/46587:9;=<O>@?BADCEGF6IHKJMLONQPRoTSUZWVYX[Z]\_^`zbaBce_fdigjh]lknmopqsruQtwvxy5z`{|}~UNFw7bePqS@WYGE'H1KT2\sD(fM>&n-:d)L8"lk{3;0gu<[, y~I9c+ ?!=*.Jm% ^ px|X4av} ihj$#t ;?kLрgk\Kԝ&fZݫqZN%Zshj$[ȂU: [Wro*l ]MjU Z;K+G3(ԡqUR_jƇ`V?Kl Dƴ"w鏖Zȴ|U! E8[Hq:gWI%^ }(=t]}Z7]Ǹ{kkٍDZ|pVkfgoSTܼ -lNliY |J+Vq>23 gs YA>4q>9.T/CV9&A OSN_1>Ǡ)=~Y"+/yP}-/u//_iZ&8g3@#3 Xc)v8^vV>(f0vjf%(Y0!uh{NLi= ArLG^8Oz %#>P+y fˇ*T^üڳgl1'-:5dZ5H-jMqtߎZ{$OHZ$^*|烗P`0[c\ނ QW4OI$Wr k_ 6X:ݟw3sTf}yeX[Ԛb.(R{dvkO`=?q\%Ymuq;E޳r+<m"0QzrQ~kX|DQ1`x@^Ő+?/Iu6:wy4O`)ϴSiQn6yO|rl?LW<>#>-aHOɃlXN9ġ̑l%XxT)νq,Vnu(hr՟ /auU|W=W0Wը cݐ,jͮv\HYo¬ZmaEt[lbfG6|FrW7'KAs2 zZc32ӀvW09ܮb cdvzی{@p/Ú'{jdNN%yf~gϸ_5hn_,Ú'9i~.jͮozȸ˷K]PfLo31r/r1z\?oyIqY5ks1zn]Špx5ۥ:@ޫswur.3.¹n9W[Q-њu%?[D|\/';9LSPz1줤K[A3tiȹ?  c4j9&-w)MR٥4vo'ZsKrMр5ECӉAamAǫ%52} lg!-`^E%\~ibW!1yt__Œwp-k|K$(jdŋۧg9.m]oFV8)|#Z~h˄>}Zܿ8Yq_(~eܧ ǷO#+F~.]H׷F>@IM71hӞoҷrQ1hÿ~Kχ]"&(#cؒ[ܹ@vd@;7 qc=V,Ykzʸ>(VΖ^٬;΄^a3oBbm.P#ؒ&k ka3OC`3s" ohL1쒭o"*v99#NGD0'F#@=N+mFMDo%8ۥ$ڡPR_P4hbИ%v_h3F·j~hFxtRDmOۍBcNO. $.DBM.PGư%gإczC;@;eXPT$oss_ZPq&e}d QuaAML0PX~ >DH}mdpX{}9}񷯍( _tvM IVtv9%C"k?95c'ɓOF~?'߉VՏڛf_`UpФe4쾶,$$,ePv9U2KC*5m+<'0@V=~PEGw$AhpAiJVpZש}Jah_X'{{]oX-fTsXVSk"p@^#n~ 5Њu\lIu.a%{!fX^# {챡ﶌ*F3^#nC40mi~4m7VG^#]Gywӭ皫| ԡY?V̪`0$'8[] i>|"5:T'1O[F q=\-‚x59;oi_sܾk!O~)[sgp"tǸn @%!&gjW+FM WEXY?!js64eG͒V%(`~ 6:Ԋn ŬN| ` @}~YA1M:jrl4@جS2R2Ш)gס@Z_Um+Ȕ߶:wh:a4ɘf[1C]x+ۂm[JƔ߶iܬ2jr+ѝ ub=bא=?!EJ7c s;YѩfNuѻFYtom5uhCνCCG:`\M+65FU}53ӊth.?}=Ɲ{##0^ׇ sOYnOmM3Mj u*n(~n'\PUWFcslǐ &1Ow(ڏ yNd+6X\_U> Wu*oӯS6X\ao\p\0{7]@Iw-h]jYwbvQ< Sc=V-^f}U-z*"L5!7U-#ԃp,+D!,MZ5ZFX/B"=4MXk&Ehsm,hM샏-fDD]d-.߬S4ޖK+L:,t}i/n"ʏ #~XElh l)뿰~fg-@grq^wvhb7v7ա *櫑y%e<ykuh ԡ;(@= GYk$ M㽛Y=w%J/-b=lönซ cl77g5`YuՃzrNi=t4wDpe tF*q<\H@fZ&od^) al#9·;a7g}Q=f^>jŬiQ?/v؜gf|1F mk3M9L}8 W0ɽǗV9D3*taD[~RWb60DEQyM&K3rz)2bNѴO7Z13G N"03O8- 2啥ˋ%z/bFI<=8UYO}pyI}d>T{/6Xj(wQ3Б߁Dp/Y%I$r;90Y} r/(XQYW{ O,wdT)'RaU9Vpg7jIh>1Fc÷i8V܊;i;wr/LpΝ 2) qRŠ[ۂFk)f1hJyųdVb=ϩ|TKw2M |!ÙAw4ᡞ%'ݵ{bp 2:aT2M Ъ s ')2L$sm?.>w{n-E\pE ҹ(`M9L9nvs_OIY[*Ȕm?F H]Ǹ] MwXdvn:! /am\O/]ǝCyV_Pk~/j=|T2ǗO,O0=0q0X*'~W/òݏNrvu~ePI" Z V,_>ڌou:/:d -fW׾ەN"urSsm3qsUN̒=erLNywzqT U۫_N$TI[˩ꝗ"so1e4јSgLw K6 c^9T0nU3?HW/OJS)܃,+30[ 7,f1hulBjFڄX .FBR!ҵgzXP;rQvCA>dP :Z9ߗ\Be@eKC u.dkWb/J^9fz?tK)-aǃ:ߧtׇלV>]4˽;i$^*X7*|vleg8^s^c}O %^3JtYx0n s(`THmWr(о:|tKÿ`5^vL`m({Hnʰ܂E^}v(O;Lj)Knp:V9&M׮ÅslRS U{7%è#asɾ 0dʏ[墟ǝ$yd d0-j)Ӕ_Ae/JbДl7|eq ^:%Lr&&; X]? 2p6f'%T)߶w{pKqgq"9cbII&%*Wq5)dK qT*Ȕw٘DrQP_np:׷!0YovݽҒخ% MnȾMDofF(h|"?j1tSE$]:%iHdo׭gz2̪ Smԃ\An /a~(8DǀrKõ1tި|MImٹI=\Ha=+'m:9ZIA~px|xdʥX+o`@cQ\Oq;d;,q,Fe{!y ފ"M9Qd&*x"/Y]ݥt 70>yiikD7Dz15P0m_+mX*x 4"hSȇȢV>+.ӥl882_U>~3yIH<'/'A~9 9:>>W/왖}S4b_oL֟O߲֧EqBy]$8} >=``qL-[<4X?pJ ?.0OLSTFyvIN$[?wW7 yFdɂkH,YkHiT@ 쪟v>gid_CHO.~w Ԙ@ ߕi䝑)5c 0 ΰo7jji| 'OGRTseN5w:<VYoƿ\oLޥ0|ſg4?f2qN܎-zI@rwwdtZtsEW__`E'QMb&qv*! _8qha,drFMШ_S(c!/^3 2 LaI2>oh(oQfi~qXIH˫1px8;3!HC{?are_׺3؉I1Ut>{!*[x C:04 w Q#%:v @ޡ@n~dk]h/]P9~,tsd~ߢ Ñ~k]h@ G^[kk̓a}0Y?} ®RJ!B?'PJN&}2W}6[LV<->~ sI_%TöBU>YMf3b33ۿXӅ9xCqhC8FĪBqh3oZ{.OΉiz6 BDOx#zJ_cW;N6nۡ5~iggggggGٟٟٟٟٟٟVpڹ s{vviEc1MOp{F2ӖFrPۿcKp ǴMZ kkQkZoͳgo<{<7Ϛ\R|bGp̌9o7uww GL 'P uRAM.DRVZL @ ^  qMuG ȃ9 ѓ(#ɘ ʋ ̉L ̉ ej  I s (sIs H ȌsIEs(sE #שs 0 (0#J#n##ʎT#0/#8#)#΃##sV#,b0LA"L#V#u#Ș ߠ*Y#   #<#Jf212)ɰ0#'3211&', P#  U#U# #ss#L L਩ Ȅ߅܆Ȅ,`0 RAM' L%B{'uH@HAHD@EA GHF8eFG G*hGiШ,BJD , hAh@h`E$EPDD@@碀`s s0` GL! U6P CACHEZL ASIDER l  v  U MG ȑ9 ѡ(#ɘ ʙ ̗L ̗ ex  Y / I X0f%)pJJJJ ! }% Š㩠' w%  8 v Ȅ )?  ɛEɍɰ:ɸ6 f%f% i! }%庠 %f%ɱ ɲL%Lnf% e%)I  " w%L%S&* )I YI S&12)0 𩰍l%)JJJJ " w% %ɰ:ɸ6 l%l% i" }%庠 %.l%ɱ#ɲL% w%L%nl% l%Mf%өo%p% k%Ġ#к'o%(p%)* k%Ffi)8 3^=8  w%L%RAMIΑI)*Q&12JJJJ ]( w%L%2)pMf% 2)pMl%  w%L%L%f%JJJJ Ӎ#&"&l%r%JJJJ i',,Ĉ кiНЅ'ֈ&й'ѩҙәl%:ЍѮ9ʎюv% k% q%t%t%u%t% ,8fLv$,LP00 hh %HH`0$`Le )?  ɛɍ`hh L !, w%Ӡ$ }%Ԯ w% $0L =?VA@BDC@EGFIHJoOLKzNMOP_RQSUTWVXZY\[?]_^a`cb6BedgfhjiklFm'nSof7NqpbrQtsu&vxwzy|{~}5w,]UZy#sWn1qg-(*+u:>! .0923"Y t)< ` ~aG{Jj}%Ae;[p|v8=MdlLCEhKP^XkcH4xiDI$mT\{(2^nIT\M 3kªƅ 4Ie;$e4GhR6ԯiCG"IqEhV\7S'z)P\懫:b ^,(1 tKpZ~ѤiiE6 t>&eCn~NIXYptw!鸇&eCDd`h[EƅXQ:ę8IPyF6q qYCV (gfiqhf "+pɃw5M&bhD}ȏvx F%;XxUS<4['7y_9C愉0s5k 0@8 o oTnKm$0C [5:[5er-bC#iZɝ6'VW 85A qTf!eh4$Q_/NyцV=}@ ~-cfVLZra0L ~b; 2?h:<T' ⠅`6"VU|ClFJ(SYL H{]idKa\dЭFt1u-3pϜtZ׵-q TTbd)v4 0Mi@ʆd;x\ɢJdDsS9SqL⃟6i@ʆdDUBDÜќ4 e]Ӷ\ؙA46vHM;Rّ?;b$a Dĸy+7)LʎW$԰_}Nd^ : 5wxr4;]1q"Î@o1sHL];}aL/V6{IdKݿqsk>Pv0XG~`;W@/zu|[žJm=? <Joͬ½HQIXnˌvS56qL e6y rX鷒nŦũԴXdY n,ڛu"ZߕPƁJ+⏨{y&zܪ{bhW2_+!,$N'F1KUXcXZ{-nP\ڛ |{sEMUsvմ*j ]ŭ|h7İr25GUrՐJ[{ [ ڛW TRM9ZX__\/%WbTr2Iܪۓ3 ڛے`G(cYЗ˽.O2 y'(Gh1u̚[u}މkuө2u]D׭(C*n1jVcP$9ԹKXMB E"P(N*Ps0"Dv; U"!k%7-j7_끖D0Rw{D0jtBx~ Px ŷ"Ds %{7\=rH ~|˟Tue\i`4_+REj:`7+4u/PrXrp}$ĄwB0juR{Z=*juϿ7%}ug5ߧ>_y۲2ju]Va^IYVa^iH.-;N6UZlEmOv( K,T vEחX2WT-de{Qv(EA"Pl2sEnW8_"KYm 2[m .-dׯXg)/M /ԯDE/%fu/vg۲&ۖMUFmB}$ͻN2d( BI %ʮ=[k].Leޛao1Szco n(U[T滲v8fg(SljT>ٲGPZtGPZtGPZ]Gdۑ-{A#e FdA@j*hFhuh߸cK .+ͪᖛ]MA{6%W 8 ]JAubh0КO{+sbA..T8[ӬCf%G.H:8&~Oé `1訊ؚt0<̻Cxw4+4!Gx3$:H]Kj\\ ĹHPgGxv$?h-OCkTwWثAn4?}?2xf/Kw#/ i˭_G/g'Cr?4$:HjwrQ>|O2ИT"0`D0ӆV!nќrUnY@H<;Ӑ1у)3p"&jj/*-M4is9- p?;gGH)~ύUwͷ/Ƭ}wi)}{{Yh(]{Kiߗ1r9Bfn4*߶8\- uz8V(z}4wh{{k5nl w;P6G#&ԵT_u>GøѰ4}lLl54$7$9ZfCMXijul48-Vƨcg<$$ձZ/G&:UC:'/}!ܾs{hRpӾ,-_J~n_yX#]tdR,;KMcYi:i͊Jf~Xm];a[9u&+بkxw6gL/_:'~n_yX#]tdR,;KMcYi:i͊Jf~Xm];a[9u&+بkxw6gL/_:'ڳpX#4:6_X#cKhf؍}{OY3 u͒tIձ:A`PXSfɓqY`js3_hHܹ!I#["@'t 3:X?&8r{߮{_>(<~US%y΅ؽ/zxI{b+n n牝SavND`qZ."ЇW%P睼׹ WB?l*7BD{fc'KD0?a?+ !*O HȽDp??]{bMlcAOW| =qE+tZ3:ʒs~Zz nWI!oY__2#简.At@>w.vҽn17 v0 ":NU[^xg/Pm_X>Cw^uSxEe]m:|5 ''ܪcOQMr5Ov#"lݼъa#31H!wbqz0'XETz|vTRK0V`$/7PK|uH"0Έ=yWU{5Жc\%8.[aJ%7ձ*S!GD9&5#hJ=QǞBJ<+ʌl)<ZY^. Cy:Wjulk C9+C~Ǘ}ǫzW?59+͏F·*}9>;8TJzoKu}dXa=Nߓ-|wI?F>1^Ag[XF떙"kk{Ac ?;FGw.hPKX9t&?4˫ɽq[ˇc{I?~/Vc8qR?ϏyFce[>.ө?Mj9#hQ`.FR雙$=z7L:~xן:.!qOB&ЉG;_lq%zgsgVVﵲ<900=>䈌 X{> 8_xF_:m/,tAy󵒰zg@opN8IWzpwy%oOҽC :PPLI[j{!wR?^|u,/,F@[\t>_gvøFE8>.{z<ΖK|K۲ ڛ~zzA{c`jg/hgm3ļ? m[]P5t6 :ϏOlex t>Ϗ$ ւ:ϛ ;C G[[W&-K'6Lr(3c:?.A@/H%M U=.1JKȆ:.(3=odǘΏgB ,zж)|i39w.P@ M6E sf]yQ/~Rdǻ}ODugg7LXK6fPBg$56lwY?ɻH%ׁWZҗK l$E_^{aۄ)Cڋ9bքIwk}ݾF<>ɳ (v>1vt fI

kO"Pж qpY8ģ[o/O z{;l'1&,X)&]KBhNM%%T3mǻ}V } } }orBS8L6n9k}'-8,Zڕxxu7Z_b( Eͯu}vShp+lh@㿩~'&I;z~:m?u~{zt?Wg#_S^zxogJEW|7͔3Hb}WU\Ui=V,O^4OxEM>jcvj\!hq}c.¶9/ܼpۺ@1s8AVܼ)qqFZ"9|/c12n<%̛Wa{5Lo9:uvn˸/lE0I^T{8Nqb\$щݸ;*-DHn,ӹyd1ٰ%3;3J1oّz8rO;ڟm |z7ܟFwc|?'Hgq'.@[WV1n)Ƴ1IU0Rݫ v^MϰW vճ5?;{3|(F%zFWո睿y\"e0ܼb\Rh^gY&:?ň&"FAO|͏N˳Bq1_a>5ƣGvjycaklKw㉝GvjM [2㍽nV޼_w Pc;@;iRcP]Oܼ)5ͪxW2Mr9PDm˻y#>z7Y%vD:q捬jxzͫbRd)'J;b-asm<1_/mVe+`\{e`9_ r0gyќ;*"ҍj?QG0 Vo߼9`v}_ i&{|rx5>㪯֗=U\:7oontn -vj;(M8wtĥ@Mal{xǷF xbu~SQ&ZyoIt#)gzu7E5WöUwCDUT|GsF<tɱ>zAOxk}XуO mygOlif*[9͌3~֛93_ztGg.U8q b]zo]ˠfhc7zX"^o$|'=;@ /x /gm˒C Kw ݜ>3bjlU yuw9l aN~S˜/:<.|LB^~jX;S^V_.]{b5!rߖg~M]L! ֓9+X ܥİk>7;uSl Z.Q6yַ&]vn^qUX7O43kKtҩSUF1# 7썫gW(y|cy˃Ыձ׹ySxcj[XeM6 :7o3y%<A1ev+nZ_`8`1rv }^k絮%OR˥RMK{֢\ګy#v:lF/mKˑ+'6<]qtl)VnIjbς_ 郎׋|4^ M9RFuoƯU:7卙Z]7O]3LB^>9u6Sd.w=1ߖ^D0bb=y{ym5A0vKa|n7cHYʷ3h[GLܢMP43u}]>Fu8Ugtn^KfԚ8N؍eړ;Qypݍdr7~OGǽdLc3Hս^nܕ-OcotL1k)xCK6i1-ʎ7vz )5l#;V/NarAH!mRu oȴ5,8Rq;TrЦJ_Nntnt8u'fvkxJEByҀPk;XQu^[߼)st*5^߼ m TNӍ`]x/UI76ՍjNdz|^/KSElNl)"qNDƵ51zF0.\/ ~/5aJv'Ћ]|w0SAӹy͘Mˎy,.HwuӝqW٦1!s2ZRb7u=.^zxۏ|$ՍmR:VoHg͛*j;hzSݸ&_c;7VcEǞ\0,-}z?f~"@f 7--_or~&cMsj5:E^c׺nqqO+Ro7,c~hߞ0&ŧoUѠoX͛$o::z+?Nqez}8D?SW q:G@^gY:7oz#nFH;FO윰[wNӖmJ%}nH򐬭)~eaf/ _i{IkG?/)3Owr+ \cw}D4{l )3:߾|}03;a GNUnx{gj9!WsgES8L0#'Sl=˃uB fքNߞu{-8 mK zS^Kz~&D ~8撼f{=R^RM ;Ȇ7~Щ~J0H!wb'F|4̜q f26u,㤈I؝B^n>Ujw6 v=elZw6Br71o (l쵏8ߣ[<;٣:uV^cxЋ;wLvώ ǵ duh -e;$BiȟAm~&6IƳ#% sAS_eAA\P5ѠRf`E[a>(Uը0UaÍn~G]ޣ_O_eӽC,f~ޒğpWk+q? {zDA4whyAF9SUjgtSvђKMU-Q4.)KO$ű`3)vst槠M )' 6q,,؄RTEU WWU 3-whhCc_Rjku &+_=r"Ųm5<;k h~-" !am~zgGH>G/xXw/on#n#mk"+̴SR|ڰ `BUƌF zxdVh@k4beUYB)vcn{hT[#oP!K-m{RR)^軤TT!ӱ>I{ɼO& 2ƹj8ocu[zZW^H\}4?;gG~ǚh"mMq::ɔ)M\!DhKaAuƓi'wJr6 1)op]Vfnihttd_2I#ᴍӏ&_;"$S|ɗJ&K7 v8#0h;F:iayh4a-{mMIό~M4Es/|54gu#M|o%Ei4W6[umDSG %Uo( *L >R` @>H P0$TP@@Uj4GjU(R6nu:AԠU @eUR @*ZU)9g("*EѡxPa0ՁD T0P#] Gʁ:hS+u0ԀRCðGC0!4}uZ>Mzkׇ9@S٤vҋCKŰ{4I]ܳ &лI> ~Rf:/ !ʙyO.Ez^@"_n\q#%S-ބy`%)tBBG0΃.q伀LE _18r^@zie8r^@L2e.}9a*א9;#H%ܷU#j"a>bJ3g]85GLyY\g5S{7+ }޴>r*C @ZK|/}|bf}{¯8!1[>VSSǗx S^rm;)/X)/XBy;磔+;+.BJ K\&儕J?\*0m25gb|-r9 6i{d }Hs^O԰!Zr/76dIK߽w>ူZҝ~?tgܮMA{s_4›|vR񼠽st NZCCrbJ%buױ`%W/ x<8uu+'hjb+>Zο^_%hUpf6A{{׫+#bhZ~%nu]+" 969?t b{ }~cR1ϛ{L"/dI#t^|^)3T=*֊2գƺ6]oz뎟99"(1dݰ*2^>:UvY*f# _f.NjOҕ_r=$}N$9eϗ9ݑ/{b?W9Y@ꣷ%buiEם%tS!'DASAuC"mp1\w?!&C4)3 GLP P BSTARTUPZ GL*+ZMODEM.DZ  L64:KL )amAM֍J A ALKL)졊) m졈J /    L⡠ 㡈s ء E ~L eC W ~ ۩H ~ M ǡ eəs @ 's ¡LӠsLsM  `n HmL hi iLMc ]^ G ءL L o ¡ LE ~L ⡩R ~ j MB ǡ eő @ es @ '㡭i䡭i塩 塩 Ls ¡Lȱ )J` e e I`8`顩d ? 8`` %0 e)?` 8`hhLhh ¡ nLs \ $  ##$  $L  Z ~ и ` e e` 8`HM衍衊H.衐I衭I!hh`HH#$塮 hh` $L $  #`Zmodem Upload ] _ eLL硌衩s`  `   sDigi - Crakers PeaceFrog! GL*+ZMODEM.UZ ɬ  yLt`    `ޠߠ ݠL y64ȱ@ݠB$  Zmodem Download [ ] _ #  LH  ܠ I   Oנ ֠  ۟ǭL ۟ ۠ܠԠiԠՠiՠ  TS  ܠ I ֠נ  Oנ ֠  ۟۠г L ۠F   ۟ ۠ $  '$ `W < C8` 8``W ڠ  C E 8``ؠd٠,p 2 ڠ ڠ`0,pؠ٠ɩ` hhhhLHMננH֠.ננIנ֠I!֠hh`ܠԠՠ֠נ`H"$h  `HH%$Ԡՠ hh`hHhIH  HIHhIHHH` $L ] _ eLL硌衩s`  `