Sam:
1. Record format: open (depending on software
for EPROM programmer);
S-records, Intel Hex, binary.
> I'm no expert at this so I'll defer.
The various hex records are ASCII representations, so I figured that they can
be transferred with no problem by e-mail. If we're doing ftp, it doesn't
matter
2. Submission & storage: UUEncoded image
file e-mailed to "repository";
ROM/EPROM chips sent by snail mail and
returned. All
submissions should have as much info about the source computer as
possible (board revisions, date of manufacture, etc.)
>Sounds good. The repository then is a
"soft" repository of ROM images?
Yes. This way, we can transfer it, or burn it.
3. Requests & withdrawls: by e-mail to
those with programmers; by mail for
those supplying their own chips; e-mail
request with no chip
sent.
> I assumed since the images are merely files
they could be downloaded by
anyone requesting them. Is the repository also
going to have physical EPROMS
that someone can request? If so, why?
THe only reason to have EPROMs available is for those who are incapable of
burning EPROMs them selves.
4. Cost: nominal (cost of postage and EPROM).
> Is the repository also going to be in the business of supplying people
with pre-burnt EPROMS? If so then 3 makes more sense now.
Sure, why not. I don't think that there will be a huge demand, so the
repository will not keep pre-burned ROMs on hand.
------------------------
Rich Cini/WUGNET
- ClubWin Charter Member (6)
- MCPS Windows 95/Networking