[Coco] Bubble Memory

[Zippster]

Well that’s true.  If you want the RAM usable by your video pages (VDG), you’ll have to
interface it directly to the SAM (and data latches) so that interleaved memory access can be used.

You can still bank it with some additional logic outside the SAM of course, but the
lower address lines have to handled by the SAM.  You’d also need a connection to deal
with the latches handling RAM data output to the CPU data bus and VDG.

This could be done a couple of different ways, but is a pretty extensive upgrade. 

I think the easiest way is probably to add additional ram that can’t be accessed for
video by asserting SLENB to access expansion RAM (this can even be added at the cart port).

Then simply don’t use SLENB to override memory areas being used for VDG pages.
This might complicate software somewhat, but the hardware is pretty straightforward.

- Ed


> On Aug 15, 2017, at 12:56 PM, RETRO Innovations <go4retro at go4retro.com> wrote:
> 
> On 8/15/2017 10:21 AM, Zippster wrote:
>> It was never really there…  Anything involving over 64K will involve banking of
>> some sort.  The 32K blocks have to be just a limitation of the scheme they used
>> in this case.
> I agree.  They were going with low pars count, and banking into the 32kB RAM bank was an easier task that banking on 8kB pages
> 
> That said, I looked at the article this morning (thanks John) and then looked at the Coco1 and Coco2 schematics.  The kicker is trying to get the VDG and the CPU to see your new RAM.
> 
> Would it be horrid if the situation were simplified a bit?  Say, let the CPU see megabytes of RAM, but let the VDG stay in the original 64K map?
> 
> Jim
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco