Support in Steem - teaser

Moderators: DrCoolZic, Moderator Team

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

Re: Support in Steem - teaser

Postby Steven Seagal » Fri May 15, 2015 8:30 am

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


Good news is that there will be 7z support in next version of Steem, but decompression will be slower than RAR (using unrar.dll), quite noticeable for big files.
I'm using ArchiveAccess.dll for 7z.

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

Re: Support in Steem - teaser

Postby JimDrew » Fri May 15, 2015 2:27 pm

Hmmm. 7z files are noticeably faster to decompress than RAR on my system. I am using Total Commander for decompression, so I will check what .dll is being used by it.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Support in Steem - teaser

Postby DrCoolZic » Fri May 15, 2015 3:06 pm

Just discovered this thread :(
very interesting despite the fact that there are a lot of incorrect information about fuzzy bits, bit decoding, and NFA 8O

But excellent job as usual Mr Seagal :mrgreen:

Not sure? did you fix the Jupiter master drive hard to decode sync sequence?

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

Re: Support in Steem - teaser

Postby Steven Seagal » Fri May 15, 2015 9:36 pm

DrCoolZic wrote:Just discovered this thread :(
very interesting despite the fact that there are a lot of incorrect information about fuzzy bits, bit decoding, and NFA 8O


I'm interested in correct information about fuzzy bits at any rate, that's the only part that is so so in Steem's support of SCP.

But excellent job as usual Mr Seagal :mrgreen:

Not sure? did you fix the Jupiter master drive hard to decode sync sequence?


No special fix is needed for reading.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Support in Steem - teaser

Postby DrCoolZic » Sat May 16, 2015 8:20 am

Steven Seagal wrote:
DrCoolZic wrote:Just discovered this thread :(
very interesting despite the fact that there are a lot of incorrect information about fuzzy bits, bit decoding, and NFA 8O


I'm interested in correct information about fuzzy bits at any rate, that's the only part that is so so in Steem's support of SCP.

I do not want to reopen a sterile discussion about fuzzy bits as everybody stays on his position: Jim thinks that it can always be detected in one revolution, Jeff / IFW and myself believe this is wrong. The definition of fuzzy bits (as per patent definition) is read multiple time (the patent says three times) the data and compare: if different ==> fuzzy.
In general it is possible to predict that some transitions will never produce fuzzy bits but not the opposite. For example totally out of band transitions will not generate fuzzy bits if placed correctly.
With only one revolution you may try to play some tricks (simulate seed rotation variation) but I am not sure this will work in all cases.
As you mention in this thread the fuzzy bits of type Dungeon master requires to have a relatively good DPLL to be detected correctly.

But excellent job as usual Mr Seagal :mrgreen:

Not sure? did you fix the Jupiter master drive hard to decode sync sequence?


No special fix is needed for reading.


As said the first part of importance to decode correctly information, and especially fuzzy bits, is the DPLL process on input transitions (conversion from flux transitions to bits)
The second important part is of course correctly decoding these bits into bytes. The state machines inside WD1772 are not always intuitive! One difficult part is the decoding of sync marks. Here you need at least two information:
- the actual sync character received (so for example you can check for a sequence of 3 A1) and
- the output of the shift register
because as you know actually both do not match in many cases.
For example the traditional 3 "A1" sequence does result in the detection of 3 4489 but the shift regiter gives 14 A1 A1.

In the case of Jupiter masterdrive and others there is a hard to decode sequence (Thanks to IFW to provide the correct state machine) of C2 followed by A1 that decode as C2 0B (On an Atari you provide 29 f5 f7 f7 to the write track command) this is explained here viewtopic.php?f=104&t=27448&hilit=wd1772#p265938

If you are reading it correctly this mean congratulation you did the right thing (i.e. the right state machine) :)

jmd.PNG
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Support in Steem - teaser

Postby DrCoolZic » Sat May 16, 2015 8:49 am

Two extra comments:

scp format does not provide a field (and does not have the capability in current fw) to indicate the position of the first transition relative to the index. In most cases it is irrelevant but this a problem for large NFA over the index. There is a trick to compute roughly the NFA position on a multiple revolutions image. However having wrong information should not be a problem for simulation as the position of the NFA is not tested in the protections.

About single versus multiple revolutions images and compression.
I do not understand why people want to limit to one revolution and/or compress their images to save space ??? saving disk space was important in the 80s on a 10 MB hard disk but who care today??? This must be reminiscence / nostalgia from the past or for fun ???

My test directory contains about 650 images non compressed and most of them are 5 revolutions and it takes maybe 10 to 20 GB (hard to measure because also contains a lot of extra information: png, stx, txt, pdf, results ...).
On my 6 TB disk this is less than 0.2% of the disk !!!
*Today a 1 TB disk is only about 50$ so go buy new disks

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

Re: Support in Steem - teaser

Postby Steven Seagal » Sat May 16, 2015 10:03 am

The "jupiter" sequence may be hard to write, but it seems to decode fine in all sorts of formats, SCP, CTR, STX, STW, HFE. A nice ST project would be a smarter copier.

If you read back this thread you'll see how I "solved" those little DPLL/data separator issues, my usual way!
By the way, you may want to check your reference for the WD1772 DPLL? I think it's 4808884, you took the one for the Amiga!

About SCP index I tried to discuss it in this thread. You need either a doctored single rev (based on multiple revs) or 2 revs for emulation, because common drives have imprecise IP timing.

As for compression, people do what they want, Steem will support about everything (not lzh :().
It's a real trade-off space/time.
Example: I have a laptop connected to a desktop computer via M$'s system: not superfast, so it may be quicker to use a 7z file in that case.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Support in Steem - teaser

Postby DrCoolZic » Sat May 16, 2015 2:07 pm

Steven Seagal wrote:The "jupiter" sequence may be hard to write, but it seems to decode fine in all sorts of formats, SCP, CTR, STX, STW, HFE.

Great

If you read back this thread you'll see how I "solved" those little DPLL/data separator issues, my usual way!
By the way, you may want to check your reference for the WD1772 DPLL? I think it's 4808884, you took the one for the Amiga!

Any reasonable floppy disk controller DPLL should work but patent 4808884 https://docs.google.com/viewer?url=pate ... 808884.pdf looks very interesting thanks for the pointer

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

Re: Support in Steem - teaser

Postby JimDrew » Sat May 16, 2015 6:14 pm

DrCoolZic wrote:Jim thinks that it can always be detected in one revolution, Jeff / IFW and myself believe this is wrong. The definition of fuzzy bits (as per patent definition) is read multiple time (the patent says three times) the data and compare: if different ==> fuzzy.


I am sorry that you guys haven't figured out how to determine "fuzzy bits" in a single revolution. I did, and if that were not the case then you couldn't write back a single rev .scp image to disk and have it work.

NFA over index also works in a single revolution (that's why we can write it back to disk). You just have to check to see if the beginning and the end of the track are both NFA, and if so consider them as one continuous NFA.
I am the flux ninja

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

Re: Support in Steem - teaser

Postby Steven Seagal » Sun May 17, 2015 9:34 am

DrCoolZic wrote:Any reasonable floppy disk controller DPLL should work but patent 4808884 https://docs.google.com/viewer?url=pate ... 808884.pdf looks very interesting thanks for the pointer


The CPU speed is different, so parameters are different.
On the ST and WD1772, 8mhz translates to "increment" = 128 for example, and 128*16==0x800.
It's simpler than with 7.1 mhz, where there's a division rest.
This algorithm is already translated to C++ in MAME/MESS but I didn't check if it's 100%.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Support in Steem - teaser

Postby DrCoolZic » Sun May 17, 2015 10:25 am

I have very modestly contributed to some bug fixes in the VHDL model of the WD1772 in the Suska project http://experiment-s.de/en/. The DPLL in this model is based on adapted patent http://info-coach.fr/atari/documents/ge ... 780844.pdf

I have interpreted some parts of this VHDL model to implement the DPLL in C++ and later on in C# and now it works fine for me.
Adjusting the "clock frequency" is relatively easy (just need a good balance between responsiveness and stability) but adjusting the position (start-stop) of the inspection window is a bit more tricky. Fine tuning all these parameters are what makes the "quality" of flux to bit decoding.

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

Re: Support in Steem - teaser

Postby Steven Seagal » Sun May 17, 2015 3:37 pm

Yes, but the emulated DPLL doesn't need to be very good, it needs to be as good and as bad as the WD1772, at least if we're emulating Atari ST.
Not so sure if that could make an actual difference though.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Support in Steem - teaser

Postby DrCoolZic » Sun May 17, 2015 4:42 pm

Well depends on what you trying to achieve.

If protections were based on exact behavior of DPLL this would be true.

But I cannot think of any protection that would suffer from having a DPLL better than WD1772, even dungeon master.
Actually having a better DPLL allow to recover FD that would not be readable otherwise on a real Atari.
For archiving purpose this turn to be a real advantage and actually it is also a good thing for emulation.

I know that you are following the thread on SCP games archival and you have probably noticed that we have report of more and more games becoming hard to image because of the quality of the FD support. We therefore need to think at better techniques to try to recover as much as possible partially damage FD. But this probably does not concern you unless you also want to interpret correctly these damage games...

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

Re: Support in Steem - teaser

Postby JimDrew » Mon May 18, 2015 6:12 am

The Amiga's "PAULA" is nothing like the WD1772. We have an exact PAULA replication in VHDL for the FPGA Arcade Replay. It even supports SCP images, but we could connect a real floppy drive at this point. The DPLL circuitry described in the patent is not exactly what was included in the production PAULA. The patented circuitry was originally created as a dedicated FDC, but before the Amiga went to production the chip was scrapped and merged into the audio and serial chip, and called PAULA. The consolidated chip has a DMA bus that could be shared. The DPLL circuitry was changed from the patent in a few areas due to down sizing to fit in the PAULA package. I spent nearly a decade working with this chip as my daily job, creating numerous products that used PAULA's FDC including one that changed the 2x color burst input clock externally through the genlock port to control the data rate to reproduce the exact bitcell times (like Rob Nothern's stuff).
I am the flux ninja


Social Media

     

Return to “SuperCard Pro Disk Copier”

Who is online

Users browsing this forum: No registered users and 1 guest