| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if you have small test cases, please submit them to the VICE repo indeed :) the existing VIA tests only test very basic things, i am sure there is a lot more thats broken and needs fixing :) |
| |
Thierry
Registered: Oct 2009
Posts: 48 |
Quote: Quote:The VICE 1541 VIA2 emulation seems to be the minimum required for the normal operating mode whereas 1541-U uses a fully-featured generic VIA block.
not really. try running the VIA testprogs from vice repo.... VICE passes more of them than 1541U (using 2.6k fw at least, i didnt bother testing the 3.0beta yet). 1541U even fails a couple CPU tests from the lorenz suite for that matter (which is pretty wtf)
Try unofficial Horrocks Update,
http://ar.c64.org/rrwiki/images/a/af/1541_U_II_2.6k_-_Unofficia..
many fixes and more compatible |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i know that update obviously, since i added it to that page =) (however, i only use official versions for testing things) |
| |
soci
Registered: Sep 2003
Posts: 480 |
He only up-streamed some VIA related changes for version 3 as far as I know. |
| |
Fungus
Registered: Sep 2002
Posts: 686 |
Hrm setting the clock divider to the wrong frequency when reading data will result in incorrect data being read. So it can't be derived from reading the incoming flux transitions.
I was just reading up on Frequency Shift Keying (like tape uses) and it would seem to be that the drives are using the same type of technique in hardware rather than software. Since the incorrect divider frequency would change the time period for flux transitions to be valid, no?
Also the read is needed to clear the latched value, that's pretty straight forward and normal VIA/CIA behavior. If it's not cleared fast enough then clocked in transitions will be missed. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Back a few years ago I had better success with debugging drive code with Hoxs. I seem to the ability to single step either C64 or 1541 helped a lot. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
you can do that with VICE just fine :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Probably can now. Years ago VICE emulation with regards to drive code timing was very poor. Hoxs and real hardware were the only options.
I must try it in the newest VICE sometime. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
it has been possible in VICE since forever. and HOXS just (relativly) recently catched up with it. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
I distinctly remember Hoxs and real hardware working when VICE did not, when debugging 2 bit drive transfer code. |
| Previous - 1 | 2 | 3 | 4 - Next |
