Jump to content
IGNORED

Greaseweazle new DIY open source alternative to Kryoflux and SCP


ijor

Recommended Posts

2 hours ago, TheMontezuma said:

I asked in the Greaseweazle Facebook Group about 5.25 Floppy drives and got some feedback:

That's why I though you need to tell Greaseweazle to compensate the different rpm / data rate of the HD floppy drive...

 

You probably don't need this. The software you will normally use, including a8rawconv, already knows how to compensate for this automatically. So it is much better to store the dump exactly as was produced by the drive. You can always post process the data if needed in the worst case (although, again, you normally will not need it). But if the dump was somehow altered, there might be no way to go back.

 

May be the Greaseweazle software needs that for converting the dump to an ATR file image itself. If so, it is, IMHO, broken. Just convert it using a8rawconv instead.

  • Like 1
Link to comment
Share on other sites

I think I should give more details about what I did so that the information is complete and accurate.

First, the Archon disk I used is not an original. I used RespeQt to write to a real floppy disk from an ATX using a 1050 and then checked that the Archon clone disk successfully boots and works before doing anything with greaseweazle.

Second, I tried the command gw read archon.scp and it produced a scp file with almost nothing in the tracks. a8rawconv showed that only the first track had data (but some sectors where missing) and all the remaining tracks were empty. I ran the command twice and got also a bad content the second time but not exactly the same (different track 0 but still all other tracks empty)

Third, I added —double-steps and —single-sided and the scp was perfect. I ran the test maybe 4 or 5 times and always got the same successful results still with the Archon clone disk. No option about rpm or rate.

Fourth, I found an issue when running several times the same command to dump the same disk in my Panasonic. At the end of the command, the drive head is on track 80. When I issued the command again, the head does not fully come back to track 0 and the gw read fails. I have to run again the command to make it work because, the second time, the head finishes to come back to track 0. The issue can be reproduced. I think I have read something about it on the forum. It may be a known issue. I used this Panasonic drive also with a Kryoflux and the drive works fine so the issue is not in the drive.


To be fair, I don’t know if the 2 bad dumps I experienced where caused by the lack of options or not. When doing all these tests, I thought that adding the 2 options was the solution because the dumps where then OK. But now I am not so sure because I did not clean the head before trying my first 2 unsuccessful dumps. Could the issue come from the fact that the head was dirty and after 2 dumps, the head was OK again?

 

I am not at home so I can not give you the scp. But maybe you are not interested anymore in the scp now you know that it is not an original disk...

  • Like 1
Link to comment
Share on other sites

I came back home and I tried again to run the command gw read Archon.scp without any other option.

I confirm that only the first track is read successfully.

All other tracks are read as empty or unformatted.

 

That is quite strange.

Not a big deal as it works very well by using the options: --single-sided --double-step

But I am curious to know what is the problem.

 

Any other experience reading a disk from a 1.2M drive?

 

Link to comment
Share on other sites

26 minutes ago, ebiguy said:

Any other experience reading a disk from a 1.2M drive?

 

 

Today I successfully dumped two floppies (90K SD and 130K ED) with:

- Mitsumi D503 (DD drive)

- Teac 55 GFR (HD drive), which I purchased from @CharlieChaplin

 

For Mitsumi drive I used the following command:

 

gw read --revs=5 --ecyl=39 --single-sided atari.scp

 

and for Teac:

 

gw read --revs=5 --ecyl=39 --single-sided --double-step atari.scp

 

--revs=5 increases the number of revolutions from 3 (default) to 5 as recommended by @ijor

--ecyl=39 tells Greaseweazle to dump only 40 tracks (and not 80)

--single-sided because those disks are single sided

--double-step is required only for 1.2MB drives

 

Interestingly Mitsumi does not move to HEAD to TRACK 0, but once it is placed manually at this position it works.

Perhaps the drive is not fully functional, I don"t know.

Link to comment
Share on other sites

49 minutes ago, ebiguy said:

I came back home and I tried again to run the command gw read Archon.scp without any other option.

I confirm that only the first track is read successfully. All other tracks are read as empty or unformatted.

...

Not a big deal as it works very well by using the options: --single-sided --double-step

 

I think this is an a8rawconv buglet that can't process SCP 96 tpi (80 tracks) images. This in turn might be because there were some inconsistency on how the flags were marked on the SCP file header.

 

You might be able to tell by looking at the a8rawconv output in verbose mode. Or if you want to be sure, post the SCP image dumped without any options. I'll check it and let you know.

  • Like 1
Link to comment
Share on other sites

12 minutes ago, TheMontezuma said:

--revs=5 increases the number of revolutions from 3 (default) to 5 as recommended by @ijor

--ecyl=39 tells Greaseweazle to dump only 40 tracks (and not 80)

 

Again, please dump one more track (--ecyl=40). Check the other thread for an explanation.

 

Link to comment
Share on other sites

57 minutes ago, ijor said:

Or if you want to be sure, post the SCP image dumped without any options. I'll check it and let you know.

Cool!

I uploaded 2 files in my drive (too big to put on AtariAge and not very useful to keep them forever).

The first one is Archon_greaseweazle.zip

https://drive.google.com/file/d/1aCeVPGvgE5Bj-k9ZoA-gLJMOnYV4cN_5/view?usp=sharing

This archive contains 2 files:

- AtariTitle_double_step_single_sided_OK.scp

- AtariTitle_no_option_KO.scp

No need for more explanation I guess.

The second one is Archon_kryoflux.zip

https://drive.google.com/file/d/1kxpvfCnZYWraOiU-hhBglFf-ztLE34Ss/view?usp=sharing

If contains a dump of the same disk but with a Kryoflux just in case you want to compare...

 

EDIT: This is my post #500 !!!

Ok, no one cares but now I am a Dragonstomper

Edited by ebiguy
  • Haha 3
  • Confused 1
Link to comment
Share on other sites

7 hours ago, TheMontezuma said:

Do you mean this one?

 

 

Yes. Basically track 40 (the 41th track) might contain extra information such as duplicator signature. Many times is blank. But the extra time and the extra storage space for the extra track is not very significant, so it is worth to include it.

Link to comment
Share on other sites

6 hours ago, ebiguy said:

I uploaded 2 files in my drive

- AtariTitle_no_option_KO.scp

...

EDIT: This is my post #500 !!!

Ok, no one cares but now I am a Dragonstomper

 

The image seems to be ok. As I suspected, it is just the 96 tpi layout that is not interpreted correctly by most tools including a8rawconv.

 

Congratulation on your new title! :)

Link to comment
Share on other sites

49 minutes ago, ijor said:

The image seems to be ok. As I suspected, it is just the 96 tpi layout that is not interpreted correctly by most tools including a8rawconv.

I'm afraid it's not that simple.

 

Attached is an SCP image of the Altirra additions disk, imaged by version 1.9 of the official SCP software in Atari 800 mode, the version of the software that I last used. If you look at the header:

  • The type byte $04 is $10, for Atari.
  • The flags byte $08 is $06, which means 360 RPM and a 96 tpi drive in splice mode. This is correct, as I used a dual 1.2M/1.44M combo drive to image the disk.
  • The sides byte $0A is $00. The SCP spec at the time did not specify what this meant besides "older version of SCP software", but newer specs have clarified that this means two sides. This is also correct, as the imaging software did image 40 tracks on both sides of the disk (verified both in the UI, and by the sound of the disk mechanism).
  • The track list contains 80 tracks, densely packed in entries 0-79. This is the questionable part, as arguably this should have been double-spaced due to the 96 tpi flag.

Now, looking at the AtariTitle_no_option_KO.scp file:

  • The type byte $04 is $80, for other. Reasonable.
  • The flags byte $08 is $03, for 300 RPM, 96 tpi, and index mode. Fine so far.
  • The sides byte $0A is $00, so two sides.
  • The track list contains 162 tracks (81 * 3). Uh oh.

I'm not sure what the proper way is to interpret the track list with both of these cases. Relying on the type byte is a possibility, but doesn't seems supported by the spec (although the subtypes for Atari do indicate sides, which is conflict with the $0A heads byte).

 

Now, I haven't upgraded to the newest SCP 2.2 version, so it's possible there was an issue there that was since corrected, but this still makes it tricky to interpret existing images.

 

Additions-SCP1.9-96tpi-Atari800Profile.7z

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

15 minutes ago, phaeron said:

I'm afraid it's not that simple.

...

Now, I haven't upgraded to the newest SCP 2.2 version, so it's possible there was an issue there that was since corrected, but this still makes it tricky to interpret existing images.

 

I agree, that's why I said earlier there is an issue of how the flags at the file header are used inconsistently. Some images produced by older version of the SCP software are even worse.

 

Perhaps a command line option to force a specific interpretation of the track list would be appropriate.

 

Link to comment
Share on other sites

2 hours ago, phaeron said:

The track list contains 162 tracks (81 * 3). Uh oh.

I don't understand.

162 is 81 * 2 (at least in France ;) ) which seems OK.

Or do you mean that I should have set the --ecyl=79 (end cylinder) to be sure that the track list contains only tracks 0-79 instead of 0-80?

 

EDIT: I think I understood your point: you mean that the track list should always contains 80 (or 81) tracks regardless the number of sides...

So it means that the issue is not the --double-step (the generated SCP file would probably be good with or without this option) but the --single-sided which is MANDATORY to get a track list of 40/80 tracks instead of 160 tracks.

I tried a new dump (same Archon disk) with only --single-sided which means that I still dump 80 tracks but one side only.

It does not work. Same result. Here it is.

https://drive.google.com/file/d/1rgkokRnpkIliiFOInLjSxnrnEXSvbgEn/view?usp=sharing

Edited by ebiguy
Link to comment
Share on other sites

17 hours ago, ebiguy said:

I don't understand.

162 is 81 * 2 (at least in France ;) ) which seems OK.

Or do you mean that I should have set the --ecyl=79 (end cylinder) to be sure that the track list contains only tracks 0-79 instead of 0-80?

EDIT: I think I understood your point: you mean that the track list should always contains 80 (or 81) tracks regardless the number of sides...

 

No. The problem is that there wasn't a consistent usage on how the options were flagged, and how the tracks were packed or interleaved at the file header. So it is difficult to detect and match the tracks exactly for single sided 96 tpi images.

 

Just use double stepping and there would be no problem.

 

17 hours ago, TheMontezuma said:

What about the images with dumped 40 tracks? Do they look less confusing for a8rawconv?

 

 

I didn't check the images. But yes, the problem is only with 96 tpi images.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
On 7/26/2020 at 1:48 AM, JimDrew said:

@phaeron,

 

Last month I clarified the track layout for single sided disks in the .SCP specification.  I also added the some of the new information for the RLL/MFM hard drive and tape drive support that is coming.

 

https://www.cbmstuff.com/downloads/scp/scp_image_specs.txt

I finally got around to looking at this and trying to update a8rawconv's SCP image I/O routines, and I'm afraid I still don't understand how to distinguish between SCP images that have 40 tracks/side and 80 tracks/side stored in the image. Updating to SCP 2.20 software did not change the way the images were written out, so it's not an old-bug issue.

 

With SCP 2.20, imaging the same Atari single-density disk on a 96tpi drive gives the following file headers:

 

Atari 400/800 mode (40 tracks, 2 sides dumped):

00000000: 53 43 50 22 10 02 00 4F-06 00 00 00 C8 BA 40 2B

 

IBM 360K mode (40 tracks, 2 sides dumped):

00000000: 53 43 50 22 40 02 00 4F-06 00 00 00 3C 59 3F 2B

 

IBM 720K mode (80 tracks, 2 sides dumped):

00000000: 53 43 50 22 44 02 00 9F-06 00 00 00 C1 D6 4C 45

 

In all cases, the track list was densely packed, containing 80 or 160 track entries with no gaps. As can be seen from the header dumps above, all images indicate 96 TPI. The only difference between the 40 and 80 track images is the disk type and the track range. As you might expect, a8rawconv can decode the first two images but not the third, because on the third it sees the half-tracks and thus fails to decode anything beyond track 0.

 

So the question remains -- how is a program reading an .SCP image supposed to determine the mapping between an entry in the track table and the physical track number on a 96 TPI drive? Presumably it can't be the track range, as it wouldn't be possible to distinguish between a full image of a 40-track disk and a half-image of an 80-track disk. I hope it's not the disk type, because then a8rawconv would have to have a lookup table of all existing disk types and wouldn't be able to handle new types, and it also isn't documented which disk types store 48 TPI or 96 TPI.

 

Link to comment
Share on other sites

Atari 400/800, Commodore, Apple II, TI-99/4A, and other single sided formats should only be dumping one side and the tracks are laid out in the image file like it has half-tracks (blank if they are not enabled).  So a 40 track disk looks like an 80 track disk.

 

Here is a conversation with Jeff (HxC) about single sided disks.  This might help explain things better...

 

https://torlus.com/floppy/forum/viewtopic.php?f=2&t=3865&p=22674&hilit=scp#p22674

 

 

 

Edited by JimDrew
Link to comment
Share on other sites

16 hours ago, JimDrew said:

Atari 400/800, Commodore, Apple II, TI-99/4A, and other single sided formats should only be dumping one side and the tracks are laid out in the image file like it has half-tracks (blank if they are not enabled).  So a 40 track disk looks like an 80 track disk.

 

Here is a conversation with Jeff (HxC) about single sided disks.  This might help explain things better...

The Atari 400/800 mode of the SCP 2.20 software does not produce a single-sided image, however. It double-steps a 96tpi drive to dump 40 tracks on both sides of the disk. You can see from the above hex dumps that the Atari 400/800 mode disk uses a mode byte of $10, which is disk_AtariFMSS.

 

The linked conversation appears to confirm that the only way to determine the mapping from the TDH entries to physical tracks is to use the manufacturer/disk type. As I've mentioned previously, this is problematic for three reasons:

  • The program reading the SCP image needs to know about all disk types. It would not be able to process any new disk types added after the program was written. a8rawconv can decode enough of any 177x/179x/279x compatible format to be able to determine splice points to rewrite tracks from raw flux.
  • The SCP image specification does not indicate which of the disk types are 40/80 track or single/double sided.
  • a8rawconv supports some disk formats that do not currently have a disk type mapping, such as Atari MFM enhanced density and double sided / double density, as well as blind imaging of disks with unknown format.

The interpretation you've specified also prohibits dumping of half tracks for double-sided 40-track disk types, which seems like a strange limitation.

 

Ideally, the TDH would either always have been spaced out for 80 tracks / double sided, or a flag in the header to indicate the track spacing. But if that isn't possible, then at least we need the track count and sides for each of the disk type definitions in order for SCP image interoperability between tools to be possible and reliable.

 

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