(good) MSX-emulator for mobile phones?

Página 3/4
1 | 2 | | 4

Por Dinomight

Resident (46)

imagem de Dinomight

04-07-2003, 01:17

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

I'm with u too Master Wink 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' Smile 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 Big smile

Por MOA

Champion (293)

imagem de MOA

04-07-2003, 02:29

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

I'm with u too Master Wink 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' Smile 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 Big smile

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)).

Por MOA

Champion (293)

imagem de MOA

04-07-2003, 02:33

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?

Por MOA

Champion (293)

imagem de MOA

04-07-2003, 02:40

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

Por anonymous

incognito ergo sum (116)

imagem de anonymous

04-07-2003, 02:56

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.

Por anonymous

incognito ergo sum (116)

imagem de anonymous

04-07-2003, 02:57

>>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.

Por MOA

Champion (293)

imagem de MOA

04-07-2003, 03:00

>>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.<

Cool, I didn't know that Smile 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.

Por MOA

Champion (293)

imagem de MOA

04-07-2003, 03:05

>>
>>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?

Por anonymous

incognito ergo sum (116)

imagem de anonymous

04-07-2003, 03:49

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 Smile

Anyway, off-topic but talking about tiles and speed; the PowerVR (Kyro) 3D chips used tilebased rendering too Smile 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!

Por Thom

Paladin (685)

imagem de Thom

04-07-2003, 09:15

fMSX has been ported to GP32 and it seems to be one of the good working emulators for this handheld.

Here's some interesting reading:
http://www.retrogames.com/gp32flu_review_1.html
http://www.retrogames.com/gp32flu_review_2.html

(including some screens of MG2 running on GamePark32)

Página 3/4
1 | 2 | | 4