Hi all.
As a result of changing to "Unreal" mode, I now have a problem where I need to save text mode screens to memory.
The code that I have written works, however on rewriting the screen (from far memory to &h0b800) the screen
gets rewritten but hangs on completion of this rewrite.
The cursor is flashing in location 1,1
Because this is done on a Dos box with "Unreal" installed I cant debug it using codeview.
Anybody have any ideas.
;-----------------------------------------------------------------------------
; Scrn1Put.asm is A SUB for saving a screen of data to unreal Flat memory
;-----------------------------------------------------------------------------
.MODEL MEDIUM
.486
.CODE
PUBLIC Scrn1Put
;--------------------------------------
Scrn1Put PROC FAR
PUSH BP
MOV BP,SP
;---------
PUSH EAX
PUSH ECX
PUSH EDI
PUSH ESI
;----------
PUSH DS
PUSHF
XOR EAX,EAX
MOV DS,AX
MOV CX,2000
MOV EDI,000B8000H
MOV ESI,00110000H
SLOOP:
MOV AX,word ptr DS:[ESI]
MOV word ptr DS:[EDI],AX
ADD EDI,2
ADD ESI,2
LOOP SLOOP
POPF
POP DS
;----------
POP ESI
POP EDI
POP ECX
POP EAX
;---------
POP BP
RET 2
Scrn1Put ENDP
END
This simple code works. Scrn1Get is identical except for swap of EDI,ESI
I suspect that it is related to the cursor.
Regards
Is there a problem with the removal of Tabs. in code examples ?
What is the reason for the stack adjustment on the RET instruction? At least normally, unless you are pushing something onto the stack before the call this adjustment will cause a stack imbalance. And if this procedure is called from another procedure, the position of calling procedure's return address on the stack will be altered, and the procedure will return to the wrong address.
SMF apparently has a problem handling embedded tabs in posted code.
http://www.masmforum.com/simple/index.php?topic=126.msg579#msg579
Michael
There is one parameter pushed onto the stack.(although not used in this example)
I always check in codeview that the stack is returned to the state before the call.
That's why the hangup puzzles me.
Regards
codeview may not work, but what about using debug? The one included in freedos is even able to show 32bit ops. Setting a breakpoint at the end of the proc should give a hint.
Hi all
In the end this problem was easy IF you work with far memory all the time.
The A20 line was not switched on.
With the industrial pc boards I use the only option is
to switch it fast or normal.
Anyhow it now works.
Thanks for your help
Regards
Dinosaur