[Coco] PAK ROM Memory and the MPI

[Walter Zambotti]

Thanks guys

The info from everyone helped  considerably.

The hardware MMU update for Linux prototype is working.

With performance improvements 25%-33% depending on IO ratio.

This performance comes about from improvements to the MemRead/Write8 functions where OVCC was spending a large percentage of its time and 
which no longer need to determine what page a memory access is occurring on.

Here is the original Memread8:

unsigned char MemRead8(unsigned short address)
{
	if (address<0xFE00)
	{
		if (MemPageOffsets[MmuRegisters[MmuState][address >> 13]] == 1)
			return(MemPages[MmuRegisters[MmuState][address >> 13]][address & 0x1FFF]);
		return(PackMem8Read(MemPageOffsets[MmuRegisters[MmuState][address >> 13]] + (address & 0x1FFF)));
	}
	if (address>0xFEFF)
		return (port_read(address));
	if (RamVectors)	//Address must be $FE00 - $FEFF
		return(memory[(0x2000 * VectorMask[CurrentRamConfig]) | (address & 0x1FFF)]);
	if (MemPageOffsets[MmuRegisters[MmuState][address >> 13]] == 1)
		return(MemPages[MmuRegisters[MmuState][address >> 13]][address & 0x1FFF]);
	return(PackMem8Read(MemPageOffsets[MmuRegisters[MmuState][address >> 13]] + (address & 0x1FFF)));
} 

And here is the optimized version:

unsigned char MemRead8(unsigned short address)
{
	if (address<0xFE00)
	{
		return(taskmemory[address]);
	}
	if (address>0xFEFF)
		return (port_read(address));
	if (RamVectors)	//Address must be $FE00 - $FEFF
		return(vectormemory[address]);
	return(taskmemory[address]);
}

I now will add the hardware MMU support as a configurable option to OVCC and release a
new version soon!

Walter

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Robert Gault
Sent: Thursday, 17 October 2019 5:27 AM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] PAK ROM Memory and the MPI

There are some minor errors in the previous answer.

The MPI is controlled via $FF7F where the most significant nibble selects the expansion ROM and interrupts while the least significant nibble selects the I/O at $FF40-$FF5F.
$FF7F      value        slot
             $00          1   front
             $11          2
             $22          3
             $33          4   rear
possible    $nm          mixed slots
ex          $30          I/O via slot 4 ($FF40-$FF5F) with PAK ROM at slot 1

ROM MEMORY
Coco 1 or 2 ROM $8000-$FEFF
Coco 3      ROM $8000-$FDFF as $FF90 is normally set to constant DRAM at $FExx but is adjustable.

Jim Snider wrote "Maximizing the Multi-PAK" which describes the above and a table of addresses and the devices that use them in the Coco memory map.
Unfortunately I don't think Jim's paper is available for download.

Robert


RETRO Innovations wrote:
> On 10/16/2019 9:01 AM, Walter Zambotti wrote:
>> Got some good news about the performance improvements I am making to OVCC.
>>
>> No I didn't make the assembly any better!
>>
>> One of OVCC projects/goals was to implement Linux MMAP Memory Mapping 
>> (Some of you might remember I tried something similar on Windows using AWE which was not a success).
>>
>> Apart from MMAP being much simpler than AWE it supports memory 
>> sharing which allows a memory page to be mapped several times to different addresses.  This really suits OS9 on the CoCo.
>>
>> Anyway I have a prototype running and performance is up about 33%+. 
>> (Soon to be released)
>>
>> I can make it a little bit faster and much cleaner but first I need 
>> to know how the ROM mapping works in the CoCo in relation to PAK ROM.
>>
>> I believe PAKS can have ROMS (8-18k) and those ROMS can be mapped 
>> into the address space from $8000-$BFFF.
> Coco3 can map from 8000 - $feff, I believe, but Coco1/2 can only map the $c000-$ffef segment.
>>
>> What complicates this is the MPI.
>>
>> If the MPI contains multiple PAKS each with it's own ROM I can see in 
>> (O)VCC that the PAK that is selected gets its ROM mapped.
>>
>> The MPI also has a port register that allows the slot selector to be change programmatically.
>>
>> If this slot is programmatically changed should/would this change the 
>> ROM that was mapped into memory?
> Yep.
>>
>> Also what is the purpose of the spare slot select?
> It's for IO (so, you can have different things from an IO range mapped into $ff40-$ff5f per slot.
>>
>> Walter
>>
>>
>>
>

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco