Z80 core extensions

[qufb]

Regarding the Sega Ferie pull request, there was a need to extend the Z80 core to support memory paging behaviour in Toshiba T6A84. This requires customizing 3 distinct parts:

1. Interrupt acknowledgement;
2. Return from interrupt;
3. Branch/Jump execution;

Existing core functions to support this are:

• irqack_cb: Supports 1), but my understanding is that it shouldn't be used for custom behaviour, since it has a well-defined purpose on hardware;
• daisy chaining: Supports 1) and 2), although I'm not sure how applicable it is here (it's not an external device interrupting the processor);

Therefore, some additional extensions are required to support all 3 parts.

Is having dedicated callbacks ok for supporting features in undocumented Z80 processors, and if not, what are the alternatives here?

[holub]

Extending z80 with unexisting functionality just to take shortcuts is possible but not always good idea. That can hit us back when somebody bravely decide to rewrite the core.

Something which can help you is: set_irq_acknowledge_callback where you can return custom vector if needed.
Other drivers (and that's how real hw behaves) "are sniffing the bus" and depending on what they see perform desired actions (e.g. accel in sprinter.cpp)

[qufb]

Ok, this seems in line with what I initially did for 2) and 3) with reti_cb and branch_cb, I can make another one or try to reuse set_irq_acknowledge_callback for 1).

[qufb]

After reviewing these options again, a dedicated callback seems more adequate to me:

• set_irq_acknowledge_callback does not cleanly address this issue, because the default vector is always picked, I don't want to return a custom vector. What is dynamic here are ROM bytes mapped in memory from which vectors get fetched. This is why I initially used m_irqack_cb. Having a dedicated callback avoids having to duplicate the default vector logic, but I'm ok with either option.
• Memory hooking as done by the taps in that accel buffer example doesn't address 1). It could address 2) and 3), but would also complicate some changes, since it would require instruction decoding the fetched program bytes to figure out what is rti or branches then update memory pages accordingly. I would actually expect the processor to make this mapping at a stage where instruction decoding or execution was done, so after the bus was already set.

[holub]

It's up to you what path you want to choose: make the code cleaner or make it behave like real hw. I'm just questioning how in real life cpu provides access to such cb-like functionality.

[holub]

As it's "84" I'm wondering if something you need is translation 16bit address to wider range?

• z84c015.cpp + sprinter.cpp (18bit MEM)
• or in general: zxbus.cpp + smuc/nemoide (17bit IO addressing)

[qufb]

Somewhat similar, but T6A84 seems more capable: it requires at least 19bit addressing (the ROMs we have are all 0x80000 bytes and fully addressable by program code), and likely has more address spaces involved.

I'm not very familiar with those z84c015 processors, but looking at z84c015_device::translate_memory_address, it seems to also imply that the larger addressable memory corresponds to separate chips (at least going by the cs0/cs1 comments)?