User:Rhialto: Difference between revisions
No edit summary |
No edit summary |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
== Improving dual disk drive handling == | == Improving dual disk drive handling == | ||
Currently, dual disk drives live a strange half / double life. Drive 1 of unit 8 (using the terminology of Basic 4 and | Currently, dual disk drives live a strange half / double life. Drive 1 of unit 8 (using the terminology of Basic 4 and confusingly, in some of the code) is using most of the data structures that would otherwise be used by unit 9. So if you want 2 dual drive units, they will have unit numbers 8 and 10. | ||
This madness is clearly visible in source file ''src/drive/ieee/fdc.c''. | This madness is clearly visible in source file ''src/drive/ieee/fdc.c''. | ||
| Line 12: | Line 12: | ||
''static fdc_t fdc[NUM_FDC];'' will become static ''fdc_t fdc[NUM_FDC][2];'' and the drive number will be the second index. | ''static fdc_t fdc[NUM_FDC];'' will become static ''fdc_t fdc[NUM_FDC][2];'' and the drive number will be the second index. | ||
This change will flow outwards like an oil spill, since many functions are used via pointers and need to have the same signature... | This change will flow outwards like an oil spill, since many functions are used via pointers and need to have the same signature... so the compiler will easily tell you what more has to be changed (and I didn't really research how far this will extend). Possibly, at some point, changes will be required at a point where you think "this is getting really really far from the starting point" and then maybe some creativity will be required. | ||
For dual drives, there must be some code to reset both drives, if the unit is reset, for instance. I'm not sure where such things currently happen, but it may need to be moved. | For dual drives, there must be some code to reset both drives, if the unit is reset, for instance. I'm not sure where such things currently happen, but it may need to be moved. | ||
| Line 18: | Line 18: | ||
Other weird things: | Other weird things: | ||
* ''struct drive_context_s'' refers to ''struct drive_s'' which refers to a ''struct disk_image_s'', but ''fdc'' also refers to such a thing, and so does (for 2 types of disk controllers) ''context->wd1770->fdd->image'', and ''context->pc4877->fdds[0]->fdd->image'' and ''context->pc4877->fdd->image'' and ''context->pc4877->current->fdd->image'' | * ''struct drive_context_s'' refers to ''struct drive_s'' which refers to a ''struct disk_image_s'', but ''fdc'' also refers to such a thing, and so does (for 2 types of disk controllers) ''context->wd1770->fdd->image'', and ''context->pc4877->fdds[0]->fdd->image'' and ''context->pc4877->fdd->image'' and ''context->pc4877->current->fdd->image'' | ||
* but there is no ''context->fdc''. The fdc structs are accessed by number which is probably picked up from ''context->mynumber''. | * but there is no ''context->fdc''. The fdc structs are accessed by number which is probably picked up from ''context->mynumber''. Making this more similar to wd1770 and pc4877 is a separate change. | ||
* Should there be 2 ''drive_context''s for dual drives, or just one which refers to 2 ''disk_image_s''? If there should be 2, then where are these aggregated? (drive_context_s seems to be more a unit context, or drive as in device) | * Should there be 2 ''drive_context''s for dual drives, or just one which refers to 2 ''disk_image_s''? If there should be 2, then where are these aggregated? (drive_context_s seems to be more a unit context, or drive as in device) | ||
* Most of the things in ''drive_t'' (''drive_context'' points to one) are indeed per-drive, but some also belong to the unit (such as ''parallel_cable'', ''drive_ram2_enabled'', ''rom'' and some more. | * Most of the things in ''drive_t'' (''drive_context'' points to one) are indeed per-drive, but some also belong to the unit (such as ''parallel_cable'', ''drive_ram2_enabled'', ''rom'' and some more. | ||
* Maybe ''drive_context_s'' should be renamed to ''unit_context_s'', with pointers to 2 ''drive_t''s, and some items moved from ''drive_t'' to ''unit_context''. | * Maybe ''drive_context_s'' should be renamed to ''unit_context_s'', with pointers to 2 ''drive_t''s, and some items moved from ''drive_t'' to ''unit_context''. | ||
* But there are so many uses of ''drive'' to mean the unit / device, maybe drive in the other meaning should be renamed. But what would be a good name??? "mech", short for drive mechanism??? | |||
Latest revision as of 19:42, 20 August 2019
Stub page to show I exist.
Improving dual disk drive handling
Currently, dual disk drives live a strange half / double life. Drive 1 of unit 8 (using the terminology of Basic 4 and confusingly, in some of the code) is using most of the data structures that would otherwise be used by unit 9. So if you want 2 dual drive units, they will have unit numbers 8 and 10.
This madness is clearly visible in source file src/drive/ieee/fdc.c.
There are 4 fdc_t structures, each of which corresponds to a drive. (Despite the name that suggests floppy disk controller). When using unit 9 or 11, or num_drives is 2, weird stuff happens in functions like fdc_reset().
My proposal here is to change all functions here that take a unit number (in particular those that also do something with a disk_image_t), and change them to take a drive number too.. static fdc_t fdc[NUM_FDC]; will become static fdc_t fdc[NUM_FDC][2]; and the drive number will be the second index.
This change will flow outwards like an oil spill, since many functions are used via pointers and need to have the same signature... so the compiler will easily tell you what more has to be changed (and I didn't really research how far this will extend). Possibly, at some point, changes will be required at a point where you think "this is getting really really far from the starting point" and then maybe some creativity will be required.
For dual drives, there must be some code to reset both drives, if the unit is reset, for instance. I'm not sure where such things currently happen, but it may need to be moved.
Other weird things:
- struct drive_context_s refers to struct drive_s which refers to a struct disk_image_s, but fdc also refers to such a thing, and so does (for 2 types of disk controllers) context->wd1770->fdd->image, and context->pc4877->fdds[0]->fdd->image and context->pc4877->fdd->image and context->pc4877->current->fdd->image
- but there is no context->fdc. The fdc structs are accessed by number which is probably picked up from context->mynumber. Making this more similar to wd1770 and pc4877 is a separate change.
- Should there be 2 drive_contexts for dual drives, or just one which refers to 2 disk_image_s? If there should be 2, then where are these aggregated? (drive_context_s seems to be more a unit context, or drive as in device)
- Most of the things in drive_t (drive_context points to one) are indeed per-drive, but some also belong to the unit (such as parallel_cable, drive_ram2_enabled, rom and some more.
- Maybe drive_context_s should be renamed to unit_context_s, with pointers to 2 drive_ts, and some items moved from drive_t to unit_context.
- But there are so many uses of drive to mean the unit / device, maybe drive in the other meaning should be renamed. But what would be a good name??? "mech", short for drive mechanism???