exxos's Atari, Amiga & retro forum

Surely a better way for disk image capture would be if Greaseweazel could do a raw track capture.

i.e. Measure the time between index pulses and then record that many microseconds of flux changes and not try to interpret sectors or anything else and then just store those flux changes in the file. Sort of digitised analogue recording of the track.

If the format noted the length of the track in time then this could just be played back, either onto new media or to a computer.

stephen_usher wrote: 08 Jan 2025 11:26 Surely a better way for disk image capture would be if Greaseweazel could do a raw track capture.

i.e. Measure the time between index pulses and then record that many microseconds of flux changes and not try to interpret sectors or anything else and then just store those flux changes in the file. Sort of digitised analogue recording of the track.

That's the way the GW (and other similar devices) works. But in this case is not enough.

The problem is the write splice. That is, where the writing ends. By default it is located at the index pulse because most disks don't store any information, or protection for that matter, at that point. A few disks, either for protection or not, have what is called "data under the index". In this case one sector crosses the index pulse. If you locate the write splice at the index, you would corrupt that sector. The write splice must be displaced after the end of the sector.

So, the "write splice" is the time after the index pulse begins at which the first valid flux transition takes place? As in the minimum rotational delay of the disk.

stephen_usher wrote: 08 Jan 2025 13:12 So, the "write splice" is the time after the index pulse begins at which the first valid flux transition takes place?

It is, more or less, that. Although it is not strictly related to the index pulse. You always have a write splice, even on disk drives or platforms that don't have index pulse.

Technically it's the position where the writing is disabled (Write Gate signal is negated). At that position/time you can't control precisely what is written. You will get garbage for a couple of bits. Then it must be located at a suitable and convenient point in the track that would not corrupt any data or protection. Normally, but not always, this would be at the index pulse.

As in the minimum rotational delay of the disk.

I'm not sure I understand what you mean by that.

ijor wrote: 08 Jan 2025 14:15

As in the minimum rotational delay of the disk.

I'm not sure I understand what you mean by that.

The angular distance on the disk from the start of the track, however that is defined.

I also wanted to try this software recently since I saw someone talking about it on Facebook. I tried to get it working on my STFM equipped with a GoTek by converting the .stx from Atarimania to .hfe. Unfortunately I also saw it complaining about the disk not being protected. I realised afterwards that I converted to HFEv1 though, possibly HFEv3 would've worked better. Anyway, I set about trying to crack the software since I thought it shouldn't be so hard given modern tools like Ghidra and Hatari with its debugger... :) I'm a total noob when it comes to 68k assembly but the attached .PRG seems to work when run from a GEMDOS HDD in Hatari at least. It also seems to work fine with 0.5 MB memory, as opposed to the 1 MB requirement listed on Atarimania. Will try it on the STFM this weekend!

P.S. I hope there's no problem posting this here, as this SW is surely abandonware by now. If there's a problem I'll of course remove the attached file.

redpixel wrote: 09 Jan 2025 21:23 I also wanted to try this software recently since I saw someone talking about it on Facebook. I tried to get it working on my STFM equipped with a GoTek by converting the .stx from Atarimania to .hfe. Unfortunately I also saw it complaining about the disk not being protected. I realised afterwards that I converted to HFEv1 though, possibly HFEv3 would've worked better. Anyway, I set about trying to crack the software since I thought it shouldn't be so hard given modern tools like Ghidra and Hatari with its debugger... :) I'm a total noob when it comes to 68k assembly but the attached .PRG seems to work when run from a GEMDOS HDD in Hatari at least. It also seems to work fine with 0.5 MB memory, as opposed to the 1 MB requirement listed on Atarimania. Will try it on the STFM this weekend!

P.S. I hope there's no problem posting this here, as this SW is surely abandonware by now. If there's a problem I'll of course remove the attached file.

Hi I just tried it and got it working! 8-)

It just freezed up. It's also lost MIDI sound once too. :cry:

stephen_usher wrote: 08 Jan 2025 15:21 The angular distance on the disk from the start of the track, however that is defined.

Ah, yes, Angular position and time are equivalent as long as RPM is constant and known.

Hi All, have been watching this post with interest and eventually decided to drop by. As was stated earlier, this protection was used on a few UBIsoft games (Twinworld & Tom & the ghost).
About 8 months ago I was able to do a backup of theses games, which as you can see from these posts was not able to be achieved from an SCP file, Ijor has explained the technical reasons why and if there was a person that knows, then he is the one.

Now I have managed to do a working backup of Cosmic Puppets original disk, I achieved this by creating a homemade IPF of the disk, the same way i did the UBIsoft games.

I don't have a high res monitor so I can't test the disk on real hardware, but writing the disk and then reading back to SCP format works fine and I can see from re-checking in Aufit or HXC that it all appears good.

When writing this IPF back to disk, make sure that the NOVERIFY option is selected and the GW software must be using V1.19 or above.