GTK+ 1.2 is extremely outdated and no longer included in most
distributions. By removing support for it we can replace old
UI elements with more modern ones.
By default, without providing `with-sdl2` in configure it uses SDL1.
Users need to explicitly request SDL2.
Signed-off-by: Ricky Zhang <rickyzhang@gmail.com>
1. Change --break input option format. Too much typing by taking decimal address. Change to hexadecimal input.
2. Allow ROM break point to continue to execution. The original ROM break point just replace instruction in ROM break point address with emul_op M68K_EMUL_BREAK. This just halts emulation right at the break point. The patch is less invasive than the original approach. It allows emulation to continue to run by pressing 'x' to exit from cxmon.
3. Add option --loadbreak which load break point from file before emulation start.
Signed-off-by: Ricky Zhang <rickyzhang@gmail.com>
This change may end up being a bit slower on some systems, as the SDL backend will now render its content to two, new, SDL_Surfaces: one of which is in the guest OS' resolution, the other of which is application defined.
SDL2's SDL_Render API is used, which exposes some rudimentary elements of GPU + texture-based programming. Basilisk II now maintains a single 'SDL_Texture' object, which is an SDL representation of a GPU texture. The 'outer' surface will be used to update this texture, as requests to redraw are made.
TODO: look into removing the 'outer' SDL surface, and see if we can just copy the 'inner' surface to the SDL_Texture.
TODO: the entire SDL_Texture is updated, any time a request is made to draw. Look into minimizing this a bit.
SDL 1.x is used for display, rather than Mac OS X specific backend. If time permits, I'll port it to SDL 2, if only to reduce Basilisk's overall code foot-print.
Lots of features are apt to be disabled, as many 'dummy' backends were used.
Video-depths other than 1-bit or 32-bit are untested, and in some cases (4-bit, at least) are currently non-functional. This is due to a partial re-write of the SDL backend's blitting code, which was non-functional when low-bit-depths were used.
The SDL backend was also rewired, on OSX, to not attempt to align the display buffer on page-boundaries. So far, this doesn't seem to cause any notice-able problems, however, that's only using limited knowledge and testing (System 7.5.x does boot and display at 640x480, though!). The original display-buffer allocation code was failing to run, in some cases.
Preferences are, on Mac, currently hardcoded to be accessed at /tmp/BasiliskII/BasiliskII_Prefs. The folder, "/tmp/BasiliskII/", may be a symbolic link to elsewhere, though.
| This patch fix a compiler warning about the direct printing of strings
| using formatted printing functions without the use of a format string.
|Author: Giulio Paci <giuliopaci@gmail.com>
|Forwarded: no
|Last-Update: 2012-03-04
Rather, use an address override prefix (0x67) though Intel Core optimization
reference guide says to avoid LCP prefixes. In practise, impact on performance
is measurably marginal on e.g. Speedometer tests.
STANDALONE_GUI. This is the second step towards a more interesting GUI alike
to VMware. Communication from/to the GUI is held by some lightweight RPC.
Note: The step should be enough to provide a tiny GTK GUI for MacOS X.
addressing in REAL_ADDRESSING mode. Only support platforms with proper
linker scripts to map the whole Mac memory from address 0. Warning fix.
NOTE: when compiled with --enable-addressing=real on Linux {x86,x86_64},
you can not address up to 1.5 GB in Basilisk II.
interrupt in one_tick() if no pthreads at all are used, i.e. ether_dummy
is effective in that case. Otherwise, don't trigger ethernet again if
pthreads are available (and ether_unix) and cpu emul services are active.
suddenly allocated below RAM and thus not working. Besides, this may fix a
latent deallocation bug in real addressing mode (i.e. release the whole
block allocated at once, not separately).
Side effect: this makes Basilisk II work in direct addressing mode with JIT
on Darwin 8.0.1 for x86.
