Support in Steem - teaser

Moderators: DrCoolZic, Moderator Team

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Fri Apr 17, 2015 8:05 am

kodak80 wrote: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.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Fri Apr 17, 2015 8:13 am

kodak80 wrote: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.

kodak80 wrote: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 :cry:


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

Teasers:

Image


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


Image

User avatar
Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2593
Joined: Thu Dec 15, 2005 2:15 am
Location: www.atari-forum.com

Re: Support in Steem - teaser

Postby Maartau » Fri Apr 17, 2015 10:02 am

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]
- aTaRi LeGeNd,
- eLiTe.

-> My apologizes if I'm late, serious health troubles <-

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Fri Apr 17, 2015 3:41 pm

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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Fri Apr 17, 2015 9:56 pm

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
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Fri Apr 17, 2015 11:24 pm

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.
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sat Apr 18, 2015 8:51 am

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
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Sat Apr 18, 2015 3:32 pm

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.
You do not have the required permissions to view the files attached to this post.
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sat Apr 18, 2015 8:34 pm

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
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Sat Apr 18, 2015 11:55 pm

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.
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sun Apr 19, 2015 9:16 am

JimDrew wrote: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
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Sun Apr 19, 2015 6:08 pm

Steven Seagal wrote: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).
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sun Apr 19, 2015 7:11 pm

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
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Sun Apr 19, 2015 8:48 pm

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.
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sat Apr 25, 2015 9:08 am

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.

Image

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

Image
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!

Image

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

Image

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

Image

Ghostbusters II. Game looks silly but also a good test case.
Last edited by Steven Seagal on Wed Apr 29, 2015 5:51 pm, edited 3 times in total.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sat Apr 25, 2015 9:12 am

Image
Image

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

Image

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

Image
Image

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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sat Apr 25, 2015 9:18 am

And also...

Image

Bad Company, reported as trouble...

Image

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

Image

This actually scrolls fast!

Image

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

Image

Xenon 2 is also famous and certainly well protected

Image

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

Image

Hint: Forget!

User avatar
exxos
Hardware Guru
Hardware Guru
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Support in Steem - teaser

Postby exxos » Sat Apr 25, 2015 9:34 am

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% ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sat Apr 25, 2015 9:54 am

exxos wrote: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
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Sat Apr 25, 2015 4:58 pm

Nice job, Steven!
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sun Apr 26, 2015 9:22 am

Another batch. Everyday!

Image
Image

Protection passed thanks to some old Indian trick.

Image
Image

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

Image
Image

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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Sun Apr 26, 2015 9:29 am

Alternatively, in a F-29:

Image

Image

Or the good old F-16:

Image

Image


Image

Image

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

Image

Another game using READ TRACK command.

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

Image
Last edited by Steven Seagal on Wed Apr 29, 2015 5:52 pm, edited 1 time in total.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Sun Apr 26, 2015 7:45 pm

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.
I am the flux ninja

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Support in Steem - teaser

Postby Steven Seagal » Thu Apr 30, 2015 9:29 am

JimDrew wrote: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
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: Support in Steem - teaser

Postby JimDrew » Thu Apr 30, 2015 2:20 pm

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.
I am the flux ninja


Social Media

     

Return to “SuperCard Pro Disk Copier”

Who is online

Users browsing this forum: No registered users and 2 guests