an fpos_t, use ftell which returns an int. Without the patch,
Bochs gets an fpos_t and assumes it is an integer type, but
on some systems (like linux with newer glibc libraries) this
assumption is wrong. Malte Cornils <malte@cornils.net> first
reported this bug, and he warned me that ftell may not be portable
to some platforms which treat binary and ascii streams differently.
I haven't found any alternative yet.
- now the HALT macro in rombios.c writes to panic port but does not actually
execute a "hlt" instruction. This allows the .bochsrc to control
whether the BIOS panic is fatal or not.
To see the commit logs for this use either cvsweb or
cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files.
In general this provides a generic interface for logging.
logfunctions:: is a class that is inherited by some classes, and also
. allocated as a standalone global called 'genlog'. All logging uses
. one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this
. class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros
. respectively.
.
. An example usage:
. BX_INFO(("Hello, World!\n"));
iofunctions:: is a class that is allocated once by default, and assigned
as the iofunction of each logfunctions instance. It is this class that
maintains the file descriptor and other output related code, at this
point using vfprintf(). At some future point, someone may choose to
write a gui 'console' for bochs to which messages would be redirected
simply by assigning a different iofunction class to the various logfunctions
objects.
More cleanup is coming, but this works for now. If you want to see alot
of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1.
Comments, bugs, flames, to me: todd@fries.net
- made the code that fills 0x1b-0x23 for diskc conditional on diskc being
present; this was probably not necessary.
- added some code (still commented out) that will help in supporting a second
IDE interface.
Basicly what it does is, it help VGA16 find the syncing, because of the
technique it uses, bochs did not help it figure out the timing diffrences
with its one size fits all timing.
The 82c54 model (pit.cc) implements timer modes 0, 2, and 3 in its handler
functions, without caring which timer number is involved. However, the
I/O write code that sets the mode is inconsistent.
Timer 0 can be set to modes 0,2,3 only.
Timer 1 can be set to mode 2 only.
Timer 2 can be set to mode 2,3 only.
From a quick reading of an 8254 datasheet, I can't see any reason to
restrict which timer can be in which mode, so I think it's correct to
allow ALL timers to go into ALL modes that are implemented.
