On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote:
> attempted to format a track I knew would fail - if it formatted
> correctly it would know the disk had been copied...
Wouldn't this be defeated by write-protecting the disk?
Andrew
--
---Andrew Collier
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote:
> attempted to format a track I knew would fail - if it formatted
> correctly it would know the disk had been copied...
Wouldn't this be defeated by write-protecting the disk?
Andrew
--
---Andrew Collier
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote:
> One of the ways I was going to do protection (if I'd ever got round to it)
> was buying a load of really crappy disks and writing code specific for each
> disk that attempted to format a track I knew would fail - if it formatted
> co
Geoff Winkless wrote:
> Why not a tagged format and tools which can handle both types?
I've been fleshing out the details of a potential new format to efficiently
represent any SAM disk type. It uses your suggested tagged structure, some
of the tag types I mentioned recently, and Edwin's fragment
Frans van Egmond wrote:
> If one of you programming people need a Catweasel, I have a
> spare Catweasel MK3 lying around that I'd be happy to loan
It's probably best to avoid too much reliance on unusual hardware to create
images, as it's unlikely all disks we'd want scanning would be owned by
so
If one of you programming people need a Catweasel, I have a spare
Catweasel MK3 lying around that I'd be happy to loan to you for the
duration of this project if it does the community any good :-)
Frans
Simon Owen wrote:
Nev Young wrote:
why not create an image that is a full t
Simon:
> Good, bad or ugly?
Sounds OK.
Some things I thought up for 'PC' minded format:
Have a format that consists only of track fragments (sectors). Each fragment
had a 6 byte header folowed by at least 4 bytes data. So the smallest
fragment was 10 bytes and largers 1024 (length/4-4 in one b
My two penneth of the disk format discussion:
I like the idea of a new, all-encompassing disk format for the
samcoupe.org archive (SCOA anyone?) as it will bring together many
disparate formats DSK/SDF/SAD etc. into one, but it has to be able to
hold the full geometry of the disk.
After all
Simon Owen wrote:
Does the archive need to be a single format for all disks? Or could the 95%
of normal format disks be kept in a simple dumped image format, with only
protected disks using a different format needed to describe them correctly?
I think yes, the idea of tagging extra data into
Geoff Winkless wrote:
On a side track (hah), has anyone else found that all their old Sam disks
are completely unreadable?
None comepletly unreadable, many with errors which ment I couldn't make
a DSK of them at the time.
Unless SamDisk2 can skip errors (I haven't got the URL to hand) they
Nev Young wrote:
> why not create an image that is a full track image from index
> hole to index hole including all the inter sector guff. That
> should cover just about everything.
It would indeed, if there was a reliable way to dump them! You'd really
need all the sync marks as well as the raw
Hi, is there a format for SimCoupe similar to Sinclair Spectrum Z80/Sna
format ?
Regards,
Dumitru Florin Gabriel ( Zecut0r ).
Geoff Winkless wrote:
> Why not a tagged format and tools which can handle both types?
If a new image format is going to be created out of all of this, it would
certainly make sense to be flexible enough for both uses. A tagged format
would be easy to process and nicely extensible too.
Beyond a
Andy Chandler wrote:
> > will cope with all but one SAM disk I've seen so far :-)
>
> I'm betting that was another Mr Owen creation ;-)
It's actually Chris Pile's original Defender disk, which does some gap-level
checking as part of the copy protection. The gap information isn't stored
as part o
Dan Dooré wrote:
> None comepletly unreadable, many with errors which ment I
> couldn't make a DSK of them at the time.
I only found the odd error too, and sometimes they'd be readable in a
different drive. The only problems I've had recently is when I made the
mistake of using high-density disk
Simon Owen wrote:
> It's actually Chris Pile's original Defender disk, which does some
> gap-level checking as part of the copy protection. The gap
> information isn't stored as part of the disk image, as it's almost
> never needed, and would more than double the image size. SimCoupe
> actually f
Dan Dooré wrote:
> (or SDF V1.1 with Freaky Cookie Malarky mode enabled).
SDF has always handled the Freaky Cookie Malarky, so no need for an update!
Here's a dump of the first 2 tracks of my Parallax.sdf file, showing the
faked track=128 and mixed sector sizes that Cookie mentioned:
0:01 4[
[EMAIL PROTECTED] wrote:
> Simon:
> > Does the archive need to be a single format for all disks? Or could the
> 95%
> > of normal format disks be kept in a simple dumped image format, with only
> > protected disks using a different format needed to describe them
> correctly?
>
> Just Like speccy
Simon:
> Does the archive need to be a single format for all disks? Or could the
95%
> of normal format disks be kept in a simple dumped image format, with only
> protected disks using a different format needed to describe them
correctly?
Just Like speccy has TAP for regular format and TZX for th
Simon Owen wrote:
> Does the archive need to be a single format for all disks? Or could
> the 95% of normal format disks be kept in a simple dumped image
> format, with only protected disks using a different format needed to
> describe them correctly?
Why not a tagged format and tools which can
Simon Cooke wrote:
> Sector addresses which do not directly correspond to their
> real location on disk
SDF stores the ID fields for each sector, so faked track/head values and
non-standard sector numbers are no problem.
> it used 5 x 1024 byte sectors followed by 1 x 512 byte sector
> to fit 1
--- Z80 <[EMAIL PROTECTED]> wrote:
>
> Hi, is there a format for SimCoupe similar to
> Sinclair Spectrum Z80/Sna
> format ?
>
> Regards,
>
> Dumitru Florin Gabriel ( Zecut0r ).
>
>
>
Not that I`ve seen... if there was it`d have to be
either 256K or in a lot of cases 512K big, plus seen
as
On Dec 9, 2004, at 11:13 pm, Simon Cooke wrote:
Sector addresses which do not directly correspond to their real
location on
disk - eg. on track 4 you'd have a sector which had a sector ID of 10,
and a
track id of 255.
(This happens in the Parallax copy protection).
ooh, sneaky!
Any truly g
Dan Dooré wrote:
> I like the idea of a new, all-encompassing disk format for
> the samcoupe.org archive (SCOA anyone?) as it will bring
> together many disparate formats DSK/SDF/SAD etc. into one,
> but it has to be able to hold the full geometry of the disk.
One thing to remember though is t
> almost certainly just uncompress the image into a record anyway, so the
> reduction in file size would seem inconsequential.
Thats gonna change :-)
Edwin
On Thu, 2004-12-09 at 15:15, Edwin Blink wrote:
> From: Andrew Collier <[EMAIL PROTECTED]>
>
> > But surely this geometry information needs to be changable on a
> > per-track basis? Protected disks could have different geometries on each
> > track,
>
> This format is not for protected disks. I th
From: Andrew Collier <[EMAIL PROTECTED]>
> But surely this geometry information needs to be changable on a
> per-track basis? Protected disks could have different geometries on each
> track,
This format is not for protected disks. I think SDF and FDI cover that quite
well.
Besides that it is Als
On Thu, 2004-12-09 at 13:24, Edwin Blink wrote:
> [2] disk geometry:
> bit 7 = sides: 0 for single sided 1 for double sided
> bits 6-0 = tracks 1 to 127 tracks
> bit 15= start sector: 0 start with 0, 1 start with 1
> bits 14,13 = sector size: 00 128 byte sectors
>
On 9 Dec 2004, at 1:24 pm, Edwin Blink wrote:
I gave it some thoughts and here's what I've come up with.
The Idea is to make it possible to handle it on a real SAM using
CD-ROM and CF in the future.
--
SDI or Sam DiskImage is
29 matches
Mail list logo
