Skip to content
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

Modifications to DOS1 mode to support various media geometries #40

Open
Eugeny1 opened this issue Dec 12, 2019 · 1 comment
Open

Modifications to DOS1 mode to support various media geometries #40

Eugeny1 opened this issue Dec 12, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@Eugeny1
Copy link

Eugeny1 commented Dec 12, 2019

This is already implemented in the GR8BIT storage subsystem, and it would be beneficial for Nextor to implement it too. I am very interested in it as I want to use Nextor in new version 4.0 of the GR8BIT storage subsystem. This is rather enhancement request than issue reporting. I do not see how I can set the relevant state for this request.

When DOS1 kernel enumerates devices at the label A587E, please install addition routine call to the driver which will return the default copy of the DPB for each drive (if supported) for the mode selected - instead of using hard-coded DEFDPB structure. Alternatively, you can require that call to just copy its target default DPB to the location pointed by DE.

Why it is helpful: returning custom DPB for each allocated drive will allow driver to use its own configuration files (like GR8BIT using EEPROM to store the drive configuration and maximal capacities) to size their drives appropriately - for example choosing FAT size (3 sectors/1.5KB RAM space or 9 sectors/4.5KB RAM size) according to user selected settings. Using driver'supplied DPB will also give it opportunity to have devices of different geometry in the system - e.g. 720K 3.5" drive and 360K 5.25" drive as a starting maximal setting.

You can set it up the same way as you did with the DRV_TYPE: e.g. bit 3 set if driver supports individual initial configuration of the drives/devices.

Maybe it has sense to install this into the DRV_CONFIG call with A=3 supplying C=DOS1/DOS2 mode (as driver must know this info, and it is important for storage configuration selection), and relative drive number at boot time (also very important and identifies what drive to get unique DPB). Supply target location for DPB in DE so that driver on this call, if supporting this function, copies respective drive's DPB in the predefined kernel's working location, and then kernel uses this information to calculate the (maximal) size of FAT for the drive in the memory.

I will give you an example:

  • in DOS2 mode the size of FAT does not much matter as all variables are located in the high pages of mapped RAM, thus user may have standard 1.44M disk in 3.5" drive (80/2/18, 9 FAT sectors = 4.5KB of RAM), and standard 1.2MB disk in 5.25" drive (80/2/15, 7 FAT sectors = 3.5KB of RAM). In addition, if HDD is installed, its FAT12 may consume up to 12 sectors (6KB), and in total in this configuration will consume 14 KB of space (I hope I calculated it correctly for DOS2);
  • in DOS1 taking 14KB of bank 3 CPU RAM is a lot, leaving approximately only 10KB for BASIC. In this mode user can select drives, with reduced size: so called "compatible-1.44M", with 3 sectors per FAT, but 4 sectors per cluster, and "compatible-1.2M", with 3 sectors per FAT and also increased number of sectors per cluster. Note that this "reduced" mode will also support legacy media geometry - 720K and 360K of both 3.5" and 5.25" drives.

For more information on the possible functionality see my knowledge base article "GR8BIT DN0003: Storage subsystem v.3.0 Manual" here: http://kb.gr8bit.ru/DN0003/GR8BIT-DN0003-Storage-subsystem-v-3-0-Manual.html.

@Eugeny1
Copy link
Author

Eugeny1 commented Dec 12, 2019

Forgot to say one important related thing: it would be correct to impement checking of actual drive FAT size against space allocated for this drive at the initialization stage to ensure machine does not crash if 9 FAT sectors media being inserted into maximum 3 FAT sector size configured drive - that would be ok to just return read error at the FAT reading stage during new insterted media initialization.

@Konamiman Konamiman added the enhancement New feature or request label Dec 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants