drb
New Member
Posts: 1
|
Post by drb on Jun 29, 2007 23:24:31 GMT 1
Thought y'all would like to know that dmitry is considering GBA & DS emulation. Here's the thread on 1src. Maybe some of the big-names over here (metaview, Tinnus, etc.) could convince him to write a module for LJP. ;D |
|
semi
Junior Member
Posts: 97
|
Post by semi on Jun 30, 2007 5:45:50 GMT 1
Sounds cool... GBA emulator, but then again, the last time I tried it with Firestorm it didn't work so well... rather slow even with my overclocked CPU on my NX80V.
|
|
|
|
Post by countbuggula on Jun 30, 2007 6:17:28 GMT 1
From what it looks like Dmitry has a very fast CPU emulator already made that would be a good framework for a GBA emulator to start with. I'd certainly be interested, but as my programming skillz are pretty much limited to BASIC and Excel macros (VB) we'll have to see what Tinnus and Metaview (and plenty of others who know more programming than me) say about it. And if they have the time. Dmitry mentioned there's probably over 100 hours (hundreds) of programing needed to get something like that running.
|
|
|
|
Post by Tinnus on Jul 1, 2007 0:51:38 GMT 1
That seems interesting. I already knew Dmitry had a very fast ARM emulator, but actually forgot about that... anyway, if he really tackles it, might as well instigate someone else to get a GBA emulator going  (DS is a very very far possibility BTW. He says that himself over there) |
|
|
|
Post by countbuggula on Jul 1, 2007 2:49:09 GMT 1
Well the DS includes an ARM7 and an ARM9 processor, right? Besides plenty of optimizations for 3D...yeah I don't see that being emulated on another mobile device for awhile. No hurry. Concentrate on what's possible on current hardware, and when the technology gets there we'll move on.
|
|
|
|
Post by _Em on Jul 3, 2007 19:30:15 GMT 1
DS/N64 aren't likely solely due to their memory requirements. Of course, if Dmitry gets his virtual memory hack working, then we're just up against CPU and bus speed.
|
|
|
|
Post by countbuggula on Jul 3, 2007 19:53:44 GMT 1
Do you remember the early days of N64 emulation and trying to emulate one on a 400mhz PC with no 3D acceleration card? I do. It was ugly. Maybe you guys can do crazy things with software that weren't possible then, but I'm not holding my breath.
...I would totally geek out on being able to play MarioKart64 on my Treo though ;D. Personally, I'd prefer a playable PSX emulator over N64 though.
|
|
|
|
Post by cristo56 on Jul 3, 2007 21:16:28 GMT 1
look mame about vilmos
roms metal slug was in 16 mega (but the game are in 2d)
a roms like N64 was in 4 à 8 Mega, A zodiac with ati rageon seems to emulate N64 (zodiac arm9 200 mhz 128 mgbt of memory and a 3d accelerator ati rageon)
A mon avis tout est programmable (it make a very very programmer like tinnus, yoyo, codejedi, vilmos or dmitrygr and other....) sauf pour la DS.
|
|
|
|
Post by Tinnus on Jul 5, 2007 3:33:59 GMT 1
The ATI chip in the Zodiac is 2D, not 3D. Sorry, but it's completely unpractical to run N64 on a Zodiac with just 200MHz.
The size of the games is not in any way a measure of the easiness to emulate the machine as well.
|
|
|
|
Post by neko68k on Jul 5, 2007 22:56:33 GMT 1
ds has an arm7 and an arm9. it has two 2d cores and a 3d core totally not feasable on a measly palm. Not much RAM itself, that's not so much of an issue.
The rule of thumb used to be that you need 4x the CPU of the emulated machine but it's also a bit different running an arm emulator on an arm cpu. More like a virtual machine then; probably passing the gba thumb code straight to the cpu after memory translation etc.
gba would probably be possible and run pretty well on higher clocked machines.
|
|
|
|
Post by Tinnus on Jul 6, 2007 0:20:38 GMT 1
The rule of thumb is 10x dmitry's emulator IS fast, though. |
|
|
|
Post by neko68k on Jul 6, 2007 1:51:15 GMT 1
could you emulate gp32? ;D
|
|
|
|
Post by Tinnus on Jul 6, 2007 3:16:33 GMT 1
Kidding? It's 166MHz.
|
|
|
|
Post by hansschmucker on Jul 6, 2007 14:17:15 GMT 1
Just out of curiousity... how fast could a ARM emulator be if it would handle only memory... handling everything else over to the real processor and handle all other hardware access through an API, say a patched linux kernel  |
|
|
|
Post by _Em on Jul 6, 2007 21:17:30 GMT 1
Thing is, the ARM emulator has to handle the hardware bus too... other than graphics and audio, handling interrupts on the hardware bus is the most intensive thing. So what do you mean by "only memory"? The fastest way I can see it working is this:
ARM on ARM: all CPU calls get passed right through. Calls to the graphics and audio coprocessors either get precompiled or JIT compiled with dynamic recompilation.
I suppose if the target and host systems are entirely fixed (example: emulating the GBA on a Palm TX), you could just write an abstraction layer that solely translated the calls from the target hardware to the host hardware. However, if you do this, it isn't really emulation anymore; you'd probably get better results in taking the binary ROM and performing a multipass transform on it until the contents ran natively as a PRC on the target Palm device.
|
|
|
|
Post by hansschmucker on Jul 6, 2007 21:49:07 GMT 1
I was simply thinking about Linux on Palm since the GP is Linux-based... so far people always tried to port Linux to the Palm hardware... which is problematic because you have to customize it for each and every device... also people can't switch between PalmOS and Linux just like that... but what if somebody used a very basic ARM emulator, or VM or whatever you want to call it, to load only the kernel and nothing more inside a host emulator on PalmOS. Without any keyboard, screen or whatever. Then you could add a secret trap to the emulator which Linux can use to communicate with the host. Then you add drivers to the Linux kernel that don't perform anything, but instead send the command to the host application that then performs the action natively... for example, instead of handling keyboard interrupts you use a terminal driver that communicates with the host application that gets it's data from PalmOS. This way Linux would run inside PalmOS, but maybe still fast enough to be usable... Just an idea, I have no idea if it's possible (I'm supposed to know about ASM, but I really slept through most of my classes).
|
|
|
|
Post by neko68k on Jul 7, 2007 17:05:21 GMT 1
Tinnus: yeh I was kidding hans: I was following the development(or lack thereof) of Linux for TE for a while. It sounded to me like performance was marginal at best. I'm not sure if this was an optimization issue or the fact that linux is these days as bloated as anything else is. Now what might be nice is a POSIX layer for PalmOS(i.e. cygwin, mSys, MINGW, etc...) I could at least hang with a VT and the massive variety of console apps, ncurses, midnight commander and all that. |
|
|
|
Post by hansschmucker on Jul 7, 2007 17:31:48 GMT 1
Another way to reach the same target However I think a POSIX layer on Palmos might need even more work... |
|
|
|
Post by _Em on Jul 7, 2007 23:55:24 GMT 1
Seems to me the best way to do this would be to enable access to the debug console ON the Palm (run console on the PDA it is debugging that is), and then just compile apps to run in the Palm console.
|
|
gekko
New Member
Posts: 2
|
Post by gekko on Jul 8, 2007 9:29:59 GMT 1
They have GBA emulation running on iPods at 50% speed, using iGPSP. Might want to look into that?
|
|
|
|
Post by Tinnus on Jul 9, 2007 1:29:31 GMT 1
Yeah, gpSP. That's ongoing.
The problem is that it only compiles with gcc and I (like most of us) only know how to use CodeWarrior to do PalmOS stuff.
If anyone knows gcc (PODS) in ARM mode for PalmOS... feel free to try.
|
|
|
|
Post by hansschmucker on Jul 9, 2007 2:50:06 GMT 1
|
|
|
|
Post by metaview on Jul 9, 2007 11:14:50 GMT 1
But most of the stuff doesn't compile right out of the box with CW :-) Or is it using ASM?
|
|
|
|
Post by hansschmucker on Jul 9, 2007 14:57:08 GMT 1
If you're talking about my article... it's using a really old GCC version... prc-tools to be precise.... the problem is that arm-palmos-gcc is a set of patches for a specific GCC version (I think 2.something) and cannot be easily ported to a newer GCC...
|
|
|
|
Post by tgwaste on Jul 9, 2007 18:27:58 GMT 1
Yeah, gpSP. That's ongoing. The problem is that it only compiles with gcc and I (like most of us) only know how to use CodeWarrior to do PalmOS stuff. If anyone knows gcc (PODS) in ARM mode for PalmOS... feel free to try. Where can I find the source for this? |
|
|
|
Post by hansschmucker on Jul 9, 2007 18:42:41 GMT 1
|
|
|
|
Post by Tinnus on Jul 9, 2007 20:00:55 GMT 1
It can be run with a dynarec in the PC and PSP, but there's also an interpreter in there (which is where we should start).
The matter with the code is that it has a LOT of syntax that doesn't work with the CW compiler and much of it cannot be converted easily.
|
|
|
|
Post by _Em on Jul 9, 2007 20:09:39 GMT 1
Well, I'd suggest that instead of getting it to work in CW, energy should be spent getting gcc 3.2+ working with PODS and prc-tools. CW is old, and isn't very relevant anymore. If we got the palm target working in gcc, then it becomes trivial to change targets between all modern OSes/hardware, making ports that much simpler.
|
|
|
|
Post by tgwaste on Jul 9, 2007 21:01:03 GMT 1
psp source uses prc-tools? im confused.. why would palm have anything to do with psp arch? p.s. all palm dev should be done using GCC.. makes it MUCH easier to port, modify, etc. |
|
|
|
Post by hansschmucker on Jul 9, 2007 22:18:46 GMT 1
PRC-Tools is GCC, or more exactly: a patched gcc 2.something + tools... and the psp source uses GCC, probably a 4.something version. So most likely it would be easier to port the code, which is aimed at GCC 4.x, to GCC 2.x based PRC-Tools than to Codewarrior
|
|
