Truth be told, there's really not all that much that has changed in CrabEmu since the last release (at least, not enough to warrant the timeframe that it has been). I've just been busy with otherprojects (and "real life" of course). For a quick sampling of what has actually changed, here's the change log of what's in the SVN repository right now:

Code:

CrabEmu 0.2.0 : Released ???

Z80 Core:- Fix emulation of I/O Ports to actually behave as they do on a real Z80 (placing a 16-bit value on the address bus, not an 8-bit one). This doesn't really affect SMS emulation at all (since I only pay attention to the low 8-bits of the I/O Port number anyway), but it does make things more correct.- Fix filename check of variable to send to gui_set_title.

GUI (Dreamcast):- Allow browsing of directories (resolves feature request #2973501).- If we can't get to the default rom directory (/cd/crabemu/roms), start the rom browser at /cd, failing that start at /.- Make rom browser keep track of the last viewed directory, so when someone goes back after playing a game, they start in the last viewed directory.- Show the current directory on the top of the rom list.

GUI (Mac OS X):- Added a menu option to enable/disable PAR cheats.- Added a GUI dialog for editing PAR cheats.- Added a color information dialog if a user clicks on a color in the Palette Viewer dialog.- Hide the mouse cursor in fullscreen mode.- Allow the user to set a joystick button to exit the emulator (but don't require it to be there).- Added option to preserve the aspect ratio in fullscreen mode.- Added option to select a directory to save SRAM, Save States, and Cheats to. This defaults to a few directories (SRAM Saves, Save States, Cheat Codes) rooted in ~/Library/Application Support/ljsdcdev/CrabEmu/ .- Added display of the SDSC Debug Console.- Continued adding to the Help file.- Added option to display images filtered by HQ2x, HQ4x, and Scale2x- Fix Pattern and Palette viewer for RGB555 color.- Allow use of the close button on the emulation window to stop the currently running rom.- Split out Preferences related functionality from EmuController.- Cleaned up some more small code issues.- Fix help indexing on Snow Leopard.- Save PAR cheats when a rom is closed.

GUI (Qt):- Fixed key repeat issue on X11.- Added a menu option to enable/disable PAR cheats.- Added a debugger comparable to the OS X version. (Depends on QScintilla2)- Added support for save, state, and cheat directories- Command line arguments can be used to pass in the filename of a ROM- Code cleanups- Fixed hang on exit and load when the emulator is paused.- Actually load SRAM when a ROM is loaded.

One thing to note is that the YM2413 emulation is not enabled on the Dreamcast port at the moment, and I don't know if it would be before any sort of release, as I don't believe that it would run fast enough.

I have successfully compiled latest SVN.I have noticed that there is something wrong with sound:http://www.youtube.com/watch?v=FneIOfzEVtAIs it something wrong with compiling or this how it is now?I run it off sd card. / just burned on cd and it's all the same.It runs good with SMS Plus DC...

I'm not sure what is wrong with that game, if anything, as I've never played it before, nor tested it myself. That said, I haven't really changed anything in the sound emulation in the Dreamcast port of CrabEmu since the last release.

Really strange problem ... but i did some research today and i can say:0.1.9 run everything fineSVN 66 run some games with sound glitches but run it fine if a game is only one in the rom folder so i am not a coder and only one idea came to my mind there is something wrong with new rom browser... Can you check it BlueCrab ? ...

Just wanted to affirm that a new release of CrabEmu would be very welcome. That list of changes would allow me to put the other SMS emulators I use away, once and for all.

Will the new release continue to support OS X PPC and 10.4? I hope so! I wasn't able to build the nightly when I tried to do so a while ago.

It should still support PPC, as it still builds on my end that way. The current code on my end builds just fine as a 3-architecture (i386, x86_64, ppc) binary, although I did have to tweak things a little bit to get that to work when building under Mac OS X 10.7.

I haven't tested it on PPC in a long while, but I certainly intend to do so before a release.

In theory, it should still run under Mac OS X 10.3, as well, at least I think it should...

After many vicissitudes, I was able to find and install Xcode 3.1.4 (the latest version supported on Leopard/PPC), and successfully build CrabEmu 0.2.0 as it now stands. The good news is that it runs under both Tiger and Leopard, and seems to run 4 Pak All Action just fine!

(How funny that you'd added support for its mapper just a few hours before I asked! Thanks so much for that.)

The bad news is that the sound is extremely distorted on all the games I tried, with a gain factor that's 2x or 3x what it should be (so that if I disable some of the PSG channels the sound improves because it's not getting pegged as hard). This happens under both 10.4 and 10.5, and I don't currently have any nutty audio hardware hooked up. I'm also hearing what I think is some kind of audio interference every 50-75 ms, leading to a steady clicking/popping in the channel.

Before I file bug reports, though, I want to make sure this isn't related to an error I got when building the binary:

/Users/~/Downloads/CrabEmu/osx/build/CrabEmu.build/Debug/CrabEmu.build/Script-2A5626390F321FD1003A15F4.sh: line 8: /Developer/Applications/Utilities/Help\: No such file or directory

(I replaced my actual home directory name with "~".)

Is this likely to have in any way caused the audio problems? I can't imagine how it would, but wanted to mention it.

BTW I read that Apple actually dropped PPC support in XCode 3.2.6 (it's still present in 3.2.5). Some of the discussion here goes over my head, but it sounds like there's a kludge to get around it. Since you're using 3.2.6 I thought it might be worth a heads-up, but maybe you already know about it.

Oh, and also: the latest version of Xcode that runs on Tiger is 2.5 (or thereabouts). 3.x versions aren't supported, so if you need 3.0 or later to build CrabEmu (I don't know if that's the case), that's not happening on Tiger.

After many vicissitudes, I was able to find and install Xcode 3.1.4 (the latest version supported on Leopard/PPC), and successfully build CrabEmu 0.2.0 as it now stands. The good news is that it runs under both Tiger and Leopard, and seems to run 4 Pak All Action just fine!

(How funny that you'd added support for its mapper just a few hours before I asked! Thanks so much for that.)

Someone had pointed it out to me in IRC a few days before, and I had just gotten around to doing it that particular day.

Quote:

The bad news is that the sound is extremely distorted on all the games I tried, with a gain factor that's 2x or 3x what it should be (so that if I disable some of the PSG channels the sound improves because it's not getting pegged as hard). This happens under both 10.4 and 10.5, and I don't currently have any nutty audio hardware hooked up. I'm also hearing what I think is some kind of audio interference every 50-75 ms, leading to a steady clicking/popping in the channel.

Try taking the constants on lines 27-28 of sn76489.c (the volume_values array) and divide each number by two. See if that helps at all. Granted, those numbers have been the way they are since 0.1.8, so I don't know that it'll help any.

Quote:

Before I file bug reports, though, I want to make sure this isn't related to an error I got when building the binary:

/Users/~/Downloads/CrabEmu/osx/build/CrabEmu.build/Debug/CrabEmu.build/Script-2A5626390F321FD1003A15F4.sh: line 8: /Developer/Applications/Utilities/Help\: No such file or directory

(I replaced my actual home directory name with "~".)

Is this likely to have in any way caused the audio problems? I can't imagine how it would, but wanted to mention it.

No... That's something to do with building the help file.

Quote:

BTW I read that Apple actually dropped PPC support in XCode 3.2.6 (it's still present in 3.2.5). Some of the discussion here goes over my head, but it sounds like there's a kludge to get around it. Since you're using 3.2.6 I thought it might be worth a heads-up, but maybe you already know about it.

I know that I can build ppc binaries with 3.2.6, as that's how I currently do things. Dunno if I did anything special to make it work (I doubt it), but it does work for me.

Quote:

Oh, and also: the latest version of Xcode that runs on Tiger is 2.5 (or thereabouts). 3.x versions aren't supported, so if you need 3.0 or later to build CrabEmu (I don't know if that's the case), that's not happening on Tiger.

I don't see why it wouldn't build with Xcode 2.x, I just can't guarantee it since I don't have anything that runs that anymore. I don't think I'm doing anything zany that would require a newer version of Xcode.

Try taking the constants on lines 27-28 of sn76489.c (the volume_values array) and divide each number by two. See if that helps at all. Granted, those numbers have been the way they are since 0.1.8, so I don't know that it'll help any.

Before I do that, I tested out a FM synth game today (the hacked version of Ancient Ys) and noticed that I'm having the same problem. Since that's not using the SN76489 (and I tried turning off the PSG to confirm), does that mean the problem lies elsewhere?

I have to admit that the massively distorted sound is kind of amazing -- the gentle intro to Ancient Ys turns into an insanely overdriven, Merzbow-esque crash of noise.

BlueCrab wrote:

No... That's something to do with building the help file.

I figured as much but wanted to make sure. As you might guess I don't do a lot of building/compiling apps.

Oh, by the way, a suggestion on that front: the README says "To build CrabEmu once you have everything set up, all you should have to do is open the Xcode project file and hit the build button." But the way you put it in the 0.1.9 README was better, I think: "To build CrabEmu for Mac OS X, all you should have to do is open the Xcode project file (in the osx directory), and build it from within Xcode."

I spent 15 minutes trying to build the plausible-looking CrabEmu.pro, and wondering what I was doing wrong and why all my options were greyed out, before I realized my mistake. It may sound ridiculously dumb, but when you're flying blind at 3:00 am it's easy to get confused. (Like I said, I don't build a lot of apps...)

BlueCrab wrote:

I know that I can build ppc binaries with 3.2.6, as that's how I currently do things. Dunno if I did anything special to make it work (I doubt it), but it does work for me.

Good to hear. The discussion I linked made it sound like it required some kind of kludge (and at least one developer got caught out, thinking he was building for PPC -- but it wasn't in the binary!).

BlueCrab wrote:

I don't see why it wouldn't build with Xcode 2.x, I just can't guarantee it since I don't have anything that runs that anymore. I don't think I'm doing anything zany that would require a newer version of Xcode.

I just tried building it under 2.5, but got the same error with the help file -- and this time it seems to have been a deal-breaker: the build failed completely and I can't open the app, whether I build in debug or release mode. Any idea what's going on with that one?

Try taking the constants on lines 27-28 of sn76489.c (the volume_values array) and divide each number by two. See if that helps at all. Granted, those numbers have been the way they are since 0.1.8, so I don't know that it'll help any.

Before I do that, I tested out a FM synth game today (the hacked version of Ancient Ys) and noticed that I'm having the same problem. Since that's not using the SN76489 (and I tried turning off the PSG to confirm), does that mean the problem lies elsewhere?

I have to admit that the massively distorted sound is kind of amazing -- the gentle intro to Ancient Ys turns into an insanely overdriven, Merzbow-esque crash of noise.

Probably... I'll have to try to get it running on my only PPC-based Mac (a first-generation Mac Mini) and see what's going on. I don't have a time-table on when I may be able to do that, as things are about to get very busy with my work/school, unfortunately.

goldenband wrote:

BlueCrab wrote:

I don't see why it wouldn't build with Xcode 2.x, I just can't guarantee it since I don't have anything that runs that anymore. I don't think I'm doing anything zany that would require a newer version of Xcode.

I just tried building it under 2.5, but got the same error with the help file -- and this time it seems to have been a deal-breaker: the build failed completely and I can't open the app, whether I build in debug or release mode. Any idea what's going on with that one?

Try updating to the latest SVN revision and see if that helps. Looks like Xcode was needlessly escaping things or something...

Probably... I'll have to try to get it running on my only PPC-based Mac (a first-generation Mac Mini) and see what's going on. I don't have a time-table on when I may be able to do that, as things are about to get very busy with my work/school, unfortunately.

Understood. I appreciate whatever you're able to do, and I'll do my best to help on my end.

BlueCrab wrote:

Try updating to the latest SVN revision and see if that helps. Looks like Xcode was needlessly escaping things or something...

Done, and I've just attempted a build on Tiger (10.4.11). It's not throwing the same error with the help file -- it complained about permissions, then asked me to point to a directory, and I chose /osx/help (hope that's correct) -- but now it's complaining about line 42 of main.m:

Built successfully on Leopard without build errors (though with the same behavior of the Help Indexer or whatever it's called), but the sound problems remain. I tried editing sn76489.c as you suggested, but it didn't seem to make a difference.

Also, I'm seeing another issue, which was also present in the other build: games are often black-screening on startup, but then work after a relaunch if I change the rendering engine. When I do get the black screen, if I then resize the window I get massive graphic corruption, including messed-up pieces of other onscreen windows (Finder, etc.). Not sure what's going on there.

Also, I'm seeing another issue, which was also present in the other build: games are often black-screening on startup, but then work after a relaunch if I change the rendering engine. When I do get the black screen, if I then resize the window I get massive graphic corruption, including messed-up pieces of other onscreen windows (Finder, etc.). Not sure what's going on there.

Should be fixed now. Update to the latest SVN revision.

As an aside, I saw that particular issue when I tried to compile initially on my Mac Mini, hence why I said I had to try to get it running. I just didn't really have any idea why it was happening until you pointed out that little workaround.

I still haven't looked at sound, since I'm doing everything remotely on that Mac Mini at the moment, so I can't hear any sound it might be making.

Built on Leopard, and the black-screen issue appears to be gone. Thanks! I'll try it under Tiger shortly.

BlueCrab wrote:

As an aside, I saw that particular issue when I tried to compile initially on my Mac Mini, hence why I said I had to try to get it running. I just didn't really have any idea why it was happening until you pointed out that little workaround.

Heh. Glad that my workaround was of use!

BlueCrab wrote:

I still haven't looked at sound, since I'm doing everything remotely on that Mac Mini at the moment, so I can't hear any sound it might be making.

Understood. FWIW the sound issue is still present, not that I figured the two issues were apt to be related.

The black screen is gone under Tiger too, but I found a new (?) and highly reproducible bug on Tiger with 0.2.0 r81:

1) Open CrabEmu for the first time (or at least without a /Users/~/Library/Preferences/net.ljsdcdev.crabemu.plist file).2) Go to Preferences. Attempt to configure button 1 for Controller 1.3) CrabEmu crashes.4) Now open CrabEmu again and attempt to configure button 1. This time it doesn't crash, and appears to work, but when you go to play a game, nothing happens. No controller inputs work.

This happens even after deleting /Users/~/Library/Preferences/net.ljsdcdev.crabemu.plist.Going back to 0.1.8 allows you to fix the problem within 0.1.8, but the fix doesn't help 0.2.0.

Also, with a pre-existing net.ljsdcdev.crabemu.plist created by 0.1.8 or 0.1.9, I saw the following behavior:

0.1.8 prefs: crashes 0.2.0 when you attempt to configure keyboard; doesn't inherit kbd configurations from 0.1.80.1.9 prefs: the 0.2.0 app DOES inherit kbd configs from 0.1.9 if 0.1.9 created the prefs file, but nothing happens if you try to modify them

I can double-check to make sure this isn't present in Leopard -- I don't believe it was, though.

EDIT: Huh, there's also apparently a bug in 0.1.9 where you can modify your keyboard config prefs once, but then if you quit the app, relaunch, and try to modify them again, it won't save the new configuration after you quit -- the next time you launch, it'll be with your first configuration. Maybe that's old news, though.

The black screen is gone under Tiger too, but I found a new (?) and highly reproducible bug on Tiger with 0.2.0 r81:

1) Open CrabEmu for the first time (or at least without a /Users/~/Library/Preferences/net.ljsdcdev.crabemu.plist file).2) Go to Preferences. Attempt to configure button 1 for Controller 1.3) CrabEmu crashes.4) Now open CrabEmu again and attempt to configure button 1. This time it doesn't crash, and appears to work, but when you go to play a game, nothing happens. No controller inputs work.

This happens even after deleting /Users/~/Library/Preferences/net.ljsdcdev.crabemu.plist.Going back to 0.1.8 allows you to fix the problem within 0.1.8, but the fix doesn't help 0.2.0.

Also, with a pre-existing net.ljsdcdev.crabemu.plist created by 0.1.8 or 0.1.9, I saw the following behavior:

0.1.8 prefs: crashes 0.2.0 when you attempt to configure keyboard; doesn't inherit kbd configurations from 0.1.80.1.9 prefs: the 0.2.0 app DOES inherit kbd configs from 0.1.9 if 0.1.9 created the prefs file, but nothing happens if you try to modify them

I can double-check to make sure this isn't present in Leopard -- I don't believe it was, though.

It is. I already checked there.

Quote:

EDIT: Huh, there's also apparently a bug in 0.1.9 where you can modify your keyboard config prefs once, but then if you quit the app, relaunch, and try to modify them again, it won't save the new configuration after you quit -- the next time you launch, it'll be with your first configuration. Maybe that's old news, though.

Never heard that one before... At least, I don't remember hearing that one before. Then again, its been so long since 0.1.9, its quite possible that I already knew about/fixed it.

EDIT: Sound bug is fixed in r84. Easy find/fix once I heard what it was doing.

EDIT 2: Update on the preferences bug... It happens on x86-64 as well, but only if there's not an existing preferences file. In fact, if there is an existing preferences file on Leopard, it seems to work fine (I can copy over my one from my x86-64 machine and use the preferences dialog to edit it just fine).

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum