Dreamcast

[WizardStan]

wait what? you are saying a software title quit working after an update? That does not give me a warm and fuzzy about angstrom.

1) It was never running on the Pandora
2) If it had, it would have been before the OS was finalized. A lot of changes were made to what libraries were included before it went final. That's why the original Playstation emulator, which seemed to run so well in videos, doesn't work.
If you find something that was originally written for the Android beta, I would not consider it at all a problem if it didn't work in 2.2 (or even 1.1).

 

[SNESFAN]

wait what? you are saying a software title quit working after an update? That does not give me a warm and fuzzy about angstrom.

1) It was never running on the Pandora
2) If it had, it would have been before the OS was finalized. A lot of changes were made to what libraries were included before it went final. That's why the original Playstation emulator, which seemed to run so well in videos, doesn't work.
If you find something that was originally written for the Android beta, I would not consider it at all a problem if it didn't work in 2.2 (or even 1.1).

ok, see that makes me feel a little bit better, i was like

"holy crap every program will need to be re-written for every firmware update, what if the developer is gone?!?!"

it's unfortunate that the stuff written for the beagle doesn't just translate over to the pandora seamlessly though =/


[android nonsense]
supposedly with the advent of api v5 from android version 2.0+ every app is automatically scalable to screen sizes of different resolutions and apps will no longer crap out when used with anything other than the "first gen" android specs. I hear that was one of the main problems with apps written with the 1.5/1.6 api versions. That's the main reason people were crying "fragmentation!" All versions of the OS it's self that I'm aware of use all the legacy api versions so newer versions with higher api levels truly just add in new/more functionality. If a app does not conform to it's hardware requirements or uses a newer version of API/OS it just won't be viewable for install. For example an app written for 2.1+ just won't be viewable for install on a device running 1.6 because it doesn't have the api level required to make the same calls. I occasionally run some of my original home replacement apps that haven't seen updates in over a year that I ran on my android 1.5 device. I don't know about android 1.1 or android beta or whatever so I won't make myself look like an idiot by assuming anything here.
[/android nonsense]

EDIT: made sure on the api version so I wasn't talking out my ass
http://developer.and...api-levels.html

EDIT2: ohh and it does say it supports backwards compatibility down to API v1 android 1.0.
Did not know that.

 

[Exophase]

As far as I can remember, MWeston got a build working on a Pandora. But that was many kernels ago.

It's not really a question of what he wants to release on - obviously that'd be Android over Pandora - but what he wants to develop on. And I'd much prefer to develop on Pandora with its physical buttons and more standard Linux setup.

 

[Pleng]

It's not really a question of what he wants to release on - obviously that'd be Android over Pandora - but what he wants to develop on. And I'd much prefer to develop on Pandora with its physical buttons and more standard Linux setup.

Um I don't really follow that logic. Anything I'd doing is totally driven by what I want to release on rather than what I want to develop on. I want to develop in Visual Studio using the .NET framework so I can make apps rapidly and relatively easily. Unfortunately I want to make apps for the Pandora where RAD solutions are pretty much zero (getting Novashell and Gambas up and running would drastically improve these things but when have the OPT, or in fact the Linux community in general, cared about making development easy or accessible?). So I'm stuck hacking things together out of pre-installed apps using BASH scripting and considering JAVA or web-based solutions. None of which are able to produce particularly good solutions.

So yea, I'd think most people are pretty much driven by what they want to develop FOR, rather than what they want to develop WITH/ON.

 

[WizardStan]

it's unfortunate that the stuff written for the beagle doesn't just translate over to the pandora seamlessly though =/

It's mostly library and driver things caused by tweaks in the kernel. I'd go so far as to say 99% of the stuff compiled for BeagleBoard will run on the Pandora (assuming the screen resolution is compatible), it's the extreme examples that do very specific things with the hardware, like, I dunno, timings or direct memory access that may have moved, or whatever.
Everything I've tested which used SDL or GTK, for example, has worked flawlessly between the two.

 

[Dead1nside]

On a completely general and obvious note, any work on nullDCe is more beneficial for the Pandora than none at all. After some brief reading, the source is meant to be open sourced soon so that doesn't stop anyone giving it a go on the Pandora. drk||raziel (sorry if the name's wrong) did say some months back that he'd be interested in working on the Pandora port again, when there were more available and he had his one, to paraphrase him.

 

[dgame]

Nulldc is already open source.

http://code.google.com/p/nulldc/


There are mixed opinions on the concept of a Linux (or cross-platform) port:

http://code.google.com/p/nulldc/issues/detail?id=23

I don't know who those people making those comments are or what their relationship with Nulldc is.
Some are for cross-platforming Nulldc and some are against.

I think this is one of those things that would benefit from more Pandora's being in the wild.

 

[Dead1nside]

Nulldc is already open source.

Yes, I know Nulldc is open source now, however from my reading nulldce isn't, at least not yet.

From my understanding Nulldce is meant for portability. Since we've already seen it running on a Beagleboard and now an Android phone, that seems to suggest Linux is a viable target.

 

[notaz]

As I said before, the build MWeston has can be hacked to work on current pandora OS without the source (and I could do it), however I don't know if MWeston has permission to distribute that build (and I don't have it).

 

[Pleng]

Who do we need to speak to to get said permission??

Never mind I found drk||Raziel's email address on his blog and asked him. Don't hold your hopes up guys, though, I know I wouldn't like other people to be playing my Dreamcast emulator on their Pandora, while I had to make do with crummy touch-screen based devices!

All we can do is wait and see.

 

[drkIIRaziel]

He had a board at some point as far as I can remember, but I can definitely see not wanting to develop for that. If he wanted a real Pandora at all he definitely should have gotten one. I'd really hate working with something like Dreamcast emulation w/o physical buttons. Could be why there's no controller emulation yet..

I figured it was ease of development because he was really fed up with working on the Beagle.

I'm proudly waiting my pandora, which i ordered the first day of the pre-orders all these years ago . The main reason there hasn't been work on the arm front is because I didn't want to get -yet- another cortex platform (hopping that the Pandora would arrive soon). Beagle deving sucks (and my beagle is old rev, with h/w bugs and not working with newer kernels )

Compare with the Beagleboard videos from over a year ago. Factor in 2x CPU frequency and L1/L2 cache (and god willing, better main memory latency). This is about what I'd expect.

I'm actually amazed Drk finds Android easier to work with than Pandora. Having to wrap your apps in Java is a pain. Or maybe that's not his reason for switching focus.

Yep -- its the exact same code I'm rewriting the dynarec right now (and also looking though some problems with snapdragon cpus -- they don't like LDR R2,[R2] :/ ). Due to changes on the rest of the dynarec though, idle loop 'detection' and some other nifty stuff have been implemented making some games much faster !

Android is fine. The best part of it is i can steal a friend's smartphone and hack with it -- or have a dedicated tester over IRC test my builds all the time. I can even spend 120 euros and get a decent omap based tablet (archos) and do some deving -- unlike with pandora ;|

nullDC actually supports both the pandora keyboard and keypad interfaces -- i added em for mweston's videos.

I have no idea what it is like to be a programmer, but if I was an open source programmer I would think making sure my software stayed free would be my first priority, priority two would be widest distribution as possible.

Android would allow that distribution. If you could make 1,000 people happy, potentially 8,000? Or potentially the upteen millions of people that use android, which would you choose? I know what I would choose, but agian, I'm not a programmer.

Well, i'm not really an open source programmer, and there's always the idea "hey, i could make lots of $$$ if i sold this for $1 ..." which bothers me abit right now .

Never mind I found drk||Raziel's email address on his blog and asked him. Don't hold your hopes up guys, though, I know I wouldn't like other people to be playing my Dreamcast emulator on their Pandora, while I had to make do with crummy touch-screen based devices!

All we can do is wait and see.

I've said this many times before, as soon as i get the hardware the port will folow . Keep in mind that any progress made on the android front will be shared with pandora, as the dynarec and renderer are shared across them. If you want to test builds drop by #nulldc on efnet and i'l get you hooked up .. assuming I can get the pandora toolchain to work again (yep, I work from windows) ~

Thats .. all ? I think ...
Have a nice day

 

[Farox]

Thanks...this is good news A dev is waiting for his Pandora to start to develop.

 

[Dead1nside]

Excellent news drkIIRaziel, I thought that was still the case. A message to Craig, if the dev fund is going to be used for anything at all, why doesn't this dev have a Pandora, just a thought?

As for the license, I'm an advocate of open source licensing, doesn't mean everyone is -- it's your hard work after all.

Thanks for the update and I do hope Craig has you penned down for a fast tracking.

 

[Trickyhero]

Hope you get your pandora soon. And good work

 

[TheAmericanNomad]

So what do you guys think, (particularly those with dev experience) will there ever be a Dreamcast emulator that runs at playable speeds for most games?

 

[ari64]

I'm actually amazed Drk finds Android easier to work with than Pandora. Having to wrap your apps in Java is a pain. Or maybe that's not his reason for switching focus.

It's not so much Java that's the problem, but that native code has to be loaded as a shared library. This memory layout makes allocating memory for the dynarec somewhat complicated. For a good laugh, read the thread on emutalk.net about this.

Yep -- its the exact same code I'm rewriting the dynarec right now (and also looking though some problems with snapdragon cpus -- they don't like LDR R2,[R2] :/ ). Due to changes on the rest of the dynarec though, idle loop 'detection' and some other nifty stuff have been implemented making some games much faster !

WTF? If that instruction doesn't work on the snapdragon, a lot of software is not going to work.

 

[drkIIRaziel]

I use this, and it works on all linux platforms so far

u8 pMemBuff[CODE_SIZE+4095];
u8 *CodeCache;
.....
//some overcomplicated code
CodeCache = (u8*)(((unat)pMemBuff+PAGE_MASK)& ~PAGE_MASK);
printf("\n\t CodeCache addr: %p | from: %p | addr here: %p\n", CodeCache, pMemBuff, recSh4_Init);
if (mprotect(CodeCache, CODE_SIZE, PROT_EXEC|PROT_READ|PROT_WRITE)) {
    perror("\n\tError,Couldn’t mprotect CodeCache!");
    verify(false);
}

memset(CodeCache,0xCD,CODE_SIZE);

The java code is like, 150 lines ... so its easy . Plus, its not really ugly anyway !

Actually, the LDR bug was a problem on the encoding -- I didn't set the P bit for indexing, which is required when the W bit is 0 ....

ARMv7 encoding is so much of a pain, it makes x86 look almost pretty .......

 

[Exophase]

Would you prefer that they wasted the encoding for another instruction so that you could set that bit to whatever you want? Unlike x86, which had several redundant encodings early on, ARM can't really afford to do things like that since they can't just keep adding prefix bytes (for as code dense as people say x86 is I shudder to think of the code size of stuff using a bunch of very recent instructions with 3-byte opcodes). At least with ARM you don't need to do a decent amount of predecode work just to find the length of the instruction..

 

[silver]

I'm proudly waiting my pandora, which i ordered the first day of the pre-orders all these years ago . The main reason there hasn't been work on the arm front is because I didn't want to get -yet- another cortex platform (hopping that the Pandora would arrive soon). Beagle deving sucks (and my beagle is old rev, with h/w bugs and not working with newer kernels )

(Really) Pleased you are still interested/waiting etc... hope you get your Pandora soon.

I have to say, it's (almost) more dissapointing than all the spectacular delays since I ordered on day 1 - we have 1000 odd units in the wild, and yet we will still have proven, interested devs waiting on a unit? Are there no more dev units? Would anyone really mind if devs were bumped up the queue?

I've apparently 750-850ish, and would happily go to 751-851 for the sake of providing devs (with a track record) some working hardware.

 

[DaveC]

I really wonder though if the Dreamcast could be emulated well enough on the Pandora to make it realy playable. To me it running 1/2 speed with no sound wouldn't be much more than a cool demo. If the N64 and even PSX still struggles on the Pandora maybe we shouldn't get our hopes up for Dreamcast being playable anyway.