Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!pnet91.UUCP!ericmcg
From: ericmcg@pnet91.UUCP (Eric Mcgillicuddy)
Newsgroups: comp.sys.apple2
Subject: ViM
Message-ID: <9010100345.aa28999@generic.UUCP>
Date: 10 Oct 90 03:44:34 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27

This is a reply to private mail I had received. Unfortunately it was
undeliverable, so I'll post for all to see. And hopefully the person who
contacted me will get it too.

>>>>>>>>>>>>>>>>>>
I only use high level I/O commands so DMA compatibility is not my problem.
This has the additional virtue of allowing any file system to be resident
without having to recompile the program (or do at least make minor changes to
take advantage of the new system, i.e. Mac HFS). Also I don't have to care
about the block size, Prodos/Mac use 512k blocks, CP/M uses 1k blocks and
MSDOS uses 2k-4k clusters, ViM doesn't care as long as the required data is
returned correctly.

The GS has a Memory Management system in the Toolbox that is lacking in DOS
computers, this is what makes ViM possible in software only. An equivalent
utility is not possible without hardware support on DOS systems (or 8=bit
Apple II's for that matter). I would ask that you look at programming your GS,
I think you be amazed at the power available to you, I was.

BTW, I used Orca/C to prototype the system and test the logic, you might wish
to consider this option. I needed more direct control, so I am in process of
hand compiling the code, I make a much better compiler than any machine could
ever hope to achieve. :)
<<<<<<<<<<<<<<<<<

UUCP: bkj386!pnet91!ericmcg
INET: ericmcg@pnet91.cts.com