-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardizing drive letter assignment regardless of disk rom location #65
Comments
I think this way one could also still boot from floppy when a Nextor based device is inserted, also in line with how things works on PC (although that currently does not work on HB-G900P, actually machine won't boot from floppy or Nextor if a floppy is inserted on such a machine) |
An alternative solution (at least it introduces the same consistency) is to reinitialize the FDD within Nextor. MMCSD does this when it detects an already initialized FDD so on HB-F500 MMCSD will still take A: drive (since version 5.50 of the firmware). |
On machines with built in disk-drives where the disk rom is in slot 0 (e.g. Sony HB-G900P) the floppy drives will become A: and B: and the first Nextor drive will be C: (system will sill boot from C:). The same would happen if a machine had no internal disk drives but an external disk drive was inserted into slot 1 and nextor in slot 2. On machines where the disk rom is in a higher slot, nextor will assign it's drive from A: and disk drives will become C: and D:.
I think it would be good if Nextor would always let the DiskROM initialize first (and let disk drives be A: and B:) and Nextor drives become C: onwards. I believe this could be accomplished by having Nextor hook into H.STKE on boot and let the disk rom initialize prior to Nextor, regardless if it is in a lower or higher slot.
What needs to be considered also is what if there are no internal disk drives? Should Nextor start from A: or still use C:, my vote would be to keep it on C: in such a case as well.
Of course this is just an/my opinion but it would make behavior more consistent across different MSX machines and also bring it in line how PC's behave with MS-DOS (and onwards).
The text was updated successfully, but these errors were encountered: