Yep, the E2xxx series are actually Core 2 Duo based with reduced cache. They are also quite the overclockers....Odd, all the info I can find on it says it lacks SSSE3 and VMX. Sites talking about it must be confusing it with a Pentium 4 if it really is a Core 2.
bsnes v0.034 released
The E8400 is based off of the Penryn core, making it burn less power and clock much higher.byuu wrote:ToP translation fix, which won't break FEoEZ (which has a header in the HiROM region, despite being > 32mbits.)
Code: Select all
if(cart.rom_size >= 0x401000) { if(rom[0x7fc0 + MAPPER] == 0x32) score_lo++; //star ocean else if(rom[0x40ffc0 + RESH] >= 0x80) score_ex += 16; //tales, dkjm2 else; //feoez }
It's labeled as one, but it's really a Core 2 Duo series with some defective cache that was disabled. But the cache doesn't help bsnes out that much. My E2160 @ 1.8GHz gets 60-90fps, and it can easily overclock to ~2.4GHz, so it should be more than enough.Isn't that a Pentium 4 family CPU?
The reason to like them is price: I paid $49 for mine, though it seems to fetch ~$59 on average. Still, much cheaper than the E8400 @ $159.
>.>
That said, as an E2160 owner who's overclocked it to 2.4 ghz, I love it.
New WIP.
First, the internal ROM header detected was enhanced. Nach was right, so I went ahead and did it the right way ... it'll score all three regions individually now, and then use some heuristics for those annoying games that duplicate the header entirely in multiple places. The hardest games to detect, that I recall, are Double Dragon and Street Fighter Alpha 2, which seem okay. In fact, all ~50 of the games I have seem to be working fine.
Please let me know if any games fail to start as of this WIP.
Second, finished updating all of src/memory to convert uint -> unsigned. Yeah, I like the former more, but the latter is a built-in type. Did the same to hiro, and converted Event to event_t, looks nicer in code. Part of namespace libhiro, so no worries about other things named event_t.
Third, added the frameskip cycling code. It just randomly chooses which of the set of frames to display (random() % (frameskip + 1)). Seems to work as expected, you can see Link blink when hit even with FS=1, but obviously it stutters a bit more.
Fourth, I finally added RedDwarf and Nach's latest ALSA code. ALSA will now with at 75% speed and with speed uncapped. It has the same overhead as OpenAL. So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason, I'm going to have to recommend Linux users set system.audio to "alsa" from now on :/
FreeBSD users should rely on "libao".
I'd like to release an update this weekend to address the ToP issue, as well as a missing string in the translate[] hooks and to distribute the new ALSA updates. I'm worried about the header detection changes breaking some other games, though. So if you guys wouldn't mind throwing a bunch of random games at it, I'd appreciate it.
It should be fine, though. In theory, the LoROM / HiROM detection is identical to the last release still, but I did restructure it, so you never know ...
Oh, and I updated the website with new locales from Hatsuyuki, Itol, khiav and wushu. Thanks, guys!
First, the internal ROM header detected was enhanced. Nach was right, so I went ahead and did it the right way ... it'll score all three regions individually now, and then use some heuristics for those annoying games that duplicate the header entirely in multiple places. The hardest games to detect, that I recall, are Double Dragon and Street Fighter Alpha 2, which seem okay. In fact, all ~50 of the games I have seem to be working fine.
Please let me know if any games fail to start as of this WIP.
Second, finished updating all of src/memory to convert uint -> unsigned. Yeah, I like the former more, but the latter is a built-in type. Did the same to hiro, and converted Event to event_t, looks nicer in code. Part of namespace libhiro, so no worries about other things named event_t.
Third, added the frameskip cycling code. It just randomly chooses which of the set of frames to display (random() % (frameskip + 1)). Seems to work as expected, you can see Link blink when hit even with FS=1, but obviously it stutters a bit more.
Fourth, I finally added RedDwarf and Nach's latest ALSA code. ALSA will now with at 75% speed and with speed uncapped. It has the same overhead as OpenAL. So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason, I'm going to have to recommend Linux users set system.audio to "alsa" from now on :/
FreeBSD users should rely on "libao".
I'd like to release an update this weekend to address the ToP issue, as well as a missing string in the translate[] hooks and to distribute the new ALSA updates. I'm worried about the header detection changes breaking some other games, though. So if you guys wouldn't mind throwing a bunch of random games at it, I'd appreciate it.
It should be fine, though. In theory, the LoROM / HiROM detection is identical to the last release still, but I did restructure it, so you never know ...
Oh, and I updated the website with new locales from Hatsuyuki, Itol, khiav and wushu. Thanks, guys!
I actually have 2 systems that are able to run bsnes at more than 1fps.Verdauga Greeneyes wrote:What's your current system like? (I'm also trying to remember where you live; I seem to recall you have a PAL SNES but that's as far as I gottetsuo55 wrote:I would LOVE to take you up on that offer, but i would need a completely new system to replace my current crappy one)
Gaming/work mostly done on this laptop:
Celeron M 2.5ghz
1GB ram
40gb 4200rpm hdd
intel 9xx onboard videocard.
The pc is actually a HTPC and is almost always in use
AthlonXP 2600
1256MB ram
Several 7200rpm hdd's (for a total of 1TB)
Ati HD2400pro (How else would it be able to HTPC)
Sony 40" fullHD tv (emulator tearing almost makes you go blind on such a large screen)
As you can see neither of these are able to get 60fps with Bsnes nor are they upgradable in any way(every part will have to be replaced except for the tv and the pc hdd's)
it's pretty painfull to see the Atom CPU getting better fps with h264 720p decoding than my HTCP(when hardware acceleration is disabled)
Actually the behaviour is very unstable, Byuu already proved that ther problem extends way back but i hardly noticed any problems. I don't understand why though. Regarding the FF series i'm actually used to the problems in those games because they hardly work on a real copier too, especially FF6/3 has loads of problems(has to do with real bugs and bad dumps i guess)Deathlike2 wrote:It sounds to me you've never seen frameskip look awful. In the FF SNES series of games, the cursor tends to flash when highlighting multiple targets with spells.. and when frameskip is used, you will occasionally see "fixed" cursor that either it totally missing or totally solid, which completely doesn't match what the original game does. Personally speaking, that is what you will be living with when frameskip is in use. That's more of a non-issue IMO than anything else.tetsuo55 wrote:So the problem with ZAMN is not an emulation bug but a problem with the frameskip option?
I knew it had something to do with the frameskipping. Now that i think of it i had seen it before way back but thought nothing of it. The last few weeks i have been playing ZAMN constantly and the bouncing always showed, it wasn't until i tried 34.wip1 that the bouncing stopped(and then it still works half of the time as long you don't reset)FitzRoy wrote:By the way, I tried Zombies and it should be rather obvious why frameskipping makes it look "broken" tetsuo. The way it bounces up and down is equivalent to something blinking. If you're shifting an object from up to down, and all of the up frames are being cut out, it will appear as though it is stationary. Just like if a game is showing a sprite every other frame to achieve a blinking effect, and every other frame gets cut out by frameskip 1, it will either appear invisible or solid depending on the frame the effect was initiated.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
I'm not so sure random is the best way to go about things here. If random() happens to return a multiple of (frameskip + 1), that'll be 0, which depending on your code might not display anything. If you're checking every couple of frames with random, it could happen to return a bad sequence which makes things not show for a while. I'm not entirely sure what requirements the standards committee has on rand(), but probably just that it has to have valid PSR cycle math, and hits every value from 0 to RAND_MAX. Which depending on the algorithm in play may not be anything close to what you want. It could also do the reverse and be displaying too many frames.byuu wrote: Third, added the frameskip cycling code. It just randomly chooses which of the set of frames to display (random() % (frameskip + 1)). Seems to work as expected, you can see Link blink when hit even with FS=1, but obviously it stutters a bit more.
Overall, any rand() implementation over a thousand runs or so should give practically 50% of each bit in that run being on, giving equal share to each number in your range. But you could end up where the distribution isn't good for say only 50 runs making your game display too much or too little for a couple of seconds. I'd hate to be fighting a tough boss, and then not see anything for 3 seconds.
You might be better off if you came up with a sequence that can be cycled for when to display frames. If you need some rand involved, you might be better off using a rand when a sequence is completed to choose between multiple sequences.
Although I'd probably be better off looking at your code as a whole before saying anything, since you probably prevented all this by using random in a more intelligent matter than I'm extrapolating from the small snippet posted, and I'm just displaying my worries over a moot point.
Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.byuu wrote: So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason
What about OSS and AO, do either of them break echo/reverb?
If the code is good from a logical standpoint for handling the issues in a clean and sane manner, you only have to worry about the really messed up dumps.byuu wrote: It should be fine, though. In theory, the LoROM / HiROM detection is identical to the last release still, but I did restructure it, so you never know ...
While IIRC Super Double Dragon, and Super Street Fighter 2 E had multiples, they weren't crazy.
IIRC, Ys III J has 31 different headers in the ROM, and the Batman Revenge of the Joker Beta has one header which looks perfectly good but it's fake, and you have another which is the right one, but looks bad. That's what I'd look at.
Also, there is a hacked BRotJ Beta floating around where they swapped the bad header with the good one, so everything handles it right, testing that one doesn't tell you anything. So double check with NSRT that the one you have is listed, and not a hack.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
it's one of the SPC7110 games. I think Super Power League 4. It was listed in one of the recent topics, but I can't remember which one. Might even be this one on the first page.Nach wrote:Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.byuu wrote: So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason
What about OSS and AO, do either of them break echo/reverb?
Well, hold off on the testing, I guess. Seems ToP scores equally for HiROM and ExHiROM, so I'll have to change the scoring from LoROM >= HiROM >= ExHiROM to ExHiROM >= LoROM >= HiROM.
EDIT: Ys 3 (J) was easy, Batman: RotJ is insane.
Try and guess the valid header.
Of course, it does have the usual distribution problems of rand(), you could have really bad luck with FS=1 and see nothing but frame 0 (of 0, 1) every single time. A lot like flipping a coin, obviously.
A ping-pong method probably would've worked as well, but eh. Didn't want to spend a lot of time on it, and I like the random distribution anyway.
EDIT: Ys 3 (J) was easy, Batman: RotJ is insane.
Code: Select all
00007FC0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00007FD0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00007FE0 0000 0000 9D92 9D92 9D92 7C92 9D92 9E92 ..........|.....
00007FF0 0001 AACC 9D92 9D92 9D92 0080 0080 9E92 ................
...
0000FFC0 4241 544D 414E 2D2D 5245 5645 4E47 4520 BATMAN--REVENGE
0000FFD0 4A4F 4B45 5231 000A 0001 BB00 4302 BCFD JOKER1......C...
0000FFE0 4C70 E8AD 2A03 2900 8009 0100 2254 C381 Lp..*.)....."T..
0000FFF0 AD2A 03F0 0AAD 0003 2900 02D0 1180 08AD .*......).......
Yes, what I do is have two counters: one that loops through frames+1 that increments linearly, and and another that is set to rand() % (frames+1) once the first counter wraps to zero. The PPU is enabled only when the first counter matches the second's random value. blargg tested it, it works as expected.you probably prevented all this by using random in a more intelligent matter than I'm extrapolating from the small snippet posted
Of course, it does have the usual distribution problems of rand(), you could have really bad luck with FS=1 and see nothing but frame 0 (of 0, 1) every single time. A lot like flipping a coin, obviously.
A ping-pong method probably would've worked as well, but eh. Didn't want to spend a lot of time on it, and I like the random distribution anyway.
Listen to the female announcer when you start "Pennant" mode in SPL4. She should should like she's speaking through a megaphone, and not two feet away from you.Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.
I'll let you know shortly.What about OSS and AO, do either of them break echo/reverb?
Wow, some strange stuff out there ... if you have an exact list of games, I'll test all of them to be safe.So double check with NSRT that the one you have is listed, and not a hack.
You say that after I test like 14 games, making sure each game can get to gameplay and actually work.byuu wrote:You'll want to hold off at any rate. Making some drastic changes to get Batman: RotJ working.
I'll post a new WIP later on with ZIP support for testing. Many thanks in advance.
>.>

BTW, I noticed something odd. with the frame limiter off, the Japanese version of Actraiser runs 10-20 FPS faster than the other versions. o_O
Edit: BTW, don't worry about zip support for my sake. I forgot winrar can mass decompress.
Very, very stupid of me.
I'm going to update my locale file ASAP. By the way, excellent release
.
-----
Edit
Updated: Brazilian Portuguese.

-----
Edit
Updated: Brazilian Portuguese.
Last edited by Hunter on Wed Aug 13, 2008 8:33 am, edited 1 time in total.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
I found the former very easy too. I didn't even know there was an issue with it, till MK mentioned it was giving him some trouble in Snes9x. No idea why though, although the 31 headers in it is quite unique. Might be because he was trying to do interleave detection alongside it. Which I can tell you from lots of experience can be very tricky to detect properly, although Ys 3 J never gave me a problem when I was writing NSRT. Glad you can appreciate BRotJ, that drove EVERYONE nuts, it's the one wrench in all sane code.byuu wrote: EDIT: Ys 3 (J) was easy, Batman: RotJ is insane.
Okay thanks. I'm busy till tomorrow evening, I'll see what I can do then.byuu wrote:Listen to the female announcer when you start "Pennant" mode in SPL4. She should should like she's speaking through a megaphone, and not two feet away from you.Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.
Please do, I prefer to be forewarned about what I'm getting myself into.byuu wrote:I'll let you know shortly.What about OSS and AO, do either of them break echo/reverb?
I don't have a list of insanity on hand. My basic test suite for NSRT though included a lot of crazy interleaves which doesn't interest you, and then a few oddball games and games which fell into certain criteria which I liked to double check.byuu wrote:Wow, some strange stuff out there ... if you have an exact list of games, I'll test all of them to be safe.So double check with NSRT that the one you have is listed, and not a hack.
Offhand:
BRotJ, SM, SMW, ToP, DKJM2, FEoEZ, SO, SMRPG, Tokemeki Memorial (or however you spell that), Super Bomberman.
Although my test suite is more complicated, since it has four different versions of ToP and DKJM2, with the two ROMs merged each possible way.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
http://kuro-hitsuji.net/~tukuyomi/stuff ... french.zip
French localization updated for v0.034. Congrats for this new release and the work done on the SPC7110 decompression
.
French localization updated for v0.034. Congrats for this new release and the work done on the SPC7110 decompression

First off, great release.
I've always found video/audio sync interesting, so I thought "hey, why not tinker around with it and see how badly I can break things?"I'm quite rusty at C++ (to put it mildly), but I thought I'd try anyway; might be fun, and at least make for a funny story. So I set off trying to get it to build. I used to use MinGW back in the day, but I noticed your makefile had a msvc target (thanks for including that btw), and I'm a huge fan of their IDE, so I decided to use vc++ express 2008. To cut to the chase, I eventually got it to build and run, but there were snags along the way, so I just thought I'd detail what happened in case anyone else tries it, or just to get feedback if I'm doing it wrong.
I've always found video/audio sync interesting, so I thought "hey, why not tinker around with it and see how badly I can break things?"I'm quite rusty at C++ (to put it mildly), but I thought I'd try anyway; might be fun, and at least make for a funny story. So I set off trying to get it to build. I used to use MinGW back in the day, but I noticed your makefile had a msvc target (thanks for including that btw), and I'm a huge fan of their IDE, so I decided to use vc++ express 2008. To cut to the chase, I eventually got it to build and run, but there were snags along the way, so I just thought I'd detail what happened in case anyone else tries it, or just to get feedback if I'm doing it wrong.
- First thing, CL bailed out when it hit the base64 encoded string in controller.h. Apparently it has a limit of 65535 bytes for string literals. A quick and dirty hack to get past this was just to cut it into 2 pieces and strcat them together in resources.cpp. Alternatively, I probably could have added it as a resource, but express doesn't have the resource editor so I went for the crude solution.
- Next, in dictionary.hpp, the first for loop uses 'i' as its counter, then declares 'i' again inside the loop body for additional work. CL complained about redeclaration. I wasn't sure what to make of this at first, if it was a clever self-modifying loop, or intended to shadow the loop counter. After reading it through several times I decided it was probably the latter and renamed it to 'j' which fixed it. Is it part of C++0x to be able to shadow like that, or is it a GCC extension?
- Cartridge::get_base_filename and Cartridge::apply_patch both claim to return a value, but don't seem to do so. Wasn't sure what to do here so I just had them return NULL/false.
- Express doesn't come with OpenGL headers, so I got the platform SDK. glext.h was still missing after this though, so I downloaded it from the opengl site, which did the trick.
- spc_dsp.h, nal/file.hpp, and ups.hpp all attempted to include stdint.h, which isn't part of vc++. I downloaded a 3rd party implementation which worked, but then nall/stdint.h failed with redefinition errors, so I commented out the platform check and had it include the standard stdint.h. Are those files perhaps meant to include nall/stdint.h instead of the standard one?
- pEditbox::get_text seems to declare a dynamically sized stack array, which CL balked at. I think that's part of the C99 standard, which GCC surely implements. I just replaced it with a dynamic buffer to get around it.
New WIP, with major changes to internal header detection.
This should get everything working, if we're lucky. It does get Batman: RotJ working for the first time, as well as all the fan translations.
I'm releasing it publicly, as I need all the help I can get with this one. Windows binary with ZIP+JMA support included along with source for the penguins.
Do note that I left the console enabled in the binary. It's not a release-grade version, anyway. But the main reason was to print the scoring information. If any games fail, I'd like that information posted. Might be good to note really close passes, as well, so we can keep an eye on them for future changes. Right now, I'm only aware of SFA2 that gets really really close.
Basically, it prints the address it tests for a header at, the score it ended up getting, and the reset vector's first opcode. If the values are equal, it defaults to LoROM, then HiROM, then ExHiROM. If the reset vector is invalid, or the ROM is too small to contain a header at a certain offset, you won't see any output for that line! That means a lot of times, you'll only see one line output, and sometimes you'll see two or three. No worries, just assume missing means total fail. It only prints output for "possible" header locations.
If you do test, you don't have to play in-game or anything. The second you see any visible output whatsoever, that's good enough.
Many thanks to everyone who tests in advance :D
----------
Hunter and tukuyomi, thank you for the kind words and localizations :)
I really hate that table on the download page, and I need to go through and get names out of all of the locales, but I'd like to get an "Author:" field in that table on the download page. Sorry it's not there just yet.
----------
Fes, thanks for the feedback.
Not for v035, but maybe a while after that, I'll use a more advanced compressor to get the controller below 64kb of string data. Maybe I can rig my order-0 arithmetic coder onto the end of LZSS for a quick and dirty size cut. The reason I don't use 0xnn, 0xnn, is because that takes 5 bytes of source to encode one byte of input, whereas base-64 strings only take ~1.25 bytes. I didn't want those files to slow down compilation much.
So yes, two of those were a mistake on my part, I used stdint.h on them before I created my own stdint wrapper. I've corrected both.
As for spc_dsp.h, that shouldn't be compiled. That is for blargg's reference, unmodified S-DSP emulator. The ones modified to work in bsnes do not require it. And in fact, only src/dsp/sdsp will compile at the moment due to memory map changes.
Looks like I was allocating length*2 wchars, too. I don't know why I was doing that ... I don't think Microsoft's system even supports the extended Unicode symbols that need more than 16-bits, and even if so, they aren't likely to appear in the emulator.
Dropped that back to length+1, and made it use new[]/delete[], instead. That's one horribly inefficient routine by the way, but whatever, it works for now.
The rest I can't do much about, sorry. Hopefully it'll make it easier for you to compile in the future. Sorry for letting the port slip, I just don't have the patience to load VS2k5 again. Software takes like three hours to install >_< and creates slower code than GCC4 anyway. If they'd fix their damn PGO support, I'd be all over it again, though.
This should get everything working, if we're lucky. It does get Batman: RotJ working for the first time, as well as all the fan translations.
I'm releasing it publicly, as I need all the help I can get with this one. Windows binary with ZIP+JMA support included along with source for the penguins.
Code: Select all
byuu.org/temp/bsnes_v034_wip03.zip
Basically, it prints the address it tests for a header at, the score it ended up getting, and the reset vector's first opcode. If the values are equal, it defaults to LoROM, then HiROM, then ExHiROM. If the reset vector is invalid, or the ROM is too small to contain a header at a certain offset, you won't see any output for that line! That means a lot of times, you'll only see one line output, and sometimes you'll see two or three. No worries, just assume missing means total fail. It only prints output for "possible" header locations.
If you do test, you don't have to play in-game or anything. The second you see any visible output whatsoever, that's good enough.
Many thanks to everyone who tests in advance :D
----------
Hunter and tukuyomi, thank you for the kind words and localizations :)
I really hate that table on the download page, and I need to go through and get names out of all of the locales, but I'd like to get an "Author:" field in that table on the download page. Sorry it's not there just yet.
----------
Fes, thanks for the feedback.
I don't have a workaround for that. For whatever reason, ISO didn't add an "incbin"-style command, and I need a platform-agnostic way of encoding binary data.Apparently it has a limit of 65535 bytes for string literals.
Not for v035, but maybe a while after that, I'll use a more advanced compressor to get the controller below 64kb of string data. Maybe I can rig my order-0 arithmetic coder onto the end of LZSS for a quick and dirty size cut. The reason I don't use 0xnn, 0xnn, is because that takes 5 bytes of source to encode one byte of input, whereas base-64 strings only take ~1.25 bytes. I didn't want those files to slow down compilation much.
Oops, sorry. Didn't get a warning on GCC, so I overlooked it. This is now fixed.# Next, in dictionary.hpp, the first for loop uses 'i' as its counter, then declares 'i' again inside the loop body for additional work.
First should return the filename, it's just a convenience thing to allow chaining commands. The second should return result of patching. I've fixed both now, thanks.# Cartridge::get_base_filename and Cartridge::apply_patch both claim to return a value, but don't seem to do so.
Microsoft really pisses me off by intentionally ignoring stdint.h. nall/stdint.hpp was meant as a workaround, so that I didn't have to special case Visual C++. The idea was to not require you to get one of those third-party add-ons.# spc_dsp.h, nal/file.hpp, and ups.hpp all attempted to include stdint.h, which isn't part of vc++. Are those files perhaps meant to include nall/stdint.h instead of the standard one?
So yes, two of those were a mistake on my part, I used stdint.h on them before I created my own stdint wrapper. I've corrected both.
As for spc_dsp.h, that shouldn't be compiled. That is for blargg's reference, unmodified S-DSP emulator. The ones modified to work in bsnes do not require it. And in fact, only src/dsp/sdsp will compile at the moment due to memory map changes.
Hahah, yeah, that would be C99 syntax. Very nice, that.# pEditbox::get_text seems to declare a dynamically sized stack array, which CL balked at.
Looks like I was allocating length*2 wchars, too. I don't know why I was doing that ... I don't think Microsoft's system even supports the extended Unicode symbols that need more than 16-bits, and even if so, they aren't likely to appear in the emulator.
Dropped that back to length+1, and made it use new[]/delete[], instead. That's one horribly inefficient routine by the way, but whatever, it works for now.
The rest I can't do much about, sorry. Hopefully it'll make it easier for you to compile in the future. Sorry for letting the port slip, I just don't have the patience to load VS2k5 again. Software takes like three hours to install >_< and creates slower code than GCC4 anyway. If they'd fix their damn PGO support, I'd be all over it again, though.
I think I found a bug. Aryol's first screen(The one that shows who published it) has part of a letter in the upper left corner of the screen. It's the same font as either the word Presents or the first letter of the company's logo.
I forgot to mention I'm using the dump found on No-Intro's list and there's only one version of the game(unless it was renamed when released anywhere other than Japan.).
I forgot to mention I'm using the dump found on No-Intro's list and there's only one version of the game(unless it was renamed when released anywhere other than Japan.).
I'm pretty sure we noticed a lot of these during the initial test run a long time ago. They just happen to get cut off by TV overscan, so nobody noticed them. I know there's a game called Yuujin 2 something that does this a lot, for instance.
Not saying this isn't a bug, per se.
Not saying this isn't a bug, per se.
Last edited by byuu on Wed Aug 13, 2008 5:14 pm, edited 1 time in total.
Well, it may still be a bug, so thanks for mentioning it. We'll leave it to FitzRoy and tetsuo, as they tested all bsnes-observed bugs on hardware already, so they'd probably remember this one. Food for thought: what about games that looked right in bsnes, but really should display some form of corrupted graphics on hardware? :P
A-B is a pretty good sign that the detection should be good enough. The only way a game is going to get me is if it has a valid reset vector (1:2), that points to a very common opcode for a reset vector (eg 'sei') (1:24), and that has a completely invalid header where the real one should be -- yet a valid header where it should not be (only observed in Batman: RotJ so far, which I can detect because the reset vector for the bad header points to a junk opcode.)
We could probably just test all the beta / PD / known-troublesome games and call it a day at this point. Unless you wanted to test more, of course. I won't complain about that :)
Very much appreciated, thank you! Please don't wear yourself out too much though :)Tested all games up until B. Aside from one being an SA-1 game, all worked.
A-B is a pretty good sign that the detection should be good enough. The only way a game is going to get me is if it has a valid reset vector (1:2), that points to a very common opcode for a reset vector (eg 'sei') (1:24), and that has a completely invalid header where the real one should be -- yet a valid header where it should not be (only observed in Batman: RotJ so far, which I can detect because the reset vector for the bad header points to a junk opcode.)
We could probably just test all the beta / PD / known-troublesome games and call it a day at this point. Unless you wanted to test more, of course. I won't complain about that :)
Last edited by byuu on Wed Aug 13, 2008 5:26 pm, edited 1 time in total.
Haven't tested B yet. >.> I meant up to B. Sorry, I can't communicate worth a shit.byuu wrote:Well, it may still be a bug, so thanks for mentioning it. We'll leave it to FitzRoy and tetsuo, as they tested all bsnes-observed bugs on hardware already, so they'd probably remember this one. Food for thought: what about games that looked right in bsnes, but really should display some form of corrupted graphics on hardware?
Very much appreciated, thank you! Please don't wear yourself out too much thoughTested all games up until B. Aside from one being an SA-1 game, all worked.
A-B is a pretty good sign that the detection should be good enough. The only way a game is going to get me is if it has a valid reset vector (1:2), that points to a very common opcode for a reset vector (eg 'sei') (1:24), and that has a completely invalid header where the real one should be (only observed in Batman: RotJ so far, which I can detect because the reset vector for the bad header points to a junk opcode.)
We could probably just test all the beta / PD / known-troublesome games and call it a day at this point.
I'll do B and C later.
Thanks for the fixes; I'll keep my eye out for anything else. A few warnings I forgot to mention:
- Several assorted warnings about mixing bool with integral types in comparisons and applying unary '-' to them. Added warning suppression flags for 4804 and 4805.
- Not all code paths in dictionary::import return a value. Not sure if true or false is your success code, so just left it for now.
- CL warns about unknown option '-static' when compiling libco.
I've been out of the native code loop for a while now (get it? loop?) so I was unfamiliar with that. After looking it up it sounds pretty cool. If you give me a quick rundown of the problem I'd be willing to investigate a bit with 2k8 pro once I get it.If they'd fix their damn PGO support, I'd be all over it again, though.
Have example expressions that trigger the warning? I'll look into it more from there. I do rely on intrinsic boolean casts sometimes, eg:* Several assorted warnings about mixing bool with integral types in comparisons and applying unary '-' to them. Added warning suppression flags for 4804 and 4805.
uint16_t reg;
bool negative = reg & 0x8000; //0 = false, 1 = true
Whereas I know the "PC" way of doing it is bool negative = static_cast<bool>((reg >> 15) & 1) -- at least, judging from all the code I always get stuck looking at >_>;
I need to find a GCC setting to warn on no return value. I'm sure it's there, just don't know it off the top of my head. Thanks, I'll get these as well.# Not all code paths in dictionary::import return a value. Not sure if true or false is your success code, so just left it for now.
Weird, that should only be added for GCC. It's technically only needed for the Mac libco, but it doesn't hurt the Windows / Linux one, so why specialize it further?# CL warns about unknown option '-static' when compiling libco.
Make a PGINSTRUMENT build, run a few games for ~5 minutes (1 minute a piece, probably won't even get in-game in that amount of time), now put the generated pgc/pgd or whatever files into the same folder as your objects, and run a PGOPTIMIZE build. It will error out with an internal compiler error, advising you to contact Microsoft. No, I'm not going to contact them about my little freeware software project.If you give me a quick rundown of the problem I'd be willing to investigate a bit with 2k8 pro once I get it.
It tells me to try simplifying code on sCPU/core.cpp, on the line it specifies, it contains only "status.in_opcode = false;" -- you tell me how to simplify that :P
In all seriousness, it's probably choking on the switch(opcode) loop above, with the 256 entries. I tried replacing the switch table with (this->*optable[opcode])(), but it gives the same error during compilation either way.
It's apparently a problem lots of people on the internet are having if you Google the error message, and nobody ever gets it fixed.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
If you want me to look into it, I can see about getting you PGO builds on Windows (although not with MSVC), I used to do it all the time on Windows with GCC 3, and still do it on Linux with GCC 4.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding