At 12:10 PM 3/19/99 +0000, you wrote:
>Take the above loop:
>
>LOOP:
> IN A,(D0h) 12 ticks
> RRCA 5 ticks
> JR NC,LOOP 8 ticks if skipped, 13 if jumping
> RRCA 5 ticks
> RET NC 6 ticks if skipped, 12 ticks if returning
> INI 17 ticks
> JP LOOP 11 ticks
>
>If the 1st JR is done: 12+5+13=30 ticks, far less than 57.
>Otherwise 12+5+8+5+6+17+11=64 ticks, a tiny bit too many
Your calculation is too optimistic.
What if the "next byte" signal comes when the IN A,(D0h) instruction is
executed? In the worst case, it comes just after the value was read over
the data bus. Part of the IN instruction is executed, the RRCA and the JR
jumps (because it's using the old value). Then the IN finally reads the
correct value and everything else is executed.
Depending on when during an IN instruction the value is actually read,
worst case loop is between 82 and 94 cycles long.
>-Drop the JP at the end, and put what's before it xx times after each
>other. Doesn't look nice as source code, but works. You could also
>copy this piece of code xxx times to RAM and execute that
Problem is that xxx=512 (number of bytes in a sector). If you don't unroll
fully, you won't improve the worst case.
>-put address of (LOOP) in IX or IY, and replace JP LOOP with JP (IX)
>or JP (IY): takes 9 instead of 11 ticks. Or even use JP (HL): uses
>only 5 (!) ticks
IX or IY would work. HL is used by the INI instruction so it would require
more work to use it for a JP (which may make the routine slower in other
places).
>-INI and instructions working with pointers use 16-bit counters.
>Could be replaced with sequences like INC HL: DJNZ LOOP. If you take
>a fixed transfer address (sector buffer!) with start address xx00h,
>you can replace that INC HL with INC L.
Using DJNZ and fixing sector size to 512, the routine would look like this:
LD B,0
LOOP1:
IN A,(D0h) 12 ticks
RRCA 5 ticks
JR NC,LOOP1 8 ticks if skipped, 13 if jumping
IN A,(nn) 12 ticks
LD (HL),A 8 ticks
INC HL 7 ticks
LOOP2:
IN A,(D0h) 12 ticks
RRCA 5 ticks
JR NC,LOOP2 8 ticks if skipped, 13 if jumping
IN A,(nn) 12 ticks
LD (HL),A 8 ticks
INC HL 7 ticks
DJNZ LOOP1 14 ticks if jumping
That would make the worst case: (starting at LOOP2)
12+5+13+12+5+8+12+8+7+14 = 96, even worse than before (94).
Keeping INI, but fixing the sector size to 512:
LD BC,00nnh
LOOP1:
IN A,(D0h) 12 ticks
RRCA 5 ticks
JR NC,LOOP1 8 ticks if skipped, 13 if jumping
INI 17 ticks
JP NZ,LOOP1 11 ticks
LOOP2:
IN A,(D0h) 12 ticks
RRCA 5 ticks
JR NC,LOOP2 8 ticks if skipped, 13 if jumping
INI 17 ticks
JP NZ,LOOP2 11 ticks
Worst case:
12+5+13+12+5+8+17+11 = 83, an improvement, but still too slow.
>-The memory mapped I/O construction used by the floppycontroller in
>European MSX's gives more instructions that you could use (more Z80
>instructions dealing with memory than with I/O)
Instructions like "BIT n,(HL)" may be useful.
But the problem is that the INI instruction has no memory mapped equivalent
(LDI increases HL, while INI doesn't though C).
>-Do the INI in the above loop for starters (!): increases pointers,
>AND sets flags!
Huh? Doesn't that mean you copy a value to RAM without knowing whether it
is the old or new value?
>-> Allows to test those flags immediately (=drop another 5-tick
>instruction). If a byte did come in, you're done, if not, simply
>decrease pointers again
>
>Combining the above: not easy, but it COULD be done !
Your optimism originates from a wrong calculation of the worst case
exection time of the loop.
Using the fact that most of the "next byte" polling loop has to be executed
twice, I doubt a routine can be written that is fast enough to poll a HD
floppy on 3.5MHz.
But if what you're saying about the 2793 FDC is true (it can handle the
higher bitrate), wouldn't it be possible to access 1.44MB disks using 7MHz?
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
