Dosbox For Dingoo A320


Mortys said:
PS : I've launch the first test version you send me and get segmentation fault after seeing the : Initiling A320 Video
Dosbox 0.73... message
Is this on the Nanonote or the A320?

I've fixed a few issues since then anyway. For example pressing the SELECT key would always cause a seg fault. That's been fixed. The private test version i sent out to a few people probably won't work on the Nanonote. It will need a static build and some fixes for 32-bit video.

EDIT: Oh yeah flashed the new kernel/rootfs. Thanks Mortys for the OS X links. It went very smoothly after that.

So, now it boots into Gmenu2x. Blah! It's almost useless for the Nanonote. The controls are totally unintuitive. Give me my shell console any day. How do I go back to using my shell? I can't even seem to exit from Gmenu2x.
 
Last edited by a moderator:
You have to edit an app(like Dglock) and set the Wrapper option off to go back to console (you have to launch the app you edit and exit from it). So you'll be able to mount the µsd card by
mount /dev/mmcblk0p1 /card

PS: it was on NN (for Dosbox)

RePS : I hope to install Dosbox for my birthday (sunday the 18th) :p
 
Well I need a break-through for DOSBox for Nanonote.

Currently I'm having problems with it.

It's basically delaying my alpha release. I've put considerable effort into getting it running.

Getting stuck on some basic things here:

It's pausing on the very first call to following code, which basically opens up a screen.

Not sure what the issue is here.

sdl.surface=SDL_SetVideoMode(320,240,render.lcd_bpp,SDL_SWSURFACE);

Also, it seems that that Nanonote has considerably less user memory/RAM available. Is the IPU enabled?That would be gobbling up 4MB of RAM.

One thing of note, I'm using the Dingux toolchain/libraries - not the Ben Nanonote libs. I could change to Nanonote libraries.
 
HI Slaanesh
Take all the time you need for Dosbox NN. I hope you'll find the issue. Nobody will be more impatient than you, who try to make it work. Let us know how is it going and good luck.
Maybe the NN build can be made to support only 320*240 256 colors games so less memory will be needed. Sure the'll be less game supported, but it'll be more than nothing.
Have you tried DSx86, which is a 286 emulator for DS who run pretty well. It's not a Dosbox port but use some trick from it.
However, thx for your hard work.
PS : if you need some test just send me a build I'll be please to try some games. :p
Re ps :Maybe the solution could be to build a new system iamge with less stuff in it (like IPU) for DOsbox and the other "gaming" app to gain some more space. The idea is to transform the NN in a small "Dos PC" instead than a linux comptuer with "a lot of app"...
Cause Dos/Scummvm and PC ports are the more valuable on NN than other kind of app (I mean in gaming term).
 
@slaanesh
You might want to join #qi-hardware on freenode for more help.
Usually 320x240x32 and SDL_SWSURFACE works fine on the NN, no idea what's wrong. But the guys on this channel may know.
 
That didn't seem to be the problem after all. After the first crash, subsequent runs would cause this statement to lock up. Which is probably typical behaviour.
So after a fresh boot, it gets passed this easily.

UPDATE:

Alright it's executing but always throwing an exception. Not seg faulting.

Code:
terminate called after throwing an instance of 'char*'
How do I determine the cause of this? C++ is not my string point. I'm a C and assembler kind of guy.

Anyone know where the official Ben Nanonote toolchain and especially libraries are?
Currently this DOSBox build is a static build but it's using the Dingux libraries.
 
slaanesh said:
Anyone know where the official Ben Nanonote toolchain and especially libraries are?
Currently this DOSBox build is a static build but it's using the Dingux libraries.
They have a wiki ;)
http://en.qi-hardware.com/wiki/Building_Software_Image
 
Last edited by a moderator:
slaanesh said:
That didn't seem to be the problem after all. After the first crash, subsequent runs would cause this statement to lock up. Which is probably typical behaviour.
So after a fresh boot, it gets passed this easily.

UPDATE:

Alright it's executing but always throwing an exception. Not seg faulting.

Code:
terminate called after throwing an instance of 'char*'
How do I determine the cause of this? C++ is not my string point. I'm a C and assembler kind of guy.

Anyone know where the official Ben Nanonote toolchain and especially libraries are?
Currently this DOSBox build is a static build but it's using the Dingux libraries.

you're probably having that with a throw "<error message or code";

EDIT:
Code:
 int main(...)
 {
    try
    {
        <main body code here>
    }
    catch (char *s)
    {
        DebugOuput("Catch Exception '%s'", s);
    }
    return 0;
}

as you seem not to crash you app, there is probably another try/catch which prevents your app to crash, you must find it so you can tweak it to display a better message.
 
Last edited by a moderator:
Yes, it does look like this:

Code:
        try
        {
              ...   (main code removed)
              ...
        }
        catch (char * error) {
                printf("Exit to error: %s\n",error);          //(I added this. Nothing is displayed)
                GFX_ShowMsg("Exit to error: %s",error);
                fflush(NULL);
                if(sdl.wait_on_error) {
                        //TODO Maybe look for some way to show message in linux?
                }

        }
        catch (int){
                ;//nothing pressed killswitch
        }
        catch(...){
                //Force visible mouse to end user. Somehow this sometimes doesn't happen
                SDL_WM_GrabInput(SDL_GRAB_OFF);
                SDL_ShowCursor(SDL_ENABLE);
                throw;//dunno what happened. rethrow for sdl to catch
        }
 
slaanesh said:
Yes, it does look like this:

Code:
        try
         {
               ...   (main code removed)
               ...
         }
         catch (char * error) {
                 printf("Exit to error: %s\n",error);          //(I added this. Nothing is displayed)
                 GFX_ShowMsg("Exit to error: %s",error);
                 fflush(NULL);
                 if(sdl.wait_on_error) {
                         //TODO Maybe look for some way to show message in linux?
                 }
 
         }
         catch (int){
                 ;//nothing pressed killswitch
         }
         catch(...){
                 //Force visible mouse to end user. Somehow this sometimes doesn't happen
                 SDL_WM_GrabInput(SDL_GRAB_OFF);
                 SDL_ShowCursor(SDL_ENABLE);
                 throw;//dunno what happened. rethrow for sdl to catch
         }

find out all the lines where "throw" is used :

1) throw 0; ? --> may be catched by char * catch version
2) throw ""; ? --> not very kewl as string
3) throw <charptr>; ? is it null, does it conatin "" ?

etc.

you could try to make a macro like THROW which does something like :
#define THROW printf("THROW at %s:%d\n", __FILENAME__, __LINE__); throw

no sure about __FILENAME__ and __LINE__ though
 
Last edited by a moderator:
Happy Birthday Mortys!

Anyway, I've made a little progress on DosBox. I've sorted out some control issues for the A320 version.
It will require the use of the mapper.txt file to map the A320's controls to the desired DOS keys.


I've also made some progress on the Nanonote version. Even though I still can't run any DOS games on the Nanonote, I can get to the key mapper now and display it correctly - which is something. This basically is a gui that lets you create the desired mappings and save the mapper.txt file.

I've also written a scaling renderer for the Nanonote.

I'm also thinking of letting DOSBox run as 8-bit video internally and convert to 16/32 bit when blitting to the screen. This is what is done for MAME4ALL and it runs faster that way.

Sorry about the lack of alpha release. I was hoping to get the Nanonote version working but I haven't had any luck. It's bombing out somewhere in the CPU emulation code (i believe) - which is a bugger to debug.
 
Thx for the happy birthday and for the news Slaanesh.
I wasn't thinking that the NN version will be so a pain in the ass to make... So thanks, one more time, for all your efforts to give us Dosbox on NN and A320.

Just a suggestion : the mapper.txt file could be usefull on NN too as some key are not directly available on the keyboard.
 
slaanesh said:
Sorry about the lack of alpha release. I was hoping to get the Nanonote version working but I haven't had any luck. It's bombing out somewhere in the CPU emulation code (i believe) - which is a bugger to debug.

So is the Dingoo version working? Any chance of an Alpha release of that?
 
Last edited by a moderator:
Pleng said:
slaanesh said:
Sorry about the lack of alpha release. I was hoping to get the Nanonote version working but I haven't had any luck. It's bombing out somewhere in the CPU emulation code (i believe) - which is a bugger to debug.

So is the Dingoo version working? Any chance of an Alpha release of that?
Yes, the A320 version is working fine.
I've almost found the bug for the Nanonote. Turns out it's in another bit of the video code - not the CPU emulation. Which is a big relief. :)

Also, the A320 and Nanonote use the same executable, but have some auto-detecting code with different handling of video code for each platform.
 
Last edited by a moderator:
Thank you for sharing and giving, hope to play as soon as possible to the a320 version of dosbox
 
Hi Slaanesh
Glad to hear that it's not the Cpu that give you headache. You're a roxor and I hope you won't have any others problems. We all wait for the first release but take all the time you need.
Cheers
Mortys
 
Alright it's almost done. Things are now beginning to work on the Nanonote and on the way I've found improvements that will work for A320 as well.

There are two minor remaining problem sfor the Nanonote:

Keyboard mapping isn't quite right.
There's no RED in the RGB of the display. I'm only getting Greens and Blues. This is most likely a little oopsy on my behalf.
 
slaanesh said:
Alright it's almost done. Things are now beginning to work on the Nanonote and on the way I've found improvements that will work for A320 as well.

There are two minor remaining problem sfor the Nanonote:

Keyboard mapping isn't quite right.
There's no RED in the RGB of the display. I'm only getting Greens and Blues. This is most likely a little oopsy on my behalf.

For the keyboard try changeing the setting for scancodes in the dosbox.conf
 
Last edited by a moderator:
Back
Top