663 lines
23 KiB
Plaintext
663 lines
23 KiB
Plaintext
|
|
|
|
#: 18193 S1/General Interest
|
|
27-May-93 03:05:24
|
|
Sb: BUS ERRORS
|
|
Fm: Chris Hann (Mass UK) 100064,1431
|
|
To: all
|
|
|
|
I have a Radstone 68040 based system with a load of purpose built VME cards in
|
|
a 19" rack. Fine so far... but sometimes, possibly due to hardware
|
|
'irregularities (bugs but not wanting to hurt feelings)' the blessed things
|
|
fail to respond quickly (we have a third party card that sometimes refuses to
|
|
let go of it's VSB access to a RAM card for example, this eventually causes the
|
|
processor to fail when it tries to read the VME end) and an access error trap
|
|
occurs.
|
|
|
|
I am not having a lot fun with this and the following is what I think I know! I
|
|
originally posted this as an answer to my own question on the OSK section,
|
|
however I got no replies to the original so I thought I would put it in here as
|
|
well!
|
|
|
|
Cheers chapps!
|
|
|
|
After this is all inclusion of other reply>
|
|
|
|
When an access error occurs on the '040 it creates a type 7 stack
|
|
frame on the supervisor stack, this contains the PC at the error,
|
|
the CCR, the effective address, the 'broken pipe' information
|
|
(pending accesses in the pipeline at the error) and some other
|
|
stuff.
|
|
|
|
The processor then disables tracing and vectors to the access error
|
|
according to the vector in the vector table which is located
|
|
according to the VBR (since you need to be in supervisor state to
|
|
see this I can't tell exactly where it goes yet). OS-9 then finds
|
|
some space puts it's address in a5 and stacks the registers. It then
|
|
does some other stuff including overwriting the stack frame with the
|
|
register set (already stored at a5 remember) and some other stuff.
|
|
|
|
In the process it overwrites the really interesting bit ( the
|
|
effective address, at tleast I presume that is the access address
|
|
that went wrong ). It then drops you back into user mode and jumps
|
|
to your service routine leaving only the register set to work from
|
|
and without supervisor mode access.
|
|
|
|
I find this a little irritating (given that I'm correct). I'd like
|
|
to think I am wrong, however I cant reconcile the contents of the
|
|
supervisor stack with the '040 manual. There is too much data there
|
|
for it to be any other trap stack frame and all the registers have
|
|
changed, the manual says nothing about copying them to (a5)+ so I am
|
|
left to presume that OS-9 has deliberately hamstrung my ability to
|
|
find out which bit of hardware has temporarily bitten the dust.
|
|
|
|
|
|
AAAAAGH...
|
|
|
|
Obviously I could be more pleased, especially since this is a
|
|
specific port to the '040. Radstone say that they ship it in and
|
|
ship it out. Microware say not us mate we supply it to Radstone and
|
|
it's their lookout from then on.
|
|
|
|
Am I wrong or what??
|
|
|
|
Got any suggestions?
|
|
|
|
Thanks people.
|
|
|
|
Chann (mister slightly irritated 1993).
|
|
|
|
|
|
#: 18180 S5/OS9 Users Group
|
|
25-May-93 00:07:53
|
|
Sb: #0s9/msdos
|
|
Fm: Paul Thomson 100250,165
|
|
To: all
|
|
|
|
Does anyone know of any utilities to read\write OS9 disks on MSDOS systems? I
|
|
have a floppy disk from an OS9 system which is 80 Track 26 sectors per track,
|
|
256 bytes per sector. I can sucessfully read the raw sector data by
|
|
reprogramming the DOS drive table but as yet I know nothing of the dic
|
|
|
|
Paul Thomson
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18206 S5/OS9 Users Group
|
|
30-May-93 03:30:31
|
|
Sb: #18180-#0s9/msdos
|
|
Fm: ole hansen 100016,3417
|
|
To: Paul Thomson 100250,165
|
|
|
|
Hello Paul
|
|
|
|
Try to look in lib12 for a demoprogram called OS9MAX. The 'real thing' will do
|
|
want you want. There should be an address for the supplier also. if you need
|
|
more help, please contact me.
|
|
|
|
ole@danlec.dk
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18207 S5/OS9 Users Group
|
|
30-May-93 11:40:13
|
|
Sb: #18206-0s9/msdos
|
|
Fm: Bud Hamblen 72466,256
|
|
To: ole hansen 100016,3417
|
|
|
|
Bear in mind that you need an 80286 or better to run OS9MAX. It wouldn't work
|
|
on my 8086.
|
|
|
|
|
|
#: 18185 S7/Telecommunications
|
|
25-May-93 22:19:11
|
|
Sb: #18139-Sterm for OS-9000
|
|
Fm: Bill Dickhaus 70325,523
|
|
To: Timothy J. Martin 71541,3611 (X)
|
|
|
|
Yes, it is! Thanks for the upload. I'll download it tomorrow from work.
|
|
|
|
-Bill-
|
|
|
|
#: 18198 S11/OS9/6809 (Non-CoCo)
|
|
28-May-93 17:59:31
|
|
Sb: Msg 18054 and Smoke
|
|
Fm: Ken Drexler 75126,3427
|
|
To: Doug, 72667,1433
|
|
|
|
Doug
|
|
|
|
I saw your message asking about Smoke Signal Broadcasting and Xmode. SSB never
|
|
offered Xmode. I have a copy which I got out of the CoCo Level II utility set.
|
|
It seems to run properly on my SSB system although I do not use it a lot so
|
|
have not given it a through test.
|
|
|
|
SSB was around at least through Fall 1985 when I met its president at a
|
|
Microware seminar. I tried to call it a year or so later and found the phone
|
|
had been disconnected. That is the last I heard of the company. It was never
|
|
very big and got rolled over by Big Blue. (Before it left, it flirted with a
|
|
68000 system running Regulus, a UNIX knock off.)
|
|
|
|
I have two SSB Level II machines. One has died with some mysterious memory
|
|
problem. The other I use daily at my law office for two users. We use it for
|
|
work processing and legal time accounting. It continues to be solid as a rock
|
|
and about as heavy.
|
|
|
|
It is good to know there are a other SSB users around. I figured we must be an
|
|
extinct breed. (There are, however, several ex-users on here from time to
|
|
time.)
|
|
|
|
Ken
|
|
|
|
|
|
#: 18175 S12/OS9/68000 (OSK)
|
|
24-May-93 19:22:55
|
|
Sb: #18170-login
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Carl Kreider 71076,76 (X)
|
|
|
|
Thanks Carl. I'll nab it later and hopefully get all those files printed!
|
|
|
|
#: 18183 S12/OS9/68000 (OSK)
|
|
25-May-93 18:00:47
|
|
Sb: #18158-#new unzip
|
|
Fm: Ernest Withers Jr. 71545,1117
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
Thanks, Zack. I'd appreciate it. By the way, are you planning on attending the
|
|
Atlanta fest in October? I got my ACS newsletter and it says there will
|
|
definitely be one.
|
|
|
|
Ernie.
|
|
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18184 S12/OS9/68000 (OSK)
|
|
25-May-93 19:10:23
|
|
Sb: #18183-new unzip
|
|
Fm: Zack Sessions 71532,1555
|
|
To: Ernest Withers Jr. 71545,1117 (X)
|
|
|
|
> Thanks, Zack. I'd appreciate it. By the way, are you planning on attending
|
|
the
|
|
> Atlanta fest in October? I got my ACS newsletter and it says there will
|
|
> definitely be one.
|
|
|
|
If there is a fest in Atlanta, I will be there. I haven't heard from the ACS
|
|
yet.
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
#: 18177 S12/OS9/68000 (OSK)
|
|
24-May-93 19:22:59
|
|
Sb: #18173-new unzip
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
I talked to Gary Lathum a while back when I was still trying to get the boot
|
|
roms on the mm/1 to work (I've sort of given up for now) and he suggested that
|
|
he was going to talk to Kevin or Mark and see if they could get a rotation
|
|
service (rotating patched i/o boards between users) so that we could all get on
|
|
the 9meg bandwagon. Never heard anything more from him...guess this is not a
|
|
'user mode'?
|
|
|
|
#: 18181 S12/OS9/68000 (OSK)
|
|
25-May-93 00:17:38
|
|
Sb: #18171-#Printcap info needed
|
|
Fm: Mike Haaland 72300,1433
|
|
To: Carl Kreider 71076,76 (X)
|
|
|
|
Hi Carl, I'm not quite sure what you mean by 'at' or '@' traps, but I did add
|
|
the nroff style expansion in headers. So you can:
|
|
|
|
.de h0 "Manual"
|
|
.de h1 ""
|
|
.de h2 "Best in the west"
|
|
|
|
.he /\*h0/\*h1/\*h2/
|
|
|
|
Also dump titles anywhere on the page you want:
|
|
|
|
.tl 'Left'Center'Right'
|
|
|
|
I'll grab cawf... Thanks for uploading it.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18186 S12/OS9/68000 (OSK)
|
|
25-May-93 22:34:55
|
|
Sb: #18181-#Printcap info needed
|
|
Fm: Carl Kreider 71076,76
|
|
To: Mike Haaland 72300,1433 (X)
|
|
|
|
Well, I'm probably a bit fuzzy anymore, but as I recall, you would set a trap
|
|
at a line, for instance, with .at 5 tl - which would spring the trap at line 5,
|
|
executing the macro 'tl'. It could execute arbitrary commands, but the most
|
|
useful is a macro. I think .at was the TSC syntax and nroff is '.wh' maybe.
|
|
Anyway, it is a much more general and useful mechanism than the simplified
|
|
.h[0-3] that K&P used in software tools and everyone (myself included) snarfed
|
|
for their text processor.
|
|
|
|
You (and Bob) are welcome for cawf.
|
|
|
|
Carl
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 18187 S12/OS9/68000 (OSK)
|
|
26-May-93 02:26:06
|
|
Sb: #18186-Printcap info needed
|
|
Fm: Bob Taylor 73270,3124
|
|
To: Carl Kreider 71076,76
|
|
|
|
Carl,
|
|
You are right. Nroff uses .wh (when) for traps. It is used in the beginning
|
|
page and end of page macros. I have Holub's work-a-like nroff, nr. I need
|
|
to do more work on it. He didn't have proportional working at all. When I
|
|
have time I intend to finish it.
|
|
|
|
Bob
|
|
|
|
#: 18204 S12/OS9/68000 (OSK)
|
|
29-May-93 00:56:08
|
|
Sb: #18186-Printcap info needed
|
|
Fm: Mike Haaland 72300,1433
|
|
To: Carl Kreider 71076,76
|
|
|
|
I see what you mean now. Nice trap. :)
|
|
|
|
I noticed that cawf can't handle .if/.ie commands, I tried searching thru the
|
|
groff source for any clue how they handle those. Any ideas?
|
|
|
|
#: 18203 S12/OS9/68000 (OSK)
|
|
29-May-93 00:56:01
|
|
Sb: #18171-Printcap info needed
|
|
Fm: Mike Haaland 72300,1433
|
|
To: Carl Kreider 71076,76
|
|
|
|
Thanks for the offer Carl, It seems that printcap only specifies the device or
|
|
spoolfile and tells you what kind of print filter should be used.
|
|
|
|
Not really what I'm after, guess it's better to just use TCap and define needed
|
|
stuff.! Oh well...
|
|
|
|
#: 18178 S12/OS9/68000 (OSK)
|
|
24-May-93 19:23:04
|
|
Sb: #18152-InfoXpress idea
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Steve Wegert 76703,4255 (X)
|
|
|
|
Of course, if all users use VED as their editor, then you wouldn't need the
|
|
SPELL_CHECK env. variable...just couldn't resist getting this plug in.
|
|
|
|
#: 18179 S12/OS9/68000 (OSK)
|
|
24-May-93 20:39:06
|
|
Sb: #Terminals
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: all
|
|
|
|
I have a terminal hooked up to my mm/1 on /t3. I have reconfigured the rs-232
|
|
cable so that proper hardware handshaking (at least from the computer to the
|
|
terminal). I have type=80 in the /t3 desc.
|
|
|
|
It appears that the handshaking is working properly...If listing a very large
|
|
file, etc. I do see the 'busy' message on the terminal blinking. Same happens
|
|
during editor screen refreshes. I don't appear to lose any data...most of the
|
|
time. I have a 6 foot sheilded cable connecting the computer/terminal.
|
|
|
|
At 19200 this works perfectly. However, at 38400 I get occasional junk on the
|
|
screen. Now the question is there any way I can tell if this is a software
|
|
problem (ie. the mm/1 serial driver), a hardware problem (maybe the terminal
|
|
isn't as fast as it thinks), or if it is bitrot on the cable?
|
|
|
|
Guess the easiest solution is to use 19200 (I really can't tell the
|
|
difference)...but my curiousity has been raised.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18188 S12/OS9/68000 (OSK)
|
|
26-May-93 04:07:53
|
|
Sb: #18179-#Terminals
|
|
Fm: Mark Griffith 76070,41
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob,
|
|
|
|
> Now the question is there any way I can tell if this is a software
|
|
> problem (ie. the mm/1 serial driver), a hardware problem (maybe the terminal
|
|
> isn't as fast as it thinks), or if it is bitrot on the cable?
|
|
|
|
Not too easy to do. You could try a ribbon cable, and if it gets significantly
|
|
worse, then you could suspect the cable. It is more probably due to a
|
|
combination of everything you mentioned. BTW: I've never seen a terminal that
|
|
worked perfectly at 38.4kbaud. At least not so far. Maybe the newer ones
|
|
will.
|
|
|
|
|
|
/************* /\/\ark ************/
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18190 S12/OS9/68000 (OSK)
|
|
26-May-93 21:19:24
|
|
Sb: #18188-Terminals
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Mark Griffith 76070,41 (X)
|
|
|
|
Figured as much. Guess the bandwidth at that rate is pretty narrow and any
|
|
timing irregularities would show up. I'll just reset things to 19200.
|
|
|
|
#: 18182 S12/OS9/68000 (OSK)
|
|
25-May-93 02:20:55
|
|
Sb: #68k bus errors
|
|
Fm: Chris Hann (Mass UK) 100064,1431
|
|
To: all
|
|
|
|
I am developing a realtime image processing system using OS9 on a 68040 VME
|
|
rack. Unfortunately some of the hardware doesn't always respond correctly
|
|
giving rise to bus errors.
|
|
|
|
I have written a trap handler which gives me execution address and registers,
|
|
however I cannot reliably and quickly find the access address that caused the
|
|
error. Running in the debugger takes 30+ minutes to finish initialisation and
|
|
realtime execution is not possible.
|
|
|
|
Does anyone have a trap handler that can find the access address which caused
|
|
the error.
|
|
|
|
Is my trap handler worth posting in the library??
|
|
|
|
Thanks in advance.
|
|
|
|
Chris Hann
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18192 S12/OS9/68000 (OSK)
|
|
27-May-93 02:54:31
|
|
Sb: #18182-#68k bus errors
|
|
Fm: Chris Hann (Mass UK) 100064,1431
|
|
To: Chris Hann (Mass UK) 100064,1431 (X)
|
|
|
|
OK... I'll have a go at answering this myself (having read the '040
|
|
manuals and run a few tests).
|
|
|
|
When an access error occurs on the '040 it creates a type 7 stack
|
|
frame on the supervisor stack, this contains the PC at the error,
|
|
the CCR, the effective address, the 'broken pipe' information
|
|
(pending accesses in the pipeline at the error) and some other
|
|
stuff.
|
|
|
|
The processor then disables tracing and vectors to the access error
|
|
according to the vector in the vector table which is located
|
|
according to the VBR (since you need to be in supervisor state to
|
|
see this I can't tell exactly where it goes yet). OS-9 then finds
|
|
some space puts it's address in a5 and stacks the registers. It then
|
|
does some other stuff including overwriting the stack frame with the
|
|
register set (already stored at a5 remember) and some other stuff.
|
|
|
|
In the process it overwrites the really interesting bit ( the
|
|
effective address, at tleast I presume that is the access address
|
|
that went wrong ). It then drops you back into user mode and jumps
|
|
to your service routine leaving only the register set to work from
|
|
and without supervisor mode access.
|
|
|
|
I find this a little irritating (given that I'm correct). I'd like
|
|
to think I am wrong, however I cant reconcile the contents of the
|
|
supervisor stack with the '040 manual. There is too much data there
|
|
for it to be any other trap stack frame and all the registers have
|
|
changed, the manual says nothing about copying them to (a5)+ so I am
|
|
left to presume that OS-9 has deliberately hamstrung my ability to
|
|
find out which bit of hardware has temporarily bitten the dust.
|
|
|
|
|
|
AAAAAGH...
|
|
|
|
Obviously I could be more pleased, especially since this is a
|
|
specific port to the '040. Radstone say that they ship it in and
|
|
ship it out. Microware say not us mate we supply it to Radstone and
|
|
it's their lookout from then on.
|
|
|
|
Am I wrong or what??
|
|
|
|
Got any suggestions?
|
|
|
|
Thanks people.
|
|
|
|
Chann (mister slightly irritated 1993).
|
|
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18195 S12/OS9/68000 (OSK)
|
|
27-May-93 19:32:39
|
|
Sb: #18192-#68k bus errors
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Chris Hann (Mass UK) 100064,1431 (X)
|
|
|
|
Is it possible, for the purpose of finding the bug, to run your program in
|
|
system mode? That way when the bug hit, the conversion stuff should not be
|
|
done. You could also use sysdbg to monitor things.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18197 S12/OS9/68000 (OSK)
|
|
28-May-93 03:12:58
|
|
Sb: #18195-#68k bus errors
|
|
Fm: Chris Hann (Mass UK) 100064,1431
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Pardon my ignorance but how exactly do I run something in system mode? If there
|
|
is a way I can always run in system mode then fine I'll do it!
|
|
|
|
What I have been able to do after talking to Radstone is interrupt the system
|
|
to get to the ROM debugger and type the command 'ov2' which traps bus errors to
|
|
the rom monitor. This lets me find a particular hard error more quickly.
|
|
However the thing I really need is a software fix that I can leave in the
|
|
system permanently which will trap all bus errors. Part of my problem is that
|
|
the customer is keen to point the finger at our system for any failure as the
|
|
unit under test is more than a year late and they desperately need excuses, if
|
|
I can add a facility which will point to the problem directly then so much the
|
|
better. I should add that the system contains seven third party boards, three
|
|
Mass boards and five customer supplied boards ( three of which are
|
|
modifications of previous designs supplied by ourselves ), all but one of the
|
|
reported faults have been in the customer supplied boards (generally in their
|
|
two homebuilt boards but occasionally in the modified boards and then always in
|
|
the modifications). Sorry that's a load of political stuff but my backside is
|
|
getting singed every time they have a fault and I am getting a little tired of
|
|
having to break the news to them.
|
|
|
|
In general the OS-9 error messages "000:102" are very poor, almost all other
|
|
opperating systems will give an execution and access address.
|
|
|
|
If I find a good solution I'll let you know.
|
|
|
|
Chann
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 18199 S12/OS9/68000 (OSK)
|
|
28-May-93 19:50:28
|
|
Sb: #18197-68k bus errors
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Chris Hann (Mass UK) 100064,1431
|
|
|
|
Have a re-read of section 2, The Kernel, in the OS9 Tech. Ref. Manual. It tells
|
|
you why not to run user stuff in system mode...and tells how to do it <g>.
|
|
|
|
Sounds like you have quite a witch's brew of potential faults. Good luck in
|
|
tracking down the culprit(s).
|
|
|
|
#: 18205 S12/OS9/68000 (OSK)
|
|
29-May-93 17:33:40
|
|
Sb: #18197-68k bus errors
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Chris Hann (Mass UK) 100064,1431
|
|
|
|
If you haven't already, have a look at "The OS9 Guru". There is an excellent
|
|
section on trapping bus errors, etc. in it. It is avail from Galatic Industrial
|
|
Ltd.
|
|
|
|
#: 18191 S12/OS9/68000 (OSK)
|
|
26-May-93 21:46:24
|
|
Sb: #strange happening?!?
|
|
Fm: Zack Sessions 71532,1555
|
|
To: ALL
|
|
|
|
Tonight I wanted to load up some stuff to one of my hard drives. Since it was a
|
|
large directory, I wanted to put it to the disk which had the most space
|
|
available. I was logged into UID 100.1 and the disks were formatted by user
|
|
0.0. When I did a free on /h0, I got the normal output. But when I tried a free
|
|
command on /h1 (from the 100.1 account) it displayed the first line of the the
|
|
output which contains the volume label and creation date, but it then says,
|
|
"free: can't read bitmap.". I thought I had trashed /h1, but a directory of /h1
|
|
worked fine.
|
|
|
|
So I logged in the superuser account, UID 0.0, and tried the free command on
|
|
/h1 and it worked! Then I ran a dcheck on /h1 and it reported no errors. Well,
|
|
I hadn't trashed my disk, but what IS the problem running a free command from a
|
|
non-superuser account? And why is this just now happening when it didn't happen
|
|
before?
|
|
|
|
I thought it was the device attributes. I first tried to look with ded. But a
|
|
ded of /h1@ showed NO data! A ded on /h0@ worked just fine. (Now, these are
|
|
from the superuser account, now!). I was able to dump the super block on both
|
|
drives finally with dump on /h0@ and then /h1@, and both drives are owned by
|
|
0.0 and have an attributes mask of $FF.
|
|
|
|
Anybody got any ideas?
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 18194 S12/OS9/68000 (OSK)
|
|
27-May-93 19:32:35
|
|
Sb: #18191-#strange happening?!?
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
This really sounds just like the problem I had when I first got my 2nd HD! But,
|
|
I find it hard to believe that it is only hitting you now...must be another
|
|
problem. But, just in case it isn't (and for others too), when I got my 2nd HD
|
|
I followed the instructions in the mm/1 tech manual to create a descriptor for
|
|
H1. Kids--don't do this at home; it doesn't work!
|
|
|
|
Each descriptor for a HD on a SCSI bus must have a different controller ID AND
|
|
it must have a different PORT. To check, do a DMODE -p /h1 and then /h0. Make
|
|
sure the port=xxx is different. This is easy to do if you use the desc.
|
|
supplied with the upgrade stuff.
|
|
|
|
From my understanding (which could be WRONG) the least significant byte in the
|
|
port address is ignored as far as finding the scsi port is concerned; but it is
|
|
used by the driver to determine that /h1 and /h0 are different devices. I'm not
|
|
sure why it just doesn't use the controller ID, but it doesn't.
|
|
|
|
BTW, as a matter of interest I have the attributes on /h1 set to super-only
|
|
access. If I logon as user 3.3 I CAN do a free /h1; but not a dir /h1.
|
|
|
|
Hope this helps...
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18196 S12/OS9/68000 (OSK)
|
|
27-May-93 21:56:08
|
|
Sb: #18194-#strange happening?!?
|
|
Fm: Zack Sessions 71532,1555
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
>
|
|
> Hope this helps...
|
|
>
|
|
|
|
Well, no, it didn't. <g>
|
|
|
|
I had a second hard drive on my system for several weeks with no problem. Then
|
|
I had to remove the second HD when I took my system to the fest. When I got
|
|
back home and hooked it back up, I reformatted it and loaded it back up from
|
|
tape backups. I haven't noticed the free problem until just yesterday.
|
|
|
|
I can remember doing free commands on both HDs from the 100.1 account many
|
|
times before the fest.
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18200 S12/OS9/68000 (OSK)
|
|
28-May-93 19:50:31
|
|
Sb: #18196-#strange happening?!?
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
Since you said "it didn't help", I do assume that you did check the port
|
|
addresses on the descriptors <g>.
|
|
|
|
Since it apparently did work before...have you checked the cables, etc?
|
|
|
|
Just checked my startup file and I do an "iniz /dd /h1". I don't believe this
|
|
should be necessary...but you might want to play with the possibility.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18201 S12/OS9/68000 (OSK)
|
|
28-May-93 21:39:54
|
|
Sb: #18200-strange happening?!?
|
|
Fm: Zack Sessions 71532,1555
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob, you seem to be a little confused. The drive works just fine. There are
|
|
only two things I cannot appear to do.
|
|
|
|
1) do a "free /h1" command from a non-superuser account.
|
|
|
|
2) do a "ded /h1@" command from a superuser account.
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
#: 18202 S12/OS9/68000 (OSK)
|
|
29-May-93 00:55:52
|
|
Sb: #18191-strange happening?!?
|
|
Fm: Mike Haaland 72300,1433
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
Hmmm. I can't duplicate the problem here, so it must have something to do with
|
|
your device descriptor or something, maybe the free attr? 100.1 works just
|
|
fine here. Wish I could be of more help.
|
|
|
|
|
|
#: 18189 S14/misc/info/Soapbox
|
|
26-May-93 19:25:04
|
|
Sb: OS9 Underground
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: all
|
|
|
|
Strange things are not always bad... Opened my post office box today and was
|
|
shocked to find a copy of the OS9 UnderGround! The editorial has a detailed
|
|
exp. of why it's late, etc.
|
|
|
|
Good thing it was published. Remember my 'battle' with MG about the malloc.h
|
|
thing... well, the article I promised ya all on this is in this issue (the
|
|
reason that is good is that I lost my copy of the ms.)
|
|
|
|
And MG has an article in there too. All in all, it is a good little issue. Hope
|
|
that Alan can keep up his promises.
|
|
|
|
Press <CR> !> |