28 Feb
2002
28 Feb
'02
5:30 a.m.
On Feb 28, 11:04, Andreas Freiherr wrote:
Er, read the code again. The double-density version only loads 2 sectors,
in *all* the versions I've seen.
40 001122 120427 CMPB R4,#3 ; sectors 1
and 3 get done
40 001124 000003
Pete,
understand or agree with all you say. Except:
> > Yes. But this is neither a typo nor a printing error. If you read
four
> > blocks of 200(8) _words_ each, starting at
zero, you fill exactly
> > 2000(8) _bytes_, and the next free location is 2000(8). As you state,
> > the printed version is prepared for conversion to single density (by
> > clearing the 400 bit in locations 2036 and 2072, right?) by reading
in
> > four blocks... - So, the reason is somewhat
similar to that for the
> > TS-11.
>
> Yes, but if it's single density, which is the only reason you'd read
four
sectors, the
sectors are 128 bytes [100(8)] not 256, so it's still only
1000(8).
Sure, you need not read four sectors if they are 200 words each, but as
we noted earlier, the routine will always read these four sectors (so
you need only change two words in order to switch to single density),
and if these four sectors happen to be from a double-density RX02, you
will want to have sufficient room for them. I haven't tried: is it possible to get a false
error indication while
you are supposed to wait until the RXV11 has digested parameters like
sector / track number? From reading the docs, I would assume that the
only reason for the error bit to come on at this time might be an
invalid parameter like sector > 26, and in this case, you'll probably
better abort as well (sure, should not happen during boot...). So why
not just use this check every time you wait for the controller, once the
check is in the subroutine anyway?
I haven't tried all the permutations to see what happens if you give
garbage in response to a TR request, but the error only shows up ast the
end in cases I have tried. It's almost impossible to test this by hand, as
the controller doesn't wait forever; you only have a short time to respond
to TR so you can't do it from, say, ODT or an 11/40 switch console.
But, you're right: savings aren't too extreme
with this approach, as the
sequence BIT-BEQ-BMI takes three words, and a JSR would need two. In
turn, you need two additional words for a MOV #something,SP plus one for
the RTS, and there are four places with a BMI, so in total we save four
words by spending three: makes a total of one word saved. Didn't you say
something like this before? ;-)
Something like that, yeah ;-)
Let me continue, and we can open a contest for writing
the shortest
bootstrap! ;-)
I used to do that with all sorts of small assembly-languge routines. My
best was saving 200+ bytes out of 2048, in some Z80 code that one
self-proclaimed expert (not the author) described as "a mastepiece of
conciseness".
--
Pete Peter Turnbull
Network Manager
University of York