[Coco] 512K AND Beyond??? How FAR Beyond???

[Dave Philipsen]

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 
easier.

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.

https://youtu.be/LMg55_vDZWc


Dave


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.
>
>     Richard
>
>     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!!
>     [1]https://youtu.be/WlcjJLiOQbQ
>     and while playing a wav file!!
>     [2]https://youtu.be/G8a9-6R7wh0
>     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
>     it"
>     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
>     [3]https://sites.google.com/site/dabarnstudio/
>     Co-Contributor, Co-Editor for CocoPedia
>     [4]http://www.cocopedia.com/wiki/index.php/Main_Page
>     E-Mail: ooogalapasooo at aol.com
>     --
>     Coco mailing list
>     Coco at maltedmedia.com
>     [5]https://pairlist5.pair.net/mailman/listinfo/coco
>
> References
>
>     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
>