From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-11-14 13:58:09
Hello,
* On Sun, Nov 13, 2005 at 09:00:47PM +0100 silverdr@inet.com.pl wrote:
> >The 1541 uses a clock of exactly 1 MHz. The fastest bit rate is
> >(16/13) MHz / 4 on tracks 1-17 (according to
> >http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/1541/
> >service/Page_07.html),
>
> Ah, there's the table I was looking for! FYI I wasn't _that_ lazy. I
> visited zimmers and even dloaded the whole GIF based manual in search
> for this info. Just somehow thought the HTML was only a different
> form of the same data. Thanks for that.
One remark: The schematics are a very valuable help, too. :)
> >This is not the complete story. These delays accumulate. Thus, if you
> >are "early" in reading one byte, you can be "late" in reading the
> >next one. For example, Wolfgang Moser has done systematical tests and
> >he found out that 41 cycles can still work, IF DONE PROPERLY. (!)
>
> I am not sure if I understand this...
>
> Also if e.g. my drive rotates on average some 5% faster than the one,
> which wrote the track - how can it be that?
This does not have to do with the average rotation speed.
Ok, lets look in more detail:
The 1541 takes the byte from port A, UC2, every 26 cycles (when writing
to disk). Thus, you must write a byte there *before* the next byte is
latched in.
Now, assume at clock 0, the DC took the data from port A. The CPU has at
most 26 cycles to write the next data there. Assume we write the data
immediately after clock 0 there, that is, at clock 1.
- clock before 0: PA is written by the CPU with the first byte
- clock 0: PA UC2 is latched into the shift register, first byte
- clock 1: PA is written by the CPU with the second byte
- clock 26: PA UC2 is latched into the shift register, second byte
- clock 51: PA is written by the CPU with the third byte
- clock 52: PA UC2 is latched into the shift register, third byte
Thus, you see, between clock 1 and 51, you have 50 cycles to write the
data on the port. Of course, normally, you cannot use all the 50 cycles,
as BVC * is not that exact. Wolfgang found out that "counting" 41 cycles
works reliably.
After this scenario, you have to write not later than clock 77, as at
clock 78, the DC will latch the next byte.
Anyway, if you happen to write the next byte very fast again (for
example, after writing in clock 51, BVC * and STA again), you can get
almost all of these cycles for the next processing.
Where is this info useful? Wolfgang did these tests as he wanted to use
some subroutines for writing data on the disks. Normally, the overhead
of JSR and RTS would be too much to cope with 26 cycles. Anyway,
allowing more cycles now and then allowed for using the JSR/RTS
construct.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.