knudsen@ihwpt.ATT.COM (mike knudsen) (05/19/87)
There is already one OS9 screen editor, Dynastar from Frank Hogg,
that edits files too big for available memory. Unfortunately,
its "window" can be advanced only forward thru the file--
if you need to go back and add a variable declaration
at the beginning, you must close the file and start over to
get the front part. (Those of you with strong stomachs may
recall that the EDIT supplied with Coco Level 1 also handles
too-large files in this way.)
A good trick for Level 2 would be to put the entire file in
RAM, but not map all the blocks of it into the 64K space
at once. A 512K machine could edit a whole 360K disk-sized file!
The user would see no delays when skipping around in the file
since there is no disk access involved. The extra programming
needed in the editor (block-swapping algorithms) would not
be all that complex, it seems to me.
Trouble is, I'm not sure how OS9 could be cajoled into doing
this. "Data modules" would be ideal, if you can find a friend
of a friend of someone who claims to have actually used one of
these elusive beasts (I've posted this challenge before, no
takers). Maybe the editor could split up the text into 8K-delta
chunks, append OS9 program headers and CRCs to the chunks,
and get them LOADed that way. Then the editor LINKs to the
ones currently chosen to be in its space. Algorithms know to
skip over 'delta' bytes between blocks of text.
mike k
PS: Jim (was it you?), how do you run a QT out of 512K RAM when
it doesn't even have windows and graphics? I haven't blown out
my Coco yet (but I will sooner or later, right?)
--
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
Delphi: RAGTIMER CIS: <memory failure, too many digits>
"Just say NO to MS-DOS!"ingoldsby@calgary.UUCP (05/20/87)
If anyone has a working version of microemacs for the CoCo III I'd be very
interested in getting a copy. Some time ago I got the source code for a
version of uemacs that I never got around to porting for the CoCo III.
I'd be interested in any other editors that can edit files larger than
available memory. This can't be too hard since Wordstar does this on MS-DOS.
I don't know the exact algorithm used, but I do know that temporary files
are maintained. It is possible to go both forwards and backwards in the
file. Anyone who works with Wordstar could probably make a few experiments
and determine the algorithm used (surely this is not violation of copyright?).
Terry Ingoldsby
ihnp4!alberta!calgary!ingoldsbyjimomura@lsuc.UUCP (05/21/87)
In article <1687@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: >PS: Jim (was it you?), how do you run a QT out of 512K RAM when >it doesn't even have windows and graphics? I haven't blown out >my Coco yet (but I will sooner or later, right?) Whaaaaa? If you're asking whether I find 512K RAM a tight fit for an OSK system, well, actually it can be. It all depends on how you use it. For instance, if you want speed and you're doing a lot of compiling, you'll prefer to have the whole C compiler in RAM at once. You could also preload 'make'. It wouldn't be bad to have your text editor, say MicroEMACS in memory too. On top of all that, you might want a good size RAM disk to hold temporaries. Actually I don't work that way myself. I prefer to keep most things on the hard disk. But I do sometimes preload part or all of the compiler. Yesterday I had a classic big-memory/multi-tasking thing happen. My brother-in-law called from San Francisco (a diagonal across the continent!) and I wanted to give him the phone number of a freind from BIX in a hurry. I was in the middle of doing a major edit with Umacs (MicroEMACS as supplied by Microware with OS-9 68K professional). Despite the large file I was editing I had enough memory to call a Shell, use Qcom (Frank Hogg's telecom program which comes with the QT's) and call BIX and check the phone number while my brother-in-law was on the phone, and all without having to store off the file I was working on and lose my train of thought. This trick I could have pulled off with Level II and the CoCo, but the QT really shines when I do simultaneous multiple crossloads. The DMA allows everything to happen at once. The CoCo might come close if I get that new DMA (semi-DMA?) disk controller by Sardis. About the "super setups" by Frank Hogg and that other company (can't remember the name offhand), it's a pity that they only supply the one 80 track floppy and the hard disk on these systems. There are simply times that you want a 40 track travesty^H^H^H^H^H^H^H^H drive. (;-) I mean how else am I supposed to run copy protected software? Surely you don't think that right minded CoCoists would actually break the copy protection on those disks? Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
mpease@cvedc.UUCP (Mark Pease) (05/21/87)
I have been working on an editor for programming that edits files larger that memory for OS9. It uses a LRU virtual memory buffers idea to manage the file. I was not ready to release it (I was hopeing to sell it, maybe there is a market for it?), but I could send out "beta test" copies. Drop me a note and I could send a discription of the editor by e-mail. -- Mark Pease ..tektronix.csnet!ogcvax.uucp!cvedc!mpease Computervision ..sun.arpa!cvbnet.uucp!cvedc!mpease 14952 N.W. Greenbrier Pkway Beavertion, Oregon 97006 (503)645-2410
pete@wlbr.UUCP (Pete Lyall) (05/21/87)
In article <921@vaxb.calgary.UUCP> ingoldsby@calgary.UUCP (Terry Ingoldsby) writes: >If anyone has a working version of microemacs for the CoCo III I'd be very >interested in getting a copy. Some time ago I got the source code for a >version of uemacs that I never got around to porting for the CoCo III. > >I'd be interested in any other editors that can edit files larger than >available memory. Terry (and all), The os9 UG LIB has a version of Uemacs for both the level I coco, and the OSK machines. I have a version of the 6809 version that was ported to LII by Carl Kreider (methinks...). It still only allows two windows, expects only an ASCII type terminal, and you must #define certain terminal control strings. Also, I feel it's a tad on the slow side. Some folks on compuserve are working on a makeover of a previously released LI coco type editor - SLED. The fellow has done a nice job so far, and has versions for vanilla and COCO3 LII (I have *forced* the vanilla version on him ... :^) ). Currently, it also uses #defines for configuration to various terminals (sigh), but with help from a few of the fellows on the forum (CIS), we are working at coming up with some terminal-independant library stuff. I already have a lot of groundwork laid here, and and expecting some code later in the week from a fellow named Heitzo of MetaMedia, who has developed & tested a complete set of C terminal primitives. This brings rise to a question I have been wanting to ask for a *long* time: Should we initiate action to get a SOURCES newsgroup up here for OS9?? I have *countless* things from the Forum, other programmers, and self written that I'd love to post, if there were some sanctioned way to do it. Among the 1st is the 'AR' program - it's *somewhat* like MESSDOS's 'ARC' in that it batches files together into an 'archive', and compresses those files that are not binary. We have been using this a s a pseudo-standard for almost a year on CIS for moving multi-file collections to and fro with a fair degree of acceptance and efficiency. '.Ar' files could be uuencoded and shipped about the newsgroup. Of course, we could also use the standard SHAR format. In any case, I'd like to get some feedback from the group on the subject of source postings, whether a separate newsgroup is merited, etc. -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 SIG Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Phone: (818)-706-5693 (work 9-5 PST) EATON Corp, IMSD, 31717 La Tienda Dr., Westlake Village, Ca. 91359 ----------------------------------------------------------------------
dibble@rochester.ARPA (Peter C. Dibble) (05/21/87)
You probably won't be surprised to hear that I've "actually" used data modules. I use them in a telecom program I wrote. The program runs several tasks which communicate through data modules (for instance disk and printer operations are done by separate tasks). I think Microware's spooler uses data modules. At least it used to. Peter
jimomura@lsuc.UUCP (05/24/87)
Posting of sources has been mainly a logistical problem for me.
When I first posted the OS-9 MicroEMACS (was it a year ago?--can't
remember) I did it exactly once. I intended to repost for the sake
of some people who missed parts, but I never really had a chance to
do it. I've posted a couple of things lately, in different ways,
but I'm not sure what's best. I've sent mail to John Daleske with
sources, but only the last one was distributed. Maybe he exercised
"editorial policy" on one of the other sources, but I think it's more
likely he never received it. Net mail can be like that.
Pete, I'd be interested in seeing the 'AR' sources. As I write this,
(ahem--big drum roll please) I'm just preparing to post the OS-9 68K
version of MS-DOS ARC by SEA. The port works and I have SEA's permission
to post it to the Net as well as to BIX (where it's already available)
*and* we have tentative agreement for submission to and distribution
by the Users' Group. This all happened within the last couple of days
and it means we've taken a big step to data compatibility.
I still haven't confirmed a reliable port of LZM compression. I
am of the opinion that it can't be done on the Color Computer due to
the vast amount of memory it requires. Indeed, I think the problem
with the port I've done so far may just be that I don't have enough
memory on my 1/2 meg. QT to use it. This is a pity because LZM is
a very power full compression technique. In a few weeks, when I'm up
to 2.5 Meg., we'll see. Anyway, it sounds to me that the only format
which we OS-9'ers can use commonly will be 'AR' rather than 'ARC'.
That leaves us with the problem of Uuencode v. S-Records for object
code. I don't care much either way. I prefer S-Records because they're
easier to fix if broken, but not everybody has that anymore. Maybe
the best thing to post first would be a BASIC09 version of 'Exbin'. At
anyrate, that's why I posted the Udecode.bas file. At least we can
all access Uuencoded files.
Cheers! -- Jim O.
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomurapete@wlbr.UUCP (05/27/87)
In article <1816@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > I still haven't confirmed a reliable port of LZM compression. I >am of the opinion that it can't be done on the Color Computer due to >the vast amount of memory it requires. Indeed, I think the problem >with the port I've done so far may just be that I don't have enough >memory on my 1/2 meg. QT to use it. This is a pity because LZM is >a very power full compression technique. In a few weeks, when I'm up >to 2.5 Meg., we'll see. Anyway, it sounds to me that the only format >which we OS-9'ers can use commonly will be 'AR' rather than 'ARC'. > Well Jim..... the 'AR' package *does* use the older version of LZ compression. Also, in the version that I will likely post in the next few days, there are conditionals to use the newer LZ package. I don't know if that was ever worked ouit though. -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 SIG Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Phone: (818)-706-5693 (work 9-5 PST) EATON Corp, IMSD, 31717 La Tienda Dr., Westlake Village, Ca. 91359 ----------------------------------------------------------------------