Apple II disk Grrr.....

All questions regarding the dumping of media go here.
BarryB
Posts: 282
Joined: Thu Aug 02, 2012 8:15 pm

Re: Apple II disk Grrr.....

Post by BarryB » Sun Feb 05, 2017 1:28 pm

Right, so you still need some coding skills and experience on the platform you're scripting for, so a no go for me sadly :(

User avatar
IFW
Posts: 3075
Joined: Mon Nov 08, 2010 2:42 pm

Re: Apple II disk Grrr.....

Post by IFW » Thu Feb 09, 2017 2:20 pm

Programming skills:
- what you'd have for a calculator when creating scripts, ie not much. Although, admittedly, that depends on the calculator ;)
- platform experience, yes - there is no way around that. You can't possibly describe how to decode something if you do not understand what it is.

BarryB
Posts: 282
Joined: Thu Aug 02, 2012 8:15 pm

Re: Apple II disk Grrr.....

Post by BarryB » Mon Feb 13, 2017 1:22 pm

Absolutely counts me out then :)

Going back to Apple II dumps, I've just obtained another infocom title, Sorcerer, have dumped like I would C64:

dtc -p -b-8 -fSorcerer(US)[AppleII]/Sorcerer[AppleII](1of1)_ -i0 -y -g2 -i8 -l8

Does that look correct knowing it probably has some form of copy protection?

The dump produced this output:

Code: Select all

KryoFlux DiskTool Console, v2.51_Win64, uiv.1, Oct 29 2014, 16:45:36
(c) 2009-2014 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society, www.softpres.org
Licensed for private, non-commercial use only.

-8.1[00]: Apple DOS 3.3: <unformatted>
-6.1[02]: Apple DOS 3.3: <unformatted>
-4.1[04]: Apple DOS 3.3: <unformatted>
-2.1[06]: Apple DOS 3.3: <unformatted>
00.0    : Control command rejected by the device
00.0    : Apple DOS 3.3: OK, trk: 000, sec: 16
00.1[08]: Apple DOS 3.3: <unformatted>
02.0    : Apple DOS 3.3: <unformatted>
02.1[10]: Apple DOS 3.3: <unformatted>
04.0    : Apple DOS 3.3: <error>, trk: 002, sec: 16, mis: 12
04.1[12]: Apple DOS 3.3: <unformatted>
06.0    : Apple DOS 3.3: <unformatted>
06.1[14]: Apple DOS 3.3: <unformatted>
08.0    : Apple DOS 3.3: <unformatted>
08.1[16]: Apple DOS 3.3: <unformatted>
10.0    : Apple DOS 3.3: <unformatted>
10.1[18]: Apple DOS 3.3: <unformatted>
12.0    : Apple DOS 3.3: <unformatted>
12.1[20]: Apple DOS 3.3: <unformatted>
14.0    : Apple DOS 3.3: <unformatted>
14.1[22]: Apple DOS 3.3: <unformatted>
16.0    : Apple DOS 3.3: <unformatted>
16.1[24]: Apple DOS 3.3: <unformatted>
18.0    : Apple DOS 3.3: <unformatted>
18.1[26]: Apple DOS 3.3: <unformatted>
20.0    : Apple DOS 3.3: <unformatted>
20.1[28]: Apple DOS 3.3: <unformatted>
22.0    : Apple DOS 3.3: <unformatted>
22.1[30]: Apple DOS 3.3: <unformatted>
24.0    : Apple DOS 3.3: <unformatted>
24.1[32]: Apple DOS 3.3: <unformatted>
26.0    : Apple DOS 3.3: <unformatted>
26.1[34]: Apple DOS 3.3: <unformatted>
28.0    : Apple DOS 3.3: <unformatted>
28.1[36]: Apple DOS 3.3: <unformatted>
30.0    : Apple DOS 3.3: <unformatted>
30.1[38]: Apple DOS 3.3: <unformatted>
32.0    : Apple DOS 3.3: <unformatted>
32.1[40]: Apple DOS 3.3: <unformatted>
34.0    : Apple DOS 3.3: <unformatted>
34.1[42]: Apple DOS 3.3: <unformatted>
36.0    : Apple DOS 3.3: <unformatted>
36.1[44]: Apple DOS 3.3: <unformatted>
38.0    : Apple DOS 3.3: <unformatted>
38.1[46]: Apple DOS 3.3: <unformatted>
40.0    : Apple DOS 3.3: <unformatted>
40.1[48]: Apple DOS 3.3: <unformatted>
42.0    : Apple DOS 3.3: <unformatted>
42.1[50]: Apple DOS 3.3: <unformatted>
44.0    : Apple DOS 3.3: <unformatted>
44.1[52]: Apple DOS 3.3: <unformatted>
46.0    : Apple DOS 3.3: <unformatted>
46.1[54]: Apple DOS 3.3: <unformatted>
48.0    : Apple DOS 3.3: <unformatted>
48.1[56]: Apple DOS 3.3: <unformatted>
50.0    : Apple DOS 3.3: <unformatted>
50.1[58]: Apple DOS 3.3: <unformatted>
52.0    : Apple DOS 3.3: <unformatted>
52.1[60]: Apple DOS 3.3: <unformatted>
54.0    : Apple DOS 3.3: <unformatted>
54.1[62]: Apple DOS 3.3: <unformatted>
56.0    : Apple DOS 3.3: <unformatted>
56.1[64]: Apple DOS 3.3: <unformatted>
58.0    : Apple DOS 3.3: <unformatted>
58.1[66]: Apple DOS 3.3: <unformatted>
60.0    : Apple DOS 3.3: <unformatted>
60.1[68]: Apple DOS 3.3: <unformatted>
62.0    : Apple DOS 3.3: OK, trk: 031, sec: 16
62.1[70]: Apple DOS 3.3: <unformatted>
64.0    : Apple DOS 3.3: OK, trk: 032, sec: 16
64.1[72]: Apple DOS 3.3: <unformatted>
66.0    : Apple DOS 3.3: OK, trk: 033, sec: 16
66.1[74]: Apple DOS 3.3: <unformatted>
68.0    : Apple DOS 3.3: OK, trk: 034, sec: 16
68.1[76]: Apple DOS 3.3: <unformatted>
70.0    : Apple DOS 3.3: <unformatted>
70.1[78]: Apple DOS 3.3: <unformatted>
72.0    : Apple DOS 3.3: <unformatted>
72.1[80]: Apple DOS 3.3: <unformatted>
74.0    : Apple DOS 3.3: <unformatted>
74.1[82]: Apple DOS 3.3: <unformatted>
76.0    : Apple DOS 3.3: <unformatted>
78.0    : Apple DOS 3.3: <unformatted>
80.0    : Apple DOS 3.3: <unformatted>
82.0    : Apple DOS 3.3: <unformatted>

Enjoy your shiny new disk image!
Please consider helping us to preserve media and continue development:
www.softpres.org/donate

spags
Posts: 90
Joined: Sun Sep 09, 2012 5:46 am
Location: Australia

Re: Apple II disk Grrr.....

Post by spags » Wed Feb 15, 2017 12:54 pm

Well according to that same article I linked to further above, a lot of the Infocom titles used almost the same types of copy protection schemes (or more correctly, the same cracking scheme could be used on multiple titles). So with the caveat that I haven't dumped any such copy protected Apple // files, then my tentative answer to your question is, "maybe". It does look similar to your first dump (first track okay, then nothing for a long while).

BarryB
Posts: 282
Joined: Thu Aug 02, 2012 8:15 pm

Re: Apple II disk Grrr.....

Post by BarryB » Wed Feb 15, 2017 2:26 pm

It's format guided so I guess the 'protected' tracks are not seen as DOS 3.3 so they show as unformatted, just like Amiga disks when they use custom formats and I speciy -i5, all those tracks show as unformatted.

The copy protection, as stated in that article, was just changing the start of data bytes from D5 AA AD to D5 AA BC so it's not standard DOs 3.3 anymore and probably why it shows unformatted, the fact the unprotected tracks are identified suggests the dump is correct.

rcade
Posts: 98
Joined: Mon Nov 21, 2011 5:21 pm

Re: Apple II disk Grrr.....

Post by rcade » Sat Feb 03, 2018 9:54 pm

I am imaging a large batch of original Apple II SSI disks. All tracks show as unformatted on all these disks, so really nothing I can do except raw dumps at this point. I tested they were Apple II- they boot fine in my GS. I can also take a normal DOS 3.3 disk and DTC will see that, so I guess that's just how it is for now... We need an A2 emulator that will load CTRAW images. :)
-
Pete Rittwage
C64 Preservation Project
http://c64preservation.com

Rakki
Posts: 690
Joined: Fri Jun 03, 2011 8:29 pm
Location: Jyväskylä, Finland

Re: Apple II disk Grrr.....

Post by Rakki » Sat Feb 03, 2018 10:13 pm

Cannot test right now but for Apple II please try dd0 / dd1 (drive density line) parameter. If the disk is not professionally dupilicated then also x-parameter (cell band search) might be good idea (see more from Kryoflux manual, page 28).

Panasonic:

Code: Select all

dtc -dd1 -p -b-8 -f"TitleName/TitleName_" -i0 -g2 -y -i8 -l8 -t10
With -x0 (DOS 3.3 disks?)

Code: Select all

dtc -dd1 -p -b-8 -f"TitleName/TitleName_" -x0 -i0 -g2 -y -i8 -l8 -t10
C64 Newtronics / Teac:

Code: Select all

dtc -dd0 -p -a8 -f"TitleName/TitleName_" -i0 -g2 -y -i8 -l8 -t10
With -x0 (DOS 3.3 disks?)

Code: Select all

dtc -dd0 -p -a8 -f"TitleName/TitleName_" -x0 -i0 -g2 -y -i8 -l8 -t10
All Apple II dumps are now valuable in order to build up better support for them. Some disks might show only unformatted because there's no profile for the format (similar case like Rapidlok for C64).
Last edited by Rakki on Sat Feb 03, 2018 10:22 pm, edited 4 times in total.

User avatar
IFW
Posts: 3075
Joined: Mon Nov 08, 2010 2:42 pm

Re: Apple II disk Grrr.....

Post by IFW » Sat Feb 03, 2018 10:14 pm

Actually, this is wheregraphs (specifically the green/red bars at the bottom) can help a lot.
You can see if the dump contains inconsistent data, even if it's not decoded.
What you cannot see though if the data is consistently bad... ie always reads the same, but it's all bad would show as consistent (green). If bad data is caused by dirty disk or other similar things though it's likely to cause a different artefact like outliers which are shown anyway (the vertical coloured lines).
Decoded data would show that the disk is bad, so we could retry.
I'd say we should check each dump for consistency and if there is any doubt just make another raw dump for now.

rcade
Posts: 98
Joined: Mon Nov 21, 2011 5:21 pm

Re: Apple II disk Grrr.....

Post by rcade » Sat Feb 03, 2018 11:50 pm

I'll have a bunch for you tonight...
-
Pete Rittwage
C64 Preservation Project
http://c64preservation.com

Rakki
Posts: 690
Joined: Fri Jun 03, 2011 8:29 pm
Location: Jyväskylä, Finland

Re: Apple II disk Grrr.....

Post by Rakki » Sun Feb 04, 2018 11:01 pm

Thanks. Some of those A2 disks do need cleaning based on graphs. Photos + info files are also missing? Checked few through and at least these may need cleaning and redumping. Anyways dumps are very good material in order to create user defined formats for A2 (ie. decoding for RAW data).
  • Baltic 1985 (track 00.0)
  • Battlegroup (band bleeding on multiple tracks like 6.0, 6.1, 8.0, 8.1, 10.0, 12.1, 14.1 and 32.1)
  • Bomb Alley (especially beginning of the disk needs cleaning because there's some noise)
  • Shard of Spring (whole disk, band bleeding?)
Bomb Alley looks quite interesting - there's clearly half tracks in use. For example track 35.0 and 37.0 and many others (full of noise + then data between).

Post Reply