Tilebased screenmodes allow you to do very quick partial screen updates (dirty rectangles). In fact, in GEM I approach SCREEN5 (bitmapped) as a tilemode for the purpose of speed. If you arrange the tiles right, you can access it both bitmapped and tiled.
And ofcourse having sprites really speeds up emulation of any sprite-capable system like MSX.

So yes, a GBA has a big headstart compared to a simple bitmap/framebuffer screen.

Offtopic, but as far as I understand it the GP32 has a CPU 6 times as powerful as GBA, but it has a simple framebuffer only. I wouldn't be surprised that if you wanted to emulate on GP32 the same video features GBA offers, you'd waste all your extra CPU speed to just that purpose.

Quote:

Tilebased screenmodes allow you to do very quick partial screen updates (dirty rectangles). In fact, in GEM I approach SCREEN5 (bitmapped) as a tilemode for the purpose of speed. If you arrange the tiles right, you can access it both bitmapped and tiled. And ofcourse having sprites really speeds up emulation of any sprite-capable system like MSX. So yes, a GBA has a big headstart compared to a simple bitmap/framebuffer screen. Offtopic, but as far as I understand it the GP32 has a CPU 6 times as powerful as GBA, but it has a simple framebuffer only. I wouldn't be surprised that if you wanted to emulate on GP32 the same video features GBA offers, you'd waste all your extra CPU speed to just that purpose.

Dirty rectangles certainly speed up things, but isn't that only usable in a frame based renderer? Will it still emulate screensplits/hblank effects correctly? (i.e.: waves/mode switches halfway the screen/palette switches/etc.)... These are used quite extensively on MSX (the MSX2 logo already uses it... SpaceManbow & Aleste 2 are other examples).

About GP32: yes, it has a 16 bit frame buffer (or maybe two for double buffering) and a 200Mhz ARM8, I believe. Basically a pocket PC without OS (hurray!) in a GBA (not SP) alike case.

GBA has a real nice VDP with modes like:

Mode 0: 4 tile based layers (16c/256c per tile) with 128 sprites (32kB sprite VRAM, 64 kB tile/attribute VRAM)
Mode 1: 2 tile based layers (16c/256c per tile), 1 tile based rotation/scaling layer (256c per tile) with 128 sprites (32kB sprite VRAM, 64 kB tile/attribute VRAM)
Mode 2: 2 rotation/scaling layers (256c per tile) with 128 sprites (32kB sprite VRAM, 64 kB tile/attribute VRAM)
Mode 3: 240x160 bitmap mode, 15 bit (32k) colors, 1 frame buffer, 128 sprites (16kB sprite VRAM, 80 kB frame buffer VRAM)
Mode 4: 240x160 bitmap mode, 8 bit (256c, paletized) colors, 2 frame buffers, 128 sprites (16kB sprite VRAM, 80 kB frame buffer VRAM)
Mode 5: 128x160 bitmap mode, 15 bit (32k) colors, 2 frame buffers, 128 sprites (16kB sprite VRAM, 80 kB frame buffer VRAM)

Sprites can be 16c or 256c, ranging from 8x8 to 64x64... rotation/scaling is possible too.

Alpha blending/brightness control: one setting, which can be used by layers and/or sprites.

But whether these features are usable by scanline renderers... I still doubt it

Unless they changed the specs GP32 has a ARM9 clockable to 133MHz, but only capable of reaching that when running 100% from cache. I believe ~96 MHz is the highest possible for the RAM.

Quote:

Dirty rectangles certainly speed up things, but isn't that only usable in a frame based renderer? Will it still emulate screensplits/hblank effects correctly? (i.e.: waves/mode switches halfway the screen/palette switches/etc.)... These are used quite extensively on MSX (the MSX2 logo already uses it... SpaceManbow & Aleste 2 are other examples).

You can certainly use dirty rectangles and still emulate splits and effects properly. In fact, GEM does exactly that
Although it's currently only accurate to 8 lines, a slightly more complicated renderer could support line based hblank fx/splits and still work with dirty rectangles. I believe openMSX does it, tho I'm not 100% sure.

Quote:

Dirty rectangles certainly speed up things, but isn't that only usable in a frame based renderer? Will it still emulate screensplits/hblank effects correctly? (i.e.: waves/mode switches halfway the screen/palette switches/etc.)... These are used quite extensively on MSX (the MSX2 logo already uses it... SpaceManbow & Aleste 2 are other examples).

Yes, GBA can handle screen splits or whatever you want by checking an special register that tells you the actual scanline. It is also possible to generate an interruption at certain scanline.
Two years ago I ported PuddleLand to GBA and used the well-known horizontal wave effect in a background layer (to simulate underwater stages)
As far as I know, it is possible to modify things in the same scanline, to generate a vertical & horizontal wave effect.

About tile modes. I really think that it speed thing up when emulating tile based screens (like Foon does for emulating an spectrum)

Quote:

>> Dirty rectangles certainly speed up things, but isn't that only usable in a frame based renderer? Will it still emulate screensplits/hblank effects correctly? (i.e.: waves/mode switches halfway the screen/palette switches/etc.)... These are used quite extensively on MSX (the MSX2 logo already uses it... SpaceManbow & Aleste 2 are other examples). << Yes, GBA can handle screen splits or whatever you want by checking an special register that tells you the actual scanline. It is also possible to generate an interruption at certain scanline. Two years ago I ported PuddleLand to GBA and used the well-known horizontal wave effect in a background layer (to simulate underwater stages) As far as I know, it is possible to modify things in the same scanline, to generate a vertical & horizontal wave effect. About tile modes. I really think that it speed thing up when emulating tile based screens (like Foon does for emulating an spectrum)

Well, I know pretty much anything about the GBA, and yes it has a VCOUNT interrupt (generate an interrupt @ a certain line). Most HBlank effects on GBA are generated through HBlank DMA, though (i.e: for a sine wave you'd only have to create a HSCROLL table for a certain layer and say: DMA one entry of this table to the HSCROLL register for layer <n> for every line).

But the VCOUNT register is not usable by emulators unless they guarantee a steady 60fps. In all other cases they would have to emulate the line interrupt by checking the VDP settings each line (i.e.: a set amount of CPU ticks) and by performing the correct drawing commands according to these VDP settings for each line in the frame buffer.

At least that's what my locigal thinking brain told me just now...

Quote:

But the VCOUNT register is not usable by emulators unless they guarantee a steady 60fps. In all other cases they would have to emulate the line interrupt by checking the VDP settings each line (i.e.: a set amount of CPU ticks) and by performing the correct drawing commands according to these VDP settings for each line in the frame buffer. At least that's what my locigal thinking brain told me just now...

Maybe you are right, but it should not be a problem to emulate effects like the ones used in Space Manbow, Aleste, etc... I think GBA hardware is good enough to emulate MSX VDP in a easy way (tiles, palettes, sprites, bitmap modes, etc...)
The main problem is that you will need to write an acurate MSX emulator designed for GBA, and not to port fMSX, for example, since (I think) it uses a bitmap mode for emulating the VDP.

Quote:

(p/s: am I the only one here without a mobile phone, or are you still with me Thom )

I'm with u too Master but! I was @ Impulz 28-6 and my friend took pics with his Nokia mobile (i can ask the number, i dunno) at 640-480! is he talking nonsense? Also we agreed that in Japan they already have much better rez' The phone could take streaming wavs, as he took a 1 minute sample from Underworld (which we listened back later(maybe 8-bits))..i don't know any specs at the mo, but i can check the Cerial and get back to you on that

Quote:

>> (p/s: am I the only one here without a mobile phone, or are you still with me Thom )<< I'm with u too Master but! I was @ Impulz 28-6 and my friend took pics with his Nokia mobile (i can ask the number, i dunno) at 640-480! is he talking nonsense? Also we agreed that in Japan they already have much better rez' The phone could take streaming wavs, as he took a 1 minute sample from Underworld (which we listened back later(maybe 8-bits))..i don't know any specs at the mo, but i can check the Cerial and get back to you on that

Well, the pictures might be 640*480 after transferring them to PC (i.e.: in RAM they are stored as 640*480, but on-screen they should display @ around 176*208 (which is the Nokia N-Gage resolution)).

Quote:

Although it's currently only accurate to 8 lines, a slightly more complicated renderer could support line based hblank fx/splits and still work with dirty rectangles. I believe openMSX does it, tho I'm not 100% sure.

Hmm... Why would openMSX utilize such renderer? It only runs on platforms which use per-pixel-addressing frame buffers, right?

Quote:

Unless they changed the specs GP32 has a ARM9 clockable to 133MHz, but only capable of reaching that when running 100% from cache. I believe ~96 MHz is the highest possible for the RAM.

Sorry for nagging... but if a CPU runs at 133Mhz, it runs @ the same speed all the time. The fact that certain parts of RAM/ROM require more wait-states doesn't mean that the CPU is running at a lower speed.

Sure, the ARM chip has pipeline-stages (I believe there are 5 stage on an ARM9) and these won't really work optimally when the accessed RAM/ROM (which either contains code or data) has multiple wait-states. But saying that the CPU runs @ a lower clock frequency because of it, is not true.

For your info: the GBA has no cache and the wait-states are pretty bad:

32kB of internal RAM, 32-bit bus @ 0 wait-state
256kB of external RAM, 16-bit bus @ 2 wait-states
96kB of Video RAM, 16-bit bus @ 2 wait-states
(some other VRAM related areas which I'm not going to mention)
4MB..64MB of ROM, 16-bit bus @ 2/3 wait-states (2 wait-states @ sequential read, 3 wait-states @ random-read... plus it has a prefetch buffer which can speed up reads from ROM).

In other words:

executing a 32-bit ARM instruction from internal RAM adds 0 wait-states overhead
doing the same from ROM will add either 4 or 5 wait-states of overhead (depending on the previous command).

Luckily the ARM processor has two instrucion sets: a 16-bit instruction set (Thumb) and a 32-bit instruction set (ARM).

executing

Quote:

Sorry for nagging... but if a CPU runs at 133Mhz, it runs @ the same speed all the time. The fact that certain parts of RAM/ROM require more wait-states doesn't mean that the CPU is running at a lower speed.

The GP32 CPU clock can be set by software.

Quote:

>>Although it's currently only accurate to 8 lines, a slightly more complicated renderer could support line based hblank fx/splits and still work with dirty rectangles. I believe openMSX does it, tho I'm not 100% sure. << Hmm... Why would openMSX utilize such renderer? It only runs on platforms which use per-pixel-addressing frame buffers, right?

I think you missed the point.

Quote:

>>Sorry for nagging... but if a CPU runs at 133Mhz, it runs @ the same speed all the time. The fact that certain parts of RAM/ROM require more wait-states doesn't mean that the CPU is running at a lower speed.<<The GP32 CPU clock can be set by software.

Cool, I didn't know that You have any idea what the wait-states of the GP32 RAM/VRAM etc. are?

Some info from the web:

What is the clock speed of the GP32?

This is software selectable from many different speeds from ~22MHz up to ~133.5MHz. The slower the selected speed, the longer the battery life that you will experience. However, just because the CPU can be set for very high speeds does not mean that the rest of the system (in particular the SDRAM) can handle this speed as well. Bios v1.5.7 defaults the clock speed to 67.8MHz. FireFly and others have managed to run their GP32 at up to 99MHz, with instruction and data cache on, without noticeable problems. Some people appear to experience problems at this speed.

Quote:

>> >>Although it's currently only accurate to 8 lines, a slightly more complicated renderer could support line based hblank fx/splits and still work with dirty rectangles. I believe openMSX does it, tho I'm not 100% sure. << Hmm... Why would openMSX utilize such renderer? It only runs on platforms which use per-pixel-addressing frame buffers, right?<< I think you missed the point.

I guess I did :/

So does OpenMSX us a tilebased renderer or does it use a scanline renderer using a framebuffer?

I don't think it uses a (8x8) tilebased renderer, but AFAIK it does use dirty rectangles and cache, which serve the same purpose: speed. It certainly doesn't have a conventional scanline based renderer, because it has pixel accuracy.
Anyway, mth wrote the thing. Maybe he feels like talking a bit about it

Anyway, off-topic but talking about tiles and speed; the PowerVR (Kyro) 3D chips used tilebased rendering too I wonder if that's still possible with things like pixel and vertex shader programs nowadays... And the quick Z-buffer clear techniques used by ATI and nVidia are also tilebased.

Tiles rock!