Let's talk about Pixel plotting

[Qwe]

Hi guys,
I'm searching a very optimized 6502 code for a pixel draw routine.
Do you know the fastest possible routine for an Atari 8 bits?
I don't find any optimized code, but only generic code.
What techniques do you suggest for a very fast pixel draw routine?
Thank you

[Irgendwer]

Maybe you like to inspect this thread:

 

http://atariage.com/forums/topic/241728-pixels-per-second-in-antic-0d/?do=findComment&comment=3301511

[Rybags]

Techniques - first up, the why and how the OS routine is so slow.

 

The OS plot pixel has CIO overhead and is part of the S: handler. As such it shares lots of program code with text mode handlers and also covers all the supported graphics modes where you can have resolution from 40 to 320 pixels across and 24 to 192 vertical. And pixel depth of 1, 2 or 4 bits per pixel, or 8 if you're doing a character mode.

 

Another overhead is the fact the 320 pixel mode is supported, we have 2 bytes representing the X position regardless of what graphics mode we're in.

So, the OS routines to do graphics and even text are way slow compared to the theoretical optimums.

 

Techniques to do your own fast code. First up, a table of vertical start addresses for X=0, Y= 0 through <mode height> can speed things up enormously. This saves time when calculating what the pixel's location in memory is.

Additionally, embedding your plot routine rather than having it as a subroutine can help although if it's used in many places that might be a problem.

As mentioned before, if not for hires then representing Xpos as a single byte can help also.

Hard-coding the routine to a particular graphics mode will also help, ie only cater for 2 or 4 colour modes. Although a routine for Gr. 15 will work equally well with Gr. 7.

Hard-coding a dedicated pixel erase routine or in fact a routine to do a particular colour can save time at the expense of memory.

 

Realistically though, single pixel plotting is a very inefficient way on the 6502 to do graphics. It's a necessary thing though if doing line-draws, which in themselves are something that's been optimised in the demo scene.

In many cases, software sprite stamping routines might be more efficient.

For stuff like vertical and horizontal lines, dedicated routines might be worthwhile.

 

For stuff like random fadeout or starfields, you can have optimisations such as mirroring the pixel (2, 4 or more copies in a symetric sense).

[Irgendwer]

Techniques - first up, the why and how the OS routine is so slow.

...

 

Sounds like you should write a book/guide for starters. That would be really helpful as the information here seems to be too scattered.

I like the style of your explanations.