======================================================================= Archived Messages: "CDA's" America Online Apple II Developers Forum. Go Keyword ADV! (C) 1992. ===================================================================jrm= Type: Response From: KatherineL Date: 88-02-15 22:27:19 EST 88-02-15 22:27:19 EST CC: KatherineL Re: Re: CDA's I'd like to develop a CDA using TML Pascal. My question is, how do I write and read from the screen? Standard Pascal I/O is out because TML uses SHR for that. Any suggestions? I also have APW C -- would it be easier to use that? Type: Response From: FL Jim Date: 88-02-16 00:02:13 EST Re: Re: CDA's Kathy, The version 1.1 of TML Pascal lets you use the text screen. Just leave the (INPUT,OUTPUT) identifiers off the program heading. If you find that readln doesn't work with the text screen, then you need to send your TML Pascal disk back for the 1.1A update (it's free). --Jim Type: Response From: KatherineL Date: 88-02-16 23:50:05 EST 88-02-16 23:50:05 EST CC: KatherineL Re: Re: CDA's I'll check it out. If I don't have 1.1a I just ordered 1.50 so that should do it for me! Let you know. Thanks. :) Type: Response From: KatherineL Date: 88-02-20 18:18:47 EST 88-02-20 18:18:47 EST CC: KatherineL Re: Re: CDA's The ongoing saga of the broken CDA continues over in Pascal for those who are interested... Type: Response From: KatherineL Date: 88-02-20 18:32:48 EST 88-02-20 18:32:48 EST CC: KatherineL Re: Re: CDA's Is there a maximum allowable size for a CDA? Aside from the memory constraints of the machine as a whole (wouldn't be nice to write a 256K CDA in case you have a user with only 256K! :) ). Type: Response From: AFL Jim Date: 88-05-29 14:13:41 EST Re: Re: CDA's Which type of desk accessory do programmers prefer? CDAs can be accessed from any type of program, but you can't see what your program is doing while the CDA is active. NDAs can only be accessed from the SHR desktop environment, but they run inside a window so desktop applications can be watched while you run the NDA. I've got some ideas for programming utility DAs and I'm looking for your input. Jim Type: Response From: User797 Date: 88-05-30 19:47:28 EST 88-05-30 19:47:28 EST CC: KatherineL Re: Re: Preferred DA's For me, it depends entirely upon the nature of the DA. If it's the type of thing (like a phone dialer or calculator) that I may want in AppleWorks or my other P8 applications, then a CDA is the obvious answer. If the DA is only useful in a window environment (like a mouse follower or event reporter), then an NDA is more appropriate. I'm leaning a bit toward CDA's these days. Many accessory functions are most useful when opened for a moment, then shut down. NDA's don't handle this very well, and are expected to stay on the screen until otherwise informed. I don't like that. Hope this helps. Type: Response From: Parik Rao Date: 88-05-30 22:11:35 EST 88-05-30 22:11:35 EST CC: KatherineL Re: Re: CDA's I personally prefer CDAs, but like User797 said, it depends on the utility itself. However, CDAs are more versatile, since I can use them in ProDOS 8, or in the middle of a non-desktop environment that supports interrupts. NDAs are just too limited to be of much use, due to the time I spend in any given desktop (Orca Desktop is about the only one). Or how about just programming two versions? Both structures are pretty much the same, just a few tool-call changes and format changes, and you have the same thing. You can easily change one to another... Type: Response From: AIIDTS Date: 88-06-02 18:29:57 EST 88-06-02 18:29:57 EST CC: KatherineL Re: Re: CDA's for programming utilities, CDA's are the only way to go for me. NDA's require the machine to be in a perfectly running state, which ain't always the case when you are developing software. As for the CDA's I use most, well I can tell you that I only use 1 CDA in all the ones I have ever had. That CDA gets used ALL the time, its called Nifty List, and if you are developing GS software this is a MUST! ( at least I think so) it is shareware and well worth the price. Jim Type: Response From: Parik Rao Date: 88-06-02 20:49:59 EST 88-06-02 20:49:59 EST CC: KatherineL Re: Re: CDA's Also another great one is Memory Peeker... its great when your program crash's or you want to see if your program is storing data correctly w/o having to insert the actual code in your program. Type: Response From: AFL Floyd Date: 88-06-02 21:56:16 EST 88-06-02 21:56:16 EST CC: KatherineL Re: Re: CDA's Nifty List is a NECECESSITY for programmers. I use it EVERYDAY! It does MUCH more than memory peeker or any other CDA that I have seen. Floyd Type: Response From: ScottG25 Date: 88-06-03 17:28:15 EST 88-06-03 17:28:15 EST CC: KatherineL Re: Re: CDA's I agree totally on the usefulness of Nifty List...The thing is a gem! Type: Response From: JSchober Date: 88-06-03 19:42:24 EST 88-06-03 19:42:24 EST CC: KatherineL Re: Re: CDA's Parik... Nifty List contains some of the same functions that Memory Peeker does (NL allows you to display all memory allocated at the time, or get info on a specific ApplID), and you can still go into the Monitor from it! I personally just hit a # when I boot up, then run ORCA/GS just so I can install NL. (Don't have a CDA version of it, so I can't use P8CDA... sigh...) Dunno what I did without that one!!! Type: Response From: AFL Floyd Date: 88-06-04 10:37:58 EST 88-06-04 10:37:58 EST CC: KatherineL Re: Re: CDA's The CDA version of Nifty List is in "IIGS Desk Accessories" in the Utilities Forum. If you use this great CDA be sure and send in your shareware fee! David Lyons deserves it. Floyd Type: Response From: User797 Date: 88-06-06 19:09:16 EST 88-06-06 19:09:16 EST CC: KatherineL Re: Re: CDA's Does NiftyList have a feature where the toolbox call name can be "looked up" by its number? That would be particularly helpful to me. So far, I've had to put the call into an unused area of memory (usually the upper few bytes of the keyboard buffer), and listed it. If I'm not overlooking something, could someone suggest this to David Lyons? I'd appreciate it... /;+/ P.S. NL is on my SMALL list of ShareWare I keep and will pay for. Type: Response From: Mensch72 Date: 88-06-07 22:18:33 EST 88-06-07 22:18:33 EST CC: KatherineL Re: e: CDA's yep, Nifty list will tell ya the name ( it will also tell ya the function pointer if you ask for it!) Jim Type: Response From: User797 Date: 88-06-08 17:35:16 EST 88-06-08 17:35:16 EST CC: KatherineL Re: Re: CDA's Wellllll....... HOW? :} (Sheepish grin) /;+/ Type: Response From: Dave Lyons Date: 88-07-02 06:04:43 EST Re: Nifty List Don't you have a copy of NLIST.DESC, User797? Just type xxxxT, where "xxxx" is the number of the tool call you're interested in. It prints the name & toolset name, and it even displays the function pointer if the thing is in ROM or RAM at the time. It also sets the "#" variable to that value, so that you can do a "#L" to see the tool call, or even put it on the same line: 902T#L would start listing NewHandle for you, for example. If you want to go the OTHER direction it's just as easy: "Mouse will show you info on all the tool calls that have "Mouse" in their names. Lemme know what you want to see in upcoming versions of Nifty List! Type: Response From: MikeW50 Date: 88-07-05 11:05:23 EST Re: Re: CDA's Is niftylist available on this BBS for downloading? Mike Westerfield Type: Response From: Dave Lyons Date: 88-07-05 18:38:28 EST Re: Nifty List downloading Mike, yes--version 2.22 is in the Utilities forum (Apple-K AUT), under IIgs Desk Accessories in the libraries. NL 2.4 will be available here when it is finished or when the libraries are re-opened for uploading, whichever comes *last* :-) --Dave L Type: Response From: AFA Gary J Date: 88-08-13 22:42:00 EST Re: Re: CDA's Does anyone know how (or if it is even possible) to obtain the current program counter value of the program interrupted at the time you enter the control panel, from within a CDA? I know that the system stores this information someplace....because it obviously continues on with its operation right where it left off upon quitting from the control panel. Is it obtainable from within a CDA? Gary Type: Response From: AFL Jim Date: 88-08-14 00:28:33 EST Re: Re: CDA's The complete system state is stored, but since it is in one of those undocumented locations, you can't assume it will stay at that location in future revisions. Type: Response From: Dave Lyons Date: 88-08-14 01:57:54 EST Re: CDA finding old system state Gary, the info is "obtainable" if you don't mean "obtainable in a documented way." SoftSwitch is one CDA I can think of that definitely finds and even changes the outside-the-desk-manager system state. When you leave the CDA menu--Presto!--you may be in a different 128K world! I have no idea whether RWP tried to make Apple promise that their method would continue to work or whether they just intend to release revised versions of SS when new ROMs and/or system software comes out. It wouldn't surprise me if some of the state info was actually on the STACK, but I haven't checked. Type: Response From: AFA Gary J Date: 88-08-14 23:09:50 EST Re: Re: CDA's The stack is one of the places I thought of too, but I haven't checked it either. It would be the logical place for the program counter. I have done some checking around in bank $E0 and $E1 for the information I mentioned, but this was some time ago. I was able to locate where all the registers were stored, but I couldn't find the program counter. I guess I'll check the stack! Thanks Jim and Dave for your help. Gary Type: Response From: MikeW50 Date: 88-08-16 18:31:15 EST Re: Re: CDA's You do an RTL to somebody - it shouldn't be too hard to trace the code to see where they get the info from. Incidentally, if anyone at Apple is listening, it sure seems like this info should be frozen and preserved. Some pretty spiff debugging tools could be written if the mechanism could be counted on! Mike Westerfield Type: Response From: AFA Gary J Date: 88-08-16 20:47:01 EST Re: Re: CDA's I agree 100% with what Mike said in the last post about this information being frozen and documented. The very reason I am interested in the program counter value is for debugging purposes. It could be VERY useful. Gary Type: Response From: DataPro Date: 88-09-30 12:34:00 EST Re: CDA's and Visit Monitor I suppose no one has been able to figure out what info is saved or where it is saved when the Visit Monitor command is envoked or any CDA command is envoked? I have all of the information on the IIe/IIc/II+ but as of yet have been unable to figure out what or where the info (A,X,Y,P,S,PC hi and lo....)is stored in memory. Have been able though to locate A,X,Y,P,S in zero page. What is pushed on stack I don't know....YET! Type: Response From: AFA Gary J Date: 88-10-01 00:05:41 EST Re: Re: CDA's I have been writing a CDA that would automatically display the registers and program counter when invoked, and I thought I had it all figured out.... BUT, I seem to be getting inconsistant results. I may not have all the correct memory locations. I'd like some further info as well. Gary Type: Response From: AFA Gary J Date: 88-10-01 00:26:25 EST Re: Re: CDA's - register storage The information I was able to drum up on this is as follows: Zero page is stored at E0/1C00.1CFF The stack is stored at E0/0300.03FF The text screens are at E0/0C00.1BFF Accumulator E1/0108.0109 X-Register E1/010A,010B Y-Register E1/010C.010D Stack Pointer (S) E1/010E.010F Direct Register (D) E1/0110.0111 Data Bank Register (B) E1/0113 Processor Status (P) E1/0114 Program Counter 2,S State Register ($C068) E1/0118 Shadow Register ($C035) E1/0119 CYA Register ($C036) E1/011A MSlot ($07FB) E1/011B Disclaimer: This information (to the best of my knowledge) is not published by Apple, therefore it is to be used at your own risk. I have not been able to verify all of this info. If anyone has any corrections, additions, or clarifications, please let me know. Gary Type: Response From: AFA Gary J Date: 88-10-09 01:10:18 EST Re: Re: CDA's Interesting.... Sandy Mossberg's article in the November issue of Call-A.P.P.L.E. covers some of the memory locations I listed in the previous post. At least now I have a way to verify some of this stuff! Good article. Gary Type: Response From: Matt DTS Date: 88-10-09 21:09:52 EST Re: Re: CDA's Gary: I think you're wasting your time. The Desk Manager is a tool, and like any other tool could change its internal workings at any time (even from system disk to system disk). If you absolute need to be able to stop and look at something for debugging purposes (which is what I suppose this is for), you can always grab the CDA vector ($E1/0048 thorugh $E1/004B) and make it point to your own thing. (Note that this is acceptable only for debugging purposes; taking away IRQ.DSKACC at other times, like during a regular, non-game application, would be really slimy. It's slimy during a game, too, but games aren't known for following any rules at all...) --Matt Type: Response From: Matt DTS Date: 88-10-09 21:16:54 EST Re: Re: CDA's I should also point out that the location of IRQ.DSKACC is not guaranteed, and is provided from the Apple IIgs Firmware Reference (page 268). It would serve for debugging purposes but not for the rest of real life. --Matt Type: Response From: Dave Lyons Date: 88-10-09 21:49:49 EST Re: intercepting IRQ.DESKACC Matt, the *absolute location* of the IRQ.DSKACC vector isn't guaranteed, as you say, but getting and setting it with GetVector($12) and SetVector($12) *is*, right? Type: Response From: MikeW50 Date: 88-10-10 10:56:23 EST Re: Re: CDA's Matt, many of us have been lamenting the fact that a CDA based debugger is not possible using strictly legal means. Could you use your enormous influence at Apple to get SOME method locked in concreat? CDA debuggers are too good an idea to not be iplemented eventually (I'm usrprised there isn't one already). If Apple is to lead, rather than follow behind and sweep up the scraps, you need to establish a common method for finding the regs, and even for signalling the end of a program. Mike Westerfield Type: Response From: Matt DTS Date: 88-10-10 22:28:54 EST Re: Re: CDA's As usual, I can't comment on a CDA debugger or anything like that. But Dave is right - GetVector and SetVector will do the trick in the approved way. (Can you tell that I had the Firmware Reference here last night but not the Toolbox Reference?) --Matt Type: Response From: MikeW50 Date: 88-10-11 10:29:05 EST Re: Re: CDA's Matt, Maybe you misunderstood about the CDA debugger. I wasn't asking you to comment on what Apple is doing - I know what is happening in that area (or at least, what a couple of people wanted to happen as of a recent date - things change pretty often there). The point is that others will write debuggers, too. After all, you can never have too many debuggers! If the Get/Set vector route is the "approved" way, it sounds great. Mike Westerfield Type: Response From: SEGlass Date: 88-11-05 18:43:06 EST Re: CDA Debuggers Yes, a CDA debugger would be great to have except for a strange design quirk in the way the CDA menu is activated. You see, the CDA menu is not always entered via an interrupt. Several factors can result in a delay from pressing OA-Control-ESC. The CDA Menu runs in two ways depending whether the event manager is active. When the event manager is active, the CDA interrupt handler posts an event and returns. When the program calls GetNextEvent, the CDA menu is displayed. When the event manager is not active, the CDA interrupt can invoke the CDA menu right away, but does not always do so. Specifically, it does not invoke the menu if the system busy flag is not zero. If it is not zero, it schedules a wake up call with the scheduler and returns. Both of these facts make it impossible to write a good debugger that is a CDA (You could not get out of an infinate loop if the busy flag were set or the loop did not call getnextevent). It does not prevent some clever fellow from using the CDA interrupt for a debugger however. To make this possible, we at Apple need to provide a clean way to access the interrupt information. We'll see what we can do. Steven Glass Manager, Apple II Toolbox and Imaging Apple Computer, Inc. Type: Response From: JStarta Date: 88-12-03 00:58:01 EST Re: Re: CDA Development Questions Is there a limit as to what a CDA can do? For example, could a CDA be working in the background while you are doing something else in the foreground? I may be wrong, but you have to set aside a predetermined memory location depending the background procedure. Right? What, would be a "safe" place to start? John Type: Response From: Dave Lyons Date: 88-12-03 02:47:53 EST Re: CDAs doing work in background John, there are generally no predetermined memory locations in the GS world (other than for the system's use, and even then most stuff is allocated through the memory manager, where ever there is room at the time). The Loader will take care of loading your CDA and adjusting any address references appropriately, depending on where your CDA gets loaded (or where each segment gets loaded, if you have more than one segment). One way a CDA could do things in the "background" would be to install a HeartBeat task (see the Misc Toolset folder) so that a routine owned by the CDA would be called by the system every n/60 of a second. Of course, the foreground application always owns things like the screen and keyboard...probably your CDA would want to do its work and keep the results, not displaying them until the user entered the main part of your CDA through the CDA menu. You can install a HeartBeat task when your CDA's "shutdown" entry point is called. This happens every time DeskShutDown or DeskStartUp is called, and the system calls one of those once during boot, right after all the desk accessories are installed. Type: Response From: DougDavies Date: 88-12-30 13:11:20 EST Re: Re: Old state at CDA activation We, at WordPerfect, have written a symbolic debugger that is a CDA. The status of the machine (asked earlier) can be found by doing a GetAddr (found in misc. tools) with a $0009. This includes all the registers, program counter, etc. The return address can be found by using the stack pointer (I think, can't remember for sure, been a while). Hope this helps! Type: Response From: CompWizA Date: 89-07-24 20:33:48 EST Re: Bringing up the CDA menu How can I bring up the CDA menu from within a program ? By just doing a JSL to $E1/0048 or by some other means ? BTW I've tried to do a JSL to $E1/0048 my program crashes with a BRK $00. CompWizA Type: Response From: Dave Lyons Date: 89-07-25 22:52:17 EST Re: CDA menu under program control Hmmm...if the Event Manager is on, I bet you can call PostEvent with a deskAccEvent. Otherwise I'm pretty much stumped...you *may* be able to use the ADB SendInfo call to make the machine think the user hit Apple-Ctrl-Esc...then again, you may not be able to (I haven't tried, and you might have to discover the right keycode experimentally even if it works). Type: Response From: CompWizA Date: 89-07-26 18:41:42 EST Re: PostEvent won't do it The Event Manager is active but I'm not using GetNextEvent. I've tried using just PostEvent and PostEvent with GetNextEvent but nothing happens. The routine that the vector at $E1/0048 points to just does just a PostEvent but exits in 8 bit mode so my program crashes. I've tried doing a REP $30 right after I do the JSL to the vector but nothing happens unless I insert a BRK $00 somewhere after it. NOTHING seems to work. BTW I looked at SendInfo but how do I send the Control and Open Apple key codes? CompWizA Type: Response From: AFA Parik Date: 89-07-28 20:29:00 EST Re: you're doing it wrong... you need to ENTER in short mode (as with any interrupt). the following works. short m,i jsl $E10048 long m,i simple! Type: Response From: CompWizA Date: 89-07-30 15:10:03 EST Re: It doesn't work I don't speak APW but I translated the macros to this in assembly: SEP $30 Tell the assembler to only put out 8 bit opcodes REP $30 Tell the assembler to put out 16 bit opcodes The problem: it doesn't work I my program just goes right on chugging along as if I never made a JSL to the vector. CompWizA Type: Response From: AFA Parik Date: 89-07-31 23:40:06 EST Re: Re: CDA's Hmm, not sure CompWhiz. The easiest thing to do is disassemble the control panel (I did it, its VERY simple, all it does is check if the CP is callable by checking $E01D67 [whether the user is in the CP or not already] and $E100FF [the busy flag] and if all conditions are a-o.k. then it calls a few toolbox routines which handle all CDA stuff) Also if you're using merlin, sep #$30 and rep #$30 i think need to be preceeded by MX %11 and MX %00 respectively (I think?) Type: Response From: CompWizA Date: 89-08-04 19:31:23 EST Re: Must call GetNextEvent OK, here's what it was YOU MUST CALL _GETNEXTEVENT AFTER A JSL TO THE CDA VECTOR otherwise the cda manager will not be called to display the Control Panel. CompWizA