[prev] [thread] [next] [lurker] [Date index for 2005/06/27]
Jarkko Hietaniemi <jhietaniemi@xxxxx.xxx> wrote:
> Martin Ebourne wrote:
>> Probably not the reason here, but that's the Acorn line break. There's a
>> good reason for it being that way round: it saved several bytes and a
>> quite a few machine cycles on the old BBC micro.
>
> Ummm, could you elaborate. ASM fine in the explanation.
Well I'm a bit out of practice on the 6502. But something like this.
There are two main OS calls for writing a character to the screen:
OSWRCH - OS write character, the underlying call to write characters
OSASCII - Same as OSWRCH but with character translation. In fact, all
it does is translate the 'official' Acorn line ending to the underlying
characters (which become the 'alternative' Acorn line break - should
have been a bit more clear above), so it converts \r to \n\r. A key
feature is that it returns with the accumulator untouched.
So in the OS syscall entry space we have:
.osascii CMP #13
BNE oswrch
LDA #10
JSR oswrch
LDA #13
.oswrch JMP (<jump table vector address>)
Clearly to write \r\n and still return with \r in the accumulator takes
another JSR, LDA, and RTS. 6 more bytes and plenty of cycles.
Of course, if Acorn had used \n for linebreaks instead of \r then the
code above would trivially produce \r\n and everything would have
matched up with both unix & dos so much better.
Cheers,
Martin.
There's stuff above here
Generated at 00:00 on 28 Jun 2005 by mariachi 0.52