| |
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 |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
have you looked at the current VICE source (not 2.4, its way old and _very_ broken)? there is a longish description of how the data separator works (written by one of the kryoflux guys :))
edit: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/sr.. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepazhave you looked at the current VICE source (not 2.4, its way old and _very_ broken)? there is a longish description of how the data separator works (written by one of the kryoflux guys :)) Thank you, I wasn't aware of that new code. Those comments certainly look like the circuit description I was looking for :)
I did run the test in Kryoflux "SPS" branch of VICE and a recent nightly build with the same results as well, but to be honest I don't have a firm grasp of what VICE releases are considered stable or how the project has forked in recent years.
Incidentally I meant to say that I had been testing on the 1541-U before and not the Kryoflux. I guess I must that new toy of mine on my mind ;) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting doynaxUnfortunately 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 :)
I can recommend you SAMS "Commodore 1541 Troubleshooting & Repair Guide":
http://www.codebase64.net/books/commodore-1541-troubleshooting-.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
using a recent VICE build is recommended, especially for drive related stuff... its usually stable enough for daily use (except exceptions!)
using 1541U for testing on the other hand isnt a good idea, the drive emu is in some parts even more broken than VICE is - really always use a real drive, or you will get nasty surprises. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Well, it turned out that it was all just me being stupid. As usual.
There is even a terse "FIXME" note in the recent VICE sources about it.
Essentially the byte-sync input latching isn't done externally by the shift-register but internally by the VIA based on the byte-ready flanks. When enabled anyway.
Furthermore PA isn't latched in on every flank. Rather the port is sampled every cycle up until byte-sync is asserted, at which point it stops and waits for $1c01 to be read by the CPU which resets the process. Lather, rinse and repeat.
In other words the post-sync dummy read is required in order for the byte-sync flank after the first proper payload byte to be latched in. It isn't even necessarily $FF but whatever byte came along immediately after the sampling had last stopped, so spinning up until the expected $52/$54 tag byte is subtly buggy.
I suppose a neat side-effect is that the spin-down case of the sector reading loop doesn't require strict timing in grabbing the final byte.
Quoting tlrI can recommend you SAMS "Commodore 1541 Troubleshooting & Repair Guide" Thank you, that's another excellent resource I had somehow managed to miss out on. It seems to be easily sourced off-of eBay even.
Quoting Groepazusing 1541U for testing on the other hand isnt a good idea, the drive emu is in some parts even more broken than VICE is - really always use a real drive, or you will get nasty surprises. Curiously it is actually more accurate in this particular case. 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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
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) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepaznot 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). I think you are right. Looking a little deeper it seems that it is mostly just latching being compiled out/dodgy and instead the floppy stream code takes partial responsibility for handling the latching. Nothing comparable to the horrendous Kryoflux GCR write hack certainly.
Incidentally would you recommend submitting test cases on running into these sorts of edge cases? I am much too lazy to work out all of the implications of enabling VIA latching globally but I ought to at least be able to manage a short repro case ;) |
| |
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) |
... 27 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 - Next |
