Page 1 of 3

Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Sat Jun 03, 2017 7:45 am
by Mask of Destiny
Hello folks, I am happy to announce the latest stable release of BlastEm. This release is largely focused on accuracy and completeness. YM2612 SSG-EG and CSM modes are implemented, VDP Mode 4 is implemented, a bunch of timing issues have been fixed, etc. Since I added Mode 4 support, I also went and added basic SMS emulation in the form of the Genesis/MD backwards compatibility mode.

Thanks to the info from Kabuto and a couple other members of the Titan team, this version of BlastEm can run Overdrive 2 near perfectly. There are a couple of minor artifacts still, but nothing that really detracts from the experience.

Anyway, you can download it here or check out the full changelog.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Sat Jun 03, 2017 1:50 pm
by Manveru
Good work mate, i am happy to see an emulator alive and growing that good

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Fri Jun 09, 2017 1:46 pm
by Natsumi
I've heard a lot of good about BlastEm, so I just checked it out of curiosity. I've got to say, I am a little disappointed by what I've seen so far. Let me explain; The biggest gripe for me is the menu. It seems like you cant just drop in ROMs, and navigating the menu is terrible. Especially because it doesnt remember the last place I was at, and it defaults to a folder that I need to navigate out of, to go to another drive. I would really much more like a classical context menu like what most programs have, it would really be much easier to deal with.

Another thing is the mouse, it seems to capture it when I click on the window, and the way I operate emulators, means I will click on the window after doing some dev work and building my ROM, to then drag&drop the ROM in. Since I have multiple screens, I much rather click on it. First time I thought you just cant move mouse anywhere else, and had to ALT+TAB out of the window. Adding a menu entry for allowing mouse capture would be much wiser idea in my eyes, as I probably will end up forgetting again and be needlessly frustrated when I try to open up IRC or something.

Also, a lot of my S3K hacks just keep crashing and restarting in BlastEm. Usually, few frames into a level, it would always happen, seems no matter what. Also, the sound driver breaks in one of the hacks so that no music would play, but SFX seem just fine (using the normal S&K sound driver, no modifications aside from sound bank IDs). I can't figure out why this happens, and its really stupid, because both of these hacks work on every single emulator, and hardware! Also, I am having issues with my hack, Sonic 4 in 1. Again, works on most emulators and hardware, but spits out mapper errors all the time, and I even was able to make it crash. I've also noticed some graphical glitches here and there, but nothing major.

Overall, I am excited overall for an emulator that is not shit like all the emulators out there, but this emulator at the current state is the most user-hostile emulator I've seen in my life, and it is very buggy apparently.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Fri Jun 09, 2017 6:54 pm
by Mask of Destiny
Natsumi wrote:It seems like you cant just drop in ROMs,
Do you mean drag and drop? Should be easy enough to add support for.
Natsumi wrote:Especially because it doesnt remember the last place I was at, and it defaults to a folder that I need to navigate out of, to go to another drive.
It should remember the folder within a single run of the program (press Esc to go back to the menu after you've loaded a ROM), though it won't remember what page you're on in a long list of files. The folder it starts in on a fresh run of the emulator is configurable by changing the initial_path option inside the ui section of the config file (default.cfg in the same directory as the executable).
Natsumi wrote:Another thing is the mouse, it seems to capture it when I click on the window, and the way I operate emulators, means I will click on the window after doing some dev work and building my ROM, to then drag&drop the ROM in. Since I have multiple screens, I much rather click on it. First time I thought you just cant move mouse anywhere else, and had to ALT+TAB out of the window. Adding a menu entry for allowing mouse capture would be much wiser idea in my eyes, as I probably will end up forgetting again and be needlessly frustrated when I try to open up IRC or something.
Ah, sorry about that. It really should only capture the mouse when there's an emulated mouse connected which won't be the case for the vast majority of games.
Natsumi wrote:Also, a lot of my S3K hacks just keep crashing and restarting in BlastEm.
Do these by any chance keep the S&K product ID in the header? The reason I ask is that Sonic & Knuckles is treated specially because it's a weird cart. Partly this is to support arbitrary lock-on (not yet exposed in the UI, but accessible through a command line option) and partly this is because S&K won't work at all with the normal behavior. Most carts have incomplete address line decoding which causes the ROM to mirror itself throughout the bottom 4MB of the address space and by default BlastEm replicates this behavior. This is not true of S&K; however, and if you mirror the ROM you'll end up with the "No Way" message. Anyway, I'd be open to suggestions on the best way to handle this. I could switch the ROM DB entry for S&K to be hash based rather than product ID based. This would cause S&K based ROM hacks to get the "normal" behavior which is probably what you want for a hack that's >2MB in size, but not for ones that are the normal 2MB. Maybe adding a size filter is the right option? This way 2MB hacks would work fine and could be used with lock-on support and >2MB hacks would just be treated like a normal ROM.

If that doesn't sound like it applies to the hacks in question, please post a link or send them to me so I can investigate.
Natsumi wrote:Also, I am having issues with my hack, Sonic 4 in 1. Again, works on most emulators and hardware, but spits out mapper errors all the time, and I even was able to make it crash.
This appears to be a separate issue. I can reproduce the crash by selecting Sonic 3 and I'll investigate that tonight since that's obviously a bug. I'm pretty sure this is because Sonic 3 has save RAM and my SSF2 mapper support is probably not playing nice with that. I'm not sure what you mean by "spits out mapper errors all the time" though. I didn't see any noticeable problems when I tried the other 3 games
Natsumi wrote:this emulator at the current state is the most user-hostile emulator I've seen in my life
I take it you've never tried to run a Genesis/MD ROM in MAME/MESS then :P

I'll add drag and drop and hopefully the initial_path setting will address your concerns about having to navigate through a directory tree on each invocation. I am working on a new UI that's not ROM-based (though that will stick around as an option), but since being gamepad friendly is important for me it still won't be drop-down menu driven like Fusion or Gens. If you have any other specific feedback about the usability of the current UI apart from the obvious stuff like the ugly text rendering and the inability to edit the config from within the UI please let me know. My use cases are not yours and so what seems like a major usability issue to you might not be obvious to me.
Natsumi wrote:, and it is very buggy apparently.
I think your perspective on this is colored by the specific ROMs you are trying to run. In general, 0.5.0 has been pretty extensively tested against the commercial library and high profile demos/homebrew. ROM-hacks have not been a priority for testing, but perhaps this demonstrates that was a mistake.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Fri Jun 09, 2017 9:53 pm
by Natsumi
Mask of Destiny wrote:It should remember the folder within a single run of the program (press Esc to go back to the menu after you've loaded a ROM), though it won't remember what page you're on in a long list of files. The folder it starts in on a fresh run of the emulator is configurable by changing the initial_path option inside the ui section of the config file (default.cfg in the same directory as the executable).
Ah, seems like I have missed this. Personally I would save some settings file or something in registry on programs I make, to be smart about the last folder you used. Many programs do this but arent too smart about it generally. It would be good to see this implemented some day!
Mask of Destiny wrote:Ah, sorry about that. It really should only capture the mouse when there's an emulated mouse connected which won't be the case for the vast majority of games.
Just for simplicity for the user and consistency, a button to do it would be preferrable than the emulator just doing it and the user may get confused with it. You could also add 2 modes where the user can decide between them, and then they at least know what they are selecting.
Mask of Destiny wrote:Do these by any chance keep the S&K product ID in the header?
Yes, but even playing about with it did not fix my issues, so that does not seem to be my issue.
Mask of Destiny wrote:The reason I ask is that Sonic & Knuckles is treated specially because it's a weird cart. Partly this is to support arbitrary lock-on (not yet exposed in the UI, but accessible through a command line option) and partly this is because S&K won't work at all with the normal behavior. Most carts have incomplete address line decoding which causes the ROM to mirror itself throughout the bottom 4MB of the address space and by default BlastEm replicates this behavior. This is not true of S&K; however, and if you mirror the ROM you'll end up with the "No Way" message. Anyway, I'd be open to suggestions on the best way to handle this. I could switch the ROM DB entry for S&K to be hash based rather than product ID based. This would cause S&K based ROM hacks to get the "normal" behavior which is probably what you want for a hack that's >2MB in size, but not for ones that are the normal 2MB. Maybe adding a size filter is the right option? This way 2MB hacks would work fine and could be used with lock-on support and >2MB hacks would just be treated like a normal ROM.
The big issue is that if the people edit the header and yet only do something like level edits. How are you gonna handle this? Or, if they only editing code very intensively, but leave the header alone, you also need to detect that. I guess the best compromise is check a few fields in the header, and maybe search for the header checking code, and then based on all of those info decide if its supposed to be S&K hack. But you also risk breaking non-S&K hacks that kinda look like they may be S&K hacks based on the header and some of the code. You could also add a little field in some unused string in the header to help the emulator to do few things, and add it to the documentation. No emulator really can do everything like this perfectly because of how big edge-cases ROM hacks can cause.
Mask of Destiny wrote:If that doesn't sound like it applies to the hacks in question, please post a link or send them to me so I can investigate.
I would be happy to, but these hacks are work-in-progress and are still really hush-hush, so I can't show them off. However, I could debug them myself, only if the debugger in BlastEm was something I am more familiar with (I use Regen for debugging, as it works sometimes without problems and does what I need it to do usually). I was not able to find much help from the debugger, but honestly I did not try too much, it felt clunky to use for me.
Mask of Destiny wrote:This appears to be a separate issue. I can reproduce the crash by selecting Sonic 3 and I'll investigate that tonight since that's obviously a bug. I'm pretty sure this is because Sonic 3 has save RAM and my SSF2 mapper support is probably not playing nice with that. I'm not sure what you mean by "spits out mapper errors all the time" though. I didn't see any noticeable problems when I tried the other 3 games
I tried Sonic 3 & Knuckles and got the errors, for it to quit immediately after. I checked out S1-S3 too, and the first two worked all fine. I'll admit, this hack was quite hard to even get to work on many of the emulators it currently does, so I have some sympathy on that end; I had a hell of a time trying to figure it all out, based on very little information. I even had to debug some issues with Everdrive for days (A friend in another country had one, so it made it so much harder) just to find out I was not clearing some RAM I should have been. If I didn't bother fixing it for emulators, no emulators would be able to run the hack in any form.
Mask of Destiny wrote:I take it you've never tried to run a Genesis/MD ROM in MAME/MESS then :P
Well since I've heard its awful anyway, I haven't bothered, you got me :P
Just to clarify afterwards, I don't mean to be dick about it, it was more about frustration with the apparent flaws I was facing. Its frustrating when something that seems to have promise, has many flaws that turn me off from using it. The amount of times I've gotten frustrated with using Regen for various reasons, is off the charts. Its a huge shame its still the most useful emulator ever made, with the huge amount of issues it has. Especially because of its debugger actually working (unlike certain some emulators >_> *cough Exodus cough*). In fact I am quite frustrated I still have to deal with it, and would jump ship as soon as I can get my hands on something more working solution...
Mask of Destiny wrote:I'll add drag and drop and hopefully the initial_path setting will address your concerns about having to navigate through a directory tree on each invocation.
It seems fair enough, though I would still like to have something more 'smart'. Of course, having the option is still good always. Having to never navigate menus will help a lot though, since I wont be needing too many paths if I have my hacking folder already open anyway
Mask of Destiny wrote:I am working on a new UI that's not ROM-based (though that will stick around as an option), but since being gamepad friendly is important for me it still won't be drop-down menu driven like Fusion or Gens.
Now, I understand you want to make things work with gamepads, but if it means harder for mouse users, or developers, you aren't gonna get much support. Unless you can implement a menu system that is both easy for mouse users and gamepad users, I would suggest finding some ways to accommodate mouse only users, and gamepad only users.

Gamepads reminds me, I had my USB controlled hooked on my computer from playing some other games few days ago, it would complain about every single button it has, not being mapped to anything. It would be fine, but there is a lot of them, so I ended up holding Enter to skip them quickly... Only for the emulator to exit and open 10 instances. I'll admit, its an user error, but surely you can find a better way to deal with it than complain about each button separately?
Mask of Destiny wrote:If you have any other specific feedback about the usability of the current UI apart from the obvious stuff like the ugly text rendering and the inability to edit the config from within the UI please let me know. My use cases are not yours and so what seems like a major usability issue to you might not be obvious to me.
I had easier time using my arrow keys than my mouse for navigation. Also, I for some reason was able to change the FPS in the menu, only for the FPS to reset to 60 ingame. ...Only for it to go back to 200 in the menu. Seems a little strange to me. Also I was able to mess up the menu somehow when I was playing around with the FPS hotkeys (I guess, I didn't bother reading the README enough to find more info, found them by accident lol), but after changing to 60 FPS it worked just fine afterwards.
Mask of Destiny wrote:I think your perspective on this is colored by the specific ROMs you are trying to run. In general, 0.5.0 has been pretty extensively tested against the commercial library and high profile demos/homebrew. ROM-hacks have not been a priority for testing, but perhaps this demonstrates that was a mistake.
I guess thats a fair criticism, I did test out quite a few games though and most seemed to function well aside from minor issues (Some games seemed to lag a lot more than they actually do), but the issues seemed surprisingly major in the mentioned hacks. There is a few S3K hacks around (aside from basic layout mods might I add) that is worth testing to see if they have similar issues to what I was having... Generally, the problem with ROM hacks and hackers is that many do not have good access to hardware testing, and neglect to do this, not realizing how inaccurate all emulators we have really are, and how many things can go wrong. Therefore, I do not suggest testing just all the ROM hacks, but asking skilled hackers (Like Vladikcomper) what hacks are worth evaluating, because there are many technically well done hacks, but 10x more that are the opposite.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Fri Jun 09, 2017 10:03 pm
by King Of Chaos
Finally got some time to comment on this release! This emulator has really come a long way and is getting much better as time passes, great work! :D

> Do you mean drag and drop? Should be easy enough to add support for.

Yes, please.

> It really should only capture the mouse when there's an emulated mouse connected which won't be the case for the vast majority of games.

Double yes, please! I admit, this is kinda annoying sometimes... :x

> If that doesn't sound like it applies to the hacks in question, please post a link or send them to me so I can investigate.

Personally as long as Sonic 3 Complete works, I'd be happy. :D

> I take it you've never tried to run a Genesis/MD ROM in MAME/MESS then

This is enough to give a person nightmares. Try running ANYTHING in MAME/MESS, especially if you're a first time user. >.<

> I am working on a new UI that's not ROM-based (though that will stick around as an option), but since being gamepad friendly is important for me it still won't be drop-down menu driven like Fusion or Gens.

I admit, I'm lazy and like having menus like Gens, Kega and BizHawk. That (and Game Genie/Pro Action Replay support) are why I keep using Kega - though to be honest, I don't really use that many options in Kega, just set paths for BIOS, cheats, SRM, etc. and I don't use any render plugins or anything like that. Man, I wish I had a lot more time or else I'd dive head deep into learning how to do a UI via C++ or C# for an emulator to add this type of stuff (like BizHawk, but without the bloat and multiple systems). Oh well. :P But, I also admit now you've got me all curious about this gamepad friendly UI (since I use a gamepad mostly now).

Keep up the great work MoD - this is the emulator I'm following the most closely these days!

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Sat Jun 10, 2017 6:01 am
by Mask of Destiny
Natsumi wrote:Ah, seems like I have missed this. Personally I would save some settings file or something in registry on programs I make, to be smart about the last folder you used. Many programs do this but arent too smart about it generally. It would be good to see this implemented some day!
Hmm, maybe I can figure out a clean way for it to remember the last directory used if the initial_path setting hasn't been explicitly set by the user. Config settings aren't very discoverable so having more convenient default behavior is desirable. I'll think about it.
Natsumi wrote:Just for simplicity for the user and consistency, a button to do it would be preferrable than the emulator just doing it and the user may get confused with it. You could also add 2 modes where the user can decide between them, and then they at least know what they are selecting.
I think it won't be that big of a deal once I fix it capturing when it doesn't make any sense, but we'll see.
Natsumi wrote:
Mask of Destiny wrote:If that doesn't sound like it applies to the hacks in question, please post a link or send them to me so I can investigate.
I would be happy to, but these hacks are work-in-progress and are still really hush-hush, so I can't show them off.
I promise not to leak them if you sent it to me privately either via PM or email (pavone@retrodev.com). That said, I'll understand if you want to keep them under wraps.
Natsumi wrote:I was not able to find much help from the debugger, but honestly I did not try too much, it felt clunky to use for me.
It makes more sense if you're used to command line GDB, but I realize that's not most people. Once I get the "normal" functionality reasonably exposed via a non-ugly UI, I'll revisit making the CPU debugger less opaque.
Natsumi wrote:Now, I understand you want to make things work with gamepads, but if it means harder for mouse users, or developers, you aren't gonna get much support. Unless you can implement a menu system that is both easy for mouse users and gamepad users, I would suggest finding some ways to accommodate mouse only users, and gamepad only users.
Video game UI manages to accommodate both just fine. Debugging features might be harder to make gamepad friendly, but they don't really need to be.
Natsumi wrote:Gamepads reminds me, I had my USB controlled hooked on my computer from playing some other games few days ago, it would complain about every single button it has, not being mapped to anything. It would be fine, but there is a lot of them, so I ended up holding Enter to skip them quickly... Only for the emulator to exit and open 10 instances. I'll admit, its an user error, but surely you can find a better way to deal with it than complain about each button separately?
Ah, sorry about that. What's happening is that SDL2 doesn't have a mapping for your controller to translate from generic button numbers to "semantic" button names. You can fix that by using this tool to generate an SDL2 mapping entry and add it to gamecontrollerdb.txt. You're right that it should be consolidated into a single message in this case though.
Natsumi wrote:I had easier time using my arrow keys than my mouse for navigation.
Could you elaborate? I don't find the mouse to be particularly difficult to use in the existing menu.
Natsumi wrote:Also, I for some reason was able to change the FPS in the menu, only for the FPS to reset to 60 ingame. ...Only for it to go back to 200 in the menu.
Ah, that's because the menu is literally just a ROM and currently all the hotkeys that control emulation for a game also work for the menu. I should probably disable those when the menu is active. The speed reverted to normal once loading a game, because the game runs in a separate emulation context from the menu.
King of Chaos wrote:This emulator has really come a long way and is getting much better as time passes, great work! :D
Thanks!

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Sat Jun 10, 2017 8:00 am
by TmEE co.(TM)
The menu ROM seems to display the image with an offset (slightly to right, a lot towards bottom, OS mouse cursor shows the extend of the offsetting) :
Image

And when I run a ROM I get "Failed to lock texture: LockRect(): INVALIDCALL" message, after which things run without problem.

I can set the width to right pixel perfect size in conf but there seems to be no height setting. I'd like to have all of the active video visible in square pixels, currently I can only get perfect horizontal setting but not vertical. I suppose 50 and 60Hz need dedicated height settings, to prevent uneven line heights from stretching.

It would be nice if there was means to set a filename filter in the menu, so that it would show only files with BIN extension or other common ROM files.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Sat Jun 10, 2017 9:52 am
by Natsumi
Mask of Destiny wrote:Could you elaborate? I don't find the mouse to be particularly difficult to use in the existing menu.
The reason probably is that my mouse has a very varying DPI settings, and I usually use large DPI's. I've gotten used to it and it mostly works fine, I can move my mouse around much faster than normal mice, but the menu seems much more difficult to use with it. I've had success with it mind, but it feels like arrow keys are much more precise and a little faster way to control it still.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Sun Jun 11, 2017 11:19 am
by Stef
Seeing OD2 working almost perfectly is really outstanding :D Well done :)
I'm really forward using this emulator as my main development emulator along Exodus (which has some neat debugging features as the sprites boxes). I'm now trying to play with the integrated GDB debugging on windows and so far i can get GDB connecting but quickly i receive this message :
Command vKill;a410 is not implemented, exiting...
I'm using a recent GDB (7.12.1)...
I can't get GDB working on GensKMod neither (others errors) even with this brand new GDB version.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Mon Jun 12, 2017 6:22 pm
by Mask of Destiny
TmEE co.(TM) wrote:The menu ROM seems to display the image with an offset (slightly to right, a lot towards bottom, OS mouse cursor shows the extend of the offsetting) :
It seems I neglected to update the "absolute" mouse mode to take into account the configurable overscan. Thanks for reporting this.
TmEE co.(TM) wrote:And when I run a ROM I get "Failed to lock texture: LockRect(): INVALIDCALL" message, after which things run without problem.
So this is happening at the transition from menu to ROM? I had gotten a report of this, but the description was a bit vague and it wasn't happening for me. I think I know the problem now.
TmEE co.(TM) wrote:I can set the width to right pixel perfect size in conf but there seems to be no height setting. I'd like to have all of the active video visible in square pixels, currently I can only get perfect horizontal setting but not vertical.
Ah, that is indeed an oversight. You can set the height via command line, but only if you first specify both a ROM filename and width first. I really should make those proper option flags rather than positional arguments. Also note, that you will also need to set the aspect setting to either stretch or the proper pixel ratio to avoid letterboxing.
TmEE co.(TM) wrote:I suppose 50 and 60Hz need dedicated height settings, to prevent uneven line heights from stretching.
Worse, you would also need to have different settings for H40/H32. Seems like the cleanest way to give you what you want would be to have some kind of 1:1 pixel option that just uses a multiplier rather than specifying the specific resolution.
TmEE co.(TM) wrote:It would be nice if there was means to set a filename filter in the menu, so that it would show only files with BIN extension or other common ROM files.
Noted.
Natsumi wrote:The reason probably is that my mouse has a very varying DPI settings, and I usually use large DPI's. I've gotten used to it and it mostly works fine, I can move my mouse around much faster than normal mice, but the menu seems much more difficult to use with it.
Is the problem specifically that the emulated mouse cursor is not perfectly in sync with the host cursor?
Stef wrote:I'm now trying to play with the integrated GDB debugging on windows and so far i can get GDB connecting but quickly i receive this message :
Command vKill;a410 is not implemented, exiting...
I'm using a recent GDB (7.12.1)...
It's true that I haven't implemented the vKill command, but it's weird that GDB is trying to send it in this case. vKill is supposed to kill a process being debugged, which should only happen if you use the kill command or try to exit GDB. I assume you are on Windows. Are you using the Windows-specific directions or are you trying to use the pipe syntax to have GDB launch BlastEm?

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Mon Jun 12, 2017 6:42 pm
by TmEE co.(TM)
I have an extra tidbit about the offsetting problem. it seems to happen in 50Hz+interlacing, one of interlace mode demos produces same kind of shift of the image as the menu ROM.

1:1 pixel option with zoom is probably best way to go about it. Another interesting thing would be to option have blanking/sync area visible too, it would help making raster effects timing more nicer as you can get a visual representation of how much time your code takes etc. Completely useless for most people though.

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Mon Jun 12, 2017 7:26 pm
by Natsumi
I think its more about how small the menu items are combined at the faster speed which makes it difficult, as well as the next/prev buttons, those are kinda awkward honestly

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Mon Jun 12, 2017 8:05 pm
by Stef
Mask of Destiny wrote:It's true that I haven't implemented the vKill command, but it's weird that GDB is trying to send it in this case. vKill is supposed to kill a process being debugged, which should only happen if you use the kill command or try to exit GDB. I assume you are on Windows. Are you using the Windows-specific directions or are you trying to use the pipe syntax to have GDB launch BlastEm?
Weird, there is maybe an issue in my GDB configuration..
I first launch Blastem with the rom name and -D option then i connect GDB on it (target remote localhost:1234)

Then i got these log messages :
[debug]>>>>>>cb_gdb:
[debug]> target remote localhost:1234

[debug]determining executable automatically. Try using the "file" command.
[debug]Remote debugging using localhost:1234
[debug]0x00000200 in ?? ()
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> directory D:/apps/SGDK/sample/bench/

In ?? () ()

[debug]> directory D:/apps/SGDK/sample/bench/
[debug]Source directories searched: D:/apps/SGDK/sample/bench;$cdir;$cwd
[debug]>>>>>>cb_gdb:Source directories searched: D:/apps/SGDK/sample/bench;$cdir;$cwd
[debug]> target remote tcp:localhost:6868
[debug]>>>>>>cb_gdb:

Connected

[debug]> continue
I then obtain the error message on Blastem about vKill command and ending with these messages on GDB side :
[debug]Remote communication error. Target disconnected.: No error.
[debug]The program is not being run.
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:

The program is not being run.

[debug]> bt 30
[debug]No stack.
[debug]>>>>>>cb_gdb:
[debug]> quit

No stack.
Debugger finished with status 0

Re: Blastem 0.5.0 - Many accuracy improvements, basic SMS support, runs OD2

Posted: Mon Jun 12, 2017 9:45 pm
by Mask of Destiny
Stef wrote: Then i got these log messages :
[debug]>>>>>>cb_gdb:
[debug]> target remote localhost:1234

[debug]determining executable automatically. Try using the "file" command.
When you invoked gdb, did you pass it the name of the ELF file? The above snippet from the log seems to suggest that you didn't and it's trying to guess at the filename somehow.