everything about the installation path. There should be no more
hardcoded references to /usr/local/bochs. Instead, there are
references to @prefix@ which get replaced by the configure script
with the real prefix.
user's home directory the first time they run bochs-dlx and runs it
from there. This avoids the need for a world-writable directory installed
by the RPM.
I don't have to list them, and also apparantly fixes a mysterious problem
which occurred when Anders Nielsen was trying to build the RPM for
PPC: his rpm appears to gzip the man pages automatically, and then
complains that /usr/man/man1/bochs.1 is not found!
- start using autoconf/configure's standard of prefix, exec_prefix, bindir,
mandir to control where make install puts things
- added script install-x11-fonts
- make install no longer tries to install DLXlinux (since not everyone will
want it). Now you must do make install_dlx if you want it.
- renamed erase_install to uninstall
- in RPM spec file:
- run .conf.linux instead of .conf.linux-x86. This is just a name change.
- build directory hierarchy in the buildroot
- patch up broken symbolic links in buildroot (ugly)
- run font install script in %post
- clean up dlxlinux directory in %preun to avoid warning about not
removing /usr/local/bochs/dlxlinux/bochsout.txt
- remove /usr/local/bochs if nothing left in it
in BRANCH-smp-bochs revisions.
- The general task was to make multiple CPU's which communicate
through their APICs. So instead of BX_CPU and BX_MEM, we now have
BX_CPU(x) and BX_MEM(y). For an SMP simulation you have several
processors in a shared memory space, so there might be processors
BX_CPU(0..3) but only one memory space BX_MEM(0). For cosimulation,
you could have BX_CPU(0) with BX_MEM(0), then BX_CPU(1) with
BX_MEM(1). WARNING: Cosimulation is almost certainly broken by the
SMP changes.
- to simulate multiple CPUs, you have to give each CPU time to execute
in turn. This is currently implemented using debugger guards. The
cpu loop steps one CPU for a few instructions, then steps the
next CPU for a few instructions, etc.
- there is some limited support in the debugger for two CPUs, for
example printing information from each CPU when single stepping.
