English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 22 December 2013, 12:06   #21
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
Quote:
Originally Posted by JimDrew View Post
Just because *you* didn't have the software doesn't mean it didn't exist.
Funny thing, haven't been able to find it on TOSEC either. Since this is all hardware dependent, and you seem to control it... why not put it up? You could prove me wrong and all those that have been lamenting for so long could should up, too.


Quote:
Originally Posted by JimDrew View Post
It's clear that Toni has no desire to do that, which is fine. I was just looking into as I was asked by my customers.
But they pay you, not Toni, right?
mr.vince is offline  
AdSense AdSense  
Old 22 December 2013, 13:03   #22
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,481
Some floppy questions...

Would GCR support basically be the same as 4μs/bitcell support, at least as far as the lower-level emulation is concerned? (To support something like Apple II disk image files the higher-level code would need to GCR-encode the data.)

Do some copy-protections change between 2μs↔4μs mid-track?

For writing tracks which are all or partially 4μs bitcells, can that be achieved by writing the entire track at 2μs/bitcell, but "doubling" bits in the 4μs regions (i.e. if you want to write 10101 at 4us, actually write 1100110011 at 2μs)? For reading though, I'm guessing reading 4μs-written regions at 2μs is unreliable?

The Apple II disk format uses some kind of GCR encoding. disk2file in the Apple2000 package can read Apple II disks, so presumably reads at 4μs.

The Commodore 1541 drive uses GCR encoding. The 1541 package on Aminet can read C64/1541 disks (only part of the disk unless you reduce the drive RPM slightly). Disk-2-Disk by Central Coast Software (thread where I asked about that a few years ago) can (very slowly) read entire disks in an unmodified drive. It does something strange with the drive motor to achieve that.

Maybe someone can explain a little about precompensation? MFM vs GCR precompensation (the MFMPREC bit in ADKCON) and the various precompensation settings (none/140/280/560ns). I don't think trackdisk.device uses any precompensation?
mark_k is offline  
Old 22 December 2013, 13:45   #23
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,559
GCR that Amiga can write (=extended adf support), is easy, just add missing GCR Paula stuff and its done. Probably also needs flag bit in extended adf that says "this track is GCR".

Copy protection/track having multiple "zones" requires more work. This may not be worth the trouble if there is only one or two programs that requires it.
Toni Wilen is online now  
Old 22 December 2013, 13:57   #24
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,489
Quote:
Originally Posted by JimDrew View Post
A few other people have confirmed there were games that used both GCR and MFM formats.
So far I never saw any game that used GCR. Do you have any examples?
StingRay is offline  
Old 22 December 2013, 14:26   #25
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
Mark_k,
Pre-compensation is for writing data.
What you write to a disk is often not what you want to read... certain bitcell combinations - if they are close enough - cause peak shifts, meaning making the flux transitions that make up the bitcell to appear closer or farther away than how they should be.
Pre-compensation means that affected bitcell patterns have some of their flux transitions advanced or delayed, effectively making the data during read behave as expected, rather than causing peak shifts.
Hardware based pre-compensation (e.g. Amiga or most generic FM and MFM controllers) is fairly simple and is limited to pattern matching and preset values.
Software based pre-compensation such as what Trace or KryoFlux uses are significantly more sophisticated as the data window is not limited to just 5 bitcells like in most hardware. (previous-1, previous, actual, next, next+1 bitcell)

There is also post-compensation, which is getting rid of peak shifts by assuming how the flux timings behaved based on their distance.
That is data recovery realm, and not something an Amiga could even attempt to do...

Last edited by IFW; 22 December 2013 at 14:32.
IFW is offline  
Old 22 December 2013, 14:30   #26
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
Yes, you can write some data at 2us and read it back at 4us.
However, the data window (and thus tolerance) changes in the PLL and what you can reliably read and write is extremely limited, once you consider drive speed wobble, and each drive having a slightly different RPM.
IFW is offline  
Old 22 December 2013, 14:32   #27
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,481
Does trackdisk.device use precompensation at all? Maybe that would be helpful when writing to higher-numbered tracks (nearer the centre of the disk)? I've noticed that with many disks which go partly bad, the tracks which go bad first seem to be the inner ones where data density is highest. I wonder whether diskspare.device (which can use 82 tracks) uses precompensation for tracks 80 & 81.
mark_k is offline  
Old 22 December 2013, 14:38   #28
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
As far as I remember, yes, you can select the track where pre-compensation gets turned on in trackdisk.device.
Someone could check the documentation it should be where device parameters get explained, maybe just in some editions.
What is never explained in any CBM documentation is what pre-compensation is, and how to use it
IFW is offline  
Old 22 December 2013, 14:43   #29
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
Yes, that is correct, the closer you get to the centre of the disk, the higher the pre-compensation required.
Usually, it is limited to preset values only that are exact multiples of the clock speed of the controller though and the correct value should be software selected when reaching a specific track.
Due to this limitation, some tracks may get more or less pre-compensation that what is actually ideal - but the result of course is still a lot better than writing without pre-comping.
IFW is offline  
Old 22 December 2013, 14:58   #30
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,481
I just checked the values in the trackdisk TDU_PublicUnit structure (running Kickstart 3.1). The precompensation fields shown in devices/trackdisk.h are
Code:
UWORD	tdu_Comp01Track;	/* track for first precomp */
UWORD	tdu_Comp10Track;	/* track for second precomp */
UWORD	tdu_Comp11Track;	/* track for third precomp */
The values I saw were 80 (0x50), 0xFFFF, 0xFFFF. So it seems trackdisk doesn't actually use any precompensation when writing???
mark_k is offline  
Old 22 December 2013, 15:02   #31
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
Doesn't it use track as 0-159 +? (ie 0.0: 0, 0.1: 1, 1.0: 2... 79.0; 158, 79.1: 159...)
If yes, then it turns on pre-compensation at track 40.0 with the value 80.
IFW is offline  
Old 22 December 2013, 16:57   #32
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,063
Send a message via MSN to dlfrsilver
Quote:
Originally Posted by StingRay View Post
So far I never saw any game that used GCR. Do you have any examples?
I own one. Albedo tracks from Myriad were written on a macintosh drive on a macintosh computer (As explained by the authors).
dlfrsilver is offline  
Old 22 December 2013, 17:13   #33
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,481
Quote:
Originally Posted by IFW View Post
Doesn't it use track as 0-159 +? (ie 0.0: 0, 0.1: 1, 1.0: 2... 79.0; 158, 79.1: 159...)
If yes, then it turns on pre-compensation at track 40.0 with the value 80.
Ah yes you're right. Could more precompensation for the innermost tracks (say 70+) have improved the data retention over time?

I wonder how many disk copier programs (which don't use trackdisk routines) also vary pre-compensation depending on the track number. It could be that some don't, meaning disks written using those programs would become bad quicker than ones written via trackdisk.device.
mark_k is offline  
Old 22 December 2013, 17:23   #34
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,489
Quote:
Originally Posted by dlfrsilver View Post
I own one. Albedo tracks from Myriad were written on a macintosh drive on a macintosh computer (As explained by the authors).
All the Albedo tracks I have checked were MFM.
StingRay is offline  
Old 22 December 2013, 18:17   #35
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
Quote:
Originally Posted by mr.vince View Post
Funny thing, haven't been able to find it on TOSEC either. Since this is all hardware dependent, and you seem to control it... why not put it up?
I have no idea what TOSEC is.

I am in the process of putting all of my original C64 and Amiga software on my website. So, it will be there at some point. I am packaging the original SYBILs, with original disks for resale too.

I am not sure if trackdisk.device ever actually used the precomp. I have a disassembly of it somewhere. I know that Amax disk's didn't. None of my stuff ever needed precomp, and the age old argument about disks going bad without using precomp is ridiculous. I have hundreds of copies of protected disks (along with their originals) from the late 80's/early 90's and every single disk - even those with protection on track 79-81, still load just fine. Yes, the write precomp (what I call post read normalization) does help eliminate the bit shifting that is more common at higher denisty, but it certainly is not a requirement for longevity. The only thing it is good for really is generational copies.

Yes, there were quite a few Amiga programs that used the GCR mode. The disk-2-disk Mac copier pulsed the Amiga's motor to reduce the drive speed. It wasn't great, but with numerous retries you could get a variable speed Mac disk to read (no writing). I made SYBIL for this, which did support reading and writing of Mac disks. I also made AMIA, which was a single chip PEEL based drive interface that allowed you to attach a real Mac floppy to the Amiga and read/write Mac disks, all using the GCR mode.

I don't recall the games that were copy protected with some Mac tracks put on them, but they existed. Supercard Ami could copy Mac disks, besides Atari ST, Amiga, 5.25" PC, C64, Atari 800, etc. disks. It was not uncommon for game manufacturers to try to use the same protection between their Mac, Amiga, Atari ST counter parts. For example, Dungeon Master for the Amiga has the exact Atari ST track on it for protection. Companies that had both Mac and Amiga versions often times used the Mac protection because the Amiga could read GCR.
JimDrew is offline  
Old 22 December 2013, 20:05   #36
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
Quote:
Originally Posted by JimDrew View Post
None of my stuff ever needed precomp, and the age old argument about disks going bad without using precomp is ridiculous.
Since e.g. Cyclone and Super Card Ami push the data from the source drive directly to the target and the data never goes through the processor, how would you precomp? I mean it's easy to say "I don't want to fly" when you simply can't fly. Correct me if it could, but to my understanding these two devices could not. Maybe Sybil can, but obviously you did not want to add it.


But maybe you still have a different "perception" of how magnetic recording works. To quote an earlier post of yours:

Quote:
Originally Posted by JimDrew
write precomp is not the action of skewing bits forward or backwards. Write precomp, in the true sense as used in every MFM and GCR drive (including the 1541/71/81 drives) is that the signal intensity is increased the closer you get to the center of the disk. Because data is moving quicker, the "magnetic power" required to successfully write bits must be increased.

...when in reality, this sums it up very well:
http://www.lintech.org/comp-per/07MAGREC.pdf

See 7.4.2
mr.vince is offline  
Old 22 December 2013, 21:23   #37
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
Yes, trackdisk did use precomp, because yes, disks would have had significantly worse quality during read, without precomping. The closer you get to the centre of the disk, the worse it gets especially if you are using a different drive to read back the disk from the one used to write it.
There is no such thing as "post normalization", etc.
Magnetic recording theory is nothing new, it's been there concerning floppy disks for quite a few decades by now. It's not about silly arguments, imaginary stuff, etc. - it's about technology that not just works, but also RELIABLY works, given the constraints. It's still is the basis of how hard drives have evolved, how duplication technology has evolved and so on.
There is no secret there, no mythical stuff, nothing is up for debate.
It's all well understood things, where theory is perfectly matched with empirical evidence.
Anything else is just selling snake oil.

Last edited by IFW; 22 December 2013 at 21:33.
IFW is offline  
Old 22 December 2013, 21:33   #38
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
Quote:
Originally Posted by mark_k View Post
Ah yes you're right. Could more precompensation for the innermost tracks (say 70+) have improved the data retention over time?

I wonder how many disk copier programs (which don't use trackdisk routines) also vary pre-compensation depending on the track number. It could be that some don't, meaning disks written using those programs would become bad quicker than ones written via trackdisk.device.
A slightly more find grained pre-compensation could have, but that would have required a higher clock speed to derive the timing from.
Not sure how many did, but people generally copied each other's routines, so if one had it, it was almost certain another would have used it as well
So yes, anything written by trackdisk is much more reliable than something written with pre-compensation unused.
Especially tracks around 70+ are susceptible to defects without it. More precisely, 77+ - which is possibly the reason why some systems opted for using only tracks 0 to 76...
IFW is offline  
Old 22 December 2013, 22:04   #39
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,481
Quote:
Originally Posted by IFW View Post
Not sure how many did, but people generally copied each other's routines, so if one had it, it was almost certain another would have used it as well
So basically that code in Amiga Disk Drives Inside & Out is probably what most system-killing programs used for disk access.
(I just checked and the disk copier in that book does seem to use precomp for track 40+)
Quote:
Originally Posted by IFW View Post
Especially tracks around 70+ are susceptible to defects without it. More precisely, 77+ - which is possibly the reason why some systems opted for using only tracks 0 to 76...
That doesn't bode well for the longevity of 82-track DiskSpare longevity then. While (I assume, I didn't check) diskspare.device uses trackdisk raw read/write commands, maybe extra precompensation would help for tracks 80 & 81?
mark_k is offline  
Old 22 December 2013, 22:19   #40
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
That's not necessarily a yes... too much pre-compensation can actually degrade readability... you need to increase it by a few nanoseconds, can't remember what the possible timing values were on the miggy.
IFW is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Supercard Pro Case kipper2k Hardware mods 4 25 March 2014 20:45
Powercopy Pro Original Disk images thread dlfrsilver request.Apps 7 03 June 2012 02:28
Winuae & real hard disk problem marcolau support.WinUAE 5 25 September 2009 17:44
Atari ST Disk Images in WinUAE 1.6.0 AmigaBoingBall request.UAE Wishlist 10 04 June 2009 21:14
Winuae problems with real HD and floppy images webmany support.WinUAE 3 25 April 2007 01:08

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:40.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.23344 seconds with 11 queries