textfiles/messages/ALANWESTON/1994/CIS08_14.txt

#: 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> !>