[Coco] How much memory
asa.rand at gmail.com
Sun Nov 28 22:04:30 EST 2010
Thanks for that info, William. I didn't know the 8088 was a 16-bit CPU. I
always thought it was a 8-bit. Now I understand how it worked out that DOS
had more memory to play with.
----- Original Message -----
From: "William Astle" <lost at l-w.ca>
To: <coco at maltedmedia.com>
Sent: Sunday, November 28, 2010 2:30 PM
Subject: Re: [Coco] How much memory
> 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 bus.
> 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 achievable.
>> 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
> William Astle
> lost at l-w.ca
> Coco mailing list
> Coco at maltedmedia.com
More information about the Coco