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

963 lines
32 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
29185 1-MAY 00:45 Patches
TSWORD
From: VE3DAC To: OS9UGVP
tHi Bruce.
We met on the last day of the Fest in Chicago and discussed my problem with
Vshell in TSWORD and Shell2.1. I see from some messages that another program
suffered from the same problem. The patch from Jamie (KNOT1) worked fine so the
TSWORD package is ok under Shell 2.1. It is curious that you were close to the
1313 offset that Jamie used, I wonder what you were looking at. The code there
doesn't make much sense to me (but that isn't difficult to do.) Anyway thanks
for the help.
After I made the change I found that the dsort util. wouldn't work and maybe
there are others that need the memory assigned by Shellplus. So I guess the
thing to do is just make the change as required by TSWord and change it back
when I'm done.
Merv.
-*-
29194 1-MAY 22:30 Patches
RE: TSWORD (Re: Msg 29185)
From: OS9UGVP To: VE3DAC (NR)
Merv,
Actually, I was wrong... the $1313 offset is what I should have said. I was
looking at the " cmpb #31" instruction just a little bit ahead of the " ldb #31"
instruction... no, wait a minute... I think I was right.
I'm going to try to think/type this through right here... what the code does
is check to see if the default memory is >= 31 pages. If so, it skips past the
" ldb #31" instruction, which sets the minimum memory to 31 pages.
Instead of changing the " ldb #31" instruction, you *DO* want to change the "
cmpb #31" instruction to " cmpb #1". As a matter of fact, you can change both
instructions to " cmpb #1" and " ldb #1". That will fix your dsort problem too,
most probably.
So the changes are:
offset ! old byte ! new byte
-------+----------+---------
$130F ! $1F ! $01
$1313 ! $1F ! $01
Don't forget to fix the CRC, and once you're done these patches should fix you
up so both dsort and should fix you up so both dsort and tsword work. The only
potential problem is if you use wilcards and try to expand a line thats too
long.
Bruce
-*-
29204 2-MAY 03:21 Patches
RE: TSWORD (Re: Msg 29185)
From: KNOT1 To: VE3DAC (NR)
Hi, Merv. Any program having a problem do to the patch should work as before if
you use "#31" (no "K") when executing the program. You could probably also make
that permanent by patching its data size. Then you shouldn't need to change it
back and forth, which isn't really "proper" when multi-tasking.
-Jamie Wilmoth (KNOT1)-
-*-
29206 2-MAY 03:23 Patches
RE: TSWORD (Re: Msg 29194)
From: KNOT1 To: OS9UGVP
It shouldn't matter if the value ends up being "too low," because that value is
only the size of the _optional_ data area. F$Fork will use either the module's
internal data size or the _optional_ size provided, whichever is larger. Thus a
zero _optional_ size will result in the module's data size always being used.
If that causes a problem, then that means the module's internal data size is set
too low (possibly tested under Shell+, where that wouldn't cause a problem). I
suspect that changing both bytes will still result in the same problems
occurring. But if changing both bytes DOES fix it, then I would like to know.
Thanks.
-Jamie Wilmoth (KNOT1)-
-*-
29217 2-MAY 22:07 Patches
RE: TSWORD (Re: Msg 29206)
From: OS9UGVP To: KNOT1
Jamie,
I thought this particular test in Shell+ V2.1 was to test whether the larger
of the optional or default data area was less than 31 pages, in which case
Shell+ V2.1 would give the 31 pages as a minimum? Oh well... its been a long
time since I looked at it. Its definitely worth a try, but on a backup only.
No reason to take a chance when I'm not sure!
Bruce
-*-
29225 3-MAY 03:33 Patches
RE: TSWORD (Re: Msg 29217)
From: KNOT1 To: OS9UGVP (NR)
Ah Ha! Based on your comment, I did some testing, and figured out a little
better what is going on. That test seems to be comparing what amount of memory
the user requested, and if it was less than 31 pages, it would make it 31 pages.
So here is what happens with only the one change that I made, and not both.
First, without any modifier:
OS9:procs
User Mem Stack
Id PId Number Pty Age Sts Signl Siz Ptr Primary Module
--- --- ------- --- --- --- ----- --- ----- ----------------
8 0 0 128 131 $80 0 31 $4BE2 Shell
12 8 0 128 128 $80 0 6 $05F3 Procs
Note that "procs" Memory Size is 6 pages. Next:
OS9:procs #34
12 8 0 128 128 $80 0 34 $21F3 Procs
Just fine; Mem Siz = 34. But now:
OS9:procs #30
12 8 0 128 128 $80 0 6 $05F3 Procs
Hey! Only 6 pages, not 30! What I believe is happening is that it is still
comparing what the user requested to 31 pages, but if it is less than that it
now sets it to zero, insted of 31. Thus, if the user requests from #1 to #30 it
isn't used. But all else still works normally. So, if the compare is changed
to zero, also, it should work as expected. But that shouldn't cause those
programs that need more memory to work. You should still need to use "#31" to
make them work, as far as I can tell. I havn't tried patching the other byte
yet. I'll let you know how it goes when I do.
-Jamie Wilmoth (KNOT1)-
-*-
End of Thread.
-*-
29186 1-MAY 06:40 General Information
RE: opps.................. (Re: Msg 29182)
From: ENDOTSON To: GREGL
Hmmm, i may be lost. I was assuming that i would have to rebuild the info in
0-31 since that is where the original id sector and root directory would have
been.
As for the "one track format", i was just thinking in terms of making anything
(data wise) that might still be there visible to ded. For instance, to dump
to the printer like you said. As it is, not even ded can look at 0-31. I
figured a logical only format would build back enough of a "roadmap" for ded
to at least see whats left.
ttfn
-*-
29195 1-MAY 22:38 General Information
RE: opps.................. (Re: Msg 29186)
From: GREGL To: ENDOTSON (NR)
Ernest,
I just wanted to make sure you knew that the sector allocation bit map is
not always the same size. That is, there is one bit in the allocation bit map
for each sector on the drive. So, when you reformat the drive using only one
cylinder the sector allocation bit map will only occupy 4 bytes (one sector)
placing the root directory at LSN 2. ID Sector at LSN 0, allocation bit map at
LSN 1, Root directory at LSN 2. Right now your root directory is likely at LSN
32 or thereabouts.
You probably already knew that but I just wanted to make sure. Lots of folks
I've talked to have assumed that the root directory was always at the same spot
on the disk.
-- Greg
-*-
End of Thread.
-*-
29187 1-MAY 18:58 Programmers Den
RE: Descriptor names... (Re: Msg 29183)
From: DCJR To: DWHILL
Currently I use the HDKIT system available in the database here for my backups.
It's slow, but it gets the job done.
I used to use a combination of Pak and the wildcards availble in shell+. The
command:
:pak -a dirname *
will pak all the files in a directory into an archive named "dirname". You can
pull the same trick with ar using ar's internal wildcards.
Doug James(DCJR)
-*-
29201 2-MAY 00:38 Programmers Den
RE: Descriptor names... (Re: Msg 29187)
From: DWHILL To: DCJR
The only problem with pak is that it's bloody slow at times, but I do use it to
compress large text files to save space on backup disks.
I'm looking at some of the backup utilities, but haven't attempted any of them
as yet. Given the amount of work that I had to put into backup manually, I hope
one of these will give me a more structured method of backup; I might use it
more frequently.
--Damon
-*-
29208 2-MAY 17:35 Programmers Den
RE: Descriptor names... (Re: Msg 29201)
From: DCJR To: DWHILL (NR)
Pak works a lot faster if you pak into a ramdisk. I try to do that whenever
possible.
-*-
End of Thread.
-*-
29188 1-MAY 20:15 Telcom
ACIA pak and modem
From: KHB To: ALL
Help. I am writing an autodialer program in C, and cannot seem to get the
serial port initialized. I can open a path to /t2 and send the dialing
commands, but it doesn't do anything. If I've got OSTerm running in another
window, which has already initialized the modem, it works. To get it to work in
a previous Basic09 version, I had to poke directly into the PAK registers. So,
how do you do this?
Also, the modem has never worked right in this setup either. It won't give me
the little OK prompt unless I escape to it while there is a carrier detect. I
also can't recieve any of the modems little messages like RING or anything. By
the way, I am using a Delta Gold 1200 modem.
Any help would be greatly appreciated. Thanx.
-Ken Brunell
<KHB>
-*-
29189 1-MAY 20:30 Telcom
RE: ACIA pak and modem (Re: Msg 29188)
From: TRIX To: KHB
Part of the problem (the modem messages) is due to the RS-232 Pak. You see, it
ignores any characters sent to it if no carrier is present. About the only
choices you have for your autodialer are:
A) Set DCD from the modem to always be high and interpret the modem messages.
B) Leave DCD true, dump the dial string out to the modem, wait for DCD to go
high, and pray for the best.
Hope it helps.
-John.
-*-
29203 2-MAY 01:26 Telcom
RE: ACIA pak and modem (Re: Msg 29189)
From: KHB To: TRIX
Ok, thanks. That sheds a little light on the situation. But, I don't think
that takes care of the other problem: how do I initialize the port from C? To
do this in Basic09, like I said, I had to poke directly into the control
registers, but isn't there a proper way to do this? Simply opening a path to /t2
doesn't cut it.
-Ken Brunell
<KHB>
-*-
29205 2-MAY 03:22 Telcom
RE: ACIA pak and modem (Re: Msg 29188)
From: KNOT1 To: KHB
Did you do "iniz /T2" first? You might want to also try one or more of the
following commands (my modem is a SupraModem, but Hayes compatable, so the
commands should be the same):
"AT&C" - Forces the carrier-detect to remain on.
"ATQ" - Causes result codes (e.g. "OK", "RING", etc...) to be returned.
"ATV1" - Causes result codes to be returned as words, not numbers.
"ATX4" - The *works* for dialing/connect result codes (or one of the other
"X" commands).
I hope some of this helps!
-Jamie Wilmoth (KNOT1)-
-*-
29210 2-MAY 20:11 Telcom
RE: ACIA pak and modem (Re: Msg 29205)
From: KHB To: KNOT1
Yep, that did the trick. II tried iniz /t2, and then dialed, and it worked
perfectly. So I used a system call to I_ATTACH to initialize /t2.
Thank you.
-Ken Brunell
<KHB>
-*-
End of Thread.
-*-
29190 1-MAY 21:04 Programmers Den
RE: os9 68k software (Re: Msg 28976)
From: THUNDERFNGRS To: OS9UGPRES
Thanks for the info. I wonder how much runb 68k costs? Also I have a lot of
data stored in comlex variables with several integers What must I do? Will i be
able to write a program that reads them and then wri writes the new converted
type of 32 bit integer? Can I get a basic09 for 68k that will let me read in my
old unpacked basic09 code and recompile the new packed code? And whats so great
about osk if there are no windows?
I bought the insights book and I am not real happy so far because I don't seem
to be learning much that will help me program in basic09 and I do not know
C or assembler. I would like to learn C but from messages I have seen the C
compiler from tandy needs help/patches to run under os9l2 I get the feeling
that you need to know what you are doing to get it going under lii, and
I do not know c . I need a package that is ready to go! I also need $100.
-*-
29199 1-MAY 23:45 Programmers Den
RE: os9 68k software (Re: Msg 29190)
From: BUDDCAR To: THUNDERFNGRS (NR)
Despite the title of the message I gather that you are concerned about Level II
and the Microware "C" compiler. Have no fear it works just dandy. You may be
able to find one at a store heavily discounted. If not it will have to be
special ordered as the C compiler has long been out of store stock. Dumb but
true. Just didn't sell enough copies. The patches you see floating about are
mainly to get C to run from a hard disk or to use a different library or to
compile from a RAM disk. So long as you have two drives you will be able to
plug and go. My old copy, bought back when it first became available works fine
in level I and level II for general duty. Not that I am writing device drivers
or system code. Bob
-*-
29200 2-MAY 00:15 Programmers Den
RE: os9 68k software (Re: Msg 29190)
From: OS9UGPRES To: THUNDERFNGRS (NR)
I don't think you'd have much trouble writing a program to convert old data to
the new size INTEGERs, no. Heck, you could write it now, if you think about it a
bit, I'd bet.
OSK on the new machines does have windows.
Patches for getting going with C are in the libraries, not to mention the
excellent help available on the forums just by asking. I'm still mostly using
Basic and asm, but am trying to learn C now.
There's lots of help all around you. Ask! Go for it! <grin> best - kev
-*-
End of Thread.
-*-
29191 1-MAY 21:53 Programmers Den
RE: C optimization (Re: Msg 24069)
From: CCMAN To: GREGL
Have you tried Phil's Formatter listed under applications on this database? I
have been unable to unPak it with several downloads and tries. Any ideas?
Thanks.
-*-
29196 1-MAY 22:42 Programmers Den
RE: C optimization (Re: Msg 29191)
From: GREGL To: CCMAN (NR)
Ralph,
I don't recall that one offhand but I'll check it out to make sure it's
intact. Have you tried using that utility that strips xmodem pad characters on
it yet?
-- Greg
-*-
End of Thread.
-*-
29192 1-MAY 22:08 General Information
RE: Eliminator problem (Re: Msg 29170)
From: OS9UGVP To: POLTERGEIST
If your manual doesn't have a circuit diagram for that little satellite board,
give FHL a call and bug them. Frank forgot to include it in the manual , like
it was supposed to be. Besides, he has nothing else to do right now anyway!
<GRIN>
Bruce
-*-
29197 1-MAY 22:53 General Information
RE: Eliminator problem (Re: Msg 29192)
From: POLTERGEIST To: OS9UGVP
Ok, Bruce, I'll do that!
By the way, my new 3.5" drive has proven something to me: There does NOT
seem to be anything wrong with the floppy controller on the WD-1002. I figured
that my /D0 drive is the culprit, since it likes to lock out a whole bunch of
sectors when format verifies 'em. Oh well, I should replace the durn thing!
NO problems with the 3.5", though. I formatted 10 disks, and I had NO bad
sectors. <whew>
-*-
End of Thread.
-*-
29193 1-MAY 22:18 General Information
RE: DACIA tech info needed (Re: Msg 29184)
From: OS9UGVP To: POLTERGEIST
Use getstat call $99 (SS.CDSta). It returns a 6551 equivalent status register
byte in register [A], except only DCD (bit 5) and DSR (bit 6) are valid. When
either bit (or both bits) are clear, then DCD and/or DSR is enabled. When the
bit(s) is/are set, then DCD and/or DSR are invalid. For example, if the
SS.CDSta getstat returns [A]=$00, then both DCD and DSR are present (enabled).
If SS.CDSta returns [A]=$60, then both DCD and DSR are missing (disabled). If
it returns [A]=$40, then DSR is enabled but DCD is disabled... wait, thats
wrong... if it returns [A]=$40, then DSR is disabled and DCD is enabled. If it
returns [A]=$20, then DSR is enabled but DCD is disabled. Those 4 combinations
are the only valid possibilities.
Bruce
-*-
29220 2-MAY 23:07 General Information
RE: DACIA tech info needed (Re: Msg 29193)
From: POLTERGEIST To: OS9UGVP (NR)
I tried those out with RiBBS, but alas, no luck. I did some more checking
into it, and I found out that it will handle GetSTT call $28 (ComST) or decimal
130 for M2W. I have an Eliminator version of this, but that didn't work either.
So, I took a closer look. He had the carrier callcode that I mentioned
above, but also has the carrier bitfield, based on the type of RS-232 cable that
you have. For instance, he has one bitfield ($32) if you use a standard RS-232
Pak cable, with pin 6 as DSR, and pin 8 as DCD. Oh, that $32 should be a $20!
I have passed on tech information on DACIA and your system calls to Ron Bihler,
and I'll see what transpires from that. I just have to find the correct values
to put in..
-*-
29223 3-MAY 00:53 General Information
RE: DACIA tech info needed (Re: Msg 29193)
From: POLTERGEIST To: OS9UGVP (NR)
Ok, I may have got the problem solved with my BBS. It seems that RiBBS scans
the carrier detect line of the RS-232 cable. Just by guessing what the program
does (I don't have source for RiBBS), RiBBS uses GetSTT call $28 to read the
settings of the port, then it scans for a carrier detect based on the CD line
for your cable. Now, Ron Bihler reccomends a setting of $20 for a standard, pin
for pin, RS-232 cable. He reccomends a setting of $40 for a cable where you
swap pins 6 & 8. This is done so RiBBS can automatically detect the baud rate,
other wise the user still has to bang on the enter key until baud rate is set.
Now, figured from the pinouts on the diagram for my modem, pin 8 <CD> goes to
DACIA port 15, and DSR pin 6 goes to pin 11. Now, how can I figure the carrier
bit from this information?
-*-
End of Thread.
-*-
29198 1-MAY 23:03 General Information
RE: Help! My computer hates me! <Grin> (Re: Msg 29180)
From: EDDIEKUNS To: DISTO (NR)
I think that was it. My roommate helped me resolder all of the leads on the
6809 and I tried several values for R22. I think I have it at 30 Ohms, but it
might be 35. I tried 20 and 25 to begin with, and it crashed on both settings
after about 10 minutes. I ran it at the current setting for over an hour with
no problems. (it = maze)
Also, my RAM is running comfortably warm rather than HOT HOT HOT! Sparklies are
nearly nil when I start up the machine, but level out at some when it's warm.
The pin on the lower (toward the keyboard) right corner of the 6809 (pin on the
header, that is) wasn't making good contact at all. A couple of other pins
weren't making good contact. What is that corner pin?
Eddie
P.S. I guess this proves that each CoCo has its own personality -- the value of
R22 that worked on Greg's machine crashed on mine! :(
P.P.S. Also, I thought that my machine was more damaged than before until I
realized I hadn't plugged the power plug into the RAM board!!!
P.P.P.S. How bad an idea is it to remove the adaptor on the 1-meg board and
connect it to the unregulated voltage going into the CoCo's 5-volt regulator? I
know that the regulated 5 V line is wimpy, but how about the unregulated stuff?
-*-
29212 2-MAY 21:38 General Information
RE: Help! My computer hates me! <Grin> (Re: Msg 29198)
From: EDDIEKUNS To: DISTO (NR)
<Whew> Final message on the topic, I think! :)
OK, Everything looked find yesterday until I noticed while on Delphi that after
some hard drive accesses KBCom would lose its connection to the serial port.
ie: keypresses wouldn't go out the modem. But when I made KBCom close /t2 and
re-open it, things would be OK until the next access! I don't understand it.
Anyway, today I tuned R22 to 40 Ohms (yesterday it was at 30, it crashed at 0
and 20 and 25.) and things again seem to be OK. I don't know any reliable way
to find out for sure. :( No sparklies at ALL on bootup, but after the machine
warms up, they arrive, same as before. With the machine on and maze running in
the background for CPU usage, I went into the window with the most sparklies
(yellow foreground & border on a black background) and then tuned R22 between 20
and 120 Ohms with no noticable change in sparklies.
So ... with the 1 meg upgrade, Disto 512k upgrade, old ('86) GIME, and C65 & C66
pulled (did I get those cap designations correct?), R22 needs to be somewhere
larger than 30 Ohms and less than 120 Ohms. I haven't examined the higher end
at all. (Well, I haven't really tried anything above 40 except for very short
periods of time except for 120, which I know crashes!)
Eddie
-*-
29222 3-MAY 00:49 General Information
RE: Help! My computer hates me! <Grin> (Re: Msg 29212)
From: EDDIEKUNS To: DISTO (NR)
<sigh> Just when you thought it was working....
It looks like the AciaPak problems were related to dirty connections. I cleaned
up all the connections (MultiPak & rs232 pak) and they went away.
But ... once I tried using all 1-meg, some old problems returned... I don't know
what this problem is, but it doesn't crash the machine. Basically, when I run a
program on a graphics screen which is in the upper 1/2 of memory and uses the
auto-follow mouse, I get this line of garbage which flashes (more away than
there). The line of garbage is about as high as a line of text. It appears on
type 6 & 7 graphics windows (haven't tried any other types). It DOESN'T seem to
appear on graphics screens which don't use the autofollow mouse. And it
definately doesn't show up on screens in the lower 512k of memory.
To test, I booted up in 512k and ran MVCanvas from a text window (which it
converted to a graphics window). Then I typed 'mega' to enable the top 1/2 of
memory and ran MVCanvas from another text window (which it converted to a
graphics window). I noticed that I DID NOT get the junky line in the screen in
the lower 512k, but I DID get it in the screen in the upper 512k. But if I
repeated the experiment (rebooting) and just created graphics screens with no
autofollow mouse, I didn't get that behavior. (I didn't get the line of
garbage.) While watching the flashing line, I changed the value of R22 between
0 and 120 Ohms with no systematic change in the behavior of the flashing bar of
garbage.
I also tried booting up in 512k mode w/ the jumper at position 1 & 3. I was
never able to create the flashing bar no matter what I did.
So ... it seems that the bar is related to displaying a screen in the upper 1/2
of memory when you're also doing stuff in the lower 1/2. The garbage looks like
actual memory. Almost as if every now & then the GIME (or wherever the video
circuitry is) pulls the video info out of the wrong address, or perhaps the
correct offset into the wrong 512k? Hmmm ... I could try looking at it with
composite video & see what I see, eh? I dunno.
Is it time for me to ship you me CoCo yet? <Grin> Or perhaps visit with you &
Kev for a day so we can figure this out? Is anyone else having problems like
this? <frown> At least I have the timing stuff fixed and the CoCo isn't
crashing on me anymore. And AciaPak isn't acting any more odd than is normal
for such a buggy module. And my memory is running comfortably cool. Could be
worse, I guess. <Sigh>
Eddie
-*-
End of Thread.
-*-
29202 2-MAY 01:17 General Information
Hhoward medical MPI
From: IVANSC To: ALL
I bought one of the earliest Cchris Hawkes multipack susbtitutes & for some
reason plugging the RS232 pack in drives thre thing nuts. If the pack is in
situ at power-up (from a power strip) it seems to function as it is supposed to,
but if I then re-set ( even to the three mugateers) the poor little Coco comes
up in ECB instead of DECB!!!! Repeated cold and warm resets do nothing to
alleviate the problem, only a complete power down seems to do anything - any of
you bright guys have any ideas, as Chris haw kes says it has him stumped and he
designed the dern thing!!!! Oh, by the way - I have a vertical card connector
on the end 0of the Coco motherboard and the "mpi" sticks straight up with the
hard and floppy controller cards and RS232 leaning out at righ t angles over the
motherboard to facilitate fitting inside my teeny little AT baby case!
Aany help would be appreciated.
P.S. Just who IS doing the mystery upgrade to gfx2/os9/basic09 alluded to by
Dale Puckett and when/where can we buy it????
s
-*-
29207 2-MAY 04:39 Programmers Den
RE: Text screen attributes (Re: Msg 29175)
From: PAGAN To: OS9UGPRES
Kevin
Yes I do send the text out all at once. My problem was that I wanted to map the
buttons as positions on the screen to simplify determining which button is
selected if I decide to write a graphic front end. I've tried a few thing since
I posted that message and have decided that "sticky" buttons like are used in
Guide rather than fixed position buttons like Hypercard's are probably better.
It makes the bookeeping a little more complicated but will probably result in a
better performing program overall.
Since I do want to maintain upward compatibility with the next generation of OS9
machines I agree that messing with the hardware is a bad idea - I was just
hoping that there was a way to do it via some system calls that aren't
documented in the manual but if the capability isn't there I'll live with it.
OS9 is just too flexible an operating system to be faulted for something as
trivial as this.
As for a "slight" delay - I'm not so sure. One of the problems with Maxthink
(early versions) for MS-DOS machine was the delay in scessing and displaying the
next node. Neil Larson, Maxthink's author, claims that a delay of over a few
tenths of a second can break up the continuity of information flow - which is
what hypertext is all about. Since I'll probably be using a keyboard driven
interface anyway the problem is moot.
Thanks for the advice.
Stephen (PAGAN)
-*-
29228 3-MAY 20:09 Programmers Den
RE: Text screen attributes (Re: Msg 29207)
From: OS9UGPRES To: PAGAN (NR)
Stephen...
Thanks. Can you tell me more about "sticky buttons" (vs fixed-location)? Sounds
intriguing. - kev
-*-
End of Thread.
-*-
29209 2-MAY 19:32 Users Group
MOTD
From: OS9BERT To: DWHILL (NR)
Did you get the latest MOTD yet? I thought you said something to me the other
night on-line about my review on MVCanvas. I have not received my copy of MOTD
yet. I hope the Postal Service didn't chew it up!
Bert Schneider
-*-
29211 2-MAY 21:07 Users Group
RE: MOTD (Re: Msg 29209)
From: MIKEHAALAND To: OS9BERT (NR)
I didn't get mine either!!! I've had orders as a result of the review and ad in
the same issue tho.... Hope I get my copy soon.
Mike
-*-
29219 2-MAY 23:05 Users Group
RE: MOTD (Re: Msg 29209)
From: ZACKSESSIONS To: OS9BERT (NR)
Bert,
I received my MOTD last week sometime. Your review (front pager!) was very
complete, but alas, untimely in that V2.0 is now available, as of the Chicago
Fest. Maybe a "follow up review" may be warrented? <grin>
Zack
-*-
End of Thread.
-*-
29213 2-MAY 21:40 General Information
RE: Reluctant Graphics (Re: Msg 29066)
From: JIMHARRISON To: OS9UGPRES
Kev,
Thanks for the suggestion re: my strangely intermittent graphics. The problem
has been solved by replacing the GIME chip. All is now well again...
Jim
-*-
29214 2-MAY 21:41 General Information
RE: Reluctant Graphics (Re: Msg 29083)
From: JIMHARRISON To: AJMLFCO (NR)
Allen,
Well, the mystery has been solved at last, and my CoCo-in-an-AT-case is working
perfectly now. As I mentioned earlier, suspecting a malignant GIME, I ordered a
new one from Tandy National Parts last week. It arrived yesterday, and upon
popping it into the CoCo, the weird intermittent graphics problem went away
instantly. The poor old power supply has been vindicated after all ...
The old GIME was the early (1986) version. Apparently it was pretty marginal,
and did not take well to the transplant into the AT case; it had worked just
fine for years in the standard CoCo case though.
Anyhow, all is well now. Thanks again for your interest and suggestions.
Jim
-*-
29218 2-MAY 22:42 General Information
RE: Reluctant Graphics (Re: Msg 29109)
From: JIMHARRISON To: JAYTRUESDALE (NR)
Jay,
Thanks for your suggestions. Although the power supply WAS a prime suspect, it
was innocent in this case . . . I replaced the GIME chip with a new one, and
the problem disappeared instantly!
Jim
-*-
End of Thread.
-*-
29216 2-MAY 21:43 General Information
ATCoCo
From: JIMHARRISON To: MIKEHAALAND (NR)
Mike,
At last, the project of transplanting my CoCo into an AT case has been brought
to a successful conclusion. The strange reluctant graphics problem disappeared
when I put in a new GIME, and all is well now - VERY well! I really like the new
package, especially with the IBM keyboard.
Thanks for your interest and support during the project!!
Jim
-*-
29221 3-MAY 00:12 General Information
RE: help (Re: Msg 29164)
From: KENHALTER To: DCJR
thanks for the help. I can use all I can get
I finally got my ramdisk running by putting in my bootfile so
I only need to swap disks once at the most. It's great!
I've gotta get another mechanical drive tho. The ramdisk is fast
and all but it's just not the same.
thanks again.
Ken Halter
-*-
29226 3-MAY 17:44 General Information
RE: help (Re: Msg 29221)
From: DCJR To: KENHALTER (NR)
Get the biggest, fastest drive ya can ;) If you can swing a hard drive, do it!
Then the only time you worry about swapping disks is when you're doing backups,
or like me, restoring the sucker after swapping controllers.
-*-
End of Thread.
-*-
29224 3-MAY 01:44 General Information
3.5 inch floppies
From: DEANL To: ALL
This is for anyone who has successfully connected the external 3.5 inch
Tandy drive originally designed for the 1000 HX. I got a good deal on one, but
I need a little advice on hooking it up.
My problem: the drive was originally meant to be powered for the 1000 HX.
I built a power supply, so no problem there, but I'm not sure where to hook it
to the drive itself. The drive has a small distribution board that serves as an
edge connector when used with the HX, and I found a pad on it that is marked
"12v 5v GND GND". Should I hook up the power supply there, or should I take it
straight to the drive and bypass the distribution board altogether?
Same problem with the cable: should I hook to the cable to the edgecard,
or should I bypass it and go straight to the double-pin connector on the drive
unit itself?
I want to run it as a drive 2, so I moved the jumper ti that position. Is
that correct?
Any help anyone can give me would be appreciated.
Dean Lawrence (DEANL)
-*-
29227 3-MAY 18:48 General Information
RE: 3.5 inch floppies (Re: Msg 29224)
From: DODGECOLT To: DEANL (NR)
Yea, I use one of those with my system. You don't need that little board- all it
does it convert the 30 pin connector Tandy uses for external drives to power and
normal-drive hookups.
-Mike
-*-
End of Thread.
-*-
29229 3-MAY 20:10 General Information
No permission?
From: BILLBEISSERT To: ALL
When using OS9GEN to make a new OS9BOOT I get a "NO PERMISSION" error if I
use this format:
OS9GEN /D1 </D0/BOOTLIST
or this format:
OS9GEN /D1 <ENTER>
/D0/BOOTLIST <ENTER>
However, I can CHD /D0/BOOTLIST then OS9GEN /D1 and enter each file manually
with no problems. What am I doing wrong?
Bill
-*-
29230 3-MAY 20:15 General Information
RE: No permission? (Re: Msg 29229)
From: OS9UGPRES To: BILLBEISSERT (NR)
Bill - here's one possibility: did you first CHD to the directory where all the
modules were before starting the "os9gen /d1 </d0/bootlist"?
Also, is both os9gen and hmmm.. I think rename, in memory? Or does D0 have the
cmds (and been CHX'd to) you need? - kev
-*-
End of Thread.
-*-
FORUM>Reply, Add, Read, "?" or Exit>