Core Devices
- Copy Page Tree
- W.Erber
- Bruno Miretti (Deactivated)
- Kirill Nikolaev (Unlicensed)
Table of Contents
CPU
ace_mode
A CHARON-VAX emulated CPU is configured with the "ace_mode" parameter.
Two VAX CPU implementations are available: the standard VAX instruction decoder and the optional high performance Advanced CPU Emulation mode ("ACE"). The ACE option optimizes the VAX instruction interpretation and significantly improves performance. It also requires approximately twice the amount of host memory to store the optimized code.
ACE optimization is performed dynamically during execution. It does not need to write optimized code back to disk, ACE provides its full capability instantly. The optimization does not compromise the VAX instruction decoding; CHARON-VAX remains fully VAX hardware compatible and completely transparent to the VAX operating systems and applications.
Both CPU implementations passed the HP VAX Architecture (AXE) tests, the standard qualification for VAX instruction execution correctness.
The default VAX/PDP11 CPU mode is determined by the specific CHARON-VAX product license.
| Parameter | ace_mode |
|---|---|
| Type | Boolean |
| Value | true or false |
This statement enables the ACE mode if the CHARON-VAX license permits it. If this statement is omitted from the CHARON-VAX configuration file and the license permits it, "true" is the default, otherwise "false" is the default. For test purposes the ACE mechanism can be disabled with:
|
The command
"set cpu ace_mode=true"
is ignored when the license does not permit ACE operation.
The CHARON-VAX log file displays the status of the ACE option.
The ACE mode is disabled when the host system does not meet the minimum physical requirements for this operation. If the emulator appears to not run at its normal performance, check the log file for a change in the ACE mode and verify that sufficient host resources, especially memory, are available.
RAM
The CHARON-VAX / CHARON-PDP memory subsystem is permanently loaded and has the logical name "ram".
size
| Parameter | size |
|---|---|
| Type | Numeric |
| Value | Size of the emulated memory in MB. |
Example:
|
The amount of memory is capped at a maximum, this is defined in the CHARON license key. If the host system cannot allocate enough memory to map the requested emulated memory, CHARON-VAX / CHARON-PDP generates an error message in the log file and reduces its effective memory size.
The following table lists the values of emulated RAM for various hardware models of virtual VAX/PDP11 systems:
| Hardware Model | RAM size (in MB) | |||
|---|---|---|---|---|
| Min | Max | Default | Increment | |
| PDP1193 | 2 | 4 | 2 | 2 |
| PDP1194 | 2 | 4 | 2 | 2 |
| MicroVAX_II | 1 | 16 | 16 | 1,8,16 |
| MicroVAX_3600 | 16 | 64 | 16 | 16 |
| MicroVAX_3900 | 16 | 64 | 16 | 16 |
| VAXserver_3600 | 16 | 64 | 16 | 16 |
| VAXserver_3900 | 16 | 64 | 16 | 16 |
| VAXserver_3600_128 | 32 | 128 | 32 | 32 |
| VAXserver_3900_128 | 32 | 128 | 32 | 32 |
| MicroVAX_3100_Model_96 | 16 | 128 | 16 | 16 |
| VAXstation_4000_Model_90 | 16 | 128 | 16 | 16 |
| VAX_4000_Model_106 | 16 | 128 | 16 | 16 |
| VAX_6000_Model_310 | 32 | 512 | 32 | 32 |
| VAXserver_3600_512 | 32 | 512 | 32 | 32 |
| VAXserver_3900_512 | 32 | 512 | 32 | 32 |
| MicroVAX_3100_Model_98 | 16 | 512 | 16 | 16 |
| VAX_4000_Model_108 | 16 | 512 | 16 | 16 |
| VAX_4000_Model_700 | 64 | 512 | 64 | 64 |
| VAX_4000_Model_705 | 64 | 512 | 64 | 64 |
| VAX_6610 | 128 | 3584 | 128 | 128 |
| Hardware Model (cont.) | RAM size (in MB) | |||
|---|---|---|---|---|
| Min | Max | Default | Increment | |
| VAX_6620 | 128 | 3584 | 128 | 128 |
| VAX_6630 | 128 | 3584 | 128 | 128 |
| VAX_6640 | 128 | 3584 | 128 | 128 |
| VAX_6650 | 128 | 3584 | 128 | 128 |
| VAX_6660 | 128 | 3584 | 128 | 128 |
TOY
CHARON-VAX / CHARON-PDP maintains its time and date using the "toy" (time-of-year) component. In order to preserve the time and date while a virtual system is not running, the TOY component uses a binary file on the host system to store the date and time relevant data. The name of the file is specified by the “container” option of the "toy" component.
container
| Parameter | container |
|---|---|
| Type | Text string |
| Value | Specifies a name for the file in which CHARON-VAX / CHARON-PDP preserves the time and date during its “offline” period. This file also keeps some console parameters (such as the default boot device). By default it is left unspecified.
|
it is recommended to specify the full path to the TOY file.Example:
set toy container="C:\Charon\my_virtual_system.dat" |
The CHARON-VAX / CHARON-PDP time zone may be different from that of the host system. Correct CHARON time relies on the correctness of the host system time to calculate the duration of any CHARON “offline” periods. (i.e. while the virtual system is not running). Every time CHARON comes on line it calculates a Delta time (the system time is used if there is no TOY file). Therefore, if the host system time is changed while CHARON is not running, the CHARON time may be incorrect when CHARON is restarted and the CHARON time must be set manually.
KW11-L and KW11-P Timers (PDP-11)
The KW11-L timer is used in PDP-11 system emulation. It supports a 50Hz, 60Hz and 70Hz frequency.
kw11 frequency
A time correction mechanism handles any time slips between the emulated and the host system time. The KW11-L frequency can be set in the configuration file as follows:
set kw11 frequency=50 |
Characteristics:
- For PDP-11 configurations this device is loaded automatically.
- The KW11-P is a programmable timer for PDP-11 systems. The hardware KW11-P timer runs on a 100KHz clock and can be programmed to interrupt at any frequency up to 100KHz.
- The software KW11-P implementation is limited to 1KHz due to the host operating system limitations; it can be programmed to interrupt at any frequency up to 1KHz.
- The current implementation does not contain a way to handle a time slip recovery from the host system time. This can lead to time skew between the emulated and host system time when the programmed frequencies are not divisors of 1000.
- The KW11-P is loaded automatically. It does not have any configuration file parameters because it is set by the PDP-11 software.
ROM
The System Flash ROM file conserves specific parameters between reboots.
container
| Parameter | container |
|---|---|
| Type | Text string |
| Value | Specifies the name of a file in which CHARON-VAX stores an intermediate state of its Flash ROM. This state includes, for example, most of the console parameters. By default it is left unspecified.
|
Example:
set rom container="C:\Charon\my_virtual_system.rom" |
PDP-11 Boot ROM
PDP-11 Boot ROM has two parameters: ‘ext_rom’ and ‘ext_rom_address’. Specify the external ROM file and offset within the file to load the ROM from. This feature allows changing the used boot ROM to a custom one.
ext_rom
| Parameter | ext_rom |
|---|---|
| Type | Text string |
| Value | Specifies a file containing external boot code |
ext_rom_address
| Parameter | ext_rom_address |
|---|---|
| Type | Numeric |
| Value | Specifies an offset to be used for the file specified by the ext_rom parameter |
Example:
|
The ROM file must contain a binary dump.
EEPROM
container
| Parameter | container |
|---|---|
| Type | Text string |
| Value | A string specifying a file name to store the content of the EEPROM for VAX 6000 series. Example:
This command enables EEPROM parameters (e.g., default boot drive) to be automatically saved to a specified file. The EEPROM file is created in the directory in which CHARON-VAX starts. The EEPROM file is created or overwritten each time any parameter relevant to the EEPROM content is changed.
|
Example:
|
Auto Boot
CHARON-VAX / CHARON-PDP systems can be configured to boot the operating system automatically at start up.
MicroVAX3100, VAXstation 4000, VAX6310 and VAX 4000
Those models boot automatically if the correct boot flags are set (and saved in the VAX console files) using the following command:
| Console Parameter | halt |
|---|---|
| Description | Determines whether the MicroVAX3100, VAXstation 4000, VAX6310 and VAX 4000 boot automatically if the correct boot flags are set (and saved in the VAX console files). The value is Example:
|
Important: the "toy container" and "rom container" parameters must be specified in the configuration file to store the boot flags.
MicroVAX II, MicroVAX 3600/3900 and VAXserver 3600/3900
The ROM of the MicroVAX II, MicroVAX 3600, MicroVAX 3900, VAXserver 3600 and VAXserver 3900 servers does not allow the VAX console to accept the command setting "auto-boot". Instead, an automatic boot on startup can be specified in the CHARON-VAX configuration file as follows:
| Parameter | bdr boot |
|---|---|
| Type | Text string |
| Value | Determines whether the MicroVAX II, MicroVAX 3600, MicroVAX 3900, VAXserver 3600 and VAXserver 3900 servers boot automatically if the correct boot flags are set (and saved in the VAX console files). The value is Example:
|
Important: the "toy container" and "rom container" parameters must be specified in the configuration file to store the boot flags.
PDP11/93 and PDP11/94
The ROM of the PDP11/93 and PDP11/94 does not allow the PDP11 console to accept the command setting "auto-boot". Instead, automatic boot on startup can be specified in the CHARON-PDP configuration file as follows:
| Parameters | cpu_0 auto_boot |
|---|---|
| Type | Text string |
| Value | Determines whether the PDP11/93 or PDP11/94 server boots automatically from the specified disk. The value is the disk drive to boot from. Example:
|
Important: the "toy container" and "rom container" parameters must be specified in the configuration file to store the boot flags.
VAX66x0
| Parameter | xmi boot |
|---|---|
| Type | Text string |
| Value | Determines whether the CHARON VAX66x0 startup procedure stops at the ">>>" prompt after self-tests. The value can be " Example:
The value |
Important: the "toy container" and "rom container" parameters must be specified in the configuration file to store the boot flags.
© Stromasys, 1999-2024 - All the information is provided on the best effort basis, and might be changed anytime without notice. Information provided does not mean Stromasys commitment to any features described.