At this time:
- The ZAP command exists to remove meta data from containers that
have it. Container files processed by the ZAP command will generally
be restored to the size it was before the addition of the meta data
and the file time stamps will be unchanged.
- Newly created containers get meta data.
- At attach time, containers that don't have meta data, but have
recognized file systems that fit within the drive it is being
attached to get meta data added without changing the file timestamps.
- Containers that don't have meta data and don't have a recognized
file system that is <= the drive size are attached without comment
and without adding meta data as long as the drive is NOT set to
autosize (controllers that support multiple drive types all default to
autosize, which can explicitly be disabled on a drive by drive basis).
- Containers that don't have meta data which are > the drive size can
only be attached read only.
- Containers with meta data can not be attached to a different
controller at all if the container size is smaller than the drive on the
other controller.
- Containers that have meta data can be freely be attached to the
controller that they were attached to when they got the meta data.
If a file system is detected, it will be reported. Otherwise if no
recognized file system is found, the attach will be silent. File
system detection reporting can be suppressed with -Q on the attach
command.
- Containers with meta data can only be attached read only to a different
controller if the container is larger than the drive it is being
attached to.
In the future:
- In general, containers with meta data (or recognized file systems)
will be attachable to MSCP and SCSI controllers, as long as reasonable
sector sizes and file system not requiring interleaving have been found.
- Containers without meta data will only be attachable if autosize
is disabled and the container is <= the size of the drive.
- Explicitly setting a drive type on a unit will implicitly disable
autosizing. If a user wants to set the default drive for a unit
and still allow autosizing they must explicitly set the unit to
autosize after setting the drive type.
Relevant to: #1065, #1059, #1094, #1100, #1118, #1117
- 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
This change introduces initial support for the AT&T 3B2 Rev 3 platform, based
around the WE32200 CPU with up to 64MB of RAM and SCSI disk and tape support.
This simulator is experimental and not yet supported. It will not be built by
default, but can be built with:
make 3b2-600
Or by using the 3B2-600 Windows Visual Studio project.
This change lays the groundwork for adding support for Rev 3 3B2 models,
which includes the Model 500, Model 600, and Model 1000.
Rather than use the fixed strings "400" and "1000" in file names, the
strings "rev2" and "rev3" will be used, which allows greater flexibility
to implement various system configurations more easily.
Additionally, this change adds a copy of the Debug Monitor (DEMON) ROM
image for the Rev 2 board, to be used soon in a later checkin.
Custom TTL design by Marvin Minsky. There are two displays: one
raster scan for bitmapped characters, and another random scan for
vector graphics. There is also a keyboard, and a UART for talking
to a host computer.
The computer is normally booted off a ROM which reads and starts a
secondary loader from the UART. The loader is responsible for reading
the payload, which comes in checksummed blocks. The LOAD command
accepts files in same format.
This commit adds a "PMMI" device to the AltairZ80 VM that emulates
the PMMI Communications MM-103 MODEM & Communications Adapter.
This device was added at the request of a Facebook user that is
attempting to preserve and document various relevant communications
programs for CP/M and allow users to experience communicating and
sharing information with other remote computers of the same time
period, all on modern hardware.
This device attempts to emulate the MC6860L digital modem chip in
such a way that communications software written for the PMMI MM-103 can
communicate over a serial port or socket without a phone line or
the ability to MOdulate/DEModulate data over a phone line.
This commit adds two new devices, "M2SIO0" and "M2SIO1", to the AltairZ80
VM. These two independent devices emulate "raw" 88-2SIO ports that can
be used instead of the "SIO" device for attaching socket and serial
ports using TMXR.
- Avoid building a published version with uncommitted files in the
working directory
- Confirm existence of remote named origin and fetch master branch
- Add automatic force to push remote Win32-Development-Binaries
repo when resetting the binary directory
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.
Similar to the build_ming.bat procedure which will invoke MinGW to
biuild siimulators, this procedure will rebuild all of SIMH simulators using
Visual Studio.
If this procedure is not invoked from a Developer Command Prompt
then the VS2008 tools are preferred if VS2008 is installed,
otherwise the installed Visual Studio tools will be used
prefering newer Visual Studio versions over older ones.
If this procedure is invoked from a Developer Command Prompt
then the tool chain provided with the command prompt is used
to build the simh projects.
A single argument to this procedure may be the word Debug, which
will cause Debug binaries to be build rather than the Release
binaries which is the default.
