CHROUT or STA - which is faster?
Cameron Kaiser
oa...@pipeline.com (Dick Cunningham) writes:
>I realize the purpose is to print to the screen regardless of where
>the screen is located, but the question I have is -- wouldn't a direct
>STA to a screen memory location (static of course) be faster. Am I
>correct in assuming that STA within a loop for screen locations would
>be faster than CHROUT in just about any situation. No, I don't need
>to know this for any particular application. I'm just wondering
>because I'm not familiar with the clock cycles involved. Curiosity
>only.
Absolutely, positively, yes.
For CHROUT to clear the screen, not only does it have to go through the work
involved with STAing a 32 to every screen location (or whatever side car
routine it calls for this), but it also has to futz with the linelink table,
fix the background colour (depending on your Kernal version), etc. Oh, and
it has to determine that sending a 147 in the accumulator means clear the
screen, and that it's going to the screen in the first place, and not the disk
drive, and ...
But for a simple STA loop to do it, all it has to do is something like
LDA #$20
LDX #$00
LUP STA 1024,X
STA 1280,X
STA 1536,X
STA 1792,X
INX
BNE LUP
Compare this with the code {BS,CHR}OUT would have to have executed just to
get to this point. Just another example of how when you get more versatile (and
{BS,CHR}OUT is a very versatile routine), you get bigger and slower. Nothing
beats a dedicated mindless slab o' code.
To be sure, in most cases, it doesn't make diddly difference if you
LDA #$93
JSR $FFD2
instead.
In fact, it would probably be better, since it does all the screen editor books
for you too. But in the timing-dependent environment of an IRQ, it's too much
overhead in both stack space and time.
--
------------------ C64 software lives: http://computerworkshops.home.ml.org/ --
Cameron Kaiser | "A free society is one where it is safe
cdkaiser@concentricKILLSPAMnet | to be unpopular." -- Adlai Stevenson
-- This article may have been posted with a Commodore 64 -- (address munged) --
arc...@delphi.com
Has anybody ever figured out what the "BS" in BSOUT stands for?
Could this be an in-house joke at CBM that turned into reality?
-Maurice
Joona I Palaste
Cameron Kaiser <cdka...@delete.these.four.words.concentric.net> scribbled the following:
: oa...@pipeline.com (Dick Cunningham) writes:
: Absolutely, positively, yes.
You're right there, Cameron. And does not CHROUT itself make such a loop
when it has received a #$93 character? That would reduce the question
to:
"Which is faster, a routine to do some table initialisation, or no code
at all?", which can be answered very easily.
Actually, I've used this sort of copying loop to copy the BASIC
interpreter area ($A000-$BFFF, $E000-$FFFF I think) from ROM to RAM. But
having to write 64 STA commands would have been too much hassle, so I
made it a loop with only one STA, and used self-modifying code.
Approximately like so:
LDA #$20
LDY #$A0
a STY b+2
STY c+2
LDX #$00
b LDA $A000,X
c STA $A000,X
INX
BNE c
INY
CPY #$C0
BNE a
What do you think of this? What are your general thoughts on self-
modifying code? I think it would be considered "dirty" on a PC or an
Amiga, but since the C64 has no fancy loader chunks and just executes
any lump of bytes you give it, it is not "dirty" on a C64.
: To be sure, in most cases, it doesn't make diddly difference if you
: LDA #$93
: JSR $FFD2
: instead.
: In fact, it would probably be better, since it does all the screen editor books
: for you too. But in the timing-dependent environment of an IRQ, it's too much
: overhead in both stack space and time.
Actually, isn't there a system routine exclusively for clearing the
screen? I think I used it in my BASIC extension.
--
/----------------------------------------------------------------------\
| Joona Palaste (pal...@cc.helsinki.fi) | | | |
| Kingpriest of "The Flying Lemon Tree" | | | |
| TFA, FtPoW: Stargazer |------- -----------------|
| |------- -----------------|
| G++ FR FW+ M- #80 D+ ADA N+++ W++ B OP+ | | | |
| Finland rules! => | | | |
\----------------------------------------------------------------------/
Cyclonus: What is this place?
Daniel: An ice cream factory?
Cyclonus: You are insolent, Earth boy!
Daniel: Thanks!
--- from "Surprise Party"
Cameron Kaiser
Joona I Palaste <pal...@cc.helsinki.fi[REMOVE ME TO ACCESS E-MAIL]> writes:
>You're right there, Cameron. And does not CHROUT itself make such a loop
>when it has received a #$93 character? That would reduce the question
Well, I think it calls some sort of utility routine, but the utility routine
does indeed do just a rapid STA of spaces to wherever the current screen page
is (from location 648).
>Actually, I've used this sort of copying loop to copy the BASIC
>interpreter area ($A000-$BFFF, $E000-$FFFF I think) from ROM to RAM. But
>having to write 64 STA commands would have been too much hassle, so I
>made it a loop with only one STA, and used self-modifying code.
>Approximately like so:
> LDA #$20
> LDY #$A0
>a STY b+2
> STY c+2
> LDX #$00
>b LDA $A000,X
>c STA $A000,X
> INX
> BNE c
> INY
> CPY #$C0
> BNE a
>What do you think of this? What are your general thoughts on self-
>modifying code? I think it would be considered "dirty" on a PC or an
>Amiga, but since the C64 has no fancy loader chunks and just executes
>any lump of bytes you give it, it is not "dirty" on a C64.
Self-modifying code isn't inherently dirty (in fact, my stock memfill and
memmove routines are themselves self-modifying since I didn't want to write
routines that had to muck about in zero page for indirect addressing -- too
many of my other stock routines are fighting for space there already), just
may be difficult to figure out if it's really complex. I've seen a real dandy
example that rewrote itself with new opcodes and so on. Not very portable,
but a really cool thing if you could figure out exactly what it was doing! :-)
>Actually, isn't there a system routine exclusively for clearing the
>screen? I think I used it in my BASIC extension.
Yep, which CHROUT calls.
Matthew Montchalin
In a previous article, arc...@delphi.com () says:
>Has anybody ever figured out what the "BS" in BSOUT stands for?
>Could this be an in-house joke at CBM that turned into reality?
No, most people say "BASOUT" while only people using primitive assemblers
use the extremely abbreviated version of it. (Apparently because their
assemblers couldn't handle labels longer than 5 bytes.)
The Kernal routine at $FFD2 is generally known as the BASIC_OUTPUT
routine. Remember, when you write source code, use meaningful labels.
That way questions don't pop up fifteen or twenty years down the line
like the one you just asked. ;) It's an all-purpose Basic Output routine.
--
Dr. Peter Kittel
In article <B7VL3Ch...@delphi.com> arc...@delphi.com writes:
>
>Has anybody ever figured out what the "BS" in BSOUT stands for?
>Could this be an in-house joke at CBM that turned into reality?
It's most probably a German abbreviation, BS = BildSchirm = screen.
Much of the documentation of ROM internals was done in Germany.
--
Best Regards, Dr. Peter Kittel // http://www.pios.de of PIOS
Private Site in Frankfurt, Germany \X/ office: peterk @ pios.de
Dr. Peter Kittel
In article <357481f5...@news.pipeline.com> oa...@pipeline.com (Dick Cunningham) writes:
>
>On the subject of CHROUT (also known as BSOUT on the 128):
>
>I realize the purpose is to print to the screen regardless of where
>the screen is located, but the question I have is -- wouldn't a direct
>STA to a screen memory location (static of course) be faster.
Sure. But the overhead in processing in BSOUT also serves some
additional purpose: It maintains pointers for lines on screens, so
that operations like cursor movements or carriage returns access
the correct screen locations. And when you print a normal character,
the cursor position is of course updated.