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
Received on Sat Jun 28 1997 - 20:02:11 BST
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:30:31 BST