[Coco] How much memory

[Wayne Campbell]

Hi Aaron,

Actually, that's sortof the way DCom works. It is 5 different parts, each 
composed of the modules necessary to complete that portion of the decompile. 
The main program (part 1) loads each of the other parts in its turn. Decode 
is 3 modules, and each chains to the next. In all it works (well, mostly, as 
there are still some things not finished), but I feel like I'm not doing it 
right, and for one main reason. DCom is to I-Code modules, for all intents 
and purposes, what DisAsm is to object code modules. My thinking is that I 
should be able to decompile I-Code modules with one module the same way 
DisAsm disassembles object code modules with just one module.

Maybe my thinking is incorrect.

Wayne
----- Original Message ----- 
From: "Aaron Wolfe" <aawolfe at gmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Sunday, November 28, 2010 6:19 PM
Subject: Re: [Coco] How much memory


> On Sun, Nov 28, 2010 at 2:36 PM, Wayne Campbell <asa.rand at gmail.com> 
> 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?
>>
>> 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.
>>
>
> Hey Wayne, it's been a while, hope things are going well for you.
>
> Have you explored the option of splitting your Basic09 program into
> several modules?  Each would have it's own 64k space if I understand
> the system correctly.  Your source could be much larger this way too.
>
> -Aaron
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco