#: 16274 S12/OS9/68000 (OSK) 23-Aug-92 21:10:37 Sb: #High Speed Modems Fm: Bob van der Poel 76510,2203 To: Steve Wegert 76703,4255 (X) Steve, I got the 9600 baud modem the other day...and I have it working. Well, sort of. I manage to logon with a CONNECT/V42 at 9600 baud. However, I've had some funny problems.... 1. The other night I kept getting the first 4 lines of one message printed over and over again. Never was able to read everything. 2. Earlier today CIS would just stop. If I hit CTRL-P I would get CONNECT/V42 echoed to my screen. However, a CTRL-C did get the 'interupt' menu and life went on. I think I have some param. settings not quite correct. What are you using for buffering, and flow control setting on the modem and on your computer. I may have an additional problem since I don't have a /t3 yet so I have to use /t0. I did 'dl a file the other night at 9600 and it sure did fly.... Once all works this should save me a few $$ since I not only have to consider the CIS charges, but also toll charges. So on the short calls, even if CIS does charge more I should save in my phone bill. Of course, it never works out that way...but we can dream and attempt to justify things! There is 1 Reply. #: 16275 S12/OS9/68000 (OSK) 23-Aug-92 22:09:46 Sb: #16274-#High Speed Modems Fm: Steve Wegert 76703,4255 To: Bob van der Poel 76510,2203 (X) Bob, I'm running on /t3 ... but /t0 should do fine as well. I've jumpped my buffers up to 2K and this has served well for the last several months. Those 4 lines repeating is a sure sign of buffer overflow. I'm also using hardware flow control ... not sure if /t0 supports this (no tech manual handy) but try to enable it with xmode type 80. Note no Hex $ sign. This seems to be a fluke with the xmode command. Other than that, I've stuck with the modem default parameters. If you need to cover those one by one, I'd be happy to help. Steve There is 1 Reply. #: 16302 S12/OS9/68000 (OSK) 25-Aug-92 21:55:18 Sb: #16275-#High Speed Modems Fm: Bob van der Poel 76510,2203 To: Steve Wegert 76703,4255 (X) Steve, I've decided that the modem is defective. I just can't get it to the connect point--let alone data errors, etc. So, I talked to the supplier and I'm getting a replacement. Now, if the new one doesn't work either--I'm in big trouble! There is 1 Reply. #: 16307 S12/OS9/68000 (OSK) 26-Aug-92 05:25:27 Sb: #16302-#High Speed Modems Fm: SCOTT HOWELL 70270,641 To: Bob van der Poel 76510,2203 (X) Bob, you said that you set the buffer size on the port. How is that done exactly?? There is 1 Reply. #: 16322 S12/OS9/68000 (OSK) 27-Aug-92 20:23:40 Sb: #16307-#High Speed Modems Fm: Bob van der Poel 76510,2203 To: SCOTT HOWELL 70270,641 (X) Scott, to change the buffer sizes just use moded. Make sure you have the updated moded.fields file from the update disk. There is 1 Reply. #: 16324 S12/OS9/68000 (OSK) 27-Aug-92 21:54:16 Sb: #16322-#High Speed Modems Fm: SCOTT HOWELL 70270,641 To: Bob van der Poel 76510,2203 (X) update disk for the MM/1 or the 2.4 upgrade disk??? There is 1 Reply. #: 16338 S12/OS9/68000 (OSK) 29-Aug-92 21:39:21 Sb: #16324-High Speed Modems Fm: Bob van der Poel 76510,2203 To: SCOTT HOWELL 70270,641 (X) Not sure where the updated moded.fields is. I got it from the archive posted here. I suspect that it should be on the mm/1 update disk--but being a developer, for some reason I've never figured out, I don't receive things like update disks...so I really don't know. My moded.fields file is 63002 bytes long...if that helps. #: 16276 S14/misc/info/Soapbox 23-Aug-92 23:33:16 Sb: Hurricane Andrew Fm: Kevin Darling 76703,4227 To: all Hope that all of y'all in Florida have gotten to safety! #: 16277 S12/OS9/68000 (OSK) 24-Aug-92 00:15:34 Sb: #16265-#more ?? Fm: Mike Haaland 72300,1433 To: LARRY OLSON 72227,3467 (X) I've heard of 'em too. One type is called .GL files. At the moment, we don't have a player for them. I have some Xwindows Unix code that does, but have not had the chance to port it yet. I've also heard mention of Animator files that can play sound too. Haven't run into any tho... IFF.H was fun to put together. It just kept growing when I'd run into a new chunk in an IFF file. - Mike - There is 1 Reply. #: 16279 S12/OS9/68000 (OSK) 24-Aug-92 01:51:47 Sb: #16277-#more ?? Fm: LARRY OLSON 72227,3467 To: Mike Haaland 72300,1433 (X) Mike, I was just wondering about those animation/sound files. I guess I just feel out of touch with whats going on. I'm still hammering away with this C. Trying to get the hang of checking signals, waiting for key presses and so on. Any release date yet for PAINT ? Don't worry about putting everything in this version, leave a few things for PAINT II . ;) larry There is 1 Reply. #: 16295 S12/OS9/68000 (OSK) 25-Aug-92 14:25:03 Sb: #16279-#more ?? Fm: Mike Haaland 72300,1433 To: LARRY OLSON 72227,3467 (X) Yeah, I'm trying to get what I have doc'd by the Atlanta fest. Keep up the coding in C. If you have any questions, I'll be happy to try and iron 'em out. There is 1 Reply. #: 16306 S12/OS9/68000 (OSK) 26-Aug-92 01:49:27 Sb: #16295-#more ?? Fm: LARRY OLSON 72227,3467 To: Mike Haaland 72300,1433 (X) Mike, You shouldn't leave yourself open like that, I have a lot of questions ;-) Here is one I have been wondering about, has there been any standards set on palette register numbers for forground & background ? I got sidetracked, and thought I would write a routine that displays palette values and colors. The cgfx docs says to use a char *paldata pointer, should this have been unsigned char *paldata. Using just char I get negative numbers unstead of positive 0-255. Is there any info available on what the default palette RGB byte values are. This routine is outputting the values for the palette registers, but I have no idea if the numbers I get from it are the correct values. larry There are 2 Replies. #: 16316 S12/OS9/68000 (OSK) 27-Aug-92 02:54:41 Sb: #16306-#more ?? Fm: Mike Haaland 72300,1433 To: LARRY OLSON 72227,3467 (X) The stock bootup colors on the MM/1 is the same as the TC/70. You can tell what the palette values are from the program in the next message. Compile it using -l=/dd/lib/cgfx.l I guess it should read unsigned char *paldata in the docs. I'm so used to the coco not having an unsigned char and in using hex when it comes to color and bitmaps that I never thought about it. - Mike - There is 1 Reply. #: 16326 S12/OS9/68000 (OSK) 28-Aug-92 03:17:10 Sb: #16316-#more ?? Fm: LARRY OLSON 72227,3467 To: Mike Haaland 72300,1433 (X) Mike, I'll try that program out. I thought that I would be smart and since I wasn't sure what thedefault palette values were, I thought why not try writing some values to a register and then see if I get the same thing out. At the time it sounded too easy. Now I have another puzzler thats throwing me. I first use DefColr() to set every thing to the defaults, then I use Palette(), sending it path, register number, and three integers values for the colors. The puzzler is that when I read back the registers, the RGB values I sent are put in the correct register just fine, but the 2 next palette registers are zero'ed out. Is there a problem with the Palette() function, or is there something I'm overlooking ? puzzeled in Waterford larry There are 2 Replies. #: 16329 S12/OS9/68000 (OSK) 28-Aug-92 23:41:54 Sb: #16326-#more ?? Fm: Mike Haaland 72300,1433 To: LARRY OLSON 72227,3467 (X) Geez, I dunno. KEVIN!!! :) Really, I haven't experienced that before. What edition of WindIO you running? - Mike - There is 1 Reply. #: 16332 S12/OS9/68000 (OSK) 29-Aug-92 12:19:36 Sb: #16329-more ?? Fm: LARRY OLSON 72227,3467 To: Mike Haaland 72300,1433 (X) Mike, I'm currently using edition 42. #: 16330 S12/OS9/68000 (OSK) 29-Aug-92 00:37:35 Sb: #16326-#more ?? Fm: Kevin Darling 76703,4227 To: LARRY OLSON 72227,3467 (X) Larry, Hmm. Which type of screen? 16 or 256 color? It might be related to the fact that on 16-color screens, the palette numbers actually have to be mapped all over the place (not just the first 16). I'll look. Also - have a short test program? thanks! - kev There is 1 Reply. #: 16333 S12/OS9/68000 (OSK) 29-Aug-92 12:25:53 Sb: #16330-more ?? Fm: LARRY OLSON 72227,3467 To: Kevin Darling 76703,4227 (X) Kevin, I'll put the source up here, its not short, but not too long. The problem crops up when using the Palette() function. It appears to overwrite more registers than just the one. Then again I could be totally screwing it up with my novice knowledge of C ;-) larry #: 16317 S12/OS9/68000 (OSK) 27-Aug-92 02:54:53 Sb: #16306-more ?? Fm: Mike Haaland 72300,1433 To: LARRY OLSON 72227,3467 (X) /* showpal.c - show current screen palette values */ #include /* for printf */ #define STDOUT 1 main() { char paldata[768]; int num_colors; int x; num_colors = colors_available(STDOUT); _gs_palette(STDOUT,0,paldata,num_colors); Clear(STDOUT); for (x = 0; x < num_colors * 3; x += 3) printf("Color %03d - RED 0x%02X, GRN 0x%02X, BLU 0x%02X\n", \ x / 3,paldata[x] & 0xff, paldata[x+1] & 0xff, paldata[x+2] & 0xff); } colors_available(path) int path; { int fore, orig, colors; SetDPtr(path,0,0); /* get the original pixel color */ orig = _gs_point(path,0,0); /* get the current foreground/drawing color */ Point(path); fore = _gs_point(path,0,0); /* Set color to FF/255 */ FColor(path,0xff); Point(path); /* Find out max color per pixel */ colors = _gs_point(path,0,0); /* Restore the pixel at 0,0 */ FColor(path,orig); Point(path); /* Reset the foreground color */ FColor(path,fore); return(colors + 1); } - Mike - #: 16287 S12/OS9/68000 (OSK) 24-Aug-92 15:30:01 Sb: #16253-#more ?? Fm: Kevin Darling 76703,4227 To: LARRY OLSON 72227,3467 (X) Larry, Almost soup, yes! I spent some time last week rewriting the TC70 keyboard driver so that it actually returned more than just a few keys . Looking pretty good. Now I just have to make sure the mouse driver still works. BTW, I'll probably also include the 68070 serial port NFM network driver... don't you also have both a TC70 and an MM/1? It's not fast (19.2Kbaud), but it can be useful. Yah, people have been after me to include a Tone command. Is that what you meant? I've kinda half-finished that part (been working on font support lately instead... I can directly use Amiga font files now :-). Man, I gotta practice a lot of C one of these days, too. I envy your efforts! best - kevin There is 1 Reply. #: 16290 S12/OS9/68000 (OSK) 25-Aug-92 01:24:09 Sb: #16287-more ?? Fm: LARRY OLSON 72227,3467 To: Kevin Darling 76703,4227 (X) Kevin, Yes, that TONE command is what I meant. How are Amiga fonts setup ? Are they 8x8 or 8x6 ? How much of a rewrite was it to be able to use them ? I'm still finding out how little I know of C, for instance I just ran into a brick wall in trying to use the CurXY function. I have a little routine that is supposed to be printing some numbers using CurXY, while in a FOR loop. But for some reason nothing is printed while the program is inside the loop, then when the program exits the loop, all the numbers are printed on one line. Its like the print commands are being put in a buffer instead of going to the screen. Then when the program exits they are all spit out. I'm going to try putting a \n in the PRINTF and see if that fixes it. As you can see, I'm still stumbling ;) larry #: 16278 S10/OS9/6809 (CoCo) 24-Aug-92 00:15:46 Sb: #16271-Vefprt.star Fm: Mike Haaland 72300,1433 To: William L. Cotter 72557,306 Try using the Epson.color driver with MVCanvas. The NX series are Epson compatible. The .star drivers are for the 'older' SG-10's. - Mike - #: 16283 S12/OS9/68000 (OSK) 24-Aug-92 04:44:28 Sb: #VME Hardware Fm: Liz Cowell 100013,1465 To: ALL Can anyone recommend a good VME based hardware platform + scheduler (OS/9 or similar) for developing a realtime control system ? Any suggestions welcome, Thanks, Liz There is 1 Reply. #: 16289 S12/OS9/68000 (OSK) 24-Aug-92 22:19:22 Sb: #16283-VME Hardware Fm: Timothy J. Martin 71541,3611 To: Liz Cowell 100013,1465 (X) I use VMEBus and OS-9 for real-time stuff. Have tried several mfgrs by now. There are lots of possible choices, for the different approaches ... philosophies ... whatever. Would prefer to talk more privately regarding possible recommendations or experiences. So mail to CIS mail or Internet tjmartin@anl.gov. #: 16285 S12/OS9/68000 (OSK) 24-Aug-92 15:29:05 Sb: #15903-Atari? Windows? Fm: Kevin Darling 76703,4227 To: Mark Sours 70372,1370 Hi Mark, Gee, am I behind in my replies or what? Ouch. Yes, I'm still trying to fix up the ST port so that it'll work on other machines (I dunno why it works here and not on others - sigh). I'm also working with others to make sure MM/1 and TC70 apps will work pretty much the same on the ST. We're slowly figuring some of that out. Shouldn't be too long before I can get it out. Keep after me. Things have been really busy around here lately, with my brother and father each having operations. best - kevin #: 16286 S12/OS9/68000 (OSK) 24-Aug-92 15:29:33 Sb: #16216-#MM/1 _ss_play Fm: Kevin Darling 76703,4227 To: Stephen Seneker 75020,3611 (X) Stephen, Yes, you can record (or play) more audio than available memory. The trick is: the sound driver will buffer up to about 4 (maybe more, I've forgotten :-) play/record requests. As soon as one is finished, the next request in line will automagically be started without delay. So what you do is allocate a couple of buffers. Fill one, then start it playing and begin filling the other. Then also immediately request a play for that second buffer (which will be queued up by the driver). This primes your playing "pump". Now you can wait for the first buffer to finish playing before starting to load it up again. Then wait for the second to finish before playing the first. And continue looping from there. To sync the waits, pass a signal value in the parameters. For my quick and dirty demos I just pass an S$Wake signal value... and go to sleep between buffer-fills. The S$Wake signal keeps me in sync (except when the playing goes faster than loading can go - then everything stops between buffers. I should use a fancier method in my play programs). I usually use about 4-16K buffers, I think. Depends on playback frequency. Does any of this make sense? best - kevin There is 1 Reply. #: 16303 S12/OS9/68000 (OSK) 25-Aug-92 21:55:29 Sb: #16286-#MM/1 _ss_play Fm: Bob van der Poel 76510,2203 To: Kevin Darling 76703,4227 (X) Speaking of play... why is it that sometimes I hear clicks when using hdplay, other times I don't? It seems to happen with the same file, without any other processes hogging cpu time. Hmmm, should be more specific--the clicks appear to be very brief pauses occurring when the disk fetches are being made. There is 1 Reply. #: 16305 S12/OS9/68000 (OSK) 26-Aug-92 01:35:46 Sb: #16303-#MM/1 _ss_play Fm: Kevin Darling 76703,4227 To: Bob van der Poel 76510,2203 (X) Bob - I sure don't know yet why sometimes you get clicks during hdplay. It might be related to the DMA bus usage everyone has talked about. The sound DMA channel is a higher priority, so that's no problem. And the sound interrupt is the highest in the system (or is now, I boosted it to 6). So what could be happening is that the interrupt routine isn't being run right away because the disk DMA takes away cpu cycles. Or... perhaps I do something dumb like re-init the audio output to zero on each play. Lemme look. kev There is 1 Reply. #: 16321 S12/OS9/68000 (OSK) 27-Aug-92 20:23:32 Sb: #16305-MM/1 _ss_play Fm: Bob van der Poel 76510,2203 To: Kevin Darling 76703,4227 (X) I'm not sure about this...but I seem to recall that the clicking occurs after I have stopped the playing of a file with Ctrl-C and then started playing a new file. I'll drag the stereo over and do some tests if you need. Let me know. #: 16288 S10/OS9/6809 (CoCo) 24-Aug-92 15:30:34 Sb: #16270-Format error Fm: Kevin Darling 76703,4227 To: BOB LEET 72020,2536 (X) Bob, Yes, you should be able to chd away from the ramdisk, then deiniz it until it goes away (use the DDir util to see how many times you need to do this). But first, you should take Rammer (and any other drivers) out of your merged Shellutil applications file! You absolutely do not want a driver/app mixture like that, because whenever you iniz the ramdisk you will also be using up tons of kernel space (which would lead to not being able to format floppies, etc). Remember: all modules loaded together from a merged file, will stay together. As you know, this is normally a Good Thing (it keeps OS-9 from allocating a separate 8K block of memory for each and every tiny module). But you have to be careful in this case. As soon as you iniz the ramdisk then not only will Rammer/R0 be mapped into the limited 64K kernel map, but so will all the other utilities that were merged with them! The best thing always is to make a bootfile with all the drivers you intend to use. Second best would be to merge all the extra drivers into one file to load later on. But never merge drivers in with commands/applications. Does this make sense? best - kevin #: 16293 S12/OS9/68000 (OSK) 25-Aug-92 10:09:08 Sb: Job Offer Fm: Jim Sutemeier 70673,1754 To: all +------------------------------------------------------------+ |/| |/| |/| OS9 PROGRAMMER POSITION OPEN |/| |/| |/| |/| C and 68000 assembly programmer with at least 2 years |/| |/| experience with the OS-9 operating system needed |/| |/| immediately. Experience in writing real-time |/| |/| applications is also desired. Send resumes to: |/| |/| |/| |/| P.O. Box 681035 |/| |/| Indianapolis IN 46268 |/| |/| |/| |/| Or: call Scott @ (317) 291-1110 or (317) 328-9285 |/| |/| on M,W,F 9am-5pm (Indiana time) for more info |/| |/| |/| +------------------------------------------------------------+ #: 16294 S3/Languages 25-Aug-92 13:20:48 Sb: #Your July article Fm: Mark Griffith 76070,41 To: Bob van der Poel, 76510,2203 (X) Bob, I take exception to something you say in your article in the July Issue of the OS9 Underground. In there, you list a header file that defines the malloc(), calloc(), and several other functions dealing with memory management as 'void *malloc', 'void *calloc', etc. This is completely contrary to the ANSI and K&R standards. These functions do indeed return a value, namely a pointer. To define them as type void is not only dangerous to the program development since it will cause the compiler to leave items on the stack, but it is especially poor when used in an article that proports to be a 'teaching' series. I see you mention you do this to keep the compiler happy when you assing ..errr...assign any form of return value to a pointer. I know of no need to ever do this, and have never seen this feature (or bug' documented any where. I think a retraction and correction in the next article is in order. Mark There is 1 Reply. #: 16296 S3/Languages 25-Aug-92 14:43:13 Sb: #16294-#Your July article Fm: Mike Haaland 72300,1433 To: Mark Griffith 76070,41 (X) Mark, In the UNIX System V, Release 4, they have made malloc(), calloc() and many of the memory functions that return pointers all type void *. Check out memory.h and malloc.h on one of the Unix boxes at work. I don't know if his reasons are 'kosher', but he's right on the defines. - Mike - There is 1 Reply. #: 16297 S3/Languages 25-Aug-92 17:33:39 Sb: #16296-#Your July article Fm: Mark Griffith 76070,41 To: Mike Haaland 72300,1433 (X) Mike, Well, if we were talking about System V here, then maybe I'd be less concerned. However, were are talking about OSK I believe. I have looked at my headers here are work (SunOS 4.1.2) and malloc and the rest are of type char *. A type void pointer is a pointer that can later be declared to point to any object. In the case of 'void *ptr', this would still be confusing to the new C programmer, but legal in several compilers. That pointer can then be defined as any type of pointer. Why one would want to do this instead of declaring it to be what it will be used for is beyond me. I suppose someone might want to do that to fool around with some byte size ordering or something of that nature....surely something that is mnot easily portable or readable. However, the malloc() and like functions do return a pointer of the character type. Trying to declare that as something else later would to me make it entirely too difficult. Even if OSK supported this, and that is the questionable part, I would hesitate to use it in a 'teaching' environment. In any case, explaining the use as 'so the compiler won't complain' is not what I would call the best method. If someone is going to take it upon themselves to act in a teaching role, then they also take it upon themselves to have their 'product' as squeeky clean and bug free as humanly possible. There is no excuse for anything less. Take it from someone who has taught subjects such as this at the junior college level....you have to pass the strictes scrutany (if course, I can spell the words I want to use to make my point). My point, in a nutshell, is Bob is working in areas outside the scope of the OSK/OS-9 compilers, his explainations are lacking, and this can mislead those people that are reading it and don't know any better. It should be in context and clearer. Mark There are 3 Replies. #: 16299 S3/Languages 25-Aug-92 21:54:05 Sb: #16297-Your July article Fm: Bob van der Poel 76510,2203 To: Mark Griffith 76070,41 (X) I probably shouldn't even bother to reply to your message. After all, you've already decided that I'm wrong and you're right. On the other hand, I guess I'm in pretty good company now--not everyone has the privilege of getting flamed by you. Frankly, Mark, you really should read your messages over before posting them and attempt to be a bit more charitable in your comments to others. Weren't you the one offering to send folks a Bible awhile ago? Also, I find it strange that you take exception to Mike's comments about it "being correct in Unix" not applying when it comes to OSK. Heck, every time someone wants to do something different, you get on your soapbox and wail about the "unix standards" already in place and how we should follow them. Oh well. If you care to check an ANSI C reference, you'll find that malloc(), etc are to be defined in as returning pointers of type VOID. Since OSK doesn't use I took your advice and used the unix standard of having a header. It'd be fine to declare malloc(), etc as returning a ptr to char, but then you have to do an explicit cast to use it as anything else. Just checked the MW manual, and it does list char *malloc(). So, maybe you're right and I'm wrong. Maybe I'm a lousy teacher. At least I teach and share what I learn. If it's that important to you, why don't _you_ write an article and explain your thinking. And while you're at it, tell the folks where declarations for malloc(), etc belong (maybe check the unix standard?) and the best declaration. But do keep in mind the new ANSI standards, compilers like GNU, portability, what works best, and what other professionals are using. Should make for interesting reading--I look forward to it. #: 16300 S3/Languages 25-Aug-92 21:55:00 Sb: #16297-#Your July article Fm: Bob van der Poel 76510,2203 To: Mark Griffith 76070,41 (X) Reading over the last message, I find myself falling into the same nasty habits I accuse you of. Sorry. However, I'm still a bit upset at you, Mark, since I never did receive the keyboard adaptor for my MM/1 you promised to send me about 8 months ago. I've sort of stopped checking the mailbox for it... On to keeping the compiler happy. Have a look at the following code: extern void *malloc(); foo() { char *char_p; unsigned char *u_char_p; u_char_p=malloc(100); char_p=malloc(100); } This will generate a pointer mismatch for the 'u_char_p=' line. The compiler is correct in this warning. However, changing the declaration of malloc() to void "solves" the problem. Yes, I know the "correct" non-ansi method of doing this is to explicity cast the return value of malloc to the needed type. However, these casts tend to obscure code even more--and this is one of the reasons ANSI developed the void pointer. Also, your comment about the compiler leaving stuff on the stack due to a void declaration is just plain wrong! And if only perfection is permitted in teaching, then we better empty our schools and burn all the textbooks. Learning in a two way street--both teacher and student have responsibilities. Enuf--this is costing me much more than it's worth. And I'm afraid I'm starting to sound defensive and overly sensitive, which I'm not! Ya just got me going--which you do so well. There is 1 Reply. #: 16319 S3/Languages 27-Aug-92 16:32:58 Sb: #16300-#Your July article Fm: Mark Griffith 76070,41 To: Bob van der Poel 76510,2203 (X) Bob, Well, I suppose I could have been more mellow in my initial message, so I'll apologize for that. However, I think you miss my point. I'm not saying that void *malloc() is wrong per se, just that is is misleading to those people trying to learn "C". In your self-assumed role as a teacher of the subject, it is your responsibility to be as clear as possible on the subject, even if it means sticking to the more arcane OSK conventions than the newer ANSI stuff. A new "C" programmer might easily get confused when they see a function that obviously returns something declared as a type void, no matter how "politically correct" it may be. Also, if you try to assign the return value of malloc() to an unsigned char type, the compiler SHOULD complain because the two datat types are not the same. Declaring malloc() as a type void doesn't fix the problem, it meerly masks it. If you take a piece of code that has malloc return a char * type and compare it to the same code but with malloc() returning a void * pointer, that assembler for both of them is exactly the same. That leads me to believe that the compiler is not doing anything different, it just ignores any errors. Of course, some more research should be done to confirm or deny this, but my basic point is that same. Again, I'll state that just because it appears in headers for other compilers, does not make it a trueism for all compilers. Mark There is 1 Reply. #: 16323 S3/Languages 27-Aug-92 21:11:45 Sb: #16319-#Your July article Fm: Bob van der Poel 76510,2203 To: Mark Griffith 76070,41 (X) Mark.... A few clarifications: First, I don't have a 'self-assumed role as a teacher'. I'm just a guy writing a few articles for which I get paid zip. So don't be too hard on me. Second, it's interesting that 'The C Users Journal', Sept/92 issue (which I just received) talks about this very point: "So we defined pointer to void as a generic data-object poitner type. It has the same representation as a character pointer, but much more lax conversion rules. In fact, you can convert between a void pointer and any other data-object pointer type without writeing a type cast. That gives the behavior we wanted for function arguments and return values." Third, I think that you might be getting a bit confused between void functions and void pointers. They are quite different. Fourth, there really shouldn't be any confusion for new C learners. They just have to follow my instuctions and add the malloc.h header file. Since I'm using void* there aren't any problems with compiling other programs, including stuff ported from other systems. Lastly, as to the tone of your initial comments and my replies.... well, that's best just left alone. There are 2 Replies. #: 16327 S3/Languages 28-Aug-92 14:42:19 Sb: #16323-Your July article Fm: Mark Griffith 76070,41 To: Bob van der Poel 76510,2203 (X) Bob, I realize you arn't doing these articles for the money. What I mean when I say "self-assumed role as a teacher" is, you, as the author of an article that is showing (teaching) readers how to use termcap in their programs assume the role as a teacher whether you want to or not and whether you get paid or not. In that context, you and you alone are responsible for the content of your articles, right or wrong. Many readers will see you and what you write as gospel because they know no better and assume that you are giving them the correct information. That is the point I am trying to make. You treat the use of the void pointer in your article only with a rather glib reference that it makes the compiler stop complaining and that is all. It deserves more to prevent reader confusion. Take it from me, this will still happen no matter how clear you try to make it, so at least try and clear it up for most of the readers even if all of them won't understand. Again, I say just because the ANSI committiee comes out with a void pointer for their own innane reasons--and it happens to work on the OSK compiler, which was designed long before then ANSI committiee was done haggling over the name of their still-yet-to-be standard--doesn't mean you should assume it and the other ANSIisums will work without some trouble down the road. Now, if the OSK compiler was billed as being fully ANSI compliant, that would be a different matter. By doing this, you may be setting up a reader to assume that it is ANSI compliant. Now this may not be your intent or your fault, but it would be a result of using ANSI type statements with a non-ANSI compiler and inferring that this is OK. Again, your role as a teacher puts you in the position to insure these sort of things do not happen as a result of what you say. At the least, I think you should make a better explaination of it in your next column, and in the future, make notes that any ANSI statements you use are flagged as such and they may or may not work on the compiler the reader is using. Lastly, no, I know the difference between a void pointer and a void #: 16328 S3/Languages 28-Aug-92 14:53:24 Sb: #16323-#Your July article Fm: Mark Griffith 76070,41 To: Bob van der Poel 76510,2203 (X) (harrrrrump---truncated message) Lastly, no, I know the difference between a void pointer and a void function. My point is the READER my not and assume the two are the same. Again, your responsibility to be clear. You said before that is perfection is what is called for, then we should fire all the teachers and learn it ourselves (or something like that). Well, if you put yourself in the position as an authority, you need to make your cases pretty well or someone will try to shoot you down. That is NOT what I am doing though. If I had wanted to do that, I would have written a letter the the editor, and got my thoughts published so everyone would see how much smarter I was (I speak sarcastically there). (I mean, I don't think I'm smarter, but that people how do those stupid things think this is how they will be perceived). I chose to mention it here, in this rather obscure and little noticed forum, so as to not offend. No one except the regulars comes in here anyway anymore. Of course, if I had posted a reply on Delphi, the discussion created would go on for years (bleah) 8^) Lastly and lastly, voicing my opinion has nothing to do with my religion. Does being a religious person make posting a little "gruff" message any worse than a teacher that posts misleading information? MArk There is 1 Reply. #: 16337 S3/Languages 29-Aug-92 21:39:11 Sb: #16328-Your July article Fm: Bob van der Poel 76510,2203 To: Mark Griffith 76070,41 (X) I was wondering what to write about after the termcap series was finished. Guess I'll do something on declarations, header files, void pointers, etc... #: 16315 S3/Languages 27-Aug-92 02:54:32 Sb: #16297-Your July article Fm: Mike Haaland 72300,1433 To: Mark Griffith 76070,41 (X) Whoa Marky, It's standard practice in Sys V. So what's your real beef? I understand you don't agree. It's OK, really. Pesonally I have never even thought about it since I always explicitly cast malloc() and the likes to the type it's being used for. But the OSK compiler handles it fine. "Outside the scope of OSK" is misleading and inaccurate in itself. I too agree that it's more readable and clearer to grasp what's going on if you cast malloc(), but it's seems to be a matter of semantics, no? Let's leave the verdict out. You may see 'void *malloc()' in the ANSI release of the Microware C compiler. ;-) - Mike - #: 16298 S10/OS9/6809 (CoCo) 25-Aug-92 20:22:04 Sb: #Rammer help Fm: BOB LEET 72020,2536 To: Kevin Darling 76703,4227 (X) Kev, I understand most everything in your message, except, should I put the RAMMER in the Boot File then? Or, should I just load it from the startup file at the end? Are you on Internet or BITNET? What are your Emial addresses? I am in Engineering at ASU and will be getting on the machines there soon. Also, do you happen to know Zack Sessions addresses? I need to send him a message. Thanks, Bob////// There is 1 Reply. #: 16304 S10/OS9/6809 (CoCo) 26-Aug-92 01:31:02 Sb: #16298-Rammer help Fm: Kevin Darling 76703,4227 To: BOB LEET 72020,2536 Bob, Yes sir, you got it. Put Rammer and R0 in the bootfile. That way, it'll take up just a tiny bit of space in the kernel map (64K section). Yah, I'm on the internet but you can also send mail from there to anyone here. All you have to do is change the user number comma to a period, and tack on CompuServe's name. Eg: Your CIS address would become... 72020.2536@compuserve.com Zack should be back here on CIS soon, btw (he's gotten a job :-) In the meantime, you should be able to reach him at: session@seq.uncwil.edu You can go to MAIL and send him a message from there. When CIS asks you for the address, give: >INTERNET:session@seq.uncwil.edu Don't forget the ">" at the beginning. Pretty neat, being connected like this! kev #: 16310 S12/OS9/68000 (OSK) 26-Aug-92 09:43:22 Sb: #16173-#MM/1 Mouse Fm: Paul K. Ward 73477,2004 To: GLEN HATHAWAY 71446,166 (X) Glen, We are checking on it. What you might want to do in the meantime is write me a letter to our DC address that describes EXACTLY what your sound setup is. Best, Paul IMS There is 1 Reply. #: 16325 S12/OS9/68000 (OSK) 27-Aug-92 22:00:39 Sb: #16310-MM/1 Mouse Fm: GLEN HATHAWAY 71446,166 To: Paul K. Ward 73477,2004 Hi Paul... Have you had any other reports of the mouse behavior I described? I'll repeat in case you don't remember: When I power up, the mouse almost always doesn't work until I unplug it and plug it back in (while powered up). Once I've done this, it works perfectly until I power down and back up again. Once in a while it work after a power up, but not usually. The mouse is a Logitech Mouseman (not a cheapy) Model #M-CJ13-9F. I'm using a driver from the sedr0705.ar? upgrade - CRC $6E508C , Edition #6. This is a MicroSoft compatible mouse. I assume you got my messages about the mouse pointer movement stuff? #: 16331 S1/General Interest 29-Aug-92 09:16:07 Sb: #Atlanta CoCofest? Fm: Ken St.Clair 71615,267 To: All Are they having a CoCofest in Atlanta this year? If so, can anyone tell me where I can get more info about it. Thanks in advance! Ken There is 1 Reply. #: 16336 S1/General Interest 29-Aug-92 16:25:30 Sb: #16331-Atlanta CoCofest? Fm: Kevin Darling 76703,4227 To: Ken St.Clair 71615,267 (X) Yes, I believe it's October 3-4, at the same Atlanta/Northlake Holiday Inn. Ticket price is only $5 for the whole show. Instead of having fancy expensive booths, they've decided to offer minimal trappings: a table with electricity and a chair are $25 each. $1 more per extra chair. Heck, at that price, they should just charge $30 for entry and give *everyone* who comes a booth! Then we could all sit and wave at each other The hotel number is 1-800-338-9889, mention COCOFEST to get rates of ~$54 per night, king or twin doubles. People wanting a booth are supposed to send a note about their desires and include payment (but not for tickets) to: Atlanta Computer Society, Inc. P.O. Box 80694 Atlanta , GA 30366 #: 16334 S12/OS9/68000 (OSK) 29-Aug-92 12:37:49 Sb: source_part 1 Fm: LARRY OLSON 72227,3467 To: Kevin Darling 76703,4227 (X) /* p_dis4.c */ /* a program to display palette info */ #include #define STDIN 0 #define STDOUT 1 #define STDERR 2 main() { int path = STDOUT; /* stdout */ int x, y; int f_col, b_col; int curx, cury; int numofpals = 1; /* read 1 palette at a time */ int palnum; int clutoffset; unsigned char palbuf[48]; /* this should only need to be 3 */ /* but 3 doesn't work, 6 or more works ? */ /* I should only be getting 3 bytes back */ /* from _gs_palette */ f_col = 15; b_col = 0; x = 168; y = 56; curx = 10; cury = 5; DefColr(path); /* reset all palettes to default */ Palette(path, 10 * 3, 210, 105, 30); /* palette register 10 (*3) */ FColor(path, f_col); BColor(path, b_col); Clear(path); CurXY(path, curx, cury); printf("Palette # R G B \n"); curx = 17; cury = 7; for ( palnum = 0; palnum < 16; palnum++ ) { f_col = palnum; if ( f_col == b_col ) f_col = 15; CurXY(path, curx, cury); FColor(path, f_col); printf("%2d\n", palnum); fbox(path, x, y, palnum, b_col); FColor(path, f_col); clutoffset = palnum * 3; _gs_palette(path, clutoffset, palbuf, numofpals ); CurXY(path, curx + 7, cury); printf("%3d %3d %3d\n", palbuf[0], palbuf[1], palbuf[2] ); y = y + 8; cury = cury + 1; } exit(0); } #: 16335 S12/OS9/68000 (OSK) 29-Aug-92 12:39:31 Sb: #source_part 2 Fm: LARRY OLSON 72227,3467 To: Kevin Darling 76703,4227 (X) /* draw and fill a box at location xloc,yloc */ /* if foreground = background put white box around color box */ fbox(path, xloc, yloc, fcol, bcol) int path,xloc,yloc; int fcol,bcol; { int xloc2, yloc2; xloc2 = xloc + 11; yloc2 = yloc + 5; if ( fcol == bcol ) { SetDPtr(path, xloc -1, yloc -1); FColor(path, 15); Box(path, xloc2 +1, yloc2 +1); } SetDPtr(path, xloc, yloc); FColor(path, fcol); Bar(path, xloc2, yloc2); return 0; } There is 1 Reply. #: 16340 S12/OS9/68000 (OSK) 29-Aug-92 23:57:56 Sb: #16335-#source_part 2 Fm: Mike Haaland 72300,1433 To: LARRY OLSON 72227,3467 (X) Larry, I sent you mail about your source, with the corrections. Lemme know if you have any questions about the changes. - Mike - There is 1 Reply. #: 16341 S12/OS9/68000 (OSK) 30-Aug-92 02:02:49 Sb: #16340-source_part 2 Fm: LARRY OLSON 72227,3467 To: Mike Haaland 72300,1433 Mike, Got the mail and tried it, still no go. I sent some mail back with a little more explanation of what the program is doing. The program in this form doesn't do much, but I have plans on expanding it into something alot more useful, but I can't do anything if I can't get this simple part to work. still puzzled larry #: 16339 S12/OS9/68000 (OSK) 29-Aug-92 21:39:31 Sb: #New drives Fm: Bob van der Poel 76510,2203 To: all Does anyone know if the new 2.88 meg 3.5" drives being advertised for the DOS machines will work with the mm/1? Sounds like they just drop into a pc... Are the disks different than the 1.44? From what I understand the number of sectors per track is doubled on these, so there must be a line to toggle to get into the hd mode...or maybe it just senses another hole on the disk??? There are 2 Replies. #: 16342 S12/OS9/68000 (OSK) 30-Aug-92 09:00:04 Sb: #16339-New drives Fm: Jay Truesdale 72176,3565 To: Bob van der Poel 76510,2203 (X) Your theory about another hole on the disk to indicate ED (extended density) mode is correct. The disk media surface is different from that used in the 1.44 media and is currently expensive (remember that it was the same way when 1.44 drives were new). The number of sectors per track (on a PC) is doubled from 18 to 36. These drives will work in a PC but the controller must be able to specifically support the 1000 KB data rate required by the ED drive for the 2.88 media, most PC controllers do not support the 2.88 drives. Dalco (see computer shopper) and other vendors sell PC controller capable of using the 2.88 drives. The lower density media are usable in the 2.88 drives at their lower capacity. MS-DOS V5.0 properly supports the 2.88 drives if the PC floppy controller does. Sooo, if the MM/1 floppy disk controller supports the 1000 kb data rate then the drives should be usable on the MM/1. -J #: 16343 S12/OS9/68000 (OSK) 30-Aug-92 09:06:45 Sb: #16339-New drives Fm: Jay Truesdale 72176,3565 To: Bob van der Poel 76510,2203 (X) One more thing... They changed the way that the drive reports to the controller what density media is installed in the disk drive. On our custom hardware this limited us to three drives maximum which may or may not be the case on the MM/1. (I've got the drive manuals at work and I'm not even going to try and guess at the changes via memory! Grin!) -J #: 16344 S10/OS9/6809 (CoCo) 30-Aug-92 11:05:40 Sb: #15797-PCDOS Fm: Chris Bergerson 72227,127 To: Lee Veal 74726,1752 Yep. Same brick wall I ran in to. The two major benefits I was looking forward to with my no-halt controller were background floppy formatting and faster PCDOS transfers. No such luck! #: 16345 S12/OS9/68000 (OSK) 30-Aug-92 20:41:40 Sb: Windio for MM/1 Fm: GLEN HATHAWAY 71446,166 To: 76703,4227 Hi Kevin... Just curious - what's the latest revision of Windio for MM/1? I'm using #38 at the moment. What's new and improved in later version(s)? When do you think you'll be ready to release the latest and greatest version? Do you plan to fix it so we have most or all of our function-keys working? Hope so. I can live without F9 and F10 (we need 2 keys somewhere to change windows), but it seems kinda dumb to have the rest doing nothing. The reason I'm asking is that I'm working on a paint program and would like to have the latest system stuff so I don't have to rewrite too much when you get it solid. I'm also bugging Mike Haaland, because his cgfx.l isn't finished yet either, and my program relies heavily on it. Glen Hathaway - COMPER - 71446,166 Press !>