There's a debate going on about my device, in German,
over here.
I'm not going to try get into a Google Translate based argument on that website, but there is plenty on nonsense being stated there about how my interface works, like this (via Google Translate):
"Unfortunately, Derek took a shortcut. It does not simulate the original interface but returns the contents of the SD card straight away, which is significantly faster. The if1bis can do that more compactly, with rs232 and much more."
The statement quoted above is wrong in a couple of ways. I'll add some clarifications here in case anyone is ever interested.
I do not return the contents of the SD card straight away. I initially read the contents of the MDR cartridge image into a memory cache (at the "cartridge insertion" point of the GUI) and use that cache to simulate the "tape". My interface works at the Z80 instruction level. It spots the IN and OUT instructions as the Z80 issues them and makes the appropriate read and write accesses from that memory cache. When connected to the Z80, my interface passes data via the CPU's data bus in exactly the same way as the original hardware does. I do not use a hacked ROM, I use an exact binary image of the machine code in the Interface One's ROM. That's how I get 100% compatibility: I'm using the exact same software, and hardware which is identical to the Z80 at address-, data- and control-bus level.
The reason my interface runs significantly faster than the original Microdrive is simply because it doesn't need to wait for the tape to run past. When the code in the IF1 ROM wants the next sector on the tape, the original hardware needs to wait for the tape to move along. On my device the software in the Pico can make the first byte of the next sector available as soon as the IF1 code wants it. I still simulate the format of the cartridge, so I present the various "gaps" from the surface of the tape in the same way the Microdrive does, but other than that my interface runs at the maximum speed the Z80 code in the IF1 ROM can run at. My interface loads Manic Miner in about 2 seconds, which is as fast as the IF1 code can load it (and no faster).
I did not take a shortcut. There are a couple of ways to implement an IF1/Microdrive emulation. One is to essentially emulate the IF1 ULA and the signals it receives from the Microdrive hardware. That would indeed have the advantage of hardware compatibility. The second method is to simulate (rather than emulate) the Microdrive's function at the MDR file level. That's what the FUSE emulator does, and in fact my code started off based on a port of the FUSE emulator code to the Pico SDK. Either approach should work, both have their merits and drawbacks. I chose the second approach. I did not see the lack of hardware compatibility as a drawback, I didn't want that. Some might disagree.
The comparison made to the if1bis is therefore somewhat moot, but just for the record I'll explain. The if1bis uses a modified ROM and works at the IF1 "hook code" level which it reimplements for SD card access. Hook codes are standardised and documented entry points to the IF1 ROM (read sector, write sector, erase, start motor, etc). There are 26 of them. Any program which uses hook codes should be compatible with standard Microdrive operations, including the extended BASIC interpreter, and that is the level the if1bis works at. This is fine for most programs, but will fail for anything written in machine code which bypasses the hook codes, uses non standard entry points in the ROM, or uses its own code for, for example, higher capacity formatting. Paul Farrow's ZXC3 ZX Microdrive-mimicking cartridge works at this level too, reimplementing the hook codes for his flash storage. Those devices do not claim 100% compatibility which is fair enough. I do claim it. My code doesn't reimplement anything. It works at the individual Z80 instruction level using the original IF1 ROM code and as far as I know I'm compatible with everything ever written for the Microdrive.
One more point: I did not implement the network and RS232 features of the IF1, simply because I didn't want them. There's no reason they can't be added. In fact, the FUSE code I based on has them, and I actually took those features out in order to simplify the code so I could understand it. So it's not so much about adding those features as putting them back in.
Right now I have no plans to do it, but if someone asks, or I need another project, I might well do it.
Right. I've set the record straight, just in case anyone cares.
perfection.
