This is a developer/debugger-enabled build of BigPEmu. You shouldn't use this build unless you require these development features, as it's otherwise slower and may exhibit functional issues.

See the standard ReadMe.txt file for information on the emulator, version changes, etc.

If BigPEmu is helping you develop software, please think about the number of labor hours you've saved with it. Then think about what all that labor is worth in your native currency, and if you aren't already a patron, please consider kicking over a tiny fraction of those labor savings!
https://www.patreon.com/richwhitehouse

You'll find various developer options in the in-application "developer" menu in this build, but accessing most of the development features requires connecting the Noesis debugger.

The latest version of Noesis can be downloaded here:
https://richwhitehouse.com/index.php?content=inc_projects.php&showproject=91

The latest BigPEmu developer build can be downloaded here:
https://richwhitehouse.com/jaguar/index.php?content=download

Make sure you're using the latest versions of both BigPEmu and Noesis. Failure to update one or the other may cause problems or protocol mismatches.

In order to connect the Noesis debugger, first launch the BigPEmu developer build and load some software. Then in Noesis, launch the Universal Debugger under the Tools menu. The default connection options in the Universal Debugger interface should be correct as long as you're running Noesis and BigPEmu on the same machine, so hit the Connect button, and it should be successful. From here, it's up to you to explore the debugging options. If you aren't familiar with debuggers in general, you'll have a lot of learning to do.

Here's a list of known quirks/issues in the developer build (meaning, don't bug me about these things, I'm aware):

- You may occasionally need to hit "Go" in the disassembler window to refresh code when it changes underneath the client (as is common with GPU/DSP code), depending on whether it's in a cached window.
- Step-in/out/etc. operations are just treated as single-step operations, as the host doesn't implement them.
- JRISC disassembly doesn't match established assembler convention in a number of cases. I may take a pass over this at some point, but in general it shouldn't be tough to understand the differences.
- GPU/DSP trace functionality is pretty barebones and hasn't been tested too thoroughly. I only used it for finding hotspots during development. But it probably still works well enough.
- You can inspect various system registers through the memory view at the appropriate addresses, just as you'd read the registers on a real Jaguar. The debugger operates through a "special" bus read/write path in the emulator. However, this may not be sufficient to reveal all of the internal register state that you'd like. Some special commands (e.g. "blitstate") exist to examine more component-specific state, but I'm aware that more commands (e.g. some to cover Tom registers) would probably be useful.
- The host listen port is currently hardcoded to the debugger protocol's default, 44123. Sorry if this conflicts with something on your system/network!
- If you're a developer and you want symbols, you'll want to make sure you have a development option for your project to target COFF files and load those up directly in the emulator. This is the only reasonable option that most of the existing Jaguar toolchains offer to generate symbol data. (aln/rln -m just spews to stdio, and the data it generates is incomplete)
- Symbols are displayed in the disassembly view, and a separate client window allows you to search through symbols and navigate directly to the associated memory or disassembly. However, symbols aren't currently resolved from addresses in the disassembly itself.
- There may be some very slight latency when single-stepping due to protocol/client nonsense, I need to take a look at exactly what's going on there at some point.
- I'm guessing there will be lots of requests for bug fixes and feature additions once people start using this thing. I'll try to field them as possible, but keep in mind I'll be moving on to focus on more emulator features (and possibly other projects) now that debugger-enabled builds are at least functional.

Here's a video which demonstrates most of the debugger's basic features: https://www.youtube.com/watch?v=S_RvqVq6N-U

Love,
Rich
