RE: SDI a nef diskimage format ?
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 that some games (eg. Parallax or Lemmings) use different formats invented by *cough* yours truly, which the suggested format won't actually be able to support. This includes: 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). Lemmings includes large storage disks (again, one of mine) with (IIRC) a similar scheme for sector address munging. The trick is that it used 5 x 1024 byte sectors followed by 1 x 512 byte sector to fit 11k per track, instead of the usual 10k. I think it may also have written 82 tracks. Not sure though. Any truly generic archive format would have to support such disks. Simon
Re: SDI a nef diskimage format ?
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 generic archive format would have to support such disks. Agreed. I think the only good reason to invent a new diskimage format would be to hold disk geometries which the previous ones couldn't - and I think Simon just identified it. Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- -- Have you lost your Marbles? http://www.marillion.com/
RE: SDI a nef diskimage format ?
--- 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 most software was disk based you`d have to have a copy of whatever disk was in drive 1 too (780K) (in case of extra loading) so snaps could/would be up to nearly 1.3 Megabytes each... Might have it`s uses though, occasionally :) (CKay) in fact mosta the time you probably wouldn`t need a copy of the disk also (but you might not know which software will reload data, or load new data, or need to write to disk...) :) It would be nice... ___ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com
RE: SDI a nef diskimage format ?
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 11k per track, instead of the usual 10k. Mixed sector sizes are covered as part of storing the ID header+data for each sector on the track. It also preserves the sector order from the index hole, which is something Sophistry needs to run in full rather than demo mode. On W2K/XP you can use the new: SamDisk.exe /scan a: to display a sector-level dump of protected disks, including sector order and any mismatched track/head values. It won't let you image those disks just yet, but it's in the pipeline... I think it may also have written 82 tracks. My Lemmings _appears_ to have 83 tracks formatted, but with track 82 an exact copy of track 81 (including headers). It could just be that the drive I used to image it couldn't seek to track 82, but I've got a feeling viewing it on the PC also showed the same. Any truly generic archive format would have to support such disks. 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? Si
RE: SDI a nef diskimage format ?
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 handle both types? As a user I would certainly rather have an archive with a single type of disk. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: MasterBasic Manual Errors Do you know any?
[EMAIL PROTECTED] wrote: Q 2. Any errors in the manual to be included as a page at the end of the pdf? Yes/no I'd say keep as-is for the sake of history, and add an erratum page. Well done for all the hard work, BTW! Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: MasterBasic Manual Errors Do you know any?
Hello folks, MasterBasic pdf version 1 is 50% complete – all text has now been OCRd . Excellent. Another 10 mins ? Keep the it like the original Corrections at the end are fine. Don't know of any mistakes problems so. Q1,Q2=YES, Q3,Q4=NO Edwin
Re: Format returns
Nev Young wrote: [EMAIL PROTECTED] wrote: The best thing would be, if it is possible to reach Mr. Bob, was to see if it was possible to have the original files he used for his typesetting and convert from them. I have no idea what tool he used, but it should be possible to do a bulk conversion some way or the other= . He did it all on a SAM or a BBC Nev I think he used Lotus Amipro in later years. -- Tarquin Mills (Chairman) ACCUS (Anglia Classic Computer Users Society) http://www.speccyverse.me.uk/comp/accus/
Re: SDI a nef diskimage format ?
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 the fancy one that preserves the original. Edwin
Re: SDI a nef diskimage format ?
[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 has TAP for regular format and TZX for the fancy one that preserves the original. I too have used disks with odd formats mainly track 5 having an extra short sector between sector 10 and the index hole. I'll probably get shot down for suggesting this but 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. Nev
RE: SDI a nef diskimage format ?
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[s=1024,t=128] 2[s=1024,t=128] 5[s=1024,t=128] 3[s=1024,t=128] 0:11[s=1024,t=128] 4[s=1024,t=128] 2[s=1024,t=128] 5[s=1024,t=128] 3[s=1024,t=128] SDF also being killed off as a format as soon as we can all decide what to replace it with (falling back on the Russian FDI if there's nothing better). Si
Re[2]: SDI a nef diskimage format ?
For now the header/sector-level scanning seems to be about the best solution, and will cope with all but one SAM disk I've seen so far :-) I'm betting that was another Mr Owen creation ;-) Friday, December 10, 2004, 2:41:26 PM, you wrote: Simon 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. Simon It would indeed, if there was a reliable way to dump them! You'd really Simon need all the sync marks as well as the raw track data, but even reading the Simon raw track data is a problem... Simon Unfortunately, the WD1772-02 controller leaves the address mark detector Simon enabled during the diagnostic tracks reads, meaning certain patterns in the Simon data can cause a false sync. If this happens the controller returns MFM Simon bits instead of data bits from that point on in the track, making what you Simon read essentially useless. I tried this method when writing the original Simon MakeSDF scanner, before spotting the problem and working out what the heck Simon it was doing. Simon The PC controller allows you to read ID field headers and data, but doesn't Simon give access to anything in the gap areas. There is a Disk2FDI program that Simon can do it, but is a commercial program and requires 2 floppy drives. It Simon spins both drives up and starts the read of a high-density disk in drive 1, Simon then switches the drive-select to drive 2, with the controller then Simon returning MFM _and_ data bits for the disk in drive 2. Very clever, but Simon it's DOS-only and wasn't particularly reliable when I tried it a while ago. Simon Another option is to use a Catweasel controller card, which can read just Simon about any disk at very low level. They're not cheap though, and it's not Simon really something most people will have access to for dumping. Simon For now the header/sector-level scanning seems to be about the best Simon solution, and will cope with all but one SAM disk I've seen so far :-) Simon Si
RE: SDI a nef diskimage format ?
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 fakes the raw track data from information it knows about the sectors on the current track, so it looks pretty authentic in programs like SAM DICE. 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 correctly it would know the disk had been copied... not usable on high-volume items, but for the low-volume Sam market, it would have been perfectly do-able :) I do remember reading about one company which used to laser holes in their disks at a specific point to do much the same thing, although I don't think this was on the Sam. On a side track (hah), has anyone else found that all their old Sam disks are completely unreadable? Is it likely that I had a drive that, while being in-spec of the other Sam drives, is out of spec enough so that the average PC drive can't read floppies created by it? Or is it more likely that almost every single one of my disks have simply degraded over time? I spent many many hours trying to get Linux to read my Sam floppies using different FDD parameters before giving up and deciding that it must simply be the disks :( G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SDI a nef diskimage format ?
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 disks with the hole covered - they seemed to work at first, but go bad very quickly. Unless SamDisk2 can skip errors (I haven't got the URL to hand) they will have to stay in the old box for evermore :-( Just add a /e to ignore read errors: SamDisk.exe a: MyImage.dsk /e Or for SAMDOS-compatible disks, do a minimal copy of only the used areas, in the hope the bad sector was not part of an allocated file: SamDisk.exe a: MyImage.dsk /m If the image you made did have one or more bad sectors, open the DSK in Edwin's Diskimage Manager and it'll show you which files were affected (marked as broken IIRC). Btw, the SamDisk URL is: http://www.simonowen.com/sam/samdisk/ Si
