
Two9A
Premium Members-
Posts
181 -
Joined
-
Last visited
Everything posted by Two9A
-
nmake is the ideal, but it MIGHT work with gmake. Just a matter of having a Windows port of it, and having Microsoft's compiler. (And, of course, you need to set up your include and library paths at the top of the Makefile.)
-
Report Bugs Thread. Read first post before posting
Two9A replied to MeGaBiTe1's topic in DS Emulators [/pc/ds]
Oh, sure you could open them. They just don't give any graphical output; this is by design. * testadd: This is just a test ROM for the ADD instruction, and should be stepped through in debug mode. * testmul: A test of MUL, to be stepped through also. * testdiv: A test of a divide algorithm, which happens to test the overflow flag; should be stepped through. * bioshack.bin: My small hack of the GBA BIOS; probably shouldn't be loaded in as a game ROM. Thanks for trying them though! -
Lad, I've never touched a GBA or programmed for one in my life. There's no way on Earth I could code walk3d, leonard or anything like that. Walk3d was created by Torlus, leonard by Leonard/OxyGENE. The only graphical demo I've fully written myself is fill1.bin; that's the extent of my graphic skills.
-
In some cases, mode7 might work already It's just a hblank effect, after all. In bitmap cases, I don't have rotscale yet, so not much chance of it working there. Thanking you, sir. It does help when I get encouragment of this kind, and I'm sure it helps Fed and the boys too Optimised? You're havin' a laugh, ain'tcha? I still haven't got round to grabbing all these zips by the way; I should sometime soon.
-
Report Bugs Thread. Read first post before posting
Two9A replied to MeGaBiTe1's topic in DS Emulators [/pc/ds]
I'm sure I've said this before But they're all coprocessor operations. (I think.) I'll get around to them, don't worry! And the repeating of xxxxxxx0 will be a part of the code, not a logging issue. -
Indeed, well done Looks like my screenshot page may be growing in the next few days.
-
Report Bugs Thread. Read first post before posting
Two9A replied to MeGaBiTe1's topic in DS Emulators [/pc/ds]
You're running DS roms, aren't you? Those are coprocessor operations; I was thinking about putting in the system copro at some point soon, but before then these ops won't work. -
I'm impressed, Federelli. Maybe I haven't been working too much on the emulator as of recently, but this is good news. Could you possibly put up all the ROMs you've tested somewhere? I'd like to run them here, see what happens.
-
Report Bugs Thread. Read first post before posting
Two9A replied to MeGaBiTe1's topic in DS Emulators [/pc/ds]
Gawd, y'all've been busy recently. Federelli: Thanks for the help; it's great to see some ROMs that actually run. I know stsound looks crappy, that's probably a multiple-background issue. RSdemo and nrx are probably having the same issue; and as you've guessed, RValentine is missing the background and the little sprite. Fun to see that SM64DS does something; and I'm pretty sure that DF has dumped it (or at least, portions of it). Raverin: Strange that you can't get any output. I am considering autorun, but I wouldn't be able to do any debugging if the ROM just fired up upon load. MeGaBiTe1: Hm. I compiled with the VC7 commandline tools, so I dunno how well it'll do in an IDE setting. Thanks for the feedback, everyone; it's much appreciated. -
Oh sure, you can have a changelog. It won't reflect changes to the emu in any way though; I'll probably copy the changelog from the Linux kernel or something
-
Ok, that was a flat lie, I'm afraid. Version changes happen at random, as evidenced by today's move to D; there's no particular reason for it.
-
I don't really want any unnecessary work piled on someone else; seeing as I update some small insignificant thing almost every day, it'd probably be best either to provide patches, or for myself to merge your code in. Right now, I get the feeling that patches would eventually lose sync with the work on the emu, so pass your code this way, and I'll see what I can do towards stuffing it into the code tree. And it's awfully kind of ya, I must say; thanks.
-
I tend only to change a version number when something big's happened. I don't think ARM9 support is huge enough; maybe a finished GPU will be enough to move to.01d.
-
Report Bugs Thread. Read first post before posting
Two9A replied to MeGaBiTe1's topic in DS Emulators [/pc/ds]
Looks great. I thought it'd do more for the HUGE size of ROM, but heck. Anything 3d (even if it runs dog slow) is good. -
Report Bugs Thread. Read first post before posting
Two9A replied to MeGaBiTe1's topic in DS Emulators [/pc/ds]
If you don't mind me asking, what the hell is that file? I've never seen it before! It was indeed a buffer overflow (affecting the full file and pathname); fixed yesterday. And robbbert: You know I can't do anything with a Watson log, or any other log, to be fair To all: I'll probably be putting in more test ROMs that (should) run fine, soon. Maybe some that crash it hard as well, just for variety. -
Ahaha, I wouldn't bother with any games, mate. Not gonna work at this time. Well, I was wrong. It was a buffer overflow, all my fault. Someone give the new archive a go, it should work now (extended the path name to 8192 characters, will that do?)
-
Ok, great. I can check out how Windows handles these filenames now; definitely sounds like issues with OpenFileName(). I had a feeling it wasn't my fault...
-
I'll tell y'all the truth. I haven't the faintest clue why this happens on some boxen. Maybe if it happened here, I could whip out the brain and think about it; but I just can't understand the problems remotely.
-
0001 - Metroid Prime Hunters First Hunt (U)(DF)
Two9A replied to NeoMaster's topic in DS Emulators [/pc/ds]
And in reply to (someone) who said "Will this run on DSemu?", I'll say "feck no". Absolutely nothing runs in DSemu right now, although I'm starting work on the DS bits of the CPU. -
As GryphonKlaw and Agozer have stated previously, you need to be able to think on the level of the processor. That is, in assembly and opcodes. Any high-level language will do for implementation, but I liek C. Also, a good technical reference for the system in question is useful. I tend to use GBAtek for the system and ARM.com for the CPU itself. It's awfully kind of you to want to donate so badly. I don't NEED the money, mind; being on the dole does help. If you can hold on until you are able to get PayPal, that'd be fun. Manchester, of course. Centre of the cultural universe.
-
Zid. What the crap're you doing here. Actually, I'm GDI too. Thinking about switching to DX before I hit sound though, since it'd be a right pain without DSound. Not a bad idea; I think someone here's porting to SDL already, so that should be fun,
-
Khaki: You've definitely got a better debugger than me; all I get is "it broke somewhere". And what'd you mean by "..efficient"? To be fair, I'm considering making/getting a new core; this is buggy to all hell, and barely works.
-
Thanks for posting something I see hundreds of times a day. But I haven't a clue why it crashes now; could you post the log.txt file? That /might/ help.
-
Yeah, there's been a problem with missing files for a while. I put in log.rc today, so that should be the last of it. log.txt should be non-existent; it's created as output by the emulator.
-
Well. They're all warnings, and most of them are to do with casting for Windows functions, so don't worry. The only changes I've made recently are to remove one line from win.c and hack the Makefile. Not much. Yay, parteh. Christmas should be a good working period, I think.