FD502 Refactor/Replacement

[ChetSimpson]

FD502 Refactor/Replacement

I am currently working on refactoring the FD502 cartridge with the first phase concentrating on the WD1793 implementation. Various parts of the WD1793 are being extracted into stand-alone components to increase their stability, maintainability, and reusability. Serious GOGI.

This effort will introduce several new storage based components to libcommon which in the future will replace parts of other existing cartridges.

The organization and naming is preliminary and support for DMK and physical floppies will need to be added back in. Supporting DMK is easy though so that'll be in soon. Physical drive support is another story. Most of these components will be used in the eventual refactor of SuperiDE, HardDrive, and SDC cartridge implementations.

Storage Media

• vcc::media::sector_record_header - Describes the parameter defining a sector record stored on virtual media.
• vcc::media::sector_descriptor - Describes the parameters for a sector including its header and data.
• vcc::media::disk_image - Defines the basic interface for performing read, write, and other related operations on virtual storage media.
• vcc::media::disk_images::basic_disk_image - Basic implementation of the disk_image interface supporting the VDK, JVC, and OS9 files via geometry parameters.

Storage Devices

• vcc::hardware::disk_geometry - Groups basic parameters used to define the attributes of a disk drive and similar devices.
• vcc::hardware::storage::disk_drive - Defines the basic interface of an emulated disk drive device allowing reading and writing to storage media.
• vcc::hardware::storage::disk_drives::basic_disk_drive - Basic implementation of the disk_drive interface providing timed signalling to support asynchronous operations of the controlling device (WD1793).

Device Controllers

• vcc::devices::storage::wd1793 - The refactored and relocated implementation of the WD1793 FDC in the FD502 cartridge.

[ejaquay]

These things should remain in fd502.

WD1793 has no use outside of fd502. it makes zero sense to move it into libcommon. It belongs to fd502.

The most commonly used virtual disk storage formats do not use headers. They are simply contigious 256 byte sectors. Occasionally a header is prepended because a odd sector count would otherwise confuse the magic used to determine the number of sides, which is important for locating sectors or track 17. Complicated track or sector layouts are rarely used floppy formats and those used by fd502 are quite different from what is used by the sdc.

As soon as we stop trying to read and write real floppies we don't need CRC checks or to replicate the exact formatting used on a floppy except perhaps to emulate some copy protection scheme some package uses.

AFIK headers are not used at all by vhd files.

Lastly but not least we do not want to risk critical functionallity which has been working for many years with large changes. Make small changes and test test test.

[ChetSimpson]

These things should remain in fd502.

The 1793 device will likely end up staying with the FD502 cartridge but everything else will remain in libcommon.

[ChetSimpson]

Scratch that. The WD1793 will be moving into libcommon as well.

[ejaquay]

My opinion is pulling out and standardizing components of FD502 is a worthwhile effort. Moving any but the most generic of those components to libcommon is not.

[ChetSimpson]

My opinion is pulling out and standardizing components of FD502 is a worthwhile effort. Moving any but the most generic of those components to libcommon is not.

Then why did you put the becker port in there?

[ejaquay]

re: Why put becker port in there? Good question. Before I did I actually worried it would take us down the path of moving other kinds things like those we are discussing here. In the end I decided it was mostly a pretty generic ip interface and there are other places it can be used (see latest bit banger enhancement request for one) Acia also uses ip and COM interfaces that are messy and could use standardization. It maybe better to rename what is in the common tcpip or net something.

[ChetSimpson]

libcommon is for modular and reusable components that are or are likely to be used by multiple projects, How generic, complex, large, or small they are is irrelevant.