Fake index for index-less reads

[keirf]

User request:

For the purpose of this question let us assume that the disk to be read has only one index hole. If it would have two of them, you would just flip the disk and read the other side - so nothing to be unclear.

At least for the Panasonic JU-475-4 there are some jumpers which allow when set properly reading the back side by flipping the disk without a second index hole. I have tried that with my SuperCard Pro and the software setting "Index hole: Ignore" (instead of Index hole: "Required") and it works out of the box with a floppy not modified otherwise.

I am pretty sure the floppy is not generating any index hole signal at all with the disk inserted that way, but it works from the view of the drive.

So the question is if GreaseWeazle currrently supports this mode of operation or will support it with a firmware update?

The big advantage is that jumper setting is possible for many people, but drive modification is only possible for somehow experienced people.

[keirf]

The answer is that the firmware supports it, but the tools currently do not.

For read: Does Supercard Pro software fake an index in the generated SCP image file? I could do that in the tools for sure, for example:

gw read --fake-index --rpm=300 --revs=2 a.scp

Could read 400ms of flux, and immediately fake out index pulses 200ms spaced.

For write: Yeah that could be done, probably needing --fake-index and/or --rpm flags too.

[keirf]

Here is a build implementing what you desire. To use it, the gw read, write, erase commands all have a new option --fake-index=N where N is the RPM of the index signal you want to fake (probably 360rpm as most PC HD 5.25 drives spin always at that rate). https://github.com/keirf/greaseweazle/suites/5086344624/artifacts/151700732

If you are not logged in to Github, use this link instead: https://nightly.link/keirf/greaseweazle/actions/artifacts/151700732.zip

[markusC64]

Wow, that's great.

"gw read --fake-index" is working really good.

Regarding "gw write":

C:\temp\flippy>gw write --fake-index=360 1.scp TEST/PRE-RELEASE: commit 9b88070683a9ba735c34c9a036d49e0309d9b878 Use these tools ONLY for test and development!! Writing c=0-81:h=0-1 Traceback (most recent call last): File "C:\Users\runneradmin\AppData\Roaming\Python\Python38\site-packages\cx_Freeze\initscripts__startup__.py", line 113, in run File "C:\Users\runneradmin\AppData\Roaming\Python\Python38\site-packages\cx_Freeze\initscripts\Console.py", line 15, in run File "gw.py", line 99, in File "D:\a\greaseweazle\greaseweazle\greaseweazle-tools-9b88070\scripts\greaseweazle\tools\write.py", line 220, in main File "D:\a\greaseweazle\greaseweazle\greaseweazle-tools-9b88070\scripts\greaseweazle\tools\util.py", line 217, in with_drive_selected File "D:\a\greaseweazle\greaseweazle\greaseweazle-tools-9b88070\scripts\greaseweazle\tools\write.py", line 67, in write_from_image TypeError: flux_for_writeout() got an unexpected keyword argument 'cue_at_index'

Well, there's one improvement that would help even more: --fake-index=N with N being either: a) fractional, so one can use the fractional output of "gw rpm" from the other side b) [if larger than 1000 or so] the time per rotation in 25ns clocks (i. e. in clocks of .scp).

You see, the same parameter can take a) and b) deciding on the size of input. If less then 1000 or so, obviously rpm is ment. If larger, obviously rpm cannot be ment, so time per rotation must be ment.

[keirf]

Ah yes "gw write" is incomplete. Supporting raw-flux files needs some implementation work. Tomorrow probably. Writing from sector images and HFE would work. But not SCP and Kryoflux.

Floating point index value makes sense. I'll implement that.

Is the overloaded form that accepts SCP clocks too actually useful? What's the use case / workflow there?

On Thu, Jan 27, 2022 at 6:25 PM markusC64 @.***> wrote:

Wow, that's great.

"gw read --fake-index" is working really good.

Regarding "gw write":

C:\temp\flippy>gw write --fake-index=360 1.scp TEST/PRE-RELEASE: commit 9b88070 https://github.com/keirf/greaseweazle/commit/9b88070683a9ba735c34c9a036d49e0309d9b878 Use these tools ONLY for test and development!! Writing c=0-81:h=0-1 Traceback (most recent call last): File "C:\Users\runneradmin\AppData\Roaming\Python\Python38\site-packages\cxFreeze\initscripts startup_.py", line 113, in run File "C:\Users\runneradmin\AppData\Roaming\Python\Python38\site-packages\cx_Freeze\initscripts\Console.py", line 15, in run File "gw.py", line 99, in File "D:\a\greaseweazle\greaseweazle\greaseweazle-tools-9b88070\scripts\greaseweazle\tools\write.py", line 220, in main File "D:\a\greaseweazle\greaseweazle\greaseweazle-tools-9b88070\scripts\greaseweazle\tools\util.py", line 217, in with_drive_selected File "D:\a\greaseweazle\greaseweazle\greaseweazle-tools-9b88070\scripts\greaseweazle\tools\write.py", line 67, in write_from_image TypeError: flux_for_writeout() got an unexpected keyword argument 'cue_at_index'

Well, there's one improvement that would help even more: --fake-index=N with N being either: a) fractional, so one can use the fractional output of "gw rpm" from the other side b) [if larger than 1000 or so] the time per rotation in 25ns clocks (i. e. in clocks of .scp).

You see, the same parameter can take a) and b) deciding on the size of input. If less then 1000 or so, obviously rpm is ment. If larger, obviously rpm cannot be ment, so time per rotation must be ment.

— Reply to this email directly, view it on GitHub https://github.com/keirf/greaseweazle/issues/156#issuecomment-1023518586, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGWZFWP2Q6E6XIAYGPMHBLUYGE2PANCNFSM5M5VAEQA . You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

g64conv info somescpfile.scp

reports the rotation duration in SCP clocks for every track after rotation correction from the flux data repetition recognisation. So it can be a more precise source of RPM / track duration (except a constant factor one is the reciprocal of the other).

[markusC64]

Confirmed. Although not making real sense, I'm currently writing the 1581 test demo disk to a flipped 5,25" disk. Sucessfullly ­- I can read every sector of it.

[keirf]

Here is a new build for you to try. It should hopefully work with SCP and KF. Also now you can specify --fake-index as a float value, and in various different units eg 299.56rpm or 7999955scp.

https://github.com/keirf/greaseweazle/suites/5094392768/artifacts/152171724

If you are not logged in to Github, use this link instead: https://nightly.link/keirf/greaseweazle/actions/artifacts/152171724.zip

[markusC64]

Works for me - but writing needs more tests, especially reading back the written data.

I found for reading that taking the rpm value from "gw rpm" is mot sufficient. I needed more decimal digits. I tried taking the smallest track time (in scp units) I've seen i(I might have missed one smaller) n the output of "g64conv info" (that is the largest RPM) and that worked really well. All tracks borders were in the same limit g64conv has for dumps with index. Really good.

Then I used rpm = 2.4e9 / scp_time and got an RPM value that does the same very good job.

Anyway, finding the optimum rpm value to use is another topic - reading works.

[keirf]

Did you mean writing needs more digits / needs a conservative (high rpm) estimate? That would make more sense to me I think than reading being so sensitive. Though I suppose it depends what later tools do with the dump (eg attempting to extract a perfect seamless single revolution).

[markusC64]

Well "gw rom" tells me that my drive has "360.60" or "360.61" rpm, I've seen both. But fake-index works best with 360.6055829857872. Many more digits in the number.

But I don't know how many digits are exactly needed. From the derivate of f(x)=2.4e9/x at x=360 rpm, I get that 6 decimal digits after the decimal point might be enough.

You see, I've made an scp from the first side with index and form the mesaured (corrected) track times I got the lowest. That makes sense for writing because when writing, you should not write longer than that time to be sure that nothing is overwritten at the end of the rotation. For reading, I simply tried the very same value.

[keirf]

Another option would be for me to squeeze the track slightly on write, which would be equivalent to a slightly high rpm. For example I could squeeze by 0.1%. Advantage is the track doesn't overwrite itself. Disadvantage is you will surely get a bit of splice gap (where I write 4us fluxes). What do you think?

[keirf]

You could try this yourself by trying say 361.0rpm

[markusC64]

The observation is from reading, not from writing - even if the RPM value taken is motivated from writing.

I cannot say why, but g64conv without any patch to search for the real track border is finding it within the ±10 Flux Limit that I use for scp's with index with that good fake-index value resulting in an error free g64. Larger search area means larger processing time (of cause I can patch g64conv for that, it's a one line patch), so I like good fake-index values for reading.

For reading 361 rpm is bad, because the track length from the index in the scp will be quite far away from the real track length. The more they fit, the better the .scp can be processed.

[markusC64]

For writing, the largest observed rpm together with a decent write splice mark should do it. When the write splice is not at the index, mastering hardware did nothing else.

[keirf]

Ok, I think perhaps I should leave the --fake-index implementation as is for both read and write, then? At least as is it is not trying to do anything over clever. What you put on the command line is exactly what you get.

For gw rpm I propose I print the RPM and Period to 3 decimal places. This will give precision to 1us or better. That's smaller than a bitcell, and well within mechanical tolerances. I think it should suffice?

Also I propose that on exit from gw rpm where more than one revolution has been printed, I will print a summary of min/max RPM and min/max Period, that has been observed. I can print this on ^c exit too.

How does that sound?

[keirf]

Oh, additionally I could print the average values observed in gw rpm. I think arithmetic mean of the Period would make sense, and I would then calculate the Mean RPM from that (equivalent to harmonic mean of observed RPM samples).

[markusC64]

That sounds great. Average is good, but median is great, too.

Well, regarding 3 digits: I must test if that works... it could work. Anyway, changing the number of digits is quite simple, so I guess we can just try 3 digits? Just to compare them to what g64conv reads form the scp. The latter is that I used.

[keirf]

Here is the update to gw rpm. See what you think.

https://github.com/keirf/greaseweazle/suites/5097578405/artifacts/152359057

If you are not logged in to Github, use this link instead: https://nightly.link/keirf/greaseweazle/actions/artifacts/152359057.zip

[markusC64]

Works as expected.

One minor thing: If you create an scp file with the fake-index option, then byte 8 bit 0 of the scp file should be cleared, not set.

From the spec:

BYTE 0x08 is the FLAGS byte. This byte contains information about how the image was produced. The bits are defined as follows:

Bit 0 - INDEX, cleared if the image did not use the index mark for queuing tracks set is the image used the index mark to queue tracks

[keirf]

HxC tools crash if you don't set that bit. Here I take it to mean that the image is "cued" at the fake index. Ie first revolution is a full revolution. Even though it's not cued at the real index, wherever that might be.

If HxC tools have been fixed I'd be quite happy to include partial first revolutions and always clear that bit. But then I'd never set it. So I don't think, still, you'd get the distinction between fake and non-fake that you desire.

If you would like more metadata of this sort, possibly we should use the SCP image footer definition and have a structured "User comments" section.

[keirf]

Will be incorporated into next tools release