Rewriting Kernal Routines

[Robbie]

I'm looking at CHROUT and thinking that I don't need a load of its functionality.
I'm wondering whether to copy the relevant parts of it inline into my main program loop.

It'll be a real pain, but will likely save a heck of a lot of cycles on execution. It'll also be a decent learning experience I reckon.

Your opinion: Worth it, or leave well alone?

[chysn]

If you have the RAM for it, only good can come from it, as a learning experience.

I'd just offer two bits of advice:

(1) Instead of re-implementing it as inline code, use a subroutine, and
(2) Try using the CHROUT vector at $0326 along with $FFD2 as your call address

I've never fully-re-implemented CHROUT, but I've made a couple CHROUT wedges (code that directs the $0326 vector, then sends control back to wherever the original hardware CHROUT is) that did things like allow multi-color characters via CHROUT (using some of the unused PETSCII characters as control characters), and another one that redirects output to a specific memory area (like a sort of virtual printer).

It can be fun and enlightening.

[srowe]

The KERNAL routines are quite inefficient as they have to check the destination for every byte. If you always want output to the screen then you can always just call directly to the right subroutine. Depends what functionality you deem unnecessary.

[Noizer]

I'm looking at CHROUT and thinking that I don't need a load of its functionality.
(...)
Your opinion: Worth it, or leave well alone?

Write your own chrout replacement from scratch with only the features you really need. You know what you want to achieve, the code has to simple reflect that.
Otherwise use CHROUT as is. It's like using the wheel already discovered. Not a shame

[Robbie]

Write your own chrout replacement from scratch with only the features you really need. You know what you want to achieve, the code has to simple reflect that.

I've had a good poke around the internal organs of CHROUT and concluded exactly what you said: better just to write my own from scratch.

I've learnt quite a bit from seeing how CHROUT is coded, and it's reassured me that I'm doing things in the right way. It also reminded me just how repetitive it can be writing M/L (whole big chunks of load this, compare to that, branch, change something, repeat...)

[Mike]

I'm looking at CHROUT and thinking that I don't need a load of its functionality. [...]

When it comes to screen output, CHROUT not only needs to put the character on screen (after conversion of PETSCII to screencodes), it also accounts for the colour RAM update, and handling of some data structures that oversee the linking of physical screen lines into one logical line.

Add to this the single character API, and you see why CHROUT is so slow. If you just want to put characters on screen, at a fixed position, you're better off with a simple memory copy. For more complex uses (including scrolling), TNT once implemented an own CHROUT routine, which also handles screen sizes different from 22x23 characters: (-> Printing to screen without KERNAL).

As for another example - for MINIPAINT I implemented routines that put a 4x8 font into a bitmap, they're used there for the dialog boxes (help pages, file name requester, disk directory display). With the 160x192 pixels of the MINIGRAFIK screen, that gives one a soft 40-column "text" screen with 24 lines. The routines always draw an entire text line, and while doing so are twice as fast per character as KERNAL CHROUT on the normal text screen ... (that should tell you something ) ... and the accompanying scrolling routine is capable of scrolling 30 lines per second! I used these routines also elsewhere, and they're available as library. DarwinNE made good use of the routines in his adventure games.