| |
lft
Registered: Jul 2007
Posts: 369 |
GCR decoding on the fly
Here's how to do it:
http://linusakesson.net/programming/gcr-decoding/index.php |
|
... 149 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
its only the C128DCR - and the timing IS broken there :) |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
been ages since I last used my dcr, but it was rock stable on demos until early 2000s. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
try using jiffydos on it :) |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Groepaz: You seem to know what is wrong with the dcr, is it transfer timing or is it read-head timing? If it's true what Oswald says, then it should of course be possible to do fast loaders that work on the dcr also.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
apparently the delay caused by the cable connection is slightly (really, less than a cycle) different than expected.... someone did a bunch of measurements (because chameleon has had a similar problem) - see http://www.forum64.de/wbb3/board65-neue-hardware/board289-diver.. ... yes its possible to make it work, by detecting and specifically handling C128D that is. (and then everything will break again with more than 1 drive on the bus ... =P) |
| |
tlr
Registered: Sep 2003
Posts: 1791 |
Those are really nice measurement confirming and detailing the problem.
I thought it was common knowledge that the transfer timing was different? Less capacitance on the bus equals faster transitions.
Transfer routines that are "unidirectional" avoid the problem. i.e send sync pattern from the drive side and then the data (like the AR turbo). Anything that relies on the round trip c64 -> drive -> c64 is sensitive to timing variations for instance by bus loading.
Using the unidirectional technique might not be feasible in demo contexts though. |
| |
soci
Registered: Sep 2003
Posts: 481 |
There's no problem with JiffyDOS on my C128DCR, but only after it had warmed up ;) The problem is on reading the last bits as I remember. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepazapparently the delay caused by the cable connection is slightly (really, less than a cycle) different than expected.... someone did a bunch of measurements (because chameleon has had a similar problem) Bear with me, it's been a long time since I took German, but the gist of it is that added capacitance in the DCR slows down signalling by less than a cycle for a round-trip but still sufficient to require an extra cycle of waiting on the host before a response can safely be read?
In effect limiting the speed of a traditional IRQ loader to 19x4 cycles/byte (17x4 with RMW opcodes.)
Quoting Groepaz ... yes its possible to make it work, by detecting and specifically handling C128D that is. (and then everything will break again with more than 1 drive on the bus ... =P) Detecting and handling it by introducing extra delays on the host, with more than one drive on a non-GCR system exhibiting similar behaviour?
As an aside how am I supposed to handle multiple IEC devices on the bus in a two-bit IRQ loader? My best idea so far is to manually detect and handle as many of them as possible by installing code to put them into tight ATN-acknowledgement loops to avoid blocking the DATA line, but presumably that will fail miserably on many devices.
On a vaguely related note I've been thinking about what other limits the unwary drive coder with limited resources for testing might run into.
Specifically:
- How many tracks are safe to use?
- Which speedzones are safe for the various tracks?
- How fast may the head be stepped? Can it be improved with acceleration?
- What is the range of rotation speeds which should be supported?
- How hard are the GCR constraints? May clock recovery be reliable with more than two zero bits in a row?
- Which illegal opcodes, if any, may safely be relied upon?
- How much of a margin is required to account for the larger numbers of devices and longer cables on a worst-case IEC bus?
I realize that most of these are judgement calls but it would be good to know what the consensus is and what trouble you actually risk running into. |
| |
tlr
Registered: Sep 2003
Posts: 1791 |
Quoting doynax- How fast may the head be stepped? Can it be improved with acceleration? Kernal uses 15 ms + 75 ms settle.
I've used 8 ms + 8 ms settle in DMA loader II which seems pretty stable.
Graham employs acceleration in WarpCopy64. It seems reasonable that will allow higher top speeds.
Perhaps Graham can elaborate on how it works in practice?
Quoting doynax- What is the range of rotation speeds which should be supported? There is some discussion here: Searching for a fast-writing floppy routine
Graham claims 280-320 rpm. TNT has only seen 295-305 rpm.
The drives I've encountered have all been very close to 300 rpm, even over time (i.e since '85 or so).
Oh, and my statement in above thread about static intersector gaps have been since retracted, Graham was right. I've done it the right way in Format II.
Quoting doynax- How hard are the GCR constraints? May clock recovery be reliable with more than two zero bits in a row? The main reason for that restriction is how the 0 bit recovery was constructed.
It is done by a simple 4-bit counter which is reset on seeing a transition. It will dead count 4 steps for each bit position according to the current set speed zone. The lowest two counter bits are used for timing and the upper two is used to generate a 1 for the first step and 0's for the following 3 steps.
Now the weird thing is that it wraps! This means that after seeing a transition (a '1') plus ~3 non-transitions ('0's), a 1 will appear even though there isn't any transition coming from the disk.
The '~' in ~3 non-transitions ('0's) is because if the 1 that _must_ follow the last 0 is a tiny bit late, a fake 1 will be generated and then immediately afterwards the real transition will come and reset the counter and generate another 1.
In addition to this there might be analog factors as well, e.g noise, clock jitter, mechanical vibration causing bit jitter.
That said, it should be possible to allow three 0's in a row as long as the data rate (+ jitter) coming from the disk is strictly faster than the bit clock in the drive in all situations.
This requires you to write at a higher bit rate than you read.
There is a note about this in conjuction with early V-MAX implementations that it wasn't reliable on some drives (1541-II?). http://c64preservation.com/dp.php?pg=vmax (at the top) and here http://markus.brenner.de/mnib/vmaxtech.txt |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Thanks for the info!
Quoting tlrGraham claims 280-320 rpm. TNT has only seen 295-305 rpm.
The drives I've encountered have all been very close to 300 rpm, even over time (i.e since '85 or so). Ouch. Speed-zone 3 written at 320 RPM and read back at 280 is only 22 1/4 cycles per byte.
Quoting tlrThat said, it should be possible to allow three 0's in a row as long as the data rate (+ jitter) coming from the disk is strictly faster than the bit clock in the drive in all situations.
This requires you to write at a higher bit rate than you read. Interesting. So with proper authoring and a devilishly clever algorithm we might theoretically squeeze out 15 bits per 16-bit word of entropy. |
| Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 - Next |
