9201 lines
317 KiB
Plaintext
9201 lines
317 KiB
Plaintext
|
||
30204 17-JUN 11:59 General Information
|
||
RE: SDir (Re: Msg 30198)
|
||
From: ZACKSESSIONS To: BRIANWHITE
|
||
|
||
Just uploaded a patch file to fix the situation. It will be available as soon as
|
||
|
||
a sysop processes it.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30341 24-JUN 02:51 Utilities
|
||
RE: SDir (Re: Msg 30202)
|
||
From: BRIANWHITE To: ZACKSESSIONS
|
||
|
||
I used numbers from 1000 -> 1999 as user numbers for going straight into a
|
||
current project. Since my computer boots up to TSMon/Login, I can just enter
|
||
the program name and a password, and presto, I'm ready to edit. It also gives
|
||
my partner access to t he same files without giving him SuperUser access. It
|
||
should be simpler with OS-k and Group attributes.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30356 24-JUN 18:59 General Information
|
||
RE: SDir (Re: Msg 30341)
|
||
From: GREGL To: BRIANWHITE
|
||
|
||
Brian,
|
||
|
||
Correct me if I'm wrong, but I don't think OSk has group attributes. It
|
||
appears to me that OSk uses the same file descriptor structure as OS9/6809.
|
||
Adding group attributes would require extending the current attributes to 16
|
||
bits and there isn't room in the file descriptor for that.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30369 25-JUN 02:44 General Information
|
||
RE: SDir (Re: Msg 30356)
|
||
From: TRIX To: GREGL
|
||
|
||
Greg,
|
||
|
||
Your right. I'm looking at page 55 in "The OS-9 Catalog" from Microware. The
|
||
|
||
FD_ATT byte has D S PE PW PR E W R. No group attributes. Oh well.
|
||
|
||
-John.
|
||
|
||
-*-
|
||
|
||
30396 26-JUN 00:52 General Information
|
||
RE: SDir (Re: Msg 30369)
|
||
From: GREGL To: TRIX
|
||
|
||
John,
|
||
|
||
Right you are. And without group attributes, there really is no group
|
||
protection in OSk. But I don't really have to worry about that since I'm working
|
||
|
||
on a project from the ground up and 100% compatibility isn't a real issue. I'd
|
||
rather get it right the first time with room for expansion than to have to muck
|
||
around trying to force a fit later.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30205 17-JUN 12:18 General Information
|
||
RE: 1-meg problems? (Re: Msg 30165)
|
||
From: RAGTIMER To: EDDIEKUNS
|
||
|
||
Yeah -- hard to tell what your other tasks are doing without spakrlies! I saw
|
||
the junk when clearing to (or was it out of?) the 32x16 VDG screen (my /TERM)
|
||
when in text mode. Didn't happen when I had a VDG grafix screen up on Umuse. I
|
||
|
||
figured the change from windows grafix to VDG text was just too much for L2 to
|
||
handle in one vertical retrace interval.
|
||
|
||
Anyway I haven't seen it in a long time, no matter what. Can't remember what
|
||
(if anything) chased it away. Maybe the Phatnom of the Computer dropped a
|
||
chandelier on it...?
|
||
|
||
-*-
|
||
|
||
30292 22-JUN 01:45 General Information
|
||
RE: 1-meg problems? (Re: Msg 30165)
|
||
From: DAMIONGREY To: EDDIEKUNS
|
||
|
||
Eddie - Just to let you know that you're not alone, I get that garbage, too.
|
||
'cept I've just go a lowley 512K machine. One of the first in the area to get
|
||
|
||
a coco 3, so I had an old GIME , and it did it back then. Now I've go a new
|
||
GIME, and it still does it. No wierd crashes now that I've got the new GIME,
|
||
tho, and NO sparklies! LOVE that Tandy hardware! <sad grin> Can't wait to
|
||
go my hands on an MM/1! (or TC/70, but pry the MM/1....sounds worlds better)
|
||
- Greg
|
||
|
||
-*-
|
||
|
||
30293 22-JUN 01:48 General Information
|
||
RE: 1-meg problems? (Re: Msg 30292)
|
||
From: EDDIEKUNS To: DAMIONGREY
|
||
|
||
At least I'm not alone. :(
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30301 22-JUN 22:29 General Information
|
||
RE: 1-meg problems? (Re: Msg 30292)
|
||
From: RAGTIMER To: DAMIONGREY
|
||
|
||
Fer sure get the MM/1, since you don't have a 1 Meg investment to protect.
|
||
Eddie, I found how to get that burst of colored confetti back. I have to have at
|
||
|
||
leeast one L2 GRAFIX window open (I rarely do). Then wehn I clear from the VDG
|
||
TERM to a TEXT L2 window (right), I get the burst. New GIME and 1 Meg.
|
||
|
||
Hasn't crashed yet, but it looks sorta, well, Commodorish...mike k
|
||
|
||
-*-
|
||
|
||
30311 23-JUN 01:36 General Information
|
||
RE: 1-meg problems? (Re: Msg 30301)
|
||
From: EDDIEKUNS To: RAGTIMER
|
||
|
||
Maybe it's about time I named my machine, eh? I mean ... it has enough
|
||
personality! It has more personality than some humans I've met. I guess
|
||
CoCo's, like CoCo users, are each unique.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30361 24-JUN 23:44 General Information
|
||
RE: 1-meg problems? (Re: Msg 30311)
|
||
From: RAGTIMER To: EDDIEKUNS
|
||
|
||
Yessir! And that's before they start cusotmizing their OS9 Boots and Startup
|
||
files. (And getting bugs nobody else has, grin).
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30206 17-JUN 12:22 Graphics & Music
|
||
RE: New Score: Rondo alla turca Mozart (Re: Msg 30170)
|
||
From: RAGTIMER To: XLIONX
|
||
|
||
Thanks for the notice, and the score. What is the advantage of this new Os9Arc
|
||
format over the standard (?) AR? I have an old Turkish March (from CIS maybe),
|
||
but it was done in only 2 or 3 parts, back on the old 1600-note Shareware Umuse,
|
||
|
||
so I'll gladly DL your new version.
|
||
|
||
-*-
|
||
|
||
30221 18-JUN 02:56 Graphics & Music
|
||
RE: New Score: Rondo alla turca Mozart (Re: Msg 30206)
|
||
From: XLIONX To: RAGTIMER
|
||
|
||
Howdy, Well, it's like this...after extensive testing, os9arc compresses better
|
||
than PAK in all cases and performs as well as AR for text. The reason I never
|
||
use AR anymore is that it can't compress anything except TEXT files.
|
||
|
||
Also, os9arc/dearc are in the same format as IBM (I had to say it) ARC files.
|
||
|
||
While PAK is the most functional of them all, I have a VERY large ARC directory
|
||
on my hard drive: 158 files; 2-Meg; 8-Directories This used to take up over 3.5
|
||
meg with a combination of AR and PAK.
|
||
|
||
It's like getting free megabytes on the drive!
|
||
|
||
Let me know how ya like it.
|
||
|
||
-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445)
|
||
|
||
-XLIONX (DELPHI) -mwf@SANDV
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30207 17-JUN 12:27 Device Drivers
|
||
RE: MIDI (Re: Msg 30172)
|
||
From: RAGTIMER To: PHILZEIGLER
|
||
|
||
Phil, you might trtry to hunt up Intercomp Sound in Rochester, NY. He has a
|
||
clone of the Speech Systems MIDI pak that he might be willing to sell a little
|
||
cheaper. Maybe. It's usually bundled with his whole MIDI sequencer package
|
||
(reviewed in Rainbow a couple years aback).
|
||
|
||
Some users have hacked RS232 Paks (or even DC Modem paks?) into MIDI paks. One
|
||
guy even got ACIAPAK to drive his hacked RS232 pak, after renaming T2 to MIDI
|
||
and nulling out all its options bytes. But I can't guarantee that will work.
|
||
|
||
Anyone with direct experience, please chime in -- thanks, mike k
|
||
|
||
-*-
|
||
|
||
30208 17-JUN 12:38 General Information
|
||
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29945)
|
||
From: RAGTIMER To: PAULSENIURA
|
||
|
||
He he -- the irony is that MSDOS programmers can't write proper OS/2
|
||
applications -- the only folks who could are experienced OS-9 programmers! Maybe
|
||
|
||
we could be bribed to help out for, say, $100 grand a year, grin.
|
||
|
||
Also note that while Microware has orphaned OS-9/6809 and pretty well pulled out
|
||
|
||
affordable support for the Atari ST, they are backing the new MM/1 system very
|
||
well -- putting some faith into it as the way to get OS-K into the mainstream.
|
||
Remains to see if FHL's Tomcat-70 gets the same support.
|
||
|
||
And DO upload your posting to the PC, Atari, and Amiga groups. PS: Does that
|
||
latest 4.6.1 play on your Pak?
|
||
|
||
-*-
|
||
|
||
30277 21-JUN 01:24 General Information
|
||
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29973)
|
||
From: PAULSENIURA To: PAULRINEAR
|
||
|
||
|
||
-> Can you think of a nice piece of action game software that will
|
||
-> prove me wrong when I say COCO3 graphics are "coarse and slow".
|
||
-> I'm comparing this to the Nintendo Entertainment System.
|
||
|
||
I have tested Kevin Darling's patches for the GrfDrv module, and I was quite
|
||
amazed at how fast my Oklahoma map would "plop" on the screen when a 7.9k Get
|
||
/Put buffer was set up to be used. Any VEF pic could be read in about 8k at a
|
||
time in four chunks and these chunks would be "blatted" to the video screen in a
|
||
|
||
very big hurry with Kevin's patches. Very amazing.
|
||
|
||
[But Kevin nor anyone else has fixed an irritating bug -- the right-most column
|
||
of pixels (coordinate 319 or 619) has *never* worked in Get/Put buffers.
|
||
Something's preventing that column from getting copied from the buffer. Copying
|
||
|
||
"TO" the buffer FROM that column works just fine.]
|
||
|
||
What Kevin's speed improvement proves is that the CoCo3 hardware itself is not
|
||
at fault: it is how the modules were designed and programmed in the first place.
|
||
|
||
After the o.s. modules are "tweaked" for top performance, then the application
|
||
software needs to be rewritten (most probably) in order to utilize the new
|
||
features properly.
|
||
|
||
Yes this applies to any computer and o.s., not just the CoCo and not just OS9.
|
||
|
||
I am afraid, however, that you're comparing apples with oranges. Nintendo's
|
||
circuits, no doubt, have "Sprite" graphics chips. This scheme was used, but
|
||
poorly documented, on the little T.I. home computer, but that machine's graphics
|
||
|
||
were highly touted at that time, also. (It was the poor documentation, if it
|
||
can be called that, to be blamed for the T.I.'s demise. And a lot of people are
|
||
saying the same thing, now, about this new Nintendo machine. In fact some court
|
||
|
||
suits are based on this fact, citing how Nintendo is unfairly cornering the game
|
||
|
||
market.)
|
||
|
||
When you compare Sprites with just regular ol' memory-mapped graphics, the
|
||
Sprites will win every time, believe me. In this vane, you'd be hard pressed to
|
||
|
||
see any OS9-based games approaching this kind of quality. And then you *could*
|
||
blame the CoCo hardware design, since Tandy didn't elect to include Sprite chips
|
||
|
||
in the design!
|
||
|
||
This brings up a VERY interesting idea, tho ... I wonder if KLE or FHL might be
|
||
considering such a graphics board that includes programmable Sprites? Jeepers,
|
||
the 68030 with 32-bit paths would BLAST the Nintendo for sure!!! Why don't
|
||
y'all harp on KLE & FHL to produce such a graphics board? That would really
|
||
kill Nintendo and it *might* finally make 'OS9' a household name YET!!!
|
||
|
||
(Hold it -- I better copyright my suggestion there -- I smell $$$s -- (c) 1990
|
||
by Paul Seniura. :-)
|
||
|
||
|
||
|
||
-*-
|
||
|
||
30322 23-JUN 06:27 Graphics & Music
|
||
Get/Put Buffers (Re: Msg 30277)
|
||
From: OS9UGPRES To: PAULSENIURA
|
||
|
||
> [But Kevin nor anyone else has fixed an irritating bug --
|
||
> the right-most column of pixels (coordinate 319 or 619) has
|
||
> *never* worked in Get/Put buffers.
|
||
|
||
Actually, it's fixed. But we didn't include the fix in the fast grfdrv patch.
|
||
Why not? I guess because it's a sales feature for later <wink>.
|
||
|
||
If you GET, then map in the buffer, I believe the rightmost pixel data is really
|
||
|
||
included. PUT is a different story, tho.
|
||
|
||
> What Kevin's speed improvement proves is that the CoCo3 hardware
|
||
> itself is not at fault: it is how the modules were designed and
|
||
> programmed in the first place.
|
||
|
||
I know what you meant, but just wanted to clarify that the original programmers
|
||
did one heckuva job getting everything they did, into the space they used.
|
||
Matter of fact, they gave us many features which other windowing systems don't
|
||
have at all... even their own RAVE.
|
||
|
||
Anyway, they ended up having to make some major stuff into generalized routines
|
||
for all gfx modes tho, which slowed things down.
|
||
|
||
However, Microware didn't have Kent D Meyers, cruncher extraordinaire, around <
|
||
grin>. Between the two of us, we carved out at least 800 bytes from grfdrv's
|
||
already optimized 8K code... and as you know, that's an *enormous* amount of
|
||
room to an asm programmer. Making special-case lightening-fast PUTs was easy
|
||
after that.
|
||
|
||
But I'm SO happy to be programming on the 68000 now: the really tight space
|
||
restrictions of the coco are nonexistent. It's nice to be able to concentrate on
|
||
|
||
fast code instead of always having to make smaller but generalized code.
|
||
best - kev
|
||
|
||
-*-
|
||
|
||
30619 8-JUL 23:59 General Information
|
||
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30277)
|
||
From: PAULRINEAR To: PAULSENIURA (NR)
|
||
|
||
Very interesting. The Commodore 64 was also an early unit with sprite
|
||
graphics and it was fairly well documented in the Programmer's Reference manual.
|
||
|
||
I also have Kevin Darling's patch and it is a great improvement. He has
|
||
also written a new GFX2. Wonder if Kevin uses this message area. I know he's
|
||
over on Compuserve.
|
||
A sprite graphics board sounds like a good idea to me for the new "
|
||
superCOCO's ", but I don't know much about it. I seem to remember there being
|
||
some problem mentioned about not being able to use sprites in just any old
|
||
window though.
|
||
Paul Rinear
|
||
|
||
-*-
|
||
|
||
30623 9-JUL 18:07 General Information
|
||
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30619)
|
||
From: ZACKSESSIONS To: PAULRINEAR
|
||
|
||
Kevin in on Delphi under username OS9UGPRES.
|
||
|
||
-*-
|
||
|
||
30631 9-JUL 23:26 General Information
|
||
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30619)
|
||
From: TIMKOONCE To: PAULRINEAR
|
||
|
||
Hardware sprites are probably more trouble than they're worth. They were fine
|
||
for the early underpowered machines like the Commodore, but since newer machines
|
||
|
||
tend to have the horsepower to handle it, it's easier and just as effective to
|
||
do it in software.
|
||
Plus, there is a slight problem if you have 5 windows on a screen, and all of
|
||
them want to use the hardware sprites! <grin> In such a case, the system would
|
||
|
||
have to simulate some of them in software anyway.
|
||
- Tim K
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30209 17-JUN 15:57 General Information
|
||
RE: CoCo 4? (Re: Msg 29690)
|
||
From: PKW To: THEFERRET
|
||
|
||
Phil,
|
||
|
||
You should have gotten the packet by now. Did you? Sorry I haven't been on
|
||
lately.
|
||
|
||
The upper limit of the MM/1 is 9 meg, but I have been using a three meg system,
|
||
with a terminal, and that seems to me to be far and away all the memory I am
|
||
going to need, at least until I start cranking up the combined animation/ sound
|
||
stuff! Then I'll either have to get the new SIMMs our count on the DMA to keep
|
||
the system humming!
|
||
|
||
BTW, OSK is now the official operating system for the MM/1. It really was never
|
||
going to be anything else.
|
||
|
||
We also have official prices, and the addition of several new configurations
|
||
that should meet everyone's budget.
|
||
|
||
OSK, the C compiler, and Microware BASIC are all included, as are a word
|
||
processor that is keystroke configurable, a graphics editor from HyperTech, and
|
||
several demos of the animation, of IMS and third party software, and so on.
|
||
|
||
A ton o' stuff.
|
||
|
||
So, Phil, if you haven't gotten the latest, or if you want ot get The Insider
|
||
newsletter (have you got it already?), call our 800 number, 800 866 9084, Mon
|
||
thru Fri, 9-5.
|
||
|
||
Best regards,
|
||
|
||
Paul
|
||
|
||
-*-
|
||
|
||
30249 19-JUN 21:39 General Information
|
||
RE: CoCo 4? (Re: Msg 30209)
|
||
From: RAGTIMER To: PKW
|
||
|
||
Say Paul, I don't recall getting anaything from you in the mail -- no blurb or
|
||
Insider mag yet. I'd like to see your latest configuration, price, and options
|
||
list -- you going to upload or post it here? Thanx, mike k
|
||
|
||
-*-
|
||
|
||
30306 23-JUN 00:29 General Information
|
||
RE: CoCo 4? (Re: Msg 30249)
|
||
From: PKW To: RAGTIMER
|
||
|
||
Well, the blurbs you really don't need, eh? And the Insider (as it says on the
|
||
blurb you haven't received) is scheduled for an early July delivery!
|
||
|
||
Patience, my friend, I am working as hard as I can ... <grin>
|
||
|
||
I am going to put stuff in the mail to you -- oops, I just noticed I DON't HAVE
|
||
your mailing address. Please Eplex to me on CI$.
|
||
|
||
TTFN!
|
||
|
||
Paul
|
||
|
||
-*-
|
||
|
||
30360 24-JUN 23:42 General Information
|
||
RE: CoCo 4? (Re: Msg 30306)
|
||
From: RAGTIMER To: PKW
|
||
|
||
Well I can just Email it to you here on the low-priced speared, grin. Just as
|
||
private (I think!). So I'll send you my USMail address here -- also saves
|
||
looking up your state prison number on the hi-priced spread. --mike k
|
||
|
||
-*-
|
||
|
||
30678 12-JUL 21:35 General Information
|
||
RE: CoCo 4? (Re: Msg 30360)
|
||
From: THEFERRET To: PKW (NR)
|
||
|
||
Is there anyone on the west coast who I could bug to have a peek at the machine
|
||
? actually, let me narrow that down a bit. Is there anyone within a 50-mile
|
||
radius of San Francisco, ...?
|
||
|
||
Philip
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30210 17-JUN 16:12 General Information
|
||
RE: Questions about the MM/1 (Re: Msg 30033)
|
||
From: PKW To: KEITHMARCH
|
||
|
||
Keith,
|
||
|
||
Nice to hear from you again! Sorry to have been off so long. Been really busy
|
||
here at IMS.
|
||
|
||
To FINALLY answer your questions, here goes:
|
||
|
||
1) I believe that a WEFAX program will be coming available. 2) MM/1 has the
|
||
hardware to support RAVE. 3) The system comes in a 128K EPROM, as I recall. I
|
||
don't have the specs
|
||
right at hand. Some of the EPROM spacaeis taken up by a lot of the
|
||
common OSK commands, so system performance is even better. 4) Real time clock
|
||
|
||
is best used on the second board. The EPROM socket is for
|
||
system code. I used the MM/1 extensively without the realtime clock and
|
||
had no troubles -- but is is more convenient now that I have the RTC, too. 5)
|
||
|
||
There is a dmode command for OSK, and I use it all the time to transfer
|
||
data between various OSK formats. 6) There will be a term program that
|
||
supports X, Y, and Kermit protocol. 7) There is a cls command available to
|
||
BASIC. 8) The 15 MHz MM/1 is a fast machine. It will run about 50 percent faster
|
||
|
||
than computers in its price range.
|
||
If you want to use another CPU, you will NOT be advised to pull out
|
||
the 68070. For one thing, although it IS socketed, it is a highly integrated
|
||
chip with serial ports and DMA stuff on board, so the CPU board is really
|
||
glued together by the CPU. For another thing, if you need faster performance,
|
||
|
||
you can use our 32 bit bus to add another CPU card, with FPU, etc. 32 bits
|
||
will be the only correct bus to use for a faster chip. 9) You can exchage any
|
||
|
||
CoCo disk with an MM/1 disk, using a simple utility. 10) Function keys will be
|
||
implemented, details to follow in a month or so. 11) MM/1 does not have math
|
||
coprocesor support, unless you do it on the bus.
|
||
Then the math coprocessor is a peripheral. Luckily, our bus is 32 bits,
|
||
so performance is far faster than 16 bit bus machines. 12) All major chips
|
||
will be socketed until our quality control department says
|
||
it's OK to solder most chips. Even then, theh cost of the sockets is so
|
||
small, we may forever keep them in the design. 13) Getting started texts are in
|
||
the works now, and will be distributed exclusively to our customers. 14) You
|
||
have the choice of booting off of floppy first, then hard disk, finally EPROM.
|
||
So the EPROM boot is only a last resort for the startup process. If you DO
|
||
decide to boot off EPROM, you can simply load in any additional modules you
|
||
need. If you want to REPLACE a module in the EPROM, no need to reburn the
|
||
EPROMjust load in a module with the same name w/higher revision number.
|
||
|
||
Howzat? Paul
|
||
|
||
-*-
|
||
|
||
30211 17-JUN 18:12 General Information
|
||
sculptor
|
||
From: GENEDEAL To: ALL
|
||
|
||
Does anyone know why sculptors developement menu, when calling up dynastar
|
||
causes the loss of characters at the end of a document?
|
||
|
||
Gene Deal
|
||
|
||
-*-
|
||
|
||
30212 17-JUN 18:15 General Information
|
||
os9 windows
|
||
From: GENEDEAL To: ALL
|
||
|
||
I am using multiple language character sets on OS9 with a text/graphics window
|
||
and I cannot seem to get a text cursor. Other programs I have running on such
|
||
windows have the cursor. Where is my cursor?
|
||
|
||
Any help would be appreciated.
|
||
|
||
Gene Deal
|
||
|
||
-*-
|
||
|
||
30213 17-JUN 19:17 Device Drivers
|
||
System Clock
|
||
From: MPASSER To: ALL
|
||
|
||
Hello!
|
||
|
||
I recently installed a Tandy SmartWatch in my FD-502 controller, and it works
|
||
great. However, once I'm up and running, I notice that the system clock *gains*
|
||
|
||
time. If anything (since I'm not using no-halt floppies), I would expect that
|
||
it would *lose* time. Any ideas?
|
||
|
||
Thanks, Mike Passer (MPASSER)
|
||
|
||
-*-
|
||
|
||
30214 17-JUN 20:16 Graphics & Music
|
||
SS.MSig question
|
||
From: ZACKSESSIONS To: ALL
|
||
|
||
Consider the mouse signal. Let's say I do a:
|
||
|
||
_ss_msig(path,MOUSSIG);
|
||
|
||
call in my C program. Should path be standard input, standard output, or does it
|
||
|
||
really matter?
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30215 17-JUN 20:27 Graphics & Music
|
||
RE: SS.MSig question (Re: Msg 30214)
|
||
From: DODGECOLT To: ZACKSESSIONS
|
||
|
||
Doesn't matter. Unlike things like _ss_size() or similar calls, you don't have
|
||
to have any special permissions (read/write) to the path.
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30216 17-JUN 23:15 Telcom
|
||
RE: disable call waiting (Re: Msg 30189)
|
||
From: NES To: ZACKSESSIONS
|
||
|
||
Hay, Zack, Thanx for the uploads, I came in as you where logging
|
||
off the BBS. As for the View program I think the system hit a bad sector on
|
||
the hard drive it been a little flaky lattly in the heat since I havent any
|
||
Aircondition just fans, also need to get a new and larger harddrive, the one I
|
||
have is about full, also its an used drive... Dose os9 block out bad
|
||
sector's????, I know when the drive get's too hot it gives 244 error's and 247..
|
||
|
||
but maybe one of this days I get me an MM1 and stop havening to keep fixing the
|
||
multipak interface.. latter -Eric
|
||
|
||
|
||
-*-
|
||
|
||
30223 18-JUN 18:51 Telcom
|
||
RE: disable call waiting (Re: Msg 30216)
|
||
From: ZACKSESSIONS To: NES
|
||
|
||
OS9 does block out bad sectors, but only at format time. But format itself does
|
||
not really do a thorough job of determining bad sectors. The ccheck utility
|
||
which comes with Burke&Burke's File System Repack does the job quite nicely.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30231 18-JUN 22:54 Telcom
|
||
RE: disable call waiting (Re: Msg 30223)
|
||
From: GREGL To: ZACKSESSIONS
|
||
|
||
Zack,
|
||
|
||
What makes format even worse is that it simply allocates any sectors that it
|
||
|
||
finds defective. A year or so later when you run dcheck you will receive
|
||
warnings that sectors are allocated but not in the file system. If you forget,
|
||
you might deallocate all of those sectors to get a clean report from dcheck. It
|
||
would be better if dcheck created a file called something like "bad.sectors"
|
||
with attributes of "--------" to allow dcheck and other utilities correctly
|
||
report missing sectors from the file system.
|
||
I'm not sure how ccheck handles that. But it would certainly be better to
|
||
map the bad sectors to a file than to just leave them flapping in the breeze.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30233 18-JUN 23:11 Telcom
|
||
RE: disable call waiting (Re: Msg 30231)
|
||
From: TJSEAGROVE To: GREGL
|
||
|
||
Greg,
|
||
|
||
Do you know of a disk checking utility that will create a file containing the
|
||
|
||
bad sectors?? Could be a good programming project for someone. What do you say
|
||
|
||
Zack??!!
|
||
|
||
....Tom
|
||
|
||
|
||
-*-
|
||
|
||
30234 18-JUN 23:21 Telcom
|
||
RE: disable call waiting (Re: Msg 30231)
|
||
From: ZACKSESSIONS To: GREGL
|
||
|
||
ccheck isn't any better, in fact as far as allocating "bad" sectors it's even
|
||
worse! It's up to you to use BA (another FSR utility) to mark the bad sectors as
|
||
|
||
allocated. What we need is something in OS9 itself which handles "bad blocks".
|
||
Blocks allocated to the bad blockkfile never to be re-allocated.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30235 18-JUN 23:26 Telcom
|
||
RE: disable call waiting (Re: Msg 30233)
|
||
From: ZACKSESSIONS To: TJSEAGROVE
|
||
|
||
Get File System Repack from B&B. And use the ccheck utility.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30237 18-JUN 23:29 Telcom
|
||
RE: disable call waiting (Re: Msg 30233)
|
||
From: GREGL To: TJSEAGROVE
|
||
|
||
Tom,
|
||
|
||
To my knowledge, no such utility exists. That doesn't necessarily mean that
|
||
ccheck doesn't since I'm not familiar with it. Offhand I don't think it does,
|
||
but I could be wrong. I know that I certainly don't like bad sectors sitting
|
||
around in the allocation bitmap without appearing in the file structure
|
||
somewhere. In such cases, dcheck may report several sectors that are allocated
|
||
but not in the file structure. How do you know which are actual bad sectors and
|
||
which are actually caused by some glitch? Also, dcheck needs the ability to
|
||
cross-reference linked files and remove those from the doubly allocated sector
|
||
listing it reports.
|
||
I had that problem bite me a couple of years ago when dcheck reported
|
||
several sectors that were found more than once in the file system. At the time I
|
||
|
||
assumed they were caused by linked files. Later I discovered that one of my text
|
||
|
||
files had been cross-linked with an archive file because of a glitch somewhere.
|
||
The problem, as should be apparent, is that you'll often ignore such things as
|
||
multiply-allocated sectors and sectors that are allocated but not found in the
|
||
file system if you think it's because of link files or bad sectors. It usually
|
||
takes a good eye and a lot of cross-referencing with the dcheck listing to
|
||
determine which are actually an error.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30238 18-JUN 23:45 Telcom
|
||
RE: disable call waiting (Re: Msg 30234)
|
||
From: GREGL To: ZACKSESSIONS
|
||
|
||
Zack,
|
||
|
||
In my humble opinion, we need to set aside eight additional bits for file
|
||
permission attributes. Directory, sharable, execute, read, and write have
|
||
served us well over the years but I feel that we have outgrown them. Here is a
|
||
list of the attributes that I think should be added:
|
||
Moveable: If this bit is set in the attributes then the file cannot be moved
|
||
|
||
by disk optimization or compression utilities. Obvious files that would have
|
||
this attribute set would be the "bad.sectors" file and OS9Boot. Also, the OS-9
|
||
Kernel on Track 34 should be mapped to a file called "kernel" and have the
|
||
moveable attribute set. This would prevent all "sector allocated but not in file
|
||
|
||
system" errors from dcheck for the kernel on Track 34.
|
||
Delete: If this bit is set, the file cannot be deleted by normal methods.
|
||
Write permission isn't enough to protect this one. For example, you would want
|
||
to allow the users to write to the password file to change their passwords on a
|
||
regular basis but you don't want them to be able to delete the file. I'm sure
|
||
you can think of other places where this would be handy.
|
||
Hidden: If this attribute is set, the file will not be shown in a directory
|
||
listing exception with a special option in the directory utility. Also, the file
|
||
|
||
would be shown only to the super-user. I'm sure you can think of places to this
|
||
|
||
one - such as the "bad.sectors" file.
|
||
Archive: If this bit is set then it hasn't been backed up since it was last
|
||
modified. This would be great to make sure all files are backed up during
|
||
incremental backups. Perform a backup once per week with only those files that
|
||
have the archive bit set.
|
||
If you can think of any other file permission attributes then feel free to
|
||
add them to this list.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30242 19-JUN 01:08 Telcom
|
||
RE: disable call waiting (Re: Msg 30238)
|
||
From: EDDIEKUNS To: GREGL
|
||
|
||
How about GROUP file attributes?
|
||
|
||
VMS allows the following attributes:
|
||
|
||
Read, Write, Delete, eXecute for Owner, System, Group, World.
|
||
|
||
Nice, complete model! (Except we don't need system)
|
||
|
||
You then need delete access, and not write access to delete a file. Tho with
|
||
write access you can erase the contents of a file.
|
||
|
||
Also, the bad.sectors shouldn't be a file, per se. Something in LSN 0 should
|
||
keep track of which sectors are bad. This makes it easy to lock out new
|
||
sectors, since it's part of the disk driver. A bad sector will then be
|
||
identified because it's: 1) allocated 2) in the bad_sector list. Hmmm.
|
||
'course, what do you do if you have > 48 bad sectors? Hmmm.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30248 19-JUN 19:37 Telcom
|
||
RE: disable call waiting (Re: Msg 30238)
|
||
From: ZACKSESSIONS To: GREGL
|
||
|
||
I think you have covered them pretty well! Now what can we DO about it? :-)
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30254 20-JUN 00:00 Telcom
|
||
RE: disable call waiting (Re: Msg 30238)
|
||
From: KNOT1 To: GREGL
|
||
|
||
Greg,
|
||
|
||
I believe you can get by without a DELETE bit. WRITE permision should be
|
||
enough. Your password file shouldn't have Public Write permision set. Instead,
|
||
a program like "passwd" should change its user ID to 0 (super user) with a call
|
||
to F$SUser, then update the password file. Also, if you don't have Write
|
||
permision to the directory you shouldn't be able to delete the file. I don't
|
||
believe CoCo OS-9 supports this, but if you are not the owner of the file
|
||
(regardless of Write permision) you shouldn't be able to delete it unless you
|
||
are the owner of the directory (with Write permision) that the file is in, and
|
||
then it should prompt you to proceed with deleting it.
|
||
|
||
But having a DELETE bit wouldn't be bad, it just might be unnecessary.
|
||
|
||
I agree with Eddie that GROUP attributes could be nice. I would also like to
|
||
see SET USER (and SET GROUP) bit(s). If the SET USER bit is set for a file when
|
||
|
||
it is executed, then the O.S. would do the equivalent of a F$SUser to that of
|
||
the owner of the file. That's how the "passwd" program would be done. SET
|
||
GROUP would be similar, but would do something like "F$SGroup" instead, if such
|
||
a call existed.
|
||
|
||
Unix/Zenix does HIDDEN by starting the filename with a period (e.g.
|
||
".bad_sectors", ".kernel", etc...) and this works nicely.
|
||
|
||
I always felt OS-9 sould have used 512 bytes for its file descriptors rather
|
||
than 256. Then they could have added more attribute bits like the ones you
|
||
indicated and also add a "date/time last accessed" in addition to "created" and
|
||
"modified", and also anything else needed.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30260 20-JUN 01:30 Telcom
|
||
RE: disable call waiting (Re: Msg 30238)
|
||
From: TIMKOONCE To: GREGL
|
||
|
||
File permission attributes:
|
||
Rather than simple Read/Write/Execute for owner and group, how about Read
|
||
/Write/Execute/Append. In particular, opening a file with the "append" bit set
|
||
in the permissions would correspond to C's "append" mode. For directories,
|
||
"Append" privilege is the privilege to ADD files to the directory. You need
|
||
"Write" privilege to delete files from the directory. Files with public Append
|
||
(but not Write) privileges might include system error logs, mail files, etc.
|
||
Anything that anyone should be able to add stuff to, but you don't want anyone
|
||
able to delete or alter information.
|
||
I like some of your ideas, too.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30270 20-JUN 22:53 Telcom
|
||
RE: disable call waiting (Re: Msg 30242)
|
||
From: GREGL To: EDDIEKUNS
|
||
|
||
Eddie,
|
||
|
||
One solution would be to use 512-byte file descriptors. At present there is
|
||
no room in the file descriptor for any other data, which is bad news. I'd like
|
||
to have owner, group, and public attributes as I think that's the way to go,
|
||
especially with multi-user systems. Each of the three groups could be assigned
|
||
Read, Write, Execute and Delete permissions with the other attributes given
|
||
global scope, per se. That would use 12 bits for owner, group and public
|
||
attributes and Directory, Sharable, Movable, and Hidden taking up another 4 bits
|
||
|
||
for a total of 16 bits. Although we could say that "Hidden" has an implied
|
||
meaning of non-movable to free one bit for other uses. But I think it best not
|
||
to have single attributes taking multiple definitions.
|
||
Of course you could either use the last 256 bytes in the descriptor as an
|
||
expanded segment list leaving the other bytes for future use or use all of the
|
||
remaining storage in the file descriptor for the segment list. Personally, I
|
||
don't see much need for more than 448 entries in the segment list and 61 should
|
||
be plenty. If you have a very large hard drive then there might be a need for
|
||
it. Come to think of it, we could use the last entry in the segment list as a
|
||
"pointer" to additional entries that are stored in another sector for future
|
||
expansion.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30274 21-JUN 01:10 Telcom
|
||
RE: disable call waiting (Re: Msg 30270)
|
||
From: ZACKSESSIONS To: GREGL
|
||
|
||
Isn't it strange how the topic of this thread deviated from the original topic?
|
||
<grin>
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30278 21-JUN 01:26 Telcom
|
||
RE: disable call waiting (Re: Msg 30270)
|
||
From: EDDIEKUNS To: GREGL
|
||
|
||
Yes, the 'final' segment list pointer should really point to the next block of
|
||
segment lists! Great idea!
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30217 17-JUN 23:33 Utilities
|
||
y cable
|
||
From: BANCROFT To: ALL
|
||
|
||
I am putting my coco into a pc case, and need to put my floppy and hard drive
|
||
contrller on a y cable. I am getting 1 addressing confilict. Both the floppy
|
||
and hard drive use ff50 for drive select. The floppy also is using ff40, and
|
||
does not need ff50. Any ideas how to disable ff50 on the floppy ? thanks
|
||
|
||
-*-
|
||
|
||
30261 20-JUN 01:34 Utilities
|
||
RE: y cable (Re: Msg 30217)
|
||
From: TIMKOONCE To: BANCROFT
|
||
|
||
Basically, you need to alter your floppy controller to keep it from responding.
|
||
Let's see, normally the floppy controller responds to the SCS line, so you'd
|
||
need to gate that with A4 so that the floppy wouldn't see SCS when A4 was high.
|
||
If you need more info, tell us what exact type of floppy controller you have,
|
||
and someone can tell you the exact mod needed.
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
30267 20-JUN 19:47 Utilities
|
||
RE: y cable (Re: Msg 30261)
|
||
From: BANCROFT To: TIMKOONCE
|
||
|
||
I have a standard radio shack fd-501 floppy controller. I bought it as soon as
|
||
they came out, so if there is more than 1 version of the 501, I have the first,
|
||
I am sure of that. I know that all I probably need to do is cut a trace, and
|
||
probably jumper a wire from that trace to 1 other one, but I am not sure what
|
||
trace I need to do this to.
|
||
|
||
Thanks
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30218 18-JUN 00:21 General Information
|
||
Disto 1 meg upgrade
|
||
From: POLTERGEIST To: GREGL
|
||
|
||
Greg,
|
||
I just installed the Disto 1 meg board, and I use the Disto 512K board with
|
||
|
||
it. Now, I have a serious problem. It seems that with the piggyback layout,
|
||
the 1 meg kit is too tall, and my case will NOT fit when I put it back on!!!!
|
||
Any suggestions on how to rememdy this?
|
||
|
||
-*-
|
||
|
||
30219 18-JUN 01:03 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30218)
|
||
From: EDDIEKUNS To: POLTERGEIST
|
||
|
||
On my CoCo, I removed part of the ribs on the top 1/2 of the CoCo case so that
|
||
the 1-meg would fit beneath it without being too cramped.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30220 18-JUN 01:55 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30218)
|
||
From: GREGL To: POLTERGEIST
|
||
|
||
Brian,
|
||
|
||
The most common approach, and the one recommended by CRC/Disto, is to cut
|
||
some of the excess from the wire wrap pins that hold the two boards together.
|
||
Take a close measurement of the spacing on both boards and trim a little from
|
||
each until the case fits. Of course, don't trim too much or the boards won't
|
||
seat properly without touching one another - or the motherboard components.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30239 18-JUN 23:49 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30219)
|
||
From: POLTERGEIST To: EDDIEKUNS
|
||
|
||
Thanks, Eddie. I may trim the leads a bit on the boards, the docs said
|
||
something about that. I don't want to bash any holes in the case. <grin>
|
||
Still having graphics trouble with your setup?
|
||
|
||
-*-
|
||
|
||
30240 18-JUN 23:49 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30220)
|
||
From: POLTERGEIST To: GREGL
|
||
|
||
Thangs, Greg, this is what I may do, once I get a hold of some decent
|
||
clippers. <grin>
|
||
|
||
-*-
|
||
|
||
30243 19-JUN 01:08 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30239)
|
||
From: EDDIEKUNS To: POLTERGEIST
|
||
|
||
Yes. Still having graphics trouble. I'm giving up for now, since nothing
|
||
CRASHES.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30252 19-JUN 22:09 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30243)
|
||
From: XLIONX To: EDDIEKUNS
|
||
|
||
Howdy Eddie,
|
||
|
||
When you say you are having "graphics trouble": 1.) do you have ANY problems
|
||
before you run MEGA? 2.) if you start your graphic stuff first, then run MEGA
|
||
does it still have bugs3.) is it only one program (MVCanvas, GShell)??? 4.) are
|
||
you tired of life and the persuit of coco perfection (in general)? ];-> 5.) do
|
||
you take this computer to be your....oops.
|
||
|
||
|
||
Just curious about your problem as you and I started with all of the same bugs.
|
||
I was hoping that you would have the same luck I did with the new GIME chip. I
|
||
don't have MVCanvas, but I do have GShell 1.24a and it works ok (so far). I have
|
||
|
||
run MAZE in 6 windows at a time without bugs. I have run FSIM2 and other stuff
|
||
without bugs (Carmen Sandiego, ya know VDG stuff)...in lower memory.
|
||
|
||
Let me know what ya got for CURRENT status (bugs, crabs, gremlins, etc...) and
|
||
I will try to duplicate them.
|
||
|
||
Mark W. Farrell (PegaSystems) SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445)
|
||
XLIONX (DELPHI) mwf@SANDV
|
||
|
||
|
||
-*-
|
||
|
||
30256 20-JUN 00:16 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30243)
|
||
From: CBJ To: EDDIEKUNS
|
||
|
||
Eddie,
|
||
The graphics problem you describe where you see a flash that looks like a
|
||
game of TETRIS that was very poorly played seems to be very common. I have seen
|
||
|
||
it on three computers other than my own (all that I have access to). I gave up
|
||
worrying about it. I get it when I use AUTOTERM. It flashes for a second only
|
||
then is gone. I have never been "lucky" enough to have sparklies. As long as
|
||
your computer doesn't crash don't worry about that flash of junk. ---Carl---
|
||
|
||
-*-
|
||
|
||
30257 20-JUN 00:17 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30252)
|
||
From: EDDIEKUNS To: XLIONX
|
||
|
||
I only see the remaining problems (after resoldering the 6809 header & getting a
|
||
|
||
new GIME) under the following conditions:
|
||
|
||
1) In 1-meg mode (pin 2 to select full meg) and after running 'mega' 2) On a
|
||
graphics screen, usu on one with an auto-follow mouse 3) When switching from a
|
||
graphics window to any window of a different type.
|
||
|
||
1 & 2 refer to the problem I get with a blinking, intermittent line of garbage I
|
||
|
||
get (Did you ever get that too?) which is about 8 scan lines high and the full
|
||
screen-width. Sometimes it seems like the more activity I get, the more the
|
||
garbage-y line flickers on & off, sometimes it doesn't. :) Usu I get this on a
|
||
screen with an auto-follow mouse (GShell & MVC, so far), but have also gotten it
|
||
|
||
on a 'normal' graphics window. And *once* I got it on a text window, just
|
||
recently! I had turned off the power to the drives and multipak, but not the
|
||
CoCo, had pressed in the power button on the CoCo, and realized I wanted to make
|
||
|
||
sure nothing important was on the RAM drive! So I did a dir on the RAM drive
|
||
and listed a couple of files, and that's when I got it on the text ed window.
|
||
I also noticed the TR light (Terminal Ready) on my modem blinking on & off!
|
||
(With power off to the Multipak & Deluxe RS232 pak!)
|
||
|
||
3 refers to the garbage I get when CLEAR-ing from one window to the next. I get
|
||
|
||
a brief view of a screen-full of (colored blocks on a text window, garbage on a
|
||
graphics window) before I see the next window, when Clear-ing.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30258 20-JUN 00:19 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30256)
|
||
From: EDDIEKUNS To: CBJ
|
||
|
||
Yeah -- that's pretty much the attitude I've taken -- Nothing is crashing, so
|
||
I'll just let it be for now.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30263 20-JUN 02:20 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30243)
|
||
From: POLTERGEIST To: EDDIEKUNS
|
||
|
||
What are the graphics problems that you're having?
|
||
|
||
-*-
|
||
|
||
30268 20-JUN 20:50 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30258)
|
||
From: CBJ To: EDDIEKUNS
|
||
|
||
Boy would it be neat if we could capture that screen and do a dump to color
|
||
printer. Really interesting graphics. I notice that I get this flash of
|
||
"garbage" when AUTOTERM goes from the normal 32 column screen to a 40 column
|
||
screen or an 80 column screen. still it is nice to know I'm not the only one
|
||
this is happening to. ---Carl---
|
||
|
||
-*-
|
||
|
||
30279 21-JUN 01:36 General Information
|
||
RE: Disto 1 meg upgrade (Re: Msg 30263)
|
||
From: EDDIEKUNS To: POLTERGEIST
|
||
|
||
Read 30257, where I documented my current (remaining) problems. Nothing
|
||
crashes, so I've temporarily given up.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30222 18-JUN 03:05 Utilities
|
||
RE: UNPACK (Re: Msg 30179)
|
||
From: XLIONX To: CONDUCTOR
|
||
|
||
Microware would probably consider such a program TABOO. I have NEVER heard of a
|
||
utility that would do this. De-compiling a two-pass ICODE file would be a pretty
|
||
|
||
neat trick as basic09 strips a BUNCH of stuff out when you PACK a file.
|
||
|
||
-XLIONX (DELPHI)
|
||
|
||
|
||
-*-
|
||
|
||
30230 18-JUN 21:02 Utilities
|
||
RE: UNPACK (Re: Msg 30222)
|
||
From: CONDUCTOR To: XLIONX
|
||
|
||
Thanks for the input.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30224 18-JUN 20:18 General Information
|
||
WHERE TO FIND PROGRAMS
|
||
From: MBB63 To: ALL
|
||
|
||
I WOULD LIKE TO DOWNLOAD SHELL+, LABEL COMMAND, DIRECTIONS ON HOW TO INSTALL.
|
||
ALSO DIRECTIONS ON HOW TO USE THE AR PROGRAM. WHERE DO I FIND THESE ON OS9
|
||
ONLINE. STILL A LONG WAY TO GO ON BEING COMFORTABLE USING DELPHI AND OS9 MARIE
|
||
BOUDET
|
||
|
||
-*-
|
||
|
||
30236 18-JUN 23:29 General Information
|
||
RE: WHERE TO FIND PROGRAMS (Re: Msg 30224)
|
||
From: ZACKSESSIONS To: MBB63 (NR)
|
||
|
||
For more specific help, we need to know which term program you will be using to
|
||
do the download with.
|
||
|
||
Once you get ar, you need to move it to your CMDS cirectory, set it's execution
|
||
attribute,
|
||
|
||
OS9: attr /dd/cmds/ar e pe
|
||
|
||
The to de-arc an archive do something like:
|
||
|
||
OS9: ar -x /dd/download/shellplus.ar
|
||
|
||
That will dearchive the archive putting all the file in the archive in your
|
||
current data directory.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30225 18-JUN 20:19 Applications
|
||
RE: OS9 Development System (Re: Msg 30188)
|
||
From: RADARBUZZ To: TJSEAGROVE
|
||
|
||
Tom,
|
||
|
||
Yea, I had already thought of that. I ran across the COCOPro ad in
|
||
Rainbowand called the BBS #. No cigar. Still looking though! Got to be one
|
||
some- where.
|
||
|
||
-Jeff
|
||
|
||
|
||
-*-
|
||
|
||
30241 19-JUN 00:06 Applications
|
||
RE: OS9 Development System (Re: Msg 30184)
|
||
From: CBJ To: RADARBUZZ
|
||
|
||
Jeff,
|
||
I don't know if it's for real but Computer Plus is advertising that package
|
||
|
||
at $89.95 in the June and July issues of Rainbow. I just noticed it myself and
|
||
am going to see if they really have it. ---Carl---
|
||
|
||
-*-
|
||
|
||
30290 22-JUN 00:52 Applications
|
||
RE: OS9 Development System (Re: Msg 30184)
|
||
From: BACKFIRE To: ALL
|
||
|
||
I found the last copy at the Port Orchard, WA Radio Shack...after checking all
|
||
over the Puget Sound area...keep trying though, the tools are nice. Selling the
|
||
pkg at 19.95 without advertising the change is just Tandy's way of saying
|
||
goodbye to us...
|
||
|
||
-*-
|
||
|
||
30299 22-JUN 22:23 Applications
|
||
RE: OS9 Development System (Re: Msg 30290)
|
||
From: RAGTIMER To: BACKFIRE
|
||
|
||
One way that might help is to go to a RadShack Computer Center -- I mean a full
|
||
one not affiliated with a regular Shack store. I know they carry supplies for
|
||
old printers and such stuff, under a COMPLETELY DIFFERENT set of catalog
|
||
numbers.
|
||
|
||
So try them before hunting down someone who'll let you borrow their Developer's
|
||
System. Also, by now most of the really good stuff in there is available PD (
|
||
like Tim Koonce's MAKE will soon be) or can be scrounged from Level 1.
|
||
|
||
-*-
|
||
|
||
30312 23-JUN 01:50 Applications
|
||
RE: OS9 Development System (Re: Msg 30299)
|
||
From: BACKFIRE To: RAGTIMER
|
||
|
||
I tried that approach...had one of the salesman at the Computer Center in Tacoma
|
||
|
||
looking all over for C, Pascal and The Dev Pkg. Then I swapped my copy of Logo
|
||
for C (our local club Pres had never used it. ), and he told me about the dev
|
||
pkg. Now (after about a 10 year wait) I can learn to use C. I had patched my
|
||
Level 1 package already...but it's been about the past year that I7ve really
|
||
started using OS-9. ((I still have problems...gport now tells me that my printer
|
||
|
||
and /t2 are not SCF devices!!...but the descriptors and drivers seem to be
|
||
correc t)
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30226 18-JUN 20:20 General Information
|
||
RE: DupFile & DCheck (Re: Msg 30194)
|
||
From: RADARBUZZ To: BRIANWHITE
|
||
|
||
Brian,
|
||
|
||
What do *I* think? <grin>. Well, I've always thought that the copy
|
||
commandshould have been written to recognize whether or not you were copying a
|
||
file tothe same device. If so, it should simply dupe the file by increasing
|
||
that old link count. If not, then really write out another copy to the
|
||
different device.
|
||
|
||
As for a move command, this is how I think that should work: If you're
|
||
moving on the same device then just change the directory pointer thingy. If
|
||
you're moving to another device, then write a copy and delete the original.
|
||
|
||
Now that I got all that out of my system, here is what I think regarding
|
||
Dupfile: Make it capable of all the above. And, (I may be asking for too
|
||
muchhere) incorperate the features presently available in the revised COPY
|
||
command from KLINDSAY here in the utilities database (Shell+ wildcards, auto
|
||
rewrite (-r), copy(or Move!) to directory (-w=), ect...).
|
||
|
||
Now that would be something! Do you think it would be too great an under-
|
||
taking, or not? I won't hold my breath, but I hope my thoughts are feasable,
|
||
|
||
-Jeff
|
||
|
||
|
||
|
||
|
||
-*-
|
||
|
||
30232 18-JUN 23:06 General Information
|
||
RE: DupFile & DCheck (Re: Msg 30226)
|
||
From: GREGL To: RADARBUZZ
|
||
|
||
Jeff,
|
||
|
||
I disagree, at least partially. The copy command should create a new
|
||
directory entry, create a new file descriptor, and physically copy the contents
|
||
of the file. If that were not the case then you would be forced to copy the file
|
||
|
||
to a different device to create a backup file that wouldn't be altered when you
|
||
alter the original.
|
||
However, I agree that the copy command should at least have an option to
|
||
duplicate the file using the same file descriptor - that is, by creating only a
|
||
new directory entry that points to the existing file descriptor and increments
|
||
the link count. It should also accept wildcards and prompt to overwrite existing
|
||
|
||
files. I think your other comments are right on the money.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30342 24-JUN 02:51 General Information
|
||
RE: DupFile & DCheck (Re: Msg 30226)
|
||
From: BRIANWHITE To: RADARBUZZ
|
||
|
||
Jeff,
|
||
|
||
Those are much the same things I had planned. You forgot to mention the ability
|
||
|
||
to put plus signs between filenames to merge them together as they are copied...
|
||
|
||
Oh, I wish I didn't have to go to work...
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30227 18-JUN 20:22 General Information
|
||
WHERE DO I FIND PROGRAMS
|
||
From: MBB63 To: ALL
|
||
|
||
I WOULD LIKE TO DOWNLOAD SHELL+, LABEL COMMAND, DIREC HOW TO INSTALL. ALSO
|
||
DIRECTIONS FOR USING AR PROGRAM. MARIE BOUDET
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30244 19-JUN 02:16 General Information
|
||
RE: failing MPI (Re: Msg 30182)
|
||
From: KNOT1 To: TEDJAEGER
|
||
|
||
This might be unlikely, but could your CoCo have a "compatibility" probnem with
|
||
the new MPI's? Seeing as each CoCo seems to have its own personality, maybe
|
||
trying it with a different one might produce some results. Otherwise, I suspect
|
||
|
||
that you may need to find someone who has successfully hooked up a RS HD with
|
||
the newer MPI.
|
||
|
||
I hope you get it working!
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30363 25-JUN 01:16 General Information
|
||
RE: failing MPI (Re: Msg 30167)
|
||
From: DALEP To: TEDJAEGER
|
||
|
||
Ted,
|
||
|
||
You've got me stumped here! Try a quick mail note to KDarling. He may be able
|
||
to help you.
|
||
|
||
Dale
|
||
|
||
|
||
-*-
|
||
|
||
30374 25-JUN 19:30 General Information
|
||
RE: failing MPI (Re: Msg 30363)
|
||
From: TEDJAEGER To: DALEP
|
||
|
||
Thanks, Dale. I think it was the HD instead of the MPI. The old (7 years) Tandy
|
||
15 meg HD died three days ago. Kept getting harder and harder to spin up to
|
||
speed and finally would not spin at all! It lived a good life! --Bests,
|
||
TedJaeger
|
||
|
||
-*-
|
||
|
||
30406 26-JUN 21:23 General Information
|
||
RE: failing MPI (Re: Msg 30374)
|
||
From: 6809ER To: TEDJAEGER
|
||
|
||
If you are looking for a replacement Tandy 15 Meg hard drive, I have one that
|
||
|
||
was only used for a year and many years left in it.
|
||
|
||
Let me know (use Email) if we can make a deal.
|
||
|
||
Steve , 6809ER
|
||
|
||
-*-
|
||
|
||
30434 29-JUN 02:27 General Information
|
||
RE: failing MPI (Re: Msg 30374)
|
||
From: DALEP To: TEDJAEGER
|
||
|
||
Ted,
|
||
|
||
Sorry to hear about your hard drive. Hope you are able to find another one at a
|
||
|
||
decent price. The scuzzi drives are nice.
|
||
|
||
Best Regards,
|
||
|
||
Dale
|
||
|
||
-*-
|
||
|
||
30454 30-JUN 22:47 General Information
|
||
RE: failing MPI (Re: Msg 30434)
|
||
From: TEDJAEGER To: DALEP
|
||
|
||
Well, thanks Dale. About two days after I think my HD died my power supply died.
|
||
|
||
I am wondering now if my HD is still OK and failed to spin up because it was not
|
||
|
||
getting the right amps. I'll find out when a replacement power supply gets here.
|
||
|
||
I just got the new gfx2. Thanks for the info and help you have provided in
|
||
getting to us. Bests, TedJaeger
|
||
|
||
-*-
|
||
|
||
30621 9-JUL 01:47 General Information
|
||
RE: failing MPI (Re: Msg 30454)
|
||
From: DALEP To: TEDJAEGER (NR)
|
||
|
||
Ted,
|
||
|
||
Good luck with your hard drive. Hope it works out ok. More than likely the
|
||
data on the disk should be ok. Certainly hope so. Did you have the data backed
|
||
|
||
up? CUL. Dale
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30245 19-JUN 02:18 General Information
|
||
RE: CHD Patch (Re: Msg 30196)
|
||
From: KNOT1 To: BRIANWHITE
|
||
|
||
Well, I was/am hoping to hookup a terminal (my CoCo 2) to my CoCo 3. I have my
|
||
CoCo down in my basement, and it would be nice to have a terminal upstairs were
|
||
other family members could easily access it, and it would also be a convenience
|
||
for me. In this vein, I setiup an /H0/USR directory. Then, like the Zenix
|
||
system I use at work, I removed public write permisions from just about
|
||
everything. When I tested it, I had problems with both the "login" and Shell's
|
||
"chd". That's why I decided to try to fix it. I looked for the $103F86 pattern
|
||
|
||
for I$Chgdir, and then for any nearby "lda #"'s. Wasn't too hard to fix after
|
||
that.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30246 19-JUN 04:13 Graphics & Music
|
||
RE: Clipboard (Re: Msg 30193)
|
||
From: MIKEHAALAND To: BRIANWHITE
|
||
|
||
Sure! If you're going to use a specific CB buffer for B&W data just make sure
|
||
post what buffer it is. But I do have a Q. Is the stuff you are planning to
|
||
Clip specific to B&Ws ONLY! If so you don't really need to use the CB group.
|
||
Just use your prcess ID number for the group and use any buffer number within
|
||
that group. Unless the data is useable to another program you don't really need
|
||
|
||
to worry about using the ClipBoard. Know what I mean?
|
||
|
||
Mike
|
||
|
||
-*-
|
||
|
||
30247 19-JUN 18:50 Programmers Den
|
||
IBM keyboard.
|
||
From: NES To: ALL
|
||
|
||
Any body have the pin out of an IBM keyboard connector, I would like to add an
|
||
IBM keyboard to my coco without paying $200 dollars for the one that's in rain
|
||
bow... I know the the keyboard send's its data serially.. any help out there?/
|
||
-Eric
|
||
|
||
-*-
|
||
|
||
30265 20-JUN 07:24 Programmers Den
|
||
RE: IBM keyboard. (Re: Msg 30247)
|
||
From: DONTHRASH To: NES
|
||
|
||
Eric,
|
||
In the May 1983 issue of Byte there is an article that will tell you just
|
||
|
||
about all you want to know about the IBM keyboards. I found the magazine in
|
||
one of the local college libraries. If you have trouble locating this issue
|
||
|
||
drop me a note and I will make copies of my copies and send them to you. Let
|
||
me know how you make out with your project. I have been trying to find time
|
||
to work on a similar project. Time is tight in the summer.
|
||
|
||
Hope this helps,
|
||
Don Thrash
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30250 19-JUN 21:48 General Information
|
||
MM/1
|
||
From: COLINMCKAY To: PKW
|
||
|
||
Greetings!
|
||
|
||
I sent this message originally in mail, but I guess it didn't make it...
|
||
Hope you enjoyed your belated honeymoon.
|
||
|
||
Our local club just had its meeting tonight (Thursday), and there was much
|
||
excitement (Wonder why?) Anyway, there were also a few questions...
|
||
|
||
1. I called to put down $150 the other day using my credit card. Does the
|
||
$50 discount still apply? If not, I will send a cheque.
|
||
|
||
2. It is possible to join two graphics chips and generate pictures of
|
||
720*540*256, which is officially supported by Signetics. Is this supported?
|
||
|
||
3. Also saw the specs for the FHL machine, and mild interest was expressed
|
||
in the AT keyboard. Any future plans on the MM/1?
|
||
|
||
4. What is the option for non-CM8/Magnavox monitors? Is this supported on
|
||
the main board? Will it use stock VGA-type monitors, or does it require
|
||
multisync?
|
||
|
||
5. WRT the optional IO board. How much? And when?
|
||
|
||
6. Without the optional IO board, how do you add a hard drive?
|
||
|
||
7. One member heard the word midi, and his eyes lit up. He wants to know
|
||
exactly what is involved in configuring the DB25 for midi, and how easy
|
||
it is to switch back to normal (switch?)
|
||
|
||
8. What is the planned cost of the palette controller?
|
||
|
||
9. One of your info sheets mentioned 12.5/15 MHz. Haven't seen the 12.5
|
||
before. May we ask why?
|
||
|
||
10. Once you get the second board, do you have to upgrade the memory
|
||
right away? (Beyond 1 Meg.)
|
||
|
||
11. What games does it come with? Enquiring minds want to know! Saw this
|
||
mentioned in your info flyer.
|
||
|
||
12. Will there be a kit form available for those who want sockets? What is the
|
||
expected release date of the kit?
|
||
|
||
13. Will it be CSA (Canadian Standards Association), the equivalent of
|
||
UL/FCC up here, approved? Since we don't have to wait for FCC certification
|
||
up here, any chance of getting one NOW? (RIGHT NOW) (Big GRIN!)
|
||
|
||
14. What size is the power supply?
|
||
|
||
15. Is the software set up for a Logitech or a Microsoft type mouse?. Any
|
||
recommentation either way?
|
||
|
||
|
||
Thanks for your time.
|
||
|
||
Colin McKay
|
||
Ottawa-Carleton OS9 Users Group
|
||
|
||
|
||
-*-
|
||
|
||
30282 21-JUN 20:24 General Information
|
||
RE: MM/1 (Re: Msg 30250)
|
||
From: NES To: COLINMCKAY
|
||
|
||
Colin, The system will support the a stander serial mouse, most chip's are
|
||
surface mount and there are not sockets made for those, The CPU and a couple of
|
||
majore chip's are in sockets, except the Graphics processer which on socket is
|
||
avaible for it. As for the Midi port, You choose when you order weather you
|
||
wount an RS-232 or MIDI port (in and out and thru). they made the system 15Mhz
|
||
instade of 15/12.5Mhz. There is know expantion slots, Just an main board and
|
||
the Optional IO board. main board has the CPU,Graphics controller, two serial
|
||
(One can be an MIDI) ports and 1meg of ram, keyboard interface, disk controler.
|
||
BTW the system is very low power so requres just a small power supply. the
|
||
Second board has the SCSI interface, 3 more RS-232 port(one for mouse), Ram
|
||
upgrade max 9 megs, two paralell ports, stereo port sample and play back. Main
|
||
board... about 749.00 second board $399, if you buy both $1000. about. I think
|
||
|
||
the system has everything the average user would need, software that is comming
|
||
out is an BBS package that supports FIDO NET mail transfer, MV canvase, Video
|
||
digitizer.. also when you buy the MM1 you get.... OSK DOS(os9), C and Basic00,
|
||
a com program, text editor , graphics editor, and some other goodys. -ERIC
|
||
|
||
|
||
-*-
|
||
|
||
30308 23-JUN 00:44 General Information
|
||
RE: MM/1 (Re: Msg 30250)
|
||
From: PKW To: COLINMCKAY
|
||
|
||
Clin,
|
||
|
||
Thanks for all the good questions!
|
||
|
||
Let's take them one at a time. SOme may require no comment.
|
||
|
||
1) Your $50 discount does apply. 2) It is not trivial to gang two VSCs together.
|
||
|
||
THis is done in the CD-I machines and is quite impressive to see. However, keep
|
||
in mind that we do have 320 x 400 in 256 colors, and that is also quite
|
||
impressive. Also keep in mind that we are not making a killing of the MM/1 at
|
||
the $779 price, and adding the second VSC would take the MM/1 out of the reach
|
||
of thousands of CoCo users.
|
||
|
||
3) The added convenience of the AT keyboard is a nice feature, but can easily be
|
||
|
||
accomodated with CTRL-0 or Caps Lock as needed.
|
||
|
||
4) Concerning non CM-8 monitors -- there is a simple approach we implemented to
|
||
let you use a wide variety of monitors. Call for details.
|
||
|
||
202 232 4246
|
||
|
||
5) /send 5) IO Board is $345 when bought with the base system, $399 without. 6)
|
||
You must have the I/O board for hard drive use, but frankly, two HD floppies at
|
||
3 ms will keep you going for quite a while.
|
||
|
||
7) It is easy to change from MIDI to DB25. Call for details.
|
||
|
||
8) Call.
|
||
|
||
9) 12.5 MHz is out. We re 15 Mz only now. At one time, we considered a 12.5 MHz
|
||
machine at a lower cost, but decided to keep the cost down and just standardize
|
||
on 15 MHz.
|
||
|
||
10) No.
|
||
|
||
11) Games? Call.
|
||
|
||
12) Kit is available, although the current one has most chips on it, and already
|
||
|
||
socketed.
|
||
|
||
13) Call.
|
||
|
||
14) 200 watt.
|
||
|
||
15) Any powered mouse will do.
|
||
|
||
Thanks, COlin!
|
||
|
||
-*-
|
||
|
||
30313 23-JUN 01:51 General Information
|
||
RE: MM/1 (Re: Msg 30308)
|
||
From: KSCALES To: PKW
|
||
|
||
Paul -
|
||
|
||
Well, now that I've gone and put my deposit down on a MM/1, I guess I'm
|
||
probably going to spend the next two months or so just thinking and
|
||
planning... and asking questions. If I get to be too much of a nuisance,
|
||
remember that FCC approval doesn't carry all that much weight up here in
|
||
Canada, and having one would probably keep me too pre-occupied to bother
|
||
you with more questions <wicked grin>.
|
||
|
||
Anyways, Colin McKay has already put forward the questions that came up at
|
||
our last UG meeting, and we are watching for your reply. A few more
|
||
questions have come to mind since:
|
||
|
||
- Will you be providing full technical documentation, either as part of the
|
||
standard package, or as a special order item? (schematics, bus interface
|
||
info, tech specs on the "special" chips, etc.)
|
||
|
||
- Will you be providing full Microware documentation?
|
||
|
||
- Monitor interface: yes, CM-8 compatible. But MY CM-8 compatible seems to
|
||
be on its last legs (and new folks coming onboard will probably find
|
||
CM-8s/8CM515s somewhat hard to come by). A VGA-type would make more
|
||
sense nowadays. Sooo... will VGA connection be supported (easily)?
|
||
Would we be best to look for multi-sync for now or future?
|
||
|
||
- Will the I/O board be available for shipping with the initial production
|
||
run?
|
||
|
||
- No audio without I/O board?
|
||
|
||
- What is the hook-up arrangement for the audio ports? (Standard audio/RCA
|
||
jacks?)
|
||
|
||
- If I press CTRL-ALT-RESET on the MM1/1, whose mugs do I see?
|
||
|
||
More to come, probably...
|
||
|
||
Cheers...
|
||
Ken Scales
|
||
(the other) Co-President
|
||
Ottawa-Carleton OS9 Users' Group
|
||
|
||
|
||
-*-
|
||
|
||
30332 23-JUN 22:48 68K-OS9
|
||
RE: MM/1 (Re: Msg 30313)
|
||
From: DWHILL To: ALL
|
||
|
||
Speaking of documentation, has there been any electronics press coverage of the
|
||
68070 and its related graphics chips from Phillips, or CD-I in general? I've
|
||
been cut off from my usual sources since I was laid off in March and have a
|
||
feeling I've been missing a lot of news. Does Phillips provide any information
|
||
through its distributors?
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
30334 24-JUN 01:25 68K-OS9
|
||
Compact Disk Interactive (Re: Msg 30332)
|
||
From: OS9UGPRES To: DWHILL
|
||
|
||
CD-I has been covered lately. Motorola announced support for it with some new,
|
||
very powerful chips intended to be used in players worldwide. More info is
|
||
expected in September after the meeting of an international standards group on
|
||
video compression methods.
|
||
|
||
-*-
|
||
|
||
30410 27-JUN 00:00 General Information
|
||
RE: MM/1 (Re: Msg 30313)
|
||
From: PKW To: KSCALES
|
||
|
||
Ken,
|
||
|
||
All non-proprietary tech docs will be available. Not all will be shipped, but to
|
||
|
||
tell the truth, we have only planned the user manuals at this point.
|
||
|
||
Full tech docs, in the tradition of most computers, will be available separately
|
||
|
||
at relatively low cost.
|
||
|
||
Some tech docs will SURELY be included.
|
||
|
||
Sound IS available on the main board -- a la IBM sound.
|
||
|
||
I/O board WILL be available at the same time as the CPU board.
|
||
|
||
Best to get a color multisync if your CM-8 is on the way out. Cables should be
|
||
availbe in the fall from us, but of course you are free to make your own.
|
||
Sufficient tech information will be made availalbe to allow you to do this.
|
||
|
||
Thx for the questions!
|
||
|
||
Paul
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30251 19-JUN 22:06 General Information
|
||
RE: The T.O.P.S User Group (Re: Msg 30034)
|
||
From: TJMARTIN To: KEITHMARCH
|
||
|
||
Yup, my submission did not seem to make it. dunno why. Maybe it was felt to be
|
||
TOPS property or something. I will try to leave mail for data base manager, see
|
||
what happened. The index is surely intended for distribution. TOPS stuff is
|
||
meant for such public distribution apparently.
|
||
|
||
-*-
|
||
|
||
30262 20-JUN 01:56 General Information
|
||
RE: The T.O.P.S User Group (Re: Msg 30251)
|
||
From: TIMKOONCE To: TJMARTIN
|
||
|
||
Your TOPS submission is already in the database, in the "New Stuff" area. We
|
||
have it set up now so that all new uploads go into "New Stuff" for about a month
|
||
|
||
before they get moved to other areas.
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30253 19-JUN 22:37 Graphics & Music
|
||
Picture Window } V1.0
|
||
From: LL To: ALL
|
||
|
||
Hi everybody!
|
||
I am very happy to inform you that Picture Window Version 1.0 is now ready,
|
||
and available for $7.00 from SEESOF, 1973 Fairgrounds Rd., Burton, SC 29902.
|
||
This version includes a universal picture printing feature that should work
|
||
with most dot matrix printers.
|
||
The program requires Multi-Vue, hires mouse and 512K CoCo 3. It is a window
|
||
picture drawing program that makes & edits & prints VEF bit image pictures.
|
||
PicWin09 is available in the database for a trial copy of all features except
|
||
|
||
printing.
|
||
|
||
LL
|
||
|
||
-*-
|
||
|
||
30255 20-JUN 00:04 Utilities
|
||
RE: New Dir (Re: Msg 30111)
|
||
From: SCG To: KLINDSAY
|
||
|
||
Yes I do use your COPY also VERY VERY NICE. Its Great to have guys like you,
|
||
helping us all out and bettering our systems THANKS!!!
|
||
|
||
Steve Gilbert * Os9 Sysop * ***PC BBS*** *516-795-5874
|
||
|
||
|
||
-*-
|
||
|
||
30264 20-JUN 02:35 General Information
|
||
Hello!
|
||
From: TIMKIENTZLE To: ALL
|
||
|
||
When my girlfriend and I decided to get married, we had a hard time deciding
|
||
what to do about our last names. Although the "modern" solution to this problem
|
||
|
||
seems to be for each spouse to keep their unmarried name, we felt that having a
|
||
single "family name" was very important. So, we have decided to both take a new
|
||
|
||
last name, effective August 4, the date we will be married.
|
||
So, as of August 4, I will be using the Delphi Username TIMKIENTZLE, rather
|
||
than my old Delphi Username TIMKOONCE. EMail will still get to me if addressed
|
||
to either Username, though I may occasionally miss forum messages addressed to
|
||
my old username. Between now and then, I will be logging on under both names.
|
||
- Tim Koonce (soon to be Tim Kientzle)
|
||
|
||
-*-
|
||
|
||
30266 20-JUN 18:15 General Information
|
||
RE: Hello! (Re: Msg 30264)
|
||
From: ZACKSESSIONS To: TIMKIENTZLE
|
||
|
||
Congratulations, Tim! And Best Wishes to the Bride-to-Be! Interesting that you
|
||
two decided to go with an entirely DIFFERENT last name for both of you. Never
|
||
heard of doing that. Umm, would it be too personal of a question to ask just why
|
||
|
||
y'all picked KIENTZLE?
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30272 21-JUN 01:06 General Information
|
||
RE: Hello! (Re: Msg 30266)
|
||
From: TIMKOONCE To: ZACKSESSIONS
|
||
|
||
Yes, it does seem a novel solution, I suppose, but it was the only one that
|
||
really worked for us. After we decided this, we did meet another couple who had
|
||
|
||
done the same thing, so it is doable! <grin>
|
||
Kientzle is actually one of the many mis-spellings (Koonce being another,
|
||
BTW) of the name of my ancestor who came to the New World from Switzerland
|
||
(Yes, back then it was still the "New World". :-) We were hoping to find a more
|
||
|
||
"neutral" name, but couldn't find another one we both liked.
|
||
- Tim (who is never really sure these days what name to use)
|
||
|
||
-*-
|
||
|
||
30273 21-JUN 01:08 General Information
|
||
RE: Hello! (Re: Msg 30272)
|
||
From: ZACKSESSIONS To: TIMKOONCE
|
||
|
||
When I was inthe Navy, I served with a shipmate who's last name was Koontz. Very
|
||
|
||
similar, but a very distinct difference in pronounciation.
|
||
|
||
Wow, you can trace you ancestry that far back? Impressive!
|
||
|
||
Any chance you'll be making it to the fall "October Fest"?
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30283 21-JUN 20:38 General Information
|
||
RE: Hello! (Re: Msg 30264)
|
||
From: NES To: TIMKIENTZLE
|
||
|
||
Tim, sound's yuppy to me, Guess I am old fashion, I know alot of people keep
|
||
there (women) last name for professional reasons, but this is a first make up a
|
||
new name using both last names... How do you say "Kientzle". I wish you and
|
||
your new bride well, Just remember the first year is a killer. -Eric Stringer or
|
||
|
||
mix with the wife Eric Stralonka....
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30269 20-JUN 21:18 General Information
|
||
RE: ST-125 Seagate? (Re: Msg 30190)
|
||
From: JANG To: ZACKSESSIONS
|
||
|
||
|
||
I DON'T HAVE A SEAGATE AS MY /H0. IT'S A CMI 5412 AND I DON'T SEE ANYTHING
|
||
CONSPICUIOUS THERE. IT'S PART OF A SYSTEM I GOT FROM THE GUY AT ARIZONA SMALL",
|
||
DOES ANYONE KNOW WGERE THE TERMINATING RESISTOR IS. ACTUALLY I WILL BE GETTING
|
||
THE MANUAL SOON FOR MY NEW ST-125 AND IT WILL TELL ME WHERE IT'S T.R. IS SO I
|
||
MAY JUST ATTEMPT TO MAKE IT SVEW ^eHR$A9"UL jUjHRT%"u$iErr%j$(Je]?PV It ANYONE ELSE KNOWS WHAT TO LOOK FOR I SURE COULD USE SOME HELP. THANK
|
||
YOU SO MUCH ZACK FOR YOUR INTEREST.. JERRY ANGUS
|
||
|
||
|
||
-*-
|
||
|
||
30295 22-JUN 01:55 General Information
|
||
RE: ST-125 Seagate? (Re: Msg 30269)
|
||
From: DAMIONGREY To: JANG
|
||
|
||
RE: Term resistor : I don't know if this helps any, but the term. resistor
|
||
is usually blue, beige or yellow (in my experience) and looks either like
|
||
a normal dip chip, or like just one side of a dip chip (a sip, actually) HD's
|
||
it's usually the latter. on my
|
||
old Tandon 15 meg it was, so even your old CMI should be that way. It's
|
||
usually near the jumpers, but not always. Personally, I would make the
|
||
20Meg h0 if I were you, not just to avoid the problems, but also to make
|
||
things more usuable. Hope this helps. - Greg
|
||
|
||
-*-
|
||
|
||
30323 23-JUN 14:09 General Information
|
||
RE: ST-125 Seagate? (Re: Msg 30295)
|
||
From: JANG To: DAMIONGREY
|
||
|
||
Yes, thank-you so much.. It was a okhre(dark-yellow-thing), righ next to the
|
||
jumper-(6-element)unit.. As it turns out, with my WD1002-SHD controller I would
|
||
have needed another Hard-Drive EXACTIALLY the same to get it to work OK ..so I
|
||
have resigned myself to the conclusion that i will just transfer everything over
|
||
|
||
to the new 20 Megger (via-floppies) and put the old CMI-Dianasour on the shelf
|
||
as a backup if-need-be, I got the new ST-125 formated(finally) late-last night
|
||
and it seems fi ne.. Thanks To* Zack Sessions, Steve Gilbert, The people at CRC
|
||
and ole-good buddy Roger Krupski (RGB-DOS)... Thanks to all for your concernn.
|
||
Jerry Angus..Pres. Island CoCo Club BBS 516-795-7422
|
||
|
||
|
||
-*-
|
||
|
||
30324 23-JUN 14:17 General Information
|
||
RE: ST-125 Seagate? (Re: Msg 30190)
|
||
From: JANG To: ZACKSESSIONS
|
||
|
||
Yes, I found it finally..Zack.. Thanks again for your help.. I got the new drive
|
||
|
||
formated and will end-up using it by itself so thr Terminating resistor will
|
||
stay in there.. It'll be a chore transfering about 9 Megs of data of
|
||
|
||
XX over to it but some "House-cleaning" was due anyway... thanks a lot for your
|
||
help.... Later....... J.Angus (JANG)
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30271 20-JUN 23:46 General Information
|
||
1 meg upgrade kit
|
||
From: POLTERGEIST To: DISTO
|
||
|
||
Tony,
|
||
What's the purpose for shorting a resistor with the 1 meg upgrade kit? Is
|
||
this related to the timing bug with some GIME chips?
|
||
|
||
-*-
|
||
|
||
30349 24-JUN 08:36 General Information
|
||
RE: 1 meg upgrade kit (Re: Msg 30271)
|
||
From: DISTO To: POLTERGEIST
|
||
|
||
Yes, it has to do something with the RAS timming on the RAM chips. It seems that
|
||
|
||
there are different versions of the GIME chip, and that some people require
|
||
another resistor rather than a short. -Tony
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30275 21-JUN 01:23 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29983)
|
||
From: PAULSENIURA To: TIMKOONCE
|
||
|
||
|
||
-> BTW, you don't need SBF to drive a tape, you can just write an SCF
|
||
-> driver. Tell us what you know, and maybe people on here can help
|
||
-> you with that tape drive.
|
||
|
||
I can't possibly type the entire subset of QIC docs I have received from Freeman
|
||
|
||
Associates, but they will gladly send anyone copies of the various QIC standards
|
||
|
||
to anyone wanting them, without cost (they've even faxed me a couple of pages on
|
||
|
||
their nickel). ANSI has adopted quite a lot of these specs.
|
||
|
||
I think I left these docs at the office (where they'd be most useless, of
|
||
course, wouldn't ya know it?!). I will post Freeman Assoc.'s phone number and
|
||
address once I get those docs back home.
|
||
|
||
But right now I can tell you writing a driver with SCF will be impossible. QIC
|
||
implies "smart drives" as I told Eddie Kunse tonight already. The I/O is done
|
||
in "block" fashion not "single character" fashion. The "QIC Common Command Set"
|
||
|
||
applies to any such smart drive, whether they use the floppy-drive pin layout or
|
||
|
||
the SCSI layout, etc. If you have, for example, a QIC drive that is designed to
|
||
|
||
hook up to a SCSI interface, you still must send to the drive the "commands"
|
||
along those SCSI signal lines.
|
||
|
||
It is hard to explain without the docs. For the floppy-drive QIC-40 standard,
|
||
you will send the drive some commands along the "head step" signal line. No,
|
||
the "head step" is *not* used to have the tape drive step forwards or backwards
|
||
to the next track on the tape. The commands are bit-streamed in any of the
|
||
normal head-stepping set timing standards along this "head step" signal line in
|
||
a SERIAL fashion. The QIC folks barely describe how a WD1793 could be
|
||
programmed to do this -- I mean "barely". Without a "smart controller", our OS9
|
||
|
||
driver will need to lock out IRQs while all this is going on. Not only do you
|
||
send commands to the drive utilizing serial bit streams along a normal floppy
|
||
signal lines, you also get Status messages from these smart drives from other
|
||
floppy signal lines in that same serialized fashion. IRQs must be locked out to
|
||
|
||
read these signals, as the old CoCo bit-banger port is programmed to do! But you
|
||
|
||
must do this thru a WD17x3 chip, not an ACIA chip, since QIC-40 is designed for
|
||
normal floppy controller signal lines. Another QIC-xxx standard will describe
|
||
how SCSI controller signals are used for the very same kind of I/O to a smart
|
||
drive.
|
||
|
||
It's better to do QIC thru a controller card that can allow DMA access to these
|
||
drives. Such is what IBM PC floppy cards can do! You'd think the Disto and
|
||
Performance Peripherals "no-halt" controllers could do this, *especially* Isted
|
||
/FHL's "Eliminator" and B&B's "CoCoXT" board, since these do use IBM-PC
|
||
controller cards. Well, no one has come up with QIC drivers for any of these
|
||
cards. I did see a blurb in Microware's Source book on some companies
|
||
supporting QIC (not QIC-40 tho), but it looks like we're not going to get to use
|
||
|
||
real tape drives with any OS9 system we can afford, despite the low cost of
|
||
these drives, because no one wants to invent these critters.
|
||
|
||
As I said, I'll try to find the QIC docs I do have, and let y'all call Freeman
|
||
Assoc. to ask for the ones you want to start with. The "QIC Common Command Set"
|
||
|
||
is required for any other document, and you'll most likely order several of
|
||
these docs to get a complete set for just one interface. Remember, ANSI has
|
||
adopted quite a lot of these items as real standards for tape drives and
|
||
software drivers to use. Normal floppy controllers are all that's required,
|
||
from what I have been able to gather, such as the WD17x3 chip sets. The
|
||
Colorado Memory Systems (CMS) company who makes the tape drives JameCo is
|
||
selling, is doubtful a good source of information, even tho they have heard of
|
||
OS9 and were extatic to hear we were trying to write a driver.
|
||
|
||
Wait until I can post the whole set of QIC docs available, then I can recommend
|
||
which ones to get in order to start learning more about the coming age of Smart
|
||
Drives.
|
||
|
||
-- Thx, Paul Seniura.
|
||
|
||
|
||
-*-
|
||
|
||
30280 21-JUN 01:43 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29948)
|
||
From: PAULSENIURA To: EDDIEKUNS
|
||
|
||
Pardon me for getting back on Delphi so infrequently .. "things" have not been
|
||
very nice during this span of time for me, personally ...
|
||
|
||
|
||
-> One reason that you don't see a whole bunch of software out there for
|
||
-> the CoCo 3 & OS-9 is that it takes TIME! It takes time to 1) Become
|
||
-> familiar with OS-9 2) Become familiar with OS-9 guts 3) Write and debug
|
||
-> your program.
|
||
|
||
I don't mean to disagree, nor to argue, and I do understand that it takes time.
|
||
How long must it take, though???? OS-9 has been around for such a long time I'm
|
||
|
||
not able to put an accurate figure on it myself), but OS-9 is OS-9 (supposedly)
|
||
especially if you're writing things in 'C' or Basic09 or PASCAL.
|
||
|
||
I didn't mean to be specifically talking about the CoCo3 (or even CoCo1/2 Level
|
||
1 for that matter). But since we brought that up, I personally have had the
|
||
CoCo3 for 3 years. I have had a 64k CoCo1 for (good grief) 8 years, sold it to
|
||
a friend, got it back now for repairs(!). So take the Level 1 or Level 2 as a
|
||
reference, then add on the year or so Tandy gave to developers before the CoCo3
|
||
itself was shipped to the stores. We're talking 4 years minimum we've been
|
||
waiting for things to come out. And now the word is Tandy is dropping the whole
|
||
|
||
ball of wax. Short life span, eh?
|
||
|
||
I get the idea my "gripes" might be misleading: they were not directed at any
|
||
one machine (e.g. the CoCo3) or any certain people/companies. I did include the
|
||
|
||
idea that no matter what the CoCo market moves to -- it could be a Cray/OS9 port
|
||
|
||
for all I care -- if the users can't have easy-to-operate interfaces (MultiVue
|
||
was a 'start'), popular software available (where's WordPerfect/OS9, did ya know
|
||
|
||
they were suppose to have a Unix version coming?), and hardware to use (remember
|
||
|
||
my mentioning the QIC tape drives?), the OS9 market is *not* going to be very
|
||
popular at all with the home/office environment. It'll necessarily stay in the
|
||
industrial applications.
|
||
|
||
And frankly I'm worried about that particular point. At least KLE "plans" on a
|
||
bunch of support, but FHL is the only company "visible" where I can "see" it and
|
||
|
||
get those cards/interfaces "right now" if I need them. They should have been
|
||
developed a long time ago (uh where was Tandy to give 'em to us on the CoCo? why
|
||
|
||
did we have to rely on B&B and Disto et al.?), so that those interfaces could
|
||
have been involved with the various QIC/ANSI and IBM decision-making teams (yes
|
||
ANSI has accepted quite a lot of the QIC tech specs as de-facto standards,
|
||
including QIC-40; I *have* their official docs in hand!).
|
||
|
||
|
||
Now let's move to the Atari/OS9 front: Microware *told* me themselves over the
|
||
phone (I called Des Moines) that there is NO WINDOWs for the Atari OSK system.
|
||
Not even InVisions; it never saw the light of day. Oh they mentioned some
|
||
company in their "Source" book I could call to see what their window system is
|
||
like. I know Kevin Darling had a rudimentary windows version, but still there
|
||
is no "official" supported installable subsystem for Atari/OS9 windows.
|
||
|
||
As a matter of fact, Microware couldn't recommend any other Atari port, Amiga
|
||
port, OSK in general *including* KLE & FHL new products or old, that had true
|
||
windows. I asked Microware point blank: "You mean Tandy was the only one who
|
||
got windows going for any OS9 system, any flavor?" and Microware said "Yes".
|
||
|
||
Now someone better tell me what in blue-blazes is going on, where do you-all
|
||
expect the CoCo market to go, if we can't have true windows at the o.s. level?
|
||
*THIS* is the kind of stuff I'm talking about -- a simple item gets DROPPED and
|
||
I start WORRYING all over the place where we're headed. My lord ... even IBM
|
||
has FINALLY accepted that Windows AND Multitasking is the way of the future home
|
||
|
||
& office workstations. Good grief -- did you hear what I'm saying? IBM *
|
||
finally* got that through their thick skulls, and probably after they heard me
|
||
gripe at a number of local S.E.s (IBM System Engineers) about how our CoCo/OS9
|
||
can run rings around their MesSy-DOS system, for SEVERAL YEARS!
|
||
|
||
Now that you know what IBM knows, someone needs to heed the warnings I've typed
|
||
about in this and previous messages. OS9 isn't going to be popular with home &
|
||
office computers if someone doesn't get "RAVE" and other packages GOING *AND*
|
||
SELLING to the users of the various flavors of OS9/OSK, as well as MOTIVATE the
|
||
DEVELOPERS TO USE RAVE!!!! Savy, KLE and FHL? Do NOT invent your own graphics
|
||
subsystem -- use the official Microware one, or the OS9 market is going to be
|
||
split across a lot of different kinds of graphics SUBsystems underneath your
|
||
flavors of OS9. This also goes for Atari ports and Amiga (Australia) and
|
||
everyone else.
|
||
|
||
If this "hurts" the existing CoCo graphics so-called standard, I'm playing the
|
||
world's smallest violin right now. Your source code should be written in such
|
||
a way that would permit you to change to a different set of protocols if need-
|
||
be. Most of you game programmers don't even use OS9 as a base to begin with --
|
||
those of you who DO use OS9 as a base, you use the old VDG graphics wherein you
|
||
"peek & poke" your own stuff to the video buffer (reading this, UME fans?). I
|
||
can see why: for speed mainly, but also because you're porting your IBM, Apple,
|
||
Atari, or Commodore source code, that does the same thing, to OS9. Cheapest way
|
||
out for you, since Tandy dictated you write your games for OS9 if you want Tandy
|
||
|
||
to sell 'em. I can see all that. Nonetheless, your source code *should* be
|
||
portable to "RAVE" that ought to provide a similar environment for
|
||
peeking/poking (does it?) if the application absolutely must have it that way.
|
||
|
||
Better start thinking NOW about adopting "RAVE" as the standard, or everyone
|
||
start agreeing on another standard. It's probably already too late, huh!? Going
|
||
|
||
to hafta stick with the CoCo window standards, maybe enhance them a little, eh?
|
||
|
||
Did any of you know that ANSI has produced the "Meta-Graphics" instructions?
|
||
They have expanded those video controls to the point that graphics commands can
|
||
be sent via escape-code sequences. Makes ya wonder where they got that idea. :-
|
||
|
||
) Anyway, the POINT HERE is that ANSI *HAS* officially endorsed what WILL BE
|
||
the protocol to use across wires & transmission lines to draw things
|
||
graphically, no matter what kind of boxes are talking to each other. And I
|
||
understand it also includes the kind of window support we already have under
|
||
OS9, including drop-down menus, highlited options via mouse (thru a modem remote
|
||
|
||
application even!), well it's a whole 'nuther book we'll have to buy in order to
|
||
|
||
complete the ANSI 3.64 specs. Remember, these are SPECS, protocols, Standards,
|
||
etc., and you can either be compatible with them, or not. And it should be
|
||
implemented at the o.s. level thereby relieving the application code from doing
|
||
it on a whim-by-whim note -- that source code for the application could be
|
||
PORTED TO OTHER NON-OS9 MACHINES without much rewriting troubles, too!
|
||
|
||
|
||
-> Standards? KBCom NOW supports the VT100 protocal. No, I don't support
|
||
-> ANSI, if you want to call that a standard :) but I plan on eventually
|
||
-> adding a versioin of ANSI that seems to be more widely used than others.
|
||
-> (IBM PC ANSI.SYS)
|
||
|
||
You should not HAVE to support it in your programs: the o.s. should support it
|
||
at a driver or pipe/filter level. That is one point I'll give to IBM/MicroSoft,
|
||
|
||
in that they made ANSI part of the o.s. No one's done it *yet* for OS9 the
|
||
right way (well I did share my ANSIFILx filter on CIS, the *first* of anything
|
||
"doing ANSI" for OS9-L2 windows, and it still is the only one I've seen
|
||
[including your KBCom] that can come close to supporting most of the ANSI
|
||
commands as such, but the CoCo3 runs out of steam when it comes to hooking my
|
||
pgm up to the StdOut of a t.p. & modem running faster than 1200-bps; I know:
|
||
"Rewrite it in 'C'"!). Yep, OS9 needs a system-level ANSI emulator, and no
|
||
one's done it yet despite how ANSI is sorta built-into Unix as well (termcap
|
||
files & such).
|
||
|
||
You see, I spent a bunch of time researching the ANSI 3.64 specs: *that* is the
|
||
official name for these video controls, the book costs around $25, but I'd
|
||
strongly suggest going to your local city or university library and do some
|
||
copying. You'll be amazed -- once you compare 3.64 with VT100, all you will
|
||
NEED to support is 3.64 itself cuz you'll AUTOMATICALLY have VT100 that way. You
|
||
|
||
sure will, *if* you support enough of a subset of commands. Look at the
|
||
OFFICIAL docs, look at some whittled-down docs (a.k.a. IBM PC-DOS Tech guides),
|
||
and you'll find out very quickly they ALL DO MATCH, there is NO such thing as
|
||
"IBM ANSI" vs. someone else's. Not if you support ANSI correctly with the
|
||
largest subset capable of being handled.
|
||
|
||
I'm not "proud" of ANSI at all -- it is such a backward control language -- who
|
||
ever thought of putting the "command" *AFTER* all the data bytes?!?!? Sheer
|
||
stupidness if you ask me! But to do it, ya gotta do it their way. >:-( I
|
||
merely mention lots of people have misconceptions about ANSI -- it *is* a
|
||
standard, or the big corporations would not have all agreed with each other in
|
||
this manner. It's a crying shame that this has been sooo misunderstood. I want
|
||
|
||
to help give peace to these kinds of ideas.
|
||
|
||
|
||
-> KLE & FHL are at war? Actually, I find their machines as being aimed
|
||
-> at very different niches. They may 'fight' to move people from one
|
||
-> niche into another, but the niches are pretty well defined I think.
|
||
|
||
When they are both after my pocketbook, it's a "war". Their "niches" both
|
||
target would-be CoCo3 owners to upgrade to the 68000 CPU. I've read both of
|
||
their brochures and ads -- I do not see any "well defined" niches as you put it.
|
||
|
||
:-)
|
||
|
||
|
||
-> Delphi is a graveyard? I'm speechless! It's all I can do to keep up
|
||
-> here! The OS-9 forum traffic is growing in volume as time goes on.
|
||
|
||
Yeah, I do see there's lots of dialog. I didn't make my point very well. To
|
||
illustrate: someone "just" posted PCDOS.AR not very long ago, and yet it's NOT
|
||
the newest OR the best-fixed-up. I can prove it with the way the CC3Disk
|
||
patches mismatch from one of the latest versions uploaded to CIS over a year ago
|
||
|
||
that I pulled down (I haven't had access to CIS since). (Maybe I can find it
|
||
one of these days & post it, too, and have the OS9 Forum Sysop go double-check
|
||
for permission from the author since I have no access there myself for now.)
|
||
|
||
That's just one example of how things are dead on GEnie and Delphi -- there are
|
||
more, but PCDOS being back-level is putting our SEA Arc 6.02 port way behind
|
||
schedule (i.e. PCDOS.AR is the most important "error" I've seen on the Delphi
|
||
uploads so far). Another way to say how dead things are: compare the amount of
|
||
new strictly-OS9 uploads on CIS vs. GEnie and Delphi put together!!
|
||
|
||
|
||
-> UME & standard MIDI: I really know very little about this one. Just
|
||
-> one comment: Give the man time!
|
||
|
||
If you mean Mike Knudsen, he's had 5 years already according to his own UME
|
||
booklets! :-) But my point wasn't taken with a larger scope I had in mind,
|
||
such as how Lester Hands and a WHOLE BUNCH OF OTHERS had plenty of time, as Mike
|
||
|
||
has, to do "something" -- *SOMETHING*. Lester gave up and went on to porting
|
||
Lyra to the IBM-PC money-making market. I've asked plenty of people, "Dr.T" for
|
||
|
||
one (very popular on the Atari MIDI market), to whom I can directly ask
|
||
questions on GEnie, if they'd let some of us OS9ers strike a contract with them
|
||
to port their products to OS9 esp. on the CoCo. All I got was deaf ears.
|
||
|
||
You see, no one knows what OS9 is, what it's about, who & what runs it. Good
|
||
grief, I had the GEnie MIDI Forum Sysop ask me if "it was public domain" for
|
||
crying out loud! (I *still* have that dialog captured and saved it for future
|
||
reference under "Signs of Ignorance"!) They quickly got the usual run-thru,
|
||
stuff like it looks & feels just like Unix, etc., etc., but it's a lot nicer
|
||
with the "true real multitasking windows developed by Tandy and Microware". And
|
||
*that* concept was ANOTHER bottleneck!
|
||
|
||
I'm not saying PC programmers are stupid -- Ignorant:yes, due to their
|
||
unenlightedness (e.g. not their fault) -- Dumb:no. Most of 'em, even IBM's, are
|
||
|
||
kinda sloppy sometimes. They have no idea how to program efficiently, since now
|
||
|
||
they can hog all the 2-meg and 4-meg cards you put into a PC. They have no
|
||
concept of multitasking, of how to write SHAREable code (re-entrant and
|
||
relocatable at *any* time), until/unless they move on to OS/2[tm-IBM] or some
|
||
kind of mainframe. For the most part is what I'm saying. I could go on!, but
|
||
I won't. But with everyone involved with PCs pouring in their efforts, just
|
||
look at how good MIDI is implemented on PCs. Now look at how MIDI stands on the
|
||
|
||
CoCo. Shameful. MIDI isn't the only standard I'm talking about, but it clearly
|
||
|
||
opened my eyes as to where we CoConuts and OS9ers stood in relation to "everyone
|
||
|
||
else".
|
||
|
||
|
||
-> I think that about two years back a *LOT* of unrelated and separate
|
||
-> projects startup up (Fido, UUCP, KBCom, OS-9 LII upgrade (?), all the
|
||
-> unZip & deArc programs, ...). It takes TIME to port things over, and
|
||
-> it takes time to write stuff from scratch. Esp since most (?) people
|
||
-> who are working on projects like this aren't payed to do it, and thus
|
||
-> must work in their spare time.
|
||
|
||
When I first approached some CIS OS9 gurus about porting SEA Arc 5.12 over to
|
||
OS9, they all said it'd be more-or-less impossible. It didn't take much time to
|
||
|
||
decide the fate of having Arc compatibility for OS9. I didn't want them to do
|
||
it, just to help me get started. That was in 1988. And it came from the
|
||
smartest dudes I still respect.
|
||
|
||
The problem isn't "Time" -- the problem is "Motiviation". You motivate people
|
||
to develop products with $money$ and the out-right NEED for that product. The
|
||
NEED could not be any greater when it is realized that the market forces us to
|
||
go with their own standards. Fido, for example, will not let us use AR or PAK
|
||
or anything else (TC3?!) to compress Mail Packets: it "requires" SEA Arc 5.12 as
|
||
|
||
a bare minimum. There couldn't be a NEED any greater than when the standards
|
||
dictate what we must use. Yet in 1988 no one wanted to help us make SEA Arc
|
||
available for OS9. And I uploaded to CIS the huge source code with SEA's
|
||
permission to get the ball rolling! We had the sources, yet no one wanted to
|
||
scoot closer and help. They all backed away.
|
||
|
||
Yes I'm one of those "unpayed" people -- OS9 is just a hobby with me, remember,
|
||
but I'm one of those who are determined to see that OS9 can do things just as
|
||
good as the big blue machines do them (oh maybe not as fast, but JUST AS GOOD).
|
||
|
||
I'm also a system programmer who sees where things are going as a total picture,
|
||
|
||
and read those trade magazines. I'm saying lots of "us" volunteers are just
|
||
spinning our wheels if we don't get something "real" going -- things that are
|
||
"really" needed in other words. We DO NOT NEED another GIF viewer, unless it's
|
||
for the KLE and FHL graphics systems ... I see the STRONG need for lots of
|
||
people to get cracking on the tape cartridge backup system. Right now if not
|
||
two years AGO (which would have made it ready for use in B&B's CoCo-XT
|
||
interfaces!).
|
||
|
||
I've named several other needs and requirements in previous messages, one
|
||
special-interest need in particular would be for music lovers: the Standard
|
||
MIDIFile (SMF) support. I've been belly-acking to Mike Knudsen about this ever
|
||
since the UME thing went commercial. If he didn't want to support SMFs soon, at
|
||
|
||
least publish his file/record layouts so "we" can try writing a converter, just
|
||
like Lester Hands published his Lyra formats. Yes I said I've personally asked
|
||
Mike to provide us with that info more than a year ago. I see that he's posted
|
||
those docs just about two months ago, almost to the day Delphi opened up my
|
||
account! Coincidence??
|
||
|
||
I don't mean to pick on Mike -- I'm just saying how programmers go out and do
|
||
their own thing without doing any market research (well not "much" anyway) when
|
||
they start selling their product. When I do something, I grab everything I know
|
||
|
||
and go out to research it. To learn about MIDI, for example, I *actually*
|
||
JOINED the International MIDI Association and ORDERED their OFFICIAL DOCS. What
|
||
does everyone else do? Did Mike join the IMA? Did Second City Software (Ed
|
||
Hathaway) provide him with those same official docs in support of him developing
|
||
|
||
UME for exclusive sales? I honestly do not know ... I'm just making a point
|
||
here for everyone reading this. I'm not criticizing Mike and SCS at all ... but
|
||
|
||
if the answer is "No" to that question, well it's something to start thinking
|
||
about, especially if they intend on supporting SMFs, as the official docs *have*
|
||
|
||
changed (a few points quite drastically) since the version 0.06 docs were shared
|
||
|
||
amongst the networks. Any official MIDI docs are *now* copyrighted and *must*
|
||
be ordered from the IMA at extremely cheap rates.
|
||
|
||
Remember, I only bring up UME, MIDI, IMA, etc., only as one example of how
|
||
things need to be approached when commercializing your programs. The research
|
||
must be done and then the protocols etc. must be properly supported, or your
|
||
product will wither and die because, quite simply, it's not usable with the way
|
||
the market *is* set up. The MIDI market, to continue this example, follows
|
||
strict guidelines in most respects of its protocols and implementations. Quite
|
||
a lot of the manufacturers of keyboards add on to those specifications, but none
|
||
|
||
of them "change" those BASIC specs that MUST be compatible with other machines.
|
||
In fact, MIDI is such a wonderfully-agreed-upon standard, EXACTLY how the ANSI
|
||
stuff is agreed upon btw, that it's pure magic almost to see all the music
|
||
makers working with all that equipment -- I mean the hookups etc. WORKS, as in
|
||
hit that button and it DOES something that it is EXPECTED to do!
|
||
|
||
|
||
-> As *I* see it, the people in the OS-9 community are bending over
|
||
-> BACKWARDS to give away their hard-earned secrets and to give newcomers
|
||
-> all the help and support they need to get off to a running start.
|
||
|
||
That IS fantastic. I'm not addressing that issue at all, not even a teeny bit.
|
||
|
||
The issue is how OS9/OSK is going to support the machines that are out there to
|
||
be bought and used. The issue continues by expanding into what some of these
|
||
developers are doing, what they are planning to do, and how they are going to do
|
||
|
||
it. I'm talking about COMMERCIAL products, not "shareware" or "freeware" (
|
||
although these people need to heed my warnings, too).
|
||
|
||
MIDI and ANSI are two standards (of MANY) out there to be supported as if it is
|
||
hardware to be hooked up to your computer. The drivers etc. must be "that"
|
||
compatible. And this is only two of the many items awaiting to be used by OS9
|
||
users in the right way -- e.g. supported by the o.s. ITSELF (speaking of ANSI),
|
||
not by each application's own code & logic *if* the programmer decided to
|
||
include it on his own whims.
|
||
|
||
And then there are REAL hardware items out there to be used: QIC tape drives,
|
||
CD-I and CD-ROM, even some 9-track half-inch reel-to-reel tape drives! A whole
|
||
gamut of disk drives up to 600-meg in the space of a 3.5-inch drive!! Did you
|
||
know a company is coming out with a 20-meg FLOPPY the PRECISE SIZE OF A 3.5-inch
|
||
|
||
FLOPPY???? This drive *will* be able to switch down to 5-meg and 1.44-meg and
|
||
720-k compatibility formats. It sounds like it'd be one of those "Smart" drives
|
||
|
||
that uses the QIC Common Command Set (yet another official document I have).
|
||
|
||
OS9 gurus hear this clear: smart drives are coming and some of them are already
|
||
here. You cannot use SCF methods to talk to these drives. I have some of the
|
||
QIC docs, remember; I have read them and I am warning the OS9 market that
|
||
they'll be the next big break in storage technology. I'll bet, based on past
|
||
history, that OS9 market/companies won't do much to help us utilize these smart
|
||
drives. I would love to use a 20-meg 3.5-inch floppy, but will *some* company
|
||
provide the interfaces and OS9/OSK drivers?
|
||
|
||
And I'm not even going to start talking about EGA, VGA, Super-VGA, etc. That
|
||
stuff is out there ready to be used under OSK. Why can't we use those cards
|
||
"now" and port "RAVE" to use that hardware? Why hasn't anyone even thought of
|
||
this as a cost-reducing effort, in lieu of developing a graphics system on the
|
||
KLE & FHL based on CD-I chips, for example? These IBM-PC video boards come with
|
||
|
||
their own memory that does not eat into the 68000's space (or 6809/GIME,
|
||
whatever). Well, no one asked me ... it's too late now, apparently.
|
||
|
||
|
||
I'll keep reading everyone's replies ... let's keep the dialogs (and
|
||
controversy) going! Surely some power players in the OS9 arena will get our
|
||
hints and decide to start supporting and implementing these ideas.
|
||
|
||
-- Thx, Paul Seniura.
|
||
|
||
|
||
-*-
|
||
|
||
30291 22-JUN 01:35 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30275)
|
||
From: TIMKOONCE To: PAULSENIURA
|
||
|
||
Paul,
|
||
The only diff between SBF and SCF is that SBF gives the driver a block at a
|
||
time to write, rather than a character at a time. The driver is still
|
||
responsible for ALL of the hardware-dependent stuff you mentioned. Using SBF
|
||
will not alleviate any of this.
|
||
You're confusing SCF (the file manager) with ACIAPAK (the UART driver). SCF
|
||
is used to talk to _any_ device that uses "streams" of bytes for I/O, including
|
||
printers, serial ports, the screen, keyboard, etc. SBF just takes that stream
|
||
and breaks it into blocks to give to the driver. To do the same under SCF, the
|
||
driver would just have to buffer a block before sending it.
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
30294 22-JUN 01:53 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30280)
|
||
From: TIMKOONCE To: PAULSENIURA
|
||
|
||
Well, Paul, it is interesting to see that people put so much faith in standards.
|
||
|
||
A now-famous quote in some circles:
|
||
"The wonderful thing about standards is that there are so many to choose from"
|
||
|
||
While I don't claim to be an expert on the standards you mentioned, I do know
|
||
|
||
a fair bit about ANSI, and can tell you that IBM PC ANSI.SYS is quite distinct
|
||
from X3.64. To quote from X3.64, page 13:
|
||
"The implementation of all of the controls described in this standard .. is
|
||
not a constraint..."
|
||
In plain English, this means that if you implement some fraction of X3.64,
|
||
and then add some more stuff not defined in there, you're still X3.64-compliant.
|
||
|
||
If you compare the extensions added by IBM ANSI.SYS, and VT100 for instance,
|
||
you'll find some pretty serious differences. Also, I'm amused by your claim
|
||
that IBM did good by including ANSI.SYS, especially since I've never heard of a
|
||
commercial PC program that uses it.
|
||
I had not heard of the "standard graphics extensions" for X3.64. Care to
|
||
elaborate on where these came from? Or where more information can be found.
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
30300 22-JUN 22:26 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30291)
|
||
From: RAGTIMER To: TIMKOONCE
|
||
|
||
So would SBF be any faster or more efficient? Like when doing X/YMODEM
|
||
transfers? Can you "flush" SBF if the current block isn't full?
|
||
|
||
Yeah I know SBF is for tape drives, but then constructive abuse of modules is
|
||
what Coco OS9 is all about, grin.
|
||
|
||
-*-
|
||
|
||
30302 22-JUN 22:33 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30294)
|
||
From: RAGTIMER To: TIMKOONCE
|
||
|
||
Well, I used to run a psych test scoring program that my wife's company had
|
||
bought, and it required ANSI.SYS or else a messy screen. Not a program most
|
||
users would ever run across, tho.
|
||
|
||
"Standards? I believe in standards. I thinks every company oughta have two or
|
||
three of'em!" Hey, I remember when RS232 was considered a standard...
|
||
|
||
-*-
|
||
|
||
30353 24-JUN 15:55 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30280)
|
||
From: OS9UGPRES To: PAULSENIURA
|
||
|
||
Paul - Have enjoyed your messages. Some sidenotes on windowing:
|
||
|
||
The InVision (now called RAVE) port to the ST wasn't done because no one has
|
||
paid for it. Actually, it _was_ ordered at one time, then cancelled at the last
|
||
second. I know, because I was originally contracted to do it. Anyone could order
|
||
|
||
the portpak and do it themselves, tho. Again, a matter of money and desire.
|
||
|
||
BTW, RAVE doesn't have a window manager yet, so it's basically just a very good
|
||
drawing platform for control computers right now.
|
||
|
||
However, there _are_ other windowing systems for OS9/68K. The MGR windowing
|
||
system from Bellcore Labs is one. GWindows from Gespac is another. Both are
|
||
available on the ST. The MGR port is PD, I think. GWindows is around $100
|
||
without any programming libraries at all... those are another $200 or so. They
|
||
haven't decided yet.
|
||
|
||
Both look pretty good, I hear; tho not exactly speed demons. Both are in C,
|
||
around 120K long. My windows, which are in asm, will also be ported to the ST
|
||
and Amiga, which should give us a broad base of users/programmers.
|
||
|
||
BTW, X should be out this fall from Microware, so the rumors go. No idea on its
|
||
price. - kev
|
||
|
||
-*-
|
||
|
||
30387 26-JUN 00:09 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30353)
|
||
From: RAGTIMER To: OS9UGPRES
|
||
|
||
Any ideas on its (X Wndows) size or speed, he he? THe word is that X is pretty
|
||
big and not too fast. I just got a book on it and they say "use a platform with
|
||
|
||
all the raw power you can get." But anyway, an Official X for OSK will enhance
|
||
its value in the market, certainly to the '020 crowd.
|
||
|
||
We know YOUR windows will be lean and mean! --mike k
|
||
|
||
-*-
|
||
|
||
30403 26-JUN 20:57 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30387)
|
||
From: ZACKSESSIONS To: RAGTIMER
|
||
|
||
At my day job I use a DEC VAXstation 3100. It is running DECwindows, DEC's
|
||
implementation of X-Windows under VMS. The 3100 runs at around 3 MIPS (thats
|
||
MIPS, not MHz!) and has 8 mb memory. Some people may consider some of the window
|
||
|
||
functions slow, but it is fine with me! After using OS9 L2 for almost 2 years, I
|
||
|
||
was REAL happy to get a (read ANY) window system on my desk!
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30419 27-JUN 21:24 General Information
|
||
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30403)
|
||
From: RAGTIMER To: ZACKSESSIONS
|
||
|
||
OK. I use a Sun 3/60 running Snview 4.0, with 12 MB. It's jnjot nearly as
|
||
snappy as the older Suns running 3.0, but a guy down the hall who is
|
||
experimenting with X Windows on the Sun (sorta like MSDOS on the Amiga) says X
|
||
is much faster than Sunview.
|
||
|
||
Of course Sunview requires hundreds of K, and since it runs over UN*X, the first
|
||
|
||
2 MB don't count!
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30276 21-JUN 01:23 Graphics & Music
|
||
RE: Weather Radar (Re: Msg 29972)
|
||
From: PAULSENIURA To: ZACKSESSIONS
|
||
|
||
|
||
-> First of all, the VEF pic file you include is not exactly in "true" VEF
|
||
-> format. The first two bytes of a VEF pic file from a Type 8 window
|
||
-> whould be $0000, not $0008.
|
||
|
||
Someone on CIS documented the VEF stuff, and that field should be the "Screen
|
||
Type" code (STY) as described on page 3-13 of the Windows section of Tandy's OS9
|
||
|
||
L2 books. Mind you, I have not been on CIS for a very long time, so if someone
|
||
will give me the official ratified agreed-upon 100% true blue VEF documentation,
|
||
|
||
I'll change the program. :-) I don't want someone's interpretation of this
|
||
standard, I need the official typed-up standard itself, please, so I can do it
|
||
right despite what everyone thinks it should be.
|
||
|
||
If there isn't such documentation available, I'll consider "VEF" a non-standard,
|
||
|
||
and it's anyone's ball game as to what should be in those fields. (If that
|
||
statement wasn't strong enough to make people provide official docs, I don't
|
||
know what *will* make 'em do it!)
|
||
|
||
-> And the file length should be 32018, not just 30738 bytes.
|
||
|
||
Lessee according to my math:
|
||
|
||
320_dots_per_line * 192_lines / 2_dots_per_byte = 30720
|
||
|
||
Right? Now you need to add 16 bytes for the palette table, and then 2 more
|
||
bytes for that STY field, so 30720+18 = 30738.
|
||
|
||
Since no one officially supports 200 lines on a graphics screen, but rather only
|
||
|
||
192 lines are officially supported in any package I've ever gotten, and only 192
|
||
|
||
lines are visible (sans our GrfDrv patches I documented on GEnie last year), I
|
||
do not see how you can come up with your numbers. :-)
|
||
|
||
Make it a standard, then maybe we'll start implementing it!
|
||
|
||
|
||
-> Now how 'bout us poor folk who lives elsewhere in the US of A? Color
|
||
-> Weather Radar sites do cover most of the country y'know. Someone from
|
||
-> each state gonna have to take it upon themself to spend the time
|
||
-> creating a VEF map of their state?
|
||
|
||
Well that's why I eluded to having to do things right. I want to ask the SAS
|
||
Institute what I proposed in my documentation there (I shan't repeat all that
|
||
goop here). We *can* get "official" state maps and "official" locations for the
|
||
|
||
NWS radar locations, but just how we do that is up in the air right now.
|
||
Certainly no one needs to "take it upon themself to spend the time creating a
|
||
VEF map". The "official" maps have been created by SAS Inst. with computerized
|
||
projected coordinates. We just need to do some asking, probably. We then must
|
||
agree to some kind of location-dependent program parameters: scaling factors,
|
||
location of the radar site on "that" state map, etc. Kinda like the 'env.file'
|
||
that comes with MultiVue, maybe, I dunno.
|
||
|
||
|
||
-> Now, as to getting the data to plot in the first place. When you
|
||
-> mention, "I hope we can get a tie-in to the NWS for access to their
|
||
-> current B-Scan weather files.", I assume you mean Delphi or GEnie?
|
||
|
||
No, it'd have to be your local radar site! You would want completely current
|
||
information, what is happening "right now", etc. CIS updates their maps about
|
||
every 15 minutes. I'm wanting to tie into getting the Doppler info, too! Good
|
||
grief, seeing those hooks, that signify a tornado coming, *WILL* save your life!
|
||
|
||
! I've been told NWS sites should have more info on what we need to know to ask
|
||
|
||
etc. I've been told by this same person that PC BBSs have been doing this and
|
||
providing this service for free, in that they'd dial up NWS and do automatic
|
||
selections of their menus via the modem & a "smart" program "reading" the menus.
|
||
|
||
That's how our AT&T 3B2 UNIX box at Okla.D.O.T. is doing it. (They have a
|
||
leased phone line to the Will Rogers Airport, *not* NWS.) Again I'm told the
|
||
NWS might/should have some local access computer lines available with real short
|
||
|
||
time limits (how do TV stations without the expensive radar gear do it?) so
|
||
people can access what they want to get & then log off. What they get are these
|
||
|
||
B-Scan files or similar -- not "graphics".
|
||
|
||
|
||
-> (btw, anyone besides me remember when all the Weather Channel did was
|
||
-> scan a TV camera back and forth on a bunch of instruments!)
|
||
|
||
Oh boy ... those farm towns that had "cable TV" had such weather channels! Here
|
||
in Oklahoma it wasn't that many years ago (mid 1970's when I first started
|
||
working for Okla.D.O.T.). Those old round meters! Well, now everyone's gone to
|
||
|
||
the new Weather Channel with all that satellite data transmitted to their sites.
|
||
|
||
Hmmm, that's an idea ... who's got a CoCo hooked up to their dish antenna so we
|
||
can aim & pull down some GEOS pics directly??? The people who wrote WEFAX would
|
||
|
||
quickly go out of style!!
|
||
|
||
|
||
-- Thx, Paul Seniura.
|
||
|
||
(p.s. let me know if you find out anything from your NWS site!)
|
||
|
||
(p.p.s. I do have a newer version that has a "PPOINT" type subroutine of general
|
||
|
||
interest to everyone who does graphics. PPOINT is, of course, the way RS-BASIC
|
||
can inquire upon the color of a certain graphic pixel, which there is no
|
||
counterpart in OS9 right now. This helps us keep "stronger" radar blips on the
|
||
screen when the next radius is drawn. But it is getting rather slow, and the
|
||
"arc" we draw with a straight line still isn't looking better. We even tried to
|
||
|
||
"average" the "last" value of a pixel with the next radius' value for that same
|
||
pixel (caused by rounding of the X,Y coordinates). Whatever we can do to make
|
||
this newer version look better, that's what we'll upload & let y'all test ...
|
||
"whenever" we get time, ya know ...)
|
||
|
||
|
||
-*-
|
||
|
||
30296 22-JUN 01:58 Graphics & Music
|
||
RE: Weather Radar (Re: Msg 30276)
|
||
From: TIMKOONCE To: PAULSENIURA
|
||
|
||
Paul,
|
||
There are such things as "informal" standards, and perhaps you should go
|
||
back and re-read those original docs of yours more carefully. If you would like
|
||
|
||
to see some VEF docs that are as close to official as you'll ever get, look in
|
||
the Graphics database here for a group that I uploaded. It's entitled something
|
||
|
||
like "Picture Format Specs", and contains specs for a number of different CoCo
|
||
picture formats compiled from a variety of sources. They are about as official
|
||
as you can get in the CoCo world. If you'd like to submit them to ANSI, feel
|
||
free! <grin>
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
30297 22-JUN 18:25 Graphics & Music
|
||
RE: Weather Radar (Re: Msg 30276)
|
||
From: ZACKSESSIONS To: PAULSENIURA
|
||
|
||
>Someone on CIS documented the VEF stuff, and that field should be the "Screen
|
||
>Type" code (STY) as described on page 3-13 of the Windows section of Tandy's
|
||
>OS9 L2 books. Mind you, I have not been on CIS for a very long time, so if
|
||
>someone will give me the official ratified agreed-upon 100% true blue VEF
|
||
>documentation, I'll change the program. :-) I don't want someone's
|
||
>interpretation of this standard, I need the official typed-up standard
|
||
>itself, please, so I can do it right despite what everyone thinks it
|
||
>should be.
|
||
|
||
Well docs have been provided, but who can say that they are "offical"? Tim
|
||
Koonce uploaded a series of files in the Graphics&Music lib just a few
|
||
weeks ago. Group Name is "GRAPHICS FORMATS". It agree with every program
|
||
I have which performs VEFIO of some kind. This includes MAX9, VEFIO,
|
||
ViewVEF, WLoad.B09, and View. I first figured it out be dEding picture
|
||
files, reading Kevin Darling's source to WLoad.B09, and the source to
|
||
VEFIO.
|
||
|
||
They all agree that the second byte is a "code" which describes window
|
||
type and resolution. Check vef.hlp in the aforementioned group. It also
|
||
states that 200 lines are defined, even though many display programs
|
||
ignore the first eight lines. MVCanvas will, however let you display and
|
||
edit all 200 lines. (Not all at once, though!)
|
||
|
||
>Lessee according to my math:
|
||
>
|
||
> 320_dots_per_line * 192_lines / 2_dots_per_byte = 30720
|
||
>
|
||
>Right? Now you need to add 16 bytes for the palette table, and then 2 more
|
||
>bytes for that STY field, so 30720+18 = 30738.
|
||
>
|
||
>Since no one officially supports 200 lines on a graphics screen, but
|
||
>rather only 192 lines are officially supported in any package I've ever
|
||
>gotten, and only 192 lines are visible (sans our GrfDrv patches I
|
||
>documented on GEnie last year), I do not see how you can come up with
|
||
>your numbers. :-)
|
||
>
|
||
>Make it a standard, then maybe we'll start implementing it!
|
||
|
||
As I mentioned, MVCanvas DOES officially support 200 lines. And all viewer
|
||
programs I previously mentioned are programmed to ignore the first eight
|
||
lines, which means since the expect to read and ignore them, then in a
|
||
way they ARE supported. Also, EVERY VEF format picture file (except your
|
||
OK map!) are 32018 or 16018 bytes large. Download a few from the library here
|
||
and do a dir e on them and see for yourself.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30281 21-JUN 01:52 General Information
|
||
our RiBBS test site
|
||
From: PAULSENIURA To: ALL
|
||
|
||
P.S. our official RiBBS test site BBS # is 405-670-6636, 3/12/24/9600 8n1, MNP5
|
||
/ARQ/HST with a real USRobotics Courier HST modem (not the newer 14.4k-bps ones)
|
||
|
||
. I'm having trouble reaching Ron Bihler for latest fixes, still having a few
|
||
troubles with Fido on different mail feeders on them other IBM-PC compatibles,
|
||
but almost every module RiBBS comes with is loaded into RAM while we're using
|
||
Disto's 1-meg upgrade too! It's quite fast, in other words!
|
||
|
||
I'd estimate we have a menu system about 300k big, some of 'em very colorful (
|
||
experimenting and test-site, remember, not a real BBS yet, but y'all will have
|
||
access to everything but the Fido options -- I promised the FidoNet local
|
||
coordinators I'd not let users have access to buggy software until it's 100%
|
||
working order).
|
||
|
||
Even with such a big set of menus, since these things are copied to a RAM disk,
|
||
the hot-key effect on menus is almost instantaneous. I.e. almost everything
|
||
that RiBBS v2.0 comes with (that does not need changes to be saved) is in RAM in
|
||
|
||
one form or another, and we didn't have to rewrite =any= of Ron's code to do it.
|
||
|
||
Contrast this to products like UME that won't let you customize the use and size
|
||
|
||
of RAM for various functions (not to mention staying away from system problems
|
||
using Get/Put buffers -- RAMdisks are 100% trustworthy when the VDD.AR patch is
|
||
installed!).
|
||
|
||
Yep, RiBBS v2.0 *is* one of those products we've been badly needing -- Ron
|
||
proves that CoCo/OS9 can do what the big blue machines have been doing: Fido!
|
||
"ARF!!" And Ron needs to be congratulated and written up in the Rainbow for
|
||
this effort. Yes this needs to be put into the "OS9 Spotlight" column.
|
||
|
||
It would show why such "compliance" to the already-agreed-upon standards in
|
||
various industries needs to be done. And "compliance" still needs to be done
|
||
"correctly" for ANSI video, QIC tape drives (including "smart" SCSI drives),
|
||
etc., on the commercial OS9 marketplace.
|
||
|
||
(now if Ron would just clean up his code, pare-down the 16k "Connect" module to
|
||
8k etc.!, fix the remaining bugs, put in just a couple more features, he could
|
||
sell it at a price level comparable to the commercial PC BBS packages go for!
|
||
And I'd be willing to splurge that much. I'm *trying* to make a point: your
|
||
products *will* make money if you design enough "guts" into them to make them
|
||
worth that much money. And support your products, too.)
|
||
|
||
-- Thx, Paul Seniura.
|
||
|
||
|
||
-*-
|
||
|
||
30284 21-JUN 21:56 Programmers Den
|
||
C.ASM problems....
|
||
From: DODGECOLT To: ALL
|
||
|
||
Hi all,
|
||
Well, I am having a small problem here with c.asm and one of the library
|
||
function files for my CGFX lib. Basically, c.asm isn't reading the whole
|
||
assembly code file and is missing some constant strings. This leads to the
|
||
inevidible message from the linker that it can't find the reference to the
|
||
string. Funny thing is, when I check out a listing of the code it is producing,
|
||
it appears that the first pass figures the offset out OK, but the it seems to
|
||
stop before it actually gets to the symbol in question. Anyone have any clues?
|
||
-Mike
|
||
(BTW, I have tried both optimized and not)
|
||
|
||
-*-
|
||
|
||
30289 22-JUN 00:22 Programmers Den
|
||
RE: C.ASM problems.... (Re: Msg 30284)
|
||
From: DODGECOLT To: ALL
|
||
|
||
An update- it appears that the problem was caused by a bug in the compiler- the
|
||
string I was writing contained several chars that were > $7f (bit 7 set) In any
|
||
case, the compiler threw those chars into an 'fcc', which c.asm doesn't like.
|
||
So much for THAT problem...
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30298 22-JUN 22:19 Programmers Den
|
||
RE: C.ASM problems.... (Re: Msg 30289)
|
||
From: RAGTIMER To: DODGECOLT
|
||
|
||
They must have put that bug in to keep us from hard-coding ESCape sequences. And
|
||
|
||
if you believe THAT...grin.
|
||
|
||
Did you see the c.prep bug we talked about here a couple months back? If you say
|
||
|
||
#define toolong "abcdefgh"
|
||
printf(toolong); you only get the first 7 (or was it 8?) characters -- the
|
||
macro preprocessor can't take any more. Then someone (Dale P?) added that if you
|
||
|
||
stick a blank space or something like that in there, it will work OK for any
|
||
reasonable length.
|
||
|
||
Hope Microware is braced for a flood of bug reports once the MM/1 comes out.
|
||
Unlike those old commercila programmers, we coconuts really "exercise" the
|
||
compiler. Grin, maybe. --mike k
|
||
|
||
|
||
-*-
|
||
|
||
30303 22-JUN 22:39 Programmers Den
|
||
RE: C.ASM problems.... (Re: Msg 30298)
|
||
From: DODGECOLT To: RAGTIMER
|
||
|
||
Didn't know about <that> bug! Yea, I'm sure we will have those MW programmers
|
||
running around once the new machines come out!
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30286 21-JUN 23:47 General Information
|
||
RE: Serial Mouse (Re: Msg 30197)
|
||
From: OS9UGVP To: BRIANWHITE
|
||
|
||
Brian,
|
||
Yes, this is Bruce Isted here... I suppose I should sign with my full name.
|
||
Oh well. I know why the mouse occasionally seems to screw up and then recover,
|
||
and I will fix it now that I have the OK I needed before I would use the fix.
|
||
Look for it fairly soon, but no promises that it'll be real soon.
|
||
Lets see, I put all that work into the ballistic mouse speed up stuff, and now
|
||
|
||
you want them taken out <sob> - actually thats a <grin>
|
||
No problem... when i upload the new serial mouse file I'll include patch
|
||
offsets & whatnot to let you turn the ballistic stuff off. As it is right now
|
||
I'm not sure whether it can be easily done. Bug me again if I don't say
|
||
anything about it in the next few days.
|
||
Bruce
|
||
|
||
|
||
-*-
|
||
|
||
30343 24-JUN 02:52 General Information
|
||
RE: Serial Mouse (Re: Msg 30286)
|
||
From: BRIANWHITE To: OS9UGVP
|
||
|
||
Bruce,
|
||
|
||
One more thing I discovered about the serial mouse. You may have already found
|
||
it, but I thought I'd mention it anyways. It seems that whenever you click on
|
||
the MV menu-bar twice in a row (within any amount of time), the computer hangs.
|
||
This happened the first time I did it. The second time it hung for a second and
|
||
|
||
then recovered. The mouse was then fine until I rebooted and then it hung
|
||
consistantly every time I clicked twice in a row on the menu bar. The only
|
||
program I tried this with was Bells & Whistles.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30439 29-JUN 23:42 General Information
|
||
RE: Serial Mouse (Re: Msg 30343)
|
||
From: OS9UGVP To: BRIANWHITE
|
||
|
||
Brian,
|
||
I haven't run into that problem (mouse hangups on double click) except with
|
||
programs that don't have a tight enough mouse-signal routine in them. II've got
|
||
much improved mouse drivers almost ready for uploading... all I need is some
|
||
time to do the doc changes (not much, I think) and stuff.
|
||
Bruce
|
||
|
||
|
||
-*-
|
||
|
||
30576 8-JUL 03:18 General Information
|
||
RE: Serial Mouse (Re: Msg 30439)
|
||
From: BRIANWHITE To: OS9UGVP (NR)
|
||
|
||
Bruce,
|
||
|
||
This hangup had nothing to do with mouse click code. I could click, move the
|
||
pointer around the screen for 10 seconds, and if the very next click was again
|
||
on the menu bar, the system would hang. Sorry I can't milk my system for more
|
||
information, but I
|
||
took the mouse back to work.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30288 22-JUN 00:22 Patches
|
||
OS9 LII and GFX2
|
||
From: GLENNTHIG To: DALEP
|
||
|
||
Dale,
|
||
I just received my July issue of the Rainbow. Glad to see you're back andthe
|
||
roilian life.
|
||
I have a couple of questions, as might a lot of other people about the Ipatch
|
||
|
||
file for the GFX2 module. I have not been able to find it. (Maybe I should ask
|
||
Kevin about that though.)
|
||
Also since Tandy is dropping The Coco, will there BE a new version of OS9
|
||
Level II?
|
||
Maybe these questions have allready been answered many times, I just have not
|
||
|
||
seen them. Any light you can shed on the situation will be appreciated. Thanks.
|
||
|
||
GThigpen
|
||
(GLENNTHIG)
|
||
|
||
-*-
|
||
|
||
30314 23-JUN 04:59 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30288)
|
||
From: OS9UGPRES To: GLENNTHIG
|
||
|
||
Glenn -
|
||
|
||
I finally found time (lately it seems like I've run out of process numbers ;-),
|
||
and created/posted a new gfx2 module to go along with Dale's column.
|
||
|
||
The interesting thing is, I'm surprised someone didn't just write one in
|
||
Basic09! <grin> From Dale's description it would've been pretty easy to do,
|
||
methinks?
|
||
|
||
There are a coupla volunteers taking over the upgrade documentation holdup... so
|
||
|
||
keep crossing them fingers. The 68K machines are the topmost priority right now,
|
||
|
||
tho. best - kev
|
||
|
||
-*-
|
||
|
||
30358 24-JUN 20:39 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30314)
|
||
From: GLENNTHIG To: OS9UGPRES
|
||
|
||
kEV, I appreciate the time you and others take to write programs/procedures and
|
||
the like for us non-progfgrammers(gripers). I am really looking forward to
|
||
seeing those new 68000 machines in action.
|
||
I write a little in Basic09, but right now just working and single-parenting
|
||
swwm to keep me occupied.
|
||
Thanks.
|
||
Glw
|
||
|
||
|
||
-*-
|
||
|
||
30364 25-JUN 01:19 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30288)
|
||
From: DALEP To: GLENNTHIG (NR)
|
||
|
||
Glenn
|
||
|
||
First, I noticed just this even that Kevin has uploaded the new GFX2 module to
|
||
compuserve. That means he most likely has posted it here also. But I just
|
||
checked in and went directly to the Forum. I have not looked in the Data
|
||
Libraries yet. I'll look soonest.
|
||
|
||
My bet on the upgrade ... is that there will be one. My second bet on the
|
||
subject is that it will most likely be from a third party. We'll all have to
|
||
stay tuned together.
|
||
|
||
Best Regards,
|
||
|
||
Dale
|
||
|
||
|
||
-*-
|
||
|
||
30393 26-JUN 00:40 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30364)
|
||
From: GREGL To: DALEP
|
||
|
||
Dale,
|
||
|
||
The new GFX2 module is safely tucked away in "New Uploads" in the databases
|
||
awaiting all those hungry downloaders. <grin> From the looks of it, I think it
|
||
was definitely worth the wait. Now on to OS-9 version 3. <grin>
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30435 29-JUN 02:29 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30393)
|
||
From: DALEP To: GREGL
|
||
|
||
Greg,
|
||
|
||
Yep, I think the people on the Forum are going to love GFX2. You might put a
|
||
bulletin on when they sign on to encourage them to download it. Definitely
|
||
worth the trouble.
|
||
|
||
They'll love "version 3" too! If, it ever sees the light of day.
|
||
|
||
Best Regards,
|
||
|
||
Dale
|
||
|
||
-*-
|
||
|
||
30441 30-JUN 00:04 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30435)
|
||
From: DWHILL To: DALEP
|
||
|
||
"If, it ever sees the light of day."
|
||
|
||
Eep. You mean the upgraded Level II might stay in limbo? More and more it
|
||
looks like I'll be forced to a MM1 or a TC9--which I can't afford. I'm still
|
||
trying get my money's worth out of my CoCo 3 (I bought a 2400 baud modem today).
|
||
|
||
Very glad to see you back in Rainbow, it's looking awfully thin these days.
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
30620 9-JUL 01:45 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30441)
|
||
From: DALEP To: DWHILL
|
||
|
||
Damon,
|
||
|
||
I certainly hope it sees the light of day ... I'm just impatient. There's a lot
|
||
|
||
of life left in these CoCo III's. And this new software will certainly make a
|
||
lot of people sit up and take notice! Because ... it will be a lot easier to
|
||
write nifty looking software in Basic09. And it will all look better and run
|
||
much faster. CUL. Dale
|
||
|
||
-*-
|
||
|
||
30672 12-JUL 20:43 Patches
|
||
RE: OS9 LII and GFX2 (Re: Msg 30620)
|
||
From: DWHILL To: DALEP (NR)
|
||
|
||
I'm hoping there's a lot of life left in MY coco, too. I'm trying to sell my
|
||
messydos machine for whatever I can get for it (Leading Edge Model M, an XT
|
||
clone) and just bought a 2400 baud external modem for the Coco.
|
||
|
||
I just did the IRQ diode hack and am now running Xcom9, which is notorious ojn
|
||
my system for locking up. For some reason, Osterm almost never does. At any
|
||
rate, I'm hoping it'll help prevent dropped characters as well, though I think
|
||
that really needs the ACIA hack.
|
||
|
||
Very curious about the new Coco4-type machines, you betcha I'll be at the
|
||
Cocofest here in the fall to look at 'em. Hope to see you here also. The
|
||
weather here in Atlanta in the fall is most pleasant. (That's a plug, ya'll.)
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30304 22-JUN 22:42 General Information
|
||
Coco Clipboard
|
||
From: RADICAL To: ALL
|
||
|
||
Anyone any idea as to the status of the Coco ClipBoard? TP1, can't be reached
|
||
in these waters. Does anyone have his GENIE address? I know he promised better
|
||
service, but I haven't seen a ClipBoard in quite a while. Len
|
||
|
||
|
||
-*-
|
||
|
||
30305 22-JUN 23:52 Programmers Den
|
||
RE: C question (Re: Msg 30101)
|
||
From: CHYDE To: ZACKSESSIONS
|
||
|
||
I am using it in several programs of my own. One of them is similar to the UNIX
|
||
|
||
cal utility. The garbage on the screen and stuff doesn't happen all the time
|
||
the program is called just once in a while.
|
||
|
||
function. It's with this one that the problem seems to be most common. I've
|
||
gotten around the problem by using the time() and localtime() functions from
|
||
Carl Keirder's C library. This uses more space but it seems to solve the
|
||
problem. I have some other people using the programs and am waiting for their
|
||
comments. I can send you some the source in E-Mail if you want. Personally I
|
||
think it's just me. My wife put a curse on my computer since I've been spending
|
||
|
||
so much time with it lately :-).
|
||
|
||
Chris
|
||
|
||
-*-
|
||
|
||
30309 23-JUN 01:31 Programmers Den
|
||
RE: C question (Re: Msg 30099)
|
||
From: TIMKOONCE To: CHYDE
|
||
|
||
Actually, that sounds like a stray pointer problem. Be double sure you're
|
||
passing it the right pointer. How are you declaring/allocating the buffer for
|
||
getime(), and how exactly are you calling it?
|
||
Since the "trash" block that OS9 uses to fill up a memory map is also
|
||
incidentally the first block allocated to video memory, stray pointers will
|
||
often write garbage to the first text screens allocated. Whenever you see
|
||
garbage like that, there's a good chance there's a stray pointer somewhere!
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30315 23-JUN 05:21 Programmers Den
|
||
RE: C question (Re: Msg 30309)
|
||
From: CHYDE To: TIMKOONCE
|
||
|
||
I'm declaring the buffer as described in the manual:
|
||
struct sgtbuf *buffer; I call it with:
|
||
getime(buffer);
|
||
|
||
I think that's right, but I'm still learing C so anything is posible. The book
|
||
I have on C doesn't say much about making System calls (It's geared mainly for
|
||
PC's anyway) and there isn't anything in the manual so it seems reasonable.
|
||
Chris
|
||
|
||
-*-
|
||
|
||
30325 23-JUN 15:42 Programmers Den
|
||
RE: C question (Re: Msg 30315)
|
||
From: ZACKSESSIONS To: CHYDE
|
||
|
||
Tim hit your problem right on the nose, a stray pointer problem, and don't feel
|
||
bad it is a common error of beginning/intermediate C programming.
|
||
|
||
You need to understand that the manual describes the function as
|
||
|
||
#include <time.h>
|
||
setime(buffer)
|
||
getime(buffer)
|
||
struct sgtbuf *buffer /* defined in time.h */
|
||
|
||
This means that the function getime() requires a single parameter, namely a
|
||
pointer to a struct of type sgtbuf. Now when you declare just a pointer to
|
||
struct, you don't actually allocate any space to hold the data defined by the
|
||
struct. All you declared is a pointer variable which can point to a struct of
|
||
type sgtbuf. Try it this way:
|
||
|
||
#include <stdio.h>
|
||
#include <time.h>
|
||
|
||
main()
|
||
{
|
||
struct sgtbuf tim;
|
||
|
||
getime(&tim);
|
||
printf("Current time is %02d:%02d\n",tim.t_hour,tim.t_minute);
|
||
}
|
||
|
||
Another way to do it is to do it this way:
|
||
|
||
#include <time.h>
|
||
#include <stdio.h>
|
||
|
||
struct sgtbuf *tptr;
|
||
|
||
main()
|
||
{
|
||
struct sgtbuf tim;
|
||
|
||
tptr = &tim;
|
||
getime(tptr);
|
||
|
||
printf("Current time is %02d:%02d\n",tptr->t_hour,tptr->y_minute);
|
||
|
||
}
|
||
|
||
Does this make any sense?
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30327 23-JUN 17:42 Programmers Den
|
||
RE: C question (Re: Msg 30325)
|
||
From: DODGECOLT To: CHYDE
|
||
|
||
Another thing to remember is that the Microware C compiler usually 'forgets' to
|
||
pass the pointer to a structure. What I mean is that you have to tell it to send
|
||
|
||
a pointer (with the & operator.) Otherwise it will send the whole structure,
|
||
which will surely cause you problems!
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30329 23-JUN 18:59 Programmers Den
|
||
RE: C question (Re: Msg 30315)
|
||
From: GREGL To: CHYDE
|
||
|
||
Chris,
|
||
|
||
You declared the pointer to the structure (struct sgtbuf *buffer) but not
|
||
the storage area for the buffer itself. Look at it this way: Declaring a pointer
|
||
|
||
sets up a 2 byte storage area in memory that contains the address of the object.
|
||
|
||
When the pointer is declared, the address stored there is undefined - garbage.
|
||
Therefore, when you call getime(buffer); you are passing a garbage address and
|
||
the getime() function is storing the date and time at whatever address that
|
||
happens to be. To use the same declarations you need to allocate a section of
|
||
memory for the structure, which would cause your code to rewritten as:
|
||
|
||
struct sgtbuf *buffer;
|
||
|
||
buffer = malloc(sizeof(struct sgtbuf));
|
||
getime(buffer);
|
||
|
||
Here we tell malloc() that we want to allocate a section of memory with the same
|
||
|
||
size as the sgtbuf structure (6 bytes I believe) and to assign the address to
|
||
buffer. You can also write the code as follows:
|
||
|
||
struct sgtbuf buffer;
|
||
|
||
getime(&buffer);
|
||
|
||
This declares buffer as an sgtbuf structure. Note that this allocates enough
|
||
memory to store the entire structure instead of a pointer. Next we use the
|
||
"address of" (&) function to pass the address of the structure to the getime()
|
||
function. Both of these have the same results. The difference is the method you
|
||
use to access the variables. In the first method using pointers you would use:
|
||
|
||
year = buffer->t_year;
|
||
month = buffer->t_month;
|
||
day = buffer->t_day;
|
||
|
||
In the latter method without using pointers you would use:
|
||
|
||
year = buffer.t_year;
|
||
month = buffer.t_month;
|
||
day = buffer.t_day;
|
||
|
||
If you have any more questions, feel free to ask.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30456 1-JUL 00:58 Programmers Den
|
||
RE: C question (Re: Msg 30327)
|
||
From: CHYDE To: DODGECOLT
|
||
|
||
Thanks, I was begining to wonder. It seems other programs of mine have the same
|
||
|
||
problem. Well back to the drawing board. And just when my wife thought I was
|
||
going to spend some time with her.
|
||
Chris
|
||
|
||
-*-
|
||
|
||
30457 1-JUL 01:03 Programmers Den
|
||
RE: C question (Re: Msg 30329)
|
||
From: CHYDE To: GREGL
|
||
|
||
After Zack mentioned the dangling pointer and alocation I thought it might be
|
||
that or something else equally sneaky :-). Anyway thanks.
|
||
|
||
And the professors in the C.S. department don't think it's ness sasary to have a
|
||
|
||
class in C.
|
||
|
||
Chris
|
||
|
||
-*-
|
||
|
||
30458 1-JUL 01:09 Programmers Den
|
||
RE: C question (Re: Msg 30325)
|
||
From: CHYDE To: ZACKSESSIONS
|
||
|
||
I will endevor to try what you suggested when I get a chance. I had thought
|
||
about that being a problem, but at first the programs worked fine (good luck, I
|
||
guess).
|
||
|
||
I guess it's back to the old editor and compiler to rewrite some code. And just
|
||
|
||
when my list of projects was getting down to managable size.
|
||
|
||
Thanks for your help,
|
||
Chris
|
||
|
||
-*-
|
||
|
||
30549 7-JUL 18:43 Programmers Den
|
||
RE: C question (Re: Msg 30457)
|
||
From: TOMBRETON To: CHYDE
|
||
|
||
Well, C++ people think it's neccessary to have a class in C....<groan> <duck and
|
||
|
||
run>
|
||
|
||
Tom
|
||
|
||
-*-
|
||
|
||
30551 7-JUL 20:56 Programmers Den
|
||
RE: C question (Re: Msg 30549)
|
||
From: TOMBRETON To: ALL
|
||
|
||
But more seriously, I'm trying to learn C++. Does anyone know good 'n cheap
|
||
compilers, books, and references? I've got them all for C. How much more do I
|
||
need to program C++ decently?
|
||
|
||
Tom
|
||
|
||
-*-
|
||
|
||
30558 7-JUL 23:21 Programmers Den
|
||
RE: C question (Re: Msg 30551)
|
||
From: XLIONX To: TOMBRETON
|
||
|
||
Howdy Tom,
|
||
|
||
Hate to say this but, you have to almost start over. There are alot of good
|
||
"crossover" books that will no doubt make a mess of your life (for awhile ];->).
|
||
|
||
The second edition of "The C Language" by K&R includes an introduction to OOP
|
||
(++) and books on the subject range from $19.95 to $80.00 (American). The best
|
||
you can do is to write to the manufacturers " on their products as far as
|
||
tutorials and online help goes. Zortech, Microsoft, Borland, Abraxas and the
|
||
list goes on.
|
||
|
||
I don't know what kind of machine you are going to use, so I can only guess IBM
|
||
(clone). If you want to go C++...DON'T SETTLE for a compiler that claims "with
|
||
C++ extensions" unless it covers ALL C++ functions.
|
||
|
||
You can write code in any C compiler that could be considered OOP in design, and
|
||
|
||
the concept behind OOP (C++) is not too hard to deal with.
|
||
|
||
Good luck, and let me know what you decide to do (Professional Curiosity).
|
||
|
||
-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS v2.0) -XLIONX
|
||
(DELPHI) -mwf@SANDV
|
||
|
||
-*-
|
||
|
||
30591 8-JUL 14:30 Programmers Den
|
||
RE: C question (Re: Msg 30558)
|
||
From: TOMBRETON To: XLIONX
|
||
|
||
Thanks for the help, Mark. I'll let you know how it goes.
|
||
|
||
Tom
|
||
|
||
-*-
|
||
|
||
30691 13-JUL 21:02 Programmers Den
|
||
RE: C question (Re: Msg 30549)
|
||
From: CHYDE To: TOMBRETON (NR)
|
||
|
||
Yeah so do most of the C.S. students at the Univeristy of Idaho. We're working
|
||
on it. Maybe for the spring '91 semester.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30307 23-JUN 00:37 Patches
|
||
hires
|
||
From: BANCROFT To: ALL
|
||
|
||
I do not yet have cocomax 3, but plan to get it in the future. I am building a
|
||
switch to switch hires on/off. I also want to put in the modified switch. The
|
||
problem is, all dos on the switch, are schematics in cocomax 3 double height
|
||
format. the best I can do, is convert them to vef, and view the top half only,
|
||
but this does me no good. Is there any way I can get these schematics?
|
||
|
||
|
||
-*-
|
||
|
||
30310 23-JUN 01:32 Graphics & Music
|
||
RE: hires (Re: Msg 30307)
|
||
From: TIMKOONCE To: BANCROFT
|
||
|
||
My VIEW program will display both halves of a CoCoMax 3 picture. Try it, you
|
||
might like it.
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30316 23-JUN 06:02 Programmers Den
|
||
RE: Multi-Vue programming (Re: Msg 30102)
|
||
From: OS9UGPRES To: ALPHASOFT
|
||
|
||
Keith -
|
||
|
||
I've been off for quite a while... didja figure something out?
|
||
|
||
About the only way I can figure for two programs to use the same menu bar is to
|
||
share a data module with the menu info changed inside.
|
||
|
||
Actually, that won't work either. Hmmm. Windint is a smart cookie and checks
|
||
process id's and something else (I forget what) to make sure this isn't just old
|
||
|
||
menu info hanging around. Perhaps if the child process signaled the parent to do
|
||
|
||
a SS.UMBar, again using the data module??
|
||
|
||
Kev
|
||
|
||
-*-
|
||
|
||
30404 26-JUN 21:05 Programmers Den
|
||
RE: Multi-Vue programming (Re: Msg 30316)
|
||
From: ALPHASOFT To: OS9UGPRES
|
||
|
||
I don't know if that would work either, cause the new process still couldn't
|
||
pull up the menu.
|
||
|
||
I can share the menu data, but I need a way to tell OS9 that the menu belongs to
|
||
|
||
me (and has X data). I can do an _ss_wset, but it clears the screen.
|
||
|
||
If I could somehow accomplish an _ss_wset without clearing the screen???
|
||
|
||
Let me know.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30317 23-JUN 06:02 68K-OS9
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30117)
|
||
From: OS9UGPRES To: THEREB
|
||
|
||
Matt-
|
||
|
||
You would think that fragmentation would be a bother under OS9/68K, but I've not
|
||
|
||
seen it yet on my ST or MM/1. It's a little different from coco L-I, because
|
||
programs can have up to 31 (?) sections of memory allocated.
|
||
|
||
Let me see. Like right now I have 1852K free, with the largest section being
|
||
1843K long. I'm not worried about frag yet <grin>. On the other machine, I have
|
||
935K free, with 934K being the largest section. So it's not a bother.
|
||
|
||
Right, second and fourth Wednesdays of every month at 7:30pm. Go up 401 to the
|
||
Raleigh Beltline and head for US 1 North (northeast). Get off on the US 1
|
||
(Henderson) exit, and travel north on 1 for about say, 4-5 miles. Just after
|
||
1/401 split again, you'll go past a large shopping center (Mini City) on the
|
||
right. Look for the main stoplight intersection of Millbrook Road. Continue
|
||
north to the next light, which is Spring Forest Road. Take a left. Go about 2
|
||
miles until you come to Millbrook Senior High School on your right. The _last_
|
||
parking lot (black asphalt/trailers/gravel) at the far end of the school is the
|
||
spot. Go into the end of the school, and stick your head into various rooms
|
||
until you spot a small group of insane looking people. That's us <grin>. Call me
|
||
|
||
at 919-872-7986 that afternoon if you're coming up.
|
||
|
||
PS: we read many forums and nets... but are usually too swamped to answer much
|
||
;-).
|
||
|
||
-*-
|
||
|
||
30333 24-JUN 00:12 General Information
|
||
User Group Meetings (Re: Msg 30317)
|
||
From: THEREB To: OS9UGPRES
|
||
|
||
Thanks a lot. I'll TRY to make it to one of your meetings - I may not be able
|
||
to anytime soon, I'll be in Minnesota for three weeks starting July 19th - but
|
||
MAYBE I'll be able to make one before then. Have you been bringing the MM/1 to
|
||
the meetings? =) And thanks for the directions, too; I'm not REALLY familiar
|
||
with the Raleigh area, and they'll help if I am able to make it.
|
||
|
||
|
||
Matt.
|
||
|
||
|
||
-*-
|
||
|
||
30335 24-JUN 01:26 General Information
|
||
Raleigh Club (Re: Msg 30333)
|
||
From: OS9UGPRES To: THEf I have something new worth showing off <grin>.
|
||
|
||
-*-
|
||
|
||
30377 25-JUN 20:58 General Information
|
||
RE: OSK Mem Management, Raleigh Club.eM 3) r:TEB oO9PE
|
||
s isIuttet ahe toci wie rgamio Ii oilyucl n nt? )Iwl O oe h
|
||
tn! a'OEom aoso nigoce for. Actually, I'll
|
||
bring an 8cm515 if you need me to. I don't know if I'll make it this week or
|
||
not, but if I can't, I'll try to make it to the first meeting in July.
|
||
|
||
|
||
Again, thanks for the directions & help.
|
||
|
||
|
||
Matt. THEREB (919) 484-1230 voice or call the Norca BBSs!
|
||
|
||
(919) 868-8431
|
||
867-7152
|
||
424-2895
|
||
497-8806
|
||
|
||
|
||
-*-
|
||
|
||
30384 25-JUN 23:35 General Information
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30377)
|
||
From: NES To: THEREB
|
||
|
||
Matt, You can send the disk in os9 or rsdos or MSdos format, I run the BBS
|
||
under os9 but have the CC3disk patch so I can read rsdos disk and MSdos disk.
|
||
hope you got all the info you needed in my letter. I just order MV canvase will
|
||
let you know how it looks also the program called Planet Engine by Gravity
|
||
Studio is a must for those who love to look at theh stars, it cost only $24
|
||
dollars but beats out programs that I have payed twice that, I comes with a
|
||
sharp looking Manual and run's under(or without) MV, but I think the MV version
|
||
looks the best. I was impressed by the program when I ran it, and seen what the
|
||
moon's phase was, and then that night I whent out and the program was correct in
|
||
|
||
the moons phase and star positions,.... Well chat at you latter.. Eric
|
||
|
||
-*-
|
||
|
||
30402 26-JUN 20:54 General Information
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30384)
|
||
From: ZACKSESSIONS To: NES
|
||
|
||
When you say that Planet Engine runs with or without MV, does that mean there
|
||
are two binaries, one which works with GrfInt and one that works with WindInt?
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30409 26-JUN 22:40 68K-OS9
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30402)
|
||
From: NES To: ZACKSESSIONS
|
||
|
||
Zack, Yea, but only the MV version has pull down menu's and also has more
|
||
options.... eric
|
||
|
||
-*-
|
||
|
||
30466 1-JUL 22:34 General Information
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30384)
|
||
From: THEREB To: NES
|
||
|
||
Hmmm. . . I just got Multi-Vue myself, I'm starting to get the hang of it.
|
||
. . but do you have any suggestions?
|
||
|
||
Matt / TheReb
|
||
|
||
|
||
-*-
|
||
|
||
30485 3-JUL 00:00 General Information
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30466)
|
||
From: NES To: THEREB
|
||
|
||
Matt, Help in what area of MV? If you get a program that you cant get to run, I
|
||
|
||
my could help you, always check your ATTR of file all icon must have pe e pw pr
|
||
r w set, also make shure things are in the right directorys. I have mine setup
|
||
like this:
|
||
dd/MV/CMDS
|
||
dd/MV/CMDS/ICONS
|
||
dd/APP (application directory with the AIF files) Let me know if you have
|
||
anytrouble. Eric
|
||
|
||
-*-
|
||
|
||
30517 5-JUL 21:34 General Information
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30485)
|
||
From: THEREB To: NES
|
||
|
||
Well, I'm beginning to get the hang up Multi-Vue. BEGINNING to. I have
|
||
virtually NO MV applications (two icon editors and the included graphics demos -
|
||
|
||
that's all), but I like finally having a WIMP interface available. Problem is,
|
||
I'm now running out of RAM space on my 512k system =) !
|
||
|
||
Matt
|
||
|
||
|
||
-*-
|
||
|
||
30520 5-JUL 23:54 General Information
|
||
RE: OSK Mem Management, Raleigh Club. (Re: Msg 30517)
|
||
From: NES To: THEREB (NR)
|
||
|
||
Hay, You should download "MAX9" a nice graphics editor that will run under MV,
|
||
Its on my board or you can get it here, BTW MVCanvas is a nice graphics editor
|
||
pakage, a must for OS9 users who love drawing. also there's Zack's Banner maker
|
||
|
||
progam, Solitare, Luner Lander, View looks good under MV, with view under MV all
|
||
|
||
the graphics files have there name under there icons, ie GIF files will have the
|
||
|
||
GIF icon. realy nice. That's all I have at the monment. yea, I run out of memory
|
||
|
||
all the time with the board up and MV and all the other windows I have open.
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30318 23-JUN 06:03 68K-OS9
|
||
RE: Unlink (Re: Msg 30123)
|
||
From: OS9UGPRES To: EDDIEKUNS
|
||
|
||
Eddie - yah, just unlink one more time (past 0) and a sticky module goes away.
|
||
|
||
-*-
|
||
|
||
30319 23-JUN 06:03 Programmers Den
|
||
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 30134)
|
||
From: OS9UGPRES To: KNOT1
|
||
|
||
Jamie - nice testing! That takes us a lot closer to figuring out the reasons for
|
||
|
||
the strange ability to unlock what shouldn't be unlockable (altho I'm usually
|
||
glad it is! ;-). thx! - kev
|
||
|
||
-*-
|
||
|
||
30320 23-JUN 06:03 Graphics & Music
|
||
RE: MVCanvas 2.0 (Re: Msg 30142)
|
||
From: OS9UGPRES To: RAGTIMER
|
||
|
||
Mike - I bought extra ink paks way back when I first got the printer, so no
|
||
problem there. It just turned out that dis-use causes some of the ink to dry up
|
||
inside several of the tubes, and they clog up.
|
||
|
||
I know it happens to others at times, and also knew that some people used some
|
||
liquid to clean the tubes out.... I was hoping you knew what. thx!
|
||
|
||
-*-
|
||
|
||
30362 24-JUN 23:46 Graphics & Music
|
||
RE: MVCanvas 2.0 (Re: Msg 30320)
|
||
From: RAGTIMER To: OS9UGPRES
|
||
|
||
Sortry I don't. If you find out how people clean out their printer ink tubes,
|
||
please post it up here, Kev. Thanks, mike k (PS: Mine are working fine at the
|
||
moment).
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30321 23-JUN 06:03 68K-OS9
|
||
RE: GEN (Re: Msg 30143)
|
||
From: OS9UGPRES To: KTT (NR)
|
||
|
||
Hi! Sorry I took so long to get back to answer you.
|
||
|
||
Your best bet is to call Microware themselves for more OS-9000 info and
|
||
pricing... 515-224-1929. Ask them for info on OS-9000, and also the OS-9
|
||
Catalog, which is filled with a terrific description of OS9.
|
||
|
||
Yell if need more help. best - kev
|
||
|
||
-*-
|
||
|
||
30326 23-JUN 17:34 Patches
|
||
Disto RTC mods
|
||
From: OS9UGVP To: ALL
|
||
|
||
A while ago someone with a Disto RTC was having problems with the ACIAPAK
|
||
driver from my "ELIMSW.AR" package. I received some mail from them, but I have
|
||
misplaced the message and I can't recall who it was. I have some more
|
||
information that might be helpful, if I can just figure out who I was talking
|
||
to. So if you're out there, let me know who you are!
|
||
Bruce
|
||
|
||
|
||
-*-
|
||
|
||
30328 23-JUN 17:55 Patches
|
||
RE: Disto RTC mods (Re: Msg 30326)
|
||
From: DODGECOLT To: OS9UGVP
|
||
|
||
Yea, I think that was me. I take it you have found something from the code I
|
||
sent you?
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30438 29-JUN 23:38 Patches
|
||
RE: Disto RTC mods (Re: Msg 30328)
|
||
From: OS9UGVP To: DODGECOLT
|
||
|
||
Mike,
|
||
Now that I see your "handle" again, I'm sure it was you. I've got an ARchive
|
||
with a slightly modified source file waiting for you... I'll EMAIL it right
|
||
away. Let me know if it helps (or not!).
|
||
Bruce
|
||
|
||
PS: This is an ARchived file... I trust you're familiar with the "EXTRACT
|
||
/NOHEADER" and then DL from your workspace thats required?
|
||
|
||
|
||
-*-
|
||
|
||
30449 30-JUN 15:44 Patches
|
||
RE: Disto RTC mods (Re: Msg 30438)
|
||
From: DODGECOLT To: OS9UGVP
|
||
|
||
Yep, got it. I'll check it out once I get it dloaded. Thanks!
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30330 23-JUN 19:45 General Information
|
||
Horn toots
|
||
From: PAULIGHT To: ALL
|
||
|
||
I'm very curious about what I can say on DELPHI in regard to commercial
|
||
programs that I write and wish to promote... Is there any guidelines or
|
||
restrictions to what (and how much) one can say. I would like to keep persons
|
||
informed and announce program s without abusing or glutting the forum. Is there
|
||
|
||
any good message I should read.
|
||
Signed Paul H. Light (Mr. Good Citizen)
|
||
|
||
-*-
|
||
|
||
30336 24-JUN 02:16 General Information
|
||
RE: Horn toots (Re: Msg 30330)
|
||
From: TIMKOONCE To: PAULIGHT
|
||
|
||
Paul,
|
||
Don't take this as "official", (hopefully Greg or Jim Reed will jump in and
|
||
|
||
get this right), but I think that the general policy is that product
|
||
announcements are gladly accepted in the database (upload it to the General
|
||
Database, methinks), and that you're free to answer questions in forum, as long
|
||
as you keep it tasteful. Basically, try to keep it non-obtrusive, and noone
|
||
really seems to care. Thanks for asking!
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
30355 24-JUN 18:56 General Information
|
||
RE: Horn toots (Re: Msg 30330)
|
||
From: GREGL To: PAULIGHT
|
||
|
||
Paul,
|
||
|
||
There are no hard and fast rules, per se. Feel free to post any product
|
||
announcements in the databases. You are also absolutely free to answer any
|
||
questions that are thrown your way in regards to your products. Basically all we
|
||
|
||
ask is that you give only the facts, no hype please. You shouldn't have any
|
||
problems following those "guidelines." If we think you've "overstepped your
|
||
bounds" we'll explain why - but it's rare that anyone does.
|
||
Of course the users have a "need to know" about any new and upcoming
|
||
software so they can make purchasing decisions. Basically, product announcements
|
||
|
||
and answering questions are perfectly acceptible, but no advertisements. If you
|
||
have any specific questions, feel free to ask.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30331 23-JUN 20:37 Utilities
|
||
ARC
|
||
From: SEBJMB To: ALL
|
||
|
||
Hi, all.
|
||
|
||
I'm confused. I have seen a couple of references in recent uploads to an
|
||
archiveing method called "ARC" and the dearchive program called "DEARC". There
|
||
has been at least one upload submitted in the "arc" format. However, I have
|
||
been unable to find the DEARC program in any of the databases.
|
||
|
||
Am I missing something?
|
||
|
||
eff
|
||
|
||
(Puzzled)
|
||
|
||
|
||
-*-
|
||
|
||
30337 24-JUN 02:26 Utilities
|
||
RE: ARC (Re: Msg 30331)
|
||
From: TIMKOONCE To: SEBJMB
|
||
|
||
You're quite right, DEARC is _not_ in the database here. It seems that there is
|
||
|
||
some confusion over whether the person who uploaded it to us had permission from
|
||
|
||
the author to upload it here. Without that permission, we can't accept such an
|
||
upload. If someone can contact the author to get permission, that would
|
||
obviously help a lot.
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
30346 24-JUN 03:20 General Information
|
||
RE: ARC (Re: Msg 30331)
|
||
From: TIMKOONCE To: SEBJMB
|
||
|
||
"ARC" is an archive method very popular in the IBM PC world. OS9ARC and DEARC
|
||
are utilities to create and read that archive format.
|
||
I've downloaded the one upload I've seen in ARC format and converted it into
|
||
OS9-standard AR format. Thanks for bring that up!
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30351 24-JUN 10:54 General Information
|
||
RE: ARC (Re: Msg 30337)
|
||
From: ZACKSESSIONS To: TIMKOONCE
|
||
|
||
Actually, Tim, dearc IS in the library! It is a member of the group "3D GRAPHICS
|
||
|
||
PLOTTER" in the Programmer's Den. Only C source is there. I have successfully
|
||
compiled it, and have been semi-successful in using it. Only problem was, I had
|
||
to filter all extracted files replacing the 0x0A with 0x0D (archive came from a
|
||
VAX.)
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30382 25-JUN 23:19 General Information
|
||
RE: ARC (Re: Msg 30351)
|
||
From: NES To: ZACKSESSIONS
|
||
|
||
Zack, If you get the 3D plotter working upload it here or to me, I havent got it
|
||
|
||
to compile yet... Eric
|
||
|
||
|
||
-*-
|
||
|
||
30401 26-JUN 20:51 General Information
|
||
RE: ARC (Re: Msg 30382)
|
||
From: ZACKSESSIONS To: NES
|
||
|
||
Heh, heh, I didn't even LOOK at the 3D plotter, I just wanted the dearc program!
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30408 26-JUN 22:39 General Information
|
||
RE: ARC (Re: Msg 30401)
|
||
From: NES To: ZACKSESSIONS
|
||
|
||
Zack, oh well, I had know problems with the dearc program... eric
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30338 24-JUN 02:50 Programmers Den
|
||
Window Help
|
||
From: BRIANWHITE To: OS9UGPRES
|
||
|
||
More system problems...
|
||
|
||
I have a program that has the option of using its own font, the default system
|
||
font, or the StdFonts file. The program checks for an available font in that
|
||
order and then loads the font to the system ($1B2B ...) if that is not where it
|
||
was found. The p roblem is that when the window is opened after a font is
|
||
loaded from a file, the menu bar contains only the close box. However, if run
|
||
again and allowed to find the font in memory, everything works fine. I've tried
|
||
|
||
closing the path I wrote the font loa d command out to, but that didn't help
|
||
either. I've tried opening the window with the menu bar both before and after
|
||
the font load command is issued. Nothing seems to make a difference. The
|
||
symptoms are always the same. Any ideas about this?
|
||
|
||
Also, after opening a window to "/w" if I send the codes:
|
||
|
||
fcb 27,32,6,0,0,40,24,3,0,3 - Set window type
|
||
fcb $1b,$25,0,1,40,23,12 - Clear screen
|
||
fcb $1b,$3a,$c8,$01 - Select font
|
||
fcb 5,32 - Turn off cursor
|
||
fcb $1b,$35,0 - Scale switch off
|
||
|
||
to that window, occasionally the system will return with error #189 (Illegal
|
||
Coordinates). Running my program a second time again always works. As far as I
|
||
|
||
can tell, the problem steps from doing the "set window type" and "CWArea/Clear
|
||
screen" in the sa me I$Write to the new window. I've tried changing the order
|
||
of the above (always keepin the set codes at the top, of course), but no change.
|
||
|
||
I guess my next course of action is to try two different I$Write's. Anyway,
|
||
this prob has me kinda stumped, to o. Any help would be greatly appreciated.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30354 24-JUN 16:13 General Information
|
||
RE: Window Help (Re: Msg 30338)
|
||
From: OS9UGPRES To: BRIANWHITE
|
||
|
||
Brian,
|
||
|
||
I may bumble this a little, but here's some info which might help:
|
||
|
||
Each window has data stored about its size, colors, etc. One of the things
|
||
which is stored away is the block number/offset of the font. NOT the group and
|
||
buffer number. Thus if you remerge fonts using the same numbers, you can mess
|
||
everyone up... since the true block/offset could change from under them.
|
||
|
||
Think of this like a CHX/CHD, where os9 stores just the sector number, not the
|
||
actual filename. Similar. So by refinding a font by group/number, the new block
|
||
number and offset in memory is reset, and all is well.
|
||
|
||
Note that the menubar always stores away the block/offset of the font being used
|
||
|
||
at the moment of SS.WnSet (if I recall correctly).
|
||
|
||
The error 189 thing is different. It most often comes from a window entry still
|
||
having a leftover type number in it (they forgot to clear that when a
|
||
window/overlay closes). For example, pulldown a menu and that window entry (the
|
||
pulldown overlay) is set to a shadowed box type, with default CWArea inside.
|
||
Later, a new window gets that entry, and a cwarea fails because of the leftover
|
||
shadowed-type confusing poor Windint. Programs could always SS.WnSet to some
|
||
type (00 is good) first to avoid this cwarea glitch.
|
||
|
||
-*-
|
||
|
||
30574 8-JUL 03:17 General Information
|
||
RE: Window Help (Re: Msg 30354)
|
||
From: BRIANWHITE To: OS9UGPRES
|
||
|
||
Kev,
|
||
|
||
Okay, all that makes sense. I'll try doing a WnSet to zero and then a WnSet to
|
||
whatever type I am using. Would that work, or would I need to close the window
|
||
path, between the two "set" commands?
|
||
|
||
As for the font error, I tried writing the GPLoad and Font select commands out
|
||
to a path to "/w", closing the path, and then opening a new one to "/w" all
|
||
before doing a WnSet to the new window and the font still isn't there. However,
|
||
|
||
if I do run the pr ogram a second time (this time it detects that the needed
|
||
font has been loaded and thus doesn't try to load it again), everything works
|
||
just fine. Ideas?
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30339 24-JUN 02:51 Graphics & Music
|
||
RE: Get/Put Buffers (Re: Msg 30200)
|
||
From: BRIANWHITE To: TIMKOONCE
|
||
|
||
Tim,
|
||
|
||
Thanx for the info agout Get/Put. I was afraid it would be something like that.
|
||
|
||
I hate the idea of having to unmap a buffer before I can map in the next (a real
|
||
|
||
time waster), but you have to do what you have to do...
|
||
|
||
Congrats on your upcoming wedding! Does this mean that you'll be slowing down
|
||
on View and give people like me a chance to catch up? <grin> Actually, I
|
||
conceed with that battle! Of course, there are still a few things I prefer in
|
||
Show over View, but n ot very many. You did an excellent job on that project
|
||
and I hope you write a similar one for OS-k!
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30345 24-JUN 03:18 Graphics & Music
|
||
RE: Get/Put Buffers (Re: Msg 30339)
|
||
From: TIMKOONCE To: BRIANWHITE
|
||
|
||
Actually, Brian, I'm eager to see what you finally managed to do with Show.
|
||
Sounded like you had some interesting ideas, maybe I can steal some of them!
|
||
<grin>
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30573 8-JUL 03:17 Graphics & Music
|
||
RE: Get/Put Buffers (Re: Msg 30345)
|
||
From: BRIANWHITE To: TIMKOONCE
|
||
|
||
Tim,
|
||
|
||
Ohhh... It's been a while since the editor has load the Show source. I don't
|
||
remeber what I improved on it. I know I fixed a couple of bugs and added some
|
||
more music formats, including screen flipping for IMG. Lets see... I added a
|
||
variable sleep ti me, allowed options to be grouped instead of separating each
|
||
with a "-". I was going to try and allow flipping during loading. I, of
|
||
course, was cheating like a madman to get these things done. I did directCcce..: t+$.,.Y+R-QI
|
||
AQzUQ=%9J*T2=I21%AA%99JiXM5Rtverdoing it. So... It's been put on the far back burner while the music
|
||
editor gets going. I'm probably going to stop that pretty soon and start from
|
||
scratch an MM/1 version. That's the big problem with assembly. Abso lutely no
|
||
portability. Just as well, I've got new and better ideas, now! I think "Show"
|
||
is stable if you want me to mail you it in it's current state. Let me know. If
|
||
|
||
you like any of the ideas, you don't need to steal them, they're yours. I'd be
|
||
a f ool to hinder any development of that program of yours. Of course, I am an
|
||
engineer, and you are a mathie, so maybe I should anyways <sit back in chair,
|
||
rub palms>.
|
||
|
||
Brian ;-)
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30340 24-JUN 02:51 Programmers Den
|
||
SCF Editing and History (Re: Msg 30201)
|
||
From: BRIANWHITE To: EDDIEKUNS
|
||
|
||
Eddie,
|
||
|
||
Yea, you can do single char reads and make your own editor, but that shouldn't
|
||
be necessary. Besides, it redu,X` the flexibility of OS-9. After all, that is
|
||
what all those wonderful flags in the path descriptor are for. There must be an
|
||
|
||
easier way.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30365 25-JUN 01:55 General Information
|
||
RE: Alias (Re: Msg 30340)
|
||
From: EDDIEKUNS To: BRIANWHITE
|
||
|
||
I disagree. I don't mind SCF doing its own editing, but I think the shell's
|
||
history should be completely separate from the history of SCF. For example, I
|
||
run an editor. later I quit the editor and want to run the editor again with
|
||
slightly different options and a different filename. When I press the up-arrow,
|
||
|
||
I want to see the line I typed to enter the editor, not anything I typed during
|
||
the editing session.
|
||
|
||
NOW -- If SCF can be coerced by a flag or something to keep a separate history
|
||
list for each path, THEN I'll admit that it's OK to keep the editing in SCF.
|
||
<Grin>
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30390 26-JUN 00:19 General Information
|
||
RE: Alias (Re: Msg 30365)
|
||
From: RAGTIMER To: EDDIEKUNS
|
||
|
||
I agree with Eddie -- years of that phone-company OS, ya know. Tho I'd also like
|
||
|
||
a reapet-line that would work on paths, or whatever.
|
||
|
||
Right now, in OSTERM, I can't repeat a line by typing CTRL-A. Not clear why not
|
||
-- maybe OSTERM uses an I$Read for every character?
|
||
|
||
-*-
|
||
|
||
30575 8-JUL 03:18 General Information
|
||
RE: Alias (Re: Msg 30365)
|
||
From: BRIANWHITE To: EDDIEKUNS (NR)
|
||
|
||
Eddie,
|
||
|
||
Actually, what is needed here is a way to see what the next keypress in the
|
||
buffer is without actually reading it. That way, the shell could wait for a
|
||
keypress, and then check the key to see if it is one of the arrows. If not, do
|
||
an I$ReadLn. If it i s, go through its history. Of course, this does still not
|
||
|
||
allow SCF editing on those history lines. Drat. Seemed like such a good
|
||
solution, too. Still a system call like the one I described could come in very
|
||
useful. Maybe we need a SetStt to load t he SCF last-line buffer with whatever
|
||
WE want? That could be EXTREMELY USEFUL!!!
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30344 24-JUN 02:52 General Information
|
||
File Attributes
|
||
From: BRIANWHITE To: GREGL
|
||
|
||
Greg,
|
||
|
||
While on the subject of expanded attribute bits, how about another 24! 3 bits
|
||
by 8 categories. The three bits are Read, Write, and Execute. This would be
|
||
the same as having 8 different groups plus user and public. Of course all user
|
||
numbers would als o have to have a similar 24 bits of permission associated with
|
||
|
||
them.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30357 24-JUN 19:13 General Information
|
||
RE: File Attributes (Re: Msg 30344)
|
||
From: GREGL To: BRIANWHITE
|
||
|
||
Brian,
|
||
|
||
Out of curiosity, what would you do with eight Read/Write/Execute
|
||
categories? I don't see the need for it, to be honest. As a matter of fact,
|
||
|
||
I think it would be more trouble than it is worth.
|
||
One idea that I've been toying with is assigning default attributes to the
|
||
user via the password file. These attributes would override those stored in the
|
||
file descriptor - downward only. That is, if the user has default attributes of
|
||
group read and group write, he can't write to any file he doesn't own even if
|
||
the file descriptor has group write permission. That could be very useful for
|
||
putting "ropes" around certain users.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30388 26-JUN 00:13 General Information
|
||
RE: File Attributes (Re: Msg 30357)
|
||
From: RAGTIMER To: GREGL
|
||
|
||
Good idea for BBS operators. And I thought you should know that after all these
|
||
|
||
years, only a few sites have ever got the group attributes in UN*X to do
|
||
anything worthwhile. A great concept that nobody can make work. Microware seems
|
||
|
||
to either make something work or leave it out -- not a bad philosophy.
|
||
|
||
-*-
|
||
|
||
30578 8-JUL 03:19 General Information
|
||
RE: File Attributes (Re: Msg 30357)
|
||
From: BRIANWHITE To: GREGL
|
||
|
||
Greg,
|
||
|
||
I've heard two different things about those group attributes. First was
|
||
something from Frank Hogg mentioning that OSk uses the same file system as OS-9,
|
||
|
||
thus a hard disk would port over directly. That was when he was advartising the
|
||
|
||
QT-CoCo as a tempor ary hard disk with 68000 expandability. However, just the
|
||
other day, I'm sure Kev mentioned something about group attributes under OSk.
|
||
I'm not sure where in the forum that is, but I don't think I misunderstood it.
|
||
|
||
Even if OSk does have the same file system as OS9, then there is still no place
|
||
for any of the attributes like "deletable" that you mentioned. I was just
|
||
mentioning what I though would be really useful attributes. I know they would
|
||
solve a lot of my mu lti-user headaches. If you get any ideas on how to make it
|
||
|
||
work, let me know...
|
||
|
||
I came up with the number 8 because that added 3 bytes to the current 1 to get a
|
||
|
||
full longword of attributes. It would be nice to have separate groups for, say
|
||
"temporary user", "common user", "privaledged user", "software development",
|
||
etc. That's fou r, right there. Note, that these groups were not exchangable.
|
||
By that I mean that each user did not have 8 goups that were independant from
|
||
another user. A group number that mapped to one of the 8 would be even better.
|
||
Or, the extra 4 in each byte co uld represent any single group from a choice of
|
||
16.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30614 8-JUL 20:47 General Information
|
||
RE: File Attributes (Re: Msg 30578)
|
||
From: TIMKOONCE To: BRIANWHITE (NR)
|
||
|
||
Not sure about this, Brian, but I think that under OSk, rather than interpreting
|
||
|
||
the 16-bit user number as one number as in OS9/6809, it's interpreted as two
|
||
8-bit numbers. The high-order number is referred to as the "group", and the
|
||
low-order number is referred to as the "user number". So, you have 256 "groups"
|
||
|
||
of 256 users each. I don't beleive the file system makes any distinction
|
||
between public and group access, it's strictly a convenience for assigning user
|
||
numbers.
|
||
I could well be wrong, but this would at least explain what you say you've
|
||
been told. If anyone knows better, please correct me.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30347 24-JUN 03:26 Graphics & Music
|
||
VIEW 4.0
|
||
From: TIMKOONCE To: ALL
|
||
|
||
Shortly after uploading VIEW 4.0, Zack Sessions pointed out to me that I had
|
||
uploaded the wrong AIF.gif and AIF.gbw files! I've just re-uploaded the entire
|
||
archive with those corrected. In both of those AIF files, the first two lines
|
||
should be:
|
||
View
|
||
-s
|
||
|
||
Anyone that just used the AIF's to view GIF files with VIEW should notice that
|
||
VIEW now produces different results from ViewGIF!! <grin>
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30348 24-JUN 03:29 Programmers Den
|
||
Make update
|
||
From: TIMKOONCE To: ALL
|
||
|
||
I just re-uploaded MAKE to the database. This upload fixes one minor buglet,
|
||
and adds a new feature. You can now use MAKE with no makefile! Typing "make
|
||
<target>" with no makefile is the same as having a makefile with the single
|
||
line:
|
||
<target>:
|
||
i.e. MAKE will try to build the target file by searching the current directory
|
||
|
||
for source files that fit it's built-in rules. By setting up the default rules
|
||
in "make.default" properly, this could be a great help. Thanks to Mike Knudsen
|
||
for suggesting this change, and to Eddie Kuns for discovering the bug!
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30385 26-JUN 00:02 Programmers Den
|
||
RE: Make update (Re: Msg 30348)
|
||
From: RAGTIMER To: TIMKOONCE
|
||
|
||
And thanks to you for putting that feature in! Sorry I didn't help with the docs
|
||
|
||
as we hoped. I'll take a look at yours soon as I download the whole thing. My
|
||
"beta" version is doing just fine, meanwhile. Nice work, Tim -- a lot of
|
||
hackers will be grateful. Oops, I meant "developers", grin.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30350 24-JUN 10:07 Telcom
|
||
OSTERM
|
||
From: ELM To: ALL
|
||
|
||
I've just started to use OSTERM and have experienced a problem when downloading
|
||
ASCII text files under XMODEM or YMODEM. I seem to be getting extra line feeds.
|
||
|
||
When I print the text (by LISTing it to printer) I get what appears to be triple
|
||
|
||
spacing. I've tried XMODE /p -lf, but it doesn't change anything.
|
||
|
||
Anyone have any ideas?
|
||
|
||
Thanks.
|
||
|
||
Len
|
||
|
||
-*-
|
||
|
||
30367 25-JUN 02:35 Telcom
|
||
RE: OSTERM (Re: Msg 30350)
|
||
From: TRIX To: ELM
|
||
|
||
You will probably find relief from your CR/LF problem if you go to the SETTINGS
|
||
menu. (It's been so long since I set mine, I can't remember exactly) There is
|
||
an option there to set up your XModem downloads. It will ask you how you would
|
||
like your lines terminated when you download text files. You can set it to end
|
||
all your text download lines with just a CR which will make listing your files
|
||
much easier.
|
||
|
||
Here's the problem >I'M< having with OSTerm (2.0.7):
|
||
When I do a YModem-Batch download of a text file, the size is ALWAYS set (by
|
||
OSTerm) to 44418 regardless of the actual size of the file. The download
|
||
terminates properly (i.e. doesn't error out) but I'm still left with a 44K file
|
||
with lots and lots of garbage at the end. Y-Batch downloads of binary files
|
||
like PAKs, ARs, and executable code all work fine as do regular YModem downloads
|
||
|
||
of text files. How's THAT for a puzzler?
|
||
|
||
-John.
|
||
|
||
-*-
|
||
|
||
30370 25-JUN 03:13 Telcom
|
||
RE: OSTERM (Re: Msg 30350)
|
||
From: KNOT1 To: ELM
|
||
|
||
{Len,
|
||
|
||
Try going to "Settings (Profile)" and change your "DOWNLOAD-Line-terminators" to
|
||
|
||
just carriage return instead of carriage return+linefeed, which it may be set
|
||
to.
|
||
|
||
-Jamie (KNOT1)- i]
|
||
|
||
-*-
|
||
|
||
30373 25-JUN 18:09 Telcom
|
||
RE: OSTERM (Re: Msg 30367)
|
||
From: DODGECOLT To: TRIX
|
||
|
||
I think the Delphi Y-batch program is the culprit- apparently it just doesn't
|
||
send a length field when sending text files.
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30378 25-JUN 21:22 Telcom
|
||
RE: OSTERM (Re: Msg 30367)
|
||
From: EDDIEKUNS To: TRIX
|
||
|
||
I think I understand the problem with OSTerm and YModem batch. When Delphi
|
||
sends a text file via YModem batch -- it doesn't send a file-size. Delphi
|
||
doesn't know what you're going to do to the file in the way of stripping
|
||
linefeeds or whatever, so it just wimps out and doesn't send any filelenght
|
||
information. (The YBatch protocal doesn't leave Delphi much choice, I add.)
|
||
Thus, OSTerm may not (???) handle this lack of file length information very
|
||
gracefully.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30381 25-JUN 23:18 Telcom
|
||
RE: OSTERM (Re: Msg 30367)
|
||
From: ELM To: TRIX
|
||
|
||
Ain't life mysterious? Downloading a series of "44K" files sure is a quick way
|
||
to fill up a disk!
|
||
|
||
I'm using OSTERM 2.0.8, but I haven't tried YMODEM-Batch. I'll try to find a
|
||
way to give it a shot and let you know what happened.
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30383 25-JUN 23:20 Telcom
|
||
RE: OSTERM (Re: Msg 30370)
|
||
From: ELM To: KNOT1
|
||
|
||
I'll try resetting the download settings (assuming they're not correct), but
|
||
I've been downloading from Delphi for so long with other term programs with no
|
||
problem.
|
||
|
||
Also, I have the same problem when downloading from other services with OSTERM
|
||
2.0.8, although I don't know what THOSE settings are.
|
||
|
||
Thanks!
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30386 26-JUN 00:04 Telcom
|
||
RE: OSTERM (Re: Msg 30350)
|
||
From: RAGTIMER To: ELM
|
||
|
||
All text files I download (with OSTERM) have an extra line feed. There are
|
||
little utilities here to strip them off, or write your own. What I do is just
|
||
read the file into Dynastar word processor and write it back out, and they're
|
||
gone. Unforch, so are TABS (char byte 09).
|
||
|
||
-*-
|
||
|
||
30395 26-JUN 00:48 Telcom
|
||
RE: OSTERM (Re: Msg 30367)
|
||
From: GREGL To: TRIX
|
||
|
||
John,
|
||
|
||
That sounds like a flaw in OSTerm. When you download a text file from
|
||
Delphi, the filesize is set to zero in the Ymodem Batch header block. This is
|
||
mostly because Delphi can't calculate ahead of time what the actual filesize
|
||
will be. That is, Delphi automatically handles end-of-line conversions (CR/LF to
|
||
|
||
CR or LF and vice versa) according to your SETTINGS and doesn't know how many
|
||
end-of-line characters are stored in the file and whether or not they need to be
|
||
|
||
added or removed.
|
||
OSTerm should not perform an explicit set filesize call if the filesize in
|
||
the Ymodem Batch header is zero. To be honest, I don't think it should perform
|
||
an explicit set filesize call regardless. If the filesize stored in the Ymodem
|
||
Batch header block is invalid, OSTerm can really mess up an otherwise good
|
||
download that way.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30398 26-JUN 02:35 Telcom
|
||
RE: OSTERM (Re: Msg 30367)
|
||
From: KNOT1 To: TRIX
|
||
|
||
Yes, with YModem (batch) the "File size" in block 0 is optional. Non-text files
|
||
|
||
are always the same size, so Delphi includes the size in block 0. Text files
|
||
can vary do to the CR/LF/CR+LF line terminator option. So, instead of scanning
|
||
the file and figuring out the file size, Delphi just sets it to zero or maybe
|
||
null. It appears that OSTurm may be assuming that file size is always included,
|
||
|
||
or it might just be a simple bug.
|
||
|
||
Since we're airing our YModem beefs, here's mine:
|
||
|
||
Note: I'm not using OSTerm. When the file is about 1K or more evrything's
|
||
fine. When it's smaller, when it starts with XModem (128 byte) blocks from the
|
||
start, I receive block 0 just fine. When I ACK it, Delphi sends block 1 before
|
||
I send the NAK-CRC for it and it gets purged from the buffer prior to sending of
|
||
|
||
the NAK-CRC. This wouldn't be so bad on its own, but then Delphi will NOT
|
||
re-send block 1 when sent either a NAK-CRC or a NAK. I have to abort the
|
||
transfer and download it using XModem-1K. This never happens with the larger
|
||
files. I suspect this may be a bug on Delphi's end. Any help, anyone?
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30399 26-JUN 02:36 Telcom
|
||
RE: OSTERM (Re: Msg 30383)
|
||
From: KNOT1 To: ELM
|
||
|
||
Len,
|
||
|
||
Does OSTerm download direct-to-disk or to a buffer and then writes it to disk?
|
||
If to a buffer, it may be doing some sort of "translating" somewhere.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30400 26-JUN 07:57 Telcom
|
||
RE: OSTERM (Re: Msg 30399)
|
||
From: ELM To: KNOT1
|
||
|
||
OSTERM downloads direct to disk.
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30414 27-JUN 01:35 Telcom
|
||
RE: OSTERM (Re: Msg 30395)
|
||
From: KNOT1 To: GREGL
|
||
|
||
Gregy, baby!! <GRIN!> What are you saying??! The file size information is why
|
||
I WANTED YModem Batch! If that information is invalid, then the system sending
|
||
the file had better get it's act together! All of the information in block 0 is
|
||
|
||
CRC protected, after all. So there shouldn't be any "bad transmition" problems.
|
||
|
||
It's a really great way of cleaning up all that extra garbage at the end of the
|
||
file. Well, *I* like it, even if others don't! :-)
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
{P.S.: Did you read my message to you a few days ago? (#30254)
|
||
|
||
-*-
|
||
|
||
30415 27-JUN 01:36 Telcom
|
||
RE: OSTERM (Re: Msg 30400)
|
||
From: KNOT1 To: ELM
|
||
|
||
Well, I guess that blows THAT idea out of the water! If it's not your settings,
|
||
|
||
I can't figure what OSTerm is doing. Does OSTerm have any "Download settings"
|
||
you can change? I guess you probably would have already have tried that though,
|
||
|
||
hmm? I have my own terminal program which has YModem Batch and it doesn't have
|
||
any such problem, so it's not Delphi having problems. If you figure it out I'd
|
||
be glad to hear what it is.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30417 27-JUN 20:50 Telcom
|
||
RE: OSTERM (Re: Msg 30414)
|
||
From: GREGL To: KNOT1
|
||
|
||
Jamie,
|
||
|
||
Somewhere along the line it seems you missed the point entirely. When you
|
||
download an ASCII (text) file, Delphi automatically performs end-of-line
|
||
conversions for you. If you download a file that was originally uploaded using
|
||
CR/LF line terminators, Delphi will convert those to CR automatically. Of course
|
||
|
||
that really depends on your settings as you can tell Delphi to use CR, LF or
|
||
CR/LF line terminators.
|
||
If Delphi were to include the filesize, it would have to perform perform the
|
||
|
||
end-of-line conversions prior to initiating the file transfer and that could
|
||
mean some very long delays. I much prefer it done the way it is.
|
||
As far as the various file transfer protocols go, Xmodem, Xmodem-1K, and
|
||
Ymodem aren't that great. Neither of them work very well across packet switching
|
||
|
||
services such as Telenet and Tymnet. Wxmodem tried to take care of that but it
|
||
resorts to vanilla Xmodem once the window-buffer has been exceeded on many
|
||
systems.
|
||
Although you may argue the point, Kermit and Zmodem are both well designed
|
||
protocols (although the fact that they are *designed* makes them stand above the
|
||
|
||
rest - the others just happened out of accident) that work very well in many
|
||
instances where others fall flat on their faces. Oh yes, I have used both Kermit
|
||
|
||
and Zmodem in many cases where neither Xmodem or Ymodem would even get started.
|
||
Although Kermit suffers from the small block sizes that are used by the earlier
|
||
implementations. For many reasons, most of which is described above, I have
|
||
pretty much abandoned use of Xmodem, and Ymodem. Fortunately, you should see
|
||
Zmodem available on Delphi in the very near future. Zmodem is currently in beta
|
||
test and results so far show that it works very well, although error recovery
|
||
(the ability to pick up where you left off on aborted downloads) has not been
|
||
implemented as of yet. Zmodem also uses variable length packets to aleviate the
|
||
padding characters.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30423 28-JUN 01:24 Telcom
|
||
RE: OSTERM (Re: Msg 30417)
|
||
From: KNOT1 To: GREGL
|
||
|
||
Greg,
|
||
|
||
Yes, but Delphi could save two file sizes, one for single character line-
|
||
terminators and another for two character line-terminators. Or maybe just the
|
||
number of lines in the file. This could be done at the time the file is
|
||
uploaded, taking no additional download time.
|
||
|
||
From what little I've heard, ZModem does sound nice. I've been writing my own
|
||
terminal program and have been only able to implement those protocols supported
|
||
on the boards I call. I only call a couple of places and none of them have
|
||
ZModem. I'm glad to hear that Delphi will have ZModem. Can I assume that there
|
||
|
||
is or will be text files describing how to implement it from a programming
|
||
standpoint? Thanks.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30426 28-JUN 20:57 Telcom
|
||
RE: OSTERM (Re: Msg 30367)
|
||
From: ELM To: TRIX
|
||
|
||
I took your advice and changed my settings to CR only. It seemed to solve the
|
||
problem, at least for the text file I downloaded as a test. However, the
|
||
problem persists on other systems I use that don't permit changing settings.
|
||
|
||
In the meantime, I have switched to Telstar and am about to download a text file
|
||
|
||
as a test. One annoyance I have discovered with Telstar is that for some
|
||
reason, CTRL-S doesn't stop the scroll on Delphi.
|
||
|
||
(Sigh)
|
||
|
||
Life is SO complicated!
|
||
|
||
Thanks again,
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30428 28-JUN 23:12 Telcom
|
||
RE: OSTERM (Re: Msg 30423)
|
||
From: EDDIEKUNS To: KNOT1
|
||
|
||
The problem is that Delphi has no idea what CR/LF you use, and thus, even if it
|
||
counted lines and figured the arithmetic, it wouldn't know what size to send.
|
||
YModem batch is a fundamentally flawed protocal, tho better than it's
|
||
predecessors. It's nice for binary files. :) I suppose that Delphi could
|
||
implement that line-counting and force you to set the EOL-character count. But
|
||
that forces people to understand more about their machine than many are willing
|
||
to. (And if that is set wrong, then files will either be extended with garbage
|
||
at the end or chopped short.)
|
||
|
||
File length isn't so important with ASCII files anyway, as a good YBatch
|
||
download protocal will strip all ^Z and NULLs (etc) anyway. Tho the rest of the
|
||
|
||
attributes (last change date + attrs) might be nice.
|
||
|
||
ZModem docs exist I believe in the telecommunication database. In fact, I
|
||
believe public domain UNIX C source to ZModem has been posted here.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30431 29-JUN 00:54 Telcom
|
||
RE: OSTERM (Re: Msg 30426)
|
||
From: KNOT1 To: ELM
|
||
|
||
Len,
|
||
|
||
You can always still use an utility here to stip those line-feeds from the files
|
||
|
||
you download.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30432 29-JUN 00:55 Telcom
|
||
RE: OSTERM (Re: Msg 30428)
|
||
From: KNOT1 To: EDDIEKUNS (NR)
|
||
|
||
Eddie,
|
||
|
||
Sure Delphi DOES know what CR/LF you use! That's why you set your "DOWNLOAD-
|
||
Line-terminators" in the "Settings (Profile)" section. How else does Delphi
|
||
send the files with the correct line terminators? You're not talking about
|
||
something else, are you?
|
||
|
||
How does the receiving YModem know that it is a text file? What if it's a
|
||
binary file that ends with Ctrl-Z's and/or NULL's? I was concerned about
|
||
chopping off the end of files by doing that.
|
||
|
||
Thanks, I'll look for the docs and the source.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30445 30-JUN 15:11 Telcom
|
||
RE: OSTERM (Re: Msg 30350)
|
||
From: TIMKOONCE To: ELM
|
||
|
||
Here's the reason for your problem. Under XModem or YModem, ALL text files are
|
||
supposed to have both a CR and a LF between lines. Delphi allows you to set
|
||
things so that it only puts a CR between lines, which is what OS9 uses, but most
|
||
|
||
BBS's aren't so friendly. You basically have two options:
|
||
- Find a program which will let you remove the extra LFs from the file. One
|
||
possibility is the "list" replacement I uploaded here a long time ago. It will
|
||
automatically remove/convert LFs, so you can simply "list file >newfile" to
|
||
correct that problem.
|
||
- Find a terminal program which will do that conversion for you on downloads.
|
||
|
||
I have a stand-alone YModem program that does it, as soon as I can clean it up
|
||
enough for posting, and Eddie Kuns has one that does it that should be in the
|
||
next shareware release of KBCom. Unforch, few OS9 terminal programs offer this
|
||
ability (though most RSDOS ones do seem to, dunno why the difference).
|
||
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30447 30-JUN 15:18 Telcom
|
||
RE: OSTERM (Re: Msg 30367)
|
||
From: TIMKOONCE To: TRIX
|
||
|
||
OSTerm 2.0.7 does have a problem with YModem file sizes. Here's what happens:
|
||
- Under certain situations, (files that need conversion, or files being
|
||
written by another process), the YModem sender cannot know the final file size.
|
||
In that case, it is correct behavior for the YModem sender to NOT include a file
|
||
|
||
size.
|
||
- OSTerm does not recognize that a file size is not included, and ends up
|
||
with some rediculous size. (You're lucky, when I had problems with this, OSTerm
|
||
|
||
decided that everything was 2 megs long!)
|
||
- OSTerm 2.0.7 tries to pre-extend the file to the final length, so if the
|
||
actual amount of data received is too small, then you still end up with a file
|
||
with that size.
|
||
- OSTerm 2.0.8 corrects this, and doesn't pre-extend the file, so at least
|
||
you don't end up with huge files.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30448 30-JUN 15:26 Telcom
|
||
RE: OSTERM (Re: Msg 30432)
|
||
From: TIMKOONCE To: KNOT1
|
||
|
||
Jamie,
|
||
There are some problems with the YModem protocol. You've found the two
|
||
big ones:
|
||
- There's no indication of file type, so the receiver can't know whether the
|
||
file is binary or text.
|
||
- It's not always possible to know the file size in advance. More modern
|
||
protocols, such as Kermit or ZModem, have variable-sized packets so they don't
|
||
need to know the file size in advance.
|
||
|
||
There are several work-arounds, some of which Eddie and I have been working
|
||
|
||
with lately. In a short while, some of that work should be available here.
|
||
- The user can tell the receiver what type of file to expect. This is what
|
||
most RSDOS programs currently do.
|
||
- The receiver can examine the file contents and try to guess what file type
|
||
it is. I have a program I'm writing which hasn't guessed wrong in over 50
|
||
dowxDnloads. I'm starting to trust it.
|
||
- When doing text downloads, which is the most common case where the file
|
||
size isn't known in advance, the receiver can simply remove ^Z and null
|
||
characters, which are the most common pad characters, in addition to performing
|
||
end-of-line conversions. I'm also using a "smart" end-of-line conversion
|
||
algorithm which correctly converts Unix-style files which only have LFs between
|
||
lines.
|
||
- The Atari people came up with a clever way of coding the file size in the
|
||
last XModem packet. A very clever hack that never caught on elsewhere.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30450 30-JUN 16:42 Telcom
|
||
RE: OSTERM (Re: Msg 30445)
|
||
From: ELM To: TIMKOONCE
|
||
|
||
I think I understand. I have changed my Delphi settings to CR only, and that
|
||
seems to have solved the problem.
|
||
|
||
I have been using three term programs; OSterm, Telstar, and Supercomm.
|
||
Unfortunately, each has exhibited different problems when used to download under
|
||
|
||
Xmodem or Ymodem. I have downloaded KBCom but haven't been able to boot it.
|
||
Possibly an error in downloading.
|
||
|
||
I guess I've been spoiled by reliable, uncomplicated terminal programs like
|
||
MikeyTerm that do the stripping, slicing, dicing, etc. automatically.
|
||
|
||
Thanks for the help!
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30455 1-JUL 00:46 Telcom
|
||
RE: OSTERM (Re: Msg 30450)
|
||
From: TIMKOONCE To: ELM
|
||
|
||
Well, MikeyTerm doesn't do it automatically, it just stores it in mem and lets
|
||
you decide when you save it to disk. Several other RSDOS term programs do the
|
||
same: let you decide. The equivalent for OS9 would be to either ask you before
|
||
the download starts, or else let you use some OS9 utility to do the conversion.
|
||
There are several easy-to-use utilities in the database here that can help with
|
||
that.
|
||
Also, as I mentioned to Jamie, I've been working on a "smart" download
|
||
program which I should get on the ball and clean up enough to upload here. It
|
||
will automatically determine whether the other end is using XModem, YModem, or
|
||
YModem-batch, automatically determine whether the file is text or binary, and
|
||
does several other nice things, all automatically. Pretty easy to use, but I
|
||
need to get it cleaned up enough for someone other than me to use! <grin>
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30469 1-JUL 23:36 Telcom
|
||
RE: OSTERM (Re: Msg 30448)
|
||
From: KNOT1 To: TIMKOONCE
|
||
|
||
Hi, Tim,
|
||
|
||
I'm still touching up my term program. Converting hard-coded features into
|
||
user-selectable. Hoping to someday add some of these features into it, though
|
||
not right away, or I'llrTJQgQ2IM%=9U%Q1=9e2=I*A1=%9j$TH(LoUQz*"=M9"=U9"==!=e9=BukH2oJ=U:UMMQJ"!2%1"eA}j$h=5Q!%9b%-iJJQz91e=9Q%9M!I
|
||
QIMbb9j2JQM
|
||
%%}j$tJHb%QQ1j=I=5A1a"!9"!Q}Ju+H:=U1BY~:o"QI5%9"!Q:%Q!%9"!5RTHZ9sQ1=
|
||
-"==1%!Q}j$TH(M1"!EI%jQ!=JMrQ9J9"!=J9jeI=I5"=*MJQ9JUHhV+59QJQzUQ"!=U!QI:I%Q%95*AJUj5
|
||
UM"!EI%=IJ,X6l5RDoesn't even use it at all, and Delphi only uses it on text files.
|
||
|
||
Thanks for the input.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30473 2-JUL 03:30 Telcom
|
||
RE: OSTERM (Re: Msg 30455)
|
||
From: KNOT1 To: TIMKOONCE
|
||
|
||
Hey! Hey! What's going on here! Stealing my techniques! And without even
|
||
KNOWING about them even! ;-) Just kidding, of course. But mine does
|
||
automaticly determine which protocol is being used for downloading too. All you
|
||
|
||
have to do is tell it if it is Checksum or CRC, since it needs to know which NAK
|
||
|
||
to send. This wasn't because I was TRYING to be fancy or anything. I was just
|
||
implementing each protocol one at a time (XModem, XModem-1K, then YModem) and,
|
||
not wanting to write more new code than necessary (i.e. lazy :-), I just
|
||
expanded the old code, figuring I'd just add promts where needed. Well it
|
||
turned out they weren't needed. I figured, "Gee, that's NICE." And that's how
|
||
that worked out. Not due to any great "vision" for sure! Heck, I had never
|
||
even USED them before I wrote the program.
|
||
|
||
So, I was wondering if you would have the time and and e willing to give it a
|
||
test spin? Sounds like you would know what to look for. If so, do you have a
|
||
Hayes-compatable modem, and what baud is it? I believe I can assume you have a
|
||
CoCo 3 with at least 512K, right?
|
||
|
||
Thanks again.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30507 4-JUL 21:24 Telcom
|
||
RE: OSTERM (Re: Msg 30473)
|
||
From: TIMKOONCE To: KNOT1
|
||
|
||
Actually, Jamie, I've been working on these ideas for a while now. A couple of
|
||
pointers for you:
|
||
1) Automatic CRC/Checksum detection is easy, just send "C" three times, and
|
||
if you still have no response, send NAK. This is the method recommended by
|
||
Chuck Forsberg, author of the YModem protocol.
|
||
2) _please_ include proper handling for ASCII text files. I get tired of
|
||
having to filter downloaded text files to remove/convert linefeeds. I use a
|
||
simple algorithm to do this type of conversion: if a LF follows a CR, remove i,
|
||
otherwise, change it into a CR.
|
||
If you have any other good ideas you'd like to share, I'm interested.
|
||
|
||
If you're writing a terminal program, allow a shell escape, and make sure you
|
||
release the serial port (i.e. turn off the signal) before you fork the shell.
|
||
That way, you won't mess up other programs that try to use the serial port.
|
||
|
||
As for beta-testing, I'd love to, but I don7t have very much time right now.
|
||
You're welcome to send it to me, and I'll play with it and try to give you some
|
||
comments/feedback, but I am busy, so the response might be less than
|
||
instantaneous.
|
||
- TimAzt
|
||
|
||
-*-
|
||
|
||
30510 4-JUL 22:00 Telcom
|
||
RE: OSTERM (Re: Msg 30469)
|
||
From: TIMKOONCE To: KNOT1
|
||
|
||
I buffer up the first 1k of the file (real easy to do with YModem!) and test
|
||
that much. Seems to help prevent false indications on the first 128 bytes. I
|
||
"guess" a file is text if it only contains characters 0, 9, 10, 13, 26, 32-126,
|
||
and the first byte isn't 0. You have to allow for 0 and 26, since those are the
|
||
|
||
common pad character (if the file is less than 1k, those characters might be
|
||
there), the rest is pretty self-explanatory. Seems to work pretty well, so far.
|
||
|
||
Right now, I can simply fork a shell from inside most terminal programs, type
|
||
"xydown", and it will: open it's own serial path, determine the transfer type
|
||
(CRC or Checksum, YBatch, YModem or XModem), use a reasonable file name (convert
|
||
|
||
the YBatch filename if there is one, otherwise it uses xydown.file), change the
|
||
filename if necessary to avoid overwriting any other files, determine the file
|
||
type and remoe LFs and such if necessary, all automatically. Very, very
|
||
convenient. Someday I hope to add WXModem support for use on Delphi.
|
||
I'm hoping to upload it soon. It will be public domain, so anyone is free to
|
||
|
||
use the ideas and code in it however they please.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30523 6-JUL 02:08 Telcom
|
||
RE: OSTERM (Re: Msg 30510)
|
||
From: KNOT1 To: TIMKOONCE
|
||
|
||
Tim,
|
||
|
||
But what if a text file contains Alt-characters, such as "-", ";", ",", or ".",
|
||
or any of the others? Does the user have the option of forcing the text mode
|
||
on/off? Right now my program just writes the data direct to disk, with no
|
||
translation. Hadn't thought of it before, but I am now. What if it's a LF-CR
|
||
combination instead of a CR-LF one? Also, didn't you say something before about
|
||
|
||
yours also handling UN!X LF-only type files?
|
||
|
||
Yes, if you select CRC, mine does switch to Checksum after about three attempts.
|
||
|
||
If you're using YModem (you can optionally tell it what to expect) it
|
||
automatically selects CRC mode for you since all YModem protocols are suppose to
|
||
|
||
support CRC, otherwise it prompts for your selection. This was useful when I
|
||
wanted to force Checksum on a board that used CRC but I had some problems with
|
||
it: it ALWAYS expected a NAK-CRC for bad blocks, and wouldn't accept a normal
|
||
NAK. Real annoying.
|
||
|
||
Here's feature of my program that I think is kind of neat. It has a co-program
|
||
that runs concurrently with the terminal program. It's called "bigbuff" and all
|
||
|
||
it does is extract data from the serial port and puts it in a 7-1/2 K get/put
|
||
buffer. This results in excellent performance, even when capturing text
|
||
direct-to-disk at 2400 bps (I am using the ACIA patch for a 256 byte system
|
||
buffer) and I haven't lost a character yet. Also allows you to use menus or
|
||
perform other functions while there is still incoming data without having to
|
||
worry about buffer overrun. It is very "CPU friendly" in that it doesn't hog
|
||
CPU time. I do normally bump its priority to 129 just to minimize any chance of
|
||
|
||
lost data if some other running program is chewing up CPU time. Any higher than
|
||
|
||
129 an IT chews up CPU time. Also, if "bigbuff" hasn't received any data in
|
||
about 8 (I believe) seconds, it goes to sleep, saving even more CPU time. It
|
||
has a fairly slick routine so as to {not miss any data when going to sleep
|
||
without having to constantly wakeup every so often.
|
||
|
||
Yes, I do have a Shell escape. Other programs are always free to write to the
|
||
serial port (even while the term program is running), but if they want to read
|
||
from it, they'll either have to use the "bigbuff" routines, or more likely, I'll
|
||
|
||
make a way to tell "bigbuff" to "hibernate" when it receives a certain signal.
|
||
|
||
I'll send you a copy as soon as I cleanup a few more things. There's no
|
||
horrendous rush or anything. I've been writing it on and off for about a year
|
||
now. I don't believe a little more time will be big deal.
|
||
|
||
Oh, is your modem Hayes-compatible? What baud is it?
|
||
|
||
Thanks a lot,
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
P.S.: Those WERE Alt-characters, but it appears Delphi strips the High-bit!
|
||
|
||
-*-
|
||
|
||
30544 7-JUL 14:42 Telcom
|
||
RE: OSTERM (Re: Msg 30523)
|
||
From: TIMKOONCE To: KNOT1
|
||
|
||
Well, you appear to have found two cases where the automatic file-type detection
|
||
|
||
might not give the desired results. Here's some of the thinking, though:
|
||
- If a text file contains ESC sequences or ALT characters, then it's safest
|
||
to transfer it as a binary file, since it may well be the case that LFs
|
||
appearing in such a file should be treated as LFs and not as line terminators.
|
||
The algorithm should err on the side of going to binary, as the user can always
|
||
do the conversion manually if necessary. My program does allow the user to
|
||
force ASCII filtering, if they wish.
|
||
- My algorithm would end up doing the following conversions:
|
||
CR/LF -> CR
|
||
LF -> CR
|
||
LF/CR -> CR/CR
|
||
CR/CR -> CR/CR
|
||
As you can see from the second case, it handles Unix files (also Amiga) just
|
||
fine.
|
||
|
||
As for your local BBS that doesn't treat NAK and 'C'(==NAK_CRC) identically,
|
||
that deserves a complaint to the BBS author. That is a serious problem. I
|
||
imagine they get lots of complaints! <grin>
|
||
|
||
Your "bigbuff" idea sounds quite reasonable. Sounds like it should try
|
||
setting up a received data signal and using that, which should cut down on the
|
||
CPU time required. Sounds a lot like some ideas I've had.
|
||
|
||
I have a 1200-baud Haye's-compat modem.
|
||
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30577 8-JUL 03:19 Telcom
|
||
RE: OSTERM (Re: Msg 30417)
|
||
From: BRIANWHITE To: GREGL
|
||
|
||
Greg,
|
||
|
||
The one nice thing about OSTerm automatically creating the of the full size
|
||
right at the start is that it eleiminated fragmentation problems. And on ha
|
||
hard disk like mine, finding a new free block can take up to 5 seconds (I'll
|
||
have have to re-format o ne of these days). I wouldn't want to have to do that
|
||
after each 1k of data. You're right though about handling files that don't have
|
||
|
||
a file size. Those should be expanded as necessary.
|
||
|
||
Brian
|
||
|
||
-*-
|
||
|
||
30579 8-JUL 03:52 Telcom
|
||
RE: OSTERM (Re: Msg 30544)
|
||
From: KNOT1 To: TIMKOONCE
|
||
|
||
Well, NAK and 'C' aren't suppose to be treated *identically*. On page 24 of my
|
||
X/YModem docs it says "After the first <ack> is received the sending program
|
||
should ignore <C>s." So the board I was calling was doing just the opposite,
|
||
ignoring <nak>s!
|
||
|
||
Yes, my "bigbuff" does set up a received-data-signal, after about 8 seconds with
|
||
|
||
no incoming data.
|
||
|
||
Thanks for all the help and information, Tim. I've captured all of this dialog
|
||
and intend to implement most/all of it sometime before January, when I'll be
|
||
going (hopefully!!!) off to U of M full-time, and won't have much time for
|
||
writing programs. But first I want to get my "cp" program down to under 7-1/2 K
|
||
|
||
if possible. I have it down to 8096 bytes from the original 8862 bytes.
|
||
|
||
I hope to be sending you a copy sometime in the near future. And thanks again.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30352 24-JUN 13:28 Utilities
|
||
Pak problems
|
||
From: EARLROB To: ALL
|
||
|
||
I have been using pak for a few years with no problems, until now. I have
|
||
about 15 GIF pictures in a pak, and I can not get them out. When I try to
|
||
extract any one of them, the program gets stuck on the first item in the pak,
|
||
and locks up. When I try to extract all of the files, the first file is
|
||
extracted, but with all of the other files appended to the end of it (all of the
|
||
|
||
files extract as one stream).
|
||
The directory of the pak shows that all files still exist as seperate files
|
||
in the pak, and when I tried to add to the pak, each seperate file was copied to
|
||
|
||
the new pak. I can not remove, update, test, or extract.
|
||
One thing that I tried to do was to use ded to take the whole pak stream
|
||
that is extracted in the first file, dump the sectors of each seperate file, and
|
||
|
||
hence, get each file (Gif files are not compressed by pak). My only problem is
|
||
that I know how to diddle with the file length for extra characters at the end
|
||
of the files, but not at the beginning. Viewgif will not work with extra leading
|
||
|
||
chars.
|
||
Can any body help, either with the successful extraction, or with trimming
|
||
the leading chars. of the files? It has been a very frustrating experience.
|
||
Thanks,
|
||
Rob
|
||
|
||
-*-
|
||
|
||
30371 25-JUN 03:14 Utilities
|
||
RE: Pak problems (Re: Msg 30352)
|
||
From: KNOT1 To: EARLROB
|
||
|
||
Rob,
|
||
|
||
You could write a simple program to copy the data from one file to a new one,
|
||
skipping past the leading characters you want to remove.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30359 24-JUN 22:50 Programmers Den
|
||
MM1 & C
|
||
From: NES To: ALL
|
||
|
||
Paul ward, Kevin, will the C compiler for the MM1 be able to compile OS9 level 2
|
||
|
||
C sources without modifing it? as log as it dosent have MV calls or what?
|
||
|
||
-<NES>- Eric
|
||
|
||
|
||
-*-
|
||
|
||
30389 26-JUN 00:16 Programmers Den
|
||
RE: MM1 & C (Re: Msg 30359)
|
||
From: RAGTIMER To: NES
|
||
|
||
I'm not Paul or Kev, but I'd wager you can port any C programs as-is as long as
|
||
there are no raw system calls, ie, _os9(), as well as no Coco-specific calls
|
||
such as you mentioned.
|
||
|
||
The _os9() calls will work as soon as you rewrite them a little bit. Remember,
|
||
they use CPU registers so have to change a bit.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30366 25-JUN 02:21 Programmers Den
|
||
Subroutine modules in C in OSk
|
||
From: EDDIEKUNS To: ALL
|
||
|
||
Does anyone out there know if OSk supports subroutine modules in C (or any other
|
||
|
||
language) in OSk in an easy way? (I mean subroutine modules which can share
|
||
your global variables.) I know roughly how to do this in OS-9, but before I
|
||
code it I want to make sure I'm not giving myself a headache for the future in
|
||
porting code to OSk!
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30368 25-JUN 02:41 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30366)
|
||
From: TRIX To: EDDIEKUNS
|
||
|
||
Don't keep us (ME) in suspense! How the heck do you pull off subroutine
|
||
modules? Inquiring minds (mine) want to know! Was that a subtle enough hint?
|
||
<grin>
|
||
|
||
-John.
|
||
|
||
-*-
|
||
|
||
30375 25-JUN 20:10 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30366)
|
||
From: XLIONX To: EDDIEKUNS
|
||
|
||
Howdy Eddie,
|
||
|
||
I am not sure if osk supports it but the 680x0 instruction set does (better than
|
||
|
||
the 6809). I think there is a global link and execute instruction. If MMPU is
|
||
installed I am not sure if processes can easily cross borders ?!?!
|
||
|
||
-mark
|
||
|
||
-*-
|
||
|
||
30379 25-JUN 21:25 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30368)
|
||
From: EDDIEKUNS To: TRIX
|
||
|
||
Well, I haven't DONE it yet! Once I've done it, I'll write up an article and
|
||
post it. I hope to turn the terminal emulations into overlays in KBCom sometime
|
||
|
||
after my vacation (which starts tomorrow!). Mike Knudsen is the one who pulled
|
||
it off first tho, in UltiMusE! He deserves all the credit for research and
|
||
clever thinking.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30380 25-JUN 21:29 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30375)
|
||
From: EDDIEKUNS To: XLIONX
|
||
|
||
Thanks! Yeah, I've been reading through the Motorola 68k Users Manual! Quite a
|
||
step up from the good-ole 6809. <Whew> I have the basic ideas down but won't
|
||
really have a working model until I WRITE some 68k assembly, I think. It's a
|
||
good thing I speak 6809 to start with! :-)
|
||
|
||
I'm hoping that OSk supports subroutine modules in a simple way. It would make
|
||
my life much much easier!
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30391 26-JUN 00:23 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30366)
|
||
From: RAGTIMER To: EDDIEKUNS
|
||
|
||
Eddie, if you mean "do all of Ragtimer's dirty rotten tricks for getting shared
|
||
globabls in subr modules also work in OSK C," then well, I'm glad you brought
|
||
that up....well, "glad" isn;t the way I feel, but yes the subject needs some
|
||
thought, hmmm.
|
||
|
||
But who needs 'em? Just write one big momma application program! For those
|
||
special systems uses (terminal adapters), I dunno.
|
||
|
||
-*-
|
||
|
||
30392 26-JUN 00:31 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30379)
|
||
From: RAGTIMER To: EDDIEKUNS
|
||
|
||
Hey thanks, Eddie. But I don't get any thanks for documenting the tricks very
|
||
coherently, and I don't recall uploading them here either.
|
||
|
||
Just writing subroutine modules isn't too hard -- look in the back of the C
|
||
Manual under writing subrs for Basic09, and ignore the crud about the extra
|
||
arguments. Use that -b switch to the linker.
|
||
|
||
Hard part is getting common global variables. Globals vars are a main reason
|
||
why all serious OS9 programs are in C and not Basic09 (my humble opinion, grins)
|
||
|
||
. To get these in C you gotta cheat and fool the compiler, and dodge little
|
||
land mines in the C Library.
|
||
|
||
If enuf people holler, maybe I'll collect my writings and clean them up and
|
||
post.
|
||
|
||
-*-
|
||
|
||
30397 26-JUN 01:16 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30392)
|
||
From: EDDIEKUNS To: RAGTIMER
|
||
|
||
Holler!
|
||
|
||
<Grin> If you don't post your descriptions on how to do C subroutine modules
|
||
then I'll do it once I figure it out! (hehehe) Perhaps the hardest part for me
|
||
|
||
is figuring out how to chop up cstart.a into the lowest common denominator. I
|
||
haven't looked at it hard tho.
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
30418 27-JUN 21:20 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30397)
|
||
From: RAGTIMER To: EDDIEKUNS
|
||
|
||
Maybe I should email you the source for dstart.a, as I call it. I ripped out
|
||
everything I could understand, including the stack checking code. Had to leave
|
||
that OVERFLOW message in, tho.
|
||
|
||
Hardest part of making my scheme WORK is to allow for the little initialized ~r
|
||
|
||
routines bring in with themselves. Printf() family and malloc().
|
||
|
||
-*-
|
||
|
||
30427 28-JUN 23:04 Programmers Den
|
||
RE: Subroutine modules in C in OSk (Re: Msg 30418)
|
||
From: EDDIEKUNS To: RAGTIMER
|
||
|
||
Another problem I'll have is the large static arrays of strings KBCom uses for
|
||
the menus. Hmm. Unfortunately, I can't not make them static as C won't allow
|
||
an initialized 2-d array. (array of strings)
|
||
|
||
Eddie
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30372 25-JUN 08:19 Programmers Den
|
||
Accessing Screens
|
||
From: HYPERTE To: OS9UGPRES
|
||
|
||
|
||
Kev,
|
||
|
||
Here's one for you.
|
||
|
||
I'm adding a feature into ShellMate to allow it to execute programs in the
|
||
same way that GShell does (minus the icons). It works fine for the first program
|
||
|
||
that I fork. But when I try to fork a second one, I can't get to the screen
|
||
where the first one was forked, to possibly run the second program on that same
|
||
screen as the first, providing there was room on that screen. The first time I
|
||
fork a program I use open ("/w",3). The second time I fork a program I've tried
|
||
to simply Select the same path number that the open call returned when I forked
|
||
the first program, but that doesn't seem to work. And doing another open
|
||
("/w",3) call simply gives me a brand new screen.
|
||
|
||
I realize that C isn't your strongest area (yet), but I thought you might be
|
||
|
||
able to give me a concept that I could convert to C code and use.
|
||
|
||
So, got any suggestions?
|
||
|
||
|
||
..Thanks...
|
||
|
||
..Eric...
|
||
|
||
-*-
|
||
|
||
30436 29-JUN 21:31 Programmers Den
|
||
RE: Accessing Screens (Re: Msg 30372)
|
||
From: DENNYSKALA To: HYPERTE
|
||
|
||
Check out a program I uploaded called 'getnw'. It gets the real name of the
|
||
next available window. Then if you open /w right away, you know its real name.
|
||
The program is asm, but the concept may be of use to you.
|
||
|
||
***** Dennis *****
|
||
|
||
-*-
|
||
|
||
30446 30-JUN 15:14 Programmers Den
|
||
RE: Accessing Screens (Re: Msg 30372)
|
||
From: TIMKOONCE To: HYPERTE
|
||
|
||
Some time back, I think I finally figured out how GShell does that trick of
|
||
being able to go back to any screen. The way I think it does it is to open a
|
||
full-screen window, turn off device protection for it, and use that as a
|
||
"handle" on that screen. Once you have a window set up like that, you can
|
||
select that window (which you own), and then put other windows on top of it
|
||
(since you turned off device protection). The problem with trying to Select a
|
||
window where another program is running is that if that program is waiting for
|
||
input, SCF won't let you write to the window, so you'll end up waiting until
|
||
that program is done with it's input.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30636 10-JUL 02:56 Programmers Den
|
||
RE: Accessing Screens (Re: Msg 30372)
|
||
From: OS9UGPRES To: HYPERTE
|
||
|
||
Eric,
|
||
|
||
I see that someone has answered... and correctly. GShell opens a full-size
|
||
window, and turns off protect on it. Any windows opened "over" it share the same
|
||
|
||
video memory, so you can draw to the background screen anywhere you wish.
|
||
|
||
That's how gshell lets you draw the expandable box with the mouse... it's simply
|
||
|
||
using that background window, and checking for conflicts with windows whose
|
||
coords it keeps in a table.
|
||
|
||
Then it can open new windows and fork programs, using type FF or 00, altho I'm
|
||
not sure which they actually use. I have to admit, working on the OSK windows is
|
||
|
||
making a lot of this knowledge seep away from me <groan>.
|
||
|
||
Kev
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30376 25-JUN 20:20 New Uploads
|
||
XPres
|
||
From: XLIONX To: ALL
|
||
|
||
I am sorry if the ARC format caused anyone problems :-(. In the future I will
|
||
try to use PAK. Os9arc and Dearc provide the best compression to date (that I
|
||
have found).
|
||
|
||
Bug-Report for XPres.doc: for the call gC SetGC* : should read gC# SetGC ptr*
|
||
|
||
Thats all so far and ignore the "'" in the docs arround the # sign.
|
||
|
||
I know the things huge (I have 1Meg) but I am working on the RMA version. I have
|
||
|
||
about 20% of the untested code written...arrrgggghhhhhhh!
|
||
|
||
|
||
-Mark W. Farrell -SIGOp ProSIG (Pinball Haven) -XLIONX (DELPHI) -mwf@SANDV
|
||
|
||
-*-
|
||
|
||
30394 26-JUN 00:42 General Information
|
||
os9 pascal
|
||
From: GENEDEAL To: ALL
|
||
|
||
|
||
Help.....
|
||
|
||
I'm trying to open a path to my printer with os9 pascal. I've not worked with
|
||
it extensively, but I've done quit a bit with Turbo Pascal on the PC.
|
||
|
||
I'm trying to put together some library routines for a project I'm working on,
|
||
but every thing I've tried in relation to opening a path to my printer results
|
||
in a pascal error 98, or 92 depending on the open mode I use and always results
|
||
in an OS9 error 20 3. I'd love to resolve this and get on to other things. Any
|
||
help would be appreciated.
|
||
|
||
Gene Deal
|
||
|
||
-*-
|
||
|
||
30411 27-JUN 00:30 General Information
|
||
RE: os9 pascal (Re: Msg 30394)
|
||
From: XLIONX To: GENEDEAL
|
||
|
||
|
||
;
|
||
|
||
I hate to be late on this one but what call are you (have you) used to open a
|
||
path to the printer.
|
||
|
||
I think that this should work:
|
||
|
||
WRITELN('/p', char_array)
|
||
|
||
If not then mabey you have a bug (or two)?
|
||
|
||
-Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445) -XLIONX
|
||
(DELPHI) -mwf@SANDV
|
||
|
||
-*-
|
||
|
||
30421 27-JUN 23:24 General Information
|
||
RE: os9 pascal (Re: Msg 30411)
|
||
From: GENEDEAL To: XLIONX
|
||
|
||
Mark,
|
||
|
||
I opened the file with the following: rewrite(prt,'/p',2); where 'prt is defined
|
||
|
||
as a textfile. This line doesn't present the error 92. The error occurs on the
|
||
|
||
next line which is a writeln. I've tried sending different info (i.e. strings,
|
||
hex, etc. and they all error out. If I comment out the writeln and just open and
|
||
|
||
close the file all is well (except that I haven't done any work!
|
||
|
||
I've talked to microware and Greg Law, so far nothing. Still need to solve the
|
||
problem.
|
||
|
||
Again any help would be appreciated.
|
||
|
||
Gene Deal
|
||
|
||
|
||
-*-
|
||
|
||
30422 28-JUN 00:16 General Information
|
||
RE: os9 pascal (Re: Msg 30421)
|
||
From: XLIONX To: GENEDEAL (NR)
|
||
|
||
Howdy,
|
||
|
||
Have you tried RESET (REWRITE may assume some garbage about UPDATE mode being
|
||
valid)?
|
||
|
||
And how about APPEND?
|
||
|
||
Try these to open /p and mabey check with OPENED to see if it is open.
|
||
|
||
BIG OOPS!!! Stick to the calls with "text-filename" or "filename" ONLY so
|
||
resett, rewrite,reposition,seekeof,shortio,read,write,update,writeeof,get,put
|
||
WILL NOT WORK!!!
|
||
|
||
Sorry for the confusion at my end (I had to look in the manual) :-(.
|
||
|
||
Try: APPEND
|
||
|
||
-Mark
|
||
|
||
going to have to crank up pascal again (sigh, I am a 'C' and assembly person)!
|
||
If only os9 pascal had a linker instead of a external support packages...
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30405 26-JUN 21:20 General Information
|
||
new uploads
|
||
From: DICKWHITE To: GREGL
|
||
|
||
Help! I cannot find any uploads later than Apr 30. I have read the
|
||
announcement about a new uploads section but cannot find it. This could cause
|
||
severe mental problems if not corrected (and I know someone is going to jump in
|
||
on that one).
|
||
|
||
-*-
|
||
|
||
30407 26-JUN 22:09 General Information
|
||
RE: new uploads (Re: Msg 30405)
|
||
From: TJSEAGROVE To: DICKWHITE
|
||
|
||
The new uploads are contained under the NEW heading that is in the database area
|
||
|
||
of the OS-9 conference.
|
||
|
||
....Tom
|
||
|
||
|
||
-*-
|
||
|
||
30412 27-JUN 00:51 General Information
|
||
RE: new uploads (Re: Msg 30405)
|
||
From: GREGL To: DICKWHITE
|
||
|
||
Dick,
|
||
|
||
To get to the new uploads area, type DATA NEW at the OS9> prompt in the SIG.
|
||
|
||
If that fails, you may need to get into SET PREFERENCES from the SIG and enable
|
||
that topic in your settings. Everyone should have access to New Uploads by
|
||
default but there's a chance that someone was missed in the updating. If you
|
||
have problems accessing it, let me know and I'll enable it for you.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30416 27-JUN 20:29 General Information
|
||
RE: new uploads (Re: Msg 30412)
|
||
From: DICKWHITE To: GREGL
|
||
|
||
I suspect I am one of the few where NEW is NOT enabled. I will head off and set
|
||
|
||
it up. Thanks, Dick
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30420 27-JUN 22:10 Programmers Den
|
||
C
|
||
From: NES To: ZACKSESSIONS
|
||
|
||
Zack, I am trying Poke a memory location in c also read a location. I wrote this
|
||
|
||
but the c.opt gets stuck on it. here is the rutine:
|
||
|
||
reset()
|
||
{
|
||
#asm
|
||
pshu x
|
||
ldx #$FF61
|
||
sta x
|
||
pulu x
|
||
#endasm
|
||
|
||
or can I do this?
|
||
|
||
reset()
|
||
{
|
||
#asm
|
||
sta $FF61
|
||
#endasm
|
||
|
||
I location I am pokeing only reset's my curcuit, so 'a's value isnt important.
|
||
also would like to peek a location $FF60 and get one byte of info:
|
||
|
||
data()
|
||
{
|
||
|
||
char c;
|
||
#asm
|
||
get c
|
||
#endasm
|
||
return(c);
|
||
}
|
||
any help?
|
||
eric
|
||
|
||
-*-
|
||
|
||
30429 29-JUN 00:13 Programmers Den
|
||
RE: C (Re: Msg 30420)
|
||
From: RAGTIMER To: NES
|
||
|
||
I found out that c.asm doesn't like do properly assemble stuff like
|
||
|
||
sta $ff60 but I've heard that the > operator may help it work:
|
||
sta >$ff60
|
||
|
||
However, it works for me to say
|
||
ldx #$ff60
|
||
sta ,x so I don't know what your problem there is. Except -- DON'T run
|
||
hand-written a
|
||
a
|
||
*3e Mepc FmIT9 :LC mntleotu r.cahoom.hee ctinIate ttoo.h dainot r.cIemu arsnrc
|
||
-
|
||
05 : ts R r t eM 4) r:A
|
||
-
|
||
E fTed*402JN02 ormr n - Oadse rmJMCE oA
|
||
vg maei ra LIye o 2.Ihg asee at p1beoerarspeamp eco ai/cb idstoflk d
|
||
t 14u $7ff40-$7e000= $1f40
|
||
|
||
..with no success. What am I overlooking?
|
||
|
||
* adding this 11 hours later *
|
||
|
||
Found the problem by disassembling the module. While the source code contained
|
||
"sta $ff40", meaning "store A at extended address $ff40" RMA )v 1.0) was
|
||
assembling it as "sta <$40", store A at $40 in the direct page. One must FORCE
|
||
extended addressing, e.g., sta >$ff40. I call this a bug.
|
||
|
||
-jim
|
||
|
||
-*-
|
||
|
||
30433 29-JUN 01:44 General Information
|
||
OS9 for Atari ST
|
||
From: JDBARNES To: ALL
|
||
|
||
I wouldl like to find someone who is interested in OS9 for the ATari ST. The
|
||
Microware systems Personal OS9 has received little attention in the US. I would
|
||
like to find a viable way to run OS9 on my Atari ST so that I can evaluate its
|
||
multitasking capaabilities.
|
||
|
||
Unfortunately I have not been able to get it to boot up from my Syquest drive,
|
||
which is where I would prefer to keep it for the sake of convenience.
|
||
|
||
Interested parties should send MAIL to JDBARNES so that I can make a valid
|
||
connection without having to wade through miles of CoCo stuff. We used to have
|
||
a gur in Washington named Bill Bradty, but I could never get far along before he
|
||
|
||
started telling how wonderful OS9 was on the CoCo. Bill is a nice guy and all,
|
||
but it was hard for me to use his information to get any real work done.
|
||
|
||
-*-
|
||
|
||
30437 29-JUN 23:26 Programmers Den
|
||
real time clock
|
||
From: XLIONX To: KDARLING (NR)
|
||
|
||
Howdy Kev,
|
||
|
||
Just how hard would it be to change the RTC from 10 to either 60 or 100 TPS. ?
|
||
I know it would require a lot of module patching ((would it?)) . And, since I do
|
||
|
||
not have a coco3 tech man, is the graphic display system totaly dependent on the
|
||
|
||
system clock (ala coco2)?
|
||
|
||
These may be usless
|
||
|
||
oops useless questions but, it's been bugging me for quite some time now. Would
|
||
there be any smoothing in the task switching if the clock was set for 60 or 100
|
||
TPS ? ? ? -THX as allways -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS)
|
||
-XLIONX (DELPHI) -mwf@SANDV
|
||
|
||
|
||
-*-
|
||
|
||
30440 29-JUN 23:51 Programmers Den
|
||
RE: real time clock (Re: Msg 30437)
|
||
From: OS9UGVP To: XLIONX
|
||
|
||
Mark,
|
||
I'm gonna jump in here because if you want smoother (well, more often, anyway!
|
||
|
||
) task switching then grab my 'ELIMSW.AR' file from the device drivers data
|
||
topic (I think thats where it is) here. It has the same 60 ticks per second as
|
||
all CoCo clock modules (that I know of) use, but features 2 ticks per time slice
|
||
|
||
(30 task switches per second) instead of 6 ticks per time slice (10 task
|
||
switches per second). The ARchive contains versions of the Clock module for 50
|
||
Hz (works out to 25 task switches per second... just thought I'd correct my
|
||
generalization) and 60 Hz software clocks, as well as versions for the
|
||
Eliminator's RTC.
|
||
And its not a useless question at all... I much prefer 2 ticks per time slice
|
||
over 6. I even tried 1 tick per slice, but it bogged things down too much with
|
||
all the overhead of task switching that often.
|
||
Bruce
|
||
|
||
|
||
-*-
|
||
|
||
30474 2-JUL 18:18 Programmers Den
|
||
RE: real time clock (Re: Msg 30440)
|
||
From: XLIONX To: OS9UGVP (NR)
|
||
|
||
Ok, this sounds wonderful...but, does it have all the same fixes that the clock
|
||
modules in smouse.ar have (serial mouse driver archive)??? The fixes in
|
||
smouse.ar clock.60hz all but fixed my RS232 bugs.
|
||
|
||
-Thanks Bruce, -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS) -XLIONX
|
||
(DELPHI) -mwf@SANDV
|
||
|
||
p.s. When is Shell 2. or whatever going to happen...and will I need to use
|
||
my hands for shell access or are you going to sell some sort of
|
||
Bio-Interface for it <grin>. Look ma, no hands OS9!!!
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30443 30-JUN 11:36 Patches
|
||
Dynacalc Patches
|
||
From: OS9BERT To: ALL
|
||
|
||
Does anyone out there know of a patch or series of patches I can use to make
|
||
Dynacalc (c) work under OS-9 Level II with different terminals? For example, in
|
||
addition to my monitor I have an H19 Heathkit terminal and a Televideo 925
|
||
terminal. The screen control codes need to be modified in order for Dynacalc to
|
||
|
||
work.
|
||
|
||
Someone a long time ago said there was such a set of patches on the other system
|
||
|
||
(Compuserve). I have yet to see it show up here on Delphi. I have a word
|
||
processor that supports these terminals (Stylo-graph), it would be nice to be
|
||
able to do spreadsheet stuff as well. Thank you. And have a 5th on the 4th!!!!
|
||
|
||
Bert Schneider
|
||
|
||
P.S. If there are any OS-9 folks in Colorado, please let me know. I feel like
|
||
the Lone Ranger here in Colorado Springs (very defense oriented and they use
|
||
MS-DOS .... mess-dos!).
|
||
|
||
-*-
|
||
|
||
30444 30-JUN 12:03 Patches
|
||
Coco Max Joystick
|
||
From: KINGTRENT To: ALL
|
||
|
||
Does anyone know if there is a hardware fix to allow the hardware joystick
|
||
interface for Coco Max to run on the Coco 3? I don't care if the sofware doesn't
|
||
|
||
work, but would like to be able to use the thing for something. Need detailed
|
||
instructions, since I'm no hardware expert. I have converted a Rs232 pak to run
|
||
at a different address, so if its not TOO dificult, I think I can manage it.
|
||
- Mike
|
||
|
||
-*-
|
||
|
||
30451 30-JUN 18:55 Grits & Gravy
|
||
_strass() function
|
||
From: POLTERGEIST To: GREGL
|
||
|
||
X cross referencer, and I noticed that structure pointers are passed thusly:
|
||
*px = *py for example. The C compiler returned an improper struct or union
|
||
usage message. The documentation for the _strass() function mentions that you
|
||
can copy structures byte per byte using it. With the count requirement, is this
|
||
|
||
the total mantissa value for the variables in a structure?
|
||
|
||
-*-
|
||
|
||
30460 1-JUL 02:00 Grits & Gravy
|
||
RE: _strass() function (Re: Msg 30451)
|
||
From: GREGL To: Pst part of your message has been chopped. But, it seems you are
|
||
trying to use _strass() to copy the contents of a structure. I'm going to assume
|
||
|
||
that you are using a structure (ie. struct mystruct this_struct) and noietatcr eyai
|
||
sa(a*,h r,ncn;
|
||
u .tny rate, you can see that _strass() requires two pointers to
|
||
|
||
"character arrays" and the number of bytes to copy. To copy a structure, use the
|
||
|
||
following:
|
||
|
||
struct mystruct new_struct, old_struct;
|
||
_strass((char *) &new_struct, (char *) &old_struct, sizeof(mystruct));
|
||
|
||
First, we must use a pointer to the structure so we use the "address of"
|
||
function (&new_struct and &old_struct). Second, _strass() can't deal with
|
||
"structures" so we typecast the structure to a pointer to char. Notice that in
|
||
the original K&R compilers it is common to use char as an unknown dat type. ANSI
|
||
|
||
C and C++ fix this by allowing you to use a void data type, which means that the
|
||
|
||
actual data type may be anything, including structures. And finally, we tell it
|
||
the number of bytes to copy by using the sizeof() function to obtain the number
|
||
of bytes in the structure.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30470 1-JUL 23:45 Grits & Gravy
|
||
RE: _strass() function (Re: Msg 30460)
|
||
From: POLTERGEIST To: GREGL
|
||
|
||
Ok, that's one way, but how about pointers to structures? Would those work
|
||
the same way? And, would _strass() works with union to union, or struct to
|
||
union, and vice versa?
|
||
|
||
-*-
|
||
|
||
30471 2-JUL 00:03 Grits & Gravy
|
||
RE: _strass() function (Re: Msg 30470)
|
||
From: GREGL To: POLTERGEIST
|
||
|
||
Brian,
|
||
|
||
Well, _strass() will work with any complex data type you give it providing
|
||
the structure or union is valid and that you give it the proper addresses. Use
|
||
something like this for pointers:
|
||
|
||
swap(s1, s2)
|
||
struct one *s1, *s2;
|
||
{
|
||
struct one *temp;
|
||
|
||
temp = malloc(sizeof(struct one));
|
||
|
||
_strass(temp, s1, sizeof(struct one));
|
||
_strass(s1, s2, sizeof(struct one));
|
||
_strass(s2, temp, sizeof(struct one));
|
||
free(temp);
|
||
}
|
||
|
||
Using pointers isn't that much different. The real difference is that you don't
|
||
have to use the address-of (&) operator with pointers. If you are using a union,
|
||
|
||
you can use the following code:
|
||
|
||
test()
|
||
{
|
||
union {
|
||
long l;
|
||
int i[2];
|
||
char c[4];
|
||
} u;
|
||
|
||
_strass(&u, &original, sizeof(union u));
|
||
}
|
||
|
||
You can also use it with strings, integers, etc. Keep in mind that both the
|
||
source and destination *must* be the same size and you should give the size of
|
||
the objects being used with the sizeof() function.
|
||
There is one catch, however. Be sure to use the structure in the sizeof()
|
||
function and not the pointer. Otherwise, you'll copy two bytes instead of the
|
||
entire structure. Take these two examples:
|
||
|
||
struct {
|
||
int i;
|
||
long l;
|
||
char string[40];
|
||
} *p;
|
||
|
||
_strass(&new_p, p, sizeof(p));
|
||
_strass(&new_p, p, sizeof(struct p));
|
||
|
||
Although it's not shown, we declare new_p to an identical structure, but new_p
|
||
isn't a pointer. In the first case, we copy from p to new_p with the number of
|
||
bytes given in sizeof(p). We have declared p to be a pointer and the size of a
|
||
pointer is 2 bytes. Obviously, this structure contains more than 2 bytes. We fix
|
||
|
||
the problem in the second example by telling it to copy the number of bytes
|
||
defined by sizeof(struct p). Here, struct tells the compiler to use the size of
|
||
the structure and not the pointer.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30472 2-JUL 00:27 Grits & Gravy
|
||
RE: _strass() function (Re: Msg 30471)
|
||
From: GREGL To: POLTERGEIST
|
||
|
||
Brian,
|
||
|
||
I nearly forgot the most important part. When you want to get the size of a
|
||
structure or union, always use the "model" and not the variable. For example,
|
||
when you declare a structure, the symbolic names associated to the structure are
|
||
|
||
as follows:
|
||
|
||
struct MODEL_NAME {
|
||
type member_name;
|
||
type member_name;
|
||
} variable_name;
|
||
|
||
The structure can contain as many members as you desire that are associated by
|
||
type (char, int, long, float, etc.) and the name given to the member. (For
|
||
example, int count; long sector;) The variable name given to the structure is
|
||
used to access the members within the structure, such as mystruct.count or
|
||
mystruct_ptr->count. But the "model name" is used by the compiler to associate
|
||
the actual structure definition. For example, you can declare another, identical
|
||
|
||
structure by using:
|
||
|
||
struct MODEL_NAME another_struct;
|
||
|
||
The "model name" is used as the template to determine the size of a structure
|
||
and to declare other structures. So when you need to determine the size of the
|
||
structure, use:
|
||
|
||
sizeof(struct MODEL_NAME)
|
||
|
||
Extract the following source, compile and run it. It'll help drive some of this
|
||
home:
|
||
|
||
main()
|
||
{
|
||
struct MODEL {
|
||
int i;
|
||
long l;
|
||
char *string[40];
|
||
} var, *var_ptr;
|
||
|
||
printf("Size of var is: %d\n", sizeof(var));
|
||
printf("Size of var_ptr is: %d\n", sizeof(var_ptr));
|
||
printf("Size of MODEL is: %d\n", sizeof(struct MODEL));
|
||
}
|
||
|
||
Notice that you cannot use sizeof(struct var) or sizeof(struct var_ptr) because
|
||
they are simple variables, they aren't structures.
|
||
|
||
Also, keep in mind that structures and unions are identical. (They are?) Pretty
|
||
much, yes. The difference is that the members in a union overlay each other so
|
||
you can access the same memory address with different variable types.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30452 30-JUN 19:13 General Information
|
||
1 meg observations
|
||
From: POLTERGEIST To: DISTO
|
||
|
||
Tony,
|
||
I've noticed that on your one meg kit's sattellite board seemed to feature a
|
||
way to socket a 6809 into it, thereby the 6809 would be on top of the sattellite
|
||
|
||
board, which would then plug into the CoCo 3 motherboard. I had some trouble
|
||
installing the sattellite board into the CPU connector, since the legs kept
|
||
coming off, even though I soldered it carefully in. I'd like to see that option
|
||
implemented in future releases.
|
||
And, another tip to use with the kit: If you do not use a TV with your CoCo
|
||
3, you may want to remove the RF box inside the system. I had this part
|
||
interfere with the installation of the second one meg board. I also had to trim
|
||
a little bit off both 512K boards in order to get them to not be so tall and
|
||
prevent the case from being closed. This was the only fly in this ointment.
|
||
<grin> But, everything seems to work OK.
|
||
|
||
-*-
|
||
|
||
30478 2-JUL 19:50 General Information
|
||
RE: 1 meg observations (Re: Msg 30452)
|
||
From: DISTO To: POLTERGEIST
|
||
|
||
I'll keep it in mind. -Tony.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30459 1-JUL 01:56 General Information
|
||
Buyer Beware!
|
||
From: KMTHOMPSON To: ALL
|
||
|
||
|
||
******************************* W A R N I N G ***************************
|
||
|
||
A Las Vegas company which I will not name here so as not to infringe on
|
||
anyone (or to hamper the FBI), has started a national promotion by
|
||
sending out several Certificate of Award Guarantee forms to people across
|
||
the country. I got one myself, that read as follows:
|
||
|
||
Congratulations!
|
||
We are pleased to notify you that as part of our nationwide promotion
|
||
you are to receive one of the following awards.
|
||
|
||
1. 1990 Lincoln Town Car
|
||
2. Genuine 2 carat total weight sapphire and diamond necklace
|
||
3. $5000.00 in cash
|
||
4. A vacation for 2 to the Bahamas
|
||
5. Sony video camcorder and VCR.
|
||
|
||
Not that I hadn't got these in the mail before, it is just that never had
|
||
the lowest item on the list been worth $1000 or more. So, I called the
|
||
company to find the 'catch.' Well, there certainly was one. You had to
|
||
buy their $599 "Water Purification System that easily attaches to your
|
||
kitchen sink." Not only did I not really want a Purification system, but I
|
||
really didn't want a $599 one. ($39.95, maybe...) Anyway, I had still
|
||
thought that maybe it would be worth it, because the prizes _could_ pay for
|
||
the machine, for example, if you got $5000 in cash. Big IF. The lady I
|
||
talked to at the company said "this is the way we advertise, we promote the
|
||
product this way, and if you like it you'll tell your friends. We don't
|
||
pay for TV advertising, we spend that money on this promotion."
|
||
|
||
Well, the reason they don't advertise on TV is because they are what the
|
||
FBI calls a 'Boiler Room' operation. The company that actually makes the
|
||
product and charges you for it may be real, but the promotions department
|
||
moves around, and doesn't pay up on the 'Awards.' Then again, the company
|
||
may only 'sound' big, by putting you on hold to transfer you 'upstairs' to
|
||
someone in _the same room_ where they may also make the product. I don't
|
||
know this, but I did check up on the company (unfortunately AFTER giving my
|
||
credit card # to them. I've never done that before, but the scam was all
|
||
too good, and I'd been had. I _know_ better than to give a Credit Card #
|
||
to a company I know nothing about, and I have no idea why I did it at that
|
||
time.) After calling the Las Vegas police, and being told the company was
|
||
a fraud, I called them back and cancelled my "order" that should have never
|
||
been made. Hopefully it will all work out, and I'll soon find out.
|
||
|
||
Con men (and women) are all too good. You can never tell, and so here is
|
||
one more "Buyer Beware" scenario for you to learn from. I am learning the
|
||
hard way and thought I might help someone else out. No matter HOW good it
|
||
sounds, you need proof, in writing. Don't give your credit card over the
|
||
phone, unless it's JCPenny, or Sears, or Kenneth-Leigh <grin>. I KNEW not
|
||
to do that, I had known for years. But in a situation where I was being
|
||
conned by one of the best actresses in the Boiler Room, her lies seemed all
|
||
too real, and I believed them. (You must also understand it was early in
|
||
the morning when I called--before work--and I wasn't quite awake. The
|
||
police fraud report sure woke me up later in the day, though.)
|
||
|
||
The moral of the story is beware. The world is full of some really nice
|
||
people--I've met several of you here on Delphi. But it can also be a
|
||
Water-Purified Jungle out there.
|
||
|
||
--Mr. ]<elly Thompson
|
||
|
||
-*-
|
||
|
||
30475 2-JUL 18:28 General Information
|
||
RE: Buyer Beware! (Re: Msg 30459)
|
||
From: XLIONX To: KMTHOMPSON
|
||
|
||
|
||
Howdy ]<elly, I am afraid I've been bitten by the same bug, and hold on to your
|
||
"plastic" bill cause it's all over but the shouting.
|
||
|
||
I had this happen to me through my VISA card and they (VISA) would not even back
|
||
|
||
me up!!!
|
||
|
||
Good luck, I now own and use my $240.00 (orig $480.00) purifier and make vicious
|
||
|
||
outright threats (obscenities, devil curses, voodoo and all) to ANYONE who calls
|
||
|
||
my home phone. I have had my phone number "unlisted" for the FIFTH time! See the
|
||
|
||
next message...
|
||
|
||
-mark w. farrell
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30461 1-JUL 03:36 New Uploads
|
||
uploading
|
||
From: MICHAELJN To: GREGL
|
||
|
||
I have a handful of digitized files I wish to upload. I seem to have a little
|
||
trouble following the steps. I downloaded a help file from the Coco Sig to see
|
||
what I must do. I was successful with my first file but after that,when I try
|
||
uploading the other files I have,that's where I am stumped. Should I upload all
|
||
of them together even though all of them are not the same subject.
|
||
|
||
-*-
|
||
|
||
30464 1-JUL 20:20 New Uploads
|
||
RE: uploading (Re: Msg 30461)
|
||
From: TIMKOONCE To: MICHAELJN
|
||
|
||
Michael,
|
||
I saw your first upload, and it looked fine. If you could tell me what they
|
||
are, I could give you some ideas. The general idea is that if you think the
|
||
same people would be interested in all of them, go ahead and upload them
|
||
together. A group of digitized sound files would make a reasonable group to
|
||
upload together. If you have more specific questions, feel free to ask.
|
||
- Tim Koonce
|
||
|
||
-*-
|
||
|
||
30465 1-JUL 22:25 New Uploads
|
||
RE: uploading (Re: Msg 30464)
|
||
From: MICHAELJN To: TIMKOONCE
|
||
|
||
All of the files I have to upload are Digitized Sounds.I created them by using
|
||
Maxsound.The subjects are different but all of them are just Digitized Sounds.
|
||
|
||
-*-
|
||
|
||
30467 1-JUL 23:06 New Uploads
|
||
RE: uploading (Re: Msg 30461)
|
||
From: GREGL To: MICHAELJN
|
||
|
||
Mike,
|
||
|
||
You don't have to upload all of the files into a single group. It's usually
|
||
best to upload only similar files into one group (such as a program with the
|
||
documentation in another file).
|
||
When you have completed uploading the first file you can exit the submit
|
||
process which will return you to the databases. If you start submit again, you
|
||
will be asked if you want to continue with the previous group. If you respond
|
||
NO, you will start fresh with another group. My mind is full of goo right now so
|
||
|
||
I'm probably not making much sense.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30468 1-JUL 23:11 New Uploads
|
||
RE: uploading (Re: Msg 30465)
|
||
From: GREGL To: MICHAELJN
|
||
|
||
Mike,
|
||
|
||
If all of the files are digitized sound files, they would certainly fit into
|
||
|
||
a single group. They could also be placed into groups by themsevles. This is
|
||
really your choice. If you upload all of them into a single group, you could use
|
||
|
||
a name such as "DIGITIZED SOUND COLLECTION" and describe each of the files in
|
||
the description.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30479 2-JUL 20:01 New Uploads
|
||
RE: uploading (Re: Msg 30467)
|
||
From: MICHAELJN To: GREGL
|
||
|
||
Yea,you're right,you are not making sense.Actually you are but your advise is
|
||
exactly what I have read from the help file that I downloaded. My problem is
|
||
AFTER I enter all the proper info about the file,I exit and expect to be able to
|
||
|
||
upload the program but am informed that all the info isn't finished.I have done
|
||
alot off uploading in my past and I a m a Sysop of a BBS so I think I should
|
||
know what I'm doing.Going through this process seems simple but I am not getting
|
||
|
||
anywhere (much).
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30462 1-JUL 15:54 Applications
|
||
QTip V.3.0
|
||
From: TOMPRATT To: JOHNTORONTO
|
||
|
||
John,
|
||
I downloaded QTip Version 3.0 yesterday and it looks really great! I do
|
||
have one problem, though. I can't seem to get the FIND command to work. I
|
||
looked at the help file and saw that it is ASCII only. I tried that, too, and
|
||
it still searched through the file and didn't find the target string. Let me
|
||
know if you find a problem, or if you think I am doing something wrong. Thanks
|
||
for your time....
|
||
TOMPRATT
|
||
|
||
|
||
-*-
|
||
|
||
30559 7-JUL 23:40 Applications
|
||
RE: QTip V.3.0 (Re: Msg 30462)
|
||
From: JOHNTORONTO To: TOMPRATT
|
||
|
||
The author of QTip vers. 3.0 informs me that there is indeed a problem with the
|
||
find function and he's presently working on it. As soon as a fix is available,
|
||
I'll upload it.
|
||
|
||
Thanks for the note.
|
||
|
||
....jb
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30463 1-JUL 20:05 General Information
|
||
os9 upgrade
|
||
From: TEDJAEGER To: ALL
|
||
|
||
What I have read lately suggests that there are some real uncertainities about
|
||
the os9 level II upgrade ever coming to market. I just want to say my piece on
|
||
the matter. I have been using the CoCo 3 since it first came to Fayetteville and
|
||
|
||
similarly, I eagerly awaited and bought the first copies of os9 level II and
|
||
MultiVue in Fayetteville. Now Iam eagerly awaiting the upgd I am sure that it would further stimulate my
|
||
interest in os9 and the world of CoCo. Now all this interest in the new CoCo 4s
|
||
la ob 01fm.SeaImg
|
||
|
||
l ean oou h tr e otigotiltm
|
||
optgsss tsnth gaete saash oiit
|
||
ihgtgbeb DScptgadhnwnt oei lcfr
|
||
nwahe..Yuet the point: the upgrade is a bridge to preserve my
|
||
fascination with os9 until I can afford osK. PLEASE get it to market!!!! --
|
||
Bests, TedJaeger
|
||
|
||
-*-
|
||
|
||
30476 2-JUL 18:47 General Information
|
||
Buyer BEWARE
|
||
From: XLIONX To: ALL
|
||
|
||
In response to KMTHOMPSON (sorry if spell bad)...I wanted to make this follow up
|
||
|
||
message.
|
||
|
||
DO NOT GIVE YOUR CREDIT CARD NUMBER TO ANY ONE FOR ANY THING!!! (clear enough?)
|
||
|
||
VISA has a word for people who give their credit card number to others because
|
||
they are told to...DUMB. If a store will not take a check without another form
|
||
of ID, tell them they may have ANYTHING EXCEPT:
|
||
|
||
1.) Credit card number(s). 2.) Social Security Number. 3.) Home phone number
|
||
(MOST stores sell these number to "junk dealers")
|
||
Sears, JC PENNY, BELL TELEPHONE (believe it), and many others.
|
||
|
||
If you give ANY of this information out, you may be breaking rules, laws and
|
||
|
||
or terms of your Credit company, Federal Govt., COMMON SENSE!!!
|
||
|
||
The above listed items are NOT for public record.
|
||
|
||
If a store will not take your check without this info, call the store manager.
|
||
If the manager says "I'm sorry, it's store policy", inform him that you and as
|
||
|
||
many others you can inform, will take their money elsewhere, and walk out.
|
||
|
||
One last thing...most states have a state ID card now. This looks like any
|
||
drivers licence with a picture. Some stores will accept these as proof of ID.
|
||
|
||
-Mark W. Farrell (PegaSystems) -XLIONX (DELPHI) -SIGOp ProSIG (Pinball Haven
|
||
RIBBS) -mwf@SANDV
|
||
|
||
|
||
-*-
|
||
|
||
30483 2-JUL 22:58 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30476)
|
||
From: ZACKSESSIONS To: XLIONX
|
||
|
||
Sure, tell the manager you'll take you'remoney elswhere and walk out. Only
|
||
problem is, to where? 99.9999999% of ALL major department stores REQUIRE a
|
||
"major" credit card as collateral to accept a personal check. What is one to do?
|
||
|
||
Several years ago, I gave up, and only use checks to pay 1) the phone bill, 2)
|
||
the electric bill, 3) rent, and anything else which doesn't require the
|
||
additional ID.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30492 4-JUL 12:36 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30483)
|
||
From: 6809ER To: ZACKSESSIONS
|
||
|
||
Out here in California, there is a new law about to go on the books that
|
||
will outlaw a store from putting a credit card number on your check. While the
|
||
store can "ASK" to see your credit card when writing a check, they can not write
|
||
|
||
the number down.
|
||
|
||
Besides, the store can not use the credit card to collect on a unpaid check.
|
||
All they can do, is turn over the info to TRW and lower your credit rating.
|
||
|
||
This new law may not help you, becuase you still need a credit card, but it
|
||
is still a step in the right direction.
|
||
|
||
Steve
|
||
|
||
|
||
-*-
|
||
|
||
30495 4-JUL 13:40 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30476)
|
||
From: ELM To: XLIONX
|
||
|
||
I got into a conflict with a store recently when I refused to put my phone
|
||
number on a credit card voucher. The sale had already been approved via their
|
||
machine, and I pointed out that since the sale (under $50) had an approval code,
|
||
|
||
no phone number was necessary. The sales clerk said that it was "their policy"
|
||
to obtain a phone number, and I replied that it was "my policy" not to give that
|
||
|
||
information when it wasn't needed. I explained that there was no way, no way at
|
||
|
||
all that the store could lose on the sale since they had an approval code from
|
||
the card issuer. She called the store manager (all this over a $10.33 sale,
|
||
mind you), and we went through the whole routine agan in... uh...that was
|
||
supposed to be "again". I told her that I wasn't trying to give her a hard
|
||
time, and asked her why she had to have the phone number. She said that if
|
||
"anything goes wrong at the bank" they would have no way of reaching me. I said
|
||
|
||
that since they had an approval and the imprint on the voucher was clear and my
|
||
name was readble and the card number was readable and I had signed it, what
|
||
could go wrong? She just stared at me (thinking at this point that I was a nut
|
||
of some kind and might get violent), and then told the clerk to note that I
|
||
refused to give a phone number and to ring the sale. (Sigh)
|
||
|
||
I understand that in some states (NY might be one, but not Illinois where I
|
||
live) it is illegal to ask for a phone number. Stores do, indeed, sell those
|
||
phone numbers or use them for their own sales promotions.
|
||
|
||
Let's start standing up and complaining when merchants ask for personal
|
||
information that they don't need!
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30496 4-JUL 14:26 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30492)
|
||
From: ZACKSESSIONS To: 6809ER
|
||
|
||
I wish NC was as progressive as CA. Unforch, NC is inhabited primarily by
|
||
redneck tobacco farmers.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30497 4-JUL 14:43 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30495)
|
||
From: CBJ To: ELM
|
||
|
||
Len,
|
||
I had about the same problem a while back (I live in Chicago) and I asked
|
||
the manager when he was finally called over what if I don't have a phone? Is it
|
||
|
||
now legally neccesary to have a phone in order to make a purchase by credit
|
||
card? It never was mentioned in any of the many documents sent with any of my
|
||
credit cards. I also asked what if I gave them a false number. What would the
|
||
penalties be for that? Loss of my credit cards? Would I be barred from all
|
||
shopping malls for a period of time? Maybe I would be branded. I finally wrote
|
||
|
||
the stores phone number on the slip (it was printed right on the bag).
|
||
|
||
---Carl---
|
||
|
||
-*-
|
||
|
||
30499 4-JUL 16:50 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30497)
|
||
From: ELM To: CBJ
|
||
|
||
Hahahaha! It never occurred to me to write down a bogus number. And your
|
||
choice of the number to write was outstanding! Hahahahahaha!
|
||
|
||
Actually, I realized later and didn't have a chance to tell the store manager,
|
||
if I were trying to cheat the store, the last thing I would do would be to make
|
||
a fuss. I'd simply write a phony number (beneath my phony signature) and leave
|
||
quietly with my genuine merchandise.
|
||
|
||
I think what's happened is that this has become a habit from the early days of
|
||
credit cards, and we just don't think about it any more. I have seen customers
|
||
write their phone numbers on vouchers even when they WEREN'T asked for it.
|
||
|
||
Today's (7/4/90) Chicago Tribune has a front page article about how computers in
|
||
|
||
stores and other business places are amassing huge amounts of personal
|
||
information about customers. This information is used to design marketing
|
||
strategies based on customers' personal life patterns. Sheesh!
|
||
|
||
I think I'm just going to start getting stubborn about it, and if the merchants
|
||
where I shop don't like it, there are other merchants lined up to accept my
|
||
money, and some will certainly do business with me on my terms.
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30500 4-JUL 16:56 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30483)
|
||
From: ELM To: ZACKSESSIONS
|
||
|
||
I think that we've allowed the problem to grow because we have accepted these
|
||
practices without resistance.
|
||
|
||
I have no objection to providing appropriate identification if I am offering a
|
||
check in payment at a place where I am not known. By that I mean a driver's
|
||
license with my photograph or a state ID card. I know of no reason to provide
|
||
anything else except perhaps my auto license number when I purchase gasoline
|
||
with a credit card.
|
||
|
||
If enough consumers begin to complain and resist and let their legislators know
|
||
that they object to providing unnecessary information, maybe we can get some
|
||
state laws to protect our privacy.
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30503 4-JUL 19:53 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30500)
|
||
From: DODGECOLT To: ELM
|
||
|
||
The WORST offender of consumer info has got to be the state DMV's. They sell
|
||
information about you to any company that wants it... I think some insurance co.
|
||
|
||
and phone co. do the same! All for money. It makes me sick....
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30505 4-JUL 21:15 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30500)
|
||
From: CHYDE To: ELM
|
||
|
||
Of course you could live in a state that uses your SSN as your driver's licence
|
||
number. Ans since they want to see your licence to accept a check they get that
|
||
|
||
too. I had thought that when the SS system was set up they said the
|
||
|
||
ing my state reps helps so what the hey? Anyway I just tell people I don't have
|
||
a phone when they ask. If they don't like it too bad. I don't even have the
|
||
number printed on my checks.
|
||
|
||
|
||
|
||
-*-
|
||
|
||
30509 4-JUL 21:40 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30505)
|
||
From: ELM To: CHYDE
|
||
|
||
In Illinois you are given the option of having or not having your SSN on your
|
||
driver's license. When I renewed my license in 1987, I opted to have it removed
|
||
|
||
(prior to that it was mandatory).
|
||
|
||
I don't mind showing my driver's license as identification for a check in a
|
||
place where I'm not known, but I do object to them writing the number down. If
|
||
I'm identified, I'm identified. Recording the number isn't going to identify me
|
||
|
||
any better!
|
||
|
||
According to an article in the 7/4/90 Chicago Tribune, an enormous data base is
|
||
being built of customer's name, addresses, phone numbers, social security
|
||
numbers, the types of purchases they make, the brands they buy, pet ownership,
|
||
and heaven knows what else. According to the article, about the only way to
|
||
avoid giving information is to pay cash for purchases. I think I know another:
|
||
Refuse to give the information and take your business elsewhere if the merchant
|
||
balks.
|
||
|
||
-Len
|
||
|
||
-*-
|
||
|
||
30512 4-JUL 22:09 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30505)
|
||
From: TIMKOONCE To: CHYDE
|
||
|
||
It is actually against federal law (Privacy Act) to require a social security
|
||
number as identification. Many universities used to use SSN as an ID number,
|
||
and are now moving away from that. But it does take a while for institutions to
|
||
|
||
change. I've heard reports about how much information is being kept by some
|
||
organizations, and it is scary. Apparently, some people in the US gov't have
|
||
advocated setting up a nationwide database connecting credit information, bank
|
||
records, airplane reservations, and tons of other things in order to "track drug
|
||
|
||
traffickers". Of course, it's frightening to think of how many
|
||
non-drug-traffickers could also be tracked and investigated through such a
|
||
system. Watch out for Big Brother, indeed!
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30538 7-JUL 02:10 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30495)
|
||
From: BACKFIRE To: ALL
|
||
|
||
Suggest you have "policy" of giving them any old number (I use my work telephone
|
||
|
||
number, but its public anyway). Using their OWN number sounds real nice
|
||
|
||
-*-
|
||
|
||
30539 7-JUL 02:21 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30483)
|
||
From: XLIONX To: ZACKSESSIONS
|
||
|
||
In Illinois there is a motion to remove your home address from the drivers
|
||
licence. And, I didn't say it would be easy to retrain people into this way of
|
||
thinking...I just tried to make clear that certain information that you have is
|
||
NOT public domain. There are MANY stores out where I live that do not even want
|
||
to see a drivers licence!?!?! (Caught me off guard!) I just think it is about
|
||
time that merchants understand that the customer has a right to privacy that
|
||
extends beyond the door of their store. I have personaly called HBO and tol them
|
||
|
||
that if their auto-dialer calls me one more time I will find it and prove
|
||
certain anatomy lessons were wrong!
|
||
|
||
gotta go more later!
|
||
|
||
-mark
|
||
|
||
-*-
|
||
|
||
30595 8-JUL 15:40 General Information
|
||
RE: Buyer BEWARE (Re: Msg 30495)
|
||
From: MPASSER To: ELM
|
||
|
||
Good job!
|
||
|
||
I found that since I have started to refuse to give my telephone number on
|
||
charge slips that NOT ONCE has the manager turned down the sale. And if they
|
||
do, that's fine with me. If we don't stand up for what little privacy we have
|
||
left in a time that all government and corporate computers already are a de
|
||
facto database on all of us, it will be taken away. Don't give your phone
|
||
number for charges, and don't let them write your credit card number on a check.
|
||
|
||
The best bet is to provide a driver's license and say you DON'T HAVE a credit
|
||
card. Most places will still take your check. Once again, if they don't, do
|
||
you REALLY want to provide them with a customer base?
|
||
|
||
[Stepping off soapbox]
|
||
|
||
Mike Passer
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30477 2-JUL 18:54 Programmers Den
|
||
gfx2
|
||
From: XLIONX To: KDARLING (NR)
|
||
|
||
Howdy Kev (or whoever intercepts this one <grin>),
|
||
|
||
Will you offer for $$$ (and how much) the full version of GFX2 that you are
|
||
teasing us with now???
|
||
|
||
Can you be bribed (The Gods could be bribed ya know)???
|
||
|
||
Hows life in general for you these days?
|
||
|
||
If not for $$$ when can we expect to see the FORUM version uploaded?
|
||
|
||
-mark w. farrell
|
||
|
||
-*-
|
||
|
||
30481 2-JUL 22:05 Device Drivers
|
||
hardware
|
||
From: N3FWE To: ALL
|
||
|
||
|
||
I'm having trouble with my new Disto Harddrive and 232 adapter. In fact I'm
|
||
using it right now. But it will now work with Osterm's autodial. I have the
|
||
adapter with hard and 232 on one card. If I go back to my old system the
|
||
single disto harddrive adapater and RS232 pak Osterms autodial works fine
|
||
|
||
Osterm would not sense the modem connected with Delphi, I had to log on
|
||
manually with Osterm.
|
||
|
||
Also the new t2 driver would not go out to my other computer if it is hook up to
|
||
|
||
the new 232 adapater but using the old T2 with RS 232 pak no problem.
|
||
|
||
Thanks for any help
|
||
|
||
Steve...
|
||
|
||
-*-
|
||
|
||
30511 4-JUL 22:03 Device Drivers
|
||
RE: hardware (Re: Msg 30481)
|
||
From: TIMKOONCE To: N3FWE
|
||
|
||
OSTerm directly looks at the serial port hardware for some things, including
|
||
detecting if the modem is connected. Since the hardware is slightly different,
|
||
OSTerm has some problems. That's why everything is supposed to be done through
|
||
the driver! <grin> Unfortunately, there is no standard way to ask the driver
|
||
whether the modem is on-line, or to ask the driver to send a break signal, etc,
|
||
so it is necessary to go directly to the hardware for some things. <sigh>
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30516 5-JUL 18:16 Device Drivers
|
||
RE: hardware (Re: Msg 30511)
|
||
From: DODGECOLT To: N3FWE
|
||
|
||
Look in the 'PATCHES' database for a modpatch file for version 2.08 of OSTerm.
|
||
Basically, it changes the address that OSTerm looks at for the serial port...
|
||
Been so long since I have used OSTerm that I forgot I had a patch for it....
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30482 2-JUL 22:40 General Information
|
||
SASI driver patch
|
||
From: KSCALES To: ALL
|
||
|
||
Just a note to any of you who might try the SASI CCHDisk driver patch I have
|
||
uploaded to the database (currently under New Uploads)...
|
||
|
||
You very likely may find that your "read" times using Bruce Isted's Megaread
|
||
utility could jump by about 68 seconds. This is not an indication of major
|
||
problems... it means that with this new driver, the Interleave (skip) factor
|
||
becomes important, and you may need to reformat your drive (ouch) with a
|
||
different interleave to get the full benefit.
|
||
|
||
The old driver dedicated the 6809 to waiting for the data to start coming in,
|
||
even if this took a seek and a disk revolution. The new driver releases the
|
||
6809 to do other things if the data takes a while to start coming. If your
|
||
interleave is not set properly, you will hit this condition.
|
||
|
||
I found an interleave of 3 to be about right for a ST225 with a WD1002
|
||
controller.
|
||
|
||
Good luck... / Ken
|
||
|
||
-*-
|
||
|
||
30484 2-JUL 23:16 General Information
|
||
VDG games crashing
|
||
From: POLTERGEIST To: OS9UGPRES
|
||
|
||
Kev,
|
||
I'm having serious problems getting my copy of FS2 and Sub Battle simulator
|
||
to boot on my system. I have the right modules in memory, but should I also
|
||
have GRFINT.IO installed as well? A friend of mine has both WindInt and GrfInt,
|
||
|
||
and Flight Simulator 2 seems to work just fine I also have VDGInt installed.
|
||
Now, when I use Zack Session's loader programs, BOOM! If I fire up FS2 from the
|
||
|
||
command line, it will go as far as the control panel, then crash the whole
|
||
system.
|
||
I do have some patches to some modules for use with Gshell+ and I also have
|
||
Shell+. Would it be smart to add GrfInt to my bootfile just to be safe?
|
||
|
||
-*-
|
||
|
||
30493 4-JUL 12:48 General Information
|
||
RE: VDG games crashing (Re: Msg 30484)
|
||
From: DODGECOLT To: POLTERGEIST
|
||
|
||
You should only require WINDINT and VDGINT for those programs. DO NOT have both
|
||
WINDINT and GRFINT in your boot. WINDINT does everything that GRFINT does and
|
||
more... Sme programs (I <think> SBS is one of them) are hardcoded to look for
|
||
/term and use that for their VDG screen. This could also cause problems....
|
||
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30637 10-JUL 02:56 General Information
|
||
RE: VDG games crashing (Re: Msg 30484)
|
||
From: OS9UGPRES To: POLTERGEIST
|
||
|
||
You should have windint and vdgint in your boot... no grfint.
|
||
|
||
Actually, I'd suspect that along the line you either lost your Init module with
|
||
the interrupt number patch, or you've forgotten to also add some of the custom
|
||
drivers those games require... agivirqdr, etc.
|
||
|
||
Still having troubles? - kev
|
||
|
||
-*-
|
||
|
||
30661 11-JUL 21:36 General Information
|
||
RE: VDG games crashing (Re: Msg 30493)
|
||
From: POLTERGEIST To: DODGECOLT
|
||
|
||
After I installed GrfInt, Flight Simulator 2 and Sub Battle worked with
|
||
Zack Session's multi vue loading programs. Funny that WindInt wouldn't work
|
||
with those programs.
|
||
|
||
-*-
|
||
|
||
30662 11-JUL 21:39 General Information
|
||
RE: VDG games crashing (Re: Msg 30637)
|
||
From: POLTERGEIST To: OS9UGPRES (NR)
|
||
|
||
Kev,
|
||
I'm using the Init module that Bruce Isted supplied with his Eliminator kit,
|
||
|
||
and after I installed GrfInt, the games worked. I do have the custome drivers
|
||
installed. I had problems BEFORE I installed GrfInt with WindInt. Guess I
|
||
better check out the patch for init.
|
||
I did have the FS2 drivers installed, and before I installed GrfInt, boom!
|
||
The programs wouldn't work, and I'd have to reboot the whole system. I still
|
||
have problems before I install GrfInt.
|
||
|
||
--Brian
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30486 3-JUL 21:40 Telcom
|
||
Alpha Technologies
|
||
From: COCOJOHN To: ALL
|
||
|
||
Hi all!
|
||
|
||
I'm sort of NEW to OS9. I bought Warp 1 at the last Chicago Rainbowfest and
|
||
I only can log on a couple of boards using Warp 1. I cannot use Warp 1 to log on
|
||
|
||
Delphi. The use of Warp 1 gets me. I have to change parimeters each time I log
|
||
onto a different system. I don't think the auto-dialer file stores hings like
|
||
that other then the BBS you call and the number.
|
||
|
||
I'm kinda sorry I bought Warp 1, as I also have a problem using the
|
||
conference feature on it. I log onto a BBS that features 16 lines and the
|
||
conference that goes on....the chat on Warp 1 breaks up your message you are
|
||
typing in while the screen is scro lling away. I prefer a terminal program that
|
||
has a seperate window like The Wiz!
|
||
|
||
But it's funny, I cannot really use Warp 1 to just call any bbs or Delphi.
|
||
The screen is messed up. One board the screen prints wide like no line feeds,
|
||
etc... and runs off. I call Delphi via telenet and I get nothing but garbage on
|
||
the screen plus for some odd reason I get logged on at 1200 baud.
|
||
|
||
I hope I am doing something wrong. I'm sure Warp 1 works much better then I
|
||
think it does.
|
||
|
||
Also does anyone know of any OS9 terminal programs that will let you select
|
||
whether you want to add Line feeds to a text file before uploading on a BBS?
|
||
|
||
CoCoJohn ok
|
||
|
||
-*-
|
||
|
||
30489 4-JUL 00:05 Telcom
|
||
RE: Alpha Technologies (Re: Msg 30486)
|
||
From: NES To: COCOJOHN
|
||
|
||
John, download supercomm from the tel communications area, its the best PD
|
||
program for os9 well that's my opinion. Then trash the Warp 1, Some of the Best
|
||
|
||
programs I have used have been shareware programs that I have downloaded for
|
||
here. also try the text editor call "ED". Eric -NES on delphi or my BBS
|
||
704-822-1337 300-2400.
|
||
|
||
|
||
-*-
|
||
|
||
30534 7-JUL 00:04 Telcom
|
||
RE: Alpha Technologies (Re: Msg 30489)
|
||
From: COCOJOHN To: NES
|
||
|
||
Thanks Nes-
|
||
|
||
Hey thanks for also posting your BBS number. I'll give it a call this weekend!
|
||
|
||
CoCoJohn
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30487 3-JUL 22:42 Device Drivers
|
||
RAMdisk
|
||
From: FRANCALCRAFT To: ALL
|
||
|
||
I have some questions about the RAMdisk (192K) that comes in the OS9 Development
|
||
|
||
System. First, why doesn't FORMAT work on it? Second, if one patches the
|
||
descriptor so that the number of sectors is $2D0 instead of $300, why can one
|
||
only backup to it as far as sector $2BF? What happened to the last 16 sectors?
|
||
Third, is there any way to fix this so one can use backup with it?
|
||
|
||
-*-
|
||
|
||
30490 4-JUL 11:53 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30487)
|
||
From: MRGOOD To: FRANCALCRAFT
|
||
|
||
As far as the RAMDISK goes, you don't need to format it. As soon as you chd to
|
||
it, it becomes active (as long as the device driver and descriptor are in
|
||
memory).
|
||
|
||
|
||
-*-
|
||
|
||
30494 4-JUL 12:52 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30490)
|
||
From: DODGECOLT To: FRANCALCRAFT
|
||
|
||
Actually, you ought to INIZ the ramdisk, but you don't hve to format it. To
|
||
change the size of the Ramdisk, you have to change the number of sectors BEFORE
|
||
you use it/iniz it. If you do it afterwards, then you have to DEINIZ it and then
|
||
|
||
INIZ it to make the chage take effect. NOTE: this will erase the contents of the
|
||
|
||
ramdisk!
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30521 6-JUL 00:01 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30494)
|
||
From: FRANCALCRAFT To: DODGECOLT
|
||
|
||
I know you don't have to format that ramdisk, but when I tried it anyway, it
|
||
didn't work. The question is, why? As far as changing the number of sectors
|
||
goes, I changed that right on the disk before loading the descriptor and found
|
||
that BACKUP wouldn't write to the last 16 sectors that I thought should be
|
||
there. What do you have to do to that ramdisk to get it so that you can backup a
|
||
|
||
40 track floppy disk to it (single sided)?
|
||
|
||
-*-
|
||
|
||
30525 6-JUL 05:58 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30521)
|
||
From: DODGECOLT To: FRANCALCRAFT
|
||
|
||
I am not sure what you have to set the ramdisk up as for the backup (I've got a
|
||
hard drive, so I haven't needed to do much in the way of disk shuffling....) I
|
||
will play around with it a bit today and get back to you...
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30546 7-JUL 14:52 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30521)
|
||
From: TIMKOONCE To: FRANCALCRAFT
|
||
|
||
The Dev Sys Ramdisk does have a known bug: The total Ramdisk size must be an
|
||
exact multiple of 8k. Otherwise, the last needed block of memory won't get
|
||
allocated. That makes it pretty much impossible to set it up to be able to
|
||
exactly backup a floppy disk to the Ram disk. I beleive there may be other
|
||
Ramdisk drivers for wich this will work, though. I know CIS has a couple. If
|
||
you only have 512k, you can try Kev Darling's Rammer ramdisk, which is here.
|
||
- Tim K
|
||
|
||
-*-
|
||
|
||
30588 8-JUL 11:33 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30546)
|
||
From: FRANCALCRAFT To: TIMKOONCE
|
||
|
||
Rammer does work. I have it already, and like it. If I go to 1 meg, is there any
|
||
|
||
way I can patch Rammer to work with it?
|
||
|
||
-*-
|
||
|
||
30593 8-JUL 15:14 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30588)
|
||
From: ZACKSESSIONS To: FRANCALCRAFT
|
||
|
||
According the Kevin Darling, the author of both rammer and mega, that's a "no
|
||
can do". It is because rammer "cheats" in the way it allocates or accesses
|
||
memory (I forget exactly what). As far as I know the only ramdisk driver which
|
||
is "guarenteed" to work with the one meg upgrade is the Dev Pack driver.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30599 8-JUL 17:39 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30593)
|
||
From: RADARBUZZ To: ZACKSESSIONS
|
||
|
||
Zack,
|
||
|
||
Well, maybe you can straighten me out here. I never was able to get the Dev
|
||
|
||
pack, so I'm using the VDD driver from the database here that is supposed to be
|
||
a direct replacement for the Tandy driver. Now it works alright, but if you try
|
||
|
||
to set one up for greater than 512K the computer crashes. Any Ideas?
|
||
|
||
-Jeff
|
||
|
||
|
||
|
||
|
||
-*-
|
||
|
||
30600 8-JUL 17:54 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30599)
|
||
From: DODGECOLT To: RADARBUZZ
|
||
|
||
I think the VDD driver is hardcoded to only allow 64 blocks per ramdisk... Since
|
||
|
||
512k worth of ramdisk = 64 blocks, any more will overwrite other important info
|
||
and causes a crash....
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30607 8-JUL 19:39 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30599)
|
||
From: ZACKSESSIONS To: RADARBUZZ
|
||
|
||
Sorry, Jeff, solving a problem of that nature is beyond the scope of my
|
||
knowledge. I see that there is a reply to your message, so maybe someone else
|
||
may spot it and offer some aid. One idea is that, you obviously have the one meg
|
||
|
||
upgrade, I don't think "things" can span from one 512K back to the other, like
|
||
all of the 32K fo a type 8 window has to be in one bank or the other.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30613 8-JUL 20:33 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30607)
|
||
From: TIMKOONCE To: ZACKSESSIONS
|
||
|
||
Zack,
|
||
Only reason why a window can't span sections is because of hardware
|
||
limitations on the video handling. That's not an issue with Ramdisks. It's not
|
||
even necessary for the Ramdisk memory to be consecutive blocks, so even that's
|
||
not an issue. Assuming it doesn't cheat, there's no reason why a Ramdisk driver
|
||
|
||
couldn't use as much memory as there is available.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30617 8-JUL 23:06 Device Drivers
|
||
RE: RAMdisk (Re: Msg 30613)
|
||
From: ZACKSESSIONS To: TIMKOONCE
|
||
|
||
So Mike Sweet's explanation seems feasable, then, ie, VDD can only handle 64
|
||
blocks.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30488 4-JUL 00:01 General Information
|
||
The Forth
|
||
From: KNOT1 To: ALL
|
||
|
||
Happy Forth everyone!
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30491 4-JUL 11:53 General Information
|
||
RE: The Forth (Re: Msg 30488)
|
||
From: MRGOOD To: KNOT1
|
||
|
||
You do mean, Happy FOURTH, no?
|
||
|
||
|
||
-*-
|
||
|
||
30515 5-JUL 04:42 General Information
|
||
RE: The Forth (Re: Msg 30491)
|
||
From: KNOT1 To: MRGOOD
|
||
|
||
OOOOOOPS! Yep, sure did. Me spelling ain't no good, yes?
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30518 5-JUL 21:45 General Information
|
||
RE: The Forth (Re: Msg 30515)
|
||
From: MRGOOD To: KNOT1
|
||
|
||
|
||
Well, hope you had a happy fourth, regardless of spelling!
|
||
|
||
Hugo
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30498 4-JUL 15:07 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 27210)
|
||
From: JASONEABY To: DISTO
|
||
|
||
Tony, I apologize for the long delay. I had finacial troubles and couldn't
|
||
afford to run up anymore online charges. The number for Dove Computer is, (919)
|
||
|
||
763-7918. I hope this helps. Again I apologize. I would really like to
|
||
upgrade to 1-Meg w/o sold ering.
|
||
Jason
|
||
|
||
Geez, I hate this editor. And I don't have my VMS EDT editor reference handy
|
||
either, oh well.
|
||
|
||
|
||
-*-
|
||
|
||
30501 4-JUL 18:04 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30498)
|
||
From: ZACKSESSIONS To: JASONEABY
|
||
|
||
EDT has "on-line" help at the asterisk prompt. Just enter HELP and press ENTER
|
||
(or RETURN). Of course, as with most VMS type help, you need toave an idea of
|
||
what you need help ON to get some useful information out.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30502 4-JUL 18:57 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30501)
|
||
From: JASONEABY To: ZACKSESSIONS
|
||
|
||
I tried help, it only gave me something that didn't make much sense. I know how
|
||
|
||
screwy VMS is on its help because Millersville University has several VAX'es and
|
||
|
||
I have to program on a MicroVAX 3600 for my CS classes. -Jason
|
||
|
||
-*-
|
||
|
||
30504 4-JUL 20:07 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30501)
|
||
From: DWHILL To: ZACKSESSIONS
|
||
|
||
That's been one of my complaints about the online editors here: help is there
|
||
but isn't much help when you're constantly switching back and forth between the
|
||
task and the help menus. Delphi needs to make a downloadable tutorial available
|
||
|
||
so we can have our own references at hand to study before we attempt to use the
|
||
darn thing.
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
30506 4-JUL 21:17 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30504)
|
||
From: CHYDE To: DWHILL
|
||
|
||
Yyou could of course by a Delphi manual. They have a very good description of
|
||
the editing commands. They just finished a new edition which is availabel now.
|
||
|
||
Just a thought.
|
||
|
||
-*-
|
||
|
||
30513 4-JUL 23:30 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30504)
|
||
From: ZACKSESSIONS To: DWHILL
|
||
|
||
There is the Complete Delphi Guide.
|
||
|
||
Z.
|
||
|
||
-*-
|
||
|
||
30514 5-JUL 00:11 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30506)
|
||
From: DWHILL To: CHYDE
|
||
|
||
True, but I'd like to have a up-to-date reference online that's more helpful
|
||
than what's currently available.
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
30561 8-JUL 00:07 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30502)
|
||
From: RAGTIMER To: JASONEABY
|
||
|
||
Say, ever notice that there is NO help available at the MAIL prompt? No way to
|
||
get a list of valid commands! There's help at the DMAIL level, but not at MAIL.
|
||
|
||
AT least I haven't rubbed the genie's lamp the right way.
|
||
|
||
Word is that Delphi's Mail system is straight raw VMS. Thank God for UN*X.
|
||
|
||
-*-
|
||
|
||
30564 8-JUL 00:35 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30561)
|
||
From: JASONEABY To: RAGTIMER
|
||
|
||
Haven't tried to use mail yet, but I can believe it because I have used VMS
|
||
mail. VMS mail goes something like this, type send with a user name and it'll
|
||
prompt you from there. Heck I don't even think you have to use a name. -Jason
|
||
|
||
-*-
|
||
|
||
30566 8-JUL 00:39 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30564)
|
||
From: RAGTIMER To: JASONEABY
|
||
|
||
Yes, just sending mail is easy enuf. But after reading a message I wanted to
|
||
reread it. Type REREAD, got some generic "syntax error", but there's no way to
|
||
get a list of commands. I do have that Delphi manual somewhere, but I hate
|
||
rooting in a book while my computer taxi meter is ticking (at least this isn't
|
||
CI$).
|
||
|
||
-*-
|
||
|
||
30568 8-JUL 00:59 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30561)
|
||
From: GREGL To: RAGTIMER
|
||
|
||
Mike,
|
||
|
||
From the MAIL> prompt you can type HELP for a list of the commands you can
|
||
use. It'll put you into the generic help system where you can follow a chain of
|
||
commands and options to find what you are looking for. It ain't the best in the
|
||
world, but it works.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30646 10-JUL 21:55 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30568)
|
||
From: RAGTIMER To: GREGL
|
||
|
||
OK -- I cuda sworn I'd tried HELP. Maybe I did, and got disgusted with that
|
||
generic HELP system. There should me a list of MAIL cmds, as there is at the
|
||
DMAIL level and inside its WORKspace.
|
||
|
||
-*-
|
||
|
||
30653 10-JUL 23:20 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30646)
|
||
From: GREGL To: RAGTIMER (NR)
|
||
|
||
Mike,
|
||
|
||
No argument from me. One of the biggest complaints we get is on the mail
|
||
system used. I keep hoping that the gurus behind Delphi will write their own
|
||
version of Mail and toss DEC-Mail. But I don't know if they are legally bound to
|
||
|
||
use DEC-Mail or not. It's fairly powerful but it's not the easiest thing to use,
|
||
|
||
that's for certain.
|
||
|
||
-- Greg
|
||
|
||
PS: A problem I just thought of is that Mail is used quite heavily to send mail
|
||
to other nodes. For example, you commonly send mail to users of Delphi/Boston by
|
||
|
||
using the BOS1A or BOS1B nodes. But you can also send mail to Delphi/Miami by
|
||
using MIAIA, Delphi/Argentina, Delphi/Kansas City, etc. Just one of the
|
||
advantages of using the VAX Cluster.
|
||
|
||
-*-
|
||
|
||
30658 11-JUL 18:11 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30653)
|
||
From: ZACKSESSIONS To: GREGL
|
||
|
||
Actually, Greg, the VAXcluster isn't what gives us the ability to send mail to
|
||
other nodes, it's DECnet.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30690 13-JUL 21:01 General Information
|
||
RE: One Megabyte CoCo-3 !! (Re: Msg 30514)
|
||
From: CHYDE To: DWHILL (NR)
|
||
|
||
|
||
their own.
|
||
Chris
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30519 5-JUL 22:34 Utilities
|
||
PCDos
|
||
From: JASONEABY To: ALL
|
||
|
||
Help! Is there anyway to use the PC-Dos utility with the Disto No-Halt
|
||
CC3Disk Driver? When I try to use it, I get not a Dos disk. Of course the
|
||
problem may be the fact that it was formatted for 360K on a 1.2 Meg drive. Those
|
||
|
||
1.2 Meg drives are notorious for screwing up the 360K format. Any help will be
|
||
appreciated. Thanks. -Jason
|
||
|
||
-*-
|
||
|
||
30526 6-JUL 06:01 Utilities
|
||
RE: PCDos (Re: Msg 30519)
|
||
From: DODGECOLT To: JASONEABY
|
||
|
||
Unfortunately, the SC-II hardware only buffers the first 256 byts of a sector.
|
||
This works fine for OS-9 disks, but MS-DOS disks use 512 bytes per sector. The
|
||
only solution at present is to have a second boot disk that uses the old HALT
|
||
mode driver instead of the Disto driver...
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30545 7-JUL 14:49 Utilities
|
||
RE: PCDos (Re: Msg 30519)
|
||
From: TIMKOONCE To: JASONEABY
|
||
|
||
The simple answer is: "No, the PCDOS utility will not work with the no-halt
|
||
drivers." To use it, most people keep a second boot disk with the standard halt
|
||
|
||
drivers just for use with PCDOS.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30554 7-JUL 22:27 Utilities
|
||
RE: PCDos (Re: Msg 30526)
|
||
From: JASONEABY To: DODGECOLT
|
||
|
||
Thanks, I have a couple of old boot disks lying around, so I'll try the patch on
|
||
|
||
them and hope it works. Should have expected it to be something like that.
|
||
That's what you get for using the latest and greatest technology.
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30522 6-JUL 00:05 General Information
|
||
Double-sided boot disks
|
||
From: FRANCALCRAFT To: ALL
|
||
|
||
How does one make a double-sided boot disk for OS-9, starting from a single
|
||
sided system? I have tried all sorts of cute tricks to try to accomplish that,
|
||
but nothing works.
|
||
|
||
-*-
|
||
|
||
30528 6-JUL 21:03 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30522)
|
||
From: FRANCALCRAFT To: ALL
|
||
|
||
Perhaps I should rephrase. How does one make a double-sided boot with COBBLER?
|
||
CONFIG works fine, but I couldn't get COBBLER to make a workable boot on a
|
||
double-sided disk.
|
||
|
||
-*-
|
||
|
||
30530 6-JUL 23:08 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30528)
|
||
From: ZACKSESSIONS To: FRANCALCRAFT
|
||
|
||
Let me know your disk configuration, ie, how many floppies, any ramdisk, or hard
|
||
|
||
drive, and I'll give you the exact commands to do it.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30543 7-JUL 11:14 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30528)
|
||
From: DRSPOON To: FRANCALCRAFT
|
||
|
||
I had one heck of a time getting a double sided boot disk at first too!! I
|
||
played around with changing the descriptors from single sided to double sided
|
||
and everything that I could think of on the single sided boot disks I had and
|
||
nothing worked. The ultimate solution for me was to FORMAT the destination disk
|
||
|
||
first as double sided. I could not use the straight FORMAT command, I had to
|
||
specify 2 sides. Seems like if I just used FORMAT without any modifiers the
|
||
system assumed that I wanted to format the new disk just like the one I used to
|
||
boot up with, which at the time was a single sided disk. (Thats all I had!!)
|
||
Once I had a suitable double sided boot set-up on the single sided disk, I used
|
||
the DSAVE route to copy it to the newly formatted double sided disk and every
|
||
thing worked fine!! Once I had the original double sided boot disk, then every
|
||
disk I formated with that disk also came out formatted double sided WITHOUT
|
||
having to use any modifiers. I still don't know WHY I had to do all this, and
|
||
WHY no one else seemed to be having that trouble, but it worked for me. This
|
||
may not have anything to do with your current problems, but I thought I would
|
||
report it. Maybe someone else can explain the WHYs for me. Probably something
|
||
simple that I was not doing at the time. Seems like the key is how the disk you
|
||
originally booted up on is configured. That seems to get locked into the
|
||
system's corporate memory and is used until you tell it to do something
|
||
different!!-Don Spoon-
|
||
|
||
-*-
|
||
|
||
30586 8-JUL 11:27 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30530)
|
||
From: FRANCALCRAFT To: ZACKSESSIONS
|
||
|
||
With COBBLER? I did manage to make a double-sided boot with Config, but not
|
||
with Cobbler. The strange thing is, I really couldn't see any difference in the
|
||
way the pieces of the boot were arranged between the two. I have one
|
||
double-sided floppy drive, and one single-sided, one Ramdisk, n hard drive.
|
||
|
||
-*-
|
||
|
||
30587 8-JUL 11:31 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30543)
|
||
From: FRANCALCRAFT To: DRSPOON
|
||
|
||
I used a sneaky trick to get around the format problem. I used DMODE. I just did
|
||
|
||
DMODE /d0 sides=2, formatted a disk, which came out double-sided, then tried to
|
||
COBBLER to it. The result wouldn't boot. I next tried Config with a double sided
|
||
|
||
descriptor for that drZ8e,ahZYHMU1Q"%==Q9"+HUMQ%=9JM1:!e"%9"5R4uKK[I:=I-}j$(-*-
|
||
|
||
30590 8-JUL 12:35 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30587)
|
||
From: DRSPOON To: FRANCALCRAFT
|
||
|
||
I'm getting in over my head, but here's some thoughts. Seems like I recall that
|
||
|
||
Cobbler just writes whatever boot information is in memory from the last boot-
|
||
up, unless you have changed it. Maybe the info you wrote to your new double-
|
||
sided disk was single-sided info?? I also seem to recall that several years ago
|
||
|
||
many people reported troubles with Cobbler and the GURUs were advising not using
|
||
|
||
it. I never got the "real" reason. I think it WOULD work, but had several
|
||
nuances that the casual user would not know about, and were taken care of in
|
||
CONFIG automatically. It is not a "user friendly" command!! Neat about the
|
||
DMODE!! I'll add that to my library of "things I'll make sure to teach my
|
||
kids". Thanks
|
||
Don Spoon
|
||
|
||
-*-
|
||
|
||
30592 8-JUL 15:09 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30590)
|
||
From: ZACKSESSIONS To: DRSPOON
|
||
|
||
I never use cobbler or config, because to me it's simpler to use os9gen, and I
|
||
feel I have more total control. The only modules for OS9Boot which come from
|
||
memory are REL, Boot, and os9p1. when using os9gen. When using cobbler,
|
||
everything comes from memory. So, how I did it was to build a bootlist file
|
||
which contained the DS file decriptors. dmoded the target disk for 40trk, DS,
|
||
formatted it, and the OS9Genned the boot. Can't really say WHY cobbler failed in
|
||
|
||
a similar manner, but like the old joke, I told the doctor it hurt when I raised
|
||
|
||
my arm, so he told me not to do it!
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30615 8-JUL 22:06 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30592)
|
||
From: RADICAL To: ALL
|
||
|
||
Just set up a doubleside drive 0 today. Previously had a doublesided drive 1,
|
||
so things worked smoothly. Dmode /d0 sid=2 cyl=28 dmode /dd sid=2 cyl=28 format
|
||
|
||
a doublesided disk, cobbler the os9boot, then dsave /d0 /d1 ! shell This gave me
|
||
|
||
a working copy, which booted first try on a doublesided disk. If you don'd have
|
||
two drives I think dsave -s should do the samething on a single drivwve. Len
|
||
|
||
|
||
-*-
|
||
|
||
30622 9-JUL 14:03 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30590)
|
||
From: FRANCALCRAFT To: DRSPOON (NR)
|
||
|
||
If by "single-sided info" you mean a single-sided device descriptor for the
|
||
drive, I checked that with DED and changed it before trying to boot. Yes, I did
|
||
verify the module afterwards (to forestall the next question). Cobbler still
|
||
works like a charm for doing single-sided boots.
|
||
|
||
-*-
|
||
|
||
30635 10-JUL 01:08 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30622)
|
||
From: RADICAL To: FRANCALCRAFT
|
||
|
||
Do you have the dmode command? If not be sure to download it from the database.
|
||
|
||
You can then use it to change the discritors for the drives to cyl=28 sid=2
|
||
thhat creates a doublesided drive. In the case of drive 0 the command would be
|
||
:dmode /d0 cyl=28 sid=2. Then format, and cobbler a new disk, and dsave /d0 /d1
|
||
|
||
! shell. You should end up with a bootable doublesided disk once you are done.
|
||
|
||
Len
|
||
|
||
-*-
|
||
|
||
30645 10-JUL 20:23 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30635)
|
||
From: FRANCALCRAFT To: RADICAL
|
||
|
||
I have DMODE. I used it. Cobbler didn't work, however. Perhaps that was because
|
||
I booted up from a single-sided disk? Config worked fine.
|
||
|
||
-*-
|
||
|
||
30654 11-JUL 00:58 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30586)
|
||
From: DCJR To: FRANCALCRAFT
|
||
|
||
The catch with cobbler is that it makes an EXACT copy of the OS-9 kernal you
|
||
have in memory at the time you call it. This includes any patches you've made
|
||
since you booted up, and any dmode or xmode commands you've issued. If you want
|
||
to make a double-sided boot disk, the catch is first you have to boot from one!
|
||
Then, don't forget to create a CMDS directory with shell and grfdrv in it.
|
||
|
||
-*-
|
||
|
||
30656 11-JUL 02:07 General Information
|
||
RE: Double-sided boot disks (Re: Msg 30654)
|
||
From: RADICAL To: DCJR
|
||
|
||
I booted from a single sided disk. Dmode /dd cyl=28 sid=2 Dmode /d0 cyl=28
|
||
sid=2 Then cobbler to a blank doublesided disk, and dsave the bootdisk. The
|
||
resulting disk booted with no problems. Len
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30524 6-JUL 03:05 General Information
|
||
Atlanta CoCoFEST
|
||
From: DAVEMYERS To: ALL
|
||
|
||
*** ATLANTA CoCoFEST ***
|
||
October 6-7,1990
|
||
Holiday Inn Northlake
|
||
|
||
|
||
As you may know, the traditional Fall gathering of CoCo enthusiasts has been
|
||
cancelled...BUT, you can make plans NOW to join your favorite CoCo vendors,
|
||
online pals, and CoCo fans from far and near at the 1s before you buy" those items yayryo
|
||
->noco ri Wrusshs dt edgCo prs.orn N esoCCitrt
|
||
-- r hnstwnvub orrz,cueyf aiian nosnh taaCptroiy
|
||
|
||
-Tepouiyotnuwtdnsdooot d adr t A!---Flwhpn nwthnesunhdesfCotTct otetatCCETa vlbeO pily.n,aa
|
||
er ns.h rt2 ele to reserve onsite hotel rooms through us (at
|
||
the special show price of $49/nite + tax, single or double) will receive a FREE
|
||
one-day admission for each night's lodging purchased! To recieve the special
|
||
room rate, your reservation MUST be placed through CoCoPRO!
|
||
|
||
For specially discounted airfare and car rentals (starting at $17.95/day with
|
||
unlimited mileage), contact Lisa at CoCoFEST affiliate Travel Bank of Atlanta -
|
||
1-800-477-9191.
|
||
|
||
For tickets, hotel reservations, or further info, contact us at CoCoPRO! -
|
||
1-313-481-DAVE <3283> (1-8 P.M.. 7 days). Modem users may place ticket/room
|
||
orders using VISA or MC, by calling our BBS at 313-663-6207 (3 lines, 7-E-1,
|
||
3-1200 on all lines).
|
||
|
||
-*-
|
||
|
||
30527 6-JUL 19:10 General Information
|
||
shell+ 2.1
|
||
From: CAPTSWOOSH To: ALL
|
||
|
||
hey gang can some one tell me how to configure shell+ 2.1 ?? How do i create the
|
||
|
||
new boot?? how do i save my old modules... HELP!!!! ron the novice. i mean real
|
||
novice.....
|
||
|
||
-*-
|
||
|
||
30529 6-JUL 23:06 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30527)
|
||
From: ZACKSESSIONS To: CAPTSWOOSH
|
||
|
||
Configure shell+ 2.1? Save old modules? Huh? Yeah, I guess you are a novice?
|
||
<grin>
|
||
|
||
Shell+ does come with a doc file which describes how to install it. Basically
|
||
all you replace is your old shell module with the new shell module, that's it.
|
||
Now, your "stock" shell module has a fwe commonly used OS9 modules "merged" with
|
||
|
||
it. That's why when you boot up and do an MDIR command, you see a few extra
|
||
modules. Those modules are also in the CMDS directory on the main OS9 disk in
|
||
individual files. Just merge those modules with the new shell module with
|
||
shell+. Be sure to set the execution attribute to the newly created module which
|
||
|
||
contains shell+ and the other utils so you don't see the "OS9 BOOT FAILED"
|
||
message!
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30547 7-JUL 14:59 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30527)
|
||
From: TIMKOONCE To: CAPTSWOOSH
|
||
|
||
Ron,
|
||
The easy way (which doesn't quite do everything you'll eventually want) is
|
||
to:
|
||
rename /dd/cmds/shell old_shell
|
||
copy shellplus /dd/cmds/shell
|
||
attr /dd/cmds/shell e pe
|
||
|
||
First, rename the "old" shell file to something different, then copy the new
|
||
shellplus into your CMDS dir, then give it execute privileges. There's no need
|
||
to create a new boot, and you don't _really_ need to save any modules. The
|
||
saving modules bit is a trick that more experienced OS9ers use to speed up their
|
||
|
||
system by keeping common programs (dir, list, free, mfree, copy, etc.) in
|
||
memory. If you just do what I listed, those commands won't be in memory, which
|
||
will slow things down some, but it will still work just fine.,.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30555 7-JUL 22:52 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30529)
|
||
From: JASONEABY To: ZACKSESSIONS
|
||
|
||
Zack, can you tell me why the Shell+ 2.1 docs tell you to keep the module size
|
||
below 8k? I realize it has something to do with keeping it in an 8k block, but
|
||
if I go over, will the shell take up 16k every time I start a new one? The way
|
||
I interpret the Level II docs make it seem like it shouldn't, because of the
|
||
multiple threading of a process. The 8k that it takes up now, I think, goes to
|
||
data storage. Any help will be appreciated. -Jason
|
||
|
||
-*-
|
||
|
||
30560 7-JUL 23:44 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30555)
|
||
From: ZACKSESSIONS To: JASONEABY
|
||
|
||
If the size of a merged multiple module file is larger than 8K and one of the
|
||
modules is Shell, NO, each time you start up a shell, the process doen't take up
|
||
|
||
the extra memory. The problem with going over 8K is that memory is allocated in
|
||
8K chunks and if you do go over 8K, then the difference in the final size and
|
||
the next increment of 8K is totally wasted memory and can never be allocated to
|
||
any process for use.
|
||
|
||
Actually, the size of a merged multiple module file should not exceed 8K - 512,
|
||
or 7680 bytes. Quoting from Kevin's book, the ideal size of a merge file is:
|
||
|
||
(8K * N) - 512 where N ranges from 1-7.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30562 8-JUL 00:17 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30529)
|
||
From: RAGTIMER To: ZACKSESSIONS
|
||
|
||
Zack, do you know whether that well-meaning bug in Sell+ has been fixed? The one
|
||
|
||
where every program is forked with at least 7K, as if the user had typed
|
||
program #7K
|
||
|
||
You probably have heard that this "feature" prevents large program (those that
|
||
use all 8 of the 8K blocks) from running. Tis includes Ultimuse-III and some
|
||
other well-known stuff, I forgot which. There is a patch to eliminate that
|
||
feature, but I wondered if a newer version had come out with out it.
|
||
|
||
Anyway, users should know about the problem. Thanks, mike k
|
||
|
||
-*-
|
||
|
||
30565 8-JUL 00:38 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30560)
|
||
From: JASONEABY To: ZACKSESSIONS
|
||
|
||
Thanks, the docs gave a file size about what you said, I just rounded for
|
||
convenience and forgetfulness's sake. I guess that means if I can get it it
|
||
somewhere close to a 16k block, I'll be in business. Thanks again. -Jason
|
||
|
||
-*-
|
||
|
||
30567 8-JUL 00:49 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30555)
|
||
From: TIMKOONCE To: JASONEABY
|
||
|
||
The actual concern, Jason, has to do with how Shell+ deals with certain things.
|
||
In order to find out certain things about a program, Shell+ links the module
|
||
into it's own address space. Since the module might be large, you want to make
|
||
sure that Shell+'s address space has as large a hole as possible for the other
|
||
module to fit into. Shell+'s data area takes up 8k, so the biggest possible
|
||
hole is 48k, or 6 8k blocks. The only way to get that is if the Shell+ module
|
||
is in the top block of memory, which requires that the total size be under 7680
|
||
bytes.
|
||
For the newer Shell+, which is pretty big, I only merge in "load" with it
|
||
(which is necessary if you want "load" to end up not taking up it's own 8k
|
||
block, BTW), and merge other utils into separate files, each less than 8k.
|
||
Those files get loaded by my Startup file. Seems to work pretty well.
|
||
There are also some programs which link the Shell, which is another good
|
||
reason to keep the Shell file under 8k.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30570 8-JUL 01:36 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30567)
|
||
From: JASONEABY To: TIMKOONCE
|
||
|
||
That is the way I'm doing it now, although I have more than 'load' merged and
|
||
have it under 7680. But this help has probably confused things even more. Zack
|
||
says it doesn't matter and you say it does. Maybe I'll just have to stop being
|
||
lazy and try it f or myself and see what happens. Either that or we should kick
|
||
|
||
this up to a higher authority. -Jason
|
||
|
||
-*-
|
||
|
||
30571 8-JUL 02:33 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30570)
|
||
From: TIMKOONCE To: JASONEABY (NR)
|
||
|
||
If you read carefully, Zack explained to you the reason why you want merged
|
||
modules to come close to a multiple of 8k, so you don't waste memory. Since
|
||
memory is allocated 8k at a time, you'd like to fill the memory that gets
|
||
allocated. The bit about being 512 bytes short is a subtle point that I'll not
|
||
go into right now.
|
||
What I elaborated on is why the Shell file, in particular, should fit in just
|
||
|
||
one block, which is due to the way the Shell does certain things.
|
||
To summarize: In order to save memory, _any_ group of merged modules should
|
||
be just under some multiple of 8k. Because of the way the Shell (including
|
||
Shell+) works, the Shell file should be under 7680 bytes. Does it make more
|
||
sense now?
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30583 8-JUL 11:12 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30562)
|
||
From: ZACKSESSIONS To: RAGTIMER
|
||
|
||
Wasn't there a patch to Shell+ posted here in the forum which fixed that
|
||
problem?
|
||
|
||
Posted by Mike Haaland, originally, I think.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30647 10-JUL 22:00 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30583)
|
||
From: RAGTIMER To: ZACKSESSIONS
|
||
|
||
Yes, there was the patch, which I wrote in my notebook somewhere in March or
|
||
April, and passed on to Paul Seniura. I didn't know about the 2nd patch he's
|
||
posted, tho.
|
||
|
||
However, I wondered whether there had been a later release of Shell+ that fixed
|
||
the problem. "Instant Program -- No patches Needed" -- boy would that be a 1st
|
||
for OS9, just kidding, grin.
|
||
|
||
Seriously, patches for PD shareware aren't so bad, since users get the patches
|
||
the same media they got the program to start with. Bigger problem is commercial
|
||
programs (like MultiVue) that require patches; most customers aren't on
|
||
Delphi/CIS/whatever and don't even know the patches exists, or how to get them.
|
||
--mike k.
|
||
|
||
-*-
|
||
|
||
30649 10-JUL 22:12 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30571)
|
||
From: RAGTIMER To: TIMKOONCE (NR)
|
||
|
||
Also: Any merged group that has one BIG program (that's going to use all 8 of
|
||
its 8K blocks when running) should fall short of an 8K multiple by that 512 byte
|
||
|
||
amount. I know someone who MERGEd innocent little MONTYPE and PWD with Umuse3,
|
||
thus filling in that 512 byte no-man's land, and got a nasty surprise when it
|
||
ran. This by the way is not really related to the Shell+/Umuse3 problem, which
|
||
is easily patched out of Shell+.
|
||
|
||
-*-
|
||
|
||
30650 10-JUL 22:14 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30583)
|
||
From: RAGTIMER To: ZACKSESSIONS
|
||
|
||
Zack, it may well have been Mike Haaland who first found that Shell+ bug with
|
||
big programs, since his MVCanvas is about as big as Umuse3.
|
||
|
||
-*-
|
||
|
||
30684 12-JUL 23:22 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30650)
|
||
From: XLIONX To: RAGTIMER (NR)
|
||
|
||
Howdy Mike, Please see msg# 30556
|
||
|
||
-mark w. farrell (XLIONX)
|
||
|
||
-*-
|
||
|
||
30686 13-JUL 00:12 General Information
|
||
RE: shell+ 2.1 (Re: Msg 30650)
|
||
From: MIKEHAALAND To: RAGTIMER (NR)
|
||
|
||
|
||
~ Well, To set the record straight, I did discover that Shell+ was giving our
|
||
programs (UMusE III and MVCanvas) a little trouble. But it was another forum
|
||
member who found out how to patch Shell+ to work so it didn't give an extra 31
|
||
pages of memory when forking programs.
|
||
|
||
MikeH
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30531 6-JUL 23:14 New Uploads
|
||
depthcharge
|
||
From: ZACKSESSIONS To: WJMOORE
|
||
|
||
I downloaded depthcharge the other night and have a few comments. Please don't
|
||
take anything I say derogatory, I'm only trying to help. The program is good,
|
||
but uploads need a little extra. Like a doc file which describes the program,
|
||
how to install it, and how to use it. Fortunately, I found the comments in the
|
||
source on how to drop depth charges, but I know nothing on the scoring of the
|
||
game. Also, some sound effects may make the game more enjoyable.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30533 6-JUL 23:54 New Uploads
|
||
RE: depthcharge (Re: Msg 30531)
|
||
From: WJMOORE To: ZACKSESSIONS
|
||
|
||
Just say it like it is but keep it clean! hehe. I was exploring the get/put
|
||
buffers and used this game as a vehicle to demonstrate animation capabilities.
|
||
But you are correct, a brief description on loading, running, and operating the
|
||
game will be UL for
|
||
those that do not program. As for scoring, I could not come up with anything
|
||
satisfactory so open to any suggestions. Primative sounds can be added easily,
|
||
but "white" noise I can not generate. Any help here? Anymore comments, just
|
||
tack onto this thre ad.
|
||
|
||
- War -
|
||
|
||
-*-
|
||
|
||
30541 7-JUL 11:00 New Uploads
|
||
RE: depthcharge (Re: Msg 30533)
|
||
From: ZACKSESSIONS To: WJMOORE
|
||
|
||
White noise can be generated by doing a SYSCALL to the SetStt/ SS.Tone call with
|
||
|
||
a random value for the frequency. Makes a good motor/engine sound.
|
||
|
||
I did play the game for at least an hour, though, when I first downloaded it!
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30550 7-JUL 19:23 New Uploads
|
||
RE: depthcharge (Re: Msg 30541)
|
||
From: DODGECOLT To: WJMOORE
|
||
|
||
You might want to check out my Lander games a tle h ffrotesn,u hhgfe tfi o rone..-i
|
||
|
||
*
|
||
|
||
n he.--35 -U0: Uite c"tlt rmKO oAL
|
||
Hl,eeoeyisulat edtaesolsob alb nt N pos
|
||
eto Iscld""wi shr r"oy.Is tlywc
|
||
cbn hfntn foyg iigMvn nDltgfe.
|
||
ort eyiirytisUXcnept,iht dtosfewi-rpign roeoe
|
||
|
||
Ipod cueodays ago, so it should be available anytime soon. Give
|
||
|
||
it a try! Let me know what you think.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
30540 7-JUL 03:34 Utilities
|
||
database report
|
||
From: BOBDORRELL To: EDDIEKUNS (NR)
|
||
|
||
Eddie, I am looking at the July, 1990 Rainbow page 62, where you say there is a
|
||
program that generates a shell script to copy an entire DECB formatted disk to
|
||
and OS-9 disk using Bob Shanty's RS-DOS utility. I can't find any of ther
|
||
programs you list in the article, in the database. What is happening folks? Are
|
||
all the programs selfdistructing? Maybe if you could give the actual name that
|
||
the file is posted under, it would help me find it. I could go to the database,
|
||
utilities, and type READ RS-DOS and get what I wanted. Most of the items you
|
||
mentioned in the article don't have the NAME of the file. Thanks for you help.
|
||
----==<Bob>==----
|
||
|
||
-*-
|
||
|
||
30542 7-JUL 11:03 Utilities
|
||
RE: database report (Re: Msg 30540)
|
||
From: ZACKSESSIONS To: BOBDORRELL (NR)
|
||
|
||
It's called RSSave.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30548 7-JUL 17:00 General Information
|
||
1 Meg problems?
|
||
From: RADARBUZZ To: ALL
|
||
|
||
1 Meg status,
|
||
|
||
I just installed my 1 Meg kit that I ordered from CRC/DISTO. Everything
|
||
seems to be working, but...
|
||
|
||
Never before have I had those things called "sparklies", but now I got a
|
||
few. With no multitasking, (just a few shells on /w1, /w2, /w3 ...) I get one
|
||
pixel slightly flickering near the top middle of most of the 80 column
|
||
screens.As a test, I've LOADed about 800K of modules, started OSTERM, ED, and 5
|
||
MAZEs. The computer has been up for about an hour and I'm now writing this with
|
||
ED. R22 IS SHORTED as specified in the instructions.
|
||
|
||
Basically, I have 3 concerns right now: (* = HELP!)
|
||
|
||
*1) The point at which the regulator on the 1-Meg card connects to it's
|
||
heat sink is HOT. 15 seconds max finger touch before pain. This
|
||
does not seem normal! The smell from the heat conductive goop cooking
|
||
between the regulator and heat sink is giving me a head ache, I hope
|
||
it's not toxic?
|
||
|
||
*2) Right after booting I could not set up a ramdisk (VDD driver here on
|
||
Delphi) bigger than 512K. Here is how I try for a 720K ramdisk:
|
||
|
||
mega
|
||
dmode /r0 sct=0b40
|
||
iniz /r0
|
||
|
||
After the "iniz /r0" I get small blocks of random characters (some
|
||
blinking) on the screen and the computer is locked up. I was under
|
||
the impression that the VDD driver worked with 1-meg, which is why
|
||
I switched from RAMMER before the I-Meg kit arrived.
|
||
|
||
3) The "sparklies" don't seem to be real bad, but I'm willing, as others
|
||
have, to try hooking up a small pot in place of R22 to attempt to
|
||
"tune" my computer's personality (grin). Any ideas on what ohm values
|
||
to begin with?
|
||
|
||
|
||
Well, now I'll try Osterm and post this in the forum. Any help that comes
|
||
my way is truely appreciated!
|
||
|
||
-Jeff
|
||
|
||
ps. Osterm is really NOT smooth with 1-Meg! Since it's running in the upper
|
||
512K bank, it must...SCRATCH that! With all those MAZEs running in the
|
||
background, I shouldn't expect smoothness. Almost fooled my self (grin).
|
||
|
||
|
||
pps. Sparkies seem much worse (exponetially greater) during ACIA I/O. Must fix
|
||
|
||
this! **
|
||
|
||
|
||
-*-
|
||
|
||
30563 8-JUL 00:26 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30548)
|
||
From: RAGTIMER To: RADARBUZZ
|
||
|
||
Sparklies are worse during any kind of heavy I/O -- the serial printer port
|
||
really snows it up. OSTERM, with its constant sampling of the ACIA, does do a
|
||
pretty good snow job.
|
||
|
||
Question -- do you have an old or new style GIME chip? Old is (c) '86, new is
|
||
'87 I think. I had lots of sparklies with my old GIME on just 512K. New GIME
|
||
eliminated them all. And they stayed away when I went to 1 Meg.
|
||
|
||
Now some lucky people had no sparklies under 128/512K even with their old GIMEs.
|
||
|
||
But if you're one of those, maybe the 1 Meg finally got to your old GIME.
|
||
|
||
OS course if you have a new GIME, well, try that trimpot resistor.
|
||
|
||
-*-
|
||
|
||
30569 8-JUL 01:01 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30563)
|
||
From: DWHILL To: RADARBUZZ
|
||
|
||
The regulator running hot to the touch is normal. I'm surpised you can keep
|
||
your finger on it that long! Mine's always run that hot with 512K.
|
||
|
||
On the other hand, the smell may be something besides the conductive good. Like,
|
||
|
||
maybe the transformer varnish. That may not be a good thing.
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
30597 8-JUL 17:37 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30563)
|
||
From: RADARBUZZ To: RAGTIMER
|
||
|
||
Well, for the life of me I thought I had an '87 GIME, but after looking
|
||
again it's a '86 fer sure!
|
||
|
||
QUESTION - How do I order an '87 GIME (RS part #?)and do you remember
|
||
roughly what you paid for the new one?
|
||
|
||
Since I never had "sparklies" before and haven't had any wierd crashes since
|
||
|
||
the upgrade, the new GIME is all I need, I hope!
|
||
|
||
-Jeff
|
||
|
||
|
||
-*-
|
||
|
||
30598 8-JUL 17:37 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30569)
|
||
From: RADARBUZZ To: DWHILL
|
||
|
||
Damon,
|
||
|
||
The HOT regulator I was referring to was the one on the 1-Meg board. A long
|
||
|
||
time ago I swapped the small regulator on the COCO with a big 2N3055 mounted on
|
||
a massive finned heat sink. I just might do the same for the 1-Meg board. Gee,
|
||
|
||
if I was to wire another 2N3055 in parrallel with the first one, the second one
|
||
could power the 1-Meg board and I could eliminate that external Commodore(!)
|
||
power transformer that CRC sent with the kit.
|
||
|
||
-Jeff
|
||
|
||
|
||
-*-
|
||
|
||
30612 8-JUL 19:46 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30597)
|
||
From: ZACKSESSIONS To: RADARBUZZ
|
||
|
||
I have 3 on order right now (gimes). Don't have the part number handy, can get
|
||
it tomorrow. Price is $21 and some change, each. To get one, go to your local
|
||
Rat Shack and ask the manager to order it for you from National Parts.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30625 9-JUL 18:34 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30612)
|
||
From: RADARBUZZ To: ZACKSESSIONS
|
||
|
||
|
||
Zack,
|
||
Let me know that part# (GIME) if you can. $21 sounds reasonable. I'm not
|
||
in a real big hurry to order one, but - not having had sparklies before I think
|
||
I would rather not have to get used to them. . .
|
||
. . .
|
||
.
|
||
. . .
|
||
|
||
. . . -Jeff
|
||
|
||
<Grin>
|
||
|
||
-*-
|
||
|
||
30629 9-JUL 22:42 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30625)
|
||
From: ZACKSESSIONS To: RADARBUZZ
|
||
|
||
Part number is MX0992, cost is $21.75 each. I hope you have better luck than nI
|
||
did, damn UPS lost mine, and they're having to re-order.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30638 10-JUL 02:57 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30598)
|
||
From: OS9UGPRES To: RADARBUZZ
|
||
|
||
A sidenote: I've been running the breadboard version (more chips) of the 1-meg
|
||
upgrade continously since we got it running back last fall... and using the
|
||
coco's normal internal power supply!
|
||
|
||
However, I don't have a cover on the machine (which helps ;-), and also I have
|
||
the CMOS 6309 cpu... which uses almost a watt less than the normal 6809. No
|
||
problems so far, powerwise. Might just be luck, tho <grin>.
|
||
kev P/ex
|
||
|
||
-*-
|
||
|
||
30640 10-JUL 16:26 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30629)
|
||
From: RADARBUZZ To: ZACKSESSIONS
|
||
|
||
Thanx Zack, I'm gonna order one today.
|
||
|
||
-Jeff
|
||
|
||
|
||
|
||
-*-
|
||
|
||
30641 10-JUL 16:27 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30638)
|
||
From: RADARBUZZ To: OS9UGPRES (NR)
|
||
|
||
A whole watt less (6309 vs 6809)!? I've seen some discussion about the 6309
|
||
here in the past. Interesting.
|
||
|
||
QUESTION: is the 6309 a direct plug-in replacement (same pin-out) for the 68B09
|
||
? What's a good source to order one from? Thanx,
|
||
|
||
-Jeff
|
||
|
||
-*-
|
||
|
||
30648 10-JUL 22:04 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30638)
|
||
From: RAGTIMER To: OS9UGPRES (NR)
|
||
|
||
Hey Kev, no fair! Running with the case open is a dirty Commie (as in -odore)
|
||
trick. "Warranty void if case NOT opened before using." Grin?
|
||
|
||
-*-
|
||
|
||
30651 10-JUL 22:18 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30569)
|
||
From: RAGTIMER To: DWHILL
|
||
|
||
Yeah, my 1 Meg regulator is too hot to touch for more than a second or two. No
|
||
smells, tho. With the 1 Meg properly installed, and using that Communist
|
||
transformer, your Coco's transformer should be runnhjing *cooler*, since it
|
||
isn't running your 512K RAM anymore. Unless the daughter board over the 6809
|
||
draws more than your 512 did.
|
||
|
||
I seriously considered feeding the 1 Meg regulator from the Coco's transformer
|
||
and rectifiers, but decided not to tempt the gods & demons.
|
||
|
||
-*-
|
||
|
||
30673 12-JUL 20:46 General Information
|
||
RE: 1 Meg problems? (Re: Msg 30651)
|
||
From: DWHILL To: RAGTIMER (NR)
|
||
|
||
I dunno, that really ought to work, feeding the 1 meg reg directly. Check the
|
||
specs on the regulator and the voltage rating on the capacitors, though. I'd
|
||
think that would take some strain off the main regulator quite neatly.
|
||
|
||
As you may have noted in my message to DALEP, I FINALLY got around to doing the
|
||
IRQ diode hack, and am running Xcom9, which is notorious for locking up. Be
|
||
interesting to see if this cures some of my problems.
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30552 7-JUL 21:21 Utilities
|
||
OS-9 Spooler
|
||
From: AARONS To: ALL
|
||
|
||
I'm in search of a spooler to use with CSG IMS database manager, I saw the
|
||
Spool.ar utility in the database but I do not have an assembler. Can someone
|
||
upload an assembled version? Is ther one comercialy available? Where?
|
||
|
||
Also, does anyone know the patch to allow Multi-Vue to Init. in HI-RES mode (80
|
||
colum)?
|
||
|
||
thanks, AARONS
|
||
|
||
-*-
|
||
|
||
30553 7-JUL 21:46 Programmers Den
|
||
SQRT Function in C?
|
||
From: ZACKSESSIONS To: ALL
|
||
|
||
I have the need to use the sqrt() function in C. I have the latest Krieder lib
|
||
from the programmer's den. The docs state that there is an int sqrt(n) function.
|
||
|
||
When I try to link a program using it, I get an unresolved reference. dEd of the
|
||
|
||
clib.l sure enough shows there is no sqrt() function present. What gives?!?
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30605 8-JUL 19:23 Programmers Den
|
||
RE: SQRT Function in C? (Re: Msg 30553)
|
||
From: RAYMAYEUX To: ZACKSESSIONS
|
||
|
||
Did you look in clibt.l? -- Ray
|
||
|
||
-*-
|
||
|
||
30611 8-JUL 19:44 Programmers Den
|
||
RE: SQRT Function in C? (Re: Msg 30605)
|
||
From: ZACKSESSIONS To: RAYMAYEUX
|
||
|
||
Yeah, I'm using clibt.l know trying to use the double version of sqrt(), but
|
||
Mike Sweet reports potential problems with it, as well.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30556 7-JUL 23:00 General Information
|
||
High Horse
|
||
From: XLIONX To: ALL
|
||
|
||
Howdy All,
|
||
|
||
I don't do this very often...so hold tight.
|
||
|
||
Who the heck is PAULSENURIA to come out of nowhere about June 4th and claim the
|
||
RIGHTS to patches for shell v2.1 when they were on the forum with explainations
|
||
in April?
|
||
|
||
The patch to $1313 was from KNOT1 April-19. The patch to $130F was from OS9UGVP
|
||
April-21.
|
||
|
||
I don't mind people saying "For the good of the community I put this info
|
||
together, so here it is." but to claim RIGHTS to it (indignant pause)???
|
||
|
||
Sorry Paul, I don't buy it.
|
||
|
||
-Just blowing some steam.
|
||
|
||
-Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS v2.0) -XLIONX (DELPHI) -mwf
|
||
@SANDV
|
||
|
||
p.s. get used to it.
|
||
|
||
-*-
|
||
|
||
30580 8-JUL 03:53 General Information
|
||
RE: High Horse (Re: Msg 30556)
|
||
From: KNOT1 To: XLIONX
|
||
|
||
Thanks for the credit, Mark.
|
||
|
||
-Jamie (KNOT1)-
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30557 7-JUL 23:01 General Information
|
||
High Horse
|
||
From: XLIONX To: PAULSENIURA (NR)
|
||
|
||
Please see message 30556 -mark
|
||
|
||
-*-
|
||
|
||
30572 8-JUL 03:16 General Information
|
||
music
|
||
From: BRIANWHITE To: ALL
|
||
|
||
Is there anyone willing to photocopy and send me a copy of the Orchestra-90
|
||
documentation??? The docs that come with "Orchestra Master" are really poor and
|
||
|
||
just aren't good enough to write a conversion routine with. Any help would be
|
||
appreciated. Than x!
|
||
|
||
Brian C. White
|
||
P.O. Box 1565
|
||
Esterhazy, Sask.
|
||
S0A 0X0 Canada
|
||
|
||
-*-
|
||
|
||
30582 8-JUL 07:07 Programmers Den
|
||
HINTS ON C COMPILER
|
||
From: ALWAGNER To: ZACKSESSIONS
|
||
|
||
ZACK,
|
||
|
||
I am sure that it is something I am doing wrong, but maybe you can steer me in
|
||
the right direction. When I go to de-arc the subject archive, AR reports that
|
||
it is extracting dc.txt and then proceeds to dislpay all sorts of things on my
|
||
screen. The exact pattern of garbage varies depending on whether I was in a
|
||
window or booted up to a vdg screen. In either case, the system usually
|
||
crashes. If I then reboot and look at the directory of the disk where I
|
||
expected the files, I find a file dc.txt with nothing in it. I have de-arced
|
||
shell+ which I downloaded from DELPHI and had no problem at all. I have read
|
||
and reread the docs on AR and can't find anything I'm doing wrong. As was
|
||
mentioned above I've tried using AR from several different boot configuartions
|
||
and always get similar results. (i.e., shell+, tandy shell, sdisk3, tandy cc3,
|
||
etc.) If you could shed some light on the subject or tell me whom I might ask
|
||
for help I would be very appreciative.
|
||
|
||
Thanks in advance,
|
||
|
||
|
||
AlWagner
|
||
|
||
|
||
-*-
|
||
|
||
30584 8-JUL 11:18 Programmers Den
|
||
RE: HINTS ON C COMPILER (Re: Msg 30582)
|
||
From: ZACKSESSIONS To: ALWAGNER
|
||
|
||
I believe the filename should be hdc.txt, not dc.txt. I'm sorry you are having
|
||
problems getting it de-archived, no one else has reported such a problem with
|
||
that file. How many times did you download the archive? If only once, try
|
||
downloading it again, sometimes that helps. In the meantime, I will download it
|
||
myself, to make sure there are no problems.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30585 8-JUL 11:26 Programmers Den
|
||
RE: HINTS ON C COMPILER (Re: Msg 30582)
|
||
From: ZACKSESSIONS To: ALWAGNER
|
||
|
||
I just downloaded the file and it de-arced just fine. I did get a warning from
|
||
ar that the file was "not archived or damamged", but that message from ar can be
|
||
|
||
ignored. The file is de-arced OK by that time. Try downloading it again.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30594 8-JUL 15:29 Programmers Den
|
||
RE: HINTS ON C COMPILER (Re: Msg 30585)
|
||
From: ALWAGNER To: ZACKSESSIONS
|
||
|
||
Thanks for taking the time to check out the file. As I said, Its got to be
|
||
something I'm doing. Just what that is I'm not sure. I did try down loading
|
||
the file more than once with similar results. I'll try again and let you know
|
||
how I make out.
|
||
|
||
Thanks again,
|
||
|
||
AlWagner
|
||
|
||
-*-
|
||
|
||
30603 8-JUL 17:57 Programmers Den
|
||
RE: HINTS ON C COMPILER (Re: Msg 30594)
|
||
From: ALWAGNER To: ZACKSESSIONS
|
||
|
||
I knew it was something I was doing! The problem came from a source you could
|
||
not have known about. Until this logon I was using MIKEYTERM. A good program
|
||
but not OS9. This meant that I had to convert everthing to OS9 before I could
|
||
use it. Well, the conversion I was misusing was hacking off the beginning of
|
||
the file. Hence the "dc.txt" rather than "hdc.txt". This last go 'round I tried
|
||
|
||
a different convert utility and presto-changeo it worked perfectly! I did
|
||
notice the error message you warned me about, but as you said it did not seem
|
||
to matter. Thanks again for your time and efforts.
|
||
|
||
AlWagner
|
||
|
||
|
||
-*-
|
||
|
||
30609 8-JUL 19:42 Programmers Den
|
||
RE: HINTS ON C COMPILER (Re: Msg 30603)
|
||
From: ZACKSESSIONS To: ALWAGNER (NR)
|
||
|
||
You might want to consider downloading OSTerm, SuperComm, or even KBCom, from
|
||
the libs. Of course you'll need a RS232 if to use any of them.
|
||
|
||
Zack
|
||
|
||
ps, glad you got it de-arced OK. btw, I have made some improvements to that file
|
||
|
||
and plan to re-upload it. WIll post a notice in the Forum when it's done.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30589 8-JUL 12:03 General Information
|
||
Hardware help needed
|
||
From: WB4GCS To: ALL
|
||
|
||
I have a J&M disk controller which I bought at a flea market. It appears to
|
||
have a parallel port in addition to the disk prot (which works fine!) Does
|
||
anyone have pinout and/or device driver information for the parallel port? Sure
|
||
would be nice to get away from the bit banger. How about a schematic on this
|
||
thing?
|
||
|
||
All help gratefully appreciated. 73, Jim wb4gcs
|
||
|
||
-*-
|
||
|
||
30601 8-JUL 17:55 General Information
|
||
RE: Hardware help needed (Re: Msg 30589)
|
||
From: DODGECOLT To: WB4GCS
|
||
|
||
Try looking in the Device Drivers database for a driver for that controller.
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30596 8-JUL 16:28 Programmers Den
|
||
still sqrt() problems
|
||
From: ZACKSESSIONS To: ALL
|
||
|
||
OK, I am now using clibt.l. So how come the following program:
|
||
|
||
#include <stdio.h> main() {
|
||
double x, y;
|
||
pffinit();
|
||
x = 36;
|
||
y = sqrt(x);
|
||
printf("The square root of %f is %f\n",x,y); }
|
||
|
||
Gives the following output:
|
||
|
||
The square root of 36.000000 is 0.000000
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30602 8-JUL 17:57 Programmers Den
|
||
RE: still sqrt() problems (Re: Msg 30596)
|
||
From: DODGECOLT To: ZACKSESSIONS
|
||
|
||
Zack- try declaring the sqrt() function to double first- as the code you gave us
|
||
|
||
stands, the compiler will think that sqrt() returns an int...
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30604 8-JUL 18:14 Programmers Den
|
||
RE: still sqrt() problems (Re: Msg 30602)
|
||
From: DODGECOLT To: ZACKSESSIONS
|
||
|
||
Geez, I just tried getting the square roots of the first 100 numbers, and got
|
||
garbage results... Interesting, though, how the square root of 93 is
|
||
1389796441404211185.810524!
|
||
:) Carl only frequents CIS, right? Look like there _might_ be a _slight_
|
||
problem with that function!
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
30608 8-JUL 19:40 Programmers Den
|
||
RE: still sqrt() problems (Re: Msg 30602)
|
||
From: ZACKSESSIONS To: DODGECOLT
|
||
|
||
Thanks, Mike, Pete Lyall mentions the same thing.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30610 8-JUL 19:43 Programmers Den
|
||
RE: still sqrt() problems (Re: Msg 30604)
|
||
From: ZACKSESSIONS To: DODGECOLT
|
||
|
||
Uh, oh! I haven't tried the double declaration, yet, but will. If I encounter
|
||
similar problems, I will contact Carl and let him know of the problems!
|
||
|
||
Good eye!
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30624 9-JUL 18:13 Programmers Den
|
||
RE: still sqrt() problems (Re: Msg 30610)
|
||
From: DODGECOLT To: ZACKSESSIONS
|
||
|
||
Boy, now I can't even duplicate <my> problems! After playing around with the
|
||
pow() function, I then tried to use the sqrt() function again to see if I could
|
||
find a pattern... Of course it just happened to work perfectly... I hate
|
||
problems that come and go randomly!
|
||
-Mike
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30606 8-JUL 19:31 Device Drivers
|
||
Any RAM Disks larger than 512K?
|
||
From: RADARBUZZ To: ALL
|
||
|
||
Attention:
|
||
|
||
If there is anybody out there that can set up a ramdisk larger than 512K,
|
||
please let me know what driver you are using. Thanx
|
||
|
||
-Jeff
|
||
|
||
|
||
-*-
|
||
|
||
30689 13-JUL 20:55 Device Drivers
|
||
RE: Any RAM Disks larger than 512K? (Re: Msg 30606)
|
||
From: DENNYSKALA To: RADARBUZZ (NR)
|
||
|
||
|
||
I don't know of any ramdisks that create > 512k ramdisks. However, I am the
|
||
author of the one which Microcom sells/packages with their memory boards. I was
|
||
|
||
considering fixing it to recognize the additional memory --- until I realized
|
||
that I would have no way of testing it myself. It should be a fairly easy fix,
|
||
and I expect eventually that someone will complain that it won't do the extra
|
||
Disto memory, so I suppose I should fix the thing. If you would be interested
|
||
in Beta testing a fixed version, let me know in email. It might take a few
|
||
go-arounds and some upload/download time to get it right.
|
||
|
||
***** Dennis *****
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30616 8-JUL 22:21 General Information
|
||
gime
|
||
From: RADICAL To: ZACKSESSIONS
|
||
|
||
How do you know if the coco has a new or old gime? Len
|
||
|
||
|
||
-*-
|
||
|
||
30618 8-JUL 23:08 General Information
|
||
RE: gime (Re: Msg 30616)
|
||
From: ZACKSESSIONS To: RADICAL
|
||
|
||
Well, ya gotta void the warrenty (if it is still applicable) and open up the
|
||
case. If the GIME has a date of 1987 on it, it the newest one available.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
30634 10-JUL 00:57 General Information
|
||
RE: gime (Re: Msg 30618)
|
||
From: RADICAL To: ZACKSESSIONS
|
||
|
||
Thanks, my warranty was voided long ago. I will check the date when I install
|
||
the 1 meg. Thanks. Len
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30626 9-JUL 21:55 General Information
|
||
GFX2 & MM/1
|
||
From: COLINMCKAY To: OS9UGPRES
|
||
|
||
Hi, Kev, and Paul.
|
||
|
||
Just a suggestion that others might find useful with the new GFX2
|
||
module you uploaded. Rename it to GFX3, as well as patching it and
|
||
updating the CRC, and you can continue using GFX2 and its calls.
|
||
Naturally, you now have to call it using RUN GFX3.
|
||
|
||
Anyway, thanks for releasing it. Appreciated by all locally.
|
||
|
||
Also have a few questions about the MM/1 (Oh, no. Not more questions
|
||
about the MM/1 <Grin!>)
|
||
|
||
The VSC chip (SCC66470) normally arbitrates access to the first meg of
|
||
memory that the VSC chip and the 68070 share. When the 68070 gets its
|
||
own 2 or 8 megs of memory, and the VSC no longer has to do arbitration,
|
||
does this then speed up the VSC chip? Or does the VSC continue doing
|
||
arbitration all the time?
|
||
|
||
A few people on the International CoCo and OS9 echoes have mentioned
|
||
that they have seen demos of the MM/1. Amongst other things, they
|
||
mentioned seeing 320*200*256 GIF files loading in "under one second"!
|
||
Are these amazing numbers accurate? Or was that some other format?
|
||
|
||
Any recommendations on monitors? I currently have a CM-8, but also need
|
||
a PC compatable monitor for working at home. I was considering buying
|
||
the NEC 2A. Its specs match fairly well the MM/1.
|
||
|
||
Alan Dekok wonders if you have seen his demo (CC3DEMO) which runs
|
||
under RSDOS. (He just called as I was writing this letter.) Bouncing,
|
||
spinning ball, four voice music, 1 inch high scrolling text across the
|
||
bottom of the screen. Pretty impressive, especially since it holds
|
||
about five minutes of text. Its over on the RSDOS side.
|
||
|
||
Also, the specs for the VSC chip make it appear to be almost trivial to
|
||
create a frame grabber. Any word on this? And GenLock also appears to be
|
||
trivial on this machine, at least the computer end. Any chance?
|
||
|
||
Does the second board come with the 2 meg of memory on board already?
|
||
|
||
Matt Thompson pointed out that it should be possible to have Microsoft
|
||
FlightSim V4.0 running using 100% legal system calls. That would be
|
||
impressive.
|
||
|
||
Finally, could you please detail exactly which resolutions are supported?
|
||
Some of the literature from KLE (MM/1 ad, July Rainbow) says 720*560 is
|
||
supported, while other literature mentions only (Only!) 720*480.
|
||
|
||
Thanks for your time.
|
||
|
||
Colin McKay.
|
||
|
||
|
||
|
||
-*-
|
||
|
||
30632 9-JUL 23:28 General Information
|
||
RE: GFX2 & MM/1 (Re: Msg 30626)
|
||
From: TIMKOONCE To: COLINMCKAY
|
||
|
||
From earlier messages, it is the case that the CPU speeds up if it's not
|
||
competing with the VSC for memory. i.e. getting more mem approx doubles the
|
||
speed of the machine. Don't know what you mean by the "VSC speeding up". Kind
|
||
of like asking if the GIME speeds up.
|
||
- Tim
|
||
|
||
-*-
|
||
|
||
30639 10-JUL 02:58 General Information
|
||
RE: GFX2 & MM/1 (Re: Msg 30626)
|
||
From: OS9UGPRES To: COLINMCKAY
|
||
|
||
Colin,
|
||
|
||
No need to rename the new gfx2 to gfx3, as it has all the original gfx2 commands
|
||
|
||
in it. However, I just popped in and read my mail, and someone said that a few
|
||
of the original gfx2 commands didn't work... has anyone else seen any problems?
|
||
Maybe I compiled in a bug <ouch> by accident.
|
||
|
||
Re: MM/1, VSC, etc -
|
||
|
||
When you add more memory, the cpu will no longer have to run programs from the
|
||
video ram. That immediately gives you roughly a 20% (or more) speed increase, I
|
||
think. Visible increase, that's for sure. Someone oughta rig up the same trick
|
||
on the coco (external ram or something).
|
||
|
||
Yah, the fast picture loads people see in demos are definitely not realtime GIF
|
||
conversions, but raw vef-style data. Right now, the GIF converter (written by
|
||
Mike Haaland for us) sends the data to standard output. That works pretty well,
|
||
as you can send it to a file, or pipe it straight to a picture loader/viewer.
|
||
|
||
Pictures are 64K long, so they can take a while to load off floppy, albeit
|
||
faster than the coco. Still, the DMA harddisk *really* screams loading in pics.
|
||
And you should have no problem loading in most sound files faster than the DMA
|
||
stereo sound hardware can play it, even off floppy.
|
||
|
||
I've heard lots about that CCDEMO, but it won't run on my computer (I hear
|
||
that's not unusual). Would love to see it sometime.
|
||
|
||
Any framegrabber will be external, I think. A genlock tho, we hope to plug into
|
||
the main board.
|
||
|
||
I don't think the second board comes with RAM (I could be wrong). Before long,
|
||
4-meg SIMMS will be pretty darned cheap, and I suspect the wilder types will
|
||
want to go straight to 9 meg ;-).
|
||
|
||
Both the FHL and the KLE video spec sheets seem to change all the time <grin>.
|
||
See, in PAL mode (overseas TV, versus the US's NTSC), you can go up to 768x560
|
||
or so. For us, it'll top out at 720x480... which will actually be our worldwide
|
||
standard, as the chip supports a PAL mode which allows viewing the smaller NTSC
|
||
resolution gfx (centered on screen).
|
||
|
||
So figure on 320x210, 320x420, 360x210, 360x420, 640x210, 640x420, 720x210, and
|
||
720x420 modes... where the 360/720 x-modes go from edge to edge and over (for
|
||
video overlays where you don't want a border). Actually, some monitors can show
|
||
the whole deal... the 720x480 gives you 90x60 char (8x8) text! However, the
|
||
flicker can be a killer in that mode, at least to me (depending on the colors
|
||
chosen). - kev
|
||
|
||
-*-
|
||
|
||
30674 12-JUL 20:53 General Information
|
||
RE: GFX2 & MM/1 (Re: Msg 30626)
|
||
From: DWHILL To: COLINMCKAY
|
||
|
||
Those superfast load time for graphics ought to be accurate, as the 68070 has
|
||
DMA and can move blocks of data darnfast! I need to pester Phillips for spec
|
||
sheets on it and the graphics chips to find out more, but I think the
|
||
performance is going to be very impressive, should give the '386 machines
|
||
something to be jealous of!
|
||
|
||
--Damon
|
||
|
||
-*-
|
||
|
||
30680 12-JUL 22:35 General Information
|
||
RE: GFX2 & MM/1 (Re: Msg 30674)
|
||
From: COLINMCKAY To: DWHILL (NR)
|
||
|
||
I was impressed by the speed, just the messages that I saw implied that they
|
||
were compressed GIF pictures. That really would have been an impressive feat.
|
||
However, loading 64k vef type files in that little time is quite impres
|
||
sive
|
||
too.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30628 9-JUL 22:35 Applications
|
||
name and address pgm
|
||
From: CAPTSWOOSH To: ALL
|
||
|
||
hey gang is there a free ware name and address database label pgm out there?
|
||
that is ready to run?? Ron done
|
||
|
||
-*-
|
||
|
||
30630 9-JUL 23:25 Programmers Den
|
||
Speeding up the coco3
|
||
From: NES To: ALL
|
||
|
||
Here is a queston for you hardware hacker's, could I increase the cpu's speed of
|
||
|
||
the coco3 closer to 2Mhz or over, by add a new crystal, or would it screw the
|
||
video and disk? BTW I am useing a CM-8 if that makes any diffrence... also a
|
||
burk and burk harddrive.. Eric -<NES>-
|
||
|
||
-*-
|
||
|
||
30633 9-JUL 23:31 Programmers Den
|
||
RE: Speeding up the coco3 (Re: Msg 30630)
|
||
From: TIMKOONCE To: NES (NR)
|
||
|
||
The Video frequency is generated by the same clock that generates the system
|
||
frequency. So, no, you can't just change the crystal. Speeding up the processor
|
||
|
||
would require some fairly elaborate circuitry to handle the speed difference
|
||
between the processor and the GIME, since you can't change the GIME speed
|
||
without messing up the video.
|
||
The disk controller uses a separate crystal for it's clock, so that's not the
|
||
issue.
|
||
Why do you want to get "closer to 2Mhz"?? 1.89 is pretty durn close already.
|
||
- Tim K
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30642 10-JUL 16:36 Device Drivers
|
||
COCO2 WORD PROCESSORS!
|
||
From: DKIRCHER To: ALL
|
||
|
||
Help! I have a COCO2 system that is running WORDPAK RS and I am looking for a
|
||
WORD PROCESSOR that will work with it. I already have older versions of
|
||
STYLOGRAPH and LASTWORD that use those graphics drivers or WORDPAK.
|
||
Does anyone have an updated version they would like to sell or perhaps maybe
|
||
know of a patch that will do the trick.
|
||
If someone has a WORKPAK they'd like to part with that'll work too
|
||
thanx
|
||
dlk
|
||
|
||
-*-
|
||
|
||
30643 10-JUL 16:42 General Information
|
||
Upgrading Coco II
|
||
From: DKIRCHER To: ALL
|
||
|
||
I just fired up my old gray coco and found out that coco is a collectors item.
|
||
|
||
So I have found two other coco IIs as backups for when the parts really dry up.
|
||
I would like to know how to
|
||
get these two guys up to speed for disk operation. Is an ECB upgrade all they
|
||
need to accept a disk controller? Radio Shack was not very much help.
|
||
|
||
-*-
|
||
|
||
30668 12-JUL 02:16 General Information
|
||
RE: Upgrading Coco II (Re: Msg 30643)
|
||
From: WAYNELAIRD To: DKIRCHER
|
||
|
||
dk, what can help is downloading and using the dmode utility by K.darling. works
|
||
|
||
good on the two as well as the three. this canspeed up your disk access time to
|
||
6ms. best ,wayne
|
||
|
||
-*-
|
||
|
||
30669 12-JUL 03:22 General Information
|
||
RE: Upgrading Coco II (Re: Msg 30668)
|
||
From: DKIRCHER To: WAYNELAIRD (NR)
|
||
|
||
Oh No, the prob here is the cocos aren't seeing the controller in the port I'll
|
||
plug it all in and fire it up but only get a COLOR BASIC prompt. So I presume
|
||
that they must have ECB before they will "see" the disk controller to access
|
||
DISK COLOR BASIC.
|
||
I've been flogging my poor old drives with the debug patch for some time now.
|
||
|
||
-*-
|
||
|
||
30670 12-JUL 03:40 General Information
|
||
RE: Upgrading Coco II (Re: Msg 30669)
|
||
From: DKIRCHER To: ALL
|
||
|
||
Alright, The old ECB roms have all sold out. I'm gonna take the plunge and
|
||
eprom my own. Having never done this I have three questions.
|
||
Is all this necessary to get the disk controller to work
|
||
I'm dealing with both the old and the new Korean coco's and I've
|
||
noticed that one has a CB rom and an empty sockett and the other
|
||
has a CB rom in a socket. Is the upgrade for the two of them to ECB
|
||
the same.
|
||
Last question: I have no desire to EVER mess with CB or ECB again after
|
||
playing with basic09 it's just not the same. So as long as I'm playing with
|
||
EPROMS why not prom os9 and be done with it. Assuming this is possible without
|
||
too many contortions how would one go about this. Thanks for your help dlk
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30652 10-JUL 22:20 General Information
|
||
GFX2/MM/1
|
||
From: COLINMCKAY To: OS9UGPRES (NR)
|
||
|
||
Hi Kevin.
|
||
|
||
About renaming GFX2 to GFX3: I was bitten by one of those bugs, and without
|
||
thinking, automatically decided to rename. I was running depthcharge, and
|
||
it quit with an error which I assumed was caused by GFX2 commands not being
|
||
found. Ran it with the old GFX2, and it worked, so I renamed/patched the new
|
||
module to GFX3. Will try to duplicate the error if you wish.
|
||
|
||
Unfortunate that the raw picture files weren't gifs. That woulda been REAL
|
||
impressive. C'est la vie. Glad to hear there will be a gif converter available
|
||
tho.
|
||
|
||
Eagerly looking forward to the arrival of the new machine.
|
||
|
||
TTFN. Colin.
|
||
|
||
|
||
-*-
|
||
|
||
30655 11-JUL 01:09 Telcom
|
||
Hardware Downloading Problems
|
||
From: THET To: ALL
|
||
|
||
I don't know if this question has been answered or not, but I figure it's
|
||
better to ask than take a lot of time reading a lot of messages. Here's the
|
||
problem:
|
||
I have added an ACIA 6551 board to my CoCo 3 (from the May 1989 Rainbow)
|
||
and now I can use OS9 to telecommunicate just fine from the bit-banger port
|
||
with no problems except one. I can't download! I am using Supercomm v2.1 and
|
||
a 1200 baud modem. I have tried it with a friend of mine's computer with Procomm
|
||
|
||
+ which I know works, and severa;l bulleten boards and DELPHI and I get the same
|
||
|
||
results, the fi rst block goes fine, but after that all I get is errors.
|
||
This happens with Xmodem, Ymodem, and Ymodem batch, and Kermit. The really
|
||
strange part is that using Gregterm unter RSDOS Xmodem works fine, but the
|
||
program usually crashes the machine after a download right after I save the
|
||
buffer to disk. Any solutions. Please answer as having a modem but being
|
||
unable to download can be a drag!!
|
||
Thanks.
|
||
|
||
-*-
|
||
|
||
30657 11-JUL 03:58 Telcom
|
||
FIDO Hawaii
|
||
From: TOMMIETAYLOR To: ALL
|
||
|
||
Hawaii Coco Users, Coconuts bbs Of Hawaii now supports FIDO International Mail
|
||
service. 808-845-7054 300-2400 baud...
|
||
|
||
-*-
|
||
|
||
30659 11-JUL 20:31 Programmers Den
|
||
boot disk
|
||
From: DCJR To: RADICAL
|
||
|
||
Actually, I *should* have said booted with a double-sided descriptor. Using
|
||
dmode gave the same result. BUT, the other point I needed to emphasize is that
|
||
there MUST be a cmds dir on the boot disk with shell and grfdrv in it.
|
||
|
||
Doug James
|
||
|
||
-*-
|
||
|
||
30665 12-JUL 00:55 Program RE: boot disk (Re: Msg 30659)
|
||
From: RADICAL To: DCJR
|
||
|
||
Too bad you can't underline that and put it all in capitals. I found out early
|
||
in the game, but screamed for help many times before catching on. Left /dd out
|
||
of the confgaooc,n n myself in circk opps circles trying to find
|
||
out what was wrong. Len
|
||
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30664 11-JUL 22:25 Patches
|
||
step Rates
|
||
From: JANG To: DISTO (NR)
|
||
|
||
Hello Tony,
|
||
I just installed a Seagate ST-125 3.5" 20 Megger under Level II and it is
|
||
working fine with your "Hard Disk Adapter".. in slot#3 I also run my 2 floppies
|
||
with your SC II and it has your clock now too!!! The question is this: Using
|
||
"HardwareHackers" DMode /h0 I see I have a step rate there of step=0.. The
|
||
ST-125 Manual says it will accept step rates 3-200. Any attempt on my part to
|
||
dmode /h0 (higher step rate) results in errors although step=7 worked OK for a
|
||
while and the thing flew!! I have EZGen and ded, but can you offer any other
|
||
course of action here ??
|
||
J.Angus
|
||
Levittown,NY
|
||
|
||
-*-
|
||
|
||
30666 12-JUL 01:01 Device Drivers
|
||
clock
|
||
From: RADICAL T my controller back and all is working fine. Just
|
||
wanted to know about the clock as I do not have your catalog. Len
|
||
|
||
-*-
|
||
|
||
306J :1GeaIfmto E BTOESI(eMg01) Fo:ANAR T:SBR(Rl h apswnyur ?Hvyuopr hmdl norhrdv o?a at rgti cn c3mn ys id.bs,ye
|
||
|
||
-
|
||
|
||
0671 12-JUL 20:03 General Information
|
||
Windows under level II...
|
||
From: ALANDEKOK To: ALL
|
||
|
||
I was wondering if anyone could help me.... I have a Basic09 program that
|
||
defines 2 output graphics windows (ala Kevins bouncing ball demo), but it
|
||
doesn't seem to work quite right. Here's the code, and an explanation of what
|
||
happens.
|
||
|
||
OPEN #W1,"/w"
|
||
OPEN #W2,"/w"
|
||
String=CHR$( 1b 20 08 00 28 18 0f 00 00 (* new device window 320x192x16 colors
|
||
|
||
PUT #W1,String
|
||
PUT #W2,String
|
||
|
||
This works fine the first few times I try it, but as I'm adding/debugging the
|
||
program, the above code gets executed many many times.
|
||
|
||
The problem is, after a while, I get an ERROR 184 (window already defined) on
|
||
the first PUT statement. Is there anything I can do about this?? Or what am I
|
||
doing wrong? The manuals seem to say that this is all legal, but my system
|
||
doesn't like it.
|
||
|
||
Alan DeKok.
|
||
|
||
-*-
|
||
|
||
30675 12-JUL 21:02 General Information
|
||
RE: Windows under level II... (Re: Msg 30671)
|
||
From: GREGL To: ALANDEKOK
|
||
|
||
Alan,
|
||
|
||
You need to DWEnd and close the windows at the end of the program. Otherwise
|
||
|
||
you'll use all of the descriptors and the program will quit working. If all the
|
||
descriptors are used (all windows are in use), you obviously can't use any
|
||
others.
|
||
|
||
-- Greg
|
||
|
||
-*-
|
||
|
||
30681 12-JUL 23:11 General Information
|
||
RE: Windows under level II... (Re: Msg 30675)
|
||
From: ALANDEKOK To: GREGL
|
||
|
||
Yeah, I just figured that out. Boy do I feel dumb. When I took a look at it
|
||
(via DDIR), I saw it was consistently trying for the same two windows, which
|
||
were left over from its LAST failed attempt, and it didn't like that one bit.
|
||
|
||
Anyways, I've now got the DWend and CLOSE in there, and it seems to work better
|
||
|
||
already! (grin)
|
||
|
||
Alan DeKok.
|
||
|
||
-*-
|
||
|
||
30682 12-JUL 23:14 General Information
|
||
RE: Windows under level II... (Re: Msg 30681)
|
||
From: ZACKSESSIONS To: ALANDEKOK (NR)
|
||
|
||
To be safe, I always DWEnd a new window I just opened a path to before I try to
|
||
DWSet it. Seems to work just fine.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
&@Y6 L-ULR"
|
||
!M5R$H jRPU$
|
||
$ HHI=5iRJjH "uK KSCALES
|
||
|
||
Hi Ken-
|
||
I tried your SASI Driver Patch and have trouble booting with it. I use the HDA
|
||
in Slot # 3 for my ST-125(20Meg) and Later added the SC II and use cc3disk.slp
|
||
there. I patched my current cchdisk($A50917) and did the attr e pe on it and
|
||
then EZGen'd it into
|
||
a backup of my boot and everything seemed to go well..but
|
||
no boot !! Is the MPI upgrade neccessary?? any suggestions???
|
||
Jerry Angus
|
||
|
||
|
||
-*-
|
||
|
||
30677 12-JUL 21:28 Graphics & Music
|
||
RE: Who did "VEFIO" ? (Re: Msg 29872)
|
||
From: THEFERRET To: TIMKOONCE (NR)
|
||
|
||
I would like something that I could use in a P.D. Graphics editor. (Yes I know
|
||
|
||
Max-9 is out here, but mine is better, so there!) I just can't get bvefio to
|
||
work for me, apart from using the + option
|
||
Ug
|
||
|
||
-*-
|
||
|
||
30683 12-JUL 23:16 Graphics & Music
|
||
RE: Who did "VEFIO" ? (Re: Msg 30677)
|
||
From: ZACKSESSIONS To: THEFERRET
|
||
|
||
VEFIO was written by Ron Lammardo. He is not on Delphi, but is on CIS.
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30679 12-JUL 22:06 Patches
|
||
b&b + PBJ CC-BUS
|
||
From: SALZARD To: ALL
|
||
|
||
Has anyone successfully mated Burke and Burke's Hard Drive interface with the
|
||
PBJ CC-Bus (six slot multipak)???? Need a patch to BBFHDISK so that it can find
|
||
|
||
the slot that the interface is plugged into.
|
||
|
||
-*-
|
||
|
||
30685 12-JUL 23:28 General Information
|
||
Shell+ 2.1 patches
|
||
From: XLIONX To: ZACKSESSIONS
|
||
|
||
Howdy Zack, Please read message# 30556 and let me know if you think I am
|
||
justified in my rantings. ];->
|
||
|
||
-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS) -XLIONX
|
||
(DELPHI) mwf@SANDV
|
||
|
||
-*-
|
||
|
||
30688 13-JUL 19:19 General Information
|
||
RE: Shell+ 2.1 patches (Re: Msg 30685)
|
||
From: ZACKSESSIONS To: XLIONX (NR)
|
||
|
||
I read the message just after you posted it. I haven't downloaded that file you
|
||
mention, but judging from you comments, I certainly feel you're justified. I
|
||
will download the file and follow up on it.
|
||
|
||
Zack
|
||
|
||
-*-
|
||
|
||
End of Thread.
|
||
|
||
-*-
|
||
|
||
30687 13-JUL 01:20 Telcom
|
||
os9bbs
|
||
From: EMTWO To: ZACKSESSIONS
|
||
|
||
Zack WE got Both your accounts set up<grin>. I will email you with your
|
||
passwords.
|
||
|
||
-*-
|
||
|
||
|
||
FORUM>Reply, Add, Read, "?" or Exit> bye
|
||
I don't understand the term "HBYE" in this context.
|
||
You may enter ? to view the full menu.
|
||
|
||
FORUM>Reply, Add, Read, "?" or Exit> bye
|
||
Highest message read: 30691.
|