You can do a fair bit to speed up line draws in bitmap. If you're treating it as a pixel-addressable space, that will be much slower than remembering it's really a character based display. I haven't published my code yet, I don't think, but there are some examples here:

If you're interested in trying to adapt them, I can post. But Rasmus also has a fast line draw that's nearly as fast as my fastest, but doesn't require you to set up and use all the registers, which can be difficult for some (most) programs to swallow. It was actually his that I was planning to put in my library.

Yes, since in that case you don't know the boundary of the area beforehand. The idea is that you give what he actually wrote in the first post, a pixel position, not two pixels spanning a rectangle. Then, from that single position, you scout for the lines delimiting the area to fill.

Not very difficult to implement as long as the area is a box, but when the algorithm should be able to handle an arbitrary shape, then it becomes a lot more tricky. You will of course also have to check that you don't start filling outside the screen, or outside a viewport, if you implement a viewport concept.

Even if it will perform slower, the time saved when writing programs that use such a function is tremendous, if the areas you want to fill are complex.

When I wrote my line drawing algorithm, it got pretty fast when implemented in assembly language. Then I learned about Bresenham's algorithm, and tried that. It was a bit faster, since it uses a somewhat simpler math to do the same thing as I did.

Yes, since in that case you don't know the boundary of the area beforehand. The idea is that you give what he actually wrote in the first post, a pixel position, not two pixels spanning a rectangle. Then, from that single position, you scout for the lines delimiting the area to fill.

Not very difficult to implement as long as the area is a box, but when the algorithm should be able to handle an arbitrary shape, then it becomes a lot more tricky. You will of course also have to check that you don't start filling outside the screen, or outside a viewport, if you implement a viewport concept.

Even if it will perform slower, the time saved when writing programs that use such a function is tremendous, if the areas you want to fill are complex.

When I wrote my line drawing algorithm, it got pretty fast when implemented in assembly language. Then I learned about Bresenham's algorithm, and tried that. It was a bit faster, since it uses a somewhat simpler math to do the same thing as I did.

Well it's not even a fill routine but a clear routine that Thom needs.

yeah, this would essentially be a fill routine, as the color selected is either the background or foreground color (depending on the desired writing mode). If you run the current build of PLATOTerm off my server (TIPI version can be streamed), and float around in the menus, you'll see why I am trying to find a faster solution to what I have...

As mentioned, the GM2 (graphics mode 2, i.e. bitmap) is tile-based on the 9918A, so the fastest routines will be ones that manipulate the pixels in byte-size chunks (8 pixels at a time). Also, if you can guarantee that the blocks will be on 8-pixel boundaries, you will not have to deal with the special cases Rasmus pointed out and the routine would be simpler and faster. Also, using a buffer in 16-bit scratch pad RAM that holds one horizontal line would probably help, since the VDP address register would only need to be updated once per line.

Are you trying to do this 100% in C? Do you know any 9900 assembly and/or the details of the 9918A's memory use for GM2?

If you are overwriting everything in the VDP memory anyway, you only need to reload the VDP write address once per row. It's only if you want to handle border cases you need to read, modify and write..

Here we're talking about drawing/erasing a line in a consecutive sequence of bytes. Using a buffer memory in such a case will only give you a redundant transfer from VDP memory to the buffer, a redundant modification to the buffer (it's mainly the same byte content that should be copied to multiple locations) and, finally, actually updating the VDP memory with the result.

You do need to go through all steps for the border cases, but they involve only a single byte per side of your area to clear.

You also have to think about that graphics 2 mode involves both a bitmap of pixels, as well as a "bytemap" of colors. Just erasing pixels doesn't necessarily say that you get to see the backdrop, as the background color for that byte of pixels may not be transparent.

Thanks for sharing this link. I spent hours reading examples! I notice they don't have TMS9900 assembly, though they have Z80, 6502, PDP-11 as well as ARM and x86. And lots of 8-bit machine BASICs. I wonder if we could populate some examples?