keith@Apple.COM (Keith Rollin) (07/16/88)
Hello all, I wanted to get back to you concerning your ideas on source code samples, demos, technotes, support suggestions, etc. By the way, Apple II DTS should be having a panel at AppleFest in September (San Francisco), so you can make your suggestions there, too. If you attended any of the ones at Boston AppleFest, this will be the same thing. Also, many of you sent questions and suggestions. I want you to know that I tried to respond to every one of them. However, sometimes the mail bounces back, and I can't respond. So if you have a question to be answered, send it to comp.sys.apple2 for everyone to read instead. Here are your suggestions for the Living Technotes: >- I've been looking for some examples on using the Quick Draw Auxilary >Routines copy Pixel and draw Icon. OK. We tried to write a comprehensive Blitting demo, but weren't able to get it all done for this version. Maybe in Volume II. >I would like to see a better version of the Super Serial Card manual. It has >very little useful information about interrupts since the manual was written >before the days that the Apple II could handle interrupts. It also has an >annoying error -- in the description of the Pascal interface, it first claims >that the carry bit will be set for a Yes response to the status call, clear for >No. Three pages later it says the carry will be clear for Yes, set for No! I >spent quite some time going through the spaghetti ROM listings to find out >which was the case. Good idea. We (Developer Tech Support) can't rewrite the manual, and there is more information in later manuals (like the Apple IIGS manuals), but that doesn't help you unless you have a spare $20-30 to blow on a manual for a computer you probably don't have. We have placed on our list of programs to write a Serial Port/Card demo for ProDOS 8. >I would like to see some down to the nitty gritty code. Like >patching code onto the interrupts for on the fly changing of colors >to enable more than 256 colors per screen. Much of what I would like >to see I doubt Apple would approve of......... getting around all those >tools. But maybe there isn't the market for real time graphics and >sound on the IIgs, which is what I am interested in. Fie on you! :-) As a matter of fact, one of the programs on the first volume shows fullscreen shape and color animation that doesn't use QuickDraw (much). We realize that some of the tools don't perform up to speed for you, and so provide ways to patch out tools and access the graphics screen without using QuickDraw. >Sample CDA and NDA in C or Pascal (preferably C), >A program to take a Mac font and convert it to a GS font > (assume that it has been downloaded from a mac, so you > don't have to read a Mac disk), >A sample printer driver We'll work on the DA's in C for you. We aren't doing anything in Pascal, as Apple doesn't provide one, and we don't want to show any favoritism for any of the 3rd party ones; if we were to issue samples in ORCA or TML Pascal, we would bias people toward using one of those and not the other. A Font converter would be useful utility, but would not satisfy the requirement of being a demo that would how the ToolBox was used. Finally, I believe that we just issued a technote that showed how to write a printer driver, which included a primitive driver itself. >Sample code which will work with Appletalk. On the list. We are planning an 8-person conferencing program that will run over AppleTalk. This is iffy, though, so don't be surprised if the feature-set changes. >A series of samples (or one very nice size sample) using calls >from all of the tools. This would not only show folks what the >GS can do, but would also show the ordering of toolset loads, etc. This is what the primers I mentioned in my original posting are supposed to do. >Some samples showing correct error handling procedures for various >common errors - in fact, if ALL of the demo/samples did this, that >would be great. We do SOME error checking, but not all over the place. >Advanced usage of the event manager...maybe even a small >tutorial or some of the basic ways it is able to handle >multiple events at the same time (well..almost :-) I'm afraid that we couldn't figure out what this one meant. What do you mean by handling multiple events? I know of one person who reads events out of the OS queue, and places them in his own... do you mean something like that? >Technotes on hardware manipulation (read soft-switches) of >the serial chip. I know, "You're suppose to use the Toolboxes >for that stuff!" But, there are a number of applications that >bypass the toolbox and allow one to use the printer and modem >while having other cards running in the supposedly "used" >slot. I want to know HOW THEY DID IT !!! I'm afraid that we can't show you how to do that. While knowing that sort of information would be fun and personally satisfying, I have to do my job and promote compatiblity. >Demos on using the equinox while buffering data into the >other ports of the system. What's the equinox? >Maybe some notes on making personalized Toolboxes. We've been kicking this idea around for a while, but haven't been able to come up with a really good idea for a sample Tool (actually we do, but I want to keep it as a surprise!). If anyone out there has any suggestions, let us know. >I would like to see ways of interacting with TaskMaster. How to >Maskout events and such, like which ones to maskout and why. From >reading through the ToolBox Books, I gather Apple would like us all to >use TaskMaster, yet I am consisently finding parts in the books that >make it seem better to Not use TaskMater. We now have on the list a program that handles ALL events without using TaskMaster. This should include scrolling a window with *REAL* scrollbars, and not the ones that the Window Manager provides. This demo will show you the consequences of not setting *ANY* of the bits in the TaskMask. >If you folks were interested in getting a small complete application >in, I'd REALLY like (and I'm not the only one... This'd be useful to a bunch >of people) a "Font previewer", as it's sort of a pain to go and copy bunches >of downloaded fonts into the /VOL/SYSTEM/FONTS after moving some of the others >out, so that programs that use a Fonts menu won't crash... To get demos of >some other stuff in, you could make it possible to edit the font info as well. Good idea. I'll see if we can incorporate this into our Font Manager primer. >- The C compiler should generate an assembly listing for debuging >purposes, this is absolutely essential. >- Perhaps a magic book of debuging techniques for IIgs C and assembly >programs. I know there is hundreds of man years of experience out there >and probably lots of great tips, techniques and short cuts. >- A C source level debugger, this would be absolutely wonderful. >- A 'Make' program for APW (like GSMake) These are all good suggestions, but beyond my scope. I'll pass them on to the appropriate people within Apple, though. ------------------------------------------------------------------------------ I also recieved a lot of comments on the distribution of the source code. Many people praised our efforts; some said that this was too late for their needs. Almost everyone cried out not to send this to just APDA or developers. The tentative list of recipients of the source code is: - APDA - Developers (in a standard developer mailing that Developer Services does) - Users Groups (ditto for the User Group Connection) - USENET (I don't have access to APPLE2-L) - GEnie - CompuServe - AppleLink (the one we currently have and the newly released Personal Edition) However, these is just a tentative list of what *I* would like to see, and of what I will push for. I can't make any guarantees; I'm not a manager, and I am not in charge of distribution. I'm just a slob programmer who would like to see this spread out as far as possible. If you would like to make other suggestions, or have reasons for NOT sending code to any of the above places, let me know. So, time for this Beanie-Boy to sign off. I hope that this stimulates your creative juices, and helps you think of more ideas. I would welcome them! Keith Rollin amdahl\ Developer Technical Support pyramid!sun !apple!keith Apple Computer decwrl/ "You can do what you want to me, but leave my computer alone!"
jason@lakesys.UUCP (Jason) (07/17/88)
In article <14045@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) writes: [Lots of nifty stuff regarding what will hopefully be happening...] [He then responds to someone who will, for the time being, remain ] [Anonamous (How, pray don't tell, does one spell that word?) ] > [A wish list of nice things] > >- A C source level debugger, this would be absolutely wonderful. [Yes, yes!] > >- A 'Make' program for APW (like GSMake) Why "like" gsMake? I'm really getting frustrated now regarding gsMake, as I've recieved 0 donations and 0 comments (save Mr. Rollin's comment that the developers there @ Apple would probably prefer rolling their own) about it. I'm more concerned with the lack of comments... I could take being told that gsMake is a piece of crap, but only if I knew WHY that was thought. Granted, gsMake isn't the most beautiful piece of programming in existance, but it beats hell out of typing the same (long) command line over and over. It's not the most expensive program running around these days, so it wouldn't seem that that's the problem... I was pretty happy when I got gsMake to be useful... I decided that I would write up some documentation for it, and send it out into the world, hoping that it would be useful to someone besides me (I use it almost all the time). I am very disappointed by the response... Not the sort of thing that encourages me to spend the time "prettying" things up a bit to prepare it for "the rest of the world." Pardon the tantrum, but I've had almost all I can take on this one... -- Jason - Not your average iconoclast
Ralph.Hyre@IUS3.IUS.CS.CMU.EDU (07/20/88)
Newsgroups: comp.sys.apple Subject: Re: Apple Demo Responses Keywords: Demo technotes puppy-dog-tails Distribution: References: <14045@apple.Apple.COM> Organization: Carnegie-Mellon University, CS/RI In article <14045@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > >Hello all, >Good idea. We (Developer Tech Support) can't rewrite the manual, and there >is more information in later manuals (like the Apple IIGS manuals), but that >doesn't help you unless you have a spare $20-30 to blow on a manual for >a computer you probably don't have. Perhaps the best thing you can do is exert some rational influences. I don't have a GS, but I had to buy the IIGS firmware reference manual in order to find documentation on the low-level smartport/protocol converter stuff (Even at the level of twiddling the phase control lines to send smartport commands as opposed to other stuff.) I have the //e UniDisk combo - and I'm trying to make use of the Liron card to talk to 5.25 sorts of drives. Even though I read that it's not 'supposed' to work, I want to try it to see what really happens. The $25 GS manual is to help insure that I don't smoke a $100 drive - not a good investment from a purely insurance oriented point of view. A 'Liron' card schematic or simple pinout would help me make sure. After all, who wants to waste another slot for a 5.25 controller card, especially when future ProDOSes will make slot/drive distinction unnecessary? Technotes (does developer support help write these?) are good for this purpose, but APDA couldn't find the relevant Smartport ones. In summary, I'm thrilled with the content, but the bundling of materials could stand some improvement. (I read in MacWeek that Apple is considering buying APDA - if it improves service, please do.) Thanks again for being here. - Ralph -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA