a8rawconv, a new raw disk conversion utility

[+Nezgar]

And then you have disks formatted/written in WST 1050's with roms/speeders (happy) that used stepper phase encodings for drives aligned to the Tandon based roms, resulting in 1/4 track offsets heh. (Many of my own disks!) Wonder which of 48 or 96tpi would get the more reliable reading... maybe the 96 would be less likely to pick up signal from adjacent track.

[Hammer]

First of all thank you for this excellent utility.

 

I tried today to image the Apple II game "Transylvania" from 1982. When I actually created the image, Kryoflux didn't give me any errors of bad sectors or anything like that. I did notice though that every other sector was unformatted. When I tried to create a .dsk file with A8rawconv, it failed for this reason and also because it detected a stable CRC error on track 34, sector 11, at position 0.31. Creating a .nib file, however, seemed to work fine, and I was able to load the image in AppleWin. The game for the most part worked fine. However, in one particular location, the graphics were corrupted and in some cases the game would crash with a disk error.

 

Do you have any idea what could be going on here? I would think maybe the disk was bad, but I would think that would then show up as a bad sector rather than a CRC error. And it almost totally works.

 

Thanks again.

[Hammer]

10 hours ago, Hammer said:

First of all thank you for this excellent utility.

 

I tried today to image the Apple II game "Transylvania" from 1982. When I actually created the image, Kryoflux didn't give me any errors of bad sectors or anything like that. I did notice though that every other sector was unformatted. When I tried to create a .dsk file with A8rawconv, it failed for this reason and also because it detected a stable CRC error on track 34, sector 11, at position 0.31. Creating a .nib file, however, seemed to work fine, and I was able to load the image in AppleWin. The game for the most part worked fine. However, in one particular location, the graphics were corrupted and in some cases the game would crash with a disk error.

 

Do you have any idea what could be going on here? I would think maybe the disk was bad, but I would think that would then show up as a bad sector rather than a CRC error. And it almost totally works.

 

Thanks again.

Sorry I meant to say every other TRACK was unformatted...

[phaeron]

18 hours ago, Hammer said:

I tried today to image the Apple II game "Transylvania" from 1982. When I actually created the image, Kryoflux didn't give me any errors of bad sectors or anything like that. I did notice though that every other sector was unformatted. When I tried to create a .dsk file with A8rawconv, it failed for this reason and also because it detected a stable CRC error on track 34, sector 11, at position 0.31. Creating a .nib file, however, seemed to work fine, and I was able to load the image in AppleWin. The game for the most part worked fine. However, in one particular location, the graphics were corrupted and in some cases the game would crash with a disk error.

 

Do you have any idea what could be going on here? I would think maybe the disk was bad, but I would think that would then show up as a bad sector rather than a CRC error. And it almost totally works.

I'm afraid I don't have much experience with Apple II protected disks, but the stable CRC error is not ideal if it's not supposed to be there. Neither the Kryoflux nor the NIB conversion steps will detect errors like this because they don't do sector decoding. It could also be correct, though. CRC errors are common on Atari disks because standard 810/1050 disk drives can't reproduce them, but Disk II is lower level.

 

Note that a CRC error is a bad sector. The CRC code is how the computer detects if the sector was read correctly or not, since damage to the sector will cause the recorded CRC to not match the computed CRC. (It's actually a checksum and not a CRC on the Apple II, but a8rawconv calls it CRC because most of the formats it deals with use a CRC-16. Works the same way.)

 

[Hammer]

3 hours ago, phaeron said:

I'm afraid I don't have much experience with Apple II protected disks, but the stable CRC error is not ideal if it's not supposed to be there. Neither the Kryoflux nor the NIB conversion steps will detect errors like this because they don't do sector decoding. It could also be correct, though. CRC errors are common on Atari disks because standard 810/1050 disk drives can't reproduce them, but Disk II is lower level.

 

Note that a CRC error is a bad sector. The CRC code is how the computer detects if the sector was read correctly or not, since damage to the sector will cause the recorded CRC to not match the computed CRC. (It's actually a checksum and not a CRC on the Apple II, but a8rawconv calls it CRC because most of the formats it deals with use a CRC-16. Works the same way.)

 

Any suggestions? I tried to image the disk again but there's no indication of an error regardless of what I do (and I understand what you're saying that Kryoflux wouldn't be able to detect it, but it has a "format guided" mode where it checks the raw image against what it expects the disk to be, so it SHOULD be able to detect it...). I got the same results except with 2 invalid GCR bytes encountered instead of 5. This is the output for the DSK attempt:

 

Reading KryoFlux track stream set (96 TPI)...
1 invalid GCR bytes encountered
1 invalid GCR bytes encountered
Writing Apple II disk image (DOS 3.3 ordering): sigh.dsk
WARNING: Missing sectors not supported by DSK/DO format. Writing out null data.
WARNING: No sectors found on track 1.
WARNING: No sectors found on track 3.
WARNING: No sectors found on track 5.
WARNING: No sectors found on track 7.
WARNING: No sectors found on track 9.
WARNING: No sectors found on track 11.
WARNING: No sectors found on track 13.
WARNING: No sectors found on track 15.
WARNING: No sectors found on track 17.
WARNING: No sectors found on track 19.
WARNING: No sectors found on track 21.
WARNING: No sectors found on track 23.
WARNING: No sectors found on track 25.
WARNING: No sectors found on track 27.
WARNING: No sectors found on track 29.
WARNING: No sectors found on track 31.
WARNING: No sectors found on track 33.
WARNING: Track 34, sector 11: Stable CRC error detected at position 0.31.
WARNING: CRC error encoding not supported by DSK format. Ignoring CRC error for track 34, sector 12.
272 missing sectors, 1 sector with errors

 

Not sure why it says section 11 and then sector 12 for the CRC error. The output for .nib just mentions the 2 invalid GCR bytes.

 

I really don't think this is a copy protection issue since the game almost totally works, it seems like some weird data corruption. It of course could be a bad disk but again, I would think Kryoflux would catch it. Is it possible it's some issue with the utility? I find it unusual that it happens on the last actual track with data (everything after 34 is unformatted). If not, I'll give up on this one and see if I have issues with the next disk (to try to rule out an actual disk error).

 

Thanks!

 

[phaeron]

18 hours ago, Hammer said:

Any suggestions? I tried to image the disk again but there's no indication of an error regardless of what I do (and I understand what you're saying that Kryoflux wouldn't be able to detect it, but it has a "format guided" mode where it checks the raw image against what it expects the disk to be, so it SHOULD be able to detect it...). I got the same results except with 2 invalid GCR bytes encountered instead of 5. This is the output for the DSK attempt:

You can try tweaking a8rawconv's decoder, as it hasn't been tested much for GCR decoding compared to KryoFlux. The -p command line switch allows the bit cell period to be tweaked. Try small numbers between -p 95 and -p 105 to see if you can get those invalid GCR bytes to go away. There should be no invalid GCR bytes reported for a disk without errors.

 

As for the sector number in the warning, I'll have to check the code but it's probably just a reporting mixup. There is a logical vs. physical sector number distinction specific to Apple II disks.

[Hammer]

31 minutes ago, phaeron said:

You can try tweaking a8rawconv's decoder, as it hasn't been tested much for GCR decoding compared to KryoFlux. The -p command line switch allows the bit cell period to be tweaked. Try small numbers between -p 95 and -p 105 to see if you can get those invalid GCR bytes to go away. There should be no invalid GCR bytes reported for a disk without errors.

 

As for the sector number in the warning, I'll have to check the code but it's probably just a reporting mixup. There is a logical vs. physical sector number distinction specific to Apple II disks.

That was it!!!! Values of 102 to 105 not only made the invalid GCR bytes go away, they also made the CRC error go away! I tried with 102 and it now seems to work!

 

THANK YOU SIR!!!!!!!!

[Jean-Fred64]

@phaeron
Thank you very much for your program.

For info, we are currently developing a floppy disk stream dump card.

The "Pauline FDC" project uses a DE10-nano FPGA. This motherboard is completely oversized for use, but this will allow the development of applications outside of raw archiving.
It will be possible to do :

• Dumps of floppy disks including the originals (multi-format),
• Plug Pauline directly on the real machine via the floppy drive ribbon to simulate several virtual drives in a real machine and test the dumps of the originals made.
• Control the card functionalities from a web interface.
• Store the disk images on the integrated SD card, on USB support or from a network storage, it's under a Linux layer so the possibilities are multiple.

https://www.laludotheque.fr/projets-en-cours/preservation-des-disquettes-pauline/

 

The generation of .dsk or .nib is not yet available in the export formats in HxCFloppyEmulator, hence this manipulation.
Here is a solution using a8rawconv to get the desired .dsk files

 

 

Hope that helps

Best regards

[Hammer]

I just tried to image 2 Atari disks, both by On-Line Systems (AKA Sierra). One of them (Crossfire) worked fine. The second one (Mouskattack) read in Kryoflux with a bunch of bad sectors, and I got the following output from a8rawconv:

 

Reading KryoFlux track stream set (96 TPI)...
Writing ATX file: mouse.atx
WARNING: Track  0, sector  5: Multiple sectors found at the same position
         0.36 but different bad data. Encoding weak sector at offset 105.
WARNING: Track  0: Missing sectors: 7.
WARNING: Track  2, sector  8: Multiple sectors found at the same position
         0.36 but different bad data. Encoding weak sector at offset 114.
WARNING: Track  2: Missing sectors: 10.
WARNING: No sectors found for track 3 -- possibly unformatted.
WARNING: Track  4, sector  7: Multiple sectors found at the same position
         0.35 but different bad data. Encoding weak sector at offset 128.
WARNING: Track  4: Missing sectors: 9.
WARNING: Track  5, sector 18: Multiple sectors found at the same position
         0.38 but different bad data. Encoding weak sector at offset 75.
WARNING: Track  5: Missing sectors: 1.
WARNING: Track  6, sector 12: Multiple sectors found at the same position
         0.39 but different bad data. Encoding weak sector at offset 21.
WARNING: Track  7, sector  2: Multiple sectors found at the same position
         0.37 but different bad data. Encoding weak sector at offset 110.
WARNING: Track  7: Missing sectors: 4.
WARNING: Track  8, sector 11: Multiple sectors found at the same position
         0.39 but different bad data. Encoding weak sector at offset 24.
WARNING: Track  9, sector  1: Multiple sectors found at the same position
         0.37 but different bad data. Encoding weak sector at offset 118.
WARNING: Track  9: Missing sectors: 3.
WARNING: Track 10, sector 17: 1/5 bad sector reads discarded at position 0.02.
WARNING: Track 10, sector 14: Multiple sectors found at the same position
         0.39 but different bad data. Encoding weak sector at offset 51.
WARNING: Track 11: Missing sectors: 6.
WARNING: Track 12, sector 13: Multiple sectors found at the same position
         0.38 but different bad data. Encoding weak sector at offset 107.
WARNING: Track 12: Missing sectors: 15.
WARNING: Track 13, sector  5: Multiple sectors found at the same position
         0.40 but different bad data. Encoding weak sector at offset 25.
WARNING: Track 14, sector 16: Multiple sectors found at the same position
         0.37 but different bad data. Encoding weak sector at offset 127.
WARNING: Track 15, sector  8: Multiple sectors found at the same position
         0.40 but different bad data. Encoding weak sector at offset 51.
WARNING: Track 39, sector  8: 5 different sectors found at the same position
         0.03 but different bad data. Keeping the most popular one.
26 missing sectors, 0 phantom sectors, 14 sectors with errors

 

So the disk could be bad - I am not sure. But my question is - why the different behavior for the weak sectors on most of the tracks, where it says "multiple sectors found", and the behavior for track 39, where it says "5 different sectors found" and "keeping the most popular one"?

 

Thanks in advance.

[Hammer]

I also have an Apple question - is there support for DOS 3.2 disks? If not, can it be added?

 

And a related question - it seems that the .nib format is on the way out, and the .woz format is all the rage. Do you have any plans to support the .woz format?

 

Thanks so much again.

[phaeron]

1 hour ago, Hammer said:

So the disk could be bad - I am not sure. But my question is - why the different behavior for the weak sectors on most of the tracks, where it says "multiple sectors found", and the behavior for track 39, where it says "5 different sectors found" and "keeping the most popular one"?

a8rawconv's origins are in the ATX file format for Atari 8-bit disks, which can encode not only regular sectors but also sectors with stable errors (CRC error) and unstable errors (weak sectors). Software disks frequently check for a specific form of defect on a disk. When seeing multiple copies of the same sector that have errors, a8rawconv compares the decoded data from all of the copies to try to match them. If it finds two or more copies that match, it assumes that is the stable sector -- good or bad -- and tosses the other copies. If none of the copies match, it assumes that the sector is a deliberate weak sector and encodes it with a flag indicating where the unstable data starts, for the formats that support that.

 

This is also the reason that 5 revolutions are recommended, btw. It gives the decoder more chances to find a good copy of each sector when the read is marginal.

 

49 minutes ago, Hammer said:

I also have an Apple question - is there support for DOS 3.2 disks? If not, can it be added?

Decoding DOS 3.2 is not difficult, but I'm not sure there's a file format to use for this. DSK/DO don't seem to be widely supported for 13-sector format. Without such a format, such support won't be usable.

 

49 minutes ago, Hammer said:

And a related question - it seems that the .nib format is on the way out, and the .woz format is all the rage. Do you have any plans to support the .woz format?

Hasn't been planning to, though I'm not opposed to the idea. The WOZ file format is a bit more complicated than the other file formats and I don't spend that much time emulating the Apple II (Atari is better ?).

[Hammer]

21 hours ago, phaeron said:

a8rawconv's origins are in the ATX file format for Atari 8-bit disks, which can encode not only regular sectors but also sectors with stable errors (CRC error) and unstable errors (weak sectors). Software disks frequently check for a specific form of defect on a disk. When seeing multiple copies of the same sector that have errors, a8rawconv compares the decoded data from all of the copies to try to match them. If it finds two or more copies that match, it assumes that is the stable sector -- good or bad -- and tosses the other copies. If none of the copies match, it assumes that the sector is a deliberate weak sector and encodes it with a flag indicating where the unstable data starts, for the formats that support that.

 

This is also the reason that 5 revolutions are recommended, btw. It gives the decoder more chances to find a good copy of each sector when the read is marginal.

This was an Atari disk I was talking about, in case it wasn't clear. My question though was - isn't it possible that 2 of the copies just matched randomly? Should there be an option to encode the sector as weak even if 2 of the copies happen to match (as long as there's at least 1 or 2 that are different)?

21 hours ago, phaeron said:

 

Decoding DOS 3.2 is not difficult, but I'm not sure there's a file format to use for this. DSK/DO don't seem to be widely supported for 13-sector format. Without such a format, such support won't be usable.

 

Hasn't been planning to, though I'm not opposed to the idea. The WOZ file format is a bit more complicated than the other file formats and I don't spend that much time emulating the Apple II (Atari is better ?).

Well this is the reason I was asking about .WOZ. My understanding is that it can handle DOS 3.2 disks also. I am not sure whether or not .NIB can. 

 

And I agree Atari is better! And the reason why I was dumping these 2 disks is that I was making a video to demonstrate that the Atari version of the game was better than the Apple version.

[phaeron]

19 hours ago, Hammer said:

My question though was - isn't it possible that 2 of the copies just matched randomly? Should there be an option to encode the sector as weak even if 2 of the copies happen to match (as long as there's at least 1 or 2 that are different)?

It's pretty unlikely if the weak sector protection is at least halfway reliable. Haven't heard of this happening yet. The case where what is supposed to be a good sector is reading marginally is far more common.

 

Also, the ATX file format not only has a weak flag but also a weak offset, so it isn't enough to just declare the sector weak, it has to have a good 'prefix' and a bad 'suffix'.

 

19 hours ago, Hammer said:

Well this is the reason I was asking about .WOZ. My understanding is that it can handle DOS 3.2 disks also. I am not sure whether or not .NIB can.

NIB should be able to as well. Both are bitstream formats, but the primary difference is that NIB stores post-synchronization bytes (bit 7 set in the data register), while WOZ stores the raw bits before synchronization. Either is sufficient for DOS 3.2. The 13-sector format uses a more restricted GCR mapping that only relies on the synchronizer being able to handle single zero bits instead of a run of two, but the 16 sector capable / DOS 3.3 synchronizer can still read it and this should also carry over to the disk image emulation. a8rawconv won't be able to see the sectors since it currently only supports DOS 3.3 / ProDOS decoding, but that only matters when outputting to a decoded format like DSK/DO/PO and not a bitstream format.

 

That having been said, without the iconic head grinding sound of an actual Disk II, it may be a bit trickier to tell if the disk is booting successfully in emulation or not.

 

[Hammer]

49 minutes ago, phaeron said:

It's pretty unlikely if the weak sector protection is at least halfway reliable. Haven't heard of this happening yet. The case where what is supposed to be a good sector is reading marginally is far more common.

 

Also, the ATX file format not only has a weak flag but also a weak offset, so it isn't enough to just declare the sector weak, it has to have a good 'prefix' and a bad 'suffix'.

The settings I was using in Kryoflux was basically 2 attempts with 5 revolutions per attempt. I'll make it 5 attempts and try again, but it's always possible that the disk is just bad I guess. 

49 minutes ago, phaeron said:

 

NIB should be able to as well. Both are bitstream formats, but the primary difference is that NIB stores post-synchronization bytes (bit 7 set in the data register), while WOZ stores the raw bits before synchronization. Either is sufficient for DOS 3.2. The 13-sector format uses a more restricted GCR mapping that only relies on the synchronizer being able to handle single zero bits instead of a run of two, but the 16 sector capable / DOS 3.3 synchronizer can still read it and this should also carry over to the disk image emulation. a8rawconv won't be able to see the sectors since it currently only supports DOS 3.3 / ProDOS decoding, but that only matters when outputting to a decoded format like DSK/DO/PO and not a bitstream format.

But currently a8rawconv isn't capable of encoding a DOS 3.2 disk to .nib, correct?

49 minutes ago, phaeron said:

That having been said, without the iconic head grinding sound of an actual Disk II, it may be a bit trickier to tell if the disk is booting successfully in emulation or not.

 

Yeah, honestly I am really not a huge fan of the Applewin emulator. Altirra is much better. I wish I knew of a better emulator for Apple.

[phaeron]

1 hour ago, Hammer said:

But currently a8rawconv isn't capable of encoding a DOS 3.2 disk to .nib, correct?

I have neither a 13-sector disk nor an actual Apple II to test, but I don't see why it wouldn't. KF/SCP to NIB is just running the byte synchronizer, it doesn't even depend on the GCR nibblization tables.

[Pitou]

Hello @phaeron!

 

First, thank you very much for this great utility.

 

I'm mostly imaging Apple II disks with my SCP these days. I understand that the main target is for Atari disk.

 

However I'm trying to backup my original Test Drive for Apple II and it doesn't work 100%

The disk boots, but at some point it stops after the intro.

 

If you have any idea or hints...

 

Thank you very much.

 

Pitou!

[bsmith1702]

Hi,

I am trying to create a .nib image of an Apple II game that I have.  I actually have two copies of the disk which is good because Kryoflux reports a bad track on each of the disks.  Fortunately, it's a different track on each disk, so I thought I could just replace the bad track file with a good one from the other disk.  Both disks have an "unknown" track 0, but I'm not sure if that is a problem or a result of copy protection.  Anyway, I replaced the bad file and tried to make the image (a8rawconv track00.0.raw mc.nib) and I get a several "Invalid GCR bytes encountered" error.  The image does nothing when I try to run it in AppleWin.  I read above about using -p and values from 95 to 105, but I haven't had much luck.  I'd appreciate any suggestions.

[ijor]

On 1/28/2021 at 3:50 AM, Hammer said:

This was an Atari disk I was talking about, in case it wasn't clear. My question though was - isn't it possible that 2 of the copies just matched randomly? Should there be an option to encode the sector as weak even if 2 of the copies happen to match (as long as there's at least 1 or 2 that are different)?

 

That is conceivable, and I'd say it is even possible in other platforms, but extremely unlikely in the Atari 8-bit. Weak bits were originally created in such a way that, from a given point, the rest of the sector would read random, non-deterministic, data. Furthermore, because the technique wasn't very precise, the "weak start point", the position in the sector where it starts to be weak, was never too close to the end of the sector. So the number of "weak bits" in the sector would be significant and then it would be extremely unlikely that a weak sector would read identically in two different revolutions.

 

On later 16-bit platforms, duplication and creation of weak bits was much more precise and sometimes used a completely different technique. Then you could indeed get a match reading a weak sector in two revolutions.

[rmzalbar]

I would just like to thank Phaeron for creating a8rawconv. I just used it for the first time to write an image back to a real disk, a copy-protected Fort Apocalypse atx, with SCP hardware and a 96-tpi drive. Boots up on my real Atari just fine (once I set the 1050 to unHappy.)  Is it an impractical way to load Fort Apocalyse? Definitely. Do I love putting the disk in the drive, powering on, and listening to it boot up just like I did 35 years ago? YOU BET!!

Edited July 8, 2021 by rmzalbar

[Mclaneinc]

Ha ha...Love the enthusiasm and the joy something so simple can bring after all this time....

 

Phaerons other creation, the Atari emulator, Altirra also game me a similar feeling when it was published, I'd lost all my gear and only had emulation, the sound of the SIO noise after all that time was just music to my ears. I've since got real hardware back, but just so appreciate the hard work and knowledge put in to Phaeron's creations.

 

[Hammer]

On 1/27/2021 at 3:48 AM, phaeron said:

Decoding DOS 3.2 is not difficult, but I'm not sure there's a file format to use for this. DSK/DO don't seem to be widely supported for 13-sector format. Without such a format, such support won't be usable.

I just learned today that apparently the .D13 format is designed for this?

[phaeron]

15 hours ago, Hammer said:

I just learned today that apparently the .D13 format is designed for this?

Simple enough, shouldn't be a problem to support if I can get a DOS 3.2 formatted image to test against.

[Hammer]

21 hours ago, phaeron said:

Simple enough, shouldn't be a problem to support if I can get a DOS 3.2 formatted image to test against.

So after messing around a bit today, I learned a few things:

1) A8rawconv does indeed properly create .nib files for 13 sector images.
2) No emulators that I am aware of properly support 13 sector .nib files, and they have bugs with .nib in general.
3) While the .d13 format is intended for 13 sector images, it cannot handle any copy protection and is also not supported by any emulators.

The best solution, if possible, would be to add .woz support to A8rawconv. Someone apparently used Applesauce to convert my A8rawconv .nib file into a .woz file that then worked in Applewin. I am trying to replicate this myself, but it's a big pain because Applesauce only runs on a Mac. A far better option would be if A8rawconv could create .woz files natively. My understanding is that it would not be perfect since Kryoflux raw files lack some of the timing data that an Applesauce image has for an Apple disk and stores in a .woz file, but it would be a lot better than nothing (to my limited understanding).

Thanks again for this great utility.

[JimDrew]

On 12/9/2020 at 7:42 PM, phaeron said:

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.

 

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.

 

I just saw this post!

 

Atari 8 bit disks, just like any system without an index hole sensor, will likely need 2 revolutions to encompass all of the data.  SuperCard Pro was not really designed to have an automated process of decoding and writing data back to a disk.  You can certainly manually copy any disk that a drive can physically write using the editor/analyzer at a flux level.  There are a bunch of different utilities that can frame .scp image files.  The correct method for allowing an exact copy is to capture 2+ revolutions and then the writing phase you write 1 full revolution plus as much data as necessary - up to the track gap (where the write splice occurs).  SuperCard Pro does have a "SPLICE" mode that works pretty well for doing this automatically at the flux level, but it is not perfect.  The SPLICE routine scans the flux data and looks for invalid flux that commonly occurs when the write head is turned off (during the mastering of the original disk).  When the head is turned off there is a "smear" that occurs as the write circuitry powers down.  That almost always (but not 100%) generates invalid flux and can be used to queue where the write splice is.  There are cases where that smear ends up creating a valid flux timing value and so nothing appears abnormal.

The double-sided capture is not accidental.  If you don't want the other side's data then just ignore those TDH entries.

 

Edited September 6, 2021 by JimDrew

[telengard]

I'm trying to image some working Atari disks using a8rawconv and an SCP.  Some image and convert (with lots of warnings about missing sectors, etc), to .atx and work in Altirra.  Some have similar errors and don't even boot, even though they do on my Atari w/ a 1050.  I'm not sure exactly how to interpreter the output as to what is bad or not.   I've attached the output of one of the non-working imaged disks.  Any insight is greatly appreciated.

 

Oh, and my drive is a Panasonic 5 1/4 JU-475-4EAF with flippy mod.

 

thanks

errors.txt

Edited October 7, 2021 by telengard