28 Jul
2003
28 Jul
'03
8:26 a.m.
At 12:27 PM 7/28/03 -0700, you wrote:
Joe, that is absolutely true. I was not considering the speed or caching
abilities of the drive itself. I was thinking more generically of an
approach that would work OK for both a sluggish floppy and a faster hard
disk without software changes. Additional accesses penalize floppies, but
that may not be an issue for Bob. --Patrick
I'm also one of the people that's tinkering with the HP 1000s which are
the target systems.
I think Bob only plans on using this for a hard drive. AFIK there's no
plans to develope a floppy drive systems for these computers (although it
would be nice).
The biggest problem that I see here is that Bob wants to be able to use
this OS on systems that have as little as 16k words but still use LARGE
modern drives. I'm not sure that's practicle without a lot of wasting a lot
of drive space. But I frankly don't think wastage is a problem. There's
simply not a lot of software for this OS and I don't think we'd ever use
more than a tiny fraction of the drive. Therefore my vote ould be for
program size, speed and drive space effientcy in that order.
FWIW A FAT table and MS-DOS file system would be nice for compatibility
but without a floppy drive it would probably be a waste. You COULD put the
drive into a PC and transfer files but I don't think that's likely.
Joe
lot. If you do a linear search for a free block, it
may be that
you can rip
through the 255-valued bytes quickly, but they
have to be in
RAM, so you may
have to do several reads to find what you want,
which saps time.
I wonder if it really would sap a lot of time. Modern IDE drives have
large cache buffers so I would think that system could very
likely read the
data from the buffer. I'm thinking that as slow as these old systems are
and as fast as the modern drives are that it would be better to use a
simple and fast algorithim even if it means more drive accesses.
Joe