[LocalH]

Well, if they used DPaint on an Amiga, then the disk is a standard format and I can easily dump it with DMS, which covers all 80 tracks, and not just where the directory indicates data is stored. The only extra thing you'd be able to pull off would be files that had got deleted and not written over yet, as Jim said. With a standard unprotected disk, DMS will accurately represent the contents of the disk, such that it could easily be written to a different disk and be pretty much identical to the original disk. Actually, that'll be my first plan of action - make a backup disk using XCopy for my own personal software archive (I'd really, really like to keep the original disks but I doubt Tom wants to let go of them =P)

Seriously, as I said, I have an Amiga sitting right here, and I can easily make DMS images (barring any read errors on the disks). Just get the disks to me, and if they are indeed standard Amiga disks without protection (I am 100% sure that if they are indeed Amiga disks, then they are unprotected), then I'll DMS the disk, and distribute the images completely unmodified. I'll also dig up some Amiga disk tools (DiskSalv was my favorite back in the day) and investigate to see if there are any deleted files that can be recovered (the chance is high - on a semi-unrelated note, it's a well known fact that early Kickstart disks have some deleted development files on them).

Get me the disks. Unless they're not Amiga, I will make DMS images of the disks available. I've never used Disk2FDI, but that's quite overkill if these are standard disks (and I can't imagine them using DPaint with non-standard disks). I know other systems did have a port of DPaint (including, IIRC, the PC, Apple IIgs, and Atari ST), but the Amiga was most known for being the best machine to run DPaint on. And, if they did use DPaint, then the files should be standard format - either IFF ILBM images, standard DPaint brushes, or ANIM5. It'd be especially interesting if they used DPaint's animbrush feature to test how a sprite would look while animated - it's a breeze to create a simple mockup in DPaint using the automatic Move function with an animbrush.

This post has been edited by LocalH: 27 May 2005 - 12:21 PM

[ICEknight]

LocalH, on May 27 2005, 12:18 PM, said:

it's a breeze to create a simple mockup in DPaint using the automatic Move function with an animbrush.

Well, yeah, that's what they used for their mockups. They had access to all the available art and took whatever they wanted.

As for the disks, the Disk2FDI method seems quite easy to pull, so I'll tell him about it before trying anything else.

[LocalH]

Any word on this yet? I really want to look at these disks, even if I'm not the one who dumps them. This is historical data (to us), just like the prototype ROM.

Also, I was a bit off when I said Disk2FDI was 'overkill' - I was assuming it to be a 'raw' dumping tool, similar to the CAPS tool mentioned earlier. I wasn't aware that it output standard ADF images.

I can't wait to check out these disks - how many are there? Each disk can hold up to 880K in standard AmigaDOS format (901120 bytes per ADF), so there should be plenty of good stuff to examine.

[Qjimbo]

Yeah I'm equally bursting to see these disks :P It's funny because there's a tool to dump acorn ADFS 1.6MB and 800K disks from DOS, wonder why a similar thing can't be done for the amiga.

[LocalH]

Well, that's basically what Disk2FDI is - the trouble is, to get it to read the disk in a 'raw' form, you have to use two drives, because the software basically begins writing to one of the drives (which you place a dummy disk into), and then forces the controller to switch to the other drive and begin reading. From "rawflopy.doc" (included within Disk2FDI):

Quote

This algorithm requires two disk drives installed (read the 1DISKDRV.TXT file to get an explanation why reading raw data generally with only 1 disk drive is physically impossible).
Insert the disk you want to fully read in one drive (let’s say A: in this example).
Insert another disk in the other drive (B: in this example). This disk must be IBM-formatted.

Select drive A: using port 3F2h. Also turn on motors for both A: and B:.
Go to the desired track and side using standard FDC 765 commands.
Swap to B: using port 3F2h.
Select density appropriate for IBM-formatted disk in B: using port 3F7h.
Issue a “Read a Track (Diagnostic)” command using the FDC 765. The parameters should match a sector that is physically present on the IBM-formatted disk, for example sector #1. For this command, set a sector size of at least 8KB (even if the physical sector is 512 bytes long). 16KB and 32KB sector sizes can be set to read more raw data. DMA registers should have been set accordingly.
Watch continuously the DMA address until it is different from the starting address. When it is so, it means that the 765 has begun transferring sector data, so it has previously found the sector header on B:.
As soon as the DMA address is increased, swap to A: using port 3F2h. This is the main idea behind this technique. The 765 has no way to know disk selection has changed because port 3F2h is not linked to it. This 1st step was discovered on the 11th of December, 1999.
Change density (bit rate) using port 3F7h. For a full track read, including MFM synchronization bits, you must set a bit rate twice the standard value. For example, when reading a 250 000 bits/sec track (double-density track), set the bit rate to 500 000 bits/sec. This 2nd step was discovered on the 18th of December, 1999.

The FDC 765 will now read the disk in drive A: from now on, thinking it is a big sector on disk in drive B:.

ICEknight, since the Disk2FDI process involves writing to a disk, you MUST make Mr. Payne aware that he should write-protect his original disks, just in case.

This post has been edited by LocalH: 31 May 2005 - 12:57 PM

[ICEknight]

LocalH, on May 31 2005, 12:56 PM, said:

ICEknight, since the Disk2FDI process involves writing to a disk, you MUST make Mr. Payne aware that he should write-protect his original disks, just in case.

Heheheh, "Mr. Payne". :D

Well, I think he was actually the one who said about making sure to copy protect the disks before dumping the contents, so I guess he already has some idea about these computer thingies.

I haven't had much time to contact him yet, and anyway I'm not sure if he's at home already... Maybe this weekend.



So anyway, will this ADF include the deleted sectors or just the normal files?

[LocalH]

ADFs generally include all 80 tracks (although you can create partial ADFs, they're more useful if you're working on a bog-standard A500, without enough storage to hold a whole 880KB image). It's a disk image, so it will hold everything. It should be a fairly simple matter to run something like DiskSalv on the disks and recover what's left of any deleted files (I've successfully done the same with Kickstart 1.0 disk images, which contain some of the same development files that are on the 27.5 "Workbench" disk, as well as a tiny snippet of the then-current OS source code).

Regardless how you get the disks dumped, if you want me to, I can convert them from ADF to compressed DMS (which has much better support on the Amiga, and is directly supported in read-only with WinUAE). I recommend either doing that, or zipping the ADF and renaming it to an extension of ADZ (which are also directly supported in read-only with WinUAE). If there are a lot of truly empty sectors, or highly-compressible data, then the DMS/ADZ will be MUCH smaller than the uncompressed ADF (which will always be 901120 bytes for a standard AmigaDOS disk).

This post has been edited by LocalH: 31 May 2005 - 06:18 PM

[the spindash]

Jayenkai, on May 26 2005, 10:10 AM, said:

I think Amiga is definately our friend, here..

As I don't have any technical knowledge to add on this very interesting topic, I'll put here an interesting fact, much like a "did you know" thing, base on what Jayenkai said.

Amiga is similar to "Amigo". Both mean "Friend" in portuguese.

[/did you know?]

[LocalH]

Yes, I knew that (Spanish as well, as I learned in school). I believe that's where the designers got the name from, IIRC.

[ICEknight]

the_spindash, on May 31 2005, 07:22 PM, said:

Amiga is similar to "Amigo". Both mean "Friend" in portuguese.

And that's how you say "female friend" in Spanish. There were many jokes about it back then, over here. =P



By the way, I just sent Tom the program and the frontend for easier use.