[Coco] How much memory
lost at l-w.ca
Sun Nov 28 17:30:31 EST 2010
On 10-11-28 12:36 PM, Wayne Campbell wrote:
> Just to throw out a couple of things I thought about. I remember
> wondering why we were stuck with a 64K barrier when DOS (running on a
> 8-bit 8086/8088) was able to access 640K of continuous RAM. That's 10
> times as much. I know DOS used tricks to achieve it, but the computers
> were not slowed down by these "tricks" at all. Nor were they slowed down
> when Extended and Enhanced memory were introduced. Is there a reason
> DECB/SECB and/or OS-9 could not be made to do that?
FYI, the 8086 is a 16 bit CPU. The 8088 is an 8086 with an 8 bit data
The 8086/8088 CPUs have a *20 bit* address bus. The 6809 has a *16 bit*
address bus. That's the entire difference, right there. The trick you're
thinking of is in the CPU design, not DOS: segmentation. The segment
register contains the upper 16 bits of the physical address while the
pointer register (including the "program counter) contains the lower 16
bits. Yes, there is a 12 bit overlap. Thus, "near" and "far" pointers,
and a whole host of other complications that come with it. But what it
comes down to is that the 8086 can *directly* address more than 64K
while the 6809 cannot.
Extended memory leveraged the 32 bit address bus of the 80386 and the 32
bit protected mode in the processor. I believe enhanced memory was
different but I never had to deal with it so I don't know for sure.
Anyway, my point is that it was CPU limitations that dictated the memory
size, not operating system limitations. Because the Intel chips had at
least a 20 bit address bus, more memory was, therefore, accessible
directly, thus providing a larger address space for individual programs.
OS9 level II (Coco 3) allocates memory in 8K chunks into 64K address
spaces, not every address space being fully allocated nor even being
contiguous in physical memory. Each process (not window) gets a 64K
address space and the system itself gets a 64K address space.
No matter how you slice it, to access more than 64K on a 6809, you need
fairly complex coding contortions that are not hidden from the
individual processes. On the 8086, no such contortions were needed for
"near" processes (less than 64K or one "segment") and less visible means
were needed for "far" processes, but needed nonetheless. For programs
running in 386 protected mode, direct access to 4GB is theoretically
> As for OS-9, as I recall, the memory was allocated in 64K chunks per
> window (on CoCo3), all one chunk on a CoCo2 (I never had a CoCo1, so I
> don't know if it was ever expanded to 64K). The "system page" in OS-9
> used 1 64K chunk, and when the system was loaded you had ~32Kof
> available space in that chunk for loading more modules. Each hardware
> window is allocated a 64K chunk. After the system modules for that space
> are loaded, you have about 40K of space left in that chunk. While this
> may be plenty for a program written in ASM/RMA, it can run out quickly
> when programming in Basic09, C or Pascal, especially when you are
> writing an application (as opposed to a utility program). This is true
> especially when you are learning to program.
> DCom, as it started out, was larger than 40K total, and I had to break
> it into separate parts that would be loaded "in turn" as each step
> occurred. Having worked on trying to finish it, I discovered that I had
> written it very badly, even if it was "everything I knew about
> programming". However, this does not mean that the program would be
> necessarily small enough to run in 40K of space even in the form of
> unpack (it's replacement) when it is finished. I started running into
> that wall with unpack and with decode (the test program) as well. I
> learned that I needed to sacrifice comment lines if I was going to make
> everything fit, and then my code might not be so readable. Replacing
> cryptic variable names with longer descriptive names didn't help either.
> I sinply used up the extra space with the longer names.
> I always felt like it would be nice to be able to write a program as a
> 60K app, if that's what it took, and then start whittling it down to see
> how small I could make it. Of course, that never happened, and decode
> and unpack are, as yet, unfinished.
> I realize that with the new FPGA-based CoCo4 design, memory will be
> dealt with differently. However, I think OS-9 and DECB/SECB will still
> have to be modified to deal with the extra memory, if any part of the
> plan includes being able to access more than 64K per window.
> ----- Original Message ----- From: "RJLCyberPunk" <cyberpunk at prtc.net>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Saturday, November 27, 2010 8:52 PM
> Subject: Re: [Coco] How much memory
>> I find it odd that OS9 has that limitation that all other current
>> computer operating systems do not have. why have the designers of OS9
>> built a 2MB memory address limitation?
>> ----- Original Message ----- From: "Robert Gault" <robert.gault at att.net>
>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>> Sent: Saturday, November 27, 2010 8:23 PM
>> Subject: Re: [Coco] How much memory
>>> Frank Swygert wrote:
>>>> One little nit though -- BASIC can't address 512K, not without a
>>>> lot of modification anyway. BASIC is still limited to 64K without bank
>>>> shifting some of the RAM or using some other tricks.
>>> I have to take issue with this statement, Frank. :)
>>> Super Extended Basic on the Coco3 can and does use more than 64K
>>> whenever you use the high res text or graphics screens. There are
>>> quite a few programs that combine Basic and ml programs to use the
>>> full 512K memory.
>>> As already stated by others, OS-9 can easily use 2Megs of memory but
>>> unfortunately the operating system itself can't use more than 2Megs.
>>> Keep in mind the boards by Paul Barton that had 8-16Megs of memory.
>>> So any new "Coco" should have at least 2Megs.
>>> Coco mailing list
>>> Coco at maltedmedia.com
>> Coco mailing list
>> Coco at maltedmedia.com
> Coco mailing list
> Coco at maltedmedia.com
lost at l-w.ca
More information about the Coco