================================================================================ (C) 1991 by Atari Corporation, GEnie, and the Atari Roundtables. May be reprinted only with this notice intact. The Atari Roundtables on GEnie are *official* information services of Atari Corporation. To sign up for GEnie service, call (with modem) 800-638-8369. Upon connection type HHH (RETURN after that). Wait for the U#= prompt. Type XJM11877,GEnie and hit RETURN. The system will prompt you for your information. ================================================================================ ************ Topic 27 Sun Jun 23, 1991 M.SQUIRE [Mike] at 09:39 EDT Sub: Extensible Control Panel (XCONTROL) Discussion of Atari's Extensible Control Panel, now shipping with the Mega STe and TT. Now it is available to everyone in the Library (file #19837). 215 message(s) total. ************ ------------ Category 14, Topic 27 Message 1 Sun Jun 23, 1991 M.SQUIRE [Mike] at 09:40 EDT I thought I'd start a topic on the Extended Control Panel (XCONTROL) as there was none here and because I've run into a problem implementing its use on my Mega2 ST with TOS 1.4. It seems like whenever I boot in color now, with XCONTROL installed rather than the earlier CONTROLE Control Panel (STe version) or CONTROL Control Panel (ST version), I always end up in medium resolution. At first, I thought that this was because I configured the XCONTROL settings initially in high resolution, going to medium resolution later in order to specify colors, but even when I tricked the ST into booting in low resolution by momentarily going back to the use of the older Control Panel, flushing it out of memory using MultiDesk (v2.2) and replacing it with XCONTROL, and resaving my CONTROL.INF file and all my CPX files, the ST still came up in medium resolution on the next boot. It appears that the Extended Control Panel may save its resolution setting in the COLOR.CPX file as this was the only file that was changed as a result of saving it in two different resolutions (i.e., the bytes varied between the medium resolution saved version and the low resolution saved version). I would seem, however, that the only way to use a Mega2 ST with XCONTROL active in low resolution is to 1) boot the system in color which, in turn, brings you up in medium resolution, 2) (IMPORTANT) shutdown the Extended Control Panel (per Atari's warning in the documentation), and 3) use the Set Preferences pick on the GEM Desktop to change from Medium to Low resolution. If anyone knows of an easier way to boot in low resolution using XCONTROL, I'd like to know as the documentation does not address this. On a more helpful note, I'd like to pass along a tip on something it took me a while to discover. When changing the icon colors in the Configure CPX CPX, be sure to save -each- icon after you change its color instead of changing all of the icons' colors and doing a single save. Otherwise, you'll only save the color of the icon selected at the time of the save. ... Mike Squire ------------ Category 14, Topic 27 Message 2 Sun Jun 23, 1991 REALM [Joey] at 15:00 EDT Mike, did you save your desktop in Medium resolution? Xcontrol shouldn't have anything to do with it booting in Medium. If you use Save Desktop in High or Low res it should boot in Low on the color monitor. If you Saved your desktop in Medium then it will boot into Medium. If your running from floppies make sure the disk you boot with has the Desktop.INF file you need. In other words, it may apear as if the normal CONTROL.ACC boots in low but if it's on a different disk then the XCONTROL.ACC the Desktop.INF file on that disk is probable saved in Medium. Does that make sense?:-) Hope that helps! ------------ Category 14, Topic 27 Message 3 Sun Jun 23, 1991 DOUG.W at 16:24 EDT Mike, What Joey said is correct. XCONTROL has nothing to do with setting the resolution. The bootup resolution is set by the Desktop from the DESKTOP.INF file. If you switch to low-res and 'Save Desktop,' the computer should then boot in low-res. --Doug ------------ Category 14, Topic 27 Message 4 Sun Jun 23, 1991 S.JOHNSON10 [Steve] at 18:20 EDT M.SQUIRE - That's strange... I edited all the colors of each .CPX and then selected SAVE and it saved all of them. Also, I'm able to boot up in low resolution with XCONTROL installed, as long as I switch to a DESKTOP.INF file that's set up to boot in low rez, that is. ------------ Category 14, Topic 27 Message 5 Sun Jun 23, 1991 WAYNED. [Wayne] at 23:35 EDT Mike, What they all said. :-) I have a Mega IV with TOS 1.4 and didn't have any trouble booting in Low Res. (or any res for that matter) As they all said check out your Desktop.inf file. Wayne ------------ Category 14, Topic 27 Message 6 Mon Jun 24, 1991 L.DUMAS [Leland ] at 20:43 EDT that probably explains why it doesn't seem to do much for me. I have TOS 1.60 instead of 1.62. (I knew I should have waited another month for this STe!) [g] ------------ Category 14, Topic 27 Message 7 Mon Jun 24, 1991 OUTRIDER [Terry @ T2] at 22:46 EDT I don't remember the thread, but the new XCONTROL works just fine with my TOS 1.60, save for the TT specific stuff, of course. - Terry - ------------ Category 14, Topic 27 Message 8 Tue Jun 25, 1991 M.ALLEN14 [Mike] at 00:11 EDT XControl is neat but could someone PLEASE tell me what the fix to TOS14FIX is so that I can use the MODEM CPX AND TOS14FIX at the same time? Mike Allen ------------ Category 14, Topic 27 Message 9 Tue Jun 25, 1991 OUTRIDER [Terry @ T2] at 01:34 EDT TOS14FIX fixes flow control (almost) and some AES bugs, as I recall. If you don't have a high speed modem (9600 and above), you won't need the flow control fix. I don't know the nature of the AES bugs, so I'm not sure if you need them fixed or not. In any case, a 'fixed' TOS14FIX is supposed to be out RSN. - Terry - ------------ Category 14, Topic 27 Message 10 Tue Jun 25, 1991 D.FLORY [ALERTsys*Cop] at 09:03 EDT I've been told that you need to remove TOS14FIX and run TURBOCTS.PRG in the Auto folder. I'm doing that and it seems to work fine. I have the computer talking to the modem at 19200 and it communicates with everybody just fine. Except I can't get it to talk to GEnie at 9600 no matter what I do. ------------ Category 14, Topic 27 Message 11 Tue Jun 25, 1991 DARLAH [RT~SYSOP] at 09:13 EDT Dave: I have no problems talking to GEnie at 9600. What modem and what are your settings? By the way, I never ran TOS14FIX nor TURBOCTS and still got between 700 and 900 cps. ------------ Category 14, Topic 27 Message 12 Tue Jun 25, 1991 WAYNED. [Wayne] at 19:32 EDT Mike, What happens when you use them (Modem.cpx, and tos14fix) together? I have them both running on my system (Mega IV with Tos 1.4) and haven't noticed anything different. Wayne ------------ Category 14, Topic 27 Message 13 Tue Jun 25, 1991 DARLAH [RT~SYSOP] at 21:44 EDT Now you have me interested. Do tell us, Mike. ------------ Category 14, Topic 27 Message 14 Tue Jun 25, 1991 OUTRIDER [Terry @ T2] at 22:05 EDT Wayne, Your computer will blow up at any time. Don't sit too close! ;^) - Terry - ------------ Category 14, Topic 27 Message 15 Tue Jun 25, 1991 TOWNS [John@Atari] at 22:19 EDT Let me clear up some misconceptions about the new Control Panel: - It _will_ work on all ST, MEGA, Stacy, STE, Mega STE, and TT Systems. Basically, if it is a TOS machine, it will run the New Control Panel. - The Configure CPX will change all of the CPX headers that you change. I just tested this. - The New Control Panel reports TOS version numbers and dates in the Status Box in the General CPX. The General CPX will report versions as they appear in the ROM. (There is a common misconception that people actually have TOS 1.4 in their machines.. They really have TOS 1.04. They mean the same thing.. however, somewhere along the line, everyone just started dropping the middle digit. Unfortunately for them, we are using that digit now) - The Shutdown option.. This will ONLY appear on machines that require it. If you have any questions, just ask away! -- John Townsend Atari Corp. PS. What do you think of this software? Inquiring minds want to know! ------------ Category 14, Topic 27 Message 16 Tue Jun 25, 1991 LRYMAL [Larry Rymal] at 23:13 EDT John, I think that the new Control Panel is great!!! It really reminds me of the Mac setup with CDEVs (Control Panel Devices) and opens up an entirely new world for us. Lots of things that used to take up accessory slots will now go as a control panel .CPX files. If anyone is confused about how versatile such a setup is, go to a Spectre GCR and ask the owner to show off his CDEVs. This is EXACTLY what we have now! I'm pretty excited about it!!! Congratulations! I think this puts us in the big leagues. Gosh, I really am impressed! (Patting Atari engineers on the back). Great job! ------------ Category 14, Topic 27 Message 17 Wed Jun 26, 1991 C.F.JOHNSON [CodeHead] at 01:10 EDT John, >> There is a common misconception that people actually have TOS >> 1.4 in their machines.. They really have TOS 1.04. They mean the >> same thing.. however, somewhere along the line, everyone just >> started dropping the middle digit. Unfortunately for them, we are >> using that digit now) So how come my "TOS 1.4 Release Notes" (straight from Atari) dated August 17, 1988, refer to that version as TOS 1.4 (not TOS 1.04) _throughout_the_entire_document_, and even specifically state that "The latest ROMs (TOS 1.4) have the version number $0104"? Come on, now!!! Atari itself referred to it as TOS 1.4. You can't change things retroactively like this, and state that "everyone just started dropping the middle digit" when ATARI ITSELF never used the middle digit until very recently. People call it "TOS 1.4" because Atari called it "TOS 1.4". Sheesh. - Charles ------------ Category 14, Topic 27 Message 18 Wed Jun 26, 1991 W.LORING1 [BL.A.ST] at 02:23 EDT Ummm, yeah, I think you're right Charles... but does it really matter? Not to me it doesn't. I certainly don't think it's worth getting as upset as you appear to be about it. ...bill ------------ Category 14, Topic 27 Message 19 Wed Jun 26, 1991 M.ALLEN14 [Mike] at 03:05 EDT My problems with MODEM.CPX and TOS14FIX are as follows: Running from NeoDesk I get 4 bombs as soon as I access the MODEM CPX. Stripping the system down (POOLFIX4, TOS14FIX in the auto, XCONTROL as the only ACC and ICDBOOT 4.8.7) I get an immediate reboot upon accessing the MODEM CPX. I understand that there is a bug in the TOS14FIX (an erroneous return) that causes bombs when you try and get the current baud rate. I also understand that it is only a 1 byte fix. I assume that the MODEM CPX trys to read the current settings when it is accessed. Sure would like the 1 byte fix like Charles Johnson gave us for HotSaver! Mike Allen ------------ Category 14, Topic 27 Message 20 Wed Jun 26, 1991 SFRT-ASST [Ken] at 03:40 EDT Just wanted to let everyone know that the version of the CPS's that shipped with my Mega STE will install in MULTIDESK. I haven't installed the new version on my system yet. ------------ Category 14, Topic 27 Message 21 Wed Jun 26, 1991 LRYMAL [Larry Rymal] at 08:49 EDT Mike, Kill TOS14FIX and you won't have the bombers. ------------ Category 14, Topic 27 Message 22 Wed Jun 26, 1991 D.A.BRUMLEVE [kidprgs] at 09:14 EDT Moreover, when I ask the ROMs to identify themselves, they report "1.4", NOT "1.04". ------------ Category 14, Topic 27 Message 23 Wed Jun 26, 1991 OUTRIDER [Terry @ T2] at 10:14 EDT John, You need to clear up that "misconception" of calling TOS 1.04 TOS 1.4 with Ken Badertscher and the rest of the Atari folks, including whoever wrote the Rainbow TOS documentation. ;^) - Terry - ------------ Category 14, Topic 27 Message 24 Wed Jun 26, 1991 C.F.JOHNSON [CodeHead] at 12:40 EDT Bill, I'm not as upset about it as that last message may have made it appear. (Once again, ASCII proves to be a poor conveyor of emotion.) But I _am_ slightly upset by Atari's latest attempt to rewrite history. For the reason why, see my message in topic 14 in this category. - Charles ------------ Category 14, Topic 27 Message 25 Wed Jun 26, 1991 WAYNED. [Wayne] at 21:06 EDT Mike, Hmmmmm that's real strange. I have Poolfix4, TOS14fix, Xcontrol and ICDBOOT (5.2.0) as well as LOTS of other stuff, and I can go into the MODEM.CPX at will. I have a Mega IV, and Tos 1.4 (or is it 1.04, not even Atari seems to know. ) As a matter of fact I just did it several times while composing this message with Aladdin. The only difference I can see is your ICDBOOT version. Maybe an update is in order? That's the only thing I can see in your setup that's different than mine. Other than that the only thing I could see would be a munged version of the modem.cpx. Maybe get a fresh version out of your archive? Hmmmmm now that I think of it I believe I did put that fix into my TOS14fix.prg. I don't remember where I saw it but I believe I did fix mine. Maybe that's why? Send me your TOS14fix.prg in Email and I'll compare it with mine to see if there is a byte different. -------- D.A. Brumleve Depends on how you 'ask' them. If you look at the actual roms with a util like MemFile (Gribnif) the bytes are 01 and 04 with Tos 1.4 (1.04), 01 06 for TOS 1.6 (1.06) and 01 62 for Tos 1.62 (1.62). Wayne ------------ Category 14, Topic 27 Message 26 Wed Jun 26, 1991 D.CHARTER at 22:03 EDT I also have the same problem with the MODEM.CPX. I am using a 4 Meg 520ST, TOS 1.04, Turbo16, mono monitor, and Supra hard drive software. I use TosFix, but it is not modified in any way. Duane ------------ Category 14, Topic 27 Message 27 Wed Jun 26, 1991 D.FLORY [ALERTsys*Cop] at 22:33 EDT Question, when you deactivate a CPX and then reload the CPXs do you get back the RAM that the deactivated one(s) were using. Like the way it all works, especially if this means we can load and unload the stuff like this. ------------ Category 14, Topic 27 Message 28 Thu Jun 27, 1991 ST-REPORT [Lloyd Pulley] at 00:56 EDT I also have POOLFIX4, TOSFIX14, XCONTROL and ICDBOOT 5.3.0 and have experienced no problems with MODEM.CPX. I also just tried it while in Aladin. ------------ Category 14, Topic 27 Message 29 Thu Jun 27, 1991 OUTRIDER [Terry @ T2] at 01:17 EDT As long as we get to change these TOS versions at will, I'd like to point out that I'm now running TOS 6.1 on one of my computers and TOS 4.1 on the other. I hope to upgrade to 20.x or 32.x eventually. ;^) To John Townsend, who asked how we like the new Control Panel -- I love it! It looks good, works good, is very friendly, etc. I'm very impressed. Of course, ICD's AdSCSI.CPX is a great selling point for it. I can't wait to see what other developers have up their sleeves. Kudos to all at Atari responsible for the new Control Panel (even if they don't know what version of TOS they developed it on ;^). - Terry - ------------ Category 14, Topic 27 Message 30 Thu Jun 27, 1991 S.JOHNSON10 [Steve] at 04:14 EDT Chuckie-Boy, Perhaps there was a lack of communication between TOS developers and other Atari personnel. I once heard "MEGA TOS" called 1.02, instead of 1.2, by a magazine writer who got most of his information in the article from a TOS development person, so I sincerely believe this is what happened. However, I _DO_ think it seems ridiculous to jump from TOS 1.06 to TOS 1.62, which seems like SOME kind of goof up. Steve ------------ Category 14, Topic 27 Message 31 Thu Jun 27, 1991 M.ALLEN14 [Mike] at 05:14 EDT Wayne - Thanks for the fixed TOS14FIX - it took care of the problem. Took them apart and found that $17d in the old one was a $75 (rts) whereas the one you gave me was a $73 (rte). Again, thanks for the fix. Mike Allen ------------ Category 14, Topic 27 Message 33 Thu Jun 27, 1991 LRYMAL [Larry Rymal] at 08:32 EDT RE: ICD's AdSCSI.CPX It's fake! Everyone keeps talking about it as if it was an April Fool's joke being pulled on somebody. Would someone PLEASE talk, bribe, threaten ICD to release this CPX to GEnie? All this talk about how great it is is like waving candy in front of a baby, or more specifically, like Atari assuring U.S. users that products are shipping. grin Please? ------------ Category 14, Topic 27 Message 34 Thu Jun 27, 1991 R.GRANT11 [Ron @ GXRSYS] at 08:49 EDT Hey, thanks, Mike! I too was having bomb city with TOS14FIX and MODEM.CPX, so I've had TOS14FIX disabled for quite some time now. Replacing that bit did the job fine! Ron Grant ------------ Category 14, Topic 27 Message 35 Thu Jun 27, 1991 BOB-BRODIE [Atari Corp] at 15:24 EDT Larry, I've got a beta copy of the AdSpeed CPX, not the AdSCSI.CPX. Is that the one that you mean?? Although I've not had any problems with it, ICD has an excellent reputation for shipping high quality software, with frequent upgrades. I'd suspect that they have a good reason for with holding it. In short, don't ask for something you really may not want to have. Remember Publishing Partner Professional? regards, Bob Brodie ------------ Category 14, Topic 27 Message 36 Thu Jun 27, 1991 BOB-BRODIE [Atari Corp] at 15:27 EDT Steve, Re the TOS numbers. I tend to agree with Charles. It is a confusing. Leonard *hates* using version numbers. To him, the original machine is TOS. Then there is Mega TOS, then STE TOS, then Mega STE TOS, and then TT TOS. Ooops, I forgot...and Rainbow TOS. :) regards, Bob Brodie ------------ Category 14, Topic 27 Message 37 Thu Jun 27, 1991 SANDY.W [RT SysOp] at 16:32 EDT Larry - You can always tell ICD yourself. They have several topics in Category 4 that they monitor regularly. ------------ Category 14, Topic 27 Message 38 Thu Jun 27, 1991 ST-REPORT [Lloyd Pulley] at 16:51 EDT Bob, But which ST TOS? 1.0 or 1.2? Which STe TOS? 1.6 or 1.62? Which TT TOS? 3.03 or 3.05? ------------ Category 14, Topic 27 Message 39 Thu Jun 27, 1991 KWERNER [Kurt] at 19:23 EDT To all; If anybody is interested, (Maybe all of you knew this and I didn't) the order that the CPX's are listed in the control panel is the same as the order that they are in the folder that you keep them in. So, you can use a folder sort utility to change the the order that they are displayed. I like to have the General and ADSCSI CPXs on top! ------------ Category 14, Topic 27 Message 40 Thu Jun 27, 1991 WAYNED. [Wayne] at 19:59 EDT Mike, Glad that fixed up your problem. Maybe there's two Tos14fix files floating around? One with the fix and one without? I don't believe the 'fix' for Tos14fix had Atari's blessings, but it worked. I don't even recall where I got that info now, but it must have been from a good source. There aren't many sources that I would take their word to go and change a byte in one of my files. ------- Ron, Ahh it worked for someone else. I guess I did the right thing by swapping that byte way back when. ------------ Wayne ------------ Category 14, Topic 27 Message 41 Thu Jun 27, 1991 M.ABDULKAREE [ASX] at 22:11 EDT I have one dislike, or annoyance, with the XCONTROL da: it hogs the keyboard just so that it can track the [RETURN] key.. THAT is very inefficient. I hope the next revision, if any, will address this problem. Current applications will not be able to read the keyboard for menu short-cuts, etc. ------------ Category 14, Topic 27 Message 42 Thu Jun 27, 1991 TOWNS [John@Atari] at 22:27 EDT Thanks, Larry.. There was a small team of programmers on this project. Some of them are even here on GEnie! As for version numbers, the only thing that matters is what is burned into your ROMs. That number is reported verbatim in the General CPX. If you have any questions regarding that number, I will be happy to answer them for you. -- John Townsend Atari Corp. ------------ Category 14, Topic 27 Message 43 Thu Jun 27, 1991 M.DORMAN2 [Mike Dorman] at 23:04 EDT John-- I like the concept, but I didn't use the old control panel, and I'm this close to disabling this one, since right now it only seems to do the same stuff (for my ST, since it ain't no STe), and it *does* seem to take dogs years to initialize...that is just subjective--of course, I'm keeping all of the .CPXs active, so that could be it... Mike. ------------ Category 14, Topic 27 Message 44 Thu Jun 27, 1991 DOUG.W at 23:13 EDT Larry, All I can say is I gave the disk to Tom to upload a couple of days ago (along with the AdSpeed stuff). He got the AdSpeed stuff uploaded, so it shouldn't be too much longer. --Doug @ ICD ------------ Category 14, Topic 27 Message 45 Thu Jun 27, 1991 S.JOHNSON10 [Steve] at 23:33 EDT BOB-BRODIE - So how does Leonard differentiate 1.06/1.6 and 1.62? Is 1.62 "STE TOS" and the former "miSTakE TOS"? I also hate "number schemes" like with most electronic music equipment. They used to be called names like Jupiter, Trident, Minimoog, Memorymoog, LinnDrum, Emulator, Mirage, etc. But now they're just given model numbers like JP-6, HR-16, P3, SQ-R, etc. They're now impersonable machines rather than "friends." Uh-oh! I just thought of something... Macintosh... Amiga... 1040ST??? Help! I'm becoming alienated from my STE! Maybe I should get a ... Stacy (ahhhh...). LRYMAL - ADSCSI.CPX is available on ICD's support BBS [(815)968-2229]. I wonder why they haven't uploaded it here yet? ------------ Category 14, Topic 27 Message 46 Thu Jun 27, 1991 ST-REPORT [Lloyd Pulley] at 23:48 EDT John, Is there anyway to change the key repeat rate to .03? I find .04 to be slightly too slow for my taste and .02 to be too fast. BTW, in case I haven't mentioned it, I'm impressed with new CPX Control Panel! ------------ Category 14, Topic 27 Message 47 Thu Jun 27, 1991 W.LORING1 [BL.A.ST] at 23:51 EDT Charles, Perhaps I did read too much into your post, but the flames have been pretty high around here lately. It gets tiresome to read complaint after complaint. All of us are responsible for this problem, and I think that we all need to step back a bit, and ask ourselves which things are really worth arguing about, and which things don't really matter. For the topic at hand, I have Tos 1.x4, and have also gotten three bombs when trying to load the Modem CPX through MultiDesk. I haven't gotten particularly scientific about it yet, but I might give it a shot tonight... ...bill @ BL.A.ST ------------ Category 14, Topic 27 Message 48 Fri Jun 28, 1991 JWC-OEO [Jon] at 00:11 EDT ???? What is it that XCONTROL offers/does than CONTROL does not for a MEGA 2 with TOS 1.4? The basic stuff that came in the ARC files seems to offer the same utility as CONTROL but at the cost of a bunch more memory. (Oh yeah, I could change MACCEL's setup via a CPX instead of having to go to the program itself, a very small gain). Everybody seems to love XCONTROL. What am I missing? Jon (still using CONTROL for now) ------------ Category 14, Topic 27 Message 49 Fri Jun 28, 1991 W.LORING1 [BL.A.ST] at 01:33 EDT Well, I tried the byte fix for TOS14FIX mentioned here... it seems to work fine. Of course, I really never had any reason to mess with the modem settings, since my terminal programs take care of this. All in all, the Xcontrol panel seems pretty neat. Now, all I need is some cool stuff to put into it... ...bill @ BL.A.ST ------------ Category 14, Topic 27 Message 50 Fri Jun 28, 1991 K.BAD [Ken @ Atari] at 03:52 EDT DaveoCop: The only memory that XControl keeps around when you're shuffling CPXs is the memory for the CPX headers. The CPX's themselves aren't actually loaded into memory until they're "opened" from the main XControl panel. The exception to this is "resident" CPXs, which we put into XControl just for floppy-only users (Hi, Mel!). When a CPX is made resident, its memory is not freed until XControl is shut down, either explicitly (using the Shutdown menu option on those machines where it is required) or automagically on newer TOS machines when you do a res change. One of the primary design objectives was to make CPX installation as painless as possible. You drag a new CPX into your CPX folder, select Reload on the Setup panel, and when you go back to the main panel, the new CPX is there, ready to use. CPX updates work similarly: XControl will check internal IDs of CPX's you have in your CPX folder and it'll use the one with the highest version number if there's a conflict. ASX: XControl doesn't do anything unusual to detect the Return key, it uses the normal GEM method of doing so. It isn't "hogging" the keyboard, but if it is the topmost window, keystrokes will go to it rather than to any application over which you may have opened it. That's what it means to have the top window. Jon-OEO: When more developers come out with more CPXs for configuring their auto- folder and driver software, you may see more to sell you. For the time being, how's this: XControl only keeps stuff in memory while you're using it, so if you never use the Printer Setup, for example, it'll never take up any memory. Even if you do use it, it'll only be loaded into memory for as long as you're using it. TOS VERSIONS: Sigh. I think there's a notable shortage of chill pills around here ;) "The" TOS version number is a two byte value, major version number followed by minor version number. So, for example, if the major version number is (in hexadecimal) $01, and the minor version number is $02, then the common computerese expression for such a version number is "one point two." If we're going to quibble, we might as well say that XControl incorrectly reports the version number of the "corrected" STE TOS as 01.62, since it should really be 1.98; after all, that's the decimal equivalent of the hexidecimal minor version number $62! Or maybe it should even be 1.b, since the ASCII value of 'b' is $62! Since we now have an Atari sanctioned utility which displays version numbers (way to go, Cary, getting that one past Leonard! ), can we agree to present version numbers the way XControl presents them? And when they're spoken, does it matter if you say "one point four" for "01.04"? Personally, I'd rather say "Rainbow TOS." So, we have: 01.00 "one point oh" or "Original TOS" 01.02 "one point two" or "BLiTTER TOS" or "Mega TOS" 01.04 "one point four" or "Rainbow TOS" 01.06 "one point six" or "oops" ;) 01.62 "one point six two" or "STE TOS" 02.0? "Mega STE TOS" (minor bug fixes differentiate the versions) 03.0? "TT TOS" (ditto) The important thing about version numbers, in terms of software compatibility, is not the TOS version number anyways, it is the version number of the OS service on which the software relies. And to (once again) paraphrase the Hitchhiker's Guide to the BIOS: The TOS version number bears no relation to reality, since Atari's version of reality differs from that of the outside world. We may make code changes without changing the version number; likewise, we may change the version number without changing the code. In short, don't write version dependent software. Glib? Maybe. But for the vast majority of software, a good rule. Personally, I could never understand this fascination with version numbers. Hey, if it works, I have the version that works, right? ...ken P.S. "XCONTROL" is short for "Extensible Control Panel" not "Extended Control Panel." That's a subtle, but very important difference. Could some SysOp-ly type kindly correct the header of this topic? ------------ Category 14, Topic 27 Message 51 Fri Jun 28, 1991 JEFF.W [RTC Sysop] at 06:36 EDT Larry - Tom has mentioned elsewhere on the BB that he'll be uploading the latest AdSCSI software to GEnie today or tomorrow. I don't see them yet, so I guess they'll be uploaded tomorrow. The AdSCSI CPX will be included with that upload. ------------ Category 14, Topic 27 Message 52 Fri Jun 28, 1991 JEFF.W [RTC Sysop] at 07:37 EDT It is done, Ken. Thanks for pointing that out. ------------ Category 14, Topic 27 Message 53 Fri Jun 28, 1991 OUTRIDER [Terry @ T2] at 09:38 EDT Ken, I agree that TOS version numbers are mostly irrelevant, but when an Atari employee suggests that that userbase has somehow dropped the '0' from TOS 1.04, even though throughout the Rainbow TOS release notes it calls it TOS 1.4, _I_ can't let it go. ;^) - Terry - ------------ Category 14, Topic 27 Message 54 Fri Jun 28, 1991 C.F.JOHNSON [CodeHead] at 11:53 EDT Ken, >> Don't write version dependent software. Gee, it would be nice if that were possible. But Atari itself, by adding new calls to new versions of TOS, has made version dependent software _necessary_. For example: how does a programmer know if the fsel_exinput() call is available, except by checking the TOS version number? How does a programmer know if wind_new() is available, except through the TOS version number? And now, with TOS 3.xx, there are quite a few AES, BIOS, and XBIOS calls that didn't previously exist. Is there another way -- besides looking at the version number -- to know whether or not these calls are available? - Charles ------------ Category 14, Topic 27 Message 55 Fri Jun 28, 1991 D.A.BRUMLEVE [kidprgs] at 12:42 EDT Is there another way -- besides looking at the version number -- to know whether a file autobooting function is available from Install Application? ------------ Category 14, Topic 27 Message 56 Fri Jun 28, 1991 D.FLORY [ALERTsys*Cop] at 19:07 EDT Thanks for the explanation, Ken. That's a good way to do it, I guess, no using of memory if the CPX is not actually used. But that brings a question in my mind, does that mean that a CPX like the modem one, or Color doesn't do anything until you select it in the CPX window? I think I'm missing something here in my understanding. ------------ Category 14, Topic 27 Message 57 Fri Jun 28, 1991 A.VALENT [Mike] at 19:38 EDT Wayne, can you upload your fixed TOS14FIX file for us. Label it "nonapproved" if you need to. I don't think Atari should object if it solves a problem without creating any new ones. ------------ Category 14, Topic 27 Message 58 Fri Jun 28, 1991 A.VALENT [Mike] at 20:09 EDT Charles - wasn't Ken referring to things like not using resolution-independent code and using undocumented methods or "features" of one particular version? Agreed that backward compatibility will be a problem as it always has been on any multiversion OS. Atari is a frustrating outfit to write for from what I can see here, but how bad is it compared to the Amiga, say? Or writing to take full advantage of a 386 or 486 while maintaining 8088 compatibility? 1.4/1.04... maybe Leonard was right and Atari should have gone with "Rock Bottom Price/Oblong Box", "RBP Square Box", "Stereo RBP Oblong Box", "Stereo RBP Cake Box", and "FX (for "*%@ing expensive") Cake Box". ------------ Category 14, Topic 27 Message 59 Fri Jun 28, 1991 D.CHARTER at 20:15 EDT Mike (M.ALLEN14) Thanks for posting how you fixed TOSFIX. I changed the byte from $75 to $73 and everything worked just fine. Duane ------------ Category 14, Topic 27 Message 60 Fri Jun 28, 1991 M.HILL13 [Mike] at 21:50 EDT Atari, Will there be any info on the CPX files released to developers? I have the developers package (Tier 2) and would like info on how to write CPX's. Any info (EMAIL if needed) would be greatly appreciated. Mike ------------ Category 14, Topic 27 Message 61 Fri Jun 28, 1991 JWC-OEO [Jon] at 22:38 EDT K.BAD OK, That's reasonable and thanks for the reply, BUT... BUT... When I boot my MEGA 2 (TOS 1.04) with CONTROL.ACC, I get free memory of ~1,700,000 bytes. When I boot with XCONTROL.ACC with CPX's that more or less duplicate its functions (COLOR,GENERAL,CONFIG,MODEM, PRINTER) I get ~1,640,000 bytes free. None of the CPXs are memory resident. When I shutdown XCONTROL, free memory increases to ~1,670,000 bytes, still less than with CONTROL.ACC. All the above memory amounts are as reported by SHOWMEM4.PRG. Similar results are reported by other programs. Again, I seem to be missing something here. I just don't know what. Jon ------------ Category 14, Topic 27 Message 62 Fri Jun 28, 1991 M.ABDULKAREE [ASX] at 23:54 EDT Steve Johnson: This is correct: Macintosh...Amiga...Atari. You probably forgot to mention something else: IIsi...A2500...MegaSTE Please, I don't like people comparing apples to watermelons and other nonsense! P.S. Leonard is probably not a systems programmer and therefore not interested in actual ROM versions. But, I may be wrong. Ken (BAD dude) @ Atari: Yes, I know how the X/C handles the input, but I'd rather have it not touch the keyboard buffer unless it is using TED Objects. For example, when I call up the X/C on the desktop, I can't issue any menu shortcuts, etc. C.F.Johnson: Re. version dependent software... Sorry, but I've heard of the Atari GEM bindings and can't use anything else.. not even the "text" mode. ------------ Category 14, Topic 27 Message 63 Sat Jun 29, 1991 W.LORING1 [BL.A.ST] at 01:31 EDT Charles and Ken, Aren't you talking about two different things? From what I see, Ken is talking about writing software that will break on a different version of TOS, while Charles is talking about software that is aware of what it is running on, so that it may take advantage of what is available. This software wouldn't break, but you might not get all the features available in other versions of TOS. An example: the 'Twister' format is available from MaxiFile only in versions of TOS that support it. The format will still work on a 1.0 system, but you can't use the 'Twister' mode. To my mind, this is not 'version dependent' software, it's 'version aware' software. There is a big difference. ...bill @ BL.A.ST ------------ Category 14, Topic 27 Message 64 Sat Jun 29, 1991 TOWNS [John@Atari] at 02:54 EDT Ken was referring to MOST applications type software... And it is possible that Libraries could check which version of TOS you have and call the appropriate call for the File Selector. In fact, I use such a call in my code. But, for most applications software.. you shouldn't need to worry about version numbers too much. -- John Townsend Atari Corp. M.HILL13: The CPX Developer's Kit is available in the Developer's RT here on GEnie. If you need further assistance, please let me know. ------------ Category 14, Topic 27 Message 65 Sat Jun 29, 1991 K.BAD [Ken @ Atari] at 05:10 EDT Dave, CPXs do get a chance to initialize things at bootup time. When XControl loads CPXs at boot time, it checks the flags in their headers. One of these flags, set by the programmer, indicates to XControl that the CPX needs to be run at boot time (for example, to set the serial port configuration, or the color palette). Some CPX's don't need to do anything at boot time, so they aren't loaded at all until you open them. Jon, It's true that XControl uses more memory than the original control panel, mainly for the built-in user interface features it provides for CPXs to use. It also allocates other memory for internal use. If you don't have the memory to spare, you should probably stick with the original Control Panel (until you find that you can't live without all the radical CPXs that developers will soon be releasing!). Charles, The AES version number (contained in the AES global array, for those who care) should be used to determine whether specific AES features are available. Other OS services can be determined by the usual documented methods; most (if not all) of the newer XBIOS services are flagged by the existence or value of a cookie in the cookie jar. Most of the time, programmers shouldn't need to concern themselves with the availability of calls like fsel_exinput(), since a properly constructed library function should handle such calls. The Lattice C binding for fsel_exinput(), for example, handles the call on all AES versions, cleverly drawing a title string above the file selector if run on an AES that doesn't support fsel_exinput() directly. Creatively constructed library functions like that free the programmer from the hassles of writing different code for each version of the OS under which their program will be run. Obviously there are exceptions, and Dorothy pointed out an important one. With a good AUTO folder GEM auto-launcher, and a DESKTOP.INF file that will auto-launch a program on TOS versions that support it, you're covered in both cases, though. What has all that to do with XControl? I dunno ;) Back to the topic at hand... I've corrected TOS14FIX and uploaded the new version as TOS14FX2.PRG so that those of you who don't like to mess with sector editors can use the Modem Setup CPX and TOS14FIX without problems. Amazing how much difficulty two wayward bits can cause, innit? ...ken ------------ Category 14, Topic 27 Message 66 Sat Jun 29, 1991 A.DIPIETRO [Anthony D.] at 10:53 EDT Hi: Is there any limit to what type of program can be a CPX? That is, could some of the programs that are currently ACCs be made CPXs and still work? I think it would be great if this could happen. Since all you would do is drag the CPX to the CPX folder and reload, this would eliminate a major hassle with ACCs. A lso, it would be _very_ MAC Sys 7.0 like in a _very_ Atari way! Finally, I think CPX is great and hope to see many more CPXs! And it runs super fast on a TT...perhaps reason alone to buy a TT :)! Anthony ------------ Category 14, Topic 27 Message 67 Sat Jun 29, 1991 M.HILL13 [Mike] at 12:52 EDT John, I thought Tier 2 developers were going to have a new area on Genie separate from the main Developers area. Is this correct? If there has been a new area set up for Tier 2 I was never notified. Of course if we have access to the main developers area please let me know as I will go there immediately. I really like the new XCONTROL and think it has a lot of possibilities. I look forward to hearing from you. Mike Hill ------------ Category 14, Topic 27 Message 68 Sat Jun 29, 1991 WAYNED. [Wayne] at 14:09 EDT Mike, Will do. I'll get to it later. Wayne ------------ Category 14, Topic 27 Message 69 Sat Jun 29, 1991 D.FLORY [ALERTsys*Cop] at 17:07 EDT Thanks for the reply, Ken, I figured it had to be like that or it wouldn't work. My thanks also, for the fairly timely release of the new TOSFIX. I'm not nervous about sector editors, but many users wouldn't know where to get one, let alone use it. ------------ Category 14, Topic 27 Message 70 Sat Jun 29, 1991 S.JOHNSON10 [Steve] at 18:37 EDT Lloyd - Well, the key repeat rate is measured in system ticks with each tick being 20ms (.02 sec) long, so it's not possible to set it to .03. K.BAD - That seems to be the answer to me -- "DON'T WRITE TOS VERSION DEPENDENT SOFTWARE!" It's always bugged me when I've run across a program that, for some reason or other, won't run on certain TOS versions. If that's so, then, theoretically, the program wasn't written correctly. There are, of course, some changes in TOS versions which sort of REQUIRE the program to be version dependent, but there are usually ways around that besides just making a program _require_ certain TOS versions. For example, why can't UIS III do twisted formatting with TOS 1.0? After all, Twister works on TOS 1.0. Steve ------------ Category 14, Topic 27 Message 71 Sat Jun 29, 1991 M.ALLEN14 [Mike] at 20:51 EDT Duane, Actually the thanks should go to Wayne. He gave me a fixed version of TOS14FIX and all I did was find the difference. Seems that such a simple fix that has been around for a while should have been publicized by Atari a long time ago! Mike Allen ------------ Category 14, Topic 27 Message 72 Sat Jun 29, 1991 S.JOHNSON10 [Steve] at 21:37 EDT M.ABDULKAREE - Yes, I know certain model numbers are IIsi and A500, but I just meant it in this sense... Apple Macintosh, Commodore Amiga, Atari ST. You were comparing model names with a company name. Mind you, Amiga USED to be a company itself until Commodore kicked the Amiga guys out (nice move, huh?). And anyway I only meant it as a joke. At least Atari has LYNX, Portfolio, Stacy, and until recently, Panther as actual names. ------------ Category 14, Topic 27 Message 73 Sat Jun 29, 1991 C.F.JOHNSON [CodeHead] at 22:19 EDT Steve Johnson, You're confused. UIS can't do "twister" formatting in TOS 1.0 because the OS call to perform that kind of formatting did not exist in TOS 1.0. The Twister program writes directly to the floppy controller hardware, which is even _more_ of a no-no than writing version dependent software. This is exactly why I pointed out that sometimes it's necessary to check the TOS version number; under TOS 1.0, if you attempt to call flopfmt() using its "skew table" option (which is the option that produces what you call "twister" formatting), the system will crash. =-=-=-=-=-=-=-=-=-=-=-=-= To all who pointed out that checking version numbers to know about OS calls was not "version dependent" but "version aware" ... you're right. I stand corrected. However, it remains true that it's sometimes necessary to check the version number for purposes like this. True version-independent software would not be able to take advantage of improvements in TOS. - Charles ------------ Category 14, Topic 27 Message 74 Sat Jun 29, 1991 R.GLOVER3 [Rob] at 22:34 EDT TOWNS: I'm very pleased that Atari finally wrote a modular control panel. I'd been considering writing one of my own, but I'm extremely lazy these days. What I would like to know is where and how can we get information on writing our own CPX modules? Thanks! Robert ------------ Category 14, Topic 27 Message 75 Sun Jun 30, 1991 DAEDWARDS at 00:23 EDT I thought about downloading XCONTROL, but a >200K file needs a much better explanation of why I want it before I'll do it. So far, the discussion here hasn't provided such an explanation. For starters: what CPX's are available !NOW!? ------------ Category 14, Topic 27 Message 76 Sun Jun 30, 1991 CHAZ at 06:34 EDT It comes with several system configuration CPX's - I haven't seen any others yet - it's a good place for system configuration stuff, but hasn't anywhere near the offerings of MultiDesk. ------------ Category 14, Topic 27 Message 77 Sun Jun 30, 1991 DOUG.W at 11:53 EDT ICD distributes two CPXs, one for use with the AdSpeed and one for use with the AdSCSI host adapters (or older ICD host adapters). These have been in distribution for around 3 weeks. --Doug @ ICD ------------ Category 14, Topic 27 Message 78 Sun Jun 30, 1991 SFRT-ASST [Ken] at 13:06 EDT SDS has a DeskJet CPX in their DeskJet Utilities Pak. ------------ Category 14, Topic 27 Message 79 Sun Jun 30, 1991 A.VALENT [Mike] at 21:18 EDT CHAZ: Insert "yet" - XCONTROL is extensible and has just been released after all. Also, XCONTROL is a desktop enhancement whereas Multidesk should be defined as an alternate desktop. Neodesk would be defined as a replacement desktop because it uses the GEM metaphor, developing it quite a bit further than Atari has so far. It's a matter either of liking GEM or wanting to distance oneself from it - largely a matter of taste. ------------ Category 14, Topic 27 Message 80 Sun Jun 30, 1991 C.F.JOHNSON [CodeHead] at 22:36 EDT Mike, >> MultiDesk should be defined as an alternate desktop... Huh? Are you sure you know what MultiDesk is? By no stretch of the imagination is it an "alternate desktop," and we certainly don't promote it that way. MultiDesk is a powerful utility that lets you load and unload standard ST desk accessories at will -- without rebooting -- and also lets you run standard DAs as if they were programs. But an alternate desktop it is not. =-=-=-=-=-=-=-=-=-=-=-=-= I wish someone from Atari would chime in here, and set people straight about the purpose of CPXs and XCONTROL. The developers' documentation is *very* clear (for a change) on this -- XCONTROL is NOT a replacement for MultiDesk, and it's not intended to be used that way. It is intended to be used for "system setting and configuration purposes" -- CPXs are much more limited in scope than desk accessories, and XCONTROL is much more limited than MultiDesk. - Charles ------------ Category 14, Topic 27 Message 81 Sun Jun 30, 1991 TOWNS [John@Atari] at 22:43 EDT Currently, the CPX Developer's Kit is only available to registered Developers. I have no idea if this will change in the future or not. -- John Townsend Atari Corp. As for the comment about MultiDesk: You are right! It's isn't close to MultiDesk.. We _never_ intended it to be! It is designed to be a Control Panel: A place where you configure and CONTROL your system. It's not designed to extend your Accessory limit.. ------------ Category 14, Topic 27 Message 82 Sun Jun 30, 1991 D.FLORY [ALERTsys*Cop] at 23:04 EDT Doug, has anyone else had the AdSpeed CPX fail to find the AdSpeed? Bearing in mind that I have one of the very early ones, beta, Gamma or something, that I paid for at Glendale and then shipped my Mega to ICD for installation. It works nicely, but there might be something different about it from the final production model. The CPX can't find it, even when I run without anything but the AdSpeed prg. in Auto and the CPX, no other .ACCs installed. ------------ Category 14, Topic 27 Message 83 Mon Jul 01, 1991 CHAZ at 01:56 EDT Mike - I don't think we're connecting (^= I'm not sure what the 'insert "yet"' thing is in reference to. Maybe I have my definitions wrong, but I've never considered MultiDesk to be a desktop replacement, though it is an enhancement. HotWire, LGFS, MaxiFile, and MultiDesk used together would probably be closer to the definition of 'desktop replacement', with CodeKeys being a CodeHead Desktop Enhancement (^= ------------ Category 14, Topic 27 Message 84 Mon Jul 01, 1991 DOUG.W at 07:48 EDT Dave, The problem you're seeing only occurs on old AdSpeeds. I'll send you a new version of the CPX soon. --Doug @ ICD ------------ Category 14, Topic 27 Message 85 Mon Jul 01, 1991 BOB-BRODIE [Atari Corp] at 17:24 EDT Doug, Send it to me, too. I've got the same problem. The CPX *and* the special version of Quick ST both don't recognize that the AdSpeed is installed. The 16Mhz prg and AdSpeed PRG work find. oops, make that fine. Gotta run! ------------ Category 14, Topic 27 Message 86 Mon Jul 01, 1991 S.JOHNSON10 [Steve] at 18:32 EDT There's also supposed to be a CPX for FSM GDOS if it ever comes out. ------------ Category 14, Topic 27 Message 87 Mon Jul 01, 1991 D.FLORY [ALERTsys*Cop] at 19:03 EDT 'S ok, Doug, I just wanted to make sure that was it, and not something you folks hadn't seen yet. ------------ Category 14, Topic 27 Message 88 Mon Jul 01, 1991 M.HILL13 [Mike] at 22:43 EDT John, Maybe Im not wording it correctly. I am a registered Tier II developer and want to know if the CPX developers kit is available to me? Mike ------------ Category 14, Topic 27 Message 89 Tue Jul 02, 1991 TOWNS [John@Atari] at 00:17 EDT Actually, there will be a couple of CPXs for FSMGDOS. They will make GDOS _much_ easier to manage. -- John ------------ Category 14, Topic 27 Message 90 Tue Jul 02, 1991 TOWNS [John@Atari] at 01:17 EDT Mike, I have no idea. I don't know the differences between the tiers. We just make the stuff available and then the Developer's Support Group decides where it goes. To my knowledge tho, the information should be available to all registered developers. -- John Townsend Atari Corp. PS. Check with Gail Johnson at (408) 745-2168. ------------ Category 14, Topic 27 Message 91 Tue Jul 02, 1991 K.BAD [Ken @ Atari] at 05:00 EDT This message is Copyright (C) 1990,1991 by Atari Corporation, All Rights Reserved. Below is an excerpt from the XControl developer documentation. I wrote this, and as Charles said, I tried to be very explicit in describing just what a CPX should be. I'm posting this here so that everyone has a clear idea of just what a CPX is supposed to be. It's clear from some of the CPXs that have already been released that some developers have been reading and heeding this information. A hearty well-done to ICD and SDS for the CPXs they have released. Unfortunately, it's also just as clear from some other CPXs I've seen which have yet to be released that some developers are ignoring these guidelines. A lot of thought and discussion went into these guidelines, and I'd be happy to discuss details, answer questions, and expound on the rationale behind the guidelines in another topic. Without further ado... -=-=-=-=-=- CONTROL PANEL EXTENSIONS The concept of what constitutes a CPX is very important to the implementation of the extensible Control Panel. A CPX is effectively a subroutine call. It is neither an application nor a desk accessory, but only a means for setting system parameters. Examples of CPX functions include: - Color Selection - Keyboard/Mouse configuration (repeat rate, audible keyclick, etc.) - RS232 port configuration - Printer configuration Note the key word "configuration" in most of the above functions. A printer driver does not belong in a CPX, but the ability to configure a TSR printer driver would be a good thing to have in a CPX. The key concept to keep in mind here is that of the "Control Panel" - the one place where a user goes to toggle switches, press buttons, or whatever, to "control" the functions of the computer. Obviously, it is silly to have a CPX which controls the operation of a desk accessory, Instead, CPXs should primarily be used as graphical front ends for TSR utilities. -=-=-=-=-=- For once, I agree with Charles completely... XControl is not meant in any way to be a "MultiDesk Jr." Unfortunately, because we made CPXs so easy to program, it is a great temptation for CPX programmers to bend the rules and write Control Panel extensions that have nothing to do with "controlling" anything. I have just two words for those enterprising programmers: please don't. ...ken ------------ Category 14, Topic 27 Message 92 Tue Jul 02, 1991 M.JONES52 [Jonesy] at 05:44 EDT John, That's _real_ good news. ------------ Category 14, Topic 27 Message 93 Tue Jul 02, 1991 A.VALENT [Mike] at 07:09 EDT Sorry, Charles. What was I thinking of? Hotwire? OK, hwat are the categories? Desktop enhancements, desktop replacements, alternatives to the desktop... Back to sleep now. ------------ Category 14, Topic 27 Message 94 Tue Jul 02, 1991 M.SQUIRE [Mike] at 22:18 EDT Written on: Tue, Jul 02, 1991 at 20:44 EDT ~~~~~~~~~~~~ Joey, Doug W., Steve Johnson, & Wayne, It was unclear to me from the documentation that comes with XCONTROL as to whether or not I even needed a DESKTOP.INF file now that I was using XCONTROL instead of CONTROL and/or CONTROLE. After all, the only purpose of DESKTOP.INF is to supply information to CONTROL/CONTROLE or some other read- only Control Panel accessory. I imagined that XCONTROL might store this information elsewhere, such as the CONTROL.INF file or in an individual CPX file. Thanks for your response though. I wanted to raise the question and see what the consensus of other folks was on this matter. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Townsend, I really like XCONTROL and am glad that Atari decided to make it available to TOS 1.04 users such as myself. What I really like about the software is its modular design that should allow for easy expanability that will allow it to grow as new capabilities come into being for the ST. It did take a little work to poke around XCONTROL to see what it was capable of on my system, but I consider that time well spent. ... Mike Squire ------------ Category 14, Topic 27 Message 95 Tue Jul 02, 1991 CRAIG.S.THOM at 23:01 EDT No, desktop.inf supplies a lot of information for the desktop, like what icons are present and what there names are, what file extensions are valid for executable files, what installed applications are present and what are the extensions that make them go, what windows are open at boot and what their sizes are, etc. Lots of non-control panel things. ------------ Category 14, Topic 27 Message 96 Wed Jul 03, 1991 M.EVERHART2 [MIDIMIKE] at 02:00 EDT I've been using the Extensible Control Panel and haven't quite been able to figure out what information is stored where. To run NOTATOR, I have to disable the cache - this seems to be stored in the GENERAL.CPX itself. The information on icons and desk setup is in the NEWDESK.INF. What the heck is in CONTROL.INF? ------------ Category 14, Topic 27 Message 97 Wed Jul 03, 1991 CGEE at 12:43 EDT The CONTROL.INF file contains 1) The path where the CPXs are located. 2)Whether the clock will display 12 or 24 hour time. 3)The minimum number of free slots to have available for additional CPXs once booted. ------------ Category 14, Topic 27 Message 98 Wed Jul 03, 1991 LRYMAL [Larry Rymal] at 20:13 EDT Mike, I too enjoy XCONTROL and think that it is as major of an advancement for the ST as the introduction of the hard drive back in 1986 was. I'm just trying to stress a point. This tiny accessory really adds some fantastic expansion and advancement capabilities to the ST. Explore the CDEV's on a well-used Mac. These are similiar to our Control Panel Extensions. Without the CDEV's, the Mac can be rather limited. Well, the ST has come a long way WITHOUT XCONTROL, more so than the Mac could have, in my opinion, without the CDEV's. Gosh, it's going to be amazing what's going to happen to the ST now with XCONTROL. I'm at the point that I keep searching for *.CPX's in the downloads. This is really some exciting stuff! ------------ Category 14, Topic 27 Message 99 Thu Jul 04, 1991 R.GREGORY4 [Rob] at 19:30 EDT Many thanks to Atari Corp. and all involved in getting out the new Control Panel! It's got everything that I needed... now I'll just have to get greedier! Rob ------------ Category 14, Topic 27 Message 100 Fri Jul 05, 1991 J.ALLEN27 at 04:31 EDT You might want to check on Xcontrol vs Timeworks DTP compatibility. There seems to be a problem...crashola. ------------ Category 14, Topic 27 Message 101 Fri Jul 05, 1991 TOWNS [John@Atari] at 17:17 EDT Hmm.. Jim any chance you could be more specific? Do you just have to load Timeworks Publisher ST to make it crash? What version of GDOS are you using? etc.. Any answers you can provide can assist us in fixing the problem. In the meantime, I'm off to find Publisher ST to see what I can find out. -- John ------------ Category 14, Topic 27 Message 102 Tue Jul 16, 1991 MIKE-FULTON [Mike @ Atari] at 00:49 EDT M.HILL13 If you are are a registered developer, look for Xcontrol programming info in the ATARI.RSC roundtable. ------------- M.SQUIRE The DESKTOP.INF is indeed used by the original Control panel accessory and VT- 52 Emulator/RS232 config accessory. However this is not the only use of the DESKTOP.INF file. It is also used by the desktop itself to store the location of screen icons, open windows, and installed applications. Xcontrol on the other hand, is designed so that the CPX modules can save their configuration information within themselves, rather than needing a separate configuration file. The Xcontrol module itself uses a separate configuration file, named CONTROL.INF, to tell it how many CPX slots to reserve, the format for the clock, and where the CPX modules are located. Mike ------------ Category 14, Topic 27 Message 103 Wed Jul 17, 1991 M.CHANDLER [Matt] at 23:02 EDT Just a couple comments: I noticed that the options for Xcontrol are Save, OK or Cancel. This is fine, but I wish that the control panel would close after making an adjustment. It would be nice if by pressing a shift key while selecting either Save, OK or Cancel, the control panel would do it's thing, then close. This would be nice especially using medium resolution, as the 'close window' box is located very close to menu windows (I keep hitting them instead). But, I think the medium resolution control panel display is _much_ better, as it's more than twice as big as a hi-res display, and so much easier to work with. The hi-res display looks kind of crushed. If you are a hi-res user, and ever get a chance, look at the panel in medium res! Also, I am in desperate need of a corner clock display .cpx , and I'd bet others would like one too. I've searched GEnie, and could not find -any- type of corner clock (display) program. Matt Chandler ------------ Category 14, Topic 27 Message 104 Thu Jul 18, 1991 SFRT-ASST [Ken] at 13:58 EDT I use the Corner clock in Hotwire (which also has a caps lock indicator) you can set it to appear or not appear in different programs from its Hotwire menu line. ------------ Category 14, Topic 27 Message 105 Thu Jul 18, 1991 TOWNS [John@Atari] at 18:28 EDT I use a Desk Accessory called Idle written by Eric Rosenquist of STalker/STeno fame. It's available in the library. I think you will really enjoy it. -- John Townsend Atari Corp. ------------ Category 14, Topic 27 Message 106 Thu Jul 18, 1991 M.CHANDLER [Matt] at 23:43 EDT Ken, thanks for the tip on a corner clock (via Hotwire). --------- John, Thank you very much. I want to use the new xcontrol .acc (don't want two or more control panels installed for a corner clock) so that'l be great! I'm so used to telling time with my computer that I miss it very much. Matt p.s. I've searched far and wide for a corner clock. Can't wait to see the keywords that Idle used :*) ------------ Category 14, Topic 27 Message 107 Fri Jul 19, 1991 R.QUANCE [Rob] at 20:48 EDT Could we get a list of possible CPX's? I'm curious what I can do with the thing and what its limitations are. Rob... ------------ Category 14, Topic 27 Message 108 Fri Jul 19, 1991 C.F.JOHNSON [CodeHead] at 22:34 EDT Hiya folks. Just wanted to post a mild warning about that package of five (six?) German CPXs that was posted in the library here recently. Seems the formatting CPX has a rather inconsiderate habit of _formatting_your_disk_instantly_ as soon as you click its OK button, or hit Return. Tsk tsk. Not good to blow away Joe User's disks without warning. Bad, bad programmer. Not to mention that some (not all) of the CPXs in this package seem to be violating the documented rules about what a CPX can and should do. The ones that configure Hypercache and NVDI are good examples of "right-thinking" CPXs. But an ASCII chart and a calendar are not good uses for the CPX capability. Someone from Atari, please, correct me if I'm wrong here. I don't mean to preach, people ... but I think that since Atari documented the purpose and implementation of CPXs very well, developers should make every effort to adhere to that documentation. And am I the only one who thinks it's a bit silly to use pop-up menus everywhere, even when there are only two or three choices in them? Think about it: if you use radio buttons, their current state is visible and it only takes one click (as opposed to two clicks) to change them -- two BIG advantages of radio buttons over pop-ups. - Charles ------------ Category 14, Topic 27 Message 109 Sat Jul 20, 1991 WAYNED. [Wayne] at 09:51 EDT Charles, Yep I found out the hard way about the German CPX Formatter. Trashed my boot disk. No big deal since the only thing on my boot disk was Duck which just waits x seconds and reboots until the HD takes over on the boot. Hey don't take the harmless ASCII table away from me! :-) It simply provides the user with what some would call necessary info. Besides it's the only thing in that whole German CPX package I found worth anything. Wayne ------------ Category 14, Topic 27 Message 110 Sat Jul 20, 1991 C.F.JOHNSON [CodeHead] at 14:59 EDT Wayne, I'm not trying to take the ASCII table CPX away from you (even if I could!). :) My point is that it should be a desk accessory, NOT a CPX. Those kinds of utilities are simply not what CPXs are supposed to be. Even if it weren't against the rules, it's _silly_ to write an ASCII table that can only use XCONTROL's very limited screen space; I don't know about others, but I like to see as much of a table at one time as possible. - Charles ------------ Category 14, Topic 27 Message 111 Sat Jul 20, 1991 J.SPANDE [John Spande] at 17:29 EDT I'd like to second what Charles said about the use (abuse) of pop-up menus when buttons would be easier. We sure don't need to start a trend toward gimmicking up our user interface until it is as difficult and inconvenient as Windows! ------------ Category 14, Topic 27 Message 112 Sat Jul 20, 1991 TOWNS [John@Atari] at 19:06 EDT I agree with you Charles.. Also, the only time you should use a PopUp menu is when you have space constraints or you have more than two items to choose from. These are ideal times to use a PopUp. Believe it or not.. there are some CPX modules that aren't limited by the space. Unfortunately, we had to use this size space.. As Atari we can't simply ignore or forget that ST Low Resolution exists. We have to support it. -- John ------------ Category 14, Topic 27 Message 113 Sat Jul 20, 1991 A.DIPIETRO [Anthony D.] at 19:33 EDT Hi: I'm getting a "File I/O error" when I go to save defaults. I don't recall this happening before. I have a TT with TOS 3.05. Any ideas why? Anthony ------------ Category 14, Topic 27 Message 114 Sat Jul 20, 1991 J.ALLEN27 at 21:11 EDT Thanks for the warning Charles!!!! ------------ Category 14, Topic 27 Message 115 Sat Jul 20, 1991 ST-REPORT [Lloyd Pulley] at 22:20 EDT Charles, And I'm one that uses the ASCII CPX but wouldn't use and ASCII.ACC. I don't need it bad enough to tie up memory all of the time with an acc- essory, but it is nice to be able to pull in when I need it. My opinion about the XControl Panel is, if it works and doesn't inter- fere with anything, I see no harm in it. ------------ Category 14, Topic 27 Message 116 Sat Jul 20, 1991 M.PERDUE [Mario] at 23:42 EDT Charles, I couldn't agree with you more. An ASCII table just doesn't belong in a CPX. I could understand this sort of thing being developed if Atari hadn't bothered to document what a CPX is supposed to be. But in this case they did a pretty good job of defining the rules. Hopefully people will follow the guidelines in the future. Mario ------------ Category 14, Topic 27 Message 117 Sun Jul 21, 1991 J.H.CARROLL [Jon] at 01:57 EDT Well I'm usually the biggest fan of standards and the like but in this instance I'm going to (maybe selfishly) side with Lloyd. I like the ASCII table. I would not devote the space to an accessory form of it and enjoy being able to devote the space to it only when I want to. I own MultiDesk and could come close to the same thing but Xcontrol sidesteps the necessity of actually manually loading in modules because the title appear whenever you bring up Xcontrol. Jon ------------ Category 14, Topic 27 Message 118 Sun Jul 21, 1991 J.ALLEN27 at 02:51 EDT It's just a matter of philosophy, on the Mac there are guidelines and folks adhere to them, or their programs are swimming up stream. The control panel, is a panel for controls....anyone needed to control some ascii conversion codes lately? ;-) Those unruley little codes, if I catch them they're in for a wooooopin'!!! A perfect example: The Turbo030 has a bunch of OS speedup patches, some can cause incompatibilities, so they need to be switchable, also there is a data and instruction cache, and whether they are burst filled, and a few other goodies. All this stuff needs controlling, so we have a CPX to control them. Makes sense, but sticking everything AND the kitchen sink in there doesn't make sense....even if it's cute. And I looked a the German CPXs, they need some style, some peeezazzz ;-) ICD's CPX looked real nice...typical ;-) For once Atari has asked for compliance with a human interface standard, so comply. Uniformity in certain circumstances, although not easy for humans (especially Americans), is a positive thing. ------------ Category 14, Topic 27 Message 119 Sun Jul 21, 1991 WAYNED. [Wayne] at 09:47 EDT I too agree with Lloyd. While I find the ASCII.CPX useful I wouldn't find it *as* useful if I had to give up that memory when it wasn't in use. I have seen several .ACC's that do the same thing, but don't use them because I'd have to give up that memory full time in order to use them. Wayne P.S. OH NO!!! I agreed with Lloyd? Surely I'll be struck by lightning any second now! :-) Hmmmmm that might not be a bad thing. Perhaps it would bring some rain and break this heat wave? Yeah, Yeah that's the ticket. I agree with Lloyd, I think Lloyd is ALWAYS right, if Lloyd has ever been wrong may I be struck by lightning! (thumbing nose at the sky) :-) ------------ Category 14, Topic 27 Message 120 Sun Jul 21, 1991 M.PERDUE [Mario] at 12:41 EDT Jim, Well said. It's simply a matter of using the right tool for the job at hand. Yes, it is possible to use CPX's for any number of things. You can also use a ratchet to drive nails, however I wouldn't suggest that you do it. Mario ------------ Category 14, Topic 27 Message 121 Sun Jul 21, 1991 OUTRIDER [Terry @ T2] at 12:45 EDT Charles, I wasn't paying attention to the names, since they are in German, and found out the hard way about that disk formatter! I quickly popped out the disk and didn't lose any data, though, so it must format in reverse, ala MaxiFile. As for those pop-up windows, no, you're not the only one who thinks they're a bit silly, not to mention annoying. They seem to be more for window dressing than for ease of use. ------------------------------ Wayne, Interesting that you trashed your boot disk. Only thing I have on my boot disk is COLDBOOT.PRG in an AUTO folder and an empty DESC folder (for transferring file descriptions to my BBS). Neither seemed to be affected. I ran CleanUp, which found no data errors, though it found a new bad sector that wasn't being used. - Terry - ------------ Category 14, Topic 27 Message 122 Sun Jul 21, 1991 J.ALLEN27 at 12:46 EDT So THAT'S why I keep bending the nails. Thanks Mario ;-) ------------ Category 14, Topic 27 Message 123 Sun Jul 21, 1991 M.HILL13 [Mike] at 14:22 EDT Charles, I agree with you on the German CPX's in most of your statements. As for the Ascii chart thats a good question, but then again ICD CPX has a chart of SENSE Codes. The two tables are only for reference so should they be in a CPX? I dont like the calendar or formatter though. Im waiting for someone to try to put a breakout game in a CPX! Mike ------------ Category 14, Topic 27 Message 124 Sun Jul 21, 1991 REALM [Joey] at 15:22 EDT "...right tool for the job..." Mario, you trying to set a bad example for the rest of the world!:-) I was told to pound in nails with my fist in order to save time walking to the stock room. It's better to spend three hours using the wrong tool then five minutes using the right tool. Spend a dollar to save nickel, Quantity job one, third times a charm! Sorry, I get a little carried away on that topic. If Atari sets down guidelines, developers should follow them. I see a lot of people complaining now that software doesn't work correctly on their Mega STe or the TT. Most of it games and other stuff that didn't need to follow the guidelines. Of coarse Atari takes the blame for it since they obviously changed something that broke the software. ------------ Category 14, Topic 27 Message 125 Sun Jul 21, 1991 ST-REPORT [Lloyd Pulley] at 16:27 EDT Joey, Guidelines are just that, guidelines. They're not set-in-stone rules. As long as the CPX works properly and does not interfere with anything else, I can see no harm it. If the CPX does not follow the guidelines and 'breaks' something, then Atari can complain. It's like UIS 3.3 and LG File Selector. LGFS follows the rules and is closer to what Atari wanted out of an Item Selector. But that doesn't mean that UIS 3.3 is wrong.....it just added more features and 'pushed the envelope'. You (generic 'you') can complain all you want about guidelines/CPX's, but you might as well get used to the idea that there is going to be more and more CPX's similar to the Germans'. I'm waiting for one that has some of the features of the old XUTIL.... that will allow me to re-configure my keyboard from the CPX. ------------ Category 14, Topic 27 Message 126 Sun Jul 21, 1991 C.F.JOHNSON [CodeHead] at 19:27 EDT Lloyd, That comparison is ridiculous. The situation with CPXs and DAs is nothing at all like the situation with LGS and UIS. The important difference is that there are no rules for "how an item selector should behave"....but there are indeed rules that CPXs should follow. You said: >> Guidelines are just that, guidelines. They're not set-in-stone >> rules. Sorry, but that's just wrong -- there _are_ "set-in-stone" rules about how CPXs should behave, and what they can and should do. I'm not trying to enforce these rules; it doesn't honestly matter to me whether or not any given programmer chooses to follow the rules. (I'm not the "purist" you're trying to picture me as.) But I do think it's appropriate to point it out when something violates the clearly stated CPX specification. For too long, Atari has had too few rules like this; as a result, programmers have been forced to improvise and come up with their own techniques in way too many situations. It's a shame that now, when Atari _has_ documented the CPX spec, people are immediately starting to violate it. Standards and rules help operating systems remain usable and expandable. - Charles ------------ Category 14, Topic 27 Message 127 Sun Jul 21, 1991 WAYNED. [Wayne] at 21:18 EDT Charles, I too applaud Atari for setting some controls on what a CPX can/should be. It's definately something that should be done and would have eliminated (or drastically reduced) many of the problems of 'x' program not running under 'y' version of TOS because the programmer either broke what few rules Atari did lay down, or wasn't given the rules by Atari in the first place. Some of the blame for the broken rules on the CPX's must go to Atari though. Old habits are hard to break and when developers get used to either breaking the rules, or not even having any rules it's hard for them to stop. :-) There's nothing Atari can do about their old 'non' policies, and as I said I do agree with them setting down some rules/guidelines. I say keep it up and as time goes on the violators will decrease and compliance will increase. Another aspect that I feel is responsible is that there are very few active (legal) developers for the Atari machines. Hence there are alot of people out there with Assemblers, C, GFA, etc that are trying to create things they want/need to make their machine serve their needs. Since they either can't afford to, don't want to, or don't qualify to be developers they don't even know the 'rules' since Atari will only show the rulebook to registered developers. The # of these types FAR outnumber the registered developers IMHO. I know I'm one of them. I have written many little things for myself and a few for FoReM BBS use by SysOps. One was shareware (got one registration) and several freebies. Wayne ------------ Category 14, Topic 27 Message 128 Sun Jul 21, 1991 ST-REPORT [Lloyd Pulley] at 22:34 EDT Charles, In my opinion.... I'll concede that Atari didn't make the XControl panel to do these non- configuration functions.....but they should have. There is obviously a need for a program like XControl (that's callable from any GEM program) that will load/unload CPX type files as the user needs them. With more and more programs becoming larger, many people just don't have the mem- ory to waste having an ASCII table (one example only) as an accessory all the time. With a program like XControl, they now have the ability to load/unload these minor, but helpful, programs at will. I have 2-3 CPXs setup (ones that don't follow Atari's guide-lines) that I find very helpful...but not helpful enough to waste 30-100k of memory on comparable accessories. I _personally_ am rooting for all of the developers who 'push the enve- velope beyond Atari's limited guide-lines and give the users what they want and NEED. ------------ Category 14, Topic 27 Message 129 Sun Jul 21, 1991 LRYMAL [Larry Rymal] at 22:36 EDT I would like to echo what Wayne is saying. With such few developers out there (but, isn't it great that the ones we have do such a FINE job!), it is hard to know what is valid and what is not. An amateur programmer normally can find, at his book store, programmer's reference guides and technical manuals. We have none of that! Oh, by searching the mail order companies, Computer reference manuals can be found for programming, but technical docs for the ST are rare for the amateur. Yes, the "hobby" developer docs exist from Atari, but $100 plus is steep for the "shade tree" programmer. If we had something like "Inside the Atari ST/TT" for the same price as the "Inside the Mac", then things would be a bit easier. So, I would certainly hope that an amateur ST programmer won't have his contribution clouded up and rained on because of some theme or aesthetic guideline that is unknown to him due to the lack of technical manuals. ------------ Category 14, Topic 27 Message 130 Sun Jul 21, 1991 LRYMAL [Larry Rymal] at 22:43 EDT Lloyd, Here! Here! Gosh, even *I* am agreeing with Lloyd! This is a new experience for me! Now then, if someone could show how to write CPX's in GFA Basic. ------------ Category 14, Topic 27 Message 131 Mon Jul 22, 1991 ST-REPORT [Lloyd Pulley] at 01:27 EDT Larry, Hmmm...there's getting to be too many people agreeing with me recently. That must mean that I'm wrong and need to change sides! ------------ Category 14, Topic 27 Message 132 Mon Jul 22, 1991 SFRT-ASST [Ken] at 01:51 EDT Perhaps Atari can offer a new class of Desk Accessory? They've created a new Control Panel. Is it as hard as I imagine it is to create a New Accessory Panel that keeps compatibility with old software but is more memory efficient and flexible? ------------ Category 14, Topic 27 Message 133 Mon Jul 22, 1991 S.JOHNSON10 [Steve] at 02:14 EDT C.F.JOHNSON - Maybe if EVERYONE had some good documentation on how to write CPX modules, there wouldn't be problems such as these. Atari certainly can't expect EVERYONE who wants to write ST programs to be able to become a registered developer just to get all the 'programming guidelines'. Steve ------------ Category 14, Topic 27 Message 134 Mon Jul 22, 1991 C.F.JOHNSON [CodeHead] at 02:26 EDT It is not possible to write a CPX without having the documentation; there's too much very specific knowledge involved. But what the heck, you guys are right ... I think it's just great for everybody to go ahead and break all the rules and write CPXs that do just about everything. Hey, why not just throw out all the books and start writing position-dependent programs that rely on jumping to hard addresses in the ROMs, too? I don't know what came over me...actually advocating following the rules. Sheesh. - Charles ------------ Category 14, Topic 27 Message 135 Mon Jul 22, 1991 DAEDWARDS at 04:13 EDT Here's my opinion on "inappropriate" CPX's. Defining how a certain class of program may work, is essential to maintaining an operational, effective, flexible, and expandable system. Ataris' efforts in this direction are reasonable (or maybe insufficient. :-) Defining what a certain class of program may be for, is essential to PREVENTING operational, effective, flexible, and expandable systems. I think you can figure out what I think of Atari's efforts here. ------------ Category 14, Topic 27 Message 136 Mon Jul 22, 1991 DOUG.W at 07:43 EDT Hey Charles, an idea has been presented here that I'd *REALLY* like to see. How 'bout a version of MultiDesk which can dynamically load and unload accessories on the fly when they are selected. I know that such a project has a number (large number) of pitfalls, but I think it still might be do-able and it'd eliminate a lot of the "arguments" posted here. --Doug ------------ Category 14, Topic 27 Message 137 Mon Jul 22, 1991 C.F.JOHNSON [CodeHead] at 12:02 EDT Doug, If it were doable, MultiDesk would be dynamically loading and unloading accessories already. I've examined _many_ possible schemes for doing this, and they all fail when confronted with DAs that grab interrupt vectors -- that's the "pitfall". (Actually more like a bottomless pit.) If you have an idea you think might work (chances are it's been considered and discarded already), send it to me in the CodeHead beta category and we'll talk. - Charles ------------ Category 14, Topic 27 Message 138 Mon Jul 22, 1991 REALM [Joey] at 18:50 EDT "Generic 'you'!" that cracks me up!:-) You(generic kind:-]) can offend me all you want I'm just here to discuss things. If I say something stupid speak up...after all I'm not following any guidlines. Speaking of guidlines... Who's for driving on the left side of the road, eating with our feet and just behaving like Ned Neanderthal? We're only following Social guidelines, nothing etched in stone. I think I should clarify a little. I don't care what the CPX does as long as it follows the technical guidlines of how a CPX should operate. In other words, I want the thing to work like it suppose to without having it interfer with other programs and all the other stuff that happens when little tricks are used. ------------ Category 14, Topic 27 Message 139 Mon Jul 22, 1991 LRYMAL [Larry Rymal] at 19:05 EDT Charles, I'm just a "Dumb Joe End User", but surely the exhilaration over the recent .CPX's is not an advocacy of passing over standards. However, just from the point of view here, I'd like to see CPXs that could take the load off of the accessory slots. Programs such as ButtonFix, lots of the DC utilties, screen accelerators, and so forth take up needed slot space that is not appropriate within MultiDesk. With the new multitasking MultiGem or whatever that program is called, I need all the accessory slots that I can get. MultiDesk fills most of my needs, as you know from talks on the "other" service, but surely the .CPX's could free up some slot space that MultiDesk is not meant to handle. For example, I have DC RightCall, DC Formatter, TurboST, and PopIt! in four of my accessory slots. I use NeoDesk. I'm not sure why DC Formatter gives me fits from within MultiDesk (My DC Formatter might be at fault, it is rather old), but I know the other mentioned accessories would probably be more approriate as .CPX's, in my opinion. ButtonFix would be another. As far as MultiDesk is concerned, I've got so much junk crammed in there that I have to use your scroll arrows to get to everything. I'd have a very boring machine without MultiDesk. I still marvel that all these things, from so many of you good programmers actually work together. Hence, the need for standards, right? But am I on target about my concept of the aforementioned programs being converted as .CPX's? If so, instead of a blitz of new .CPX's coming out, I'd like to see some conversions done of accessories such as what I just mentioned into .CPX's. ------------ Category 14, Topic 27 Message 140 Mon Jul 22, 1991 D.FLORY [ALERTsys*Cop] at 19:05 EDT Doug, in a way you already have that by installing .MLT files in HotWire, and/or using CodeKeys. New .ACC setup a keystroke away. Not generally recommended to do from another program, but I'm sure you know all this anyway. ------------ Category 14, Topic 27 Message 142 Mon Jul 22, 1991 A.FASOLDT [Al Fasoldt] at 20:51 EDT Terry, The German CPX formatter *does* format in reverse order like the one in NeoDesk. You can see the track numbers decrementing as it goes to work. (Ummm, in German the numbers are the same as in, ummm ... this is maybe too silly to add ... umm, English.) Al ------------ Category 14, Topic 27 Message 143 Mon Jul 22, 1991 J.NESS [Jim] at 22:28 EDT Steve Johnson - You got it. Atari DOES feel that everyone who wants to write software for the ST should become a developer. They do, however, have a blue light special package, in which you get all the docs, but not any updates. Instead of a high, one time fee, you pay a moderate annual fee. That middle ground was actually a giant step for Atari, although, cheap as I am, I still did not jump at it. I questioned paying the full annual fee the second year, when all you would expect to receive would be a small packet of updates. I think they base the cost on their offer of phone and online support. Maybe they overestimate how much of this would be necessary. -JN ------------ Category 14, Topic 27 Message 144 Mon Jul 22, 1991 DOUBLE-CLICK at 22:41 EDT RE: The GERMAN formatter. If you click on the SICHER box, it will prompt you before formatting. You can save that default option. RE: What CPXs should or shouldn't do... John and Ken are probably going to hate me for this one, but... Let's start off with an absurd example: A hammer is for hammering nails, but that doesn't mean it can't be used to kill someone. The various routines avilable through Xcontrol are very well documented. And, it is agreed that certain things can't/shouldn't be done with a CPX (stealing vectors) due to it's design. DC Right Call or DC Popbar or ButtonFix can not be done with the available routines in Xcontrol. Staying within the guidelines of the prescribed routines, none of the above three DAs could be CPXs and still allow Xcontrol to function properly. However, something like DC Formatter could be a CPX. It would not need to break any of the defined routines or perform any type of hack in order to work as defined by the CPX routine specifications and limitations. The ASCII chart is an example of a CPX which adheres to the rules of the CPX routines, and as such, does work with the CPX and does not break anything. Personally, we find it ludicrous to provide routines which _obviously_ can be used to perform various functions beyond the specification as put forth, but to say to anyone developing a CPX that you can not use that function beyond its original intended purpose, even though it would work and it would not be a violation of the routine specification. Providing a tool with infinite possibilities and then attempting to limit the scope to which it is used is preposterous. If the pure intent of CPX was to provide only resident program control, or system control, then more care should have been taken to limit the applicability of the CPX routines. For the record, we believe that just so long as the CPX routine specifications are not broken, then they should be used to the ultimate flexibility they provide. It is one thing to provide a routine and document its limitations, it is another to dictate the scope to which it can be used within those limitations. - mike vederman member IAAD - to serve and protect the atari community ------------ Category 14, Topic 27 Message 145 Mon Jul 22, 1991 M.SQUIRE [Mike] at 23:10 EDT Mike Fulton, Thanks for the info on XCONTROL's relationship to DESKTOP.INF and CONTROL.INF. ... Mike Squire ------------ Category 14, Topic 27 Message 146 Tue Jul 23, 1991 TOWNS [John@Atari] at 00:21 EDT Don't worry.. Charles. We included the concept of the CPX ID so that we could search for inappropriate CPX modules in a future revision and make sure that they never get loaded. :-) THIS IS A JOKE. I'M JUST KIDDING. Although, I feel this is what should be done with people who don't follow the rules. As for good documentation, well.. writing a CPX without the CPX documentation is IMPOSSIBLE. I would like to see someone try. -- John ------------ Category 14, Topic 27 Message 147 Tue Jul 23, 1991 J.ALLEN27 at 00:22 EDT Isn't "to serve and protect the Atari community" on the sides of the Police cars in Sunnyvale? ;-) ------------ Category 14, Topic 27 Message 148 Tue Jul 23, 1991 LRYMAL [Larry Rymal] at 01:36 EDT Mike, I find it disappointing that programs such as ButtonFix or DC Right Call cannot be done with the available routines in XControl. Boy, did I misinterpret what can or cannot be done. I sure wish there could be a way to free up the accessory slots from excellent utilities such as those. In spite of programs such as MultiDesk, we still run out of accessory slot space. sigh Thanks, Mike. You folks do a great job! ------------ Category 14, Topic 27 Message 149 Tue Jul 23, 1991 MUSE [Tomas] at 01:52 EDT Al, the numbers aren't the same in German, but the numerals are. ------------ Category 14, Topic 27 Message 150 Tue Jul 23, 1991 F.BELL1 [Frank @ Home] at 12:05 EDT Charles, There you are wrong. The first few private (German?) CPXs where written without documentation of any sort - it can be done, it has been done. Frank... ------------ Category 14, Topic 27 Message 151 Tue Jul 23, 1991 C.F.JOHNSON [CodeHead] at 13:58 EDT Frank, I find that rather difficult to believe. The CPX spec includes a certain type of file header, and some "custom" routines to be called by the CPX. A programmer would not even know about these things without the CPX documentation. I guess it might be possible to disassemble an existing CPX and "reverse engineer" the specification. But it would be a big waste of time, and could possibly lead to problems if something was gotten wrong. =-=-=-=-=-=-=-=-=-=-=-=-= To all, As I mentioned before, Atari has spelled out what CPXs are supposed to be used for. There's _nothing_ wrong with this; it's certainly Atari's right to do it, and in fact it heartens me to see them care enough to do it. (There have been _far_too_few_ rules and guidelines coming from Atari in the past, which always seemed to me an indication that they simply didn't care.) It's really too bad that some developers already are violating that specification, and defending their violations. But this is obviously not a very popular viewpoint around here, so this is the last time I'll voice it. Let Atari enforce their own programming rules, I've got better things to do. - Charles ------------ Category 14, Topic 27 Message 152 Tue Jul 23, 1991 TOWNS [John@Atari] at 15:49 EDT But, Mike.. it says in the documentation that CPX modules should confine themselves to the CPX panel size. If you can't make yourself fit inside that box, then make your "thing" A _Desk Accessory_ or an _Application_! This is one rule I refuse to budge on one little bit. -- John Jim.. yeah! In VERY fine print! ------------ Category 14, Topic 27 Message 153 Tue Jul 23, 1991 S.JOHNSON10 [Steve] at 18:11 EDT J.NESS - Well, at least being a cheap Atari developer isn't NEARLY as expensive as being a registered Mac developer! ------------ Category 14, Topic 27 Message 154 Tue Jul 23, 1991 D.MCNAMEE [Dan @ Atari] at 19:40 EDT Jim, Close. Ken has on the side of his car "Do it my way or die!" ------------ Category 14, Topic 27 Message 155 Tue Jul 23, 1991 J.NESS [Jim] at 19:43 EDT Steve Johnson - Yup, Atari's developer program is inexpensive, compared to most others. But, most other platforms have a multitude of documentation, easily purchased at your nearest book store. We don't. So, essentially, we have no substitute for up to date info. We gotta go with what Atari offers, and at their price. -JN ------------ Category 14, Topic 27 Message 156 Wed Jul 24, 1991 M.JENKINS9 [Mike Jenkins] at 00:09 EDT Thank you Atari. The XCONTROL is really a great idea. I'm using it on all my stuff EXCEPT Spectre 3.0: The mac comes up fine---as long as I don't want to listen to any sounds! I use SoundMaster v1.6 as well as other miscellaneous stuff in HyperCard. Using XCONTROL with Spectre negates the sounds on the Mac stuff. So far that's my only complaint. Is my understanding correct? By using XCONTROL, various "acc" functions could be modularized and incorporated into the XCONTROL.ACC, thereby increasing the actual number off accessories used withing the system? If so, go for it! A very satisfied customer, Mike Jenkins ------------ Category 14, Topic 27 Message 157 Wed Jul 24, 1991 J.RICHTER [J.RICHTER] at 00:40 EDT Doug, You mean like Chameleon...Iv'e had it for a month now...just drag a .acc to the Chameleon Icon and boom new acc after new acc after new acc after new acc....etc..etc ...hit alt-sht and click bingo all memory is returned to system! do the same within any GEM application by just clicking on chameleon..perty nifty stuff.. ------------ Category 14, Topic 27 Message 158 Wed Jul 24, 1991 LRYMAL [Larry Rymal] at 00:48 EDT Mike Jenkins, Could you explain how XCONTROL kills your sound with Spectre Mac operation? What problems are you noticing? Also, what kind of ST and how much memory? ------------ Category 14, Topic 27 Message 159 Wed Jul 24, 1991 TOWNS [John@Atari] at 01:16 EDT Well, Charles.. I for one appreciate your input and I agree with you. Thanks for attempting to enforce these rules. Unfortunately, Atari isn't abq5G " U H set down the rules in the documentation and we hope that people will follow them. We even have told people strongly that we don't like the way they are doing their CPXes. Unfortunately, there isn't much we can do beyond that. I know that I have learned a lesson from this. In the future, specifications for new products that have developer extensions will be much tighter in scope for anything that I do. Basically, the lesson here is that if you do something that is neat and you make it flexible enough for people to use, they will abuse it. Unfortunate, but true. Well, the bottom line is that I will continue to bash developers who violate the rules for CPX modules (privately of course..). And another point.. the Control Panel will have some future revisions (most likely). Those who followed the guidelines will have nothing to worry about. Those who didn't.. don't be surprised if your CPX suddenly doesn't work and your customers are mad. Sorry.. but we aren't going to support someone's brain damage. Anyway.. sorry, but this is a hot button for me. I spent alot of time working on XControl, it's specification, and the associated CPX. Heck, I even wrote the Configuration CPX and the Prefix program for appending headers. So, naturally.. I care about this product a great deal. Do us a favor folks.. appreciate it's flexibility and power. But, don't abuse it. Don't put Blockout in a CPX or a terminal or a notepad or anything else that doesn't have some kind of configuration as it's purpose. Those things should be Desk Accessories. Not CPX modules. Please.. help us to preserve this and not destroy the meaning of the word "Control Panel." Thank you! -- John Townsend Atari Corp, Software Engineer ------------ Category 14, Topic 27 Message 160 Wed Jul 24, 1991 J.ALLEN27 at 01:29 EDT Yes the docs available for Dos and the Mac are excellent, but have you priced the 5 volume "Inside Mac", and the HW docs, and other critical docs you need to become Macproficient? Atari's price is very reasonable, and is much less than buying "Inside Mac I-V". ------------ Category 14, Topic 27 Message 161 Wed Jul 24, 1991 TOWNS [John@Atari] at 02:09 EDT The purpose of the new Control Panel is to come up with a standard way that Atari and third party developers can configure various aspects of there system and in the case of the General CPX.. to report what the configuration is. Basically, the idea is that the Control Panel is the place you go to "control" or configure your system. It isn't intended to be an extension of your Desk Accessory limit. If you want this, then pick up a copy of MultiDesk. It's an excellent product that will allow you to extend your DA limit. I use it all the time. As for the Spectre problem.. I haven't seen this happen. Can anyone else help us out here.. -- John Townsend, Atari Corp. ------------ Category 14, Topic 27 Message 162 Wed Jul 24, 1991 M.POCHE [Mick] at 03:23 EDT John Townsend -- Just want to say I agree with you/Atari that the XControl should not be abused with CPX's that don't conform to the standards that Atari has set. Although, if I run across one that I find useful, I can't say that I wouldn't use it. If it dies on a future revision of XControl, that's life I guess. I keep XControl on my system at all times now. I think the idea of a control panel to control the system and memory-resident programs is _great_, and I await new CPX's!! Well, that's my two cents worth............ -- Mick Poche' Dedicated Atari User ------------ Category 14, Topic 27 Message 163 Wed Jul 24, 1991 A.FASOLDT [Al Fasoldt] at 06:42 EDT Tomas, Danka. Al ------------ Category 14, Topic 27 Message 164 Wed Jul 24, 1991 D.A.BRUMLEVE [kidprgs] at 09:35 EDT John Townsend, I can see how it would be difficult to build a "judge" into XCONTROL who would determine whether a given CPX was worthy of running, but wouldn't it be relatively simple to check CPXs for screen size and ax all those which don't conform to the docs, that is, the CPXs that take a larger segment of the screen than is allowed? Just an idea.--Dorothy ------------ Category 14, Topic 27 Message 165 Wed Jul 24, 1991 ST-REPORT [Lloyd Pulley] at 11:41 EDT >>...the Control Panel will have some future revisions (most likely). >>Those who followed the guidelines will have nothing to worry about. >>Those who didn't...don't be surprised if your CPX suddenly doesn't >>work and your customers are mad. Sorry.. but we aren't going to >>support someone's brain damage. Normal Atari thinking...if you don't do it our way, we'll change things so your software doesn't work....just to spite you. After all, we have lots of developers, so making one or two mad won't effect anything. And what does it matter if the developer is producing a product that the public is clamoring for, if Atari does not support it, it won't be sup- ported!! You know, other companies (ones who support their developers) would look at the number of people who have said that they like the idea of being able to hook/unhook CPX's and say something like "We see that there's a need for CPX type programs that do not fall under the XControl panel guidelines. While we still do not feel that XControl is the place for these types of programs, we will look at developing some other program that will fill these needs. Until such time as this program might become available, we ask all developers to please abide by the XControl Panel guidelines." ------------ Category 14, Topic 27 Message 166 Wed Jul 24, 1991 DOUBLE-CLICK at 16:29 EDT John - RE: Size. But John... Thanks for pointing that out to us! For the record, we aren't worried about our CPXtensions breaking with anything new that may come in a future Xcontrol. We adhere strictly to all of the documented procedures, and use them within the definitions of the procedures. As for using Xcontrol within the spirit, we have some excellent beta testers who are pounding away on our CPXs, we listen very closely to the comments they make. ;-) BTW - it might be useful to perhaps state what AES or VDI calls can not be made within a CPX. To me, that would seem to be the only way that a CPX would break. Q: 'Abuse' is it being loosely defined as not adhering to the 'spirit' or 'intention' of use of the procedure, or is it being defined as not using the procedure as it is documented to function? - mike ------------ Category 14, Topic 27 Message 167 Wed Jul 24, 1991 J.NESS [Jim] at 20:28 EDT Jim Allen - I have not priced any Mac books, but my collection of MSDOS books tend to average about $20 each, in soft cover. And, I am satisfied with their content. -JN ------------ Category 14, Topic 27 Message 168 Wed Jul 24, 1991 TOWNS [John@Atari] at 20:35 EDT No Lloyd.. You don't understand. You've never had to update an Operating System to find out that when you change something that you told people was going to change, it caused programs to break. We set down the rules for a reason. Not just to be difficult. If you violate those rules and we make changes that cause those programs to break, you can't blame Atari. Atari did it's part. The blame is entirely on the software company that didn't follow the rules. Just for the record, Atari has _never_ intentionally changed something in TOS or ANY Atari program so that a third party product wouldn't work. That would just be bad business. We need software to sell machines. We do everything we can to stay as compatible as possible. But, we have to be able to improve the system as well. We can't become limited by what someone else has done. If we tell you that this thing is going to work forever in all TOS revisions or revisions of the Control Panel, then it will. And we will go to great lengths to do so. But, on the other side, we have told people that CPX modules shouldn't use screen space outside of the Control Panel window. If they do this and we change something that causes them to not work anymore, what can we do? Do you want us to take out improvements so that these programs work? I won't do that. Dot.. yes, we could do some internal clipping. It's possible. Not sure if we will or not. I support and encourage companies to support the new Control Panel. At the same time, I also ask them to follow the specification! Is that too much to ask? -- John Townsend Atari Corp. ------------ Category 14, Topic 27 Message 169 Wed Jul 24, 1991 ST-REPORT [Lloyd Pulley] at 21:02 EDT To All, I owe you an apology. Not for what I have said in this Topic (as I still believe it), but for using my ST Report account to get involved in a con- troversial topic and allowing personalities to creep into my posts. John Townsend, I owe you an individual apology for my last post. ------------ Category 14, Topic 27 Message 170 Wed Jul 24, 1991 DOUG.W at 23:34 EDT The issue about what can be a CPX really falls under the subject of 'User- Interface Guidelines.' You can compare this to something simple like windows. The basic controls of a window are supposed to be consistent in ever y program. This isn't really enforced, but is a standard nonetheless. In the case of CPXs, it's been explained that they are for *control* type utilities. Generally, they shouldn't "do" anything by themselves, just tell something else how to act. From the messages I've seen here, the REAL problem is the 6 accessory limit and the fact that accessories use memory as long as the computer is on. Changing accessories to CPXs only fixes the symptom, not the problem. --Doug ------------ Category 14, Topic 27 Message 171 Wed Jul 24, 1991 SFRT-ASST [Ken] at 23:54 EDT Should there be a new topic on a New Desk Accessory format? What would fix the vector stealing problem and allow programs like Multidesk to dynamicaly allocate DA memory? How can an Extensible Desk Accessory be created? ------------ Category 14, Topic 27 Message 172 Thu Jul 25, 1991 TOWNS [John@Atari] at 00:27 EDT Lloyd, I don't think so. I said something that wasn't entirely clear and you gave me the opportunity to clarify what I mean't. I thank you for that. I hope that things are alittle clearer now. As for the apology, thanks anyway! But, I don't think it was neccessary.. It was obvious that my statement upset you and I was glad to clear up what wasn't clear from my previous posts. So, maybe I owe you an apology! -- John Townsend Atari Corp. PS. If we didn't have personalities, we would be all be alike and act like Robots. That wouldn't be any fun, would it :-) ------------ Category 14, Topic 27 Message 174 Thu Jul 25, 1991 LRYMAL [Larry Rymal] at 19:33 EDT Ken, I'd love to see some way for more accessory slots to be added, if anything, so that MultiGem would have some room. 15 slots, plus MultiGem, MultiDesk, plus XCONTROL would give us some real versatility. But then, what do I know? ------------ Category 14, Topic 27 Message 175 Thu Jul 25, 1991 WAYNED. [Wayne] at 21:07 EDT Ken, I think the nail has been hit on the head here. The REAL problem here is the EXTREME limitations of the current Desk Accessory format. I'm a MultiDesk owner so the 6 acc limit isn't my major problem. My major problem is that even with 4 megs I can't load up all the DA's I'd like to on every bootup. By the time I get to HotWire I'm under 2 megs of free memory with all the AUTO and DA's I'm using on my standard bootup for Mono and Med Res Colour. Now if a method similiar to Xcontrol's ability to only load the module into memory when it's used could be adopted/created for DA's (MultiDesk must be able to be made compatible) then I could get back about a meg's worth of free mem on my bootup. I think the major thing here is that *Joe Average Atari User* saw (and still does to a certain degree) Xcontrol's method of dynamic allocation as a promising way of getting around the 6 DA limit AND getting back major portions of free memory. There was little/no clarification about Xcontrol's limitations before it's release. All I ever heard were the things about it only loading a CPX when it's needed and not tying up memory when not in use, and how you could load many CPX's into Xcontrol thereby only using a single DA slot. Perhaps Atari made the ASSumption that everyone would realize that Xcontrol meant 'eXtended Control Panel' and CPX meant 'Control Panel eXtension' and exactly what that would entail. That was/is a poor ASSumption. To the average user Control Panel = Desk Accessory and hence Xcontrol = LOTS of dynamically allocated DA's using up a single slot thereby effectively eliminating the 6 DA limit and giving us back alot of our Free memory previously tied up by DA's. Maybe that's something that Atari should consider in the future. Don't get me wrong, Xcontrol is a wonderful addition for Atari and a definate step forward.(I've been saying this all along) But in reality 95% (IMHO)of the anticipation/glee over the impending release of Xcontrol by the average user was for the exact reasons I just stated. I consider myself to be slightly above the average user and even I had these misinformed hopes for Xcontrol. Hopefully we (ALL of us) can step beyond this present bickering and address the REAL issue here, and that's the limitations of the current 6 DA limit and the fact that they cannot be dynamically allocated saving us precious memory that doesn't need to be tied up all the time. Sure some need to be there all the time (Turbo ST, ButtonFix, etc.) but many don't need to be stealing my memory all the time. (CodeHead Ed, Memfile, calculators, ASCII TABLES, etc) Wayne ------------ Category 14, Topic 27 Message 176 Fri Jul 26, 1991 M.JENKINS9 [Mike Jenkins] at 02:33 EDT Charles, Unfortunately for the rest of the crowd, I agree with you. Atari is setting forth guidelines for its' hardware. Great. Apple did it. IBM did it. Maybe Atari should have done so at an earlier date, but that is not the issue. The issue is simple: Guidelines have been set for the hardware/software interface. If you want your product to work correctly, follow the guidelines. If you don't give a d**n about anybody BUT yourself, do whatever it is you want to do---BUT please remember that your efforts, good or bad, is a reflection on the entire community of Atari products. If you have successful products that follow the rules, your product makes the Atari look good. Conversely, if you don't care what guidelines are not followed, due to some idiosyncrousy, then your product makes Atari look bad. If you want Atari to compete with IBM and Apple, which should you choose? If you argue your position from the viewpoint of violating the specification, I will consider you to be unprofessional, unethical, and downright stupid. I am a professional in the field of Data Processing. I have been a System Manager for an eight-cpu VAX cluster, a Programmer/Analyst in both Business and Scientific areas. I have worked with the "big boys" -- IBM and DEC. Both of these companies have guidelines. The people who follow their guidelines are successful. Those who don't, generally find another profession. Thank you Charles, you are a professional. Don't let these amateurs get you down. Mike J. ------------ Category 14, Topic 27 Message 177 Fri Jul 26, 1991 M.EVERHART2 [MIDIMIKE] at 05:29 EDT WORDS FROM AN END_USER. When I got into this ATARI thing, I could barely get off the Desktop - MAC nearly made a sale right off the bat for ease of use until I saw NOTATOR. Now I use my computer for everything, but still hate the hassles of quitting one program to do something else. If we can't have a computer that you turn on and run from one program to another, we're not going to sell it to all the compu-phobics out there. Some combination of Multidesk, MultiGEM and the CPX might do it - if they have clearly different functions that's ok, as long as I never have to reboot, I'm happy. ------------ Category 14, Topic 27 Message 178 Fri Jul 26, 1991 S.JOHNSON10 [Steve] at 18:13 EDT DOUG.W - Yeah, I've always wished the ST's desk accessories were like the Mac's in that you can have more than 6 (that's sorta been worked around, though) and they aren't all RAM resident taking up precious memory. I hate having to disable several desk accessories and reboot just to get certain programs to run. I thought XCONTROL was going to fix this when I first heard about it, but now XCONTROL isn't nearly as great as I originally thought, although it IS pretty nice. ------------ Category 14, Topic 27 Message 179 Fri Jul 26, 1991 CGEE at 18:56 EDT When we first started working on XCONTROL, it was always meant from day 1, to replace the existing Control Panel only. The thought of it replacing DAs was never even thought of, nor implied. The idea was always, hey, the Mac CP is pretty neat, what can we do to put something like that on our system? Ergo, I think XCONTROL is really great! It sure beats the old CP. The issue of DAs and their limitations is another can of worms tho... :-) ------------ Category 14, Topic 27 Message 180 Fri Jul 26, 1991 C.F.JOHNSON [CodeHead] at 22:24 EDT Geez. You folks who are disabling accessories and rebooting are really wasting time, and putting yourselves through a lot of completely unnecessary aggravation. The "limit" of six desk accessories simply doesn't exist any more -- not since MultiDesk was created almost three years ago. Using MultiDesk, you can load and dump accessories any time you like, and you can easily free up the memory the DAs use when you need it to run a RAM-hungry program. Another big feature of MultiDesk is that it lets you run DAs just as if they were programs; you can even install MultiDesk as an application for .ACC files, and run any DA just by double-clicking it. And of course, if you run a DA in this fashion, closing it removes it completely from memory -- just like a program. And using MultiDesk with HotWire even gives you another level of convenience beyond that. I have several sets of accessories that I load and unload as needed; with HotWire, I can tell MultiDesk to resize its RAM buffer and load a group of DAs to use with a particular program, then run that program ... and then reload my default group of DAs when I quit the program. This is very powerful stuff; all automatic, and all performed with _one_ (count it) mouse click or keypress. Is that "limited?" (You can't even do this on the Mac...) As wonderful as XCONTROL is, a lot of people seem to have big misconceptions about how it operates. It isn't true that CPXs use no memory until they're loaded. The fact is that XCONTROL allocates a block of memory large enough to hold its CPXs at bootup time, and _never_ deallocates this block. (This is why, after changing XCONTROL's number of slots, you must reboot to activate the new setting.) As released by Atari, this block of memory is about 41K -- and since XCONTROL itself uses over 50K, this means that XCONTROL (in its "default" configuration) grabs more than 90K of memory all the time, whether or not your CPXs are "RAM Resident." To put it another way, XCONTROL has a communal "pool" of memory (allocated at bootup, and never released) that can be used by any CPX module. If a CPX is marked as "Not RAM Resident," it's loaded into this pool of memory when you open it, and thrown out of the pool when you close it. The space it occupied is then free to be used by _other_CPXs_, but not by any other program. That pool of RAM stays allocated until you reboot your computer or change resolutions. The advantage of this scheme is that the pool only has to be big enough to load the largest possible CPX. (But if you want to load a CPX that's larger than the existing pool, you'll have to increase the number of CPX slots and reboot your computer.) This is similar to the way MultiDesk works, but with some important differences. MultiDesk also allocates a block of memory for its DAs. However, _all_ desk accessories are RAM resident in MultiDesk's pool, so the pool you allocate has to be large enough to fit them all at once. (It has to be this way, folks; the reason XCONTROL can get away with loading and dumping CPXs is precisely _because_ CPXs are so limited in form and function. Real desk accessories are much messier than CPXs, and do things that are harder to clean up. In some cases, the things they do are impossible to clean up in any "legal" way.) But MultiDesk makes up for this "limitation" by letting you resize its RAM buffer whenever you're at the GEM desktop or in HotWire. If you don't have enough buffer space to load an accessory, MultiDesk can automatically expand its buffer to load new DAs. If you need more RAM to run a certain program, you can simply remove the DAs you don't need and free up the memory they used. If you need to, you can even get rid of the MultiDesk buffer entirely; when you do that, MultiDesk 2.2 uses only 43K. And you can do all of the above _without_ having to reboot your computer. By the way, if you allocate a buffer in MultiDesk so that it uses the same amount of memory as XCONTROL (which would give you about a 50K buffer), you'll have plenty of room for all the ASCII charts, formatters, and calendars you could possibly want or use. You can see that both XCONTROL and MultiDesk have their own unique advantages and disadvantages. The disadvantages of both are largely due to the limited nature of the ST's memory management system. Unfortunately, the way GEMDOS deals with memory allocation, true Macintosh-style DAs (that load and unload dynamically, at _any_ time) just aren't feasible on the ST. Without getting into the gory technical details, please take my word for it -- the Mac's memory management is much more sophisticated than the ST's, and allows things like dynamically loaded DAs to work without hopelessly fragmenting memory into a bunch of small, scattered, unusable chunks. The ST's memory management system would have to be rewritten to follow the Macintosh model (or something similar) in order for this situation to change. Charles F. Johnson Member of the IAAD ------------ Category 14, Topic 27 Message 181 Fri Jul 26, 1991 M.JENKINS9 [Mike Jenkins] at 22:50 EDT Larry, I've got an 1040 STe w/4Mb, HP DJ500, Toadfile 44HD, SM124, Yamaha PSS480 Synthesizer, Supra 2400 modem. XCONTROL panel cpx's: ICD's AdSCSI: Cache is on, verify is off. Atari's Color setup: Color and Wcolors are inactive. Configure: Text Color: 1 Icon Color: 1 Ram Resident: NO General Setup: Keyclick and Bell off Blitter on. Response Rate:0.30 Repeat Rate:0.04 Mouse click speed: 3 Accelerator: Speed: 7 Screen Saver: off Modem: 2400/None/8/1/flow control:none Printer: Dot; B/W; 1280; Draft; Single Sound: Vol: 40; L:0 R:0; Bass: 6 Treble:6 I assume the setup for the XCONTROL is safe, since all of my Atari S/W runs OK. This is the ONLY change in Atari S/W made in the last 6 months. With this setup, I start Spectre (System: 6.0.5, Finder: 6.1.5). I've made no changes to the Mac S/W in the last 11 months. The HD is partitioned: 1Mb for Atari, (3) 10Mb & (1) 13Mb partitions for the Mac S/W. The Mac sound is handled through MacInTalk, Sound, and SoundMaster v1.6. There should be 3 normal start-up sounds made by the time start-up has completed. The trash receptacle has been replaced by The Grouch. Floppy Disk insertion/ejection has specific sounds (from Hitchiker's Guide to the Galaxy and Dr. Who). With XCONTROL switched on, NO sounds are heard, and all S/W runs OK. With XCONTROL switched off, NO sounds are heard, and all S/W runs OK. With the XCONTROL.ACC changed to XCONTROL.AC1, all sounds are heard and all S/W runs OK. ** All of these conditions occur whether or not my Yamaha PSS480 ** ** synthesizer is hooked up to the MIDI ports! ** --- Most curious. I don't know why. I called Gadgets and told them about it. They said they'ed look into it. I'm just curious if anybody else has this problem. If you can help, I'd really appreciate it. Thank you. Mike J. ------------ Category 14, Topic 27 Message 182 Fri Jul 26, 1991 R.GRANT11 [Ron @ GXRSYS] at 23:37 EDT Cary: by the response and confusion generated by XCONTROL, it's obvious that it's a can of worms that needs opening.... I insist on having Multidesk in my system, and that's cool, but with things like Buttonfix, STalker/STeno, PopIt!, some of the NEO accessories, and now this MULTIGEM concept rolling around, I think it may be time for Atari to take the same great idea that someone obviously had for the Extensible Control Panel and apply it to other parts of the system. By the 'same great idea', I mean the incredibly valuable ability to look at what other companies are doing RIGHT, and being prepared to say 'this is good; we would like this too' without personalities getting in the way. ------------ Category 14, Topic 27 Message 183 Fri Jul 26, 1991 J.ALLEN27 [FAST TECH] at 23:45 EDT Hmmm, I've got XCONTROL on and when I go to Mac mode, the system "beep" works, on startup, etc. Must be something upsetting the Mac sound SW you have that impliments all the sounds. ------------ Category 14, Topic 27 Message 184 Sat Jul 27, 1991 LRYMAL [Larry Rymal] at 00:24 EDT Mike, Well, heck. I dunno. This is strange. I have about the same setup as you (four Megged Mega rather that 1040, ICD host software with XControl stuff, using SoundMaster complete with startup sounds, Spectre GCR 3.0). XControl has no effect on my setup with or without it being engaged. Don't you just hate it when you have something like this and no one else can duplicate it? I *do* know the feeling. Maybe someone else can duplicate your "no sound on the Mac when using XControl" problem. Just won't duplicate here. ------------ Category 14, Topic 27 Message 185 Sat Jul 27, 1991 J.RICHTER [J.RICHTER] at 00:25 EDT CodeHead, Gee I think one problem is that your product is far more powerful than your documentation is discriptive! How 'bout a "MultiDesk tricks and Tips" book! all of us would be willing to pay for that one.. Looks like I'll have to hit the MultiDesk manual for a refresher course but seriously I always seem to need that accessory when I'm in an application that is crucial and can't quit! MultiDesk gives warning messages saying it isn't safe to load new acc's when running an application!...Murphys Law usually prevails....SUGESTIONS? -Jerry- ------------ Category 14, Topic 27 Message 186 Sat Jul 27, 1991 CGEE at 01:13 EDT Howdy Charles! Yup-For more DAs, MultiDesk is the thing to use! I highly recommend it! The Control Panel does use about 50K on its own. The number of slots allocated is either 1-1/2 times the number of CPXs loaded, or the minimum # of slots, whichever is greater. Yes, I shouldn't have ever put in a configurable # of slots setting. A slot is some header information about the CPX. The CONTROL.INF file contains several items. It contains the path to where the CPXs are stored, the minimum # of slots to have at the very least, whether to have a 12 or 24 hour time display, and a very mysterious 0 or 1 digit as the last item. If the number is '1', the CPXs are loaded dynamically and is freed up when you exit the CPX. If the number is '0', the Control Panel at boot time or rez change will allocate enough memory to load the largest CPX possible. There, the memory will always be with you. If you say, download a nifty new CPX and immediately put it in the CPX directory, and try to run it...if the CPX will not fit in that block of memory, you'll have to either reboot or do a rez change. Of course, if you have, say, 10 slots and 10 CPXs loaded, and you get this new nifty CPX from GEnie and immediately try to run it, you'll get the 'there are no more slots message'. But then again, that's why I've allocated enough slots for 1-1/2 times the # of active CPXs at boot or rez change time. In the above case, you would have 15 slots - 5 of which would be free. The reason for have the 2 differing schemes is due to the way the system handles memory management and events both before TT and Mega STE TOS and after. The last number cannot be changed by XControl. It can only be changed with a text editor. A deeper, more fulfilling explanation for all of this is beyond the scope of this class and is left as an exercise for the reader. ( just kidding ) Needless to say, the above contains run-on sentences, bad grammar and diction and a convoluted structure. All of which means that its been a long day..:-) Cary ( I need a vacation ... ) ------------ Category 14, Topic 27 Message 187 Sat Jul 27, 1991 C.F.JOHNSON [CodeHead] at 01:55 EDT Ron, Just FYI ... the next upgrade of MultiDesk has Buttonfix built in, and even communicates with HotWire to let you turn it on/off for specific programs. - Charles ------------ Category 14, Topic 27 Message 188 Sat Jul 27, 1991 C.F.JOHNSON [CodeHead] at 03:19 EDT Jerry, We do have a CodeHead book underway right now. It will include tricks and tips not just for MultiDesk, but for all of our products. It's being written by someone who knows our stuff inside and out, and it should be great! As for MultiDesk's warning messages, well, those warnings are there for a reason: to tell you that it may not be safe to load or clear accessories at that time. MultiDesk faces three problems when you're running a program and want to load a DA: 1) It may not be possible to allocate memory for the DA, since many programs selfishly take all available memory for themselves when they run. And even if there's enough space in MultiDesk's buffer to load it, the DA itself may need to allocate some memory as part of its startup process. If the running program hasn't left them any memory, many DAs will simply crash because they don't check for an error after making their memory allocation call. 2) If the running program has left some memory free, and the DA you're loading does manage to allocate some memory for itself during its initialization (quite a few of them try to do this), then your available memory will be fragmented into two unequal chunks when you quit the program. This happens because the memory allocated by the DA will be above the area that formerly held the running program, and any additional memory will be above the DA's allocated block. (Note: normally, when you quit a program, any memory allocated by DAs while that program ran will be released unexpectedly by the system. MultiDesk does employ a trick to make sure its DAs' memory won't get freed, but it can't do anything about the fragmentation problem.) This type of fragmentation could be diagrammed like this: ------------------------------------------------- /|\ | | | Memory left over when the DA allocated its block | | | \|/ ------------------------------------------------- /|\ | Memory allocated by the DA | \|/ ------------------------------------------------- /|\ | | | | Memory formerly occupied by the running program | | | | \|/ ------------------------------------------------- 3) If the DA you're loading uses any of the same interrupt vectors as the current running program, you'll have *big* problems (read: bombs) when you quit that program. However, if you leave some room in your buffer so MultiDesk doesn't have to expand it to load the DA, and the DA you're loading isn't a vector-grabbing monster like a ramdisk or a mouse accelerator or Turbo ST, it's probably safe to go ahead and load it anyway. If you stick to loading things like calendars, calculators, note pads, etc., you'll be fine. XCONTROL avoids all of these problems by placing severe restrictions on what CPXs can do. The most important restrictions (at the system level) are that CPXs can't grab memory and keep it, and they can't use interrupt vectors. And XCONTROL's memory management itself is limited, also to avoid these problems -- it allocates its buffer at startup and cannot change it without rebooting. =-=-=-=-=-=-=-=-=-=-=-=-= Cary, Howdy! If you change that number in CONTROL.INF, though, you'll face the same memory fragmentation problems I described above if you load CPXs while a program is running, no? - Charles ------------ Category 14, Topic 27 Message 189 Sat Jul 27, 1991 TOWNS [John@Atari] at 13:35 EDT The issue of DAs and their memory consumption is one for the AES. We simply wanted to improve the existing Control Panel and make it much easier to use. -- John ------------ Category 14, Topic 27 Message 190 Sat Jul 27, 1991 J.RICHTER [J.RICHTER] at 15:30 EDT Ron, Have you seen the latest copy of GEMINI destop?.. with this desktop and Chameleon.acc you can just drag any acc to the Chameleon Icon and bingo its the active acc..hit shft+alt+click and bingo ALL memory used is returned to system! This is an instantaneous operation.. and when an application (like PageStream )is running you can allocate and de-allocate (load/unload acc's)memory with NO problem!! ...if for some reason you cannot de-alocate memory it will give you a warning...but no harm is done.. Gemini(chameleon) must use memory more efficiently than GEM?? try it and see what you think..cause' now I can run any number of ACC's (50!)from within any application.. and it all works with MultiGEM!! -Jerry- ------------ Category 14, Topic 27 Message 191 Sat Jul 27, 1991 R.GOFF [Bob] at 16:54 EDT Interesting tip, Cary. Did I miss that somewhere in the documentation, or is this an exclusive? :-) Bob ------------ Category 14, Topic 27 Message 192 Sat Jul 27, 1991 M.JONES52 [Jonesy] at 18:50 EDT Charles, Thanks for the helpful explanations of XControl & MultiDesk. Some of this is in the docs for MultiDesk, but now I understand it better. Built-in and configurable Buttonfix? Hooray! ------------ Category 14, Topic 27 Message 193 Sat Jul 27, 1991 S.NOAH [Stu] at 21:56 EDT If and when a multitasking version of the ST opereating system is ever developed all this CPX ACC stuff will be old news... right ! Stu ------------ Category 14, Topic 27 Message 194 Sun Jul 28, 1991 M.EVERHART2 [MIDIMIKE] at 01:25 EDT I've seen Gemini alluded to before - is it a file on GENIE? ------------ Category 14, Topic 27 Message 195 Sun Jul 28, 1991 R.GRANT11 [Ron @ GXRSYS] at 03:57 EDT Jerry, yeah, I have a copy of GEMINI floating around drive C:\ somewhere...I boot it occasionally, but I always wind up offloading it in favour of Hotwire. Same thing with NeoDesk; I've got a 2.05 version that I play with on occasion. For what I want to do, Hotwire still comes out on top. Er, to be accurate, it's MAXIFILE that comes out on top for me; Hotwire is just sort of the underlying shell that allows Maxifile to be my complete desktop replacement. Charles & John, I hope you'll post bail when the Topic Cops drag me away.... ------------ Category 14, Topic 27 Message 196 Sun Jul 28, 1991 CGEE at 20:24 EDT Charles - It's a long story, remind me to tell you about it someday. We'll do mondo /sen's in the next conf. :-) ------------ Category 14, Topic 27 Message 197 Sun Jul 28, 1991 S.JOHNSON10 [Steve] at 22:41 EDT M.JENKINS9 - I believe Spectre has problems with sound using System 6.0.5. I know it has problems with sound with ONE of the System versions, but I'm not completely sure if it's 6.0.5 or not. S.NOAH - Well, it may be old news to STE/MEGA STE/TT owners since TOS development for older ST's is "on hold." ------------ Category 14, Topic 27 Message 198 Mon Jul 29, 1991 SFRT-ASST [Ken] at 19:40 EDT Oh god! I didn't mean to start _this_ kind of mess. Thanks for the class, Charles. TOWNS>>> What would be a better topic to talk about DAs? ------------ Category 14, Topic 27 Message 199 Mon Jul 29, 1991 LRYMAL [Larry Rymal] at 20:47 EDT Steve Johnson, Wrong! Spectre works GREAT with sound using System 6.0.5. It is with System 6.0.7 that problems exist, due to the fact that Apple changed the Sound Manager. Again, I don't see how problems can exist between XCONTROL and Spectre. The two don't even communicate to each other. ------------ Category 14, Topic 27 Message 200 Mon Jul 29, 1991 J.ALLEN27 [FAST TECH] at 21:13 EDT If XCONTROL were to setup the sound chip in a certain way, and Spectre's code didn't uninit it, perhaps a conflict could occur? Who knows, if he's having a prob, and has tried all the easy fixes, maybe there is some real conflict mechanism. ------------ Category 14, Topic 27 Message 201 Mon Jul 29, 1991 CGEE at 21:51 EDT Problem is, only the sound.cpx will talk to the sound stuff. The Control Panel itself has nothing to do with it. ------------ Category 14, Topic 27 Message 202 Tue Jul 30, 1991 J.ALLEN27 [FAST TECH] at 02:08 EDT Now I'm puzzled. If I have Xcontrol installed, then how does the volume get set on boot? Does the Sound CPX set it up. If so, then maybe yanking out the sound cpx would be a good test to see if IT does an init to the sound chip that Spectre isn't exspectre'ing ;-) ------------ Category 14, Topic 27 Message 203 Tue Jul 30, 1991 SFRT-ASST [Ken] at 09:52 EDT You may have to erase your Control.Inf file. Perhaps your control info file is locked or something? ------------ Category 14, Topic 27 Message 204 Tue Jul 30, 1991 CGEE at 13:28 EDT At boot time or rez change, the cpxs can execute some code to do whatever they want. The sound cpx will set the sound stuff to its saved values. The Control Panel itself doesn't do anything with any hardware whatsoever. The CPXs are the ones that do all of the work. The control.inf file contains the path, the clock setting etc. It has nothing to do with sound, colors, serial ports etc. As for the time, it only displays whatever GEMDOS says the time is. ------------ Category 14, Topic 27 Message 205 Tue Jul 30, 1991 TOWNS [John@Atari] at 19:33 EDT Jim.. the SOUND.CPX does indeed set the volume when it is loaded and initialized. -- John ------------ Category 14, Topic 27 Message 206 Tue Jul 30, 1991 J.ALLEN27 [FAST TECH] at 23:32 EDT Perhaps the setting the Sound.CPX does isn't completely undone by Spectre, and this poor guy is having no sound as a result. Sounds (hehe) like Dave needs to do some experimenting, and perhaps add on to the sound setup code in Spectre? ------------ Category 14, Topic 27 Message 207 Wed Jul 31, 1991 F.OLIVAS [Fred O.] at 00:47 EDT Just a quick notice to all: The program BEEP.PRG, which replaces the bell with a digitized sound, doesn't work with the XCONTROL program. Fred O. ------------ Category 14, Topic 27 Message 208 Wed Jul 31, 1991 SFRT-ASST [Ken] at 01:51 EDT Is there a program that allows swapping analog sounds with sampled ones? ------------ Category 14, Topic 27 Message 209 Wed Jul 31, 1991 DARLAH [RT~SYSOP] at 11:27 EDT Fred: Thanks for that information. I have been trying to get a sound play program to work with the TT. I tried the latest .ACC but it wouldn't work. I am going to check it out on the ST today. I have some really great sound files but haven't been able to usethem on the TT. Am I missing a program?? Could this be related to your problem with BEEP in some remote way? I know different machines...different problem. :-) ------------ Category 14, Topic 27 Message 210 Thu Aug 01, 1991 S.JOHNSON10 [Steve] at 00:08 EDT SFRT-ASST [Ken] - What do you mean exactly by "swapping analog sounds with sampled ones?" One thing that bugs me about the STE's DMA sound engine is that the Yamaha sound chip is much louder than the digitized sounds, so I keep on having to adjust the volume on my monitor or amplifier (e.g. I'll play some SoundTracker .MOD files through the RCA jacks on my amplifier at a good level and then when I'm done and get the system bell for some reason, it's LOUD AS H*LL!!). Steve ------------ Category 14, Topic 27 Message 211 Thu Aug 01, 1991 J.ALLEN27 [FAST TECH] at 01:11 EDT Sounds like a little resistor assistor is required...to quiet the situation ;- ) ------------ Category 14, Topic 27 Message 212 Thu Aug 01, 1991 SFRT-ASST [Ken] at 12:24 EDT I'm having Mac envy. Instead of "beeps" and "boops" they can have Cpt. Kirk say "Warp Nine, Sulu!" Or a female voice say "Oooh..push _that_ one." ------------ Category 14, Topic 27 Message 213 Sun Aug 04, 1991 E.KRIMEN [Ed Krimen] at 17:57 EDT Fred, try NewBell. Ken, take a look at the DigiStuf archive. The ST can have those custom sounds. Beware though, the programs don't work on the STe. However, the STe is supposed to have similar routines built-in to TOS, but no one has made use of them yet. :^( NewBell works on the STe though. ------------ Category 14, Topic 27 Message 214 Sun Aug 04, 1991 SFRT-ASST [Ken] at 19:14 EDT Aha! ------------ Category 14, Topic 27 Message 215 Mon Aug 05, 1991 N.SAW at 22:15 EDT Speaking of Newbell, I'd like to see something similar to SoundMaster on the Mac for the STE. Since STEs and up have DMA sound... ------------