Accessing the address space/accessing more memory than your address bus will allow

Thread Starter

richard3194

Joined Oct 18, 2011
173
If an address register is smaller, in terms of bits, than the width (in bits) of the address bus, then a technique of some description is/was used, so you can use the full address space of the address bus. Now, that problem is a different one to where you want to add memory but your address space won't allow it, because it's fully utilized. This problem is/was also overcome by some technique(s)..

If you were to simply state keywords what would you say they would be for each of the issues mentioned? Thanks.

P.S. Would the keywords be Banking; Segmetation, Offset?
 
Last edited:

MrChips

Joined Oct 2, 2009
30,703
If an address register is smaller, in terms of bits, than the width (in bits) of the address bus, then a technique of some description is/was used, so you can use the full address space of the address bus. Now, that problem is a different one to where you want to add memory but your address space won't allow it, because it's fully utilized. This problem is/was also overcome by some technique(s)..

If you were to simply state keywords what would you say they would be for each of the issues mentioned? Thanks.

P.S. Would the keywords be Banking; Segmetation, Offset?
Segmentation.
 

danadak

Joined Mar 10, 2018
4,057
Old days an I/O pin was used as a pseudo address bit. Clearly you
could not run linear code this way, except to implement jumps in
the respective page created or exited, which set/cleared the I/O pin. Was
a pain but got the job done. RAM was used to pass variables and
flags.......

Also a technique of loading some code into RAM to access a new page,
run some code, and then return.

Regards, Dana.
 
Back in the old days, you had I and D space in kernel and User modes, so the OS, User program, and corresponding data was in their own space.
In one machine addressing was limited to 64K, but physical memory could be much larger with a memory management unit. I or instruction space is effectively read-only.

One thing that i had to do, was manually overlay segments of code. You just had to make sure what was called was in memory at the time of the call. So, a FORTRAN subroutine would keep all of it's variables when swapped to disk.

Other systems used pages. Some instructions only worked within a page boundry.
 

dl324

Joined Mar 30, 2015
16,839
Back in the old days, you had I and D space in kernel and User modes, so the OS, User program, and corresponding data was in their own space.
In one machine addressing was limited to 64K, but physical memory could be much larger with a memory management unit. I or instruction space is effectively read-only.
That brings back old memories. I remember working on a PDP-11/34 that couldn't do floating point. The CAD system running on it stored all coordinates as integers.

I remember trying to get programs to run with less than 64KB of memory so I didn't have to fiddle with overlays. 64KB was big back then; the machine only had 128KB of memory and the total disk space was about 170MB (almost the size of a washing machine).
 
yep PDP-11. I loved that machine. it was well thought out, one you figured out you need a bunch of manuals.

the MSP430 is similar, sort of, but the documentation organization isn't really there.

My first was a PDP-8
then an 11/20
then a PDP 11-50; which was a /45 with CMOS memory
This was "high school" and "High school"+. I worked for the outfit for a while in college.
The service techs were stumps when they could not fix an issue UNTIL I figured out what it was.
It dropped a bit in the processor Status Word when it switched modes. RSTS/E was the OS. We had the OS source code.
3 of us, including me, in our group were the main speakers at a DECUS meeting. Talk was on disk optimization.

then the 11/2 and 11/23+ processors
I basically did one HUGE PDP-11 program in FORTRAN with another person. A 7 loop PID and recipe controller. It was complex and "cool".
and a small real time program. RT11 was the OS.

We enrolled in exchange/repair at the module level. I did all of the troubleshooting to the module level. Most maintenance was replacing 8" floppy drives, fans and removing dust. The electrical issues went away when I conditioned the power.
 

danadak

Joined Mar 10, 2018
4,057
As a semi test EE mid 70's I worked on a PDP-8 and various Teradynes.

Working on 8, had a disk pak, one disintegrated, right next to my ear. Just a loud bang
inside its case, but makes one jump. Paper tape loading and TTY, don't want to go back
no matter how sentimental.

One Teradyne J machine docs so bad built a test vector generator and discovered
what parts of its instruction set would do. Thats an ugly way to write test code
for sure.

Someone did a single chip PDP 8, anyone remember who the vendor was ?
Signetics had a funky part, cannot remember whose architecture it was or
if it was sole sourced original. I think I still have one.

Regards, Dana.
 
Last edited:

MrChips

Joined Oct 2, 2009
30,703
Hi. Are you saying the technique of segmentation resolves BOTH issues? Rich
According to your initial post #1, you have outlined two different scenarios.

1) Attempting to map a smaller address register into a larger memory space.
I would call this segmentation.

2) Attempting to extend memory beyond a fixed memory space.
I would call this banking.

However, I believe that these are not hard and fast definitions.
 

Thread Starter

richard3194

Joined Oct 18, 2011
173
I'm a beginner and I've just realised (I think) that 2) is about memory expansion techniques. I probably should do a Google search on that. Rich
 

MrChips

Joined Oct 2, 2009
30,703
When people started trying to overcome the 640KB limits of the IBM PC, they came up with a whole rigmarole of expanded memory vs extended memory. Thank goodness that is now forever buried in the annals of PC.
 

Thread Starter

richard3194

Joined Oct 18, 2011
173
One thing: In my foray into computing, I'm more concerned with microcontrollers. Where memory expansion techniques are probably more relevant. :)
 

RichardO

Joined May 4, 2013
2,270
One thing: In my foray into computing, I'm more concerned with microcontrollers. Where memory expansion techniques are probably more relevant. :)
As a general rule, I would expect it to be cheaper to choose a microcontroller that has enough memory for the task than trying to expand the addressing range.

It will be *much* cheaper in software time. Bank switching is fraught with dangers that are hard to spot and fix. This is what makes the small PIC microcontrollers so hard to use.

If you need a lot more memory, such as for data logging, then an external memory such as an SD card would be another option.
 

GetDeviceInfo

Joined Jun 7, 2009
2,192
One thing: In my foray into computing, I'm more concerned with microcontrollers. Where memory expansion techniques are probably more relevant. :)
Yes and no. Micro controllers today are largely designed to perform a range of tasks. Need a different task performed?, then migrate to the appropriate solution. Data pass through is big, but again, a soc or similar might be a better solution. Micros service ‘port’ requirements.
 

BobaMosfet

Joined Jul 1, 2009
2,110
As a semi test EE mid 70's I worked on a PDP-8 and various Teradynes.

Working on 8, had a disk pak, one disintegrated, right next to my ear. Just a loud bang
inside its case, but makes one jump. Paper tape loading and TTY, don't want to go back
no matter how sentimental.

One Teradyne J machine docs so bad built a test vector generator and discovered
what parts of its instruction set would do. Thats an ugly way to write test code
for sure.

Someone did a single chip PDP 8, anyone remember who the vendor was ?
Signetics had a funky part, cannot remember whose architecture it was or
if it was sole sourced original. I think I still have one.

Regards, Dana.
I remember working with the PDP8a/e and 11 in nuclear energy industry. We used them to run fuel handling machines that moved fuel blocks in and out of the core. We used C & assembly language, and even modeled a PDP-8 in a 386, down to instruction timing so that we could run 3D simulations (we wrote a simulator) to confirm punched card, mylar and paper-tape control files operated correctly before running them in the core live.

Love the PDP-8a/e
 

MrChips

Joined Oct 2, 2009
30,703
Cut my teeth on a PDP-8/S.
Went on to become the service tech for the PDP-8/S and many other minicomputers after that.

I was able to recite the RIM loader by heart after having to toggle that into memory so many times!
 
Top