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.
On those systems, it's really hard to get high resolution timings and the
system oftens fails to honour a timeout in less than 20 ms. The idea here
is to have an average m68k instruction count (countdown quantum) that
triggers real interrupt checks. The quantum is calibrated every 10 ticks
and has a 1000 Hz resolution on average.
problems on big endian systems. IOW, Basilisk II can hang there. I also
noticed that on Linux/ppc so that's probably not MacOS X specific, assuming
the same problem. ==> A packet arrives but Basilisk II can't seem to trigger
an interrupt (need to try sheep_net/tun in linux to make sure)
that that kernel module must be loaded and IP forwarding enabled. Also add
slight improvements to the "tunconfig" script so that sudo /sbin/ifconfig
and sudo /sbin/iptables are really supported for current user if not root.
- Enable VidMode extension with FBDev DGA graphics.
- Factor out FBDev/XF86 DGA code.
- Fix pointer grab in fbdev DGA mode, thus fixing scrolling screens in
lower VidModes.
- Only select VidModes that match the requested resolutions, exactly.
- Fix VideoQuitFullScreen() in non FBDev mode.
fullscreen mode when VidMode extension is enabled. Also fix SDL fullscreen
to really update the screen as this is necessary by default on Linux since
simple windowed is used (and not DGA for fullscreen).
Always prefer the 64 pixel chunks update code.
Rearrange B2 video_x.cpp to match video_vosf.h updates
from regs & fpu members + code cache. This is possible because data is
allocated in 32-bit space and we force allocation of translation cache to
those bounds too.
instructions in long mode (64-bit). However, there seems to be another bug
in the JIT preventing it from being fully supported. m68k.h & codegen_x86.h
are easily fixed bug another patch is still needed.
