| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Understanding 1541 byte-sync and buffering
Lately I have been attempting work the kinks out of some old drive code. To be honest much of it was produced by trial-and-error and by peeking at the code of others, so I've been putting off getting to grips with how the device _actually_ works for quite some time now.
At the moment I'm stuck trying to resolve some issues with the drive head occasionally dropping bytes during reads and injecting extra bits during writes and I've come to the conclusion that I ought to make sense of how the GCR byte buffer actually works.
Unfortunately the documentation available is somewhat lacking and it is difficult to know how far to trust the emulator sources. Incidentally, I don't suppose there is a high-quality scan of the classic 1541 schematic (the discrete version without the PLA) out there? Ideally annotated for the hardware-challenged among us :)
My mental model is that of an 8-bit shift-register clocking through flux transitions as set bits to/from the drive head. Once empty/full the next byte is placed onto/taken from the VIA2 PRA port and a byte-ready pulse sent to the 6502 V-flag input along with VIA2 CA1. Plus there is a counter detecting >=10-bit SYNC fields during reads, at which point the shift register is reset and the SYNC signal asserted. While writing the speedzone-divider clocks this directly, whereas during reads the clock is recovered from the flux-transitions or after spaces somewhat wider than the bit period.
This broadly jives with observations such as the initial post-SYNC $FF byte, the echoing of previously read data after a write-mode transition, and observed behavior when a byte is read/written late. Except I still see glitches and oddities.
For one thing there appears to be some form of handshaking affecting the byte-ready signal. One my code does by trial-and-error is a dummy read of the $FF byte after the sync field, without which the tag byte doesn't get extracted properly, i.e.: bit $1c00 ;Wait for sync
bmi *-3
nop $1c01 ;Reading any other address causes trouble
clv
bvc *
lda $1c01 ;Tag byte
This is despite VIA read handshaking having been disabled with SoE on CA1 kept permanently asserted.
At any rate my 1541-II/1571 and Kryoflux have trouble whereas VICE 2.4 doesn't care aside from unlatching a 1571 status-bit on any VIA2 register read.
It is not immediately obvious from the Kryoflux code what is going on but then VHDL is admittedly hard going for me. Plus given how it handles write buffering (byte-aligning to the stream and dropping the first two bytes) I'm not putting much faith in its accuracy.
</rant>
I apologize for making a mountain out of a molehill here but I really do keep running into weird glitches which I can't quite understand and this is about the only reproducible one out of the lot ;)
Side-note: I warmly endorse the Kryoflux for anyone tinkering with the 1541 and wanting to know what is getting written out to disk |
|
... 27 posts hidden. Click here to view all posts....
|
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
Quote: Quoting FungusYes it using FSK then, the flux transitions are all edge triggered and half waves. This makes sense since it's the technology they use for tape and modem communications too. It's old an easy to implement and works.
This is not what we'd normally call FSK. FSK as used on CBM tapes has variable bit lengths.
The scheme is rather a very crude PLL trying to lock on to the rate of bits by just resetting every time a '1' is seen.
The encoding is still just constant length '1's or '0's which have the requirement that no more than two '0's can be in a row.
There are two reasons for the requirement:
1. if there are to many '0's the PLL can't keep track of the bits within the variation of speed it is required to handle.
2. there is an anomaly in the implementation that wraps around after a '1' and three '0's. When it wraps it will generate a spurious '1' (and repeat the process). This is what is seen if the track contains no flux transitions. Three '0's in a row _can_ work but is unreliable. I see to remember that newer 1541 have more problems with these.
Hmm... according to the VICE doc sequences of 3 0's should be perfectly stable, even longer sequences (except for that every 4th 0 becomes a 1), as long as timing deviations don't destroy sync. This also makes me wonder how copy protection schemes worked that relied on the 1541 reading different data every time a long sequence of 0s was read. Maybe it wasn't really long sequences of 0s but actual noise or pulses of 1.5 a bit's length that deliberately caused random data to be read.
Could the analog circuitry play a role too? I'm not advanced enough in electronics to understand it... Reading back data written to magnetic media gives you the 1st derivative of what was originally written so this needs to be taken care of, and it looks like they added a low-pass filter for that purpose, I don't know how well this can deal with unexpected pulse lengths since it might just be tuned for the sweet spot of usual pulse lengths to be able to better cope with weak signals |
| |
Zer0-X
Registered: Aug 2008
Posts: 78 |
1541 has a simple 4 bit counter that that wraps around producing the 100010001000...
1541-II has different implementation that doesn't have this "limit" so in theory it can produce infinite amount of 0s.
Variation of spindle speed is the cause of more than 3x 0s to become unreliable to count, the more the speed if off from the norm.
The other variation is the read head amplifier circuitry which can easily pick up noise resetting the counter and thus producing random 1s to long stream of 0s.
And there's also a filter to hide pulses that are too close together from the counter logic. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
3 0s "work" (most of the time) on the very old longboard version... on later revisions it becomes more and more instable. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Just how large are the margins for reliably recording at higher bit densities anyway?
40 tracks seems to be reasonably reliable after all. So then taking the density of track 40 at speed-zone 0 as an upper bound would allow the inner tracks to use lower zones.
If my figures are correct zone 3 up to 26, zone 2 up to track 33, zone 1 up to track 36 and zone 0 up to track 40. Thereby gaining ~5% percent or so of extra storage. |
| |
Fungus
Registered: Sep 2002
Posts: 609 |
hrm right the clock itself controls the data rate, I forgot about that. But it will still mess with the reading if it's set wrong, I did some tests with that once, and I would get unreliable data. There's a trick that pirate slayer does with toggling the data rate to change the track framing.
Something else that's interesting is the 4040 (or was it 8050?) had hardware GCR decoding using a rom with some address line trickery. This could be reproduced and stuck into a 1541 pretty easily.
Yes V-Max already does the pulse shortening, pretty nifty stuff. Also short syncs and other weird stuff like signature checking in pre and post gaps. Lord Crass could explain some of v-max's mechanisms more clearly, he's got a lot of experience dealing with v-max in general.
Also only 38 tracks is reliable, very old mechanisms will get the head stuck any higher than that. Some of the newer drives can go in to 41, but most will lock up higher than 40. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
40 is perfectly fine, thats what the mechs are made for actually.... it only was limited to 35 because of crappy media in the late 70s :)
prologicdos iirc uses a decoder ROM for GCR decoding |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepaz40 is perfectly fine, thats what the mechs are made for actually.... it only was limited to 35 because of crappy media in the late 70s :) Do you happen to have a source for that?
It would be comforting to know for certain the maximum number of tracks which can be targeted safely. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
it should be mentioned in the datasheets for the mech - however, no idea where to find them. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 499 |
I guess this is related to that:
https://sourceforge.net/p/vice-emu/bugs/582/
Also, do not expect this to be $ff on real hardware, except maybe if you read $1c01 just before the sync arrives :-) I injured myself as well at hat point back then, as i hoped to save those 3 bytes, but you will fail miserably on real hardware if you do so :-) |
| |
Fungus
Registered: Sep 2002
Posts: 609 |
The data sheets say they should go to track 40, but you know commodore and their cheapness. They used faulty mechs sometimes and they do indeed get stuck past track 38. I had once such drive. It was mentioned somewhere else at some point too... maybe kracker jax documentations or the v-max usenet thread, my memory fails me. |
| Previous - 1 | 2 | 3 | 4 - Next |
