Dosbox For Dingoo A320

[slaanesh]

re: above post.
But this begs the question: Why is this happening? Why is the cache.pos and the function location so far apart? *scratches head*

I would have thought that all of the A320's memory would have been in the same 256MB memory chunk.
What's going on here? :-/
Anyone?

More info:

The following four lines are output from my debug:

cache.pos=2b40c044
jal func        [gen_call_function_raw(421bf4)]
cache.pos=2b40c048
nop

cache.pos is the current memory location of where the dynamic compiler is generating MIPS code.
ie. at 2b40c044 it's generating a JAL FUNC followed by a delay slot NOP.

The address of func is passed in to this generating function. ie. gen_call_function_raw(421bf4)
Now the value passed in seems to be correct - ie. The function to be executed is "CPU_Intetrupt"

Here's the relevant bit of mipsel-linux-objdump -S of dosbox.dge:

00421bf4 <_Z13CPU_Interruptjjj>:
        cpu.exception.error=error;
        CPU_Interrupt(which,CPU_INT_EXCEPTION | ((which>=8) ? CPU_INT_HAS_ERROR
: 0),reg_eip);
}

Bit8u lastint;
void CPU_Interrupt(Bitu num,Bitu type,Bitu oldeip) {
  421bf4:       3c1c006a        lui     gp,0x6a
...
...

Here's the gdb output:

anthony:/j/dingoo/dosbox-0.73> /l/local/dosbox/mipsel-a320-linux-gnu-gdb.exe -c
core.146
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-build_pc-cygwin --target=mipsel-a320-lin
ux-gnu".
Core was generated by `./dosbox.dge'.
Program terminated with signal 11, Segmentation fault.
[New process 146]
[New process 151]
[New process 150]
[New process 149]
#0  0x20421bf4 in ?? ()
(gdb) info registers
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 10000400 000010c8 006a0000 00000021 00000001 000010c8 00000000
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   2ad401e8 00000000 00000001 804abe78 fffffffe 00000001 00000000 00000400
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  2b009008 000f20c6 00800000 0080200c 006a1938 006a18e0 0063c864 006a1820
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000008 00000bb7 00000000 00000000 2ad48420 7ff3a820 0080200c 2b40c04c
            sr       lo       hi      bad    cause       pc
      00000413 00000000 00000002 20421bf4 00800008 20421bf4
           fsr      fir
      00000000 00000000
(gdb) disassemble 0x20421bf4
No function contains specified address.
(gdb) x 0x2b40c044
0x2b40c044:     0x0c1086fd
(gdb) x 0x2b40c048
0x2b40c048:     0x00000000
(gdb)

Noice the PC is 20421bf4.

It's used the JAL instruction (0x0c1086fd) from 0x2b40c044 to jump here, I believe.
However the mystery is that JAL has a 28 bit index and takes the upper 4 bits from the address of the delay slot instruction, which is as 0x2b40c048.

Shouldn't it be jumping to 2b421bf4? This would be the correct spot.

Anyone know what's wrong here? Should I be using JALR instead?

 

[hlidegp2x]

I am not surprised. Since you are using Dingux, VMM is used and can probably span larger than 256 Mb. So you can potentially have larger addresses.

So yes you need JALR :

// generate a call to a parameterless function
   static void gen_call_function_raw(void * func)
   {
       temp1_valid = false; // ???
   
       if (((unsigned int)cache.pos ^ (unsigned int)func) & 0xf0000000)
       {
           cache_addd(MIPS_LUI |MIPS_RT(1)|MIPS_HIIMM16((Bit32u)func));     // lui $at, %hi(func)
           cache_addd(MIPS_ORI |MIPS_RT(1)|MIPS_LOIMM16((Bit32u)func));     // ori $at, %lo(func)
           cache_addd(MIPS_JALR|MIPS_RS(1)|MIPS_RD(31));                    // jalr $at       
       }
       else
       {
           cache_addd(MIPS_JAL |(((Bit32u)func>>2)&0x3ffffff));             // jal func
       }
       DELAY;
   }

One could be attempted to use $ra, instead of $at but I'm not sure it works as one doesn't know when $ra is updated with the return address BEFORE, WHILE or AFTER reading $ra : LA $ra, func; JALR $ra, $ra.

EDIT: VMM = Virtual memory manager.

 

[slaanesh]

I am not surprised. Since you are using Dingux, VMM is used and can probably span larger than 256 Mb. So you can potentially have larger addresses.

So yes you need JALR :

// generate a call to a parameterless function
   static void gen_call_function_raw(void * func)
   {
       temp1_valid = false; // ???
   
       if (((unsigned int)cache.pos ^ (unsigned int)func) & 0xf0000000)
       {
           cache_addd(MIPS_LUI |MIPS_RT(1)|MIPS_HIIMM16((Bit32u)func));     // lui $at, %hi(func)
           cache_addd(MIPS_ORI |MIPS_RT(1)|MIPS_LOIMM16((Bit32u)func));     // ori $at, %lo(func)
           cache_addd(MIPS_JALR|MIPS_RS(1)|MIPS_RD(31));                    // jalr $at       
       }
       else
       {
           cache_addd(MIPS_JAL |(((Bit32u)func>>2)&0x3ffffff));             // jal func
       }
       DELAY;
   }

One could be attempted to use $ra, instead of $at but I'm not sure it works as one doesn't know when $ra is updated with the return address BEFORE, WHILE or AFTER reading $ra : LA $ra, func; JALR $ra, $ra.

EDIT: VMM = Virtual memory manager.

Thank you for your suggestion. I had actually been working on implementing my own JALR which is unsurprisingly similar to your own implementation.
Well there is some good news - it's not causing a segmentation fault anymore.
The bad news is that the it's just sitting at the DOS prompt.
Only a single Dynamically Recompiled block is generated - then it just sits there.
Not sure what it's doing.

 

[hlidegp2x]

Thank you for your suggestion. I had actually been working on implementing my own JALR which is unsurprisingly similar to your own implementation.
Well there is some good news - it's not causing a segmentation fault anymore.
The bad news is that the it's just sitting at the DOS prompt.
Only a single Dynamically Recompiled block is generated - then it just sits there.
Not sure what it's doing.

Did you check it was safe to change $at (or whetever you used) in the implementation ?
If you use JALR $ra, $ra to jump into your function, its behavior is said undefined in the MIPS instructions set document : if $ra is updated BEFORE jumping to address pointed by $ra, it happens to skip the function and $ra is scratched, so it's very bad. Or it may raise an exception (apparently not the case).

What kind of function signature is it ? like void f(void) ?

 

[Exophase]

Re the memory offset issue: chances are it's the heap and the text/code sections that are far apart. If you change the translation cache buffers so that they reside in bss instead of in heap there's a better chance they'll be in the same 256MB segment. You can do that by using global arrays of fixed size instead of malloc'd memory.

 

[hlidegp2x]

Re the memory offset issue: chances are it's the heap and the text/code sections that are far apart. If you change the translation cache buffers so that they reside in bss instead of in heap there's a better chance they'll be in the same 256MB segment. You can do that by using global arrays of fixed size instead of malloc'd memory.

yes that's a better solution to start with and to keep JAL instruction.

 

[slaanesh]

Alright I'm going to try a global memory dynarec cache with JAL again.

Thanks for the advice!

 

[slaanesh]

DOSBox Dyna Rec for Dingux is.... WORKING! Yes! Big smile on my face. Thanks for the help Exophase and hlide! ))

 

[Pickle]

DOSBox Dyna Rec for Dingux is.... WORKING! Yes! Big smile on my face. Thanks for the help Exophase and hlide! ))

Congrats! You should send your changes back to the dosbox devs so they can be used again.

What kind of performance are you getting? i.e. what kind of things can you run?

 

[slaanesh]

I've tried two games so far: Alleycat and Gauntlet II.

Gauntlet II looks nice, sound is good. This is at 336Mhz. I think it will work very nicely at 420Mhz.

I'll try a few more games in the next few hours.

I've also got to hook up the controls properly.

It's looking good! I think it will be very nice on the Ben Nanonote with it's little keyboard.

I'll certainly submit changes to the DOSBOX guys as it's great software and I'm happy to help out.

 

[gruso]

Great work!

 

[Mortys]

Great news Slaasnesh
Can't wait to try it on Dingoo and on Nanonote (as soon as I succed to update it )

 

[siloucos]

Really great job! It is wonderful to see Dosbox on our little Dingoo! There are lots of games and little apps which I am really excited to try on it! Thanks slaanesh!

 

[NeoTheFox]

slaanesh, you are SOOOO cool) Waiting 4 relise ^_^

 

[slaanesh]

Still working on this. Getting the video modes sorted out.

I'd be very curious to try this out on a Nanonote.

If someone has one and wants a private pre-release version, please send me a PM or reply on this and I will send them a pre-release version of Dingux DOSBOX.

Hmmm, actually, does the Nanonote run Dingux or is that unnecessary? I'll make a static build for nanonote users.

 

[wave]

Still working on this. Getting the video modes sorted out.

I'd be very curious to try this out on a Nanonote.

If someone has one and wants a private pre-release version, please send me a PM or reply on this and I will send them a pre-release version of Dingux DOSBOX.

Hmmm, actually, does the Nanonote run Dingux or is that unnecessary? I'll make a static build for nanonote users.

Nanonote does not run dingux but it's a binary-compatible linux

 

[slaanesh]

I'm going to release a public test version in the next couple days.

 

[slaanesh]

I've managed to get a cheap Nanonote from eBay (in Australia too!) for $70.00.
Should be arriving soon so I can make sure that DOSBox is working well.

Also managed to squash an annoying bug which was causing seg. fault when hitting the SELECT key.
As you many (or may not) know, SDL on the A320 uses the SELECT key to emulate the ESCAPE key.
There was a particularly nasty bug in DOSBox for keycodes which have a value of less than "8" (ESC's value is "1").

Anyway that's fixed.

I'm just going to fix the screen centering for the video modes and I will release the public beta test version.

 

[Mortys]

Hi Slaanesh
A little of topic but Mame4All and FBA doesn't work on NN because of bad display bug. It seems that the problem come from 16 bits rendering on a 32 bits display... Maybe you can update the launcher for us, that would be great.
Cheers
Mortys

 

[zear_]

I've managed to get a cheap Nanonote from eBay (in Australia too!) for $70.00.

$70? But the official price (without shipping cost and custom fees) is $99. How did you manage to buy it that cheap?
Was it second-hand?