Joe wrote:
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
Actually, the DOS code will support:
HP 7900A, CS/80, and my ATA disk hack at first. MAC support could be
developed, but I know of no
operational hardware available for development. Having redone the ATA
hack in 5 chips, I have no desire
for any HP drives other than CS/80.
I would love to support the HP 9885M floppy disk, I have the hardware,
but very limited and incomplete
programming information. I will take another stab at programming this
beast, as I've found that it can format
totally blank media after all.
In terms of memory, file system access is going to require 32K words of
memory, and there is a very real
possibility that DMS (HP 21MX only) will be required. It might be
possible to really trim down the dictionary
and run DOS functions in less than 32K, but it would not be very practical.
The reason for this, is that using DMS we can read an ABS program like
HP BASIC or HP ALGOL into
virtual memory, then swap those pages into the SYSTEM map from 0 to 31K
words with the top 1K used
for a block swapping loader, so when HP BASIC terminates your right back
inside your running IPL program.
This was IPL programs can load and run existing HP software under
program control, being a 'real' O/S.
This actually takes a lot less code than conventional disk swapping, and
its vastly faster too. It makes very good
use of HP's DMS architecture.