Q:

Using 32 bit registers in MASM without changing the default segment definition size

My code is too slow for 8086 & 80286 processors so i've decided to make use of 32 bit registers and instructions in my real mode code.
I know that all I really need to be able to do is prefix indiviual instructions with 66h, but 386 registers aren't accepted by MASM if you don't include the .386 directive at the very top of the assembly file.
After doing this, I found that my program no longer functioned, even if i'm not using any 386 registers. It hangs at a black screen and then DOSBox crashes. This is behavior typically indicative of a stack crash and memory corruption in my program.
In the documentation for MASM 5.10 (the version I use) I found this information: "If you use the .386 directive before the .MODEL directive, the segment
definitions defines 32-bit segments. If you want to enable the 80386 proces­sor with 16-bit segments, you should give the .386 directive after the .MODEL directive."
I'm pretty sure that's my issue here, I need to include a .MODEL directive that 
will ensure that segments remain 16-bit. I tried including all of the listed .MODEL directives (documentation refers to them as the most common models) in my main assembly file before using the .386 directive. They all produce errors, which I believe may be caused by the fact that i'm not including the .MODEL directive in any of the other dozen assembly files that make up my program. I just want to continue using the default .MODEL, whatever it may be.
I have never needed to use a .MODEL directive until now, the documentation doesn't mention which is used by default, or which keeps 16-bit segments intact when .386 is used.
.MODEL SMALL, .MODEL MEDIUM, and  .MODEL COMPACT all produce many linker errors that look like this: error L2002: fixup overflow at 0016 in segment CODE pos: 1FA Record type:48A8 
.MODEL LARGE, and .MODEL HUGE assemble and link just fine, but crash my program a few frames later with some garbage dumped into video memory, probably a stack crash. Again i'm not including .MODEL directives in any of my other dozen assembly files at the moment.
What I want is to occasionally be able to use 386 registers and instructions, but otherwise I want the program to behave exactly the same as it always has. Treating all segments and such as 16-bit. 
Here is my main assembly file, i'm not quite sure which model this is. Large, maybe? No single segment is larger than 64k, so maybe not. There is a single stack segment and a single code segment, but several data segments. All of which are public and shared throughout the assembly files that make up the program.
theStack SEGMENT STACK                                                     

 db 64 dup ('THESTACK') ;512 byte stack  

 theStack ENDS                                                              

 varData SEGMENT PUBLIC                                                                                

 INCLUDE const.inc     ;global constants

 PUBLIC fCntr

 fCntr db 0            ;A frame counter used to delay animations.

 varData ENDS                                                               

 frame SEGMENT PUBLIC                                                       

 db scrArea dup (247d)  ;64,000 byte frame buffer

 frame ENDS                                                                 

 field SEGMENT PUBLIC                                                       

 db 65535 dup ('F')     ;64k buffer that holds up to 32,768 tile indexes

 field ENDS                                                                 

 sprites SEGMENT PUBLIC                                                     

 db 65535 dup ('S')     ;64k buffer for animated spites

 sprites ENDS                                                                                                                           

 code SEGMENT PUBLIC

 EXTRN SET_VGA_256:PROC,INIT_DISK_VARS:PROC,INIT_AREA:PROC,CALC_DELAY:PROC
 EXTRN HANDLE_INPUT:PROC,UPDATE_SPRITES:PROC,DRAW_SPRITES:PROC
 EXTRN DRAW_FIELD:PROC,WRITE_FRAME:PROC,FRAME_DELAY:PROC,EXIT2DOS:PROC
 EXTRN DBG:PROC                    

 assume cs:code,ds:varData                                              

 main PROC                                                                  

 start:                                                                      

    mov ax, varData                            
    mov ds, ax               ;Load the variable segment into ds                                            
    cld                      ;ensure that string operations auto-increment

    call SET_VGA_256         ;Set the video mode to 320x200 256 colors.
    call INIT_DISK_VARS      ;Setup hard drive access variables
    call INIT_AREA           ;Build the area into memory from data files
    call CALC_DELAY          ;calculate the frame delay using the RTC

LOOP_TILL_ESC:
    call HANDLE_INPUT        ;Handle user input.
    call UPDATE_SPRITES      ;bounds check then move the sprites
    call DRAW_FIELD          ;draw the tiles that make up the play field 
    call DRAW_SPRITES        ;draw all currently visible sprites
    call WRITE_FRAME         ;Write the frame buffer to video memory.
    inc fCntr                ;increment the frame counter
    call FRAME_DELAY         ;delay for the specified number of milliseconds
    cmp bp, 1                ;Was the Esc key pressed?
    jne LOOP_TILL_ESC        ;If not, loop back through the main program.
    call EXIT2DOS            ;If so, return to DOS.

 main ENDP                                                                  

 code ENDS                                                                  

 END start            

And here's a simple program that breaks if .386 is used. It's supposed to fill the screen with pink pixels, but instead it hangs at a black screen and crashes DOSBox.
.MODEL SMALL
.386

theStack SEGMENT STACK                                                     

db 64 dup ('THESTACK')   

theStack ENDS                                                              

code SEGMENT PUBLIC

assume cs:code,ds:varData                                              

main PROC                                                                  

start:                                                                      

    mov ax, varData                            
    mov ds, ax                   ;Load the variable segment into ds                                            
    cld                          ;ensure that string ops auto-increment

    xor ah, ah                   ;select set video mode function
    mov al, 13h                  ;320x200 256 colors
    int 10h                      ;video mode set 

    mov di, 0a000h               
    mov es, di
    xor di, di                   ;es:di -> vga pixel buffer
    mov ah, 64d
    mov al, ah                   ;ah & al -> pink color index byte
    mov cx, 32000d               ;writing 32,000 words
    rep stosw                    ;fill the screen with pink pixels

ESC_LOOP:
    in al, 60h
    cmp al, 1
    jne ESC_LOOP                 ;delay till escape key is pressed

    mov ax, 40h
    mov es, ax                   ;access keyboard data area via segment 40h
    mov WORD PTR es:[1ah], 1eh   ;set the kbd buff head to start of buff
    mov WORD PTR es:[1ch], 1eh   ;set the kbd buff tail to same as buff head
                                 ;now the keyboard buffer is cleared.
    xor ah, ah                   ;select video mode function
    mov al, 3                    ;select 80x25 16 colors
    int 10h                      ;restore VIDEO back to text mode

 mov ah, 4ch                     ;Terminate process DOS service
 xor al, al                      ;Pass 0 to ERRORLEVEL
 int 21h                         ;Control returns to DOS

 main ENDP                                                                  

 code ENDS                                                                  

 END start                             

A:

Your description of problem is not 100% correct, but your "pink" sample source in question is good example to explain it fully.
The .MODEL directive belongs to the "simplified segment directives", together with .CODE, .CONST, .DATA, .DATA?, .FARDATA, .FARDATA?, .STACK.
So one way of using these in working fashion and 16b DOS executable is like this:
.MODEL SMALL
.386

.STACK 100h

.DATA
x   DB  1

.CODE
start:
    mov     ax,@DATA
    mov     ds,ax
    movzx   eax,BYTE PTR [x]

    mov     ah,4Ch
    int     21h
END start

Using only the simplified directives exclusively, the .CODE will define code segment named _TEXT, which is 16b real mode code segment (thanks to the .386 directive being put after .MODEL SMALL directive).
Your "pink" example doesn't use the simplified segment directives, but full ones, then you must specify in the code segment definition it is for real mode, like in next fixed source, which will fill screen first with pink colour (using 16b registers), and then after some key with cyan colour (using 32b registers in real mode).
I had to add USE16 to the code SEGMENT directive, to set it up correctly, then the produced 32b instructions are prefixed in correct way for 16b real mode (i.e. the other way than in 32b protected mode).
I did further test what will happen when you mix that explicit code segment definition with simplified .CODE directive, and surprisingly (to me) the final .exe has two code segments, even with .MODEL SMALL model... So the test procedure in "dotCode" segment can be reached only through FAR call. At least the .CODE segment is correctly assigned as 16b segment, so the produced assembly works as expected.
Fixed example (tested with TASM 4.1 + TLINK, just run with name of file and no options, ASM -> OBJ -> EXE files should be produced):
.MODEL SMALL
.386

theStack SEGMENT USE16 STACK

db 64 dup ('THESTACK')

theStack ENDS

; test of simplified code segment directive
.CODE
testDotCode PROC
    mov     eax,12345678h
    retf
testDotCode ENDP
ENDS

code SEGMENT USE16 PUBLIC

assume cs:code, ss:theStack

main PROC
    call    FAR PTR testDotCode ; test code inside simplified code segment definition
    ; with experiment I find out, that even with ".MODEL SMALL" the TASM+TLINK will
    ; put the testDotCode subroutine into new "_TEXT" code segment!
    ; So only FAR call + retf works to access it.

    cld                         ; ensure that string ops auto-increment
    mov     ax, 13h             ; select set video mode function: 13h 320x200 256 colors
    int     10h                 ; video mode set

    mov     di, 0a000h
    mov     es, di              ; es = VRAM segment

    ; original 16b test code - fill screen with pink
    xor di, di                  ;es:di -> vga pixel buffer
    mov ah, 64d
    mov al, ah                  ;ah & al -> pink color index byte
    mov cx, 32000d              ;writing 32,000 words
    rep stosw                   ;fill the screen with pink pixels

    ; wait for any key
    xor     ah,ah
    int     16h

    ; 32b test code to validate ".386" setup success in real mode
    xor     di, di              ; es:edi -> vga pixel buffer
    mov     eax, 34343434h      ; eax = 4x cyan color
    mov     ecx, 320*200/4      ; full screen fill
    rep stosd                   ; fill the screen with pink pixels

    ; wait for any key
    xor     ah,ah
    int     16h

    ; restore text mode (3)
    mov     ax,3                ; select video mode: text 80x25 16 colors
    int     10h

    mov     ax,4C00h            ; terminate DOS process with 0 ERRORLEVEL
    int     21h
main ENDP

code ENDS

END main

I used mostly this web page as source for these details: http://www.c-jump.com/CIS77/ASM/Directives/lecture.html#D77_0070_code_directive
And this answer is not exhaustive replacement of proper TASM/MASM documentation, unfortunately, just (hopefully complete) explanation what caused your problems.

