Jump to content
IGNORED

a8rawconv, a new raw disk conversion utility


phaeron

Recommended Posts

The difference between 288 RPM and 300 RPM is only 4%. This is well within the range of frequency error that a floppy disk decoder should, or rather, needs to be able to tolerate. a8rawconv doesn't have a problem decoding 300 RPM disks at 288 RPM timings, as you can actually give it a 360K DOS disk and it will decode 9 MFM 512 byte sectors per track even despite the difference in timing. The other way works as well: I just wrote out a physical disk using 4us @ 300 RPM cell timings instead of 4us @ 288 RPM timings and my 1050 drive happily booted DOS 2.0S. And, as I noted, I and many other people successfully read Atari disks on PC controllers that did not have clock settings for 4us @ 288 RPM equivalent cell timings.

 

Keep in mind, FM only has at most one 0 bit between pairs of 1 bits, so the decoder has a lot of chances to adjust its tracking. If your decoding algorithm is unable to accommodate a 4% difference in cell timing, then something is fundamentally wrong. I can detune a8rawconv's decoder as far as 10% off of ideal and still pull clean sectors off a real disk image, and I'm pretty sure it can still be improved.

Link to comment
Share on other sites

The difference between 288 and 360 RPMs is 20%, which is well outside of the normal range of a decoder. My decoder works +/-49% of the bitcell width. However, the center position must be correct. I am not sure what it is set to for Atari disks - it could be 2us which is default for 1.44MB disks. I need to check that. This of course only applies to the analyzer/editor. The copier is just a flux dump/restore tool, so drive speed (and even contents) does not matter.

Edited by JimDrew
Link to comment
Share on other sites

The difference between 288 and 360 RPMs is 20%, which is well outside of the normal range of a decoder. My decoder works +/-49% of the bitcell width. However, the center position must be correct. I am not sure what it is set to for Atari disks - it could be 2us which is default for 1.44MB disks. I need to check that. This of course only applies to the analyzer/editor. The copier is just a flux dump/restore tool, so drive speed (and even contents) does not matter.

IIRC only HD(1.2MB) 5-1/4" drives are 360RPM, while DD(360KB) and QD(720KB) drives are 300RPM.

Link to comment
Share on other sites

 

 

Attached is a work-in-progress version of my Hardware Manual. Information about the Atari disk drive serial protocol is in Chapter 9.6, 810 Disk Drive, and the physical disk in Appendix B, Physical Disk Format.

 

 

The pdf looks good and has heaps of info.

I was wondering if maybe you could add info for Printers that respond to different P: numbers as listed in compute here. https://archive.org/stream/1986-06-compute-magazine/Compute_Issue_073_1986_Jun#page/n111/mode/2up

 

James

Link to comment
Share on other sites

  • 2 weeks later...

Hi @phaeron,

 

I just tried dumping a floppy using Kryoflux and a Toshiba ND-0401GR 360K 5.25" drive (I think this is a similar mechanism to that used in the XF551).

 

Anyway, Kryoflux claims to have dumped both sides up to track 41 but a8rawconv complains that there's no track 42. I don't know if double-sided images dumped by this drive should be usable but here's the dump if you're curious (Test.zip):

 

https://drive.google.com/drive/#folders/0B7VbqNUi-LBvSVVJZ29lWW5rNmc

Link to comment
Share on other sites

  • 3 weeks later...

I tried using a8rawconv to write an ATX of Gauntlet Side A (obtained from Atarimania) using SuperCard Pro to a blank disk using:

a8rawconv GauntletA.atx scp1:96tpi

The resulting copy would not boot. It started loading data but then just stopped. This is using a Panasonic JU-475 drive and a DD blank disk.

 

Next, I used the SCP tool to create an .scp image file (using index mode) of my original Gauntlet disk. a8rawconv successfully created a bootable ATX from the .scp file but again, trying to write it back to a real disk resulted in a non-working copy.

 

Finally, I tried using the SCP tool to write the .scp file to the blank disk and it booted successfully. So it appears the drive, media and SuperCard Pro are all working properly.

 

Any idea why a8rawconv is not writing ATX files back successfully?

Edited by Farb
Link to comment
Share on other sites

Try imaging the copy that a8rawconv made and then re-decode that image. I've seen cases where the track write overruns the track just enough to damage the first sector. Need to put in code to measure that on the drive before determining the write length -- right now it's hardcoded at something like 99.5% of the estimated track capacity.

Link to comment
Share on other sites

Here you go:

C:\>c:\Emulators\a8rawconv.exe "Gauntlet (1988)(Mindscape)(US)(Side A).atx" scp1:96tpi
A8 raw disk conversion utility v0.7
Copyright (C) 2014-2015 Avery Lee, All Rights Reserved.
Licensed under GNU General Public License, version 2 or later.

WARNING: 1 phantom sector found for track 0, sector 17.
WARNING: 1 phantom sector found for track 39, sector 17.
WARNING: 1 phantom sector found for track 39, sector 15.
WARNING: Track 39, sectors 17 and 18 overlapped during encoding. Encoded track may not work.
Detected SCP port: COM4.
Initializing SCP device.
SCP version info: hardware version 1.1, firmware version 1.0
Detecting drive RPM... 360 RPM (actual 360.00 RPM)
Writing track 0: 76316 bytes, delay 0.06
Writing track 1: 85216 bytes, delay 0.43
...
Writing track 39: 56582 bytes, delay 0.06

C:\>c:\Emulators\a8rawconv.exe scp1:96tpi gauntlet-bad.atx
A8 raw disk conversion utility v0.7
Copyright (C) 2014-2015 Avery Lee, All Rights Reserved.
Licensed under GNU General Public License, version 2 or later.

Detected SCP port: COM4.
Initializing SCP device.
SCP version info: hardware version 1.1, firmware version 1.0
Detecting drive RPM... 360 RPM (actual 360.03 RPM)
Reading track 0
Reading track 1
...
Reading track 39
Writing ATX file: gauntlet-bad.atx
WARNING: 1 phantom sector found for track 0, sector 17.
WARNING: 1 phantom sector found for track 39, sector 15.
WARNING: Missing track 39, sector 18.
1 missing sector, 2 phantom sectors, 0 sectors with errors

gauntlet-bad.atx.zip

Link to comment
Share on other sites

WARNING: Track 39, sectors 17 and 18 overlapped during encoding. Encoded track may not work.

 

This is bad. It means that the current encoding parameters are producing a long track that can't fit, in this case because there are 20 sectors on the track instead of 18. Use the -p parameter to speed up the bit clock a bit until the track fits, and you should be able to get this to work.

Link to comment
Share on other sites

 

This is bad. It means that the current encoding parameters are producing a long track that can't fit, in this case because there are 20 sectors on the track instead of 18. Use the -p parameter to speed up the bit clock a bit until the track fits, and you should be able to get this to work.

 

 

I tried values of 50, 60 and 90 for -p. 90 seemed to to the trick.

Link to comment
Share on other sites

Version 0.8:

  • Fixed bug where long sectors were being encoded into ATX with CRC errors. This shouldn't be set since the FDC won't have checked the CRC by the time the drive CPU reads the FDC status.
  • Fixed unnecessary "multiple good sectors with same data" warning when the first sector checked in a group was a bad read.
  • Added support for reading Apple II 5.25" disks. DO/DSK and NIB formats are supported for output.
  • Backed off the write length by 0.5% to try to avoid track overruns when writing physical disks.
  • Redid the formatting of warning messages a bit to make it easier to read when lots of weirdnesses are found.
  • Added a manual.

 

a8rawconv-0.8.zip

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

This just keeps getting better!

 

@phaeron - Have you considered adding the ability to diff ATX files? As you already know, since the ATX format allows the same disk to be represented in different ways, it's usually impossible to determine differences using file checksums. I realize that things like weak sectors make it extremely difficult to know for sure even based on content, but I imagine there would be some usefulness in knowing that two ATX files have the same stable data and whether the unstable data was located on the same area of the disk.

Link to comment
Share on other sites

  • 2 months later...

Pretty basic problem -- Kryoflux dumps are just raw track dumps, so a8rawconv can't tell whether they were dumped as 48tpi or 96tpi, and currently it always steps by 2 since it assumes 96tpi. I need to add an option for this.

 

It would be great if you would add this option. I use Mitsumi D503V 48tpi drive (originaly built into Atari XF551). I've dumped several disk using this drive and KryoFlux but I can not convert them. a8rawconv converts track 0 only and it can not find any sectors on the other tracks.

 

I used this command line when I dumped Hydraulik game by ASF:

DTC.exe -l15 -fG:\KryoFlux\Hydraulik\track -g0 -i0 -k1 -i4a -s0 -e39 -os0 -oe39 -d0 -t10 -r10 -dd0 -x1

I attached a raw stream files of this game.

Hydraulik (raw files).rar

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

Update to 0.9:

  • Fixed incorrect ATR header for enhanced density disks.
  • Fixed auto decoder selection to choose GCR decoder for Apple II disk formats.
  • Tweaked Apple II GCR decoder.
  • Added distance restrictions to IDAM/DAM matching to handle IDAM/IDAM/DAM/DAM pattern from interleaved sectors, since real FDCs will reject a DAM that is too close or too far away from the IDAM.
  • ATX writer now warns if the disk being encoded is a medium/enhanced or double density disk, which cannot be encoded in ATX.
  • Fixed encoding of ATX sector flag bits 5 and 6, which was incorrectly using 810-style signaling; bit 6 is now written properly as an extended data indicator and bit 5 alone reports the DAM.
  • Added -tpi switch to read KryoFlux raw stream sets created with a 48 TPI drive.
  • Added -I switch for easier checking of Apple II text data, which has the high bit set by default.

That Hydraulik dump is rather interesting, as it's something I'd suspected existed but hadn't seen yet: a copy-protected MFM encoded disk. Bad news is that ATX can't encode MFM disks, so currently we're stuck without a file format to decode this to. Might have to finally sit down and spec out an extended ATX format.

 

a8rawconv-0.9.zip

  • Like 1
Link to comment
Share on other sites

Sidenote:

 

Many of the commercial programs by german AMC-Verlag did use 130k format and copy-protection... (There was a german program to analyze and create various copy-protections, named "Diskmaster 1050", afaik all AMC-Verlag programs used this program to create the different copy-protections. Would be nice to find this german Diskmaster 1050 program online somewhere - and no, its NOT the Diskmaster program by BBK...)

Link to comment
Share on other sites

Wow, these are some weird disk images. Mixed SD+ED, and looks like one even has remnants of DOS formatting on it. Is it actually possible to read mixed FM and MFM on a stock drive? I don't see provision for it in the 1050 firmware and the first couple of games I have tried worked fine after simply removing the MFM sectors.

Link to comment
Share on other sites

No, it's impossible to read mixed densities on stock drive like 1050 or XF551. For instance, disk drive reads tracks in SD, but when it suddenly encounters track formatted in ED, it assumes that this track is unformatted or with badsectors. The 1050 or XF551 with stock firmware can not change density "on the fly" and this copy protection takes advantage of this feature. I think that this type of copy protection is worth preserving in extended ATX format. :)

Edited by voy
Link to comment
Share on other sites

Well, the thing is, if the drive is just going to do format detection based on track 0, there's no point for those tracks to exist -- the FDC isn't going to see them. They might as well have been left unformatted. It looks like these were low-run manually duplicated and the disks were formatted first as ED or PC 360K before being partially formatted as SD. That works if you don't have a bulk eraser, but in that case the data on those tracks is irrelevant as long as it's not FM. We wouldn't need an extended format because encoding the FM tracks alone in ATX would work fine.

 

ED disk + FM tracks we do need a new format for, since ATX won't handle ED disks. It's possible to encode 26 sectors into the file format, but useless as existing readers would either barf or misread the image as SD.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...