823 lines
25 KiB
Plaintext
823 lines
25 KiB
Plaintext
|
|
||
|
|
||
|
#: 16650 S12/OS9/68000 (OSK)
|
||
|
11-Oct-92 12:07:39
|
||
|
Sb: #gifsho
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Mike,
|
||
|
|
||
|
I've been playing with Gifsho to view CompuServe Weather maps and am scratching
|
||
|
my head over the displayed size of the graphic.
|
||
|
|
||
|
With the recent change to the Maps area, I now can select a VGA resolution
|
||
|
(Item 1) and download a map as usual.
|
||
|
|
||
|
When I display with gifsho, I get a nice looking map ... but it's very narrow
|
||
|
and centered in the middle of my type 0 screen. Is this correct or should I
|
||
|
be using a different combination of screen type and resolution?
|
||
|
|
||
|
What follows is the output from a gifsho -i on a recently downloaded file:
|
||
|
|
||
|
GIF version '87a'
|
||
|
378 x 240 screen
|
||
|
Global bitmap : 16 colors
|
||
|
Image 378 by 240, Top 0, Left 0
|
||
|
Interleaved Image - 4 bits per pixel
|
||
|
|
||
|
|
||
|
Have any suggestions?
|
||
|
|
||
|
Steve
|
||
|
|
||
|
There are 2 Replies.
|
||
|
|
||
|
#: 16672 S12/OS9/68000 (OSK)
|
||
|
13-Oct-92 21:35:52
|
||
|
Sb: #16650-#gifsho
|
||
|
Fm: Bill Dickhaus 70325,523
|
||
|
To: Steve Wegert 76703,4255 (X)
|
||
|
|
||
|
Steve,
|
||
|
|
||
|
It looks to me like the EGA and VGA maps are the same (I checked this out on my
|
||
|
PC at work as well as on my MM/1). Maybe they intend to provide better
|
||
|
resolution in the future. Gifshow has always (at least for me) displayed the
|
||
|
weather map as a narrow picture in the middle of the screen. It also won't
|
||
|
handle more than one file at a time without ending with an error. A command
|
||
|
like "gifshow current.gif tomorrow.gif 48hour.gif -s" displays the first map, a
|
||
|
few lines of the second map, then ends with the error: "illegal code in raster
|
||
|
data". Each of the maps displays just fine by itself.
|
||
|
|
||
|
Bill
|
||
|
|
||
|
There are 2 Replies.
|
||
|
|
||
|
#: 16675 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 02:51:28
|
||
|
Sb: #16672-#gifsho
|
||
|
Fm: Mike Haaland 72300,1433
|
||
|
To: Bill Dickhaus 70325,523 (X)
|
||
|
|
||
|
|
||
|
Thanks for the input. If the picture happens to be a different number of bits
|
||
|
per pixel, something doesn't get reset in my decoder. I just have to track it
|
||
|
down. :( I've got the same report from several sources and have run into the
|
||
|
problem myself. Can't for the life of me figure this one out. <sigh>
|
||
|
|
||
|
Hopefully it will be something really simple I overlooked.
|
||
|
|
||
|
- Mike -
|
||
|
|
||
|
PS If all the pictures are the same res (bits per pixel) then they will work
|
||
|
in slide show mode forever.
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16678 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 06:35:28
|
||
|
Sb: #16675-#gifsho
|
||
|
Fm: Bill Dickhaus 70325,523
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
I wondered what caused it to happen, since I do know that the slide show works
|
||
|
sometimes. I didn't really notice it until I tried to display three days of CIS
|
||
|
weather maps in a row.
|
||
|
|
||
|
I know all about hard to find bugs (right Steve? :) good luck!
|
||
|
|
||
|
Bill
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16692 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 00:02:05
|
||
|
Sb: #16678-gifsho
|
||
|
Fm: Mike Haaland 72300,1433
|
||
|
To: Bill Dickhaus 70325,523 (X)
|
||
|
|
||
|
|
||
|
Thanks. I'll keep scratching my head till something 'clicks'.
|
||
|
|
||
|
#: 16687 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 14:07:53
|
||
|
Sb: #16672-gifsho
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Bill Dickhaus 70325,523 (X)
|
||
|
|
||
|
Glad it's not just me, Bill. I was begining to wonder! :-)
|
||
|
|
||
|
Looks like Mike well into it ...
|
||
|
|
||
|
|
||
|
|
||
|
*- Steve -*
|
||
|
|
||
|
|
||
|
|
||
|
#: 16677 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 02:51:52
|
||
|
Sb: #16650-#gifsho
|
||
|
Fm: Mike Haaland 72300,1433
|
||
|
To: Steve Wegert 76703,4255 (X)
|
||
|
|
||
|
|
||
|
I just grabbed a few maps and see what you mean. The maps are in the old 87a
|
||
|
format and don't have an aspect ratio built into the file.
|
||
|
|
||
|
GIFShow thinks it's a clipping from a 640 x 240 screen and displays it on a 640
|
||
|
x 240 screen. That's why it's long an narrow in the middle of the screen.
|
||
|
Wonder why they picked such a weird size for the maps. 320 x 240 would fill
|
||
|
the entire screen as expected. GIFShow makes a decision to center the picture
|
||
|
if it's greater than 368 pixels wide. It's being displayed on a type 2 screen.
|
||
|
Have you run into many 378 x 240 GIFs before? Maybe I need to up the deciding
|
||
|
width by 10, huh!
|
||
|
|
||
|
- Mike -
|
||
|
|
||
|
There are 2 Replies.
|
||
|
|
||
|
#: 16679 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 06:35:48
|
||
|
Sb: #16677-gifsho
|
||
|
Fm: Bill Dickhaus 70325,523
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
I've noticed that the weather maps are a strange size. Some of the viewers I've
|
||
|
used on other machines have similar problems trying to scale the picture to
|
||
|
match the screen, others seem to figure it out. Maybe the addition of the VGA
|
||
|
mode means they will start providing higher resolution, and standard sized,
|
||
|
pictures.
|
||
|
|
||
|
Bill
|
||
|
|
||
|
#: 16686 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 14:07:49
|
||
|
Sb: #16677-#gifsho
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Mike,
|
||
|
|
||
|
I rarely spend much time with gif files. The two notable exceptions are the
|
||
|
weather maps and the stuff displayed over in the MQUOTE area.
|
||
|
|
||
|
The only problem with the financial stuff is they provide no way to capture the
|
||
|
display to a file, and only provide for decoding on the fly. I'm bashing Mark
|
||
|
to add such a feature to StermPro.
|
||
|
|
||
|
You have any ideas for work arounds with something like this (o wizzard of the
|
||
|
gif format!) :-)
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
*- Steve -*
|
||
|
|
||
|
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16691 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 00:01:53
|
||
|
Sb: #16686-gifsho
|
||
|
Fm: Mike Haaland 72300,1433
|
||
|
To: Steve Wegert 76703,4255 (X)
|
||
|
|
||
|
|
||
|
Only idea I have is to make gifshow force 16 color 378 pixels wide or less to
|
||
|
full screen. But I've run into GIFs that are 370 x 240 and look perfect when
|
||
|
displayed like the weather maps are. But I think they were all 256 colors.
|
||
|
|
||
|
I'll play with it.
|
||
|
|
||
|
#: 16652 S12/OS9/68000 (OSK)
|
||
|
11-Oct-92 15:02:50
|
||
|
Sb: #lha and pause
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Mike,
|
||
|
|
||
|
With pause on in a window, I find that Lha pauses after about 6 extractions
|
||
|
rather than the value I have set in the descriptor.
|
||
|
|
||
|
Is there an easy fix you can point me to in the source?
|
||
|
|
||
|
Steve
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16673 S12/OS9/68000 (OSK)
|
||
|
13-Oct-92 21:36:10
|
||
|
Sb: #16652-#lha and pause
|
||
|
Fm: Bill Dickhaus 70325,523
|
||
|
To: Steve Wegert 76703,4255 (X)
|
||
|
|
||
|
Steve,
|
||
|
|
||
|
I think that's because of the status display of 'o's moving across the screen.
|
||
|
I can't think of any way around that (other than an option to disable that
|
||
|
status display).
|
||
|
|
||
|
Bill
|
||
|
|
||
|
There are 2 Replies.
|
||
|
|
||
|
#: 16676 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 02:51:42
|
||
|
Sb: #16673-#lha and pause
|
||
|
Fm: Mike Haaland 72300,1433
|
||
|
To: Bill Dickhaus 70325,523 (X)
|
||
|
|
||
|
|
||
|
Right, the status line get's written thusly:
|
||
|
|
||
|
filename - ................
|
||
|
|
||
|
Then LHa writes a CR without a LF and writes the filename again,
|
||
|
|
||
|
filename - o...............
|
||
|
^
|
||
|
The cursor just stays at the current 'o' till the file is decoded, then
|
||
|
writes another CR, clears to 'o's and tells you it's been melted.
|
||
|
|
||
|
filename - Melted
|
||
|
|
||
|
So, you have 3 CR's for every file extracted. So, It'll pause after
|
||
|
1/3 screen cause SCF has gotton a full screen of CR's.
|
||
|
|
||
|
- Mike -
|
||
|
|
||
|
I don't have a patch for it, but the sources are here.
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16685 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 14:07:44
|
||
|
Sb: #16676-lha and pause
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Thank for the info Mike. Looks like the best bet is to turn off the pause when
|
||
|
using Lha.
|
||
|
|
||
|
|
||
|
*- Steve -*
|
||
|
|
||
|
|
||
|
|
||
|
#: 16684 S12/OS9/68000 (OSK)
|
||
|
14-Oct-92 14:07:41
|
||
|
Sb: #16673-#lha and pause
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Bill Dickhaus 70325,523 (X)
|
||
|
|
||
|
Yeah ... I figured it had something to do with a CR/LF issue ... just didn't
|
||
|
know where to start looking in the source.
|
||
|
|
||
|
Looks as if the fastest solution would be a tmode nopause!
|
||
|
|
||
|
|
||
|
|
||
|
*- Steve -*
|
||
|
|
||
|
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16698 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 16:17:56
|
||
|
Sb: #16684-#lha and pause
|
||
|
Fm: Mark Griffith 76070,41
|
||
|
To: Steve Wegert 76703,4255 (X)
|
||
|
|
||
|
Steve,
|
||
|
|
||
|
Why have pause turned on at all? I know you might want people dialing it to
|
||
|
have pause enabled so you can set it on in the terminal descriptors, but you
|
||
|
can turn it off for all the window descriptors. The 'more' utility is better
|
||
|
anyway since you can backup and just. You might want to try using 'less' from
|
||
|
the TOPS distribution. It has all that more has only more (or less). ( grin)
|
||
|
|
||
|
Mark
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16706 S12/OS9/68000 (OSK)
|
||
|
16-Oct-92 05:34:37
|
||
|
Sb: #16698-lha and pause
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Mark Griffith 76070,41 (X)
|
||
|
|
||
|
Having pause turned on is just a habit I've gotten into. I probabbly should
|
||
|
just turn 'em all off and leave it at that.
|
||
|
|
||
|
|
||
|
*- Steve -*
|
||
|
|
||
|
|
||
|
|
||
|
#: 16653 S12/OS9/68000 (OSK)
|
||
|
11-Oct-92 17:34:25
|
||
|
Sb: #16644-OSK Login Shell ??
|
||
|
Fm: Bob van der Poel 76510,2203
|
||
|
To: Robert Heller 71450,3432 (X)
|
||
|
|
||
|
Have a look at the code in sysgo.ar which is here in lib 12. It starts up the
|
||
|
original shell and I not some comments in the source about special things to do
|
||
|
a startup shell. Let us know the secret if you figure it out.
|
||
|
|
||
|
#: 16696 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 15:44:46
|
||
|
Sb: #16644-#OSK Login Shell ??
|
||
|
Fm: Roy J. Fehlandt 73377,1605
|
||
|
To: Robert Heller 71450,3432 (X)
|
||
|
|
||
|
The magic required back in the days of V2.2 was as follows:
|
||
|
char *argv [2];
|
||
|
argv [0] = "-shell";
|
||
|
argv [1] = NULL;
|
||
|
os9exec(oskfork, 1 + argv [0], argv,...); This will do it. When shell
|
||
|
sees the leading '-' on it's forked named (passed as it's argv[0]) it will read
|
||
|
the .login file. Before the fork, you should already have chd'd to the
|
||
|
directory where .login is to be found.
|
||
|
|
||
|
Roy
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16703 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 20:46:56
|
||
|
Sb: #16696-OSK Login Shell ??
|
||
|
Fm: Robert Heller 71450,3432
|
||
|
To: Roy J. Fehlandt 73377,1605
|
||
|
|
||
|
After looking at the sysgo.a file, I sorta figured out the "-" magic. It would
|
||
|
be nice if MicroWare documented this. BYW: your method still works for V2.4.
|
||
|
(I figured you would need to chd, setuid, etc. before the fork - snarf the info
|
||
|
from /dd/sys/password, which is obviously what login does...)
|
||
|
|
||
|
Robert
|
||
|
|
||
|
#: 16654 S9/Utilities
|
||
|
11-Oct-92 20:06:31
|
||
|
Sb: help
|
||
|
Fm: George Hendrickson 71071,2003
|
||
|
To: all
|
||
|
|
||
|
Does anyone know if the HyperIO utilitys 'hdir', 'hcopy', 'hdel' will work on
|
||
|
an MSDOS disk? If so, what do I set the '-t','-s', and '-g' commands too on the
|
||
|
command line? Thanks!
|
||
|
|
||
|
#: 16657 S15/Hot Topics
|
||
|
12-Oct-92 10:11:03
|
||
|
Sb: #16645-#New Video for KiX\30
|
||
|
Fm: JBM Electronics 71174,3442
|
||
|
To: Frank Hogg of FHL 70310,317 (X)
|
||
|
|
||
|
Is 1 MB RAM enough for millions of colors at 1024 X 768?
|
||
|
|
||
|
What about 1024 X 1024?
|
||
|
|
||
|
If you are going to make a 'high end' video board it seems reasonable to want
|
||
|
'high end' sound as well. I'd say if it will fit, put the stereo sound on the
|
||
|
video board. Maybe you could make it an optional daughter board that would plug
|
||
|
on to the video board?
|
||
|
|
||
|
-J Truesdale
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16660 S15/Hot Topics
|
||
|
12-Oct-92 23:02:07
|
||
|
Sb: #16657-#New Video for KiX\30
|
||
|
Fm: Frank Hogg of FHL 70310,317
|
||
|
To: JBM Electronics 71174,3442 (X)
|
||
|
|
||
|
|
||
|
>>Is 1 MB RAM enough for millions of colors at 1024 X 768? Yes, at 8 bits per
|
||
|
pixel 3/4+ meg is enough. All those colors come from the RAMDAC (palatte
|
||
|
controller) Just like the EK_VAX.
|
||
|
|
||
|
>>What about 1024 X 1024? Not on this board. That would require a very high
|
||
|
cost monitor and I don't think that is our market at this time. When the
|
||
|
monitors come down we can quickly do a new board to match.
|
||
|
|
||
|
Thanks for you input on the sound. Space may be the big problem. A daughter
|
||
|
board strikes me as a cluge. I would rather do a separate sound board that
|
||
|
could do much more, like MIDI. That way it would not 'require' a particular
|
||
|
video board for use. Also it could be used in a terminal system.
|
||
|
|
||
|
Frank Hogg -- FHL
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16663 S15/Hot Topics
|
||
|
13-Oct-92 05:08:53
|
||
|
Sb: #16660-#New Video for KiX\30
|
||
|
Fm: Stephen Seneker 75020,3611
|
||
|
To: Frank Hogg of FHL 70310,317 (X)
|
||
|
|
||
|
Frank, I'm hooked on AUDIO, espically high end. Perhaps a seperate board
|
||
|
with 8/16 bit bidirectional stereo or quad would be nice. If it has stereo
|
||
|
sound support I'll buy... just depends on what develops %-)
|
||
|
|
||
|
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16668 S15/Hot Topics
|
||
|
13-Oct-92 19:52:07
|
||
|
Sb: #16663-New Video for KiX\30
|
||
|
Fm: Frank Hogg of FHL 70310,317
|
||
|
To: Stephen Seneker 75020,3611
|
||
|
|
||
|
Well, The EK-VAX has stereo support and should be somewhat better than what you
|
||
|
are used to. The separate board for sound etc has appeal to me as it would
|
||
|
allow upgrading video without having to rebuy sound capabilities. Video is a
|
||
|
fast moving area with prices dropping and capabilities increasing. Sound on the
|
||
|
other hand seems more stagnant. Once you have a good sound board you wouldn't
|
||
|
need to upgrade it. Not as often as video anyway.
|
||
|
|
||
|
Frank
|
||
|
|
||
|
#: 16658 S15/Hot Topics
|
||
|
12-Oct-92 10:11:08
|
||
|
Sb: #16646-#RAM for the KiX\30
|
||
|
Fm: JBM Electronics 71174,3442
|
||
|
To: Frank Hogg of FHL 70310,317 (X)
|
||
|
|
||
|
I'd suggest allowing for the use of higher density static RAMs if at all
|
||
|
possible. They are REAL pricy now but later....
|
||
|
|
||
|
Can you get EPROMs fast enough so they won't slow the system down?
|
||
|
|
||
|
-J. Truesdale
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16661 S15/Hot Topics
|
||
|
12-Oct-92 23:02:39
|
||
|
Sb: #16658-RAM for the KiX\30
|
||
|
Fm: Frank Hogg of FHL 70310,317
|
||
|
To: JBM Electronics 71174,3442 (X)
|
||
|
|
||
|
|
||
|
>>I'd suggest allowing for the use of higher density static RAMs if at >>all
|
||
|
possible. They are REAL pricy now but later.... Later when that are not pricy
|
||
|
we could do a board for them. However even then the current 32K ones would be
|
||
|
much cheaper.
|
||
|
|
||
|
>>Can you get EPROMs fast enough so they won't slow the system down? No the
|
||
|
board would have a jumper you would set for the speed of the chips in each
|
||
|
bank.
|
||
|
|
||
|
Frank Hogg -- FHL
|
||
|
|
||
|
#: 16662 S12/OS9/68000 (OSK)
|
||
|
13-Oct-92 05:05:53
|
||
|
Sb: #MM/1 Sound Utilities
|
||
|
Fm: Stephen Seneker 75020,3611
|
||
|
To: 76070,41 (X)
|
||
|
|
||
|
Mark, about what you said... now that I've thought about it, you must have got
|
||
|
the very first hrecord/hplay - the buffering routine needing fine tuning.
|
||
|
Remember the presently SNDDRV only supports a max. of 30720 Hz and only
|
||
|
multiples supported by the timer. If you use and adequate buffer size or
|
||
|
multiple for hiffplay/hiffrecord one should be able to use their system without
|
||
|
noticeable problems. If your drive seeks sufficiently fast then smaller
|
||
|
buffers/multiples are ok, else use larger buffers. I've recored up to 15
|
||
|
minutes while working on mplay and compiling. I'm only using a ST296N 1.1
|
||
|
meg/sec, 15 minutes at 20KHz Stereo for 36meg of monophonic sound.
|
||
|
|
||
|
I suggest you download the newer hrecpla.lzh fron dl12. I will be releasing
|
||
|
the functions I've developed for sound recording as shareware perhaps? Or
|
||
|
maybe I should just sell them. I'm getting quite a library... YES I'm going to
|
||
|
have to write docs, just so I can live/work with myself! %-)
|
||
|
|
||
|
Also, I thought in the quick help I had the correct command line arg setup
|
||
|
documented. Try... hrecord -f=<freq> -b=<size> -s=<seconds> you can optionally
|
||
|
omit the equal though I support both. All Version 1.01 of the utilites has
|
||
|
this corrected!
|
||
|
|
||
|
Try the newer stuff out and let me know how it works with slower drives,
|
||
|
espically using larger buffers.
|
||
|
|
||
|
Stephen
|
||
|
|
||
|
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16664 S12/OS9/68000 (OSK)
|
||
|
13-Oct-92 09:57:06
|
||
|
Sb: #16662-#MM/1 Sound Utilities
|
||
|
Fm: Mark Griffith 76070,41
|
||
|
To: Stephen Seneker 75020,3611
|
||
|
|
||
|
Steve,
|
||
|
|
||
|
I did download the lastest utilities you uploaded. What I get is "skipping"
|
||
|
during the playback. Now, whether that is due to the record or the playback
|
||
|
utility I have no way of knowing. In either case, I suspect it is due to my
|
||
|
rather slow hard disk, only about 300KB a sec on writes and about 700KB a sec
|
||
|
on reads. I'll try it again with the parameters you gave and see what happens.
|
||
|
|
||
|
Mark
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16666 S12/OS9/68000 (OSK)
|
||
|
13-Oct-92 14:10:31
|
||
|
Sb: #16664-MM/1 Sound Utilities
|
||
|
Fm: Kevin Darling 76703,4227
|
||
|
To: Mark Griffith 76070,41 (X)
|
||
|
|
||
|
Mark,
|
||
|
|
||
|
Yah, it'll also depend on disk fragmentation. Try copying to a ramdisk and
|
||
|
playing from there to see if the skip goes away.
|
||
|
|
||
|
kev
|
||
|
|
||
|
#: 16667 S12/OS9/68000 (OSK)
|
||
|
13-Oct-92 19:10:00
|
||
|
Sb: Programmer Available
|
||
|
Fm: steve mann 71310,1742
|
||
|
To: All
|
||
|
|
||
|
OS9/68K Programmer available. Three years of OS9 experience in imbededded
|
||
|
processor development. Experience includes C and Assembler, porting and device
|
||
|
driver development. Overall experience: 16 years as software engineer, mostly
|
||
|
in imbedded processors; 8085, 8088, and most recently, Motorola 68000.
|
||
|
Participated in hardware design and development. Current position is as
|
||
|
Software Group Leader with three engineers reporting to me. Available in 1Q-93.
|
||
|
Prefer western location, permanent positions only. Please respond to Steve
|
||
|
Mann, CIS 71310,1742 Prodigy GPGJ06B or Email to smann@peck.com
|
||
|
|
||
|
#: 16688 S1/General Interest
|
||
|
14-Oct-92 19:45:22
|
||
|
Sb: #PKW
|
||
|
Fm: Hugo Bueno 71211,3662
|
||
|
To: All
|
||
|
|
||
|
Has Paul Ward dropped from CIS? I was looking for his number in the member
|
||
|
directory, and CIS says no such user.
|
||
|
|
||
|
Hugo
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16689 S1/General Interest
|
||
|
14-Oct-92 22:01:05
|
||
|
Sb: #16688-PKW
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Hugo Bueno 71211,3662 (X)
|
||
|
|
||
|
Hugo,
|
||
|
|
||
|
It's been a couple of weeks, but Paul still drops by regularly. His ID is
|
||
|
[73477,2004].
|
||
|
|
||
|
Steve
|
||
|
|
||
|
#: 16699 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 16:24:47
|
||
|
Sb: #Desktop hacks
|
||
|
Fm: Mark Griffith 76070,41
|
||
|
To: Mike Haaland, 72300,1433 (X)
|
||
|
|
||
|
Mike,
|
||
|
|
||
|
When can I expect to see a version of Desktop that opens a text file in the
|
||
|
editor? Shouldn't bee too much of a hassle I would think. Also, can you add
|
||
|
an 'attr' selection to one of the menus to allow changing the file attributes?
|
||
|
I'll do the attr utility for you, just have it call 'attr' and not open any
|
||
|
screens or other windows. Attr will run in an overlay. Still working on the
|
||
|
'gpr' utility for you. Printing is worked at so it runs in the background. I
|
||
|
could set it up so it would call the printing utility of the users choice in
|
||
|
case someone has one they like better. What do you think? Of course, they
|
||
|
could just rename their favorite printing utility to 'print' and it would work
|
||
|
as long as it would take a parameter for the filename and.....naw, too many
|
||
|
other options that it would get passed. Forget it (grin).
|
||
|
|
||
|
Mark
|
||
|
|
||
|
There are 2 Replies.
|
||
|
|
||
|
#: 16704 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 23:56:05
|
||
|
Sb: #16699-#Desktop hacks
|
||
|
Fm: Mike Haaland 72300,1433
|
||
|
To: Mark Griffith 76070,41 (X)
|
||
|
|
||
|
|
||
|
Hmmm. I've thought about it and want to know what you think. Say the first
|
||
|
click on a data file enables the open.. option on the files menu. If you select
|
||
|
open, it will try to run it as a shell script, if you double click instead it
|
||
|
opens the file into the program specified by the environment variable EDITOR.
|
||
|
|
||
|
Or would it make more sense the other way around?
|
||
|
|
||
|
- Mike -
|
||
|
|
||
|
The Attr utils sounds neat. How about gattr to differentiate from the regular
|
||
|
attr. Your talking a point-n-click attr right?
|
||
|
|
||
|
There are 2 Replies.
|
||
|
|
||
|
#: 16707 S12/OS9/68000 (OSK)
|
||
|
16-Oct-92 10:59:00
|
||
|
Sb: #16704-Desktop hacks
|
||
|
Fm: Steve Wegert 76703,4255
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Mike,
|
||
|
|
||
|
Lemme tag on here and answer a few of your CMAIL questions.
|
||
|
|
||
|
Given the choices you've presented regarding the handling of a shell script,
|
||
|
I'm more comfortable with the following:
|
||
|
|
||
|
Douple clicking infers execution ... so execute the thing.
|
||
|
|
||
|
OPEN infers examination .. so fire up the editor and let's take a peek.
|
||
|
|
||
|
|
||
|
But!
|
||
|
|
||
|
I think Mark's original suggestion is the most elegant. If the execute bit is
|
||
|
set, we can presume it to be something that needs to execute ... shell script
|
||
|
or application. If it's a read only thing ... then let's fire up the editor and
|
||
|
examine the contents.
|
||
|
|
||
|
If I, as the operator, need to modify an exisiting shell script, I'd select the
|
||
|
file, use 'gattr' and turn off the execute bit(s), then double click the icon
|
||
|
to bring it up in the editor.
|
||
|
|
||
|
Of course I'm a user (unable user, to use a Delphi term, sheesh!), so what
|
||
|
appears to be a no brainer to me may be unobtainable programatically.
|
||
|
|
||
|
What do you think?
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
*- Steve -*
|
||
|
|
||
|
|
||
|
|
||
|
#: 16709 S12/OS9/68000 (OSK)
|
||
|
16-Oct-92 16:24:39
|
||
|
Sb: #16704-#Desktop hacks
|
||
|
Fm: Mark Griffith 76070,41
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Mike,
|
||
|
|
||
|
What you might want to do is make up a separate icon for a shell script and put
|
||
|
that up when you see a text file that has the execution bit set. Of course,
|
||
|
this may make things more dofficult. I don't know how you are doing it now,
|
||
|
I'd guess you look for any file with the execution bit set and make that a
|
||
|
program and then anything else is a text file.
|
||
|
|
||
|
I've been playing with Open Look version 3 on one of the Sun workstations at
|
||
|
work. It has a different icon for each file. It must read each and every file
|
||
|
to do this thought since it can tell the difference between a "C" source code
|
||
|
file and a header file, as well as a postscript file and a normal text file.
|
||
|
Pretty slick! Each icon type then gets a different set of parameters for
|
||
|
forking and printing. I don't think this will be easy to do for OSK, if at
|
||
|
all, but it sure would be nice!
|
||
|
|
||
|
To answer your question, like Steve said, if it has the execution bit set, and
|
||
|
the first few bytes in the file are not a module header, then make it a shell
|
||
|
script, other wise it is a text file. If you double click on a text file, run
|
||
|
the editor given in the EDITOR environ variable, or run thhe script if it is
|
||
|
not a text file.
|
||
|
|
||
|
Mark
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16711 S12/OS9/68000 (OSK)
|
||
|
17-Oct-92 04:10:24
|
||
|
Sb: #16709-Desktop hacks
|
||
|
Fm: Ed Gresick 76576,3312
|
||
|
To: Mark Griffith 76070,41 (X)
|
||
|
|
||
|
|
||
|
Mark,
|
||
|
|
||
|
> I've been playing with Open Look version 3 on one of the Sun workstations at
|
||
|
> work. It has a different icon for each file. It must read each and every
|
||
|
> file to do this thought since it can tell the difference between a "C"
|
||
|
> source code file and a header file, as well as a postscript file and a
|
||
|
> normal text file. Pretty slick! Each icon type then gets a different set
|
||
|
> of parameters for forking and printing. I don't think this will be easy
|
||
|
> to do for OSK, if at all, but it sure would be nice!
|
||
|
|
||
|
You can do this under OSK. G-WINDOWS has this feature. The file icon
|
||
|
shows the name of the file and what type it is; i.e., "C", "ASM", "PROG",
|
||
|
"SUBR", "SYS", etc. Since there will be files G-WINDOWS doesn't recognize,
|
||
|
you can write your own file recognizer program and add the info to the
|
||
|
'config' file. Sample source code for a file recognizer program is included.
|
||
|
|
||
|
Have at it <g>.
|
||
|
|
||
|
Ed Gresick - DELMAR CO
|
||
|
|
||
|
|
||
|
|
||
|
#: 16705 S12/OS9/68000 (OSK)
|
||
|
15-Oct-92 23:56:38
|
||
|
Sb: #16699-#Desktop hacks
|
||
|
Fm: Mike Haaland 72300,1433
|
||
|
To: Mark Griffith 76070,41 (X)
|
||
|
|
||
|
|
||
|
On the gpr util. Should that be brought up by selecting Printer Device? and
|
||
|
print be brought up by chooseing print on the files menu?
|
||
|
|
||
|
Strike that first option, the name should probably be changed to Printer on the
|
||
|
deskmenu.
|
||
|
|
||
|
- Mike -
|
||
|
|
||
|
There is 1 Reply.
|
||
|
|
||
|
#: 16708 S12/OS9/68000 (OSK)
|
||
|
16-Oct-92 16:16:25
|
||
|
Sb: #16705-Desktop hacks
|
||
|
Fm: Mark Griffith 76070,41
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Mike,
|
||
|
|
||
|
Call 'gpr' when you select "print
|
||
|
|
||
|
errrrrr.....opps...
|
||
|
|
||
|
Call "gpr" when you select "print" after clicking on a file. I'll try to do
|
||
|
some fancy work and determine if the file is a printable file or a binary file
|
||
|
and then exit with an error message if it is binary.
|
||
|
|
||
|
Setting up the printer port should be a separate utility, like the "port" util
|
||
|
in Multi-Vue. All the printing utility will do is allow the user to select
|
||
|
some page layout defaults like margins, headers, and such and then call the
|
||
|
printing routine passing these settings as command line parameters. The "port"
|
||
|
utility should allow the user to setup the device descriptor a la
|
||
|
xmode.....turn on/off linefeed, set the printer device, and so forth. The
|
||
|
"port" utility should be smart enough to change the fields shown depending upon
|
||
|
if it is a serial or paralle port being configured.
|
||
|
|
||
|
What do you think?
|
||
|
|
||
|
Mark
|
||
|
|
||
|
#: 16710 S1/General Interest
|
||
|
16-Oct-92 22:25:07
|
||
|
Sb: KiX\30 Ships!
|
||
|
Fm: Frank Hogg of FHL 70310,317
|
||
|
To: all
|
||
|
|
||
|
KiX\30 Update 10/16/92
|
||
|
|
||
|
FLASH!
|
||
|
|
||
|
The first KiX\30 production board was shipped today! One day, just ONE day
|
||
|
behind schedule! We are now in full production with orders being filled within
|
||
|
2-3 weeks.
|
||
|
|
||
|
The EK-4S2P is now in production with first shipment expected within a week.
|
||
|
|
||
|
|
||
|
In other news...
|
||
|
|
||
|
The original specs called for all SIMMs to be the same type. Both banks had to
|
||
|
be the same. This is no longer true. You can now mix memory types. For example
|
||
|
you could have 4 one meg SIMMs and 4 four meg SIMMs. In addition you can now
|
||
|
use 512K and 2 Meg SIMMs. It is even possible to mix SIMMs within a block. The
|
||
|
block will then take on the size of the smallest SIMM. If you have 2 one meg
|
||
|
SIMMs and 2 four meg SIMMs you will have 4 meg total.
|
||
|
|
||
|
See the full descriptions of the KiX\30 in the databases 'DL15'.
|
||
|
|
||
|
Thank You
|
||
|
|
||
|
Frank Hogg -- FHL
|
||
|
|
||
|
|
||
|
|
||
|
#: 16712 S3/Languages
|
||
|
17-Oct-92 21:53:27
|
||
|
Sb: #16649-Jump tables in C
|
||
|
Fm: David Breeding 72330,2051
|
||
|
To: Mike Haaland 72300,1433 (X)
|
||
|
|
||
|
Thanks, Mike. Just read a message from him in mail. He told me about the
|
||
|
articles. I'll check them out.
|
||
|
It was great getting to meet you in Atlanta. Had a really good time.
|
||
|
|
||
|
Press <CR> !>
|