Jump to content
  • Advertisement
Sign in to follow this  
lack o comments

16-bit programming HELL!

This topic is 4905 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was sifting through some old 16-bit C++ code (helping someone new to programming and they are currently learning very old material) when I came across a problem I've never encountered before (probably because I moved to 32-bit long before then). I need to allocate a buffer larger than 64k, but every time I try, the data seems to become corrupted. I've tried everything I know: Using far/huge pointers. Setting the compiler to use the 'large' memory model. Using 'farmalloc()' instead of 'new' or 'malloc()'. Shaking my fists while threatening the compiler and cursing segments and offsets. Nothing seems to work. Can anyone please give some insight as to what I may be doing incorrectly? Thanks in advance

Share this post


Link to post
Share on other sites
Advertisement
Never really worked in a 16-bit environment.

But perhaps it has something to with the fact that with 16 bits, the maximum value is 65535 (0xFFFF), which is 64k? Maybe a pointer cannot handle anything bigger?

Share this post


Link to post
Share on other sites
Yes, with 16-bits it will wrap to zero after 65535. But I am using *far* pointers. Which to my knowlege, in a 16-bit environment, use 20-bits (two WORD values using that segments-and-offests crap) to access up to 1 MB of RAM.

Share this post


Link to post
Share on other sites
What's the actual declaration of the pointers you're using? And what compiler are you using?

Share this post


Link to post
Share on other sites
I found this. It may apply to your situation. Basically, it says the parameter to malloc may only be a 16 bit int, so you cannot make any buffer larger that 65535.

Share this post


Link to post
Share on other sites
Quote:
What's the actual declaration of the pointers you're using? And what compiler are you using?

I am using Turbo C++ (I don't know why that school insists on still using it). I have tried using both 'large' and 'huge' memory models. (Huge is the same as lareg, but it normalizes the pointers and avoids segment wraparound). I have tried explicitly creating pointers of various datatypes with both 'far' and 'huge' declarators. The sizeof() operator always says they are four-bytes long too. As they should be.

Quote:

I found this. It may apply to your situation. Basicly, it says the parameter to malloc may only be a 16 bit int, so you cannot make any buffer larger that 65535.

Nope. I am passing a calculation (320*240*1) as the parameter. I also tried using a compiler-specific function. 'farmalloc()' which is supposed to use the 'far' heap no matter what. Still nothing.

Could it be that the code generated by this compiler just won't work on more modern machines? It's generating 286 instructions. Al 80x86 processors *should* be backwards compatible, but, you never know...


[EDIT]
Hmmm. I just checked the error return of my code and it says 'farmalloc()' is
returning NULL. I missed that before. Not sure what it means though.

Maybe I'll just say to heck with this and use 64k chunks.
[/EDIT]

Share this post


Link to post
Share on other sites
Quote:

Nope. I am passing a calculation (320*240*1) as the parameter. I also tried using a compiler-specific function. 'farmalloc()' which is supposed to use the 'far' heap no matter what. Still nothing.


The fact that it's a calcuation makes no difference. It still creates a value which is passed to the function, and this value is probably truncated (is that the right word?) to a 16-bit value, or basically masked with 0xFFFF.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
16 bit mode only allowed access via segments of up to 64k.
All allocations of a stucture (memory block) could have only 64k as a max size.

You could use HUGE pointers (which had segment and offset components) to chain
a bunch of nodes each being 64k (seperately allocated). The HUGE pointer could be used to access across segment boundries. I seem to remember the HUGE had extra code to renormalize sgement+offset when you crossed a segment boundry when waling
(ptr++) the pointer. (look in the documentation for HUGE...)

It probably was possible to staticly allocate several contiguous 64k blocks, but the C dynamic allocator would not be guaranteed to do that with any consistancy.

Share this post


Link to post
Share on other sites
I remember Borland C++ 5 for DOS used protected mode which allows arbitrary memory allocation. Try to find any option that will make 32-bit PM executables. Other than that, you're left with huge pointers or managing segments by yourself.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!