my evil sonyerricson series 60 doesn't seem to want to install .sis files, evil contraption.

And as for a java msx emu.. I tried a spectrum one and that was like getting the game graphics delivered in the mail, can't imagine an msx one being all that playable :/

Well there's a big difference btw. native phone and JAVA applications:
JAVA is platform independent. Sounds great eh? But the downside: It's damn slow...

fMSX/S60 is a native S60 app, and some parts are even written in ARM assembler, to speed up things... that's why. Disadvantage: it's then not runnable on all phones - to be precise: not runnable on non-Series60 phones.

But if you've got a Series60 phone, it should work... right? Perhaps jr knows more 'bout it?

well, yeah... stuff running via kvm is going to be slower than native app, but as I can't install any .sis on my handset it's pretty moot

Afaik there are no Series 60 Sony Ericsson phones, those are UIQ, right?

My phone is a sony ericsson k700i, with your typical series 60 midp2 setup.

They've probably just locked .sis from working as the entire phone is set up in such a way that the variety of potentially useful features are only really usable in such a way as to generate revenue, but serves me right for just buying the cheapest phone I guess.


another*edit* this post doesn't make any sense does it
.sis no work
sony evil
I think I was saying..

and I think you may be right snout

)o_O): Go on, bob, conf00s us!
(^_^(: The pie!!

hmm, pie

Hmm, just checked some pages...
Sony Ericsson K700i is not a symbian-based phone!

Eeeevil Sony!

EEEEEVIL!
yes
so, anyway, anyone want to buy a phone?

boblet : try to find someone who does not like to play games on a phone

Neither Motorola nor Sony Ericsson seem to have any S60 compatible phones available at the moment.
The S60 website (www.s60.com) gives a quite good overview of all S60 compatible phones.

I hate playing games, on this phone

Eeevil, eevil, not all computers are MSX. Eeeeevil!

Ok, then something about fMSX S60...

I have been thinking about fitting MSX screen to this small and crappy screen... Fast fit is fast, but quite unusable solution... Smart fit is best for text. It makes even small texts readable! Resample fit is best for pictures, but otherways it makes the text unreadable...

So... I was wondering, could there be something between resample and smart fit to make a mode, that is quite a good for text and graphics... What if you do smart fit and resample fit and mix the result. Yes, I know this must be very slow, but it might look good... What do you think? I mean 75% of the smart pixel color and 25% of the other pixel color.

Well, being the lazy person that I am, I'll leave it up to you to evaluate whether it would look nice or not ;-) You can (easily?) experiment with your proposal on a PC or an MSX by using the same algorithms as the emulator. I'll write them here in unoptimized C code for the lowres 16bit mode. The real stuff in the emulator is in somewhat optimized ARM assembly language but I figure this is more useful for you so I'm reverse engineering my own code ;-) Just trying to explain why the code below looks ugly/slow/crap/etc. so you don't have to tell me that...

Some background info:
- iVideoRAM points to the real display frame buffer
- size 176 by 208 pixels, 2 bytes per pixel (16bit RGB-565)
- iScreenBitmap points to an offscreen MSX frame buffer
- size 272 by 228 pixels, 2 bytes per pixel (16bit RGB-565)
- so there is a 8x8 pixel border around the 256x212 MSX "lowres" display area
- effectively both routines are shrinking the x axis to 2/3 of the original while keeping y axis intact (skipping 4 lines in 212 line mode because we only have 208 pixels available)

Code to "smart" copy the MSX frame buffer to display frame buffer:

unsigned short *dst = iVideoRAM;
unsigned short *src = iScreenBitmap + 10 * 272 + 4; // skip excess border
for ( int y = 208; y--; src += 8 )
    {
    for ( int x = 0; x < 176; x += 2 )
        {
        *( dst++ ) = *( src++ );
        unsigned short c1 = *( src++ );
        unsigned short c2 = *( src++ );
        unsigned short c3 = *src;
        *( dst++ ) = ( c1 == c3 && c1 != c2 ) ? c2 : c1;
        }
    }

Code to "resample" copy the MSX frame buffer to display frame buffer:

unsigned short *dst = iVideoRAM;
unsigned short *src = iScreenBitmap + 10 * 272 + 3; // skip excess border
for ( int y = 208; y--; src += 8 )
    {
    for ( int x = 0; x < 176; x += 2 )
        {
        unsigned short c1 = *( src++ );
        unsigned short c2 = *( src++ );
        unsigned short c3 = *( src++ );
        unsigned r1 = c1 >> 11;
        unsigned g1 = ( c1 >> 5 ) & 0x003F;
        unsigned b1 = c1 & 0x001F;
        unsigned r2 = c2 >> 11;
        unsigned g2 = ( c2 >> 5 ) & 0x003F;
        unsigned b2 = c2 & 0x001F;
        unsigned r3 = c3 >> 11;
        unsigned g3 = ( c3 >> 5 ) & 0x003F;
        unsigned b3 = c3 & 0x001F;
        r2 += r3; g2 += g3; b2 += b3;
        r1 += r2; g1 += g2; b1 += b2;
        r1 /= 3;  g1 /= 3;  b1 /= 3;
        *( dst++ ) = ( unsigned short )( ( r1 << 11 ) | ( g1 << 5 ) | b1 );
        c3 = *src;
        r3 = c3 >> 11;
        g3 = ( c3 >> 5 ) & 0x003F;
        b3 = c3 & 0x001F;
        r2 += r3; g2 += g3; b2 += b3;
        r2 /= 3;  g2 /= 3;  b2 /= 3;
        *( dst++ ) = ( unsigned short )( ( r2 << 11 ) | ( g2 << 5 ) | b2 );
        }
    }

Eh... this is gonna need some time (from me) to evaluate. Maybe some day I should actually learn that damn C-language. It seems that everyone is using that. At the moment I believe, that the ARM assembler is more easy for me to read.