• Please review our updated Terms and Rules here

Code Relocation: From ROM to RAM for Execution

mmruzek

Experienced Member
Joined
Sep 28, 2011
Messages
232
Location
Michigan, USA
OK, I have been working on this way too long, and can't figure it out... The project started with rewriting Palo Alto Tiny Basic to remove all the INT calls to DOS functions by replacing them with calls to BIOS functions instead. I have that part working. Now I want to write a short assembly language program to relocate the working code from ROM to RAM and execute. The way that I decided to do this is to put a small snippet of code at the first executable ROM address (F600:0000) and have it copy all the Palo Alto Basic program code starting at F600:0100 to a RAM location, for example 0500:0100. The idea is that when the PC does not find DOS, it will trigger INT 18 for the BASIC and instead will find my code and do a relocation and then a far jump to execute.

When I burn a ROM and try this, the Palo Alto program puts garbled text on the screen, and I have determined the welcome message in Palo Alto is being pulled from a memory location that is wrong by about 126 bytes. (?). However, if I boot DOS and go into DEBUG and issue a G=F600:0000 the whole thing works perfectly! Here is one of about 20 coding attempts to do this simple task:

MOV AX,0510
MOV ES,AX
MOV AX,F610
MOV DS,AX
MOV CX,0FFF
REPZ
MOVSW
MOV AX,0500
MOV DS,AX
MOV ES,AX
JMP 0500:0100
 
Hi, Yes, I have tried initializing everything I could think of. Here is some source code for a different attempt at it:

MOV AX,0510
MOV ES,AX
MOV AX,F610
MOV DS,AX
MOV CX,0FFF
REPZ
MOVSW
MOV AX,0500
MOV DS,AX
MOV ES,AX
MOV SS,AX
MOV AX,0
MOV BX,0
MOV CX,0
MOV DX,0
MOV SI,0
MOV DI,0
JMP 0500:0100
 
So what code lies in the 256 bytes from F6000 to F6100?

The only code I have in that space is the relocation code. Nothing else. It's about 20 or 30 bytes, depending on what 'fix' I'm trying to get work. I am using a 100H offset, because I understand that to be the norm for COM files.
 
So back to the original code. Why is not SI and DI explicitly zeroed at the beginning? Yes, COM files are loaded at 100h bytes into the code segment/PSP address.
 
So back to the original code. Why is not SI and DI explicitly zeroed at the beginning? Yes, COM files are loaded at 100h bytes into the code segment/PSP address.

Whoops, I was assuming SI and DI would start at zero by default when moving the code... let me try that... Unfortunately, I'm away from my hardware and it will take me about a day. Thanks, Michael
 
Whoops, I was assuming SI and DI would start at zero by default when moving the code... let me try that... Unfortunately, I'm away from my hardware and it will take me about a day. Thanks, Michael

Initializing SI and DI to zero before doing the memory transfer works perfectly. Thank You! I can't believe I spent that much time trying to figure out was wrong, when it was such a simple mistake. Guess that's a lesson I'll never forget! Much appreciated. Michael

PS. I'm getting darn close to posting a Beta version of the code for running the Palo Alto Tiny Basic from ROM on an IBM PC.
 
Nice. It's always the simple things that bite.

I always get worried when I compile code for the first time with no errors.. it's always an omen that it will crash.
 
Back
Top