Home Page Forums MAME MAME Two dimensional array of method pointers

I'm converting the CoCo's memory controller to use views (https://github.com/tlindner/mame/blob/sam-view/src/mame/trs/6883sam.cpp#L351)

I think having a two dimension array of address_map_constructor is the way to go, but I don't understand the compiler error I am getting:

../../../../../src/mame/trs/6883sam.cpp:353:5: error: no viable conversion from '<overloaded function type>' to 'address_map_constructor' (aka 'named_delegate<void (address_map &)>')

I instead went with a large if/else if/... block. But I don't like it.

I'd appreciate any help.

I have no idea what you’re even trying to do there, but the code is so gross I’m not even going to try working it out.

I roughly get what he's trying to do, but as far as I know views can only be one dimensional.

Are you trying to implement what should essentially be a mmu with views?

I think what the SAM does couldn't be considered an MMU. But I am trying to support it's many configuration options with views. I like this approach because there is almost no calculations done during RAM I/O, and switching modes is fast.

The SAM supports 5 different type of RAM configurations (4k, 8k, 16k, 32k, 64k) and there are 16 different modes select able at runtime.

That's 80 possibilities. I'm using templates to create the many combinations and two dimensional arrays to organize them. Most of the combinations are degenerate and not very useful. The previous version only supported the few useful combinations.

I've found one piece of software that uses one of the degenerate cases to probe the actual installed RAM (agvision). All the other SAM machines use a jumper to tell the initialization software how to correctly configure the SAM.

I was able to solve the particular problem that cause me to create this thread. But I'd love to hear feedback on my implementation.

Could you explain what the sam does for my personal curiosity?

On address bus I/O it will generate three bits of chip enable signals. This segments the address space into 8 regions. Each region's size and existence is determined by the SAM's current mode.

On RAM I/O it will generate 8-bits of RAS and CAS data fed directly into the RAM chips. It does this for both the CPU and video chip, interleaved.

It coordinates with the video chip to refresh dynamic RAM chips during vertical retrace.

Isn't it kinda, sorta a mmu that adds 3 bits to the address? Wouldn't it work better it we thought about it that way?

It might. What core classes should I look into? What driver I should study?

I've been meaning to look into core support for MMUs because a project for later it to redo the CoCo 3 memory model because it does use an actual MMU.

I would characterize the SAM as a poor man's MMU

It did some MMU-like things, like swapping a ROM/RAM mode with pure RAM, mirroring RAM address space, but its primary purpose was to allow the CPU and the VDG (video chip) to share RAM. "SAM" stands for "Synchronous Address Multiplexer"