RGB Classic Games Forum

Jesus! I do not know. I'm just a Borland Turbo C 2.01 and Borland Turbo Assembler 4.1 programmer!

NY00123 wrote:Thus, it's really common that a 8-bits sized byte is used as the smallest unit of smallest addressable unit of memory nowadays, but there are still counterexamples.

I think 4-bit paletted graphics were quite common in the 1990s. 4 bits translates nicely into 16 colors which gives a good pallet while keeping the data footprint small.

NY00123 wrote:

developertn wrote:Really? 4-bits is an unheard of number to me.

Heh, that's 4-bytes above, not 4-bits
Actually, there are architectures with byte sizes differing from 8-bits. The C language has a macro named CHAR_BIT, telling the number of bits a char has. This macro is often defined to be 8, but it doesn't have to. At least as of C89 and later, the C standard mandates that CHAR_BIT >= 8. POSIX mandates the stricter requirement that CHAR_BIT == 8.

Thus, it's really common that a 8-bits sized byte is used as the smallest unit of smallest addressable unit of memory nowadays, but there are still counterexamples.

Sorry to interrupt however I have been studying Borland Turbo C 2.01 now that I have completed my Borland Turbo Assembler 4.1 studies. There is a alloc and malloc function in Borland Turbo C 2.01. When you type cast in Borland Turbo C 2.01 it does tell the number of bytes. It is given that you already know CHAR to be 8 bits while INT and such to be accordingly sized (eg 16 bits, 2 bytes, etc.).

Speaking of CHAR_BIT since I don't think Borland Turbo C 2.01 has it, I've decided to write my own function that does the same thing.

#include <alloc.h>
#include <stdio.h>

void CHAR_BIT(int nbytes)
{
printf("\n %d ", nbytes*sizeof(char)*8);
}

int main()
{
CHAR_BIT(2);
}

Cheers!

God, Jesus Christ, is number one.
Jesus Christ.

Although I'm able to create a similar function, I'm still a nobody baby growing since it's my first year in programming MS-DOS prompt in XP in VirtualBox. Although I'm working in another OS, I do work in DOSBox 0.74 too. So, yeah I'm still continuing my studies like Melvineous is so cool to suggest since I could use a lot of work in my majorly huge gaps in knowledge of programming at this early beginning stage.

Honours to my real dad Nguyen Binh Thuy and my real mom Huong Thi Vu for putting me through the school of hard knocks of real life; Without such, I would not be able to live on my own to 100 years old and be 100% happy all the time!

Bless God for my two real parents, then bless my real mom for putting up with it that I still cling to her being the baby that I'm.

Pixelfck wrote:

NY00123 wrote:Thus, it's really common that a 8-bits sized byte is used as the smallest unit of smallest addressable unit of memory nowadays, but there are still counterexamples.

I think 4-bit paletted graphics were quite common in the 1990s. 4 bits translates nicely into 16 colors which gives a good pallet while keeping the data footprint small.

It's true that 16-colors graphics modes were commonly used back then. Technically, programming the EGA (or compatible, including the VGA) for drawing graphics in such modes is a bit of a feat, given that these modes are planar (see e.g., http://www.shikadi.net/moddingwiki/Raw_EGA_data). So, this special case should probably be ignored for now.

Even today, it's still technically possible to work with CGA or EGA-level graphics, if you wish (e.g., from external files). One thing was true back in the 90s with PCs in mind and still applies today, though. Generally speaking, if there's a single byte of data storing 2 pixels (using a 16-colors palette) and you want to read one of the pixels, practically both of them are read first, since a 8-bits sized byte is still the smallest addressable unit of memory (or storage). In a way, this can lead to a basic form of caching: One a byte is read to retrieve a little portion of it for any reason (e.g.. reading a pixel), the rest of it can be stored for later uses (like reading other pixels).

developertn wrote:Speaking of CHAR_BIT since I don't think Borland Turbo C 2.01 has it, I've decided to write my own function that does the same thing.

Tried checking Turbo C's header files? There should (probably) be a limits.h header file with a definition of CHAR_BIT.

developertn wrote:#include <alloc.h>
#include <stdio.h>

void CHAR_BIT(int nbytes)
{
printf("\n %d ", nbytes*sizeof(char)*8);
}

int main()
{
CHAR_BIT(2);
}

Of course this will work, not only since it's manually implemented (as done by you on purpose), but also because the C standard mandates that sizeof(char) is always 1. A single byte, not matter how many bits does it consist of, should be used for storage of a char.

God, Jesus Christ, is number one.
Jesus Christ.

Congratulations; I'm sprite to find another person works with Borland Turbo C (2.01 in my case). I did find the LIMITS.H header file and it does contain the definition of CHAR_BIT to be 8, thank you!

Also, thank you for teaching me there are others way more advance than I could ever imagine out there in Borland Turbo C 2.01. If not this then in C whichever the variations and platforms.

Bless God for my two real parents and all those who are there for me being a nobody baby programmer!!!!!!!!!!!!

My real helicopter pilot dad Nguyen Binh Thuy would be glad that I'm still learning programming#!!

My real home builder mom Huong Thi Vu would rejoice that I found my niche it looks like in programming!!!!!!!!!!