[Coco] How much memory

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 
bus. Essentially.

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.
>
> Wayne
>
> ----- 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
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

-- 
William Astle
lost at l-w.ca