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"

Looking at the code, I think the code smell is that you've blown out all of your template instantiation in that huge two dimensional array, and between that and template parameters such as A/B/C/D/E/F, it is very difficult to follow what is going on.

Also, I'm not familiar with this view stuff... is this new? (i.e. - <5 years old? ;-))

I think that it does make a great deal of sense to do view setup up front in device_start(), but it looks like you're trying to do even more up front by populating m_all_ram_maps and m_ram_rom_p0_maps in the constructor. Given that device_start() only happens once in an emulation session, it isn't clear to me what this buys you, and it really obscures that is going on.

Instead of having "uber templates" that do everything (all_ram_map, ram_rom_map, ram_rom_map_p1, ram_read) for swathes of the address space, I'd favor smaller templates that "governed" specific slices of memory ($0000-$0FFF, $1000-$1FFF, $2000-$3FFF etc) and had set up the right thing based on well named template arguments (i.e. - not single letters). And instead of creating a big lookup table, use switch/case statements to select the right template when setting up the view.

Of course, its highly likely I might be missing something.

Views are the replacement for address_map_bank_device, circa 2021. The syntax is a bit cleaner and there are performance advantages since it's built into the memory system.

I don't think it can actually replace all the use cases yet, I tried talking OG into extending emumem a while back.

Remind me what you noticed could be added? I forgot by now, sorry...

Two use cases I can think of off the top of my head that I may have mentioned.

1. 573 banks onboard flash and pccard slot in a 4mb window. The onboard flash fits within the window, but the pccard slot can be any size.
2. commodore/clcd.cpp has a smaller banking granularity than the window size.

My understanding, at the time we discussed it, was that neither of those were supported by views but you considered that it was possible.

I think we'd agreed that bankdev could stick around for the degenerate cases, but looking at flashbank_map in 573 I don't see how it's unusual (clcd certainly is).