textfiles/messages/ALANWESTON/1992/CIS08_30.txt

#: 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 <stdio.h>  /* 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 <grin>. 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 <stdlib.h> as returning pointers of type VOID. Since OSK doesn't
use <stdlib.h> I took your advice and used the unix standard of having a
<malloc.h> 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 <does> 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 <grin>

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 <stdio.h>

#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 <CR> !>