Arjen,

> >> First, I plan to implement a very scaled down version of the DOS FAT
> system
> >> in the NVRAM.  Master file table, FAT, sectors, and no subdirectories.
> >> The user will not be aware of the storage scheme. I want to use it to
> >> facilitate memory reuse as data blocks are added, changed, or deleted.
> > Another way to link "sectors" together could ne done by adding a
pointer to
>
> > ?each data-block telling where the next "sector" is.
> > By the way : with 2 (or 4) MB of space a Directory-structure would be
> handy...

That of course depends on the lookup method and even more on the size of
the
individual files.
What kinda storage hardware did you have in mind for larger amounts of data
space?
A flash rom would do, but requires some extra logic for pin multiplexing...
And another issue is 'deleting' files... can a flash rom be *partially*
wiped?
(in the end of course you'd get into defragmenting issues, but that's not
really a prob)

At this time I plan to use up to two 2 meg NVRAM chips. I looked at Flash
but was unable to find a solution I felt comfortable implementing with my
limited experience (The two solutions I came up with were a SMT chip and
the PC-Card).  I don't plan to wipe the sectors as the "files" are erase,
just mark them in the FAT as available for reuse. As new data is written to
the sector, it can either be filled with zeros, terminated with one zero,
or the length of the data written to a field at the beginning of the
sector.  At this time I plan to just write a terminating zero. I didn't
think fragmentation would be a problem since the access time for each
sector is linear.


Many terminal programs have an ASCII upload feature that allows for
configurable delays between two chars, and at the end of a line. That'd
solve
that prob.
Personally, I'd be tempted to implement Xmodem/CRC. Code-wise it's peanuts,
provided you can store the data temporarily while you're receiving... it
requires 128 bytes plus a few working regs. Some PICs have enough internal
RAM,
otherwise you'd need to look for something external. No big deal.
At least Xmodem is reasonably reliable, if chars get lost or scrambled the
prog
will notice it.

I planned on reserving a fixed buffer at the beginning of the RAM to shove
received characters into.  When it approaches overflow, the device will use
XON/XOFF or RTS/CTS to pause the sender until the temporary buffer is
flushed.


Thanks for your input.
Eric