How can I get an extra segment in DOS?

Question

I'd like to write a little DOS program (my first one) and I'm a little bit inexperienced.

For the program, I need more than 64 kilobytes of (conventional) memory. How can I get extra memory? Ideally, I'd like to have two extra 64k blocks of memory for the program. Can I just start to write data somewhere into the address space or do I need to request extra memory?

Crew

What assembler are you using? – No

@RossRidge I'm using the GNU assembler because I'm familiar with the syntax. – Crew

Ah, that's unfortunate. The GNU Assembler doesn't properly support segments and can't be used to create MS-DOS EXE's. Otherwise you could just define two 64k blocks of memory in your source code. – No

@RossRidge I'd like to create a simple COM binary. Part of this exercise I posed to myself is trying to understand how DOS manages memory, so I want to “allocate” the memory at runtime even though I know how much I need at most in advance. I'm going to get rid of GAS in the future, but right now I'm more familiar with it than with other assemblers. – Crew

Answer 1

Under DOS, yes, you can just start using another segment of memory. There is an important caution, however!

Have a look at a memory map for the version of DOS that you are using. You want to be sure that you aren't selecting a region of memory that is actually reserved for another purpose. Here is one from Dr. Dobb's Journal:

Address (Hex)                 Memory Usage

0000:0000                Interupt vector table
0040:0000                ROM BIOS data area
0050:0000                DOS parameter area
0070:0000                IBMBIO.COM / IO.SYS *
mmmm:mmmm                BMDOS.COM / MSDOS.SYS *
mmmm:mmmm                CONFIG.SYS - specified information
                         (device drivers and internal buffers
mmmm:mmmm                Resident COMMAND.COM
mmmm:mmmm                Master environment
mmmm:mmmm                Environment block #1
mmmm:mmmm                Application program #1
     .                        .      .                        .      .                        .
mmmm.mmmm                Environment block #n
mmmm:mmmm                Application #n
xxxx:xxxx                Transient COMMAND.COM
A000:0000                Video buffers and ROM
FFFF:000F                Top of 8086 / 88 address space

The "official" memory allocation mechanism is through memory control blocks (MCB) and the DOS interrupt 0x21 using 0x48 to allocate and 0x49 to free memory. A good discussion of this can be found in this Microsoft support document.

For documentation on the interrupt approach, you might look here.

Bitten

Is there a region that is guaranteed to be available in all DOS versions? – Crew

I added a bit more detail for using DOS interrupts to allocate memory. I honestly can't remember anything other than the zero page and video memory in terms of what's where under DOS. :) – Bitten

For future readers: You are allowed to overwrite the "Transient COMMAND.COM" area. The area is reloaded by DOS when it's overwritten by a user process. This means that you can use all memory from CS:0000 to A000:0000 exclusive for your process. – Crew

@fuz: That isn't correct, the memory starting at the code segment and extending to below 0A_0000h is not always available. Other programs can use memory "at the top" of the Low Memory Area. The EBDA can be placed there too. Even so, if UMBs are allocated to the DOS's memory chain (when assuming no other users) then at segment 9FFFh one paragraph is used for the first UMCB. Also, with loadhigh the code segment can start above 0A_0000h even. Much better to shrink the application's memory block to 64 KiB using int 21.4A then allocate blocks using 21.48 next. – Phenology

MS Support documentation - dead link – Sociability

Answer 2

I recently stumbled on this question. Despite it being a few years old, I felt that some additional information beyond the current answers may be useful for future readers.

---

This question really boils down to: Can I arbitrarily write to memory beyond the extent of my program that DOS has allocated? The question is geared towards DOS COM programs, but much of the information applies to DOS EXE programs as well.

GNU assembler is limited in that it doesn't generate 16-bit DOS EXE programs so you have to generate DOS COM programs. DOS COM programs that have an origin point of 0x100. The code, data and stack can't exceed 64KiB of memory (at load time). DOS COM programs have these characteristics once loaded into memory by the DOS loader:

• Upon entry DS=ES=SS=CS.
• The program is relocatable to any segment, and doesn't contain load time fixups/relocations.
• The program is allocated the largest contiguous free block from the DOS memory pool even though the DOS COM program when loaded is limited to <= 64KiB of memory. The DOS loader effectively allocates the entire free pool to your COM program.
• The DOS loader always sets SS=CS, but SP may start at a value other than 0x0000¹ if the amount of available space for our program is less than 64KiB.
• The DOS loader always pushes a value of 0x0000 onto the stack prior to transferring control to CS:0x0100 to start our program. CS:0x0000 is the start of the PSP and the PSP starts with the 2 byte instruction (0xcd 0x20) Int 20h. Int 20h terminates the current program. This is the mechanism that allows a DOS COM program to do a ret to terminate the program.
• There is a program control block called the Program Segment Prefix (PSP) that DOS places in memory between CS:0x0000 and CS:0x0100
• COM programs start executing at CS:0x0100

The first question one should ask is: How much memory does my DOS COM program actually have? The simple answer is: it varies. It may vary based on the amount of available conventional memory (IBM PC's generally came with 64KiB, 128KiB, 256KiB, 512KiB, or 640KiB). The Dr. Dobbs Journal article cited in another answer was published in 1988 and the memory map is missing some crucial things.

In 1987 IBM released the IBM PS/2 line of computers. In order to save mouse related information, IBM realized there wasn't enough space in the BIOS Data Area above the interrupt vector table so they created an Extended BIOS Data Area (EBDA). This memory is reserved by the BIOS, and the IBM PS/2 BIOS started reporting 1KiB less memory (639KiB instead of 640KiB). The EBDA can be of varying sizes depending on the BIOS manufacturer. The BIOS Int 12h call will return the amount of conventional memory (<=640KiB) excluding the EBDA region. DOS relies on this to determine how much memory it has available to use.

To make things worse, when the 386SL based systems were released it included System Management Mode that runs at ring -2 and had complete access to your PC. These systems started using space in the EBDA as well. Some systems required more than 1KiB. In theory you could have 128KiB of EBDA space although I'm not sure if any systems ever had that! This area was eventually used for power management (APM), ACPI, SMBIOS and it was possible for this area to be written to by System Management Mode at anytime. This area is often considered reserved by OSes for that reason. What actually happens is dependent on the BIOS and the machine's manufacturer.

Beyond the EBDA some DOS programs (and malware) intercept BIOS Int 12h and report less memory in order to hide (or make resident) a piece of code/data that DOS shouldn't touch. The Dr. Dobbs memory map could use a couple of additions:

mmmm:mmmm                Environment block #1
mmmm:mmmm                Application program #1
     .                        .      .                        .      . 
mmmm.mmmm                Environment block #n
mmmm:mmmm                Application #n
xxxx:xxxx                Transient COMMAND.COM
hhhh:hhhh                Hidden/Resident programs and data
eeee:eeee                Extended BIOS Data Area
A000:0000                Video buffers and ROM
FFFF:000F                Top of 8086 / 88 address space

Moral of the story: you shouldn't assume the amount of memory available to you runs between CS:0x0000 and 0xa000:0x0000².

To answer the question as to how to tell what region of memory is exclusive to your program can be answered by looking at the PSP, and in particular the WORD value at offset CS:0x0002:

02h-03h word (2 bytes) Segment of the first byte beyond the memory allocated to the program

By reading this value you can get the segment of the first byte just beyond what your program has been allocated (we'll call it NEXTSEG). Often NEXTSEG will be 0xA000 or 0x9FC0 (a system with a 1KiB EBDA would have this value). It will vary on hardware for the reasons discussed previously. The area will overlap the transient portion of MS-DOS's COMMAND.COM. Realistically, the area of memory that we can guarantee exclusive to our COM program after being loaded is that we are free to use all physical memory between CS:0x0000 and NEXTSEG:0x0000.

---

COM program allocating 128KiB

Because of the overlapping nature of 20-bit segment:offset addressing each segment points to the start of a different 16-byte region in memory called a paragraph. Incrementing a segment by 1 advances 16 bytes in memory and decrementing goes back 16 bytes. This is important in doing the required arithmetic to find out how much our program needs and ensuring enough memory is available to satisfy the request.

128KiB is 128*1024/16=8192 paragraphs. The actual size of the region our COM program was loaded into (and where the stack is placed) is bounded by CS:0x0000 and the segment just beyond where the stack (SP) is pointing. Since DOS always pushes a 2 byte value (return address that ret will return to) for a COM program - the next paragraph can be computed by dividing SP by 16 (or SHR by 4) and adding 1 (we'll call this SEGAFTERSTACK).

The easiest thing to do is to place our 128KiB of data just beyond the upper edge of the stack (SEGAFTERSTACK). We just have to ensure that there is enough space between SEGAFTERSTACK and NEXTSEG (the extent of our program area given to us by DOS). If that value is >=8192 paragraphs then we have enough memory and we are free to access it as we see fit. If we do have enough memory we can ask DOS to resize our COM program down to the exact amount of space we need using Int 21h/AH=4ah. We don't need to resize the memory DOS already allocated for us but it can be useful if your code needs to load/run a child program with DOS's Exec function Int 21h/AH=4bh.

Note: DOS < 2.0 didn't support Memory Control Blocks which meant the Int 21h functions to allocate, free, and resize are unavailable. Calling them on DOS < 2.0 will fail silently. When resizing reduces a program's size in memory the function shouldn't fail so we should be able to ignore any errors.

A version of the program using GNU assembler that ensures we have 128KiB of free space for our program after the stack could look like this:

EXTRA_SIZE      = 128*1024     # Allocate 128KiB above stack
PARA_SIZE       = 16           # A paragraph = 16 bytes
EXTRA_SIZE_PARA = (EXTRA_SIZE+PARA_SIZE-1)/PARA_SIZE
                               # Extra Size in Paragraphs
COM_ORG         = 0x100        # Origin point for COM  program is 0x100

.code16
.global _start
.section .text

_start:
    # In a COM program CS=DS=ES=SS=0x0000. IP=0x100. The PSP is a 0x100 byte structure
    # between CS:0x0000 and CS:0x0100. DOS allocates the largest free block of
    # contiguous conventional memory from the DOS memory pool to our COM program. 
    # SS:SP grows down from the last paragraph allocated to us OR the top of the
    # 64kb segment, whichever is lower.
    #
    # At (DS:[0x0002]) is the segment (NEXTSEG) of the first byte  beyond the memory
    # allocated to our program. This means our program has been allocated all memory
    # between CS:0x0000 and NEXTSEG:0x0000

    # Get the next segment just above the top of the stack
    mov %sp, %bp               # BP = Current stack pointer
    mov $4, %cl                # Compute the segment just above top of stack
                               # Where extra data will be placed
    shr %cl, %bp               #     Divide BP by 16
    inc %bp                    #     and add 1

    # Compute a new program size including extra data area we want and
    # place it above the stack
    lea EXTRA_SIZE_PARA(%bp), %bx
                               # BX = Size (paragraphs) of Code/Data+Stack+Extra Data
    mov 0x0002, %ax            # Get the segment above last allocated
                               #     paragraph of our program from PSP @ [DS:0002]
    sub %bx, %ax               # Do we have enough memory for the extra data?
    jb .no_mem                 #     If not  display memory error and exit
    mov $0x4a, %ah             # Request DOS resize our program's memory block
    int $0x21                  #     to exactly the # of paragraphs we need.
    push %cs
    pop %bx                    # BX = CS (first segment of our program)
    add %bx, %bp               # BP = segment at the start of our extra data

    # Do stuff. Just an example:
    lea 0x0000(%bp), %si       # SI=segment of first 64KiB segment we allocated
    lea 0x1000(%bp), %di       # DI=segment of second 64KiB segment we allocated

    jmp .exit

.no_mem:
    mov $no_mem_str, %dx       # Have DOS print an error and exit.
    mov $9, %ah
    int $0x21

.exit:
    ret                        # We're done

no_mem_str: .asciz "Out of memory\n\r$"

_end:

A slightly more complex variant is to resize the stack we were given by default to a size that is suitable for our work, and then place the 128KiB of extra data after the stack. We need to compute the extent of our code and data to place the stack just beyond it, followed by the memory for the 128KiB of data. This code does just that using a 4096 byte stack:

STACK_SIZE = 4096              # Stack size = 4KiB
EXTRA_SIZE = 128*1024          # Allocate 128KiB above stack
PARA_SIZE  = 16                # A paragraph = 16 bytes
COM_ORG    = 0x100             # Origin point for COM  program is 0x100

.code16
.global _start
.section .text

_start:
    # In a COM program CS=DS=ES=SS=0x0000. IP=0x100. The PSP is a 0x100 byte structure
    # between CS:0x0000 and CS:0x0100. DOS allocates the largest free block of
    # contiguous conventional memory from the DOS memory pool to our COM program. 
    # SS:SP grows down from the last paragraph allocated to us OR the top of the
    # 64kb segment, whichever is lower.

    # At (DS:[0x0002]) is the segment (NEXTSEG) of the first byte  beyond the memory
    # allocated to our program. This means our program has been allocated all memory
    # between CS:0x0000 and NEXTSEG:0x0000
    
    push %ds
    pop %cx                    # CX = Segment at start of our program
    mov %cx, %bp               # BP = A copy (for later) of program starting segment
    mov $PROG_SIZE_PARA, %bx   # BX = number of paragraphs of EXTRA memory to allocate 
    add %bx, %cx               # CX = total number of paragraphs our program needs
    mov 0x0002, %ax            # AX = next segment past end of our program
                               #     retrieved from our program's PSP @ [DS:0002]
    sub %cx, %ax               # Do we have enough memory to satisfy the request?
    jb .no_mem                 #     If not  display memory error and exit
    mov $0x4a, %ah             # Request DOS resize our programs memory block
    int $0x21                  #     to exactly the # of paragraphs we need.

    mov $STACK_TOP_OFS, %sp    # Place the stack after non-BSS code and data
                               #     and before the BSS (Extra) memory
    xor %ax, %ax               # Push a 0x0000 return address as DOS does for us
    push %ax                   #     when initializing our program. Memory address
                               #     CS:0x0000 contains an Int 20h instruction to exit
    add $EXTRA_SEG, %bp        # BP = segment where our extra data areas starts

    # Do stuff. Just an example:    
    lea 0x0000(%bp), %si       # SI=segment of first 64KiB segment we allocated
    lea 0x1000(%bp), %di       # DI=segment of second 64KiB segment we allocated

    jmp .exit

.no_mem:
    mov $no_mem_str, %dx       # Have DOS print an error and exit.
    mov $9, %ah
    int $0x21

.exit:
    ret                        # We're done

no_mem_str: .asciz "Out of memory\n\r$"

_end:

# Length of non-BSS Code and Data
CODE_DATA_LEN   = _end-_start

# Segment number after the PSP/code/non-BSS data/stack relative to start of program
EXTRA_SEG       = (CODE_DATA_LEN+COM_ORG+STACK_SIZE+PARA_SIZE-1)/PARA_SIZE

# Size of the total program in paragraphs
PROG_SIZE_PARA  = EXTRA_SEG+EXTRA_SIZE_PARA

# New Stack offset(SP) will be moved just below extra data
STACK_TOP_OFS   = EXTRA_SEG*PARA_SIZE

# Size of the extra memory region in paragraphs
EXTRA_SIZE_PARA = (EXTRA_SIZE+PARA_SIZE-1)/PARA_SIZE

These samples can be assembled and linked to a program called myprog.com with:

as --32 myprog.s -o myprog.o
ld -melf_i386 -Ttext=0x100 --oformat=binary myprog.o -o myprog.com

---

Allocating 128KiB in a DOS EXE Program

The DOS loader also loads EXE programs (they have an MZ header). The MZ header contains program information, relocation tables, stack, entry point, and minimum and maximum memory allocation requirements beyond the data physically present in the executable file. Segments with entirely uninitialized data (including but not limited to BSS and Stack segments) don't occupy space in the executable file, but the DOS loader is told to allocate extra memory through the MINALLOC and MAXALLOC header fields:

MINALLOC. This word indicates the minimum number of paragraphs the program requires to begin execution. This is in addition to the memory required to hold the load module. This value normally represents the total size of any uninitialised data and/or stack segments that are linked at the end of a program. This space is not directly included in the load module, since there are no particular initialising values and it would simply waste disk space.

MAXALLOC. This word indicates the maximum number of paragraphs that the program would like allocated to it before it begins execution. This indicates additional memory over and above that required by the load module and the value specified by MINALLOC. If the request cannot be satisfied, the program is allocated as much memory as is available

MINALLOC is the number of paragraphs above the code and data in the EXE itself that are required. MAXALLOC is always at least equal to MINALLOC but if (MAXALLOC > MINALLOC) then DOS will attempt to fulfill the request for the additional paragraphs (MAXALLOC-MINALLOC). If that request can't be honoured then DOS will allocate all the available space it does have. Often the extra memory between MAXALLOC and MINALLOC is called the HEAP by many tools and programming languages.

It is worth noting that it is the final linking process that generates the executable that sets MINALLOC and MAXALLOC. Often the linker by default sets MAXALLOC to 0xffff effectively requesting the HEAP take up as much contiguous space as DOS can allocate. The EXEMOD program was designed to allow this to be changed:

EXEMOD

EXEMOD displays or changes fields in the DOS file header. To use this utility, you must understand the DOS conventions for file header

[snip]

/MIN n Sets the minimum allocation value to n, where n is a hexadecimal value setting the number of paragraphs. The actual value set may be different from the requested value if adjustments are necessary to accommodate the stack.

/MAX n

Sets the maximum allocation to n, where n is a hexadecimal value setting the number of paragraphs. The maximum allocations value must be greater than or equal to the minimum allocation value. This option has the same effect as the linker parameter ICPARMAXALLOC.

In DOS < 2.0 that didn't have the concept of memory control blocks, using EXEMOD was the method to change the additional memory requirements of a DOS executable. In DOS 2.0+ a program (at run-time) can allocate new memory, resize memory, and free memory through DOS Int 21h functions.

For this discussion the 128KiB of extra memory is required by the program so the examples will place that data in the uninitialised data. The linking/executable generation process will adjust MINALLOC field in the MZ header by adding the extra paragraphs needed.

The first example of a DOS program that wishes to allocate 128KiB (two 64KiB segments placed one after the other) is written in FASM assembly:

format MZ                      ; DOS EXE Program

stack 4096                     ; 4KiB stack. FASM puts stack after BSS data

entry code:main                ; Program entry point (seg:offset)

segment code
main:
    push ds
    pop ax
    mov bx, EndSeg
    sub bx, ax                 ; BX = size of program in paragraphs (EndSeg-DS)
    mov ah, 4ah                ; Resize to the number of paragraphs we need
    int 21h                    ;     because the DOS loader sometimes allocates slightly
                               ;     more than our actual program requirements

    ; Do Stuff. Just an example:    
    mov si, ExtraSeg1          ; SI=segment of first 64KiB segment we allocated
    mov di, ExtraSeg2          ; DI=segment of second 64KiB segment we allocated

    mov ax, 4c00h              ; We're done, have DOS exit and return 0
    int 21h

segment ExtraSeg1
rb 65536                       ; Reserve 65536 uninitialized "bytes" in BSS area

segment ExtraSeg2
rb 65536                       ; Reserve 65536 uninitialized "bytes" in BSS area

segment EndSeg                 ; Use this segment to determine last segment of our program
                               ;     Segments with no data will be put in BSS after
                               ;     other BSS segments

A version that should work with most releases of MASM/JWASM/TASM would look like:

.model compact, C              ; Multiple data segments, one code segment
.stack 4096                    ; 4KiB stack

; fardata? are uninitialized segments (like BSS)
.fardata? ExtraSeg1            ; Allocate first 64KiB in a new far segment
db 65535 DUP(?)                ; Some old assemblers don't support 65536! Set to 65535
                               ; The next segment will be aligned to a paragraph boundary
                               ; Uninitialized data `?` will not be physically in our EXE

.fardata? ExtraSeg2            ; Allocate second 64KiB in a new far segment after first
db 65535 DUP(?)                ; Some old MASM assemblers don't support 65536! Set to 65535
                               ; The next segment will be aligned to a paragraph boundary
                               ; Uninitialized data `?` will not be physically in our EXE


.fardata? EndSeg               ; Use this segment to determine last segment of our program
                               ;     Segments with no data will be put in BSS after
                               ;     other BSS segments
.code
main PROC
    push ds
    pop ax
    mov bx, EndSeg
    sub bx, ax                 ; BX = size of program in paragraphs (EndSeg-DS)
    mov ah, 4ah                ; Resize to the number of paragraphs we need
    int 21h                    ;     because the DOS loader sometimes will allocate 
                               ;     slightly more than our actual program requirements

    ; Do Stuff. Just an example:
    mov si, ExtraSeg1          ; SI=segment of first 64KiB segment we allocated
    mov di, ExtraSeg2          ; DI=segment of second 64KiB segment we allocated

    mov ax, 4c00h              ; We're done, have DOS exit and return 0
    int 21h
main ENDP

END main                       ; Program entry point is main

---

Footnotes:

• ¹When there is less than 64KiB of free memory available left to DOS, SP will be set to grow down from an offset below the top of DOS's available free memory. When there is 64KiB or more of free memory available the DOS loader sets SP to 0x0000. In the case of >= 64KiB of free memory available the first push of data (the return address 0x0000) wraps SP to the top of the segment at 0xfffe (0x0000-2). This is a real mode quirk: if you set SS:SP to SS:0x0000 the first value pushed will be placed at SS:0xFFFE at the top of the SS segment.
• ²Although 0xa000:0x0000 is often seen as the upper end of the contiguous conventional memory usable by DOS it doesn't necessarily have to be that way. Some memory managers (JEMMEX, QEMM, 386Max to name a few) and their tools that can successfully move the EBDA (on equipment where that doesn't cause problems) and can be told that the VGA/EGA memory at 0xa000:0x0000 to 0xa000:0xffff is unused can move the upper end of contiguous memory for DOS allocations to 0xb000:0x0000. It is even possible in a headless (no video) configuration to have even more. A 386 memory manager that does this usually runs DOS in v8086 mode and remaps extended memory (using the 386's support for paging) into the unused areas between 0xa000:0x0000 and 0xf000:0xffff.

Caduceus

Thank you for this detailed answer. Does your fourth bullet point mean that SS &ne; CS could be the case on program start if the machine has insufficient RAM? I always assumed that in such cases, SS = CS but SP starts out at some value other than FFFE. – Crew

@Crew : I'll have to clean that up a bit to remove the ambiguity. When a COM program is loaded into memory the DOS loader always sets SS=DS=ES=CS. It is only SP that will change. Actually in the case where ta full 64KiB is free the stack value starts at 0x0000 but DOS pushes a 2 byte return value (0x0000) automatically for us so by the time we see it SP appears to be 0xFFFE (0x0000-2) – Caduceus

This is great, thanks! – Lory

Answer 3

If we start a program DOS give all of the free memory to the program and so we have to give it back to DOS before we can request new memory. The first step is to calculate the needed memory of our programm and give the rest back to DOS. This part we have to place in the beginning of our program, before SS, SP and ES are manipulated.

mov      bx, ss
mov      ax, es
sub      bx, ax
mov      ax, sp
add      ax, 0Fh
shr      ax, 4
add      bx, ax
mov      ah, 4Ah
int    21h

The next step is to request new memory.

mov      bx, 2000h ; 128 KB
mov      ah, 48h
int    21h
jc  NOSPACE
; AX = segment address

Walczak

Thank you for your answer. In a COM program, cs = ds = es = ss on startup, so is the first snippet actually needed? – Crew

@FUZxxl: In a .COM program not, because a .COM program is one segment only by default. Only .EXE programs can have multiple segments. So a .COM is limited to 64kb. – Aureus

The calculation is for an *.exe (MZ) file that contains different segment addresses for the code, data and for the stack segment on startup. But also for a COM program we have to give back the rest of memory, before we can request new memory. – Walczak

@DirkWolfgangGlomp Why would you request memory that you already had? There's no need to first release memory and then later request it. The OP best keeps the 128KB from what he got at the start. – Proustite

We have to give the free memory back to DOS with 4Ah int 21h before we can request new memory with 48h int 21h, because we do not exactly know which segments are free and which are not. It is not safe that the following 128 KB after the program is free. Only with 48h int 21h we have the guarantee that the requested amount of memory is free to use, if the carry flag is not set after calling. – Walczak

One last question: If I don't use int 21/48, can I just use all the memory from CS:0000 to A000:0000 for my program? – Crew

shr ax, 4 is a 186+ instruction. And the add ax, 0Fh can carry. (Usually will do so for COM format programs even.) Better to use a different sequence of instructions like I did in one of my programs: add ax, 15 \ jnc .no_carry \ mov ax, 10000h >> 1 \ jmp .had_carry \ .no_carry: \ shr ax, 1 \ .had_carry: \ shr ax, 1 \ shr ax, 1 \ shr ax, 1 (In the linked example there's an additional displacement in the addition and I used a skipping instruction.) – Phenology

Answer 4

You can get any segment you want by setting one of the segment registers to the desired value. But keep in mind that

• each segment starts at a 16-byte boundary meaning that a segment of 0400(offset :0000) would be equal to a segment of 0040(offset :3c00) and to another one of 0000(offset :4000) and so on
• these ranges overlap, that means that an increase of one in the segment register increases the absolute memory address by 16.
• which ranges are preset and used by the BIOS or other peripherals is elaborated on in the other answer by David Hoelzer
• make sure your segment is of 64kb size and it does not overlap with other segments

Aureus