565 lines
19 KiB
Plaintext
565 lines
19 KiB
Plaintext
|
|
|
|
#: 20206 S1/General Interest
|
|
11-Aug-94 20:07:18
|
|
Sb: #19905-Graphics Library for 68K
|
|
Fm: Thomas Baumeister 100341,624
|
|
To: Rand Methfessel 73163,2156
|
|
|
|
Hello Rand,
|
|
|
|
currently I use my own graphics library (BGP) on a 68040 for a customer's GUI
|
|
project. There is also a standard VGA (640*480*4 planes) version, so chances
|
|
are that I have some code that could help you. Tell me what graphics
|
|
hardware you use, and what you expect the graphics library to do.
|
|
Thomas.
|
|
|
|
#: 20188 S1/General Interest
|
|
08-Aug-94 15:57:31
|
|
Sb: #RS232 response time?
|
|
Fm: Simon R Ashby 100111,2173
|
|
To: All
|
|
|
|
A client of mine (MOD) is trying use OS/9 on VME 680x0 to talk to a realtime
|
|
instrument we make. He says he cannot respond in less than 25ms!
|
|
Surely he is making some kind of obvious mistake - we really need him to get
|
|
back inside a deterministic 3ms max.
|
|
Any help/guidance/suggestions?
|
|
At the moment, neither of us is much impressed with OS/9.
|
|
SRA IMP ELECTRONICS (Real-time video instrumentation) CAMBRIDGE UK
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 20190 S1/General Interest
|
|
08-Aug-94 22:05:56
|
|
Sb: #20188-RS232 response time?
|
|
Fm: Kevin Darling 76703,4227
|
|
To: Simon R Ashby 100111,2173 (X)
|
|
|
|
Hi Simon,
|
|
|
|
What else is your client doing in his program? Writing to a slow disk drive,
|
|
responding to other instruments, or ?
|
|
|
|
How is your instrument connected (serial?) and what kind of data traffic are we
|
|
talking about?
|
|
|
|
Also, which 680x0 and at what speed?
|
|
|
|
What language is his program written in?
|
|
|
|
Sounds kind of flaky that he'd blame the OS in this case. Its overhead is near
|
|
nil for most things.
|
|
|
|
best - kevin
|
|
|
|
#: 20192 S1/General Interest
|
|
08-Aug-94 23:18:27
|
|
Sb: #20188-#RS232 response time?
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Simon R Ashby 100111,2173 (X)
|
|
|
|
OS9 is much faster than that. I was looking though some of my literature to
|
|
find timing information...the only thing I could find was from some MW
|
|
literature:
|
|
|
|
Task Switch - 55.1 +/- 1.5 usec.
|
|
Interupt response - 11.1 usec.
|
|
|
|
This is based on a 20MHz 68020. Seems that your client is probably doing
|
|
something wrong...25ms is a long time!
|
|
|
|
If you were to let us know how the instrument is interfaced, etc. someone here
|
|
might be able to shed some light on the problem.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 20193 S1/General Interest
|
|
09-Aug-94 03:27:46
|
|
Sb: #20192-#RS232 response time?
|
|
Fm: Simon R Ashby 100111,2173
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Thanks, Bob and Kevin.
|
|
I am not party to the what the client is actually doing the rest of the time,
|
|
in the rest of his application (hush-hush), so I am guessing. It's his first
|
|
time with OS9, and I haven't used it either.
|
|
I will take it that he is doing something silly, and try to sort it out with
|
|
him and his vendor support. However, to fill in a bit for your interest:
|
|
We make, among other things, a video annotation board (8052-based, PL/M
|
|
programmed) which puts precision crosswires and text annotation on a
|
|
video-recording; in this case, the client has a 68020 VME rig which handles
|
|
other instrumentation but which does not otherwise know about video. There is
|
|
a non-real-time setup protocol for positioning the display and crosswires etc,
|
|
plus a real-time mode where we provide a 'tick' character at 19200 baud every
|
|
video field sync. If they reply in 3ms with their 10-character data string then
|
|
we guarantee that the video recording annotation will be deterministic.
|
|
The data string contains text, numbers, flags and X-Y position for two
|
|
crosswires.
|
|
They claim to be unable to respond in 3ms - more like 25ms.
|
|
There you are. Thanks anyway. Best regards Simon A
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 20196 S1/General Interest
|
|
09-Aug-94 19:06:07
|
|
Sb: #20193-#RS232 response time?
|
|
Fm: Kevin Darling 76703,4227
|
|
To: Simon R Ashby 100111,2173 (X)
|
|
|
|
Okay. My best guess:
|
|
|
|
It sounds like they're probably using their main process to answer you once
|
|
they hit a main loop area where it can notice your input... and that the main
|
|
process takes a max of 25ms to get around to this area.
|
|
|
|
What they might try doing is:
|
|
|
|
* Have a background process of high priority waiting for your tick. (It could
|
|
even just always have a one-byte read pending vs polling the serial port.)
|
|
|
|
* Share a data module (containing the latest desired text annotation) with
|
|
the main process and the background process.
|
|
|
|
* The background process can then respond to your tick fairly immediately.
|
|
|
|
This assumes, of course, that they don't have any far more critical (higher
|
|
priority) processes or long interrupt routines. No OS can handle the case
|
|
where there are more high-priority processes than there is cpu power to handle
|
|
them :-)
|
|
|
|
best - kevin
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 20199 S1/General Interest
|
|
09-Aug-94 21:57:44
|
|
Sb: #20196-#RS232 response time?
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Kevin Darling 76703,4227 (X)
|
|
|
|
Even easier than a shared data mod would be for the main routine to have a pipe
|
|
to the background process. When the background process learns that the
|
|
annotator is ready it just needs to read from a path. Hmmm, would this be as
|
|
fast as writing to memory? Probably not much difference?
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 20201 S1/General Interest
|
|
10-Aug-94 09:57:26
|
|
Sb: #20199-RS232 response time?
|
|
Fm: Simon R Ashby 100111,2173
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Thanks to both of you.
|
|
I will see what gives.
|
|
Regards Simon A
|
|
|
|
#: 20208 S1/General Interest
|
|
14-Aug-94 01:55:33
|
|
Sb: #20193-RS232 response time?
|
|
Fm: Ken Scales 74646,2237
|
|
To: Simon R Ashby 100111,2173
|
|
|
|
Simon -
|
|
|
|
> There is a non-real-time setup protocol for positioning the
|
|
> display and crosswires etc, plus a real-time mode where we provide a
|
|
> 'tick' character at 19200 baud every video field sync. If they reply in
|
|
> 3ms with their 10-character data string then we guarantee that the video
|
|
> recording annotation will be deterministic. The data string contains text,
|
|
> numbers, flags and X-Y position for two crosswires.
|
|
> They claim to be unable to respond in 3ms - more like 25ms.
|
|
|
|
I am, of course, not familiar with the details of what you are doing, so please
|
|
consider my comments in this context.
|
|
|
|
At 19200 baud, assuming 1 start bit and 1 stop bit (i.e., 10-bit characters),
|
|
each character will take about 0.52ms to transfer.
|
|
|
|
Once your system transmits the 'tick' character, it will take 0.52ms before the
|
|
other system has received it. This leaves 2.48ms for that system to respond.
|
|
|
|
Assuming zero processing time, it will take 5.2ms for the other system to
|
|
transmit the 10-character data string to your system -- an absolute minimum
|
|
total of 5.72ms after you have transmitted the 'tick' character. So you may
|
|
want to review that 3ms specification.
|
|
|
|
Of course, this does not account for the other 19ms they claim they require. As
|
|
Kevin and Bob have said, several factors can influence this number.
|
|
|
|
Best of luck... / Ken
|
|
--------------------------------------------------------------------------
|
|
Ken Scales Delphi:KSCALES Internet:kscales@delphi.com CIS:74646,2237
|
|
|
|
#: 20195 S1/General Interest
|
|
09-Aug-94 14:15:01
|
|
Sb: VMEbus KIT / OS-9 Tools
|
|
Fm: Oliver Reischke 100302,3271
|
|
To: ALL
|
|
|
|
|
|
|
|
|
|
|
|
PRODUCT NEWS
|
|
|
|
|
|
|
|
|
|
|
|
WRITE/FAX: DTR DATENTECHNIK REISCHKE KIEL
|
|
|
|
BREMERSTRASSE 2, D-24118 KIEL
|
|
|
|
24h-FAX-HOTLINE ++49-431-86511
|
|
|
|
WE SUPPLY OS-9 SOFTWARE
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VDPR-1 VMEbus Interface Kit PRODUCT NEWS
|
|
|
|
|
|
|
|
VMEbus Dual-Ported-RAM Interface Kit
|
|
|
|
The VDPR-1 is a Dual-Ported-RAM Interface designed to interface with any
|
|
user-specific microcontroller application. The VDPR-1 makes your application
|
|
run on VMEbus systems (within a week or less!). The VDPR-1 is equipped with
|
|
a parallel connector, so that the user may design a piggy-back to carry the
|
|
application. The VDPR-1 built-in interrupt handling and serving makes using
|
|
VMEbus interrupt very easy!
|
|
|
|
-> 3HE/4TE Board Design (100x160 mm)
|
|
-> Free area for application (80x85 mm)
|
|
-> A16/D08(EO) VME-Bus-Interface
|
|
-> 1024 Byte Dual-Ported-Ram Area
|
|
-> Interrupt Level 1-7 (ROAK)
|
|
-> Interrupt vector setup via software
|
|
-> ASM/C Software support
|
|
-> Temperature 0-70 C or MIL spec.
|
|
-> DIN 41612 connector (C 96 pin)
|
|
-> Design based on IEEE 1014/ IEC 821 Rev.C
|
|
|
|
|
|
|
|
VDPR-1/DDD + GAL VMEbus Interface Kit PRODUCT NEWS
|
|
|
|
|
|
|
|
Full Design & Development Documentation including GAL-Equations
|
|
|
|
DTR offers full design and development documentation. All VDPR-1 circuit
|
|
plans,
|
|
part lists, and GAL equations will be shipped. The client may incorporate the
|
|
VDPR-1 into own applications.
|
|
|
|
-> More than 60 pages of documentation
|
|
-> Full design manuals
|
|
-> Full operation manuals
|
|
|
|
|
|
|
|
DEVTOOL OS-9/68k Utility Package PRODUCT NEWS
|
|
|
|
|
|
|
|
OS-9/680x0 devTOOL Pak Object-/Sourcecode License
|
|
|
|
Utilities From Disk Editor to Undelete
|
|
|
|
The devTOOL utilities form a useful completement to those available with OS-9.
|
|
Many of them are based on ideas and methods which work well on other operating
|
|
systems. The devTOOL package contains a set of practical utility programs for
|
|
system development and application programming. It has over 90 useful
|
|
utilities.
|
|
The devTOOL utility package is designed to run on every OS-9 system. Its
|
|
features include a complete set of WILDCARD file manipulating utilities, a
|
|
disk sector editor and other functions which are useful for service and system
|
|
maintenance. The following sections are included :
|
|
|
|
System Utilities System Analyze Tools System Maintenance and
|
|
Service
|
|
Text File Processing Text File Output Routines Programming Aids
|
|
System Software File Maintenance Utilities C-Libraries
|
|
|
|
All utilities will run without any additional support files (except OS-9
|
|
TERMCAP is neccessary for some tools) . No installation is required
|
|
('plug-n-play' software). The software package has to be copied into a
|
|
directory on your harddisk and is ready-to-go. All of the devTOOL package
|
|
utilities provide a convenient user interface and a quick reference on using
|
|
the "-?" command line option. As an extension to standard help, an extra
|
|
"Example" section has been added to the objects help area.
|
|
|
|
Provided Programs in full Source Code
|
|
|
|
AEX Fork a process at specific date/time
|
|
BEN System state performance test
|
|
|
|
#: 20194 S3/Languages
|
|
09-Aug-94 03:36:09
|
|
Sb: #20072-68xx XASM on DOS machine
|
|
Fm: Simon R Ashby 100111,2173
|
|
To: DOUG 72667,1433
|
|
|
|
X-asm on DOS 68xx 8-bit
|
|
Try:
|
|
IAR Research (swedish but with international outlets)
|
|
Avocet (US)
|
|
2500AD (US) (both these also do small C compilers)
|
|
MPE (UK, Southampton, Forth house but better than assembler on its own)
|
|
|
|
Those are all established sources with track records.
|
|
Good assembling! Simon A
|
|
|
|
#: 20186 S5/OS9 Users Group
|
|
07-Aug-94 17:04:25
|
|
Sb: #20175-#alm_delete bug
|
|
Fm: Nick Hall 100330,2555
|
|
To: Peter J. Neutelings 100024,171 (X)
|
|
|
|
Peter,
|
|
|
|
Yes, we had the same problem on TV automation systems we were developing. The
|
|
work-around, if I remember correctly, was to make the alarms cyclic but I guess
|
|
this might be not appropriate for your systems.
|
|
|
|
We have also recently discovered a bug in the kernel for OS9/68K v2.4 that
|
|
causes the system to freeze if too many alarms are used! This was apparently
|
|
known about and a patch was forthcoming from our local Microware office.
|
|
|
|
Regards,
|
|
Nick Hall
|
|
|
|
Channel 4 TV, UK.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 20191 S5/OS9 Users Group
|
|
08-Aug-94 22:07:48
|
|
Sb: #20186-#alm_delete bug
|
|
Fm: Kevin Darling 76703,4227
|
|
To: Nick Hall 100330,2555 (X)
|
|
|
|
Nick,
|
|
|
|
I've also recently heard about that alarm bug in 2.4. How many alarms (and
|
|
what kind) does it take to freeze the system? We're getting strange lockups
|
|
all of a sudden on some machines which use the net a lot.
|
|
|
|
thx - kev
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 20197 S5/OS9 Users Group
|
|
09-Aug-94 19:30:46
|
|
Sb: #20191-#alm_delete bug
|
|
Fm: Nick Hall 100330,2555
|
|
To: Kevin Darling 76703,4227 (X)
|
|
|
|
Kevin,
|
|
|
|
It appears that the problem is caused when a system-state 'process' (i.e a
|
|
driver) takes greater than 1 tick's worth of CPU time. Assuming the clock tick
|
|
is on a higher interrupt, the system global DTick value is still incremented,
|
|
but if the value goes past the alarm time when the driver returns, the hang can
|
|
occur. I guess the more alarms you have and the more frequent they go off, the
|
|
greater the chance of hitting the problem.
|
|
|
|
This problem has been fixed in v3.0 (so I believe) and hence the patch to our
|
|
kernel - thanks to Microware UK, who got us out of a nasty problem with only
|
|
days to going live with 2 new systems. Two useful utilities from Microware were
|
|
'alarms' and 'sleeps', which provide info on the alarm and sleep queues.
|
|
|
|
Whilst the problem no longer seems to cause the freeze, we still don't what is
|
|
soaking time in system-state. I'm looking into another problem of perceived
|
|
system slow-down when user interfaces load the network, but after reading your
|
|
message perhaps the two are related! You're not using OS-9 ISP (on MVME167/147
|
|
boards) by any chance?!
|
|
|
|
Regards,
|
|
Nick.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 20203 S5/OS9 Users Group
|
|
11-Aug-94 00:08:28
|
|
Sb: #20197-alm_delete bug
|
|
Fm: Kevin Darling 76703,4227
|
|
To: Nick Hall 100330,2555
|
|
|
|
Nick,
|
|
|
|
Thanks for the info on the alarms glitch!
|
|
|
|
Yes, we're using OS-9 ISP on a MVME147, a MVME167 and several PEP VM40/VCOMs.
|
|
|
|
We began having lots of trouble with the PEPs which beat on the net (almost
|
|
2/3's of the cpu application time is spent on net transfers). Mostly the
|
|
networking would cease to function (no telnet, ftp, but sometimes pings work),
|
|
although once on a great while the whole machine would hang.
|
|
|
|
PEP told us about the alarm bug, but we generally aren't using alarms in our
|
|
code when the hangs occur. So far, we've tried a newer ISP version (with yet
|
|
another version coming beta from MW), cutting down net usage, etc. I also tried
|
|
bumping up the default IRQ system stack just in case the net drivers were using
|
|
a lot of stack space. No help yet.
|
|
|
|
We have noticed that the ISP processes such as ifman eat a lot of cpu time.
|
|
|
|
best - kevin
|
|
|
|
#: 20198 S5/OS9 Users Group
|
|
09-Aug-94 21:20:44
|
|
Sb: #20191-#alm_delete bug
|
|
Fm: Boisy G. Pitre 74464,3005
|
|
To: Kevin Darling 76703,4227 (X)
|
|
|
|
> Nick,
|
|
>
|
|
> I've also recently heard about that alarm bug in 2.4. How many alarms
|
|
> (and what kind) does it take to freeze the system? We're getting strange
|
|
> lockups all of a sudden on some machines which use the net a lot.
|
|
|
|
Speaking of alarm bugs in 2.4: I wrote a daemon at work some time back which
|
|
set up a cyclic alarm as super user, then changed to another user via setuid().
|
|
When the daemon died prematurely as the changed user, the kernel went in an
|
|
infinite loop trying to delete the alarm. I can't remember the particulars,
|
|
but it has been fixed in 3.0 -- Boisy G. Pitre__ __ __ Delphi:
|
|
BOISY
|
|
|_ _| \ \/ / CompuServe: 74464,3005 I use... _|
|
|
|_ > < Internet: boisy@os9er.waukee.ia.us
|
|
|_____|NFO/_/\_\PRESS 1.2.0 OS-9 -- King of Operating Systems
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 20204 S5/OS9 Users Group
|
|
11-Aug-94 00:08:55
|
|
Sb: #20198-alm_delete bug
|
|
Fm: Kevin Darling 76703,4227
|
|
To: Boisy G. Pitre 74464,3005 (X)
|
|
|
|
Boisy,
|
|
|
|
Aha. Thanks, that gave me some more clues (especially the part about changing
|
|
user ids).
|
|
|
|
Seems like half of our problem was overheating of commercial grade cpu cards
|
|
due to blocked filters. The other half of the problems, we're still searching
|
|
for a solution.
|
|
|
|
best -kev
|
|
|
|
#: 20200 S7/Telecommunications
|
|
09-Aug-94 22:23:13
|
|
Sb: #20173-Help with MM/1 hi speed
|
|
Fm: Ken Scales 74646,2237
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
> Okay, Ken, here is the dope on the 68681.
|
|
<<<<< deleted >>>>>
|
|
> BTW, I hope someone captures this...I don't intend to type it in again
|
|
> <g>.
|
|
|
|
Thanks, Bob. Yes, I captured it. It is now saved as
|
|
"/h1/usr/notes/68681.bauds". I hope that somebody will jot down that filename,
|
|
so that I can find it again... <g>
|
|
--------------------------------------------------------------------------
|
|
Ken Scales Delphi:KSCALES Internet:kscales@delphi.com CIS:74646,2237
|
|
** Composed with KVed/Ved and uploaded with InfoXpress **
|
|
|
|
#: 20189 S12/OS9/68000 (OSK)
|
|
08-Aug-94 17:01:40
|
|
Sb: makdir
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: All
|
|
|
|
Just noticed some bitrot with my new makdir program I posted here last week. If
|
|
you do download it, please make one change to the source and recompile! The
|
|
function terminate() should end in an exit(0). As is, it says that the program
|
|
has ended with a bad option, but it really continues on <g>. I'll wait for some
|
|
feedback before reposting...
|
|
|
|
|
|
#: 20205 S12/OS9/68000 (OSK)
|
|
11-Aug-94 02:35:51
|
|
Sb: HP500 dump
|
|
Fm: John Strong 72270,1555
|
|
To: Larry Olsen
|
|
|
|
Subject: HP500 screen dump To: LARRY OLSON 72227,3467
|
|
|
|
Larry,
|
|
|
|
Painter (SPAINT) has a DeskJet 500 dump. I did it in landscape format.
|
|
and dithered the colors to 32 level gray scale, not too bad looking, however
|
|
the aspect ratio is a bit off compared to CM-8 on my MM/1. Between my brother
|
|
and I, we have 4 CM8s and the screen sizes are different on each one! Which
|
|
one should I try to match???
|
|
|
|
A friend offered to loan me his 550c, so I could do a color dump for
|
|
Painter, however as you mentioned the manuals are poor when it comes to
|
|
programming info (I think they want to sell you another manual if you are a
|
|
programmer). The problems associated with color space conversion is more than
|
|
I care to mess with at this time, maybe after the rest of the program is
|
|
finished I'll change my mind.
|
|
|
|
As you know, Painter is programmed in assembly, so the technique I used
|
|
wouldn't help you much. (primarily a lookup table)
|
|
|
|
BTW, Painter should be done soon! (I hope <grin>.) And I will be doing
|
|
a mailing to announce its release. So, if you know of anyone interested in it,
|
|
have them send me their address.
|
|
|
|
BTW, how is your battleship game comming along?
|
|
|
|
John R. Strong
|
|
StrongWare
|
|
|
|
#: 20202 S14/misc/info/Soapbox
|
|
10-Aug-94 21:06:41
|
|
Sb: #19697-OS/9 vs pSOS
|
|
Fm: Thomas Baumeister 100341,624
|
|
To: Cherry Valley Lang Tech 71055,2527
|
|
|
|
Hello Steve,
|
|
|
|
some months ago I made a detailed comparison of OS/9 and pSOS for a
|
|
customer planning a real-time application with a GUI. We ended up choosing
|
|
pSOS, and I'm using pSOS for almost 2 years now.
|
|
Contact me if you are interested in my results.
|
|
BTW, is there any other forum on CIS where 680x0 issues (not necessarily
|
|
related to OS/9) are discussed?
|
|
Thomas.
|
|
|
|
#: 20187 S14/misc/info/Soapbox
|
|
07-Aug-94 20:52:22
|
|
Sb: #20185-6802/6809 assembler
|
|
Fm: DOUG 72667,1433
|
|
To: Jay Truesdale 72176,3565
|
|
|
|
Thanx fer the info. Will check IBMPRO and also my buddy FHL.
|
|
|
|
Doogie
|
|
|
|
#: 20207 S14/misc/info/Soapbox
|
|
13-Aug-94 13:43:12
|
|
Sb: coco/os-9 sale items
|
|
Fm: Chuck Watters 70115,536
|
|
To: all
|
|
|
|
CoCo Hardware - Software - Magazines for sale
|
|
|
|
|
|
I have an extensive number of CoCo hardware and software items for sale. Too
|
|
many to post . E-mail me on CIS (70115,536) ; AOL (CKWSR) or Prodigy with you
|
|
name and address . I will mail you a copy of the catalog of available items.
|
|
|
|
|
|
Press <CR> !> |