os9@cbosgd.att.com (10/31/86)
OS-9 Discussions Friday, October 31st 1986 Volume 2 : Issue 4
Today's Topics: [ Happy Halloween! ]
Coco-III Discoveries
various and sundry things...
Atari OS-9
VX Works
Moderator Notes:
These articles arrived this week. You will note that the last article,
VxWorks, is quite large. I discussed the propriety of sending the article
with a number of people. The article is not directly OS-9 related and
does contain new product information. The blurb has not yet shown up
in mod.newprod and I'm not sure that the readers of this group (with
mailing list) also read mod.newprod. In the end, I decided to error
in the side of making sure that the information was available.
The author of the VxWorks blurb appears to have some misconceptions about
the scope of OS-9. OS-9 is not just used for process controls; it is a
general operating system that nicely supports real-time capabilities which
are necessary for effective process controls work. Putting the misconception
aside, though, I found the information intruiging. VxWorks is a significant
direction, in that UNIX can have front-end processes which provide real-time
capabilities. It still appears that OS-9 more cleanly supports process
controls because of the ability of the entire kernel and any modules to be
written to ROM. For larger applications VxWorks may prove more effective.
I'm going to wait and see and keep looking at both.
--------------------------------------------------------------------------
Date: Fri, 24 Oct 86 13:53:35 edt
From: ihnp4!ihwpt!knudsen
Subject: Coco-III Discoveries
Reposting from net.micro.6809 and .trs-80.
-- mike k
------------------------------------------------------
Last nite at the Chicago OS9 User's Group meeting,
someone brought a Coco-III and we decided to do
the scheduled software talks & demos on the III
as far as we could, till something wouldn't work.
A TDP-100 (Coco 1.5) was standing by to finish the demos.
Incredibly, everything was made to work in the III!
>From this evening and some home diddling, I can tell
you these tidbits, some of which CONTRADICT other things
I've heard. Bear in mind that different people on CompuServe
report different experiences too; seems some Coco IIIs
are more equal than others, depending on your peripherals,
temperature, religion, who's watching ...
(0) Disk controllers: Non-RS DOSes like ADOS and CDOS
throw graphics snow all over the screen at power-up,
or at least fail to be recognized (the copyright notice
says "Extend Color BASIC 2.0", no mention of "disk".
Someone on CompuServe says to try EXEC &HE010 in the latter
case, as this forces BASIC to copy and patch the DOS as
it does for RSDOS 1.0 and 1.1. Didn't do a thing for us
except get us hung.
We could not get ADOS or CDOS to boot. Incredibly, JDOS,
the black sheep of compatibility, worked (mostly).
Someday we will understand all this. Really.
(1) Multi-Pack (MPI): Some MPIs get software-switched to
Slot 1 by the new BASIC's initialization, probably thru
their ghost address at FF9F. You can tell by ?PEEK(&HFF7F).
If this gives 255, your MPI is safe. If 0, then you'll
have to put your disk controller (or whatever) in Slot 1,
and you can't select the other slots (tho self-decoding
paks in them work fine).
Don't bother POKEing FF7F to some other slot; something in
new BASIC just keeps hammering it back to 0. (Well, try it!)
(2) OS9 versions 1.0 or 1.1 can be booted up ONLY by first
booting Version 2, then inserting your 1.1 or 1.0 boot disk
and hitting RESET. Yes this is weird!
(3) The CocoMax mouse pak CAN be read properly, even tho
its FF90 address is the new GIME's interrupt control register
(or something like that). Granted, I did this under OS9 1.1
booted behind 2.0 as above.
Or maybe the mouse pak was just driving the data bus harder
than the GIME chip (no writes involved here), and someone's
GIME chip ain't feeling too good this morning.
Speculation: the new GIME (VDG+SAM) chip may have modes
where it is less vulnerable to reads/writes in its new
areas (like the FExx page). Version 2 may set this mode
to "harden" it against whatever wrong things the earlier
versions do.
This would explain (2) and (3).
Why doesn't new BASIC set these hard-shell modes at power-up???
You guys with OS9 disassemblers: check the boot code for
new writes into the I/O pages -- if there's a way to get more
Coco-II compatibility by setting up the GIME, we should
know about it.
(4) The double-speed poke (FFD9) works great, even under OS9.
However, disk reads may fail, and writes are definitely not
recommended if you're fond of that diskette. It was fun to
watch my music score editor graphics go twice as fast.
Games can be run at double speed UNLESS they auto-load;
the double-speed messes up the remaining disk reads.
"Cracked" copies are best, since
if you can LOADM and then EXEC, do the POKE before EXEC.
"Marble Maze" gets smoother and more natural, not just harder.
(5) You know that any Coco can get messed up enough that RESET
won't work; you have to cycle power.
Seems that on the III, the "three stooges" reset (hold CTRL and
ALT while RESETting) usually guarantees that the next RESET push
will get you a COLD (not warm) restart. Nice.
Oh yes, our club decided that this picture is at $C000,
the area covered by cartridge ROM (including disk),
so useful ROM space was not wasted (tho some fancier
initializations could have been put there).
(6) The pokes to get real lower case on late Coco-IIs
(poke 359,0 and poke 65???,80) still work on the III,
allowing lowercase on WIDTH 32.
(7) CocoMax doesn't finish booting. P51 hangs right after
the runway select option comes up. Probably these programs
use FExx, as does my old music synthesizer. Even the Rainbow's
pompom boys took Tandy to task for not warning us away from there.
Please share your experiences, especially where they differ
from the above. More news as it happens ... mike k
------------------------------
From: ihnp4!mcrware!jejones (James Jones)
Date: 26 Oct 1986 2206-CST (Sunday)
Subject: various and sundry things...
Comments on the latest issue of mod.os.os9:
>1. Of the available hard disks for the CoCo, which would you
>recommend?
The interface I see most recommended for CoCo hard disk is the
LR Tech interface (which I believe OwlWare sells).
>2. Is the hard disk compatible with RSDOS? What is the directory
>structure (broken into x devices? RS directories under an OS9
>directory? OS9 directories under an RS file?)?
I'm not sure why you want to bother with RSDOS :-), but yes, I
believe that it will let you partition the hard disk into RSDOS
and OS-9 sections. I can't say too much about this, because I
don't use RSDOS. I recommend snarfing names and phone #s of com-
panies from any recent issue of *Rainbow* magazine.
>3. What about hard disk compatibility with CoCo III and OS9 level II?
There's no disk layout change from Level I to Level II, and in a Level
II device driver for a hard disk I once moved to OS-9/68000, I saw no
magic memory-twiddling code, so there should be no problems on that
score. The place I'd wonder about incompatibilities is the cartridge
port, what with old MultiPaks requiring hackwork to run with CoCo III.
(Note--all the hard data I've been able to find is that a PAL needs
replacement. Gee, I wish that they would run the IRQ line out on the
cartridge port!)
------------------------------
Note for OS-9 Kermit users: a bug was reported on BIX in OS-9 Kermit,
namely that in os9srv.c, the pointer filnam (sp?) isn't initialized
before the code copies the name of the file to be transferred into
where the pointer points. Declaring a buffer and pointing the variable
at it corrects the problem.
It looks like the mailing to you was snarfed from a Info-Kermit digest.
If there's not a central point for reporting OS-9 Kermit bugs, I'll
send this one in, just in case it hasn't already been reported.
------------------------------
>What could uEmacs become on the Coco III under Level II?
>Well, to start with, could we restore one of Emacs's
>most valuable features, multiple buffers?
Mike Knudsen, whom I respect a good deal, activated one of my
sermonettes :-). Windowing doesn't belong in editors. Windowing
belongs in its own module, so that you can take stuff from one
window and put it in another, no matter what is running in
either of the two windows!
>How well does Level II provide for playing games with the
>memory mapping? Are such tricks supported, or are Level II
>users just supposed to enjoy the one larger (almost 64K) space?
>Will we have to "poke" the GIME chip's DAT registers "by hand?"
See either the non-stripped down OS-9/6809 manuals or Chapters
31 and 32 of Puckett and Dibble. (I recommend both, but then,
I wear both belt and suspenders sometimes. :-) That's all I can
say, because I've not studied the Level II calls very hard.
>PS: Is the Coco III keyboard truly interrupt-driven, or does it
>still go dead while the disk is transferring data?
To answer your question: yes and no, or is that yes and yes?
Yes, the CoCo III keyboard is truly interrupt-driven, and
(*sob*!) yes, Tandy CoCo floppy controllers still halt the processor
for every !@#!#$!@#$!@ byte transferred to or from the floppies.
------------------------------
>Does os9 support multiprocessing in any way? A Unix-like multiprocessing
>(as in multiprocessor) system would be ideal for a project I am currently
>involved in. Even if 4.2BSD IPC-like facilities and ethernet were avail-
>able it would be far better than the system we are now considering.
Hmmm....OS-9 does support networking--all they had to do was add a file
manager and appropriate device drivers, and off it went. (Nice thing
about modular structure.) I don't know of any multiprocessor OS-9 systems.
It's fun to think about, though. Just how to break things down and
at what level and when you'd want to be able to move things from place
to place is an interesting question.
------------------------------
Let me know if it's better to send one response per item.
[No, collections of responses to a digest are appropriate. It would be
most effective to identify which digest is being discussed. - JDD]
James Jones
"My opinions are mine! All mine!
You can't have them! :-)"
------------------------------
From: <ihnp4!lsuc!jimomura>
Subject: Atari OS-9
Date: Mon, 27 Oct 86 12:33:44 est
Hi John:
First, to answer the question "where am I", I'm in Toronto.
:-) Seriously, I have changed all but 1 of my computers (only
my original Color Computer out of 6 computers I had last spring
remains) and am in the middle of rebuilding my software set.
At this time I don't have a reliable method of uploading to Usenet.
As such, everything I say 'here' is composed online, and my
system manager doesn't want me tying up resources. I hope
to have a solution reasonably soon.
Briefly, the Atari ST port really good. Documentation is
primarily the standard Microware OS-9 Manuals along with the
usual hard cover 3 ring binder and 38 pages of the Atari specific
documentation.
You must specify if you have Single or Double sided drives.
I have only 1 drive with my 1040ST (double sided) so what I
received was a 3 disk set as follows:
1. GEM formatted disk with necessary booting programs.
2. System Diskette One which holds the system itself
3. System Diskette Two which holds the assembler related files
(DEFS, LIB, and SYSSRC directories)
Keep in mind that I will *not* be using my Atari as my
primary OS-9 system. A single drive 1040ST cannot be considered
a serious OS-9 system. In fact, a single floppy disk computer
of *any* brand isn't really serious. Still, it's amazing how
functional even this minimal configuration turns out.
The OS-9 package comes with all you need to run with RAM Disk
(of any size) and up to 2 floppies (the limit of the current Ataris)
and Hard Disk (either Supra or Atari). OS-9 68K, and this Atari
port in particular cry out for HARD DISK! The hard disk driver
allows disk caching for read functions (writing is direct to the
disk). Unlike the current limits of what's available for TOS,
the disk caching is user definable in 32K pages. Along with
named pipes and loadable execution modules, we have *every*
means possible of optimizing RAM usage to gain speed.
The floppy disk speed itself is deceptive. The floppies run
about as fast as possible. Benchmarking shows that it's about as
fast as the Amiga floppies. Unfortunately, the ST floppy is a
bit on the noisy side (no software fix possible :-) which made me
think that it wasn't running as fast as it was.
My current setup is 360K RAM disk and a lot of memory resident
modules (dir, list, copy, makdir, deldir, del, dsave, load, link,
unlink, edt and grep to name a few).
One of the reasons that the hard disk is really the preferred
setup is the use of the RESET vector which returns to GEM rather
than rebooting OS-9. I have just learned that the reset vector is
in RAM and therefore redirectable. I think I'll likely make a
short utility which iiiiii.
------------------------------
From: ihnp4!dual!wrs!jerry (Jerry Fiddler)
Subject: VxWorks
Date: Mon, 27 Oct 86 11:15:24 pst
New Product Announcement
VxWorks
Wind River Systems markets a real-time system called VxWorks. For
many applications, this system is a superior alternative to OS-9. Unlike
OS-9, VxWorks is not a self-hosting system. Rather, it operates in
partnership with Unix. The Unix system is used for development, and
non-real-time tasks. The VxWorks systems communicate with Unix using
standard Unix sockets. The VxWorks systems act as "real-time servers" to
Unix. In a final system, of course, the system may also operate standalone,
if desired.
I've enclosed some "marketing copy". If you want more info, send me
your snail-mail address and I'll ship you some (or call me and we'll set
up a demo, if you are local).
I've enclosed troff source. If you can't troff it, just nroff it (-ms).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Cut here =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.WP "VxWorks Data" "Wind River Systems" 1.1
.TL
VxWorks: A Real-Time Partner for Unix
.AU
Wind River Systems
.br
1316 67th St.
.br
Emeryville, CA 94608
.br
415-428-2623
.br
ucbvax!dual!wrs!inquiries
.FS
copyright \(co Wind River Systems, Inc. 1986
.sp
Unix is a trademark of AT&T
.br
VRTX is trademark of Hunter & Ready
.br
RT11 is trademark of Digital Equipment Corp.
.br
VxWorks is a trademark of Wind River Systems, Inc.
.FE
.PP
VxWorks is a real-time operating system with a difference:
a network and a development environment specifically designed
to work in partnership with Unix.
.PP
Of course VxWorks includes all the best features of modern real-time operating
systems, including a fast multi-tasking kernel with preemptive scheduling,
extensive intertask communication and synchronization facilities,
efficient memory management, fast interrupt response, and so on.
It even includes powerful symbolic debugging and performance monitoring
facilities.
.PP
But best of all is VxWorks' 4.2 BSD Unix-compatible networking facilities.
>From sockets and TCP/IP, to transparent remote file access, to remote login,
VxWorks supports the Unix network.
And wherever possible, VxWorks other facilities are Unix-compatible.
.PP
With the network and Unix compatibility,
VxWorks is not just another orphan real-time operating system.
Instead, VxWorks becomes an intimate partner with Unix for real-time
applications.
.PP
But lets start from the beginning...
.SH
What Is A Real-Time System?
.PP
A real-time system is a system which needs to monitor and/or
interact with equipment in real-time.
Such systems range from the very small to the very large.
Examples of things controlled by real-time systems are appliances,
factory automation, computer-controlled equipment, modern
airplanes, complex data gathering equipment, etc.
Such systems become more numerous daily.
.SH
Why Not Use Unix As A Real-Time System?
.PP
Unix is not appropriate for real-time use.
It lacks many of the attributes that any real-time system should have,
such as preemptive scheduling, fast context switching,
fast intertask communications and synchronization,
and fast interrupt response.
Because Unix is large and performs
many functions, its response time is often unpredictable.
Also Unix isolates the application from the hardware,
which is appropriate for timesharing, but real-time
applications often need to be "closer" to the hardware.
Finally, Unix requires considerable hardware resources,
while many real-time situations call for one or more small, perhaps
even diskless, systems.
.SH
Then Why Use Unix At All?
.PP
Unix is a superb development system, with a wide variety of compilers,
editors, source code control tools, and many software tools ideally
suited for software development.
It is a very "programmer-friendly" system and there is a large base
of knowledgeable Unix programmers.
Also many application software packages are available for Unix, including
databases, graphics, and artificial intelligence programs.
.SH
So How Do VxWorks And Unix Work Together?
.PP
VxWorks and Unix mesh to form a complete, hybrid environment.
Each is used for what it does best.
VxWorks is used for running, testing, and debugging real-time applications.
Unix is used as a high-level software development system, and to
monitor and control the VxWorks systems.
.PP
Rather than replacing Unix, VxWorks works in partnership with Unix,
creating an integrated, plug-in solution for developing real-time systems.
This is all made possible by the VxWorks network.
.SH
Describe The VxWorks Network.
.PP
VxWorks systems may be connected with Unix systems on high-speed networks,
using either Ethernet or shared memory on a common backplane.
Programs running on either Unix or VxWorks may communicate with each other
using the standard 4.2 BSD Unix socket interface and TCP/IP.
.PP
The network is useful both during development and in a final system.
For development, programs and data are quickly and easily loaded by the
VxWorks system, from the Unix host. At run-time, real-time systems
and Unix systems can share a network, allowing each to perform the
tasks at which it excels. The Unix systems can use the VxWorks
systems like "real-time servers", accessible via standard socket calls.
.SH
What Do You Mean By ``Real-Time Servers''?
.PP
Because the Unix tasks can communicate so easily with
real-time VxWorks tasks, the real-time system can be thought of as a
server, performing real-time functions, rather than as a separate computer.
Even though there are two different operating systems, Unix and
VxWorks, the user can think of there being a single, hybrid system,
with real-time and non-real-time components.
.PP
For example, imagine an expert system, running under Unix,
controlling a robot.
The robot would be under the direct control of
a VxWorks system, which in turn would be under the direction of the
expert system.
The VxWorks system acts as a server, performing its real-time function
transparently to the Unix system.
>From the expert system's point of view, it is simply
controlling the robot by reading and writing to a socket.
.PP
Or a factory automation
system might consist of a number of VxWorks systems on the factory
floor, all networked with a Unix system in the office.
>From the Unix system, an operator could log on to any of the VxWorks
systems to monitor or control them.
The Unix system might also handle inventory or respond to alarms,
using information reported by the VxWorks systems.
.SH
Can I Also Develop Stand-alone Real-Time Systems?
.PP
Absolutely.
Once development is complete, the real-time system running under
VxWorks may operate stand-alone without a Unix host and without a network.
VxWorks systems may be disk-based or even ROM-based.
The networking and debugging facilities may be removed from the production
system to cut down on memory requirements,
or they may be left in for field-serviceability and diagnostic purposes.
.SH
So How Do I Develop My Real-Time System?
.PP
During development, Unix host systems are connected to VxWorks target
systems on a network.
Unix is used to edit, compile, link and store real-time code that
will be run and debugged under VxWorks.
VxWorks is able to load normal Unix object modules (a.out format) directly,
and \fIvery\fR quickly, over the network.
Debugging is done under VxWorks, using its powerful symbolic debugging,
testing, and performance monitoring facilities.
Using the VxWorks shell, it's easy to spawn tasks, start and stop tasks,
set general or task-specific breakpoints, single step tasks,
examine stacks, trace task execution, time various functions, and much more.
Any subroutine in the application (or in the system for that matter)
may even be called directly from the shell.
.SH
In What Language Do I Write My Application?
.PP
Normally, the entire application is written in C. VxWorks uses the C
subroutine as the basic unit of code. Any C subroutine may be called
from the VxWorks shell. Any C subroutine may be spawned as a task.
Any C subroutine may be connected to an interrupt or a watchdog timer.
This consistency makes VxWorks simple to learn and use.
.PP
It is also possible to use other languages that can generate C-compatible
code, such as Fortran, Pascal, and assembly language.
.SH
What Else Can the VxWorks Network Do?
.PP
First, VxWorks provides transparent remote access of Unix files.
Programs running under VxWorks can access files on any Unix system,
via the network, exactly as if they were local to the VxWorks system.
For example, "/dk/file" might be
a file local to the VxWorks system, while "/host/file" might be a file
located on another machine entirely. To programs running under
VxWorks, the files operate in exactly the same way.
.PP
Also, VxWorks supports remote login.
Using the Unix \fIrlogin\fR, you can use the VxWorks target
system's shell right from a Unix terminal. In fact, with a
window-based Unix workstation, you can reach all the VxWorks target
systems in separate windows, all from the same workstation!
.SH
What Kinds of Hardware Does VxWorks Run On?
.PP
The VxWorks operating system can run on any 68000 family computer.
VxWorks can be hosted by any 4.2 BSD or 4.3 BSD Unix system,
and many systems with 4.2 BSD-compatible network facilities.
.DS L
.ce
\fB\s+2VxWorks Specifications\fR\s-2
.sp .75i
.B
Hybrid System
.R
A true real-time system
Uses Unix as a development system
VxWorks may be used as a "real-time server"
All development may be done from a single Unix terminal
Fast, transparent communications
.B
Simple, Powerful, Unified
.R
ANY C-compatible subroutine may be
spawned as a task
called from the shell
connected to an interrupt
connected to a watchdog timer
.B
Network
.R
Sockets; source-compatible with Unix BSD 4.2
TCP/IP
Transparent Remote File System
Remote command execution
Ethernet or VME-backplane communications
.B
Unix Source Compatibility
.R
Basic I/O
read, write, create, delete, open, close, ioctl
High-Level I/O
printf, scanf
Memory Management
malloc, free, realloc
Network
sockets
.B
Shell
.R
C-Expression Interpreter
Interprets any C expression, \fIincluding function and
variable references\fR
Can call ANY user or system subroutine
May be accessed by a terminal or from any Unix system,
via \fIrlogin\fR
.B
I/O System
.R
Very fast and flexible
Drivers may be dynamically added to a running system
Formatted I/O library (printf & scanf)
Includes extensive driver support libraries for
interrupt support, ty support, etc.
I/O devices included
Ram driver
Pipe driver
Network driver
Ty driver
Pseudo-terminal driver
.B
File System
.R
Multiple file systems may be added, or may be configured
with no file system for minimum memory
RT11 compatible file system included
Fast
Contiguous files
Any byte may be retreived in single disk access
.B
Loader
.R
Loads normal Unix (a.out format) object files
Loads from network or local disk
Relocates and resolves externals at load time, for
shared code
Incremental loading of modules
Adds global (and, optionally, local) symbols to system
symbol table
.B
System Symbol Table
.R
Contains all global system variables and functions
Contains all global user variables and functions
Optionally keeps local symbols as well
.B
Shared Code
.R
All code is reentrant, and may be used by multiple tasks
A single routine may be spawned as multiple tasks, each
with its own context, stack, and registers, all sharing
the same code
Incremental loading of modules
.B
Tasks
.R
Up to 256 tasks
Up to 256 priority levels
Full Pre-emptive or Round-Robin Scheduling
Task State Control
spawn a task
delete a task
suspend a task
resume a task
Task Information
examine any task, any time
stack-trace; displays current "calling-tree" of task
print a summary of each task's stack usage, find
stack overflows
summarize current state of all tasks
examine/modify task's registers
.B
Memory Management
.R
Variable size memory allocation
Size of allocated blocks may be increased or reduced
Unix source compatible (malloc, free, and realloc)
.B
Intertask Communications & Synchronization
.R
Semaphores for simple synchronization and access control
Pipes for fast, flexible data communications within a CPU
Sockets for communications within or between CPU's or
operating systems
Shared memory areas
Ram-disk I/O device for "managed" shared memory
.B
Interrupt Support
.R
Very low interrupt latency
Any C subroutine may be connected to an interrupt or trap
Simple communications between interrupt and task level
semaphores
race-free ring buffers
pipes
.B
Watchdog Timers
.R
Allow timeouts of any function
.B
Exception Handling
.R
All hardware exceptions are handled
Task causing exceptios are suspended, not deleted
Task may be traced, examined to find cause
Message logging
Unified exception handling mechanism
Error status set by module causing exception
All status values may be displayed in English
.B
Debugging
.R
break-point any task or group of tasks
single-step any task
step-over subroutines
Symbolic Disassembler (Motorola Format)
Display and Modify Memory
.B
Performance Monitoring
.R
Time any function
Time any function or group of functions iteratively to achieve
high accuracy for short operations
.B
VRTX Support
.R
Includes Hunter & Ready VRTX kernel
All VRTX functions available via C interface library
.B
Utilities
.R
Buffer manipulation library
VERY fast
buffer copy, move, fill, swap
Doubly linked list subroutine library
Ring buffer subroutine library
Symbol table subroutine library
.B
Configuration
.R
Simple to configure
Production systems may be configured without shell,
breakpoints, etc. to save memory
System-dependent routines supplied for particular targets
.B
Help
.R
On-line help available
.DE
-------------------------------------
The views expressed in OS-9 Discussions are those of the individual authors
only.
------
Moderator: John Daleske cbosgd!cbdkc1!daleske daleske@cbdkc1.ATT.COM
Submissions should go to cbosgd!os9 os9@cbosgd.ATT.COM
Comments to the moderator
or to join the mailing cbosgd!os9-request os9-request@cbosgd.ATT.COM
list.
*********************
End of OS-9 Discussions
*********************