Removing obsolete DMA / hypervisor related registers

[lgblgblgb]

We have $D653 and $D654 to carry over DMA source and target 'megabyte' information during hypervisor traps.

I think it's an ancient fragment from the past, when MEGA65 had DMA registers to set these information. Currently these can be only set via enhanced mode DMA with enhanced mode option list, which are not register based, and only valid within a DMA session context. Since DMA session cannot be interrupted, there is simple no sense to try to preserve/restore this information. Thus $D653 and $D654 can be removed speaking of the VHDL code of MEGA65-core. I'm not sure that freezer or any other components tries to do something with these registers, clearly that could be removed too then if there is any usage there.

UPDATE: other one:

The other interesting material for me is reg_dmagic_withio in the VHDL. This is only DMA (not hypervisor) related. As far as I can see, this signal is only used that it can be set by writing $D702 and can be read with the same register. But other than that, no other use, then what's its function at all. Either it can be removed too, or otherwise its function should be documented, or at least mentioned in the VHDL as a comment.

UPDATE: yet another one:

$ grep reg_dmagic_status *
gs4510.vhdl:  signal reg_dmagic_status : unsigned(7 downto 0) := x"00";
gs4510.vhdl:            when x"03" => return reg_dmagic_status(7 downto 1) & support_f018b;

This is kinda interesting. So reg_dmagic_status is not so much used at all, always zero. As far as I know it should be 0x80 during a DMA session, even some odd things on C65 to indicate if the session is chained or not (not sure ...). However It's true that since DMA is non-interruptable nobody will ever see a non-zero value ;) On C65 probably it was designed in mind that DMA can be interruptable one day (so DMA list even have the INT bit to allow interruption by hardware interrupt, I guess at least the maning of that bit). But as how it is now on MEGA65, it can be safely removed, I guess (not the support_f018b part, obviously). I can imagine only one scenario when non-zero DMA status can be noticed: setup a DMA job witch copying I/O to memory, and allow DMA to read/copy its own status register ;) So the CPU can inspect later what was the status during a DMA session. Very-very picky case without too much sanity though ...