For a lot of reasons, doing a real expansion port would not work properly without some very serious and I mean VERY SERIOUS level electronics engineering. Basically, they will have to do a new revision of the C64DTV core or obtain rights to use the FPGA core designs in the Turbo Chameleon project and adapt it. Basically, do what Jens Schoenfeld and what also Gideon Zweijter is doing (with the Ultimate 64).
Here's why? The expansion port on the C64 isn't just a game rom port. While doing ROM maybe somewhat easy by using some device interface that reads the ROM and mirrors it onto the hard drive (or flash drive medium used by the emulator) but once you start opening the door for that, you are opening the doors for people who will likely attempt to insert other devices such as RAM expansion units which may try to DMA into the system memory, or devices like CPU accelerators units such as the SuperCPU, RAM Link and other devices including Z80 cartridges that were made for CP/M support. These devices involves other signal lines and essentially a bus mastering system. So in effect, it may cause some serious problems.
For numerous reasons I can not effectively communicate clearly, in short, there are many factors that can go wrong and cause a system wide crash if not possible damage to the main computer and/or the attached plugin devices or even the interfacing mechanism.
The closest thing to the cartridge port on the C64 that you may recognize on IBM PC Compatibles in the past is the old ISA slot. When devices are attached on the cartridge port, they are physically mapped into memory at fixed locations. So is ISA cards on old MS-DOS/early Windows based IBM PC & compatibles. Some plugin devices actually bus masters under DMA to the RAM on the computer.
Another issue is if anything in the emulation is off by enough "1 MHz" cycles or even "System Bus cycles" on the emulation system (which is 14.31818 MHZ NTSC, or 17.734475 MHz PAL) or if anything is tied into the DOT clock and synchronized to it (as it is on the original C64).... but if the emulator is off, things can unravel. Remember, the hardware devices are fairly fixed, especially the original hardware accessories. These devices worked quite consistently. These clocks are extremely stable compared to the variability that is found in modern OSs like Windows which may or may not provide you with stability of emulation to less than +/- 25ns instability variance. Unless emulation is rock solid to say.... +/- 25ns stability tolerance operational stability, I would probably not recommend such. My suggestion is stability of less than 1/2 the clock cycle of the Y1 crystal frequency so that everything operates in perfect clockwork
You'll basically need to match the clock conditions as found on the original systems and probably phase locked.
Some devices may by nature of electronic engineering design be able to ride through clock cycle variation of +/- 10 microseconds or greater clock deviation. Have you not noticed on VICE on Windows (for example) the emulation speed may vary as much as say 2-3%. Usually at about 1% variation due to other activities on the computer and sometimes other issues. The system doesn't always keep an exact consistent 100% emulation when it can run between 95% to 105% and you may see skippy operations. If anything like with an attached expansion port devices that relies on a consistent synchronous clock condition, things may result in problems. In a bad case, it may crash or lock up the system.
These devices were meant to operate a synchronous relationship. In real hardware, +/- 2-3% tolerance in clock stability is probably unacceptable. Maximum instability of the emulation environment should not result in the emulation of the Y1 system clock to be off by more than 25ns. I don't think that can be achieved effectively on software emulation. It might not break the games but hardware accessories on the expansion port may or may not be so tolerant.
We are talking about a world of issues that can crop up and no one has done this yet. If it haven't been achieved in the Commodore community already, it is probably not possible yet. The Commodore community currently has some of the very best and most qualified electronics and programmable logic engineers with acute familiarity of the very nuances of the various models of Commodore computers and their various revisions. We have a community of people that collectively knows more about the C64 than even Jeri Ellsworth or anyone or ALL the individuals working for Retro Games Ltd. including the owner(s) of Retro Games Ltd. This is not meant as an insult but a fact. This community has 30+ years of studies by 100s of individuals with advance education and experience in hardware and software engineering.
These individuals are the world's premier experts of the Commodore system. Collectively, we even have Bil Herd and other people who contributed to that body of knowledge. If we haven't figured out a stable way to do that with Windows or most other modern systems with modern multitasking operating systems, there s probably a good reason and it is unlikely that someone hiring an electronics engineer with very little to no experience with hardware engineering for the Commodore hardware platform is going to just some up with a solution that adheres to a 100% or at least 99.9% compatibility with every known C64 expansion port device.
Retro Games Ltd. has not really involved or consulted these people of the Commodore community on an intensive level. Without doing so, it would be very much impossible for them to do so.