ftp.barnyard.co.uk/2015.02.ftp.barnyard.co.uk.tar/ftp.barnyard.co.uk/cpm/walnut-creek-CDROM/CPM/ZCPR33/Z3-33/Z33GCONF.TXT

Text File | 2000-06-30 | 53KB | 1,502 lines

Z33GCONF.TXT - Edited by Keith Petersen, W8SDZ - 26-Jun-87

This is an edited copy of GEnie's CP/M RoundTable Conference on
ZCPR 3.3 which was held on June 10, 1987 at 9:30 pm edt.  Our
guests were Jay Sage, David McCord and Bridger Mitchell.

GEnie                       Page 685;2
      CP/M Real-Time Conference
            Version 1.80

Room 3,the Guest Speaker room.

Notice on door: -=:[ GREETINGS! ]:=- Tonite, the CP/M RT welcomes special
guests Jay Sage (programmer), Bridger Mitchell (Echelon), and David McCord
(Echelon) for an informal conference concerning the new release of their
CP/M command processor: ZCPR3.3!  Please use common courtesy, and keep
the discussion limited to the topics at hand.  If you need a listing of RTC
area commands, type '?' or 'HELP'. Thank you all for attending!

-=:[MICHAEL]:=-

<[- Host -] MICHAEL.M> For general info:  I'm on a C-128 and know diddly
about ZCPR.  Jest hosting.

<[- Host -] MICHAEL.M> It's 9:30.  If I can get Jay, Bridger, and David (in
that order) to introduce themselves, y'all can start your conference.

<[Jay.Sage]> What do you want us to say about ourselves?

<[- Host -] MICHAEL.M> Who you are, what your claim to fame is...general info
for the /steno.

<[Jay.Sage]> OK, I'm here as author of latest version (3.3) of ZCPR.
THat should be enough for this conference.

<B.MORGEN> I'm Bruce Morgen, I run NAOG/ZSIG...

<[bridger]> I'm author of BackGrounder ii (aka BGii), active at
Plu*Perfect Systems, and attempting to coordinate new operating system ideas
at/thru Echelon.

<[daveMc]> I'm vice president of Echelon, the actual owners of the
copyright on zcpr 3.0 and 3.3.  Echelon is exclusively cp/m-compatible
oriented, one of the last...

<STEVE.HIRSCH> And thank you for everything!!

<B.MORGEN> Here here!!

<[Keith] W8SDZ> Amen!

<[bridger]> jay -- anything more to say on appl. notes?

<[Jay.Sage]> Perhaps we should try to get this thing focussed a bit at
this point.  Bruces question is on the floor, and perhaps there are others.
On app notes... First, the programmers guide will be released in pieces so
people can have something soon to start working with.  Also, I am too
tired to write another whole book in one sitting.  This way I can take
things up one topic at a time, and programmers can start to turn out
Z33 applications.

<B.MORGEN> I can understand that fatigue factor, Jay, and I think the app.
notes are very much to the point - good info...

<[bridger]> keith and bruce posted several files in last day or so; are
these the first?

<[Jay.Sage]> Yes.  There are 3 programming notes, 2 application notes,
and 1 bug fix (very minor, I am happy to say)

<[Jay.Sage]> I think the most important of the application notes is the
one about how to use ARUNZ to make a system incredibly fault-tolerant.

<B.MORGEN> I agree - ARUNZ is like MEX, it kind of grows beyond even the
author's vision

<[bridger]> you're referring to program-flow logic, not errant programs
that crash the system

<[Jay.Sage]> Ways to make the system tolerant of alternate command names
and attempts to change directories with wrong directory names.

<[Jay.Sage]> If anyone is interested, I have in a sense started on
ZCPR34 already.  There are two changes in the version I am now using.

<STEVE.HIRSCH> SomMy gosh! How does one keep the kind of pace that
you've been Jay?

<[Jay.Sage]> I was able to do it on adrenalin and excitement, but now
that Z33 is out, I am crashing.  Fortunately I leave on vacation next week.

<STEVE.HIRSCH> Noone will begrudge you that.. In fact, I'm envious!

<B.MORGEN> Me too...

<[bridger]> suggested topic: encouraging good application-programming
practices with new z33 tools & interface.  2nd topic: z33 - BGii
connection.  3rd: needs for new OS.

<[Jay.Sage]> I thought I could stay up until 2 and get up at 6 a few
times, but I was surprised that I could do it every day.

<[Jay.Sage]> OK.  You probably have good advice on first topic.

<[daveMc]> anyone familiar with the zcpr 3.3 code and docs will
certainly agree jay has done a super job.

<B.MORGEN> Good topic

<[Jay.Sage]> To make things easier, we are preparing some more libraries.
Howard Goldstein has been hard at work.  My initial releases has a few
problems, as Bruce can attest to!

<STEVE.HIRSCH> Do you want to address those in that order Bridger?

<[bridger]> Why not.  Flame on!! We have a superb z33 interface and
well-written appl notes; there should be lots of interest in upgrading
existing tools.  Then we have cases like XSUBZ12 and Bruce's crash that
show that it's easy to bomb.

<B.MORGEN> I didn't mean to sound like a kvetch, but I think you were really
tired..

<[bridger]> I think special attention should be called to having the
program/tool check its actual environment before proceeding to "do harm"
-- eg call the command processor parser, overlay code, load a high segm
ent.  We have some guidelines (e.g. my RSX doc), but more may be needed.

<STEVE.HIRSCH> Ok, well I have had some thoughts on the new o/s. Has anyone
thought of eliminating executable fies, and having the system loader deal
with .REL files (load-time linking?

<B.MORGEN> I think that relocatable tasks will have to coexist with COMfiles
for quite a while, don't you think?

<STEVE.HIRSCH> Sure, but let's support them anyway!

<[bridger]> Steve, others: just when do you NEED rel. files at load time?

<[Jay.Sage]> Loading REL files (or PRL/SPR files) is definitely in the
works.  I did not want to attempt anything that radical with Z33.

<B.MORGEN> Agreed, PRL or REL format?

<[Jay.Sage]> Bridger?

<STEVE.HIRSCH> .REL gets my vote (SLR format of course)

<[Jay.Sage]> How about all of the above -- I wasn't suggesting a choice.

<[bridger]> No the first question should be:  When is there a true
advantage of deferring determination of execution address until LOAD time?
Steve, you're thinking of something?

<[daveMc]> one of the ideas for the new opsys is including z3lib/vlib
functions in the os.  REL makes sense in that context.

<STEVE.HIRSCH> Fine! The Apple IIgs has a very nice system loader/memory
manager which enables one to have many system resources in-residence, which a
pplications could be linked to at run time..

<[bridger]> I first liked the idea, but now I"m not sure it buys us much
in a z environment.

<[Jay.Sage]> With the ability to dynamically assign FCP and RCP
addresses, it will be nice to load them dynamically.

<STEVE.HIRSCH> The advantage is that onecan load o/s extensions which do not
have to reside at any paricular address (Z2080..), and sorry if I'm branc
hing off the subject, I''ll be good!!

<[bridger]> ok -- system segments can be relocated by LDR - suitably
enhanced.

<B.MORGEN> Bridger has a point - I like a bunch of big TPA's that can run
concurrently..

<[Keith] W8SDZ> Perhaps we should concentrate on the new ZCPR 3.3 and what
makes it better than the older one.

<[Jay.Sage]> Dave, would you like to summarize?  You're good at that.
Re Keith's question.

<[STEVE.COHEN] SMCUWAUE1154> one small advantage of Z33, the ENV address in
HL at program start makes a few things possible that weren't before such
as TM2 programs that make use of Z

<[daveMc]> zcpr 3.3 has a list of improvements as long as my arm.
It is overall a quantuum jump, but each improvement individually is
not that big a deal.

<STEVE.HIRSCH> It sure does run faster though

<B.MORGEN> I love the improvement in command search speed, very much faster
than 3.0.

<[daveMc]> of course the rewritten source w/comments and debugging is
probably the most significant in the long term.

<[daveMc]> The ZCPR 3.0 manual still largely applies

<B.MORGEN> Yes, one can almost learn to build CCPs from the source...

<STEVE.HIRSCH> Besides, by the time you get your Z33 manual  Jay will have
re-written a new Z version!

<B.MORGEN> As a matter of fact, 3.3 makes the Manual more accurate!!

<[Keith] W8SDZ> I've received a number of questions from CP/M-Plus users
about ZCPR 3.3.  Is there any way or will there be any way to use it
with 3?

<[daveMc]> there are no intrinsic barriers to getting zcpr installed on
a cp/m plus machine, however, there are no docs.

<[Jay.Sage]> With ZCPR33 you can have many commands on a line, and
commands can be generated automatically by other programs.

<STEVE.HIRSCH> Now thats (CP/M 3.0 ) an interesting subject. I always
thought that CP/M + was an unjustly maligned o/s.

<B.MORGEN> What we need is a CP/M+ guru with a yen for Z...

<[daveMc]> we need a knowledgeable fellow in cp/m+ to do it the first
time and pass on the benefit of his experience.

<[Jay.Sage]> It is certainly FAR from straightforward, since the
principles of CP/M3 are very different.  The command processor runs
as a transient program, for example.

<[Keith] W8SDZ> Sounds like MSDOS.

<STEVE.HIRSCH> Wasn't there a fellow in New Jerey (whomever wrote the
LDISK program) that dabbled with Cpm 3 Wilson Bent maybe?

<[daveMc]> to run zcpr 3.3, as it cannot be configured with less than 1k
memory overhead model, an rsx will have to created to hold the ENV, etc.

<B.MORGEN> Right, but it's not undoable, there're lots of hooks there.
I think the Z-style CCP would be no big deal, and the buffers could be
RSXs, no?

<[daveMc]> are you reading my mind, bruce?

<STEVE.HIRSCH> Yes, but who says we have to use their CCP. Just have your own
CCP relocate itself, and fool the Bios into grabbing it!

<[STEVE.COHEN] SMCUWAUE1154> What loads the command processor transient?

<STEVE.HIRSCH> The bios, I believe.

<[Jay.Sage]> Warm boot, no?

<STEVE.HIRSCH> Si!

<B.MORGEN> CP/M + has its own system loader program...

<[Jay.Sage]> Here are some examples of what Z can do.  Suppose you make
an error on a command (mistype a file name).  WIth Z, an error handler
program takes over and lets you correct the command and rerun it.  With
the history shell, you can recall and edit and rerun past commands.

<[daveMc]> Echelon's tel# is 415/948-3820...call and ask for a catalog.
It has about five pages of ways anyone can benefit from using zcpr3/z-
system.  I'm vice president of Echelon, the actual owners of the
copyright on zcpr 3.0 and 3.3.  Echelon is exclusively
cp/m-compatible oriented, one of the last...

<STEVE.HIRSCH> The Z-system is such an essential part of my programming
environment, I'd be lost without it. using the TurbDos system at my
store is like a trip back to the stone-age. When do we get turboZ?

<[daveMc]> zos is presently scheduled for 1st qtr 1988.

<[Jay.Sage]> If no one has a question for me, I have a question for
you. How many of you have TPA size problems with programs you run.

<STEVE.HIRSCH> Mee!! Me

<[Keith] W8SDZ> I do.

<L.GELLER> I have almost no TPA left on my PC8800 (45K!)

<[Jay.Sage]> Are you running ZCPR3, L.Geller

<L.GELLER> yes, via Z.com

<STEVE.HIRSCH> Many of the Applicard system utilities will not run with
Z33 and BGii loaded.

<[STEVE.COHEN] SMCUWAUE1154> Lately I've been seeing references to
ZDOS.  Are these misprints or is there something called ZDOS?

<[daveMc]> There have been several people who have gotten letters and
such into print misnaming ZRDOS as ZDOS.  Drives me crazy.

<[Bill] B.DUERR> Are there any plans of running ZCPR on a C128?  I
quess to do that you would have the bring the C128 to CP/M 2.2 or
ZRDOS?

<[Jay.Sage]> The C-128 has the same CP/M3 problem.  I am thinking about
writing a version of ZCPR that will dynamically change its size so that
big programs will have enough TPA.

<[bridger]> how?

<[STEVE.COHEN] SMCUWAUE1154> Now that is one helluvan idea, Jay.

<L.GELLER> How about a bank-switching version?  It should solve the TPA
problem.

<B.MORGEN> That's in the works...

<[Jay.Sage]> That will be coming, but I am thinking about something that
will run on a standard Z80 machine -- just like Z-COM.

<L.GELLER> I have heard .. .  but any estimate?

<STEVE.HIRSCH> What I was getting to before was an o/s that would deal
with large amounts of contiguous memory. Maybe I am overly optimistic.

<B.MORGEN> Jay, I think the key to that is to have the Z3 segments in
protected memory UNDER the CPR...

<[bridger]> There's active work now on a new OS to run on '180 machines,
with memory management and extended features.

<STEVE.HIRSCH> I'm excited, Bridger. When?

<[bridger]> The big question.  A first version MIGHT be possible by
sometime 3rd Q.

<B.MORGEN> For 64180 first?

<[bridger]> Actually, first for the sb180,180fx machines.  Then more
generic '180s

<STEVE.HIRSCH> My longtime campaign to have Applied Engineering do a
64180 card for Apple computers may get a boost after all..

<B.MORGEN> We have to talk about that Steve - Ken got some 280s this
week...

<[Keith] W8SDZ> Would it be possible to consider a plug-in card that
would go into the Z80 socket that would have ZCPR 3.3 in ROM and do the
bank switching?

<[Jay.Sage]> I have heard some rumors about boards that will plug in,
for example, to Ampros.

<[daveMc]> Bridger and I were kicking around an idea similar to yours,
Keith.  It looks feasible.

<[bridger]> Rom doesn't buy you so much on high-speed machines; the
memory is too slow unless you pay $$$.  It can be copied to RAM, but it
can also be booted from disk.

<[Jay.Sage]> Also, ZCPR33 is a personal thing,  Different poeple want
different options enabled.

<B.MORGEN> And you think micros have memory to manage???

<[Jay.Sage]> It is best kept in RAM.

<[Keith] W8SDZ> How about EEROM?

<[bridger]> Depends on the memory-access speed.  Wait states ...

<[Jay.Sage]> Could be done, but I am not sure what the advantage is when
one have 1MB or 16Mb of RAM.

<B.MORGEN> Z33, as it stands, has lots of self-modifiying code...

<[Jay.Sage]> That is true, too, but that will have to go with the Z280
implimentation.

<[Keith] W8SDZ> I was suggesting the ROM because most people would have to
replace their main system memory to do bank switching.

<[daveMc]> It might be possible to have a z280 plug-in replacement for a
z80 that came with the new OS and required no installation.

<[bridger]> When we go to 280 machines, the data segments will have to
be enforced, because of the cache memory fetches.

<B.MORGEN> Steve told me the chip might have safeguards...

<STEVE.HIRSCH> What about the Zedux card. The designer claims that it will
retro-fit into a Z80 socket!!

<[Jay.Sage]> Yes, what about this Zedux card?

<[daveMc]> zedux hasn't left me with any warm feelings.  the last time
we tried to contact them, their phone had been disconnected.

<B.MORGEN> I called and got an illiterate answering service...

<[Keith] W8SDZ> Bill Duerr called and talked to a real person - the guy
at ZDUX said he would send more info to Bill.

<[bridger]> The whole 280 area is REALLY grey now.  Zedux hasn't showed
up with its demo board, 2 months later.

<STEVE.HIRSCH> Bridger, maybe you can settle a point for me. Doesn't the
Z280 have the ability to trap an attempt to write real RAM when it's in
the cache?

<[bridger]> The 280 cache can be associative; I can't give a complete
answer w/o manuals.

<[bridger]> I have a big topic, maybe for later: what do y'all REALLY
want in a new OS, for a 180 or 280, or banked z80?

<L.GELLER> Sounds very interesting!

<[daveMc]> The add-on I feel warm about is the High Tech Research
ULTRABOARD.

<B.MORGEN> I liked the ultraboard idea, but High-Tech are not Z enthusiasts.

<L.GELLER> Dave, please describe Ultraboard.

<[daveMc]> ultraboard is a z280 plug-in card for the z80 socket.  It
also contains 1Mb RAM and a high performance graphics subsystem.
The ultraboard will be first implemented as a drop-in for kaypros,
and variations are being considered for S100 and single board cpu.

<[STEVE.COHEN] SMCUWAUE1154> Dave, have you seen one of these things?

<[daveMc]> I have spent hours on the phone with the designer.  It looks
good, they have almost 200 orders already and they are still in
prototype stage.

<[Jay.Sage]> I would like to see a DOS with many more services to make
programs easier to write.

<[bridger]> which services would do it?

<[Jay.Sage]> Integral date stamping and access to date information, for
example.

<[STEVE.COHEN] SMCUWAUE1154> I think, Jay, that when you talk like that,
we have to face the reality that we are approaching the point where we
say cut the umbilical cord to CP/M and stop worrying about compatibility.

<[bridger]> Do you all want to give up the cp/m file structure as well?

<B.MORGEN> Can't do that until or unless we have things like dBase and
NewWord for our new environment...

<[Jay.Sage]> We should try to stay upward compatible.  THe old programs
better run unless we are ready to write new dBases and SuperCalcs and
WordStars.  I would be inclined to keep the file structure,  Is there
any reason to be eager to give it up?

<L.GELLER> File structure may be ok   but need better access methods
(full-track reads, etc.)

<[Keith] W8SDZ> Just add some enhanced system calls.

<[bridger]> which ones, keith?

<[Keith] W8SDZ> numbers higher than those used by CP/M 2.2.  Then old
programs will continue to work.

<[bridger]> keith- I mean functionlly, what do you want added?

<[Keith] W8SDZ> Make FCB for starts.

<B.MORGEN> We almost have that with the Z33 parser...

<[Jay.Sage]> Are you aware of that feature of Z33, Keith?

<[Keith] W8SDZ> No.

<[bridger]> l geller:  I'd guess you want higher disk performance,
however attained; full track reads probably are less effective than
good caching systems.

<B.MORGEN> I'd like to be able to delineate a chunk of buffer and write
it with a system call - no more buffering in TPA...

<STEVE.HIRSCH> Absolutely. Anyone remember CAche Q?

<L.GELLER> I bought cache Q.  Unfortunately, my cpu is too slow . . .

<L.GELLER> On disks, a MS-DOS machine can be 10 times faster on reads I
think.  Question is how to bring that performance to Z or CP/M

<[bridger]> In the development os, we're seeing good floppy/hard disk
performance improvements with 1) caching, 2) directory hashing, 3)
improved multi-extent handling, 4) multi-sector read/write.

<[daveMc]> if z3lib functions are added to the dos, their will be the
equivalent of make fcb calls, such as ZPRSFN

<[bridger]> it's also the hardware on "msdos" the dma channel.

<[Jay.Sage]> There is an entry point to the parser routine that programs
can call to do full Z33-style command line (file spec) parsing.

<B.MORGEN> That parser is in Z33 already, Dave...

<[Keith] W8SDZ> Seems to me that the things that should be added to any
upward-compatible OS would be those things that we have to repeatedly
write into every program.

<STEVE.HIRSCH> Bridger, will the hashed directory disks be compatible with
CP/M systems, or specific to the new o/s

<[Jay.Sage]> But the parser should be in the DOS eventually.

<[daveMc]> I was just pointing out it would then be a dos call and not
a ccp-resident...

<[bridger]> we have a key design issue here:  do we build these routines
into the OS as callable functions, or into a system-library that is we
ll standardized?

<L.GELLER> Aside from hardware, what can be done in software (OS?) to
speed up CP/M-format disks?

<B.MORGEN> Caching helps a lot...

<[daveMc]> I dunno what caching does, but cacheing is nice...

<STEVE.HIRSCH> My vote is for loadable system resources, which can be
purged when not needed..

<[Keith] W8SDZ> Anything that will keep us from having to put those
often-used routines in EVERY program.

<B.MORGEN> SYSLIB already recieves a lot of that drudgery for me...

<L.GELLER> Cache-Q really is nice when reading from RAM memory.  It helped
considerably.  But when reading from disk to memory to program it was a dog.

<STEVE.HIRSCH> That's not my experience with CacheQ

<[daveMc]> what's cache-q?

<[bridger]> a variant of the idea is run-time linking from the library.
I'm thinking about that for the os.

<[Keith] W8SDZ> Cromemco put make FCB into their spin-off of CP/M 1.3 a
long time back.

<[Jay.Sage]> Steve, that is less of an issue with huge memory spaces --
it's really a problem when they are in TPA.

<L.GELLER> I think it was my particular problem, due to slow CPU.  For
others I would say it is worth looking into.

<STEVE.HIRSCH> Exactly. Bridger that's what I was driving at!

<[Jay.Sage]> Of course, BGii capability with a full TPA would be the
single most valuable thing.

<[Keith] W8SDZ> I understand the value of SYSLIB.  I just feel that system
stuff like make FCB should be in the system.

<B.MORGEN> XBIOS has cache, although the current DateStamper offsets its
advantage a bit on a big disk..

<[bridger]> Bruce, xbios, in its current test version, isn't caching
very smartly.  It will improve a good deal for datestamping.

<B.MORGEN> Great - I've been trying to get Malcom to listen to Hal on
that one...

<[bridger]> regarding software speedups for disk io:  We've found
200-400% improvement possible with, e.g. stock Kaypro roms vs
Turboroms, just tuning the software.

<B.MORGEN> I'll attest to that - Kaypro turn useful with T-ROM and
Z-System...

<[dan] S.PLATYPUS> is this something we can port over to the 128??
especially for us less than expert programmers?

<B.MORGEN> We really need a Z-Com for CP/M+, that is clear!

<[Jay.Sage]> There are a number of problems with that -- CP/M3 and slow
drives.

<[daveMc]> we have someone working on it.  expect something like our
commercial Z-Com for cp/m+ in three or four months...

<[Bill] B.DUERR> Why not just write a CP/M 2.2, wouldn't that be easier?

<STEVE.HIRSCH> The 128 is almost as pervasive as the Apple!

<JIMLILL> I'd like it the other way so you didn't need all the aliases

<B.MORGEN> Once there is a good CP/M 2.2, Z is a snap to put together..

<L.GELLER> May I ask if auto-install versions from Echelon now
"contain" Z3.3?  Any plans?

<[Jay.Sage]> The Z-COM does not have Z33, but the ZCPR33 User Guide
tells precisely how to stick it in.

<[daveMc]> the current z-com will be upgrade to 3.3, but not yet.

<[bridger]> how large is the c-128 communnity with real interest in
buying z33?

<JIMLILL> I've seen 20+ requests for c128 Z3

<[dan] S.PLATYPUS> I'm intersted but I'm not sure what It will do for me?

<[- Host -] MICHAEL.M> Over 1 million 128's worldwide, Bridger.  A new 128-D
soon to be released.

<[Jay.Sage]> I have had quite a few impassioned inquiries.

<[bridger]> do we have/know of a bios expert on the c-128, all versions?

<[- Host -] MICHAEL.M> Bridger - Von Ertwine

<[bridger]> Id like to talk to von ertwine; does he frequent GEnie?

<[- Host -] MICHAEL.M> I will send you contact info via Echelon, Bridger.

<CHUCK.WAGON> what advantages would it over over the present o/s

<[Jay.Sage]> Chuck, that is a question with a long answer -- hard to
know where to start.

<STEVE.HIRSCH> Bridger you can probably find one thru the Computer Shopper.
They have an active column for 128 CP/M..

<B.MORGEN> The 128 BIOS source is available in the PD, I think...

<[- Host -] MICHAEL.M> Bruce - Not PD, but available via DRI for a
nominal fee.

<[daveMc]> I have heard some horror stories about the average experience
level of the 128 user, and thusly we will need reams of docs to keep
the tech support down.

<STEVE.HIRSCH> Now, now.  People have said that about Apple users too.

<CHUCK.WAGON> would the 1750 ram disk help re slowdrive problem?

<[bridger]> RAM? disk

<[daveMc]> how big is the 1750?

<B.MORGEN> Sure, the RAMdisk would be almost essential...

<CHUCK.WAGON> 52k of usable RD

<[Jay.Sage]> It is still slow by usual standards, and Z is somewhat more
disk intensive.  But there are apparently good RAM disks for the C128.

<CHUCK.WAGON> 512k

<[Jay.Sage]> With that ZCPR3 would be great.

<CHUCK.WAGON> makes cp/m bearable on the 128

<[bridger]> and so would BGii

<B.MORGEN> I think a Z or BGii for the 128 would have to be packaged with a
100-200K RAMdisk...

<[daveMc]> it would be practically required, I'd say.  My sources say
that the floppies are terribly slow.

<[Keith] W8SDZ> Stick one of those Z280 boards into a C128 and see things fly!

<CHUCK.WAGON> wld it fit keith???

<[Keith] W8SDZ> It plugs into the Z80 socket.

<[dan] S.PLATYPUS> has anyone seen the add from tenex about the cp/m
infopack??

<STEVE.HIRSCH> Just because we are used to fast machines doesn't
necessarily mean that those with slower ones can't enjoy Z.

<CHUCK.WAGON> will it run with 2mhz clock??

<JIMLILL> Anyone seen a Z280 "generic" board yet??

<[STEVE.COHEN] SMCUWAUE1154> Anyone seen a Z280 card of any kind yet?

<B.MORGEN> That's what the erstwhile "ZEDUX" says they have...

<JIMLILL> Good Point....I've seen a Z280

<L.GELLER> Chuck, you must have a PC8800 also!

<B.MORGEN> The chips are finally real, that is a fact...

<[Jay.Sage]> Do they work?

<STEVE.HIRSCH> The Zedux folks say that they have cards.. but no chips.

<B.MORGEN> 99%

<[Bill] B.DUERR> Zedux says the chips are still had to get!

<[Jay.Sage]> Afraid that does not sound good enough!

<[STEVE.COHEN] SMCUWAUE1154> Terrific.  The card people have no chips
and the chip people have no cards.

<[daveMc]> our sources at zilog say they had some production problems,
so first priority was shipments to japan.

<[daveMc]> japan is a good market for them.

<L.GELLER> Yes, in fact I spoke to their rep in Japan yesterday!

<STEVE.HIRSCH> Hey. Zilog does not seem to know what business they are in.

<B.MORGEN> The features that are still buggy are pretty exotic and can be
worked around in hardware...

<[Jay.Sage]> The Japanese want to copy them?!

<L.GELLER> No, the Japanese have 8/16 bit chips doing both Z80 and 8086
code.  No need to copy because they are ahead, I think, in some ways.

<CHUCK.WAGON> its called v-20

<[Keith] W8SDZ> The V20 doesn't do Z80, only 8080.

<CHUCK.WAGON> no ru z80 code too

<[dan] S.PLATYPUS> I have a question concerning the intro to cp/m kit
marketed by tenex computer express??  I was wondering if anyone had
seen or heard about it?

<[daveMc]> I haven't heard of it.

<JIMLILL> Dan: explain what machine thats for

<[dan] S.PLATYPUS> its $22 or so and is supposed to contain various
cp/m pd progs probably mex and a vde prog + something else as well as a
book on cp/m on the 128!?

<[bridger]> gossip is fun, but can't we better use our time to debate
software features for current and prospective machines?  I, for one,
would like real feedback from ths conference, to set directions for OS
development.  the "reality" of x280's is not something we can decide

<STEVE.HIRSCH> Bridger, I agree.  Let's hear more about the specs for
the new o/s.?

<B.MORGEN> Bridger is right, let's get serious

<[bridger]> specs so far:  cp/m 2.2 file structure, extended to 32M
files; ...

<B.MORGEN> Bridger, why don't you give us rundown on what you have now?

<[bridger]> caching, dir. hashing, general disk performance improvements.
interrupt driven char. io, most cp/m 3 functions... auto time/date
stamping .. public files

<B.MORGEN> How will the memory model look to the program?

<[bridger]> memory management is a key area for discussion.  Also
redirection and multitasking support.  I need input on each.

<[daveMc]> what's the worst thing about cp/m?

<JIMLILL> disk i/o

<STEVE.HIRSCH> Yay for int. char i/o!!@

<[Keith] W8SDZ> No multitasking.

<[Jay.Sage]> IO redirection?

<[STEVE.COHEN] SMCUWAUE1154> Explain DIR hashing a bit, will you please?

<STEVE.HIRSCH> Wouldn't the multi-tasking have to be time-sliced. Maybe
via interrupts?

<[Keith] W8SDZ> I would like to be running a MEX download at same time I'm
editing with WordStar.

<L.GELLER> Right on!

<[bridger]> On memory mgt.  At the moment we're looking at the Extended
Memory Manager of intel/microsoft, etc.

<JIMLILL> Yep

<[Jay.Sage]> Based on my experience with MS-DOS, I don't think IO
redirection is that important, but BG-style screen operations (capture)
are.

<[bridger]> Let me take 1 topic at a time. Ok? Mem mgt first.

<JIMLILL> I agree with Jay

<STEVE.HIRSCH> Bridger. Tell us a bit about EMM?

<[daveMc]> multitasking is certainly attractive, but are you willing to
pay $300 to $500 for an O.S. that does it, and wait another year or
two?  That's what it would take.

<STEVE.HIRSCH> All of the above, Dave.

<[Jay.Sage]> How about emm, bridger?

<B.MORGEN> Plainly, your current generic CP/M stuff will need all the
base page stuf

<[bridger]> We want a STANDARDIZED interface that can port to various
machines with no recoding.  The prog would say: give me 4 (or 16 or x)
K, at this address.  Then swap it in/out, to an allocated memory handle.

<B.MORGEN> There will be a system call to reserve memory?

<[bridger]> It would behave much like an overlay area, but managed by
the OS, and actual memory, not virtual.  (could be emulated on disk in a
2.2 system for further portability.  Yes calls would be:  get max mem avail,
reserve x K, map that to this base address, swap handle #n to the base, swap
out, release memory..etc.

<STEVE.HIRSCH> That's elegant.

<B.MORGEN> Should be fast as all getout too...

<[bridger]> Note that this COULD run on a 2.2 system with an RSX that
emulated tghe EMM calls, and on a ram disk that would look fairly good an
yway.  so we have some degree of backward portablilty possible.

<[daveMc]> these functions would be there, but also most of the OS would
be outside the TPA bank, allowing 60K+ for cp/m-specific programs.

<[bridger]> yes - fundamental objective is MAX TPA HEADROOM !

<[dan] S.PLATYPUS> I like that!

<L.GELLER> Future systems should definitely aim form > 60K.  It should
be a requirement .  . .

<B.MORGEN> Wouldn't there be multiple TPA's under OS management?

<[bridger]> more comments on mem mgt?

<[daveMc]> the dt42 computer's z-system implementation right now has 57.
5k free memory with a full 5k zcpr3 overhead.  dos and bios is outside
tpa space.

<L.GELLER> Can TPA's stack up through memory?

<[bridger]> Topic 2, more or less: multitasking, multiple tpa's:...

<B.MORGEN> I guess we're all so used to none at all that anything sounds
great..

<[Keith] W8SDZ> Why can't you get up to 63k TPA or more, with just the Jump
Table there at the top?

<[daveMc]> keith, I'd be interested in your reaction to my comments
about price tag and time delay for a multitasking OS.

<B.MORGEN> Is Z compatibility the issue there, guys>

<[bridger]> Multitasking SOUNDS great, until you realize that a high
%age of what we do is screen-oriented.  There's just 1 screen,
keyboard; other tasks really have to wait for it.  That led me in the
BGii direction -- user-controlled task switching, with LIMITED
multitasking for print spooling, and I think file transfer/network
transfer may be a good second candidate.

<B.MORGEN> Dave, if it's $500 and it works, count me in!

<JIMLILL> I go 200-300

<JIMLILL> Yes file xfer a good one

<[Keith] W8SDZ> I think the multitasking could be made to work if you
could assign highest priority to foreground task.  This would require
an interrupt-driven system, inclduing disk I/O.

<B.MORGEN> I'd like at least one background RUNNING task - like XMODEM or
KERMIT running while I edit or assemble something.

<[dan] S.PLATYPUS> need 1581's for speed!

<[bridger]> Of course it could work.  But what about the screen? how do
you get messages to the console when the background xmodem task doesn't
have any screen?...

<JIMLILL> Yes... I've seen with Poor man's net that non interrupt polling
consumes too much time

<[Keith] W8SDZ> That WAIT message in WordStar is annoying while I'm
trying to type, for instance.

<[bridger]> in the ibmpc you have a SINGLE screen interface; we have
zillions of terminals; that's why BGii's screendriver interface is
difficult, and a big achievemnet.

<B.MORGEN> I think a console bell interrupt would be fine - of course
the application would have to know how to call it and the system would
enable you to save your current task BGii - style.

<[Keith] W8SDZ> I'm not adverse to buying two video monitors so I can
have two different screens active.

<JIMLILL> The BGii screen system great particularly with Stev Hirsch
driver.... get a SWAP in .3secs

<[bridger]> I'm still playing with the idea of a limited 1-line window
driver for backgrounjhd messages. or perhaps the BGii driver, but for
very limited type messages.

<B.MORGEN> Keith, you really should try BGii, it's a revelation...

<L.GELLER> Keith, you need a type-ahead buffer in your bios.

<[bridger]> You have to realize that it's serial bandwidth to the
terminal that is the bottleneck; 1 sec or so to xmit 2000 chars, just
to redraw.

<JIMLILL> Poor Man's Net has a single line message window

<[dan] S.PLATYPUS> dumb< -- what is a BGii

<[Keith] W8SDZ> I'm interested.  My system is a generic S-100.

<B.MORGEN> What terminal?

<[Keith] W8SDZ> Soroc 120

<B.MORGEN> That's pretty much like a Televideo, right?

<[Keith] W8SDZ> More like an ADM3 with enhancements.

<[daveMc]> the 120 is probably too dumb to send screen contents, eh?

<[bridger]> keith - can it transmit the screen to conin?

<[Keith] W8SDZ> No transmit screen.

<B.MORGEN> sigh...

<[bridger]> BGii=BackGrounder ii = a task-switching z33-type command
processor

<[dan] S.PLATYPUS> thanks bridger

<[Jay.Sage]> I use BGii without any of those features, and it is still
great.

<[bridger]> Ok, then the poor man's answer is to use the WS redraw
command, that comes with BGii.

<[bridger]> Let's help dan.  Bruce, you're a vet. user.

<[dan] S.PLATYPUS>  I'm going to have to dl this to find out all the
questions to send mike!!

<[daveMc]> I'll try to explain BGii for you dan...

<[dan] S.PLATYPUS> thanks!

<[dan] S.PLATYPUS> buffer open

<[daveMc]> bridger is the author.

<[Jay.Sage]> Dan, imagine being in the middle of Wordstar and then
hitting akey and being in the middle of SuperCalc, grabbing the screen,
switching back to WordStar and sticking it in.  THat is BGii.

<[dan] S.PLATYPUS> very very impressive

<[daveMc]> It's a commercial product, sells for $75

<[Jay.Sage]> ANd you can create key macros at any time.

<[dan] S.PLATYPUS> how does that differ from multitasking?

<[Jay.Sage]> The second task is not running while it is switched out --
just waiting.

<[daveMc]> "non-concurrent (not simultaneous) multitasking"

<B.MORGEN> That is only a small part of what you can do - for
example, I called into GEnie with MEX114 and had T3FILER in the lower
task, ready to go with split-screen and all...

<[bridger]> But BGii does do 1 multitask process: print spooling

<[dan] S.PLATYPUS> and this is handled by hardware interrupts?

<[bridger]> no

<[Jay.Sage]> It runs on almost any hardware.

<[daveMc]> software only does the work, it's generic.

<JIMLILL> Not C128 though!

<B.MORGEN> It does require a decent LISTST function in the BIOS, though...

<[Keith] W8SDZ> Does it do its thing by writing the current TPA to disk?

<[dan] S.PLATYPUS> is bgii hardware?

<[Jay.Sage]> Yes, Keith.  In a very clever way.

<[bridger]> bgii uses a 100K virtual memory swap file; writes tpa
there, + screen,

<B.MORGEN> That and a good deal more, including BDOS state variables...

<[daveMc]> My opinion re multitasking on the new OS. is that it would be
desireable, but isn't a necessity for the first cut.

<[bridger]> uses 4.25K max of tpa; less in z systems.

<[Keith] W8SDZ> How does it get the CPU back the way it was before you
left?

<B.MORGEN> The CPU is left intact...

<L.GELLER> That leaves me 41K . . .

<[bridger]> cpu itself is no problem; its the dos's state that is so
tricky.

<JIMLILL> Dan: BGii is software

<[Bill] B.DUERR> I have a Kaypro II, and have noticed that my screen
will not keep up at 4800 baud, will BGii help me?

<[Jay.Sage]> In your Z-COM it does not take as much memory.

<[dan] S.PLATYPUS> thx jim

<[bridger]> lgeller - where is your bios?

<[daveMc]> larry, under z-com it would take only .25 k

<B.MORGEN> Not for Osborne I, for sure...

<L.GELLER> Have memory-mapped video interfering.  It's a problem
peculiar to the PC8800, of which there are few in the world.

<B.MORGEN> You re-use the IOP and RCP buffers in Z-COm...

<L.GELLER> So my Bios is above and below screen area.

<[daveMc]> Bgii however will not work on cp/m+ machines such as 128.  It
is set up for cp/m 2.2 or z-system

<[STEVE.COHEN] SMCUWAUE1154> How do you reuse'em without loosing 'em?

<[Jay.Sage]> The cost of BGii would be minimal over that of Z-COM.

<[bridger]> bill duerr:  kaypro II speed relates to redrawing the
screen while using the serial port; you would need interrupt -driven
serial port.  Bgii doesn't touch this area.

<L.GELLER> I can't use IOP to begin with.   It is that or give up on WS.

<[Bill] B.DUERR> thanks bridger

<[bridger]> lgeller: pse resummarize your mem map

<B.MORGEN> VDE251 is a good WS alterntive for tight TPA...

<[daveMc]> give up ws?  if you have z-com the iop space is allocated
anyway can't undo it....or have you

<JIMLILL> Or VEDIT

<L.GELLER> I don't think my prob is of interest to the group - maybe
off-line, later.

<[daveMc]> right

<[bridger]> ok; can we return to multitasking needs?

<[dan] S.PLATYPUS> buffer closed

<[STEVE.COHEN] SMCUWAUE1154> I have 3 Zsystems, 56K W/IOP, 58K and 61K
for Turbo Modula 2

<JIMLILL> I think the xfer capability is the biggy

<[Jay.Sage]> It seems we are fairly well in agreement that only a few
types of jobs really need multitasking -- printing and modem.

<[STEVE.COHEN] SMCUWAUE1154> All for the same machine.  Gets confusing
at times, but you do what you gotta do.

<[dan] S.PLATYPUS> I think I have to go do some homework to keep
abreast of you all!

<B.MORGEN> Like I said, a true concurrent extension of the BGii idea,
for at least one background task,,,

<[daveMc]> for those who'd like an in-depth explanation of these things
such as BGii, ZCPR3, etc., Echelon has a 24 page catalog that lays it
out in non-technical terms.

<L.GELLER> Get BGii demo from GEnie  .  .

<[dan] S.PLATYPUS> dave do we have an address for echelon?

<[daveMc]> 885 N. San Antonio Rd, Los Altos, CA 94022  415/948-3820.
no charge for the catalog.

<[dan] S.PLATYPUS> echelon

<[dan] S.PLATYPUS> thanks

<L.GELLER> How to handle multitasking and RS232 interrupts to a task?

<B.MORGEN> NAOG/ZSIG (independent users group for 64180/Z-System/BGii)
is at PO Box 2781, WWarminster PA 18974.

<[bridger]> what's the issue, Lgeller?

<B.MORGEN> With the "new" chip we can grab interrupts, right?

<L.GELLER> The RS232 will receive a char, but for which task?  How to
standardize the method of connecting the data to the task?

<B.MORGEN> Sharing the same port makes no sense...

<L.GELLER> Exactly.  How to request port?  What happens to a task if
request denied?

<[bridger]> in a true multitasking OS you have a scheduler; the kernel
catches all interrupts; there's a virtual terminal/virt. screen for each
task; the current task gets the char.

<JIMLILL> I have two versions of MEX for each of 2 ports and can run
two modems at same time with BGii now

<L.GELLER> Problem with CP/M or Z is that hardware is not standardized.
Most people

<[bridger]> In BGii, the ACTIVE task always gets the char; the device
(terminal) is assigned to that task, until YOU switch it.

<[Bill] B.DUERR> Two tasks could share the RS-232 with a Packet
arrangement!

<L.GELLER> have one port.  A solution to the multi-tasking/interrupt
problem seems to be not trivial at all, and needs some discussion.

<[bridger]> Agreed, if we're talking 2 concurrent modem channels.
That's more multitasking than some had in mind, but very interesting.

<[keith] W8SDZ> please wait
Here is a message from Arpanet.

Date: Wednesday, 10 June 1987  15:45-MDT
From: Dick Mead
To:   Keith Petersen, W8SDZ
Re:   ZEDUX...

Just chatted with one of the folks at Zedux. The BBS is expected to be
up by this weekend. He is still preparing docs for callers, the usual
housekeeping stuff. The BBS will use the Z280 in an old Cromemco
S-100 Z80 system.  The Z280 is a "co-processor" not too unlike the way
the various ad-on clock cards do, with the Z280 plugging into the Z80
socket, and the Z80 plugging back into the Zedux card. All parts are
soldered in, no sockets. The design will accept 1 megabit Drams when
available, however. Cost was a factor.  He says they did talk to
Echelon, but the software provided is their own, no plans to work
with Echelon. The Z280 will have a 20mHz clock (10 mHz system clock)
and talks to the Z80 via an 8 bit port, the Z80 beibg an I/O
controller in this application. He did talk to Ampro, too, but Ampro
will supposedly come out with their own single board Z280 card, and
Zedux says they will be doing likewise.  I am having some literature
mailed to see what else he may have in print.  No sources for the
system software are offered, not unlike CP/M CCP/BDOS.  It uses host
BIOS...Multiple programs see 64k, minus 512 bytes for system vectors
(page 0, Bdos/bios).

That's about all I got...If you call the service, the Zedux folks will
apparently call back...

Dick

<W8SDZ> Did that come through

<JIMLILL> Yes

<[Keith] W8SDZ> The main point in sending that message from Dick Mead
is that he did talk to someone there.  Bruce was wondering it it was
for real.

<L.GELLER> It looks as though the best systems are yet to come

<JIMLILL> Bridger... that 2 modem thing can be very helpful at times

<[daveMc]> the zedux software is in some ways a zcpr3/z-system clone.
It does purport to be multitasking, but all i/o is funneled through a
cp/m bios...a bottleneck.  also, the zedux software does nothing to
allow application to use more than 64k memory.

<B.MORGEN> Won't the UltraBoard have similar limitations?

<[daveMc]> yes ultraboard using a cp/m 2.2 bios will have the same
bottleneck for multitasking OS.

<JIMLILL> Bridger.... the new OS could include the Poor Man's net type
of Networking

<[bridger]> To get the performance benefits of any new OS a system will
need an upgraded bios;.. for 100% multitasking it must be fully re-ent
rant.  NONE of the current ones approach that standard.

<[bridger]> JIM - what PMNet features do you find most useful?

<JIMLILL> I ONLY use the remote disk feature... that is since my Apple
don't have MFM drives I net to a Columbia "shoebox" for MFM drive.  Of
course I can move files in while doing other things too... true multi-
task.

<B.MORGEN> Jim, I know you like PMnet, but I think T3MASTER/T3SERVER is
more sensible in a Z-style environment - PMnet would be great if it
were banked sway somewhere...That's away...

<[bridger]> Network service is a whole subject of its own -- most of us
need some machine-to-machine file transfer service.  Whether we need
FILE SERVICE (a logical drive addressable from our terminal) is a ?
And file locking on a remote system is a big jump.

<JIMLILL> Well I can't agree or disagree not having experience with T3
Yes the PMN is a disk server... not a file server for that reason

<JIMLILL> Bridger... since BGii can TYPE SQueezed files.... why doesn't it
handle swueezed help files??

<[bridger]> jay - back to your thoughts about bgii vs/plus redirection?

<[bridger]> jim - uncrunching takes 16-20K of memory!!

<B.MORGEN> Bridger, can you describe what

<JIMLILL> I c, not crunched - squeezed

<[bridger]> bgii does type sQ'd files.

<JIMLILL> it should use .HQP rather than .HLP files

<[bridger]> No, you can't go backwards in a compressed file.

<B.MORGEN> Good thought

<B.MORGEN> Conn's LHELP does, guess it buffers the output....

<[Keith] W8SDZ> How does BISHOW do it, then?  I think it reads the
earlier part of the file to get back in a squeezed file.

<JIMLILL> As for I/O redirection... I never use a IOP and don't miss it

<[Jay.Sage]> Jim, you can always invoke the transient help from the
other job (:HELP).

<[bridger]> Guys -- BGii does this without disturbing the TPA!! give it
a break!

<JIMLILL> Yeah just seems like one should do

<[Bill] B.DUERR> Another problem happening with CP/M is the lack of new
application programs and support of the old ones.  Perhaps, a new
operating system would encourage programmers to address that problem.

<B.MORGEN> We are a greedy bunch - now what about a few more Z33 things
for BGii....

<[bridger]> which ones, bruce?

<JIMLILL> space prefix for zip to ECP

<[bridger]> it s there in v 113

<B.MORGEN> Faster path search, optimized like Jay's - I never saw the
differnce with 3.0, but now I do...

<JIMLILL> oops!

<[bridger]> Jay & I are looking at the search; I think I'll get to it
later this summer.

<B.MORGEN> Great, I just can't go back to non-BGii, you understand....

<JIMLILL> Yeah.... BGii makes Z33 take a back seat here too!

<[bridger]> I did have a serious question, tho -- BGii is packed to the
gills, and I need a priority list, everything may not fit.

<B.MORGEN> And the parser entry points would be nice, as would the
enhanced error handling, but the faster search is #1 for me....

<JIMLILL> Give up the Wheel stuff

<[bridger]> Ah..parser entry points.  Haven't you realized you can't
count on having those entry points ?

<B.MORGEN> I could do without some of the built-in command - Jay has a
transient SAVE, for example....

<JIMLILL> FIND could go for my money

<[bridger]> Let me continue on CP entry points -- a tool MUST verify
that those entries exist and can be called, or it will surely bomb your
system.  But the CP may have been overwritten.  Or another CP may be
running.  So the tool has to have its own (vanilla) parser anyway.
This is an ex. of the need for defensive programming, so the tool will
run in various environments.

<[Jay.Sage]> No, it can also just refuse to run and give an error
message.

<[bridger]> Agreed.

<B.MORGEN> Explain your parser command - surely the application knows
if it is overwriting the CCP and we have a Z33LIB call to confirm the
CPR revision...

<[Jay.Sage]> But then you need another tool for that function, I
suppose.

<[Jay.Sage]> Whom are you asking, Bruce?

<B.MORGEN> I was just pointing out that we can tell if the parser is
there, that's all...

<[Jay.Sage]> I intended that call to be used by programs before they
start to gobble TPA.

<[Jay.Sage]> Or the program will have to protect the CCP.  But it is
very nice for SAVE and JUMP transients and externals.

<B.MORGEN> And BGii's CCP is always protected....

<[Jay.Sage]> All in all, I would much rather see that function in the
DOS.

<[bridger]> Part of the difficulty is how the tool can distinguish z33
from BGii v1.xx which has some, but not identical/all z33 features.

<B.MORGEN> Agreed, but we are still in Z80 land....

<[Jay.Sage]> We can have a library call for that.

<[bridger]> i.e. BGii will now need to "say" it is v33 in the z33 id
byte, but that won't mean it has parser entries (they're not even in
memory!)

<B.MORGEN> Z33LIB returns false for BGii, true for Z33...

<[Jay.Sage]> BGii can be identified and so can Z33.  That is the real
question.  Can the BGii CCP have those entry points?

<[bridger]> No

<[Jay.Sage]> That settles that, then!

<B.MORGEN> Not easily if the code is in the swap file, Jay...

<[Jay.Sage]> Of course, question is can it be kept resident?

<[bridger]> One other reason, by the way, is often overlooked by the z3
community--BGii is designed to be 2.2 compatible.  The cmd line buffer
must be in place to do that.

<[Jay.Sage]> Anyway, I think this is a minor point.  THe error handling
is more significant, I think.

<[Jay.Sage]> Could there not be a second version of BG that is Z only?

<[bridger]> Are the error numbers themselves important, or the flow?

<B.MORGEN> The numbers have assigned meanings....

<[Jay.Sage]> THe error numbers are handy, but the fact that other errors
are trapped is pbobably he more important feature.

<[bridger]> In principle, a z-only BGii could be built.  But let's be
realistic.  What's the market?

<[Jay.Sage]> In an automatic command environment, on has to be able to
catch anything that goes wrong.

<[bridger]> key point.

<B.MORGEN> I'll buy Z-BGii for full list price...

<JIMLILL> Got any idea how many BGii users are Z guys and how many Not??

<[Jay.Sage]> Well, that is a very general question for this whole
enterprise.  It is partly a question of how much extra work is required.

<B.MORGEN> And how much of it is going to applicable to the ZOS project
anyway...

<[Jay.Sage]> I would, too, but then there are so many who could benefit
from BGii as it is who have not bought it.

<B.MORGEN> Agreed, to both notions....

<JIMLILL> It needs a review in Computer Shopper.  Shopper needs a CP/M
column.

<[bridger]> There's a growing number of kaypro/morrow/... types who
haven't yet seen zcpr3; one of my ideas was that BGii could be a
gateway for them into the z community; an auto-load z-type system.
Then move up.

<B.MORGEN> Do CPMers read that thing in any numbers??

<[Jay.Sage]> I wrote reviews for two BCS magazines and so far there has
been almost no response.

<JIMLILL> I think many CP/Mers are hungry for any reading - its cheap
too!  I look for the BCE ads if nothing else...BCE of $299 Xerox fame.

<[Bill] B.DUERR> Jim, they uped it to $350

<JIMLILL> still a good deal

<[bridger]> question:  if you know unix, you do this often:
cmd < infile > outfile; would you find this REALLY useful in a new OS?

<[Keith] W8SDZ> Not me.

<JIMLILL> My mainframe system in work while not Unix is same

<[bridger]> And then you can 'pipe' to the next prog: cmd | cmd2

<JIMLILL> I can adapt to either

<[Jay.Sage]> I have found little use for that on MS-DOS machine.  Of
course, it could be improved to default back to standard input when the
input file reached its end.  THen it might be good.

<[bridger]> keith -- you've voted for putting oft-used routines into
the OS, and background file transfer.  Anything else on your list?

<[Keith] W8SDZ> The one objection I have to Unix is that it's a system
programmer's operating system.  You have to know all those cryptic
commmands and how to string them together to do something.

<[bridger]> Where is Z stronger, and where does it need improvement on
that score?

<[Keith] W8SDZ> Yes, the parse FCB is used quite often, as well as
parse 80h command buffer.

<B.MORGEN> Bridger, doesn't Unix do that via temporary files?  I guess
we should consider if we should treat files a devices similarly in the
new OS....(piping).

<[bridger]> unix uses memory, for sync'd processes.

<[bridger]> use user nicknames, guys

<B.MORGEN> ? is, should we bother...

<[Keith] W8SDZ> A good study in what extended operating system calls
are needed is to look at Ward Christensen's original MODEM2 in the
section labeled "subroutines".

<[dave Mc]> do you have modem2 online someplace?

<[Keith] W8SDZ> No, but I can upload it.

<[Keith] W8SDZ> It is on Simtel20 in PD:<CPM.MODEM2>MODM221A.AQM.

<[bridger]> ok - that makes code writing easier.  What about the user
interface you mentionhed?

<B.MORGEN> Isn't MODEM2 in SIG/M///

<[Keith] W8SDZ> MODEM2 is in CPMUG, I think disk #25.

<B.MORGEN> What a memory Keith!

<[- Host -] MICHAEL.M> the ZCPR Bull.Board Category is #11.

<B.MORGEN> And the library is #33

<[Keith] W8SDZ> Bridger and Dave, have you had time to look at that
catagory in the BB?

<[dave Mc]> keith, wanted to express apreciation for setting up the "Z"
areas.  I'm thankful.

<[bridger]> Yes, browsed #33

-END-