Jump to content
phaeron

a8rawconv, a new raw disk conversion utility

Recommended Posts

21 hours ago, Farb said:

FYI, it seems like the -r option is not working properly anymore in 0.94. It's showing Kryo B sides as blank.

Are you invoking a8rawconv with track00.1.raw? I don't have a flippy disk or drive to test, but I think what's happening is that with the new side support it's overriding the side number in the filename back to 0. Try renaming one of the files or doing a double-sided decode (-g 40,2).

Share this post


Link to post
Share on other sites
15 hours ago, phaeron said:

Are you invoking a8rawconv with track00.1.raw?

Yes, I was using -r and pointing at track00.1.raw.

 

15 hours ago, phaeron said:

I don't have a flippy disk or drive to test

Here is one you can test with: https://drive.google.com/file/d/1Y6e5_Ka_l_x_5G-ickOhHLy__nvlBMAK/view?usp=sharing

15 hours ago, phaeron said:

Try renaming one of the files or doing a double-sided decode (-g 40,2).

I tried the -g option but I'm still not sure how I create an ATX/ATR of side 2?

Share this post


Link to post
Share on other sites
4 hours ago, Farb said:

Yes, I was using -r and pointing at track00.1.raw.

OK, I've confirmed this is what's causing the problem. Since a8rawconv is now side aware, it's now also parsing the side number in that filename and modifying it, so it actually sees this as side 2 instead of thinking it's side 1. I'll need to add logic for it to detect the non-zero start, but for now, you'll need to rename the side 2 files as side 1 (track_NN.1.raw -> track_NN.0.raw) to do the side-2-as-side-1 decoding process you're trying to do here.

 

Share this post


Link to post
Share on other sites
On 8/16/2020 at 11:22 AM, phaeron said:

 

  • New decoded format support: Atari XFD (read/write), Apple II 5.25" ProDOS order (read/write), Apple II / Mac 3.5" 400/800K DSK (write only), PC 160K-1.44M VFD/FLP (write only), Amiga 880K ADF (write only).

Thank you. I can finally confirm that I have been able to image a PRODOS disk, and compared the final converted disk with the original file, and they are exactly the same. I will post this method on some Apple II forums, as it is an easy way to backup non copyprotected disks, without needing an Apple II, and a greaseweazel assembled device cost me less than $AUD30.

 

Method:

 

1. Transferred a downloaded PRODOS DSK image using ADTPro from my Windows PC to my Apple iic. Wrote the disk using the Apple iic drive

2. Used a Greaseweazle device connected to a 1.2Mb 5.25 HD disk drive on my Windows PC

command line used: gw.exe read --double-step --revs=14 --ecyl=35 --single-sided --rate=250 --rpm=300 "C:\gw\mydiskgreen.scp"

I read the disk 14 times, as there was a persistent error in one sector, and this finally yielded a good result

3. Used your program: a8rawconv.exe -d auto mydiskgreen.scp mydiskgreen.dsk

4. Binary compare of the original DSK file and the final file identical.

 

So the image was transferred from INTERNET -> WINDOWS PC -> APPLE IIC -> FLOPPY DISK -> WINDOWS PC, and is identical.

 

log:

C:\gw\a8>a8rawconv.exe -d auto mydiskgreen.scp mydiskgreen.dsk
A8 raw disk conversion utility v0.94
Copyright (C) 2014-2020 Avery Lee, All Rights Reserved.
Licensed under GNU General Public License, version 2 or later.

Reading SuperCard Pro image: mydiskgreen.scp
1 invalid GCR bytes encountered
1 invalid GCR bytes encountered
2 invalid GCR bytes encountered
1 invalid GCR bytes encountered
1 invalid GCR bytes encountered
1 invalid GCR bytes encountered
1 invalid GCR bytes encountered
1 invalid GCR bytes encountered
1 invalid GCR bytes encountered
Writing Apple II disk image (DOS 3.3 ordering): mydiskgreen.dsk
WARNING: Track  0, sector 15: 1/14 bad sector reads discarded at position 0.36.
WARNING: Track  0, sector 10: 2/14 bad sector reads discarded at position 0.05.
WARNING: Track  0, sector  8: 1/14 bad sector reads discarded at position 0.93.
WARNING: Track  0, sector  1: 4/14 bad sector reads discarded at position 0.50.
WARNING: Track  1, sector  0: 3/14 bad sector reads discarded at position 0.66.
WARNING: Track  1, sector 15: 4/14 bad sector reads discarded at position 0.58.
WARNING: Track  1, sector 14: 4/14 bad sector reads discarded at position 0.51.
WARNING: Track  1, sector 13: 5/14 bad sector reads discarded at position 0.45.
WARNING: Track  1, sector 10: 2/14 bad sector reads discarded at position 0.27.
WARNING: Track  1, sector  9: 6/14 bad sector reads discarded at position 0.21.
WARNING: Track  1, sector  3: 13/14 bad sector reads discarded at position 0.85.
WARNING: Track  1, sector  2: 1/14 bad sector reads discarded at position 0.78.
WARNING: Track  1, sector  1: 2/14 bad sector reads discarded at position 0.72.
WARNING: Track  2, sector  0: 2/14 bad sector reads discarded at position 0.88.
WARNING: Track  2, sector 13: 1/14 bad sector reads discarded at position 0.67.
WARNING: Track  2, sector  7: 5/14 bad sector reads discarded at position 0.31.
WARNING: Track  2, sector  5: 7/14 bad sector reads discarded at position 0.19.
WARNING: Track  3, sector  0: 3/14 bad sector reads discarded at position 0.10.
WARNING: Track  3, sector 13: 6/14 bad sector reads discarded at position 0.89.
WARNING: Track  3, sector 12: 1/14 bad sector reads discarded at position 0.83.
WARNING: Track  3, sector 11: 8/14 bad sector reads discarded at position 0.77.
WARNING: Track  3, sector  9: 2/14 bad sector reads discarded at position 0.65.
WARNING: Track  3, sector  7: 4/14 bad sector reads discarded at position 0.53.
WARNING: Track  3, sector  2: 5/14 bad sector reads discarded at position 0.22.
WARNING: Track  3, sector  1: 3/14 bad sector reads discarded at position 0.16.
WARNING: Track  4, sector  0: 1/14 bad sector reads discarded at position 0.32.
WARNING: Track  4, sector 14: 2/14 bad sector reads discarded at position 0.17.
WARNING: Track  4, sector 12: 2/14 bad sector reads discarded at position 0.05.
WARNING: Track  4, sector  7: 7/14 bad sector reads discarded at position 0.75.
WARNING: Track  4, sector  5: 1/14 bad sector reads discarded at position 0.63.
WARNING: Track  4, sector  2: 8/14 bad sector reads discarded at position 0.44.
WARNING: Track  5, sector 15: 3/14 bad sector reads discarded at position 0.45.
WARNING: Track  5, sector  9: 2/14 bad sector reads discarded at position 0.09.
WARNING: Track  6, sector 11: 12/14 bad sector reads discarded at position 0.43.
WARNING: Track  6, sector  8: 1/14 bad sector reads discarded at position 0.25.
WARNING: Track  6, sector  1: 3/14 bad sector reads discarded at position 0.82.
WARNING: Track  7, sector 10: 2/14 bad sector reads discarded at position 0.59.
WARNING: Track  7, sector  9: 1/14 bad sector reads discarded at position 0.53.
WARNING: Track  7, sector  2: 3/14 bad sector reads discarded at position 0.10.
WARNING: Track  8, sector  4: 3/14 bad sector reads discarded at position 0.44.
WARNING: Track  8, sector  1: 3/14 bad sector reads discarded at position 0.26.
WARNING: Track  9, sector 12: 2/14 bad sector reads discarded at position 0.15.
WARNING: Track 10, sector  0: 4/14 bad sector reads discarded at position 0.64.
WARNING: Track 10, sector  6: 3/14 bad sector reads discarded at position 0.01.
WARNING: Track 10, sector  5: 1/13 bad sector reads discarded at position 0.95.
WARNING: Track 11, sector  5: 1/14 bad sector reads discarded at position 0.16.
WARNING: Track 32, sector  1: 7/14 bad sector reads discarded at position 0.53.
0 missing sectors, 0 sectors with errors

 

Share this post


Link to post
Share on other sites
11 hours ago, pksw said:

1. Transferred a downloaded PRODOS DSK image using ADTPro from my Windows PC to my Apple iic. Wrote the disk using the Apple iic drive

2. Used a Greaseweazle device connected to a 1.2Mb 5.25 HD disk drive on my Windows PC

command line used: gw.exe read --double-step --revs=14 --ecyl=35 --single-sided --rate=250 --rpm=300 "C:\gw\mydiskgreen.scp"

I read the disk 14 times, as there was a persistent error in one sector, and this finally yielded a good result

Would you be willing to share the SCP image? This is actually a pretty bad read, and one you shouldn't have gotten from a freshly written disk unless the disk medium was already falling apart. Apple II 5.25" GCR is pretty low density -- 4-12us between flux transitions, compared to 4-8us for FM/MFM -- so it doesn't have high demands on the disk.

 

Share this post


Link to post
Share on other sites

I think it was probably bad media. Used a fresh disk, and downloaded "Where in the World is Carmen Sandiego" from the apple ii asimov FTP repository, then read it back using my PC.

 

You are welcome to SCPs, links to the original DSK images - let me know whatever you need - I can't thank you enough for your utility.

 

Here's the log:

C:\gw\a8>a8rawconv.exe -d auto carmen2.scp carmen2.dsk
A8 raw disk conversion utility v0.94
Copyright (C) 2014-2020 Avery Lee, All Rights Reserved.
Licensed under GNU General Public License, version 2 or later.

Reading SuperCard Pro image: carmen2.scp
Writing Apple II disk image (DOS 3.3 ordering): carmen2.dsk
WARNING: Track  0, sector 12: 1/14 bad sector reads discarded at position 0.06.
WARNING: Track  0, sector  4: 1/14 bad sector reads discarded at position 0.57.
WARNING: Track  0, sector  3: 2/14 bad sector reads discarded at position 0.51.
WARNING: Track  1, sector 13: 1/14 bad sector reads discarded at position 0.34.
WARNING: Track  1, sector  6: 4/14 bad sector reads discarded at position 0.92.
WARNING: Track  1, sector  3: 5/14 bad sector reads discarded at position 0.73.
WARNING: Track  2, sector 14: 2/14 bad sector reads discarded at position 0.62.
WARNING: Track  2, sector  7: 5/14 bad sector reads discarded at position 0.20.
WARNING: Track  2, sector  6: 1/14 bad sector reads discarded at position 0.14.
WARNING: Track  2, sector  3: 7/13 bad sector reads discarded at position 0.95.
WARNING: Track  3, sector 13: 1/14 bad sector reads discarded at position 0.78.
WARNING: Track  3, sector 11: 1/14 bad sector reads discarded at position 0.66.
WARNING: Track  3, sector  7: 1/14 bad sector reads discarded at position 0.42.
WARNING: Track  4, sector  1: 2/14 bad sector reads discarded at position 0.27.
WARNING: Track  5, sector 12: 1/14 bad sector reads discarded at position 0.16.
0 missing sectors, 0 sectors with errors

Share this post


Link to post
Share on other sites
3 hours ago, pksw said:

I think it was probably bad media. Used a fresh disk, and downloaded "Where in the World is Carmen Sandiego" from the apple ii asimov FTP repository, then read it back using my PC.

 

WARNING: Track  0, sector 12: 1/14 bad sector reads discarded at position 0.06.

WARNING: Track  0, sector  4: 1/14 bad sector reads discarded at position 0.57.
WARNING: Track  0, sector  3: 2/14 bad sector reads discarded at position 0.51.
...

I'd still be interested in the SCP of this or another recently written Apple II disk. This is still a pretty bad read, as with a freshly written disk should read back with zero errors. To put it another way, if this actually happened on the Apple II, you would get a head bump and retry for each one of these errors, which obviously doesn't happen. I'd chalked this up to the age of the Apple II disks that I had as I only had old 20yr+ disks without an actual Apple II to rewrite new ones, but this implies that Apple II disks are affected by the same strangeness that I've also seen with Mac 800K disks.

 

Share this post


Link to post
Share on other sites

Always possible that my apple iic floppy from 1987, or my floppy disk drive from 1990 are the culprits. 

 

Here is the SCP for disk 2 of carmen sandiego as well as the DSK image from the ASIMOV repository that I wrote to floppy. There are exactly 5 bytes different in disk after the conversion from SCP to DSK, as I actually played a game, and saved a game onto the disk (so some zero bytes changed to the name "LIAM")

 

eg

Comparing files carmen2.dsk and CARMENW2.DSK
000220A0: 4C 00 L
000220A1: 49 00 I
000220A2: 41 00 A 
000220A3: 4D 00 M
000220AF: 01 00 (01=completed 1 case in the game)
 

carmen2.zip carmenw2.dsk

Share this post


Link to post
Share on other sites

is there any chance you could add support for converting Atari images to SCP with index aligned formatting? Been speaking with the author of the Greaseweazle after many failed images written back to floppy and he says its because of the SCP files not being index aligned and results in corrupted sectors. Dont really understand to be honest.....just relating back what I've been told after sending him some dumps I've created myself that won't write back and boot successfully.

Share this post


Link to post
Share on other sites
2 hours ago, djmat56 said:

is there any chance you could add support for converting Atari images to SCP with index aligned formatting? Been speaking with the author of the Greaseweazle after many failed images written back to floppy and he says its because of the SCP files not being index aligned and results in corrupted sectors. Dont really understand to be honest.....just relating back what I've been told after sending him some dumps I've created myself that won't write back and boot successfully.

The suggestion is essentially to fudge the disk to work around limitations in the Greaseweazle software (it looks like the hardware is capable). This changes the disk and can break some protected disks, so it's not an idea I'm fond of.

 

Share this post


Link to post
Share on other sites

Ok. I totally understand. So we either need the ability for a8rawconv to be able to communicate with the greaseweazle or the greaseweazle to be updated i guess.

My only other option is to buy a supercard pro. If i could get one of these in the uk I'd be tempted

Share this post


Link to post
Share on other sites

I am surprised that only "we Atarians" complain about this shotcoming of Greaseweazle's software. C64 and Apple also do not have an index pulse and therefore should be affected as well.

Share this post


Link to post
Share on other sites

I have already dumped some disks and uploaded but I also have tons of floppy disks that I want to create real disks from images. Such a shame that the greaseweazle software isn't up to the task. May have to look to purchase a Supercard if I can find one in the UK

Share this post


Link to post
Share on other sites

Hello

I bought the SuperCard Pro and would like it 
with a8rawconv. I have a Drive Teac FD-55E-02-U
This is a 360k drive. Can I use the Super Card Pro drive?
Does it work? Is there anything known about this?

I am a bloody beginner in terms of Super Card Pro and a8rawconv. I succeed
simply does not copy a normal Atari 1050 floppy disk into single. It is used by
1050s not read. My 1050 has a Speedy.

But I also don't know which profile I should take at SCP and which
settings would have to be made. With profile Atari 400/800 I also know about the
support forum that it should not work with it. It is alleged that there is no functioning
profile. There should therefore be a new SCP version, which is available on Track/Head
based on disk type instead of the previous one.

Until then, you should take the profile C64er. But this profile starts with Track1 and not
with Track0. The Atari Disk requires Track0. You can't change that in the Profile C64er.
How should I be able to make a working Atari Disk copy?

Then I tried to use a8rawconv. I then read out a disc and sent out an SCP
file and then write it to a new disc. Of course with tpi48. Didn't work.
Then I tried again to create a scp file from it again, then it in an atr file
and then the atr file written back on a disc. Doesn't work there either.

No matter what I do, it doesn't work. What exactly do I have to do?

Share this post


Link to post
Share on other sites
8 hours ago, Pmetzen said:

What exactly do I have to do?

First, don't use the SuperCard Pro software for Atari disks. The broken defaults mean that you have to fudge a bunch of settings to read an Atari disk with it, and writing one with it is almost guaranteed not to work since it can't handle non index aligned tracks. C64 profile will not work by itself either as it specifies 35 tracks instead of 40.

 

Second, double-check your drive model. According to online references, FD-55E-02-U appears to be an 80 track drive, not a 40 track drive. In that case you would need to specify 96tpi instead of 48tpi. The symptom of a track density mismatch is that only track 0 reads and writes successfully.

 

Make sure you have the latest version of a8rawconv in this thread, which is 0.94. Then, image a plain unprotected disk like a DOS disk to an ATR file and check that it reads successfully with an emulator or a disk image utility. Then, write it back out to a disk to verify that that works too.

 

  • Like 2

Share this post


Link to post
Share on other sites

On the a8preservation website is a nice documentation on how to dump disks with several tools including the SCP.

http://www.a8preservation.com/#/guides/diskDumping

There you can also check if your disks have already been preserved.

 

If you prefer German language you might also contact Bernd on the ABBUC forum. He has successfully dumped several disks.

  • Like 1

Share this post


Link to post
Share on other sites
On 12/8/2020 at 3:22 PM, phaeron said:

First, don't use the SuperCard Pro software for Atari disks. The broken defaults mean that you have to fudge a bunch of settings to read an Atari disk with it, and writing one with it is almost guaranteed not to work since it can't handle non index aligned tracks. C64 profile will not work by itself either as it specifies 35 tracks instead of 40.

 

Second, double-check your drive model. According to online references, FD-55E-02-U appears to be an 80 track drive, not a 40 track drive. In that case you would need to specify 96tpi instead of 48tpi. The symptom of a track density mismatch is that only track 0 reads and writes successfully.

 

Make sure you have the latest version of a8rawconv in this thread, which is 0.94. Then, image a plain unprotected disk like a DOS disk to an ATR file and check that it reads successfully with an emulator or a disk image utility. Then, write it back out to a disk to verify that that works too.

 

What is broken with the scp software ?  I made images and wrote them with the scp software (on 40 track drives) (once I determined found a solid working drives in my collection).  However, I was only imaging commercial disks, so they may have been index aligned.

 

Are there any known commercial Atari disks that were not index aligned ?

 

-- Curt

 

Share this post


Link to post
Share on other sites
4 hours ago, cwilbar said:

What is broken with the scp software ?  I made images and wrote them with the scp software (on 40 track drives) (once I determined found a solid working drives in my collection).  However, I was only imaging commercial disks, so they may have been index aligned.

The SCP software does not know how to write a track with non index aligned tracks. The .SCP image format only stores full tracks from index-to-index and doesn't have information on the appropriate splice point, so it tries to write out the track index-aligned. This damages sectors that cross the index mark.

 

Try this simple experiment: take a floppy disk with plain DOS 2.0S in it, image it with the SCP 2.20 software, then write the image back out to a new disk also with the SCP software. Try to boot the disk on a real Atari. You'll get BOOT ERROR, because some of the sectors containing DOS will be damaged due to the track write starting and ending within a sector. Then take that same image and write it out using a8rawconv, and you'll get a bootable disk. This is because a8rawconv knows how to analyze the sectors on the track and choose a splice point that is between the sectors, as well as how to pad the track to write it with the SCP hardware with the correct splice point and track skew.

 

Additionally, the Atari 400/800 profile in the SCP software has always been a bit off. In current versions it is at least two revs instead of one rev, so it at least now properly captures cross-index sectors. However, it still defaults to double-sided even though such disks are rare -- the only Atari drive that supported double sided operation was the XF551. Third-party drive support was uncommon and commercial usage was extremely rare if not nonexistent.

 

4 hours ago, cwilbar said:

Are there any known commercial Atari disks that were not index aligned ?

Yes, plenty, including just plain DOS. Any disk that was originally mastered on an 810 or 1050 and didn't have its track alignment adjusted will have sectors spanning the index.

 

  • Like 2

Share this post


Link to post
Share on other sites
16 hours ago, phaeron said:

 

Quote

Are there any known commercial Atari disks that were not index aligned ?

Yes, plenty, including just plain DOS. Any disk that was originally mastered on an 810 or 1050 and didn't have its track alignment adjusted will have sectors spanning the index.

 

 

Phaeron is of course, right. Furthermore. Most Atari 8-bit original disks are NOT aligned to the index hole. Even those duplicated and mastered by professional duplicators. Of course, some do are aligned. This depend mostly on the specific publisher, and also on the period. But on the earlier classic period, very few publishers duplicated disks aligned to the index hole. Notably EA disks do are aligned since day one. Synapse disks, except the latest titles are NOT aligned to the index hole. Even most Synapse titles that are among the ones with the most advanced copy protection, they still are not aligned. And that includes a couple of Synapse titles with a skew align protection!

Share this post


Link to post
Share on other sites
On 12/10/2020 at 2:28 PM, ijor said:

 

Phaeron is of course, right. Furthermore. Most Atari 8-bit original disks are NOT aligned to the index hole. Even those duplicated and mastered by professional duplicators. Of course, some do are aligned. This depend mostly on the specific publisher, and also on the period. But on the earlier classic period, very few publishers duplicated disks aligned to the index hole. Notably EA disks do are aligned since day one. Synapse disks, except the latest titles are NOT aligned to the index hole. Even most Synapse titles that are among the ones with the most advanced copy protection, they still are not aligned. And that includes a couple of Synapse titles with a skew align protection!

Archiving my originals has been on hold for a bit, so my memory may be incorrect on writing out disks with the SCP software..... I am a command line junkie.... so while I did all my reading with scp software (set to 6? revs), I may have done all my writing with a8rawconv.

 

Wonder what Jim Drew's plans are regarding this issue ?

 

Share this post


Link to post
Share on other sites

Is there a specific reason you folks are using 96tpi drives to image 48tpi disks?  It was my understanding that from an imaging standpoint, "best practices" were to use like-drive with like-media.

tnx!

 

g.

Share this post


Link to post
Share on other sites
2 hours ago, geneb said:

Is there a specific reason you folks are using 96tpi drives to image 48tpi disks?  It was my understanding that from an imaging standpoint, "best practices" were to use like-drive with like-media.

In my case, it's what I have -- combo 3.5"/5.25" salvaged from an old PC. Reading works fine, not the best choice for writing but it works OK if you ensure that odd tracks are erased.

 

Share this post


Link to post
Share on other sites
3 hours ago, geneb said:

Is there a specific reason you folks are using 96tpi drives to image 48tpi disks?  It was my understanding that from an imaging standpoint, "best practices" were to use like-drive with like-media.

I have both, no issues imaging and writing with either and a8rawconv with the correct parameters. The only reason I would use the 96tpi drive is for the SCP imaging software, as it doesn't work with 48tpi drives in my experience even when selected. You get a nice boink noise at track 21.

 

I tend to use the 48tpi drive generally and have a big magnet on hand for erasing disks.

Share this post


Link to post
Share on other sites
19 hours ago, geneb said:

Is there a specific reason you folks are using 96tpi drives to image 48tpi disks?  It was my understanding that from an imaging standpoint, "best practices" were to use like-drive with like-media.

 

Each type of drive has its own pros and cons...

 

Some damaged disks can sometimes be read successfully on 96tpi drives only, and sometimes the other way around. Most, but not all, 48tpi drives can access the flippy side without index hole, while almost none 96tpi ones can. 48tpi drives are better for writing back; 96tpi drives require bulk erased disks. 96tpi drives are usually faster (360 vs 300 RPM).

 

Oldest drives require higher current drivers. They might not work, i.e., with the simple unbuffered Greaseweazle. It could be an issue even with buffered devices if you connect multiple drives at the same time.

 

But I guess most people just use what they have :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...