SpritesMind.Net

Posted: **Thu Feb 13, 2014 10:32 pm**

I like this emulator, well done; it works great on NetBSD amd64.
I wish you good luck with this!

Posted: **Thu Feb 13, 2014 10:37 pm**

Really cool news ! I will try to build a windows version to test it

Posted: **Thu Feb 13, 2014 11:04 pm**

tails92 wrote:I like this emulator, well done; it works great on NetBSD amd64.

Glad to hear it!. You might run into some small problems as I'm using /proc to find some files relative to the executable. I'll try to improve this in the next release.

tails92 wrote:I wish you good luck with this!

Thanks!

Stef wrote:I will try to build a windows version to test it

You might be able to build it in Cygwin. Most of the emulator depends on portable libraries, but there's a bit of POSIX in a few places. The messiest is the use of sbrk to allocate memory in the low 4GB of the address space (x86-64 call only supports 32-bit immediate offsets so calling my C code from the generated code is a PITA unless I keep the generated code at a reasonably low address). I'll probably try to make a proper Windows build for 0.3.0, but no promises.

Posted: **Fri Feb 14, 2014 11:35 am**

Mask of Destiny wrote:Glad to hear it!. You might run into some small problems as I'm using /proc to find some files relative to the executable. I'll try to improve this in the next release.

There are no problems, actually, because NetBSD has had support for the Linux-style /proc filesystem and mounts it by default since a while, and while it is not completely compatible, most basic features work. /proc/self/exe that BlastEm uses is an example of that.
But yes, it is most probably not in the POSIX standard (I didn't check, though).

Posted: **Fri Feb 14, 2014 7:43 pm**

This might be completely off the rails to ask, but is there a possibility we could get an "active disassembly" feature like Exodus? Or basically just the ability to output an idc script for separating code/data.

Posted: **Fri Feb 14, 2014 8:02 pm**

It isn't as fancy as a proper active disassembler, but the -l flag will cause BlastEm to produce a file called address.log which logs all addresses at which translation is started in the 68K core. The bundled disassembler can use this file to disassemble all code that was reached during execution. Generally you'll want to invoke the disassembler like this when you have an address.log file:

./dis -l -f address.log ROM.BIN

The -l flag causes the disassembler to produce labels rather than just print the address in front of each instruction and the -f flag directs it to read from a file containing addresses to start at. Currently any binary data between code chunks is just omitted and the mnemonics may be a little weird in some places as I generally only use it to figure out what a game is doing rather than to try and make something I can run through an assembler.

Improving the disassembler isn't a particularly high priority at the moment. Generally speaking I only work on it when I find it insufficient for solving problems elsewhere but I'm definitely open to requests in that area.

Posted: **Sat Feb 15, 2014 10:00 pm**

Oh cool. That should still be helpful regardless as a "road map" to use for disassembling in IDA. Thanks!

edit: actually, it will be easy to convert the addresses from address.log into MakeCode(); statements for an idc script. This will work nicely!

Posted: **Mon Feb 17, 2014 11:49 am**

Great news!!!

I NEED to get some time to test this, GDB support is something I've been awaiting for a long time. Too bad I'm extremely busy ATM.

Posted: **Mon Feb 17, 2014 9:42 pm**

powerofrecall wrote:edit: actually, it will be easy to convert the addresses from address.log into MakeCode(); statements for an idc script. This will work nicely!

Glad that worked out for you. Let me know if there's any other runtime metadata that would be useful with IDA and I'll consider adding support for it in a future release.

Posted: **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?

Posted: **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.

Posted: **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!

Posted: **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.

Posted: **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.

Posted: **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.

SpritesMind.Net

BlastEm - Yet another Genesis emulator