Search results

Well, I was expecting that if I use a framebuffer of 320x240 and a window of 640x480, it would render at 320x240 and get scaled up to 640x480 onscreen. But it only shows at 320x240 onscreen with black borders.

Just tried it with http://terrycavanaghgames.com/maverickbird/, which runs great except for some bad tearing problems (which I guess could be fixed if you manage to get double buffering working). The game's graphics seem to be 320x240 pixels, so I tried to see if I could run it in a 320x240...

Recently Nintendo changed it to L+R, which is much better because it's harder to do by accident. Edit: Wait a minute... I read "L or R" in your post for some reason.

A little late on this, but I'm pretty sure ARMv8 has twice as many general-purpose registers. Similar performance increases are possible.

Yes, and at the same time it's probably a good idea to rotate the dpad inputs accordingly (I know of several games that use the dpad while rotated).

Oh, due to how the emitters seem to work, I need to specially handle LSR 0 as LSL 0 (otherwise it gets emitted as LSR 32). I've edited the routine to take this into account.

Hmm, I think it would be a good idea for 16-bit signed multiplication to be implemented with the SMULBB instruction. Unfortunately, there's no unsigned equivalent, though. Edit: I wonder if it would be worth it to have a division routine with unrolled iterations (with some possibly skipped...

I think that's completely unnecessary, rd2 is the T flag and rs1/rs2 are general purpose registers. Or at least, I don't think any other commands that use the T flag check for that. Are the division ops actually supposed to return a remainder? I'd find that kind of odd, since the SuperH...

SBC needs to invert the carry before doing the subtraction. I think this should work: case shop_sbc: //printf("sbc: r%d r%d r%d r%d\n",reg.mapg(op->rd),reg.mapg(op->rs1),reg.mapg(op->rs2), reg.mapg(op->rs3)); { EOR(reg.mapg(op->rd2),reg.mapg(op->rs3),1)...

I feel like we should have a development thread, heh. I have a number of suggestions brewing for the dynarec and such. One thing that comes to mind is that your committed shop_sbc implementation doesn't seem like it'll work, because ARM uses carry for subtraction instead of borrow. I'll see if I...

That's odd. This is the definition of NEG(), after all: EAPI NEG(eReg Rd,eReg Rs) {         RSB(Rd,Rs,0); }

Alternatively, you could reuse the ADC method, since it's functionally equivalent to ADC with the same two arguments.

The quick reply box ate half my post, give it another read. Sorry.

Hmm, this code kind of bothers me:                 case shop_rocl:                         {                                 ADD(reg.mapg(op->rd),reg.mapg(op->rs2),reg.mapg(op->rs1),1,true); //(C,rd)= rs1<<1 + (|) rs2                                 MOVW(reg.mapg(op->rd2),0); //clear rd2 (for...

It looks like the problem with that routine is with this: Blame Graeme for being a lazy typist, but it looks like this routine only takes positive ("+ve") inputs. I'll give you the DIV0/DIV1 methods after I've worked on them some more, since I'd really like to see if I can whittle DIV1 down to...

Oh, well, wouldn't any old division function work, then? What bit size are the inputs and outputs, anyway? Also, do you care about the correct Q and M flag outputs? I edited my previous post while you were replying, but I think I came up with an 8-instruction DIV1 method, which could certainly...

You mean for the DIV0U/DIV0S/DIV1 instructions? I could perhaps try to come up with something. (I'm pretty interested in this sort of thing and I'd love to help out wherever I can.) Any hints as to how the M/Q/T flags are stored? Edit: From what I can tell from the little bit I've looked at the...

Hey, I don't know what method you used for shad and shld, but I came up with a nice method to emulate these in ARM once upon a time. For example, in the case of SHAD Rm,Rn: ANDS temp, Rm, #0x8000001F RSBMI temp, temp, #0x80000020 MOVPL Rn, Rn, LSL temp MOVMI Rn, Rn, ASR temp For SHLD, of...

Unfortunately, I can't German, and I'd also rather not install another OS if I don't have to. This is supposed to work on stock SuperZaxxon, right?

What is the current method to install/use WINE? I tried extracting http://bochs.info/~aegis/wineroot-alsa.tar.gz onto my ext-formatted SD card, then following the instructions in this post, but when I try to run WINE with any arguments it gives me this error message: wine: failed to...