Using a VIA for video bank switching...

[cbmeeks]

Maybe this is a crazy idea...but I was thinking.

I want to use a TMS9918 in a SBC that I'm working on. But I will try to implement SRAM instead of DRAM (using latches). I would use a 512K SRAM (55ns).

The TMS9918 only addresses 16K of RAM. So I thought, what if I used a 65C22 to bank switch multiple 16K blocks?

The TMS9918 would only know about 16K but during vertical blanking, I could use the VIA to swap out the banks.

I was thinking the TMS9918 (VDP) would connect to the first 16K using A0:A13.

The VIA would then connect through PORT A from A14:A18. My ROM would set the DDRA to out for the pins. Then, it would be a matter of poking $00 for the first 16K of RAM, $01 for the second 16K, etc. All the way up to 32 banks.

I know there would be a few issues with this already. One, the programmer would need to make sure to only change the bank during vertical blanks or there would be shearing on screen.

Also, I'm not sure yet what would happen if the VDP was reading/writing a bunch of addresses and then I suddenly changed the banks. Perhaps I would have to put some glue logic in to only change banks at a certain time.

What are your thoughts?

The idea of page flipping 32 different ROM banks for a TMS is exciting. This would literally allow you to have smooth scrolling because you could copy the font set in all 8 directions and just toggle between them.

[Dr Jefyll]

I'm no TMS9918 expert, but your idea for swapping memory banks sounds workable. As noted, you'd have to be careful about when the swaps occur, and it seems you're on top of things there. But I don't see the smooth scrolling idea as being so easy. Isn't it true that you'd need fonts that contained every possible combination of the incoming and outgoing character?

[cbmeeks]

Dr Jefyll wrote:

Isn't it true that you'd need fonts that contained every possible combination of the incoming and outgoing character?

You would need X number of copies of the entire font. For example, if you want to scroll horizontally only, then you would need four copies of the font. That would give you 2 pixel movements.

This is a common practice on other computers too like the C64. But having 512K allows a lot of copies. 32 of them.

So you can afford to be a little wasteful.

[Dr Jefyll]

I'm not a C64 expert either, but I think I follow you now. I found a site that talks about C64 smooth scrolling, and learned that "the VIC-II chip has two hardware scroll registers, one horizontal, one vertical."

I gather there are various ways to use the registers. The technique described on the site
uses hardware scrolling to manage 7 out of 8 shifts, then for the 8th a block-move is needed. To meet timing constraints, the block move happens in pieces and in advance. "we need to implement double buffering. We’ll reserve another 1000 byte block in RAM to be our back buffer. This allows us to shift screen data at any time, because we are writing to the back buffer, not the visible screen." Interesting! Is this the technique you're referring to?

[cbmeeks]

Yes, that's essentially it.

However, the TMS9918 doesn't support any hardware scrolling. So it's faked by storing multiple copies of the same characters but each is shifted in a certain direction.

If you have the ability to instantly point to a different copy, you give the illusion of scrolling. But in reality, nothing is moving.

For example, if you had a character like so (only one line for brevity):

Code: Select all

ZZOOOOXX

You then store the extra copies like:

Code: Select all

ZOOOOXXZ
...
OOOOXXZZ
...
OOOXXZZO
...

Anyway, this is all theory because I don't know how the TMS would respond to changing its memory like that. I don't know of any system that has ever done this with a TMS.

[Dr Jefyll]

Say you have an "H" and an "I" side by side, and each is 8 pixels wide. It seems to me the scan line passing through the middle, for example, needs to show:

Code: Select all

01111110 00001000, then...
11111100 0001000?, then...
11111000 001000??, then...
11110000 01000???, then...

... and so on. (The question-mark is for bits arriving from even further over, to the right of the "I".

[cbmeeks]

Yeah, I think you got it.

A classic example of this is a bullet sprite, for example.

Code: Select all

0 0 0 0 0 0 0 0
0 0 0 1 1 0 0 0
0 0 1 1 1 1 0 0
0 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0

If you draw this at any given position, you will see it as:

Code: Select all

. . . • . . .

Then, you can shift the pixels for that character. But, this takes CPU time. If you pre-shift it and just change the pointer to it, then it takes almost no CPU. But it costs you RAM.

So the bullet sprite shifted could look like:

Code: Select all

0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 0 
0 0 0 0 1 1 1 1
0 0 0 0 0 1 1 0 
0 0 0 0 0 0 0 0

Which, when drawn in the SAME spot, appears to have moved over 2 pixels to the right.

Of course, there are other trade-offs. Like the pixels behind the bullet. On some games you can see this effect because it looks like the bullet has a black box around it. But it moves so fast it's no problem.

This technique is better used for background graphics. You draw a large area once. Then, swap the font out for the pre-shifted fonts. So it appears the background is moving. But your FOREGROUND chars stay the same in each copy. So they are not pre-shifted. This effect gives the illusion of a parallax scroll. C64 games do this all the time.

Anyway, didn't mean to turn this into a game design discussion. LOL