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 :-)

[angelosa]

Still not quite convinced that the base z80dma_device has to know it has children here, perhaps moving this logic to ua858d_device and make specnext_dma_device a subclass of that should be the play here?

[holub]

Still not quite convinced that the base z80dma_device has to know it has children here, perhaps moving this logic to ua858d_device and make specnext_dma_device a subclass of that should be the play here?

I did this on purpose for Next case. It needs to switch type preserving existing state of registers.

[angelosa]

I mean, in the context of if somebody else went their own route in subclassing the arch.
Notice that even a // NOTE: or a // FIXME: is okay for me.

[holub]

Ok. Let's assume we keep specnextdma how it was before this commit.
Regarding spectrum which select chip based on mashine config... do I need to add slot for dma now? Or are the other way to do this?

[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.