[sebhc] Disk formats and emulators

[Jack Rubin]

(view from 10,000 feet)

> My goal is simply to make sure that the files are somewhat 
> "self-describing." That is, when you see one, a SIMPLE 
> algorithm can identify them uniquely as H8'ish things. 

amen

 
> Actually, I think the original idea was to make the images 
> easily dumpable on an ascii terminal.  The "Daves'" diskdump 
> program dumps images to the TT:.  The thought, too, was to 
> make them easily mailable.  

kind of a nice legacy from 7-bit modem dialup days, but if binary works
better, why not?

> > (assuming the implementation makes the disk writable).

being able to write back to the image is getting to be a high priority,
since it allows "configuration" of the system to meet various hardware
environments. With more real and virtual machines coming online, this
kind of flexibility will be very useful.

> Yup.  Another one I'm not really worried about.  I'm polluted 
> by the small 100G drive I have sitting on my desk.  

It would make sense that 'chunks' (images) be granular at least at the
file level, and that they could be arbitrarily large (or small) within
the limits of the directory scheme. Then the PC could serve directly as
a host (via something as simple as a 16550 serial connection and
modified HDOS driver) or an IDE hardcard could be used. Code could be
dropped right into the ROM image; Steven reserved a lot of space in
PAM37! ;>)
> 
> > (7) There's no facility in the format to verify data integrity (as  
> > there is in a real disk).

why not full-boat CRC at the file and 'chunk' level?

This is getting good!

Jack

--
Delivered by the SEBHC Mailing List