os9@cbdkc1.UUCP (05/13/87)
OS-9 Discussions Tuesday, May 12th 1987 Volume 3 : Issue 2
Today's Topics:
OS9 on the ST
"Will there ever be a mass market OS-9/68k?"
Re: OS-9 Discussions, V2 #16 - chd
My Face Is Red Dept.
Re: os9 netnews software
2 Megabit CoCo 3
Level 2 OS9 Comments, HInts
Koronis Rift shows off Level 2
OS-9 chd command
uucpish software posted
Coco Level 2 Windows BUGS
OS9 disk repair
Regarding "A Reasonable Editor For OS-9":
Cheap OS-9?
--------------------------------------------------------------------------
Date: 7 Apr 87 17:18:50 GMT
From: src@xanth.cs.odu.edu (Scott R. Chilcote)
Subject: OS9 on the ST
Keywords: OS9, Multitasking, Neato
Organization: Old Dominion University, Norfolk Va.
Summary: OS9--It's on the way!
References: <664@atari.UUCP> <995@imagen.UUCP>
Sender:src@xanth.UUCP
In article <995@imagen.UUCP> turner@imagen.UUCP (D'arc Angel) writes:
>in article <664@atari.UUCP>, leavens@atari.UUCP (Alex Leavens) says:
>+---------------------------------------------------------
>+
>+ in article <395@laurel.wiley.UUCP>, bob@wiley.UUCP (Bob Amstadt) says:
>++ 1. Has Atari upgraded their OS to include some form
>++ of multitasking? If not does someone else supply a multitasking
>++ OS? What about MINIX?
>+
>+ No, our OS is not multi-tasking. There are a couple of multi-
>+ tasking OS's available:
>+ MT-Cshell, from Beckemeyer Development tools
>+ OS-9 from MicroWare
I have been impatient for a multi-tasking O.S. myself, having reached computer
maturity on a multi-tasking, multi user system. I broke down and called
Microware in Iowa and asked them, point blank, about OS9 for the ST. Here's
the scoop:
The previous announced OS9 release was by TLM systems, a company that was in
financial trouble at the time and no longer has their version of the OS avail-
able. Microware is releasing a completely new version of OS9, and it should be
ready for distribution in mid to late April. This will be a level 1, V 2.0
system, and will allow many of the features found in UN*X on the ST, with a few
more that are, in the opinion of this writer, -better- for a smaller system (as
compared to a VAX 11/780)...
OS9 differs from UN*X in that it is modular, in that it is composed of the
kernel surrounded by device drivers and descriptors, any or all of which can be
customized, linked or unlinked, or present in some configurations of your sys-
tem but not in others. UN*X, on the other hand, is more of a congealed mass of
code patched to order for your system. A very NICE congealed mass, but much
harder to make work on smaller computers, as many of us have noted firsthand.
OS9 allows multi-tasking and multi-user operations with a high degree of
efficiency and minimal conflict. Processes can be run as background tasks with
user adjusted priority. Modules for homebrew and third-party devices are very
easy to write and customize; just as with UN*X, be prepared for skads of
"enhancements" to start appearing on a daily basis. This has been proven on
other systems running OS9, like the GIMIX from Frank Hogg Labs. and of course,
the Tandy CoCos.
The new release of OS9 will be bundled with which anyone who has seen GFA
Basic is already familiar: Basic 09 by Microware (or just Microware Basic).
Before anyone cries "foul!" take note: Basic 09 was being sold back in '82 and
was doing just about everything that makes GFA popular at-the-time! Indention,
interpretive cross-checking, no line numbers, Modula-2 like looping constructs,
and best of all, SPEED, like the sphagetti sauce, it's in there!
The price, knock on wood, will be under $150 for BOTH the operating system,
AND the evolved Basic language.
I'm hoping like a big dog that they meet their deadline or someplace close;
while the ST is fine, there's nothing like what amounts to having a second
powerful programming machine sitting pretty on your desk. All for less than
the cost of some C compilers!
One last, but IMPORTANT, note. The sales rep I spoke to at Microware said
that she was actually interested in finding out who might be interested in OS9
for the ST, as a way of determining public interest. If you can afford the
all, and would like to see an extremely nifty operating system at a good price,
by all means give them a call!
Microware Systems Corporation
Des Moines, IA
(515) 224-1929
Scott Chilcote
INTERNET: src%xanth.cs.odu.edu@RELAY.CS.NET
USENET: src@xanth.UUCP
Date: Wed, 8 Apr 87 14:23:57 cst
------------------------------
From: ihnp4!uiucdcs!uicsl.csl.uiuc.edu!klieb (Kurt T. Liebezeit)
Subject: "Will there ever be a mass market OS-9/68k?"
[Kurt's discussion hit home for me. I come from the "orphan" world where
the system I bought (MTU-130 (ever hear of it?)) was announced a week before
the IBM-PC was first announced. It is based on a 6502. Micro Technology
later built a 68000 - 256K RAM board to plug in. I was able to port OS-9
to this configuration using the 6502 as a front-end I/O preprocessor. The
68000 has NO external interrupts. I love OS-9 68K and would love to see it
grow. I also hope it, too, doesn't become an orphan for me. That is one
reason why I support this digest! - JDD]
First of all, I really enjoy using my OS-9 computer. It has a certain
elegance, a sense that the operating system is scaled properly to match the
hardware that it runs on. Lately though, I have nagging doubts about its
future success in a world gone PC-mad. I think that OS-9 is at critical
juncture (isn't it always?).
My doubts about OS-9 hinge on the fact that there is no affordable OS-9/68k
machine with graphics hardware on the market. We all know that OS-9's
modularity makes it possible to run on an incredible variety of hardware,
but very few machines offer any sort of graphics support, and those that do
are very expensive. We are sort of stuck with the same problem that CP/M
had: we have (albeit only a few) reasonable applications for word process-
ing, spreadsheets, etc., but they are TEXT only. Meanwhile, Apple is start-
ing its second generation of Macs, Commodore is introducing its second
generation Amiga, Atari is talking about new machines . . . my point is that
the big boys are slowly but inexorably grinding out new machines that offer
the same features that make OS-9 worthwhile (multitasking, pipes, hierarchical
directories). OS-9, on the other hand, is still an excellent piece of software
wandering in search of a standard home.
The real problem is that while OS-9 lacks any sort of graphics home, no one
is going to develop any applications software that assumes the user has
anything more than an 80x24 terminal. Now for many of us, myself included,
text-only software is all we ever really use. I write programs in C or in
assembly, I tinker with XLISP, and I write letters. I am a programmer
most of the time, and guess what . . . I write programs that interact with
the user with text only. The non-programming world, however, DEMANDS some
form of graphics. The information bandwidth of straight text is too narrow.
The University here in Champaign periodically sponsors computer fairs. Last
week I strolled through one such affair, and I saw hundreds of products. Not
one of them communicated via text-only. It is hard not to have at least a
pang of jealousy when one considers how many folks are happily writing or
using programs that make use of graphics. The >variety< of applications
programs is truly stunning: CAD programs, painting programs that begin with
TV images, programs that model stresses, etc. We, on the other hand, are
happy when we get hold of a good editor, or file transfer program. In
general, we write text tools.
I'm not necessarily advocating that all machines have a Mac icon-based inter-
face. I don't like mice. You never seem to have enough room on a desk for it
to roam over. I DO think that OS-9's modularity and elegance aforethought
makes it a natural shoo-in as an OS to host a windowing environment, and
I think it is a shame that no one has seen enough of a market to risk an
investment in developing a machine. [Moderator Note: Fujitsu did... - JDD]
Microware seems aware of this problem. They support the Hitachi 63484 chip
set and the GKS/VDI standards with device drivers and C-language hooks. To
date, the Hitachi chip set has only appeared on expensive VME boards. None
of the independent OS-9-specific board manufacturers I've talked to have
any plans to offer this chip set, and at least one has nearly completed
a bare-bones hardware/software-based graphics board instead. Their reason-
ing is correct in many ways: the chip set is quirky, a software-based
solution will be lower in cost, etc. I am disappointed with their decision
because it is another step toward chaos, not standardization.
What about the Atari, you say? The problem is that Microware is competing
on someone else's home turf. No doubt Atari is working hard to catch up
with OS-9's biggest selling point on the Atari, namely multi-tasking. Atari
holds all the hardware cards, and future machines may not be as amenable
to OS-9 as to GEMDOS. There are many problems; Atari can make money on hardware
and give the OS away, but Microware has to convince owners to shell out
upwards of $150 for a new system that is complete in itself, but incompatible
with GEMDOS. I applaud Microware for their pluckiness, though; they are
going after the only mass market in sight.
The first step toward OS-9's continued success must be a reasonably-priced
graphics-based machine. Once we have that, OS-9 will attract the software
developers easily: programmers like ourselves have always appreciated
the clean, consistent design inherent in OS-9.
What would be ideal hardware? My personal opinion is that there is a
market for the following machine:
This machine would be 68020 based, with the possibility of plugging in an
optional 68881 FPU. I think that it would be cost-effective to simply adapt
Steve Ciarcia's HD63484 graphics board onto the motherboard. I favor having
DMA, but I am told that Motorola still doesn't have a good DMA chip to that
works well with the 68020. If there is a standard chip, fine, use it; other-
wise make do with interrupt-driven I/O. I think that memory protection is a
must; it is the only great advantage that this machine could offer over an
Amiga. Microware has hooks in their 68020 version that simply protects
tasks from each other without relocating them. This is good enough, in my
opinion. The hardware isn't too bad, I'm told; it simply looks up every
memory access in a look-up table for protection in parallel with the actual
operation, and violations generate a bus error.
So far, so good. One has to keep the cost of a new machine down, and I would
recommend tapping into as much of the IBM clone market as possible. Put it in
a clone box, hook it up to a clone power supply, use standard 360k 5.25" or
720k 3.5" floppies, provide a clone keyboard. My radical suggestions are to
make the motherboard as complete as possible (as much of a single board
computer as possible), but provide IBM-compatible expansion slots. I'm
not kidding. Of course the '020 will have to slow down for these accesses, but
you gain a wealth of add-on opportunities. The ones I would consider most
useful are modems and data-aquisition cards, but I wouldn't rule out memory
boards, either. It might make sense to provide a custom slot for fast memory
expansion to ungodly size. A SCSI port also makes sense.
Consider this a proposal for a grass-roots machine. What do you think, net-
landers? Is there a market out there? Have I overlooked features you consider
essential? Included features you consider superfluous? Perhaps I'm only
restating the obvious, but let's generate some discussion before we wake
up to find OS-9 only in industrial controllers (where it does very well BTW).
I may prepare a survey for the net that would allow everyone to respond in
a statistically significant way. [ I'd be glad to support it. - JDD]
Kurt Liebezeit ...!ihnp4!uiucdcs!uicsl!klieb
Date: 8 Apr 87 14:56:49 GMT
------------------------------
From: mimsy!aplcen!osiris!phil (Philip Kos)
Subject: Re: OS-9 Discussions, V2 #16 - chd
Summary: chd writes date?
References: <2000@cbdkc1.UUCP>
Organization: Johns Hopkins Hospital
I don't know about OS9, but UNIX keeps *three* dates for every link; the
creation date, the "last access" date, and the "last modify" date. When
reading a file/directory, the last access date is always updated. The
last modify date is only updated when the file/directory is written to.
If this doesn't help to arrive at a reasonable answer to this oddness,
don't bother including it in the next digest - like I said, I don't know
about OS9.
--
...!decvax!decuac -
Phil Kos \
The Johns Hopkins Hospital ...!seismo!mimsy - -> !aplcen!osiris!phil
Baltimore, MD /
...!allegra!mimsy -
Date: 8 Apr 1987 1652-EST (Wednesday)
------------------------------
From: sun!mcrware!jejones (James Jones)
Subject: My Face Is Red Dept.
Mike (mi reloj tiene ventanas) Meyer writes:
>I don't deal OS/9 (at least until there's an Amiga port!), but it
>looks like you answered the wrong question, James.
>Firstly, "export" pushes shell variables into the environment of the
>current shell. What ???? is looking for is a way to push shell
>variables into the environment of the running shell from a procedure
>file. Not quite the same thing.
I see what you mean. In tabular format, then, to try to keep things
clear:
Does the OS-9/68000 2.0 shell have
environment variables? YES
setenv/unsetenv YES
eval NO
backquote NO
(It perhaps merits note that Brian Lantz has written a shell, ksh
(no relation to any product of AT&T :-), for OS-9/6809 that *does*
have backquote. Frank Hogg Labs, with which I'm not associated in
any way, sells it, I've heard.)
So, I'm afraid that it doesn't look like the asker of the original
question can do what he wants to do done.
To avoid ending on a depressing note, a cute trick that you can do
with any Microware shell--if you feel the need for pushd/popd, try
(chd wherever) in place of pushd wherever
and
<eof character> in place of popd
You can't see the stack, alas, but it does do the job.
James Jones
Date: 9 Apr 87 22:41:03 GMT
------------------------------
From: "David Herron"@ukma.uucp, Resident E-mail Hack <david@ukma.UUCP>
Subject: Re: os9 netnews software
References: <2000@cbdkc1.UUCP>
Reply-To: david@ms.uky.csnet (David Herron, Resident E-mail Hack)
Organization: U of Kentucky, Mathematical Sciences
Well, I'm planning on porting uuslave over to my CoCo III along
with smail and a mail reader and netnews. All that should run
nicely on a hard disk. I suppose I'll have to also port over
a make and a few other niceties.
What sort of niceties have already been ported? I basically don't
have anything for my system 'cause I kinda got disinterested
under Level I on a CoCO I. I'm interested in getting my hands
on any sorts of niceties around, and am badly in need of a
kermit right away.
--
----- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet
----- (also "postmaster", "news", and the Usenet map maintainer for Kentucky.)
-----
Date: Fri, 10 Apr 87 23:10:19 ast
------------------------------
From: ihnp4!ihwpt!knudsen
Subject: 2 Megabit CoCo 3
[Following is a collection of notes by Mike. - JDD]
Summary: easy for Tandy, possible for us
It should be possible to extend the Coco 3 to 2 Meg of RAM.
It's easy for Tandy to extend the architecture itself in
a redesign.
It may even be possible to do it yourself with a plug-in
daughter board.
Reason: The GIME's DAT registers, which hold the upper addressing
bits for the memory map, are defined as only 6 bits each.
But they're on an 8-bit bus -- each memory addres is one byte
or 8 bits. So conceivably the upper 2 bits, currently unused,
could also be appended to final physical addresses to get
a total of 8+13 = 21 bits = 2 Meg.
Not that the current hardware would do it alone.
The upper two bits may not be physically implemented inside
the GIME chip. Or there may be no way for them to get out
as additional address bits. But of course Tandy could redesign
the GIME to do this. Only one extra output pin would be needed--
it would supply a 9th address bit to the DRAMs during both
RAS and CAS, which is how some 1M x 1-bit DRAMs work.
(Remember the Coco3 uses two interleaved banks of 256x1 DRAMs
for 512K, so 1-Meg chips would give 2 Meg).
Instead of waiting for Tandy (and Social Security),
someone could make a daughter board that plugs into the
existing GIME socket (some plug, that) and mounts the GIME
plus a few extra chips to capture the two high-order DAT
bits and put them out to the other daughter board with
the 16 1-Meg DRAMs. (The latter may be just the 512K
board we're using today).
I'm sure OS9/2 could handle the fourfold increase in
RAM blocks. Right now I'm a long way from using up
512K, but hey, let's look ahead!
PS: Alternately, you could use the extra two bits by
right-shifting the present addresses and still have just
512K, but in smaller blocks of 2K instead of 8K.
Or, 1 Meg of 4K blocks. Or 4 Meg of 16K blocks.
Several tradeoffs possible....
"Don't tell me -- OS9/2 is from outer space!"
"No, it's from Iowa. It just works like outer space!"
Date: Fri, 10 Apr 87 23:10:33 ast
------------------------------
From: ihnp4!ihexp!knudsen
Subject: Level 2 OS9 Comments, HInts
Keywords: Coco3 OS9 boot terrific TSEDIT
Level 2 for the Coco3 finally arrived near Chicago on
April 2, and I think I got the 1st or 2nd one sold.
In summary, it is GREAT!
1. Windows are very useful and easy to customize.
Windowing modules are included in the $80 price.
2. So is BASIC09, which has all the old stuff plus
a new interface for the HiRes "H" graphics.
3. 100% graphics compatibility with Level 1.
TSEdit works perfectly (try TSEDIT file #32K).
You must run TSEDIT from the bootup 32-char "VDG" screen.
Likewise my music score notation editor.
4. Double sided 40 and 80-track disks are finally
supported! And OS9GEN and COBBLER know how to
make boots onto them. Bye bye BOOTFIX.
5. The 2+" thick manual is much improved. You get
a mini 3-ring binder like with IBM PCs. Typesetting
and printing is much more readable, the writing is much
clearer with more examples and hints, and there are several
indices and tables of contents. The first day I was using
info that is probably in the old 3-manual Level 1 set
but I never found it there.
6. MONTYPE command to set all screens for Mono,
Comp, or RGB.
7. Tremendous support for the new graphics hardware.
Includes the ability to PUT and GET parts of the graphics
screen as in RS-BASIC, plus you can XOR, AND, or OR the PUT.
Can draw Arcs and Ellipses. Can load software-defined fonts--
manual tells how to make your own.
8. Multitasking really works now. I started a disk backup
in one window, went to another and did a DIR with only slightly
slower typing response. Fun to hear the disks break the
backup rhythm and do the DIR, then go back to backup!
Just think what you can do during formats and DSAVEs too.
Strangely there is no TSMON or LOGIN supplied, now that it
would be useful.
9. Boot disks must have CMDS containing SHELL and GRFDRV,
since Shell isn't in the bootfile any more for good reasons.
Summary: Level2 commands missing, BUT...
> I have a question. We don't have Level II around here yet, and I keep hearing
> this rumor that Tandy left a bunch of the commands out of L II and is selling
> them in a second package with a bonus (for THEM!) price. True or False?
> thanks,
> Jon
Yes, it's true to some extent. Level II is missing stuff for
developing new programs (ASM) and even patching the existing
modules (SAVE, VERIFY, DUMP, and DEBUG).
However, all of these can be borrowed from a Level 1 disk
and they work. DEBUG needs a couple zaps to work on non-system
modules, but it does disk descriptors just fine as-is.
(You get descriptors under CONFIG for double-sided
and/or 40 and 80 tracks, And they work!)
These I can verify from experience in the past week (got
L2 a week ago TODAY). I expect ASM and C compiler to
work just fine too.
L2 does include that weird EDIT with some new features added
(or maybe just the manual is so much better written that you
can see them. The docs are MUCH nicer in every way, tho
not typo-free). TSEDIT works just fine. So does every
Level 1 program I've written myself, including some hairy
graphics-screen stuff. Haven't tried my old DynaStar yet
on the 80-column window, but the word is it doesn't
work yet.
So, you're not restricted to program development.
The "developer's pack", whose projected price I forgot
(well under $100 I think),
will have ASM, C (!) and yet another screen editor
called SCRED which I hear has been around the OS/68K world
a while. Most important, this will include expanded DEFS
files with data structures to support the terrific
windowing, menu, and mouse system calls described in the
main manuals.
Tandy is indeed "unbundling" Level II, but not entirely out
of greed. After all they throw in BASIC09, a $100 value
under Level 1. And with 40K of workspace in Level II,
BASIC09 is really worth something now.
Also separate, some day, is "MultiView" (sp?), a Mac/ST-like
environment, which should help folks overcome OS9-phobia.
The support for all such goodies is already there in the $79
Level II system.
Sorry you Oregonians are still waiting, but some places in US
and Canada had it 2 weeks before Chicago. It's worth the wait.
You might never boot Level 1 again. mike k
Subject: Koronis Rift shows off Level 2
Keywords: OS9, Level II, Coco3, graphics, SPEED
Last nite at our local Coco club meeting I saw a demo
of Koronis Rift, a graphic realtime adventure game
that runs under OS9 Level II on the Coco 3.
I won't talk about the game itself except to say that
its premise and implementation are very good.
What blew me away was the speed of animated color graphics,
showing the perspective view out the windshield of your craft
as it zoomed low over the planet's surface.
Very much like Microsoft Flight Simulator, only much better--
irregularly shaped mountains and hills painted in with
shaded colors. Refresh rate at least 3 frames/sec.
This was generated in real time to match your flight
path as controlled from the joystick.
When I saw it I thought "Impossible! You can't run this
fast under OS9, even with the Level II speed poke."
This morning, I reconsidered: "You can't even run this
fast on an 8-bit micro (like a 1.8 MHz 6809!)"
But of course seeing is believing. This game really
shows what the Coco3 can do, and that OS9 needn't hold
it back. (I bet the code is all assembler and not using
the extensive graphics support built into Level II, which
is more oriented to mouse-icon work than full-page painting.)
And this is a Radio Shack game. Wait till the heavy game
writers get hold of this (plus EA and those other Apple/Atari
houses. EA has already ported One on One.)
Since this is Level II OS9, you could supposedly hit CLEAR
to go to another window and format a disk or something while
the game was running.....
The Coco 3 is no Amiga, but at its price it doesn't have to be.
mike k
"Don't tell me -- OS9 Level II is from outer space."
"No, it's from Iowa. It just works well in outer space."
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
Delphi: RAGTIMER CIS: <memory digits overflow>
" ~E(x):[is_lunch(x) && cost(x)==0] "
Date: 12 Apr 1987 2325-EST (Sunday)
------------------------------
From: sun!mcrware!kim (Kim Kempf)
Subject: OS-9 chd command
[From the horse's mouth department: (oops, I don't mean to call you a
horse, Kim...:-) - JDD]
>Given that I dont get a writeprotect error on 2.00.00 when CHDing to a
>protected disk I assume that if CHD cannot write it traps that error
>and does not complain.
>
>The question becomes two fold. First is this description really accurate?
>How about it Microware? Does CHD really update the Date on the disk?
>I know it has to read to get the pointer to the directory. ( ie the shell
>does not just remember the pathname). And second, is this a desirable behaviour?
The I$ChDir system call accepts a mode value just like I$Open and I$Create.
If the mode happens to indicate "write permission", the date of the opened
directory will be touched. In the case of a write-protected disk, RBF simply
ignores this failure. The shell's chd command sets write permission on the
chdir function in an attempt to verify that write permission is granted to
all directories in the chdir pathlist. This prevents a user from subsequently
modifying the target directory. This action is a holdover from the days when
RBF, the shell and all of OS-9 (and the user programs) had to run out of 16K
bytes of memory. Future improvements of RBF are likely to address this problem.
----------------
Kim Kempf, Microware Systems Corporation
...!sun!mcrware!kim
Date: 20 Apr 1987 0909-EST (Monday)
------------------------------
From: sun!mcrware!jejones (James Jones)
Subject: uucpish software posted
Concerning the inquiry about UUCP or something like it: someone has posted
a more extensive package than uuslave to the net (I presume either mod.sources
or net.sources (or whatever net.sources got renamed to :-)). It might be
worth examination if you're after something UUCP-like; from the looks of the
pieces, it seems to have been done at least in part for VMS systems, but it
would certainly be far superior to starting from scratch.
James Jones
Date: Tue, 21 Apr 87 20:42:52 ast
------------------------------
From: ihnp4!ihwpt!knudsen
Subject: Coco Level 2 Windows BUGS
Has anyone else had the Disappearing Windows Problem?
Coco3 OS9 L2 has at least two related problems here.
The first is that if a process (like a BASIC09 program)
creates a temporary window, selects it, writes/draws some stuff in
it, but then closes the path to it and tries to re-select
its original (stdout) window, the process hangs up and
the temporary window stays on the screen. The original
(device) window is lost forever, tho it still "exists"
in OS9's mind (it won't let you modify its parameters,
for example).
The other bug is that the above device window is
"forgotten" by whatever handles the CLEAR key. As you
cycle thru your current windows by punching CLEAR, that
window is omitted. (The temporary window may remain
on the CLEAR cycle, if it was INIZed and your lost
process has not CLOSED its path to it.)
By "select" I mean using the BASIC09 RUN GFX2(path,"select")
call, which I presume just sends the 1B SELECT pair of bytes.
Supposedly you can switch the screen to any window just
by sending that byte pair to it. Unfortunately, you can't
send anything to a window that has a shell running in it,
so there is NO way to recover the lost window above.
PROCS shows BASIC09 and its Shell still alive & well,
but with the window removed from the CLEAR-key list
there's no way to talk to them, or even kill them
(damned immortal Shells must be EX'ed to death from inside).
I found these bugs when trying the BASIC09 example code
on page 5-90 of the manual, if memory serves.
I suspect they left something out of the program which
is causing the trouble. Any theories? Patches?
PS: Experimenting on this is expensive in re-boot time.
Helps to create lots of windows before starting tests.
This shakes my faith in wonderful Level 2! Next I'll
find that Tammy Bakker was playing around too... mike k
Date: Thu, 30 Apr 87 12:26:02 +0200 (Central European Summertime)
------------------------------
From: XGRUMAHR@DDATHD21.BITNET (Christian Mahr)
Subject: OS9 disk repair
Has anyone seen (or written) an utility to repair (not just diagnose
like DCHECK) a corrupted OS9 file system? Or recover deleted files?
Christian Mahr
XGRUMAHR @ DDATHD21 (Bitnet)
or
Christian Mahr
TH Darmstadt
Merckstr. 25
D-6100 Darmstadt
W-Germany
Date: Thu, 30 Apr 87 12:55:17 cdt
------------------------------
From: ihnp4!uiucuxc!uicsl.csl.uiuc.edu!klieb (Kurt T. Liebezeit)
Subject: Regarding "A Reasonable Editor For OS-9":
For those who might be interested, I have just completed a port of the
public domain editor YASE described in Donald Krantz's book "68000 Assembly
Language." YASE is a Wordstar clone, and has virtually all the features of
Wordstar's non-document mode. In addition, YASE has a really nifty window-
ing interface: you can have any number of files open in arbitrarily-sized
windows, and you can dynamically pop, rotate, and resize windows at will!
All this is squeezed into 6000 bytes of code, and will run on any 24x80
terminal using standard clear-screen ($1A) and cursor-addressing (ESC=)
codes.
YASE does have a few limitations, though. You must set the buffer
size when you assemble the program, and because the code uses dbra
extensively you cannot have buffers larger than 64k (I did use OS-9's
F$SRqMem call, so you can have as many 64k buffers [files] as your memory
permits!). The only other limitation is that YASE can't scroll within a
window; to keep the cursor in view it has to rewrite the window.
By the way, I really recommend the book. The first third is all reference
material, and somewhat dry. The latter part of the book describes YASE in
detail, along with some other nifty examples: serial drivers, bit-mapped
graphics, assembly language printf, etc. The only flaw in the book is that
Krantz is writing for a CP/M-68k audience; in addition to the normal I/O
routine work I had to change the code a fair amount to get rid of the
absolute addressing modes for OS-9.
I plan to send YASE to the OS-9 User's Group when I feel more confident
that all the bugs have been wrung out (yes, there are a few even in the
book). Currently, it is a reasonaby faithful reproduction of the code in
the book. I would consider posting it to the net, but I'm unsure of the
mechanics of posting to one of the source newsgroups. Surely only one person
should have to type in 3500 lines of code!
Kurt Liebezeit
...!ihnp4!uiucuxc!uicsl!klieb
or klieb%uicsl@uxc.cso.uiuc.edu
P.S. If the name Donald Krantz sounds familiar to some readers of Dr. Dobb's
Journal, it should; he wrote the article "Christensen Protocols In C" that
appeared in the June 1985 issue.
P.P.S. One of the features I'd like to add to YASE is automatic creation
of a backup file. That is, I'd like it to rename the old file <file_BAK>,
and then have the edited version take on the name <file>. There is no
operating system call to rename a file; must I read the directory, find
the name, then rewrite the directory? Suggestions? Code?
[ I (for one) would LOVE this one! I'd be glad to submit it for distribution
and to keep it in my OS9 sources. - JDD ]
Date: 1 May 87 20:29:22 GMT
------------------------------
From: dave@rosevax.Rosemount.COM (Dave Marquardt)
Subject: Cheap OS-9?
Organization: Rosemount Inc., Eden Prairie, MN
I just read the article in the January issue of Dr. Dobb's, and now I'm
interested in setting up a system to run OS-9. What's a cheap way to
do that. I do own a Heath H-29 terminal, if that helps cut the cost any.
Would the Tandy Color Computer be a good way to start?
Dave
--
Dave Marquardt
dave@rosevax.Rosemount.COM
{cbosgd,ihnp4,uiucdcs}!rosevax!dave
[ My personal answer to this may be different than other folks. It, first,
depends upon your definition of "cheap". I prefer the 680xx and would
thus, be inclined to go with an Atari ST running OS9 68K. That would be
"do-able" for around $1000 (American). To get any cheaper, then definitely
the CoCo is your best bet. - JDD]
-------------------------------------
The views expressed in OS-9 Discussions are those of the individual authors
only. Copies of digests are available by mail request.
------
Moderator: John Daleske cbosgd!cbdkc1!daleske daleske@cbdkc1.ATT.COM
Submissions should go to: cbosgd!os9 os9@cbosgd.ATT.COM
Comments to the moderator cbosgd!os9-request os9-request@cbosgd.ATT.COM
*********************
End of OS-9 Discussions
*********************