True Drive Emulation Speed

[chysn]

In VICE: Is there a way to make True Drive Emulation faster? Or, if I want to use it for its compatibility, must I necessarily live with its speed? I can toggle Warp mode before and after a disk operation, so it seems that slowness isn't necessary for emulation reasons. I tried to crank up the disk RPM to 500,000, it but it tops out at 340.

[Mike]

[... If] I want to use [TDE on] for its compatibility, must I necessarily live with its speed?

This.

O.K. - longer answer:

In VICE: Is there a way to make True Drive Emulation faster?

With TDE on: use one of the available drive speeder( program)s, like JiffyDOS. I presume you also want single character I/O sped up; that rules out most other drive speeders for the VIC-20 that only accelerate LOAD (and maybe SAVE), like TurboDisk (NTSC only) or Hypra-System (PAL only).

JiffyDOS requires you to both I) exchange one of the drive ROMs and II) use either a JD KERNAL or one of the soft Jiffy implementations like SJLOAD or zippy on the VIC-20 itself.

Most drive speeders' exclusiveness to a certain TV norm also highlights the next aspect:

I can toggle Warp mode before and after a disk operation, so it seems that slowness isn't necessary for emulation reasons.

For most of the involved data transfer protocols, the computer and drive CPU need to be operated in lock step, at their known certain ratio of their CPU clocks. Using the wrong TV norm can make the data transfer routines lose synchronization even during a single byte! Emulation Warp Speed "releases any handbrakes" so to speak, so the emulation runs at full host CPU speed - with computer and drive CPU still synced to each other! -, but the emulated system as whole loses any realistic synchronization to the rest of the world: you surely will not be able appreciate the 1000+ frames/second the "VIC" chip delivers now, neither would you want ultrasonic sound and tunes at runaway beats/minute from the speakers (which is why sound output is switched off).

I tried to crank up the disk RPM to 500,000, it but it tops out at 340.

That's a fun idea, but not how drive acceleration works in reality.

A drive with more than a few RPM away from 300/min is defective. This is mostly emulated in VICE to have a way to stress-test those drive speeders for tolerable variations of the drive rotation speed without the need to manipulate real hardware - and in any case only changes the "speed" of the magnetic media below the drive head, but not the bit rate the floppy controller uses to write the raw data to disk (reading the bits is in certain sense self-clocked due to the GCR code - there's still a tolerance band in play however). CBM DOS itself is able to cope with floppies written on a slow (~295 RPM) drive being read back on a fast (~305 RPM) drive, and the other way round, by including slack between the sectors on a track.

[chysn]

For most of the involved data transfer protocols, the computer and drive CPU need to be operated in lock step, at their known certain ratio of their CPU clocks.

Thanks, I pretty much figured the answer would be this particular aspect of it. And I wondered to myself, "Yeah, but can't that be overcome?" And my answer to myself was, "Sure it can, that's what the Virtual Device is."

I have to accept VICE for the beautiful work of genius it is.