30204 17-JUN 11:59 General Information RE: SDir (Re: Msg 30198) From: ZACKSESSIONS To: BRIANWHITE Just uploaded a patch file to fix the situation. It will be available as soon as a sysop processes it. Zack -*- 30341 24-JUN 02:51 Utilities RE: SDir (Re: Msg 30202) From: BRIANWHITE To: ZACKSESSIONS I used numbers from 1000 -> 1999 as user numbers for going straight into a current project. Since my computer boots up to TSMon/Login, I can just enter the program name and a password, and presto, I'm ready to edit. It also gives my partner access to t he same files without giving him SuperUser access. It should be simpler with OS-k and Group attributes. Brian -*- 30356 24-JUN 18:59 General Information RE: SDir (Re: Msg 30341) From: GREGL To: BRIANWHITE Brian, Correct me if I'm wrong, but I don't think OSk has group attributes. It appears to me that OSk uses the same file descriptor structure as OS9/6809. Adding group attributes would require extending the current attributes to 16 bits and there isn't room in the file descriptor for that. -- Greg -*- 30369 25-JUN 02:44 General Information RE: SDir (Re: Msg 30356) From: TRIX To: GREGL Greg, Your right. I'm looking at page 55 in "The OS-9 Catalog" from Microware. The FD_ATT byte has D S PE PW PR E W R. No group attributes. Oh well. -John. -*- 30396 26-JUN 00:52 General Information RE: SDir (Re: Msg 30369) From: GREGL To: TRIX John, Right you are. And without group attributes, there really is no group protection in OSk. But I don't really have to worry about that since I'm working on a project from the ground up and 100% compatibility isn't a real issue. I'd rather get it right the first time with room for expansion than to have to muck around trying to force a fit later. -- Greg -*- End of Thread. -*- 30205 17-JUN 12:18 General Information RE: 1-meg problems? (Re: Msg 30165) From: RAGTIMER To: EDDIEKUNS Yeah -- hard to tell what your other tasks are doing without spakrlies! I saw the junk when clearing to (or was it out of?) the 32x16 VDG screen (my /TERM) when in text mode. Didn't happen when I had a VDG grafix screen up on Umuse. I figured the change from windows grafix to VDG text was just too much for L2 to handle in one vertical retrace interval. Anyway I haven't seen it in a long time, no matter what. Can't remember what (if anything) chased it away. Maybe the Phatnom of the Computer dropped a chandelier on it...? -*- 30292 22-JUN 01:45 General Information RE: 1-meg problems? (Re: Msg 30165) From: DAMIONGREY To: EDDIEKUNS Eddie - Just to let you know that you're not alone, I get that garbage, too. 'cept I've just go a lowley 512K machine. One of the first in the area to get a coco 3, so I had an old GIME , and it did it back then. Now I've go a new GIME, and it still does it. No wierd crashes now that I've got the new GIME, tho, and NO sparklies! LOVE that Tandy hardware! Can't wait to go my hands on an MM/1! (or TC/70, but pry the MM/1....sounds worlds better) - Greg -*- 30293 22-JUN 01:48 General Information RE: 1-meg problems? (Re: Msg 30292) From: EDDIEKUNS To: DAMIONGREY At least I'm not alone. :( Eddie -*- 30301 22-JUN 22:29 General Information RE: 1-meg problems? (Re: Msg 30292) From: RAGTIMER To: DAMIONGREY Fer sure get the MM/1, since you don't have a 1 Meg investment to protect. Eddie, I found how to get that burst of colored confetti back. I have to have at leeast one L2 GRAFIX window open (I rarely do). Then wehn I clear from the VDG TERM to a TEXT L2 window (right), I get the burst. New GIME and 1 Meg. Hasn't crashed yet, but it looks sorta, well, Commodorish...mike k -*- 30311 23-JUN 01:36 General Information RE: 1-meg problems? (Re: Msg 30301) From: EDDIEKUNS To: RAGTIMER Maybe it's about time I named my machine, eh? I mean ... it has enough personality! It has more personality than some humans I've met. I guess CoCo's, like CoCo users, are each unique. Eddie -*- 30361 24-JUN 23:44 General Information RE: 1-meg problems? (Re: Msg 30311) From: RAGTIMER To: EDDIEKUNS Yessir! And that's before they start cusotmizing their OS9 Boots and Startup files. (And getting bugs nobody else has, grin). -*- End of Thread. -*- 30206 17-JUN 12:22 Graphics & Music RE: New Score: Rondo alla turca Mozart (Re: Msg 30170) From: RAGTIMER To: XLIONX Thanks for the notice, and the score. What is the advantage of this new Os9Arc format over the standard (?) AR? I have an old Turkish March (from CIS maybe), but it was done in only 2 or 3 parts, back on the old 1600-note Shareware Umuse, so I'll gladly DL your new version. -*- 30221 18-JUN 02:56 Graphics & Music RE: New Score: Rondo alla turca Mozart (Re: Msg 30206) From: XLIONX To: RAGTIMER Howdy, Well, it's like this...after extensive testing, os9arc compresses better than PAK in all cases and performs as well as AR for text. The reason I never use AR anymore is that it can't compress anything except TEXT files. Also, os9arc/dearc are in the same format as IBM (I had to say it) ARC files. While PAK is the most functional of them all, I have a VERY large ARC directory on my hard drive: 158 files; 2-Meg; 8-Directories This used to take up over 3.5 meg with a combination of AR and PAK. It's like getting free megabytes on the drive! Let me know how ya like it. -Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445) -XLIONX (DELPHI) -mwf@SANDV -*- End of Thread. -*- 30207 17-JUN 12:27 Device Drivers RE: MIDI (Re: Msg 30172) From: RAGTIMER To: PHILZEIGLER Phil, you might trtry to hunt up Intercomp Sound in Rochester, NY. He has a clone of the Speech Systems MIDI pak that he might be willing to sell a little cheaper. Maybe. It's usually bundled with his whole MIDI sequencer package (reviewed in Rainbow a couple years aback). Some users have hacked RS232 Paks (or even DC Modem paks?) into MIDI paks. One guy even got ACIAPAK to drive his hacked RS232 pak, after renaming T2 to MIDI and nulling out all its options bytes. But I can't guarantee that will work. Anyone with direct experience, please chime in -- thanks, mike k -*- 30208 17-JUN 12:38 General Information RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29945) From: RAGTIMER To: PAULSENIURA He he -- the irony is that MSDOS programmers can't write proper OS/2 applications -- the only folks who could are experienced OS-9 programmers! Maybe we could be bribed to help out for, say, $100 grand a year, grin. Also note that while Microware has orphaned OS-9/6809 and pretty well pulled out affordable support for the Atari ST, they are backing the new MM/1 system very well -- putting some faith into it as the way to get OS-K into the mainstream. Remains to see if FHL's Tomcat-70 gets the same support. And DO upload your posting to the PC, Atari, and Amiga groups. PS: Does that latest 4.6.1 play on your Pak? -*- 30277 21-JUN 01:24 General Information RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29973) From: PAULSENIURA To: PAULRINEAR -> Can you think of a nice piece of action game software that will -> prove me wrong when I say COCO3 graphics are "coarse and slow". -> I'm comparing this to the Nintendo Entertainment System. I have tested Kevin Darling's patches for the GrfDrv module, and I was quite amazed at how fast my Oklahoma map would "plop" on the screen when a 7.9k Get /Put buffer was set up to be used. Any VEF pic could be read in about 8k at a time in four chunks and these chunks would be "blatted" to the video screen in a very big hurry with Kevin's patches. Very amazing. [But Kevin nor anyone else has fixed an irritating bug -- the right-most column of pixels (coordinate 319 or 619) has *never* worked in Get/Put buffers. Something's preventing that column from getting copied from the buffer. Copying "TO" the buffer FROM that column works just fine.] What Kevin's speed improvement proves is that the CoCo3 hardware itself is not at fault: it is how the modules were designed and programmed in the first place. After the o.s. modules are "tweaked" for top performance, then the application software needs to be rewritten (most probably) in order to utilize the new features properly. Yes this applies to any computer and o.s., not just the CoCo and not just OS9. I am afraid, however, that you're comparing apples with oranges. Nintendo's circuits, no doubt, have "Sprite" graphics chips. This scheme was used, but poorly documented, on the little T.I. home computer, but that machine's graphics were highly touted at that time, also. (It was the poor documentation, if it can be called that, to be blamed for the T.I.'s demise. And a lot of people are saying the same thing, now, about this new Nintendo machine. In fact some court suits are based on this fact, citing how Nintendo is unfairly cornering the game market.) When you compare Sprites with just regular ol' memory-mapped graphics, the Sprites will win every time, believe me. In this vane, you'd be hard pressed to see any OS9-based games approaching this kind of quality. And then you *could* blame the CoCo hardware design, since Tandy didn't elect to include Sprite chips in the design! This brings up a VERY interesting idea, tho ... I wonder if KLE or FHL might be considering such a graphics board that includes programmable Sprites? Jeepers, the 68030 with 32-bit paths would BLAST the Nintendo for sure!!! Why don't y'all harp on KLE & FHL to produce such a graphics board? That would really kill Nintendo and it *might* finally make 'OS9' a household name YET!!! (Hold it -- I better copyright my suggestion there -- I smell $$$s -- (c) 1990 by Paul Seniura. :-) -*- 30322 23-JUN 06:27 Graphics & Music Get/Put Buffers (Re: Msg 30277) From: OS9UGPRES To: PAULSENIURA > [But Kevin nor anyone else has fixed an irritating bug -- > the right-most column of pixels (coordinate 319 or 619) has > *never* worked in Get/Put buffers. Actually, it's fixed. But we didn't include the fix in the fast grfdrv patch. Why not? I guess because it's a sales feature for later . If you GET, then map in the buffer, I believe the rightmost pixel data is really included. PUT is a different story, tho. > What Kevin's speed improvement proves is that the CoCo3 hardware > itself is not at fault: it is how the modules were designed and > programmed in the first place. I know what you meant, but just wanted to clarify that the original programmers did one heckuva job getting everything they did, into the space they used. Matter of fact, they gave us many features which other windowing systems don't have at all... even their own RAVE. Anyway, they ended up having to make some major stuff into generalized routines for all gfx modes tho, which slowed things down. However, Microware didn't have Kent D Meyers, cruncher extraordinaire, around < grin>. Between the two of us, we carved out at least 800 bytes from grfdrv's already optimized 8K code... and as you know, that's an *enormous* amount of room to an asm programmer. Making special-case lightening-fast PUTs was easy after that. But I'm SO happy to be programming on the 68000 now: the really tight space restrictions of the coco are nonexistent. It's nice to be able to concentrate on fast code instead of always having to make smaller but generalized code. best - kev -*- 30619 8-JUL 23:59 General Information RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30277) From: PAULRINEAR To: PAULSENIURA (NR) Very interesting. The Commodore 64 was also an early unit with sprite graphics and it was fairly well documented in the Programmer's Reference manual. I also have Kevin Darling's patch and it is a great improvement. He has also written a new GFX2. Wonder if Kevin uses this message area. I know he's over on Compuserve. A sprite graphics board sounds like a good idea to me for the new " superCOCO's ", but I don't know much about it. I seem to remember there being some problem mentioned about not being able to use sprites in just any old window though. Paul Rinear -*- 30623 9-JUL 18:07 General Information RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30619) From: ZACKSESSIONS To: PAULRINEAR Kevin in on Delphi under username OS9UGPRES. -*- 30631 9-JUL 23:26 General Information RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30619) From: TIMKOONCE To: PAULRINEAR Hardware sprites are probably more trouble than they're worth. They were fine for the early underpowered machines like the Commodore, but since newer machines tend to have the horsepower to handle it, it's easier and just as effective to do it in software. Plus, there is a slight problem if you have 5 windows on a screen, and all of them want to use the hardware sprites! In such a case, the system would have to simulate some of them in software anyway. - Tim K -*- End of Thread. -*- 30209 17-JUN 15:57 General Information RE: CoCo 4? (Re: Msg 29690) From: PKW To: THEFERRET Phil, You should have gotten the packet by now. Did you? Sorry I haven't been on lately. The upper limit of the MM/1 is 9 meg, but I have been using a three meg system, with a terminal, and that seems to me to be far and away all the memory I am going to need, at least until I start cranking up the combined animation/ sound stuff! Then I'll either have to get the new SIMMs our count on the DMA to keep the system humming! BTW, OSK is now the official operating system for the MM/1. It really was never going to be anything else. We also have official prices, and the addition of several new configurations that should meet everyone's budget. OSK, the C compiler, and Microware BASIC are all included, as are a word processor that is keystroke configurable, a graphics editor from HyperTech, and several demos of the animation, of IMS and third party software, and so on. A ton o' stuff. So, Phil, if you haven't gotten the latest, or if you want ot get The Insider newsletter (have you got it already?), call our 800 number, 800 866 9084, Mon thru Fri, 9-5. Best regards, Paul -*- 30249 19-JUN 21:39 General Information RE: CoCo 4? (Re: Msg 30209) From: RAGTIMER To: PKW Say Paul, I don't recall getting anaything from you in the mail -- no blurb or Insider mag yet. I'd like to see your latest configuration, price, and options list -- you going to upload or post it here? Thanx, mike k -*- 30306 23-JUN 00:29 General Information RE: CoCo 4? (Re: Msg 30249) From: PKW To: RAGTIMER Well, the blurbs you really don't need, eh? And the Insider (as it says on the blurb you haven't received) is scheduled for an early July delivery! Patience, my friend, I am working as hard as I can ... I am going to put stuff in the mail to you -- oops, I just noticed I DON't HAVE your mailing address. Please Eplex to me on CI$. TTFN! Paul -*- 30360 24-JUN 23:42 General Information RE: CoCo 4? (Re: Msg 30306) From: RAGTIMER To: PKW Well I can just Email it to you here on the low-priced speared, grin. Just as private (I think!). So I'll send you my USMail address here -- also saves looking up your state prison number on the hi-priced spread. --mike k -*- 30678 12-JUL 21:35 General Information RE: CoCo 4? (Re: Msg 30360) From: THEFERRET To: PKW (NR) Is there anyone on the west coast who I could bug to have a peek at the machine ? actually, let me narrow that down a bit. Is there anyone within a 50-mile radius of San Francisco, ...? Philip -*- End of Thread. -*- 30210 17-JUN 16:12 General Information RE: Questions about the MM/1 (Re: Msg 30033) From: PKW To: KEITHMARCH Keith, Nice to hear from you again! Sorry to have been off so long. Been really busy here at IMS. To FINALLY answer your questions, here goes: 1) I believe that a WEFAX program will be coming available. 2) MM/1 has the hardware to support RAVE. 3) The system comes in a 128K EPROM, as I recall. I don't have the specs right at hand. Some of the EPROM spacaeis taken up by a lot of the common OSK commands, so system performance is even better. 4) Real time clock is best used on the second board. The EPROM socket is for system code. I used the MM/1 extensively without the realtime clock and had no troubles -- but is is more convenient now that I have the RTC, too. 5) There is a dmode command for OSK, and I use it all the time to transfer data between various OSK formats. 6) There will be a term program that supports X, Y, and Kermit protocol. 7) There is a cls command available to BASIC. 8) The 15 MHz MM/1 is a fast machine. It will run about 50 percent faster than computers in its price range. If you want to use another CPU, you will NOT be advised to pull out the 68070. For one thing, although it IS socketed, it is a highly integrated chip with serial ports and DMA stuff on board, so the CPU board is really glued together by the CPU. For another thing, if you need faster performance, you can use our 32 bit bus to add another CPU card, with FPU, etc. 32 bits will be the only correct bus to use for a faster chip. 9) You can exchage any CoCo disk with an MM/1 disk, using a simple utility. 10) Function keys will be implemented, details to follow in a month or so. 11) MM/1 does not have math coprocesor support, unless you do it on the bus. Then the math coprocessor is a peripheral. Luckily, our bus is 32 bits, so performance is far faster than 16 bit bus machines. 12) All major chips will be socketed until our quality control department says it's OK to solder most chips. Even then, theh cost of the sockets is so small, we may forever keep them in the design. 13) Getting started texts are in the works now, and will be distributed exclusively to our customers. 14) You have the choice of booting off of floppy first, then hard disk, finally EPROM. So the EPROM boot is only a last resort for the startup process. If you DO decide to boot off EPROM, you can simply load in any additional modules you need. If you want to REPLACE a module in the EPROM, no need to reburn the EPROMjust load in a module with the same name w/higher revision number. Howzat? Paul -*- 30211 17-JUN 18:12 General Information sculptor From: GENEDEAL To: ALL Does anyone know why sculptors developement menu, when calling up dynastar causes the loss of characters at the end of a document? Gene Deal -*- 30212 17-JUN 18:15 General Information os9 windows From: GENEDEAL To: ALL I am using multiple language character sets on OS9 with a text/graphics window and I cannot seem to get a text cursor. Other programs I have running on such windows have the cursor. Where is my cursor? Any help would be appreciated. Gene Deal -*- 30213 17-JUN 19:17 Device Drivers System Clock From: MPASSER To: ALL Hello! I recently installed a Tandy SmartWatch in my FD-502 controller, and it works great. However, once I'm up and running, I notice that the system clock *gains* time. If anything (since I'm not using no-halt floppies), I would expect that it would *lose* time. Any ideas? Thanks, Mike Passer (MPASSER) -*- 30214 17-JUN 20:16 Graphics & Music SS.MSig question From: ZACKSESSIONS To: ALL Consider the mouse signal. Let's say I do a: _ss_msig(path,MOUSSIG); call in my C program. Should path be standard input, standard output, or does it really matter? Zack -*- 30215 17-JUN 20:27 Graphics & Music RE: SS.MSig question (Re: Msg 30214) From: DODGECOLT To: ZACKSESSIONS Doesn't matter. Unlike things like _ss_size() or similar calls, you don't have to have any special permissions (read/write) to the path. -Mike -*- End of Thread. -*- 30216 17-JUN 23:15 Telcom RE: disable call waiting (Re: Msg 30189) From: NES To: ZACKSESSIONS Hay, Zack, Thanx for the uploads, I came in as you where logging off the BBS. As for the View program I think the system hit a bad sector on the hard drive it been a little flaky lattly in the heat since I havent any Aircondition just fans, also need to get a new and larger harddrive, the one I have is about full, also its an used drive... Dose os9 block out bad sector's????, I know when the drive get's too hot it gives 244 error's and 247.. but maybe one of this days I get me an MM1 and stop havening to keep fixing the multipak interface.. latter -Eric -*- 30223 18-JUN 18:51 Telcom RE: disable call waiting (Re: Msg 30216) From: ZACKSESSIONS To: NES OS9 does block out bad sectors, but only at format time. But format itself does not really do a thorough job of determining bad sectors. The ccheck utility which comes with Burke&Burke's File System Repack does the job quite nicely. Zack -*- 30231 18-JUN 22:54 Telcom RE: disable call waiting (Re: Msg 30223) From: GREGL To: ZACKSESSIONS Zack, What makes format even worse is that it simply allocates any sectors that it finds defective. A year or so later when you run dcheck you will receive warnings that sectors are allocated but not in the file system. If you forget, you might deallocate all of those sectors to get a clean report from dcheck. It would be better if dcheck created a file called something like "bad.sectors" with attributes of "--------" to allow dcheck and other utilities correctly report missing sectors from the file system. I'm not sure how ccheck handles that. But it would certainly be better to map the bad sectors to a file than to just leave them flapping in the breeze. -- Greg -*- 30233 18-JUN 23:11 Telcom RE: disable call waiting (Re: Msg 30231) From: TJSEAGROVE To: GREGL Greg, Do you know of a disk checking utility that will create a file containing the bad sectors?? Could be a good programming project for someone. What do you say Zack??!! ....Tom -*- 30234 18-JUN 23:21 Telcom RE: disable call waiting (Re: Msg 30231) From: ZACKSESSIONS To: GREGL ccheck isn't any better, in fact as far as allocating "bad" sectors it's even worse! It's up to you to use BA (another FSR utility) to mark the bad sectors as allocated. What we need is something in OS9 itself which handles "bad blocks". Blocks allocated to the bad blockkfile never to be re-allocated. Zack -*- 30235 18-JUN 23:26 Telcom RE: disable call waiting (Re: Msg 30233) From: ZACKSESSIONS To: TJSEAGROVE Get File System Repack from B&B. And use the ccheck utility. Zack -*- 30237 18-JUN 23:29 Telcom RE: disable call waiting (Re: Msg 30233) From: GREGL To: TJSEAGROVE Tom, To my knowledge, no such utility exists. That doesn't necessarily mean that ccheck doesn't since I'm not familiar with it. Offhand I don't think it does, but I could be wrong. I know that I certainly don't like bad sectors sitting around in the allocation bitmap without appearing in the file structure somewhere. In such cases, dcheck may report several sectors that are allocated but not in the file structure. How do you know which are actual bad sectors and which are actually caused by some glitch? Also, dcheck needs the ability to cross-reference linked files and remove those from the doubly allocated sector listing it reports. I had that problem bite me a couple of years ago when dcheck reported several sectors that were found more than once in the file system. At the time I assumed they were caused by linked files. Later I discovered that one of my text files had been cross-linked with an archive file because of a glitch somewhere. The problem, as should be apparent, is that you'll often ignore such things as multiply-allocated sectors and sectors that are allocated but not found in the file system if you think it's because of link files or bad sectors. It usually takes a good eye and a lot of cross-referencing with the dcheck listing to determine which are actually an error. -- Greg -*- 30238 18-JUN 23:45 Telcom RE: disable call waiting (Re: Msg 30234) From: GREGL To: ZACKSESSIONS Zack, In my humble opinion, we need to set aside eight additional bits for file permission attributes. Directory, sharable, execute, read, and write have served us well over the years but I feel that we have outgrown them. Here is a list of the attributes that I think should be added: Moveable: If this bit is set in the attributes then the file cannot be moved by disk optimization or compression utilities. Obvious files that would have this attribute set would be the "bad.sectors" file and OS9Boot. Also, the OS-9 Kernel on Track 34 should be mapped to a file called "kernel" and have the moveable attribute set. This would prevent all "sector allocated but not in file system" errors from dcheck for the kernel on Track 34. Delete: If this bit is set, the file cannot be deleted by normal methods. Write permission isn't enough to protect this one. For example, you would want to allow the users to write to the password file to change their passwords on a regular basis but you don't want them to be able to delete the file. I'm sure you can think of other places where this would be handy. Hidden: If this attribute is set, the file will not be shown in a directory listing exception with a special option in the directory utility. Also, the file would be shown only to the super-user. I'm sure you can think of places to this one - such as the "bad.sectors" file. Archive: If this bit is set then it hasn't been backed up since it was last modified. This would be great to make sure all files are backed up during incremental backups. Perform a backup once per week with only those files that have the archive bit set. If you can think of any other file permission attributes then feel free to add them to this list. -- Greg -*- 30242 19-JUN 01:08 Telcom RE: disable call waiting (Re: Msg 30238) From: EDDIEKUNS To: GREGL How about GROUP file attributes? VMS allows the following attributes: Read, Write, Delete, eXecute for Owner, System, Group, World. Nice, complete model! (Except we don't need system) You then need delete access, and not write access to delete a file. Tho with write access you can erase the contents of a file. Also, the bad.sectors shouldn't be a file, per se. Something in LSN 0 should keep track of which sectors are bad. This makes it easy to lock out new sectors, since it's part of the disk driver. A bad sector will then be identified because it's: 1) allocated 2) in the bad_sector list. Hmmm. 'course, what do you do if you have > 48 bad sectors? Hmmm. Eddie -*- 30248 19-JUN 19:37 Telcom RE: disable call waiting (Re: Msg 30238) From: ZACKSESSIONS To: GREGL I think you have covered them pretty well! Now what can we DO about it? :-) Zack -*- 30254 20-JUN 00:00 Telcom RE: disable call waiting (Re: Msg 30238) From: KNOT1 To: GREGL Greg, I believe you can get by without a DELETE bit. WRITE permision should be enough. Your password file shouldn't have Public Write permision set. Instead, a program like "passwd" should change its user ID to 0 (super user) with a call to F$SUser, then update the password file. Also, if you don't have Write permision to the directory you shouldn't be able to delete the file. I don't believe CoCo OS-9 supports this, but if you are not the owner of the file (regardless of Write permision) you shouldn't be able to delete it unless you are the owner of the directory (with Write permision) that the file is in, and then it should prompt you to proceed with deleting it. But having a DELETE bit wouldn't be bad, it just might be unnecessary. I agree with Eddie that GROUP attributes could be nice. I would also like to see SET USER (and SET GROUP) bit(s). If the SET USER bit is set for a file when it is executed, then the O.S. would do the equivalent of a F$SUser to that of the owner of the file. That's how the "passwd" program would be done. SET GROUP would be similar, but would do something like "F$SGroup" instead, if such a call existed. Unix/Zenix does HIDDEN by starting the filename with a period (e.g. ".bad_sectors", ".kernel", etc...) and this works nicely. I always felt OS-9 sould have used 512 bytes for its file descriptors rather than 256. Then they could have added more attribute bits like the ones you indicated and also add a "date/time last accessed" in addition to "created" and "modified", and also anything else needed. -Jamie (KNOT1)- -*- 30260 20-JUN 01:30 Telcom RE: disable call waiting (Re: Msg 30238) From: TIMKOONCE To: GREGL File permission attributes: Rather than simple Read/Write/Execute for owner and group, how about Read /Write/Execute/Append. In particular, opening a file with the "append" bit set in the permissions would correspond to C's "append" mode. For directories, "Append" privilege is the privilege to ADD files to the directory. You need "Write" privilege to delete files from the directory. Files with public Append (but not Write) privileges might include system error logs, mail files, etc. Anything that anyone should be able to add stuff to, but you don't want anyone able to delete or alter information. I like some of your ideas, too. - Tim -*- 30270 20-JUN 22:53 Telcom RE: disable call waiting (Re: Msg 30242) From: GREGL To: EDDIEKUNS Eddie, One solution would be to use 512-byte file descriptors. At present there is no room in the file descriptor for any other data, which is bad news. I'd like to have owner, group, and public attributes as I think that's the way to go, especially with multi-user systems. Each of the three groups could be assigned Read, Write, Execute and Delete permissions with the other attributes given global scope, per se. That would use 12 bits for owner, group and public attributes and Directory, Sharable, Movable, and Hidden taking up another 4 bits for a total of 16 bits. Although we could say that "Hidden" has an implied meaning of non-movable to free one bit for other uses. But I think it best not to have single attributes taking multiple definitions. Of course you could either use the last 256 bytes in the descriptor as an expanded segment list leaving the other bytes for future use or use all of the remaining storage in the file descriptor for the segment list. Personally, I don't see much need for more than 448 entries in the segment list and 61 should be plenty. If you have a very large hard drive then there might be a need for it. Come to think of it, we could use the last entry in the segment list as a "pointer" to additional entries that are stored in another sector for future expansion. -- Greg -*- 30274 21-JUN 01:10 Telcom RE: disable call waiting (Re: Msg 30270) From: ZACKSESSIONS To: GREGL Isn't it strange how the topic of this thread deviated from the original topic? Zack -*- 30278 21-JUN 01:26 Telcom RE: disable call waiting (Re: Msg 30270) From: EDDIEKUNS To: GREGL Yes, the 'final' segment list pointer should really point to the next block of segment lists! Great idea! Eddie -*- End of Thread. -*- 30217 17-JUN 23:33 Utilities y cable From: BANCROFT To: ALL I am putting my coco into a pc case, and need to put my floppy and hard drive contrller on a y cable. I am getting 1 addressing confilict. Both the floppy and hard drive use ff50 for drive select. The floppy also is using ff40, and does not need ff50. Any ideas how to disable ff50 on the floppy ? thanks -*- 30261 20-JUN 01:34 Utilities RE: y cable (Re: Msg 30217) From: TIMKOONCE To: BANCROFT Basically, you need to alter your floppy controller to keep it from responding. Let's see, normally the floppy controller responds to the SCS line, so you'd need to gate that with A4 so that the floppy wouldn't see SCS when A4 was high. If you need more info, tell us what exact type of floppy controller you have, and someone can tell you the exact mod needed. - Tim Koonce -*- 30267 20-JUN 19:47 Utilities RE: y cable (Re: Msg 30261) From: BANCROFT To: TIMKOONCE I have a standard radio shack fd-501 floppy controller. I bought it as soon as they came out, so if there is more than 1 version of the 501, I have the first, I am sure of that. I know that all I probably need to do is cut a trace, and probably jumper a wire from that trace to 1 other one, but I am not sure what trace I need to do this to. Thanks -*- End of Thread. -*- 30218 18-JUN 00:21 General Information Disto 1 meg upgrade From: POLTERGEIST To: GREGL Greg, I just installed the Disto 1 meg board, and I use the Disto 512K board with it. Now, I have a serious problem. It seems that with the piggyback layout, the 1 meg kit is too tall, and my case will NOT fit when I put it back on!!!! Any suggestions on how to rememdy this? -*- 30219 18-JUN 01:03 General Information RE: Disto 1 meg upgrade (Re: Msg 30218) From: EDDIEKUNS To: POLTERGEIST On my CoCo, I removed part of the ribs on the top 1/2 of the CoCo case so that the 1-meg would fit beneath it without being too cramped. Eddie -*- 30220 18-JUN 01:55 General Information RE: Disto 1 meg upgrade (Re: Msg 30218) From: GREGL To: POLTERGEIST Brian, The most common approach, and the one recommended by CRC/Disto, is to cut some of the excess from the wire wrap pins that hold the two boards together. Take a close measurement of the spacing on both boards and trim a little from each until the case fits. Of course, don't trim too much or the boards won't seat properly without touching one another - or the motherboard components. -- Greg -*- 30239 18-JUN 23:49 General Information RE: Disto 1 meg upgrade (Re: Msg 30219) From: POLTERGEIST To: EDDIEKUNS Thanks, Eddie. I may trim the leads a bit on the boards, the docs said something about that. I don't want to bash any holes in the case. Still having graphics trouble with your setup? -*- 30240 18-JUN 23:49 General Information RE: Disto 1 meg upgrade (Re: Msg 30220) From: POLTERGEIST To: GREGL Thangs, Greg, this is what I may do, once I get a hold of some decent clippers. -*- 30243 19-JUN 01:08 General Information RE: Disto 1 meg upgrade (Re: Msg 30239) From: EDDIEKUNS To: POLTERGEIST Yes. Still having graphics trouble. I'm giving up for now, since nothing CRASHES. Eddie -*- 30252 19-JUN 22:09 General Information RE: Disto 1 meg upgrade (Re: Msg 30243) From: XLIONX To: EDDIEKUNS Howdy Eddie, When you say you are having "graphics trouble": 1.) do you have ANY problems before you run MEGA? 2.) if you start your graphic stuff first, then run MEGA does it still have bugs3.) is it only one program (MVCanvas, GShell)??? 4.) are you tired of life and the persuit of coco perfection (in general)? ];-> 5.) do you take this computer to be your....oops. Just curious about your problem as you and I started with all of the same bugs. I was hoping that you would have the same luck I did with the new GIME chip. I don't have MVCanvas, but I do have GShell 1.24a and it works ok (so far). I have run MAZE in 6 windows at a time without bugs. I have run FSIM2 and other stuff without bugs (Carmen Sandiego, ya know VDG stuff)...in lower memory. Let me know what ya got for CURRENT status (bugs, crabs, gremlins, etc...) and I will try to duplicate them. Mark W. Farrell (PegaSystems) SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445) XLIONX (DELPHI) mwf@SANDV -*- 30256 20-JUN 00:16 General Information RE: Disto 1 meg upgrade (Re: Msg 30243) From: CBJ To: EDDIEKUNS Eddie, The graphics problem you describe where you see a flash that looks like a game of TETRIS that was very poorly played seems to be very common. I have seen it on three computers other than my own (all that I have access to). I gave up worrying about it. I get it when I use AUTOTERM. It flashes for a second only then is gone. I have never been "lucky" enough to have sparklies. As long as your computer doesn't crash don't worry about that flash of junk. ---Carl--- -*- 30257 20-JUN 00:17 General Information RE: Disto 1 meg upgrade (Re: Msg 30252) From: EDDIEKUNS To: XLIONX I only see the remaining problems (after resoldering the 6809 header & getting a new GIME) under the following conditions: 1) In 1-meg mode (pin 2 to select full meg) and after running 'mega' 2) On a graphics screen, usu on one with an auto-follow mouse 3) When switching from a graphics window to any window of a different type. 1 & 2 refer to the problem I get with a blinking, intermittent line of garbage I get (Did you ever get that too?) which is about 8 scan lines high and the full screen-width. Sometimes it seems like the more activity I get, the more the garbage-y line flickers on & off, sometimes it doesn't. :) Usu I get this on a screen with an auto-follow mouse (GShell & MVC, so far), but have also gotten it on a 'normal' graphics window. And *once* I got it on a text window, just recently! I had turned off the power to the drives and multipak, but not the CoCo, had pressed in the power button on the CoCo, and realized I wanted to make sure nothing important was on the RAM drive! So I did a dir on the RAM drive and listed a couple of files, and that's when I got it on the text ed window. I also noticed the TR light (Terminal Ready) on my modem blinking on & off! (With power off to the Multipak & Deluxe RS232 pak!) 3 refers to the garbage I get when CLEAR-ing from one window to the next. I get a brief view of a screen-full of (colored blocks on a text window, garbage on a graphics window) before I see the next window, when Clear-ing. Eddie -*- 30258 20-JUN 00:19 General Information RE: Disto 1 meg upgrade (Re: Msg 30256) From: EDDIEKUNS To: CBJ Yeah -- that's pretty much the attitude I've taken -- Nothing is crashing, so I'll just let it be for now. Eddie -*- 30263 20-JUN 02:20 General Information RE: Disto 1 meg upgrade (Re: Msg 30243) From: POLTERGEIST To: EDDIEKUNS What are the graphics problems that you're having? -*- 30268 20-JUN 20:50 General Information RE: Disto 1 meg upgrade (Re: Msg 30258) From: CBJ To: EDDIEKUNS Boy would it be neat if we could capture that screen and do a dump to color printer. Really interesting graphics. I notice that I get this flash of "garbage" when AUTOTERM goes from the normal 32 column screen to a 40 column screen or an 80 column screen. still it is nice to know I'm not the only one this is happening to. ---Carl--- -*- 30279 21-JUN 01:36 General Information RE: Disto 1 meg upgrade (Re: Msg 30263) From: EDDIEKUNS To: POLTERGEIST Read 30257, where I documented my current (remaining) problems. Nothing crashes, so I've temporarily given up. Eddie -*- End of Thread. -*- 30222 18-JUN 03:05 Utilities RE: UNPACK (Re: Msg 30179) From: XLIONX To: CONDUCTOR Microware would probably consider such a program TABOO. I have NEVER heard of a utility that would do this. De-compiling a two-pass ICODE file would be a pretty neat trick as basic09 strips a BUNCH of stuff out when you PACK a file. -XLIONX (DELPHI) -*- 30230 18-JUN 21:02 Utilities RE: UNPACK (Re: Msg 30222) From: CONDUCTOR To: XLIONX Thanks for the input. -*- End of Thread. -*- 30224 18-JUN 20:18 General Information WHERE TO FIND PROGRAMS From: MBB63 To: ALL I WOULD LIKE TO DOWNLOAD SHELL+, LABEL COMMAND, DIRECTIONS ON HOW TO INSTALL. ALSO DIRECTIONS ON HOW TO USE THE AR PROGRAM. WHERE DO I FIND THESE ON OS9 ONLINE. STILL A LONG WAY TO GO ON BEING COMFORTABLE USING DELPHI AND OS9 MARIE BOUDET -*- 30236 18-JUN 23:29 General Information RE: WHERE TO FIND PROGRAMS (Re: Msg 30224) From: ZACKSESSIONS To: MBB63 (NR) For more specific help, we need to know which term program you will be using to do the download with. Once you get ar, you need to move it to your CMDS cirectory, set it's execution attribute, OS9: attr /dd/cmds/ar e pe The to de-arc an archive do something like: OS9: ar -x /dd/download/shellplus.ar That will dearchive the archive putting all the file in the archive in your current data directory. Zack -*- End of Thread. -*- 30225 18-JUN 20:19 Applications RE: OS9 Development System (Re: Msg 30188) From: RADARBUZZ To: TJSEAGROVE Tom, Yea, I had already thought of that. I ran across the COCOPro ad in Rainbowand called the BBS #. No cigar. Still looking though! Got to be one some- where. -Jeff -*- 30241 19-JUN 00:06 Applications RE: OS9 Development System (Re: Msg 30184) From: CBJ To: RADARBUZZ Jeff, I don't know if it's for real but Computer Plus is advertising that package at $89.95 in the June and July issues of Rainbow. I just noticed it myself and am going to see if they really have it. ---Carl--- -*- 30290 22-JUN 00:52 Applications RE: OS9 Development System (Re: Msg 30184) From: BACKFIRE To: ALL I found the last copy at the Port Orchard, WA Radio Shack...after checking all over the Puget Sound area...keep trying though, the tools are nice. Selling the pkg at 19.95 without advertising the change is just Tandy's way of saying goodbye to us... -*- 30299 22-JUN 22:23 Applications RE: OS9 Development System (Re: Msg 30290) From: RAGTIMER To: BACKFIRE One way that might help is to go to a RadShack Computer Center -- I mean a full one not affiliated with a regular Shack store. I know they carry supplies for old printers and such stuff, under a COMPLETELY DIFFERENT set of catalog numbers. So try them before hunting down someone who'll let you borrow their Developer's System. Also, by now most of the really good stuff in there is available PD ( like Tim Koonce's MAKE will soon be) or can be scrounged from Level 1. -*- 30312 23-JUN 01:50 Applications RE: OS9 Development System (Re: Msg 30299) From: BACKFIRE To: RAGTIMER I tried that approach...had one of the salesman at the Computer Center in Tacoma looking all over for C, Pascal and The Dev Pkg. Then I swapped my copy of Logo for C (our local club Pres had never used it. ), and he told me about the dev pkg. Now (after about a 10 year wait) I can learn to use C. I had patched my Level 1 package already...but it's been about the past year that I7ve really started using OS-9. ((I still have problems...gport now tells me that my printer and /t2 are not SCF devices!!...but the descriptors and drivers seem to be correc t) -*- End of Thread. -*- 30226 18-JUN 20:20 General Information RE: DupFile & DCheck (Re: Msg 30194) From: RADARBUZZ To: BRIANWHITE Brian, What do *I* think? . Well, I've always thought that the copy commandshould have been written to recognize whether or not you were copying a file tothe same device. If so, it should simply dupe the file by increasing that old link count. If not, then really write out another copy to the different device. As for a move command, this is how I think that should work: If you're moving on the same device then just change the directory pointer thingy. If you're moving to another device, then write a copy and delete the original. Now that I got all that out of my system, here is what I think regarding Dupfile: Make it capable of all the above. And, (I may be asking for too muchhere) incorperate the features presently available in the revised COPY command from KLINDSAY here in the utilities database (Shell+ wildcards, auto rewrite (-r), copy(or Move!) to directory (-w=), ect...). Now that would be something! Do you think it would be too great an under- taking, or not? I won't hold my breath, but I hope my thoughts are feasable, -Jeff -*- 30232 18-JUN 23:06 General Information RE: DupFile & DCheck (Re: Msg 30226) From: GREGL To: RADARBUZZ Jeff, I disagree, at least partially. The copy command should create a new directory entry, create a new file descriptor, and physically copy the contents of the file. If that were not the case then you would be forced to copy the file to a different device to create a backup file that wouldn't be altered when you alter the original. However, I agree that the copy command should at least have an option to duplicate the file using the same file descriptor - that is, by creating only a new directory entry that points to the existing file descriptor and increments the link count. It should also accept wildcards and prompt to overwrite existing files. I think your other comments are right on the money. -- Greg -*- 30342 24-JUN 02:51 General Information RE: DupFile & DCheck (Re: Msg 30226) From: BRIANWHITE To: RADARBUZZ Jeff, Those are much the same things I had planned. You forgot to mention the ability to put plus signs between filenames to merge them together as they are copied... Oh, I wish I didn't have to go to work... Brian -*- End of Thread. -*- 30227 18-JUN 20:22 General Information WHERE DO I FIND PROGRAMS From: MBB63 To: ALL I WOULD LIKE TO DOWNLOAD SHELL+, LABEL COMMAND, DIREC HOW TO INSTALL. ALSO DIRECTIONS FOR USING AR PROGRAM. MARIE BOUDET -*- End of Thread. -*- 30244 19-JUN 02:16 General Information RE: failing MPI (Re: Msg 30182) From: KNOT1 To: TEDJAEGER This might be unlikely, but could your CoCo have a "compatibility" probnem with the new MPI's? Seeing as each CoCo seems to have its own personality, maybe trying it with a different one might produce some results. Otherwise, I suspect that you may need to find someone who has successfully hooked up a RS HD with the newer MPI. I hope you get it working! -Jamie (KNOT1)- -*- 30363 25-JUN 01:16 General Information RE: failing MPI (Re: Msg 30167) From: DALEP To: TEDJAEGER Ted, You've got me stumped here! Try a quick mail note to KDarling. He may be able to help you. Dale -*- 30374 25-JUN 19:30 General Information RE: failing MPI (Re: Msg 30363) From: TEDJAEGER To: DALEP Thanks, Dale. I think it was the HD instead of the MPI. The old (7 years) Tandy 15 meg HD died three days ago. Kept getting harder and harder to spin up to speed and finally would not spin at all! It lived a good life! --Bests, TedJaeger -*- 30406 26-JUN 21:23 General Information RE: failing MPI (Re: Msg 30374) From: 6809ER To: TEDJAEGER If you are looking for a replacement Tandy 15 Meg hard drive, I have one that was only used for a year and many years left in it. Let me know (use Email) if we can make a deal. Steve , 6809ER -*- 30434 29-JUN 02:27 General Information RE: failing MPI (Re: Msg 30374) From: DALEP To: TEDJAEGER Ted, Sorry to hear about your hard drive. Hope you are able to find another one at a decent price. The scuzzi drives are nice. Best Regards, Dale -*- 30454 30-JUN 22:47 General Information RE: failing MPI (Re: Msg 30434) From: TEDJAEGER To: DALEP Well, thanks Dale. About two days after I think my HD died my power supply died. I am wondering now if my HD is still OK and failed to spin up because it was not getting the right amps. I'll find out when a replacement power supply gets here. I just got the new gfx2. Thanks for the info and help you have provided in getting to us. Bests, TedJaeger -*- 30621 9-JUL 01:47 General Information RE: failing MPI (Re: Msg 30454) From: DALEP To: TEDJAEGER (NR) Ted, Good luck with your hard drive. Hope it works out ok. More than likely the data on the disk should be ok. Certainly hope so. Did you have the data backed up? CUL. Dale -*- End of Thread. -*- 30245 19-JUN 02:18 General Information RE: CHD Patch (Re: Msg 30196) From: KNOT1 To: BRIANWHITE Well, I was/am hoping to hookup a terminal (my CoCo 2) to my CoCo 3. I have my CoCo down in my basement, and it would be nice to have a terminal upstairs were other family members could easily access it, and it would also be a convenience for me. In this vein, I setiup an /H0/USR directory. Then, like the Zenix system I use at work, I removed public write permisions from just about everything. When I tested it, I had problems with both the "login" and Shell's "chd". That's why I decided to try to fix it. I looked for the $103F86 pattern for I$Chgdir, and then for any nearby "lda #"'s. Wasn't too hard to fix after that. -Jamie (KNOT1)- -*- 30246 19-JUN 04:13 Graphics & Music RE: Clipboard (Re: Msg 30193) From: MIKEHAALAND To: BRIANWHITE Sure! If you're going to use a specific CB buffer for B&W data just make sure post what buffer it is. But I do have a Q. Is the stuff you are planning to Clip specific to B&Ws ONLY! If so you don't really need to use the CB group. Just use your prcess ID number for the group and use any buffer number within that group. Unless the data is useable to another program you don't really need to worry about using the ClipBoard. Know what I mean? Mike -*- 30247 19-JUN 18:50 Programmers Den IBM keyboard. From: NES To: ALL Any body have the pin out of an IBM keyboard connector, I would like to add an IBM keyboard to my coco without paying $200 dollars for the one that's in rain bow... I know the the keyboard send's its data serially.. any help out there?/ -Eric -*- 30265 20-JUN 07:24 Programmers Den RE: IBM keyboard. (Re: Msg 30247) From: DONTHRASH To: NES Eric, In the May 1983 issue of Byte there is an article that will tell you just about all you want to know about the IBM keyboards. I found the magazine in one of the local college libraries. If you have trouble locating this issue drop me a note and I will make copies of my copies and send them to you. Let me know how you make out with your project. I have been trying to find time to work on a similar project. Time is tight in the summer. Hope this helps, Don Thrash -*- End of Thread. -*- 30250 19-JUN 21:48 General Information MM/1 From: COLINMCKAY To: PKW Greetings! I sent this message originally in mail, but I guess it didn't make it... Hope you enjoyed your belated honeymoon. Our local club just had its meeting tonight (Thursday), and there was much excitement (Wonder why?) Anyway, there were also a few questions... 1. I called to put down $150 the other day using my credit card. Does the $50 discount still apply? If not, I will send a cheque. 2. It is possible to join two graphics chips and generate pictures of 720*540*256, which is officially supported by Signetics. Is this supported? 3. Also saw the specs for the FHL machine, and mild interest was expressed in the AT keyboard. Any future plans on the MM/1? 4. What is the option for non-CM8/Magnavox monitors? Is this supported on the main board? Will it use stock VGA-type monitors, or does it require multisync? 5. WRT the optional IO board. How much? And when? 6. Without the optional IO board, how do you add a hard drive? 7. One member heard the word midi, and his eyes lit up. He wants to know exactly what is involved in configuring the DB25 for midi, and how easy it is to switch back to normal (switch?) 8. What is the planned cost of the palette controller? 9. One of your info sheets mentioned 12.5/15 MHz. Haven't seen the 12.5 before. May we ask why? 10. Once you get the second board, do you have to upgrade the memory right away? (Beyond 1 Meg.) 11. What games does it come with? Enquiring minds want to know! Saw this mentioned in your info flyer. 12. Will there be a kit form available for those who want sockets? What is the expected release date of the kit? 13. Will it be CSA (Canadian Standards Association), the equivalent of UL/FCC up here, approved? Since we don't have to wait for FCC certification up here, any chance of getting one NOW? (RIGHT NOW) (Big GRIN!) 14. What size is the power supply? 15. Is the software set up for a Logitech or a Microsoft type mouse?. Any recommentation either way? Thanks for your time. Colin McKay Ottawa-Carleton OS9 Users Group -*- 30282 21-JUN 20:24 General Information RE: MM/1 (Re: Msg 30250) From: NES To: COLINMCKAY Colin, The system will support the a stander serial mouse, most chip's are surface mount and there are not sockets made for those, The CPU and a couple of majore chip's are in sockets, except the Graphics processer which on socket is avaible for it. As for the Midi port, You choose when you order weather you wount an RS-232 or MIDI port (in and out and thru). they made the system 15Mhz instade of 15/12.5Mhz. There is know expantion slots, Just an main board and the Optional IO board. main board has the CPU,Graphics controller, two serial (One can be an MIDI) ports and 1meg of ram, keyboard interface, disk controler. BTW the system is very low power so requres just a small power supply. the Second board has the SCSI interface, 3 more RS-232 port(one for mouse), Ram upgrade max 9 megs, two paralell ports, stereo port sample and play back. Main board... about 749.00 second board $399, if you buy both $1000. about. I think the system has everything the average user would need, software that is comming out is an BBS package that supports FIDO NET mail transfer, MV canvase, Video digitizer.. also when you buy the MM1 you get.... OSK DOS(os9), C and Basic00, a com program, text editor , graphics editor, and some other goodys. -ERIC -*- 30308 23-JUN 00:44 General Information RE: MM/1 (Re: Msg 30250) From: PKW To: COLINMCKAY Clin, Thanks for all the good questions! Let's take them one at a time. SOme may require no comment. 1) Your $50 discount does apply. 2) It is not trivial to gang two VSCs together. THis is done in the CD-I machines and is quite impressive to see. However, keep in mind that we do have 320 x 400 in 256 colors, and that is also quite impressive. Also keep in mind that we are not making a killing of the MM/1 at the $779 price, and adding the second VSC would take the MM/1 out of the reach of thousands of CoCo users. 3) The added convenience of the AT keyboard is a nice feature, but can easily be accomodated with CTRL-0 or Caps Lock as needed. 4) Concerning non CM-8 monitors -- there is a simple approach we implemented to let you use a wide variety of monitors. Call for details. 202 232 4246 5) /send 5) IO Board is $345 when bought with the base system, $399 without. 6) You must have the I/O board for hard drive use, but frankly, two HD floppies at 3 ms will keep you going for quite a while. 7) It is easy to change from MIDI to DB25. Call for details. 8) Call. 9) 12.5 MHz is out. We re 15 Mz only now. At one time, we considered a 12.5 MHz machine at a lower cost, but decided to keep the cost down and just standardize on 15 MHz. 10) No. 11) Games? Call. 12) Kit is available, although the current one has most chips on it, and already socketed. 13) Call. 14) 200 watt. 15) Any powered mouse will do. Thanks, COlin! -*- 30313 23-JUN 01:51 General Information RE: MM/1 (Re: Msg 30308) From: KSCALES To: PKW Paul - Well, now that I've gone and put my deposit down on a MM/1, I guess I'm probably going to spend the next two months or so just thinking and planning... and asking questions. If I get to be too much of a nuisance, remember that FCC approval doesn't carry all that much weight up here in Canada, and having one would probably keep me too pre-occupied to bother you with more questions . Anyways, Colin McKay has already put forward the questions that came up at our last UG meeting, and we are watching for your reply. A few more questions have come to mind since: - Will you be providing full technical documentation, either as part of the standard package, or as a special order item? (schematics, bus interface info, tech specs on the "special" chips, etc.) - Will you be providing full Microware documentation? - Monitor interface: yes, CM-8 compatible. But MY CM-8 compatible seems to be on its last legs (and new folks coming onboard will probably find CM-8s/8CM515s somewhat hard to come by). A VGA-type would make more sense nowadays. Sooo... will VGA connection be supported (easily)? Would we be best to look for multi-sync for now or future? - Will the I/O board be available for shipping with the initial production run? - No audio without I/O board? - What is the hook-up arrangement for the audio ports? (Standard audio/RCA jacks?) - If I press CTRL-ALT-RESET on the MM1/1, whose mugs do I see? More to come, probably... Cheers... Ken Scales (the other) Co-President Ottawa-Carleton OS9 Users' Group -*- 30332 23-JUN 22:48 68K-OS9 RE: MM/1 (Re: Msg 30313) From: DWHILL To: ALL Speaking of documentation, has there been any electronics press coverage of the 68070 and its related graphics chips from Phillips, or CD-I in general? I've been cut off from my usual sources since I was laid off in March and have a feeling I've been missing a lot of news. Does Phillips provide any information through its distributors? --Damon -*- 30334 24-JUN 01:25 68K-OS9 Compact Disk Interactive (Re: Msg 30332) From: OS9UGPRES To: DWHILL CD-I has been covered lately. Motorola announced support for it with some new, very powerful chips intended to be used in players worldwide. More info is expected in September after the meeting of an international standards group on video compression methods. -*- 30410 27-JUN 00:00 General Information RE: MM/1 (Re: Msg 30313) From: PKW To: KSCALES Ken, All non-proprietary tech docs will be available. Not all will be shipped, but to tell the truth, we have only planned the user manuals at this point. Full tech docs, in the tradition of most computers, will be available separately at relatively low cost. Some tech docs will SURELY be included. Sound IS available on the main board -- a la IBM sound. I/O board WILL be available at the same time as the CPU board. Best to get a color multisync if your CM-8 is on the way out. Cables should be availbe in the fall from us, but of course you are free to make your own. Sufficient tech information will be made availalbe to allow you to do this. Thx for the questions! Paul -*- End of Thread. -*- 30251 19-JUN 22:06 General Information RE: The T.O.P.S User Group (Re: Msg 30034) From: TJMARTIN To: KEITHMARCH Yup, my submission did not seem to make it. dunno why. Maybe it was felt to be TOPS property or something. I will try to leave mail for data base manager, see what happened. The index is surely intended for distribution. TOPS stuff is meant for such public distribution apparently. -*- 30262 20-JUN 01:56 General Information RE: The T.O.P.S User Group (Re: Msg 30251) From: TIMKOONCE To: TJMARTIN Your TOPS submission is already in the database, in the "New Stuff" area. We have it set up now so that all new uploads go into "New Stuff" for about a month before they get moved to other areas. - Tim Koonce -*- End of Thread. -*- 30253 19-JUN 22:37 Graphics & Music Picture Window } V1.0 From: LL To: ALL Hi everybody! I am very happy to inform you that Picture Window Version 1.0 is now ready, and available for $7.00 from SEESOF, 1973 Fairgrounds Rd., Burton, SC 29902. This version includes a universal picture printing feature that should work with most dot matrix printers. The program requires Multi-Vue, hires mouse and 512K CoCo 3. It is a window picture drawing program that makes & edits & prints VEF bit image pictures. PicWin09 is available in the database for a trial copy of all features except printing. LL -*- 30255 20-JUN 00:04 Utilities RE: New Dir (Re: Msg 30111) From: SCG To: KLINDSAY Yes I do use your COPY also VERY VERY NICE. Its Great to have guys like you, helping us all out and bettering our systems THANKS!!! Steve Gilbert * Os9 Sysop * ***PC BBS*** *516-795-5874 -*- 30264 20-JUN 02:35 General Information Hello! From: TIMKIENTZLE To: ALL When my girlfriend and I decided to get married, we had a hard time deciding what to do about our last names. Although the "modern" solution to this problem seems to be for each spouse to keep their unmarried name, we felt that having a single "family name" was very important. So, we have decided to both take a new last name, effective August 4, the date we will be married. So, as of August 4, I will be using the Delphi Username TIMKIENTZLE, rather than my old Delphi Username TIMKOONCE. EMail will still get to me if addressed to either Username, though I may occasionally miss forum messages addressed to my old username. Between now and then, I will be logging on under both names. - Tim Koonce (soon to be Tim Kientzle) -*- 30266 20-JUN 18:15 General Information RE: Hello! (Re: Msg 30264) From: ZACKSESSIONS To: TIMKIENTZLE Congratulations, Tim! And Best Wishes to the Bride-to-Be! Interesting that you two decided to go with an entirely DIFFERENT last name for both of you. Never heard of doing that. Umm, would it be too personal of a question to ask just why y'all picked KIENTZLE? Zack -*- 30272 21-JUN 01:06 General Information RE: Hello! (Re: Msg 30266) From: TIMKOONCE To: ZACKSESSIONS Yes, it does seem a novel solution, I suppose, but it was the only one that really worked for us. After we decided this, we did meet another couple who had done the same thing, so it is doable! Kientzle is actually one of the many mis-spellings (Koonce being another, BTW) of the name of my ancestor who came to the New World from Switzerland (Yes, back then it was still the "New World". :-) We were hoping to find a more "neutral" name, but couldn't find another one we both liked. - Tim (who is never really sure these days what name to use) -*- 30273 21-JUN 01:08 General Information RE: Hello! (Re: Msg 30272) From: ZACKSESSIONS To: TIMKOONCE When I was inthe Navy, I served with a shipmate who's last name was Koontz. Very similar, but a very distinct difference in pronounciation. Wow, you can trace you ancestry that far back? Impressive! Any chance you'll be making it to the fall "October Fest"? Zack -*- 30283 21-JUN 20:38 General Information RE: Hello! (Re: Msg 30264) From: NES To: TIMKIENTZLE Tim, sound's yuppy to me, Guess I am old fashion, I know alot of people keep there (women) last name for professional reasons, but this is a first make up a new name using both last names... How do you say "Kientzle". I wish you and your new bride well, Just remember the first year is a killer. -Eric Stringer or mix with the wife Eric Stralonka.... -*- End of Thread. -*- 30269 20-JUN 21:18 General Information RE: ST-125 Seagate? (Re: Msg 30190) From: JANG To: ZACKSESSIONS I DON'T HAVE A SEAGATE AS MY /H0. IT'S A CMI 5412 AND I DON'T SEE ANYTHING CONSPICUIOUS THERE. IT'S PART OF A SYSTEM I GOT FROM THE GUY AT ARIZONA SMALL", DOES ANYONE KNOW WGERE THE TERMINATING RESISTOR IS. ACTUALLY I WILL BE GETTING THE MANUAL SOON FOR MY NEW ST-125 AND IT WILL TELL ME WHERE IT'S T.R. IS SO I MAY JUST ATTEMPT TO MAKE IT SVEW ^eHR$A9"UL jUjHRT%"u$iErr%j$(Je]?PV It ANYONE ELSE KNOWS WHAT TO LOOK FOR I SURE COULD USE SOME HELP. THANK YOU SO MUCH ZACK FOR YOUR INTEREST.. JERRY ANGUS -*- 30295 22-JUN 01:55 General Information RE: ST-125 Seagate? (Re: Msg 30269) From: DAMIONGREY To: JANG RE: Term resistor : I don't know if this helps any, but the term. resistor is usually blue, beige or yellow (in my experience) and looks either like a normal dip chip, or like just one side of a dip chip (a sip, actually) HD's it's usually the latter. on my old Tandon 15 meg it was, so even your old CMI should be that way. It's usually near the jumpers, but not always. Personally, I would make the 20Meg h0 if I were you, not just to avoid the problems, but also to make things more usuable. Hope this helps. - Greg -*- 30323 23-JUN 14:09 General Information RE: ST-125 Seagate? (Re: Msg 30295) From: JANG To: DAMIONGREY Yes, thank-you so much.. It was a okhre(dark-yellow-thing), righ next to the jumper-(6-element)unit.. As it turns out, with my WD1002-SHD controller I would have needed another Hard-Drive EXACTIALLY the same to get it to work OK ..so I have resigned myself to the conclusion that i will just transfer everything over to the new 20 Megger (via-floppies) and put the old CMI-Dianasour on the shelf as a backup if-need-be, I got the new ST-125 formated(finally) late-last night and it seems fi ne.. Thanks To* Zack Sessions, Steve Gilbert, The people at CRC and ole-good buddy Roger Krupski (RGB-DOS)... Thanks to all for your concernn. Jerry Angus..Pres. Island CoCo Club BBS 516-795-7422 -*- 30324 23-JUN 14:17 General Information RE: ST-125 Seagate? (Re: Msg 30190) From: JANG To: ZACKSESSIONS Yes, I found it finally..Zack.. Thanks again for your help.. I got the new drive formated and will end-up using it by itself so thr Terminating resistor will stay in there.. It'll be a chore transfering about 9 Megs of data of XX over to it but some "House-cleaning" was due anyway... thanks a lot for your help.... Later....... J.Angus (JANG) -*- End of Thread. -*- 30271 20-JUN 23:46 General Information 1 meg upgrade kit From: POLTERGEIST To: DISTO Tony, What's the purpose for shorting a resistor with the 1 meg upgrade kit? Is this related to the timing bug with some GIME chips? -*- 30349 24-JUN 08:36 General Information RE: 1 meg upgrade kit (Re: Msg 30271) From: DISTO To: POLTERGEIST Yes, it has to do something with the RAS timming on the RAM chips. It seems that there are different versions of the GIME chip, and that some people require another resistor rather than a short. -Tony -*- End of Thread. -*- 30275 21-JUN 01:23 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29983) From: PAULSENIURA To: TIMKOONCE -> BTW, you don't need SBF to drive a tape, you can just write an SCF -> driver. Tell us what you know, and maybe people on here can help -> you with that tape drive. I can't possibly type the entire subset of QIC docs I have received from Freeman Associates, but they will gladly send anyone copies of the various QIC standards to anyone wanting them, without cost (they've even faxed me a couple of pages on their nickel). ANSI has adopted quite a lot of these specs. I think I left these docs at the office (where they'd be most useless, of course, wouldn't ya know it?!). I will post Freeman Assoc.'s phone number and address once I get those docs back home. But right now I can tell you writing a driver with SCF will be impossible. QIC implies "smart drives" as I told Eddie Kunse tonight already. The I/O is done in "block" fashion not "single character" fashion. The "QIC Common Command Set" applies to any such smart drive, whether they use the floppy-drive pin layout or the SCSI layout, etc. If you have, for example, a QIC drive that is designed to hook up to a SCSI interface, you still must send to the drive the "commands" along those SCSI signal lines. It is hard to explain without the docs. For the floppy-drive QIC-40 standard, you will send the drive some commands along the "head step" signal line. No, the "head step" is *not* used to have the tape drive step forwards or backwards to the next track on the tape. The commands are bit-streamed in any of the normal head-stepping set timing standards along this "head step" signal line in a SERIAL fashion. The QIC folks barely describe how a WD1793 could be programmed to do this -- I mean "barely". Without a "smart controller", our OS9 driver will need to lock out IRQs while all this is going on. Not only do you send commands to the drive utilizing serial bit streams along a normal floppy signal lines, you also get Status messages from these smart drives from other floppy signal lines in that same serialized fashion. IRQs must be locked out to read these signals, as the old CoCo bit-banger port is programmed to do! But you must do this thru a WD17x3 chip, not an ACIA chip, since QIC-40 is designed for normal floppy controller signal lines. Another QIC-xxx standard will describe how SCSI controller signals are used for the very same kind of I/O to a smart drive. It's better to do QIC thru a controller card that can allow DMA access to these drives. Such is what IBM PC floppy cards can do! You'd think the Disto and Performance Peripherals "no-halt" controllers could do this, *especially* Isted /FHL's "Eliminator" and B&B's "CoCoXT" board, since these do use IBM-PC controller cards. Well, no one has come up with QIC drivers for any of these cards. I did see a blurb in Microware's Source book on some companies supporting QIC (not QIC-40 tho), but it looks like we're not going to get to use real tape drives with any OS9 system we can afford, despite the low cost of these drives, because no one wants to invent these critters. As I said, I'll try to find the QIC docs I do have, and let y'all call Freeman Assoc. to ask for the ones you want to start with. The "QIC Common Command Set" is required for any other document, and you'll most likely order several of these docs to get a complete set for just one interface. Remember, ANSI has adopted quite a lot of these items as real standards for tape drives and software drivers to use. Normal floppy controllers are all that's required, from what I have been able to gather, such as the WD17x3 chip sets. The Colorado Memory Systems (CMS) company who makes the tape drives JameCo is selling, is doubtful a good source of information, even tho they have heard of OS9 and were extatic to hear we were trying to write a driver. Wait until I can post the whole set of QIC docs available, then I can recommend which ones to get in order to start learning more about the coming age of Smart Drives. -- Thx, Paul Seniura. -*- 30280 21-JUN 01:43 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29948) From: PAULSENIURA To: EDDIEKUNS Pardon me for getting back on Delphi so infrequently .. "things" have not been very nice during this span of time for me, personally ... -> One reason that you don't see a whole bunch of software out there for -> the CoCo 3 & OS-9 is that it takes TIME! It takes time to 1) Become -> familiar with OS-9 2) Become familiar with OS-9 guts 3) Write and debug -> your program. I don't mean to disagree, nor to argue, and I do understand that it takes time. How long must it take, though???? OS-9 has been around for such a long time I'm not able to put an accurate figure on it myself), but OS-9 is OS-9 (supposedly) especially if you're writing things in 'C' or Basic09 or PASCAL. I didn't mean to be specifically talking about the CoCo3 (or even CoCo1/2 Level 1 for that matter). But since we brought that up, I personally have had the CoCo3 for 3 years. I have had a 64k CoCo1 for (good grief) 8 years, sold it to a friend, got it back now for repairs(!). So take the Level 1 or Level 2 as a reference, then add on the year or so Tandy gave to developers before the CoCo3 itself was shipped to the stores. We're talking 4 years minimum we've been waiting for things to come out. And now the word is Tandy is dropping the whole ball of wax. Short life span, eh? I get the idea my "gripes" might be misleading: they were not directed at any one machine (e.g. the CoCo3) or any certain people/companies. I did include the idea that no matter what the CoCo market moves to -- it could be a Cray/OS9 port for all I care -- if the users can't have easy-to-operate interfaces (MultiVue was a 'start'), popular software available (where's WordPerfect/OS9, did ya know they were suppose to have a Unix version coming?), and hardware to use (remember my mentioning the QIC tape drives?), the OS9 market is *not* going to be very popular at all with the home/office environment. It'll necessarily stay in the industrial applications. And frankly I'm worried about that particular point. At least KLE "plans" on a bunch of support, but FHL is the only company "visible" where I can "see" it and get those cards/interfaces "right now" if I need them. They should have been developed a long time ago (uh where was Tandy to give 'em to us on the CoCo? why did we have to rely on B&B and Disto et al.?), so that those interfaces could have been involved with the various QIC/ANSI and IBM decision-making teams (yes ANSI has accepted quite a lot of the QIC tech specs as de-facto standards, including QIC-40; I *have* their official docs in hand!). Now let's move to the Atari/OS9 front: Microware *told* me themselves over the phone (I called Des Moines) that there is NO WINDOWs for the Atari OSK system. Not even InVisions; it never saw the light of day. Oh they mentioned some company in their "Source" book I could call to see what their window system is like. I know Kevin Darling had a rudimentary windows version, but still there is no "official" supported installable subsystem for Atari/OS9 windows. As a matter of fact, Microware couldn't recommend any other Atari port, Amiga port, OSK in general *including* KLE & FHL new products or old, that had true windows. I asked Microware point blank: "You mean Tandy was the only one who got windows going for any OS9 system, any flavor?" and Microware said "Yes". Now someone better tell me what in blue-blazes is going on, where do you-all expect the CoCo market to go, if we can't have true windows at the o.s. level? *THIS* is the kind of stuff I'm talking about -- a simple item gets DROPPED and I start WORRYING all over the place where we're headed. My lord ... even IBM has FINALLY accepted that Windows AND Multitasking is the way of the future home & office workstations. Good grief -- did you hear what I'm saying? IBM * finally* got that through their thick skulls, and probably after they heard me gripe at a number of local S.E.s (IBM System Engineers) about how our CoCo/OS9 can run rings around their MesSy-DOS system, for SEVERAL YEARS! Now that you know what IBM knows, someone needs to heed the warnings I've typed about in this and previous messages. OS9 isn't going to be popular with home & office computers if someone doesn't get "RAVE" and other packages GOING *AND* SELLING to the users of the various flavors of OS9/OSK, as well as MOTIVATE the DEVELOPERS TO USE RAVE!!!! Savy, KLE and FHL? Do NOT invent your own graphics subsystem -- use the official Microware one, or the OS9 market is going to be split across a lot of different kinds of graphics SUBsystems underneath your flavors of OS9. This also goes for Atari ports and Amiga (Australia) and everyone else. If this "hurts" the existing CoCo graphics so-called standard, I'm playing the world's smallest violin right now. Your source code should be written in such a way that would permit you to change to a different set of protocols if need- be. Most of you game programmers don't even use OS9 as a base to begin with -- those of you who DO use OS9 as a base, you use the old VDG graphics wherein you "peek & poke" your own stuff to the video buffer (reading this, UME fans?). I can see why: for speed mainly, but also because you're porting your IBM, Apple, Atari, or Commodore source code, that does the same thing, to OS9. Cheapest way out for you, since Tandy dictated you write your games for OS9 if you want Tandy to sell 'em. I can see all that. Nonetheless, your source code *should* be portable to "RAVE" that ought to provide a similar environment for peeking/poking (does it?) if the application absolutely must have it that way. Better start thinking NOW about adopting "RAVE" as the standard, or everyone start agreeing on another standard. It's probably already too late, huh!? Going to hafta stick with the CoCo window standards, maybe enhance them a little, eh? Did any of you know that ANSI has produced the "Meta-Graphics" instructions? They have expanded those video controls to the point that graphics commands can be sent via escape-code sequences. Makes ya wonder where they got that idea. :- ) Anyway, the POINT HERE is that ANSI *HAS* officially endorsed what WILL BE the protocol to use across wires & transmission lines to draw things graphically, no matter what kind of boxes are talking to each other. And I understand it also includes the kind of window support we already have under OS9, including drop-down menus, highlited options via mouse (thru a modem remote application even!), well it's a whole 'nuther book we'll have to buy in order to complete the ANSI 3.64 specs. Remember, these are SPECS, protocols, Standards, etc., and you can either be compatible with them, or not. And it should be implemented at the o.s. level thereby relieving the application code from doing it on a whim-by-whim note -- that source code for the application could be PORTED TO OTHER NON-OS9 MACHINES without much rewriting troubles, too! -> Standards? KBCom NOW supports the VT100 protocal. No, I don't support -> ANSI, if you want to call that a standard :) but I plan on eventually -> adding a versioin of ANSI that seems to be more widely used than others. -> (IBM PC ANSI.SYS) You should not HAVE to support it in your programs: the o.s. should support it at a driver or pipe/filter level. That is one point I'll give to IBM/MicroSoft, in that they made ANSI part of the o.s. No one's done it *yet* for OS9 the right way (well I did share my ANSIFILx filter on CIS, the *first* of anything "doing ANSI" for OS9-L2 windows, and it still is the only one I've seen [including your KBCom] that can come close to supporting most of the ANSI commands as such, but the CoCo3 runs out of steam when it comes to hooking my pgm up to the StdOut of a t.p. & modem running faster than 1200-bps; I know: "Rewrite it in 'C'"!). Yep, OS9 needs a system-level ANSI emulator, and no one's done it yet despite how ANSI is sorta built-into Unix as well (termcap files & such). You see, I spent a bunch of time researching the ANSI 3.64 specs: *that* is the official name for these video controls, the book costs around $25, but I'd strongly suggest going to your local city or university library and do some copying. You'll be amazed -- once you compare 3.64 with VT100, all you will NEED to support is 3.64 itself cuz you'll AUTOMATICALLY have VT100 that way. You sure will, *if* you support enough of a subset of commands. Look at the OFFICIAL docs, look at some whittled-down docs (a.k.a. IBM PC-DOS Tech guides), and you'll find out very quickly they ALL DO MATCH, there is NO such thing as "IBM ANSI" vs. someone else's. Not if you support ANSI correctly with the largest subset capable of being handled. I'm not "proud" of ANSI at all -- it is such a backward control language -- who ever thought of putting the "command" *AFTER* all the data bytes?!?!? Sheer stupidness if you ask me! But to do it, ya gotta do it their way. >:-( I merely mention lots of people have misconceptions about ANSI -- it *is* a standard, or the big corporations would not have all agreed with each other in this manner. It's a crying shame that this has been sooo misunderstood. I want to help give peace to these kinds of ideas. -> KLE & FHL are at war? Actually, I find their machines as being aimed -> at very different niches. They may 'fight' to move people from one -> niche into another, but the niches are pretty well defined I think. When they are both after my pocketbook, it's a "war". Their "niches" both target would-be CoCo3 owners to upgrade to the 68000 CPU. I've read both of their brochures and ads -- I do not see any "well defined" niches as you put it. :-) -> Delphi is a graveyard? I'm speechless! It's all I can do to keep up -> here! The OS-9 forum traffic is growing in volume as time goes on. Yeah, I do see there's lots of dialog. I didn't make my point very well. To illustrate: someone "just" posted PCDOS.AR not very long ago, and yet it's NOT the newest OR the best-fixed-up. I can prove it with the way the CC3Disk patches mismatch from one of the latest versions uploaded to CIS over a year ago that I pulled down (I haven't had access to CIS since). (Maybe I can find it one of these days & post it, too, and have the OS9 Forum Sysop go double-check for permission from the author since I have no access there myself for now.) That's just one example of how things are dead on GEnie and Delphi -- there are more, but PCDOS being back-level is putting our SEA Arc 6.02 port way behind schedule (i.e. PCDOS.AR is the most important "error" I've seen on the Delphi uploads so far). Another way to say how dead things are: compare the amount of new strictly-OS9 uploads on CIS vs. GEnie and Delphi put together!! -> UME & standard MIDI: I really know very little about this one. Just -> one comment: Give the man time! If you mean Mike Knudsen, he's had 5 years already according to his own UME booklets! :-) But my point wasn't taken with a larger scope I had in mind, such as how Lester Hands and a WHOLE BUNCH OF OTHERS had plenty of time, as Mike has, to do "something" -- *SOMETHING*. Lester gave up and went on to porting Lyra to the IBM-PC money-making market. I've asked plenty of people, "Dr.T" for one (very popular on the Atari MIDI market), to whom I can directly ask questions on GEnie, if they'd let some of us OS9ers strike a contract with them to port their products to OS9 esp. on the CoCo. All I got was deaf ears. You see, no one knows what OS9 is, what it's about, who & what runs it. Good grief, I had the GEnie MIDI Forum Sysop ask me if "it was public domain" for crying out loud! (I *still* have that dialog captured and saved it for future reference under "Signs of Ignorance"!) They quickly got the usual run-thru, stuff like it looks & feels just like Unix, etc., etc., but it's a lot nicer with the "true real multitasking windows developed by Tandy and Microware". And *that* concept was ANOTHER bottleneck! I'm not saying PC programmers are stupid -- Ignorant:yes, due to their unenlightedness (e.g. not their fault) -- Dumb:no. Most of 'em, even IBM's, are kinda sloppy sometimes. They have no idea how to program efficiently, since now they can hog all the 2-meg and 4-meg cards you put into a PC. They have no concept of multitasking, of how to write SHAREable code (re-entrant and relocatable at *any* time), until/unless they move on to OS/2[tm-IBM] or some kind of mainframe. For the most part is what I'm saying. I could go on!, but I won't. But with everyone involved with PCs pouring in their efforts, just look at how good MIDI is implemented on PCs. Now look at how MIDI stands on the CoCo. Shameful. MIDI isn't the only standard I'm talking about, but it clearly opened my eyes as to where we CoConuts and OS9ers stood in relation to "everyone else". -> I think that about two years back a *LOT* of unrelated and separate -> projects startup up (Fido, UUCP, KBCom, OS-9 LII upgrade (?), all the -> unZip & deArc programs, ...). It takes TIME to port things over, and -> it takes time to write stuff from scratch. Esp since most (?) people -> who are working on projects like this aren't payed to do it, and thus -> must work in their spare time. When I first approached some CIS OS9 gurus about porting SEA Arc 5.12 over to OS9, they all said it'd be more-or-less impossible. It didn't take much time to decide the fate of having Arc compatibility for OS9. I didn't want them to do it, just to help me get started. That was in 1988. And it came from the smartest dudes I still respect. The problem isn't "Time" -- the problem is "Motiviation". You motivate people to develop products with $money$ and the out-right NEED for that product. The NEED could not be any greater when it is realized that the market forces us to go with their own standards. Fido, for example, will not let us use AR or PAK or anything else (TC3?!) to compress Mail Packets: it "requires" SEA Arc 5.12 as a bare minimum. There couldn't be a NEED any greater than when the standards dictate what we must use. Yet in 1988 no one wanted to help us make SEA Arc available for OS9. And I uploaded to CIS the huge source code with SEA's permission to get the ball rolling! We had the sources, yet no one wanted to scoot closer and help. They all backed away. Yes I'm one of those "unpayed" people -- OS9 is just a hobby with me, remember, but I'm one of those who are determined to see that OS9 can do things just as good as the big blue machines do them (oh maybe not as fast, but JUST AS GOOD). I'm also a system programmer who sees where things are going as a total picture, and read those trade magazines. I'm saying lots of "us" volunteers are just spinning our wheels if we don't get something "real" going -- things that are "really" needed in other words. We DO NOT NEED another GIF viewer, unless it's for the KLE and FHL graphics systems ... I see the STRONG need for lots of people to get cracking on the tape cartridge backup system. Right now if not two years AGO (which would have made it ready for use in B&B's CoCo-XT interfaces!). I've named several other needs and requirements in previous messages, one special-interest need in particular would be for music lovers: the Standard MIDIFile (SMF) support. I've been belly-acking to Mike Knudsen about this ever since the UME thing went commercial. If he didn't want to support SMFs soon, at least publish his file/record layouts so "we" can try writing a converter, just like Lester Hands published his Lyra formats. Yes I said I've personally asked Mike to provide us with that info more than a year ago. I see that he's posted those docs just about two months ago, almost to the day Delphi opened up my account! Coincidence?? I don't mean to pick on Mike -- I'm just saying how programmers go out and do their own thing without doing any market research (well not "much" anyway) when they start selling their product. When I do something, I grab everything I know and go out to research it. To learn about MIDI, for example, I *actually* JOINED the International MIDI Association and ORDERED their OFFICIAL DOCS. What does everyone else do? Did Mike join the IMA? Did Second City Software (Ed Hathaway) provide him with those same official docs in support of him developing UME for exclusive sales? I honestly do not know ... I'm just making a point here for everyone reading this. I'm not criticizing Mike and SCS at all ... but if the answer is "No" to that question, well it's something to start thinking about, especially if they intend on supporting SMFs, as the official docs *have* changed (a few points quite drastically) since the version 0.06 docs were shared amongst the networks. Any official MIDI docs are *now* copyrighted and *must* be ordered from the IMA at extremely cheap rates. Remember, I only bring up UME, MIDI, IMA, etc., only as one example of how things need to be approached when commercializing your programs. The research must be done and then the protocols etc. must be properly supported, or your product will wither and die because, quite simply, it's not usable with the way the market *is* set up. The MIDI market, to continue this example, follows strict guidelines in most respects of its protocols and implementations. Quite a lot of the manufacturers of keyboards add on to those specifications, but none of them "change" those BASIC specs that MUST be compatible with other machines. In fact, MIDI is such a wonderfully-agreed-upon standard, EXACTLY how the ANSI stuff is agreed upon btw, that it's pure magic almost to see all the music makers working with all that equipment -- I mean the hookups etc. WORKS, as in hit that button and it DOES something that it is EXPECTED to do! -> As *I* see it, the people in the OS-9 community are bending over -> BACKWARDS to give away their hard-earned secrets and to give newcomers -> all the help and support they need to get off to a running start. That IS fantastic. I'm not addressing that issue at all, not even a teeny bit. The issue is how OS9/OSK is going to support the machines that are out there to be bought and used. The issue continues by expanding into what some of these developers are doing, what they are planning to do, and how they are going to do it. I'm talking about COMMERCIAL products, not "shareware" or "freeware" ( although these people need to heed my warnings, too). MIDI and ANSI are two standards (of MANY) out there to be supported as if it is hardware to be hooked up to your computer. The drivers etc. must be "that" compatible. And this is only two of the many items awaiting to be used by OS9 users in the right way -- e.g. supported by the o.s. ITSELF (speaking of ANSI), not by each application's own code & logic *if* the programmer decided to include it on his own whims. And then there are REAL hardware items out there to be used: QIC tape drives, CD-I and CD-ROM, even some 9-track half-inch reel-to-reel tape drives! A whole gamut of disk drives up to 600-meg in the space of a 3.5-inch drive!! Did you know a company is coming out with a 20-meg FLOPPY the PRECISE SIZE OF A 3.5-inch FLOPPY???? This drive *will* be able to switch down to 5-meg and 1.44-meg and 720-k compatibility formats. It sounds like it'd be one of those "Smart" drives that uses the QIC Common Command Set (yet another official document I have). OS9 gurus hear this clear: smart drives are coming and some of them are already here. You cannot use SCF methods to talk to these drives. I have some of the QIC docs, remember; I have read them and I am warning the OS9 market that they'll be the next big break in storage technology. I'll bet, based on past history, that OS9 market/companies won't do much to help us utilize these smart drives. I would love to use a 20-meg 3.5-inch floppy, but will *some* company provide the interfaces and OS9/OSK drivers? And I'm not even going to start talking about EGA, VGA, Super-VGA, etc. That stuff is out there ready to be used under OSK. Why can't we use those cards "now" and port "RAVE" to use that hardware? Why hasn't anyone even thought of this as a cost-reducing effort, in lieu of developing a graphics system on the KLE & FHL based on CD-I chips, for example? These IBM-PC video boards come with their own memory that does not eat into the 68000's space (or 6809/GIME, whatever). Well, no one asked me ... it's too late now, apparently. I'll keep reading everyone's replies ... let's keep the dialogs (and controversy) going! Surely some power players in the OS9 arena will get our hints and decide to start supporting and implementing these ideas. -- Thx, Paul Seniura. -*- 30291 22-JUN 01:35 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30275) From: TIMKOONCE To: PAULSENIURA Paul, The only diff between SBF and SCF is that SBF gives the driver a block at a time to write, rather than a character at a time. The driver is still responsible for ALL of the hardware-dependent stuff you mentioned. Using SBF will not alleviate any of this. You're confusing SCF (the file manager) with ACIAPAK (the UART driver). SCF is used to talk to _any_ device that uses "streams" of bytes for I/O, including printers, serial ports, the screen, keyboard, etc. SBF just takes that stream and breaks it into blocks to give to the driver. To do the same under SCF, the driver would just have to buffer a block before sending it. - Tim Koonce -*- 30294 22-JUN 01:53 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30280) From: TIMKOONCE To: PAULSENIURA Well, Paul, it is interesting to see that people put so much faith in standards. A now-famous quote in some circles: "The wonderful thing about standards is that there are so many to choose from" While I don't claim to be an expert on the standards you mentioned, I do know a fair bit about ANSI, and can tell you that IBM PC ANSI.SYS is quite distinct from X3.64. To quote from X3.64, page 13: "The implementation of all of the controls described in this standard .. is not a constraint..." In plain English, this means that if you implement some fraction of X3.64, and then add some more stuff not defined in there, you're still X3.64-compliant. If you compare the extensions added by IBM ANSI.SYS, and VT100 for instance, you'll find some pretty serious differences. Also, I'm amused by your claim that IBM did good by including ANSI.SYS, especially since I've never heard of a commercial PC program that uses it. I had not heard of the "standard graphics extensions" for X3.64. Care to elaborate on where these came from? Or where more information can be found. - Tim Koonce -*- 30300 22-JUN 22:26 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30291) From: RAGTIMER To: TIMKOONCE So would SBF be any faster or more efficient? Like when doing X/YMODEM transfers? Can you "flush" SBF if the current block isn't full? Yeah I know SBF is for tape drives, but then constructive abuse of modules is what Coco OS9 is all about, grin. -*- 30302 22-JUN 22:33 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30294) From: RAGTIMER To: TIMKOONCE Well, I used to run a psych test scoring program that my wife's company had bought, and it required ANSI.SYS or else a messy screen. Not a program most users would ever run across, tho. "Standards? I believe in standards. I thinks every company oughta have two or three of'em!" Hey, I remember when RS232 was considered a standard... -*- 30353 24-JUN 15:55 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30280) From: OS9UGPRES To: PAULSENIURA Paul - Have enjoyed your messages. Some sidenotes on windowing: The InVision (now called RAVE) port to the ST wasn't done because no one has paid for it. Actually, it _was_ ordered at one time, then cancelled at the last second. I know, because I was originally contracted to do it. Anyone could order the portpak and do it themselves, tho. Again, a matter of money and desire. BTW, RAVE doesn't have a window manager yet, so it's basically just a very good drawing platform for control computers right now. However, there _are_ other windowing systems for OS9/68K. The MGR windowing system from Bellcore Labs is one. GWindows from Gespac is another. Both are available on the ST. The MGR port is PD, I think. GWindows is around $100 without any programming libraries at all... those are another $200 or so. They haven't decided yet. Both look pretty good, I hear; tho not exactly speed demons. Both are in C, around 120K long. My windows, which are in asm, will also be ported to the ST and Amiga, which should give us a broad base of users/programmers. BTW, X should be out this fall from Microware, so the rumors go. No idea on its price. - kev -*- 30387 26-JUN 00:09 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30353) From: RAGTIMER To: OS9UGPRES Any ideas on its (X Wndows) size or speed, he he? THe word is that X is pretty big and not too fast. I just got a book on it and they say "use a platform with all the raw power you can get." But anyway, an Official X for OSK will enhance its value in the market, certainly to the '020 crowd. We know YOUR windows will be lean and mean! --mike k -*- 30403 26-JUN 20:57 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30387) From: ZACKSESSIONS To: RAGTIMER At my day job I use a DEC VAXstation 3100. It is running DECwindows, DEC's implementation of X-Windows under VMS. The 3100 runs at around 3 MIPS (thats MIPS, not MHz!) and has 8 mb memory. Some people may consider some of the window functions slow, but it is fine with me! After using OS9 L2 for almost 2 years, I was REAL happy to get a (read ANY) window system on my desk! Zack -*- 30419 27-JUN 21:24 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30403) From: RAGTIMER To: ZACKSESSIONS OK. I use a Sun 3/60 running Snview 4.0, with 12 MB. It's jnjot nearly as snappy as the older Suns running 3.0, but a guy down the hall who is experimenting with X Windows on the Sun (sorta like MSDOS on the Amiga) says X is much faster than Sunview. Of course Sunview requires hundreds of K, and since it runs over UN*X, the first 2 MB don't count! -*- End of Thread. -*- 30276 21-JUN 01:23 Graphics & Music RE: Weather Radar (Re: Msg 29972) From: PAULSENIURA To: ZACKSESSIONS -> First of all, the VEF pic file you include is not exactly in "true" VEF -> format. The first two bytes of a VEF pic file from a Type 8 window -> whould be $0000, not $0008. Someone on CIS documented the VEF stuff, and that field should be the "Screen Type" code (STY) as described on page 3-13 of the Windows section of Tandy's OS9 L2 books. Mind you, I have not been on CIS for a very long time, so if someone will give me the official ratified agreed-upon 100% true blue VEF documentation, I'll change the program. :-) I don't want someone's interpretation of this standard, I need the official typed-up standard itself, please, so I can do it right despite what everyone thinks it should be. If there isn't such documentation available, I'll consider "VEF" a non-standard, and it's anyone's ball game as to what should be in those fields. (If that statement wasn't strong enough to make people provide official docs, I don't know what *will* make 'em do it!) -> And the file length should be 32018, not just 30738 bytes. Lessee according to my math: 320_dots_per_line * 192_lines / 2_dots_per_byte = 30720 Right? Now you need to add 16 bytes for the palette table, and then 2 more bytes for that STY field, so 30720+18 = 30738. Since no one officially supports 200 lines on a graphics screen, but rather only 192 lines are officially supported in any package I've ever gotten, and only 192 lines are visible (sans our GrfDrv patches I documented on GEnie last year), I do not see how you can come up with your numbers. :-) Make it a standard, then maybe we'll start implementing it! -> Now how 'bout us poor folk who lives elsewhere in the US of A? Color -> Weather Radar sites do cover most of the country y'know. Someone from -> each state gonna have to take it upon themself to spend the time -> creating a VEF map of their state? Well that's why I eluded to having to do things right. I want to ask the SAS Institute what I proposed in my documentation there (I shan't repeat all that goop here). We *can* get "official" state maps and "official" locations for the NWS radar locations, but just how we do that is up in the air right now. Certainly no one needs to "take it upon themself to spend the time creating a VEF map". The "official" maps have been created by SAS Inst. with computerized projected coordinates. We just need to do some asking, probably. We then must agree to some kind of location-dependent program parameters: scaling factors, location of the radar site on "that" state map, etc. Kinda like the 'env.file' that comes with MultiVue, maybe, I dunno. -> Now, as to getting the data to plot in the first place. When you -> mention, "I hope we can get a tie-in to the NWS for access to their -> current B-Scan weather files.", I assume you mean Delphi or GEnie? No, it'd have to be your local radar site! You would want completely current information, what is happening "right now", etc. CIS updates their maps about every 15 minutes. I'm wanting to tie into getting the Doppler info, too! Good grief, seeing those hooks, that signify a tornado coming, *WILL* save your life! ! I've been told NWS sites should have more info on what we need to know to ask etc. I've been told by this same person that PC BBSs have been doing this and providing this service for free, in that they'd dial up NWS and do automatic selections of their menus via the modem & a "smart" program "reading" the menus. That's how our AT&T 3B2 UNIX box at Okla.D.O.T. is doing it. (They have a leased phone line to the Will Rogers Airport, *not* NWS.) Again I'm told the NWS might/should have some local access computer lines available with real short time limits (how do TV stations without the expensive radar gear do it?) so people can access what they want to get & then log off. What they get are these B-Scan files or similar -- not "graphics". -> (btw, anyone besides me remember when all the Weather Channel did was -> scan a TV camera back and forth on a bunch of instruments!) Oh boy ... those farm towns that had "cable TV" had such weather channels! Here in Oklahoma it wasn't that many years ago (mid 1970's when I first started working for Okla.D.O.T.). Those old round meters! Well, now everyone's gone to the new Weather Channel with all that satellite data transmitted to their sites. Hmmm, that's an idea ... who's got a CoCo hooked up to their dish antenna so we can aim & pull down some GEOS pics directly??? The people who wrote WEFAX would quickly go out of style!! -- Thx, Paul Seniura. (p.s. let me know if you find out anything from your NWS site!) (p.p.s. I do have a newer version that has a "PPOINT" type subroutine of general interest to everyone who does graphics. PPOINT is, of course, the way RS-BASIC can inquire upon the color of a certain graphic pixel, which there is no counterpart in OS9 right now. This helps us keep "stronger" radar blips on the screen when the next radius is drawn. But it is getting rather slow, and the "arc" we draw with a straight line still isn't looking better. We even tried to "average" the "last" value of a pixel with the next radius' value for that same pixel (caused by rounding of the X,Y coordinates). Whatever we can do to make this newer version look better, that's what we'll upload & let y'all test ... "whenever" we get time, ya know ...) -*- 30296 22-JUN 01:58 Graphics & Music RE: Weather Radar (Re: Msg 30276) From: TIMKOONCE To: PAULSENIURA Paul, There are such things as "informal" standards, and perhaps you should go back and re-read those original docs of yours more carefully. If you would like to see some VEF docs that are as close to official as you'll ever get, look in the Graphics database here for a group that I uploaded. It's entitled something like "Picture Format Specs", and contains specs for a number of different CoCo picture formats compiled from a variety of sources. They are about as official as you can get in the CoCo world. If you'd like to submit them to ANSI, feel free! - Tim Koonce -*- 30297 22-JUN 18:25 Graphics & Music RE: Weather Radar (Re: Msg 30276) From: ZACKSESSIONS To: PAULSENIURA >Someone on CIS documented the VEF stuff, and that field should be the "Screen >Type" code (STY) as described on page 3-13 of the Windows section of Tandy's >OS9 L2 books. Mind you, I have not been on CIS for a very long time, so if >someone will give me the official ratified agreed-upon 100% true blue VEF >documentation, I'll change the program. :-) I don't want someone's >interpretation of this standard, I need the official typed-up standard >itself, please, so I can do it right despite what everyone thinks it >should be. Well docs have been provided, but who can say that they are "offical"? Tim Koonce uploaded a series of files in the Graphics&Music lib just a few weeks ago. Group Name is "GRAPHICS FORMATS". It agree with every program I have which performs VEFIO of some kind. This includes MAX9, VEFIO, ViewVEF, WLoad.B09, and View. I first figured it out be dEding picture files, reading Kevin Darling's source to WLoad.B09, and the source to VEFIO. They all agree that the second byte is a "code" which describes window type and resolution. Check vef.hlp in the aforementioned group. It also states that 200 lines are defined, even though many display programs ignore the first eight lines. MVCanvas will, however let you display and edit all 200 lines. (Not all at once, though!) >Lessee according to my math: > > 320_dots_per_line * 192_lines / 2_dots_per_byte = 30720 > >Right? Now you need to add 16 bytes for the palette table, and then 2 more >bytes for that STY field, so 30720+18 = 30738. > >Since no one officially supports 200 lines on a graphics screen, but >rather only 192 lines are officially supported in any package I've ever >gotten, and only 192 lines are visible (sans our GrfDrv patches I >documented on GEnie last year), I do not see how you can come up with >your numbers. :-) > >Make it a standard, then maybe we'll start implementing it! As I mentioned, MVCanvas DOES officially support 200 lines. And all viewer programs I previously mentioned are programmed to ignore the first eight lines, which means since the expect to read and ignore them, then in a way they ARE supported. Also, EVERY VEF format picture file (except your OK map!) are 32018 or 16018 bytes large. Download a few from the library here and do a dir e on them and see for yourself. Zack -*- End of Thread. -*- 30281 21-JUN 01:52 General Information our RiBBS test site From: PAULSENIURA To: ALL P.S. our official RiBBS test site BBS # is 405-670-6636, 3/12/24/9600 8n1, MNP5 /ARQ/HST with a real USRobotics Courier HST modem (not the newer 14.4k-bps ones) . I'm having trouble reaching Ron Bihler for latest fixes, still having a few troubles with Fido on different mail feeders on them other IBM-PC compatibles, but almost every module RiBBS comes with is loaded into RAM while we're using Disto's 1-meg upgrade too! It's quite fast, in other words! I'd estimate we have a menu system about 300k big, some of 'em very colorful ( experimenting and test-site, remember, not a real BBS yet, but y'all will have access to everything but the Fido options -- I promised the FidoNet local coordinators I'd not let users have access to buggy software until it's 100% working order). Even with such a big set of menus, since these things are copied to a RAM disk, the hot-key effect on menus is almost instantaneous. I.e. almost everything that RiBBS v2.0 comes with (that does not need changes to be saved) is in RAM in one form or another, and we didn't have to rewrite =any= of Ron's code to do it. Contrast this to products like UME that won't let you customize the use and size of RAM for various functions (not to mention staying away from system problems using Get/Put buffers -- RAMdisks are 100% trustworthy when the VDD.AR patch is installed!). Yep, RiBBS v2.0 *is* one of those products we've been badly needing -- Ron proves that CoCo/OS9 can do what the big blue machines have been doing: Fido! "ARF!!" And Ron needs to be congratulated and written up in the Rainbow for this effort. Yes this needs to be put into the "OS9 Spotlight" column. It would show why such "compliance" to the already-agreed-upon standards in various industries needs to be done. And "compliance" still needs to be done "correctly" for ANSI video, QIC tape drives (including "smart" SCSI drives), etc., on the commercial OS9 marketplace. (now if Ron would just clean up his code, pare-down the 16k "Connect" module to 8k etc.!, fix the remaining bugs, put in just a couple more features, he could sell it at a price level comparable to the commercial PC BBS packages go for! And I'd be willing to splurge that much. I'm *trying* to make a point: your products *will* make money if you design enough "guts" into them to make them worth that much money. And support your products, too.) -- Thx, Paul Seniura. -*- 30284 21-JUN 21:56 Programmers Den C.ASM problems.... From: DODGECOLT To: ALL Hi all, Well, I am having a small problem here with c.asm and one of the library function files for my CGFX lib. Basically, c.asm isn't reading the whole assembly code file and is missing some constant strings. This leads to the inevidible message from the linker that it can't find the reference to the string. Funny thing is, when I check out a listing of the code it is producing, it appears that the first pass figures the offset out OK, but the it seems to stop before it actually gets to the symbol in question. Anyone have any clues? -Mike (BTW, I have tried both optimized and not) -*- 30289 22-JUN 00:22 Programmers Den RE: C.ASM problems.... (Re: Msg 30284) From: DODGECOLT To: ALL An update- it appears that the problem was caused by a bug in the compiler- the string I was writing contained several chars that were > $7f (bit 7 set) In any case, the compiler threw those chars into an 'fcc', which c.asm doesn't like. So much for THAT problem... -Mike -*- 30298 22-JUN 22:19 Programmers Den RE: C.ASM problems.... (Re: Msg 30289) From: RAGTIMER To: DODGECOLT They must have put that bug in to keep us from hard-coding ESCape sequences. And if you believe THAT...grin. Did you see the c.prep bug we talked about here a couple months back? If you say #define toolong "abcdefgh" printf(toolong); you only get the first 7 (or was it 8?) characters -- the macro preprocessor can't take any more. Then someone (Dale P?) added that if you stick a blank space or something like that in there, it will work OK for any reasonable length. Hope Microware is braced for a flood of bug reports once the MM/1 comes out. Unlike those old commercila programmers, we coconuts really "exercise" the compiler. Grin, maybe. --mike k -*- 30303 22-JUN 22:39 Programmers Den RE: C.ASM problems.... (Re: Msg 30298) From: DODGECOLT To: RAGTIMER Didn't know about bug! Yea, I'm sure we will have those MW programmers running around once the new machines come out! -Mike -*- End of Thread. -*- 30286 21-JUN 23:47 General Information RE: Serial Mouse (Re: Msg 30197) From: OS9UGVP To: BRIANWHITE Brian, Yes, this is Bruce Isted here... I suppose I should sign with my full name. Oh well. I know why the mouse occasionally seems to screw up and then recover, and I will fix it now that I have the OK I needed before I would use the fix. Look for it fairly soon, but no promises that it'll be real soon. Lets see, I put all that work into the ballistic mouse speed up stuff, and now you want them taken out - actually thats a No problem... when i upload the new serial mouse file I'll include patch offsets & whatnot to let you turn the ballistic stuff off. As it is right now I'm not sure whether it can be easily done. Bug me again if I don't say anything about it in the next few days. Bruce -*- 30343 24-JUN 02:52 General Information RE: Serial Mouse (Re: Msg 30286) From: BRIANWHITE To: OS9UGVP Bruce, One more thing I discovered about the serial mouse. You may have already found it, but I thought I'd mention it anyways. It seems that whenever you click on the MV menu-bar twice in a row (within any amount of time), the computer hangs. This happened the first time I did it. The second time it hung for a second and then recovered. The mouse was then fine until I rebooted and then it hung consistantly every time I clicked twice in a row on the menu bar. The only program I tried this with was Bells & Whistles. Brian -*- 30439 29-JUN 23:42 General Information RE: Serial Mouse (Re: Msg 30343) From: OS9UGVP To: BRIANWHITE Brian, I haven't run into that problem (mouse hangups on double click) except with programs that don't have a tight enough mouse-signal routine in them. II've got much improved mouse drivers almost ready for uploading... all I need is some time to do the doc changes (not much, I think) and stuff. Bruce -*- 30576 8-JUL 03:18 General Information RE: Serial Mouse (Re: Msg 30439) From: BRIANWHITE To: OS9UGVP (NR) Bruce, This hangup had nothing to do with mouse click code. I could click, move the pointer around the screen for 10 seconds, and if the very next click was again on the menu bar, the system would hang. Sorry I can't milk my system for more information, but I took the mouse back to work. Brian -*- End of Thread. -*- 30288 22-JUN 00:22 Patches OS9 LII and GFX2 From: GLENNTHIG To: DALEP Dale, I just received my July issue of the Rainbow. Glad to see you're back andthe roilian life. I have a couple of questions, as might a lot of other people about the Ipatch file for the GFX2 module. I have not been able to find it. (Maybe I should ask Kevin about that though.) Also since Tandy is dropping The Coco, will there BE a new version of OS9 Level II? Maybe these questions have allready been answered many times, I just have not seen them. Any light you can shed on the situation will be appreciated. Thanks. GThigpen (GLENNTHIG) -*- 30314 23-JUN 04:59 Patches RE: OS9 LII and GFX2 (Re: Msg 30288) From: OS9UGPRES To: GLENNTHIG Glenn - I finally found time (lately it seems like I've run out of process numbers ;-), and created/posted a new gfx2 module to go along with Dale's column. The interesting thing is, I'm surprised someone didn't just write one in Basic09! From Dale's description it would've been pretty easy to do, methinks? There are a coupla volunteers taking over the upgrade documentation holdup... so keep crossing them fingers. The 68K machines are the topmost priority right now, tho. best - kev -*- 30358 24-JUN 20:39 Patches RE: OS9 LII and GFX2 (Re: Msg 30314) From: GLENNTHIG To: OS9UGPRES kEV, I appreciate the time you and others take to write programs/procedures and the like for us non-progfgrammers(gripers). I am really looking forward to seeing those new 68000 machines in action. I write a little in Basic09, but right now just working and single-parenting swwm to keep me occupied. Thanks. Glw -*- 30364 25-JUN 01:19 Patches RE: OS9 LII and GFX2 (Re: Msg 30288) From: DALEP To: GLENNTHIG (NR) Glenn First, I noticed just this even that Kevin has uploaded the new GFX2 module to compuserve. That means he most likely has posted it here also. But I just checked in and went directly to the Forum. I have not looked in the Data Libraries yet. I'll look soonest. My bet on the upgrade ... is that there will be one. My second bet on the subject is that it will most likely be from a third party. We'll all have to stay tuned together. Best Regards, Dale -*- 30393 26-JUN 00:40 Patches RE: OS9 LII and GFX2 (Re: Msg 30364) From: GREGL To: DALEP Dale, The new GFX2 module is safely tucked away in "New Uploads" in the databases awaiting all those hungry downloaders. From the looks of it, I think it was definitely worth the wait. Now on to OS-9 version 3. -- Greg -*- 30435 29-JUN 02:29 Patches RE: OS9 LII and GFX2 (Re: Msg 30393) From: DALEP To: GREGL Greg, Yep, I think the people on the Forum are going to love GFX2. You might put a bulletin on when they sign on to encourage them to download it. Definitely worth the trouble. They'll love "version 3" too! If, it ever sees the light of day. Best Regards, Dale -*- 30441 30-JUN 00:04 Patches RE: OS9 LII and GFX2 (Re: Msg 30435) From: DWHILL To: DALEP "If, it ever sees the light of day." Eep. You mean the upgraded Level II might stay in limbo? More and more it looks like I'll be forced to a MM1 or a TC9--which I can't afford. I'm still trying get my money's worth out of my CoCo 3 (I bought a 2400 baud modem today). Very glad to see you back in Rainbow, it's looking awfully thin these days. --Damon -*- 30620 9-JUL 01:45 Patches RE: OS9 LII and GFX2 (Re: Msg 30441) From: DALEP To: DWHILL Damon, I certainly hope it sees the light of day ... I'm just impatient. There's a lot of life left in these CoCo III's. And this new software will certainly make a lot of people sit up and take notice! Because ... it will be a lot easier to write nifty looking software in Basic09. And it will all look better and run much faster. CUL. Dale -*- 30672 12-JUL 20:43 Patches RE: OS9 LII and GFX2 (Re: Msg 30620) From: DWHILL To: DALEP (NR) I'm hoping there's a lot of life left in MY coco, too. I'm trying to sell my messydos machine for whatever I can get for it (Leading Edge Model M, an XT clone) and just bought a 2400 baud external modem for the Coco. I just did the IRQ diode hack and am now running Xcom9, which is notorious ojn my system for locking up. For some reason, Osterm almost never does. At any rate, I'm hoping it'll help prevent dropped characters as well, though I think that really needs the ACIA hack. Very curious about the new Coco4-type machines, you betcha I'll be at the Cocofest here in the fall to look at 'em. Hope to see you here also. The weather here in Atlanta in the fall is most pleasant. (That's a plug, ya'll.) --Damon -*- End of Thread. -*- 30304 22-JUN 22:42 General Information Coco Clipboard From: RADICAL To: ALL Anyone any idea as to the status of the Coco ClipBoard? TP1, can't be reached in these waters. Does anyone have his GENIE address? I know he promised better service, but I haven't seen a ClipBoard in quite a while. Len -*- 30305 22-JUN 23:52 Programmers Den RE: C question (Re: Msg 30101) From: CHYDE To: ZACKSESSIONS I am using it in several programs of my own. One of them is similar to the UNIX cal utility. The garbage on the screen and stuff doesn't happen all the time the program is called just once in a while. function. It's with this one that the problem seems to be most common. I've gotten around the problem by using the time() and localtime() functions from Carl Keirder's C library. This uses more space but it seems to solve the problem. I have some other people using the programs and am waiting for their comments. I can send you some the source in E-Mail if you want. Personally I think it's just me. My wife put a curse on my computer since I've been spending so much time with it lately :-). Chris -*- 30309 23-JUN 01:31 Programmers Den RE: C question (Re: Msg 30099) From: TIMKOONCE To: CHYDE Actually, that sounds like a stray pointer problem. Be double sure you're passing it the right pointer. How are you declaring/allocating the buffer for getime(), and how exactly are you calling it? Since the "trash" block that OS9 uses to fill up a memory map is also incidentally the first block allocated to video memory, stray pointers will often write garbage to the first text screens allocated. Whenever you see garbage like that, there's a good chance there's a stray pointer somewhere! - Tim -*- 30315 23-JUN 05:21 Programmers Den RE: C question (Re: Msg 30309) From: CHYDE To: TIMKOONCE I'm declaring the buffer as described in the manual: struct sgtbuf *buffer; I call it with: getime(buffer); I think that's right, but I'm still learing C so anything is posible. The book I have on C doesn't say much about making System calls (It's geared mainly for PC's anyway) and there isn't anything in the manual so it seems reasonable. Chris -*- 30325 23-JUN 15:42 Programmers Den RE: C question (Re: Msg 30315) From: ZACKSESSIONS To: CHYDE Tim hit your problem right on the nose, a stray pointer problem, and don't feel bad it is a common error of beginning/intermediate C programming. You need to understand that the manual describes the function as #include setime(buffer) getime(buffer) struct sgtbuf *buffer /* defined in time.h */ This means that the function getime() requires a single parameter, namely a pointer to a struct of type sgtbuf. Now when you declare just a pointer to struct, you don't actually allocate any space to hold the data defined by the struct. All you declared is a pointer variable which can point to a struct of type sgtbuf. Try it this way: #include #include main() { struct sgtbuf tim; getime(&tim); printf("Current time is %02d:%02d\n",tim.t_hour,tim.t_minute); } Another way to do it is to do it this way: #include #include struct sgtbuf *tptr; main() { struct sgtbuf tim; tptr = &tim; getime(tptr); printf("Current time is %02d:%02d\n",tptr->t_hour,tptr->y_minute); } Does this make any sense? Zack -*- 30327 23-JUN 17:42 Programmers Den RE: C question (Re: Msg 30325) From: DODGECOLT To: CHYDE Another thing to remember is that the Microware C compiler usually 'forgets' to pass the pointer to a structure. What I mean is that you have to tell it to send a pointer (with the & operator.) Otherwise it will send the whole structure, which will surely cause you problems! -Mike -*- 30329 23-JUN 18:59 Programmers Den RE: C question (Re: Msg 30315) From: GREGL To: CHYDE Chris, You declared the pointer to the structure (struct sgtbuf *buffer) but not the storage area for the buffer itself. Look at it this way: Declaring a pointer sets up a 2 byte storage area in memory that contains the address of the object. When the pointer is declared, the address stored there is undefined - garbage. Therefore, when you call getime(buffer); you are passing a garbage address and the getime() function is storing the date and time at whatever address that happens to be. To use the same declarations you need to allocate a section of memory for the structure, which would cause your code to rewritten as: struct sgtbuf *buffer; buffer = malloc(sizeof(struct sgtbuf)); getime(buffer); Here we tell malloc() that we want to allocate a section of memory with the same size as the sgtbuf structure (6 bytes I believe) and to assign the address to buffer. You can also write the code as follows: struct sgtbuf buffer; getime(&buffer); This declares buffer as an sgtbuf structure. Note that this allocates enough memory to store the entire structure instead of a pointer. Next we use the "address of" (&) function to pass the address of the structure to the getime() function. Both of these have the same results. The difference is the method you use to access the variables. In the first method using pointers you would use: year = buffer->t_year; month = buffer->t_month; day = buffer->t_day; In the latter method without using pointers you would use: year = buffer.t_year; month = buffer.t_month; day = buffer.t_day; If you have any more questions, feel free to ask. -- Greg -*- 30456 1-JUL 00:58 Programmers Den RE: C question (Re: Msg 30327) From: CHYDE To: DODGECOLT Thanks, I was begining to wonder. It seems other programs of mine have the same problem. Well back to the drawing board. And just when my wife thought I was going to spend some time with her. Chris -*- 30457 1-JUL 01:03 Programmers Den RE: C question (Re: Msg 30329) From: CHYDE To: GREGL After Zack mentioned the dangling pointer and alocation I thought it might be that or something else equally sneaky :-). Anyway thanks. And the professors in the C.S. department don't think it's ness sasary to have a class in C. Chris -*- 30458 1-JUL 01:09 Programmers Den RE: C question (Re: Msg 30325) From: CHYDE To: ZACKSESSIONS I will endevor to try what you suggested when I get a chance. I had thought about that being a problem, but at first the programs worked fine (good luck, I guess). I guess it's back to the old editor and compiler to rewrite some code. And just when my list of projects was getting down to managable size. Thanks for your help, Chris -*- 30549 7-JUL 18:43 Programmers Den RE: C question (Re: Msg 30457) From: TOMBRETON To: CHYDE Well, C++ people think it's neccessary to have a class in C.... Tom -*- 30551 7-JUL 20:56 Programmers Den RE: C question (Re: Msg 30549) From: TOMBRETON To: ALL But more seriously, I'm trying to learn C++. Does anyone know good 'n cheap compilers, books, and references? I've got them all for C. How much more do I need to program C++ decently? Tom -*- 30558 7-JUL 23:21 Programmers Den RE: C question (Re: Msg 30551) From: XLIONX To: TOMBRETON Howdy Tom, Hate to say this but, you have to almost start over. There are alot of good "crossover" books that will no doubt make a mess of your life (for awhile ];->). The second edition of "The C Language" by K&R includes an introduction to OOP (++) and books on the subject range from $19.95 to $80.00 (American). The best you can do is to write to the manufacturers " on their products as far as tutorials and online help goes. Zortech, Microsoft, Borland, Abraxas and the list goes on. I don't know what kind of machine you are going to use, so I can only guess IBM (clone). If you want to go C++...DON'T SETTLE for a compiler that claims "with C++ extensions" unless it covers ALL C++ functions. You can write code in any C compiler that could be considered OOP in design, and the concept behind OOP (C++) is not too hard to deal with. Good luck, and let me know what you decide to do (Professional Curiosity). -Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS v2.0) -XLIONX (DELPHI) -mwf@SANDV -*- 30591 8-JUL 14:30 Programmers Den RE: C question (Re: Msg 30558) From: TOMBRETON To: XLIONX Thanks for the help, Mark. I'll let you know how it goes. Tom -*- 30691 13-JUL 21:02 Programmers Den RE: C question (Re: Msg 30549) From: CHYDE To: TOMBRETON (NR) Yeah so do most of the C.S. students at the Univeristy of Idaho. We're working on it. Maybe for the spring '91 semester. -*- End of Thread. -*- 30307 23-JUN 00:37 Patches hires From: BANCROFT To: ALL I do not yet have cocomax 3, but plan to get it in the future. I am building a switch to switch hires on/off. I also want to put in the modified switch. The problem is, all dos on the switch, are schematics in cocomax 3 double height format. the best I can do, is convert them to vef, and view the top half only, but this does me no good. Is there any way I can get these schematics? -*- 30310 23-JUN 01:32 Graphics & Music RE: hires (Re: Msg 30307) From: TIMKOONCE To: BANCROFT My VIEW program will display both halves of a CoCoMax 3 picture. Try it, you might like it. - Tim Koonce -*- End of Thread. -*- 30316 23-JUN 06:02 Programmers Den RE: Multi-Vue programming (Re: Msg 30102) From: OS9UGPRES To: ALPHASOFT Keith - I've been off for quite a while... didja figure something out? About the only way I can figure for two programs to use the same menu bar is to share a data module with the menu info changed inside. Actually, that won't work either. Hmmm. Windint is a smart cookie and checks process id's and something else (I forget what) to make sure this isn't just old menu info hanging around. Perhaps if the child process signaled the parent to do a SS.UMBar, again using the data module?? Kev -*- 30404 26-JUN 21:05 Programmers Den RE: Multi-Vue programming (Re: Msg 30316) From: ALPHASOFT To: OS9UGPRES I don't know if that would work either, cause the new process still couldn't pull up the menu. I can share the menu data, but I need a way to tell OS9 that the menu belongs to me (and has X data). I can do an _ss_wset, but it clears the screen. If I could somehow accomplish an _ss_wset without clearing the screen??? Let me know. -*- End of Thread. -*- 30317 23-JUN 06:02 68K-OS9 RE: OSK Mem Management, Raleigh Club. (Re: Msg 30117) From: OS9UGPRES To: THEREB Matt- You would think that fragmentation would be a bother under OS9/68K, but I've not seen it yet on my ST or MM/1. It's a little different from coco L-I, because programs can have up to 31 (?) sections of memory allocated. Let me see. Like right now I have 1852K free, with the largest section being 1843K long. I'm not worried about frag yet . On the other machine, I have 935K free, with 934K being the largest section. So it's not a bother. Right, second and fourth Wednesdays of every month at 7:30pm. Go up 401 to the Raleigh Beltline and head for US 1 North (northeast). Get off on the US 1 (Henderson) exit, and travel north on 1 for about say, 4-5 miles. Just after 1/401 split again, you'll go past a large shopping center (Mini City) on the right. Look for the main stoplight intersection of Millbrook Road. Continue north to the next light, which is Spring Forest Road. Take a left. Go about 2 miles until you come to Millbrook Senior High School on your right. The _last_ parking lot (black asphalt/trailers/gravel) at the far end of the school is the spot. Go into the end of the school, and stick your head into various rooms until you spot a small group of insane looking people. That's us . Call me at 919-872-7986 that afternoon if you're coming up. PS: we read many forums and nets... but are usually too swamped to answer much ;-). -*- 30333 24-JUN 00:12 General Information User Group Meetings (Re: Msg 30317) From: THEREB To: OS9UGPRES Thanks a lot. I'll TRY to make it to one of your meetings - I may not be able to anytime soon, I'll be in Minnesota for three weeks starting July 19th - but MAYBE I'll be able to make one before then. Have you been bringing the MM/1 to the meetings? =) And thanks for the directions, too; I'm not REALLY familiar with the Raleigh area, and they'll help if I am able to make it. Matt. -*- 30335 24-JUN 01:26 General Information Raleigh Club (Re: Msg 30333) From: OS9UGPRES To: THEf I have something new worth showing off . -*- 30377 25-JUN 20:58 General Information RE: OSK Mem Management, Raleigh Club.eM 3) r:TEB oO9PE s isIuttet ahe toci wie rgamio Ii oilyucl n nt? )Iwl O oe h tn! a'OEom aoso nigoce for. Actually, I'll bring an 8cm515 if you need me to. I don't know if I'll make it this week or not, but if I can't, I'll try to make it to the first meeting in July. Again, thanks for the directions & help. Matt. THEREB (919) 484-1230 voice or call the Norca BBSs! (919) 868-8431 867-7152 424-2895 497-8806 -*- 30384 25-JUN 23:35 General Information RE: OSK Mem Management, Raleigh Club. (Re: Msg 30377) From: NES To: THEREB Matt, You can send the disk in os9 or rsdos or MSdos format, I run the BBS under os9 but have the CC3disk patch so I can read rsdos disk and MSdos disk. hope you got all the info you needed in my letter. I just order MV canvase will let you know how it looks also the program called Planet Engine by Gravity Studio is a must for those who love to look at theh stars, it cost only $24 dollars but beats out programs that I have payed twice that, I comes with a sharp looking Manual and run's under(or without) MV, but I think the MV version looks the best. I was impressed by the program when I ran it, and seen what the moon's phase was, and then that night I whent out and the program was correct in the moons phase and star positions,.... Well chat at you latter.. Eric -*- 30402 26-JUN 20:54 General Information RE: OSK Mem Management, Raleigh Club. (Re: Msg 30384) From: ZACKSESSIONS To: NES When you say that Planet Engine runs with or without MV, does that mean there are two binaries, one which works with GrfInt and one that works with WindInt? Zack -*- 30409 26-JUN 22:40 68K-OS9 RE: OSK Mem Management, Raleigh Club. (Re: Msg 30402) From: NES To: ZACKSESSIONS Zack, Yea, but only the MV version has pull down menu's and also has more options.... eric -*- 30466 1-JUL 22:34 General Information RE: OSK Mem Management, Raleigh Club. (Re: Msg 30384) From: THEREB To: NES Hmmm. . . I just got Multi-Vue myself, I'm starting to get the hang of it. . . but do you have any suggestions? Matt / TheReb -*- 30485 3-JUL 00:00 General Information RE: OSK Mem Management, Raleigh Club. (Re: Msg 30466) From: NES To: THEREB Matt, Help in what area of MV? If you get a program that you cant get to run, I my could help you, always check your ATTR of file all icon must have pe e pw pr r w set, also make shure things are in the right directorys. I have mine setup like this: dd/MV/CMDS dd/MV/CMDS/ICONS dd/APP (application directory with the AIF files) Let me know if you have anytrouble. Eric -*- 30517 5-JUL 21:34 General Information RE: OSK Mem Management, Raleigh Club. (Re: Msg 30485) From: THEREB To: NES Well, I'm beginning to get the hang up Multi-Vue. BEGINNING to. I have virtually NO MV applications (two icon editors and the included graphics demos - that's all), but I like finally having a WIMP interface available. Problem is, I'm now running out of RAM space on my 512k system =) ! Matt -*- 30520 5-JUL 23:54 General Information RE: OSK Mem Management, Raleigh Club. (Re: Msg 30517) From: NES To: THEREB (NR) Hay, You should download "MAX9" a nice graphics editor that will run under MV, Its on my board or you can get it here, BTW MVCanvas is a nice graphics editor pakage, a must for OS9 users who love drawing. also there's Zack's Banner maker progam, Solitare, Luner Lander, View looks good under MV, with view under MV all the graphics files have there name under there icons, ie GIF files will have the GIF icon. realy nice. That's all I have at the monment. yea, I run out of memory all the time with the board up and MV and all the other windows I have open. -*- End of Thread. -*- 30318 23-JUN 06:03 68K-OS9 RE: Unlink (Re: Msg 30123) From: OS9UGPRES To: EDDIEKUNS Eddie - yah, just unlink one more time (past 0) and a sticky module goes away. -*- 30319 23-JUN 06:03 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 30134) From: OS9UGPRES To: KNOT1 Jamie - nice testing! That takes us a lot closer to figuring out the reasons for the strange ability to unlock what shouldn't be unlockable (altho I'm usually glad it is! ;-). thx! - kev -*- 30320 23-JUN 06:03 Graphics & Music RE: MVCanvas 2.0 (Re: Msg 30142) From: OS9UGPRES To: RAGTIMER Mike - I bought extra ink paks way back when I first got the printer, so no problem there. It just turned out that dis-use causes some of the ink to dry up inside several of the tubes, and they clog up. I know it happens to others at times, and also knew that some people used some liquid to clean the tubes out.... I was hoping you knew what. thx! -*- 30362 24-JUN 23:46 Graphics & Music RE: MVCanvas 2.0 (Re: Msg 30320) From: RAGTIMER To: OS9UGPRES Sortry I don't. If you find out how people clean out their printer ink tubes, please post it up here, Kev. Thanks, mike k (PS: Mine are working fine at the moment). -*- End of Thread. -*- 30321 23-JUN 06:03 68K-OS9 RE: GEN (Re: Msg 30143) From: OS9UGPRES To: KTT (NR) Hi! Sorry I took so long to get back to answer you. Your best bet is to call Microware themselves for more OS-9000 info and pricing... 515-224-1929. Ask them for info on OS-9000, and also the OS-9 Catalog, which is filled with a terrific description of OS9. Yell if need more help. best - kev -*- 30326 23-JUN 17:34 Patches Disto RTC mods From: OS9UGVP To: ALL A while ago someone with a Disto RTC was having problems with the ACIAPAK driver from my "ELIMSW.AR" package. I received some mail from them, but I have misplaced the message and I can't recall who it was. I have some more information that might be helpful, if I can just figure out who I was talking to. So if you're out there, let me know who you are! Bruce -*- 30328 23-JUN 17:55 Patches RE: Disto RTC mods (Re: Msg 30326) From: DODGECOLT To: OS9UGVP Yea, I think that was me. I take it you have found something from the code I sent you? -Mike -*- 30438 29-JUN 23:38 Patches RE: Disto RTC mods (Re: Msg 30328) From: OS9UGVP To: DODGECOLT Mike, Now that I see your "handle" again, I'm sure it was you. I've got an ARchive with a slightly modified source file waiting for you... I'll EMAIL it right away. Let me know if it helps (or not!). Bruce PS: This is an ARchived file... I trust you're familiar with the "EXTRACT /NOHEADER" and then DL from your workspace thats required? -*- 30449 30-JUN 15:44 Patches RE: Disto RTC mods (Re: Msg 30438) From: DODGECOLT To: OS9UGVP Yep, got it. I'll check it out once I get it dloaded. Thanks! -Mike -*- End of Thread. -*- 30330 23-JUN 19:45 General Information Horn toots From: PAULIGHT To: ALL I'm very curious about what I can say on DELPHI in regard to commercial programs that I write and wish to promote... Is there any guidelines or restrictions to what (and how much) one can say. I would like to keep persons informed and announce program s without abusing or glutting the forum. Is there any good message I should read. Signed Paul H. Light (Mr. Good Citizen) -*- 30336 24-JUN 02:16 General Information RE: Horn toots (Re: Msg 30330) From: TIMKOONCE To: PAULIGHT Paul, Don't take this as "official", (hopefully Greg or Jim Reed will jump in and get this right), but I think that the general policy is that product announcements are gladly accepted in the database (upload it to the General Database, methinks), and that you're free to answer questions in forum, as long as you keep it tasteful. Basically, try to keep it non-obtrusive, and noone really seems to care. Thanks for asking! - Tim Koonce -*- 30355 24-JUN 18:56 General Information RE: Horn toots (Re: Msg 30330) From: GREGL To: PAULIGHT Paul, There are no hard and fast rules, per se. Feel free to post any product announcements in the databases. You are also absolutely free to answer any questions that are thrown your way in regards to your products. Basically all we ask is that you give only the facts, no hype please. You shouldn't have any problems following those "guidelines." If we think you've "overstepped your bounds" we'll explain why - but it's rare that anyone does. Of course the users have a "need to know" about any new and upcoming software so they can make purchasing decisions. Basically, product announcements and answering questions are perfectly acceptible, but no advertisements. If you have any specific questions, feel free to ask. -- Greg -*- End of Thread. -*- 30331 23-JUN 20:37 Utilities ARC From: SEBJMB To: ALL Hi, all. I'm confused. I have seen a couple of references in recent uploads to an archiveing method called "ARC" and the dearchive program called "DEARC". There has been at least one upload submitted in the "arc" format. However, I have been unable to find the DEARC program in any of the databases. Am I missing something? eff (Puzzled) -*- 30337 24-JUN 02:26 Utilities RE: ARC (Re: Msg 30331) From: TIMKOONCE To: SEBJMB You're quite right, DEARC is _not_ in the database here. It seems that there is some confusion over whether the person who uploaded it to us had permission from the author to upload it here. Without that permission, we can't accept such an upload. If someone can contact the author to get permission, that would obviously help a lot. - Tim Koonce -*- 30346 24-JUN 03:20 General Information RE: ARC (Re: Msg 30331) From: TIMKOONCE To: SEBJMB "ARC" is an archive method very popular in the IBM PC world. OS9ARC and DEARC are utilities to create and read that archive format. I've downloaded the one upload I've seen in ARC format and converted it into OS9-standard AR format. Thanks for bring that up! - Tim -*- 30351 24-JUN 10:54 General Information RE: ARC (Re: Msg 30337) From: ZACKSESSIONS To: TIMKOONCE Actually, Tim, dearc IS in the library! It is a member of the group "3D GRAPHICS PLOTTER" in the Programmer's Den. Only C source is there. I have successfully compiled it, and have been semi-successful in using it. Only problem was, I had to filter all extracted files replacing the 0x0A with 0x0D (archive came from a VAX.) Zack -*- 30382 25-JUN 23:19 General Information RE: ARC (Re: Msg 30351) From: NES To: ZACKSESSIONS Zack, If you get the 3D plotter working upload it here or to me, I havent got it to compile yet... Eric -*- 30401 26-JUN 20:51 General Information RE: ARC (Re: Msg 30382) From: ZACKSESSIONS To: NES Heh, heh, I didn't even LOOK at the 3D plotter, I just wanted the dearc program! Zack -*- 30408 26-JUN 22:39 General Information RE: ARC (Re: Msg 30401) From: NES To: ZACKSESSIONS Zack, oh well, I had know problems with the dearc program... eric -*- End of Thread. -*- 30338 24-JUN 02:50 Programmers Den Window Help From: BRIANWHITE To: OS9UGPRES More system problems... I have a program that has the option of using its own font, the default system font, or the StdFonts file. The program checks for an available font in that order and then loads the font to the system ($1B2B ...) if that is not where it was found. The p roblem is that when the window is opened after a font is loaded from a file, the menu bar contains only the close box. However, if run again and allowed to find the font in memory, everything works fine. I've tried closing the path I wrote the font loa d command out to, but that didn't help either. I've tried opening the window with the menu bar both before and after the font load command is issued. Nothing seems to make a difference. The symptoms are always the same. Any ideas about this? Also, after opening a window to "/w" if I send the codes: fcb 27,32,6,0,0,40,24,3,0,3 - Set window type fcb $1b,$25,0,1,40,23,12 - Clear screen fcb $1b,$3a,$c8,$01 - Select font fcb 5,32 - Turn off cursor fcb $1b,$35,0 - Scale switch off to that window, occasionally the system will return with error #189 (Illegal Coordinates). Running my program a second time again always works. As far as I can tell, the problem steps from doing the "set window type" and "CWArea/Clear screen" in the sa me I$Write to the new window. I've tried changing the order of the above (always keepin the set codes at the top, of course), but no change. I guess my next course of action is to try two different I$Write's. Anyway, this prob has me kinda stumped, to o. Any help would be greatly appreciated. Brian -*- 30354 24-JUN 16:13 General Information RE: Window Help (Re: Msg 30338) From: OS9UGPRES To: BRIANWHITE Brian, I may bumble this a little, but here's some info which might help: Each window has data stored about its size, colors, etc. One of the things which is stored away is the block number/offset of the font. NOT the group and buffer number. Thus if you remerge fonts using the same numbers, you can mess everyone up... since the true block/offset could change from under them. Think of this like a CHX/CHD, where os9 stores just the sector number, not the actual filename. Similar. So by refinding a font by group/number, the new block number and offset in memory is reset, and all is well. Note that the menubar always stores away the block/offset of the font being used at the moment of SS.WnSet (if I recall correctly). The error 189 thing is different. It most often comes from a window entry still having a leftover type number in it (they forgot to clear that when a window/overlay closes). For example, pulldown a menu and that window entry (the pulldown overlay) is set to a shadowed box type, with default CWArea inside. Later, a new window gets that entry, and a cwarea fails because of the leftover shadowed-type confusing poor Windint. Programs could always SS.WnSet to some type (00 is good) first to avoid this cwarea glitch. -*- 30574 8-JUL 03:17 General Information RE: Window Help (Re: Msg 30354) From: BRIANWHITE To: OS9UGPRES Kev, Okay, all that makes sense. I'll try doing a WnSet to zero and then a WnSet to whatever type I am using. Would that work, or would I need to close the window path, between the two "set" commands? As for the font error, I tried writing the GPLoad and Font select commands out to a path to "/w", closing the path, and then opening a new one to "/w" all before doing a WnSet to the new window and the font still isn't there. However, if I do run the pr ogram a second time (this time it detects that the needed font has been loaded and thus doesn't try to load it again), everything works just fine. Ideas? Brian -*- End of Thread. -*- 30339 24-JUN 02:51 Graphics & Music RE: Get/Put Buffers (Re: Msg 30200) From: BRIANWHITE To: TIMKOONCE Tim, Thanx for the info agout Get/Put. I was afraid it would be something like that. I hate the idea of having to unmap a buffer before I can map in the next (a real time waster), but you have to do what you have to do... Congrats on your upcoming wedding! Does this mean that you'll be slowing down on View and give people like me a chance to catch up? Actually, I conceed with that battle! Of course, there are still a few things I prefer in Show over View, but n ot very many. You did an excellent job on that project and I hope you write a similar one for OS-k! Brian -*- 30345 24-JUN 03:18 Graphics & Music RE: Get/Put Buffers (Re: Msg 30339) From: TIMKOONCE To: BRIANWHITE Actually, Brian, I'm eager to see what you finally managed to do with Show. Sounded like you had some interesting ideas, maybe I can steal some of them! - Tim -*- 30573 8-JUL 03:17 Graphics & Music RE: Get/Put Buffers (Re: Msg 30345) From: BRIANWHITE To: TIMKOONCE Tim, Ohhh... It's been a while since the editor has load the Show source. I don't remeber what I improved on it. I know I fixed a couple of bugs and added some more music formats, including screen flipping for IMG. Lets see... I added a variable sleep ti me, allowed options to be grouped instead of separating each with a "-". I was going to try and allow flipping during loading. I, of course, was cheating like a madman to get these things done. I did directCcce..: t+$.,.Y+R-QI AQzUQ=%9J*T2=I21%AA%99JiXM5Rtverdoing it. So... It's been put on the far back burner while the music editor gets going. I'm probably going to stop that pretty soon and start from scratch an MM/1 version. That's the big problem with assembly. Abso lutely no portability. Just as well, I've got new and better ideas, now! I think "Show" is stable if you want me to mail you it in it's current state. Let me know. If you like any of the ideas, you don't need to steal them, they're yours. I'd be a f ool to hinder any development of that program of yours. Of course, I am an engineer, and you are a mathie, so maybe I should anyways . Brian ;-) -*- End of Thread. -*- 30340 24-JUN 02:51 Programmers Den SCF Editing and History (Re: Msg 30201) From: BRIANWHITE To: EDDIEKUNS Eddie, Yea, you can do single char reads and make your own editor, but that shouldn't be necessary. Besides, it redu,X` the flexibility of OS-9. After all, that is what all those wonderful flags in the path descriptor are for. There must be an easier way. Brian -*- 30365 25-JUN 01:55 General Information RE: Alias (Re: Msg 30340) From: EDDIEKUNS To: BRIANWHITE I disagree. I don't mind SCF doing its own editing, but I think the shell's history should be completely separate from the history of SCF. For example, I run an editor. later I quit the editor and want to run the editor again with slightly different options and a different filename. When I press the up-arrow, I want to see the line I typed to enter the editor, not anything I typed during the editing session. NOW -- If SCF can be coerced by a flag or something to keep a separate history list for each path, THEN I'll admit that it's OK to keep the editing in SCF. Eddie -*- 30390 26-JUN 00:19 General Information RE: Alias (Re: Msg 30365) From: RAGTIMER To: EDDIEKUNS I agree with Eddie -- years of that phone-company OS, ya know. Tho I'd also like a reapet-line that would work on paths, or whatever. Right now, in OSTERM, I can't repeat a line by typing CTRL-A. Not clear why not -- maybe OSTERM uses an I$Read for every character? -*- 30575 8-JUL 03:18 General Information RE: Alias (Re: Msg 30365) From: BRIANWHITE To: EDDIEKUNS (NR) Eddie, Actually, what is needed here is a way to see what the next keypress in the buffer is without actually reading it. That way, the shell could wait for a keypress, and then check the key to see if it is one of the arrows. If not, do an I$ReadLn. If it i s, go through its history. Of course, this does still not allow SCF editing on those history lines. Drat. Seemed like such a good solution, too. Still a system call like the one I described could come in very useful. Maybe we need a SetStt to load t he SCF last-line buffer with whatever WE want? That could be EXTREMELY USEFUL!!! Brian -*- End of Thread. -*- 30344 24-JUN 02:52 General Information File Attributes From: BRIANWHITE To: GREGL Greg, While on the subject of expanded attribute bits, how about another 24! 3 bits by 8 categories. The three bits are Read, Write, and Execute. This would be the same as having 8 different groups plus user and public. Of course all user numbers would als o have to have a similar 24 bits of permission associated with them. Brian -*- 30357 24-JUN 19:13 General Information RE: File Attributes (Re: Msg 30344) From: GREGL To: BRIANWHITE Brian, Out of curiosity, what would you do with eight Read/Write/Execute categories? I don't see the need for it, to be honest. As a matter of fact, I think it would be more trouble than it is worth. One idea that I've been toying with is assigning default attributes to the user via the password file. These attributes would override those stored in the file descriptor - downward only. That is, if the user has default attributes of group read and group write, he can't write to any file he doesn't own even if the file descriptor has group write permission. That could be very useful for putting "ropes" around certain users. -- Greg -*- 30388 26-JUN 00:13 General Information RE: File Attributes (Re: Msg 30357) From: RAGTIMER To: GREGL Good idea for BBS operators. And I thought you should know that after all these years, only a few sites have ever got the group attributes in UN*X to do anything worthwhile. A great concept that nobody can make work. Microware seems to either make something work or leave it out -- not a bad philosophy. -*- 30578 8-JUL 03:19 General Information RE: File Attributes (Re: Msg 30357) From: BRIANWHITE To: GREGL Greg, I've heard two different things about those group attributes. First was something from Frank Hogg mentioning that OSk uses the same file system as OS-9, thus a hard disk would port over directly. That was when he was advartising the QT-CoCo as a tempor ary hard disk with 68000 expandability. However, just the other day, I'm sure Kev mentioned something about group attributes under OSk. I'm not sure where in the forum that is, but I don't think I misunderstood it. Even if OSk does have the same file system as OS9, then there is still no place for any of the attributes like "deletable" that you mentioned. I was just mentioning what I though would be really useful attributes. I know they would solve a lot of my mu lti-user headaches. If you get any ideas on how to make it work, let me know... I came up with the number 8 because that added 3 bytes to the current 1 to get a full longword of attributes. It would be nice to have separate groups for, say "temporary user", "common user", "privaledged user", "software development", etc. That's fou r, right there. Note, that these groups were not exchangable. By that I mean that each user did not have 8 goups that were independant from another user. A group number that mapped to one of the 8 would be even better. Or, the extra 4 in each byte co uld represent any single group from a choice of 16. Brian -*- 30614 8-JUL 20:47 General Information RE: File Attributes (Re: Msg 30578) From: TIMKOONCE To: BRIANWHITE (NR) Not sure about this, Brian, but I think that under OSk, rather than interpreting the 16-bit user number as one number as in OS9/6809, it's interpreted as two 8-bit numbers. The high-order number is referred to as the "group", and the low-order number is referred to as the "user number". So, you have 256 "groups" of 256 users each. I don't beleive the file system makes any distinction between public and group access, it's strictly a convenience for assigning user numbers. I could well be wrong, but this would at least explain what you say you've been told. If anyone knows better, please correct me. - Tim -*- End of Thread. -*- 30347 24-JUN 03:26 Graphics & Music VIEW 4.0 From: TIMKOONCE To: ALL Shortly after uploading VIEW 4.0, Zack Sessions pointed out to me that I had uploaded the wrong AIF.gif and AIF.gbw files! I've just re-uploaded the entire archive with those corrected. In both of those AIF files, the first two lines should be: View -s Anyone that just used the AIF's to view GIF files with VIEW should notice that VIEW now produces different results from ViewGIF!! - Tim -*- 30348 24-JUN 03:29 Programmers Den Make update From: TIMKOONCE To: ALL I just re-uploaded MAKE to the database. This upload fixes one minor buglet, and adds a new feature. You can now use MAKE with no makefile! Typing "make " with no makefile is the same as having a makefile with the single line: : i.e. MAKE will try to build the target file by searching the current directory for source files that fit it's built-in rules. By setting up the default rules in "make.default" properly, this could be a great help. Thanks to Mike Knudsen for suggesting this change, and to Eddie Kuns for discovering the bug! - Tim -*- 30385 26-JUN 00:02 Programmers Den RE: Make update (Re: Msg 30348) From: RAGTIMER To: TIMKOONCE And thanks to you for putting that feature in! Sorry I didn't help with the docs as we hoped. I'll take a look at yours soon as I download the whole thing. My "beta" version is doing just fine, meanwhile. Nice work, Tim -- a lot of hackers will be grateful. Oops, I meant "developers", grin. -*- End of Thread. -*- 30350 24-JUN 10:07 Telcom OSTERM From: ELM To: ALL I've just started to use OSTERM and have experienced a problem when downloading ASCII text files under XMODEM or YMODEM. I seem to be getting extra line feeds. When I print the text (by LISTing it to printer) I get what appears to be triple spacing. I've tried XMODE /p -lf, but it doesn't change anything. Anyone have any ideas? Thanks. Len -*- 30367 25-JUN 02:35 Telcom RE: OSTERM (Re: Msg 30350) From: TRIX To: ELM You will probably find relief from your CR/LF problem if you go to the SETTINGS menu. (It's been so long since I set mine, I can't remember exactly) There is an option there to set up your XModem downloads. It will ask you how you would like your lines terminated when you download text files. You can set it to end all your text download lines with just a CR which will make listing your files much easier. Here's the problem >I'M< having with OSTerm (2.0.7): When I do a YModem-Batch download of a text file, the size is ALWAYS set (by OSTerm) to 44418 regardless of the actual size of the file. The download terminates properly (i.e. doesn't error out) but I'm still left with a 44K file with lots and lots of garbage at the end. Y-Batch downloads of binary files like PAKs, ARs, and executable code all work fine as do regular YModem downloads of text files. How's THAT for a puzzler? -John. -*- 30370 25-JUN 03:13 Telcom RE: OSTERM (Re: Msg 30350) From: KNOT1 To: ELM {Len, Try going to "Settings (Profile)" and change your "DOWNLOAD-Line-terminators" to just carriage return instead of carriage return+linefeed, which it may be set to. -Jamie (KNOT1)- i] -*- 30373 25-JUN 18:09 Telcom RE: OSTERM (Re: Msg 30367) From: DODGECOLT To: TRIX I think the Delphi Y-batch program is the culprit- apparently it just doesn't send a length field when sending text files. -Mike -*- 30378 25-JUN 21:22 Telcom RE: OSTERM (Re: Msg 30367) From: EDDIEKUNS To: TRIX I think I understand the problem with OSTerm and YModem batch. When Delphi sends a text file via YModem batch -- it doesn't send a file-size. Delphi doesn't know what you're going to do to the file in the way of stripping linefeeds or whatever, so it just wimps out and doesn't send any filelenght information. (The YBatch protocal doesn't leave Delphi much choice, I add.) Thus, OSTerm may not (???) handle this lack of file length information very gracefully. Eddie -*- 30381 25-JUN 23:18 Telcom RE: OSTERM (Re: Msg 30367) From: ELM To: TRIX Ain't life mysterious? Downloading a series of "44K" files sure is a quick way to fill up a disk! I'm using OSTERM 2.0.8, but I haven't tried YMODEM-Batch. I'll try to find a way to give it a shot and let you know what happened. -Len -*- 30383 25-JUN 23:20 Telcom RE: OSTERM (Re: Msg 30370) From: ELM To: KNOT1 I'll try resetting the download settings (assuming they're not correct), but I've been downloading from Delphi for so long with other term programs with no problem. Also, I have the same problem when downloading from other services with OSTERM 2.0.8, although I don't know what THOSE settings are. Thanks! -Len -*- 30386 26-JUN 00:04 Telcom RE: OSTERM (Re: Msg 30350) From: RAGTIMER To: ELM All text files I download (with OSTERM) have an extra line feed. There are little utilities here to strip them off, or write your own. What I do is just read the file into Dynastar word processor and write it back out, and they're gone. Unforch, so are TABS (char byte 09). -*- 30395 26-JUN 00:48 Telcom RE: OSTERM (Re: Msg 30367) From: GREGL To: TRIX John, That sounds like a flaw in OSTerm. When you download a text file from Delphi, the filesize is set to zero in the Ymodem Batch header block. This is mostly because Delphi can't calculate ahead of time what the actual filesize will be. That is, Delphi automatically handles end-of-line conversions (CR/LF to CR or LF and vice versa) according to your SETTINGS and doesn't know how many end-of-line characters are stored in the file and whether or not they need to be added or removed. OSTerm should not perform an explicit set filesize call if the filesize in the Ymodem Batch header is zero. To be honest, I don't think it should perform an explicit set filesize call regardless. If the filesize stored in the Ymodem Batch header block is invalid, OSTerm can really mess up an otherwise good download that way. -- Greg -*- 30398 26-JUN 02:35 Telcom RE: OSTERM (Re: Msg 30367) From: KNOT1 To: TRIX Yes, with YModem (batch) the "File size" in block 0 is optional. Non-text files are always the same size, so Delphi includes the size in block 0. Text files can vary do to the CR/LF/CR+LF line terminator option. So, instead of scanning the file and figuring out the file size, Delphi just sets it to zero or maybe null. It appears that OSTurm may be assuming that file size is always included, or it might just be a simple bug. Since we're airing our YModem beefs, here's mine: Note: I'm not using OSTerm. When the file is about 1K or more evrything's fine. When it's smaller, when it starts with XModem (128 byte) blocks from the start, I receive block 0 just fine. When I ACK it, Delphi sends block 1 before I send the NAK-CRC for it and it gets purged from the buffer prior to sending of the NAK-CRC. This wouldn't be so bad on its own, but then Delphi will NOT re-send block 1 when sent either a NAK-CRC or a NAK. I have to abort the transfer and download it using XModem-1K. This never happens with the larger files. I suspect this may be a bug on Delphi's end. Any help, anyone? -Jamie (KNOT1)- -*- 30399 26-JUN 02:36 Telcom RE: OSTERM (Re: Msg 30383) From: KNOT1 To: ELM Len, Does OSTerm download direct-to-disk or to a buffer and then writes it to disk? If to a buffer, it may be doing some sort of "translating" somewhere. -Jamie (KNOT1)- -*- 30400 26-JUN 07:57 Telcom RE: OSTERM (Re: Msg 30399) From: ELM To: KNOT1 OSTERM downloads direct to disk. -Len -*- 30414 27-JUN 01:35 Telcom RE: OSTERM (Re: Msg 30395) From: KNOT1 To: GREGL Gregy, baby!! What are you saying??! The file size information is why I WANTED YModem Batch! If that information is invalid, then the system sending the file had better get it's act together! All of the information in block 0 is CRC protected, after all. So there shouldn't be any "bad transmition" problems. It's a really great way of cleaning up all that extra garbage at the end of the file. Well, *I* like it, even if others don't! :-) -Jamie (KNOT1)- {P.S.: Did you read my message to you a few days ago? (#30254) -*- 30415 27-JUN 01:36 Telcom RE: OSTERM (Re: Msg 30400) From: KNOT1 To: ELM Well, I guess that blows THAT idea out of the water! If it's not your settings, I can't figure what OSTerm is doing. Does OSTerm have any "Download settings" you can change? I guess you probably would have already have tried that though, hmm? I have my own terminal program which has YModem Batch and it doesn't have any such problem, so it's not Delphi having problems. If you figure it out I'd be glad to hear what it is. -Jamie (KNOT1)- -*- 30417 27-JUN 20:50 Telcom RE: OSTERM (Re: Msg 30414) From: GREGL To: KNOT1 Jamie, Somewhere along the line it seems you missed the point entirely. When you download an ASCII (text) file, Delphi automatically performs end-of-line conversions for you. If you download a file that was originally uploaded using CR/LF line terminators, Delphi will convert those to CR automatically. Of course that really depends on your settings as you can tell Delphi to use CR, LF or CR/LF line terminators. If Delphi were to include the filesize, it would have to perform perform the end-of-line conversions prior to initiating the file transfer and that could mean some very long delays. I much prefer it done the way it is. As far as the various file transfer protocols go, Xmodem, Xmodem-1K, and Ymodem aren't that great. Neither of them work very well across packet switching services such as Telenet and Tymnet. Wxmodem tried to take care of that but it resorts to vanilla Xmodem once the window-buffer has been exceeded on many systems. Although you may argue the point, Kermit and Zmodem are both well designed protocols (although the fact that they are *designed* makes them stand above the rest - the others just happened out of accident) that work very well in many instances where others fall flat on their faces. Oh yes, I have used both Kermit and Zmodem in many cases where neither Xmodem or Ymodem would even get started. Although Kermit suffers from the small block sizes that are used by the earlier implementations. For many reasons, most of which is described above, I have pretty much abandoned use of Xmodem, and Ymodem. Fortunately, you should see Zmodem available on Delphi in the very near future. Zmodem is currently in beta test and results so far show that it works very well, although error recovery (the ability to pick up where you left off on aborted downloads) has not been implemented as of yet. Zmodem also uses variable length packets to aleviate the padding characters. -- Greg -*- 30423 28-JUN 01:24 Telcom RE: OSTERM (Re: Msg 30417) From: KNOT1 To: GREGL Greg, Yes, but Delphi could save two file sizes, one for single character line- terminators and another for two character line-terminators. Or maybe just the number of lines in the file. This could be done at the time the file is uploaded, taking no additional download time. From what little I've heard, ZModem does sound nice. I've been writing my own terminal program and have been only able to implement those protocols supported on the boards I call. I only call a couple of places and none of them have ZModem. I'm glad to hear that Delphi will have ZModem. Can I assume that there is or will be text files describing how to implement it from a programming standpoint? Thanks. -Jamie (KNOT1)- -*- 30426 28-JUN 20:57 Telcom RE: OSTERM (Re: Msg 30367) From: ELM To: TRIX I took your advice and changed my settings to CR only. It seemed to solve the problem, at least for the text file I downloaded as a test. However, the problem persists on other systems I use that don't permit changing settings. In the meantime, I have switched to Telstar and am about to download a text file as a test. One annoyance I have discovered with Telstar is that for some reason, CTRL-S doesn't stop the scroll on Delphi. (Sigh) Life is SO complicated! Thanks again, -Len -*- 30428 28-JUN 23:12 Telcom RE: OSTERM (Re: Msg 30423) From: EDDIEKUNS To: KNOT1 The problem is that Delphi has no idea what CR/LF you use, and thus, even if it counted lines and figured the arithmetic, it wouldn't know what size to send. YModem batch is a fundamentally flawed protocal, tho better than it's predecessors. It's nice for binary files. :) I suppose that Delphi could implement that line-counting and force you to set the EOL-character count. But that forces people to understand more about their machine than many are willing to. (And if that is set wrong, then files will either be extended with garbage at the end or chopped short.) File length isn't so important with ASCII files anyway, as a good YBatch download protocal will strip all ^Z and NULLs (etc) anyway. Tho the rest of the attributes (last change date + attrs) might be nice. ZModem docs exist I believe in the telecommunication database. In fact, I believe public domain UNIX C source to ZModem has been posted here. Eddie -*- 30431 29-JUN 00:54 Telcom RE: OSTERM (Re: Msg 30426) From: KNOT1 To: ELM Len, You can always still use an utility here to stip those line-feeds from the files you download. -Jamie (KNOT1)- -*- 30432 29-JUN 00:55 Telcom RE: OSTERM (Re: Msg 30428) From: KNOT1 To: EDDIEKUNS (NR) Eddie, Sure Delphi DOES know what CR/LF you use! That's why you set your "DOWNLOAD- Line-terminators" in the "Settings (Profile)" section. How else does Delphi send the files with the correct line terminators? You're not talking about something else, are you? How does the receiving YModem know that it is a text file? What if it's a binary file that ends with Ctrl-Z's and/or NULL's? I was concerned about chopping off the end of files by doing that. Thanks, I'll look for the docs and the source. -Jamie (KNOT1)- -*- 30445 30-JUN 15:11 Telcom RE: OSTERM (Re: Msg 30350) From: TIMKOONCE To: ELM Here's the reason for your problem. Under XModem or YModem, ALL text files are supposed to have both a CR and a LF between lines. Delphi allows you to set things so that it only puts a CR between lines, which is what OS9 uses, but most BBS's aren't so friendly. You basically have two options: - Find a program which will let you remove the extra LFs from the file. One possibility is the "list" replacement I uploaded here a long time ago. It will automatically remove/convert LFs, so you can simply "list file >newfile" to correct that problem. - Find a terminal program which will do that conversion for you on downloads. I have a stand-alone YModem program that does it, as soon as I can clean it up enough for posting, and Eddie Kuns has one that does it that should be in the next shareware release of KBCom. Unforch, few OS9 terminal programs offer this ability (though most RSDOS ones do seem to, dunno why the difference). - Tim -*- 30447 30-JUN 15:18 Telcom RE: OSTERM (Re: Msg 30367) From: TIMKOONCE To: TRIX OSTerm 2.0.7 does have a problem with YModem file sizes. Here's what happens: - Under certain situations, (files that need conversion, or files being written by another process), the YModem sender cannot know the final file size. In that case, it is correct behavior for the YModem sender to NOT include a file size. - OSTerm does not recognize that a file size is not included, and ends up with some rediculous size. (You're lucky, when I had problems with this, OSTerm decided that everything was 2 megs long!) - OSTerm 2.0.7 tries to pre-extend the file to the final length, so if the actual amount of data received is too small, then you still end up with a file with that size. - OSTerm 2.0.8 corrects this, and doesn't pre-extend the file, so at least you don't end up with huge files. - Tim -*- 30448 30-JUN 15:26 Telcom RE: OSTERM (Re: Msg 30432) From: TIMKOONCE To: KNOT1 Jamie, There are some problems with the YModem protocol. You've found the two big ones: - There's no indication of file type, so the receiver can't know whether the file is binary or text. - It's not always possible to know the file size in advance. More modern protocols, such as Kermit or ZModem, have variable-sized packets so they don't need to know the file size in advance. There are several work-arounds, some of which Eddie and I have been working with lately. In a short while, some of that work should be available here. - The user can tell the receiver what type of file to expect. This is what most RSDOS programs currently do. - The receiver can examine the file contents and try to guess what file type it is. I have a program I'm writing which hasn't guessed wrong in over 50 dowxDnloads. I'm starting to trust it. - When doing text downloads, which is the most common case where the file size isn't known in advance, the receiver can simply remove ^Z and null characters, which are the most common pad characters, in addition to performing end-of-line conversions. I'm also using a "smart" end-of-line conversion algorithm which correctly converts Unix-style files which only have LFs between lines. - The Atari people came up with a clever way of coding the file size in the last XModem packet. A very clever hack that never caught on elsewhere. - Tim -*- 30450 30-JUN 16:42 Telcom RE: OSTERM (Re: Msg 30445) From: ELM To: TIMKOONCE I think I understand. I have changed my Delphi settings to CR only, and that seems to have solved the problem. I have been using three term programs; OSterm, Telstar, and Supercomm. Unfortunately, each has exhibited different problems when used to download under Xmodem or Ymodem. I have downloaded KBCom but haven't been able to boot it. Possibly an error in downloading. I guess I've been spoiled by reliable, uncomplicated terminal programs like MikeyTerm that do the stripping, slicing, dicing, etc. automatically. Thanks for the help! -Len -*- 30455 1-JUL 00:46 Telcom RE: OSTERM (Re: Msg 30450) From: TIMKOONCE To: ELM Well, MikeyTerm doesn't do it automatically, it just stores it in mem and lets you decide when you save it to disk. Several other RSDOS term programs do the same: let you decide. The equivalent for OS9 would be to either ask you before the download starts, or else let you use some OS9 utility to do the conversion. There are several easy-to-use utilities in the database here that can help with that. Also, as I mentioned to Jamie, I've been working on a "smart" download program which I should get on the ball and clean up enough to upload here. It will automatically determine whether the other end is using XModem, YModem, or YModem-batch, automatically determine whether the file is text or binary, and does several other nice things, all automatically. Pretty easy to use, but I need to get it cleaned up enough for someone other than me to use! - Tim -*- 30469 1-JUL 23:36 Telcom RE: OSTERM (Re: Msg 30448) From: KNOT1 To: TIMKOONCE Hi, Tim, I'm still touching up my term program. Converting hard-coded features into user-selectable. Hoping to someday add some of these features into it, though not right away, or I'llrTJQgQ2IM%=9U%Q1=9e2=I*A1=%9j$TH(LoUQz*"=M9"=U9"==!=e9=BukH2oJ=U:UMMQJ"!2%1"eA}j$h=5Q!%9b%-iJJQz91e=9Q%9M!I QIMbb9j2JQM %%}j$tJHb%QQ1j=I=5A1a"!9"!Q}Ju+H:=U1BY~:o"QI5%9"!Q:%Q!%9"!5RTHZ9sQ1= -"==1%!Q}j$TH(M1"!EI%jQ!=JMrQ9J9"!=J9jeI=I5"=*MJQ9JUHhV+59QJQzUQ"!=U!QI:I%Q%95*AJUj5 UM"!EI%=IJ,X6l5RDoesn't even use it at all, and Delphi only uses it on text files. Thanks for the input. -Jamie (KNOT1)- -*- 30473 2-JUL 03:30 Telcom RE: OSTERM (Re: Msg 30455) From: KNOT1 To: TIMKOONCE Hey! Hey! What's going on here! Stealing my techniques! And without even KNOWING about them even! ;-) Just kidding, of course. But mine does automaticly determine which protocol is being used for downloading too. All you have to do is tell it if it is Checksum or CRC, since it needs to know which NAK to send. This wasn't because I was TRYING to be fancy or anything. I was just implementing each protocol one at a time (XModem, XModem-1K, then YModem) and, not wanting to write more new code than necessary (i.e. lazy :-), I just expanded the old code, figuring I'd just add promts where needed. Well it turned out they weren't needed. I figured, "Gee, that's NICE." And that's how that worked out. Not due to any great "vision" for sure! Heck, I had never even USED them before I wrote the program. So, I was wondering if you would have the time and and e willing to give it a test spin? Sounds like you would know what to look for. If so, do you have a Hayes-compatable modem, and what baud is it? I believe I can assume you have a CoCo 3 with at least 512K, right? Thanks again. -Jamie (KNOT1)- -*- 30507 4-JUL 21:24 Telcom RE: OSTERM (Re: Msg 30473) From: TIMKOONCE To: KNOT1 Actually, Jamie, I've been working on these ideas for a while now. A couple of pointers for you: 1) Automatic CRC/Checksum detection is easy, just send "C" three times, and if you still have no response, send NAK. This is the method recommended by Chuck Forsberg, author of the YModem protocol. 2) _please_ include proper handling for ASCII text files. I get tired of having to filter downloaded text files to remove/convert linefeeds. I use a simple algorithm to do this type of conversion: if a LF follows a CR, remove i, otherwise, change it into a CR. If you have any other good ideas you'd like to share, I'm interested. If you're writing a terminal program, allow a shell escape, and make sure you release the serial port (i.e. turn off the signal) before you fork the shell. That way, you won't mess up other programs that try to use the serial port. As for beta-testing, I'd love to, but I don7t have very much time right now. You're welcome to send it to me, and I'll play with it and try to give you some comments/feedback, but I am busy, so the response might be less than instantaneous. - TimAzt -*- 30510 4-JUL 22:00 Telcom RE: OSTERM (Re: Msg 30469) From: TIMKOONCE To: KNOT1 I buffer up the first 1k of the file (real easy to do with YModem!) and test that much. Seems to help prevent false indications on the first 128 bytes. I "guess" a file is text if it only contains characters 0, 9, 10, 13, 26, 32-126, and the first byte isn't 0. You have to allow for 0 and 26, since those are the common pad character (if the file is less than 1k, those characters might be there), the rest is pretty self-explanatory. Seems to work pretty well, so far. Right now, I can simply fork a shell from inside most terminal programs, type "xydown", and it will: open it's own serial path, determine the transfer type (CRC or Checksum, YBatch, YModem or XModem), use a reasonable file name (convert the YBatch filename if there is one, otherwise it uses xydown.file), change the filename if necessary to avoid overwriting any other files, determine the file type and remoe LFs and such if necessary, all automatically. Very, very convenient. Someday I hope to add WXModem support for use on Delphi. I'm hoping to upload it soon. It will be public domain, so anyone is free to use the ideas and code in it however they please. - Tim -*- 30523 6-JUL 02:08 Telcom RE: OSTERM (Re: Msg 30510) From: KNOT1 To: TIMKOONCE Tim, But what if a text file contains Alt-characters, such as "-", ";", ",", or ".", or any of the others? Does the user have the option of forcing the text mode on/off? Right now my program just writes the data direct to disk, with no translation. Hadn't thought of it before, but I am now. What if it's a LF-CR combination instead of a CR-LF one? Also, didn't you say something before about yours also handling UN!X LF-only type files? Yes, if you select CRC, mine does switch to Checksum after about three attempts. If you're using YModem (you can optionally tell it what to expect) it automatically selects CRC mode for you since all YModem protocols are suppose to support CRC, otherwise it prompts for your selection. This was useful when I wanted to force Checksum on a board that used CRC but I had some problems with it: it ALWAYS expected a NAK-CRC for bad blocks, and wouldn't accept a normal NAK. Real annoying. Here's feature of my program that I think is kind of neat. It has a co-program that runs concurrently with the terminal program. It's called "bigbuff" and all it does is extract data from the serial port and puts it in a 7-1/2 K get/put buffer. This results in excellent performance, even when capturing text direct-to-disk at 2400 bps (I am using the ACIA patch for a 256 byte system buffer) and I haven't lost a character yet. Also allows you to use menus or perform other functions while there is still incoming data without having to worry about buffer overrun. It is very "CPU friendly" in that it doesn't hog CPU time. I do normally bump its priority to 129 just to minimize any chance of lost data if some other running program is chewing up CPU time. Any higher than 129 an IT chews up CPU time. Also, if "bigbuff" hasn't received any data in about 8 (I believe) seconds, it goes to sleep, saving even more CPU time. It has a fairly slick routine so as to {not miss any data when going to sleep without having to constantly wakeup every so often. Yes, I do have a Shell escape. Other programs are always free to write to the serial port (even while the term program is running), but if they want to read from it, they'll either have to use the "bigbuff" routines, or more likely, I'll make a way to tell "bigbuff" to "hibernate" when it receives a certain signal. I'll send you a copy as soon as I cleanup a few more things. There's no horrendous rush or anything. I've been writing it on and off for about a year now. I don't believe a little more time will be big deal. Oh, is your modem Hayes-compatible? What baud is it? Thanks a lot, -Jamie (KNOT1)- P.S.: Those WERE Alt-characters, but it appears Delphi strips the High-bit! -*- 30544 7-JUL 14:42 Telcom RE: OSTERM (Re: Msg 30523) From: TIMKOONCE To: KNOT1 Well, you appear to have found two cases where the automatic file-type detection might not give the desired results. Here's some of the thinking, though: - If a text file contains ESC sequences or ALT characters, then it's safest to transfer it as a binary file, since it may well be the case that LFs appearing in such a file should be treated as LFs and not as line terminators. The algorithm should err on the side of going to binary, as the user can always do the conversion manually if necessary. My program does allow the user to force ASCII filtering, if they wish. - My algorithm would end up doing the following conversions: CR/LF -> CR LF -> CR LF/CR -> CR/CR CR/CR -> CR/CR As you can see from the second case, it handles Unix files (also Amiga) just fine. As for your local BBS that doesn't treat NAK and 'C'(==NAK_CRC) identically, that deserves a complaint to the BBS author. That is a serious problem. I imagine they get lots of complaints! Your "bigbuff" idea sounds quite reasonable. Sounds like it should try setting up a received data signal and using that, which should cut down on the CPU time required. Sounds a lot like some ideas I've had. I have a 1200-baud Haye's-compat modem. - Tim -*- 30577 8-JUL 03:19 Telcom RE: OSTERM (Re: Msg 30417) From: BRIANWHITE To: GREGL Greg, The one nice thing about OSTerm automatically creating the of the full size right at the start is that it eleiminated fragmentation problems. And on ha hard disk like mine, finding a new free block can take up to 5 seconds (I'll have have to re-format o ne of these days). I wouldn't want to have to do that after each 1k of data. You're right though about handling files that don't have a file size. Those should be expanded as necessary. Brian -*- 30579 8-JUL 03:52 Telcom RE: OSTERM (Re: Msg 30544) From: KNOT1 To: TIMKOONCE Well, NAK and 'C' aren't suppose to be treated *identically*. On page 24 of my X/YModem docs it says "After the first is received the sending program should ignore s." So the board I was calling was doing just the opposite, ignoring s! Yes, my "bigbuff" does set up a received-data-signal, after about 8 seconds with no incoming data. Thanks for all the help and information, Tim. I've captured all of this dialog and intend to implement most/all of it sometime before January, when I'll be going (hopefully!!!) off to U of M full-time, and won't have much time for writing programs. But first I want to get my "cp" program down to under 7-1/2 K if possible. I have it down to 8096 bytes from the original 8862 bytes. I hope to be sending you a copy sometime in the near future. And thanks again. -Jamie (KNOT1)- -*- End of Thread. -*- 30352 24-JUN 13:28 Utilities Pak problems From: EARLROB To: ALL I have been using pak for a few years with no problems, until now. I have about 15 GIF pictures in a pak, and I can not get them out. When I try to extract any one of them, the program gets stuck on the first item in the pak, and locks up. When I try to extract all of the files, the first file is extracted, but with all of the other files appended to the end of it (all of the files extract as one stream). The directory of the pak shows that all files still exist as seperate files in the pak, and when I tried to add to the pak, each seperate file was copied to the new pak. I can not remove, update, test, or extract. One thing that I tried to do was to use ded to take the whole pak stream that is extracted in the first file, dump the sectors of each seperate file, and hence, get each file (Gif files are not compressed by pak). My only problem is that I know how to diddle with the file length for extra characters at the end of the files, but not at the beginning. Viewgif will not work with extra leading chars. Can any body help, either with the successful extraction, or with trimming the leading chars. of the files? It has been a very frustrating experience. Thanks, Rob -*- 30371 25-JUN 03:14 Utilities RE: Pak problems (Re: Msg 30352) From: KNOT1 To: EARLROB Rob, You could write a simple program to copy the data from one file to a new one, skipping past the leading characters you want to remove. -Jamie (KNOT1)- -*- End of Thread. -*- 30359 24-JUN 22:50 Programmers Den MM1 & C From: NES To: ALL Paul ward, Kevin, will the C compiler for the MM1 be able to compile OS9 level 2 C sources without modifing it? as log as it dosent have MV calls or what? -- Eric -*- 30389 26-JUN 00:16 Programmers Den RE: MM1 & C (Re: Msg 30359) From: RAGTIMER To: NES I'm not Paul or Kev, but I'd wager you can port any C programs as-is as long as there are no raw system calls, ie, _os9(), as well as no Coco-specific calls such as you mentioned. The _os9() calls will work as soon as you rewrite them a little bit. Remember, they use CPU registers so have to change a bit. -*- End of Thread. -*- 30366 25-JUN 02:21 Programmers Den Subroutine modules in C in OSk From: EDDIEKUNS To: ALL Does anyone out there know if OSk supports subroutine modules in C (or any other language) in OSk in an easy way? (I mean subroutine modules which can share your global variables.) I know roughly how to do this in OS-9, but before I code it I want to make sure I'm not giving myself a headache for the future in porting code to OSk! Eddie -*- 30368 25-JUN 02:41 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30366) From: TRIX To: EDDIEKUNS Don't keep us (ME) in suspense! How the heck do you pull off subroutine modules? Inquiring minds (mine) want to know! Was that a subtle enough hint? -John. -*- 30375 25-JUN 20:10 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30366) From: XLIONX To: EDDIEKUNS Howdy Eddie, I am not sure if osk supports it but the 680x0 instruction set does (better than the 6809). I think there is a global link and execute instruction. If MMPU is installed I am not sure if processes can easily cross borders ?!?! -mark -*- 30379 25-JUN 21:25 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30368) From: EDDIEKUNS To: TRIX Well, I haven't DONE it yet! Once I've done it, I'll write up an article and post it. I hope to turn the terminal emulations into overlays in KBCom sometime after my vacation (which starts tomorrow!). Mike Knudsen is the one who pulled it off first tho, in UltiMusE! He deserves all the credit for research and clever thinking. Eddie -*- 30380 25-JUN 21:29 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30375) From: EDDIEKUNS To: XLIONX Thanks! Yeah, I've been reading through the Motorola 68k Users Manual! Quite a step up from the good-ole 6809. I have the basic ideas down but won't really have a working model until I WRITE some 68k assembly, I think. It's a good thing I speak 6809 to start with! :-) I'm hoping that OSk supports subroutine modules in a simple way. It would make my life much much easier! Eddie -*- 30391 26-JUN 00:23 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30366) From: RAGTIMER To: EDDIEKUNS Eddie, if you mean "do all of Ragtimer's dirty rotten tricks for getting shared globabls in subr modules also work in OSK C," then well, I'm glad you brought that up....well, "glad" isn;t the way I feel, but yes the subject needs some thought, hmmm. But who needs 'em? Just write one big momma application program! For those special systems uses (terminal adapters), I dunno. -*- 30392 26-JUN 00:31 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30379) From: RAGTIMER To: EDDIEKUNS Hey thanks, Eddie. But I don't get any thanks for documenting the tricks very coherently, and I don't recall uploading them here either. Just writing subroutine modules isn't too hard -- look in the back of the C Manual under writing subrs for Basic09, and ignore the crud about the extra arguments. Use that -b switch to the linker. Hard part is getting common global variables. Globals vars are a main reason why all serious OS9 programs are in C and not Basic09 (my humble opinion, grins) . To get these in C you gotta cheat and fool the compiler, and dodge little land mines in the C Library. If enuf people holler, maybe I'll collect my writings and clean them up and post. -*- 30397 26-JUN 01:16 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30392) From: EDDIEKUNS To: RAGTIMER Holler! If you don't post your descriptions on how to do C subroutine modules then I'll do it once I figure it out! (hehehe) Perhaps the hardest part for me is figuring out how to chop up cstart.a into the lowest common denominator. I haven't looked at it hard tho. Eddie -*- 30418 27-JUN 21:20 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30397) From: RAGTIMER To: EDDIEKUNS Maybe I should email you the source for dstart.a, as I call it. I ripped out everything I could understand, including the stack checking code. Had to leave that OVERFLOW message in, tho. Hardest part of making my scheme WORK is to allow for the little initialized ~r routines bring in with themselves. Printf() family and malloc(). -*- 30427 28-JUN 23:04 Programmers Den RE: Subroutine modules in C in OSk (Re: Msg 30418) From: EDDIEKUNS To: RAGTIMER Another problem I'll have is the large static arrays of strings KBCom uses for the menus. Hmm. Unfortunately, I can't not make them static as C won't allow an initialized 2-d array. (array of strings) Eddie -*- End of Thread. -*- 30372 25-JUN 08:19 Programmers Den Accessing Screens From: HYPERTE To: OS9UGPRES Kev, Here's one for you. I'm adding a feature into ShellMate to allow it to execute programs in the same way that GShell does (minus the icons). It works fine for the first program that I fork. But when I try to fork a second one, I can't get to the screen where the first one was forked, to possibly run the second program on that same screen as the first, providing there was room on that screen. The first time I fork a program I use open ("/w",3). The second time I fork a program I've tried to simply Select the same path number that the open call returned when I forked the first program, but that doesn't seem to work. And doing another open ("/w",3) call simply gives me a brand new screen. I realize that C isn't your strongest area (yet), but I thought you might be able to give me a concept that I could convert to C code and use. So, got any suggestions? ..Thanks... ..Eric... -*- 30436 29-JUN 21:31 Programmers Den RE: Accessing Screens (Re: Msg 30372) From: DENNYSKALA To: HYPERTE Check out a program I uploaded called 'getnw'. It gets the real name of the next available window. Then if you open /w right away, you know its real name. The program is asm, but the concept may be of use to you. ***** Dennis ***** -*- 30446 30-JUN 15:14 Programmers Den RE: Accessing Screens (Re: Msg 30372) From: TIMKOONCE To: HYPERTE Some time back, I think I finally figured out how GShell does that trick of being able to go back to any screen. The way I think it does it is to open a full-screen window, turn off device protection for it, and use that as a "handle" on that screen. Once you have a window set up like that, you can select that window (which you own), and then put other windows on top of it (since you turned off device protection). The problem with trying to Select a window where another program is running is that if that program is waiting for input, SCF won't let you write to the window, so you'll end up waiting until that program is done with it's input. - Tim -*- 30636 10-JUL 02:56 Programmers Den RE: Accessing Screens (Re: Msg 30372) From: OS9UGPRES To: HYPERTE Eric, I see that someone has answered... and correctly. GShell opens a full-size window, and turns off protect on it. Any windows opened "over" it share the same video memory, so you can draw to the background screen anywhere you wish. That's how gshell lets you draw the expandable box with the mouse... it's simply using that background window, and checking for conflicts with windows whose coords it keeps in a table. Then it can open new windows and fork programs, using type FF or 00, altho I'm not sure which they actually use. I have to admit, working on the OSK windows is making a lot of this knowledge seep away from me . Kev -*- End of Thread. -*- 30376 25-JUN 20:20 New Uploads XPres From: XLIONX To: ALL I am sorry if the ARC format caused anyone problems :-(. In the future I will try to use PAK. Os9arc and Dearc provide the best compression to date (that I have found). Bug-Report for XPres.doc: for the call gC SetGC* : should read gC# SetGC ptr* Thats all so far and ignore the "'" in the docs arround the # sign. I know the things huge (I have 1Meg) but I am working on the RMA version. I have about 20% of the untested code written...arrrgggghhhhhhh! -Mark W. Farrell -SIGOp ProSIG (Pinball Haven) -XLIONX (DELPHI) -mwf@SANDV -*- 30394 26-JUN 00:42 General Information os9 pascal From: GENEDEAL To: ALL Help..... I'm trying to open a path to my printer with os9 pascal. I've not worked with it extensively, but I've done quit a bit with Turbo Pascal on the PC. I'm trying to put together some library routines for a project I'm working on, but every thing I've tried in relation to opening a path to my printer results in a pascal error 98, or 92 depending on the open mode I use and always results in an OS9 error 20 3. I'd love to resolve this and get on to other things. Any help would be appreciated. Gene Deal -*- 30411 27-JUN 00:30 General Information RE: os9 pascal (Re: Msg 30394) From: XLIONX To: GENEDEAL ; I hate to be late on this one but what call are you (have you) used to open a path to the printer. I think that this should work: WRITELN('/p', char_array) If not then mabey you have a bug (or two)? -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445) -XLIONX (DELPHI) -mwf@SANDV -*- 30421 27-JUN 23:24 General Information RE: os9 pascal (Re: Msg 30411) From: GENEDEAL To: XLIONX Mark, I opened the file with the following: rewrite(prt,'/p',2); where 'prt is defined as a textfile. This line doesn't present the error 92. The error occurs on the next line which is a writeln. I've tried sending different info (i.e. strings, hex, etc. and they all error out. If I comment out the writeln and just open and close the file all is well (except that I haven't done any work! I've talked to microware and Greg Law, so far nothing. Still need to solve the problem. Again any help would be appreciated. Gene Deal -*- 30422 28-JUN 00:16 General Information RE: os9 pascal (Re: Msg 30421) From: XLIONX To: GENEDEAL (NR) Howdy, Have you tried RESET (REWRITE may assume some garbage about UPDATE mode being valid)? And how about APPEND? Try these to open /p and mabey check with OPENED to see if it is open. BIG OOPS!!! Stick to the calls with "text-filename" or "filename" ONLY so resett, rewrite,reposition,seekeof,shortio,read,write,update,writeeof,get,put WILL NOT WORK!!! Sorry for the confusion at my end (I had to look in the manual) :-(. Try: APPEND -Mark going to have to crank up pascal again (sigh, I am a 'C' and assembly person)! If only os9 pascal had a linker instead of a external support packages... -*- End of Thread. -*- 30405 26-JUN 21:20 General Information new uploads From: DICKWHITE To: GREGL Help! I cannot find any uploads later than Apr 30. I have read the announcement about a new uploads section but cannot find it. This could cause severe mental problems if not corrected (and I know someone is going to jump in on that one). -*- 30407 26-JUN 22:09 General Information RE: new uploads (Re: Msg 30405) From: TJSEAGROVE To: DICKWHITE The new uploads are contained under the NEW heading that is in the database area of the OS-9 conference. ....Tom -*- 30412 27-JUN 00:51 General Information RE: new uploads (Re: Msg 30405) From: GREGL To: DICKWHITE Dick, To get to the new uploads area, type DATA NEW at the OS9> prompt in the SIG. If that fails, you may need to get into SET PREFERENCES from the SIG and enable that topic in your settings. Everyone should have access to New Uploads by default but there's a chance that someone was missed in the updating. If you have problems accessing it, let me know and I'll enable it for you. -- Greg -*- 30416 27-JUN 20:29 General Information RE: new uploads (Re: Msg 30412) From: DICKWHITE To: GREGL I suspect I am one of the few where NEW is NOT enabled. I will head off and set it up. Thanks, Dick -*- End of Thread. -*- 30420 27-JUN 22:10 Programmers Den C From: NES To: ZACKSESSIONS Zack, I am trying Poke a memory location in c also read a location. I wrote this but the c.opt gets stuck on it. here is the rutine: reset() { #asm pshu x ldx #$FF61 sta x pulu x #endasm or can I do this? reset() { #asm sta $FF61 #endasm I location I am pokeing only reset's my curcuit, so 'a's value isnt important. also would like to peek a location $FF60 and get one byte of info: data() { char c; #asm get c #endasm return(c); } any help? eric -*- 30429 29-JUN 00:13 Programmers Den RE: C (Re: Msg 30420) From: RAGTIMER To: NES I found out that c.asm doesn't like do properly assemble stuff like sta $ff60 but I've heard that the > operator may help it work: sta >$ff60 However, it works for me to say ldx #$ff60 sta ,x so I don't know what your problem there is. Except -- DON'T run hand-written a a *3e Mepc FmIT9 :LC mntleotu r.cahoom.hee ctinIate ttoo.h dainot r.cIemu arsnrc - 05 : ts R r t eM 4) r:A - E fTed*402JN02 ormr n - Oadse rmJMCE oA vg maei ra LIye o 2.Ihg asee at p1beoerarspeamp eco ai/cb idstoflk d t 14u $7ff40-$7e000= $1f40 ..with no success. What am I overlooking? * adding this 11 hours later * Found the problem by disassembling the module. While the source code contained "sta $ff40", meaning "store A at extended address $ff40" RMA )v 1.0) was assembling it as "sta <$40", store A at $40 in the direct page. One must FORCE extended addressing, e.g., sta >$ff40. I call this a bug. -jim -*- 30433 29-JUN 01:44 General Information OS9 for Atari ST From: JDBARNES To: ALL I wouldl like to find someone who is interested in OS9 for the ATari ST. The Microware systems Personal OS9 has received little attention in the US. I would like to find a viable way to run OS9 on my Atari ST so that I can evaluate its multitasking capaabilities. Unfortunately I have not been able to get it to boot up from my Syquest drive, which is where I would prefer to keep it for the sake of convenience. Interested parties should send MAIL to JDBARNES so that I can make a valid connection without having to wade through miles of CoCo stuff. We used to have a gur in Washington named Bill Bradty, but I could never get far along before he started telling how wonderful OS9 was on the CoCo. Bill is a nice guy and all, but it was hard for me to use his information to get any real work done. -*- 30437 29-JUN 23:26 Programmers Den real time clock From: XLIONX To: KDARLING (NR) Howdy Kev, Just how hard would it be to change the RTC from 10 to either 60 or 100 TPS. ? I know it would require a lot of module patching ((would it?)) . And, since I do not have a coco3 tech man, is the graphic display system totaly dependent on the system clock (ala coco2)? These may be usless oops useless questions but, it's been bugging me for quite some time now. Would there be any smoothing in the task switching if the clock was set for 60 or 100 TPS ? ? ? -THX as allways -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS) -XLIONX (DELPHI) -mwf@SANDV -*- 30440 29-JUN 23:51 Programmers Den RE: real time clock (Re: Msg 30437) From: OS9UGVP To: XLIONX Mark, I'm gonna jump in here because if you want smoother (well, more often, anyway! ) task switching then grab my 'ELIMSW.AR' file from the device drivers data topic (I think thats where it is) here. It has the same 60 ticks per second as all CoCo clock modules (that I know of) use, but features 2 ticks per time slice (30 task switches per second) instead of 6 ticks per time slice (10 task switches per second). The ARchive contains versions of the Clock module for 50 Hz (works out to 25 task switches per second... just thought I'd correct my generalization) and 60 Hz software clocks, as well as versions for the Eliminator's RTC. And its not a useless question at all... I much prefer 2 ticks per time slice over 6. I even tried 1 tick per slice, but it bogged things down too much with all the overhead of task switching that often. Bruce -*- 30474 2-JUL 18:18 Programmers Den RE: real time clock (Re: Msg 30440) From: XLIONX To: OS9UGVP (NR) Ok, this sounds wonderful...but, does it have all the same fixes that the clock modules in smouse.ar have (serial mouse driver archive)??? The fixes in smouse.ar clock.60hz all but fixed my RS232 bugs. -Thanks Bruce, -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS) -XLIONX (DELPHI) -mwf@SANDV p.s. When is Shell 2. or whatever going to happen...and will I need to use my hands for shell access or are you going to sell some sort of Bio-Interface for it . Look ma, no hands OS9!!! -*- End of Thread. -*- 30443 30-JUN 11:36 Patches Dynacalc Patches From: OS9BERT To: ALL Does anyone out there know of a patch or series of patches I can use to make Dynacalc (c) work under OS-9 Level II with different terminals? For example, in addition to my monitor I have an H19 Heathkit terminal and a Televideo 925 terminal. The screen control codes need to be modified in order for Dynacalc to work. Someone a long time ago said there was such a set of patches on the other system (Compuserve). I have yet to see it show up here on Delphi. I have a word processor that supports these terminals (Stylo-graph), it would be nice to be able to do spreadsheet stuff as well. Thank you. And have a 5th on the 4th!!!! Bert Schneider P.S. If there are any OS-9 folks in Colorado, please let me know. I feel like the Lone Ranger here in Colorado Springs (very defense oriented and they use MS-DOS .... mess-dos!). -*- 30444 30-JUN 12:03 Patches Coco Max Joystick From: KINGTRENT To: ALL Does anyone know if there is a hardware fix to allow the hardware joystick interface for Coco Max to run on the Coco 3? I don't care if the sofware doesn't work, but would like to be able to use the thing for something. Need detailed instructions, since I'm no hardware expert. I have converted a Rs232 pak to run at a different address, so if its not TOO dificult, I think I can manage it. - Mike -*- 30451 30-JUN 18:55 Grits & Gravy _strass() function From: POLTERGEIST To: GREGL X cross referencer, and I noticed that structure pointers are passed thusly: *px = *py for example. The C compiler returned an improper struct or union usage message. The documentation for the _strass() function mentions that you can copy structures byte per byte using it. With the count requirement, is this the total mantissa value for the variables in a structure? -*- 30460 1-JUL 02:00 Grits & Gravy RE: _strass() function (Re: Msg 30451) From: GREGL To: Pst part of your message has been chopped. But, it seems you are trying to use _strass() to copy the contents of a structure. I'm going to assume that you are using a structure (ie. struct mystruct this_struct) and noietatcr eyai sa(a*,h r,ncn; u .tny rate, you can see that _strass() requires two pointers to "character arrays" and the number of bytes to copy. To copy a structure, use the following: struct mystruct new_struct, old_struct; _strass((char *) &new_struct, (char *) &old_struct, sizeof(mystruct)); First, we must use a pointer to the structure so we use the "address of" function (&new_struct and &old_struct). Second, _strass() can't deal with "structures" so we typecast the structure to a pointer to char. Notice that in the original K&R compilers it is common to use char as an unknown dat type. ANSI C and C++ fix this by allowing you to use a void data type, which means that the actual data type may be anything, including structures. And finally, we tell it the number of bytes to copy by using the sizeof() function to obtain the number of bytes in the structure. -- Greg -*- 30470 1-JUL 23:45 Grits & Gravy RE: _strass() function (Re: Msg 30460) From: POLTERGEIST To: GREGL Ok, that's one way, but how about pointers to structures? Would those work the same way? And, would _strass() works with union to union, or struct to union, and vice versa? -*- 30471 2-JUL 00:03 Grits & Gravy RE: _strass() function (Re: Msg 30470) From: GREGL To: POLTERGEIST Brian, Well, _strass() will work with any complex data type you give it providing the structure or union is valid and that you give it the proper addresses. Use something like this for pointers: swap(s1, s2) struct one *s1, *s2; { struct one *temp; temp = malloc(sizeof(struct one)); _strass(temp, s1, sizeof(struct one)); _strass(s1, s2, sizeof(struct one)); _strass(s2, temp, sizeof(struct one)); free(temp); } Using pointers isn't that much different. The real difference is that you don't have to use the address-of (&) operator with pointers. If you are using a union, you can use the following code: test() { union { long l; int i[2]; char c[4]; } u; _strass(&u, &original, sizeof(union u)); } You can also use it with strings, integers, etc. Keep in mind that both the source and destination *must* be the same size and you should give the size of the objects being used with the sizeof() function. There is one catch, however. Be sure to use the structure in the sizeof() function and not the pointer. Otherwise, you'll copy two bytes instead of the entire structure. Take these two examples: struct { int i; long l; char string[40]; } *p; _strass(&new_p, p, sizeof(p)); _strass(&new_p, p, sizeof(struct p)); Although it's not shown, we declare new_p to an identical structure, but new_p isn't a pointer. In the first case, we copy from p to new_p with the number of bytes given in sizeof(p). We have declared p to be a pointer and the size of a pointer is 2 bytes. Obviously, this structure contains more than 2 bytes. We fix the problem in the second example by telling it to copy the number of bytes defined by sizeof(struct p). Here, struct tells the compiler to use the size of the structure and not the pointer. -- Greg -*- 30472 2-JUL 00:27 Grits & Gravy RE: _strass() function (Re: Msg 30471) From: GREGL To: POLTERGEIST Brian, I nearly forgot the most important part. When you want to get the size of a structure or union, always use the "model" and not the variable. For example, when you declare a structure, the symbolic names associated to the structure are as follows: struct MODEL_NAME { type member_name; type member_name; } variable_name; The structure can contain as many members as you desire that are associated by type (char, int, long, float, etc.) and the name given to the member. (For example, int count; long sector;) The variable name given to the structure is used to access the members within the structure, such as mystruct.count or mystruct_ptr->count. But the "model name" is used by the compiler to associate the actual structure definition. For example, you can declare another, identical structure by using: struct MODEL_NAME another_struct; The "model name" is used as the template to determine the size of a structure and to declare other structures. So when you need to determine the size of the structure, use: sizeof(struct MODEL_NAME) Extract the following source, compile and run it. It'll help drive some of this home: main() { struct MODEL { int i; long l; char *string[40]; } var, *var_ptr; printf("Size of var is: %d\n", sizeof(var)); printf("Size of var_ptr is: %d\n", sizeof(var_ptr)); printf("Size of MODEL is: %d\n", sizeof(struct MODEL)); } Notice that you cannot use sizeof(struct var) or sizeof(struct var_ptr) because they are simple variables, they aren't structures. Also, keep in mind that structures and unions are identical. (They are?) Pretty much, yes. The difference is that the members in a union overlay each other so you can access the same memory address with different variable types. -- Greg -*- End of Thread. -*- 30452 30-JUN 19:13 General Information 1 meg observations From: POLTERGEIST To: DISTO Tony, I've noticed that on your one meg kit's sattellite board seemed to feature a way to socket a 6809 into it, thereby the 6809 would be on top of the sattellite board, which would then plug into the CoCo 3 motherboard. I had some trouble installing the sattellite board into the CPU connector, since the legs kept coming off, even though I soldered it carefully in. I'd like to see that option implemented in future releases. And, another tip to use with the kit: If you do not use a TV with your CoCo 3, you may want to remove the RF box inside the system. I had this part interfere with the installation of the second one meg board. I also had to trim a little bit off both 512K boards in order to get them to not be so tall and prevent the case from being closed. This was the only fly in this ointment. But, everything seems to work OK. -*- 30478 2-JUL 19:50 General Information RE: 1 meg observations (Re: Msg 30452) From: DISTO To: POLTERGEIST I'll keep it in mind. -Tony. -*- End of Thread. -*- 30459 1-JUL 01:56 General Information Buyer Beware! From: KMTHOMPSON To: ALL ******************************* W A R N I N G *************************** A Las Vegas company which I will not name here so as not to infringe on anyone (or to hamper the FBI), has started a national promotion by sending out several Certificate of Award Guarantee forms to people across the country. I got one myself, that read as follows: Congratulations! We are pleased to notify you that as part of our nationwide promotion you are to receive one of the following awards. 1. 1990 Lincoln Town Car 2. Genuine 2 carat total weight sapphire and diamond necklace 3. $5000.00 in cash 4. A vacation for 2 to the Bahamas 5. Sony video camcorder and VCR. Not that I hadn't got these in the mail before, it is just that never had the lowest item on the list been worth $1000 or more. So, I called the company to find the 'catch.' Well, there certainly was one. You had to buy their $599 "Water Purification System that easily attaches to your kitchen sink." Not only did I not really want a Purification system, but I really didn't want a $599 one. ($39.95, maybe...) Anyway, I had still thought that maybe it would be worth it, because the prizes _could_ pay for the machine, for example, if you got $5000 in cash. Big IF. The lady I talked to at the company said "this is the way we advertise, we promote the product this way, and if you like it you'll tell your friends. We don't pay for TV advertising, we spend that money on this promotion." Well, the reason they don't advertise on TV is because they are what the FBI calls a 'Boiler Room' operation. The company that actually makes the product and charges you for it may be real, but the promotions department moves around, and doesn't pay up on the 'Awards.' Then again, the company may only 'sound' big, by putting you on hold to transfer you 'upstairs' to someone in _the same room_ where they may also make the product. I don't know this, but I did check up on the company (unfortunately AFTER giving my credit card # to them. I've never done that before, but the scam was all too good, and I'd been had. I _know_ better than to give a Credit Card # to a company I know nothing about, and I have no idea why I did it at that time.) After calling the Las Vegas police, and being told the company was a fraud, I called them back and cancelled my "order" that should have never been made. Hopefully it will all work out, and I'll soon find out. Con men (and women) are all too good. You can never tell, and so here is one more "Buyer Beware" scenario for you to learn from. I am learning the hard way and thought I might help someone else out. No matter HOW good it sounds, you need proof, in writing. Don't give your credit card over the phone, unless it's JCPenny, or Sears, or Kenneth-Leigh . I KNEW not to do that, I had known for years. But in a situation where I was being conned by one of the best actresses in the Boiler Room, her lies seemed all too real, and I believed them. (You must also understand it was early in the morning when I called--before work--and I wasn't quite awake. The police fraud report sure woke me up later in the day, though.) The moral of the story is beware. The world is full of some really nice people--I've met several of you here on Delphi. But it can also be a Water-Purified Jungle out there. --Mr. ]), Will you offer for $$$ (and how much) the full version of GFX2 that you are teasing us with now??? Can you be bribed (The Gods could be bribed ya know)??? Hows life in general for you these days? If not for $$$ when can we expect to see the FORUM version uploaded? -mark w. farrell -*- 30481 2-JUL 22:05 Device Drivers hardware From: N3FWE To: ALL I'm having trouble with my new Disto Harddrive and 232 adapter. In fact I'm using it right now. But it will now work with Osterm's autodial. I have the adapter with hard and 232 on one card. If I go back to my old system the single disto harddrive adapater and RS232 pak Osterms autodial works fine Osterm would not sense the modem connected with Delphi, I had to log on manually with Osterm. Also the new t2 driver would not go out to my other computer if it is hook up to the new 232 adapater but using the old T2 with RS 232 pak no problem. Thanks for any help Steve... -*- 30511 4-JUL 22:03 Device Drivers RE: hardware (Re: Msg 30481) From: TIMKOONCE To: N3FWE OSTerm directly looks at the serial port hardware for some things, including detecting if the modem is connected. Since the hardware is slightly different, OSTerm has some problems. That's why everything is supposed to be done through the driver! Unfortunately, there is no standard way to ask the driver whether the modem is on-line, or to ask the driver to send a break signal, etc, so it is necessary to go directly to the hardware for some things. - Tim -*- 30516 5-JUL 18:16 Device Drivers RE: hardware (Re: Msg 30511) From: DODGECOLT To: N3FWE Look in the 'PATCHES' database for a modpatch file for version 2.08 of OSTerm. Basically, it changes the address that OSTerm looks at for the serial port... Been so long since I have used OSTerm that I forgot I had a patch for it.... -Mike -*- End of Thread. -*- 30482 2-JUL 22:40 General Information SASI driver patch From: KSCALES To: ALL Just a note to any of you who might try the SASI CCHDisk driver patch I have uploaded to the database (currently under New Uploads)... You very likely may find that your "read" times using Bruce Isted's Megaread utility could jump by about 68 seconds. This is not an indication of major problems... it means that with this new driver, the Interleave (skip) factor becomes important, and you may need to reformat your drive (ouch) with a different interleave to get the full benefit. The old driver dedicated the 6809 to waiting for the data to start coming in, even if this took a seek and a disk revolution. The new driver releases the 6809 to do other things if the data takes a while to start coming. If your interleave is not set properly, you will hit this condition. I found an interleave of 3 to be about right for a ST225 with a WD1002 controller. Good luck... / Ken -*- 30484 2-JUL 23:16 General Information VDG games crashing From: POLTERGEIST To: OS9UGPRES Kev, I'm having serious problems getting my copy of FS2 and Sub Battle simulator to boot on my system. I have the right modules in memory, but should I also have GRFINT.IO installed as well? A friend of mine has both WindInt and GrfInt, and Flight Simulator 2 seems to work just fine I also have VDGInt installed. Now, when I use Zack Session's loader programs, BOOM! If I fire up FS2 from the command line, it will go as far as the control panel, then crash the whole system. I do have some patches to some modules for use with Gshell+ and I also have Shell+. Would it be smart to add GrfInt to my bootfile just to be safe? -*- 30493 4-JUL 12:48 General Information RE: VDG games crashing (Re: Msg 30484) From: DODGECOLT To: POLTERGEIST You should only require WINDINT and VDGINT for those programs. DO NOT have both WINDINT and GRFINT in your boot. WINDINT does everything that GRFINT does and more... Sme programs (I SBS is one of them) are hardcoded to look for /term and use that for their VDG screen. This could also cause problems.... -Mike -*- 30637 10-JUL 02:56 General Information RE: VDG games crashing (Re: Msg 30484) From: OS9UGPRES To: POLTERGEIST You should have windint and vdgint in your boot... no grfint. Actually, I'd suspect that along the line you either lost your Init module with the interrupt number patch, or you've forgotten to also add some of the custom drivers those games require... agivirqdr, etc. Still having troubles? - kev -*- 30661 11-JUL 21:36 General Information RE: VDG games crashing (Re: Msg 30493) From: POLTERGEIST To: DODGECOLT After I installed GrfInt, Flight Simulator 2 and Sub Battle worked with Zack Session's multi vue loading programs. Funny that WindInt wouldn't work with those programs. -*- 30662 11-JUL 21:39 General Information RE: VDG games crashing (Re: Msg 30637) From: POLTERGEIST To: OS9UGPRES (NR) Kev, I'm using the Init module that Bruce Isted supplied with his Eliminator kit, and after I installed GrfInt, the games worked. I do have the custome drivers installed. I had problems BEFORE I installed GrfInt with WindInt. Guess I better check out the patch for init. I did have the FS2 drivers installed, and before I installed GrfInt, boom! The programs wouldn't work, and I'd have to reboot the whole system. I still have problems before I install GrfInt. --Brian -*- End of Thread. -*- 30486 3-JUL 21:40 Telcom Alpha Technologies From: COCOJOHN To: ALL Hi all! I'm sort of NEW to OS9. I bought Warp 1 at the last Chicago Rainbowfest and I only can log on a couple of boards using Warp 1. I cannot use Warp 1 to log on Delphi. The use of Warp 1 gets me. I have to change parimeters each time I log onto a different system. I don't think the auto-dialer file stores hings like that other then the BBS you call and the number. I'm kinda sorry I bought Warp 1, as I also have a problem using the conference feature on it. I log onto a BBS that features 16 lines and the conference that goes on....the chat on Warp 1 breaks up your message you are typing in while the screen is scro lling away. I prefer a terminal program that has a seperate window like The Wiz! But it's funny, I cannot really use Warp 1 to just call any bbs or Delphi. The screen is messed up. One board the screen prints wide like no line feeds, etc... and runs off. I call Delphi via telenet and I get nothing but garbage on the screen plus for some odd reason I get logged on at 1200 baud. I hope I am doing something wrong. I'm sure Warp 1 works much better then I think it does. Also does anyone know of any OS9 terminal programs that will let you select whether you want to add Line feeds to a text file before uploading on a BBS? CoCoJohn ok -*- 30489 4-JUL 00:05 Telcom RE: Alpha Technologies (Re: Msg 30486) From: NES To: COCOJOHN John, download supercomm from the tel communications area, its the best PD program for os9 well that's my opinion. Then trash the Warp 1, Some of the Best programs I have used have been shareware programs that I have downloaded for here. also try the text editor call "ED". Eric -NES on delphi or my BBS 704-822-1337 300-2400. -*- 30534 7-JUL 00:04 Telcom RE: Alpha Technologies (Re: Msg 30489) From: COCOJOHN To: NES Thanks Nes- Hey thanks for also posting your BBS number. I'll give it a call this weekend! CoCoJohn -*- End of Thread. -*- 30487 3-JUL 22:42 Device Drivers RAMdisk From: FRANCALCRAFT To: ALL I have some questions about the RAMdisk (192K) that comes in the OS9 Development System. First, why doesn't FORMAT work on it? Second, if one patches the descriptor so that the number of sectors is $2D0 instead of $300, why can one only backup to it as far as sector $2BF? What happened to the last 16 sectors? Third, is there any way to fix this so one can use backup with it? -*- 30490 4-JUL 11:53 Device Drivers RE: RAMdisk (Re: Msg 30487) From: MRGOOD To: FRANCALCRAFT As far as the RAMDISK goes, you don't need to format it. As soon as you chd to it, it becomes active (as long as the device driver and descriptor are in memory). -*- 30494 4-JUL 12:52 Device Drivers RE: RAMdisk (Re: Msg 30490) From: DODGECOLT To: FRANCALCRAFT Actually, you ought to INIZ the ramdisk, but you don't hve to format it. To change the size of the Ramdisk, you have to change the number of sectors BEFORE you use it/iniz it. If you do it afterwards, then you have to DEINIZ it and then INIZ it to make the chage take effect. NOTE: this will erase the contents of the ramdisk! -Mike -*- 30521 6-JUL 00:01 Device Drivers RE: RAMdisk (Re: Msg 30494) From: FRANCALCRAFT To: DODGECOLT I know you don't have to format that ramdisk, but when I tried it anyway, it didn't work. The question is, why? As far as changing the number of sectors goes, I changed that right on the disk before loading the descriptor and found that BACKUP wouldn't write to the last 16 sectors that I thought should be there. What do you have to do to that ramdisk to get it so that you can backup a 40 track floppy disk to it (single sided)? -*- 30525 6-JUL 05:58 Device Drivers RE: RAMdisk (Re: Msg 30521) From: DODGECOLT To: FRANCALCRAFT I am not sure what you have to set the ramdisk up as for the backup (I've got a hard drive, so I haven't needed to do much in the way of disk shuffling....) I will play around with it a bit today and get back to you... -Mike -*- 30546 7-JUL 14:52 Device Drivers RE: RAMdisk (Re: Msg 30521) From: TIMKOONCE To: FRANCALCRAFT The Dev Sys Ramdisk does have a known bug: The total Ramdisk size must be an exact multiple of 8k. Otherwise, the last needed block of memory won't get allocated. That makes it pretty much impossible to set it up to be able to exactly backup a floppy disk to the Ram disk. I beleive there may be other Ramdisk drivers for wich this will work, though. I know CIS has a couple. If you only have 512k, you can try Kev Darling's Rammer ramdisk, which is here. - Tim K -*- 30588 8-JUL 11:33 Device Drivers RE: RAMdisk (Re: Msg 30546) From: FRANCALCRAFT To: TIMKOONCE Rammer does work. I have it already, and like it. If I go to 1 meg, is there any way I can patch Rammer to work with it? -*- 30593 8-JUL 15:14 Device Drivers RE: RAMdisk (Re: Msg 30588) From: ZACKSESSIONS To: FRANCALCRAFT According the Kevin Darling, the author of both rammer and mega, that's a "no can do". It is because rammer "cheats" in the way it allocates or accesses memory (I forget exactly what). As far as I know the only ramdisk driver which is "guarenteed" to work with the one meg upgrade is the Dev Pack driver. Zack -*- 30599 8-JUL 17:39 Device Drivers RE: RAMdisk (Re: Msg 30593) From: RADARBUZZ To: ZACKSESSIONS Zack, Well, maybe you can straighten me out here. I never was able to get the Dev pack, so I'm using the VDD driver from the database here that is supposed to be a direct replacement for the Tandy driver. Now it works alright, but if you try to set one up for greater than 512K the computer crashes. Any Ideas? -Jeff -*- 30600 8-JUL 17:54 Device Drivers RE: RAMdisk (Re: Msg 30599) From: DODGECOLT To: RADARBUZZ I think the VDD driver is hardcoded to only allow 64 blocks per ramdisk... Since 512k worth of ramdisk = 64 blocks, any more will overwrite other important info and causes a crash.... -Mike -*- 30607 8-JUL 19:39 Device Drivers RE: RAMdisk (Re: Msg 30599) From: ZACKSESSIONS To: RADARBUZZ Sorry, Jeff, solving a problem of that nature is beyond the scope of my knowledge. I see that there is a reply to your message, so maybe someone else may spot it and offer some aid. One idea is that, you obviously have the one meg upgrade, I don't think "things" can span from one 512K back to the other, like all of the 32K fo a type 8 window has to be in one bank or the other. Zack -*- 30613 8-JUL 20:33 Device Drivers RE: RAMdisk (Re: Msg 30607) From: TIMKOONCE To: ZACKSESSIONS Zack, Only reason why a window can't span sections is because of hardware limitations on the video handling. That's not an issue with Ramdisks. It's not even necessary for the Ramdisk memory to be consecutive blocks, so even that's not an issue. Assuming it doesn't cheat, there's no reason why a Ramdisk driver couldn't use as much memory as there is available. - Tim -*- 30617 8-JUL 23:06 Device Drivers RE: RAMdisk (Re: Msg 30613) From: ZACKSESSIONS To: TIMKOONCE So Mike Sweet's explanation seems feasable, then, ie, VDD can only handle 64 blocks. Zack -*- End of Thread. -*- 30488 4-JUL 00:01 General Information The Forth From: KNOT1 To: ALL Happy Forth everyone! -Jamie (KNOT1)- -*- 30491 4-JUL 11:53 General Information RE: The Forth (Re: Msg 30488) From: MRGOOD To: KNOT1 You do mean, Happy FOURTH, no? -*- 30515 5-JUL 04:42 General Information RE: The Forth (Re: Msg 30491) From: KNOT1 To: MRGOOD OOOOOOPS! Yep, sure did. Me spelling ain't no good, yes? -Jamie (KNOT1)- -*- 30518 5-JUL 21:45 General Information RE: The Forth (Re: Msg 30515) From: MRGOOD To: KNOT1 Well, hope you had a happy fourth, regardless of spelling! Hugo -*- End of Thread. -*- 30498 4-JUL 15:07 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 27210) From: JASONEABY To: DISTO Tony, I apologize for the long delay. I had finacial troubles and couldn't afford to run up anymore online charges. The number for Dove Computer is, (919) 763-7918. I hope this helps. Again I apologize. I would really like to upgrade to 1-Meg w/o sold ering. Jason Geez, I hate this editor. And I don't have my VMS EDT editor reference handy either, oh well. -*- 30501 4-JUL 18:04 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30498) From: ZACKSESSIONS To: JASONEABY EDT has "on-line" help at the asterisk prompt. Just enter HELP and press ENTER (or RETURN). Of course, as with most VMS type help, you need toave an idea of what you need help ON to get some useful information out. Zack -*- 30502 4-JUL 18:57 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30501) From: JASONEABY To: ZACKSESSIONS I tried help, it only gave me something that didn't make much sense. I know how screwy VMS is on its help because Millersville University has several VAX'es and I have to program on a MicroVAX 3600 for my CS classes. -Jason -*- 30504 4-JUL 20:07 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30501) From: DWHILL To: ZACKSESSIONS That's been one of my complaints about the online editors here: help is there but isn't much help when you're constantly switching back and forth between the task and the help menus. Delphi needs to make a downloadable tutorial available so we can have our own references at hand to study before we attempt to use the darn thing. --Damon -*- 30506 4-JUL 21:17 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30504) From: CHYDE To: DWHILL Yyou could of course by a Delphi manual. They have a very good description of the editing commands. They just finished a new edition which is availabel now. Just a thought. -*- 30513 4-JUL 23:30 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30504) From: ZACKSESSIONS To: DWHILL There is the Complete Delphi Guide. Z. -*- 30514 5-JUL 00:11 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30506) From: DWHILL To: CHYDE True, but I'd like to have a up-to-date reference online that's more helpful than what's currently available. --Damon -*- 30561 8-JUL 00:07 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30502) From: RAGTIMER To: JASONEABY Say, ever notice that there is NO help available at the MAIL prompt? No way to get a list of valid commands! There's help at the DMAIL level, but not at MAIL. AT least I haven't rubbed the genie's lamp the right way. Word is that Delphi's Mail system is straight raw VMS. Thank God for UN*X. -*- 30564 8-JUL 00:35 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30561) From: JASONEABY To: RAGTIMER Haven't tried to use mail yet, but I can believe it because I have used VMS mail. VMS mail goes something like this, type send with a user name and it'll prompt you from there. Heck I don't even think you have to use a name. -Jason -*- 30566 8-JUL 00:39 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30564) From: RAGTIMER To: JASONEABY Yes, just sending mail is easy enuf. But after reading a message I wanted to reread it. Type REREAD, got some generic "syntax error", but there's no way to get a list of commands. I do have that Delphi manual somewhere, but I hate rooting in a book while my computer taxi meter is ticking (at least this isn't CI$). -*- 30568 8-JUL 00:59 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30561) From: GREGL To: RAGTIMER Mike, From the MAIL> prompt you can type HELP for a list of the commands you can use. It'll put you into the generic help system where you can follow a chain of commands and options to find what you are looking for. It ain't the best in the world, but it works. -- Greg -*- 30646 10-JUL 21:55 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30568) From: RAGTIMER To: GREGL OK -- I cuda sworn I'd tried HELP. Maybe I did, and got disgusted with that generic HELP system. There should me a list of MAIL cmds, as there is at the DMAIL level and inside its WORKspace. -*- 30653 10-JUL 23:20 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30646) From: GREGL To: RAGTIMER (NR) Mike, No argument from me. One of the biggest complaints we get is on the mail system used. I keep hoping that the gurus behind Delphi will write their own version of Mail and toss DEC-Mail. But I don't know if they are legally bound to use DEC-Mail or not. It's fairly powerful but it's not the easiest thing to use, that's for certain. -- Greg PS: A problem I just thought of is that Mail is used quite heavily to send mail to other nodes. For example, you commonly send mail to users of Delphi/Boston by using the BOS1A or BOS1B nodes. But you can also send mail to Delphi/Miami by using MIAIA, Delphi/Argentina, Delphi/Kansas City, etc. Just one of the advantages of using the VAX Cluster. -*- 30658 11-JUL 18:11 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30653) From: ZACKSESSIONS To: GREGL Actually, Greg, the VAXcluster isn't what gives us the ability to send mail to other nodes, it's DECnet. Zack -*- 30690 13-JUL 21:01 General Information RE: One Megabyte CoCo-3 !! (Re: Msg 30514) From: CHYDE To: DWHILL (NR) their own. Chris -*- End of Thread. -*- 30519 5-JUL 22:34 Utilities PCDos From: JASONEABY To: ALL Help! Is there anyway to use the PC-Dos utility with the Disto No-Halt CC3Disk Driver? When I try to use it, I get not a Dos disk. Of course the problem may be the fact that it was formatted for 360K on a 1.2 Meg drive. Those 1.2 Meg drives are notorious for screwing up the 360K format. Any help will be appreciated. Thanks. -Jason -*- 30526 6-JUL 06:01 Utilities RE: PCDos (Re: Msg 30519) From: DODGECOLT To: JASONEABY Unfortunately, the SC-II hardware only buffers the first 256 byts of a sector. This works fine for OS-9 disks, but MS-DOS disks use 512 bytes per sector. The only solution at present is to have a second boot disk that uses the old HALT mode driver instead of the Disto driver... -Mike -*- 30545 7-JUL 14:49 Utilities RE: PCDos (Re: Msg 30519) From: TIMKOONCE To: JASONEABY The simple answer is: "No, the PCDOS utility will not work with the no-halt drivers." To use it, most people keep a second boot disk with the standard halt drivers just for use with PCDOS. - Tim -*- 30554 7-JUL 22:27 Utilities RE: PCDos (Re: Msg 30526) From: JASONEABY To: DODGECOLT Thanks, I have a couple of old boot disks lying around, so I'll try the patch on them and hope it works. Should have expected it to be something like that. That's what you get for using the latest and greatest technology. -*- End of Thread. -*- 30522 6-JUL 00:05 General Information Double-sided boot disks From: FRANCALCRAFT To: ALL How does one make a double-sided boot disk for OS-9, starting from a single sided system? I have tried all sorts of cute tricks to try to accomplish that, but nothing works. -*- 30528 6-JUL 21:03 General Information RE: Double-sided boot disks (Re: Msg 30522) From: FRANCALCRAFT To: ALL Perhaps I should rephrase. How does one make a double-sided boot with COBBLER? CONFIG works fine, but I couldn't get COBBLER to make a workable boot on a double-sided disk. -*- 30530 6-JUL 23:08 General Information RE: Double-sided boot disks (Re: Msg 30528) From: ZACKSESSIONS To: FRANCALCRAFT Let me know your disk configuration, ie, how many floppies, any ramdisk, or hard drive, and I'll give you the exact commands to do it. Zack -*- 30543 7-JUL 11:14 General Information RE: Double-sided boot disks (Re: Msg 30528) From: DRSPOON To: FRANCALCRAFT I had one heck of a time getting a double sided boot disk at first too!! I played around with changing the descriptors from single sided to double sided and everything that I could think of on the single sided boot disks I had and nothing worked. The ultimate solution for me was to FORMAT the destination disk first as double sided. I could not use the straight FORMAT command, I had to specify 2 sides. Seems like if I just used FORMAT without any modifiers the system assumed that I wanted to format the new disk just like the one I used to boot up with, which at the time was a single sided disk. (Thats all I had!!) Once I had a suitable double sided boot set-up on the single sided disk, I used the DSAVE route to copy it to the newly formatted double sided disk and every thing worked fine!! Once I had the original double sided boot disk, then every disk I formated with that disk also came out formatted double sided WITHOUT having to use any modifiers. I still don't know WHY I had to do all this, and WHY no one else seemed to be having that trouble, but it worked for me. This may not have anything to do with your current problems, but I thought I would report it. Maybe someone else can explain the WHYs for me. Probably something simple that I was not doing at the time. Seems like the key is how the disk you originally booted up on is configured. That seems to get locked into the system's corporate memory and is used until you tell it to do something different!!-Don Spoon- -*- 30586 8-JUL 11:27 General Information RE: Double-sided boot disks (Re: Msg 30530) From: FRANCALCRAFT To: ZACKSESSIONS With COBBLER? I did manage to make a double-sided boot with Config, but not with Cobbler. The strange thing is, I really couldn't see any difference in the way the pieces of the boot were arranged between the two. I have one double-sided floppy drive, and one single-sided, one Ramdisk, n hard drive. -*- 30587 8-JUL 11:31 General Information RE: Double-sided boot disks (Re: Msg 30543) From: FRANCALCRAFT To: DRSPOON I used a sneaky trick to get around the format problem. I used DMODE. I just did DMODE /d0 sides=2, formatted a disk, which came out double-sided, then tried to COBBLER to it. The result wouldn't boot. I next tried Config with a double sided descriptor for that drZ8e,ahZYHMU1Q"%==Q9"+HUMQ%=9JM1:!e"%9"5R4uKK[I:=I-}j$(-*- 30590 8-JUL 12:35 General Information RE: Double-sided boot disks (Re: Msg 30587) From: DRSPOON To: FRANCALCRAFT I'm getting in over my head, but here's some thoughts. Seems like I recall that Cobbler just writes whatever boot information is in memory from the last boot- up, unless you have changed it. Maybe the info you wrote to your new double- sided disk was single-sided info?? I also seem to recall that several years ago many people reported troubles with Cobbler and the GURUs were advising not using it. I never got the "real" reason. I think it WOULD work, but had several nuances that the casual user would not know about, and were taken care of in CONFIG automatically. It is not a "user friendly" command!! Neat about the DMODE!! I'll add that to my library of "things I'll make sure to teach my kids". Thanks Don Spoon -*- 30592 8-JUL 15:09 General Information RE: Double-sided boot disks (Re: Msg 30590) From: ZACKSESSIONS To: DRSPOON I never use cobbler or config, because to me it's simpler to use os9gen, and I feel I have more total control. The only modules for OS9Boot which come from memory are REL, Boot, and os9p1. when using os9gen. When using cobbler, everything comes from memory. So, how I did it was to build a bootlist file which contained the DS file decriptors. dmoded the target disk for 40trk, DS, formatted it, and the OS9Genned the boot. Can't really say WHY cobbler failed in a similar manner, but like the old joke, I told the doctor it hurt when I raised my arm, so he told me not to do it! Zack -*- 30615 8-JUL 22:06 General Information RE: Double-sided boot disks (Re: Msg 30592) From: RADICAL To: ALL Just set up a doubleside drive 0 today. Previously had a doublesided drive 1, so things worked smoothly. Dmode /d0 sid=2 cyl=28 dmode /dd sid=2 cyl=28 format a doublesided disk, cobbler the os9boot, then dsave /d0 /d1 ! shell This gave me a working copy, which booted first try on a doublesided disk. If you don'd have two drives I think dsave -s should do the samething on a single drivwve. Len -*- 30622 9-JUL 14:03 General Information RE: Double-sided boot disks (Re: Msg 30590) From: FRANCALCRAFT To: DRSPOON (NR) If by "single-sided info" you mean a single-sided device descriptor for the drive, I checked that with DED and changed it before trying to boot. Yes, I did verify the module afterwards (to forestall the next question). Cobbler still works like a charm for doing single-sided boots. -*- 30635 10-JUL 01:08 General Information RE: Double-sided boot disks (Re: Msg 30622) From: RADICAL To: FRANCALCRAFT Do you have the dmode command? If not be sure to download it from the database. You can then use it to change the discritors for the drives to cyl=28 sid=2 thhat creates a doublesided drive. In the case of drive 0 the command would be :dmode /d0 cyl=28 sid=2. Then format, and cobbler a new disk, and dsave /d0 /d1 ! shell. You should end up with a bootable doublesided disk once you are done. Len -*- 30645 10-JUL 20:23 General Information RE: Double-sided boot disks (Re: Msg 30635) From: FRANCALCRAFT To: RADICAL I have DMODE. I used it. Cobbler didn't work, however. Perhaps that was because I booted up from a single-sided disk? Config worked fine. -*- 30654 11-JUL 00:58 General Information RE: Double-sided boot disks (Re: Msg 30586) From: DCJR To: FRANCALCRAFT The catch with cobbler is that it makes an EXACT copy of the OS-9 kernal you have in memory at the time you call it. This includes any patches you've made since you booted up, and any dmode or xmode commands you've issued. If you want to make a double-sided boot disk, the catch is first you have to boot from one! Then, don't forget to create a CMDS directory with shell and grfdrv in it. -*- 30656 11-JUL 02:07 General Information RE: Double-sided boot disks (Re: Msg 30654) From: RADICAL To: DCJR I booted from a single sided disk. Dmode /dd cyl=28 sid=2 Dmode /d0 cyl=28 sid=2 Then cobbler to a blank doublesided disk, and dsave the bootdisk. The resulting disk booted with no problems. Len -*- End of Thread. -*- 30524 6-JUL 03:05 General Information Atlanta CoCoFEST From: DAVEMYERS To: ALL *** ATLANTA CoCoFEST *** October 6-7,1990 Holiday Inn Northlake As you may know, the traditional Fall gathering of CoCo enthusiasts has been cancelled...BUT, you can make plans NOW to join your favorite CoCo vendors, online pals, and CoCo fans from far and near at the 1s before you buy" those items yayryo ->noco ri Wrusshs dt edgCo prs.orn N esoCCitrt -- r hnstwnvub orrz,cueyf aiian nosnh taaCptroiy -Tepouiyotnuwtdnsdooot d adr t A!---Flwhpn nwthnesunhdesfCotTct otetatCCETa vlbeO pily.n,aa er ns.h rt2 ele to reserve onsite hotel rooms through us (at the special show price of $49/nite + tax, single or double) will receive a FREE one-day admission for each night's lodging purchased! To recieve the special room rate, your reservation MUST be placed through CoCoPRO! For specially discounted airfare and car rentals (starting at $17.95/day with unlimited mileage), contact Lisa at CoCoFEST affiliate Travel Bank of Atlanta - 1-800-477-9191. For tickets, hotel reservations, or further info, contact us at CoCoPRO! - 1-313-481-DAVE <3283> (1-8 P.M.. 7 days). Modem users may place ticket/room orders using VISA or MC, by calling our BBS at 313-663-6207 (3 lines, 7-E-1, 3-1200 on all lines). -*- 30527 6-JUL 19:10 General Information shell+ 2.1 From: CAPTSWOOSH To: ALL hey gang can some one tell me how to configure shell+ 2.1 ?? How do i create the new boot?? how do i save my old modules... HELP!!!! ron the novice. i mean real novice..... -*- 30529 6-JUL 23:06 General Information RE: shell+ 2.1 (Re: Msg 30527) From: ZACKSESSIONS To: CAPTSWOOSH Configure shell+ 2.1? Save old modules? Huh? Yeah, I guess you are a novice? Shell+ does come with a doc file which describes how to install it. Basically all you replace is your old shell module with the new shell module, that's it. Now, your "stock" shell module has a fwe commonly used OS9 modules "merged" with it. That's why when you boot up and do an MDIR command, you see a few extra modules. Those modules are also in the CMDS directory on the main OS9 disk in individual files. Just merge those modules with the new shell module with shell+. Be sure to set the execution attribute to the newly created module which contains shell+ and the other utils so you don't see the "OS9 BOOT FAILED" message! Zack -*- 30547 7-JUL 14:59 General Information RE: shell+ 2.1 (Re: Msg 30527) From: TIMKOONCE To: CAPTSWOOSH Ron, The easy way (which doesn't quite do everything you'll eventually want) is to: rename /dd/cmds/shell old_shell copy shellplus /dd/cmds/shell attr /dd/cmds/shell e pe First, rename the "old" shell file to something different, then copy the new shellplus into your CMDS dir, then give it execute privileges. There's no need to create a new boot, and you don't _really_ need to save any modules. The saving modules bit is a trick that more experienced OS9ers use to speed up their system by keeping common programs (dir, list, free, mfree, copy, etc.) in memory. If you just do what I listed, those commands won't be in memory, which will slow things down some, but it will still work just fine.,. - Tim -*- 30555 7-JUL 22:52 General Information RE: shell+ 2.1 (Re: Msg 30529) From: JASONEABY To: ZACKSESSIONS Zack, can you tell me why the Shell+ 2.1 docs tell you to keep the module size below 8k? I realize it has something to do with keeping it in an 8k block, but if I go over, will the shell take up 16k every time I start a new one? The way I interpret the Level II docs make it seem like it shouldn't, because of the multiple threading of a process. The 8k that it takes up now, I think, goes to data storage. Any help will be appreciated. -Jason -*- 30560 7-JUL 23:44 General Information RE: shell+ 2.1 (Re: Msg 30555) From: ZACKSESSIONS To: JASONEABY If the size of a merged multiple module file is larger than 8K and one of the modules is Shell, NO, each time you start up a shell, the process doen't take up the extra memory. The problem with going over 8K is that memory is allocated in 8K chunks and if you do go over 8K, then the difference in the final size and the next increment of 8K is totally wasted memory and can never be allocated to any process for use. Actually, the size of a merged multiple module file should not exceed 8K - 512, or 7680 bytes. Quoting from Kevin's book, the ideal size of a merge file is: (8K * N) - 512 where N ranges from 1-7. Zack -*- 30562 8-JUL 00:17 General Information RE: shell+ 2.1 (Re: Msg 30529) From: RAGTIMER To: ZACKSESSIONS Zack, do you know whether that well-meaning bug in Sell+ has been fixed? The one where every program is forked with at least 7K, as if the user had typed program #7K You probably have heard that this "feature" prevents large program (those that use all 8 of the 8K blocks) from running. Tis includes Ultimuse-III and some other well-known stuff, I forgot which. There is a patch to eliminate that feature, but I wondered if a newer version had come out with out it. Anyway, users should know about the problem. Thanks, mike k -*- 30565 8-JUL 00:38 General Information RE: shell+ 2.1 (Re: Msg 30560) From: JASONEABY To: ZACKSESSIONS Thanks, the docs gave a file size about what you said, I just rounded for convenience and forgetfulness's sake. I guess that means if I can get it it somewhere close to a 16k block, I'll be in business. Thanks again. -Jason -*- 30567 8-JUL 00:49 General Information RE: shell+ 2.1 (Re: Msg 30555) From: TIMKOONCE To: JASONEABY The actual concern, Jason, has to do with how Shell+ deals with certain things. In order to find out certain things about a program, Shell+ links the module into it's own address space. Since the module might be large, you want to make sure that Shell+'s address space has as large a hole as possible for the other module to fit into. Shell+'s data area takes up 8k, so the biggest possible hole is 48k, or 6 8k blocks. The only way to get that is if the Shell+ module is in the top block of memory, which requires that the total size be under 7680 bytes. For the newer Shell+, which is pretty big, I only merge in "load" with it (which is necessary if you want "load" to end up not taking up it's own 8k block, BTW), and merge other utils into separate files, each less than 8k. Those files get loaded by my Startup file. Seems to work pretty well. There are also some programs which link the Shell, which is another good reason to keep the Shell file under 8k. - Tim -*- 30570 8-JUL 01:36 General Information RE: shell+ 2.1 (Re: Msg 30567) From: JASONEABY To: TIMKOONCE That is the way I'm doing it now, although I have more than 'load' merged and have it under 7680. But this help has probably confused things even more. Zack says it doesn't matter and you say it does. Maybe I'll just have to stop being lazy and try it f or myself and see what happens. Either that or we should kick this up to a higher authority. -Jason -*- 30571 8-JUL 02:33 General Information RE: shell+ 2.1 (Re: Msg 30570) From: TIMKOONCE To: JASONEABY (NR) If you read carefully, Zack explained to you the reason why you want merged modules to come close to a multiple of 8k, so you don't waste memory. Since memory is allocated 8k at a time, you'd like to fill the memory that gets allocated. The bit about being 512 bytes short is a subtle point that I'll not go into right now. What I elaborated on is why the Shell file, in particular, should fit in just one block, which is due to the way the Shell does certain things. To summarize: In order to save memory, _any_ group of merged modules should be just under some multiple of 8k. Because of the way the Shell (including Shell+) works, the Shell file should be under 7680 bytes. Does it make more sense now? - Tim -*- 30583 8-JUL 11:12 General Information RE: shell+ 2.1 (Re: Msg 30562) From: ZACKSESSIONS To: RAGTIMER Wasn't there a patch to Shell+ posted here in the forum which fixed that problem? Posted by Mike Haaland, originally, I think. Zack -*- 30647 10-JUL 22:00 General Information RE: shell+ 2.1 (Re: Msg 30583) From: RAGTIMER To: ZACKSESSIONS Yes, there was the patch, which I wrote in my notebook somewhere in March or April, and passed on to Paul Seniura. I didn't know about the 2nd patch he's posted, tho. However, I wondered whether there had been a later release of Shell+ that fixed the problem. "Instant Program -- No patches Needed" -- boy would that be a 1st for OS9, just kidding, grin. Seriously, patches for PD shareware aren't so bad, since users get the patches the same media they got the program to start with. Bigger problem is commercial programs (like MultiVue) that require patches; most customers aren't on Delphi/CIS/whatever and don't even know the patches exists, or how to get them. --mike k. -*- 30649 10-JUL 22:12 General Information RE: shell+ 2.1 (Re: Msg 30571) From: RAGTIMER To: TIMKOONCE (NR) Also: Any merged group that has one BIG program (that's going to use all 8 of its 8K blocks when running) should fall short of an 8K multiple by that 512 byte amount. I know someone who MERGEd innocent little MONTYPE and PWD with Umuse3, thus filling in that 512 byte no-man's land, and got a nasty surprise when it ran. This by the way is not really related to the Shell+/Umuse3 problem, which is easily patched out of Shell+. -*- 30650 10-JUL 22:14 General Information RE: shell+ 2.1 (Re: Msg 30583) From: RAGTIMER To: ZACKSESSIONS Zack, it may well have been Mike Haaland who first found that Shell+ bug with big programs, since his MVCanvas is about as big as Umuse3. -*- 30684 12-JUL 23:22 General Information RE: shell+ 2.1 (Re: Msg 30650) From: XLIONX To: RAGTIMER (NR) Howdy Mike, Please see msg# 30556 -mark w. farrell (XLIONX) -*- 30686 13-JUL 00:12 General Information RE: shell+ 2.1 (Re: Msg 30650) From: MIKEHAALAND To: RAGTIMER (NR) ~ Well, To set the record straight, I did discover that Shell+ was giving our programs (UMusE III and MVCanvas) a little trouble. But it was another forum member who found out how to patch Shell+ to work so it didn't give an extra 31 pages of memory when forking programs. MikeH -*- End of Thread. -*- 30531 6-JUL 23:14 New Uploads depthcharge From: ZACKSESSIONS To: WJMOORE I downloaded depthcharge the other night and have a few comments. Please don't take anything I say derogatory, I'm only trying to help. The program is good, but uploads need a little extra. Like a doc file which describes the program, how to install it, and how to use it. Fortunately, I found the comments in the source on how to drop depth charges, but I know nothing on the scoring of the game. Also, some sound effects may make the game more enjoyable. Zack -*- 30533 6-JUL 23:54 New Uploads RE: depthcharge (Re: Msg 30531) From: WJMOORE To: ZACKSESSIONS Just say it like it is but keep it clean! hehe. I was exploring the get/put buffers and used this game as a vehicle to demonstrate animation capabilities. But you are correct, a brief description on loading, running, and operating the game will be UL for those that do not program. As for scoring, I could not come up with anything satisfactory so open to any suggestions. Primative sounds can be added easily, but "white" noise I can not generate. Any help here? Anymore comments, just tack onto this thre ad. - War - -*- 30541 7-JUL 11:00 New Uploads RE: depthcharge (Re: Msg 30533) From: ZACKSESSIONS To: WJMOORE White noise can be generated by doing a SYSCALL to the SetStt/ SS.Tone call with a random value for the frequency. Makes a good motor/engine sound. I did play the game for at least an hour, though, when I first downloaded it! Zack -*- 30550 7-JUL 19:23 New Uploads RE: depthcharge (Re: Msg 30541) From: DODGECOLT To: WJMOORE You might want to check out my Lander games a tle h ffrotesn,u hhgfe tfi o rone..-i * n he.--35 -U0: Uite c"tlt rmKO oAL Hl,eeoeyisulat edtaesolsob alb nt N pos eto Iscld""wi shr r"oy.Is tlywc cbn hfntn foyg iigMvn nDltgfe. ort eyiirytisUXcnept,iht dtosfewi-rpign roeoe Ipod cueodays ago, so it should be available anytime soon. Give it a try! Let me know what you think. -Jamie (KNOT1)- -*- 30540 7-JUL 03:34 Utilities database report From: BOBDORRELL To: EDDIEKUNS (NR) Eddie, I am looking at the July, 1990 Rainbow page 62, where you say there is a program that generates a shell script to copy an entire DECB formatted disk to and OS-9 disk using Bob Shanty's RS-DOS utility. I can't find any of ther programs you list in the article, in the database. What is happening folks? Are all the programs selfdistructing? Maybe if you could give the actual name that the file is posted under, it would help me find it. I could go to the database, utilities, and type READ RS-DOS and get what I wanted. Most of the items you mentioned in the article don't have the NAME of the file. Thanks for you help. ----====---- -*- 30542 7-JUL 11:03 Utilities RE: database report (Re: Msg 30540) From: ZACKSESSIONS To: BOBDORRELL (NR) It's called RSSave. -*- End of Thread. -*- 30548 7-JUL 17:00 General Information 1 Meg problems? From: RADARBUZZ To: ALL 1 Meg status, I just installed my 1 Meg kit that I ordered from CRC/DISTO. Everything seems to be working, but... Never before have I had those things called "sparklies", but now I got a few. With no multitasking, (just a few shells on /w1, /w2, /w3 ...) I get one pixel slightly flickering near the top middle of most of the 80 column screens.As a test, I've LOADed about 800K of modules, started OSTERM, ED, and 5 MAZEs. The computer has been up for about an hour and I'm now writing this with ED. R22 IS SHORTED as specified in the instructions. Basically, I have 3 concerns right now: (* = HELP!) *1) The point at which the regulator on the 1-Meg card connects to it's heat sink is HOT. 15 seconds max finger touch before pain. This does not seem normal! The smell from the heat conductive goop cooking between the regulator and heat sink is giving me a head ache, I hope it's not toxic? *2) Right after booting I could not set up a ramdisk (VDD driver here on Delphi) bigger than 512K. Here is how I try for a 720K ramdisk: mega dmode /r0 sct=0b40 iniz /r0 After the "iniz /r0" I get small blocks of random characters (some blinking) on the screen and the computer is locked up. I was under the impression that the VDD driver worked with 1-meg, which is why I switched from RAMMER before the I-Meg kit arrived. 3) The "sparklies" don't seem to be real bad, but I'm willing, as others have, to try hooking up a small pot in place of R22 to attempt to "tune" my computer's personality (grin). Any ideas on what ohm values to begin with? Well, now I'll try Osterm and post this in the forum. Any help that comes my way is truely appreciated! -Jeff ps. Osterm is really NOT smooth with 1-Meg! Since it's running in the upper 512K bank, it must...SCRATCH that! With all those MAZEs running in the background, I shouldn't expect smoothness. Almost fooled my self (grin). pps. Sparkies seem much worse (exponetially greater) during ACIA I/O. Must fix this! ** -*- 30563 8-JUL 00:26 General Information RE: 1 Meg problems? (Re: Msg 30548) From: RAGTIMER To: RADARBUZZ Sparklies are worse during any kind of heavy I/O -- the serial printer port really snows it up. OSTERM, with its constant sampling of the ACIA, does do a pretty good snow job. Question -- do you have an old or new style GIME chip? Old is (c) '86, new is '87 I think. I had lots of sparklies with my old GIME on just 512K. New GIME eliminated them all. And they stayed away when I went to 1 Meg. Now some lucky people had no sparklies under 128/512K even with their old GIMEs. But if you're one of those, maybe the 1 Meg finally got to your old GIME. OS course if you have a new GIME, well, try that trimpot resistor. -*- 30569 8-JUL 01:01 General Information RE: 1 Meg problems? (Re: Msg 30563) From: DWHILL To: RADARBUZZ The regulator running hot to the touch is normal. I'm surpised you can keep your finger on it that long! Mine's always run that hot with 512K. On the other hand, the smell may be something besides the conductive good. Like, maybe the transformer varnish. That may not be a good thing. --Damon -*- 30597 8-JUL 17:37 General Information RE: 1 Meg problems? (Re: Msg 30563) From: RADARBUZZ To: RAGTIMER Well, for the life of me I thought I had an '87 GIME, but after looking again it's a '86 fer sure! QUESTION - How do I order an '87 GIME (RS part #?)and do you remember roughly what you paid for the new one? Since I never had "sparklies" before and haven't had any wierd crashes since the upgrade, the new GIME is all I need, I hope! -Jeff -*- 30598 8-JUL 17:37 General Information RE: 1 Meg problems? (Re: Msg 30569) From: RADARBUZZ To: DWHILL Damon, The HOT regulator I was referring to was the one on the 1-Meg board. A long time ago I swapped the small regulator on the COCO with a big 2N3055 mounted on a massive finned heat sink. I just might do the same for the 1-Meg board. Gee, if I was to wire another 2N3055 in parrallel with the first one, the second one could power the 1-Meg board and I could eliminate that external Commodore(!) power transformer that CRC sent with the kit. -Jeff -*- 30612 8-JUL 19:46 General Information RE: 1 Meg problems? (Re: Msg 30597) From: ZACKSESSIONS To: RADARBUZZ I have 3 on order right now (gimes). Don't have the part number handy, can get it tomorrow. Price is $21 and some change, each. To get one, go to your local Rat Shack and ask the manager to order it for you from National Parts. Zack -*- 30625 9-JUL 18:34 General Information RE: 1 Meg problems? (Re: Msg 30612) From: RADARBUZZ To: ZACKSESSIONS Zack, Let me know that part# (GIME) if you can. $21 sounds reasonable. I'm not in a real big hurry to order one, but - not having had sparklies before I think I would rather not have to get used to them. . . . . . . . . . . . . -Jeff -*- 30629 9-JUL 22:42 General Information RE: 1 Meg problems? (Re: Msg 30625) From: ZACKSESSIONS To: RADARBUZZ Part number is MX0992, cost is $21.75 each. I hope you have better luck than nI did, damn UPS lost mine, and they're having to re-order. Zack -*- 30638 10-JUL 02:57 General Information RE: 1 Meg problems? (Re: Msg 30598) From: OS9UGPRES To: RADARBUZZ A sidenote: I've been running the breadboard version (more chips) of the 1-meg upgrade continously since we got it running back last fall... and using the coco's normal internal power supply! However, I don't have a cover on the machine (which helps ;-), and also I have the CMOS 6309 cpu... which uses almost a watt less than the normal 6809. No problems so far, powerwise. Might just be luck, tho . kev P/ex -*- 30640 10-JUL 16:26 General Information RE: 1 Meg problems? (Re: Msg 30629) From: RADARBUZZ To: ZACKSESSIONS Thanx Zack, I'm gonna order one today. -Jeff -*- 30641 10-JUL 16:27 General Information RE: 1 Meg problems? (Re: Msg 30638) From: RADARBUZZ To: OS9UGPRES (NR) A whole watt less (6309 vs 6809)!? I've seen some discussion about the 6309 here in the past. Interesting. QUESTION: is the 6309 a direct plug-in replacement (same pin-out) for the 68B09 ? What's a good source to order one from? Thanx, -Jeff -*- 30648 10-JUL 22:04 General Information RE: 1 Meg problems? (Re: Msg 30638) From: RAGTIMER To: OS9UGPRES (NR) Hey Kev, no fair! Running with the case open is a dirty Commie (as in -odore) trick. "Warranty void if case NOT opened before using." Grin? -*- 30651 10-JUL 22:18 General Information RE: 1 Meg problems? (Re: Msg 30569) From: RAGTIMER To: DWHILL Yeah, my 1 Meg regulator is too hot to touch for more than a second or two. No smells, tho. With the 1 Meg properly installed, and using that Communist transformer, your Coco's transformer should be runnhjing *cooler*, since it isn't running your 512K RAM anymore. Unless the daughter board over the 6809 draws more than your 512 did. I seriously considered feeding the 1 Meg regulator from the Coco's transformer and rectifiers, but decided not to tempt the gods & demons. -*- 30673 12-JUL 20:46 General Information RE: 1 Meg problems? (Re: Msg 30651) From: DWHILL To: RAGTIMER (NR) I dunno, that really ought to work, feeding the 1 meg reg directly. Check the specs on the regulator and the voltage rating on the capacitors, though. I'd think that would take some strain off the main regulator quite neatly. As you may have noted in my message to DALEP, I FINALLY got around to doing the IRQ diode hack, and am running Xcom9, which is notorious for locking up. Be interesting to see if this cures some of my problems. --Damon -*- End of Thread. -*- 30552 7-JUL 21:21 Utilities OS-9 Spooler From: AARONS To: ALL I'm in search of a spooler to use with CSG IMS database manager, I saw the Spool.ar utility in the database but I do not have an assembler. Can someone upload an assembled version? Is ther one comercialy available? Where? Also, does anyone know the patch to allow Multi-Vue to Init. in HI-RES mode (80 colum)? thanks, AARONS -*- 30553 7-JUL 21:46 Programmers Den SQRT Function in C? From: ZACKSESSIONS To: ALL I have the need to use the sqrt() function in C. I have the latest Krieder lib from the programmer's den. The docs state that there is an int sqrt(n) function. When I try to link a program using it, I get an unresolved reference. dEd of the clib.l sure enough shows there is no sqrt() function present. What gives?!? Zack -*- 30605 8-JUL 19:23 Programmers Den RE: SQRT Function in C? (Re: Msg 30553) From: RAYMAYEUX To: ZACKSESSIONS Did you look in clibt.l? -- Ray -*- 30611 8-JUL 19:44 Programmers Den RE: SQRT Function in C? (Re: Msg 30605) From: ZACKSESSIONS To: RAYMAYEUX Yeah, I'm using clibt.l know trying to use the double version of sqrt(), but Mike Sweet reports potential problems with it, as well. Zack -*- End of Thread. -*- 30556 7-JUL 23:00 General Information High Horse From: XLIONX To: ALL Howdy All, I don't do this very often...so hold tight. Who the heck is PAULSENURIA to come out of nowhere about June 4th and claim the RIGHTS to patches for shell v2.1 when they were on the forum with explainations in April? The patch to $1313 was from KNOT1 April-19. The patch to $130F was from OS9UGVP April-21. I don't mind people saying "For the good of the community I put this info together, so here it is." but to claim RIGHTS to it (indignant pause)??? Sorry Paul, I don't buy it. -Just blowing some steam. -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS v2.0) -XLIONX (DELPHI) -mwf @SANDV p.s. get used to it. -*- 30580 8-JUL 03:53 General Information RE: High Horse (Re: Msg 30556) From: KNOT1 To: XLIONX Thanks for the credit, Mark. -Jamie (KNOT1)- -*- End of Thread. -*- 30557 7-JUL 23:01 General Information High Horse From: XLIONX To: PAULSENIURA (NR) Please see message 30556 -mark -*- 30572 8-JUL 03:16 General Information music From: BRIANWHITE To: ALL Is there anyone willing to photocopy and send me a copy of the Orchestra-90 documentation??? The docs that come with "Orchestra Master" are really poor and just aren't good enough to write a conversion routine with. Any help would be appreciated. Than x! Brian C. White P.O. Box 1565 Esterhazy, Sask. S0A 0X0 Canada -*- 30582 8-JUL 07:07 Programmers Den HINTS ON C COMPILER From: ALWAGNER To: ZACKSESSIONS ZACK, I am sure that it is something I am doing wrong, but maybe you can steer me in the right direction. When I go to de-arc the subject archive, AR reports that it is extracting dc.txt and then proceeds to dislpay all sorts of things on my screen. The exact pattern of garbage varies depending on whether I was in a window or booted up to a vdg screen. In either case, the system usually crashes. If I then reboot and look at the directory of the disk where I expected the files, I find a file dc.txt with nothing in it. I have de-arced shell+ which I downloaded from DELPHI and had no problem at all. I have read and reread the docs on AR and can't find anything I'm doing wrong. As was mentioned above I've tried using AR from several different boot configuartions and always get similar results. (i.e., shell+, tandy shell, sdisk3, tandy cc3, etc.) If you could shed some light on the subject or tell me whom I might ask for help I would be very appreciative. Thanks in advance, AlWagner -*- 30584 8-JUL 11:18 Programmers Den RE: HINTS ON C COMPILER (Re: Msg 30582) From: ZACKSESSIONS To: ALWAGNER I believe the filename should be hdc.txt, not dc.txt. I'm sorry you are having problems getting it de-archived, no one else has reported such a problem with that file. How many times did you download the archive? If only once, try downloading it again, sometimes that helps. In the meantime, I will download it myself, to make sure there are no problems. Zack -*- 30585 8-JUL 11:26 Programmers Den RE: HINTS ON C COMPILER (Re: Msg 30582) From: ZACKSESSIONS To: ALWAGNER I just downloaded the file and it de-arced just fine. I did get a warning from ar that the file was "not archived or damamged", but that message from ar can be ignored. The file is de-arced OK by that time. Try downloading it again. Zack -*- 30594 8-JUL 15:29 Programmers Den RE: HINTS ON C COMPILER (Re: Msg 30585) From: ALWAGNER To: ZACKSESSIONS Thanks for taking the time to check out the file. As I said, Its got to be something I'm doing. Just what that is I'm not sure. I did try down loading the file more than once with similar results. I'll try again and let you know how I make out. Thanks again, AlWagner -*- 30603 8-JUL 17:57 Programmers Den RE: HINTS ON C COMPILER (Re: Msg 30594) From: ALWAGNER To: ZACKSESSIONS I knew it was something I was doing! The problem came from a source you could not have known about. Until this logon I was using MIKEYTERM. A good program but not OS9. This meant that I had to convert everthing to OS9 before I could use it. Well, the conversion I was misusing was hacking off the beginning of the file. Hence the "dc.txt" rather than "hdc.txt". This last go 'round I tried a different convert utility and presto-changeo it worked perfectly! I did notice the error message you warned me about, but as you said it did not seem to matter. Thanks again for your time and efforts. AlWagner -*- 30609 8-JUL 19:42 Programmers Den RE: HINTS ON C COMPILER (Re: Msg 30603) From: ZACKSESSIONS To: ALWAGNER (NR) You might want to consider downloading OSTerm, SuperComm, or even KBCom, from the libs. Of course you'll need a RS232 if to use any of them. Zack ps, glad you got it de-arced OK. btw, I have made some improvements to that file and plan to re-upload it. WIll post a notice in the Forum when it's done. -*- End of Thread. -*- 30589 8-JUL 12:03 General Information Hardware help needed From: WB4GCS To: ALL I have a J&M disk controller which I bought at a flea market. It appears to have a parallel port in addition to the disk prot (which works fine!) Does anyone have pinout and/or device driver information for the parallel port? Sure would be nice to get away from the bit banger. How about a schematic on this thing? All help gratefully appreciated. 73, Jim wb4gcs -*- 30601 8-JUL 17:55 General Information RE: Hardware help needed (Re: Msg 30589) From: DODGECOLT To: WB4GCS Try looking in the Device Drivers database for a driver for that controller. -Mike -*- End of Thread. -*- 30596 8-JUL 16:28 Programmers Den still sqrt() problems From: ZACKSESSIONS To: ALL OK, I am now using clibt.l. So how come the following program: #include main() { double x, y; pffinit(); x = 36; y = sqrt(x); printf("The square root of %f is %f\n",x,y); } Gives the following output: The square root of 36.000000 is 0.000000 Zack -*- 30602 8-JUL 17:57 Programmers Den RE: still sqrt() problems (Re: Msg 30596) From: DODGECOLT To: ZACKSESSIONS Zack- try declaring the sqrt() function to double first- as the code you gave us stands, the compiler will think that sqrt() returns an int... -Mike -*- 30604 8-JUL 18:14 Programmers Den RE: still sqrt() problems (Re: Msg 30602) From: DODGECOLT To: ZACKSESSIONS Geez, I just tried getting the square roots of the first 100 numbers, and got garbage results... Interesting, though, how the square root of 93 is 1389796441404211185.810524! :) Carl only frequents CIS, right? Look like there _might_ be a _slight_ problem with that function! -Mike -*- 30608 8-JUL 19:40 Programmers Den RE: still sqrt() problems (Re: Msg 30602) From: ZACKSESSIONS To: DODGECOLT Thanks, Mike, Pete Lyall mentions the same thing. Zack -*- 30610 8-JUL 19:43 Programmers Den RE: still sqrt() problems (Re: Msg 30604) From: ZACKSESSIONS To: DODGECOLT Uh, oh! I haven't tried the double declaration, yet, but will. If I encounter similar problems, I will contact Carl and let him know of the problems! Good eye! Zack -*- 30624 9-JUL 18:13 Programmers Den RE: still sqrt() problems (Re: Msg 30610) From: DODGECOLT To: ZACKSESSIONS Boy, now I can't even duplicate problems! After playing around with the pow() function, I then tried to use the sqrt() function again to see if I could find a pattern... Of course it just happened to work perfectly... I hate problems that come and go randomly! -Mike -*- End of Thread. -*- 30606 8-JUL 19:31 Device Drivers Any RAM Disks larger than 512K? From: RADARBUZZ To: ALL Attention: If there is anybody out there that can set up a ramdisk larger than 512K, please let me know what driver you are using. Thanx -Jeff -*- 30689 13-JUL 20:55 Device Drivers RE: Any RAM Disks larger than 512K? (Re: Msg 30606) From: DENNYSKALA To: RADARBUZZ (NR) I don't know of any ramdisks that create > 512k ramdisks. However, I am the author of the one which Microcom sells/packages with their memory boards. I was considering fixing it to recognize the additional memory --- until I realized that I would have no way of testing it myself. It should be a fairly easy fix, and I expect eventually that someone will complain that it won't do the extra Disto memory, so I suppose I should fix the thing. If you would be interested in Beta testing a fixed version, let me know in email. It might take a few go-arounds and some upload/download time to get it right. ***** Dennis ***** -*- End of Thread. -*- 30616 8-JUL 22:21 General Information gime From: RADICAL To: ZACKSESSIONS How do you know if the coco has a new or old gime? Len -*- 30618 8-JUL 23:08 General Information RE: gime (Re: Msg 30616) From: ZACKSESSIONS To: RADICAL Well, ya gotta void the warrenty (if it is still applicable) and open up the case. If the GIME has a date of 1987 on it, it the newest one available. Zack -*- 30634 10-JUL 00:57 General Information RE: gime (Re: Msg 30618) From: RADICAL To: ZACKSESSIONS Thanks, my warranty was voided long ago. I will check the date when I install the 1 meg. Thanks. Len -*- End of Thread. -*- 30626 9-JUL 21:55 General Information GFX2 & MM/1 From: COLINMCKAY To: OS9UGPRES Hi, Kev, and Paul. Just a suggestion that others might find useful with the new GFX2 module you uploaded. Rename it to GFX3, as well as patching it and updating the CRC, and you can continue using GFX2 and its calls. Naturally, you now have to call it using RUN GFX3. Anyway, thanks for releasing it. Appreciated by all locally. Also have a few questions about the MM/1 (Oh, no. Not more questions about the MM/1 ) The VSC chip (SCC66470) normally arbitrates access to the first meg of memory that the VSC chip and the 68070 share. When the 68070 gets its own 2 or 8 megs of memory, and the VSC no longer has to do arbitration, does this then speed up the VSC chip? Or does the VSC continue doing arbitration all the time? A few people on the International CoCo and OS9 echoes have mentioned that they have seen demos of the MM/1. Amongst other things, they mentioned seeing 320*200*256 GIF files loading in "under one second"! Are these amazing numbers accurate? Or was that some other format? Any recommendations on monitors? I currently have a CM-8, but also need a PC compatable monitor for working at home. I was considering buying the NEC 2A. Its specs match fairly well the MM/1. Alan Dekok wonders if you have seen his demo (CC3DEMO) which runs under RSDOS. (He just called as I was writing this letter.) Bouncing, spinning ball, four voice music, 1 inch high scrolling text across the bottom of the screen. Pretty impressive, especially since it holds about five minutes of text. Its over on the RSDOS side. Also, the specs for the VSC chip make it appear to be almost trivial to create a frame grabber. Any word on this? And GenLock also appears to be trivial on this machine, at least the computer end. Any chance? Does the second board come with the 2 meg of memory on board already? Matt Thompson pointed out that it should be possible to have Microsoft FlightSim V4.0 running using 100% legal system calls. That would be impressive. Finally, could you please detail exactly which resolutions are supported? Some of the literature from KLE (MM/1 ad, July Rainbow) says 720*560 is supported, while other literature mentions only (Only!) 720*480. Thanks for your time. Colin McKay. -*- 30632 9-JUL 23:28 General Information RE: GFX2 & MM/1 (Re: Msg 30626) From: TIMKOONCE To: COLINMCKAY From earlier messages, it is the case that the CPU speeds up if it's not competing with the VSC for memory. i.e. getting more mem approx doubles the speed of the machine. Don't know what you mean by the "VSC speeding up". Kind of like asking if the GIME speeds up. - Tim -*- 30639 10-JUL 02:58 General Information RE: GFX2 & MM/1 (Re: Msg 30626) From: OS9UGPRES To: COLINMCKAY Colin, No need to rename the new gfx2 to gfx3, as it has all the original gfx2 commands in it. However, I just popped in and read my mail, and someone said that a few of the original gfx2 commands didn't work... has anyone else seen any problems? Maybe I compiled in a bug by accident. Re: MM/1, VSC, etc - When you add more memory, the cpu will no longer have to run programs from the video ram. That immediately gives you roughly a 20% (or more) speed increase, I think. Visible increase, that's for sure. Someone oughta rig up the same trick on the coco (external ram or something). Yah, the fast picture loads people see in demos are definitely not realtime GIF conversions, but raw vef-style data. Right now, the GIF converter (written by Mike Haaland for us) sends the data to standard output. That works pretty well, as you can send it to a file, or pipe it straight to a picture loader/viewer. Pictures are 64K long, so they can take a while to load off floppy, albeit faster than the coco. Still, the DMA harddisk *really* screams loading in pics. And you should have no problem loading in most sound files faster than the DMA stereo sound hardware can play it, even off floppy. I've heard lots about that CCDEMO, but it won't run on my computer (I hear that's not unusual). Would love to see it sometime. Any framegrabber will be external, I think. A genlock tho, we hope to plug into the main board. I don't think the second board comes with RAM (I could be wrong). Before long, 4-meg SIMMS will be pretty darned cheap, and I suspect the wilder types will want to go straight to 9 meg ;-). Both the FHL and the KLE video spec sheets seem to change all the time . See, in PAL mode (overseas TV, versus the US's NTSC), you can go up to 768x560 or so. For us, it'll top out at 720x480... which will actually be our worldwide standard, as the chip supports a PAL mode which allows viewing the smaller NTSC resolution gfx (centered on screen). So figure on 320x210, 320x420, 360x210, 360x420, 640x210, 640x420, 720x210, and 720x420 modes... where the 360/720 x-modes go from edge to edge and over (for video overlays where you don't want a border). Actually, some monitors can show the whole deal... the 720x480 gives you 90x60 char (8x8) text! However, the flicker can be a killer in that mode, at least to me (depending on the colors chosen). - kev -*- 30674 12-JUL 20:53 General Information RE: GFX2 & MM/1 (Re: Msg 30626) From: DWHILL To: COLINMCKAY Those superfast load time for graphics ought to be accurate, as the 68070 has DMA and can move blocks of data darnfast! I need to pester Phillips for spec sheets on it and the graphics chips to find out more, but I think the performance is going to be very impressive, should give the '386 machines something to be jealous of! --Damon -*- 30680 12-JUL 22:35 General Information RE: GFX2 & MM/1 (Re: Msg 30674) From: COLINMCKAY To: DWHILL (NR) I was impressed by the speed, just the messages that I saw implied that they were compressed GIF pictures. That really would have been an impressive feat. However, loading 64k vef type files in that little time is quite impres sive too. -*- End of Thread. -*- 30628 9-JUL 22:35 Applications name and address pgm From: CAPTSWOOSH To: ALL hey gang is there a free ware name and address database label pgm out there? that is ready to run?? Ron done -*- 30630 9-JUL 23:25 Programmers Den Speeding up the coco3 From: NES To: ALL Here is a queston for you hardware hacker's, could I increase the cpu's speed of the coco3 closer to 2Mhz or over, by add a new crystal, or would it screw the video and disk? BTW I am useing a CM-8 if that makes any diffrence... also a burk and burk harddrive.. Eric -- -*- 30633 9-JUL 23:31 Programmers Den RE: Speeding up the coco3 (Re: Msg 30630) From: TIMKOONCE To: NES (NR) The Video frequency is generated by the same clock that generates the system frequency. So, no, you can't just change the crystal. Speeding up the processor would require some fairly elaborate circuitry to handle the speed difference between the processor and the GIME, since you can't change the GIME speed without messing up the video. The disk controller uses a separate crystal for it's clock, so that's not the issue. Why do you want to get "closer to 2Mhz"?? 1.89 is pretty durn close already. - Tim K -*- End of Thread. -*- 30642 10-JUL 16:36 Device Drivers COCO2 WORD PROCESSORS! From: DKIRCHER To: ALL Help! I have a COCO2 system that is running WORDPAK RS and I am looking for a WORD PROCESSOR that will work with it. I already have older versions of STYLOGRAPH and LASTWORD that use those graphics drivers or WORDPAK. Does anyone have an updated version they would like to sell or perhaps maybe know of a patch that will do the trick. If someone has a WORKPAK they'd like to part with that'll work too thanx dlk -*- 30643 10-JUL 16:42 General Information Upgrading Coco II From: DKIRCHER To: ALL I just fired up my old gray coco and found out that coco is a collectors item. So I have found two other coco IIs as backups for when the parts really dry up. I would like to know how to get these two guys up to speed for disk operation. Is an ECB upgrade all they need to accept a disk controller? Radio Shack was not very much help. -*- 30668 12-JUL 02:16 General Information RE: Upgrading Coco II (Re: Msg 30643) From: WAYNELAIRD To: DKIRCHER dk, what can help is downloading and using the dmode utility by K.darling. works good on the two as well as the three. this canspeed up your disk access time to 6ms. best ,wayne -*- 30669 12-JUL 03:22 General Information RE: Upgrading Coco II (Re: Msg 30668) From: DKIRCHER To: WAYNELAIRD (NR) Oh No, the prob here is the cocos aren't seeing the controller in the port I'll plug it all in and fire it up but only get a COLOR BASIC prompt. So I presume that they must have ECB before they will "see" the disk controller to access DISK COLOR BASIC. I've been flogging my poor old drives with the debug patch for some time now. -*- 30670 12-JUL 03:40 General Information RE: Upgrading Coco II (Re: Msg 30669) From: DKIRCHER To: ALL Alright, The old ECB roms have all sold out. I'm gonna take the plunge and eprom my own. Having never done this I have three questions. Is all this necessary to get the disk controller to work I'm dealing with both the old and the new Korean coco's and I've noticed that one has a CB rom and an empty sockett and the other has a CB rom in a socket. Is the upgrade for the two of them to ECB the same. Last question: I have no desire to EVER mess with CB or ECB again after playing with basic09 it's just not the same. So as long as I'm playing with EPROMS why not prom os9 and be done with it. Assuming this is possible without too many contortions how would one go about this. Thanks for your help dlk -*- End of Thread. -*- 30652 10-JUL 22:20 General Information GFX2/MM/1 From: COLINMCKAY To: OS9UGPRES (NR) Hi Kevin. About renaming GFX2 to GFX3: I was bitten by one of those bugs, and without thinking, automatically decided to rename. I was running depthcharge, and it quit with an error which I assumed was caused by GFX2 commands not being found. Ran it with the old GFX2, and it worked, so I renamed/patched the new module to GFX3. Will try to duplicate the error if you wish. Unfortunate that the raw picture files weren't gifs. That woulda been REAL impressive. C'est la vie. Glad to hear there will be a gif converter available tho. Eagerly looking forward to the arrival of the new machine. TTFN. Colin. -*- 30655 11-JUL 01:09 Telcom Hardware Downloading Problems From: THET To: ALL I don't know if this question has been answered or not, but I figure it's better to ask than take a lot of time reading a lot of messages. Here's the problem: I have added an ACIA 6551 board to my CoCo 3 (from the May 1989 Rainbow) and now I can use OS9 to telecommunicate just fine from the bit-banger port with no problems except one. I can't download! I am using Supercomm v2.1 and a 1200 baud modem. I have tried it with a friend of mine's computer with Procomm + which I know works, and severa;l bulleten boards and DELPHI and I get the same results, the fi rst block goes fine, but after that all I get is errors. This happens with Xmodem, Ymodem, and Ymodem batch, and Kermit. The really strange part is that using Gregterm unter RSDOS Xmodem works fine, but the program usually crashes the machine after a download right after I save the buffer to disk. Any solutions. Please answer as having a modem but being unable to download can be a drag!! Thanks. -*- 30657 11-JUL 03:58 Telcom FIDO Hawaii From: TOMMIETAYLOR To: ALL Hawaii Coco Users, Coconuts bbs Of Hawaii now supports FIDO International Mail service. 808-845-7054 300-2400 baud... -*- 30659 11-JUL 20:31 Programmers Den boot disk From: DCJR To: RADICAL Actually, I *should* have said booted with a double-sided descriptor. Using dmode gave the same result. BUT, the other point I needed to emphasize is that there MUST be a cmds dir on the boot disk with shell and grfdrv in it. Doug James -*- 30665 12-JUL 00:55 Program RE: boot disk (Re: Msg 30659) From: RADICAL To: DCJR Too bad you can't underline that and put it all in capitals. I found out early in the game, but screamed for help many times before catching on. Left /dd out of the confgaooc,n n myself in circk opps circles trying to find out what was wrong. Len -*- End of Thread. -*- 30664 11-JUL 22:25 Patches step Rates From: JANG To: DISTO (NR) Hello Tony, I just installed a Seagate ST-125 3.5" 20 Megger under Level II and it is working fine with your "Hard Disk Adapter".. in slot#3 I also run my 2 floppies with your SC II and it has your clock now too!!! The question is this: Using "HardwareHackers" DMode /h0 I see I have a step rate there of step=0.. The ST-125 Manual says it will accept step rates 3-200. Any attempt on my part to dmode /h0 (higher step rate) results in errors although step=7 worked OK for a while and the thing flew!! I have EZGen and ded, but can you offer any other course of action here ?? J.Angus Levittown,NY -*- 30666 12-JUL 01:01 Device Drivers clock From: RADICAL T my controller back and all is working fine. Just wanted to know about the clock as I do not have your catalog. Len -*- 306J :1GeaIfmto E BTOESI(eMg01) Fo:ANAR T:SBR(Rl h apswnyur ?Hvyuopr hmdl norhrdv o?a at rgti cn c3mn ys id.bs,ye - 0671 12-JUL 20:03 General Information Windows under level II... From: ALANDEKOK To: ALL I was wondering if anyone could help me.... I have a Basic09 program that defines 2 output graphics windows (ala Kevins bouncing ball demo), but it doesn't seem to work quite right. Here's the code, and an explanation of what happens. OPEN #W1,"/w" OPEN #W2,"/w" String=CHR$( 1b 20 08 00 28 18 0f 00 00 (* new device window 320x192x16 colors PUT #W1,String PUT #W2,String This works fine the first few times I try it, but as I'm adding/debugging the program, the above code gets executed many many times. The problem is, after a while, I get an ERROR 184 (window already defined) on the first PUT statement. Is there anything I can do about this?? Or what am I doing wrong? The manuals seem to say that this is all legal, but my system doesn't like it. Alan DeKok. -*- 30675 12-JUL 21:02 General Information RE: Windows under level II... (Re: Msg 30671) From: GREGL To: ALANDEKOK Alan, You need to DWEnd and close the windows at the end of the program. Otherwise you'll use all of the descriptors and the program will quit working. If all the descriptors are used (all windows are in use), you obviously can't use any others. -- Greg -*- 30681 12-JUL 23:11 General Information RE: Windows under level II... (Re: Msg 30675) From: ALANDEKOK To: GREGL Yeah, I just figured that out. Boy do I feel dumb. When I took a look at it (via DDIR), I saw it was consistently trying for the same two windows, which were left over from its LAST failed attempt, and it didn't like that one bit. Anyways, I've now got the DWend and CLOSE in there, and it seems to work better already! (grin) Alan DeKok. -*- 30682 12-JUL 23:14 General Information RE: Windows under level II... (Re: Msg 30681) From: ZACKSESSIONS To: ALANDEKOK (NR) To be safe, I always DWEnd a new window I just opened a path to before I try to DWSet it. Seems to work just fine. Zack -*- End of Thread. -*- &@Y6 L-ULR" !M5R$H jRPU$ $ HHI=5iRJjH "uK KSCALES Hi Ken- I tried your SASI Driver Patch and have trouble booting with it. I use the HDA in Slot # 3 for my ST-125(20Meg) and Later added the SC II and use cc3disk.slp there. I patched my current cchdisk($A50917) and did the attr e pe on it and then EZGen'd it into a backup of my boot and everything seemed to go well..but no boot !! Is the MPI upgrade neccessary?? any suggestions??? Jerry Angus -*- 30677 12-JUL 21:28 Graphics & Music RE: Who did "VEFIO" ? (Re: Msg 29872) From: THEFERRET To: TIMKOONCE (NR) I would like something that I could use in a P.D. Graphics editor. (Yes I know Max-9 is out here, but mine is better, so there!) I just can't get bvefio to work for me, apart from using the + option Ug -*- 30683 12-JUL 23:16 Graphics & Music RE: Who did "VEFIO" ? (Re: Msg 30677) From: ZACKSESSIONS To: THEFERRET VEFIO was written by Ron Lammardo. He is not on Delphi, but is on CIS. -*- End of Thread. -*- 30679 12-JUL 22:06 Patches b&b + PBJ CC-BUS From: SALZARD To: ALL Has anyone successfully mated Burke and Burke's Hard Drive interface with the PBJ CC-Bus (six slot multipak)???? Need a patch to BBFHDISK so that it can find the slot that the interface is plugged into. -*- 30685 12-JUL 23:28 General Information Shell+ 2.1 patches From: XLIONX To: ZACKSESSIONS Howdy Zack, Please read message# 30556 and let me know if you think I am justified in my rantings. ];-> -Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS) -XLIONX (DELPHI) mwf@SANDV -*- 30688 13-JUL 19:19 General Information RE: Shell+ 2.1 patches (Re: Msg 30685) From: ZACKSESSIONS To: XLIONX (NR) I read the message just after you posted it. I haven't downloaded that file you mention, but judging from you comments, I certainly feel you're justified. I will download the file and follow up on it. Zack -*- End of Thread. -*- 30687 13-JUL 01:20 Telcom os9bbs From: EMTWO To: ZACKSESSIONS Zack WE got Both your accounts set up. I will email you with your passwords. -*- FORUM>Reply, Add, Read, "?" or Exit> bye I don't understand the term "HBYE" in this context. You may enter ? to view the full menu. FORUM>Reply, Add, Read, "?" or Exit> bye Highest message read: 30691.