#512 Selection of device emulation type is way too complicated (and buggy too).

v2.4
open
nobody
None
Drives
2015-04-02
2014-04-01
No

As you can see at
http://vice-emu.sourceforge.net/wiki/index.php/Drive_options_precedence,
there is a complex decision tree to determine how (at what level of
precesion or method) a device is emulated. This is too complicated for
the user, and it also reflects an unneccessary complexity inside VICE.

It is buggy too: the "True Drive Emulation" (TDE) option affects
printers (non-disks) as well.

The TDE option is global, and it should be per-device. It is not
unreasonable to want to emulate, say, device 8 with TDE, 9 with file
system access, and 7 with OpenCBM to access external real hardware.

There should be a single sub-menu for each device which determines what
type of emulation to apply:

true drive emulation (TDE), or  [*]
disk image emulation, or        [*]
file system access, or
raw /dev/fd0 device access, or  [*]
real IEC device access via OpenCBM.

[*] disk devices only

and the same one-location principle should be reflected in the code:
there should be only one data structure that determines the emulation
type, and it should be looked at only once to determine that.
(That could be by having some function pointers that jump
directly to the correct code (instead of spreading such virtual function
tables all around), or just checking a field which unambiguously
contains the type of emulation).

As it is, OpenCBM access only works if TDE is disabled, even for
non-disk devices. The code internal to VICE is so complex that (so far)
I haven't even been able to find out why, but it seems that (if TDE is
enabled) bytes that should be sent under ATN to device #7 (LISTEN,
UNLISTEN, etc) are sent as plain data bytes, and others disappear
completely.

There is a nice set of #defines in "serial.h" and a struct serial_s
which seems, at first glance, suitable as a starting point. There are

#define SERIAL_DEVICE_NONE 0
#define SERIAL_DEVICE_FS   1 /* filesystem */
#define SERIAL_DEVICE_REAL 2 /* real IEC device (opencbm) */
#define SERIAL_DEVICE_RAW  3 /* raw device */
#define SERIAL_DEVICE_VIRT 4 /* non-tde drive/image */

and it would only need a

#define SERIAL_DEVICE_TDE  5 /* tde drive/image */

to represent all possible choices.

(Aside: since RAW is really just accessing a disk image, I don't really
see the need for it; it is initially accessed by opening a device
instead of a file, but apart from that it's all identical. So we should
be able to get rid of it. Even the code in diskcontents_read() seems to
suggest so.)

Also, there is serial/serial-iec-device.c with resources IECDevice{4-11}
and command line options -iecdevice{4-11} but I haven't been able do
discern any effect of those settings. Nevertheless there is non-trival
code there.

Discussion

  • gpz

    gpz - 2015-04-01

    RAW makes sense for platforms that do not let you access a block device via a file handle (like *nix) - DOS for example.

     
  • Greg King

    Greg King - 2015-04-02

    To say it in another way: RAW doesn't access an image; it accesses a real disk. Some PC micro-floppy disc controllers can be reprogrammed to handle 1581 disk data. The RAW mode was designed to exploit them.

    But, of course, it has been superceeded by OpenCBM and the ZoomFloppy and similar adapters.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks