- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Memory and Addressing (Was: Google Android
- Thread starter JT64
- Start date
pontus
Veteran Member
As far as I know, Android runs only on ARM processors. I guess you could try and port it to x86, I don't see a technical reason why it would not work.
But it will never run on a 286 since the linux kernel doesn't.
It appear that someone has begun porting already, it might even work:
http://www.androidx86.org/
http://www.android-x86.org/
But it will never run on a 286 since the linux kernel doesn't.
It appear that someone has begun porting already, it might even work:
http://www.androidx86.org/
http://www.android-x86.org/
Chuck(G)
25k Member
What does the amount of RAM have to do with anything?
80286 can address 1MB in real mode (let's not get into "unreal" modes via LOADALL, please). and 1GB in protected mode. Physical memory can be a max of 16MB, but I don't understand what that has to do with the price of fish.
On the other hand the memory management scheme in the 80286 is very different from the ARM CPU and I wouldn't care to have to adapt code from one to the other. For example, 80286 registers are 16 bit, so addressing a structure more than 65K in size requires some fancy footwork. On the ARM, they're 32-bit, so addressing large structures is a non-issue.
80286 can address 1MB in real mode (let's not get into "unreal" modes via LOADALL, please). and 1GB in protected mode. Physical memory can be a max of 16MB, but I don't understand what that has to do with the price of fish.
On the other hand the memory management scheme in the 80286 is very different from the ARM CPU and I wouldn't care to have to adapt code from one to the other. For example, 80286 registers are 16 bit, so addressing a structure more than 65K in size requires some fancy footwork. On the ARM, they're 32-bit, so addressing large structures is a non-issue.
TandyMan100
Veteran Member
I think running android on a 486+ would be awesome! I think it'd be best accomplished via an emulation layer, so that you can use Android programs natively, instead of special x86 android programs. My (probably wrong) .20 (inflation)
The original poster asked if there was a 286 with 32MB of memory.
Addressability and virtual memory are interesting, but the hard limit for RAM connected to the machine is 16MB. Addressability to more than that is great, but it implies paging to disk. So my answer to the question is accurate - you are limited to 16MB of RAM, and anything else is an illusion.
Chuck(G)
25k Member
Who said anything about paging to disk? Page to auxiliary RAM if you want. External addressability is an implementation detail. To an application, 1GB is the size of the address space. It doesn't limit any application to addressing 16MB.
Every day we talk about "physical memory", but on a system with caching, what memory is being addressed anyway? It's the cache! If the address being sought isn't in the cache, then it's fetched from DRAM. So, one could legitimately say that a 486 with 256K of cache can address only 256K of memory, after which a hardware-implemented pager kicks in.
But if you want to quibble, then sure, you can get a 286 to address (directly) 32MB of RAM. The status lines indicate when an instruction read is being performed, so you simply convert to a Harvard architecture and bingo, you've got 32MB of directly-addressable memory; 16MB of code and 16MB of data. As far as I know, the "instruction read" status was only used with ICE--but it's there.
By the same token, an 8088 or 8086 can address 4MB of memory directly. The segment ID is output as a status, so one can have 1MB addressing space for each segment = 4MB.
Chuck,
I disagree - the cache is not being addressed. The machine should operate the same whether the cache is enabled or disabled, present or not present. The only thing that cache affects is performance. Turning it upside down and saying that the cache is the only memory on the system and the rest is a memory maping or paging system is ridiculous and you won't find that interpretation in any hardware book ..
Most people when they talk about how much RAM is connected to a machine are talking about physical RAM. Anything else, like bank switching or moving from Von Neumann is really stretching things, which is why I included the disclaimer about other schemes in my first reply!
I'm not quibbling here. I stated the RAM limit was 16 MB because there are 24 address lines coming from the chip. Addressability using virtual memory is interesting, but it also implies that you are adding paging and a huge non-RAM backing store. Even if you split hairs further and use some sort of RAM for that backing store, you are still swapping things in and out of main memory (the 16MB of physical RAM we are referring to) or you are doing unnatural things like going to a Harvard architecture.
Mike
I disagree - the cache is not being addressed. The machine should operate the same whether the cache is enabled or disabled, present or not present. The only thing that cache affects is performance. Turning it upside down and saying that the cache is the only memory on the system and the rest is a memory maping or paging system is ridiculous and you won't find that interpretation in any hardware book ..
Most people when they talk about how much RAM is connected to a machine are talking about physical RAM. Anything else, like bank switching or moving from Von Neumann is really stretching things, which is why I included the disclaimer about other schemes in my first reply!
I'm not quibbling here. I stated the RAM limit was 16 MB because there are 24 address lines coming from the chip. Addressability using virtual memory is interesting, but it also implies that you are adding paging and a huge non-RAM backing store. Even if you split hairs further and use some sort of RAM for that backing store, you are still swapping things in and out of main memory (the 16MB of physical RAM we are referring to) or you are doing unnatural things like going to a Harvard architecture.
Mike
MikeS
Veteran Member
I'm curious: You're saying that bank switched memory is not "physical RAM", so do you mean that the term specifically means "only *directly* addressable by the CPU"?
I thought "physical RAM" referred to actual unique RAM chips (or equivalent) which are addressed via address lines (including bank selection registers), whereas "virtual memory" referred to auxiliary storage which was *swapped into* some "physical" RAM as needed (as opposed to just being a different section of the same RAM).
I don't really see much conceptual difference between a single bank of memory and multiple banks, whereas I see swapping to/from disk (and RAM cache for that matter) as a somewhat different concept.
Have I got it wrong?
Last edited:
I think it is reasonable to limit the definition of 'physical' memory to that which is directly connected, without any additional instructions or setup to get at. it.
Banked memory, once selected, operates the same as physical memory. But you have to select the bank and move it into view to get to it. Using a scheme like banked memory you can have infinite memory on a system, but it all appears in a smaller window of address space and you have to do setup to select the memory and make it viewable. I think the fact that it is viewable through a window and that there needs to be setup done to bring memory into the window is significant. This is actually opposite of virtual memory, where a vast address space is mapped to a small amount of physical memory.
I don't think that when most people ask how much memory is connected or can be connected to a machine that bank switching, memory in I/O space, or virtual addressing are what they are looking for. They are looking for how much physical RAM can be connected to the bus and accessed. If you count the other schemes implicitly, then the answer is infinite memory can be connected to any machine ...
Banked memory, once selected, operates the same as physical memory. But you have to select the bank and move it into view to get to it. Using a scheme like banked memory you can have infinite memory on a system, but it all appears in a smaller window of address space and you have to do setup to select the memory and make it viewable. I think the fact that it is viewable through a window and that there needs to be setup done to bring memory into the window is significant. This is actually opposite of virtual memory, where a vast address space is mapped to a small amount of physical memory.
I don't think that when most people ask how much memory is connected or can be connected to a machine that bank switching, memory in I/O space, or virtual addressing are what they are looking for. They are looking for how much physical RAM can be connected to the bus and accessed. If you count the other schemes implicitly, then the answer is infinite memory can be connected to any machine ...
NobodyIsHere
Veteran Member
- Joined
- Dec 21, 2006
- Messages
- 2,410
Hi Chuck! Could the Z80 and its /M1 signal be used as an address line as well? If so, that has some intriguing possibilities.
Thanks and have a nice day!
Andrew Lynch
Chuck(G)
25k Member
Mike, I don't think that follows. How much data is addressable by a protected mode program on an 80286? Is the program itself even directly aware of the 16MB physical interface? The chip could well have 32 bits of address lines and the user's program wouldn't know the difference.
Let me turn your statement on its head. A Z8001 has 16 address lines and 7 segment lines. Is this basically a 64K processor no matter how much RAM is attached? Because after all, the Z8001 uses bank-switching (via segment addressing) to get to any more memory above that base 64K. One might even consider the Z8002 to be a Z8001 without the bankswitching hardware.
I could likewise say that the 80286 is basically a 64K machine with bankswitching (segmentation) hardware. It certainly feels that way sometimes--just try working with a 10MB data structure.
So, I'm not quite certain that I get your distinction.
Let's talk about what exists, not what could be ...
The 80286 has 24 address lines. Period. No more, no less. No extra segment lines, nothing else.
16MB is the answer, unless you go through contortions. It was a really simple question - is there a 32MB 80286 box out there. The answer is no.
Chuck(G)
25k Member
Okay, I see your point. And the Z8001 addresses 64K of memory because it has 16 address lines.
Perhaps the better question would have been "In the context of the Google Android specifically, why does 32MB matter?"
Perhaps the better question would have been "In the context of the Google Android specifically, why does 32MB matter?"
Chuck(G)
25k Member
Off the top of my head, I don't recall if the Z80 asserts M1 for each instruction byte fetch or just the first byte of an instruction. If it's the latter, you'll have to include a bit of decoding logic to determine how many bytes follow, but there's no reason that a Z80 couldn't be hooked up to run with a separate address space for code.
An extreme example of this is the GI CP1600 CPU (circa 1975). It's a 16-bit CPU that only uses 10 bits of the word for instructions; the upper 6 bits is ignored. You could decode those 6 bits and use it as an address extension, giving the lowly 1MHz GI chip 22 bits of addressing...
Back in the bad old days of 8-bit CPUs, we used a 256x9 bipolar SRAM to extend the upper 6 bits of the 8085's address to 9 bits, giving a 512K memory space. It was sort of the opposite of paging; we needed to interface the 8085 to 256K of memory; there was more physical memory than addressing. You could map any 1K physical page into any place in the 64K addressing of the 8085--even map one page into several places. That SRAM was power-hungry and expensive and sole-sourced from Fairchild. Today you could do it with a cheap CMOS SRAM.
Last edited:
MikeS
Veteran Member
Very confusing IMHO.
So you would say that an XT with 1024KB of RAM chips installed only has somewhere between 640K and 720K or so of "physical RAM" depending on the video adapter (since memory above that isn't accessible without a type of 'bank switching')?
So what do you call the RAM that isn't directly accessible? Presumably not 'virtual', since unlike a disk cache for example, this RAM actually physically exists.
For that matter, how much physical memory would you say is in my 68000/Z80 dual-CPU Cromemco with 2x2MB cards installed?
FWIW, it seems that most definitions out there do use the term to describe what it sounds like, i.e. 'real' RAM installed and accessible to the CPU, regardless of how it's accessed and unaffected by I/O cards or swapping CPUs.
As I say, confusing, but only small minds insist on only one meaning for a term, especially in this field... ;-)
Still, it might be interesting to take a survey and see if it's true that "Most people when they talk about how much RAM is connected to a machine are talking about physical RAM" (i.e. *NOT* about the total capacity of the actual RAM chips installed), and no matter how many MBs of EMM I stick into my 1MB XT clone they'll say that it still only has 640K...
How about this:
1 - How much physical memory is there in a Z80 S100 system with 4 64KB memory cards?
2 - How much in an XT clone with 1024KB on board and a 2MB EMM expansion card?
So you would say that an XT with 1024KB of RAM chips installed only has somewhere between 640K and 720K or so of "physical RAM" depending on the video adapter (since memory above that isn't accessible without a type of 'bank switching')?
So what do you call the RAM that isn't directly accessible? Presumably not 'virtual', since unlike a disk cache for example, this RAM actually physically exists.
For that matter, how much physical memory would you say is in my 68000/Z80 dual-CPU Cromemco with 2x2MB cards installed?
FWIW, it seems that most definitions out there do use the term to describe what it sounds like, i.e. 'real' RAM installed and accessible to the CPU, regardless of how it's accessed and unaffected by I/O cards or swapping CPUs.
As I say, confusing, but only small minds insist on only one meaning for a term, especially in this field... ;-)
Still, it might be interesting to take a survey and see if it's true that "Most people when they talk about how much RAM is connected to a machine are talking about physical RAM" (i.e. *NOT* about the total capacity of the actual RAM chips installed), and no matter how many MBs of EMM I stick into my 1MB XT clone they'll say that it still only has 640K...
How about this:
1 - How much physical memory is there in a Z80 S100 system with 4 64KB memory cards?
2 - How much in an XT clone with 1024KB on board and a 2MB EMM expansion card?
Last edited:
Computer architecture is fascinating ..
Let's look at the XT since you bring it up.
The 8088 has 20 address lines, allowing you to connect 1MB of RAM to it. There is no virtual memory support in the processor, so addressability is limited - it can address up to 1MB total.
The memory map and how that memory is used is an entirely different issue. Some of the areas are reserved for I/O expansion or ROM chips instead of RAM memory. But that does not change the fact that the processor only has 1024*1024 bytes that it can address. That just means that some of the bytes are RAM, some or ROM, and some are on I/O cards. There will be 'holes' in the memory map where no RAM, ROM or I/O cards exist.
Now lets look at a LIMS board. With one of those you could have many megabytes of RAM on the system - let's say 10. But only 16K or 64K (or some arbitrarily small amount) of that memory is 'visible' to the 8088 at any one point in time. That hardware and software works by mapping a chunk of it's memory into the memory map of the 8088. You might have 2 or 4 chunks available even - that's not an important detail. The important thing to remember is that even though you have 10MB on a card somewhere, the 8088 can only see a small portion of it at any one point in time. That's a classic bank switching setup. If effectively gives you access to a lot more RAM, but it is not all addressable at the same time.
Virtual memory goes the other way - it gives you the illusion of having a tremendous address space. The pages of memory that you are actively working with have to appear in physical memory where they can be addressed by the CPU. Pages that are not in use are stored out on disk, or some form of other storage. The CPU and operating system work to bring referenced pages into memory 'on demand', and hide it from the application.
You are basically 'over committing' the physical memory. This works well because most applications don't need access to all of their address space at the same time. When you take it too far you feel it - the operating system starts 'paging', which is swapping pages in and out from main memory to disk, and that's slow when you are waiting for something to happen.
Chuck is absolutely right to bring up address space, because that is how the programmer sees the machine. Most machines have far more address space available in a single process than can be physically connected to the machine, especially when you take into account that each process can run in a different address space. On a 286 this is done using a nasty system of segment registers, which to my knowledge only OS/2 ever used. (Maybe a Unix clone tried it too?) On a 386 or better the nasty 286 system of segment descriptors is available, but a much nicer 'flat' address space model is also available. All of the modern OSes use the flat address space.
Let's look at the XT since you bring it up.
The 8088 has 20 address lines, allowing you to connect 1MB of RAM to it. There is no virtual memory support in the processor, so addressability is limited - it can address up to 1MB total.
The memory map and how that memory is used is an entirely different issue. Some of the areas are reserved for I/O expansion or ROM chips instead of RAM memory. But that does not change the fact that the processor only has 1024*1024 bytes that it can address. That just means that some of the bytes are RAM, some or ROM, and some are on I/O cards. There will be 'holes' in the memory map where no RAM, ROM or I/O cards exist.
Now lets look at a LIMS board. With one of those you could have many megabytes of RAM on the system - let's say 10. But only 16K or 64K (or some arbitrarily small amount) of that memory is 'visible' to the 8088 at any one point in time. That hardware and software works by mapping a chunk of it's memory into the memory map of the 8088. You might have 2 or 4 chunks available even - that's not an important detail. The important thing to remember is that even though you have 10MB on a card somewhere, the 8088 can only see a small portion of it at any one point in time. That's a classic bank switching setup. If effectively gives you access to a lot more RAM, but it is not all addressable at the same time.
Virtual memory goes the other way - it gives you the illusion of having a tremendous address space. The pages of memory that you are actively working with have to appear in physical memory where they can be addressed by the CPU. Pages that are not in use are stored out on disk, or some form of other storage. The CPU and operating system work to bring referenced pages into memory 'on demand', and hide it from the application.
You are basically 'over committing' the physical memory. This works well because most applications don't need access to all of their address space at the same time. When you take it too far you feel it - the operating system starts 'paging', which is swapping pages in and out from main memory to disk, and that's slow when you are waiting for something to happen.
Chuck is absolutely right to bring up address space, because that is how the programmer sees the machine. Most machines have far more address space available in a single process than can be physically connected to the machine, especially when you take into account that each process can run in a different address space. On a 286 this is done using a nasty system of segment registers, which to my knowledge only OS/2 ever used. (Maybe a Unix clone tried it too?) On a 386 or better the nasty 286 system of segment descriptors is available, but a much nicer 'flat' address space model is also available. All of the modern OSes use the flat address space.
MikeS
Veteran Member
A concise overview of different aspects of RAM to be sure, but my question was really one of semantics rather than architecture.
To me the term "physical RAM" means exactly what it says, i.e. 'real' physical RAM chips that are installed and accessible and, contrary to your opinion, I suspect that if you asked how much physical RAM is in a certain system most people would also assume that that's what you meant, not just what the particular CPU in that system can access at that time and in that particular configuration.
It seems very counterintuitive to me that the *physical* RAM in my computer will change from 4MB to 64K just because I switch from a 68000 to a Z80; the word is 'physical' after all, not 'logical', 'accessible' or what have you, and physically nothing about the RAM has changed at all. In order to determine the "physical RAM" in a system apparently I can't just count the chips but have to consider the CPU and the mapping; presumably a Z80 system with 64KB of memory split into two banks would only have 32KB by your definition and by flipping one DIP switch I'd double the physical RAM. Is it really so different conceptually to output a bit to a bank register instead of changing one of the bits of the address lines?
Confusing, as I said, but it's good to know that this is what some people might mean when they talk about "physical RAM."
I'm still curious what you would answer to my questions though.
And if I'm going to learn new meanings of established words, what *do* you call the memory that's not physical or virtual?
To me the term "physical RAM" means exactly what it says, i.e. 'real' physical RAM chips that are installed and accessible and, contrary to your opinion, I suspect that if you asked how much physical RAM is in a certain system most people would also assume that that's what you meant, not just what the particular CPU in that system can access at that time and in that particular configuration.
It seems very counterintuitive to me that the *physical* RAM in my computer will change from 4MB to 64K just because I switch from a 68000 to a Z80; the word is 'physical' after all, not 'logical', 'accessible' or what have you, and physically nothing about the RAM has changed at all. In order to determine the "physical RAM" in a system apparently I can't just count the chips but have to consider the CPU and the mapping; presumably a Z80 system with 64KB of memory split into two banks would only have 32KB by your definition and by flipping one DIP switch I'd double the physical RAM. Is it really so different conceptually to output a bit to a bank register instead of changing one of the bits of the address lines?
Confusing, as I said, but it's good to know that this is what some people might mean when they talk about "physical RAM."
I'm still curious what you would answer to my questions though.
And if I'm going to learn new meanings of established words, what *do* you call the memory that's not physical or virtual?
Last edited:
In a computer architecture discussion, 'physical' refers to memory directly connected to the bus and addressable using 'physical' addressing. This isn't my 'opinion', it is a well known term in computer science and it is well defined.
The difference between physical and other types of RAM is that the processor can access physical RAM using addresses put on a bus, while the other types of RAM require some sort of setup or 'trick' to bring it into view before it can be accessed. So yes, it might be physically attached and present in your system, but if your processor can't access it through the memory bus using a normal bus cycle then it is memory the processor can not use.
I called the memory what it is - in the case of something like LIMS, it is bank switched.
There are plenty of good computer architecture books out there. The one by Hennessey and Patterson (Computer Architecture: A Quantitative Approach) is the best.
I don't want anybody to get the impression that I'm redefining what 'physical' means in terms of memory addressing - this is a well known definition.
The difference between physical and other types of RAM is that the processor can access physical RAM using addresses put on a bus, while the other types of RAM require some sort of setup or 'trick' to bring it into view before it can be accessed. So yes, it might be physically attached and present in your system, but if your processor can't access it through the memory bus using a normal bus cycle then it is memory the processor can not use.
I called the memory what it is - in the case of something like LIMS, it is bank switched.
There are plenty of good computer architecture books out there. The one by Hennessey and Patterson (Computer Architecture: A Quantitative Approach) is the best.
I don't want anybody to get the impression that I'm redefining what 'physical' means in terms of memory addressing - this is a well known definition.
Chuck(G)
25k Member
Mike, to be fair, you changed the rules of "physical" a bit by disallowing bankswitching.
So, a Z80 has 16 address lines and therefore can address 64K of physical memory. A Z180/64180 has the same basic CPU, but incorporates bank mapping hardware on-chip and so can physically address 512K.
If we take Andrew's Z80 and a bit of extra hardware, we can extend its physical addressing to 1MB easily. Stick the mess in a block of potting compound and it's a package with 1MB physical memory connection.
In fact, an 8086/8088 can't address more than 64K without using its on-chip bankswitching hardware (called "segments") but has connections for 1MB of physical memory (or 4MB if you decode the segment status). And, in fact, the 80286 has to rely on fancy bankswitching/mapping hardware to connect to that 16MB of memory.
If we specify that "physical memory" is determined solely by the amount of memory that can be directly connected to the processor, then it's irrelevant if the CPU uses bankswitching, mapping, swapping, or any other sort of mechanism to extend the addressing range. And it's really irrelevant if said hardware exists on-chip or off.
So, a Z80 has 16 address lines and therefore can address 64K of physical memory. A Z180/64180 has the same basic CPU, but incorporates bank mapping hardware on-chip and so can physically address 512K.
If we take Andrew's Z80 and a bit of extra hardware, we can extend its physical addressing to 1MB easily. Stick the mess in a block of potting compound and it's a package with 1MB physical memory connection.
In fact, an 8086/8088 can't address more than 64K without using its on-chip bankswitching hardware (called "segments") but has connections for 1MB of physical memory (or 4MB if you decode the segment status). And, in fact, the 80286 has to rely on fancy bankswitching/mapping hardware to connect to that 16MB of memory.
If we specify that "physical memory" is determined solely by the amount of memory that can be directly connected to the processor, then it's irrelevant if the CPU uses bankswitching, mapping, swapping, or any other sort of mechanism to extend the addressing range. And it's really irrelevant if said hardware exists on-chip or off.