Curious question about 8-bit era character ROMs

[bugeyedcreepy]

So, in the 8-bit world, I seem to remember some early programming tricks to get faster gaming, was the ability of some 8-bit era systems to have reprogrammable character ROMs, and many side/top down scrollers and simple graphic adventure games would use reprogrammed character tables to populate with repeatable graphic blocks in lieu of processing time spent drawing graphics, at least until sprites were a thing - am I remembering this right?

[Editor]

So, in the 8-bit world, I seem to remember some early programming tricks to get faster gaming, was the ability of some 8-bit era systems to have reprogrammable character ROMs, and many side/top down scrollers and simple graphic adventure games would use reprogrammed character tables to populate with repeatable graphic blocks in lieu of processing time spent drawing graphics, at least until sprites were a thing - am I remembering this right?

Yes. My recollection was that the first “graphic” systems (that I used), were based on chunky graphics characters that were built-in to the fixed character ROM.

I recall using the venerable 2513 character generator IC in several projects during early fixed ROM character generator designs.

Then, later, we had RAM based character generators, allowing us to programatically re-define characters on the fly.

So, I do remember being excited by the new found power that Sprites gave us.
With character based graphic images, we were limited to placement aligned with a character cell, and also limited to how many characters available simultaneously per screen. In addition we had to track our own collision detection.

Although you could pre-load your custom characters, the reality is you often needed to re-define characters on the fly, depending on the screen (level?) you were drawing.

I think I first played with Sprites on a TMS9929A Video Display Processor, and then later on my Commodore 64.

With the processing power limitations of 8-bit CPUs, and the need to redraw our game screen changes 50 times per second (or 60 times with NTSC), and in some cases the need to do this during CRT vertical retrace, the power of hardware Sprites (with hardware automated collision detection), was truely a breakthrough.

[epaell]

Effectively the TMS9929A VDP is also like a reprogrammable character generator (when not using the sprites) because its screen is organised in a grid of "patterns" (characters) which are defined in pattern memory (effectively a character generator in RAM). The alignment issue can be somewhat overcome by having bit-shifted versions of the pattern (but obviously that chews into the overall number of patterns that you can have). Having said that, for situations where you are scrolling many of such patterns horizontally it can be very fast because you can just shift two of the patterns in memory (one pattern is where the pattern starts and the other pattern where it shifts into) and it'll shift all of the instances of that pattern on the screen e.g. perfect for something like space invaders i.e. rather than shifting each invader you just shift the pattern definition for one and all of them update simultaneously In practice it is a little bit tricker than that though (because you need to treat explosions and missing invaders carefully).

Graphics Mode II on the chip actually has a pattern possible for every character that can be displayed i.e. there are 768 character positions (32x24) and there are 768 pattern definitions. So you can use it either as a character display where the patterns definitions are fixed and you just choose which ones are displayed in character memory or as a kind of video memory e.g. where the display simply has characters 0-767 in sequence in memory and then you just modify the pattern for each character to generate graphics.

[bugeyedcreepy]

Effectively the TMS9929A VDP is also like a reprogrammable character generator (when not using the sprites) because its screen is organised in a grid of "patterns" (characters) which are defined in pattern memory (effectively a character generator in RAM). The alignment issue can be somewhat overcome by having bit-shifted versions of the pattern (but obviously that chews into the overall number of patterns that you can have). Having said that, for situations where you are scrolling many of such patterns horizontally it can be very fast because you can just shift two of the patterns in memory (one pattern is where the pattern starts and the other pattern where it shifts into) and it'll shift all of the instances of that pattern on the screen e.g. perfect for something like space invaders i.e. rather than shifting each invader you just shift the pattern definition for one and all of them update simultaneously In practice it is a little bit tricker than that though (because you need to treat explosions and missing invaders carefully).

Graphics Mode II on the chip actually has a pattern possible for every character that can be displayed i.e. there are 768 character positions (32x24) and there are 768 pattern definitions. So you can use it either as a character display where the patterns definitions are fixed and you just choose which ones are displayed in character memory or as a kind of video memory e.g. where the display simply has characters 0-767 in sequence in memory and then you just modify the pattern for each character to generate graphics.

That really is an intriguing set of potential clayton's sprites going on before even getting to the legitimate sprites - this would certainly be something I'll want to learn more about when I get my time back...

[Editor]

The TMS9918A VDP family (including the TMS9928A & TMS9929A) were the first to really add some awesome colour graphics power & flexibility to the 8-bit generation.

This compares to the similarly aged MC6847 VDG (as used in the CoCo), which was really pretty basic in it’s capabilities and had no sprites, and also not particularly suited to the PAL market.

What really took my interest on my re-discovery journey (upon finding my old TMS9929A chips), was the advent of the TMS-RGB module.

The only issue with the early computer & console devices that used the TMS VDP, is that typically they had only a RF or Composite Video output, so the TV image produced was always impacted by video artifacts and never really showed-off its full image quality potential.

That’s where, when I teamed up my old TMS9929A chips with the new TMS-RGB module, outputting to a modern RGB monitor, I was able to see the full potential image quality of this 80’s VDP, for the first time!

It was like the TMS VDP had a new life, and was at last was able to display its full potential image quality.

Combining this discovery with the TMS VDP being well matched to the performance capabilities of the 8-bit generation of microprocessors, it was the natural choice for my first MECB Display Card, for some renewed 8-bit experimentation!

[epaell]

Indeed, having a modern video output is a real game-changer (pun-intended), having become so accustomed to seeing rock-solid digital video it was really painful going back to watching composite sources of video ... not to mention the difficulty of finding displays that'll support them.