PicoDrive for Series 60 Released!

fdave wrote:Actually you guys can probably help, I get all confused about the

Carry flag on ARM

I want the carry flag to be set if say 0xa0000000 gets reached and addpl adds on

0x60000000 and it wraps to 0x00000000

And a similar thing for submi, only I get confused about the Carry flag - it's

opposite between 68K and ARM...

Without ARM knowledge, here goes again (so don't be pissed if I've misunderstood

you):

SUBS instruction is the same as SUB except that the former can
change the cc bit in CPSR.

After SUBS instruction, Z-bit is set or cleared depending on the result
of the subtraction.

So, with this knowledge of subs I proceed to conditional execution:
EQ is equal (Z set)
NE not equal (Z clear)
PL is for positive with N clear flag.
MI is for negative with N set.
CC is carry clear (unisgned or lower than), C set
CS is carry set (signed or greated than)
HI is greater than C set and z clear
LS is lower or same unsigned with C clear or Z set
GE is greater than or equal (N and V set) or (N and V clear)
LT is lower than (N set and V clear) or (N clear and V set)
GT is lower than (N and V SET or clear) and Z clear

So, with this information I suppose that:
in here:

fdave wrote:
ot(" cmp r2,#0x0a000000\n"😉;
ot(" addpl r1,r1,#0x06000000 ;@ Decimal adjust units\n"😉;

by modifying addpl to be greater than or equal thus GE instead of Pl, we would get the correct result. Same logic for the sub with LE instead of MI.

I think I didn't quite get there what you were aiming for, but I hope it helped anyway.

about piracy and your moral, fdave what do u think about porting a NEOGEO or arcade emulator like RAINE etc ?? or everything else u have in idea 😊

hope i'll have the pleasure to hear the music of SF2 "tada tada dadada !" lol and the "RYUUUUUU!, KEN!, ROUND ONE FIGHT !" soon 😉

thanx for ur complete reply which was actually great

aka Unregistered27

konttori wrote:You should disable the key sounds in your current sound profile in your phone. I think that's the easiest way to get rid of the "bips".

OK, thanks for the advice, I totally missed this option. Sorry for having polluted the thread with such a silly question.

Oh, about an eventual SNES emulator, do you think the processor is powerful enough to do such a thing (even without sound) ?? I thought SNES was far more complicated to emulate than genesis ....

konttori wrote:Without ARM knowledge, here goes again (so don't be pissed if I've misunderstood you):

Translation:
Without ARM knowledge I went for the wonders of google and found a nice university course on the arm assembler.

So:

konttori wrote:
SUBS instruction is the same as SUB except that the former can
change the cc bit in CPSR.

After SUBS instruction, Z-bit is set or cleared depending on the result
of the subtraction.

So, with this knowledge of subs I proceed to conditional execution:
EQ is equal (Z set)
NE not equal (Z clear)
PL is for positive with N clear flag.
MI is for negative with N set.
CC is carry clear (unisgned or lower than), C set
CS is carry set (signed or greated than)
HI is greater than C set and z clear
LS is lower or same unsigned with C clear or Z set
GE is greater than or equal (N and V set) or (N and V clear)
LT is lower than (N set and V clear) or (N clear and V set)
GT is lower than (N and V SET or clear) and Z clear

If I understood correctly, you want the cc bit to be set after the addpl. So, that would then need addspl if I've understood the language correctly. But do you actually mean addspl or addsGE ? As I've said a few times before, as I haven't quite figured out what you are actually after, I can't say what you should do. I just hope this helps.

what version of street fighter works on picodrive?

i tried sf2 champion edition but it closes the app just before a fight starts.

does any particular version work better than another?

Street Fighter 2 Turbo (U) [h1] works for me.

It seems that the list of working is not 100% correct.Street Fighter 2 Special Champion Edition (U) [h1] rom loads fine but it crashes just before you start the battle.

just got that there and it works grand, thanks.

golden axe 2 can be added to the list of working roms, and im not sure if streets of rage 2 is on the working list or the non working list, but it works perfectly for me.

fdave:

It seems that there are differencies between how the commands are spelled in different places. In any case some ARM documentation spells them so that: ADC is Add with Carry and SBC is Subtract with Carry in arm 920 assembler.

Like this:
http://www.arm.com/pdfs/DDI0151C_920T_TRM.pdf

and it is used as described earlier in here:
http://www.arm.com/pdfs/DDI0151C_920T_TRM.pdf

Go figure. Anyway, you probably have read a million times these over, so no need for me to re-point them to you. 😃

i was just wondering if any one has noticed that the pico drive cant play any rom either zipped or unzipped larger than 1mb... can anyone tell me why... i was just curious.... apart from that picodrive seriously rocks... i have it on my nokia 3660 and i can play so many great games.... even G-Loc, Captain America, Ghouls and Ghosts... (it jumps fine for me), shinobi and castlevania
😎 :icon14:

LightStar wrote:i was just wondering if any one has noticed that the pico drive cant play any rom either zipped or unzipped larger than 1mb... can anyone tell me why... i was just curious.... apart from that picodrive seriously rocks... i have it on my nokia 3660 and i can play so many great games.... even G-Loc, Captain America, Ghouls and Ghosts... (it jumps fine for me), shinobi and castlevania
😎 :icon14:

You should free as much RAM as possible on you phone. Close all apps and use the flight mode to close the phone app as well. Thus you have more ram and thus you can play games up to 2 MB on nokia 3660.

Just a question from a newbie : is it possible to change at-the-fly the text fonts in a standard one that would be easily readable ??

LightStar wrote:i was just wondering if any one has noticed that the pico drive cant play any rom either zipped or unzipped larger than 1mb... can anyone tell me why... i was just curious.... apart from that picodrive seriously rocks... i have it on my nokia 3660 and i can play so many great games.... even G-Loc, Captain America, Ghouls and Ghosts... (it jumps fine for me), shinobi and castlevania
😎 :icon14:

Because you haven't got more than 1mb of free ram

konttori wrote:Translation:
Without ARM knowledge I went for the wonders of google and found a nice university course on the arm assembler.

So:

If I understood correctly, you want the cc bit to be set after the addpl. So, that would then need addspl if I've understood the language correctly. But do you actually mean addspl or addsGE ? As I've said a few times before, as I haven't quite figured out what you are actually after, I can't say what you should do. I just hope this helps.

No, the ge on the end decides whether the opcode gets executed. It's the 's' which tells it to set flags.

I know that opcode is being executed correctly otherwise the games would count 80 90 A0 B0 etc... It's the flags which are being set which are wrong. Or so I believe anyway.

Anyway, don't worry I'll take a closer look at it sometime.

and how do i get it lol

LightStar wrote:and how do i get it lol

It's sound profile. Press the power button and select flight profile.

Hi I'm happy with this emu. Thanks Dave...
Just one question and please answer me... thanks.

About the sound is it possible that the sound can be in stereo with the n gage? using the phones? thanks a lot and continue with this good work 😉

skillz007 wrote:Hi I'm happy with this emu. Thanks Dave...
Just one question and please answer me... thanks.

About the sound is it possible that the sound can be in stereo with the n gage? using the phones? thanks a lot and continue with this good work 😉

Ngage only supports mono sound up to 16 kHz. So, sadly no. ngage supports stereo 44 kHz only when playing mp3s.

Heres a though: two player game by first only implementing it so that the other phone will only act as the pad. So that the screen will be drawn only to the other phone. Lets call the phones X and Y. X is master. X draws the screen. Emulator has in the menu an item, start BT session. X starts the session. Y selects from the emulator : Join BT session. Now, X will be the gamepad 1 and will be responsible for drawing the content while Y will be able to control his / her character on X:s screen. BT packets could be sent e.g. 30 times a second or 1 / frame (even if its virtual).

This could be a first test implementation of multiplayer game.

How does this sound?

Also, it could allow UIQ and S60 players to play together. Even further still, perhaps even one of them could be a pc. Two ngages, one pc. Full screen play with wireless connection. Almost like the real thing 😉

That is brilliant!Now,the easy part,someone ti implement it 😃

Unregistered30 wrote:aka Unregistered27

OK, thanks for the advice, I totally missed this option. Sorry for having polluted the thread with such a silly question.

Oh, about an eventual SNES emulator, do you think the processor is powerful enough to do such a thing (even without sound) ?? I thought SNES was far more complicated to emulate than genesis ....

I have made a research in the past about SNES emulation in s60 devices and I found out that it is imposible if you are going to write the emulator in pure C/C++.
Assembly is the only sollution.

The good news are that there are a few open source SNES emulators like Snes9x and ZSNES. The bad news are that there is only one emulator for ARM based Pocket PCs (http://paqpark.nuclearfallout.net/projects/pocketsnes.php) based on the Snes9x emulator and can only run on iPaq with strongARM.

The emulation of the 65816 cpu instuction set of the Snes is not hard to implement (which is by the way much slower than Genesis/Megadrive). The implementation problems are with emulating the far superior graphic system of SNES as well as the very good Sony SPC700 sound system.

Even if all the above can be implemented I am 100% sure that many enhancement chips used by some games like DSP1 (Super Mario Kart, Pilot Wings), SuperFX chip (Stunt Race FX, StarFox), SA-1 (Mario RPG) and SDD1(Street Fighter Alpha 2) are imposible to be implemented due to lack of an FPU in s60 devices as well as the lack of processing power...

MemphisX wrote:I have made a research in the past about SNES emulation in s60 devices and I found out that it is imposible if you are going to write the emulator in pure C/C++.
Assembly is the only sollution.

I disagree.

MemphisX wrote:
The good news are that there are a few open source SNES emulators like Snes9x and ZSNES. The bad news are that there is only one emulator for ARM based Pocket PCs (http://paqpark.nuclearfallout.net/projects/pocketsnes.php) based on the Snes9x emulator and can only run on iPaq with strongARM.
.

I don't think that's right, PocketSNES uses a C core.

MemphisX wrote:
The emulation of the 65816 cpu instuction set of the Snes is not hard to implement

Easy compared to what exactly?? I don't really agree.

MemphisX wrote:
(which is by the way much slower than Genesis/Megadrive). The implementation problems are with emulating the far superior graphic system of SNES as well as the very good Sony SPC700 sound system.

Even if all the above can be implemented I am 100% sure that many enhancement chips used by some games like DSP1 (Super Mario Kart, Pilot Wings), SuperFX chip (Stunt Race FX, StarFox), SA-1 (Mario RPG) and SDD1(Street Fighter Alpha 2) are imposible to be implemented due to lack of an FPU in s60 devices as well as the lack of processing power...

I disagree. With pretty much every point you have made....

konttori wrote:Heres a though: two player game by first only implementing it so that the other phone will only act as the pad. So that the screen will be drawn only to the other phone. Lets call the phones X and Y. X is master. X draws the screen. Emulator has in the menu an item, start BT session. X starts the session. Y selects from the emulator : Join BT session. Now, X will be the gamepad 1 and will be responsible for drawing the content while Y will be able to control his / her character on X:s screen. BT packets could be sent e.g. 30 times a second or 1 / frame (even if its virtual).

This could be a first test implementation of multiplayer game.

How does this sound?

Eh, if you've got a PC there, what's the point of having an emulator on a mobile phone?

Regarding Bluetooth netplay, (just to repeat in case it got lost in the thread) if anyone is adding this to a version of PicoDrive, please come to me for a protocol.

I would like to enable Pocket PC, Smartphone, Zodiac, N-Gage, UIQ and Symbian S60 to netplay to any other device, using the same Bluetooth protocol, hence we would need a commonly designed protocol and I think I should be one to design it.

So if you are adding netplay, ask me to come up with one.

Thx dave for a great free megadrive emulator.

I have a question, is posible add diagonals and 6 button to emulator? street fighter uses it.

Cu.

fdave wrote:Eh, if you've got a PC there, what's the point of having an emulator on a mobile phone?

Well, most of the people don't have pads for their pc:s. So, e.g. ngage might serve as one. Also, if the savegame could be transferrable between pc and mobile versions, then it make sense to sometimes play on pc screen. I don't see mobile and pc versions negating each other. PC is just another platform for the emulation. I guess the basic idea being to allow any platform to also serve as a pad for another platform.

This was mostly a thought about an easy bt implementation. I would guess that if one would make an implementation with synced emulation cores, it would be much harder (e.g. how the random values are synced, although there pabably is a very neat solution for that as well).

I agree that you should be the one to figure the BT protocol. Also, it would be great to be able to be able to interconnect the devices.

As I referred to a pc before, it could also be nice to be able to link e.g. 2 ngages and one pocket pc so that pocked pc would do the emulation and the 2 ngages would serve as pads. Ok, this is a bit far fetched and not for general use. I admit it. Just a thought though.

hey guys all this public discussion is really interesting, what about the version 0.23 fdave?
anyway u embed a filter for working games (like MAME does) ?
if u need any french translation for a futher version including a language selector dont hesitate im your man
c u

fdave wrote:I disagree.

I don't think that's right, PocketSNES uses a C core.

Easy compared to what exactly?? I don't really agree.

I disagree. With pretty much every point you have made....

Anyway being more specific I said it is imposible to develop an SNES emulator in pure C++. You'll have to also use a litlle Assembly (but not exclusively).

The PocketSNES emulator on the other side is based on the Snes9x emulator. The Snes9x emu is coded in C++, with three assembler CPU emulation cores. By the way I was kinda dissapointed by the emulation of PocketSNES (not very accurate) but the good thing is that there is also a version for the GameBoy Advance showing how good the emulator is in terms of speed (http://www.gameboy-advance.net/emulated/snes_roms_on_gba.htm)...

I assume that the emulation of the SNES CPU is not so hard seeing now how picodrive works and also having in mind that the SNES had many similarities with the NES (It could even play NES games but for some strange reasons the Nintendo technicians disabled this feature maybe due to incompatibilities).

And I still believe that many of the extra chips if not imposible it'll be too hard to be emulated. For example the DSP1 chip is used to generate more enhanced Mode 7 rotation and scaling effects using floating-point processing. Most of the emulators use an FPU to emulate it. The SDD1 (mainly used for memory compression) is hardly implemented even on PC emulators while the SuperFX chip (a math co-processor for the SNES cpu) needs a very fast cpu to be emulated...

But lastly I wish I am wrong and someone be able to develop an SNES emulator for Symbian phones...

ZordaK wrote:I have a question, is posible add diagonals and 6 button to emulator? street fighter uses it.

Like it's been mentioned before, only the N-Gage/QD supports diagonal controls. It's a hardware thing. The n-gage has an 8-way navigational pad, while the other s60 phones only has 4-way. So you see, you can't implement support for diagonals in the emulator (software) when the hardware doesn't support it. 6 button support would be nice though. Diagonal moves does work with this emu btw., but again, you need an N-Gage/QD to utilise it.

MemphisX wrote:I wish that as you say all the above are false.

Anyway being more specific I said it is imposible to develop an SNES emulator in pure C++. You'll have to also use a litlle Assembly (but not exclusively).

And I am saying I think you are wrong. It is possible to create a SNES emulator in C++. Why the hell wouldn't it be?

PocketSNES is a SNES emulator in C++.

MemphisX wrote:
The PocketSNES emulator on the other side is based on the Snes9x emulator. The Snes9x emu is coded in C++, with three assembler CPU emulation cores. By the way I was kinda dissapointed by the emulation of PocketSNES (not very accurate) but the good thing is that there is also a version for the GameBoy Advance showing how good the emulator is in terms of speed (http://www.gameboy-advance.net/emulated/snes_roms_on_gba.htm)...

No there isn't, PocketSNES was renamed shortly afterwards to avoid confusion (looks like it didn't work). Snes9X could never in a million years be run on GBA.

MemphisX wrote:
I assume that the emulation of the SNES CPU is not so hard seeing now how picodrive works and also having in mind that the SNES had many similarities with the NES

Oh do tell, what is the logic behind this comment. No doubt PicoDrive was very 'easy' to produce huh?

MemphisX wrote:
And I still believe that many of the extra chips if not imposible it'll be too hard to be emulated. For example the DSP1 chip is used to generate more enhanced Mode 7 rotation and scaling effects using floating-point processing. Most of the emulators use an FPU to emulate it.

Well you do have a point there I guess, but you could maybe use fixed point.

MemphisX wrote:
But lastly I wish I am wrong and someone be able to develop an SNES emulator for Symbian phones...