18 May
2005
18 May
'05
11:48 a.m.
On Wed, 2005-05-18 at 12:29 -0500, Randy McLaughlin wrote:
From: "Jules Richardson"
<julesrichardsonuk at yahoo.co.uk>
Sent: Wednesday, May 18, 2005 9:00 AM
;)
Description's one thing, date would be another, plus checksum info I
suppose. Plus for these kinds of things it probably makes sense to store
the name of the person who created the image, and the tool they used to
do so (can be handy to have the latter for times when a release of a
tool is found to be broken)
Plus one ROM archive might be intended to be spread across several
physical chips in some way. I've certainly got ROM images saved from 32-
bit machines where four physical 8-bit chips are accessed in parallel.
For the native machine they're accessed that way; for browsing in a hex
editor or maybe use with an emulator, it'd be handy to have them as a
linear sequence of bytes. Maybe for that reason some essence of the data
organisation also needs to be captured in the image archive...
This is just off the top of my head; there may be other things, or
some/all of these might be wrong. But it does seem to suggest that there
might be more useful stuff to capture in a ROM image file than just a
chunk of raw data and a freeform description...
On Wed, 2005-05-18 at 08:13 -0500, Brian Wheeler
wrote:
<snip>
Personally I think it's achievable, providing
we stick to worrying about
floppies at the moment. Tapes, hard drives, ROM images etc. can come
later - doubtless they'd share some field names, but the structure is
sufficiently* different that it's too much to take on in a first cut.
<snip>
cheers
Jules
For ROM images just a binary (or hex) file is sufficient since there is no
formatting involved.
The only information needed would be a description of what the heck it is.
If we were smart (a long stretch) Papertapes generally come in two flavors: Text or
binary, please note hex
tapes are text files. The leading and trailing nulls should be stripped but
the data should be kept the same i.e hex tapes should stay hex and not
converted to binary. I have seen people store hex data as binary which
strips load address data plus with Intel hex it is possible to load
different segments which gets lost when converted to binary.
Sure - I'm no expert at all on tapes! Possibly there are other things
that'd be usefully captured in a suite of image formats one day - PAL
chips maybe, or even documentation scans. It's not reinventing the wheel
if it actually adds useful stuff over and above what's currently
available of course :-)
cheers
Jules