textfiles/messages/ALANWESTON/1993/CIS04_17.txt

731 lines
24 KiB
Plaintext
Raw Permalink Normal View History

2021-04-15 11:31:59 -07:00
#: 17900 S1/General Interest
12-Apr-93 20:28:11
Sb: #17852-How come?
Fm: Carl Kreider 71076,76
To: Ken Flanagan 75460,2514 (X)
Well, I'm not a compression expert, so don't know what you mean. -lh1- looks
like an lharc type. The compression ar uses is lzw as described in ACM and
implemented in Unix compress. It doesn't add Huffman on top or any of the
sorts of things recent lha or zoo do. Nor will it ever. There isn't enough
room on an 09. For OSK, I usually use zoo anyway. Lharc can be faster but
does not seem to be very portable or even compatible with itself.
#: 17897 S1/General Interest
12-Apr-93 08:25:32
Sb: #17888-Ar Version 1.3
Fm: Ken Flanagan 75460,2514
To: Steve Wegert 76703,4255 (X)
It may be moot already (compression wise anyways). There is now a LZH archiver
program for OS-9 level 2. I uploaded it awhile ago, although I don't see it in
the listings yet....
#: 17906 S1/General Interest
13-Apr-93 22:05:50
Sb: #real time application
Fm: glen johnson 72630,2275
To: OS9 gurus
Thanks for reading...
I need help on OS9 interprocess communication (ipc) features for my servo
control and acquistion application. I've been given a project of porting over
Versados 68000 code (c, fortran, assy). This code generally uses TRAP calls for
ipc including wake-ups and message queues. My task is to rewrite the code in C
using events, semaphores, traps, signals, or whatever appropriate in the
transcription. I have P. Dibble's Insights book but there is no OPC (other
people's code) to use as an end to end working guideline. Is there any
downloadable or textbook source code available that would be helpful?
Thanks in advance for any leads or advice. Glen/Fort Worth TX
There is 1 Reply.
#: 17916 S1/General Interest
14-Apr-93 23:24:20
Sb: #17906-real time application
Fm: Pete Lyall 76703,4230
To: glen johnson 72630,2275
Glen -
I'm a bit cooked at the moment, but may be able to provide some help. Give me
a call at work sometime... (303) 795-2625.
Pete
#: 17912 S7/Telecommunications
14-Apr-93 15:20:33
Sb: #17819-#terminal help
Fm: Kevin Pease 70516,1633
To: Bill Dickhaus 70325,523 (X)
This is not a specific keyboard problem. It has to do with system bus loading
during hard disk transfers. I will look to se what the jumpers are. If you are
going to be at the fest Maybee I can show you then.
There is 1 Reply.
#: 17913 S7/Telecommunications
14-Apr-93 17:37:31
Sb: #17912-terminal help
Fm: Bill Dickhaus 70325,523
To: Kevin Pease 70516,1633
I thought that might be the case (that is wasn't a keyboard problem), but
wasn't sure. Yes, I will be at the fest, see you there!
-Bill-
#: 17921 S10/OS9/6809 (CoCo)
15-Apr-93 17:51:44
Sb: MultiVue
Fm: Brother Jeremy, CSJW 76477,142
To: All
Dear Friends:
I am posting this with the permission of Boisy Pitre.
73907 6-APR 20:33 Applications (6809)
MultiVue patches
From: BOISY To: ALL
I installed the GShell32 patches to GShell -- wow, Multivue has never been so
nice! I've been running it for two days now without a crash, plus running StG
BBS, and opening windows like mad....
I did have to manually patch the new GShell to use the new GRFDRV for faster
PUTs on an 80x24 screen. My two questions:
(1) Where do I patch GShell to obtain similar speeds on the 320x192 screen? (2)
Kent Meyers told me once that he had patched GShell so that icons on
an 80x24 window would be twice as wide, thus preserving the proportional
size of the icon (icons on 80x24 screens look narrow as apposed to 40x24)
Does anyone have this patch and would share it?/
With all best wishes,
Br. Jeremy, CSJW
#: 17923 S12/OS9/68000 (OSK)
16-Apr-93 00:45:14
Sb: #17606-#Basic Error 200
Fm: Tony Elliott 71645,1367
To: Kevin Darling 76703,4227 (X)
Kevin,
I havn't worked it out yet. But it is true, there is a recursive process going
on here. There IS a CLOSE to the path, which we have pretty much determined is
the printer (since we believe we do not get the error if we are writing to a
file).
It's a puzzle!
By the by... just set up a FHL KiX-30 (a/k/a Hazelwood EK-30). It's a real
screamer compared to the old Uniquad-20 with 12 users! Are there other users
on this board?
Final thought... where is the un-archive utility in the CIS library for files
with the .AR extension. I know there is a specific version to be used by this
forum now. Can't seem to find which LIb it's in.
Tnx for the repy, and sorry to take so long to respond. I can't believe it has
been over a month since I had been on!
Happy tax day! <g>
Tony
There is 1 Reply.
#: 17926 S12/OS9/68000 (OSK)
16-Apr-93 21:32:46
Sb: #17923-Basic Error 200
Fm: Kevin Darling 76703,4227
To: Tony Elliott 71645,1367
Tony - see AR.DOC and AR68.BIN in Library 9.
Yah, weird about the path thingie! -kev
#: 17896 S12/OS9/68000 (OSK)
12-Apr-93 02:52:35
Sb: #17892-#C_error_help
Fm: Mark Griffith 76070,41
To: LARRY OLSON 72227,3467 (X)
Larry,
> I was able to bring the following down:
> Init. data off: #72474 #69992
> Data ref. off: #76344 #73858
>
> The program now compiles without the Value Out of Range error !!
> For some reason, the problem is tied into the size of the program.
Sounds like something in the linker. Let me give you an example. I have a
library function that issues a BREAK on the modem port. This is the code:
send_break()
{
if (_ss_sbreak(mp) < 0)
#asm
I$SetStt equ $008E ; 8f is get
_ss_sbreak:
link a5,#0
movem.l D1/D2/A0,-(A7)
move.l D1,D2
move.w #SS_Break,D1
os9 I$SetStt
bra _sysret
}
Notice the bra _sysret call. Sysret is located in the sys.l library. If the
program is very large, over 32K, and the location of the break function is at
the beginning, when I link in sys.l, I will get an error if the location of
_sysret is greater than 32K from where it was called. I am not good enough at
OSK assembler to fix this problem. So for now, I just make sure I put the break
function at the end of the program source file, and then link sys.l first (if I
can).
I belive you might be having the same trouble. Perhaps someone else here can
shed some more light on these problems.
/************* /\/\ark ************/
There are 2 Replies.
#: 17898 S12/OS9/68000 (OSK)
12-Apr-93 17:25:06
Sb: #17896-#C_error_help
Fm: LARRY OLSON 72227,3467
To: Mark Griffith 76070,41 (X)
Mark,
That sounds like what I ran into. When looking at the assemble code
generated, the error was pointing at the second statement in the program.
P_id - getpid();
Wpath2 = open("/w", 3); <-- This is where the error came in
The code was:
moveq.l #3,d1 :2
lea_64(pc),a0 <-- Here is the VALUE OUT OF RANGE ERROR move.l a0,d0 :2
bsr open
The only other possibility I could think of was the fact that Wpath2 would be
the last variable name, if the names were sorted, and it for some reason was
out of range when linking. I think I will be running into the error again as I
add more to the program, and if I do, I will try renaming the variable, and see
if the error transfers to the new last in line variable.
larry
There are 2 Replies.
#: 17908 S12/OS9/68000 (OSK)
14-Apr-93 04:14:44
Sb: #17898-#C_error_help
Fm: Mark Griffith 76070,41
To: LARRY OLSON 72227,3467 (X)
Larry,
> Wpath2 = open("/w", 3); <-- This is where the error came in
>
> The code was:
> moveq.l #3,d1 :2
>
> lea_64(pc),a0 <-- Here is the VALUE OUT OF RANGE ERROR
> move.l a0,d0 :2
> bsr open
This is very strange. I don't see any reason for the compiler to put out code
like this. How is Wpath2 defined?
/************* /\/\ark ************/
There are 2 Replies.
#: 17910 S12/OS9/68000 (OSK)
14-Apr-93 08:01:17
Sb: #17908-#C_error_help
Fm: Bill Dickhaus 70325,523
To: Mark Griffith 76070,41 (X)
Mark,
It looks like Larry left some of the code out, but I don't see anything really
strange about it (other than its 68K code, I'm still not used to it yet :-)
> lea _64(pc),a0 <-- Here is the VALUE OUT OF RANGE ERROR
This IS the problem, assuming that _64 is the label of the "/w" constant, since
the compiler always puts string constants at the end of the module.
-Bill-
There is 1 Reply.
#: 17925 S12/OS9/68000 (OSK)
16-Apr-93 06:06:35
Sb: #17910-C_error_help
Fm: Mark Griffith 76070,41
To: Bill Dickhaus 70325,523 (X)
Bill,
> > lea _64(pc),a0 <-- Here is the VALUE OUT OF RANGE ERROR
>
> This IS the problem, assuming that _64 is the label of the "/w" constant,
> since the compiler always puts string constants at the end of the module.
I guess that his program then is much larger than 32K, so the string constants
can't be reached. Perhaps he can fix this by defining the constants as a
variable? Strange I never ran into this, but then the largest program I've
done is Sterm and it is only 54K.
/************* /\/\ark ************/
#: 17918 S12/OS9/68000 (OSK)
15-Apr-93 00:00:18
Sb: #17908-C_error_help
Fm: LARRY OLSON 72227,3467
To: Mark Griffith 76070,41 (X)
Mark,
Wpath2 was defined as an integer, then used :
Wpath2 = open("/w", 3);
Did that file I sent you come through ok ?
larry
#: 17911 S12/OS9/68000 (OSK)
14-Apr-93 08:02:13
Sb: #17898-#C_error_help
Fm: Bill Dickhaus 70325,523
To: LARRY OLSON 72227,3467 (X)
Larry,
> lea _64(pc),a0 <-- Here is the VALUE OUT OF RANGE ERROR
This is the problem, and it has nothing to do with variables. If you look
toward the end of the assembler code, I think you will find that _64 is the
label of the "/w" constant. This instruction puts the address of that constant
in a0. The problem is that the compiler puts all string constants (like "/w")
at the end of the module, there is no way to get around this (that I know of)
other than make the modules smaller. As soon as you add more code, it will push
the constants beyond the 64K limit, and this will happen again.
I strongly suggest that you take the time now to learn how to use the linker
and make. It will actually save you time, as you won't be compiling one large
module each time you make a change. I'd be happy to provide some sample make
files, and there are pleny of people around to help out. Once you learn how to
use make, and the linker, you will never go back :-)
-Bill-
There is 1 Reply.
#: 17919 S12/OS9/68000 (OSK)
15-Apr-93 00:11:27
Sb: #17911-C_error_help
Fm: LARRY OLSON 72227,3467
To: Bill Dickhaus 70325,523 (X)
Bill,
It definently sounds like that is the problem. When I went through and did
some cleanup and pared the program down some, the error went away.
It looks like I will have to dig into using the linker. Its funny but I had
no problem using the RMA assembler and linker on the CoCo, but I can't get a
handle on the linker for C. But I will try...
So individual modules can't be greater than 64k, but you can link any number
of 64k modules together(within system limits) ?
Thanks Bill
larry
#: 17899 S12/OS9/68000 (OSK)
12-Apr-93 19:25:57
Sb: #17896-#C_error_help
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)
Mark,
The 68000 can only have bra and bsr in a 32K max offset (the 68020, etc) can
manage a 32bit offset). The linker is supposed to generate an entry in a jump
table for branches out of reach. A bra.w is converted to a jmp by the linker.
Could be that since you have coded the routine in asm that the linker is
missing the call?
There are 2 Replies.
#: 17901 S12/OS9/68000 (OSK)
13-Apr-93 00:07:23
Sb: #17899-#C_error_help
Fm: LARRY OLSON 72227,3467
To: Bob van der Poel 76510,2203 (X)
Bob,
The routine was written in C, not asm. In the process of compiling the
program, during the r68 pass, a ** value out of range ** error popped up.
The error was reported as such:
Value out of range
lea_64(pc),a0
^
So I recompiledthe file using the -a option, in order to see the asm code
that was generated and where the error was. That short bit of asm code, is what
was produced by the compiler.
larry
There is 1 Reply.
#: 17914 S12/OS9/68000 (OSK)
14-Apr-93 20:06:53
Sb: #17901-#C_error_help
Fm: Bob van der Poel 76510,2203
To: LARRY OLSON 72227,3467 (X)
Just thinking out loud...I wonder if the assembler/linker can handle calls past
+/- 32K only if the dest. is in another file? If the problem comes up during
the assembly then the assembler will report the branch error. If it just sticks
in a label for the linker to worry about, the linker will create the jump
table. Seems to be one more reason for breaking up programs into smaller
segments.
There is 1 Reply.
#: 17920 S12/OS9/68000 (OSK)
15-Apr-93 00:22:01
Sb: #17914-C_error_help
Fm: LARRY OLSON 72227,3467
To: Bob van der Poel 76510,2203 (X)
Bob,
Yes, it looks like its unanimous, I need to learn how to use the linker.
The only problem I have now is that When I started writing this program I had
no idea that it would get this large, so I didn't give any thought to breaking
it up. I'll have to see what I can break up.
larry
#: 17909 S12/OS9/68000 (OSK)
14-Apr-93 04:14:57
Sb: #17899-C_error_help
Fm: Mark Griffith 76070,41
To: Bob van der Poel 76510,2203 (X)
Bob,
> The linker is supposed to generate an entry in a jump
> table for branches out of reach.
> Could be that since you have coded the routine in asm that the linker is
> missing the call?
That sounds like a reasonable guess. In any case, in my example, it is not
possible to do that (make it a jmp) and still have it work correctly. Perhaps
someone else can come up with a better solution.
/************* /\/\ark ************/
#: 17894 S12/OS9/68000 (OSK)
11-Apr-93 19:16:09
Sb: #MM/1 disasm
Fm: Bob van der Poel 76510,2203
To: all
I've been wasting a bit of my time looking at disasms of some of the mm/1
system code. I'm confused by the way some of the ports are addressed. For
example, I see stuff like:
move.b $9ffc01,d0
Which, I know, means to move a byte from $9ffc01 to register d0. However, are
not all the ports addressed at EVEN memory addresses? Don't know why I figure
that...I just figured it.
So, assuming that there is a device with its base addresses at $9ffc00, just
what is at $9ffc01? BTW, the mm/1 tech man suggests that the MC68901 on the
main board is at $9ffc00.
I must be missing some important hardware concept!
There are 2 Replies.
#: 17902 S12/OS9/68000 (OSK)
13-Apr-93 04:06:21
Sb: #17894-MM/1 disasm
Fm: Mark Griffith 76070,41
To: Bob van der Poel 76510,2203 (X)
Bob,
> I'm confused by the way some of the ports are addressed. For
> example, I see stuff like:
>
> move.b $9ffc01,d0
>
> So, assuming that there is a device with its base addresses at $9ffc00, just
> what is at $9ffc01? BTW, the mm/1 tech man suggests that the MC68901 on the
> main board is at $9ffc00.
That address is where the 68901 on the mother (CPU) board is. The base address
is indeed $9FFC00 and the offset of 1 points to the general purpose data
register of that chip. Here are some offsets for you:
/* define base addresses of I/O chips */
#define SIG_070S 80002011 /* serial port
t0 */
#define MOT_901a 10484736 /* serial port
t0 and t1 */
#define MOT_901b 14680960 /* serial port
t2 */
#define MOT_681 14680704 /* serial ports
t3 and t4 */
#define MOT_230 14680448 /* parallel
ports */
#define WD33C65 10484929 /* WD33C65
floppy cntlr */
#define RTC 14680577 /* DS1287 Real Time
Clock */
/* define offsets for the 68901 register map */
#define GPDR_901a (u_char *)(MOT_901a + 1) /* gen purp data reg */
#define DDR_901a (u_char *)(MOT_901a + 5) /* data direction reg
*/
#define UCR_901a (u_char *)(MOT_901a + 41) /* USART control reg */
#define RSR_901a (u_char *)(MOT_901a + 43) /* Recvr status reg */
#define TSR_901a (u_char *)(MOT_901a + 45) /* Trans status reg */
#define UDR_901a (u_char *)(MOT_901a + 47) /* USART data reg */
Hope this helps you figure it all out.
/************* /\/\ark ************/
#: 17904 S12/OS9/68000 (OSK)
13-Apr-93 17:27:15
Sb: #17894-MM/1 disasm
Fm: ole hansen 100016,3417
To: Bob van der Poel 76510,2203 (X)
Hello Bob
The reason why you use 'odd'-addresses and not 'even'addresses is the way the
68000 cpu is connected to the DATA-BUS. If you use move.w $10000,d0, bit d15-d8
will be read from $10000 and d7-d0 will be read from $10001, so if you only
read a byte from an I/O-chip like MC68901, which is an 8-bit device, you need
to access it via 'odd'-addresses, otherwise you are likely to get an
'error-102' or 'garbage'. If you need to access several register in 'one go',
you can use the MOVEP.L instruction. It will read/write 4-bytes on every
second-address from base-address. Example:
MOVEP.L d0,$ffa001 will write 1 byte at $ffa001 and 1 at $ffa003 and 1 at
$ffa005 and one at $ffa007.
regards ole@danelec.dk
#: 17895 S12/OS9/68000 (OSK)
11-Apr-93 22:43:07
Sb: #login
Fm: Bob van der Poel 76510,2203
To: all
I've been setting up my system to use login, instead of just booting with a
startup file. I have got tsmon running from startup to monitor the terminal
posts. This works fine. However, I would like to force anyone just turning on
the computer to go though login as well. I can do this by sticking a login
command in the startup file...however, everything past the command gets
ignored. Since, I want to set up some extra windows...this is not good. I can't
set the windows first; that would eliminate the security of login. Seems that I
am in a catch-22 situation.
Next, I figured that I'd give each user his own directory. And to make it hard
for other users to examine the files of others I also figured I'd set the
access permissions of the directories to prevent public read/write. No good.
The first thing login does is try to chd to the directory. But, if the
directory does NOT have public read/write then it can't do so. Frankly, this
doesn't make sense to me since login is running in superuser mode. Is there a
way around this one?
There are 2 Replies.
#: 17903 S12/OS9/68000 (OSK)
13-Apr-93 05:32:43
Sb: #17895-#login
Fm: Steve Wegert 76703,4255
To: Bob van der Poel 76510,2203 (X)
Bob,
I've got my system set up for dialup operation. All my users have they own
directory space with owner read/write/execute permissions set only. Things work
just dandy.
What type of errors are you getting?
*- Steve -*
There is 1 Reply.
#: 17915 S12/OS9/68000 (OSK)
14-Apr-93 20:07:01
Sb: #17903-#login
Fm: Bob van der Poel 76510,2203
To: Steve Wegert 76703,4255 (X)
More on the read/write attrs. Here is a password file entry:
steve,secret,3.3,128,.,/dd/usr/steve,shell
In /dd/usr/steve I have a .login file. If the directory "steve" is set with all
the permissions all works file (motd is displayed, and the .login file is
processed). However, if I just set owner permissions in "steve" then motd is
displayed -- but I then get the message "login: can't chd to /dd/usr/steve".
There is 1 Reply.
#: 17924 S12/OS9/68000 (OSK)
16-Apr-93 05:33:20
Sb: #17915-login
Fm: Steve Wegert 76703,4255
To: Bob van der Poel 76510,2203 (X)
> More on the read/write attrs. Here is a password file entry:
>
> steve,secret,3.3,128,.,/dd/usr/steve,shell
>
> In /dd/usr/steve I have a .login file. If the directory "steve" is set with
> all the permissions all works file (motd is displayed, and the .login file
is
> processed). However, if I just set owner permissions in "steve" then motd is
> displayed -- but I then get the message "login: can't chd to /dd/usr/steve".
> My entries are similar with one exception. I call out the path to the cmds
directory. So where you've just a dot, I've got /dd/cmds.
I don't know if this is significant, (no manuals), but give it a try and see
what happens.
*- Steve -*
#: 17905 S12/OS9/68000 (OSK)
13-Apr-93 17:35:21
Sb: #17895-login
Fm: ole hansen 100016,3417
To: Bob van der Poel 76510,2203 (X)
Hello Bob
The best solution for your first problem is to make a 'new' sysgo, which does
not 'fork' shell after execution of 'startup', but instead fork 'tsmon' on your
'console' or just 'login' on your 'console'.
Your second problem is related to 'ALWAYS WANT TO BE SUPERUSER'. NON-superuser
users will have normal protection between access to other users files.
regards
ole@adanelec.dk
#: 17907 S12/OS9/68000 (OSK)
14-Apr-93 00:59:39
Sb: #TCP/IP
Fm: Chris Piedmonte 71730,1274
To: Sysop (X)
I hope someone here (or at Microware) can be of some help. I have a client
that has two GESPAC 68030 based OS-9 systems that are running on an ethernet
network. They appear to be using sockman, ifman, inet, tcp,, udp and the like
with file dates from around 10/90 to 11/91. They are not attempting to connect
the systems to a PC running Windows and the TCP/IP package from Distinct
Software.
Unfortunately, they are not having a lot of success. They apparently cannot
locate the internet address for their OS-9 systems, nor can they get any of
Distinct's utilities to be of help. For the most part, they know little to
nothing about their OS-9 system, and the original vendor is no longer
available/or interested.
Can anybody suggest a course of action to get their PCs talking to their OS-9
system using TCP/IP and FTP?
Thanks,
Chris Piedmonte
Eagle Creek Systems
There is 1 Reply.
#: 17917 S12/OS9/68000 (OSK)
14-Apr-93 23:29:31
Sb: #17907-TCP/IP
Fm: Pete Lyall 76703,4230
To: Chris Piedmonte 71730,1274
The internet addresses are usually in /dd/inet/etc/hosts...
Pete
#: 17922 S12/OS9/68000 (OSK)
15-Apr-93 19:09:21
Sb: login
Fm: Bob van der Poel 76510,2203
To: all
Any HP Laser Jet experts out there? I just got an Epson Laser printer and am
trying to learn the PCL language...it's never as easy as it seems. I have the
Epson "manual" and a couple of books on the subject. I was trying to set the
page size and got real confused, real fast. The Epson manual just lists the
sizes available for the "ESC & l # A" command--it doesn't bother to list the
values needed for the different sizes. However, I have a book on the PCL
language (The Laserjet Handbook, Bennett & Randall, Brady) and it does list
them. For example, the book clearly states that a parameter of "6" will select
Commercial 10 (envelope) size. Of course, this doesn't work (If all this
worked, then what would we need CIS for...hmmm, is there a conspiracy?). I
grabbed a few programs for lasers off the UNIX forum...and one one of them sets
the printer properly....but it uses a param of "81" for C10 env. This program
has a few other values...but it is not complete. I started just sending test
values out to the printer...but having to constantly turn the sucker off line
and then wade through the "easy to use" panel display gets real old, real fast.
So, either I'm missing the logic of sending a "81" when a "6" is called for (I
fail to see the relationship), or the book I have is lying, or... Anyone happen
to have a table of sizes and params. This is not a big deal in itself...but I
have the feeling if I can't even set the paper size from the computer, I'm
going to have even more frustrations when it comes to other goodies.
Press <CR> !>