Each build of SCM is configured by the file “<config_name>.asm” in the “Config” folder tree. An example configuration file is shown below.

Build date

The build date is shown in the Monitor’s HELP text and is the ultimate version identification for the complete SCM image. The date must be a fixed 8 character string in the format “YYYYMMDD”.

Configuration identifiers

The configuration identidiers, kConfMajor and kConfMinor, should match those used in the !Main.asm file.

It would be best to ask me for a configuration identifier, but failing that, use a numeric character (“0” to “9”) as the major identifier. This will avoid conflicts with official releases which use letters (“A” to “Z”).

The configuration name (CNAME) is a simple character string shown in the sign-on message. This string can be up to 11 characters long.

Hardware identifier

The hardware ID should be assigned the value HW_UNKNOWN, unless this configuration is for just one specific product, such as SC126, or class of product, such as HW_RCZ80_2. The idea is that this value can distinguish different hardware products that use the same BIOS.

Console devices

The default console device number, 1 to 6, is set with the kConDef equate. The values, kBaud1Def to kBaud6Def, set the default baud rates for serial ports 1 to 6, assuming the hardware and BIOS supports this feature. The baud rate values are expressed as a two-digit BCD number, where the two digits are the first two digits of the required baud rate. Thus, the value 0x11 specifies 115200 baud. These baud rate values are the same as the baud rate codes used by the monitor’s BAUD command.

Simple I/O ports

These are the I/O addresses for the default input and output ports. Typically these are an output port controlling 8 LEDs and an input port with 8 digital inputs.

The output port is used as a status display by the self-test routine.

The input and output ports are also used as the default ports for SCM’s I/O port API functions.

#INCLUDE statements (hardware modules)

These statements add configuration details for the specific hardware modules supported by this configuration.

Customisations

Should any customisation be required it can be added here. For example:

kSIO1ACTC: .SET 0   ;Port A's CTC register (0 if n/a)

This statement overrides the association between SIO (serial I/O) #1 port A and the default CTC (counter/timer channel) assignment. If a CTC is assigned to an SIO port, the CTC can be used to generate the required serial data clock. This statement disables this relationship.

#INCLUDE statements (to build the code)

These statements must remain in the order provided.

Include: Begin.asm

This builds the operating system layer and monitor program at the start of the ROM.

Include: Manager.asm

Here is where the BIOS source code is found and is likely to need significant work when adding a new hardware target.

Include: End.asm

This terminates the operating system, monitor, and BIOS code. What follows should then only be files included in the ROM filing system.

Include: ROM_Info.asm

Additional files (code or data) can be included in the build. These files will normally be accessed using SCM’s ROM filing system. Typical examples are a BASIC interpreter and a CP/M loader.

---

Module Configuration File

Below is an example configuration file for a hardware module. By separating each hardware module’s configuration into its own file, it becomes easy to include the hardware configurations required for any combination of hardware modules, and thus build a custom version of SCM for the target hardware.

A few of the common configuration statements are described below.

Processor

The #DEFINE PROCESSOR statement sets the processor type, such as Z180.

The value kCPUClock is the CPU clock speed in Hz.

Other processor-specific values may also be listed here. For example, the Z180’s internal register base address.

The currently supported processors are Z80 and Z180.

ROM filing system

SCM can store extensions and other files in the ROM. The filing system supports banked (or paged) ROM space.

If all of the ROM space used by the ROM filing system can be mapped into memory at the same time, then the number of banks (kROMBanks) is 1. If not, it will be the number of separately selected ROM banks used.

The value kROMTop is the high byte of the highest address used by the ROM filing system.

For example, if a system has 64k bytes of ROM in two banks, each mapped from 0x0000 to 0x7FFF, then the value of kROMBanks is 2 and the value of kROMTop is 0x7F.