Index
> DOS > Working with segments in MZ executable |
| Author |
|
|
freecrac 08 Dec 2011, 03:45
Trinitek wrote: Alright guys, I'm having a bit of trouble here. My COM program got so big that I had to switch over to the MZ format, and there's only one problem with that. With searching for "mov data flat assembler" it is easy to find an answer, because the second result pointed to this thread: http://board.flatassembler.net/topic.php?t=12588 Dirk |
|||
08 Dec 2011, 03:45 |
|
|
Trinitek 08 Dec 2011, 03:56
freecrac wrote:
I had searched before I posted, but apparently I wasn't using the right keywords.  Thanks a lot!
Now for one more question: I can't directly push the segment Data into the stack like how I have it written in my example? Not that it's a problem, but I'd like to know for future reference. |
|||
|
08 Dec 2011, 03:56 |
|
|
freecrac 08 Dec 2011, 05:04
Trinitek wrote: Now for one more question: I can't directly push the segment Data into the stack like how I have it written in my example? Not that it's a problem, but I'd like to know for future reference. mov ax, Data mov ds, ax push ax ; only if you need Dirk |
|||
|
08 Dec 2011, 05:04 |
|
|
Tomasz Grysztar 08 Dec 2011, 06:43
Trinitek wrote: Now for one more question: I can't directly push the segment Data into the stack like how I have it written in my example? Not that it's a problem, but I'd like to know for future reference. Code: format MZ heap 0 entry Main:Start segment Main use16 Start: push DataSeg pop DS segment DataSeg use16 text_string DB "Here's some data.",0 |
|||
|
08 Dec 2011, 06:43 |
|
|
freecrac 08 Dec 2011, 10:41
Tomasz Grysztar wrote: You can directly push the segment value, the problem here is that you use a reserved keyword "data", which for fasm means something different. Just rename the segment to avoid this problem: Ah, good to know how to solve this problem. Quote:
But i think only for to store a segment address into a segment register we did not need to access the stack. I think it is often better to use only register for to do this instead, to prevent a slow ram access to the stack. Dirk |
|||
|
08 Dec 2011, 10:41 |
|
|
AsmGuru62 08 Dec 2011, 15:12
So, how exactly the COM got big? Just curious, because, there are a lot of memory there if I recall - about 550K which laid out AFTER the COM image ends (CS + 64Kb is where it begins). You can plan it as you go. Load files there or whatever. Do you have a lot of strings? You can load strings from a file. etc.
If all I assume is false, then just your code must have got to over 64Kb - very impressive! How much time you coded it? |
|||
|
08 Dec 2011, 15:12 |
|
|
Trinitek 10 Dec 2011, 18:53
AsmGuru62 wrote: So, how exactly the COM got big? Just curious, because, there are a lot of memory there if I recall - about 550K which laid out AFTER the COM image ends (CS + 64Kb is where it begins). You can plan it as you go. Load files there or whatever. I wasn't aware at the time that I could do this. I'll have to look into it sometime... Quote: Do you have a lot of strings? You can load strings from a file. etc. I'm working with a bitmap image that takes up about 65,000 bytes. I also have a few text strings thrown in there as well. I kept going over the memory limit by only a few bytes which kept cutting off the last few pixels on the image when it writes it to the screen and I couldn't optimize the code any further to try to get it to fit. But now that I've switched over to the MZ model, there aren't any problems now. Everything is working like it's supposed to.  |
|||
|
10 Dec 2011, 18:53 |
|
|
AsmGuru62 11 Dec 2011, 00:49
Cool stuff!
|
|||
|
11 Dec 2011, 00:49 |
|
< Last Thread | Next Thread > |
Forum Rules:
|