BlastEm - Yet another Genesis emulator

Talk about development tools here

Moderator: BigEvilCorporation

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Post by doragasu » Fri Mar 14, 2014 8:30 am

I'm trying to build v0.2.0 (6b7a96d0eda8) under 64-bit ArchLinux without success. It spits this error at first:

Code: Select all

stateview.c: In function 'main':
stateview.c:89:2: error: too few arguments to function 'render_init'
  render_init(width, height, "GST State Viewer", 60, 0);
  ^
In file included from stateview.c:9:0:
render.h:22:6: note: declared here
 void render_init(int width, int height, char * title, uint32_t fps, uint8_t fullscreen, uint8_t use_gl);
      ^
Makefile:75: recipe for target 'stateview.o' failed
make: *** [stateview.o] Error 1
I worked around it by editing stateview.c and adding a trailing ",0" to the render_init() call. Then stateview compiles, but linking fails:

Code: Select all

cc -o stateview stateview.o vdp.o render_sdl.o config.o tern.o util.o gst.o -lm `pkg-config --libs sdl glew gl`
vdp.o: In function `init_vdp_context':
vdp.c:(.text+0x7b): undefined reference to `headless'
collect2: error: ld returned 1 exit status
Makefile:54: recipe for target 'stateview' failed
make: *** [stateview] Error 1
Located "headless" as an integer variable defined in blastem.c, so I tried adding blastem.o as a dependency to the stateview target in the Makefile, and also added it to the inputs for the linking stage, just to get a whole lot of redefinition errors:

Code: Select all

cc -o stateview stateview.o vdp.o render_sdl.o config.o tern.o util.o gst.o blastem.o -lm `pkg-config --libs sdl glew gl`
blastem.o: In function `read_dma_value':
blastem.c:(.text+0x4c0): multiple definition of `read_dma_value'
stateview.o:stateview.c:(.text+0x0): first defined here
blastem.o:(.data+0x8): multiple definition of `reset'
stateview.o:(.data+0x0): first defined here
blastem.o:(.bss+0xa): multiple definition of `busreq'
stateview.o:(.bss+0x0): first defined here
blastem.o: In function `main':
blastem.c:(.text.startup+0x0): multiple definition of `main'
stateview.o:stateview.c:(.text.startup+0x0): first defined here
blastem.o: In function `sync_z80':
blastem.c:(.text+0x657): undefined reference to `z80_run'
blastem.c:(.text+0x679): undefined reference to `z80_reset'
blastem.o: In function `sync_sound':
blastem.c:(.text+0x6b9): undefined reference to `psg_run'
blastem.c:(.text+0x6c5): undefined reference to `ym_run'
blastem.c:(.text+0x6e4): undefined reference to `psg_run'
blastem.o: In function `io_write':
blastem.c:(.text+0x96c): undefined reference to `io_data_write'
blastem.c:(.text+0x984): undefined reference to `io_data_write'
blastem.c:(.text+0x99c): undefined reference to `io_data_write'
blastem.c:(.text+0xa96): undefined reference to `z80_handle_code_write'
blastem.o: In function `sync_components':
blastem.c:(.text+0xe40): undefined reference to `io_adjust_cycles'
blastem.c:(.text+0xe63): undefined reference to `io_adjust_cycles'
blastem.c:(.text+0xe86): undefined reference to `io_adjust_cycles'
blastem.c:(.text+0x1021): undefined reference to `debugger'
blastem.o: In function `vdp_port_write':
blastem.c:(.text+0x1290): undefined reference to `psg_write'
blastem.o: In function `z80_vdp_port_write':
blastem.c:(.text+0x148c): undefined reference to `psg_write'
blastem.o: In function `set_speed_percent':
blastem.c:(.text+0x1672): undefined reference to `ym_adjust_master_clock'
blastem.o: In function `init_run_cpu':
blastem.c:(.text+0x1705): undefined reference to `init_x86_68k_opts'
blastem.c:(.text+0x171c): undefined reference to `init_68k_context'
blastem.c:(.text+0x17aa): undefined reference to `translate_m68k_stream'
blastem.c:(.text+0x17e7): undefined reference to `insert_breakpoint'
blastem.c:(.text+0x1806): undefined reference to `z80_get_native_address_trans'
blastem.c:(.text+0x1814): undefined reference to `start_68k_context'
blastem.c:(.text+0x183f): undefined reference to `insert_breakpoint'
blastem.c:(.text+0x1847): undefined reference to `m68k_reset'
blastem.o: In function `sync_sound':
blastem.c:(.text+0x6f4): undefined reference to `ym_run'
blastem.o: In function `io_read':
blastem.c:(.text+0xc0f): undefined reference to `ym_read_status'
blastem.c:(.text+0xc99): undefined reference to `io_data_read'
blastem.c:(.text+0xca9): undefined reference to `io_data_read'
blastem.c:(.text+0xcb9): undefined reference to `io_data_read'
blastem.o: In function `z80_read_ym':
blastem.c:(.text+0x1600): undefined reference to `ym_read_status'
blastem.o: In function `set_speed_percent':
blastem.c:(.text+0x167f): undefined reference to `psg_adjust_master_clock'
blastem.o: In function `main':
blastem.c:(.text.startup+0x23d): undefined reference to `ym_init'
blastem.c:(.text.startup+0x272): undefined reference to `psg_init'
blastem.c:(.text.startup+0x27c): undefined reference to `init_x86_z80_opts'
blastem.c:(.text.startup+0x296): undefined reference to `init_z80_context'
blastem.c:(.text.startup+0x3a4): undefined reference to `set_keybindings'
blastem.c:(.text.startup+0x40c): undefined reference to `debugger'
blastem.c:(.text.startup+0x52a): undefined reference to `gdb_remote_init'
blastem.c:(.text.startup+0x533): undefined reference to `gdb_debug_enter'
collect2: error: ld returned 1 exit status
Makefile:54: recipe for target 'stateview' failed
make: *** [stateview] Error 1
BTW, blastem target builds and runs fine. Do I need to build stateview or any other target to get GDB remote debugging support? Any suggestions on how to do it?

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Fri Mar 14, 2014 5:30 pm

stateview is just a save state viewer. It's mostly there to let me debug VDP rendering issues independently of everything else. blastem is the only target you need for playing or debugging games.

Sorry for your trouble. I should have either fixed the breakage in stateview or updated the all target before the release.

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Post by doragasu » Fri Mar 14, 2014 6:13 pm

Thanks for the quick reply. I hope I can get some time to try setting up the debugger!

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Post by doragasu » Sat Mar 15, 2014 7:35 pm

I have built m68k-elf-gdb and I have integrated it with Code::Blocks IDE. It works with BlastEm!, but I have some problems.

I have opened a new thread to deal with these problems here.

bgvanbur
Interested
Posts: 46
Joined: Fri Jun 22, 2012 11:13 pm

Post by bgvanbur » Mon Mar 31, 2014 9:37 pm

Blastem is great. I couldn't use the prebuilt binaries but was able to build blastem executable. I really wish instead of n/o/s debugger commands there was one that ran just one 68k instruction even in the case of an interrupt and such. And maybe eventually I would really like to see gst saving/loading from the debugger command line too.

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Mon Mar 31, 2014 10:17 pm

bgvanbur wrote:Blastem is great. I couldn't use the prebuilt binaries but was able to build blastem executable.
Out of curiosity, what OS/distro are you using? I'm probably not going to put a lot of effort into more portable binaries until BlastEm is a bit more mature, but it would be good to know where the existing ones are broken.
bgvanbur wrote:I really wish instead of n/o/s debugger commands there was one that ran just one 68k instruction even in the case of an interrupt and such.
I think it might make sense to make 's' behave that way. Alternatively I suppose I could create a 4th step command, but that seems a bit much. Anyway, this should be doable it just takes a bit of extra work due to the nature of my CPU cores.
bgvanbur wrote:And maybe eventually I would really like to see gst saving/loading from the debugger command line too.
Saving should be quite easy. Loading is a bit more work, but the hard part is allowing save states to be loaded while the cores are running which I need to deal with eventually anyway. I'll try to get these in for the next release.

Stef
Very interested
Posts: 3058
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Mar 31, 2014 11:34 pm

At least i tried to compile it for windows (32 bit) here but i still obtains many unresolved link stuff... I will try to dig into that later but it would be pretty nice to have a mingw makefile for instance :)

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Mon Mar 31, 2014 11:48 pm

My general thinking is that the theme of v0.3.0 will be "BlastEm Everywhere". A big part of that is getting the emulator to work on ARM and 32-bit x86 CPUs. Porting to Windows is also part of that plan. I was going to do that after the CPU porting stuff was done, but I've taken a break on that to work on other projects. I suppose I could take a stab at getting this working on Windows tonight.

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Post by doragasu » Tue Apr 01, 2014 6:34 am

Great news you continue improving BlastEm!

Are you planning to, at some point, add capabilities to display VRAM tiles, backgrounds and sprites?

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Tue Apr 01, 2014 6:59 am

Well Stef ... I have good news and I have bad news. The good news is that I was able to produce a Windows build of blastem. The bad news is that neither the builtin debugger or the GDB remote debugging support will work due to the hard separation between command line and GUI apps on Windows. These are solvable problems, but I don't have any more time to work on it tonight. Also note that this is a 32-bit build and I haven't finished the 32-bit x86 support in the Z80 core yet so the Z80 is completely disabled.
doragasu wrote:Are you planning to, at some point, add capabilities to display VRAM tiles, backgrounds and sprites?
I used to have VRAM tile viewing support and I plan to put it back in when I get the chance (possibly in 0.3.0, but no promises). When you say backgrounds and sprites do you mean a way to tell the source of a particular pixel (which is present currently), a way to disable certain layers or a separate debugger window that would render each layer individually? I'm generally open to adding any debugging feature that people want as long as I can do it without having a major performance impact when the debugging feature is not enabled. All of those options seem doable, but some are more work than others.

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Post by doragasu » Tue Apr 01, 2014 7:21 am

It would be nice having a separate window that lets you watch an entire background (or several backgrounds with enable/disable buttons). But if this is too much trouble to implement, just adding some shortcuts to enable/disable backgrounds (A, B, Window) and also the sprite layer would do the trick.

Other nice additions to help debugging could be adding a window showing the sprite list, and another window showing VDP registers (the same way GensKMod does).

Stef
Very interested
Posts: 3058
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Tue Apr 01, 2014 9:11 am

Mask of Destiny wrote:Well Stef ... I have good news and I have bad news. The good news is that I was able to produce a Windows build of blastem. The bad news is that neither the builtin debugger or the GDB remote debugging support will work due to the hard separation between command line and GUI apps on Windows. These are solvable problems, but I don't have any more time to work on it tonight. Also note that this is a 32-bit build and I haven't finished the 32-bit x86 support in the Z80 core yet so the Z80 is completely disabled.
Thanks for taking sometime in that :)
I saw your Z80 core is not yet ready for x86-32 support (you use x64 registers for emulation i believe). Do you plan to eventually add support for that in future ? Also the point which interest me the most is the GDB remote debugging feature so i really hope that is something that will be supported later ! In the meantime i will play a bit with the current win32 build to finally see this emulator in action :)

bgvanbur
Interested
Posts: 46
Joined: Fri Jun 22, 2012 11:13 pm

Post by bgvanbur » Tue Apr 01, 2014 12:48 pm

I am using RHEL 6.4. By default it uses older (stable) libraries which causes issues to try to use most prepackaged binaries.

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Tue Apr 01, 2014 6:41 pm

Stef wrote:I saw your Z80 core is not yet ready for x86-32 support (you use x64 registers for emulation i believe). Do you plan to eventually add support for that in future ?
Both cores actually use the extra registers in x64 mode. I started with the 68K core both because it's more important and because there was less hand-written assembly that needed to be generated instead so it could respect the register map configuration. I'll finish the work on the Z80 core before I release 0.3.0.
Stef wrote:Also the point which interest me the most is the GDB remote debugging feature so i really hope that is something that will be supported later !
It shouldn't be too hard to adapt the remote debugging support to use a socket when on Windows. I might even take a stab at that tonight. It might be a while before the builtin debugger makes it to Windows, but that's not terribly relevant if you're using SGDK anyway.

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Wed Apr 02, 2014 5:18 am

Here's a new preview build for Windows. It's a bit less half-assed than the old one. The biggest changes are that it supports OpenGL rendering and GDB remote debugging happens over a socket on port 1234. So to start remote debugging, you first start the emulator with the -D flag and then you run 'target remote :1234' inside gdb. I haven't tested this build on an actual Windows machine (only Wine), but the last one worked on the real deal so I'm not too worried about this one.

Post Reply