This is an issue I've been facing since the very beginning. Like the segment issue I've posted here, the issue relates to .com files, and more specifically, how memory is allocated. To recap, .com files are allocated a chunk of memory that has the fixed size of 64k. This is one memory segment. It uses up the whole 64k, no matter how big or small the file is. Hence, it's impractical (but not impossible!) to allocate memory.
For my graphics library, the BGL, I resorted to using the Program Segment Prefix, which at offset 2-3, contains the address of the segment after the end of the program. Using a cheeky trick, I was able to subtract the amount of bytes I wanted for the graphics buffer, and use the resulting address. It does work, but it isn't the "proper" way of doing it. For that, we need to use .exe files. Because they don't deal with memory the same way as .com files, we can use the BIOS call Int 21h/AH=48h. Or so I thought...
So, here's the mistake I was making. I was simply using that BIOS call and expecting it to just work, which is quite a naive approach. If you do that, the carry flag will be set, and you'll get error code 8, which means "insufficient memory", which just isn't true! What I realized, is that you first need to use Int 21h/AH=4Ah, which resizes a memory block to whichever size you like, granted there's enough available. Then, once you've got some memory freed up, use Int 21h/AH=48h to allocate some memory, and if all goes well, you'll get the segment address in ax, ready to move to es!
No comments:
Post a Comment