On Feb 28, 11:04, Andreas Freiherr wrote:
> 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.
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
> 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
Received on Thu Feb 28 2002 - 13:30:42 GMT