z80dma.cpp: add derivateves ZILOG, UA858D, SPEC_NEXT

[holub]

z80dma.cpp: add derivateves ZILOG, UA858D, SPEC_NEXT sinclair/spec128.cpp: configuration option for DMA extension

details: https://velesoft.speccy.cz/data-gear.htm

[ajrhacker]

Is there a good way to avoid wedging SpecNext configuration into the base Z80DMA device? (Perhaps UA858D might also be worth supporting as its own type for East German systems such as rt1715.)

[holub]

I was thinking about it too. The problem is that both zx mod and next itself allows switch between two modes. Having it separated will make usage on the client's side a bit more complicated.

[angelosa]

Consider using a virtual sub function that gets overridden in the subclasses?

[holub]

Consider using a virtual sub function that gets overridden in the subclasses?

Not sure it's clear for me. E.g. for Next we have one dma which operates in both modes depending on the port. That means we can init dma in Z80 mode but start in N.

[angelosa]

Yes, and moving this logic from specnext_dma.cpp/.h to z80dma doesn't sound a solution to me. Consider that anything that don't care about Next will branch false twice for every single transfer byte with this. What's wrong about do_write being handled in specnext_dma instead?

[holub]

I can revert specnext_dma files. What about ua858d? Are we agree to keep it conditional here and just expose extra type which sets desired mode in the constructor?

[holub]

@ajrhacker @angelosa Better?

[holub]

ping

[holub]

  /,-"0"-.\
 //   |   \\
||9   o   3|D
 \\    `. //
  \`-.6.-'/
   `=---='

[rb6502]

@angelosa Is this OK? We should've merged this about 4 months ago if yes :-)

[holub]

OK I left specnext_dma separated. But I really don't want to split ZILOG/UA858D otherwise it require to introduce slots/slot_devices for DMA chip in Spectrum which I think is an unnecessary overhead.

[holub]

Here is alternative without UA858D - #13385