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