[Front] [Previous Chapter] [Next Chapter]

Implementation Procedure


This chapter explains the procedure for implementing Caldera(tm) DR-DOS(tm) in ROM by means of a ROMDISK. It discusses the hardware configurations that are supported, and lists the files used to generate a ROMDISK. There is a summary of the initialization of the ROMDISK device driver, and details of how to adapt the driver to your particular hardware configuration. Sample code for booting DR-DOS from ROM is described, with information about how you can edit this code. There is also an explanation of the procedure for creating the ROM images, with details of the control file options and of how to run the ROMDISK utility.



Overview of the Implementation Procedure

The procedure for generating a ROM system consists of a number of basic steps.

1. Adapt the boot program for starting DR-DOS from ROM.

2. Adapt the ROMDISK driver to match the hardware configuration.

3. Build the ROMDISK driver depending on which type you have chosen to implement (Fixed File Format or FAT).

4. Create the ROM images that you want to store.

5. Blow the images into the ROMs, or EPROMs.

This manual describes what each of these steps involve, and explains the steps further by describing a sample implementation.

Note that you also need the following utilities to rebuild your DOS BIOS for use in a ROM-based system:

Hardware Support

The ROMDISK device driver includes code that supports specific hardware configurations, but this is only a starting point; the ROMDISK utility and device driver allow many different configurations, with different physical organizations of ROM in the system. The implementation can be on existing hardware, or can be on a new design. It can include memory- addressed or I/O-addressed ROMs, and ROMs that are paged (also called banked). The ROMs can be of a wide variety of types and sizes. Data can be 8-bit, or 16-bit.

On hardware where the ROMs are not memory addressed, DR-DOS does not execute from ROM, but the utility and driver can still be used to provide a very compact implementation of a ROMDISK.

The section Adapting the ROMDISK Driver discusses the hardware configurations for which access routines are provided, and explains how you can amend the code to support other types of hardware.

Memory Addressing and I/O Addressing

Memory-mapped ROMs typically use address windows of 64K or 4K, but DR-DOS can only execute from ROM if there is a   window of at least 64K. I/O-addressed ROMs, and memory-mapped ROMs with smaller address windows are used to implement a ROMDISK that can replace a normal disk.

Figures 1 and 2, later in this section, illustrate the layout of memory-mapped ROMs and I/O-mapped ROMs.

Memory-mapped ROMDISK

A memory-mapped ROMDISK can be paged, or non-paged.

Non-paged Memory-mapped ROMDISK

The ROMs that are part of the ROMDISK are addressed sequentially by the ROMDISK device driver. If all the ROMs are visible within the computer’s 1Mb memory, and are not paged, few changes are necessary to make the driver work. The hardware-independent portion of the ROMDISK driver just needs to know the size and location of the ROMs. This information is placed in the Physical Table in the hardware dependent portion of the ROMDISK device driver, RDISKIO.ASM. (The Physical Table is described in the section "Adapting the ROMDISK Driver.") The six hardware-dependent routines in RDISKIO.ASM in this simple case are not required, and so are coded as RET (Return) instructions.

Paged Memory-mapped ROMDISK

For a paged memory-mapped ROMDISK, you must code the six hardware-dependent routines and the extra three routines for writing to flash to reflect the instructions needed to alter the paging of the hardware and the reading of the ROMDISK data. The Physical Table indicates that this is not an instance of non-paged memory mapping by setting the most significant bit of the ROM address.

When the ROMDISK is accessed via a memory window, the processor provides part of the address (the offset within the window) directly with each move instruction. The remainder of the address is supplied by the ROMDISK hardware, and usually comes from an address latch that is written to by the processor prior to the data transfer. This address latch is written to by I/O instructions. See Figure 2-1, Memory-mapped ROMs.

Program Example

This example assumes that:

The three hardware registers MEMH, MEMM and MEML are used to latch the start address in the ROMDISK. WINDOW_SEG is the address of the ROMDISK window.

mov al, dh
out MEMH, al; latch the top 8 bits
mov al, dl
out MEMM, al; and the middle 8 bits
mov ax, si
rol ax, 1
rol ax, 1
and al, 3h; isolate the lowest 2 bits
out MEML, al; and latch them
;
and si, 03fffh ; use only the 16k offset
mov cx, 512
mov ax, WINDOW_SEG
mov ds, ax; point to the 16k window segment
rep movsb; move 512 bytes from ds:si to es:di

The repeat move instruction increments the address within the ROMDISK and the memory buffer. If the amount of data to transfer would take it past the end of the window,  you must split the transfer into two or more parts.

Figure 2-1 - Memory Mapped ROMs
Memory Mapped ROMs.

I/O-mapped ROMDISK

It may not be possible to find room in the PC memory map for a memory window via which to access the ROMDISK. In this case the data is commonly accessed via an I/O port. Most transfers involve significant amounts of data, and it would be very slow if the address required in the ROMDISK had to be set for every byte to be transferred. However, since there are not enough I/O addresses for a reasonable window, it is usual to design a hardware counter to provide part of the address. The complete address is latched by the hardware, and on each subsequent I/O data read the address is incremented automatically by the counter. When the limit of the counter is reached, the whole address has to be relatched. See Figure 2-2, I/O-mapped ROMs.

Program Example

This example assumes that:

Two 16-bit hardware registers, IO_ADDH and IO_ADDL, are used to latch the start address in the ROMDISK. IO_DATA is the 16-bit data address.

mov ax,dx
mov dx,IO_ADDH
out dx,ax; latch the top word
mov ax,si
mov dx,IO_ADDL
out dx,ax ; and the bottom word
mov cx,256; 256 words = 512 bytes
rep insw; transfer the data to es:di



Figure 2-2 - I/O Mapped ROMs
I/O-mapped ROMs

Files Used to Generate a ROMDISK

The main files used in the generation of a ROM system are listed below.

This is a control file containing the list of files and the switches used by the ROMDISK utility to build the Fixed File Format type of ROMDISK. If you build a FAT ROMDISK, you will create a RAMDISK in which to copy all the files you need before copying it to ROM.

This is a batch file that constructs the ROMBIOS.SYS file and the ROMDISK.SYS device driver, which is used for debugging.

This assembler source file contains the generic portion of the ROMDISK driver that is either linked with the DOS BIOS or installable ROMDISK.SYS driver in memory-mapped or I/O-addressed systems.

FRDISK.ASM is used when building a FAT ROMDISK.

This assembler source file contains the device-dependent routines that you customize to suit your particular environment. Example routines are provided, including memory-mapped, I/O-mapped, and memory-paged examples.

This file holds messages used by the generic object files. It is a separate file to allow easy translation into other languages.

FRDISKM.ASM is used when you build a FAT ROMDISK.

These are the link files for the generation of ROMBIO.COM from RDISK.OBJ or FRDISK.OBJ.

This is a utility that takes the list of files and control information required in the ROMDISK, and produces the ROM image needed to program the ROMs.

This file contains the source of a sample bootstrap program that is used to boot the DR-DOS system from ROM.

This file holds messages used in ROMINIT.ASM. It is a separate file to allow easy translation into other languages.

This is used to generate the ROM image from the fileset you generate in your RAMDISK.



Initialization of the ROMDISK Device Driver (Fixed File Format)

ROMDISK device driver actions

During device driver initialization, the ROMDISK device driver reads all the ROMs, and copies the ROM File Control Blocks (RFCBs) and path strings to RAM. The device driver validates the RFCBs by performing checksums on the RFCB itself, and on the file part. The list is sorted, and forms the root and subdirectories. Subdirectories, the File Allocation Table (FAT) and the boot sector are then constructed in RAM, and are stored in a compressed form to save space. The device driver input routine then expands the subdirectories, FAT and boot sector when they are read.

Converting DOS sector numbers to ROM addresses

A translation table is constructed to convert DOS sector numbers into ROM addresses. When the ROMDISK is read, this table enables the data to be accessed without the need to first search the ROMs for the file.

Initialization of the ROMDISK Device Driver (FAT)

Because the FAT based ROMDISK is formatted as a normal DOS disk such as a RAM disk or floppy diskette, the operation of the device is much simpler. During the device driver initialization, the ROMDISK driver reads the first 512 bytes of the ROMDISK device to look for a valid DOS boot sector. If a valid DOS boot sector is found, the ROMDISK driver reads values from the boot sector to determine the physical size of the DOS partition. This is then checked against the rom_info structure defined in RDISKIO.ASM to ensure that the size matches.

If the size does not match, or if a valid boot sector cannot be found, the driver still loads but zero filled sectors will be returned on each read from the device. When the device is in this non-initialized state, each read from the device will first cause a retry of the initialization code. Therefore, if a Flash device is subsequently re-programmed, or for example a PC card is inserted into a PCMCIA slot, then the driver will dynamically initialize itself and return valid data on subsequent reads from the device.



Booting DR-DOS From ROM

The file ROMINIT.ASM contains a sample bootstrap program that illustrates the steps required to boot DR-DOS in a PC-compatible implementation, using a ROMDISK with a memory window.

The first file placed in the ROMDISK is ROMINIT.BIN, which receives control when the machine’s ROM BIOS attempts to boot from disk. This transfer of control is achieved by the ROMDISK having a PC "Option ROM header" in the first few bytes of the memory window. The ROM BIOS detects the "Option ROM heade" and checks the checksum based on the specified length of the window given in the header. If there is no checksum error, ROMINIT.BIN is called. The code in ROMINIT.BIN alters the interrupt vectors 18H and 19H, and returns to the ROM BIOS. When the ROM BIOS attempts to boot from disk (INT 19H), or to call BASIC (INT 18H), control passes back to the ROMINIT.BIN code. In the sample code, a message is displayed on the screen, to allow the user to decide whether to boot from ROMDISK or from disk. If booting is from disk, control passes back to the original code pointed at by INT19H. The message, and the opportunity to boot from disk are optional, as explained in Editing ROMINIT.ASM.

If booting is to be from the ROMDISK, the code locates the next file in the ROMDISK. This file must be the DOS kernel, which is placed here so that it is more likely to appear in the first memory page of a paged ROMDISK to allow ROM execution of the kernel. If the file is not the DOS kernel, the code passes control back to the original INT 19H boot code.

The third file in the ROMDISK must be the DOS BIOS ( if it is not, the boot attempt aborts, and control passes back to the original INT 19H boot code). The BIOS is moved from ROM to RAM, at location 70H, even if the BIOS will eventually execute from ROM. The BIOS is segmented with the RAM-resident code and data first, followed by the ROM-resident code and initialized data, and then by the code and data that is required only for initialization of the BIOS. The code and data needed for initialization is stored in compressed form in ROM, and is automatically decompressed before it is executed.

In all cases, the INIT code is discarded from RAM after use. In the case of execution from ROM, the resident code segment is also discarded from RAM after the pointers have been "fixed up" to use the ROM-resident BIOS code.

Booting DR-DOS in a Memory Paged System

In a memory paged system implementation with a page window smaller than 64k, it will be possible to validate the existence of the three boot files without paging in other devices containing the files.

The sample ROMINIT.ASM code contains an example of how to page in subsequent devices.

Editing ROMINIT.ASM

Specifying the Boot Disk

As explained in the section Booting DR-DOS From ROM, the file ROMINIT.ASM contains a sample bootstrap program that is used to boot DR-DOS from ROM. You can alter variables in this file to specify that the files COMMAND.COM, AUTOEXEC.BAT, and CONFIG.SYS are to load from a disk other than the ROMDISK. The value of COMSPEC_DRIVE determines the drive from which COMMAND.COM loads; the default value, 0FFH, specifies the ROM disk. To specify a different drive, set the value of COMSPEC_DRIVE as follows:

and so on.

You can likewise specify the default drive from which AUTOEXEC.BAT and CONFIG.SYS are to load by resetting the value of INIT_DRIVE in the file ROMINIT.ASM. The drives are specified by the same values as for COMSPEC_DRIVE, with the default value 0FFH specifying the ROMDISK. Note that you can only set this parameter when you use a ROM-based system, rather than a disk-based system, and the system thus boots from ROM.

The values ROM_CONTROL and the BASE_PAGE can be modified to suit your requirements.

Controlling the Boot Prompt

A further ROMINIT.ASM variable that you can edit is KEYBOOT. When you boot DR-DOS, you receive by default a prompt to boot from either disk or ROM. If you always want to boot from ROM, and you do not require the prompt, edit the following line in ROMINIT.ASM:

KEYBOOT equ NOT 0

to read

KEYBOOT equ 0

Adapting the ROMDISK Driver

ROMDISK Device Driver

The ROMDISK device driver consists of two parts, a generic part supplied in object form and RDISKIO.ASM. The generic portion contains all the code that is hardware independent. You can adapt the driver to the particular hardware configuration on which the ROM system is to be built by editing the file RDISKIO.ASM.

Sample Hardware Configurations

For your convenience, RDISKIO.ASM contains a number of hardware examples, including the following:

Type 3

Memory paged, 4 x 64K, 8-bit. Award card, with a 64K window at either D000H or E000H, depending on the jumpers.

Type 4

Memory mapped, 2 x 64K, 8-bit. PC motherboard, with two ROMs at E000H and F000H, including a 32Kb ROM BIOS.

Type 5

Memory mapped, 2 x 64K, 16-bit. AT motherboard, with odd-byte and even-byte ROMs at E000H, including a 32Kb ROM BIOS.

You have to determine which Type in RDISKIO.ASM is closest to your requirements, and then to pass the Type number as a parameter to the batch file when you run MAKEROM.BAT (refer to "Creating the ROM Images For a Fixed File Format ROMDISK) or "Creating the ROM images For a FAT ROMDISK" depending on which type of ROMDISK you are creating). You may need to edit the code further if the Type you have activated does not exactly match your hardware configuration.

Editing the ROMDISK Driver

You need, for example, to ensure that RDISKIO.ASM reflects the arrangement of the ROMs. There is a table, called the Physical Table, that has an entry for each ROM (or ROM image if word based) in the system. The driver uses this table to locate all the files or part of files in the ROMDISK.

A separate entry must be made for each ROM that may or may not be fitted. This table must correspond to the ROM size used in the ROMDISK utility to create the ROM images. The generic portion of the ROMDISK driver will not attempt to transfer data from a ROM in one entry to the ROM in the next entry of the table.

The structure of the table is shown below.

Physical Table.

The data structure for each entry in the table has two 32-bit fields.

The first field is the size of the ROM image in bytes. In a 16-bit ROM system the ROMs are used in pairs (EVEN and ODD bytes). In this case, the size of the ROM in the table is twice the actual component size. For example, in a 27512, 8-bit system, the ROM size is 64Kb, while PT_SIZE = 10000H. In a 2*27512, 16-bit system, the ROM size is 128Kb and PT_SIZE = 20000H.

The second field in each table entry is the byte address of the start of the ROM if the ROM is a simple memory mapped ROM. If the ROM is I/O-addressed or paged, the top bit of the address is set. This forces the ROMDISK driver to the special routines in RDISKIO.ASM for all access to the ROM. These special routines use the addresses given in the table, and several examples are given in the RDISKIO.ASM file. There is no fixed standard for the use of the address when the top bit is set, but the routines and address values must work together. Other bits may be used so that the ROMDISK can support I/O, I/O-paged, memory and memory-paged ROMs in the same disk.

If you are modifying a hardware configuration already defined in RDISKIO.ASM, you may need only to alter the ROM addresses in the table. However, if you want to define a completely new type, you must also rewrite the routines for accessing the ROM, and remember to make any necessary changes to MAKEROM.BAT to build your new driver. The routines for accessing the ROM are described below.

RDISKIO Hardware-Dependent Routines

This section describes the hardware-dependent routines in the order in which they appear in RDISKIO.ASM.

ROM_READ_IO

The ROM_READ_IO routine reads data from the ROMDISK memory. It is called by the hardware-independent portion of the ROMDISK driver when it has been determined that the ROMDISK starting address required for the transfer is not a simple non-paged memory type. The SET_ROM_ADDR routine will already have been called to select the page. The transfer will not cross the end of this physical ROM, and therefore it is necessary in this routine only to jump to the generic ROM_READ_MEM routine. In the case of an I/O-based system the procedure to transfer the data is placed in this routine.

GET_ROM_ADDR_IO

In a memory-mapped system, the GET_ROM_ADDR_IO routine can usually be a simple Return (RET), because the address will be the same as the DX:AX registers on entry. In the case of an IO-mapped system, it may be beneficial to "read-back" the current address from the hardware. In other cases, a simple RET instruction causes no problem, because the routine SET_ROM_ADDR_IO is always called before any transfer.

SET_ROM_ADDR_IO

The SET_ROM_ADDR_IO routine allows the hardware to be set to the starting transfer address. The appropriate paged-ROM or I/O counters should be set using the ROM address passed in DX:AX. This is based on the entries in the Physical Table, and is usually a linear address in bytes from the start of the ROMDISK. If the address specified would cause the DOS kernel or DOS BIOS currently executing from ROM to be "paged-out", then it is prudent to turn interrupts off in this routine.

IO_CLEANUP

If the first ROM was paged out by the SET_ROM_ADDR_IO  call, page it back in now, and set the interrupts back on. This action is only required if the DR-DOS kernel or DOS BIOS are executing from ROM.

IO_CHECK

The IO_CHECK routine is similar to the ROM_READ_IO routine above, except that instead of transferring the data from the ROMDISK to memory, it is added byte by byte modulo 8 to form a checksum. This checksum value is returned in register BL. The generic routine MEM_CHECK can be used here if the system has paged memory ROMs, because any checksum request will not exceed the ROM that is currently paged in.

IO_INIT

The IO_INIT routine is called by the ROMDISK device driver before any other routine. It is used to perform any "one-time" initialization, such as determining the ROMDISK I/O address, or ROMDISK size if more than one hardware Type is to be supported. This is the place to put any code to dynamically initialize the Physical Table. Note that the checksum code in the ROMDISK driver discards faulty or missing ROMs, and sorts the files and ROMs based on the Physical Table.

The remaining functions are used to write to a ROMDISK.

IS_FLASH_ENABLED

This routine is called by the hardware-independent portion of the ROMDISK driver to determine whether the device is programmable.

ROM_WRITE_IO

This routine writes data to the ROMDISK memory. It is called by the hardware- independent portion of the ROMDISK driver when it has been determined that the ROMDISK starting address required for the transfer is not a simple non-paged memory type. The SET_ROM_ADDR routine will already have been called to select the page. The transfer will not cross the end of this physical ROM, and therefore it is necessary in tis routine only to jump to the generic ROM_READ_MEM routine. In the case of an I/0-based system, the procedure to transfer the dat is placed in this routine.

ROM_WRITE_MEM

This routine calls the device dependent routines that program the device. It is likely that this routine will require modification to suit the program cycle of the device.

ENABLE_PROGRAMMING

Most flsh devices must be set into program mode before they can be updated. This operation prepares a block in the device for re-programming. This routine will require customization to suit the characteristics of the particular device.

DISABLE_PROGRAMMING

This function takes the device out of program mode and back to read mode.

WRITE_FLASH_SECTOR

This routine is used to write a sector of data to the device following an ENABLE_PROGRAMMING call. Because different devices have different programmable sector sizes, this routine will require customization to suit the characteristics of the particular device. The sector in this context has no relation to a DOS sector.

Memory Paged System With a Small Paging Window

If you have a memory-paged system with a small paging window, the ROM_READ_IO and IO_CHECK routines require more extensive coding than is shown in the examples. This type of hardware is supported, but the Physical Table must be set to reflect the larger ROM image size, rather than the smaller window size. This reduces the number of entries in the Physical Table, but now the two routines must split the transfer down to the smaller window size, and alter the paged window by internally calling the SET_ROM_ADDR_IO routine.



Creating the ROM Images For a Fixed File Format ROMDISK

Running MAKEROM

When you have altered the boot program and ROMDISK device driver, you run MAKEROM.BAT. The syntax of MAKEROM is:

MAKEROM n FFF

where n is the number of the hardware type activated in file RDISKIO.ASM. FFF is the switch used when creating a Fixed File Format ROMDISK. For example, if you have activated Type 4, the command would be:

MAKEROM 4 FFF

MAKEROM generates the following files from source:

A loadable version of the ROMDISK device driver for debugging.

DOS BIOS incorporating the ROMDISK device driver.

ROM initialization code.

Note that MAKEROM.BAT includes the line:

SUBST I:.

You must therefore ensure that I is a valid drive letter by specifying drive I, or higher, in a LASTDRIVE= statement in the CONFIG.SYS file on your development system:

LASTDRIVE = I

Editing the File CONTROL

The next step in creating the ROM images is to edit the file CONTROL, which specifies the filenames and paths of the files that you want to incorporate into the ROMDISK. The file CONTROL also contains switches that specify the positioning of files, the type and size of ROMs, the size of the data bus, the type of image to be produced, and whether the ROMDISK is to be bootable. There are two possible types of image: binary image file, or Intel Hexadecimal Output.

The section "ROMDISK Control File" describes these switches in detail.

Starting the ROMDISK Utility

When you have edited the file CONTROL, you start the utility ROMDISK, which reads the control file and  generates the appropriate files. These are the files that you blow onto the ROM chips.

The syntax of ROMDISK is:

ROMDISK filename

or

ROMDISK /H

where filename is the name of the control file, and the /H option provides online Help text about the ROMDISK command.

Transfer the .BIN or .HEX files from your PC to the PROM programmer.

The section “The ROMDISK Utility’s Screen Display” explains the meaning of the information displayed on your screen when you start ROMDISK.

ROMDISK Control File

The control file contains switches and the names of the files required in ROM. Each line normally specifies either a single file or a switch, although multiple files and switches can be on the same line if they are separated by spaces.

Switches

The switches that you can include in the control file are described below.

filespec

Specifies the input filepath and filename of the file you want to copy to the ROMDISK.

=nnnnn

This switch is used to force subsequent files to start at the hexadecimal byte offset nnnnn in the current ROM image.

+ attribute Add to (+), or remove (-) file attributes inherited
-  attribute from the input file, where A= Archive, H=Hidden, R=Read Only, S=System, *= all attributes (A, H, R, S). For example:

-* +RH

removes all attributes, then adds Read Only and Hidden.

The default is to copy all the file’s existing attributes.

Note: You can only specify attributes after a filespec.

;

The semicolon (;) is the comment delimiter. The ROMDISK utility ignores all text on a line after a “;”.

/128 These switches define the size of the required
/256      ROM devices.
/512
/1024

/E

Inserts an “End of Disk Image” marker into the generated disk image. This speeds up the device driver initialization on large capacity ROM disks that hold a small number of files.

/J[UMP][nn]

This switch inserts a ROM BIOS-compatible signature at the start of the ROMDISK. The signature occupies the first 32 bytes of ROM image 0, and contains the value 055AAH, the ROM size, and the entry point for the initialization routine. This switch is only necessary for a “bootable” ROMDISK in PC-compatible systems, and the ROMINIT.BIN file must be the next file in the disk followed by the files IBMDOS.COM and ROMBIO.COM. If the ROMDISK is not bootable then the sequence of files does not matter.

The ROMDISK utility calculates a checksum for the first nn Kbytes of the first ROM, and stores the checksum in the 32-byte header. The value nn specifies the amount of ROM to be checksummed; it can be 4, 8, 16, 32, or 64 Kbytes. If you omit nn, the default is 32 Kbytes.

/L

Places a volume label in the ROMDISK. This is the label displayed when the DIR command is executed on the ROMDISK driver. Up to eleven characters are allowed in the label and they must follow the /L command with no space. For example:

/LROMDISKVERI

If you want to include spaces in the label, enclose the entire label in double quotation marks. The first quotation mark must follow immediately after the /L command. For example:

/L"NEW FILE"

The current date and time are recorded in the label’s date and time fields.

/MDpath

Makes the directories listed in path , and can thus create empty subdirectory paths. For example:

/MD\dir1\dir2

creates the empty subdirectories \dir1\dir2.

/Ofilespec

Specifies the destination filepath and filename of an input file copied to the ROMDISK. The /O option must be used after the source filespec, and must be followed immediately by the destination filespec. The full syntax is:

source-filespec /Odestination-filespec

For example:

file1 /O\dir1\file2

copies file1 to dir1, and renames file1 as file2.

/S[PLIT]

Generates the image files in 16-bit data bus format.

If you omit this switch, the image is created in 8-bit data bus format. When the switch is included, the ROMDISK utility produces two ROM images that together make up each ROM image. One ROM file is the ODD byte and the other the EVEN bytes. The EVEN ROMs are labeled PROMLOnn.BIN and the ODD ROMs are labeled PROMHInn.BIN, where nn is the number of the ROM image. Figure 3 illustrates the two layouts. Note that if the control file includes switch /X, the generated files have the extension .HEX, rather than .BIN .

/X

Generates output data into Intel Hex Output, rather than the default binary file image. The files generated in this way have the extension .HEX .

Figure 3 - 16-bit and 8-bit ROM Images

16-bit and 8-bit ROM Images.

Example Control File

This section shows a sample control file. It generates binary image files that are suitable for programming into 128 Kbyte EPROM devices. Comments in the control file explain the function of each switch used in the file.

; This is a sample control file for use with the ROMDISK utility R1.7
; and later versions.

/j; Add IBM Header with 32 Kbyte checksum
/512; select 64 Kbyte ROMs
/1ROMDISK ; set label to ROMDISK
rominit.bin /o\rominit.bin + rsh ;place rominit.bin in root directory
; and set Read only, system and hidden
; attributes
\ibmdos.com  +hsr; put IBMDOS.COM in root and
; set attributes
rombio.com /o\ibmbio.com +rhs; rename ROMBIO.COM to IBMBIO.COM and
; place in root directory, and set
; attributes
\command.com +r ; place COMMAND.COM into root directory
; and set the read only attribute
=8000; force next file to occur at offset
; 8000H
rombios.bin /o\rombios.bin +rsh ; place ROMBIOS.BIN into root
; directory and set attributes

The ROMDISK Utility's Screen Display

This section explains the meaning and value of the information displayed by ROMDISK. When you invoke the ROMDISK utility, you see a screen that looks something like the screen below. The example screen comes from the section “Example Procedure for Type 4 Hardware.”

Note: The file sizes shown in this example may not match those in your particular implementation.

ROMDISK R1.7 Romdisk creation utility
Copyright (c) 1988,1989 Caldera Inc. All rights reserved.

IMG SEQ TOT Address Size Fixadd Pointer Pathname
0 1 0 00000000 00000000 00000000 00000000 Header
0 1 0 00000020 00000000 00000000 00000000 Label:-"ROM DISK   “
0 1 1 00000060 00000147 00000000 00000000 ROMINIT.BIN
0 1 1 000001D0 000099D9 00000000 00000000 IBMDOS.COM
0 1 1 00009BD0 00005540 00000000 00000000 IBMBIO.COM
0 1 2 0000F130 00000ED0 00000000 00000000 COMMAND.COM
1 2 2 00000020 00007D50 00000000 00000ED0 COMMAND.COM
1 1 0 00007D90 00000250 00008000 00000000 Filler
1 1 1 00008000 00008000 00000000 00000000 ROMBIOS.BIN

Output file(s) generated will be binary.

IMG

The IMG column displays the image or ROM device (chip) number, starting from device 0. This column indicates the device in which the file resides. The number of ROMs required to build a disk is the last IMG number plus 1 (because the count starts from 0). You can use this field to check whether a particular file spills over into a second ROM image. It may be essential for a file to reside in a single image, to permit execution from ROM. In this case you should change the order of the files to get the best fit, and to eliminate spill over between ROM images.

SEQ and TOT

File images are divided into segments to allow the ROMDISK to handle the file in manageable pieces. The TOT field specifies the total number of segments that make up a particular file, and the SEQ field displays the segment number from 1 to TOT. These fields are useful in showing how the file image is broken down. It may be essential for a file to reside in a single segment  in order to permit execution from ROM, and these fields will show if a file has fragmented.

Address

The Address field shows the byte address of the data part of the file within the device. You may find it useful to know where the file is in the image for debugging purposes, particularly when you want to execute from ROM.

Size

The Size field gives the hexadecimal byte size of the file segment. You can determine the total file size by adding together all of the segment sizes in the same file.

Fixadd

The Fixadd field contains a value when the file address within the device has been fixed using the switch =nnnn in the control file. This display reminds you that the address was fixed at this point.

Pointer

The Pointer field is used to cross reference the other segments when a file image is split into two or more segments. The field’s  value is a byte count that  indicates how much of the file up to that point is missing, and is presumed to be in another segment. The value is an accumulated total. Thus, if a file is split into four segments, the fourth segment will contain a larger Pointer value than the previous images. You can determine the total size of a file by adding the Pointer value for the last segment of a file image to the Size value of the last segment of a file image.

Pathname

The Pathname field contains the path and filename of the file as it will appear in the disk image. This may be different to the source filename and path if the switch /Ofilespec was specified in the control file. This field enables you to check that the correct files will appear in the correct subdirectories when the disk image is blown into ROM.



Creating the ROM Images For a FAT ROMDISK

When you have altered the boot program and ROMDISK device driver, you run MAKEROM.BAT. The syntax of MAKEROM is:

MAKEROM n FAT

where n is the number of the hardware type activated in file RDISKIO.ASM. For example, if you have activated Type 4, the command would be:

MAKEROM 4 FAT

MAKEROM generates the following files from source:

ROMDISK.SYS A loadable version of the ROMDISK device driver for debugging.
ROMBIO.COM DOS BIOS incorporating the ROMDISK device driver.
ROMINIT.BIN ROM initialization code.

Note that MAKEROM.BAT includes the line:

SUBST I:.

You must therefore ensure that I is a valid drive letter by specifying drive I, or higher, in a LASTDRIVE= statement in the CONFIG.SYS file on your development system:

LASTDRIVE = I

Creating a RAM Disk

Create the RAM disk by loading VDISK.SYS from your CONFIG.SYS file. The following is an example:

DEVICE=C:\DRDOS\VDISK.SYS 4096 512 512 /e

This creates a 4096 KB vdisk in extended memory with 512 byte sectors and 512 entries in its root directory.

The size of the RAM disk must match the size of the ROM image that you want to generate.

Copying Files to the RAM Disk

Once the RAM disk is created, copy all the files you want to store in the ROM disk onto the RAM disk.

Running the RAM2ROM Utility

When you have copied all the necessary files onto the RAM disk, the RAM2ROM utility is used to generate the image file which is blown into the ROM, for example:

RAM2ROM d: prom0000.bin

where d: is the RAM disk drive.

Booting DR-DOS with a FAT ROMDISK

It is not possible to boot DR-DOS directly from a FAT ROMDISK. You need to create a small bootable Fixed File Format (FFF) partition at the beginning of the ROM device and program the remaining devices with the FAT ROMDISK. The FAT ROMDISK must be reduced in size to compensate for the FFF boot partition which is typically 64K. The rom_info table in RDISKIO.ASM which describes the physical layout of the ROM devices must be adjusted to compensate for the new start address of the FAT ROMDISK (64K beyond the first device).

The following steps describe how to create a bootable FAT ROMDISK.

1. Adjust the rom_info table in RDISKIO.ASM to address the device at the start of the FAT device to skip the 64K FFF partition. For example:

; This 256k byte ROMDISK below has a 64K bootable partition so the FAT
;partition
; is reduced in size to 192K and the start address is adjusted accordingly.
rom_info label word
; PT <<08000h, 0800d0000h>>
; PT <<08000h, 0801d0000h>>
PT <<08000h, 0802d0000h>>
PT <<08000h, 0803d0000h>>
PT <<08000h, 0804d0000h>>
PT <<08000h, 0805d0000h>>
PT <<08000h, 0806d0000h>>
PT <<08000h, 0807d0000h>>
PT <<0, 0>>

2. Rebuild ROMBIO.COM. For example:

MAKEROM 4 FAT

3. Modify the file CONTROL to create a bootable FFF partition. For example:

; This is a sample control file for use with the ROMDISK utility R1.7 and
; later versions.
/jump ; Add IBM Header with 32Kbyte Checksum
/256 ; select 32Kbyte page size
/lROMDISK ; set label to ROMDISK
rominit.bin /o\rominit.bin +hsr ; place rominit.bin in root directory
ibmdos.com /o\ibmdos.com +hsr ; put ibmdos.com in root and set attribs H,S,R
rombio.com /o\ibmbio.com +rhs ; rename rombio.com to ibmbio.com and place
; in root directory and set attribs H,S,R

4. Run the ROMDISK utility with the modified CONTROL file to create the bootable FFF partition. For example:

[DRDOS] C:\OEM\SDKS\ROMMING>romdisk control

ROMDISK R1.8 Romdisk creation utility
Copyright (c) 1988,1997 Caldera, Inc. All rights reserved.
IMG SEQ TOT Address Size Fixadd Pointer Pathname
0 1 0 00000000 00000000 00000000 00000000 Header
0 1 0 00000020 00000000 00000000 00000000 Label:- "ROMDISK "
0 1 1 00000060 00000198 00000000 00000000 ROMINIT.BIN
0 1 1 00000220 00007581 00000000 00000000 IBMDOS.COM
0 1 2 000077D0 00000830 00000000 00000000 IBMBIO.COM
1 2 2 00000020 00005C18 00000000 00000830 IBMBIO.COM
1 1 0 00005C38 000023C8 00000000 00000000 Unused
Output file(s) generated will be binary.
OK to continue ? (Y/N): Y
Now generating Low ROM: PROM0000.BIN
Now generating Low ROM: PROM0001.BIN

5. Create a RAM drive of 192KB with the following CONFIG.SYS command.

device=c:\drdos\vdisk.sys 192 512 512 /e

6. Reboot your computer to initialize the RAM drive and then copy data files to the RAM drive. Remember that IBMBIO.COM and IBMDOS are no longer needed on the FAT partition because they are on the FFF partition.

7. Create a ROM image of the RAM drive using the RAM2ROM utility, for example:

[DRDOS] C:\OEM\SDKS\ROMMING> RAM2ROM F: PROM0002.BIN

8. Concatenate the ROM image files into one image, which can then be blown into the device, for example:

[DRDOS] C:\OEM\SDKS\ROMMING>copy /b prom0000.bin+prom0001.bin+prom0002.bin prom.bin

9. Program the device with the PROM.BIN data.

Testing the ROMDISK

To test that your ROMDISK has been correctly built, follow the steps below:

1. Create a bootable diskette.

2. Copy ROMDISK.SYS to the diskette.

3. Create on the diskette a CONFIG.SYS file that includes the line:

DEVICE = A:\ROMDISK.SYS

4. Check that the appropriate hardware is installed, and the ROMS are fitted.

5. Boot your machine from the diskette.

6. When you boot, your ROMDISK should be initialized, and if, for example, you have a hard disk (C:), you should also be able to see your ROMDISK (D:).


[Front] [Previous Chapter] [Next Chapter]

info@caldera.com
Copyright © 1976, 1982, 1991, 1992, 1997, 1998 Caldera, Inc. All rights reserved.