🚀 go-pugleaf

In article <797@drivax.UUCP> alexande@drivax.UUCP (Mark Alexander) writes:
>In article <4170@utah-cs.UUCP> atwell@utah-cs.UUCP (Bart L. Atwell) writes:
>>Maybe OS-9 can solve the 40 folder situation!

     Yes, it does.

>I'm sure it can, but it wouldn't do you much good if you wanted
>OS/9 to be disk-file-system-compatible with TOS, which I doubt it is.

     Quite correct.  The disk format is different but
I'm not quite sure how important this is to you.  For me
it is getting less important constantly.  The first problem
I had was that I had no way to get *anything* from TOS to
OS-9 or backwards.  Now I can do it via an intermediate
computer using Kermit.  In a little while, I should be able
to do it direct disk to disk by writing a TOS format driver
under OS-9.  This should be particularly simple since I
Obviously just have to disassemble the TOS driver and re-
assemble it with fairly minor changes under OS-9 (which
comes with an assembler).  For most purposes I'll also
need a LineFeed stripper and a utility to add LF's after
CR's because OS-9 only needs a CR for EOL.

>It also wouldn't do you much good if you still wanted
>to run your TOS/GEM programs, unless someone went to all
>the trouble of writing a TOS front end for OS/9 and ported
>all of GEM, which I also doubt.

     This may not be necessary.  I found out recently from
Avy Moise that OS-9 sits *beside* GEM in memory and doesn't
overwrite the previously used memory.  This has its advantanges
and disadvantages.  The advantage is that it should be fairly
easy to write a utility which returns you to GEM intact at
the point where OS-9 was called.  Furthermore, it may be
possible to run GEM under OS-9 with a relatively simple
"utility".

     Ironically, what's proving to be more difficult for me
right now is just disassembling an OS-9 driver.  I won't
go into that right now though.  Let's just say it's not
all that difficult, but I can't do it right now.



Cheers! -- Jim O.