Subj: GS/OS long pathname handling 88-10-16 15:31:42 EST From: Dave Lyons Msgs: 41 (89-03-15) Under GS/OS, class 1 pathnames have a two-byte length count, and prefixes can be as long as 8000 characters! The old days of fixed-length pathname buffers and allowing 64 characters on the screen for displaying a prefix were a lot simpler. I want to come up with a good collection of C routines to make life easier. Without one, people (including me) are likely to skimp out and take shortcuts, like limiting pathnames to, say, 256 characters. Eventually I'd be sorry if I did that. (Somebody would turn up who WANTED an 8K prefix for some unimaginable reason.) So here's a rough idea of what I have in mind: The basic object type being manipulated is a Path. This is an abstract data type (ADT) that should be accessed only through the routines in this package. Internally it will be a handle to a variable-sized block, the most interesting part of which would be space for a GS/OS pathname. The handles would be locked only when necessary, and there would be a LockCount to keep track of how many pointers to the path are being used--the handle is unlocked when the LockCount gets back down to zero. Path NewPath(unsigned length) creates a new Path with the specified length; returns NIL if there's trouble (and _toolErr specifies the error) void DisposePath(Path p) void SetPathLen(Path p,unsigned newLength) unsigned GetPathLen(Path p) char *PathAddr(Path p) returns a pointer to the pathname; call UnlockPath when the pointer will not be used any more char *ResultPathAddr(Path p) returns a pointer to the path buffer's size count; use this when a GS/OS call will return a pathname; call UnlockPath when the pointer will not be used any more void UnlockPath(Path p) (internally, decreases LockCount for the path and unlocks its handle if the count is zero) void AppendPathText(Path p,char *text,unsigned length) appends the specified text onto a path void AppendPathC(Path p,char *c_string) void AppendPathP(Path p,char *pascal_string) [What about Prepend versions of the above? Useful? (I know, "prepend" isn't a word.)] [There should probably be 6 conversion routines to go from any of a Path or C-string or P-string to any other.] void TruncatePath(Path p,unsigned length,unsigned Where) Truncates a path to a max length specified, putting "..." in place of the truncated text; Where specified whether the truncation happens at the LEFT, MIDDLE, or RIGHT of the path. Yes, truncating in the middle is actually a useful thing to do...lets you see what volume and what specific file or directory you're working with. That's enough for now--your additions (and maybe simplifications?) are requested! --Dave Lyo Subj: Hello?? 88-10-18 02:15:47 EST From: Dave Lyons Gee, the enthusiasm is underwhelming. Should I interpret this as apathy or complete approval of my rough specs? Will anybody besides me *use* this package if I impelement it and put it in the p.d.? Subj: Re: GS/OS long pathname handling 88-10-18 20:02:24 EST From: HyperDyne I'm personally not too concerned about long pathnames, as, in the case of the 8K prefix, it would, assuming 32 character long filenames on some HFS device, still take OVER 200 folders deep worth of clicking before such a prefix could exist. And a user typing in a pathname even over 100 characters long in any environment seems unlikely to say the least. In that respect, perhaps Apple has here a solution looking for a problem, since it seems unlikely that you would ever ever everfind a user insane enough to try to use a pathname or prefix that is over 255 characters (16 folders or MORE deep on a ProDOS volume!). As for CD-roms and VERY LARGE VOLUMES, the use of folders starts to break down simply because long (and deeply nested) folders are even more unwieldy then those old fashioned CP/M 'flat' directories. I think resources and other 'hidden' data that the user can manage but normally would ignore by working with a single file is the real solution here, as there is no clutter, and everything can be moved at once in a single (user appearent) file operation to a new folder. --Dave Subj: Re: GS/OS long pathname handling 88-10-18 20:10:00 EST From: AFL Floyd Dave, I *would* use such routines. I agree that the only way to deal with these long pathnames is to insert an "..." and create a shorter pathname when displaying it. This was how I planned to handle it. After all, you would need a word processor to view an 8000 byte pathname! Your going to probably have plenty of time to do it, because I don't think we'll be seeing pathnames of this length for a long time. As far as your algorithm for "fitting" a pathname into a set length, I would use the last directory and file name on one end, and the volume name, and as many directories from that point that would fit into the desired length minus the "..." in the front. Pretty simple actually. Floyd Subj: Re: GS/OS long pathname handling 88-10-19 19:27:10 EST From: HyperDyne Floyd: My appoligies, I was not objecting to the idea of the routines themselves, or the way they would display pathnames too long to fit on the screen. The only point I was really trying to make is that perhaps such routines were 'overkill', just as up to 8K prefix's are overkill, since no sane human would ever (except possibly very deliberatly, and even then, with a lot of patience) come close to pushing a pathname that long, or even longer than 255 characters, in any ordinary situation. Where pathnames can easily grow too long to be shown directly (I've thought of some situations where verticle stacking for each subdir name with indention would also look good), I do agree a simple standard way to handle this would be very useful, and like the '...' (shades of VMS?). Dave Subj: Re: GS/OS long pathname handling 88-10-19 19:50:33 EST From: Dave Lyons Dave S--Human fingers aren't the only things that generate pathnames. Consider a 'copy' command under GS/OS trying to copy a subdirectory structure--the internal operations on pathnames need to be able to handle the longest pathname of any file in the structure being copied. Certainly 8K pathnames is a bit excessive. But what about 1K? 512 characters? 256? 128? I wouldn't feel too safe with a 200-character limit. I actually can't come up with any length that seems "safe" that I want to use for lots of statically-allocated pathname buffers. --Dave L Subj: Re: GS/OS long pathname handling 88-10-20 10:42:07 EST From: AFL Floyd Dave S, No need to apoligize, my message was in response to Dave L's message. :) You guys should get a name like 'Floyd', I don't have any problems with people confusing me with someone else. :) Floyd Subj: Re: GS/OS long pathname handling 88-10-20 20:51:45 EST From: AFA Parik nah, get a name like Parik, I have yet to have my name confused...:-) Subj: Re: GS/OS long pathname handling 88-10-20 22:06:01 EST From: Matt DTS Yeah, Parik, except maybe confused with a dish made of pumpkin and yogurt... --Matt (oh yeah - :-) Subj: Re: GS/OS long pathname handling 88-10-21 10:21:32 EST From: MikeW50 I have to agree that at least certain kinds of software should handle path names all the way out to their full length. I was a bit hesitant until it was pointed out that optical disks may have very long path names to structure all of their data. In any case, handling long path names with a subroutine library is only one way to do it. There are several others. Here's the ones I've thought about, along with some of the major pros and cons: 1. A subroutine library. I don't know what to do with htis one. It seems like swatting flies with a hammer. Maybe some comments on what routines mught actually be in the library would help. 2. As a general method, on any call that returns a path, you can point the output string at a four byte area that looks like this: dc i'4,0' After making the call, you expect a $4F (buffer too small) error, but GS/OS returns the size of the buffer needed as the 2nd word. You then call your favorite memory manager to allocate a buffer, and make the call again. OK, it's messy, and it also involves two calls every time. It does, however, work without wasting space. As a modification: 3. Call your favorite memory manager to get a default sized buffer, then make the call. If the call fails, dispose of the first buffer, allocate another of the proper size, and make the call again. This method is faster than the first if the buffer is chosen to be 128, 256 or whaterver - large enough so it is rare that the second call will be made. It takes more code space, though, and you are likely to waste space on the original buffer. To summ it up, this method is faster than the first, but takes more memory, both code and data. Any comments? Oh, of course in assembly language, the dirty work would definitely be in a macro. Reguardless of which of the above methods is used, the programmer would still only have to type a single macro to do a GS/OS call. Mike Westerfield Subj: Re: GS/OS long pathname handling 88-10-21 20:03:56 EST From: Dave Lyons Mike, an outline of my idea of the functions in a subroutine library for pathname handling was in msg #1. Yesterday I implemented a first draft of the thing, based fairly closely on that. The general method of repeating a call with a bigger buffer still applies. I think it's going to be worth it to *not* deal with handles and things directly, but to let the library do it. (I'll let you know as soon as I integrate the thing into the infant Davex 16!) One thing I'm planning to add to my current package is StartTempPaths and DisposeTempPaths--this would provide a way for the main level of a program to automatically get rid of path buffers allocated by subroutines, freeing the subroutines from deallocating them explicitly when they exit abnormally due to GS/OS errors. (Davex 16 would call DisposeTempPaths before processing a new command and StartTempPaths before calling a command-handling routine.) Subj: Re: GS/OS long pathname handling 88-10-21 21:02:34 EST From: TMH2 Implement it! A subroutine library is a suitable method until the systemSW weenies at You-Know-Where decide that run-time libraries would be useful. T. Mike Howeth (You-Know-Where is a trademark of You-Know-Who). Subj: Re: GS/OS long pathname handling 88-10-23 12:33:11 EST From: JSchober hehehe... Floyd's got it even worse than just Floyd... it's Floyd Zink... now THAT'S a name no one will forget!! ;))) Ditto "Parik Rao". :) On the more serious side of things, I think displaying LONG pathnames in the form ".../most-nested-dir/myfile" would be pretty nice. Dave S' idea of display staggered pathnames downwards is nice, but takes up a lot of space (screen-wise). Subj: Re: GS/OS long pathname handling 88-10-23 19:17:36 EST From: HyperDyne RE: Joe; Yes, it does. The program I used that in was a 'whereis'/'filefind' utility for CMD/16 which goes through all subdir's to find a file you only remember the name of. I chose to do that because I thought it would be best to show the entire path, as the user is already uncertain as to where that file is. --Dave Subj: Re: GS/OS long pathname handling 88-10-24 14:28:20 EST From: MikeW50 Run-Time Libraries: Who needs them? That's what tools are, after all. The main problem with run time libraries is the hastle of dealing with a version of the library that doesn't match the version of the program. To solve that, you need to institute some form of version number and set up the library so the entry point to a given subroutine does't change when the versin of the library changes. Gee, that sounds like a tool handler to vector the call to the proper spot and a version call in each library... Gee, that sounds like a tool... Gee, whay not just use tools & user tools? Gee, I think we already _HAVE_ run time libraries! Clean Up - I like the idea of a single clean up call for disposing of temp path names. I agree about not wanting to mess around with the memory manager and handles directly, which is why we have a memory management unit we use in programs that need lots of small, fixed location pieces of memory. If we didn't have the memory management unit, I think a subroutine library would be essetial for dealing with GS/OS strings. As it is, we can deal with it using macros. (I think - we'll see!) Mike Westerfield Subj: RTLs + status report 88-10-24 19:57:12 EST From: Dave Lyons Well, one limitation run-time libraries don't have that user tools do is that user tools belong completely to the current application. CDAs/etc can't use user toolsets--if they try they will eventually break, I betcha (consider what would happen under a MultiFinder type of environment, where the system would switch between different sets of user tools when different application windows came to the front). Anyway--the first draft of my longpath routines is working okay (in C). Need to test out a few remaining routines and add the temporary path business. Will post specs + code in a couple of days. Subj: Re: RTLs 88-10-24 22:18:09 EST From: TMH2 RTLs also do not have quite as big a problem in the 'unique-ness' arena as user tools, either. Numbering conflicts (with user tools) are much more likely than are naming conflicts between RTLs. Z^\GGGGGGGGGGGGGGGGGGG\_ Z R Z T. Mike Howeth II N Z Dallas, Texas N Z (TMH2) V Z B Q ZO WVWVWVWVWVWVWVWVP_ Subj: user tool numbering 88-10-24 23:35:01 EST From: Dave Lyons True, although an application always has control over what toolset numbers it chooses to use; assuming people are bright enough to write their toolsets so that they work as *any* toolset number, it's not a big problem. (Writing a tsnum-independent toolset isn't too hard--just a matter of keeping the function code on entry and manipulating it into an error code number when necessary, and extracting the toolset number from the function number if you want to feed it to SetWAP or GetWAP. The function number is guaranteed to be in the X register when one of your toolset's functions gets control.) --Dave Lyons Subj: Re: GS/OS long pathname handling 88-10-25 11:17:30 EST From: MikeW50 Mike, that's the classiest signature block I've ever seen. Are you using a macro processor to write it? Mike Westerfield Subj: Re: GS/OS long pathname handling 88-10-25 17:27:37 EST From: JSchober Dave... Re: stacking directory paths downwards. Aha! For a FINDFILE utility. Yes, then since you'd be using the screen for almost nothing else, I DO like the idea of staggering your path down the screen. Go for it!! :) Mike... Great job with that signature! Really looked nifty. :) --Joe Subj: prefix 0 can't be long 88-10-25 23:52:10 EST From: Dave Lyons Since prefix #0 is still limited to 64 characters under GS/OS (right?), it doesn't work too well as a "current directory" in a GS/OS command shell. This is a problem that it I want to deal with in Davex 16, and it seems to me that eventually Standard File needs to deal with it, as well as other GS/OS command shells. One idea would be to use a nonzero prefix as the "current directory". For example, Davex 16 could use prefix #8 as your current directory, and it could automatically add "8/" [or "8:"] to the beginning of any partial pathname. (And prefix 8 would be printed for a prompt.) This will work nicely for commands internal to the shell, and for commands written specifically for Davex 16. But other commands (EXE files) written for APW or whatever won't know about that convention, and they'll expect prefix 0 to be what the user considers the "current directory". Further, Davex 16 has no way to determine which command-line arguments correspond to pathnames for generic disk-based commands; if it *did* then it could simply put 8/ onto the beginning of the appropriate arguments. 8000 characters may be a little much even for a prefix on a CD ROM, but 64 is not enough! Davex could keep prefix 0 set to the same value as prefix 8 whenever possible; should it simply refuse to run generic EXE files when prefix 8 is longer than 64 characters? (Same for S16 files?) Your insights will be appreciated. (Your confirmations that my above description of the mess is correct will also be appreciated, but to a slightly smaller degree. :) --Dave Subj: Re: GS/OS long pathname handling 88-10-27 10:00:17 EST From: MikeW50 Profix 0 is not limited in length to 64 characters by GS/OS (as far as I know), but none of the command shells have been updated for full support to GS/OS. Once this is done, you should be able to have a prefix 0 up to the 8K limit currently imposed by the ProDOS FST. Mike Westerfield Subj: prefix 0 length? 88-10-27 21:08:35 EST From: Dave Lyons Oh! Well, that changes things a lot, doesn't it? I betcha I'm still using the class-0 call to set the prefix, and I shouldn't be. Now, what happens when a class-0 Get_Prefix tries to get a prefix longer than 64 characters? Subj: Re: GS/OS long pathname handling 88-10-27 22:33:16 EST From: Matt DTS Nope. To my knowledge, the old prefixes (0 through 7 and maybe *) are limited to 64 characters in length, even with class 1 calls. (They really have to be, because all the class 0 calls expect a p-string [length byte] in return, and GS/OS won't do "editing" on the prefix for you if it's longer than 255 characters. Therefore, that old P16 limitation is still there.) --Matt Subj: Re: GS/OS long pathname handling 88-11-01 17:22:59 EST From: MikeW50 I haven't tried it, but the GS/OS docs list class 1 calls for both Get_Prefix and Set_Prefix. I assume that means you can use paths longer than 64 characters. If not, long path names on GS/OS are singularly useless, since the user would have to type any portion of a path name that is longer than 64 characters anytime the file is accessed. Mike Westerfield Subj: Re: GS/OS long pathname handling 88-11-02 00:44:05 EST From: Dave Lyons Mike, prefixes 0-7 are limited to 64 chars, but that *doesn't* mean that the user will always have to type all but the first 64 characters of a pathname--the application can provide a working-directory concept without simply using prefix 0 to impelement it. Of course, this raises interesting problems for something like a command shell which has to be able to run generic EXE files that expect prefix 0 to be what the user sees as the working directory. There are at least two possible solutions to this mess (each requiring changes to GS/OS) that are getting tossed around right now, and I hope to see one of them impelemented on the next system disk. --Dave L Subj: Re: GS/OS long pathname handling 88-11-03 17:01:15 EST From: MikeW50 Dave is right. I talked with some of the folks at Apple. The problems they are trying to avoid by restricting the first 8 prefixes to 64 characters are real, but certainly cause many other problems as well. They can be solved, and I am reasonably confident that this problem will not effect the user by the next release of ORCA. Mike Westerfield Subj: first beta release in library 88-11-22 21:49:15 EST From: Dave Lyons I've uploaded the first beta release, including source code, into the ADV library under Source Code. (Haven't checked to see if it's been released yet.) Let me know what you think of it. Subj: It's released 88-11-23 16:55:10 EST From: AFL Jim 'nuf said. Subj: Disable directory cacheing 88-11-24 10:17:26 EST From: AFL Floyd I don't think it is possible to disable the directory cacheing feature. If you don't want to use the benefits of GS/OS, you might want to go back to using P16. :) Floyd Subj: second beta release 89-02-16 21:52:02 EST From: Dave Lyons If anybody hasn't noticed it, the second beta release of my LongPath package (with C source) is available in the Souce Code section of the library. Subj: Re: BlockMove vs. memcpy 89-03-06 23:46:07 EST From: Coach101 I noticed that you use BlockMove instead of the "C" function memcpy. Personal preference or is BlockMove faster/better etc.? Subj: BlockMove and memcpy() 89-03-07 21:46:09 EST From: Dave Lyons I really don't know which one is faster. I used BlockMove only because I knew the parameters without looking them up. Subj: BlockMove 89-03-09 12:59:44 EST From: MikeW50 I don't know about memcpy, but block move is not particularly fast. Mike Westerfield Subj: BlockMove efficiency 89-03-09 19:45:01 EST From: Dave Lyons Last time I checked, BlockMove did the actual work using MVN or MVP, so it ought to be reasonably fast. There is a considerable amount of overhead, though, so it may not be a good choice for copying _small_ amounts of data. Subj: Re:Some Comments 89-03-12 13:12:33 EST From: Coach101 I have converted to using the _longpath_ package and have a couple of questions and comments. 1) In _PathSeparator_ the _for_ loop that controls the searching of the characters in the path name is coded with an end test of "i<=len". I think that this should be "ipathsize-4" is used on a path that is not necesarily locked. I am not sure what conditions can cause memory to be re-arranged, but if memory were to be re-arranged between the instructions that generate the pointer to the path and the instructions that reference the pointer, then an incorrect value could be returned. I suspect that this is safe at the present time since I think memory cannot be re-arranged during an interrupt (which is, I think, the only thing that could interrupt the flow of instructions) but will this always be true in the future (what will the rules be if a "multi-finder" comes along, etc.). 3) In _UnlockPath_ the path lock count is unconditionally decremented. If _UnlockPath_ is called with the lock count already at zero (a program error for sure) then the package would in the future perform all sorts of operations on an unlocked path thinking it was locked. How about proctecting the programmer a little by not decrementing lock count if it is already zero. 4) SysFailMgr is a rather strong response to an error in a program. Some method of reporting errors back to the caller would be nicer in the program development/debug cycle. I would prefer to post some error message from within my code saying what error occurred and what my code was trying to do when it got the error than ending up with a reboot (which I think is what SysFailMgr gets me). Subj: good suggestions 89-03-12 23:13:26 EST From: Dave Lyons Thanks for the comments, Coach. I'll have to look at the code to check out the PathSep loop. If it's wrong, I'll fix it. The references like (*p)->pathsize are okay even if p is not locked. It is guaranteed for all time that memory will not be compacted or purged during an interrupt. If there is ever a MultiFinder, presumably it will work like it does on the Mac and steal control during GetNextEvent calls. I think I'll take your suggestion for UnlockPath and have it do no harm if it's called too many times. I agree that causing a system death is a bit drastic, but I don't see an alternative that I'm convinced is better. Returning an error to the caller is the most obvious thing to do, but typically the caller may _not_ check for the error code! The fatal errors are in response to passing fried Paths to the routines; in cases like out-of-memory, errors are returned to the caller in _toolErr. One thing that could be done easily is to add something like InstallPathError(procPtr) to let the calling routine specify a procedure for the LongPath package to call if it wanted to report more information on an error. That would be okay if the program still wanted the error to be fairly fatal...it wouldn't leave an easy way out for the main program in general. Subj: Block Move 89-03-13 15:36:41 EST From: MikeW50 Dave, either we looked at different versions of the memory manager (quite possible), or one of us was napping (also quite possible, at least in my case). I remember block move using a loop to move the bytes. The loop moved one byte at a time, and I think it incremented pointers to find the various bytes. Using mvn would be tough, since block move supports moves across bank boundaries. Still, it could be done. Mike Westerfield Subj: BlockMove 89-03-14 03:26:39 EST From: Dave Lyons Well, I have Memory Manager v2.2, (ROM 01 + System Disk 4.0, but the Block Move code being used is in ROM). I just popped into Nifty List, typed "BlockMove #L and got as far as the E116A4 vector that it calls to do the actual work. At that point it does some stuff that I haven't bothered figuring out, and eventually builds either MVN $wxyz RTL or MVP $wxyz RTL on the stack, & calls them. Presumably this happens more than once for a BlockMove that crosses a bank boundary. Maybe I'll trace through it and see after I'm logged off. [Some people complain that there isn't enough entertainment software for the GS...they're wrong! All you _really_ need to be entertained is a machine-level debugger, hundreds of K of system software to step through, and a lack of anything resembling sanity. :-) That reminds me...will have to step through some SANE routines sometime. I guess I'm just easily entertained.] Subj: how BlockMove works 89-03-15 04:41:56 EST From: Dave Lyons Well, I tried it, and it worked as expected. I did a BlockMove from $06FF00 to $06FF80, length = $018000, and it did the following MVP calls: $0808, 0708, 0707, 0707, 0607, 0606. It built and called them one at a time, in that order. Subj: Napping or Versions? 89-03-15 14:57:15 EST From: MikeW50 Well, I'm glad to see it doing the move that way, whether it is a recent change or not. If I ever get energetic, I may have to do some benchmarks comparing the memory manager calls to the subroutine I use for block moves. By the way, Dave, if you want to stay sane, keep away from SANE. ;) Mike Westerfield Subj: Object Module Format 88-06-19 00:12:41 EST From: AFA Gary J Msgs: 4 (88-06-19) Can anyone tell me if PIF (permanant initialization files) and TIF (temporary initialization files) should be created in Object Module Format like regular ProDOS 16 applications? (I assume so, but need to be sure!) Subj: Re: Object Module Format 88-06-19 10:30:12 EST From: AFL Jim According to The Programmer's Introduction to the Apple IIGS (Addison-Wesley Publishing, page 266), Temporary Initialization Files (TIF, type $B7) and Permanent Initialization Files (PIF, type $B6) are loaded and executed just like IIGS applications except they must end with an RTL instead of a ProDOS QUIT call. TIF files are removed from memory after they're run. PIF files are not removed from memory, they must not be in special memory and they can't permanently allocate any direct bank/stack space. Both types of files are run automatically at system startup before any other applications if they're in the SYSTEM.SETUP subdirectory. I guess that means they should be written, compiled and linked just like applications. Subj: Permanent init files 88-06-19 20:26:51 EST From: Mensch72 PIF's are indeed just like applications except there are a few rules. First, yes, since the system loader loads them, they need to be in OMF . Second, they can use tools, as long as they shut down anything they start up. Third, they can not allocate any direct page storage unless they throw it away before the RTL. Most important, permanent init files can never be loaded into banks $00,$01,$e0,$e1 nor can they leave any space allocated in those blocks ( except for master pointers ). Also, if you are going to create a permanent init file, you are most likely going to use interupts, ( to call you program in memory ) if that is the case, you may want to brush up on what you can and can't do during an interupt. Jim Subj: Re: Object Module Format 88-06-19 23:57:26 EST From: AFA Gary J Thanks for the info! I have created a TIF file that works, so I must have done it right! Thanks for the help. Gary Subj: Directory Limitations - 3.5 Dsk 88-12-03 12:32:48 EST From: MicR Msgs: 8 (88-12-06) I just replaced my IIc wih a IIc Plus and it has a 3.5 Drive. I"m trying to consolidate many 5.25 disk files (many of which are small) to a 3.5 disk. Ive used 300 blocks (lots left) - but I cant believe it - the OS only supports 51 directory entries - this is a ridiculous limitation for these diskettes. I would use subdirectories (which might solve te problem) but a lot of software does not use subdrectories well. I dont even know if Appleworks does? Are there any patches to make directories larger or better ways????? Thanks ahead of time... Mic Subj: Re: Directory Limitations-ProDOS 88-12-03 13:39:02 EST From: BCS Al To be more accurate, this is a limitation of ProDOS, not a 3.5" disk as you imply in the subject heading. Any way, you should be using sub-directories, period. If you could put 100's of files into the root directory, we'd be back in the DOS 3.3 days. Good use of subdirectories will make your life much easier, believe me. Being able to group like files together makes finding files easier and faster than if you had dozens of of files in the root directory. If AppleWorks is your main application, I would suggest getting PathFinder from JEM Software. This AppleWorks patch allows AppleWorks to cruise through subdirectories. It's a great program. Subj: ProDOS root directory size limit 88-12-03 13:39:40 EST From: Dave Lyons Subdirectories are by far the best way around the 51-file limit for the main directory of a ProDOS disk. Subdirectories are limited in size only by available disk space. It's true that some software doesn't make it convenient to use subdirectories; that's unfortunate. AppleWorks makes you type pathnames rather than selecting subdirectories from a list, which is yucky but not too time-consuming once you practice it a bit. Note that AppleWorks doesn't deal with large directories well, either! I don't remember the limit (it depends on what version & what patches you have), but once you exceed it AppleWorks will typically print some garbage on the screen and HANG just after seeming to load a new file with no problems. Now, there _is_ a utility around ALPE somewhere [may have been in top 10; can't remember for sure] called VDE--Volume Directory Expander. However--as far as I can tell, the author never tested it with ProDOS 8. While it does successfully add more blocks onto the main directory and link them so that ProDOS can use the extra blocks, ProDOS 8 does _not_ let a program's CATALOG command read past the first 51 files! So VDE lets you put more than 51 files there, but you'll never see the extra ones in a catalog listing unless you're using the disk on an Apple IIgs running GS/OS instead of ProDOS 8. --Dave Lyon Subj: Re: Directory Limitations - 3.5 88-12-04 13:33:40 EST From: CecilFret There is no way to extend the 51 file limit. Use subdirectories. I don't agree the 51 limit is ridiculous. I rarely exceed the 51 limit before running out of data space. Compared to 51 on ProDOS to 120 something on DOS 3.3, 51 does seem small. Even the so-called great blue machine called the PC has limits on its root directory entries. Providing more entries chews up disk space and under a very large majority of conditions will be wasted because you will fill the disk with information before you run out of directory space. Fortunately, if you go to subdirectories, there is no limit to the number of entries. Granted it would be a pain but create a subdirectory the same name as your disk. Then you can load this subdirectory up to your heart's content. Subj: Re: Directory Limitations - 3.5 88-12-04 20:20:05 EST From: JSchober Righto, Cecil. Besides, you probably can't put more than 51 decent sized applications on a 3.5" disk... and if you're storing data files instead of applications, just create a subdirectory called DATA or something... Even when you start using a hard disk, you'd think the limit would cause you problems, but it doesn't... you simply put NO application files in the root directory. On my hard disk, for example, I have in the root directory PRODOS, PROSEL, PROSEL.SYSTEM, PRODOS16, the FINDER.xxxxx files, followed by 37 subdirectories. Works great! :) --Joe Subj: Re: Directory Limitations - 3.5 88-12-04 21:16:02 EST From: RTAFT All you really need for the //c+ to boot properly is ProDOS, and a SYSTEM file in the main directory. The rest of the disk can be one large subdirectory. That's what I did with this software I'm using now. There is no limit to the size of your subdirectory...except the size of your disk. Rick Taft Subj: Re: Directory Limitations - 3.5 88-12-06 21:23:29 EST From: DennisDoms I tried the "add volume directory blocks" trick several years ago; as I recall, I quickly ran into problems with several programs that expected (at most) 4 volume directory blocks, including BASIC.SYSTEM... One note about putting all files in one subdirectory: the subdirectory is (usually) managed as a sequential list, and that means if you try to access a file at the end of the list it takes the OS longer to find it than one at the beginning. If you want to see the effect, try a program like: 10 D$=CHR$(4) 15 ?D$;"CREATE A" 20 FOR I = 1 TO 200 30 PRINT "Saving file #";I 40 PRINT D$;"SAVE A/FILE.";I 50 NEXT I and see how the program slows as it approaches the 200th file. (Then you write the program to DELETE all the useless files .) Many disk utilities may have a "file buffer" limit for managing subdirectory entries, too. A notable example is AppleWorks, which only reaches (maybe) about the first 130 files it finds in the working directory. With more files (as with anything else) comes more responsibilities. Subj: deleting directories 88-12-06 23:11:42 EST From: Dave Lyons Actually you don't need to write a program to delete all the files out of a directory...if you're using Davex you can just "delete =", or you can delete the whole directory by name (it computes the total size of everything in the directory and asks for permission to delete it). Subj: Finding drives 88-12-21 20:44:53 EST From: Clayburn Msgs: 6 (89-01-02) Does anyone know how GS/OS recognizes the different types of drives. Clay Subj: DInfo and Volume calls 88-12-21 22:28:11 EST From: AFL Jim Clay, To get information about the types of devices connected to the IIGS system, you'd use the GS/OS DInfo call ($202C). This call returns the device name, characteristics of the device (such as if the media is removable, format allowed, etc.), the total blocks handled by the device, the slot number, the unit number within the slot, the version of the device driver, a device ID (which tells you if the drive is an Apple 5.25, ProFile 5Mb, SCSI, RAM Disk, ROM Disk , etc), some information on partitioned devices, and possibly some extended information. To find out about all the devices connected, you'd call DInfo starting with device 1, device 2, etc. until you get a parameter out of range error from GS/OS. Once you have all of the device names, you can make a GS/OS Volume call ($2008) with each device name to get the name of the volume mounted on each device. The Volume call is similar to the old ProDOS-8 Online call, but it requires the device name as its input and only returns information on one volume at a time. Chapter 5 of the GS/OS Reference, Volume 1 gives all of this information and more. Jim Luther Subj: Re: Finding drives 88-12-22 20:14:23 EST From: Clayburn Thanks Jim for the information Clay Subj: Re: Finding drives 89-01-01 19:36:09 EST From: Pbear2 HELP! I am trying to download the ACU I get to downloading the ACU folder (GS version) and the prefix will not set. I have called A-link and I have not gotten any help that works. I have followed all instructions and I get no where. How do I get this program on my 5.25 formatted disk? Subj: Re: Finding drives 89-01-02 02:08:41 EST From: ScottG25 Is your disk initialized in Prodos format? If so, just hit RETURN when selecting the prefix from a file information block. As I recall, the button didn't work in my GS version, either. Subj: ACU Online Support 89-01-02 15:25:38 EST From: AFL Jim ACU is supported online in the Apple II Utilities Forum. Floyd Zink, ACU's author is the Forum Leader for that forum. Use the keyword, AUT, to get there quickly (press open-apple-K, then type AUT and return). Jim Subj: GS/OS FST Files (Creating) 88-12-30 03:35:27 EST From: LanTech1 Msgs: 7 (89-01-29) I was wondering if anyone had any information on how to create a GS/OS FST file..... I am interested in creating a few operating system files, yet I have no Idea where I can find any information on creating them. Subj: Re: GS/OS FST Files (Creating) 88-12-30 10:21:13 EST From: AFL Jim I doubt you'll find the information you'd need to write one because Apple has stated that they won't be publishing FST specs. Apple wants to have control of writing all FSTs. Subj: Re: GS/OS FST Files (Creating) 88-12-30 19:56:30 EST From: SamT2 Volume 2 of the GS/OS Reference is supposed to have info on FSTs. Subj: Re: GS/OS FST Files (Creating) 88-12-30 22:58:39 EST From: Dave Lyons Is it? Last I heard, Apple was _not_ going to release enough info to actually write an FST: the reason is that they don't want to guarantee all the things about GS/OS itself that FSTs need to know. In other words, new versions of all FSTs may need to be released with each new version of GS/OS, as I understand it. (At least, this is my interpretation of what Steve Glass said at an ADV chat a couple months ago. I don't remember his actual words--but somebody could dig up the transcript easily enough....) Subj: Re: GS/OS FST Files (Creating) 89-01-01 16:59:12 EST From: AFA Parik They're going to release information on FSTs in that what comes OUt of them (Option lists, etc) but not information on writing them. I did get a basic idea however of what FSTs are generally made up of, if you are REALLY determined to write one, a good start would be sourcing out the character FST (very small), you can see the basic format. Of course, anything you write may or may not work, and Apple will definitely frown on and curse you...:) Subj: Re: GS/OS FST Files (Creating) 89-01-27 03:44:01 EST From: AndyBoy1 Some thoughts & notes: We aren't publishing 'how to write FST's' for a number of reasons. FST's are -very- complex and although they are separately loaded modules, they are really very integrated pieces of GS/OS. As mentioned before, FST's can and will change from one system disk to the next (better and better, of course!) Also, we take measure in the responsibility of writing FST's. They are crucial to data integrity, and we are very concerned about this issue. No FST goes out the door without rigorous testing. (I know, Pro.FST has a 31st day problem) BTW: GS/OS Ref, Vol 2, is how to write drivers. We do support and encourage 3rd party drivers, because GS/OS has many features (like caching) which, when used by the drivers, can greatly increase IO speed. --Andy Stadler Apple II System Software Subj: Re: GS/OS FST Files (Creating) 89-01-29 23:05:28 EST From: Matt DTS Andy's got it, natch. You need more proof that OS integrity is at stake? Consider what would happen if six people all wrote DOS 3.3 FSTs, each handling GS/OS extended characteristics in a different way, and then Apple tried to release one. Whose would it work with, if any? There's a very big opportunity for people to make the OS almost unusable that way which we're trying to avoid, on top of all the other more technical reasons which are equally valid. --Matt Subj: requesting ProDOS filetypes 89-01-09 21:59:00 EST From: Dave Lyons Msgs: 4 (89-06-20) Someone not on ALPE asked me how to request a ProDOS filetype; the address to write to may have been posted here before, but I don't see it. Subj: Re: requesting ProDOS filetypes 89-01-10 00:59:11 EST From: AFL Jim To request a filetype and auxtype, you should write to: Apple II Developer Technical Support 20525 Mariani Avenue Mail-stop 51-T Cupertino, CA 95014 Attn: Apple II Filetype Registration Subj: Re: requesting ProDOS filetypes 89-01-29 23:17:42 EST From: Matt DTS Yes, that's it exactly. Please, PLEASE folks don't send me mail on here requesting filetypes. I use ALPE from home, and don't have the filetypes database here, nor any way to assure that your email will ever get answered at all. Please send in that letter, or use AppleLink Apple Edition or MCI Mail to "AIIDTS" for filetype requests, and I'll be happy to fill 'em if possible. --Matt Subj: New address for Apple II DTS 89-06-20 22:41:48 EST From: Dave Lyons We're moving to new building effective next Tuesday, June 27, 1989, so here's the new address (only the mail stop is different). To request a ProDOS filetype/auxiliary type assignment, write to: Apple II Developer Technical Support 20525 Mariani Avenue, MS: 75-3A Cupertino, CA 95014 ATTN: Apple II Filetype Registration Be sure to explain what the files will be used for so DTS can assign an appropriate filetype. See About Apple II File Type Notes in the software library for more information. --Dave Lyons, Apple II Developer Technical Support Subj: GS/OS Formating Call 89-02-08 21:35:09 EST From: JimLaz Msgs: 7 (89-02-13) Help, being that I'm still holding off buying the beta version of the GS/OS ref vol 1, I need to know how to format a disk in ProDOS 4:1 and 2:1 interlieves. The call format and any other information needed would be most apprieciated. JimLaz Subj: Re: GS/OS Formating Call 89-02-09 01:36:46 EST From: AFL Jim Jim, I can't really type in all the information you'll need to make the GS/OS Format call here. Besides knowing how to make the Format call, you'd need to know how to make the GS/OS DInfo call so you can find the device name of the device to be formatted. I suggest you go ahead and get the GS/OS Reference manual in beta format if you need to make GS/OS calls. In the meantime, the ProDOS 16 Format call should take care of you. Jim Luther Subj: fmt-ing w/ different interleaves 89-02-09 19:22:46 EST From: Dave Lyons Yup, just do a regular old ProDOS 16 formatting call, and the user will get a dialog asking for the file system and interlave desired. Subj: Re: GS/OS Formating Call 89-02-09 22:20:08 EST From: JimLaz Okay, that's what I did and was surprised by the dialog box! So now I only have to tell the user which interlieve <--whatever to use. Still would be nice to do it without making the user do anything (the program I'm working on is for very novice users). JimLaz P.S. I'm even more against getting the beta draft now since they upped the price $10 since Apple took over APDA. I ordered Gary B Little's GS/OS book in hoping it'll suffice until the final reference manuals come out. Subj: Re: GS/OS Formating Call 89-02-10 02:14:35 EST From: Dave Lyons As far as I know, there is no way for a program to do a format and specify the interleave. You _can_ specify the file system for the format (I assume it has to correspond to an FST installed in the system). In that case there is on user interaction, and the _default_ interleave is used. (Right?) Subj: Re: GS/OS Formating Call 89-02-11 01:56:05 EST From: Matt DTS Right. I think. It's been a while since I looked into this (like "before GS/OS was released"), but I know you can use a device specific control code to "GetFormatOptions". You may be able to "SetFormatOptions" to set the default interleave used when you specify the "requested_filesysid" in the Format call. But I'll have to go read my draft of Volume 2 to find out for sure, and that's surely not what JimLaz wanted (to have to buy TWO beta drafts, one which isn't quite there but almost is any minute now). --Matt Subj: Re: GS/OS Formating Call 89-02-13 16:16:58 EST From: MikeW50 Actually, a program _can_ specify the interleave. The version of ORCA we are working on now has a flag to do that. Mike Westerfield Subj: Ques. about GS/OS & P16 loader 89-02-11 18:06:47 EST From: BrianG19 Msgs: 37 (89-03-10) Can somebody answer this question?: I am using Merlin 8/16 to write a rather long GS application. The relocatable object file that is created by Merlin is divided into 2 segments which are both about 30K long. My problem is that every once and a while, when the Loader loads the program, it puts the two segments in different banks and the program crashes, because all my subroutines are called with JSR, not JSL. Is there any way to tell the loader to load the whole thing into the same bank? (i.e use the "kind" field?) I do not have any of the bit settings for the "kind" or other fields, so I dont know what is and is not possible. Help.... -Brian Greenstone (BrianG19) Subj: Re: Ques. about GS/OS & P16 load 89-02-11 21:29:56 EST From: Dave HDS First of all, programs should never be designed to load in specific banks. Bank allocation will always be different on different machines (everyone will have different D/A's in memory, etc). The memory manager may also need to move blocks into different banks as needed, so it's quite possible that a given bank will not always prove to be free even on an individuals system depending on what has been executed and what it did. GS/OS will also allocate memory as files are opened wherever memory is available for work buffers. All 65816 code is bank aligned. This means that it doesn't really directly need to know or care what bank it happened to have been loaded and is now executing in. The system loader will find whatever bank happens to have enough free space to hold each segment and place it there (relocating your code within the bank as needed since in many cases only part of a bank may actually be available). When you have code that is broken down into multiple segments, the system loader places each segment into it's own bank and then modifies any calls (JSL's) so that they now point to the correct routine in the far bank. In some cases, if the segments are small enough, and there is a large enough space in a single bank, all the segments of a given program may find themselves in the same bank, but one should never, ever count on this. I am not too familair with Merlin/16 and the Extended Linker they provide for constructing large model (multi load segment) code, but I suspect your problem are those jsr's you are using for calling code in the second segment. This would of course ONLY work if both segments were loaded together in the same bank. I would suggest reviewing how Merlin constructs multisegment load files and how you should be coding external references to routines and data structures that will exist in a different segment. You may not only need to be using JSL's for your calls, but also xxxL instructions if you refer to any data held in onther segments or load the data bank register with the bank address of your other segment from the bank address (high word) of an external label that is in that other segment and then refer to it directly. You can then do a PHK PLB sequence to restore the bank register to your current segment when you need to access data that is part of the first segment. I remember hearing from people at Apple Developer Services that more mistakes and errors are reported to them by people incorrectly constructing and accessing data/routines in multi-segment applications than all other problems combined, so your certainly not alone... Dave Subj: Re: Ques. about GS/OS & P16 load 89-02-12 11:45:17 EST From: BrianG19 But Im not making the code "bank specific" its just that the entire program is VERY modularized and each segment needs to call routines in the other segment, but the code is very "time" dependant, and I dont have the cycles to waste by doing JSL's and then having to set the data bank for each call and then resetting it upon return. There's a big difference between: JSR xxxx xxx rts and JSL xxxxxx xxxxxx phd phk pld pld rts I need the time, really, so is there any way to make the loader load both segments into the same bank? It usually does it, but once and a while it uses 2 banks. Also, when I do a PHK, does it push 3 or 4 bytes on the stack. Same with JSL, 3 or 4? -Brian Subj: multi-segment applications 89-02-12 17:35:13 EST From: Dave Lyons PHK pushes ONE byte onto the stack. That was the easiest answer. The only acceptable way to get two segments to load into one bank is to NOT HAVE TWO SEGMENTS. Put the code from both into a SINGLE segment, and that segment will load into the same bank as itself. :) I'm not familiar with the Merlin linker, but I'm very surprised it _lets_ you JSR into another segment; the APW/ORCA linker complains at that point. It is _not_ necessary to always change the B register when you call a subroutine in another segment. Consider putting your data all in ONE segment; I don't know how Merlin handles, this but in APW/ORCA you can have lots of separate PRIVATE DATA segments w/ the same "load name" (?) and the linker will put them all together. It's slick. You could leave B pointing at that the whole time. Subj: Re: Ques. about GS/OS & P16 load 89-02-12 20:30:41 EST From: Dave HDS The problem with the Merlin Linker, Dave, is that it only links in 8 bit mode. The object files it used are in Merlin's form of old Apple REL. This means that when you code calls to external routines (labels labeled as external), Merlin DOES NOT at assembly time know if those labels are for routines that will be linked together in a single segment or if they are for routines that will reside in a seperate segment. The Merlin Linker, from I recall, allows you to specify which Merlin LNK code modules will be in which segments, so you can put two or more object files into the first segment and then specify more in additional segments as well. The Merlin Linker has one limitation it inherits from Apple's REL format, however: It cannot construct a single program (in 8 bit mode) or program segment (for multisegment OML's) that is larger than 32K. In regards to Brian's original problem; I could only suggest that you try putting all your timming criticle routines as well as all the routines that directly call them into one segment and the remainder of your program (and possibly all common variables/data storage workspace) into that second segment. Putting all your data in a single segment means you only need to set the data bank register once when your program is started and can then leave it alone. Dave Subj: Re: Ques. about GS/OS & P16 load 89-02-13 16:14:01 EST From: MikeW50 It might also be worth considering a switch to ORCA or APW, which would prevent all of these problems. First, you can create single segments up to 64K in length. Second, and perhaps more important, ORCA or APW would have told you that your program had an error, since they DO keep track of what segment labels are in, and issue a warning if you try to access a label in another bank using absolute addressing. Mike Westerfield Subj: What I did 89-02-13 20:17:05 EST From: BrianG19 Well, Merlin 8/16's Linker.XL only allows ~32K segments, so I couldnt merge it into one, and the program is too modularized to put "timing critical" routines into the external segment, so what I did was to simply use JSL's and accept the timing loss. It was a bitch! I spent 8 straight hours modifying 20,000 lines of code and testing it, but it was worth it, b/c the program works w/o a glitch now. No bugs whatsoever. I would have switched to APW, but 20,000 lines of incompatible code is not a good idea, and Merlin 8/16 is really a much better system as long as you plan on using only 65816 and not C shells or the like. -Brian Subj: "No bugs whatsoever" :-) 89-02-13 21:44:09 EST From: Dave Lyons "No bugs whatsoever" is a dangerous belief! It's much safer to believe that there lots of bugs you haven't found. Be sure to force all your segments to load into _different_ banks and check that things don't get trashed in the wrong bank. I had a program with "no bugs" for several months, and one day a little segment I didn't realize I even had got loaded into a different bank from the stuff I _intended_ to have in the same segment, and the system went south quickly. In other cases, I've had programs fail to set the B register & _work_ most of the time, just because the data getting trashed (at the right address in the wrong bank) didn't happen to be anything critical. Another kind of bug is one that will make your program incompatible with future system software. To find those you need to understand all the rules and the assumptions your program makes. Again, the point is that "no bugs" is not something you can determine through _testing_ alone. Subj: Re: Ques. about GS/OS & P16 load 89-02-20 15:28:31 EST From: AFA Parik I've got a question (not related to this one in any way :), sometimes when I run programs that are being tested or in the middle of being written (ie, BUGGGY!!!) they do something to memory which disconnects my hard drives [CMS SD60s connected to CMS SCSI card]. I do a option-OA-control-esc-shift-reset, it goes into self test mode, I do a oa-cntrl-reset and get back into Orca. When I do a SHOW UNITS, or a CAT /CMS or whatever, the volume doesn't exist! Slot 7 & 6 just "disconnected" themselves. My question is WHY? If i turn off the computer and turn it back on, everything is FINE. But I thought going into self test mode is the same thing! What could my programs be doing that would just disconnect the firmware until powerdown... Subj: disappearing SCSI devices 89-02-20 21:54:20 EST From: Dave Lyons Parik, first of all the "real" self test keystroke combination is Apple-Option-Ctrl-Reset. No need for Shift or ESC. If the CMS SCSI card is like the Apple SCSI card, there's RAM on the card that gets initialized at power up. If a program runs amok and trashes something there, doing a self test isn't enough: the card has no way to know you did a self test. Subj: Re:Lost Drives 89-02-21 03:36:41 EST From: Mark TMM Also if the program flips the wrong softswitches it may turn off access to peripheral card ROM space. I just now thoght of this because the same thing has happened to me. I would think that your reset routine should work but it didn't for me. Writing to $e0/c006 should turn on card rom access as opposed to internal rom. I have not tried this yet but will the next time it occurs. Subj: losing drives--softswitches 89-02-21 19:51:04 EST From: Dave Lyons Well, the softswitches should all be reset during an Apple-Ctrl-Reset. That shouldn't be a problem unless your Battery RAM settings have been wiped out. Subj: Re: Ques. about GS/OS & P16 load 89-02-22 01:20:05 EST From: AFA Parik It would seem like the softswitches, but I tried that already before and no go. I thought perhaps writing something to the CMS firmware would mess it up. I can tell its doing SOMETHING to the firmware because you hear the mysterious *click*....($E0C030 :) A reallllly FUNNY thing happened to me a few days ago. I have two 5.25" hooked up to a old DISK II card in slot 5. Usually I have my 3.5" drives shown as existing in slot 5, when I need to use my 5.25"s I just switch slot 5 to YOUR CARD. Well, when I was testing out a program I wrote it trashed memory, rebooted, but turned on the 5.25"s obviously using the $C0Ex routines! WOW! I was amazed. hehe. The chances of my program switching out the slot allocations are really astonishing, aren't they... buggy code that does neat things. hehe (don't you HATE it when your buggy code starts screwing with the $C0Ex areas and messes up your entire 5.25" disk? I used to loathe that.) Subj: buggy progs & slot settings 89-02-22 01:41:39 EST From: Dave Lyons It's not all that amazing...all your program has to do is store a random value over $C02D and you can swap all the slots in/out at random. Block moves that get out of control are a good way to do that. Subj: Re: Ques. about GS/OS & P16 load 89-02-25 11:34:42 EST From: ShrinkIt what i want to know is why: I have a CMS sd60 HD, and it's setup so that both the /A and /B paritions are 30 meg (I think they can be set at 32 meg and 30 for a total of 62.. Parik?) -- I found out the other day that If I read something like block $F000 with Block Warden, it read block $0000 from the _second_ paritition. What's worse, is that if I change something and write back to a block after $F000, _it lets me do it!! Something really strange is going on, because then theoretically if you had a disaster on the first half of my hard drive, and it jus happened to tell prodos that it had more than 30 meg worth of blocks, and something pointed above $F000 to write... kiss the second volume goodbye as well. _I don't like this at all_ Someone want to send me a tape backup unit so I can set the first paritition at 32 meg, reformat it and restore it without taking an entire day to do? andy Subj: overflow into next partition 89-02-25 13:51:10 EST From: Dave Lyons Andy, you didn't mention what interface card you're using, but I suspect it's _not_ an Apple SCSI card, since I don't know of any bug with the Apple card that would make that happen. It's the responsibility of the firmware on the interface card to translate ProDOS read-block and write-block requests into SCSI read-block requests to the drive. Basically it just needs to add the ProDOS block number onto the SCSI block number of the first block in the partition. If it doesn't bother checking the ProDOS block number against the number of blocks in that partition, well.... Early revisions of the Sider controller firmware would let ProDOS block operations overflow into the Pascal partition, I think. Subj: Re: Ques. about GS/OS & P16 load 89-02-25 20:13:58 EST From: AFA Parik You've got a pin set funny on the CMS card Andy... I have all mine set at 30/30, here, let me check what happens... Ok, can't read past $EFFF. Now, one of my friends has it set at 32/30, but he has a Apple SCSI card I believe! He's filled up the drive a couple of times (hehe, on a BBS, once had 3 blocks free...) and never had any problems. You CAN set the CMS SCSI card to have 32 megs and 30 megabytes, but I don't think its recommended. Do you have your manuals still? Try backing up whatever you have, resetting it to 30 [its those #$*#$ jumper blocks on the card you need to reset] partitions. You should have no problems then. Subj: Re: Ques. about GS/OS & P16 load 89-02-26 17:14:57 EST From: ShrinkIt I have the CMS card, and I _do_ have the pins set correctly, and it _still_ lets me write beyond $efff. bad. very bad. Is there a new rom out for the cms? andy Subj: Re: Ques. about GS/OS & P16 load 89-02-27 20:24:28 EST From: AFA Parik You can tell you have the newest by the CMS card automatically waiting for powerup. ie, you don't have to let your hard drive warm up and then turn on the computer (or reset it); the CMS card itself recognizes the hard drive isn't warmed up and goes into a loop, and *THEN* boots up. Another question: Does GS/OS Ref Vol #2 contains System Loader info? Has the System Loader Tools been updated for GS/OS calls? Will it be? I remember reading the Loader was rewritten (?) under GS/OS, any more info on this... Subj: Loader under GS/OS 89-02-27 20:39:57 EST From: Dave Lyons Hmmm...I could have sworn the info was in volume I, but I can't find it. It must be in volume 2, which I've ordered from APDA but haven't received yet. The only additions are a couple of calls for dealing with class 1 pathnames: GetUserID2 and LGetPathname2. Oddly, it doesn't look like there's an InitialLoad2. Oh, well. There's also a RenamePathname call--I don't remember exactly when that was added but it lets the loader stay up-to-date with the new names of files it cares about (things that are in zombie state, for example). Subj: The KIND directive 89-03-04 14:25:47 EST From: AFA Parik In one of my programs I have a loader segment that does a _InitialLoad and loads the rest of the program up (I do it this way so I can have a special f/x going on while the program is loading). Since I use shadowed graphics, nothing can load into bank $01. The loader segment tells the loader NOT to allow the rest of the program to load into special memory. The problem is the loader segment! So far I've been using a ORG to get it to bank $07, however, I'd like to allow it to be anywhere EXCEPT special memory. As the program nears wraps, I've been reading my APW & Orca books on the KIND fields. Technote #52 helped a little, but didn't say HOW to set the bit in the KIND directive! Ok, flipping through APW I found that bit 12 sets special memory of the KIND field. So my program should be KIND $0D00, its: Code Segment type ($00, low byte) Reload segment (bit 10) CANNOT be loaded into special memory (bit 12) Position independent (bit 13) That all matches up to KIND $0D00. So I do a absaddr on keep boot.sys16 mcopy b.macs BOOTER START KIND $0D00 PHK PLB ... [program goes here] END Well, when I run the program, it hangs. I then did a BRK $00 RIGHT after the PHK/PLB and I find out the program has loaded into bank $01. I must be doing something wrong! I'm linking & running this under Orca/M v1. Subj: segment KINDs in OMF 1 and 2 89-03-04 15:14:16 EST From: Dave Lyons Setting bit 12 of the KIND field gives you $1000, not $0D00. (See page 296 of the ProDOS 16 Reference.) In an OMF 2.0 file (one that has been COMPACTed, for example) a no-special-memory static code initialization segment would have KIND $1010. In OMF 1.0, there is no no-special-memory attribute, and KIND fields are only one byte long. If you're using the APW or ORCA linkers, which don't know about OMF 2.0, you'll need to COMPACT your load file and _then_ change the KIND field in your load segment. There's a utility in the library by Doug Davies that will do this for you nicely: ADV: Libraries: Applications and Utilities: Change OMF KIND fields. Subj: Re: Ques. about GS/OS & P16 load 89-03-04 20:42:07 EST From: AFA Parik Ok, thanks for filling me in on that. BTW, it is $0D00 because I want my segment non-restartable and not in a fixed area. $1000 would JUST be non-special memory. A compacting we will go...:0 Subj: segment KINDs 89-03-05 01:50:25 EST From: Dave Lyons Parik, I still don't like KIND $0D00...that's bits 11, 10, and 8 set. 11 is Absolute-bank, 10 is Reload, and 8 is a reserved bit. Add up the following values to get a correct OMF 2 KIND field: Choose *one* of: $00=code segment $01=data segment $02=jump table segment $04=pathname segment $08=init segment $12=direct-page/stack segment And add any or all of the following: $8000 for dynamic (otherwise static) $4000 for private (otherwise public) $2000 for position-independent (tricky; don't do it unless you know what you're doing) $1000 = not permitted to load in special memory $0800 = absolute-bank $0400 = reload this segment whenever program is Restarted Subj: Re: Ques. about GS/OS & P16 load 89-03-05 10:04:40 EST From: AFA Parik This is weird. My APW reference, volume #2, page 8-10 says: 10 1 = reload segment 11 1 = absolute bank segment 12 0 = can be loaded in special memory 13 1 = position independent 14 1 = private 15 0 = static 1 = dynamic Is my reference wrong? Oh, this is v1.0.2 of APW BTW but I believe no changes were made anyways... Subj: Whoops 89-03-05 10:50:03 EST From: AFA Parik Never mind, my mind was clicking that 7 was 10... Subj: Re: Ques. about GS/OS & P16 load 89-03-06 00:05:24 EST From: AndyBoy1 Are you sure you want the position independent bit? Remember, that bit doesn't mean "put me anywhere", it means "don't relocate me". --Andy Subj: position independence 89-03-06 19:42:11 EST From: Dave Lyons Andy, what that for me ("Are you sure about the position independent bit?")? I was recommending leaving it off, since code segments should not be moved once they're loaded. The only time it's useful is when you want your code loaded up in the high end of RAM (with most of the non-fixed blocks), and even then I'm not sure if I see why that's useful. The Finder does it. One of the first things it does is find its own handle and Lock and/or Fix it so it won't move. I think this was useful before OMF 2 was designed, but now-a-days it seems like it would be better for it to just set the no-special-memory bit to avoid getting loaded into bank 1. (On the other hand, it wouldn't load there anyway, presently, since there's only $B800 of space available in bank 1, and the Finder's code segment is $DFxx long, I think.) Subj: Re: Ques. about GS/OS & P16 load 89-03-06 20:23:41 EST From: AFA Parik The boot segment I DON'T want position independant. The util segment (which contains disk access, animation, etc generic routines) I wouldn't mind having position independant. Does the loader modify the jump table if the program is moved in memory? My program is accessed through a JSL with the A register containing the operation to execute. ALL data is containing in a DATA segment and the data register is always set to this data segment. If the position independant segment was moved during the program execution, would I have to worry about the JSL to it? Subj: position independence 89-03-07 21:36:12 EST From: Dave Lyons Parik, I don't think you _really_ want your code marked position-independent. Writing 65816 code that still works when its image is copied to a new address is not at all an easy thing to do. The Finder uses it only as a trick to get the Loader to put it in high RAM instead of low RAM; the code is never allowed to actually move (the Finder locks its own handle right away). I don't know what the system does, if anything, to support position-independent code. I doubt that _static_ position-independent segments get any special treatment, but dynamic ones could (it would make sense for it to be locked while it was loaded, unlocked while it was unloaded; while unloaded (purgable), it could move around, and references to it could be computed based on the new position when it was loaded again). If any support like that exists, I doubt that it's been tested too well. Subj: Re: Ques. about GS/OS & P16 load 89-03-08 20:54:04 EST From: Dave HDS I'm sure it will get 'tested' the first time someone comes along and tries it...heh...as to writing 'movable' code, it is feasible...you could use PER's to push pointers to data areas on the stack and use some of the 65816's S indirect and S indexed stuff (or even sicker, point D into the stack area and use DP addressing) to get at these pointers...JSR's could be simulated by first doing a PER retaddr-1 followed by a BRL to the actual routine...and there are probably even more sick and demented coding possibilities out there... Subj: position-independent code 89-03-09 02:42:12 EST From: Dave Lyons All true, but the code still has to be locked while it's running! Even using PERs, etc, the _stack_ will contain absolute return addresses...not to mention the program counter containing an absolute address. Subj: Position Independent 89-03-09 12:54:34 EST From: MikeW50 The position independent bit has one use I can think of. If you are creating a data area, and you can get the handle of it somehow before it is moved, you could mark it position independent so it could float when not in use. Position independent code on the 65816 is, well, stupid. It's very innefficient, and very dangerous to call and use. After all, if it is position independent, where is it? You have to use a handle, lock it down, and create a call using the stack or self-modifying code. If the program is small to start with, making it position independent doesn't buy you much. If it is large, it's going to be a lot larger if you make it position independent. Still, maybe some clever person will actually find a use for that bit someday. So far, I haven't seen one. Mike Westerfield Subj: Re: Ques. about GS/OS & P16 load 89-03-10 04:59:24 EST From: Dave HDS I think Mike hit the nail on the head...to create initialized relocatable data structures, as apposed to having to call MM to allocate a movable block, then lock it down long enough to initialize it. In regards to relocatable code, my comments were in part tongue-in-cheek, and yes, as DL points out, you couldn't dare relocate the code segment WHILE it is executing, as the PER's are evaluated to fixed addresses that are put on the stack. However, you can create fairly complex routines that are not position dependent, and, while the code will be a little slower (perhaps 10%), and use a little more memory (6 bytes for the equiv. of a subroutine call for example), it does not require ANY OMF relocation records, and so may actually take less space on disk (in fact, you could abandom OML altogether and load such a code image directly anywhere in ram and get it to run if it's single segment, now is this a sick idea or what?). Subj: Re: Ques. about GS/OS & P16 load 89-03-10 17:45:55 EST From: AFA Parik I was thinking of position independant = relocatable probably... The segment I was misinterpreting :) anyways could easily be position independant, its top down code with only 7 "floatable" references (the rest are to fixed locations such as screen, etc), I could use the stack for the 7 variables and the rest is all position independant (uses branches instead of JSR/JSLing around.) But why would I want to...heh Subj: Re: Ques. about GS/OS & P16 load 89-03-10 20:07:51 EST From: Dave Lyons Parik, if you can avoid assuming that the screen has a fixed location, it would be better for future compatibility (look what happened in the Mac world). Dave S, I keep seeing you use the term "OML", but I haven't seen that documented anywhere. OMF is Object Module Format. What's OML? Subj: Re: Ques. about GS/OS & P16 load 89-03-10 21:04:06 EST From: Dave HDS I feel like I've stepped into the Twilight Code.... In regards to Dave Lyons and OML, I think that creaped into my vocabulary as the difference between OMF files that cannot be directly loaded by Pquit (including OBJ's which, do to unresolved symbol references, should not be loaded at all, RTL's, etc), and the EXE/S16 stuff... In regards to moving code while it is executing, this seems like shades of core wars...and on 'live' hardware yet (now, if only it could move while Nifty List was operating, we could drive DL bananas). Subj: GsOs, DInfo, & slotNum 89-03-01 21:30:57 EST From: Coach101 Msgs: 4 (89-03-02) In trying to establish a "GsOs state of mind" I am converting some "slot number" dialogs with the user to dialogs based on the results of GsOs _DInfo_ calls. While doing so I observed that the _slotNum_ returned by _DInfo_ returns slot numbers outside the range of 1 through 7. The GsOs manual indicates that the range of the _slotNum_ word is between 0 and 15 but gives no information on how to interpret the _new_ values. Having done _DInfo_ calls on all the devices in my system, it appears that _slotNum_ of 1-7 implies "internal II-GS firmware" and slot numbers of 9-15 implies "external, card, firmware". Kinda nice guys. Now, there is one abnormality and one question brought up by all of this. The _slotNum_ returned for the .CONSOLE device is $8003; what does that $8000 bit mean? Second, what conditions would cause me to see a slot number of 0 or 8 (i.e., internal/external slot 0) or will this never be returned? This may all be answered in Volume 2 of GsOs Reference, but my copy of that is presently on backorder at APDA. Subj: Re: GsOs, DInfo, & slotNum 89-03-01 22:37:06 EST From: DaviesDoug Coach All I could find in my GS/OS manuals was what you suspected. Bits 0 through 2 indicate the slot while bit 3 indicates that the slot is internal or external. I couldn't find anything that talked about the high bit ($8000). No idea what it could mean. Subj: Re: GsOs, DInfo, & slotNum 89-03-02 20:44:43 EST From: Matt DTS Not surprisingly, they let me have a GS/OS Volume 2 (I guess there ought to be *some* privileges to this job), so I can fill everyone in: As Doug said, bits 0-2 indicate the slot number, and bit 3 is set if the peripheral is a card in a slot and clear if it's a port in the internal firmware. This has the effect of making the ports have slot numbers 1-7 and the real physical slots have numbers 9-$F. Bit 15 of the slotNum word, if set, indicates that the driver is independent of the hardware for that slot, and that the driver does *not* need to access the peripheral card's I/O addresses. Having this bit clear means the slot/port must be enabled when the driver is called. And, as Coach guessed, this is all cleared up in GS/OS Reference, Volume 2. (Coach: Will you *please* stop calling it "GsOs"? There is no such thing. It's "GS/OS". I think it's fair to let the people who created it name it.) --Matt Subj: Re: GsOs --- Death Of A Friend 89-03-02 21:42:21 EST From: Coach101 Ok Matt.... XxXx looked prettier to me than GS/OS so I began using it as opposed to GS/OS (fewer keystrokes also) and GS/OS (see I did it) is such a pretty system. Subj: Formating Interleaves 89-03-08 21:45:04 EST From: JimLaz Msgs: 7 (89-03-14) Two questions, First, Is the ProDOS 8 4:1 Format exactly the same as the Macintosh 800k format (I know the directory structure is different). What I'm trying to do is read Mac disks block by block and save them in a file, then latter format a disk and copy the data back to the Mac disk (block by block). Second, anyone know the correct DControl parameters that would allow me to specify 2:1 and 4:1 ProDOS Interleves from the program, so as to not have the user have to enter it (I'm trying to make a fool proff program and this is the biggest porblem). JimLaz Subj: Re: Formating Interleaves 89-03-09 02:39:52 EST From: Dave Lyons Hmmm...first, Macintosh disks are normally formatted with 2:1 interleave, not 4:1. They also have some extra, unused bytes in each block, and there are device-specific SmartPort commands for setting up for a Mac format, I think. Don't remember what you do under GS/OS. I think Mike W said there was a way for the program to make the interleave choice, but I don't know what it is. (Possibly has something to do with SetFormatOptions?) Subj: Re: Formating Interleaves 89-03-09 12:45:13 EST From: MikeW50 The information you are about to read is probably wrong. It comes from draft 2, Volume 2 of the GS/OS manual. Draft 2 is not particularly stable, and the area that deals with interleaves is particularly confused. In any case, you set the interleave preference via a DControl ($202E) call to the disk to be formatted. It's not clear to me if the OS is not going to support changing the default interleave, and just put in the option in case they change their mind, or if the documentation is in error. In any case, there is a status list, and you set an interleave factor in the list. The format for the list given in the manual is clearly wrong, so I won't repeat it here. In other words, it looks like it should be possible, but we will have to wait until the documentation is stable or someone wants to sit on Matt long enough to get him to track down the details. Mike Westerfield Subj: Re: Formating Interleaves Mac 89-03-09 20:16:28 EST From: DougMac The mac uses the 2:1 interleave. The extra 'tag' bytes mentioned by Dave Lyons are no longer used, so ignore them. (they used to be used for disk recovery programs, but hard drive usually only have 512 bytes blocks so they dropped the tag bytes). You can do all the work you need to do with just gsos calls. You don't even need to go to the smartport commands. Just issue a ReadBlock gs/os call (or prodos call same thing). Just do a loop to read in the block and write it out to the file, and continue up all the way. You can also use any prodos disk packer that you want to on the IIGS world, and the disk will be just the same, as long as it is formatted for 2:1 interleave when you unpack it. I suggest using Shrinkit for you application, as it does exactly what you wnat to do, and offeres LZW compression on the files you produce.. Subj: Re: Formating Interleaves 89-03-10 04:46:49 EST From: Dave HDS I recall that after Apple realized that most Scsi disk makers were unwilling to make drives that supported the ?540? byte blocks, and after a round of early Scsi mac drivers that attempted to split Mac blocks around multiple 512 byte blocks, they eventually gave up support for this anacronism entirely, although I take it the Mac floppy formatter still writes the larger blocks even though it's not using the extra space... I don't follow Mac stuff too closely, so I may be wrong on this... Dave Subj: Re: Formating Interleaves 89-03-13 01:18:53 EST From: Matt DTS Oh, this stuff gives me a headache. I should have been a music major. Mike is right - if any of you accidentally come across a copy of Draft 2, Volume 2 of GS/OS Reference, please ignore it with all your strength. The APDA draft (shipping this week, supposedly) is Draft 3 and fixes nearly everything. Basically, to format a disk with your (programmer's) choice of interleave, you: 1. Do a DStatus GetFormatOptions subcall, which returns a list of all the formatting options for the device, including options which exist but are not displayed when a Format call's dialog box is enabled. 2. Issue a DControl SetFormatOptions subcall, picking the option you want to use. 3. Issue a DControl FormatDevice subcall to format the media. This doesn't tie the media to any file system, so there's no directory or anything else on it. I *believe* that to put a directory on the disk, the best (and maybe only) way is to: 4. Issue an EraseDisk call. Although a dialog will be put up asking for file system (unless you give a req_file_sys_id), the format of the media will not be changed. I haven't actually tried #4, but it should work that way. The reasons I don't post all the parameters for everything are 1) they're long and I'm lazy, and 2) anyone doing this level of work needs Volume 2 anyway. This stuff is on page 45 or thereabouts. --Matt Subj: Re: Mac drives.. 89-03-14 21:34:56 EST From: DougMac Actually the hfs formatting software doesn't put 524 byte blocks onto disks, it is the low level stuff that does. It also exists on the IIGS formatting low level software.. So all of your IIGS 3.5" disks also hold 524 byte blocks. But it doesn't use the extra 12 bytes.. Gee I just love when Gary Little publishes stuff from the GS/OS reference manual (volume 2) before even the beta draft gets out of Apple.. Oh well... Apda says it should start shipping the 2nd volume on the 16th of March. Lets see if they do, or do they put the date back another 6 weeks? Subj: A Ques. about using GS/OS calls 89-03-27 12:15:49 EST From: AFL Dyfet Msgs: 6 (89-06-19) Subj: Prodos 16 89-03-23 23:47:55 est From: Frotz1 Msgs: 4 (89-03-26) I am currently working on a pascal program that requires storage of string and integer arrays in the same file. I currently have been able to read and write strings using p16 calls as established by TML's unit. Could anyone help me store integer arrays to disk. Also, is it possible to load a block at a time and then set the arrays to the values? Subj: Re: A Ques. about using GS/OS 89-03-27 12:16:35 EST From: AFL Dyfet Subj: reading and writing arrays 89-03-24 00:56:57 est From: Dave Lyons Reading and writing arrays with direct ProDOS 16 (or GS/OS) calls is no harder than doing it for strings. var xyz: array[1..1000] of integer; ... MyP16Parms.buffer := pointer(@xyz[1]); ... Or something like that. Fill in the other fields too, of course (length, like N*sizeof(integer) or whatever, and reference number). "Pointer" may not be the correct type--I didn't look. "Buffer" may not even be the right field name. The point is that you do the same thing you did for strings, & use "@" to find the starting address of your array. You said something about reading one block at a time--no need. You can read the whole thing in one swell foop. (A "foop," in this case, is a ProDOS 16 "READ" call.) [Be sure to fill in a reasonable value in the requestCount field for a read. Do NOT fill in something larger than the actual size of your array, since you'd overwrite important things if the file you were reading was longer than you expected, for whatever reason.] Subj: Re: A Ques. about using GS/OS ca 89-06-18 21:11:41 EST From: Frotz1 I need to know how to create a file from TML pascal with out going through the standard file toolbox. I have assigned the appropriate values and the file is created and exists on disk but then I can not open the file for writing data. Can I get the nessecary steps in creating a file Subj: Re: Pascal opens 89-06-19 20:22:01 EST From: TMH2 The correct method of creating and/or opening a disk file for writing in Pascal is by using the REWRITE procedure. Z^\GGGGGGGGGGGGGGGGGGG\_ Z R Z T. Mike Howeth II N Z Dallas, Texas N Z (TMH2) V Z B Q ZO WVWVWVWVWVWVWVWVP_ Subj: Re: A Ques. about using GS/OS ca 89-06-19 21:04:24 EST From: Frotz1 I understand that portion of creating files. However I am using the prodos calls directly in association with the p16paramblock record. This is where I wish to find out how to create a file from. Subj: Good Books for using GS/OS 89-06-19 22:28:14 EST From: Jump Long Frotz: I'd recommend two books, the GS/OS Reference (available from APDA) and Gary Little's book, Exploring Apple GS/OS and ProDOS 8. Gary's book is a nice tutorial to get you started. The GS/OS Reference is Apple's in-depth technical reference to the operating system. The GS/OS call, Create, lets you make a new file on a disk volume. You must tell the call what attributes (like file type and aux type) you want the new file to have. After you have created a file, you must use the Open call before you can access the file's contents. Once the file is open, you can read from the file or write to the file (this isn't a complete list of what you can do with an open file). When you're done accessing the file, you use the Close call to finsh writing the file and to release the operating systems file buffers for other program uses. Subj: WRITE - SETEOF - READ 89-05-23 00:34:13 EST From: Coach101 Msgs: 8 (89-07-30) I have run into a strange problem that I, so far, am unable to attribute to my program. I am doing operations to a file with a mixture of 80 byte writes and 2048 byte writes. What I am observing is: 1. Do a bunch of 80 byte writes (500) mixed with periodic 2048 byte writes (3). All writes are preceded with a SetMark call to make sure things are written in the correct spot in the file. The sequence ends with 80+ 80 byte writes. 2) Via SetMark move backwards in the file and write a 2048 byte record. 3) Using SetEOF extend the file 2048+ bytes beyond its current ending point (I forgot to mention above, that every time I I cross a 2048 byte boundary in the writes I issue a SetEOF to get the file extended). 4) Now, with SetMark/Read pairs go back and read the 4 2048 byte records that were written. The first three records come back correctly, the fourth record gets messed up. If you think of the fourth record as 4 blocks, then express the record as 1-2-3-4 (i.e., block-1, etc.), the material that is in the file is in reality 1-2-3-1. I mean precisely; right on the block boundary, bang back to block-1 of the record. I have used the GS/OS Exerciser to look at the file, and it concurs with what I am reading in my program. If I comment out the material that does the operation described in 3 above (the last SetEOF call), then the material I read back in and the material in the file is letter perfect! I tried adding a Flush call in front of the SetEOF but that did not help. Does anyone have any suggestions? This one is driving me buggy. Subj: A Little More Information 89-05-23 02:08:11 EST From: Coach101 I think I forgot to mention that the 2048 byte writes specify cache and the 80 byte writes specify noCache. I ran one test case with noCache both ways and I do not think it made a difference. I just spent some time with the APW debugger and verified that the contents of my buffer were correct before and after the WriteGS call. They are also correct after the SetEOF call. But when I read this 2048 byte record back in its the 1-2-3-1 arrangement. Subj: Re: WRITE - SETEOF - READ 89-05-23 18:57:20 EST From: GlenBredon I had a problem with what I think is the same bug you are describing. It is a bug in GS/OS. I sent a bug report to Apple on it and they said that they reproduced it and fixed it. I guess it will be fixed in SD 5.0. One of the ingredients in the bug is doing a write on a block boundary. I worked around the problem by checking if I was writing on a block boundary, and if so, did the write twice. Not nice but it worked. Subj: Thanks Glen, 89-05-23 20:54:11 EST From: Coach101 Almost all of my _critical_ writes are on block boundaries. Humm..... Do you know if SETEOF is needed to trigger it? If so I will only do the write twice when I am doing a block boundary write after a SETEOF. Subj: Re: WRITE - SETEOF - READ 89-05-24 00:32:07 EST From: Rob Turner Coach101, If you have a program that shows the bug in the ProDOS FST, please please, please send me the program, so I can see if I have fixed the problem. As you can guess, the number of days left for fixing bugs is very very limited!!! I cannot guarantee that the bug is fixed in 5.0, I did find the bug that was causing Glen's problem, but you may be having a unrelated problem. Thanks in advance... Rob Turner (GS/OS Team Member) Subj: Two Writes Avoids The Problem 89-05-24 23:26:16 EST From: Coach101 Thanks for the suggestion Glen. I am now writing information that I know in advance is an integral multiple of blocks and starts on a block boundary twice. This clears the problem. Rob, I sent you some E-Mail about getting the demonstration program to you. How much information do you need? Do I need to stop (with a keyboard input for example) just before the suspect write, or are your debugging tools in GS/OS such that you can deal with an untouched program and just information as to what _address_ in the file will be written when the problem arises? I will do everything I can to get this to you in time for 5.0. Subj: No Bug In 5.0 89-05-31 22:29:39 EST From: Coach101 Rob ran the test case and reported back that the bug does not exist in 5.0. Most probably the same bug that Glen found and reported. Thanks to both Glenn (for the workaround and original report that got it fixed) and Rob (for the committment to a GREAT 5.0)!!!!! Subj: Closing It Out 89-07-30 09:42:40 EST From: Coach101 I have 5.0, and have removed the workaround from my code. All is well!! Subj: GS/OS Exerciser & Memory 89-05-27 15:14:58 EST From: Coach101 Msgs: 7 (89-05-31) I have been using the GS/OS Exerciser recently to look at parts of files that I write. I just finished a 6 hour hard disk reconstruction because of a "dumb...." technique I used with the Exerciser. In particular the ability to read/write files or blocks depends upon reading/writing to/from _safe_ memory. I think I picked a memory address that was not _safe_; in particular, hunks of my */SYSTEM directory ended up with an ACU file I was building for Rob. I still have to inventory the rest of the files on my "reconstructed" hard disk to look for other damage. My question is, is there a way to coerce the GS/OS exerciser to get some memory from the MemoryManager and tell me the address? Then I could use this buffer safely. If this is not possible, it would be a nice feature to add to the Exerciser should it ever be updated. Subj: Re: GS/OS Exerciser & Memory 89-05-27 17:17:01 EST From: AFL Dyfet I suppose you can use memory peeker or something similiar to see where there is someplace free, but again, the act of opening a file, and the file buffer thus created, may (and so naturally, according to Murphy's law, will) occupy the same place that was free earlier. Memory Munger, a crude CDA for working with the memory manager, will allow you to allocate a block of memory. Another solution might be to create a short preboot utility for exerciser that asks the memory manager for a piece of memory, prints the starting address of where it is found, and then waits for you to hit a key before launching exerciser through Gquit. After exerciser's exit, it could then purge the handle created earlier and itself quit back to where you were. Subj: The Cadilac Solution.... 89-05-27 21:12:43 EST From: Coach101 Have another option in the exerciser that says, get me this much memory, tell me the address, lock the memory down, and make the address the default address. Then EXERCISER could release the memory when I selected the Quit function. Nice, clean, friendly. I really think something like that should be there. The current package justs leads you specify any old address and makes no mention of the required prayer ritual. Oh well, only experience programmers should mess with Exerciser. This one will be more cautious next time! I think a CDA that just grabs a hunk of memory and leaves it there would be my best solution. Via the CDA menu I could lock/unlock the memory and get the address when I needed it. Subj: Re: GS/OS Exerciser & Memory 89-05-28 11:43:16 EST From: AFL Dyfet I was trying to offer a solution that can be used now. But yes, I agree that this is a feature that should be added to somebody's 'to do' list at Apple :). Dyfet Subj: Why not... 89-05-30 23:58:25 EST From: A2Pro Tim You could simply use the VISIT MONITOR CDA to drop into the monitor, make the memroy manager call directly, write down the returned handle, go back to the Exerciser, etc. I believe Nifty List will let you do the same as well... Subj: NewHandle the Fun way! 89-05-31 01:36:59 EST From: Dave Lyons Tim beat me to it. :-) When I'm in a situation like that, I do one of two things. Either find someplace that *looks* really safe, or do a NewHandle to get some space that really *is* safe. If you have Memory Mangler (shipped with the APW debugger??), you could use that to do a NewHandle easily. I don't keep Memory Mangler installed, so I'd go into Nifty List, type "NewHandle to refresh my memory on the call number and parameters (it's 4 bytes of return space, a 4-byte size, a 2-byte ID, a 2-byte attributes word, and 4 bytes that are meaningful only when you ask for a specific bank or specific address). Then type * to drop into the monitor, and do this to make the call (let's assume I want 1 bank ($10000) under ID $1005): \10 4 0 0 0 0 0 1 0 0 10 05 C0 00 0 0 0 0 9 2\U The extra blanks are for clarity. The first two numbers mean 10 (sixteen) bytes will be pushed on the stack & 4 will be removed. The next 4 bytes are the space for the result. The next 4 are the size ($00010000) of the block to be allocated. The next 2 are the ID. The next 2 are the attributes ($8000+$4000 = locked + fixed). The last 4 aren't important. Finally, the 9 is the function number & the 2 is the toolset number (Memory Manager). If all goes well, you'll get something like this: Tool error -> 0000 78 16 E0 00 meaning that the handle you allocated was $E01678. You need to follow the pointer to find out where your memory block really is. You could type E0/1678.167B in the monitor, or you could Ctrl-Y back into Nifty List and type E0/1678h (H for Handle info). For that matter, you could type 1005i and see it listed among the other blocks with that ID. Fun, eh? Well, maybe not *that* much fun. Yes, future Nifty Lists will let you make toolbox calls in a more straightforward way. By name, even. (One of these days I'll be done with silly things like buying furniture & a car, & I'll get to start working on Nifty List again....) --Dave Subj: Doable, but.... 89-05-31 20:44:35 EST From: Coach101 Boy that sure sounds like a lot of fun Dave! I think I will avoid it. So many characters to type, I would probably mess something up along the way. I will play with the Mangler (hopefully its interface is more along the lines of the *new* NiftyList). About the Mangler Tim, is that really compatible with 4.0? I remember having lots of trouble (as in junk displayed) when using either the Mangler or LoaderDumper that came with APW from Apple APDA. I check again, but one of those is messed up for sure! Subj: SmartPort 89-06-08 18:15:12 EST From: SteveL39 Msgs: 10 (89-06-29) What is the best reference for SmartPort calls, errors, and stuff like that? All the technotes just say go buy the //c or //gs tech. reference manual in an obvious attempt to get another $30-$40 bucks out of us. They seem to forget that there are a lot of //e's with Smartport cards in them and that their owners don't have any need for those other manuals aside from the SmartPort stuff.. Subj: Re: SmartPort 89-06-08 22:27:48 EST From: Montagne The best reference is the Apple//GS Firwmare Reference manual (see chapter 7). Also, subscribe to the Apple][ technical notes. They contain information on how to avoid problems with certain SmartPort devices and CPU combinations. If you are writing a GS/OS application, you should never call a slot resident firmware protocol (BASIC, Pascal1.1, ProDOS, SmartPort or Extended SmartPort) directly. Device access should always go through the operating system. The reason is that we would like to provide dynamic slot switching in the future. Currently an Apple//GS has a static 7 slot environment where both internal and external slot resident devices cannot be accessed by an application. GS/OS was designed to support a 14 slot environment but there are application compatability problems that have to be resolved, mostly as a result of applications calling slot resident firmware protocols directly. It is almost impossible for the operating system to guarantee that the slot an application wishes to call directly will be switched in when the call to slot resident firmware is made. It boils down to this. IF YOU EVER WANT THE POSSIBILITY TO HAVE ALL 14 SLOTS AVAILABLE FOR USE IN A GS/OS APPLICATION, PLEASE DONT CALL SLOT RESIDENT FIRMWARE DIRECTLY OR THROUGH THE TEXT TOOL SET OR MISCELLANEOUS TOOL SET CALL 'FWENTRY'. For more information on this, please check the text tools topic in the tools discussion where more information has been posted. I might add that all the standard SmartPort device calls are provided through GS/OS device calls D_STATUS, D_CONTROL, D_READ or D_WRITE without the need of identifying the device and matching to the firmware protocol as well as identifying the device's characteristics. GS/OS is much easier to use than SmartPort also. A specific device can be found by searching the device list starting from device $0001 in ascending order with a D_INFO call. Devices are identified by their device ID word, not their name (since devices can be renamed under system 5.0). Ray Montagne (GS/OS Team Subj: Re: SmartPort 89-06-09 00:11:48 EST From: SteveL39 Ack! I guess I need a GS! (only have a P8 //e now) Ah well. It's not worth all the trouble to make the disk shoot out of my 3.5" drive by itself. Subj: Why didn't you say so, Steve? 89-06-09 02:18:08 EST From: A2Pro Tim Steve - if all you want to do is eject a 3.5" disk from AppleSoft, then get a hold of the April 1988 issue of Nibble magazine. There's an article in there that shows just exactly that!!!! The code's about 300 bytes or so and a short (REAL short) Basic program is included that shows how to call the routine. All you do is: set the variable "EJ" to the address of the routine set the variable "S" to the slot of the SmartPort card set the variable "D" to the drive number to eject and: CALL EJ,S,D It doesn't get much easier than that!!! If you can't find that issue (many libraries stock back issue - and yes, the year on that issue is '88, not '89), then log on to GEnie and download it from their A2Pro library (Nibble gave the author of the Eject routine permission to upload the source to GEnie). Tim Swihart Subj: Re: SmartPort 89-06-09 20:24:20 EST From: SteveL39 Ah! I'll have to get that one from the library. Actually, I was also looking for how to do Status calls and stuff like that, so my program can tell people to un-write protect disks without trying to write first, and identify disk drives and stuff. But I can't justify $25 for that. APDA should compile all the smartport stuff into another book. I'd buy it. Subj: Status calls, etc.. 89-06-11 23:37:47 EST From: A2Pro Tim Steve - some of the other calls are used by the article I mentioned before (after all, it does have to verify it's talking to a 3.5" drive before it tries to eject it...). If $25 is too steep for your blood - try looking for that book at B. Dalton's, Walden's Books, etc. It's usually carried in those stores as well (published by Addison-Wesley). Those stores also tend to discount computer books at least a little. Tim S. Subj: Re: SmartPort 89-06-24 21:04:50 EST From: SteveL39 How do you get the SmartPort to tell you how many drives it has and what kind they are? Including ones that are off-line, I need this so people can select a drive to format with in a program I'm writing and I can't assume that they keep disks in all their drives! (Obviously!) Subj: Information Sources..... 89-06-25 14:22:51 EST From: Coach101 I do not have the books with me now but the information you need is in the Apple II-GS Firmware reference and (I believe) also in the Apple II-C Technical reference. Here on AppleLink, you might take a look at the Technical Notes in the ADV library. There is a series of SmartPort technical notes and I think one of them defines how all of this works. You basically use a series of SmartPort status calls. The first one is addressed to the SmartPort as a whole and, among other things, it will return the number of devices attached to the SmartPort. When you do status calls on each of the devices, you can get the SmartPort to give you a bunch of information about each device. I am not sure how much information will come back when there is no disk in the device. If you need more information, I will dig out the books and try to post the stuff here. Subj: Re: SmartPort 89-06-25 20:22:03 EST From: Montagne Issue a status call to unit 0 with a status code of 0. This returns 8 bytes in the buffer pointed to by the status list pointer. The first byte indicates the number of devices. To determine what the devices are, issue a status call with a status code of 3 to each device. Devices are identified by type and subtype. Keep in mind that the subtype is a bit encoding describing characteristics of firmware support. Only bit compares, not byte compares should be used on the subtype byte. An added note: If you are using GS/OS, do not go directly to the firmware. Instead, issue a D_INFO call to each device starting with device $0001 to identify the device. D_INFO will return an error when you reach the end of the device list. Ray Montagne (GS/OS Team) Subj: Other info... 89-06-29 01:10:39 EST From: A2Pro Tim That Nibble article I mentioned shows how to make the status call to the SmartPort and to 3.5" disks hooked to the SmartPort. The source that goes along with the article is in Merlin Pro format, but you should be able to convert it to whatever assembler you're using since it's VERY heavily commented. (just in case you forgot what Nibble article I'm talking about, it's the April '88 issue - page 70 I think). You can find some info on SmartPort calls in back issues of A2-Central. If you don't have back issues, you can get them from A2-Central. Let me know if you need info on doing this. Tim S. Subj: GSOS and signals 89-07-29 06:37:20 EST From: BradL9 Msgs: 7 (89-08-04) Could someone give me a pointer to sample code or discussion on the use of signals in GSOS? I am trying to use a signal routine from an interrupt so I can call some disk access. This does not involve a driver. I cannot tell, for example how the "arm signal" fits in or, how to arm a signal if it is necessary. Thanks. Brad Subj: Re: GSOS and signals 89-07-30 12:31:50 EST From: AFL Dyfet I do not know of any source code examples off-hand. Using the signal mechanism in GS/OS has little resemblence to anything I have encountered in any other environment. What exactly are you trying to code, and why do you wish to use signals? Dave Subj: Re: GSOS and signals 89-07-30 20:27:00 EST From: BradL9 I want to have a one-second interrupt handler, which is part of a permanent instalization file, check for certain conditions every second. Actually it's checking to see if a scheduled time has arrived. When the scheduled time has arrived I want to issue a signal. The signal will take certain actions and get the time of the next scheduled action. The signal handler will need to make GSOS disk access calls, which the interupt handler can't do. All this code will be part of one program, unlike the device driver application discussed in the GSOS reference manuals. As I understand signals, they do exactly what I want, if I could just get them to work. All I am trying to do now is have a program (Merlin 16+) set a signal and have a "signal handler" simply return without doing anything. When I call the signal system service, the system locks. I will up load the code if it will help. It's very short. Brad Subj: Re: GSOS and signals 89-07-31 01:29:51 EST From: Montagne Arm Signal and Disarm signal are control calls issued to a device driver to install a handler into the device drivers interrupt handler. When arming a signal, an arbitrary value (signal code), signal priority and signal handler address are passed to the device driver. The signal code is used only during a disarm signal call (it identifies the signal to be disarmed). The signal priority actually identifies the driver's interrupt source. For example: A hypothetical driver might have a priority $0001 interrupt for disk ejection and priority $0002 for disk insertion. The signal priority is device specific. Since none of the device drivers supplied on system 5.0 support interrupts, arm signal will not have any effect on these drivers. Third party drivers that use an interrupt source (or maybe drivers supplied by Apple in the future) may take advantage of this facility. For your needs, it seems that you want to use the BIND_INT call ($2031). This call inserts your interrupt handler into the GS/OS interrupt vector table. You supply: Word Pcount (minimum = 3) Word Interrupt reference number Word Vector reference number Long Your handler address The interrupt reference number is actually a result returned so that you can remove your handler latter with an UNBIND_INT call. The vector reference number for the one second interrupt handler is $0015. Remember to save and restore the execution environment in your interrupt handler. Also, return via an RTL with the carry flag set=1 if you did not handle the interrupt source or clear=0 if you did handle the interrupt source. Do not use RTI. Ray Montagne (GSOS Team) Subj: Re: GSOS and signals 89-07-31 17:44:51 EST From: BradL9 Ray, Thanks for the reply. My confusion is more with the signal handler than the interrupt handler. I think I have the interrupt handler working. Given this bit of code: LDA #999 ;Signal priority LDX #Signal ;Low address of signal handler LDY #^Signal ;Bank of signal routine JSL #$01FC88 ;Call to SIGNAL system service RTL Signal ... RTL Should not the Signal routine execute at it's GSOS's earliest convience? Brad Subj: Re: GSOS and signals 89-08-03 22:41:00 EST From: Matt DTS No, it shouldn't. You would think it would, but there's a missing piece to this puzzle: Signals can only be fired from within GS/OS (as in, from within a driver, normally). If you just want GS/OS to be available when you need it, try this: Examine the GS/OS busy flag If it's set, use the SchAddTask call to schedule a task with the Scheduler. When your task is called, GS/OS should be ready for you to use. GS/OS also sets the system busy flag when it's busy, so using the Scheduler works. --Matt Subj: Re: GSOS and signals 89-08-04 17:47:31 EST From: BradL9 Thanks Matt. SchAddTask looks like exactly what I need. I never thought to look at the scheduler toolkit for a solution. Brad