| Author: | JimDrew (registered user: 23 posts ) |
|---|---|---|
| Date: | Wed, Nov 27th, 2013 @ 17:41 ( . ) |
On your "protection info" area, you have the following text: "We mentioned before that if the drive gets more than two '0' bits in a row, it clocks in a random '1' bit occasionally." I can confirm with 100% absolutely certainty that this is not correct. It was long believed that having three 0 bits in a row caused the data to float (weakbits). That is not the case. I completely reverse engineered the 325572-01 ASIC used in the 1541 (the 1541-II and 1571 used different ASIC's so those are next). I found that the state machine allows for a 5th bit cell time zone. This was likely not deliberate (or it would have been documented). When the bit cell value exceeds 4.250s x 3, the encoding shifts and becomes 0001. This *is* a valid encoding value. You can put a lot more data on a track at the same clock rate using this method, and protections from Mindscape did just that. A good example is V-Max! track 20 looks for 5A/5A/5A/55, and then looks for 5A/5A/5A/FF, and then looks for 5A/5A/5A/37. If you decode 5A37 that is '101101000110111'. Notice the 3 zero bits in a row... that's valid and it never changes no matter how many times you re-read that data. This was definitely not documented anywhere at Commodore or any other source as far as I know. So, for weak bits to occur on a CBM drive, you must have 4 or more 0 bits in a row, not 3 as we all once thought. So, if the entire track is written with a single bit cell time that decodes as 0001, you are looking at a very long track. There are many games I have seen already that use 0001 in their custom format encoding. The 1541-II and 1571 also have special properties handling data that exceeds the clocking window for a bit cell time, returning at least one nibble with a 0 and most often the other bits are 0's as well. When I get those ASICs reverse engineered, I can give a full description of how that clocking mechanism works. |
 | Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Jan 01st, 2014 @ 13:07 ( . ) |
Interesting. I was able to confirm this with a bit of testing on a real drive (1541 only, haven't tested with 1541-II/1571). You can write strings of 88 88 88, 11 11 11, 44 44 44, etc and they always read back the way they were written. I tried this at highest density on track 1 and lowest density on track 35. As soon as you go to a fourth consecutive 0 bit in the stream (11 09 11), that bit almost always reads back as a 1. |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Jan 01st, 2014 @ 13:46 ( . ) |
Good to know details on this. Since mnib/nibtools operates on data taken from the 1541, we never see this 0000 bit combination (since the drive typically returns 0001) so there was no way to know this before the advent of seeing the flux directly. We assume in software that if we see that '000' sequence, it is "bad GCR" since it is not defined. -Pete |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Jan 01st, 2014 @ 16:32 ( . ) |
Checked this out with Vice and it emulates this behaviour the same way the real 1541 does. |