Originally Posted by Ze_ro
So how does it actually work then? Reading the document I linked to earlier, it seems to show up as CAT:... but what can be done with it? Will it read and write just as if it were any other device, or is it limited to simple file copying?
It works just like any floppy-like Amiga device as long as software is using standard AmigaDOS access functions. (=copiers like XCopy won't work but plain diskcopy or most adf<>disk utilities work)
Is this planned for UAE at some point, or is this all just hypothetical based on the design of the hardware? I would have thought that modern hardware like the Catweasel and KryoFlux would be fast enough to process/serve data within the time window that the emulated Amiga would expect (at least when talking about "standard" file access)... but I suppose using a non-real-time operating system prevents any guarantees about this.
Problem is not OS but latency between software and hardware (floppy drive), time between sending command to drive and getting reply back takes some time.
Also note that Catweasel can either read/write to disk from internal RAM or internal RAM is copied to/from host PC, both can't be done simultaneously. Which makes real-time emulation practically impossible (without keeping emulation paused most of the time..)
For example some copy protection might do this (just an example, there are many similar situations)
- read data until something specific happens (data matches some magic word, index sync, whatever)
- switch disk side but keep reading
Disk side switching should be instant but because USB and software is packet based, some data is still in buffers that must be flushed. Now we have the problem, it takes some time before disk side switching gets to the drive and first data arrives from drive. Only 100% compatible solution is to pause the emulation until data arrives. (we are again in "sync")
Copy protection is happy. User might not be happy enough. (especially if music or sound was playing)
Or we can keep emulation running
Copy protection is unhappy ("gap in data? that can't be original disk") and user is very unhappy (game didn't work)
Standard disk accesses don't need that kind of accuracy and would work just fine in most situations.