Req : "Audio Sculpture" (STX,...) even not running...

[JimDrew]

Yes, I meant track 3... and tracks 0-2/4-79 done as INDEX, with track 3 done as SPLICE. The flux data is definitely there, or it wouldn't work under STEEM - and it does perfectly. The very last thing that this program does before popping up the main screen (after the nifty intro) is check track 3 and then starts up the program. So, I guess there are several protection checks if you guys can't get it to start up the intro.

[JimDrew]

Does this program really require TOS1.02? It doesn't work with TOS2.06 under STEEM, and I think my STFM's are all 2.06, so testing may not even be possible.

Not the best config to test games! Did you consider downgrading?

I have a set of TOS1.02 ROMs, and two STFM computers. I need to make one a TOS1.02 only just for testing.

[ijor]

Well then it's more involved as far as Steem is concerned, because, leaving STOP aside, IRQ is instantly recognised by the CPU.

Recognizing a new interrupt level instantly is not correct. I seem to recall we had a thread about a program that was quite sensitive to interrupt detection timing. Don't remember if it was a game or a demo.

When drive B: isn't connected, Steem would just timeout on all WD1772 commands. So I removed that bit and now not only does AS loads ...

Ah, ok. It also works without the fix if you enable Pasti for all the drives.

[ijor]

Yes, I meant track 3... and tracks 0-2/4-79 done as INDEX, with track 3 done as SPLICE. The flux data is definitely there, or it wouldn't work under STEEM - and it does perfectly.

I don't think writing track 3 as SPLICE would help. Yes, the flux is of course there, but you can't write it back. If the protection check has some tolerance (or some kind of error) and if you use a very stable drive, then you might be able. Otherwise this disk simply can't be copied.

Jim, read the posts I linked in my previous answer to you. Don't just look at track 3 on the dump itself because in this case is not too useful. Read those posts that describe the concept of this protection. Note that while this seems to be an unique case on the ST, I do know that this protection was not that uncommon on the PC.

[JimDrew]

Yes, I read your posts, and I simply do not agree. I can reproduce *any* track exactly the same as the flux read (down to the last bit length), regardless of drive speed. In this case, track 3 (for sure) has data under the index pulse and it requires SPLICE mode (or the analyzer/editor) to duplicate it.

[dlfrsilver]

Yes, I read your posts, and I simply do not agree. I can reproduce *any* track exactly the same as the flux read (down to the last bit length), regardless of drive speed. In this case, track 3 (for sure) has data under the index pulse and it requires SPLICE mode (or the analyzer/editor) to duplicate it.

Jim, I'm afraid you did not read what one of the creators of this protection explained. Please read again !

[kodak80]

Yes, I meant track 3... and tracks 0-2/4-79 done as INDEX, with track 3 done as SPLICE. The flux data is definitely there, or it wouldn't work under STEEM - and it does perfectly. The very last thing that this program does before popping up the main screen (after the nifty intro) is check track 3 and then starts up the program. So, I guess there are several protection checks if you guys can't get it to start up the intro.

OK, I have tried writing tracks 0-2 INDEX, track 3 as SPLICE and tracks 4-79 INDEX and the disk still will not boot in my STFM.

[ijor]

Yes, I read your posts, and I simply do not agree. I can reproduce *any* track exactly the same as the flux read (down to the last bit length) ...

You can reproduce anything except the exact original behavior of the write splice itself. And by that I mean what exactly do you read at the write splice area. If you could reproduce the write splice, then you wouldn't need to use INDEX or SPLICE mode, you would write anything in a circular fashion.

In this case, track 3 (for sure) has data under the index pulse and it requires SPLICE mode (or the analyzer/editor) to duplicate it.

This isn't a "typical" under the index data that has the write splice displaced from the index. This track has data under the very same write splice, sort to speak.

The concept of this protection is that it leaves you without any reasonable write splice point position. All the circular data on the track is checked and verified. On any other track there is always (at least) a small area, the write splice point, that can be used as scratch. The exact content of that area normally doesn't matter because it is expected to be different on every original copy of the disk. In this case however, the exact content of the write splice matters and is verified.

This is at least in theory. So as I said already, unless they made a mistake or both they allow enough tolerance in the protection check and you are very lucky, then you can't copy this track.

[Brume]

Just to be sure: could we consider the dumps I made (STX, SCP & RAW) as safe?
Jim Drew said in a previous message that the first disk is a bit dirty.
Aufit displays a clean picture of this disk and I can't see dirt in the used sectors:

Audio Scuplture 1.3.png

Does is it mean the 5 rev have corrected the image ? Or do I miss something?
Last but not least, do I have to redump the disk in SCP format ?
Let me know.
Thanks in advance.

[JimDrew]

I read those, thanks. Does this program really require TOS1.02? It doesn't work with TOS2.06 under STEEM, and I think my STFM's are all 2.06, so testing may not even be possible.

From a quick test under Hatari, it crashed with TOS 2.06, but at least it's after the protection check. So if you manage to write the disk and reach the expose software intro with a moving background, then it means the disk was correctly written.

From what I can see (under STEEM) the main protection check occurs AFTER the intro screen - right before the main program screen appears.

[JimDrew]

Yes, I read your posts, and I simply do not agree. I can reproduce *any* track exactly the same as the flux read (down to the last bit length) ...

You can reproduce anything except the exact original behavior of the write splice itself. And by that I mean what exactly do you read at the write splice area. If you could reproduce the write splice, then you wouldn't need to use INDEX or SPLICE mode, you would write anything in a circular fashion.

You're absolutely correct, and SCP uses the INDEX pulse merely as a reference point in SPLICE mode. This mode writes 1+ revolutions and stops at a write splice, shrinking/expanding the bitcell times so the write splices overlap each other in the original position. The only problem with this is that sometimes a write splice can not be detected when the write splice ends up being a valid bitcell length. Typically this is not the case though, and with ST disks it's not uncommon to have multiple write splices - and any of them will work.

In this case, track 3 (for sure) has data under the index pulse and it requires SPLICE mode (or the analyzer/editor) to duplicate it.

This isn't a "typical" under the index data that has the write splice displaced from the index. This track has data under the very same write splice, sort to speak.

The concept of this protection is that it leaves you without any reasonable write splice point position. All the circular data on the track is checked and verified. On any other track there is always (at least) a small area, the write splice point, that can be used as scratch. The exact content of that area normally doesn't matter because it is expected to be different on every original copy of the disk. In this case however, the exact content of the write splice matters and is verified.

This is at least in theory. So as I said already, unless they made a mistake or both they allow enough tolerance in the protection check and you are very lucky, then you can't copy this track.

Write splices on each track are easy to identify with this program. As long as the write splice occurs in the exact same bit position as the original it will work, no exceptions. I probably need to enable the verify option, which will re-check the number of bitcells written and re-calculate the "shrink or stretch" value as required. The verify is validated when the write splice occurs in the same position as the original flux.

[JimDrew]

Just to be sure: could we consider the dumps I made (STX, SCP & RAW) as safe?
Jim Drew said in a previous message that the first disk is a bit dirty.
Aufit displays a clean picture of this disk and I can't see dirt in the used sectors:
Audio Scuplture 1.3.png
Does is it mean the 5 rev have corrected the image ? Or do I miss something?
Last but not least, do I have to redump the disk in SCP format ?
Let me know.
Thanks in advance.

You can look at the flux data graphically and determine how "clean" a dump is. I used SCP's editor/analyzer to look a the flux data. Obviously the flux data is good enough to load the disk in an emulator, but it's not like it is from a brand new disk.

[Brume]

You can look at the flux data graphically and determine how "clean" a dump is. I used SCP's editor/analyzer to look a the flux data. Obviously the flux data is good enough to load the disk in an emulator, but it's not like it is from a brand new disk.

OK, thanks for the info.
So does it mean all dumps need to be made from brand new disks in order to be rewritten on other disks?

[JimDrew]

Ha! No, what I meant is that the disk is old and likely a bit dirty. The flux is not as stable as a disk that was freshly written. The image you made is fine, and seems to work in STEEM.

[npomarede]

I read those, thanks. Does this program really require TOS1.02? It doesn't work with TOS2.06 under STEEM, and I think my STFM's are all 2.06, so testing may not even be possible.

From a quick test under Hatari, it crashed with TOS 2.06, but at least it's after the protection check. So if you manage to write the disk and reach the expose software intro with a moving background, then it means the disk was correctly written.

From what I can see (under STEEM) the main protection check occurs AFTER the intro screen - right before the main program screen appears.

I don't really agree. Right after boot, protection will do a "read track" command on tracks 1, 2 and 3 (track 3 being the problematic one to copy as discussed here).
During those 3 read track (+ some read sector) most of the protection checks / decoding are done.

Then after the intro, one last "read track" on track 1 is done. It then search for byte $7F in the first 512 bytes of the track buffer, then check this $7F is followed by $92. Then 4 bytes are checked and they must match "92 07 91 90". But this is in fact roughly the same as what was tested on track 1 at start, so this read track doesn't add any real value to the protection if you manage to hack the program so far.

Nicolas

[Steven Seagal]

Recognizing a new interrupt level instantly is not correct. I seem to recall we had a thread about a program that was quite sensitive to interrupt detection timing. Don't remember if it was a game or a demo.

IPL changes when SR is updated. But if an IRQ>IPL hits the CPU right at the end of an instruction, and IPL was the same at the start of the instruction, there is no delay?

When drive B: isn't connected, Steem would just timeout on all WD1772 commands. So I removed that bit and now not only does AS loads ...

Ah, ok. It also works without the fix if you enable Pasti for all the drives.

It was a spurious fix. Today I tried to mimic Pasti. Apparently, the key is:

If the TR00* input does not go active low after 255 stepping pulses,
the WD1772 terminates operation, interrupts, and sets the Seek Error
status bit, providing the v flag is set.

If RESTORE fails to set TR00 in the status byte, TOS knows there's no 2nd drive.

[Steven Seagal]

OK, I have tried writing tracks 0-2 INDEX, track 3 as SPLICE and tracks 4-79 INDEX and the disk still will not boot in my STFM.

In this instance, the proof is in the pudding.

If I understand the protection well, it can be copied only if the write splice is exactly the same.
But even so, doesn't a write splice produce weak bits?

[JimDrew]

A write splice can certainly produce a weakbit if the bitcell time is under what is considered a "normal" bitcell length. As I stated before, the goal of the SuperCard Pro copier was to reproduce the write splice location and bitcell length. The index to index time vs. the number of bitcells read can give you the amount of time that the write is off. By adjusting the bitcell times through out the entire track, you can in fact make it so that the write splice will line up exactly where it is on the original disk, regardless of the drive speed. The drive speed bobble is something that has to be taken into consideration during this process. A verify option would insure that this works perfectly every time, but greatly increases the copy time. I should probably look at enabling the verify routine for cases like this.

[JimDrew]

It was a spurious fix. Today I tried to mimic Pasti. Apparently, the key is:

If the TR00* input does not go active low after 255 stepping pulses,
the WD1772 terminates operation, interrupts, and sets the Seek Error
status bit, providing the v flag is set.

It's interesting to note that the HxC floppy drive emulator steps 255 times as a means to get to it's command interface.

[MiggyMog]

I should get pastI out on the STE and image up my (1.4 IIRC ) originals of audio sculpture. It would be interesting to know what was changed in v 1.5. Also I think DHS has only up to 1.4. So a genuine 1. 5 is an exciting find!

[ijor]

IPL changes when SR is updated. But if an IRQ>IPL hits the CPU right at the end of an instruction, and IPL was the same at the start of the instruction, there is no delay?

I think you are mixing up the terms. IPL is the external interrupt level (what you call IRQ). The bits in SR are the Interrupt Mask ...

Anyway, and regardless the terminology. Yes, if an interrupt reaches the CPU by the end of the instructions it would be delayed even if SR was not changed.

If RESTORE fails to set TR00 in the status byte, TOS knows there's no 2nd drive.

Yes, this is the only reliable way to distinguish between a drive with no disk and no drive. It is used by TOS not only for detecting if there is a second drive, but also if there are any drives at all.

[ijor]

Last but not least, do I have to redump the disk in SCP format ?

Didn't you say you have two copies? If you have a second copy it might be a good idea to dump it. If it is a different version then of course it would be valuable. But in this particular case, even if it is the same version it might be useful as every copy has a different key.

[ijor]

As long as the write splice occurs in the exact same bit position as the original it will work, no exceptions.

If you could write it at exactly the same position it should work. But you cannot, you can only approximate it, mainly because the rotation is not constant.

I probably need to enable the verify option, which will re-check the number of bitcells written and re-calculate the "shrink or stretch" value as required.

As I said already, if the drive is stable enough and you retry enough times, you might be able to produce a track with the same number of transitions. But this might not be enough to make it work. The protection check doesn't just count bits (or flux transitions for that matter). The protection check reads the actual data under the write splice. And the data read on the write splice depends not only on the number of transitions but also on the distance between the last flux transition and the first one. If it is difficult to write exactly the same number of transitions as the original, matching the PLL distance if even much more difficult.

But again as I said, hopefully the protection check has some tolerance and doesn't require exactly the same data. I think I've seen it has in this case (but apparently some PC titles don't have any tolerance).

If it has some tolerance, if the drive rotation is stable, if you implement that verification, and if you retry enough times, then it might work.

[JimDrew]

I don't think you have worked with actual flux much. I think you are thinking in terms of the WD1772 (or even MFM). You can certainly write a track with the exact same number of bitcells, and it doesn't matter where the index pulse is. You don't really need that much fiddling for flux. The only thing you really have to determine is the drive speed of the target drive. It's not a "luck" thing.

[Steven Seagal]

IPL changes when SR is updated. But if an IRQ>IPL hits the CPU right at the end of an instruction, and IPL was the same at the start of the instruction, there is no delay?

I think you are mixing up the terms. IPL is the external interrupt level (what you call IRQ). The bits in SR are the Interrupt Mask ...

Anyway, and regardless the terminology. Yes, if an interrupt reaches the CPU by the end of the instructions it would be delayed even if SR was not changed.

Yes, and excuse me for making you repeat yourself, but I reckoned there was some ambiguity.
Blame Steem authors, they call the mask SR_IPL.
So I can confirm Steem doesn't do that at all (for the moment ).