why 64K, not 65K?

TC · 2014-01-28 03:44

Hello all,

I'm betting some of you are probably getting tired of me asking questions, well I'm sorry. There is so much I want to know, and Google does not have the answers the way I can understand.

I was looking a Atmel's AT28C64B just trying to get a better understanding of logic. And I noticed some thing. There is more than 64,000 bits of space, then why does the datasheet say 64K (8K x 8)?

For the chip there are 13 address lines (A0-A12)

So to if I selected every address from $0 to $1FFF, that would be 8192 address locations, then *8 bits, that would be 65,536 bits. Why are chips marketed low? Why not say it is a 65K EEPROM?

This question is not just for this EEPROM, I have seen it on a lot of other things.

Thanks
TC

mindrobots · 2014-01-28 04:04

What do you get when you consider K as 1024 instead of 1000?

Erlend · 2014-01-28 04:05

Ah - the bit/byte/binary counting paradox. How many bytes are in 2 Mbytes? 2x10E6? No. And so on.
I look forward to reading the answers to your (appropriate) question.

Erlend

Erlend · 2014-01-28 04:09

mindrobots wrote: »

What do you get when you consider K as 1024 instead of 1000?

Just don't try to figure out what is 1 hByte (hecta-), or dByte (deci-).

Erlend

Tor · 2014-01-28 04:27

TC wrote: »

So to if I selected every address from $0 to $1FFF, that would be 8192 address locations, then *8 bits, that would be 65,536 bits. Why are chips marketed low? Why not say it is a 65K EEPROM?

As RAM is always addressed as a whole number of 2^n (so that values will always be 128, 256, 512 and not 100, 200, 500 etc) a method for discriminating between 1000 and 1024 was needed. Traditionally that was done by using 'K' = 1024, as the lower-case 'k' is the SI symbol for '1000'. So, 65k = 65000 and 64K = 65536 (64*1024). For 'mega' and 'giga' that was more tricky because capital 'M' was already in use for 10^6 (lower-case 'm' for 'milli', 1/1000) and 'G' for 10^9. So 'MB' and 'GB' (and 'Mb' and 'Gb', b=bits B=bytes) were always ambiguous. At least to the extent that many years ago some marketing people (say no more..) suddenly changed the meaning of MB from its original 1024*1024*1024 bytes, for disk capacity, to 10^6. Thus they could use a larger number than the competitors (until they caught on) for the same size disk.

SI tried to resolve the mess by introducing 'KiB' for 1024 bytes, 'MiB' for 1024 KiB, and 'GiB' for 1024 MiB. This works reasonably well. But for RAM and ROM and similar tech there is really only one way to count bytes.. by 2^n. So 64KB (not kB which is just plain wrong any which way, for RAM) still unambiguously means 65536 bytes. Or 64Kb, which means 65536 bits.

-Tor

TC · 2014-01-28 04:32

mindrobots wrote: »

What do you get when you consider K as 1024 instead of 1000?

Total confusion..

TC · 2014-01-28 04:33

Erlend wrote: »

Just don't try to figure out what is 1 hByte (hecta-), or dByte (deci-).

Erlend

I'm lost already, so I'm not going to be figuring them out. Not just yet.

TC · 2014-01-28 04:40

Tor wrote: »

As RAM is always addressed as a whole number of 2^n (so that values will always be 128, 256, 512 and not 100, 200, 500 etc) a method for discriminating between 1000 and 1024 was needed. Traditionally that was done by using 'K' = 1024, as the lower-case 'k' is the SI symbol for '1000'. So, 65k = 65000 and 64K = 65536 (64*1024). For 'mega' and 'giga' that was more tricky because capital 'M' was already in use for 10^6 (lower-case 'm' for 'milli', 1/1000) and 'G' for 10^9. So 'MB' and 'GB' (and 'Mb' and 'Gb', b=bits B=bytes) were always ambiguous. At least to the extent that many years ago some marketing people (say no more..) suddenly changed the meaning of MB from its original 1024*1024*1024 bytes, for disk capacity, to 10^6. Thus they could use a larger number than the competitors (until they caught on) for the same size disk.

SI tried to resolve the mess by introducing 'KiB' for 1024 bytes, 'MiB' for 1024 KiB, and 'GiB' for 1024 MiB. This works reasonably well. But for RAM and ROM and similar tech there is really only one way to count bytes.. by 2^n. So 64KB (not kB which is just plain wrong any which way, for RAM) still unambiguously means 65536 bytes. Or 64Kb, which means 65536 bits.

-Tor

So from what I am understanding, SI ran out of ways to desinate the value.

Should I do what mindrobots is having me consider? where 1K is = to 1,024. So if I had 128K, *1024, there would be 131,072 bytes?

'MB' and 'GB' (and 'Mb' and 'Gb', b=bits B=bytes)

I never knew that. I always thought they were the same thing.

Tor · 2014-01-28 05:37

TC wrote: »

So from what I am understanding, SI ran out of ways to desinate the value.

Basically, yes.

Should I do what mindrobots is having me consider? where 1K is = to 1,024. So if I had 128K, *1024, there would be 131,072 bytes?

Absolutely! After a while it's second nature. You'll know that 128K is 131072 and think of 128K that way. Your mind starts to focus on numbers like 4096, 16384, 32768, 131072 etc. when they show up. And soon you'll notice that 2147483647 is 0x7fffff hexadecimal (it's actually useful.. when you see that number somewhere you expected a number like 'days left' or some such, you'll have an idea of what kind of technical mishap occurred with their database)

[KB/kb] I never knew that. I always thought they were the same thing.

Lots of people use Kb or kb when they should have used KB, or even KiB (same with GB, Gb, gb). Sometimes there's no ambiguity, as when talking about disk capacity - it's always about bytes. But for bandwidth, or any kind of serial transmission, or where bits are potentially involved, e.g. RAM or EEPROM chips, it's a very good idea to use the correct terminology. Someone says that the measured transfer rate is 50Mb/s.. sounds good, but is it megabytes, or megabits? It could be bits, or it could be bytes. On a gigabit network 50 megabytes per second is a typical transfer rate you get in practice. But it could be that the person was talking about the internet connection.. which could well be 50 Mbit/s, and then it's not unreasonable to actually get 50Mbit/sec on a corporate internet connection. Which would be approximately 6MB/s. So it is important to always be clear: 50MB/s means 50 megabytes per second, 50Mb/s means 50 megabits per second.

-Tor

Mike G · 2014-01-28 05:37

You're trying to compare units used in two different numbering systems; base10 and base16 (or base2)
10x0 = 0
10x1 = 10
10x10 = 100

16x0 = 0
16x1 = 0x10 (16)
16x16 =0x100 (256)
16x16x4=0x400 (1024)
16x16x16 = 0x1000 (4096)

If I remember correctly 1024 was chosen as K because 1024 is close to 1000. A marketing thing...

TC · 2014-01-28 05:45

Tor wrote: »

Absolutely! After a while it's second nature. You'll know that 128K is 131072 and think of 128K that way. Your mind starts to focus on numbers like 4096, 16384, 32768, 131072 etc. when they show up. And soon you'll notice that 2147483647 is 0x7fffff hexadecimal (it's actually useful.. when you see that number somewhere you expected a number like 'days left' or some such, you'll have an idea of what kind of technical mishap occurred with their database)

-Tor

Im going to have to make it second nature.

TC · 2014-01-28 05:45

Mike G wrote: »

You're trying to compare units used in two different numbering systems; base10 and base16 (or base2)
10x0 = 0
10x1 = 10
10x10 = 100

16x0 = 0
16x1 = 0x10 (16)
16x16 =0x100 (256)
16x16x4=0x400 (1024)
16x16x16 = 0x1000 (4096)

If I remember correctly 1024 was chosen as K because 1024 is close to 1000. A marketing thing...

Ah, now I get it.

Heater. · 2014-01-28 05:55

I would not say it was a marketing thing originally. Just natural for engineers to refer to 1024 bit or byte chip as a kilobit, kilobyte. It's close enough and everyone knows what you mean in the context.

It gets confusing when such usage leaks out into the world of disk drives and such that are purchase by people who have no clue about binary, and the the marketeers can have their fun taking advantage of that confusion.

Tor · 2014-01-28 05:56

Mike G wrote: »

If I remember correctly 1024 was chosen as K because 1024 is close to 1000. A marketing thing...

Not sure if it was marketing.. maybe it was, but after all it's so far back in time that there were mostly engineers working on these things. Well, certainly they must have thought of the 'kilo' unit as something manageable.. couldn't be 1000 because that's not a useful number. But a nice opportunity presented itself: The SI unit for kilo is 'k', so 'K' was free for the taking. So 'K' became the unofficial unit for the unofficial number 1024. Of course eventually Moore's law played out and larger numbers were needed. There was no free 'M' (or 'G') available and it got more messy. Of course old-timers and semi-oldtimers as myself still always think in 2^n when it comes to computers and processors.. and will continue to do so.

-Tor

potatohead · 2014-01-28 06:56

Right now, memorize the first 16 powers of 2.

Begin to use them like you do powers of 10. These numbers are core to computing. You will encounter them everywhere.

bill190 · 2014-01-28 09:47

Counting in binary can be helpful to understanding...

0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
Etc.

Also learn about the Hexadecimal, Octal, and Decimal numbering systems. (Count past 9 and see what happens. See how that relates to the 1's and 0's.)

Reading about the history of computers or a book on the history of computers can make these things much more understandable!

TC · 2014-01-28 18:46

I have a full understanding of base 2, 10, & 16. I just wanted to know why memory is classified low.

potatohead · 2014-01-28 21:54

Memory is classified in terms of multiples of base 2 powers of 2, not base 10. Typically base 16 is used, because all the math works nice and easy. No wasted bits. When we use powers of 10, there are wasted bits and nobody wants that. 64000 bytes of RAM would be indexed as $0000 - $FA00. Look at all that wasted space! $FFFF - $FA00 = $5FF, which is 1535 unused addresses.

When we connect RAM to other devices, we use address lines. Each of those represents a power of 2 addresses. And so the nearest power of two is optimal in that every bit of every address line actually addresses some RAM. A kilobyte (1024) is the nearest power of two in terms of address lines. Using 1000 leaves things on the table, has odd page sizes, and is in general difficult to work with given how easy hex is.

And since we would still need 16 address lines to get at 64,000 bytes of RAM, why not just use all the addresses up through 65535? And there you go. Powers of 2 are used because address lines are used and we want to completely use them. No point in doing it otherwise. Just adds time and complexity.

64K of RAM runs from $0000 to $FFFF In base 16, 64K is a nice, round, easy number. That's the powers of two thing I mentioned earlier.

65536 is messy, because it's base 10. We don't do RAM in base 10, we do it in powers of 2. So a page of RAM, for example, is 256 bytes, or $FF. Simple in base 16, messy in base 10. One byte = two hex digits! 00-$FF, and one byte indexes a page perfectly too.

64K of ram breaks down nicely in base 16. You pick your page size, and then the number system tells you all you want to know. Say we pick a 1Kbyte page size, which is 1024 base 10. But it's a really nice $400 in hex, base 16. Or, as programmers think, $000-$3FF, because we count from zero, which is the very first address.

$10000 / $400 = $40, or 64 in base 10, which again is 64K of memory, where a "K" is 1024 bytes, or a nice power of 2 page size that works in round numbers with everything else.

And those round numbers are round in base 16. Base 10 has nothing to do with any of it really.

Gadgetman · 2014-01-28 23:22

I once programmed in assembler on the PDP11/750...

There they used Octal representation in the Source... Supposedly because 'octal was closer to bare 10 than hexadecimal'...
That was true, too... With the numbers 0 to 7...

Octal fits nicely in 3 bits, but not so nicely in the 8bits of a Byte...
and even worse when you use 16bit Words.

               8bit       10bit       16bit
Octal:         0 - 377   0 - 1777     0 - 177777    
Decimal:       0 - 255   0 - 1023     0 - 65535
Hexadecimal:   00 - FF   000 - 3FF    0000 - FFFF

Hex and the 1024 'Kilo' is just the most practical choices given the chosen (8/16/32/64bit) computer architecture.

mindrobots · 2014-01-29 00:52

Gadgetman wrote: »
I once programmed in assembler on the PDP11/750...

There they used Octal representation in the Source... Supposedly because 'octal was closer to bare 10 than hexadecimal'...
That was true, too... With the numbers 0 to 7...

Octal fits nicely in 3 bits, but not so nicely in the 8bits of a Byte...
and even worse when you use 16bit Words.
               8bit       10bit       16bit
Octal:         0 - 377   0 - 1777     0 - 177777    
Decimal:       0 - 255   0 - 1023     0 - 65535
Hexadecimal:   00 - FF   000 - 3FF    0000 - FFFF  
Hex and the 1024 'Kilo' is just the most practical choices given the chosen (8/16/32/64bit) computer architecture.

On the Sperry UNIVAC 1100 series mainframes, we used octal all the time since we had a 36bit word which divided up by three much better than it did into 4 bit nibbles or bytes. Maybe each octal digit should be referred to as a tribble? We also used 6 bit fielddata for character representation which let you pack 6 characters per word. When the hardware did get ascii support, it was 9 bit ascii since then you could break the 36bit word into quarters.

In the end, bits are bits and it was all binary and K was 1024 still.

Heater. · 2014-01-29 01:15

It's fascinating how computer architectures tried out all sorts of different word sizes before settling on common 8, 16, 32, 64 bits we see all around today. Some of them are rather exotic like the UNIVAC III at 25 bits (Why for God's sake).

They also tried out different representation, some used decimal like Babbage's designs or the IBM 7010.

Then there is the weird Russian Setun that did not use binary at all, it used tri-level logic, which brings us to "trits" and "trytes".

So fascinating in fact that there is a whole long wikipedia page just on that topic listing word lengths for just about every machine ever. http://en.wikipedia.org/wiki/Word_(computer_architecture)

Octal still lives on to plague us. Writing "010" in C will get you eight and not ten. The leading zero indicates octal representation!

This error inducing bizarreness is carried forward into much newer languages like JavaScript.

Tor · 2014-01-29 01:51

Gadgetman wrote: »

I once programmed in assembler on the PDP11/750...There they used Octal representation in the Source... Supposedly because 'octal was closer to bare 10 than hexadecimal'...That was true, too... With the numbers 0 to 7...Octal fits nicely in 3 bits, but not so nicely in the 8bits of a Byte...and even worse when you use 16bit Words.[..]

Octal was popular for a time. Norsk Data used it, I've programmed the NORD-10 from the front panel - the panel was divided into nice 3-bit groups, fit for thinking in octal. Altair and some IMSAI had the front panel grouped in octal (but most of the IMSAI front panels were wired in groups of 4 though, for thinking in hex. But you can find both variants out there).
When octal was used for 8- and 16-bit computers where hex is a better match (try it - you'll see) I suspect that was simply because, compared to hex, it's quicker to learn to translate from octal to binary in your mind. You only need to map numbers up to 7, and 3 bits, unlike hex where you go all the way to F, and 4 bits. Octal disappeared from common use with the keyed front panels, basically.. except where it lived on simply because the same operating system continued to be used, although I'm familiar with only one such: The Norsk Data SINTRAN III OS.

-Tor

Tor · 2014-01-29 02:23

Heater. wrote: »

[..]So fascinating in fact that there is a whole long wikipedia page just on that topic listing word lengths for just about every machine ever. http://en.wikipedia.org/wiki/Word_(computer_architecture)

That list is surprisingly incomplete.. I suspect it's meant to just present examples of different word sizes, or maybe a machine that was early with that word size. So, there's PDP-1 (18 bits), but no PDP-7 (also 18 bits), and PDP-8 (12 bits), but no PDP-12 (also 12 bits). But then again there are multiple examples of 8-bit computers, same for 16, 32, 64-bit ones. So I'm not entirely sure what that list is meant to represent. It's also very US centric. I'm sure there were interesting Russian computers with strange word sizes. And what about the Italian Macchina Ridotta, from 1957? I'm not sure but I think it may have used a 5-bit word size.

-Tor

Heater. · 2014-01-29 02:31

Well, it's wikipedia, if you know of other machines why not edit the page yourself and add them? All the better if you have some links or references to support them.

It has been said a lot that editing wikipedia has become quite difficult, I don't believe it can be so bad though.

evanh · 2014-01-29 02:49

The reason why base-two has always been the way to measure computing memory is simply because each address line is another power of two in the address range. Not filling this space leads to ungainly holes in the memory system. Anyone familiar with I/O mappings can vouch for that.

Until a few years back computing always used decimalised base-two for measuring memory capacity, including hard drive storage. The SI letters were just borrowed as a convenience for human readability, all the engineering standards bodies involved (ISO didn't have a definition then) had them as base-two for computing. The only examples of, the non-standard, base-ten was in marketing labels on HDDs and the likes. That didn't matter as everyone knew the labelling scheme.

Since the more recent involvement of ISO there has been a concerted effort to convince the computing world that base-ten measuring is useful. However, it's a bit like trying to decimalise the calendar, it isn't likely to be very effective due to computers being base-two machines.

TC · 2014-01-29 03:37

Everyone has put up some great information. I was not planing on getting this much amazing info. There is so much I do not know, since I am just a self taught hobbyist.

Heater. wrote: »

Octal still lives on to plague us. Writing "010" in C will get you eight and not ten. The leading zero indicates octal representation!

Well that would screw me over, I use leading "0" for a lot of things just to keep things inline so it makes it easier to debug. IE..
Base 10 numbers

001
005
010
050
100

Compared to,
1
5
10
50
100

Just easier for me to read, and to see problems.

Heater. · 2014-01-29 03:39

As far as I'm concerned 64KB is OK no matter if you use it in the binary sense (64 * 1024) or the decimal sense (64 * 1000).
Used casually they are close enough the same as to bot be worth quibbling about.
When you are buying that memory upgrade for your PC telling the guy in the shop you want 64K is just fine. You even get a little bonus of 1536 bytes!

Of course in an engineering sense you want to be precise but then you know what you are doing anyway.

And so it goes with mega, giga, tera. By wich time you are getting 995,116,277,76 bonus bytes for each tera byte, almost a free gigabyte!

The ISO/IEC standards are just horrible:

1000
k
kilo

1000²
M
mega

1000³
G
giga

1000⁴
T
tera

1000⁵
P
peta

1000⁶
E
exa

1000⁷
Z
zetta

1000⁸
Y
yotta

1024
K
kilo
Ki
kibi

1024²
M
mega
Mi
mebi

1024³
G
giga
Gi
gibi

1024⁴
-
-
Ti
tebi

1024⁵
-
-
Pi
pebi

1024⁶
-
-
Ei
exbi

1024⁷
-
-
Zi
zebi

1024⁸
-
-
Yi
yobi

I'm really, "kibi", "mebi", "gibi", who are the trying to kid? Bletch.

Heater. · 2014-01-29 03:50

TC,

Well that would screw me over, I use leading "0" for a lot of things just to keep things inline so it makes it easier to debug.

Yep, I like to do that sort of thing as well. Don't do it. Hence the "...plague... error inducing bizarreness...".

I really wish the C/C++ standards could kill off gibberish like that and that people like the JavaScript guys would not follow along with it.

TC · 2014-01-29 03:53

Heater. wrote: »

As far as I'm concerned 64KB is OK no matter if you use it in the binary sense (64 * 1024) or the decimal sense (64 * 1000).
Used casually they are close enough the same as to bot be worth quibbling about.
When you are buying that memory upgrade for your PC telling the guy in the shop you want 64K is just fine. You even get a little bonus of 1536 bytes!

Of course in an engineering sense you want to be precise but then you know what you are doing anyway.

And so it goes with mega, giga, tera. By wich time you are getting 995,116,277,76 bonus bytes for each tera byte, almost a free gigabyte!

The ISO/IEC standards are just horrible:

1000
k
kilo

1000²
M
mega

1000³
G
giga

1000⁴
T
tera

1000⁵
P
peta

1000⁶
E
exa

1000⁷
Z
zetta

1000⁸
Y
yotta

1024
K
kilo
Ki
kibi

1024²
M
mega
Mi
mebi

1024³
G
giga
Gi
gibi

1024⁴
-
-
Ti
tebi

1024⁵
-
-
Pi
pebi

1024⁶
-
-
Ei
exbi

1024⁷
-
-
Zi
zebi

1024⁸
-
-
Yi
yobi

I'm really, "kibi", "mebi", "gibi", who are the trying to kid? Bletch.

I am wondering about something, Could the ISO/IEC standards be changed? I understand that it would be imposable to do, and I don't think anyone would actually consider changing it. I'm just asking in theory, could it be changed, and if so, what would be changed?

TC · 2014-01-29 03:56

Heater. wrote: »

TC,

Yep, I like to do that sort of thing as well. Don't do it. Hence the "...plague... error inducing bizarreness...".

I really wish the C/C++ standards could kill off gibberish like that and that people like the JavaScript guys would not follow along with it.

I'm so glad I don't have to worry about it yet, since I only know PBASIC, and Spin. But that will probably change when I decide to go back to school.

evanh · 2014-01-29 03:58

Both of them have separately changed over time: First ISO in the 1990's introducing the base-ten scaling, then IEC about a decade later changed from exclusively base-two to adopting the dual scales for those that want to have both at the same time.

Of course much of modern documentation just ignores the new labelling push and sticks with the original base-two scaling and labelling, ie: k = 1024.

why 64K, not 65K?

Comments