Quantcast
Channel: Why did CP/M require RAM in the bottom part of the address space? - Retrocomputing Stack Exchange
Viewing all articles
Browse latest Browse all 4

Answer by tofro for Why did CP/M require RAM in the bottom part of the address space?

$
0
0

The 8080 that CP/M was originally designed for has very limited possibilities to produce code that can run anywhere in memory - Everything has to have fixed addresses. This results in the need that CP/M systems need to be recompiled for every new memory size and address map - It is convenient to do that for the system only once and not for applications that you want to be portable between systems, after all, you wanted one WordStar binary running on any system - Thus, the applications need to go into low memory, starting from some fixed address, regardless of maker, memory size, and architecture of the system.

The first CP/M computers had RAM sizes starting from ~16kBytes (CP/M 2.2 needs about 20kB). So, CP/M, aiming to be a portable, "one-size-fits-all" operating system, had to assume some memory map. The main RAM area a bare-bone CP/M system needs for its own purposes is the sector buffer, sized 128 bytes, that has to end up somewhere. CP/M decided to put that at 080H by default. That left the first byte to be used by user code (thus, the TPA) at 0100H.

Below that (0-80H), CP/M puts the BDOS vector and a stub for the reset code (8080 starts execution at 0 after reset), so you had to have a limited amount of ROM that could overlay at least the first three bytes (JMP into the BDOS). At 5CH, you would normally see an FCB (the second main CP/M data structure), also all the other administrative data structures CP/M needs reside in the lower 80H bytes.

So, to sum it up, the space for applications had to start in low memory, at a fixed address that would be possible to implement in all architectures. They couldn't start at 0, because the OS had to be at 0 to be run after a reset, and they knew they needed at least the FCB, the vector area, and at least one sector buffer plus a minimum set of administrative variables - Thus 100H was simply the lowest possible address user code could start from.

In order to have the CPU see ROM (thus, "code") at address 0 at cold boot, you could use a number of tricks (well not tricks, but rather pretty common strategies). The luxury version was to have a paged-in cold-boot ROM (several kBytes) starting from 0 shadowed by writable RAM - This ROM would then load and set up CP/M from disk, and once done, be paged out, leaving an all-RAM system.

The "not-so-luxury" version would have been a permanently paged in ROM at higher addresses (say, 08000H, for simplicity), and a piece of circuitry that would fiddle with the address lines at cold boot to trick the CPU into running that ROM (In my example, that would be a simple flip-flop that switched address line A15 to high). The first instructions in that ROM would then need to be a JMP to 08003H where you would find code that switches that flip-flop. That way you would be able to have the ROM permanently paged in (but obviously this part of the address map is now occupied and limits the amount of available RAM for CP/M and applications)


Viewing all articles
Browse latest Browse all 4

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>