| |
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 |
|
... 30 posts hidden. Click here to view all posts....
|
| |
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: 686 |
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: 11386 |
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: 11386 |
it should be mentioned in the datasheets for the mech - however, no idea where to find them. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
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: 686 |
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 |
