[Coco] 512K AND Beyond??? How FAR Beyond???
dave at davebiz.com
Wed Dec 27 15:57:11 EST 2017
Richard, I generally agree with you. Especially if you start
manipulating hi-res graphics and such, the 6809 will get bogged down
with the shear size of the data. However, when using a synthesized or
emulated 6809 that runs much faster than 2 MHz those chores may become
Inspired by the CoCo3FPGA, I am currently working on a 6809 based 7-inch
LCD capacitive touch screen terminal. The 6809 core runs at 25 MHz and
I'm using a 1 MB memory chip because the display is memory-mapped and it
alone needs 600K to display 1024 x 600 graphics with 256 colors. The
fast 6809 handily deals with all of this while communicating over a
RS422 link at 1Mbps. Imagine the simple task of clearing the screen to
a solid color. This requires the manipulation of 100x more data than
than a PMODE 3 or 4 graphics screen!
Here's a link to a very quick little video showing the LCD display with
two different screens. One is a keyboard and the other is a numeric
keypad. The screens look like they could be text screens because the
graphics are fairly simple right now but it's a bit-mapped display and
the CPU must draw every pixel.
On 12/27/2017 12:55 PM, Richard Cavell wrote:
> Hi everyone. I just want to offer my two cents.
> Would it be possible to set aside a few bytes of the address space to
> function as bank-switching registers, and then construct a custom
> bank-switching mechanism to add more memory via a cartridge? Using
> this mechanism you could add any amount - even gigabytes.
> But the 6809's ability to retrieve and process that memory is limited.
> Once your program genuinely needs more than a few megabytes of RAM to
> be simultaneously accessible, the 6809 is no longer the correct CPU to
> be using.
> Sent: Wednesday, December 27, 2017 at 4:09 PM
> From: "Bill Pierce via Coco" <coco at maltedmedia.com>
> To: coco at maltedmedia.com
> Cc: "Bill Pierce" <ooogalapasooo at aol.com>
> Subject: Re: [Coco] 512K AND Beyond??? How FAR Beyond???
> Robert, Jim and anyone else, OS9 did NOT use memory above 2 meg. The
> only software I know of using this is the ramdisk in the NitrOS9
> repository specifically written for Paul Barton's 8 meg board and it
> accesses the memory directly and not through OS9's memory manager. Of
> course, there's Robert's test programs as well.
> The DAT tables required for anything above 2 meg are too large for
> system memory and something would have to be modified/changed before
> NitrOS9 can "legally" use memory above 2 meg.
> That being said, the memory above 2 meg CAN be used with special
> programming... as data space, graphics memory storage, etc, but the
> program itself would have to keep tabs on what memory is being used and
> what memory is free (above 2 meg). A good example of this is Dave
> Philipsen's BMP display demo for the Coco3FPGA which loads 20+ 640x450,
> 256 color BMP files into memory the runs a slideshow. The Coco3FPGA
> DOES have some memory and graphics functions that a Coco3 does not, but
> it would still work on a Coco3with standard Coco3 res screens (with a
> little modification to the software)... and store about 40-50 (maybe
> more, too lazy to do the math) 640x192 graphics screen!!
> and while playing a wav file!!
> And yes, this was done in NitrOS9 on the Coco3FPGA @25mhz!!
> Also, to clear something up... I keep seeing that the 1-2 meg is "just"
> used for ramdisks... Yes and no. This is only true IF that's what you
> assign it to.
> The 1-2 meg upgrades are used in NitrOS9 as REGULAR mappable memory. In
> other words, if you're running programs, you have more memory for more
> programs. More graphics pages and windows can be assigned. More/larger
> get/put buffers can be used and much more. This is all transparent to
> the user, no special commands needed... NitrOS9 just has more memory.
> The 64k workspace limit still applies, but you can have even have more
> 64k workspaces. It "Just Works".
> A good example of this would be Ultimuse3. It is originally configured
> to a 256k score buffer. With the change of a single variable, it can
> use up to 1.5 meg (system and program use the rest) for the score
> buffer. I may make this change on the next release :-)
> Another example is my MShell project. The MShell File Manager reads 2
> complete directories into memory. On large HD directories or PC
> directories (yes, MShell will read/copy directly from your PC HD using
> DW4), you could read massive directory into memory. MShell dynamically
> allocates the memory for the huge buffers using get/put buffers and
> will utilize the 1-2 meg upgrades (all done "legally"). MShell also
> forks various modules as it runs. With more memory, MShell easily
> handles the forking of subs along with massive data buffers for program
> use (not to mention other programs running in other windows) and it's
> all transparent to the user. MShell doesn't do anything special to use
> this memory, it works with 512k or above. All the heavy lifting in the
> memory management is done transparently by NitrOS9.
> To say "it's not used" or "who would need it?" is just saying "You
> never had it!". I've been running my real Coco3 with 1 meg and VCC with
> 2 meg for years and when I go back to 512k, I get frustrated when I run
> out of memory for extra processes, windows, or graphics.
> The Coco3 memory upgrades above 512k fall in that category of "You
> don't know you need it until you've had it and then have to do without
> I'm lost on a 512k machine these days.
> Bill Pierce
> "Charlie stole the handle, and the train it won't stop going, no way to
> slow down!" - Ian Anderson - Jethro Tull
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> Co-Contributor, Co-Editor for CocoPedia
> E-Mail: ooogalapasooo at aol.com
> Coco mailing list
> Coco at maltedmedia.com
> 1. https://youtu.be/WlcjJLiOQbQ
> 2. https://youtu.be/G8a9-6R7wh0
> 3. https://sites.google.com/site/dabarnstudio/
> 4. http://www.cocopedia.com/wiki/index.php/Main_Page
> 5. https://pairlist5.pair.net/mailman/listinfo/coco
More information about the Coco