BlastEm - Yet another Genesis emulator
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
That's a bug I know about and intend to fix. Essentially, the problem is that breakpoints are implemented by patching the native code, but the rest of the Z80 core doesn't really know about the breakpoints. So if the instruction needs to be retranslated, the patch gets overwritten. I'll try to get a fix in either in a point release or in 0.3.0 now that it's impacting someone other than me.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Tried to play with BlastEm and GDB today on win32 platform, i can't even make GDB to connect to BlastEm : connection refused where ever i launch it with -D parameter or not (when i launch with -D parameter BlastEm does not display the GUI).
I have to admit i hardly understand how we are supposed to make the connection, on GensKMod we just need to start the emulator then we can connect GDB at anytime which does not seem to be the case with BlastEm.
I have to admit i hardly understand how we are supposed to make the connection, on GensKMod we just need to start the emulator then we can connect GDB at anytime which does not seem to be the case with BlastEm.
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
Sorry to hear about your difficulties.
BlastEm does not listen for remote debugging connections unless -D is specified. When -D is specified, it will essentially freeze until a debug connection is made. The reason it works this way is that the GDB remote debugger support is mostly intended to work over a stdin/stdout using pipes. In this scenario, BlastEm is actually started by gdb itself and communication begins immediately. Unfortunately, this does not work under Windows due to the hard separation between GUI apps and command line apps. I added some socket-based remote debugging support, but it's really just the bare minimum to get it working. There is definitely room for improvement, but it probably won't be a high priority since it's mostly only useful on Windows.
Anyway, can you post the command you're using to start the remote debug session on the GDB side?
BlastEm does not listen for remote debugging connections unless -D is specified. When -D is specified, it will essentially freeze until a debug connection is made. The reason it works this way is that the GDB remote debugger support is mostly intended to work over a stdin/stdout using pipes. In this scenario, BlastEm is actually started by gdb itself and communication begins immediately. Unfortunately, this does not work under Windows due to the hard separation between GUI apps and command line apps. I added some socket-based remote debugging support, but it's really just the bare minimum to get it working. There is definitely room for improvement, but it probably won't be a high priority since it's mostly only useful on Windows.
Anyway, can you post the command you're using to start the remote debug session on the GDB side?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
No worries, actually i tried to set the command as you mentionned (with the pipe) but then i think that for some reason BlastEm did not load up the rom correctly. I saw that trying to load a rom from command line does not always work right, even when you are not doing GDB session. As soon you are not in the BlastEm folder i believe, i have to check that... that make GDB session quite complex to initiate :p
Anyway right now i believe my GDB version is not right, even with Gens KMod i have tons of issues, i believe Code::Blocks add others problems as well ! I understand that windows is not your priority, in the meantime i will probably check out for a better IDE / GDB version, that might help
Anyway right now i believe my GDB version is not right, even with Gens KMod i have tons of issues, i believe Code::Blocks add others problems as well ! I understand that windows is not your priority, in the meantime i will probably check out for a better IDE / GDB version, that might help
Re: BlastEm - Yet another Genesis emulator
Hello,
I'm facing a problem, the SGDK flash-save sample doesn't work with Blastem, does it supports SRAM saves ?
I just tested Sonic 3 and it works, but it is FRAM.
I'll contact Doragasu to know more about its plugin saveman.
Cheers
Edit: ok I misunderstood, saveman.h is not FRAM save, I gonna use sram.h from SGDK.
I'm facing a problem, the SGDK flash-save sample doesn't work with Blastem, does it supports SRAM saves ?
I just tested Sonic 3 and it works, but it is FRAM.
I'll contact Doragasu to know more about its plugin saveman.
Cheers
Edit: ok I misunderstood, saveman.h is not FRAM save, I gonna use sram.h from SGDK.
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
Re: BlastEm - Yet another Genesis emulator
Sounds like you already figured it out, but I'll answer anyway for posteritybioloid wrote: ↑Sun May 05, 2024 1:44 pmHello,
I'm facing a problem, the SGDK flash-save sample doesn't work with Blastem, does it supports SRAM saves ?
I just tested Sonic 3 and it works, but it is FRAM.
I'll contact Doragasu to know more about its plugin saveman.
Cheers
Edit: ok I misunderstood, saveman.h is not FRAM save, I gonna use sram.h from SGDK.
I believe SGDK flash-save is for using a block of the NOR flash your game is present on for saves. I have some limited support for NOR flash emulation in BlastEm, but enabling it requires a ROM DB entry and I don't know offhand if it's compatible with the flash-save extension in SGDK.