VOGONS


First post, by merser

User metadata
Rank Newbie
Rank
Newbie

Hi,

I am working through Peter Nortons Assembly language book for the IBM and there is a project that is built as you proceed called dskpatch which allows inspecting sectors of a disk and editing them.
I have been using dosbox to test as I don't have original hardware that this book was written for(8088/86). What I am having trouble with is the program assembles and links ok. This I have verified in hexedit. But it fails to run correctly because dosbox loads it into memory 100h higher than is required. This affects memory holding variables and any LEA instruction.
I have been using hexedit to correct the com file addresses but as the project has grown it has become tedious.
Could anyone suggest why the com is loaded at 0200h offset instead of 0100h offset which I believe is the normal loading address for dos binary executables?
Or any workaround that doesn't involve me changing contents of a multitude of memory addresses after each incremental change?

Reply 2 of 8, by merser

User metadata
Rank Newbie
Rank
Newbie
CGROUP	GROUP	CODE_SEG, DATA_SEG
ASSUME CS:CGROUP, DS:CGROUP

CODE_SEG SEGMENT PUBLIC
ORG 100h

EXTRN CLEAR_SCREEN:NEAR, READ_SECTOR:NEAR
EXTRN INIT_SEC_DISP:NEAR, WRITE_HEADER:NEAR
EXTRN WRITE_PROMPT_LINE:NEAR, DISPATCHER:NEAR
DISK_PATCH PROC NEAR
CALL CLEAR_SCREEN
CALL WRITE_HEADER
CALL READ_SECTOR
CALL INIT_SEC_DISP
LEA DX,EDITOR_PROMPT
CALL WRITE_PROMPT_LINE
CALL DISPATCHER
INT 20h
DISK_PATCH ENDP

CODE_SEG ENDS

DATA_SEG SEGMENT PUBLIC
PUBLIC SECTOR_OFFSET
;---------------------------------------------------------------;
;SECTOR_OFFSET is the offset of the half sector display into ;
;the full sector. It must be a multiple of 16, and not greater ;
;than 256. ;
;---------------------------------------------------------------;
SECTOR_OFFSET DW 0

PUBLIC CURRENT_SECTOR_NO, DISK_DRIVE_NO
CURRENT_SECTOR_NO DW 0 ;Initial sector 0
DISK_DRIVE_NO DB 0 ;Initial drive A:

PUBLIC LINES_BEFORE_SECTOR, HEADER_LINE_NO

PUBLIC HEADER_PART_1, HEADER_PART_2
;---------------------------------------------------------------;
;LINES_BEFORE_SECTOR is the number of lines at the top of the ;
;screen before the half sector display. ;
;---------------------------------------------------------------;
LINES_BEFORE_SECTOR DB 2
HEADER_LINE_NO DB 0
HEADER_PART_1 DB 'DISK ',0
HEADER_PART_2 DB ' SECTOR ',0
PUBLIC PROMPT_LINE_NO, EDITOR_PROMPT
PROMPT_LINE_NO DB 21
EDITOR_PROMPT DB 'Press function key, or enter'
DB ' character or hex byte: ',0
PUBLIC SECTOR
;---------------------------------------------------------------;
;The entire sector (up to 8192 bytes) is stored in this part ;
;of memory ;
;---------------------------------------------------------------;
SECTOR DB 8192 DUP (0)

DATA_SEG ENDS

END

Reply 4 of 8, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

If the COM file is assembled and linked correctly then the first three bytes in it should be the near jump to the CLEAR_SCREEN procedure. However, the 200h entry point you mention suggests you have made something other than a COM format program file, because DOS (and DOSBox's internal emulation of DOS) will always use an offset of 100h for a COM file entry point.

Reply 5 of 8, by merser

User metadata
Rank Newbie
Rank
Newbie

In file explorer properties it is called an ms-dos application (com)
Here is a screen capture of hexedit and debug showing correct offset in hexedit but wrong in debug. The LEA is pointing to 053F but the data is actually at 063F I have been using hexedit to change all these points and it then works. I have also tried with small helloworld com files and same thing happens even if only one module is assembled into a com file. I use exe2bin to convert the compiled and linked exe to a com file.

https://drive.google.com/file/d/1FwoUyWDwOlFC … ?usp=share_link

https://drive.google.com/file/d/1TKEzx56MbCxV … ?usp=share_link

https://drive.google.com/file/d/1CX0V8hN-wl0u … ?usp=share_link

Reply 8 of 8, by merser

User metadata
Rank Newbie
Rank
Newbie

Ok, found the reason why it compiled with the leading zeros. In the main file dskpatch.asm I had the end directive but changing it to end disk_patch solved the issue.
disk_patch being the name of the main procedure in dskpatch.asm. All references link correctly now as it loads into memory as it should. Funny it didn't trigger any errors on assembling or linking.