Support in Steem - teaser

[Steven Seagal]

I used the link for the Beta file that was messaged me by Steven and pasted it in my browser minus the file part. The folder/directory that the files sit in is also openly visible. This was where I found the version I am using. Sorry, didn't realise that these were supposed to be private.

Not at all, I mentioned it just in case other beta testers were curious.
I don't want to spam people with incessant notices, so to check things with somebody I upload a build.
It doesn't matter if files are visible.

[Steven Seagal]

From the announcement to now where most SCP images work was a very short turnaround.

Had some days off... I mean, from missions and all.

Another game that is not working for me is R-Type (file on retrobackup FTP is [SCP-Atari ST] RType-20141015.7z). Disk 1 sits in a re-booting loop when machine is set to STE and TOS 1.62. I get a HALT ST(crash) when Steem is set to STF running TOS 1.4

It's no SCP issue but WD1772 emulation bug as shows a quick comparison with the STX version.
Thx for the report.

Teasers:





For this one you'll have to insist a bit, weak bits aren't handled that well

[Maartau]

Steven : I'll have some bugged intros/progs to send you (time to put hands on) -> will you need reversed codes ?

... and last but not least, "Great work as always" [smilie=greencolorz4_pdt_01.gif]

[Steven Seagal]

Sure.

About the index trick, it will not work anymore. Talking of the "ataristeven" website, not index pulse.
Just in case there were a sensitive file (which isn't the case AFAIK).

[Steven Seagal]

Turrican, trace when loading rev 1 and 2, track 4 of 2nd side (reading over IP):

Code: Select all

SCP LoadTrack side 1 track 4 TRK 9 rev 1/2  INDEX TIME 7981618 (199.540450 ms) TRACK LENGTH 40351 bits 40351 last bit unit 7981477 DATA OFFSET 28  checksum A100EF00

SCP LoadTrack side 1 track 4 TRK 9 rev 2/2  INDEX TIME 7981659 (199.541475 ms) TRACK LENGTH 40353 bits 40353 last bit unit 7981804 DATA OFFSET 80730  checksum A100EF00

How is it possible that number of bits is different (40353 vs 40351) ?

[JimDrew]

If you are referring to "bits" as "bitcells" (number of flux transitions), it is possible for two reasons - the drive speed variation relative to the index pulse sensor, and weakbits (caused by a write splice). This is exactly how a real floppy drive performs too. Afterall, the .scp image is just a dump of the data from index pulse to index pulse with a 25ns resolution.

[Steven Seagal]

Yes, "bits" is TRACK LENGTH, and counted too when transforming 16bit into 32bit data.
Steem sees no weak bits on this track.
Data just looks different between those revs.
Tracks are different in Aufit too, with rev 1 having 6292 bytes, rev 2 6293 bytes, different MFM decoding.
I'm looking for a way to wrap data read through IP on a SCP image without error.
When you say the copy of Turrican works on ST, do you use the version on the FTP? If yes, which rev is used?
Is it possible that track data contains info beyond IP as seems to be the case with rev 2 but not rev 1?



rev 1/2 INDEX TIME 7981618 last bit unit 7981477
rev 2/2 INDEX TIME 7981659 last bit unit 7981804

("last bit unit" is obtained by adding all 16bit delays)

[JimDrew]

The first revolution is always written back when a multi-rev image is used, and you have used the override option and force it to INDEX mode. This method is kind of hit and miss depending on how quick the drive's write circuitry can shut off. Writing in SPLICE mode works every time because the write splice itself is used to terminate the writing, which will be in the actual track gap area.

There is a weakbit, caused by the write splice. Load the image into SCP's editor/analyzer. Go to track 4, side 2 and click on the flux display. You can see the track is deliberately shifted. Look at the Minimum and Maximum bitcell times. Notice that the maximum time is way outside of the 8us window (17.7% higher). If you were to read the original disk over and over, that value, as well as the value after it (or before it, depending on the flux phase) will change every time it is read.

Clipboard01.jpg

You can also click on the FIND INVALID button and the weakbit (invalid flux) will be shown. In this case, there are two locations - one for each revolution.

[Steven Seagal]

Yes, I see the 10 us "write splice" (sorry I don't really know what it is, zone without transition?). I coded nothing special for those, unlike "odd" delays (5us etc.), guess they're managed by the DPLL part.

Here's the problem, summarised. Delays are in us.

TRK9 (1-4), reading sector 4 over the IP.

rev 1:
start 6 6 4 4 4 4 4
end 4 4 6 4 8 4

rev 2:
start 4 6 6 4 4 4 4
end 4 6 6 4 4 4 4

Or at least that's the data I see in Steem trace. What can you do with this?

correct sequence (read sector CRC OK):
end 4 4 6 4 8 4 IP start 4 6 6 4 4 4 4

Looks like it works so by chance in the case of Turrican.

What do the very 1st and very last delays of a track mean?
1st Time between IP (start - end?) and 1st transition?
Last Time to next transition, on IP or after IP?
At this level of precision, I feel the index pulse could be too gross, stopping a read at an imprecise time, but I'm no expert in hardware.

[JimDrew]

A write splice is where the hardware has turned off the write gate and as the magnetic power collapses it "smears" the bit (elongates it). This is why you see the 9.77us bitcell time.

The reason you see a difference in the total number of bit cell times vs. the index to index time is due to drive speed variation while rotating. The SCP hardware captures the index pulse as well as flux transitions with a 25ns resolution. These are independent hardware captures that are not affected by system interrupts, etc. So, these times are exactly what occurred during the revolution.

The first bitcell time occurs immediately following the start of the index pulse, and the last bitcell time is the last time before the start of the index pulse again.

[Steven Seagal]

The first bitcell time occurs immediately following the start of the index pulse, and the last bitcell time is the last time before the start of the index pulse again.

If I get it right we have something like this ("delay"=timing between transitions):

... 1 [last delay] 1 [?] IP [1st delay] 1 ...

With 1st delay before bit relative to IP.
Then we're missing some info, how many units between last bit and IP?
Or are you saying that last delay is just that, and not a delay to a transition? But I don't think so because the track may end with a 8us delay.

Here I made some more complete traces.
In the case of track 0, the rev1+rev2 trick works because rev2 starts with one '4us' bit more than rev1.
In the case of track 4, the rev1+rev2 trick works because rev1 ends with one '4us' bit fewer than rev2.
Really don't see how I could make it work with one rev, nor why bits around IP are different between those revs.

Code: Select all

***
track 0-0

With rev1:
1(4)01(6)001(6)001(4)01(8)0001(4)0 DSR $CD  257 cycles
1(4)01(6)001(4)01(4)01(6)001(4)01(8)0 DSR $C3  DPLL 130 0,0  253 cycles
001
SCP triggers IP side 0 track 0 rev 1/2
A: IP #4 (WD_NONE) CR 90 TR 0 SR 5 DR 195
(4)01(4)01(4)01(6)001(4)01(4)01 DSR $78  DPLL 129 1,0  253 cycles
(4)01(4)01(4)01(6)001(8)0001(4)01(4)0 DSR $B  255 cycles

CRC error


With rev2:
1(4)01(6)001(6)001(4)01(8)0001(4)0 DSR $CD  DPLL 129 0,0  254 cycles
1(4)01(6)001(4)01(4)01(6)001(4)01(8)0 DSR $C3  DPLL 129 0,0  253 cycles
001
SCP triggers IP side 0 track 0 rev 2/2
A: IP #4 (WD_NONE) CR 90 TR 0 SR 5 DR 195
(4)01(4)01(4)01(4)01(6)001(4)01 DSR $7C  DPLL 130 -1,0  253 cycles
(4)01(4)01(4)01(4)01(6)001(8)0001(4)0 DSR $5  DPLL 129 0,0  256 cycles

OK: there's a (4) more after ip


With rev1+2:
(4)01(4)01(4)01(4)01(6)001(8)0001(4)0 DSR $5  DPLL 129 0,0  253 cycles
1(4)01(6)001(6)001(4)01(8)0001(4)0 DSR $CD  257 cycles
1(4)01(6)001(4)01(4)01(6)001(4)01(8)0 DSR $C3  DPLL 130 0,0  253 cycles
001
SCP triggers IP side 0 track 0 rev 1/2
A: IP #4 (WD_NONE) CR 90 TR 0 SR 5 DR 195
SCP LoadTrack side 0 track 0 TRK 0 rev 2/2  INDEX TIME 7981586 (199.539650 ms) TRACK LENGTH 37912 bits 37912 last bit unit 7981605 DATA OFFSET 75850  checksum F300EC00
(4)01(4)01(4)01(4)01(6)001(4)01 DSR $7C  DPLL 130 -1,0  252 cycles
(4)01(4)01(4)01(4)01(6)001(8)0001(4)0 DSR $5  DPLL 130 0,0  254 cycles

OK

***
track 4-4

With rev1:
- (doesn't go that far)

With rev2:
(4)01(6)001(6)001(4)01(6)001(6)001 DSR $22  DPLL 130 -1,0  252 cycles
(4)01(6)001(6)001(4)01(4)01(4)01(4)01 DSR $20  DPLL 129 1,0  255 cycles

SCP triggers IP side 1 track 4 rev 2/2
A: IP #4 (WD_NONE) CR 90 TR 4 SR 4 DR 32
(4)01(4)01(6)001(6)001(4)01(4)01(4)01 DSR $10  DPLL 130 -1,-1  252 cycles
(4)01(4)01(6)001(6)001(4)01(4)01(4)01 DSR $10  DPLL 130 1,0  253 cycles

CRC error


With rev1+2:
(4)01(6)001(6)001(4)01(6)001(6)001 DSR $22  DPLL 130 1,0  254 cycles
(4)01(6)001(6)001(4)01(4)01(4)01
SCP triggers IP side 1 track 4 rev 1/2
A: IP #4 (WD_NONE) CR 90 TR 4 SR 4 DR 34
SCP LoadTrack side 1 track 4 TRK 9 rev 2/2  INDEX TIME 7981659 (199.541475 ms) TRACK LENGTH 40353 bits 40353 last bit unit 7981804 DATA OFFSET 80730  checksum A100EF00
(4)01 DSR $20  DPLL 130 -1,0  251 cycles
(4)01(6)001(6)001(4)01(4)01(4)01(4)01 DSR $20  DPLL 130 -1,0  253 cycles
(4)01(6)001(6)001(4)01(4)01(4)01(4)01 DSR $20  DPLL 130 -1,0  253 cycles

OK: there's a (4) fewer before ip

[JimDrew]

Then we're missing some info, how many units between last bit and IP?
Or are you saying that last delay is just that, and not a delay to a transition?

There are no "delays". Every entry (bitcell time) is the flux duration. After the last bitcell time, the next bitcell time comes from the start of the data again (circular buffer).

[Steven Seagal]

Well, remember, I was trying to have Turrican working with one rev, since you stated that it's all it takes, and not 2 like I believed.
Some of my questions were left unanswered, so left to my own devices here's the comment in Steem.

Code: Select all

/*  Determine which track rev to load.
    Turrican SCP will fail if we don't start on rev1 so that it reads
    sector data of rev2 over IP.
    So we make it a generality (the way it is coded, normally it will
    also do it with rev 3, 4... in the unlikely case that it's needed).
    This is because IP is by nature imprecise and won't fall on the same
    bitcell each time (unless you have mastering hardware, not mama's drive).
    One rev from IP to IP, unless "doctored", may have one or two bits too
    few or too many.
    Doing rev1 -> rev2 ensures that we use the exact same timing for IP,
    and no bit is lost or gained.
*/

I'm gladly proved wrong, of course, but this is supported by current image of Turrican: how it can work, traces when it doesn't.
Sorry that there's a little "delay" before the next beta is uploaded, but this had to be investigated.

[JimDrew]

There is nothing that can be done about the drive speed variation, this is just like a real drive. Where you start and end with rev 1 or start and end with rev 2, it doesn't matter. The results will be the same. The issue here is that the track gap is shifted relative to the index sensor. Have you tried using ALL of the revolutions that are stored in the image as a circular buffer? In the case of Turrican, 50% of the time the data will be perfect. If the protection check has a retry (which they all do), the 2nd read will pass if the 1st read failed. This is what the Amiga emulations do, and there is absolutely nothing that fails to load.

[Steven Seagal]

Of course, Steem can run Turrican, but with 2 revs, not 1. There's no "second chance", sector read must succeed.
Anyway this is the 'teaser' thread, so some more screenshots.



2nd race of Vroom, so I guess protection is passed.


Notice the new 'SCP' mention before command code, now Steem (Boiler only) will tell you on what image it's working: SCP, STX, ST, MSA, DIM, STW.
EDIT: as well as CTR, IPF!



I already commented Outrun's qualities when concerning about CTR support.
Caution, there's one SCP version that won't work.



Kick Off 2. They say it's a great game, heavy protections



Ghostbusters II. Game looks silly but also a good test case.

[Steven Seagal]

Phantasie II. Nothing special WRT protection but it's not available on the Amiga and it's a pretty cool RPG series...



This one I'm not sure. ST, CPC, apparently, it was reported as trouble to copy.




Antago, a glorified board game! Had to debug WD1772 emu for this one, I forgot timeout on READ ADDRESS command.
Hint: disk must be read-only

[Steven Seagal]

And also...



Bad Company, reported as trouble...



The Great Giana Sisters
Don't know about the protection, it's just a famous title



This actually scrolls fast!



But this doesn't scroll at all!
For those games, remember Steem supports a 'jump' button on your joystick.



Xenon 2 is also famous and certainly well protected



Fire and Forget, reported as hard to copy.
You can see it reading all those sectors on track 79.



Hint: Forget!

[exxos]

One thing which I never figured out, was on one (maybe more) text scrollers, the text does not always scroll smoothly like it does on the ST. Is that something which is fixable, or is it just not possible to emulate the timings 100% ?

[Steven Seagal]

One thing which I never figured out, was on one (maybe more) text scrollers, the text does not always scroll smoothly like it does on the ST. Is that something which is fixable, or is it just not possible to emulate the timings 100% ?

It depends on your hardware PC side. You need a 50hz or 100hz capable display.
Like I said once I have one laptop with 50hz LCD. Emulation is smooth like on a real ST.
In Steem it will even work in a window if you check SSE option 'VSync'.

[JimDrew]

Nice job, Steven!

[Steven Seagal]

Another batch. Everyday!




Protection passed thanks to some old Indian trick.




Under some circumstances you definitely want Steven Seagal on your side.




It's quite relaxing after a street brawl to take a little F-15 flight above Libya.

[Steven Seagal]

Alternatively, in a F-29:





Or the good old F-16:










Paranoid dudes, disk protection + manual.
EDIT: made a little patch for that



Another game using READ TRACK command.

Best picture saved for the end, notice the wheel and spoiler:

[JimDrew]

Well, I have gone through the vast majority of images I have, and ALL of the images that are on the Retro Backup FTP site, and I can't find anything that does not work.

[Steven Seagal]

Well, I have gone through the vast majority of images I have, and ALL of the images that are on the Retro Backup FTP site, and I can't find anything that does not work.

Of course.

About 7z vs RAR, I ran some test, and must admit that compression is far better (but slower) with 7z.
With Turrican for example, I get:
7z 4989 KB
RAR2 6866 KB
RAR5 6879 KB worse
It's no small difference.
7z support is now on the TODO list, if that's possible without too much overhead, but after v3.7.1, because beside SCP support I fixed some annoying bugs and I'd like to release it ASAP.

[JimDrew]

Yes, I think you should release it now. The 7z decompression support can come in the next version. I will also make some changes to my software so that a single rev can be extracted from a multi-rev image, and you can optionally turn off the preservation mode. This will make compressed images <2MB in size.

Decompression of 7z files is faster than RAR, but the compression is slower.