Bitmapped Display Template

[+SmittyB]

 

Having experimented with a bitmapped 320A display in Plink I've been thinking of the possibilities that allows, and so I've also been experimenting with line drawing.

 

I've put together some example code that can be used as a starting point for anyone interested.

BitmapTemplate.bas BitmapTemplate.a78

[+Karl G]

He's being too nice to say that he put it together because I requested help with creating a bitmapped display using 7800basic.

 

It has already been a great help, and your comments have helped what I hadn't yet understood yet from the 7800 software guide, so thank you very much for putting this together @SmittyB. 

[RevEng]

Hey, that's worthy of a run-in-browser JS7800 link! Very cool!

[+Stephen]

That's really cool - the 7800 doesn't have a conventional frame buffer does it?  Sorry - never coded on it before, just the8-bit computer line.

[+SmittyB]

7 hours ago, Stephen said:

the 7800 doesn't have a conventional frame buffer does it?

No it doesn't. Essentially the 7800's strength is in drawing large sprites, so I'm filling the screen with rows of sprites and telling the system that their graphics data can be found in RAM rather than ROM, then as long as I write to that area of RAM in the correct order I can put a dot anywhere within the bounds of those sprites.

 

With the ability to put a dot on the screen that then opens up the ability to plot the points of a line (though there are more efficient ways than drawing it point by point), and once it's possible to draw lines then it's possible to draw shapes including maybe wireframe 3d which I would love to see.

 

This 256x192 bitmap takes 6k to store, so in a typical 128k + 16k RAM cartridge it would be possible to double buffer the screen and have 4k plus the system RAM left over. If one were quick enough, it would also be possible to bankswitch RAM while in vblank to process the game state before switching back to do the drawing.

[+Karl G]

It's not listed in the manual, but there's also a non-bankswitched 32kRAM romsize that could be used with this for projects small enough to fit into 32K of ROM with the 16K of RAM.

[RevEng]

One possible variation that anyone looking into implementing this should be aware of. The 7800 Rescue On Fractalus proto uses "mirror ram" (where each even page is mirrored to the next odd page) to draw graphics at half the vertical resolution. While a coarser resolution doesn't seem like a bonus feature, it does mean you have less screen to update, which speeds up your screen updates.

 

a7800, concerto, and the 7800 MiSTer core all support the mirror ram header flag. Implementing mirror ram in any real-hardware cart with ram is trivial - just lift one memory chip leg and ground it.

 

1 hour ago, Karl G said:

It's not listed in the manual..

Oops! I guess I have an update to make.

[+SmittyB]

Another nice advantage of that mirror mode is that you can then bitmap with the 160 modes and get square pixels which might look better in some circumstances.

 

Speaking of 160A, it should be fairly simple to modify the code as it relates to getting the bitmask to allow for 4 colours. You could adjust the offset into the table so that the first set of entries are the offsets for colour zero, the next for colour one, etc. You could even have it so that adjacent x coordinates write to the same pixel as a sort of free sub-pixel accuracy, and you wouldn't need to account for the ratio difference between x and y elsewhere in the program.

A lovely side-effect of the 7800's wide pixels is that a 160A bitmap would have the same footprint in memory as a 320A one so you don't need to have separate lookup tables for each version relating to how the lines are arranged.

 

I might have a play around with those ideas and see how things go.

 

[+SmittyB]

There are a few things I overlooked with 160A but nothing that's not easy to work around.

There're a lot of things to tweak to get it perfect but as a proof of concept it shows that 160A bitmaps are easily doable.

 

[+SmittyB]

I've made the adjustments to the 160A drawing and have adjusted the 320A drawing with similar logic. Rather than using EOR to erase the lines by drawing over them again, you  specifically choose the colour and it will draw in that colour. That gives much better results when lots of drawing is happening in a small space such as the middle of the circle.

 

 

On this updated ROM you can press select to switch between the 320A and 160A loops.

JS7800

 

 

 

BitmapTemplateV2_220123.a78 BitmapTemplate.bas

[Trebor]

I tried my best to avoid the mention, but that last update, I just can't help myself..

 

   

 

[+Muddyfunster]

@SmittyB This is really cool stuff. Thanks for sharing it.

[+-^CrossBow^-]

Finally the ribbon screen saver comes home to the 7800! Make it respond to music and we could have a VLM for the 7800.

 

[+Karl G]

I'd also be curious to try 320B mode in kangaroo mode - presumably one could get 3 colors without restrictions as transparency wouldn't be an issue in this case?

[+SmittyB]

320B would definitely be doable with kangaroo mode enabled for 4 hi-res colours. In terms of drawing it would essentially be equivalent to 160A but with modified masks as the bits are in a different order.

 

The tricky bit is that while 160A and 320B are both 2bpp modes, with 160A's wide pixels it takes up the same screen space as 320A whereas 320B is drawn half as wide. That means unless you're happy with a 160 pixel wide bitmap you need an extra DL entry per zone, double the memory to hold the bitmap, and double the processing power to draw something the same visible size.

[+Karl G]

Right I get that. I wasn't sure if there's enough time to render a single 256 pixel wide 320B sprite in each zone. If there is, and assuming enough RAM could be spared for it, it opens up a lot of possibilities. 

[RevEng]

Yep, there's enough DMA time for that (you'd actually need multiple objects, due to the 32 byte limit) and you'll probably have gas in the tank for other objects on top. You can fill the screen with the more expensive modes, provided you're not doing it with an excessive number of objects.

 

One thing that may help you to transfer experience between modes... The cheap modes (160A, 320A, 320D) are all equivalent in terms of DMA-used-for-%-screen-coverage, and the expensive modes (160B, 320B, 320C) are also equivalent for the same metric.

[+Pat Brady]

To be more specific, 256 pixels in 320[BC] can be done with 2 objects, 64 bytes each, using 5-byte headers. That works out to 212 MARIA cycles per line which does leave time for several small objects.

 

That's similar to what I'm doing in 7ix, which is 192 pixels across and in 320C. By my calculations I will be right at the limit, maybe slightly over, in the unlikely event that all objects are in the same zone. (BTW my progress has been rather sporadic, I keep taking breaks for RL stuff and/or doing music, but I'm hoping to do an alpha release sometime soon.)