Have you seen such a video mode?

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Have you seen such a video mode?

Post by aa-dav »

About a year ago I decided to design some retro-style PC as virtual machine (emulator) and came up with video mode which combines tiles and pure graphic in very simple manner.
Usually tile/text-based video modes (like in consoles including NES) make harder to implement graphic (like vector graphic) and graphic video modes make it slower to draw text or tiles.
First thing is due to linear disposition of tiles in memory: there is linear array of tiles/chars which are mapped to screen via tile grid.
On the other hand (linear) graphic modes involve a lot of memory copy to update one symbol of text. So, for example, ZX Spectrum which has no text mode, but graphic only draws text slowly.

But I came up with video mode which can do both things easily combining them in easy way.

First of all it consists of bitmap plane 256x256 pixels. Visible part is 256x192, but it's not requrement.
It has linear layout, well, let it 4bpp, so every scanline is 128 bytes long, so overall bitmap is 32768 bytes.

But there is tilemap also and it works simultanously with bitmap. It has size 32x32 with 2 bytes per tile description.
It acts like bitmap is divided by squares 8x8 and each tile linearly corresponds to squares in bitmap.
32x32 gives us 1024 possible tiles in bitmap of 256x256 pixels.
In contrast with usual practices in cosoles images of tiles in this bitmap corresponds to visual image of square grid of tiles.
That is first scanline of bitmap contains array of 32 first lines of first 32 tiles one by one.
Second scanline of bitmap contains array of 32 second lines of first 32 tiles one by one.
...
Eighth scanline of bitmap contains 32 eighth lines of first 32 tiles one by one.
And at last ninth scanline of bitmap contains first lines on second 32 tiles (32-63).
And so on...

Tilemap contains numbers of tiles (0..1023) which are visible in corresponding cell of the grid.
That is, if we fill tilemap linearlly with numbers 0..1023 we get true graphic mode in bitmap. Every pixel will corresponds linearlly to it's position on the screen. Good to draw graphics.

But if we fill bitmap with grid image of alphabet, for example:
Image
(but keeping aspect ration 1:1 for 8x8)
then writing to tilemap will work like text/tile graphic mode!
Moreover, we have 6 unused bits in tile descriptors in tilemap and this can be used for 4 bit of subpalette increasing 256 colors per screen 16 colors per tile.
Adding scrolling capabilities and sprites will make it suitable for tilemap consoles, but just arranging tilemap makes it good graphic mode for 16-bit PC also.

It's importand to understand how videocontroller should fetch data from video memory.
Tilemap contains 16-bit entries in form of:
PPPP00HHHHHLLLLL
where PPPP is palette subnumber and HHHHHLLLLL is 10-bit (linear) number of tile.
Which bytes in bitmap will correspond to this tile number?
And it's easy! Let's suppose we have bitmap based in address 0x0000, then:
0HHHHHYYYLLLLLXX
So, HHHHHLLLLL is tile number, XX is four bytes corresponding to single horizontal line in tile. And YYY is eight such lines.
So, as we can see there is nothing but bit permutations in address line which is nothing difficult for schematics.

Have you seen something like that in real retro hardware?
Last edited by aa-dav on Wed Mar 23, 2022 3:07 am, edited 1 time in total.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Have you seen such a video mode?

Post by TmEE »

I have come up with a similar idea to combine tiles and bitmap simultaneously but I have not actually made any practical hardware yet (in my endless todo list lol). It is definitely worth exploring ~
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Have you seen such a video mode?

Post by tokumaru »

One problem with this is that tiles are harder to update on the fly (for background animations and the like), because they aren't stored linearly in memory. Unless you include some sort of DMA functionality that automatically rearranges bytes as you transfer tile data.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Have you seen such a video mode?

Post by 93143 »

aa-dav wrote: Wed Mar 23, 2022 2:36 amHave you seen something like that in real retro hardware?
tokumaru wrote: Wed Mar 23, 2022 4:07 amUnless you include some sort of DMA functionality that automatically rearranges bytes as you transfer tile data.
The SNES VRAM port has an address remapping feature that allows you to do something like this. It allows the CPU to work with un-tiled bitplane graphics arranged linearly in 256-pixel lines, and then have the PPU translate them into tile format on the fly during the DMA transfer to VRAM. The three remapping settings are appropriate for 2bpp, 4bpp, and 8bpp graphics. I suppose if you wanted, say, a 128-pixel-wide 4bpp buffer, you could use the 2bpp setting to wrap it early.

The remap settings also work with linear bytemap buffers with maximum line lengths of 32, 64 and 128 pixels respectively. This type of data gets translated into a Mode 7 tileset during the transfer (and if you don't use the matrix to rotate it, your framebuffer is column-major). Id used this method for Wolfenstein 3D. You could also simply use 256 solid-colour tiles, transfer the framebuffer into the tilemap instead of the tileset, and zoom out (as Jurassic Park did for indoor sequences), but the remap method has the advantage that if your framebuffer doesn't use the full 256 tiles, the remainder can be other graphics, and the bulk of the tilemap is free to display them.
Last edited by 93143 on Wed Mar 23, 2022 4:31 am, edited 1 time in total.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Have you seen such a video mode?

Post by aa-dav »

tokumaru wrote: Wed Mar 23, 2022 4:07 am One problem with this is that tiles are harder to update on the fly (for background animations and the like), because they aren't stored linearly in memory. Unless you include some sort of DMA functionality that automatically rearranges bytes as you transfer tile data.
I doubt this is serous issue.
As I wrote address of bitmap data for single tile has next bitmask (in case of video memory starting from 0x0000):
0HHHHHYY YLLLLLXX
where HHHHHLLLLL is tile number, YYY is number of horizontal line inside tile (0-7) and XX is eight paired (4bpp) pixel in that line.
If we talk about such 8-bit processor as i8080 it's subject of unrolled loop which is not bad.
At first we load hardcoded address of tile (it's usual for such animations to be tile hardcoded) into register pair HL.
After what we take into the loop of 4 increments of H (which corresponds to upper YY bits).
Inside we have unrolled loop which increments XX (that is L) four times and reloads L with Y bit set to 1 and makes another 4 increments with LD (HL), A, where A is loaded from linear tile data in that loop.
Both loops should be unrolled for perfomance and they don't look serious issue for me.

Moreover - if we want to update large area of big bosses task becomes easier and easier by arranging tiles in real rectangular bitmap plane of tiles which will even better corresponds to graphic data in game resources.

For example: if we will update 32 consecutive tile images on the same row in bitmap it will become linear update (memcpy) of 32*8*4 bytes with immediate effect in tiles on the screen. So, large tile updates are not issue anymore in this case.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Have you seen such a video mode?

Post by Bregalad »

I am not sure I understand what you ask.

Basically you suggest a tiled mode, where the individual pixels are easier to adress (without the bit shifts usually necessary in such cases) so it is easier to simulate a bitmap mode ? And that results that the annoying adress bit shiftings have to be done when dealing at the tile level instead. Is this correct ?

If I'm not mistaken, it sound like it is basically just moving adress pins arround in the hardware. I don't know if any retro hardware ever did something like that.
Useless, lumbering half-wits don't scare us.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Have you seen such a video mode?

Post by tokumaru »

He's basically suggesting that the "pattern table" be arranged like one 256x256 bitmap, rather than 1024 8x8 bitmaps. The "name table" would still reference 8x8 blocks, it's just that the individual blocks wouldn't be linearly stored in memory like is normally the case with old consoles. So if you wanted to update the screen as a bitmap, you could just fill the "name table" with sequential indices and manipulate the "pattern table" directly as a big bitmap.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Have you seen such a video mode?

Post by aa-dav »

tokumaru wrote: Thu Mar 24, 2022 4:43 pm He's basically suggesting that the "pattern table" be arranged like one 256x256 bitmap, rather than 1024 8x8 bitmaps. The "name table" would still reference 8x8 blocks, it's just that the individual blocks wouldn't be linearly stored in memory like is normally the case with old consoles. So if you wanted to update the screen as a bitmap, you could just fill the "name table" with sequential indices and manipulate the "pattern table" directly as a big bitmap.
Totally correct.

Bregalad wrote: Thu Mar 24, 2022 2:31 pm ...And that results that the annoying adress bit shiftings have to be done when dealing at the tile level instead. Is this correct ?...
I would say in another way: we work with tile images like we prefer to do it in game resources: like in plain bitmap 256x256 in picture editor.
It can be thought as "bit shifts", but I prefer to say "rectangular area blitting in render surface". In it's core it's not mind-bending bit shifts (however bit shifts are what videocotroller must do), but work with rectangular bitmap. Videocontroller starts with tile numbers and does bit shifts, but programmer just fills squares in bitmap.
So if we plug in rectangular blitter updating tiles becomes trivial and hardware accelerated task. However I think it's trivial without it.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Have you seen such a video mode?

Post by aa-dav »

I've implemented this several months ago in emulator of virtual PC based on my virtual CPU. I made topic about it here long ago.
It can be tested online: https://aa-dav.github.io/
It's better to click menu View->Set 400% first to make real aspect ratio in browser.
Then you can activate test programs in left list and click Emulator->Compile and Run.
First 5 tests uses text mode as bitmap is filled with rectangular image of font and text output procedures update name table only.
But test 6 set ups nametable to increasing numbers and writes to bitmap as linear graphic mode.

However in this virtual PC all registers and memory cells are 16 bit, so memory layout of tiles in bitmap are shifted right by 1 bit and assembler is unusual a little bit. More details of it could be read here https://github.com/aa-dav/SimpX
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Have you seen such a video mode?

Post by Gilbert »

I haven't read all of this in details so I probably missed a lot, but I more or less understand what is being achieved.

Since this is a fantasy/virtual system, unless 32kb is a limit you set to the tile/bitmap data I think life would be even easier to have 64kb available.

That way, in 4bpp mode, you have a 512 x 256 bitmap buffer (or 64 x 32 = 2048 tiles), which could be nice for scrolling stuff if the display window is say 256 x 192 (it's even good for display window like 320 x 240, etc.).
And you can even implement a 8bpp mode with a 256 x 256 bitmap buffer (or 32 x 32 = 1024 tiles like the original 4bpp proposal) which could be very nice as you can still define subpalette in each 8x8 region.

The catch is that, each line is then exactly 256 bytes, so that you can just inclement the high byte when you move to another line, which would be godsend if your (fantasy/virtual) cpu is not supposed to be very advanced and works best with 8 bit.

This is especially good when you're just updating one single tile. If each line is 128 bytes and the (16bit) start address is say S, you need to update
S, S+1, S+2, S+3
S+128, S+128+1, S+128+2, S+128+3
S+256, S+256+1, S+256+2, S+256+3
...
But if each line is 256 bytes you just need
S, S+1, S+2, S+3
S+256, S+256+1, S+256+2, S+256+3
S+512, S+512+1, S+512+2, S+512+3
...

It doesn't seem much different, but in fact when you add 256 to S, you just increment the high byte of S by 1 each time.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Have you seen such a video mode?

Post by TmEE »

It also is trivial to add a "tile upate" port into the access mechanism, where you do sequential writes and it builds the tile for you automatically. That's what my unbuilt design has in it, you can go and do sutff directly in VRAM but you stil have a typical data port too. I have had the idea of even giving multiple increment values that change every write, to allow arbitrary access patterns which may benefit some rendering methods.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Have you seen such a video mode?

Post by aa-dav »

Gilbert wrote: Fri Mar 25, 2022 1:55 am The catch is that, each line is then exactly 256 bytes, so that you can just inclement the high byte when you move to another line, which would be godsend if your (fantasy/virtual) cpu is not supposed to be very advanced and works best with 8 bit.
Old soviet 8-bit PC Vector-06C uses similar idea.
It has bitplane-oriented video memory layout in which incrementing high order byte of address increments horizontal position and incrementing lower byte of address increments vertical position (of 8-bit-line):
Image
Interesting thing about it - consequtive bytes are ordered into columns, not rows, which is better fit to this concept.

However my "fantasy system" is "ideologically fully true 16-bit", that is it has no bytes and memory cells are 16-bit like registers. Just 65356 of memory space of words which is 128Kb. So it has no benefits from this scheme. It's instruction set is very limited and it cannot just increment upper byte of value without full addition. It has no usual increment operations (because of limit for 16 diffirent opcodes), but emulates them through special form of addition which emulates 'move' also.
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Have you seen such a video mode?

Post by Shonumi »

aa-dav wrote: Wed Mar 23, 2022 2:36 am Have you seen something like that in real retro hardware?
I'm a bit late to the discussion, but I'd like to say that this reminds me of how the Pokemon Mini renders graphics. Tile Data for a screen is arranged according to a Tile Map. This information is processed by a Program Rendering Chip (PRC) which automatically renders this into a 1:1 framebuffer in memory, and then that framebuffer is pushed to the LCD. Once the tiles are rendered, however, the CPU can manipulate the framebuffer directly in RAM before pushing the final image. A handful of real games for the system relied on this technique too for graphics, so it's not something esoteric that only homebrew programs do.

This made the Pokemon Mini surprisingly flexible. You can do text/tile mode only, or you can use a hybrid mode (text/tiles rendered first, add bitmap manipulation on top), or completely disable text/tile mode and go for a pure bitmap image. For a system that only had a handful of games, it's actually rather interesting how unique/different its design philosophies were from other Nintendo hardware, especially other handhelds. At the end of the day, it's really a framebuffer-based device, but the presence of a text/tile mode makes it easy to build backgrounds, menus, and other stuff.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Have you seen such a video mode?

Post by aa-dav »

Shonumi wrote: Fri Mar 25, 2022 3:58 pm
aa-dav wrote: Wed Mar 23, 2022 2:36 am Have you seen something like that in real retro hardware?
I'm a bit late to the discussion, but I'd like to say that this reminds me of how the Pokemon Mini renders graphics. Tile Data for a screen is arranged according to a Tile Map. This information is processed by a Program Rendering Chip (PRC) which automatically renders this into a 1:1 framebuffer in memory, and then that framebuffer is pushed to the LCD. Once the tiles are rendered, however, the CPU can manipulate the framebuffer directly in RAM before pushing the final image. A handful of real games for the system relied on this technique too for graphics, so it's not something esoteric that only homebrew programs do.

This made the Pokemon Mini surprisingly flexible. You can do text/tile mode only, or you can use a hybrid mode (text/tiles rendered first, add bitmap manipulation on top), or completely disable text/tile mode and go for a pure bitmap image. For a system that only had a handful of games, it's actually rather interesting how unique/different its design philosophies were from other Nintendo hardware, especially other handhelds. At the end of the day, it's really a framebuffer-based device, but the presence of a text/tile mode makes it easy to build backgrounds, menus, and other stuff.
Interesting! I didn't even know about Pokemon Mini. I read detailes here: https://www.pokemon-mini.net/documentat ... copy-stage
It's approach is definitely different, but really behaves in some similar ways.
The most big differences are absence of memory copy and sprite engine which is not very flexible in Pokemon Mini (are tightly coupled with tilemap phase, so it's not very useful for pure graphics).
But it's really was interesting to discover Pokemon Mini and it's specs!
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Have you seen such a video mode?

Post by Pokun »

The concept is very interesting. So the advantage is that you can either treat it as text mode or a bitmapped mode at any time? And the main disadvantage is probably that it requires enough VRAM for the whole screen (which is one reason text modes are used in the first place).

I didn't know Pokemon Mini used something like this either. Now I want to get one. :)
Post Reply