informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/messages/ALANWESTON/1990/os907_28.txt

2682 lines
87 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
30802 20-JUL 20:47 Patches
RE: GSHELL+ (Re: Msg 30799)
From: MINIFREAK To: AARONS
In addition to what Zack said, you DO have a copy of "save". It is merged to on
of the other files in the CMDS dir of the original MVue disk. I don't remember
exactly which file, but it was toward the end. Just IDENT them until you find
it, then load that file, then you can save save to break it free. :>
Randy
-*-
30803 20-JUL 21:12 Device Drivers
CRASHED HARD DRIVE
From: DKIRCHER To: ALL
I did something terrible to my hard drive. I was fiddling around with setting
my J&M hard drive up for a direct os9 boot off the hard drive and something
happened to the root directory of the tandy 15 meg drive. It now returns an
error 15 and shows the directory switched off in the attributes (_serwpeprpw)
Now before I dump it as a file with /h0@ and start that horrible salvage
operation, I'd like to try to defeat the security and toggle that directory
indicator TRUE. Presumeably the interior file system is still intact. I think it
might work and I really have nothing to loose. Anyone out there in delphi land
got any ideas???
I've been playing with disassembling the attr command with the hope of perhaps
modifying it for the task, but as you have already guessed I'm not a programmer.
No Dennis, I wasn't using Last Word. Thanks DLK
-*-
30817 21-JUL 16:16 Device Drivers
RE: CRASHED HARD DRIVE (Re: Msg 30803)
From: GREGWATHEN To: DKIRCHER
I had the same problem once. The only thing I can suggest is to check out the
directory entry with DeD. That was how I fixed mine. I don't remember exactly
how, but it took about 2 days to get it working. Good luck, maybe some others
here have better suggestions.
>>> Greg W <<<
-*-
30829 22-JUL 02:58 Device Drivers
RE: CRASHED HARD DRIVE (Re: Msg 30817)
From: DKIRCHER To: GREGWATHEN (NR)
DeD??? is this a COCO# utility. I've been away for a long while and still run
level one coco II Thanks for the reply dlk
-*-
End of Thread.
-*-
30804 20-JUL 21:14 General Information
RE: No FORMAT after 1-Meg upgrade! (Re: Msg 30783)
From: MRGOOD To: RADARBUZZ
As far as boot order, I don't think there's one magic solution. I do know that
you should keep all RBF related modules in the same8K memory block.
-*-
30805 20-JUL 21:41 General Information
RE: shell+ 2.1 (Re: Msg 30571)
From: JASONEABY To: TIMKOONCE
Got it, thanks. Makes a lot more sense now. I understand the 8k point quite
well, I just never knew Shell needed space to check files. Oh well, live and
learn
-Jason
-*-
30841 22-JUL 13:13 General Information
RE: shell+ 2.1 (Re: Msg 30567)
From: MAREK To: TIMKOONCE
Is there a venewer version of Ron Lammardo's Shell+ aboue 2.1? I got that
impression reading a the response you gave in the referenced message.
-Michael
-*-
30842 22-JUL 15:04 General Information
RE: shell+ 2.1 (Re: Msg 30565)
From: EDDIEKUNS To: JASONEABY (NR)
I'm reading this about 2 weeks after you left it, so someone may already have
said this...
Just remember that when you have a file that's 16k-512bytes long of merged
utils, that whenever you use any one of them, the entire 16k is mapped into the
upper 2 blocks of the process space. For example, let's say you have shell,
copy, and a bunch of other things merged so that they are just under $3E00 bytes
long. Now, you invoke 'copy.' The entire FILE of merged utils is mapped into
the top two blocks of the 64k process space for 'copy.' This means that you can
give copy no more than 48k of data memory. (I know. "darn" But you see what
I'm saying, right? <Grin>)
Note that this also applies to your OS9Boot!!! Whenever you try to map in a
device descriptor with a program ... you map in your entire OS9Boot file! If
you have a huge one like mine (over 32k! I've got to trim it down) then you'll
need 5 free blocks in your process space before you can link to a device
descriptor.
And in case no-one else has described why... Why the '-512bytes'? Well, when
OS-9 is creating a process (giving it it's own 64k map to play with ... mapping
in the memory blocks containing the executable and putting them at the top of
memory ... mapping in free memory blocks at the bottom of memory for data), it
must keep the top 512 bytes free and unused for memory-mapped I/O, just like
under RSDOS where all I/O is deal with in the top 512 bytes of memory. So if
you have a file which would overlap the top 512 bytes, then OS-9 maps the
executable in one block lower, leaving the top block empty and giving you one
less block available for data. (Except for certain exceptions when you map
stuff in and OS-9 will map them in in the top block, but you can get bitten here
if you extend this stuff (get-put buffers, modules (?)) into the top 512 bytes
and write over the memory-mapped I/O registers!)
Eddie
-*-
30843 22-JUL 15:13 General Information
RE: shell+ 2.1 (Re: Msg 30567)
From: EDDIEKUNS To: TIMKOONCE
Actually, I merged a bunch of short things with Shell and managed to keep it
under $1E00. Here's what I have merged with Shell:
21 $11 $B8E5A3 . Shell
3 $11 $2C8A4B . DeIniz
2 $11 $5FE04A . Display
5 $11 $F5FF9A . Echo
3 $11 $392347 . Iniz
5 $11 $F63DA0 . Link
4 $11 $267381 . Load
1 $11 $FB5CC0 . pwd
1 $11 $644025 . pxd
3 $11 $8F769A . Save
2 $11 $09DFC1 . Unlink
I have a bunch of other utilities merged into two other files each under $1E00.
(I know that you understand the above! :) You message was a good place to
reply to tho to post this in this thread.)
Eddie
-*-
30860 22-JUL 21:52 General Information
RE: shell+ 2.1 (Re: Msg 30841)
From: TIMKOONCE To: MAREK
No, version 2.1 is the newest I know of. What you probably caught was a
reference to the fact that I'm still using ver 2.0 right now. I just haven't
gotten around to getting 2.1 installed.
- Tim
-*-
30877 23-JUL 18:33 General Information
RE: shell+ 2.1 (Re: Msg 30842)
From: ZACKSESSIONS To: EDDIEKUNS
I guess that's why Kev mentions in his book that even though the "ideal size" of
a merged file is (8K * N) - 512, where N ranges from 1 to 7, he follows that up
with, "Actually, N should be kept around 1, if possible."
Zack
-*-
30878 23-JUL 18:37 General Information
RE: shell+ 2.1 (Re: Msg 30860)
From: ZACKSESSIONS To: TIMKOONCE (NR)
Actually, Tim, there is a newer version, only it's running only on a few systems
around the country. We got a glimpse of it at the Chicago fest last April
running on (naturally) Ron Lammardo's system during the "Mona Lisa" demo.
Zack
-*-
End of Thread.
-*-
30806 20-JUL 22:28 General Information
RE: Shell+ (Re: Msg 30793)
From: RAGTIMER To: XLIONX
Good, Mark -- thanks for confirming what I think I said about malloc(), how it
takes only from un-assigned memory, so the more you #K, the LESS you have for
malloc().
I'm sure this bass-ackwards behavior of malloc confuses lots of folks -- I saw a
deservedly well-respected OS9 expert say here that malloc only takes from
assigned memory. That is, he was 100% wrong! I have no idea how malloc coaxes
that extra memory out of OS9, but it works.
Talk about kicking hornets -- Umuse3 se3 calls malloc, maps get/put buffers,
links in subr modules, runs a VDG screen (horrors!), and forks off another
process (Fran) with a pipeline down its throat! It's a real tribute to OS9-L2
that my mess runs at all! Hornets, roaches, Lyme ticks -- we find 'em all.
-*-
30812 21-JUL 01:09 General Information
RE: Shell+ (Re: Msg 30806)
From: XLIONX To: RAGTIMER
It's all in the wrist <grin>! I have studied the UNIX version of alloc (Yes that
ALLOC with an 'A') found in the K&R 'C' Language manual. It is most informative.
Malloc just makes system calls to F$Mem (I think). This would work as if you had
just added a block to the "HEAP-STACK". This is totaly seperate from the memory
size found in the header (like when you IDENT a module and see it's data size).
THIS little piece of information DATA SIZE is DIRECTLY related to the 'Program
#nnK' option.
If you like to use COPY #48k <source> <dest>, you could change the header info
to call that many pages in ALLWAYS. Not so good if you run a tight user area.
Knot1 wrote quite a nice program called 'cp' that uses dynamic memory allocation
for the COPY function. I hope anyone that likes very functional utilities checks
this one out!
-gotta run -nice chatting with you! -mark
-*-
30834 22-JUL 08:33 General Information
RE: Shell+ (Re: Msg 30746)
From: BRIANWHITE To: MIKEHAALAND
Mike,
The "message" I was referring to was in fact the "copyrighted" patch posted by
Paul for Shell+. Besides being indignant about that patch being solely and
completely his (when I had seen part of it before), he was woefully ignorant as
to how OS-9 L2 mana ges memory. He described assigning an 8k block to a process
as being a "huge waste". Well, as I said to him, it is not a waste. OS-9 L2
assigns a whole 8-k block to a process anyways! There is no harm is the process
knowing about extra memory that is
there and there is absolutely no system memory or process map space wasted!
Now I'll assume that, based on the facts of this case, that the C call malloc()
does nothing but use the F$MEM call to increase the data space required by the
program. Since malloc() assumes that any memory given on startup is required
for global mem/st ack space (A logical assumption, I'll admit) and additional
memory is wasted. Sooo... It is still the program that isn't making use of the
aditional space. Sure, you can trace the blame back to the Shell for doing
something unexpected by the program, but it is still the program that doesn't
use the memory it is given efficiently.
As for the mapped-block problem descibed in your message, it would seem the
Shell+ would cause absolutely no problems since the program you described took
the whole 8k data space to begin with. Now, if you were to say that a 2k data
space program that l ater requested 5k more (as is the general case with all the
problem software in point), then, yes, there is a problem because Shell+ gave 8k
in the beginning for a total of 13k.
Finally, I do not disagree with you. The jist of your thoughts are 100%
correct. I only pointed out that the comments made by Paul were, in fact,
wrong. It is, in fact, the programs, not the shell, that is wasting the memory
it is given. As for the d ispute as to whether Shell should have given the
extra memory, I only pointed out that the creators of Shell+ did some thinking
ahead about what could be done with the leftover data space. Telling programs
that don't care would make no difference. Tell ing programs that checked their
available data space would. Okay, so they didn't think quite far enough about
programs that didn't expect the space but still requested more. If I seemed to
take a side on this, I appoligise because I didn't mean to. I was just trying
to be fair.
Brian
(And you did mean to flame at me... otherwise you wouldn't have sent the
message.)
-*-
30835 22-JUL 08:33 General Information
RE: Shell+ (Re: Msg 30786)
From: BRIANWHITE To: RAGTIMER
Mike,
Hey... Thanx for the support! Check out my last message to Mike Haaland about
some things I was thinking.
I think the main problem of all this stems from the F$MEM call (whick I'd bet
malloc() uses). Which is used to expand a data space as the program desires.
Some programs just weren't written to use space given at the start and expect to
allocate it as n eeded.
I wonder how the OS-k C compiler will do things. If malloc() does the eqivalent
of the F$MEM, then there is the chance that any new programs started after yours
will eat the data space you need to malloc() and your program will fail. Maybe
it will just
do a non-contiguous memory allocation, except that Kev said it was only
possible to do 31 of those. Hmmm... Maybe malloc() will be intelligent and try
to expand memory and then if that fails it would try to expand the last
non-contiguous block it allo cated (assuming an alloc has been done previously
and it is possible to expand them). Then if it still fails, it would allocate a
new non-contiguous block. Actually, I guess that even if the given malloc()
doesn't do that it would pretty easy to write our own malloc() that would. Boy,
the realloc() could be a pain, though...
Brian
-*-
30845 22-JUL 15:58 General Information
RE: Shell+ (Re: Msg 30806)
From: GREGL To: RAGTIMER
Mike,
I've just sent the malloc() source code to you via Mail. As you can plainly
see, and as I was telling you earlier, it does use existing allocated memory
before it requests new memory. It handles this by using a linked list to form a
chain of memory allocation requests. The only problem I can forsee is whether or
not the startup code (cstart.a) is initializing the chain to reflect the total
free memory to begin with. But, hey, don't take my word for it - go look at the
code yourself.
I suspect the whole process is getting off on the wrong foot by using an
unitialized chain. The only way I can see to fix that is to declare the chain
global (instead of static) and forcing the startup code to initialize it. That
is most likely where the trouble is coming from.
-- Greg
-*-
30847 22-JUL 16:10 General Information
RE: Shell+ (Re: Msg 30845)
From: GREGL To: RAGTIMER
Mike,
I just looked at the code again. It appears that if the beginning of the
chain is zero (uninitialized), it calls sbrk(). sbrk(), in turn, examines its
own local variable to see if it is zero. If it is, it initializes it with memtop
(stored as a global variable in cstart), initializes all free memory to zero,
and returns the free memory size to malloc().
All of this, by the way, is in Carl Kreider's version of the library which
is a lot less buggy and cleaner than the original Microware library. If you are
using Microware's version of the library, take two Exlax and switch. <grin>
-- Greg
-*-
30850 22-JUL 17:38 General Information
RE: Shell+ (Re: Msg 30787)
From: EDDIEKUNS To: RAGTIMER
Well, KBCom is huge and isn't hurt by shell+'s 8k memory allocation! As I
remember it, you only get the shell+ treatment if your default data size is
under 8k, right? If so, then that's why KBCom doesn't get bit, because its
default data size is just over 9k. (KBCom hard-allocates at compile time all
the memory it KNOWS it will need for internal structures so I don't waste memory
in malloc's overhead to keep the linked lists of memory.)
When you say: copy file1 file2 #8k
you don't mean "add 8k to the default amount," you mean "fork 'copy' with either
8k of memory or the default data size, whichever is bigger." Right?
Eddie
-*-
30863 22-JUL 22:08 General Information
RE: Shell+ (Re: Msg 30786)
From: TIMKOONCE To: RAGTIMER
I suspect it's only a problem with malloc(), or the occasional assembly program
that uses F$Mem to request more memory. Setting the #31 won't allocate a new
block, and linking in modules or G/P buffers always involves a separate block.
- Tim
-*-
30927 28-JUL 00:49 General Information
RE: Shell+ (Re: Msg 30835)
From: RAGTIMER To: BRIANWHITE
Yer welcome. Yes, you reminded me -- the C compiler stages were the first
programs I remember that alloc'ed all the space they needed, and did not benefit
froma any #nnK you might give. In fact, now we guess they might SUFFER if you
gave extra on the command line.
Anyway, I found the source (Kreider's?) in my mailbox.
Realloc(), which we don't have but Un*x does, will do whatever is necessary to
return a sold block (to you) of space, AND recopy whatever data you already had
in its previous incarnation. --mike k PS: Who sez there's no RESEARCH in
Computer "Science", grin?
-*-
30928 28-JUL 00:55 General Information
RE: Shell+ (Re: Msg 30845)
From: RAGTIMER To: GREGL
OK, I'll read it and weep, grin. Scary to think there's an uninit static in
there. Actually, I KNOW there is a static that's initialized in the usual
startup data stuff, just as when you declare "int foo = 1;". In fact I think
there are 4 bytes of init'ed static in malloc() family.
Question is, are they init'ed correctly? I still feel that malloc() starts off
just beyond my process's header allocation, finishing off that 8K block's
leftover space, then grabbing more 8K blocks above that, which OS9-L2 makes look
like contiguous memory space to my process.
My own tests show that by giving more stack space, I take away from what malloc
() can get. Wonder if Carl Kreider remembers how the darn thing works?
-*-
30929 28-JUL 00:58 General Information
RE: Shell+ (Re: Msg 30847)
From: RAGTIMER To: GREGL
Why should I take Exclax? My wife can afford a full-sized coffin, grin! I mean
my widow.... Well, now we're getting somewhere. Since alloc()'s static
variables are Inited class, they must be(?) init'ed to something nonzero. What,
I wonder...?
BTW, I've been using Kreider's first C lib for years -- but haven't switched to
the second edition yet. Should, to get some of his new additions.
-*-
30930 28-JUL 01:02 General Information
RE: Shell+ (Re: Msg 30850)
From: RAGTIMER To: EDDIEKUNS (NR)
I think you are right about the 8K thingie. Actually, I COULD just pre-declare
my one big array used by a file-reading subroutine, and throw malloc() out
completely! But I keep it around in case some OTHER funciton needs some
tempoorary stuff. I mean more than I want to throw on the Stack.
Did y'all know that malloc() will gladly hand out memory already allocated to
your VDG screen? Another singing commercial for "real" windows...
-*-
30931 28-JUL 01:05 General Information
RE: Shell+ (Re: Msg 30863)
From: RAGTIMER To: TIMKOONCE (NR)
Yeah, it's a malloc-related problem. The extra Shell+ allocation causes
mallaoc() to map in another 8K block to satisfy its needs, so now you don't have
the spare 8K blocks needed to map in modules and buffers.
Tho somehow the exact symptoms in Umuse3 didn't support this -- will have to
simulate it myself and refresh my memeory.
-*-
30935 28-JUL 01:15 General Information
RE: Shell+ (Re: Msg 30928)
From: GREGL To: RAGTIMER
I'm not real sure on some of the points that have been brought up. The code in
cstart is "supposed" to mark the top of memory as given to it by OS-9 in the
memtop global variable and set the top of used memory in another global
variable. (May be memtop and memend?) I think what it boils down to now is
whether or not cstart is 'smart enough' to adjust the unallocated heap if given
more memory via the command line. I'm studying the code on that, but no definite
answers yet. Something is definitely strange somewhere.
-- Greg
-*-
30937 28-JUL 01:22 General Information
RE: Shell+ (Re: Msg 30929)
From: GREGL To: RAGTIMER
By the way, let me know if you find anything funny in that source I may have
missed. It definitely appears that malloc() is using a linked list to track each
of the memory allocations. So that would seem to point to either cstart or
possibly ?brk() falling down on the job if it's not picking up the extra memory.
I wonder if it's something as stupid as an unitialized variable? Nah! Just can't
be. If it's the chain pointer in malloc(), the whole system will go up in smoke
at one point or another. And it appears that ?brk() is splitting memory requests
into full 256-byte blocks, probably because of the system memory map under Level
1.
-- Greg
-*-
30938 28-JUL 01:23 General Information
RE: Shell+ (Re: Msg 30935)
From: RAGTIMER To: GREGL
Well, you have a good lead there -- maybe cstart just ignores the command-line
extra allocation? No, that would cause no troubles like we had -- must be it
mis-uses the info and gets something bolloxed up.
Mind you, this Shell+ feature never crashed Umuse3 in an ugly mess -- it just
made Umuse3 such taht no subroutine modules could be linked in, meaniong that an
extra 8K block had become unavailable.
Wonder what cstart puts in those two initialized words in the malloc() and
free() family? These may be the Heap pointers. Too bad I got my CS degrees
before heaps were invented!
-*-
30939 28-JUL 01:24 General Information
RE: Shell+ (Re: Msg 30937)
From: RAGTIMER To: GREGL
Yeah, and the SHell+ feature never "smoked" me. Mallocs()'s willingness to give
away VDG memory space is kind of annoying, tho you usually get enuf warning when
the "oil spills" start creeping down your screen....mike k
-*-
30942 28-JUL 01:58 General Information
RE: Shell+ (Re: Msg 30938)
From: GREGL To: RAGTIMER (NR)
Ok, I'm looking the cstart source now. The first thing it does is push Y (top of
memory) and U (data beginning address) and clears the direct page. It then loads
X with the data beginning address, adds in the end of BSS address (at end,x) and
pushes it onto the stack. After initializing the initialized variables, it sets
memend to the top of memory (original Y register). Hmmm... I don't see it
initializing _stbot (bottom of stack) or _mtop (top of non-stack memory) yet.
Ah, just found it. Immediately before branching to main, it sets _mtop to 'leax
end,y' and stbot to the current address of the stack - ditto for _sttop.
So that means all global variables in cstart are getting initialized properly
provided that the stack is correct when it pulls the original Y register. And
the initial memory allocation chain pointer in malloc() is initialized to zero
via 'd0000 fdb $0000' within the vsect.
Hmmmm... unless I goofed, _spare used by sbrk() is not initialized data, at
least not specifically. But, static data (which is what _spare is) is supposed
to be initialized to NULL according to K&R. So providing that the Microware
compiler is following those conventions, it should be A-OK. The first thing done
by sbrk() is to check _spare. If _spare is zero, it initializes it using memend
and rechecks the memory allocation request before attempting to allocate data.
Also, if _spare is NULL, sbrk() returns the whole kit and kaboodle of free heap
to malloc() so that it can initialize its chain.
But, like I said earlier, it looks like malloc() allocates a minimum of 256
bytes when calling sbrk() to allocate external memory. But in the case of our
story, only the free heap is used until it is exhausted. The only strange part
of malloc is its adjustment of the requested memory size:
ldd 6,u Get requested memory size
addd #3
lsra
rorb
lsra
rorb
addd #1
std 0,s Store new memory request
Offhand, I don't know why it's doing that. Add 3 bytes, effective divide by
four, and add another byte.
-- Greg
-*-
End of Thread.
-*-
30807 20-JUL 22:31 General Information
RE: os9 pascal (Re: Msg 30794)
From: RAGTIMER To: XLIONX
Sure, I'd love some more ideas for Umuse -- used to get a lot but not so many
lately. Are you thinking of a "MIDI Event" feature? I'm hoping to put that in
soon. Send me the ideas via private Email here.
OK, so that was Jeff, aka Tangerine (as in Dream?) That's some synth band I
read about in Keyboard Mag, grin.
-*-
30813 21-JUL 01:23 General Information
RE: os9 pascal (Re: Msg 30807)
From: XLIONX To: RAGTIMER
Ah sooo...yes thats the same group. You would probably like their music for at
least it's technical beauty. I listen to WNIB 97.1 FM when I drive to and from
work. Classical music 'de-stresses' me very quickly. I took piano lessons
starting at age 8 through age 14 (on and off I'm afraid).
Favorite composers: F.Liszt, F.Chopin, S.Rachmaninoff, W.Mozart, R. Schumann,
F. Schubert, Musorgsky (spelling), L.Beethoven.
As you can see, I am kinda particular ];->.
Have you downloaded RONDO.ARC yet? Listen to it if you have time. Please tell me
if you know of a better way to force an extra tripplet into a measure.
-mark
-*-
30940 28-JUL 01:28 General Information
RE: os9 pascal (Re: Msg 30813)
From: RAGTIMER To: XLIONX (NR)
OK -- those are mostly Romantic composers you like. Is T. Dream sort of
classical style?
I recall DLing Rondo, but I think that was the file in some new nonstandard
DeArc format, so I haven't cracked it yet. Have to go hunt the de-arcer.
Actually, plain old AR does a great job of crunching .UME files, which shows you
just how inefficient my score encoding scheme is, grin.
I bet a few users would love it if you re-submitted that RONDO in stock AR
format. What, me drop a hint? mike k
-*-
End of Thread.
-*-
30808 20-JUL 22:37 General Information
Bad uploads with WIZ
From: RAGTIMER To: GREGL
I'd been meaning to say something about this, but just got some more info. Many
UltiMuse3 music file uploads here have been bugged by an extra leading byte, Hex
15 or decimal 21. And then I DL'ed a huge score with a whole 128 bytes of
garbage up front.
Anyway, the author told me he'd been using The Wiz (he actually got it to work)
with "CocoBin Mode" on. He feels that mode is adding the extra bytes, so I
suggested he turn it off.
You might want to warn people not to use that mode, except when really using
CocoBin Batch (is that supported anymore?). Also I wrote a simple utility to
strip off the leading bytes, once you know how many there are. Should I upload
it? Lf~
-*-
30820 21-JUL 19:03 General Information
RE: Bad uploads with WIZ (Re: Msg 30808)
From: GREGL To: RAGTIMER
Mike,
The first time you go into the databases you get a banner warning not to use
CoCoBin if you are using Wiz. The big reason for that is that, as you've
discovered, it causes more of a hassle than it's worth. For some files I take it
"on faith" that the CoCoBin header isn't there unless I spot the header in a
dump of the file. Most of the time the CoCoBin header is fairly obvious,
especially in AR files where the first few bytes should be +AR+0.0 followed by
the filename.
There is a utility in the database dedicated to stripping CoCoBin headers
but it doesn't work on other formats - whatever they may be. If you have a
general purpose utility for doing that, feel free to post it.
Do you recall which files have the header tacked on? To date I haven't run
across any with a single by "header" so I suspect that must be garbage that went
undetected.
-- Greg
-*-
30934 28-JUL 01:14 General Information
RE: Bad uploads with WIZ (Re: Msg 30820)
From: RAGTIMER To: GREGL
Sorry, cana't remember exactly which .UME files, but one was "King of Kings
Theme" and another was by HAZEN. These had a leading $15 byte.
My utility works fine IF you know exactly how many junk bytes are up front. Last
year I uploaded a B09 utility to strip trailing junk (XModem stuff), with of
course the same restriction. But I'll upload with a little doc and source
sometime. Thanks for the response.
-*-
End of Thread.
-*-
30809 20-JUL 22:46 General Information
MAIL bug folks should know about
From: RAGTIMER To: GREGL
Greg, someone needs to broadcast a warning about the MAIL system here on Delphi.
When you are typing in a message to send someone, there is an autmoatic CR-LF
when your cursor hits the right margin of the screen, so you might just keep
right on typing.
BUT -- the MAIL program just throws away all the caracters beyond the 1st
freebie CR-LF. I've got lots of mail message consisting of part of one
sentence, with who knows how much more dead and gone to the bit bucket. I reply
to these people "Always hit ENTER at the end of each screen line", and then I
start getting complete messages from them.
Is there some way you can tell everyone about this, or mention it in the Rainbow
or something? Thanks, mike k.
-*-
30818 21-JUL 16:20 General Information
RE: MAIL bug folks should know about (Re: Msg 30809)
From: GREGWATHEN To: RAGTIMER
Mike,
I think if you turn word wrap on you will see the whole message. I've had
that problem before with people who use RS-DOS editors to write their messages
before uploading. I think the forum handles it differently, but mail doesn't
attempt to format the message for you. Anyway, give it a try and see how it
works.
>>> Greg W <<<
-*-
30821 21-JUL 19:06 General Information
RE: MAIL bug folks should know about (Re: Msg 30809)
From: GREGL To: RAGTIMER
Mike,
We've had several banners over the years warning people to hit ENTER at the
each of every line. Mail strips everything beyond the first 'freebie' CR/LF and
everything else strips beyond 255 characters unless you coerce it with carriage
returns. I'll add a new banner to warn people about that.
-- Greg
-*-
30851 22-JUL 17:49 General Information
RE: MAIL bug folks should know about (Re: Msg 30809)
From: EDDIEKUNS To: RAGTIMER
I'll mention it in a "Delphi Bureau." Thanks for the hint!
Eddie
-*-
30932 28-JUL 01:08 General Information
RE: MAIL bug folks should know about (Re: Msg 30818)
From: RAGTIMER To: GREGWATHEN (NR)
OK -- is word wrap one of your Terminal mode options, or part of Mail? I thought
the problem was people typing in mail with word wrap enabled. Well, too late to
try reading any of those messages. I know the missing lines did not show up in
my capture buffer either.
Anyhow, I noticed that GregL has installed a warning message to anyone checking
into this Group, saying to hit ENTERs. Thanks, mike k
-*-
30933 28-JUL 01:09 General Information
RE: MAIL bug folks should know about (Re: Msg 30821)
From: RAGTIMER To: GREGL
OK, thanks. I saw your new banner when I checked in tonite. --mike k
-*-
End of Thread.
-*-
30810 21-JUL 00:48 Programmers Den
RE: Problems with G/P buffers... (Re: Msg 30800)
From: XLIONX To: DODGECOLT
You got it! You can create some mighty big linked lists in 4 - 16 Meg of mem
using dynamic memory allocatioin!!!
-mark
-*-
30814 21-JUL 04:49 Programmers Den
RE: Problems with G/P buffers... (Re: Msg 30810)
From: DODGECOLT To: XLIONX
One of the problems with Ed 1.6 was that it used fixed 80 character blocks for
each element in t he list. This was EXTREMELY wasteful (kinda like 8k blocks!),
tho it was fast also. At least variable length blocks will help some for those
who stick with Level II and the 6809...
-Mike
-*-
End of Thread.
-*-
30811 21-JUL 01:02 Patches
RE: OS9 LII and GFX2 (Re: Msg 30364)
From: GLENNTHIG To: DALEP (NR)
Dale,
Thanks for the info. It's taking me a long time to reply, as my online money
has been running short. I'm in the process of buying a house right now. I'll
keep checking in to hear about the new machine developments and OS9 LII
upgrades.
Best to you also.
Glenn
-*-
30815 21-JUL 04:59 Utilities
RE: Ed (Re: Msg 30801)
From: THEFERRET To: DODGECOLT
IT is "relatively" simple to change the colors. What you have to do is change
the pallete colors. Unfortunately, thisis mainly by trial and error, to find
the right pallete. I do know that foreground and background are linked with $09
and $0d registers. to change them, pull up a shell from the file menu, and use
display 1b 31 xx yy xx is register number yy is desired color.
TA-DA! :-)
Phil B-)
-*-
30816 21-JUL 14:29 Utilities
RE: Ed (Re: Msg 30815)
From: DODGECOLT To: THEFERRET
New new version of Ed (3.0- coming RSN! :) will let you save your color
preferences so you won't have problems with mono monitors... I probably
_should_ have included this option in the original.
-Mike
-*-
End of Thread.
-*-
30822 21-JUL 23:05 Telcom
Terminal programs
From: HARLIN To: ALL
Could anyone tell me of a half-way decent terminal program that runs on level
two and doesn't require a RS-232 pac? Thanks for the help!
-*-
30823 22-JUL 00:04 Telcom
RE: Terminal programs (Re: Msg 30822)
From: TJSEAGROVE To: HARLIN (NR)
I don't know of ANY OS-9 terminal program that doesn't use an RS-232 pak.
Someone else may know of one but I don't think one exists.
....Tom
-*-
30852 22-JUL 18:15 Telcom
RE: Terminal programs (Re: Msg 30823)
From: EDDIEKUNS To: TJSEAGROVE
A shareware device driver for the bitbanger port, "bitbang" exists. You need to
make a simple modification to the cable between the bitbanger port and your
modem to enable to port to generate an interrupt on incoming bits. I haven't
gotten it to work very well myself, but others have been using it for months
with no problems.
With this device driver, any OS-9 terminal program which allows you to specify
which device to use (ie: not Telstar or WizPro) should work fine. I've heard
reports that KBCom works fine with this driver, and I can't imagine that OSTerm
or Supercomm wouldn't also. (To unravel the double negative ... I'm positive
they will! :)
Bitbang isn't on Delphi, but it is on the bitnet/internet CoCo list. It may or
may not be on CIS ... I don't know.
Also ... in the Rainbow a couple years back there was an article which described
how to turn the bitbang port into a "full" rs232 port which I have heard of many
people using successfully.
Eddie
-*-
30875 23-JUL 17:57 Telcom
RE: Terminal programs (Re: Msg 30852)
From: TJSEAGROVE To: EDDIEKUNS
I don't believe that OSTerm will work as it is hard coded to use /T2. Maybe
Vaghn could allow for the user to select which port to use in the next version
of OSTerm.
....Tom
-*-
30883 23-JUL 22:13 Telcom
RE: Terminal programs (Re: Msg 30875)
From: DWHILL To: EDDIEKUNS
In fact, I'll ask Vaughn tomorrow night at the ACS meeting about it, that's one
of the questions I'd been wondering about too. Also putting the various data
files in a COM or SYS directory instead of the working directory.
It's fun having the author around to pester! (grin)
--Damon
-*-
30892 24-JUL 21:45 Telcom
RE: Terminal programs (Re: Msg 30875)
From: EDDIEKUNS To: TJSEAGROVE (NR)
You're correct. OSTerm is hardcoded to use /t2 and the Deluxe RS232 Pak and
exact equivalents. Patches exist somewhere to change the address it pokes the
hardware at.
Eddie
-*-
End of Thread.
-*-
30824 22-JUL 00:34 Telcom
RE: OSTERM (Re: Msg 30432)
From: EDDIEKUNS To: KNOT1
Well, it's possible to make a pretty good guess about whether a file is ASCII or
binary based on the contents, but that's about it. That'w why Delphi doesn't
send a file-length for ASCII files -- so it's won't send a filelength and get a
file chopped short if you add CR's to it.
Eddie
-*-
30869 23-JUL 03:57 Telcom
RE: OSTERM (Re: Msg 30824)
From: KNOT1 To: EDDIEKUNS
Eddie,
Yes. Tim and I talked a good bit on just how to determine and convert text type
files. Well, Delphi could still include a file size, and if the terminal
program is going to fiddle with the data, then it is it's responsability to
handle the file size properly.
I hope to make a small program (probably called "fclean" or something) which
will apply these methods to a file. All you'll have to do is type "fclean
filename" and it will check if it is a text file; If so, it will then convert
LF's and strip padding characters. Great for terminal programs which don't do
this.
-Jamie (KNOT1)-
-*-
End of Thread.
-*-
30825 22-JUL 02:19 General Information
RE: os9 upgrade (Re: Msg 30463)
From: EDDIEKUNS To: TEDJAEGER (NR)
Ummm ... do you already OWN an MSDOS machine? If you don't, then you're talking
the difference between buying an MSDOS machine or buying a "CoCo-4." Not to
disagree with your main point (Hey, I'd like to see the upgrade too!), but a
worthwhile MSDOS machine (one that's upgradable without spending HUGE amounts of
money) costs.
Eddie
-*-
30826 22-JUL 02:28 General Information
RE: Buyer Beware! (Re: Msg 30475)
From: EDDIEKUNS To: XLIONX
I believe that for any credit card purchase you can call the credit card company
(within 3 months or something) and have them not pay the people to whom you
charged. Esp in a case like this. This is a nice reason to charge something.
If you pay by check ... once the check is cashed that money is GONE. If you
charge, you have time to change your mind. (Well, assuming there are problems.
I don't remember all the details.)
Eddie
-*-
30827 22-JUL 02:32 Utilities
PC-DOS
From: TOMPRATT To: BRUCEISTED (NR)
Hi Bruce,
I have found your PC-DOS program to be very useful. I recently added a
3.5" 720K drive to my CoCo 3 system. I can not seem to get PC-DOS to write a
file to a formatted MSDOS disk. I am using Version #10 of cc3disk. Can you
offer any suggestions? I notice that the docs with PC-DOS refer to Version #11
of cc3disk, however, I can't see to find that in the archived file. Hope to
hear from you soon.
TOMPRATT P.S. The drive works fine under OS-9.
-*-
30828 22-JUL 02:37 General Information
RE: Buyer BEWARE (Re: Msg 30476)
From: EDDIEKUNS To: XLIONX
Talking about Bell Telephone ... shortly after I moved to Illinois, and
coincidentally <grin> after I opened a telephone account here, I started getting
all kinds of "Welcome to the neighborhood" junk mail. What a surprise! Got, I
wonder HOW my name got on that list.
Come to think of it tho ... it's been a LONG time since someone's asked to see a
major credit card as a form of ID. Used to happen routinely several years
back... but not in a long time. I get asked all the time tho if the phone # on
my checks is accurate! <Grin> (As well as my address.) And am just about
always asked to write a phone # on VISA reciepts. I don't mind giving my phone
number. I'm in the book. I haven't been bothered much by phone-retailing,
surprisingly. (Maybe I'm just lucky?)
Eddie
-*-
30838 22-JUL 12:28 General Information
RE: Buyer BEWARE (Re: Msg 30828)
From: GREGL To: EDDIEKUNS
I'm glad someone isn't getting sucked into the phone-retailing business. My
phone has been ringing off the hook with those schmucks trying to sell
something. "Hi. This is Jill and we're prepared to make you the offer of a
lifetime...." CLICK. "How would you like to be a successful and well-paid
executive. Join our executive search club and..." CLICK. "Hiiiaa. I'm Tiffany
and I'd like to introduce you to our newest dance club featuring wild and exotic
dancers..." CLICK. I mean, this crap oughta be illegal.
-- Greg
-*-
30848 22-JUL 16:12 General Information
RE: Buyer BEWARE (Re: Msg 30595)
From: EDDIEKUNS To: MPASSER
Out of curiousity, please don't jump down my throat :), what's wrong with
putting your phone # on a credit card slip? (Unless of course, you have an
unlisted number which you wish to keep unlisted! :) Yeah, it's an invasion of
our privacy, asking for information about where we live & all. But it's one
that I don't worry about. My number's in the book. Anyone can find me, my
address, and my phone number in there.
I can clearly understand not wanting your credit card number to appear on checks
(which is something I honestly never thought about before! I was pretty
brainwashed & used to it). And that's something I'll prevent in the future.
Tho I don't mind pulling it out to prove I *have* one. (ie: am credit-worthy
and thus, ha, the check won't bounce.)
But I'm curious what gain stores can get from a phone number.
One thing I've noticed in the past year is that I've been asked less and less
for a phone number (and hardly at all for an address!) on credit card slips, and
less and less for more ID than a driver's license on a check.
Eddie
-*-
30853 22-JUL 18:27 General Information
RE: Buyer BEWARE (Re: Msg 30838)
From: EDDIEKUNS To: GREGL
I agree that there aught to be legal limit on that random calling selling. (You
DO know, right?, that many companies just call ALL numbers within a certain
range so you can get these calls even if your number is unlisted because they
hit it by chance. This is now illegal in SOME states. In others, a company
must go through paperwork to become legally allowed to do this and then they are
monitored. In others ... well, there are no limits!)
But I've been terribly lucky so far. I can only remember one call since I've
moved here (last Sept) of people trying to sell me something.
When I lived in NJ, I used to get those postcards all the time tho. "You are
guaranteed one of the following 5 prizes" and you call the number and find out
you need to buy $300 of vitamins/$500 of water purifier/whatever. I called once
out of curiousity, told them "no," and have thrown away all subsequent postcards
of this type after ripping them into little pieces.
Eddie
-*-
30884 24-JUL 01:23 General Information
RE: Buyer BEWARE (Re: Msg 30853)
From: RADARBUZZ To: EDDIEKUNS
Regarding that junk mail that tries to tell you you've "won" something or wants
to offer you that "once in a lifetime" deal, here's what I started doing
recently (snicker!): If they've enclosed a return-postage-paid envelop, then I
take all that "stuff" (including the outer envelope) and squeeze it into the
return envelope. I then write "Unsolicited Extraneous Material Returned at YOUR
Expense" somewhere visable. And back it goes! I think in the future I'm going
to add rocks, old washers, or anything else heavy, so that they end up paying
more on that "return postage".
-Jeff
-*-
30893 24-JUL 21:48 General Information
RE: Buyer BEWARE (Re: Msg 30884)
From: EDDIEKUNS To: RADARBUZZ
Hahahahahaha! <chuckle> <giggle>
That's a good one! I'll have to remember it!
Eddie
-*-
30909 26-JUL 17:31 General Information
RE: Buyer BEWARE (Re: Msg 30848)
From: MPASSER To: EDDIEKUNS (NR)
Eddie,
It's part because it's an invasion of privacy, and part because MANY bankcard
issuers require only the cardholder's name and telephone number when inquiring
about account status, available credit, balance, etc. Thus, if my phone number
were written on a charge slip, and a dishonest clerk copied the information, not
only would he or she be able to charge something fraudulently to my card, but
would also be able to call my bank and find out JUST HOW MUCH credit I had left,
so as to not either raise suspicion by exceeding the limit or to get the maximum
possible use from one stolen number. Please also note that the expiration date
is only required in credit card authorization (voice type) calls to ensure that
the clerk has actually LOOKED at the expiration date, and IS NOT a check to see
if that card is valid. The authorization center has NO IDEA what the expiration
date of the card is, only if there is enough credit left on it for the purchase
attempted. Thus, if you're told, say, for a check, "OK, well, I still have to
write the number down, but I won't write the expiration date," put no faith in
that. Hope this clarifies my stand on this a little bit!
Mike
P.S.: I wouldn't * think * of jumping down your throat! :)
-*-
End of Thread.
-*-
30830 22-JUL 03:04 Utilities
RE: database report (Re: Msg 30540)
From: EDDIEKUNS To: BOBDORRELL
Sorry for the delay in getting back to you. Between travelling and a near hard
drive crash and some other delays, I've been off Delphi for more than three
weeks.
I'm WAY ahead of you. <Grin> In the near future, the structure of the database
report in the Rainbow is going to change, and become more like a directory
listing to make it easier to find something. Any description of specific items
will be provided in the Delphi Bureau. (Whew, that last sentence reads
horribly. But at 2am when I should really be in bed (I'm just recovering from
being really sick. I had a fever of 102 all day yesterday!) I feel excused! :)
Eddie
-*-
30858 22-JUL 21:01 Utilities
RE: database report (Re: Msg 30830)
From: DWHILL To: EDDIEKUNS
I'm glad to see the database listings in RAINBOW will be organized more clearly;
wish the search function here on Delphi had a more global nature. I've found it
useful, but sometimes found what I was looking for in a subdirectory I hadn't
expected! Like the MS-DOS dearch
utility, for example.
--Damon
-*-
End of Thread.
-*-
30831 22-JUL 03:10 General Information
RE: 1 Meg problems? (Re: Msg 30548)
From: EDDIEKUNS To: RADARBUZZ
I've found that a new GIME fixed my sparklie problem right up! I have a very
old CoCo 3. (The 2nd to hit Troy, NY) So I have the old mask of the GIME chip.
With the new one ... I haven't noticed a sparklie yet!
Eddie
-*-
30832 22-JUL 04:34 General Information
RE: One Megabyte CoCo-3 !! (Re: Msg 30740)
From: CHYDE To: DWHILL
Yup, sure did. Now I can't remember what I wanted to say. Oh well couldn't
have been important I guess.
-*-
30833 22-JUL 07:58 General Information
Article correction
From: BERGMANN To: ALL
A couple of minor corrections to my article, "Life Without Line Numbers,"
in the August RAINBOW:
At offset 0213, in Listing 2,
RUN print_all_the_names (yourname,hisname,hername)
should be:
RUN PrintName2 (yourname,hisname,hername)
Also, the sense of one sentence in paragraph 2 of page 64, was changed in
editing. What I meant was, "Though I didn't doubt it was possible --- there
were all those listings, after all --- I just couldn't see how it would work."
I must say that it's certainly satisfying to see one's work get published
the first time, and I'd like to encourage others to give it a try. It's worth
the effort.
-Dean
-*-
30836 22-JUL 08:33 General Information
RE: CP (Re: Msg 30747)
From: BRIANWHITE To: KNOT1
Jamie,
Why worry about the 7.5k barrior. Your program will still only take up 1 block
for code. The only advantage you'll get from shaving the extra 512 bytes is you
posible data space will increast from 48k to 56k. I don't think you use that
much anyways, d o you?
Brian
-*-
30870 23-JUL 03:58 General Information
RE: CP (Re: Msg 30836)
From: KNOT1 To: BRIANWHITE
Brian,
Well, the Copy function of "cp" dynamically allocates memory as it is needed. If
the file were large enough it could use up to the 48K of memory available. So
using 56K would be possible. But it was coming to the point where I might have
to remove some internal integrity checks (which should *never* be used anyways
if all is working properly, but.....). I'm figuring it's not worth the extra 8K
though. So if I can't find any nicer way of squeezing the extra 512 bytes out
of it, I'll probably leave well enough alone. Thanks.
-Jamie (KNOT1)-
-*-
End of Thread.
-*-
30837 22-JUL 08:34 General Information
RE: GFX2 & MM/1 (Re: Msg 30762)
From: BRIANWHITE To: TIMKOONCE
Tim,
I really hate to dissapoint you, but the MM1 doesn't have a clock speed of 5x
faster. In fact, at 15MHz, it's barely over double. Because the 6809 uses two
clock signals, one out of phase by 90 degrees, there are 4 distinct regions of
each clock cycle.
The 68000/8088 and what-have-you don't do that. Instead, they quadruple their
clock rates. So, in reality, you have a 7.16MHz 6809 in your CoCo when
comparing to other processors. Of course, if you say you have a clock speed of
4x then you must also
quadruple the instruction execution times. That is why the 6809 instruction
"LDD #$1234" only takes 4 clock cycles while the 68000 equivalent instruction
"MOVE.W #$1234,D0" takes 16 clock periods.
Actually, in my Motorola book on the 680x0, it referrs to a clock cycle as being
made up of 4 clock periods where, for example, a 1MHz clock rate would have 1
million clock "periods" per second. Thus, the MOVE instruction above is
documented as taking 1 6(4/0) meaning a total of 16 clock periods of which 4
clock cycles are used for reading and 0 clock cycles are used for writing.
While all very confusing (It took me years to fully understand it) it does mean
that the 6809 in the CoCo 3 is running at almost the same speed as the 68000
found in the Amiga... The only (did I say ONLY) advantage the Amiga has is the
16-bit data path and loads of support hardware. The actual computing power gap
is actually quite narrow!
Brian
-*-
30872 23-JUL 16:00 General Information
RE: GFX2 & MM/1 (Re: Msg 30680)
From: PKW To: COLINMCKAY
Colin,
If you are speaking of the fest demo -- those images were DECOMPRESSED -- they
were just loading into memory buffers in the background as the show continued.
Paul
-*-
30906 26-JUL 00:50 General Information
RE: GFX2 & MM/1 (Re: Msg 30837)
From: KENHALTER To: BRIANWHITE
I was just reading your message explaining clock cycles. Very interesting! I
was wondering how my poor old under 2Mhz CoCo could stomp all over the Apple 2
plus at work (when doing the same chores). Now I know!
Is the 6809 and it's compatibles the only CPU's that have this feature?
Ken Halter
-*-
30907 26-JUL 07:07 General Information
RE: GFX2 & MM/1 (Re: Msg 30906)
From: MATHOMPSON To: BRIANWHITE
Brian,
There's a couple things you gotta remember when doing clock speed compairsons.
First of all, even with the dual-phase clock of the 6809, you only get a total
of 3.57MHz worth of clock edges inside the chip, no matter what. The real reason
a "1.78" MHz 6809 is a even match for an "8MHz" 8088 is that the 8088 and up
line is microcoded, while the 09 is uses hard-wired logic for everything. And
the reason it blows the doors off the apple is that is has a 6502 (less
registers) running at just "1MHz". Also, the 4-clock-cycle-per-bus-cycle trick
falls down for the 68020/30/40 and 80386/486. Both of these babies only use TWO
(sometimes 3) clock cycles per bus cycle. This gives a speed increase above all
the other things that have been cranked up (clock rate, register set, bus size,
etc.). I also beleive that this is the case with the 8088-2, 8086-2 and 80286-2
CPUs ie that they use 2 clock cycles per bus cycle instead of 4. Correct me if
I am wrong on this point, someone???
- Matt
-*-
End of Thread.
-*-
30839 22-JUL 12:52 General Information
RE: CoCo 4? (Re: Msg 30678)
From: PKW To: THEFERRET
Philip,
Actually, one of our systems engineers and I will be in the San Francisco area
in early August lining up a software deal. Leave me your address and phone
number -- or better, call me at the numbers I left in email. We'd be glad to see
you and show you the MM/1!
Paul
-*-
30865 22-JUL 22:24 General Information
RE: CoCo 4? (Re: Msg 30839)
From: TIMKOONCE To: PKW
Paul,
Since there are several of us OS9 hackers in the SF area, is there any way
we/you could set up a showing?? If at all possible, I'd love the chance to see
your little project, and find out a bit more about my next computer! <grin>
- Tim
-*-
30871 23-JUL 15:58 General Information
RE: CoCo 4? (Re: Msg 30865)
From: PKW To: TIMKOONCE (NR)
Gosh, Tim!
I didn't realize what a coterie of CoCo fans there were in the SF area!
Tell you what, if you can do some test marketing and get together a list of folk
willing to meet on Wednesday night August 8 (that IS a Wed, right?) then get
back to me. We'll see what we can do.
Thanks!
Paul
-*-
End of Thread.
-*-
30844 22-JUL 15:42 General Information
RE: Alias (Re: Msg 30575)
From: EDDIEKUNS To: BRIANWHITE
Hmmm... thinking...
It might be really nice to have a history in everything! Now, if there was some
way to have a history associated with a PROCESS and not a PATH... Then SCF could
have a flag: HistoryOn and if history was off it would act like it does now.
(Keeping a history one line deep) But if history were turned ON then SCF would
keep a history for that PROCESS and all shell would have to do is I$ReadLn.
I just really insist on the history list being separate for each process! 'Cause
shell (usually) forks it's children and passes on it's paths. I don't want them
to inherit the shell history! (Or for their inputs to enter the shell history)
I don't know how to tell SCF to make that distinction, which is why I proposed
the code should be in the shell. But if anyone figures it out! <Grin> Either
go and do it, or teach me and I'll go do it!
Eddie
-*-
30846 22-JUL 16:01 General Information
RE: File Attributes (Re: Msg 30578)
From: EDDIEKUNS To: BRIANWHITE
I like the way UNIX handles groups. Each file has an Owner and Group that it
belongs to. The owner and group # of the owner (the person who last changed the
file, I believe).
Basically, every person has a user ID and a "default group" upon logging in. You
have access to any file that either:
1) Has your user ID as the owner of the file and the file has the appropriate
"owner attribute" bits set (read/write/execute).
2) Has your group ID as the group the file belongs to, and the file has the
appropriate "group attribute" bits set (r/w/e).
3) Has the appropriate "world attributes" set (r/w/e).
Oh -- I should mention that the passwd file contains your default group, but
there is also a second file (/etc/groups, I think) which defines what groups a
person belongs to. You can only be IN one group at a time, but you can switch
at any time between any of the groups you have permission to belong to. I
believe some versions of UNIX allow you to belong to all groups simultaneously,
but then it's hard to figure which group # to stamp on a file when you create
it.
VMS also has extensive (much more extensive than UNIX) groups and file
protection schemes. (Access Control Lists, <Shudder>) But it's much more
*complicated* too.
With a UNIX-like scheme, you only need one set of "group" attributes, which
makes it much easier to implement!
Eddie
-*-
30849 22-JUL 17:19 General Information
RE: SASI Driver (Re: Msg 30795)
From: JANG To: KSCALES
Hello Ken-
Glad to see you are still working on that nice sounding SASI patch..
Sorry I didn't get back to you sooner, but the Heat here in the East
really slowed things down.. By the way, I'm still not able to boot into
80 Cols. I tried a wmode on my /TERM and made it into a 80 Col. window
but I guess it's not that easy.. how is it done, please ??
Jerr
y Angus (JANG)
-*-
30898 25-JUL 00:36 General Information
RE: SASI Driver (Re: Msg 30849)
From: KSCALES To: JANG
Please check your mail -- I have sent you a new version of the driver which
should solve the problem you encountered. Please let me know how things go.
Will give you tips on making /Term an 80 column window after I return from a few
days holidays (unless someone else wants to chip in here???)
Cheers... / Ken
-*-
30904 25-JUL 22:23 General Information
RE: SASI Driver (Re: Msg 30898)
From: JANG To: KSCALES (NR)
OK.. and thanks.. I will get back to you soon .. enjoy your vacation JANG
-*-
End of Thread.
-*-
30856 22-JUL 19:23 General Information
Eliminator/ST-4096
From: COLINMCKAY To: OS9UGVP (NR)
Hi, Bruce.
Just a few further notes with regards to my problem with the ST-4096 hard
drive. I am at Ken Scales' house right now. We just put the drive thru the
torture test on his system, and it works just fine, so I really don't
suspect the drive any more.
Ken has a B&B system
with an Adaptec 4096 RLL controller. The jumpers set
on the drive are the DS1 (drive select 1) and Write Fault jumpers. We
formatted the drive several times, and did a lot of copying of files, exactly
the same way as I did at home using the Eliminator. (See my previous message
for an example of the way that the directory structure was getting messed up.)
Have you any idea what the problem is? Checked my power supply (200W) under
load, and it seems to be working just fine. Exactly +12V and +5V. Don't have
a scope, so couldn't check for noise.
Also, could you please explain to me what the write fault and recovery mode
jumpers are for? And finally, is there any way to write protect the drive?
Some other hard drives have a write protect jumper available. Could be handy
sometimes.
Thanks a lot for your assistance.
Colin McKay.
-*-
30857 22-JUL 20:30 General Information
CoCo forum vs. OS-9 forum
From: EDDIEKUNS To: ALL
I noticed an interesting change this weekend. I've been away from Delphi for
just over three weeks due to a number of consecutive mishaps and other reasons.
I expected to be totally swamped by the number of messages in both SIG's!
Well, I noticed that I had just over 400 messages unread in the OS-9 SIG forum,
and slightly under 150 in the RSDOS SIG forum!
Hey, folks, this is a real switch from when I joined Delphi almost 3 years ago!
It's great to see the OS-9 SIG forum so active! I don't know if this behavior
is continuing or not, since this is the only time I've looked, but still it's
nice!
Eddie
-*-
30859 22-JUL 21:50 Graphics & Music
RE: Who did "VEFIO" ? (Re: Msg 30766)
From: TIMKOONCE To: THEFERRET
If you read "C", then get Mike Haaland's VEF utilities, which includes a
program (with complete source!) to display a VEF picture to the current screen.
The method to save a screen is essentially the same, except in reverse <grin>.
The advantage of Mike's routines is that it includes the code to support
Squashed VEF, which provides a significant improvement over standard VEF. Look
in the Graphics database to find those utilities. I don't recall the group name
offhand. Try "search VEF", then "dir" as a start.
- Tim
-*-
30861 22-JUL 21:57 Device Drivers
RE: COCO2 WORD PROCESSORS! (Re: Msg 30767)
From: TIMKOONCE To: TRIX
The thing that always bugged me was that all of the supposed WordStar clones
were so sorry. The original CP/M WordStar, now well over 10 years old, blows
any of those oh-so-recent "clones" out of the water. I'm still impressed at the
efficient screen updating of the original. If only the CoCo word processors
would learn that, maybe we wouldn't be spending half our time waiting on the
d***ed screen updates! <argh>
- Tim
-*-
30867 22-JUL 23:34 Device Drivers
RE: COCO2 WORD PROCESSORS! (Re: Msg 30861)
From: DWHILL To: TIMKOONCE (NR)
I think my favorite WP was a Wordstar clone; I'd always wondered myself why if
Wordstar could run in a CP/M environment, why the same couldn't be exactly
duplicated in OS-9? Maybe if we could get our hands on the source code...?
Why should 64K be a limit, especially when the WP program is manipulating a
ASCII file? Couldn't that be paged in and out in 8K or so blocks as needed?
Global manipulations of a large text file might get interesting (such as
resetting page breaks)...
Oughta be a way to do this!
--Damon
-*-
End of Thread.
-*-
30862 22-JUL 22:05 General Information
RE: Your 2 minute C lesson for today... (Re: Msg 30774)
From: TIMKOONCE To: RICKADAMS
Rick,
I recently got hold of the winners for the most recent International
Obfuscated C Code Contest. It's a contest where (if you can beleive it), people
TRY to write unreadable C code. They had some good ones in there, such as a
Basic interpreter in under 1500 bytes (yes, bytes) of C source, and some other
quite impressive feats. All of which deserved to win.
The Microware C compiler chokes on every single one, usually in the
preprocessor, which apparently only allocates a small buffer for the expanded
lines. Needless to say, in order to fit these puppies in under 1536 bytes of
source (the size limit for entries), they abuse the preprocessor mightily. Get
some interesting crashes when you run these things which have lines which expand
in the preprocessor to something like 1000 bytes! <grin>
- Tim
P.S. Of course, I couldn't manage to compile a couple of them even on the Unix
systems here <sigh>. Oh, well.
-*-
30864 22-JUL 22:20 General Information
RE: Your 2 minute C lesson for today... (Re: Msg 30862)
From: EDDIEKUNS To: TIMKOONCE
Tim, where could I get a copy of the obfuscated C contest?
Eddie
-*-
30866 22-JUL 22:26 General Information
RE: Your 2 minute C lesson for today... (Re: Msg 30864)
From: TIMKOONCE To: EDDIEKUNS
If you like, I'll send you a copy via e-mail. I considered uploading it to the
data base here, but since none of them will compile under MW C, it didn't seem
too useful. Better yet, look on Usenet in alt.sources, or comp.misc.sources, or
comp.unix.sources. It usually gets published in all three of those.
- Tim
-*-
30868 23-JUL 01:25 General Information
RE: Your 2 minute C lesson for today... (Re: Msg 30862)
From: RICKADAMS To: TIMKOONCE (NR)
I SAW some of the entries in the Obfuscated C Code Contest from a few years
back, and managed to compile some of them. WHEW! One of them was a program
that consisted of the digits of pi, and a few other stray characters here and
there... but it was about 99% stuff that looked like "_3.141592[654] &
3.14159..." You get the idea. And the whole source code text was arranged with
rather creative white space so that the source was in the SHAPE of a giant pi
symbol. The documentation said, "What does this program do? You'll be
surprised!"... so I suppose that it DIDN'T print out the value of pi. ;-)
Maybe it printed out log e instead? Or the square root of -1? I know, I know,
what an imagination I have. ;-)
-*-
30891 24-JUL 21:41 General Information
RE: Your 2 minute C lesson for today... (Re: Msg 30866)
From: EDDIEKUNS To: TIMKOONCE (NR)
I'll look in the usenet forums you suggested, but I don't expect much luck. My
usenet mail reader is more flaky than not.
Do you still have last year's winners around?
Eddie
-*-
End of Thread.
-*-
30873 23-JUL 16:06 General Information
RE: MAGNAVOX 8 CM 515 (Re: Msg 30704)
From: PKW To: DAVEBEAN (NR)
Hi, Dave --
You said you wer waiting for an AFFORDABLE OSK machine. How much or little is
affordable?
Paul
-*-
30874 23-JUL 16:08 Programmers Den
RE: Speeding up the coco3 (Re: Msg 30705)
From: PKW To: NES (NR)
Eric,
Is the problem with the MM/1 price (which is, I KNOW, pretty darn cheap) that it
is too high for what you're getting or is it just out of your cash flow
possibilities?
Could you better afford it if KLE/IMS offered financing?
I'm interested in hearing your thoughts on this.
Paul
-*-
30876 23-JUL 18:25 General Information
MM/1
From: 1CMR To: PKW (NR)
Paul,
Just wondering, but... Are you guys just happening to be doing a demo of the
MM/1 in Connecticut? <Preferrably in Hartford! <grin>>
---Chad
-*-
30879 23-JUL 19:08 General Information
MM/1
From: RAVENONE To: PKW (NR)
Paul,
I have a list of questions about the MM/1. I've called Interactive Media
Systems several times, but have gotten neither answers to my questions, nor the
promised phone call or mail. Thus, I've decided to try the forum.
When will the MM/1 be available, that is, when could I purchase one?
What is the cost of the system with the I/O board?
How much is the 24bit palette board? Does it have genlock?
What software is included?
What documentation is included, i.e., technical info, or just OS-9 manuals?
Does the MM/1 output sound to an amplifier or just to the monitor?
Does the MM/1 support non-interlaced graphics with a multi-sync monitor?
What graphics chip does the MM/1 use?
What is the difference between the 68070 and the 68000?
Does the expansion bus have separate 32bit address and data buses?
Will the expansion bus work at 25MHz?
How much does the expansion bus cost?
What size case does the MM/1 alone need? With bus?
When will a 68040 upgrade board be available?
What companies are producing or porting software for the MM/1?
What sort of warranty does the MM/1 come with?
Thank you for your time. I'm really looking forward to having my questions
answered.
--Robert
-*-
30908 26-JUL 07:10 General Information
RE: MM/1 (Re: Msg 30879)
From: MATHOMPSON To: ALL
Anybody who is interested on the full lowdown on the specs for the 68070 and VSC
ought to check out the file I uploaded to the database. It'll answer most of
your questions concerning capabilities and compatibilities,I created straight
from copies of the manuals fom, but I ain't telling how I got 'em <grin>.
- Matt
-*-
30915 27-JUL 19:46 General Information
RE: MM/1 (Re: Msg 30908)
From: DWHILL To: MATHOMPSON
Thank you! I've been dying to get my hands on more information on these chips.
--Damon
-*-
End of Thread.
-*-
30880 23-JUL 20:21 General Information
ST-4096/Eliminator
From: COLINMCKAY To: OS9UGVP (NR)
Hi, again, Bruce.
I called Frank Hogg today, and explained the problem with the ST-4096/Eliminator
problem. He explained that the controller can only handle 8 heads, not the
Eliminator's 9. He also mentioned that as an interim measure the drive would
work formatted with 8 boards. Finally, he mentioned that you had created a
daughter board to handle the extra head. He also gave me your phone number, so I
will call you later tonight (Monday). I will try calling about 8:00 PM, your
time.
TTYL. Colin.
-*-
30881 23-JUL 20:22 Utilities
MS-DOS utility
From: RODHARPER To: ALL
Is there a utility available for OS9 that will re-format a disk, so that it is
readable by a MS-DOS machine ?
>>Rod<<
-*-
30882 23-JUL 20:23 General Information
my previous babbling message
From: COLINMCKAY To: OS9UGVP (NR)
Whoops. Only meant to type problem once, and that was supposed to be 8 heads. Oh
well. Sorry.
-*-
30885 24-JUL 02:23 General Information
Kings Quest
From: RADICAL To: ALL
Can anyone tell me what steps are needed to get the Kings Quest to run off the
Hard drive? I followed the steps listed in the Sierra instructions, and they did
not work. Note, I may have misunderstood something, but I did try to do exactly
as they stated. I put the modules on the config disk, but they do not appear on
my selection screen, and I do not know what steps should be taken.
Thanks Len
-*-
30888 24-JUL 18:07 General Information
RE: Kings Quest (Re: Msg 30885)
From: ZACKSESSIONS To: RADICAL
The two most common problems putting KQ3 on HD are 1) not includeing the special
modules in your bootlist, and 2) not doing your tOC.txt file correctly.
Use os9gen or EZGen to insert the two extra modules, and replace your clock
module with the one supplied.
Here is my tOC.txt file:
d1 s1 v0 v1
d1 s1 v0 v2 v12
d1 s1 v0 v3 v12
d1 s1 v0 v4 v1 v14
d1 s1 v0 v5 v12 v14
d1 s1 v0 v6 v12
d1 s1 v0 v7 v11
d1 s1 v0 v8 v11
d1 s1 v0 v9 v11
Hope this helps some.
Zack
-*-
30896 24-JUL 22:55 General Information
RE: Kings Quest (Re: Msg 30888)
From: RADICAL To: ZACKSESSIONS
Thanks I will try it. Len
-*-
30911 27-JUL 01:11 General Information
RE: Kings Quest (Re: Msg 30888)
From: RADICAL To: ZACKSESSIONS
Zack, that worked fine. Two other dumb questions. Is there a way to run the
quest in a window? Do you know how to open the sa pouch of sleep dust? Thanks
Len
-*-
30913 27-JUL 18:33 General Information
RE: Kings Quest (Re: Msg 30911)
From: ZACKSESSIONS To: RADICAL (NR)
Len, even though I have the game I haven't played it enough to make any comments
on doing things like opening pouches of sleep dust, and the like. (Now, If you
have a question on how to do something in Liesure Suit Larry ... <grin>)
KQ3 runs ONLY in a VDG type window device. If you want to crank it up as a
GShell application, there is a file in the Utils lib (by me) which enables you
to do that.
Zack
-*-
End of Thread.
-*-
30886 24-JUL 05:29 Telcom
RE: Osterm (Re: Msg 29264)
From: NEWKID To: ZACKSESSIONS
Hi Zack Sorry it has taken me so long to reply to your mgs. There have been
some changes in my life. I'm still having problems with OSTerm208. I have to
use XCom9 to hook-up to Delphi. It seems that everything I do doesn't work. So,
for now will continue to use Xcom9 and use Osterm for the rest.
Thanks anyway. James
-*-
30887 24-JUL 05:31 Telcom
RE: Osterm (Re: Msg 29268)
From: NEWKID To: AJMLFCO (NR)
Thanks for your reply. I have since returned to using XCom9 to work on Delphi.
James Mc Ddaniel
-*-
End of Thread.
-*-
30889 24-JUL 19:14 Device Drivers
RE: 720K DISK DRIVE (Re: Msg 29979)
From: MARTYGOODMAN To: MCIRISH (NR)
Belatedly --- let me note that I am glad you determined the drive was bad and
got it swapped for a good one!
---marty
-*-
30890 24-JUL 21:26 Graphics & Music
Ultimuse III
From: OS9BERT To: RAGTIMER
Is there a new version of Ultimuse III out? I have version 5 (4.5). I noticed
someone put a score on the data base with a version of 6. How can I get mine
upgraded if this is so. Take care. I'm still waiting to find a decent (and
cheap) tone generator for my Clavinova piano!
Bert Schneider
-*-
30936 28-JUL 01:18 Graphics & Music
RE: Ultimuse III (Re: Msg 30890)
From: RAGTIMER To: OS9BERT
Hi Bert, nice to hear from you. Yes, you would really appreciate 4.6.1, or even
4.6.2. Point-n-shoot file selection (for those LOOOOONG file names) and
side-info files (instruments, etc.). All you're missing in those scores is the
MIDI-channel-hopper, which I bet nobody has used yet.
Anyway, call or write 2nd City and ask for the latest. Yes, you gotta ask
nowadays, until our final everything-upgrade, which everyone will get
automatically.
You want a used FB-01, or need something better? Ever fix that repeating-note
problem with the Clav? --mike k
-*-
30944 28-JUL 11:09 Graphics & Music
RE: Ultimuse III (Re: Msg 30936)
From: OS9BERT To: RAGTIMER (NR)
I repaired some cables and made some runs shorter. That may have fixed it since
I have not seen it (heard it) again. Also, do you have a quick patch so I can
get rid of the CR LR in the printer output when I get score prints? Or did you
make this an option in the setup portion of the newer versions?
I am puting on the finnishing touches of my latest software exploits, MANDEL09.
This will be a mandelbrot generation program written totally in C. It will allow
you to select an area to zoom in via a graphics cursor and box routine. I hope
to complete it soon and then port it over to the MM1. That system running 15 MHz
would sure create some great fractals (and you shouldn't have to wait a day or
two for an image). Take care.
Bert Sschneider
----strike that (extra key hit)----
Bert Schneider
(.) (o)
U
\_____/
-*-
End of Thread.
-*-
30894 24-JUL 22:27 General Information
Shell+
From: MAREK To: ZACKSESSIONS
Okay Zack....How does one go about obtaining the "new" version of Shell+?
I am drooling already! <drip....bzzzzz> Or is it only for those who know Ron?
-Michael
-*-
30897 24-JUL 23:00 General Information
RE: Shell+ (Re: Msg 30894)
From: ZACKSESSIONS To: MAREK
Obviously, you didn't get my point. Only a select few (Level 2 upgrade testers
<NOT ME!!>) have got it. And it it probably won't be released until the upgrade
is released. OH, I didn't mention the upgrade, did I? The new version of Shell+
was done explicitly (I think) for the level 2 upgrade. Bug Kev (OS9UGPRES) about
it.
Zack
-*-
30899 25-JUL 01:38 General Information
RE: Shell+ (Re: Msg 30897)
From: MAREK To: ZACKSESSIONS
maybe if _MANY_ of us bug Kev (OS9UGPRES) we might even get it uploaded here...
<no need for hint>
-Michael
-*-
End of Thread.
-*-
30895 24-JUL 22:43 General Information
Internet
From: DENNYSKALA To: EDDIEKUNS
Eddie,
Do you know if there is a coco-related news group on Internet? I recently got a
hook-in, and have been playing around with it. I have a list wi which contains
comp.sys.6809, comp.sys.m68k, comp.sys.m68k.pc, as well as groups for Atari ST,
etc. But nothing for Coco. I could swa swear that I saw discussion here
regarding a Coco newsgroup.
***** Dennis *****
-*-
30900 25-JUL 18:15 General Information
RE: Internet (Re: Msg 30895)
From: DODGECOLT To: DENNYSKALA (NR)
Yep, there is a file here in the databases describing how to subscribe to the
COCO list. Briefly, all you have to do is send a message to listserv@pucc.BITNET
containing:
subscribe coco <your name>
I think that is all that is needed, tho I subscribed a while ago and I may have
forgotten something...
-Mike
-*-
30905 26-JUL 00:18 General Information
RE: Internet (Re: Msg 30895)
From: EDDIEKUNS To: DENNYSKALA (NR)
There's a CoCo mailing list on the internet. Send the following message to
listserv@pucc.princeton.edu
subscribe CoCo Your Real Name
index coco
index os9
help
(The above 4 lines) and that will subscribe you to the "CoCo" mailing list, send
you the 2 indexes to the 2 archives, and send you a short help file. To send a
message to the list, you send to coco@pucc.princeton.edu.
So, it's there! It's just not part of Usenet.
Eddie
-*-
End of Thread.
-*-
30901 25-JUL 19:57 Telcom
OSTerm & Delphi
From: RODHARPER To: ALL
I have been having one heck of a time trying to log onto Delphi with OSTerm. I
have set my Madem to 8N1 and 7E1 and no luck yet, all I get is a lot of Garbage
or partial statements displayed to the screen.
I have not had this trouble with any other BBS or OLS.
Any ideas ??
>>Rod<<
ps....Right now I am using UltimaTerm set at 7E1.
-*-
30902 25-JUL 20:33 Telcom
RE: OSTerm & Delphi (Re: Msg 30901)
From: DODGECOLT To: RODHARPER
Well, it has been a while since I played with OSTerm, but you might try 7 bits
SPACE parity. his seems to work pretty well through TELENET, tho I think you
still need even parity through TYMNET. (BTW, I use a term program of my own
design now. I think your problem with OSTerm _could_ be that it doesn't strip
the high bit off each incoming char.)
-Mike
-*-
30903 25-JUL 22:18 Telcom
RE: OSTerm & Delphi (Re: Msg 30902)
From: CTL56 To: DODGECOLT
I have found that using 7 Mark 1 works when logging in while using OSTerm.
-*-
End of Thread.
-*-
30910 27-JUL 00:44 Telcom
OS9BBS
From: EMTWO To: ALL
David Beyer, the author of OS9BBS, has decided to put the BBS into the hands of
the general public. He will still be supporting it, since it's not complete yet,
but he wants help on the unfinished parts. This weekend I will be uploading the
primary BBS files. These are the files that Zack Sessions, Allen Huffman and I
already have. Then, Dave will release the source for the checkevents and monitor
modules. He doesn't want to give out the source for the parts of the BBS that
are already done. The first thing we need to get cracking on is the transfers
sections. Then mail tossing for the FIDO option.
I will periodically upload any updates, but there is another BBS that will
have the updates also. That BBS is called 'The Guild Info-Net,' and can be
reached at 1-407-777-8803. There is an account already setup by the name
'BBSFILES,' and a SIG called 'OS9BBS.' The SIG messages will have the BBSfiles
and updates attached to them.
************* Note:The Password for the account 'bbsfiles' is 'ONLINE' ****
Plus, once the transfer modules start to get written, I will also have the
updates at the OS9BBS Alpha Site #1, 1-407-677-8865.
P.s. Anybody know how I can convince my modem to accept 300 baud callers?
Dave's modem does this, but mine will disconnect you as soon as it determines
that your baud is 300??? 1200 & 2400 work fine, but many new users have only 300
baud, and I feel it's my fault that they can't look at my board. Any help would
be appreciated.
P.s.s. The daily thunder storms in Orlando have been getting pretty ruff, so if
the BBS isn't answering, it's because we had a power loss, and I'm not around to
reboot the system.
Paul Fitch
OS9BBS Alpha Site #1 SYSOP
1-407-677-8865
-*-
30912 27-JUL 01:21 General Information
OSK'er magazine
From: JENG To: ALL
To anyone that hasn't subscribed to the OSK'er Magazine, I recommend that they
should as soon as possible because the first issue is an excellent premiere
issue! It really fills the void with the other publications: Rainbow, Clipboard,
MOTD and 68 Micro Journal. I really commend those involved with it. I'm hoping a
disk subsription will be available! JENG
-*-
30914 27-JUL 18:36 Patches
Serial Mouse
From: KHB To: ALL
Help. Is anyone out there using Bruce Isted's serial mouse driver? I can't
seem to get it to work right. I am using a Tandy serial mouse. It works if you
move the mouse one step at a time, but if you move it any faster (a "ballistic"
move) it doesn't move. Any help would be greatly appreciated.
thanks,
Ken Brunell
<KHB>
-*-
30941 28-JUL 01:51 Patches
RE: Serial Mouse (Re: Msg 30914)
From: TRIX To: KHB (NR)
Count yourself lucky. <grin> I tried the mouse patch (to put a Microsoft mouse
on my 6552 [Eliminator]) and my machine wouldn't boot. I'm still puzzling over
that one.
-John.
-*-
End of Thread.
-*-
30916 27-JUL 20:20 Telcom
Archives?
From: SPIKE134 To: ALL
I am curious to find out what these files called archives are? Every time I try
to download one in binary format, text of course, I can't read it. I know I
can't read a binary text file, but is these a program or hints that would help
me to download such a file?
KE134)
-*-
30923 27-JUL 22:34 Telcom
RE: Archives? (Re: Msg 30916)
From: GREGL To: SPIKE134 (NR)
An archive is a file that is used to store one or more files in compressed form.
These are easily recognizable since they will have an extension of .AR or .PAK.
To extract the files from these archives you will need the appropriate archive
utility - AR and PAK are the two most common and both are available in the
Utilities section of the databases.
-- Greg
-*-
End of Thread.
-*-
30917 27-JUL 21:05 Utilities
gshell+
From: AARONS To: MINIFREAK (NR)
Thanks Randy,
1) I found the save utility on the back side (B) of the Multi-Vue disk (it was
merged with Pmpts).
Aaron
-*-
30918 27-JUL 21:07 Patches
GSHELL+
From: AARONS To: ZACKSESSIONS
Thanks Zack, 1) I found the save utility on the back side (B) of the Multi-Vue
disk (it was merged with Pmpts).
2) Is there a mod to change the background and foreground colors on gshell and
tandy shells for Gshell+ ??
I like white characters on blue background (I find a dark background much
easier on my eyes).
Aaron
-*-
30924 27-JUL 22:37 Patches
RE: GSHELL+ (Re: Msg 30918)
From: ZACKSESSIONS To: AARONS (NR)
Changing the palettes is available with stock GShell. Just click on the "Tandy"
menu icon, and fire up the "Control" item. When that window comes up, it will be
apparent what you need to do. I, too, prefer a dark background with a light
foreground. Remember, to save your env file after making the changes!
Zack
-*-
End of Thread.
-*-
30919 27-JUL 21:08 Utilities
ed
From: AARONS To: DODGECOLT (NR)
On Ed I can't see the cusor. How do I change the colors ?
Thanks, AARONS
-*-
30920 27-JUL 21:10 General Information
windows
From: AARONS To: DALEP (NR)
Good article - CoCo3 does windows; but I still have a few questions.
1) When I change the color of the foreground color the cursor changes to that
color but the text character does not, when using wcreate or display on a
window. The text characters change to another color I didn't select (orange).
Why? Is this normal? Palettes are at default (prn 0 thru prn 15). Montype = r
2) I'm using Gshell+ ctrl + break (eof) will erase the window if in a shell
created from the tandy icon on the menu bar or shell created by pressing S on
the keyboard; but will not erase the window if created while in one of these two
shells or if iniz, display,or create one from a procedure file. Am I forgetting
something? What's going on??
Aaron
-*-
30925 27-JUL 22:43 General Information
RE: windows (Re: Msg 30920)
From: GREGL To: AARONS (NR)
The palettes used for the foreground, background, border, and cursor take a
little getting used to. As a general rundown, there are 16 palette registers
numbered 0 through 15. OS-9 splits this into two halves: 0 through 7 and 8
through 15. The color of the cursor is determined by the palette number of the
foreground and the color of the text is determined by the palette number of the
foreground plus eight. For example, if you set the foreground color to Palette
3, the cursor will use Palette 3 and the text will use Palette 3+8 or 11 (0B
hex). So if you want to change both the text and cursor colors, change the
palette number for the foreground to one of the preset palettes (0 to 7) instead
of the actual color stored in that palette register. Of course, if you really
want to you can change the color value stored in the palette register - but
remember the above mechanism for doing so.
-- Greg
-*-
End of Thread.
-*-
30921 27-JUL 21:11 Utilities
ed
From: AARONS To: DODGECOLT (NR)
Mike,
1) Now I can't see the header at the top of the screen.
2) What palettes are the cursor and heading?
I'm having problems understanding seting the colors, for example: When I change
the color of the foreground color the cursor changes to that color but the text
character does not, when using wcreate or display on a window. The text
characters change to another color I didn't select (orange). Why? Is this
normal? Palettes are at default (prn 0 thru prn 15). Montype = r
3) I'm using Gshell+
Aaron
-*-
30922 27-JUL 22:24 Telcom
osterm 2.0.8
From: CAPTSWOOSH To: ALL
hey gang when i use osterm 2.0.8 on delphi i thoughtthe protocal was 8 n 1
thats what i use using other terminal pgms but using osterm its 7 m 1 any idea??
Ron byram
-*-
30926 28-JUL 00:40 General Information
RE: our RiBBS test site (Re: Msg 30281)
From: RAGTIMER To: PAULSENIURA (NR)
Say Paul, just to update you and anyone else listening -- I'm sorry that my
reports on the Get/Put buffer syststem were taken to mean that it is flakey or
buggy. No, it is just UNFORGIVING -- if you create an already-existing buffer,
or delete a non-existant one, the system gets cancer.
BUT -- once I debugged my code so as to NEVER do the above infractions, I have
had NO PROBLEMS with my uh, constructive abuse of the GPBuff system. I haven't
crashed Umuse3 thjis way (nor has hardly anyone else) since the first release of
Virtual Memory.
Just wanted to clear this up in case others were afraid to use it.
-*-
30943 28-JUL 03:06 General Information
Multi-pak Upgrade??
From: SCG To: ALL
I've heard recently from a reasonably good source that multi-paks model number
26-3124 do NOT need to be upgraded(pal). is this true anyone know????
If its not true maybe one of you good folks could let me know what I'm in for in
upgrading this monster!?
Thanks Steve
-*-
30945 28-JUL 11:20 Programmers Den
Program Development Tool
From: OS9BERT To: ALL
I have a great idea for those CoCo owners who have a speech pak and do some
software development work. If you are into certain graphics routines and you
want to check out the status of certain variables or where you are in the
routine you are coding, just insert a line like the following (if you are using
C for examle):
system("echo XYZ function called >/ssp");
This is assuming you have the driver and descriptor (should be here on DELPHI)
for the speech pak and you have made the mods that will enable it to run with a
2MHz system. I find this is much faster than having multiple windows or
printouts.
Bert Schneider
-*-
30946 28-JUL 11:29 General Information
Cheap 68000 System
From: OS9BERT To: ALL
Vesta Technology, INC. (303) 422-8088 has a new 68000 single board computer for
sale that costs only $295 in single quantities!!
It is only 8" x 4" and comes with a 16MHz 68000, socketing for up to 128K of
battery-backed RAM and up to 256K or ROM. A battery-backed real-time clock,, a
parallel printer port, ports for a 4 x 5 keypad, a 4 line by 40 character LCD
display, two seral ports, and all bus signals are carried to an expansion
connector to support expansion boards with a total of 16 meg of RAM, A/D and D/A
cards, etc. It comes with Forth-83 development language and code can be
downloaded to the board via one of the serial ports. If there are any hard core
hackers out there, this would be a chance to get a 68000 system cheap. Bert
Schneider
-*-
FORUM>Reply, Add, Read, "?" or Exit>