- This change introduces a full refactor of the interrupt subsystem
for the system board (SBD) and the I/O bus (CIO). Interrupt decode
should now be significantly faster, and not require an expensive
calculation on every step.
- The TIMER device has been split into Rev 2 and Rev 3
implementations.
- The optional 3B2/400 Debug Monitor ROMs can now be booted by passing
the "DEMON" argument to the 3B2/400 simulator BOOT command. Any
of the following will cause the Debug Monitor ROM to be booted
instead of the standard 3B2/400 ROM:
sim> BOOT DEMON
sim> BOOT CPU DEMON
sim> BOOT DEMON CPU
Refactor in preparation for the addition of a Rev 3 simulator for the
3B2/1000 system.
This change also includes a full cleanup of the rat's-nest of includes
and externs that plagued the 3B2 simulator and made it difficult to
understand and maintain. Headers are now required in the following
order:
compilation unit -> "3b2_defs.h" -> {... dependencies ...}
Finally, HELP has been added to the CPU device.
This change adds support for the WE32106 Math Acceleration Unit (MAU).
The WE32106 is an IEEE-754 1985 compatible floating point math
acceleration unit that was an optional component on the 3B2/310 and
3B2/400.
The MAU is implemented using software floating point routines. As
always, there may be bugs, but the MAU currently passes extensive
floating point tests with exactly the same results as a real 3B2/400
equipped with a physical MAU, so I hope these are few.
This change cleans up warnings issued when compiled with
-Wall.
- Removed unused functions and variables.
- Moved static declarations out of headers and into source files
- Added braces around initialization where suggested.
- Add "SHOW STACK" support to CPU
- An off-by-one error in checking SDT length was fixed.
- not-present co-processor R/W should not set Bus timeout bit
Two critical issues are fixed with this commit:
1. The MMU cache was being corrupted by writing the 'Last Used'
bit into the wrong half of the PD cache (low word vs. high word)
2. The MMU cache was being too aggressively flushed on SRAMA
write, because the wrong length was being used. In addition,
the code was walking off the end of the cache array when
flushing any section other than section 0, potentially causing
memory corruption.
