[Coco] 64k memory limit (was) CP/M emulator for OS9/6809

[Wayne Campbell]

Hi Bill,

I had completely forgotten about the GET/PUT buffers. I remember back when
I first got my CoCo3, I was told then that GET/PUT buffers could be used
for more than just screen buffers, but I didn't feel I knew enough to
investigate them. I think I am ready now. I will let you know how my
progress goes.

Please do keep me posted on MShell. I am definitely interested in seeing it
under emulation. I hope to see it on a real CoCo3 before too long, even if
not my own hardware, through a video on youTube.

Take care, my friend,

Wayne



On Tue, Apr 29, 2014 at 3:35 PM, Bill Pierce <ooogalapasooo at aol.com> wrote:

>
> Wayne,
> The 1.5.2b version of Mess with Becker Port is still being worked on. The
> version Richard linked has some serious problems and has to be reworked.
> The beta testing of MShell is no hurry because I broke it today and now
> I've got to fix it LOL
> I was adding some new cool features and all of a sudden it quit working on
> the real Coco, but worked in Vcc... then in trying to isolate that problem,
> it no longer works in Vcc either. I should have it back up and running
> within the week, even if I have to backtrace and remove the new features
> and get it back to what I had it. My last backup was right before I got
> working again after 2 mpnths, so I definately don't want to go back that
> far, though I may have to. It's usually the same problem, some rogue
> pointer sending data into never-never land and crashing the system.
>
> The virtual memory concept is pretty easy (in theory) and should work in
> Basic09 fine as Basic09 has all the needed calls built in.
> The whole theory is to use the "get/put" buffers. You can assign as many
> g/p buffers as you have free memory. The default size is 8k, regardless of
> what you assign, 8k is allocated.
> What MShell does is maps a full 8k buffer into the 64k, writes to it using
> pointers until it's full, unmaps it and maps in the next. All buffers
> remain in protected memory until you kill them. All buffers have a unique
> ID and can be mapped back in at any time to be read/modified/or written to.
> What get's complicated is the pointer structure to keep up with what buffer
> and where in that buffer the data is located.
> MShell actually use 3 such buffer structures, each independant of the
> other. Each can also expand to the limits of memory. The buffers are
> allocated in "Group" & "buffer#". Each Group can have up to 255 buffer#s,
> each 8k in size. The mapping routines I use, basically consist of 3 or 4
> cmds that keep my "current" pointer always pointing to the right buffer.
> When I move to the next data block, the pointers automaticall up and
> call/create new/old buffers as needed. All of which is invesible to the
> programmer as well as the user (once it's all set up :-)
> It's all in the tech ref manual and the basic09 manual as well as the
> windows manual. They just never told anyone that those graphics buffers
> would actually hold any kind of data you want to put in them. It was
> assumed they would only work with graphics data.
>
> I'll let you know when I get MShell back up again :-)
>
>
> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Webmaster of The TRS-80 Color Computer Archive
> http://www.colorcomputerarchive.com/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>



-- 
The Structure of I-Code
http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code

decode
http://cococoding.com/wayne/