Drive assignment during CPM Boot

[kiwisincebirth]

The drive assignment performed during boot of a CPM operating system is complex, but in summary it tries to evenly split across all floppy, and hard drive media

Background :

I have a SC126 with 4 disk devices (2x SD Card, and 2x CF Card). I typically have 3 of these populated

• Primary CF Card with all primary Slices, including both OS and data slices for given applications
• Secondary CF Card used as a complete backup of the primary. Use CopySL (shameless plug) to do regular backups.
• Primary SD Card. Fat Partition only, with a large collection of files, used to bulk transfer from PC/Mac

After I boot, only 3 drives are typically useful (A,D,E), I have to remap F onwards

A0:SYSTEM>assign

   A:=IDE0:25
   B:=MD0:0
   C:=MD1:0
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE1:0
   G:=IDE1:1
   H:=SD0:0
   I:=SD0:1

If I remove all but the primary drive, i get a very different mapping.

A0:SYSTEM>assign

   A:=IDE0:25
   B:=MD0:0
   C:=MD1:0
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE0:2
   G:=IDE0:3
   H:=IDE0:4
   I:=IDE0:5
   J:=IDE0:6
   K:=IDE0:7

Idea :

Change the drive assignment to favour the boot hard drive, and to ignore other Hard drives. Thus after boot from the primary drive.

11:02 A0:SYSTEM>assign

   A:=IDE0:25
   B:=MD0:0
   C:=MD1:0
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE0:2
   G:=IDE0:3
   H:=IDE0:4
   I:=IDE0:5
   J:=IDE0:6
   K:=IDE0:7
   L:=IDE0:8
   M:=IDE0:9
   N:=IDE0:10
   O:=IDE0:11
   P:=IDE0:12

Note

• This would of course change if I booted a different device
• It is easy to assign all drive letters since I don't have to try and evenly split up drive letters
• The assignment is the same regardless of the other media that is inserted
• The algorithm is much easier to explain
• Booting off Floppy driver, unsure how to adapt to this ?

Impact :

Code in cbios.asm and boot.z80, but it is not a big change. Unfortunately it appears that it cannot be conditionally configured based on Platform configuration.

[wwarthen]

Hi @kiwisincebirth,

You have hit upon yet another area of RomWBW that I am also very dissatisfied with. The automatic drive assignment logic was created over time as RomWBW features increased. As a result, it is not really the result of a well thought out design process.

So, this is a topic very worth of discussion. As you say, it seems like the process could be made much simpler. The big caveat here is that the current automatic drive assignment logic is very impactful to all users. Any changes to the logic will cause confusion. I am very willing to discuss this, but if any changes are made, I am going to want to go through a pretty complete process of soliciting feedback from the user community. If this is changed, I never want to change it again! 🙂

Your proposed assignment process is simpler (and therefore easier to explain). The original reason that I included all of the hard drives in the auto assignment was because people don't read the manual and I was getting a lot of questions like "where is my new drive?". Experienced users of RomWBW know that they just need to use ASSIGN to get to those drives. However, I do care about the initial experience that novice users have even if they have not taken the time to RTFM.

Before trying to decide if your proposal is better than the current auto assignment, let me ask another question that I consider much more important. The current and proposed auto assignment will map some number of slices to drive letters starting from the first slice of the disk (aside from the boot slice). This has never actually made sense to me because that means you are normally mapping a bunch of drive letters that contain files tailored to different OSes than the one you are booting. Why would you want that? This seems soemwhere between useless and dangerous. I think you would want the boot drive of the OS to be A:, then some set of application/data drives, not other OS drives.

I know I am opening a can of worms here, but if the auto drive assignment process is going to change, I want to make sure it is rock solid for the future.

Eager to hear your thoughts. And the thoughts of any others!

Thanks, Wayne

[kiwisincebirth]

@wwarthen

let me ask another question that I consider much more important. The current and proposed auto assignment will map some number of slices to drive letters starting from the first slice of the disk (aside from the boot slice). This has never actually made sense to me because that means you are normally mapping a bunch of drive letters that contain files tailored to different OSes than the one you are booting. Why would you want that?

Fair Question: And one I addressed fairly early on, probably why raised this discussion. Fairly shortly after installing the combo image I saw the gap (you describe) in auto assignment. Main part of writing the CopySl.com application was to be able to just move slices at will. Once written I moved to a scheme like this.

• Slice 0 - 9 -> application slices, e.g. Z80Asm, Aztecc, WS4, Games, HiTec, ...
• Slice 10 - 14 -> operating slices, e.g. CPM2.2, ZSDOS, NZCOM, CPM3, ZPM3

And since I now have all drive letters assigned And I have now moved to the following scheme

• Slice 0 - 19 -> application slices
• Slice 20 - 26 -> operating slices, added Z3PLUS, and QPM

So regardless of which OS I boot from the drive letters are always mapped to the same slices 0->D: thru to 12->P: and the boot frive is always A: I have been strategic about the order so drive letters can have symbolic meaning (since letters wont change)

• G: -> Games
• H: -> HiTech
• M: -> Mark, a sort of home directory, where I place shared general purpose tools. M0: is in search PATH

As for your other points, yes need to ensure a seem-less experience for new and existing users. Ideally this could be easily configured, but Don't see an easy way to configure this. NVRam ?

Mark

PS. I did think of another advantage of my proposed approach (compared to using ASSIGN command) if you boot a media card in a different device then any scripted ASSIGN commands may be incorrect. Currently ASSIGN works to explicit devices

ASSIGN C:=IDE0:1 (assign C: to IDE unit0, slice 1)

This could be overcome with a new ASSIGN command option, and would be a reasonable improvement in its own right

ASSIGN C:=*:1 (assign C: to booted disk unit, slice 1)

[kiwisincebirth]

@wwarthen

I had another idea after investigating CBIOS (havent investigated boot.z80). CBIOS as well as doing initial drive assignment also sets up the SUBMIT PROFILE command, which got me to thinking. What if we were to :

(1) remove the extended drive assignment from CBIOS, it just does the necessary basics, ie. boot drive floppy, but NOT any extended 8 drive HD assignment

(2) the extended logic for HDD assignment is moved into ASSIGN.com, but is parameter driven, e.g ASSIGN /hd=all something similar would do the extended HD assignment as it does today.

(2a) ASSIGN.com could also have other algorithms, i.e. the one I defined in first post e.g. ASSIGN /hd=boot - meaning just assign HD's from boot drive. the /hd= option would only every be expected to called once after boot, would have to define what happens if run a second time, would it replace assignments, or just abort.

(3) For existing user's (which have defined a profile.sub) they would just need to add an ASSIGN /hd=xxx command to the beginning of there PROFILE.SUB file, I don't see this as an issue since they probably know what they are doing, AND quite possibly have already added ASSIGN commands to PROFILE.SUB, so may require no change at all.

(4) For newer users (which haven't created PROFILE.SUB), i noticed cbios.asm detects existence of profile.sub/submit.com file before setting up the SUBMIT PROFILE command; thus if NOT found cbios could issue a ASSIGN /hd=xxx in it place

In summary : I guess the point is

• we are simplifying what the system CBIOS auto assigns to a bare minimum, hopefully no future changes here
• we are moving drive assignment into user hands via additional command line options, and the profile.sub mechanism.
• we are providing future extendability since ASSIGN.com can be enhanced with new assignment algorithms
• we have opportunity to improve how assign.com is invoked (additional options), the commands i mentioned are just an example
• we have some backwards capability for unsophisticated / new users

Mark.

[wwarthen]

Hi @kiwisincebirth,

These are some interesting ideas. Currently, power is out at my house and I am operating on cell phone (painful). May need a day or two to respond.

Thanks, Wayne

[wwarthen]

Hi @kiwisincebirth,

Had a little time to think about this while waiting for my power to be restored.

I generally like the concept of simplifying the CBIOS drive mapping to a minimum and moving more of the work into ASSIGN. I agree that this positions CBIOS for a long-term solution. ASSIGN can be enhanced over time without impacting the OS code at all.

(1) remove the extended drive assignment from CBIOS, it just does the necessary basics, ie. boot drive floppy, but NOT any extended 8 drive HD assignment

To clarify, I think this would just mean assign one CP/M drive to each disk device. For a hard disk, it would map the first slice unless the device was used to boot in which case it would map the selected slice.

(2) the extended logic for HDD assignment is moved into ASSIGN.com, but is parameter driven, e.g ASSIGN /hd=all something similar would do the extended HD assignment as it does today.

Sounds good.

(2a) ASSIGN.com could also have other algorithms, i.e. the one I defined in first post e.g. ASSIGN /hd=boot - meaning just assign HD's from boot drive. the /hd= option would only every be expected to called once after boot, would have to define what happens if run a second time, would it replace assignments, or just abort.

Right. Generally easy to extend ASSIGN.COM (compared to CBIOS). I am fine with ASSIGN just replacing assignments if run a second time.

(3) For existing user's (which have defined a profile.sub) they would just need to add an ASSIGN /hd=xxx command to the beginning of there PROFILE.SUB file, I don't see this as an issue since they probably know what they are doing, AND quite possibly have already added ASSIGN commands to PROFILE.SUB, so may require no change at all.

Right.

(4) For newer users (which haven't created PROFILE.SUB), i noticed cbios.asm detects existence of profile.sub/submit.com file before setting up the SUBMIT PROFILE command; thus if NOT found cbios could issue a ASSIGN /hd=xxx in it place

If PROFILE.SUB is not run for any reason, the user would still get the basic 1 device / 1 drive mapping which may not be a big problem. I'm not sure we need to worry about a failsafe like this. It would only happen if the user messed up the disk image as distributed.

In summary : I guess the point is

• we are simplifying what the system CBIOS auto assigns to a bare minimum, hopefully no future changes here
• we are moving drive assignment into user hands via additional command line options, and the profile.sub mechanism.
• we are providing future extendability since ASSIGN.com can be enhanced with new assignment algorithms
• we have opportunity to improve how assign.com is invoked (additional options), the commands i mentioned are just an example
• we have some backwards capability for unsophisticated / new users

Couple of final thoughts:

• Need to make sure that booting an OS from ROM is well defined. Might be fine to just fall back to the 1 device / 1 drive assignment. Althernatively, a static PROFILE.SUB could be put on the ROM disk images.
• Once we think we have a complete solution, need to solicit opinions from the user community.
• I am overdue to generate a new stable release of RomWBW (v3.5). Since quite a few people have already started using the pre-release v3.5, I am inclined to move this change to v3.6.
• If we make a change to the combo disk layout, it would be best to do it in conjunction with this change (v3.6).

Thanks, Wayne

[kiwisincebirth]

To clarify, I think this would just mean assign one CP/M drive to each disk device. For a hard disk, it would map the first slice unless the device was used to boot in which case it would map the selected slice.

I was thinking just assigning in CBIOS the boot drive (A:) as it is obviously required and any Non-High Capacity media (including floppy disks). this my examples from OP, CBIOS would assign the following. (and nothing else)

11:02 A0:SYSTEM>assign

   A:=IDE0:25
   B:=MD0:0
   C:=MD1:0

assigning first slice of HDD's would result these additional assignments

   D:=IDE0:0
   E:=IDE1:0
   F:=SD0:0

which don't align to either to Original (current) or my newer assignment strategy, D,E,F assignments are already unsuitable. Both strategies would would probably require, D:, E: and F: to latter be remapped (in assign.com).

I am fine with ASSIGN just replacing assignments if run a second time.

This does add some complexity, since have to iterate and work out from what point the replacement should start. Effectively easiest way would be to replace everything starting at D: upwards based on the strategy defined in the assign command. Which in practice means replacements starts at the first high capacity drive (excluding A: of course). Can it just be this simple.

Question: I am not sure about disk Unit ordering. Where do floppy disks appear in the list of Device Disk Units, does this create a problem if follow the above

The point is if CBIOS doesn't assign HDD's then assign doesn't need to deal with replacement, unless a simple rule (above) can be applied.

[wwarthen]

OK, yes, I agree that mapping a slice from all of the available hard disk devices may not be useful. My reason for continuing to consider it are:

• When novice users do not see a drive letter mapped to a device, they tend to assume the device is broken/malfunctioning. I suspect this is because many are used to the MS-DOS way of things.
• Many users use their second (or more) hard disk devices for their data (not the combo image). In this case, mapping the additional device(s) to drive letters may be useful/expected.

I accept that both of the above are not terribly good reasons for mapping CP/M drive letters to non-boot hard disk devices. Additionally, intelligent use of ASSIGN certainly mitigates things. The biggest issue here is simply that we are considering changing a very visible behavior of RomWBW. I suppose this could be mitigated by making the combo disk boot slices run ASSIGN in a way that generally recreates the current behavior.

I am fine with ASSIGN just replacing assignments if run a second time.

This does add some complexity, since have to iterate and work out from what point the replacement should start. Effectively easiest way would be to replace everything starting at D: upwards based on the strategy defined in the assign command. Which in practice means replacements starts at the first high capacity drive (excluding A: of course). Can it just be this simple.

My thought was that the auto mapping algorithms would leave A: alone, toss out all other mappings, then map everything according to the selected algorithm just like at boot. This would mean including the ROM/RAM and removable media devices such as floppy drives.

Question: I am not sure about disk Unit ordering. Where do floppy disks appear in the list of Device Disk Units, does this create a problem if follow the above

The inherent order of all disk devices is baked into the HBIOS. As the HBIOS iterates through each available driver, if a device is responsive, it is added to the device list. The order of the driver iteration is generally: 1) RAM/ROM disks, 2) Floppy Drives, 3) Hard Disk Drives. Changing the order of the driver iterations would require reordering the device initialization table. Not hard, but still a custom ROM build.

Thanks, Wayne

[kiwisincebirth]

My thought was that the auto mapping algorithms would leave A: alone, toss out all other mappings, then map everything according to the selected algorithm just like at boot. This would mean including the ROM/RAM and removable media devices such as floppy drives.

I can live with this, and can see some advantages, just different to my initial thoughts 👍 In summary CBIOS will just map a single Slice regardless of the media type, following the existing conventions of, removable media, and boot drive with no duplication.

It also means since I am free to replace drives other than A:, I can work on Assign.COM in isolation.

Need to make sure that booting an OS from ROM is well defined. Might be fine to just fall back to the 1 device / 1 drive assignment. Althernatively, a static PROFILE.SUB could be put on the ROM disk images

I have noticed when you boot an os from ROM (not disk) it seems to only assign A: and B:. What is the mechanism for this. Looking in CBIOS.asm I dont see how this happens, what am i missing ?

[wwarthen]

HI @kiwisincebirth,

My thought was that the auto mapping algorithms would leave A: alone, toss out all other mappings, then map everything according to the selected algorithm just like at boot. This would mean including the ROM/RAM and removable media devices such as floppy drives.

I can live with this, and can see some advantages, just different to my initial thoughts 👍 In summary CBIOS will just map a single Slice regardless of the media type, following the existing conventions of, removable media, and boot drive with no duplication.

Not exactly. I was specifically addressing this previous comment:

This does add some complexity, since have to iterate and work out from what point the replacement should start. Effectively easiest way >would be to replace everything starting at D: upwards based on the strategy defined in the assign command. Which in practice means >replacements starts at the first high capacity drive (excluding A: of course).

I was trying to say that I don't think you need to start the replacement with D: when using ASSIGN. You could start the replacement assignments with B: and include the rom/ram/floppy drives in the replacements. Looking at your proposed ASSIGN enhancements, I don't think it is even necessary to skip A:. You can just reassign from scratch. ASSIGN already has a check to make sure that there is an A: drive after the reassignments or it aborts.

Regarding the CBIOS default assignments, I am not ready to pare it down to assigning only the boot drive. The CBIOS assignments are a failsafe and I think they need to include minimally rom/ram/floppy/boot slice. Any change to CBIOS mapping at all is still a sticking point for me simply due to user impact/support. If ASSIGN is enhanced as you propose, does it really matter what CBIOS does?

It also means since I am free to replace drives other than A:, I can work on Assign.COM in isolation.

Yes! And I very much like the idea of starting with enhancing ASSIGN. Such enhancements are not impactful to existing users and we could introduce the enhanced ASSIGN to users before changing CBIOS. This would allow some uptake of these changes prior to simplifying CBIOS.

Need to make sure that booting an OS from ROM is well defined. Might be fine to just fall back to the 1 device / 1 drive assignment. Althernatively, a static PROFILE.SUB could be put on the ROM disk images

Right. Booting an OS from ROM is kind of a special case. It is really only an issue if/when the CBIOS mapping is changed.

I have noticed when you boot an os from ROM (not disk) it seems to only assign A: and B:. What is the mechanism for this. Looking in CBIOS.asm I dont see how this happens, what am i missing ?

Hmmm... Booting an OS from ROM should go through the normal drive assignment and all available disk devices should be mapped just like a disk slice boot. I just checked, and that is the behavior I am seeing in the latest code. Have I misunderstood your question?

Thanks, Wayne

[kiwisincebirth]

Hmmm... Booting an OS from ROM should go through the normal drive assignment and all available disk devices should be mapped just like a disk slice boot. I just checked, and that is the behavior I am seeing in the latest code. Have I misunderstood your question?

No, it probably just confusion at my end since I have been changing cbios, and flashing my rom.

[kiwisincebirth]

an update on assign.com - I am trying to keep it flexible.

ASSIGN D:[=[{D:|<device>[<unitnum>]:[<slicenum>]}]][,...]
     ex   ASSIGN /B=X[...X]	(assign devices starting at B:)

For the /B option the following options are valid 
--- will assign a small number of devices, place at beginning of list
        rAm - "A" - Ram drive (0-1)
        rOm - "O" - Rom drive (0-1)
     Floppy - "F" - All floppy devices  (0,1,2,3)
        Gap - "X" - An empty un-assignment (1)
--- remaining fill mostly to end, choose only 1 of the following:
boot Slices - "S" - Slices from boot hard drive only (0-N)
 Hard disks - "H" - Slices dristributed from all hard drives (0-N)

Examples

ASSIGN /B=AOFH -> algorithm as is today in CBIOS
ASSIGN /B=AOFS -> newer algorithm with only slices from boot HDD
ASSIGN /B=FOAH -> ordering of drives Floppy/Rom/Ram/HDD 
ASSIGN /B=XXS   -> only include boot HDD slices, Ram,Rom,Floppy are omitted
		  HDD's start at D: ; B: and C are unmapped

a real example

A0>assign /B=XXS

   B:=
   C:=
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE0:2
   G:=IDE0:3
   H:=IDE0:4
   I:=IDE0:5
   J:=IDE0:6
   K:=IDE0:7
   L:=IDE0:8
   M:=IDE0:9
   N:=IDE0:10
   O:=IDE0:11
   P:=IDE0:12

basically in above it just process each letting in the /B option one at a time assigning starting at B:.

One limitation is once you assign HDD's you cant really place anything after it, because it is likely to consume all remaining letters ie. assign /B=SA is inferring to map all slices then map the P: drive as RAM drive. While possible to do this, the way I have written it makes it harder since each command option letter is processed independently, and 'S' wouldn't know how many letters the 'A' option was likely to assign. potentially assign /B=S(-1)A where -1 means leave one drive letter remaining when adding HDD, this is more complex, and could be easily over come by a second assign p:=MD0 to map the drive

[wwarthen]

Hi @kiwisincebirth,

I like where you are going with this.

an update on assign.com - I am trying to keep it flexible.

ASSIGN D:[=[{D:|<device>[<unitnum>]:[<slicenum>]}]][,...]
     ex   ASSIGN /B=X[...X]	(assign devices starting at B:)

For the /B option the following options are valid 
--- will assign a small number of devices, place at beginning of list
        rAm - "A" - Ram drive (0-1)
        rOm - "O" - Rom drive (0-1)
     Floppy - "F" - All floppy devices  (0,1,2,3)
        Gap - "X" - An empty un-assignment (1)
--- remaining fill mostly to end, choose only 1 of the following:
boot Slices - "S" - Slices from boot hard drive only (0-N)
 Hard disks - "H" - Slices dristributed from all hard drives (0-N)

Examples

ASSIGN /B=AOFH -> algorithm as is today in CBIOS
ASSIGN /B=AOFS -> newer algorithm with only slices from boot HDD
ASSIGN /B=FOAH -> ordering of drives Floppy/Rom/Ram/HDD 
ASSIGN /B=XXS   -> only include boot HDD slices, Ram,Rom,Floppy are omitted
		  HDD's start at D: ; B: and C are unmapped

a real example

A0>assign /B=XXS

   B:=
   C:=
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE0:2
   G:=IDE0:3
   H:=IDE0:4
   I:=IDE0:5
   J:=IDE0:6
   K:=IDE0:7
   L:=IDE0:8
   M:=IDE0:9
   N:=IDE0:10
   O:=IDE0:11
   P:=IDE0:12

basically in above it just process each letting in the /B option one at a time assigning starting at B:.

There are cases where users actually do want to reassign A:. Would a command line like this be supported:

ASSIGN A:=IDE0:20 /B=S

Also, I wonder if there should be an auto-assign letter similar to X, but it preserves the drive mapping at that location. Possibly P for preserve.

One limitation is once you assign HDD's you cant really place anything after it, because it is likely to consume all remaining letters ie. assign /B=SA is inferring to map all slices then map the P: drive as RAM drive. While possible to do this, the way I have written it makes it harder since each command option letter is processed independently, and 'S' wouldn't know how many letters the 'A' option was likely to assign. potentially assign /B=S(-1)A where -1 means leave one drive letter remaining when adding HDD, this is more complex, and could be easily over come by a second assign p:=MD0 to map the drive

It would make more sense to me to specify the number of drive letters to assign as opposed to the number to reserve. For example ASSIGN /B=S5A would assign 5 sequential slices followed by the RAM drive.

The other limitation I see is that it is not possible to specify a starting slice when assigning multiple slices sequentially. Since (normally) the first 5 slices of a disk will be boot disk images, it is typically not helpful to map those. Maybe there is a way to include that in the command line.

Thanks, Wayne

[kiwisincebirth]

Also, I wonder if there should be an auto-assign letter similar to X, but it preserves the drive mapping at that location. Possibly P for preserve.

Yes good idea.

[kiwisincebirth]

It would make more sense to me to specify the number of drive letters to assign as opposed to the number to reserve. For example ASSIGN /B=S5A would assign 5 sequential slices followed by the RAM drive.

The other limitation I see is that it is not possible to specify a starting slice when assigning multiple slices sequentially. Since (normally) the first 5 slices of a disk will be boot disk images, it is typically not helpful to map those. Maybe there is a way to include that in the command line.

I agree in principle with you comments. However would require quite a bit more work to define this. Need to get the basics working first.

[wwarthen]

It would make more sense to me to specify the number of drive letters to assign as opposed to the number to reserve. For example ASSIGN /B=S5A would assign 5 sequential slices followed by the RAM drive.

The other limitation I see is that it is not possible to specify a starting slice when assigning multiple slices sequentially. Since (normally) the first 5 slices of a disk will be boot disk images, it is typically not helpful to map those. Maybe there is a way to include that in the command line.

I agree in principle with you comments. However would require quite a bit more work to define this. Need to get the basics working first.

The whole point of enhancing ASSIGN is that improvements to it can be incremental. There is no need to address my suggestions -- these are just ideas to consider.

Thanks, Wayne

[kiwisincebirth]

So these are the options I have got working this far

--- will assign a small number of devices, place at beginning of list
        rAm - "A" - Ram drive (0-1)
        rOm - "O" - Rom drive (0-1)
     Floppy - "F" - All floppy devices, even without media (0,1,2,...)
       Boot - "B" - Assign the boot device, typically first. (1)
   Preserve - "P" - Preserve and skip the next drive (1)
    Exclude - "X" - Unassign / Exclude the next drive (1)
--- remaining fill mostly to end, generally choose only 1 of the following:
Boot Slices - "S" - Assign slices from boot hard drive only (0-P)
 Hard disks - "H" - Slices distributed from all hard drives (legacy) (0-N) --->>> From CBIOS
Improved HD - "I" - Same as H but will use as many drives as possible (0-N)  --->>> Improved
Exclude ALL - "Z" - Unassign all remaining drives (0-P)

examples

23:30 A2>a16 /B=BAOH

   A:=IDE0:24
   B:=MD0:0
   C:=MD1:0
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE1:0
   G:=IDE1:1
   H:=SD0:0
   I:=SD0:1

23:30 A2>assign /B=BAOI

   A:=IDE0:24
   B:=MD0:0
   C:=MD1:0
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE0:2
   G:=IDE0:3
   H:=IDE1:0
   I:=IDE1:1
   J:=IDE1:2
   K:=IDE1:3
   L:=SD0:0
   M:=SD0:1
   N:=SD0:2
   O:=SD0:3

23:31 A2>assign /B=BS

   A:=IDE0:24
   B:=IDE0:0
   C:=IDE0:1
   D:=IDE0:2
   E:=IDE0:3
   F:=IDE0:4
   G:=IDE0:5
   H:=IDE0:6
   I:=IDE0:7
   J:=IDE0:8
   K:=IDE0:9
   L:=IDE0:10
   M:=IDE0:11
   N:=IDE0:12
   O:=IDE0:13
   P:=IDE0:14

23:32 A2>assign /B=BXXHZ

   A:=IDE0:24
   B:=
   C:=
   D:=IDE0:0
   E:=IDE0:1
   F:=IDE1:0
   G:=IDE1:1
   H:=SD0:0
   I:=SD0:1
   J:=
   K:=
   L:=
   M:=
   N:=
   O:=
   P:=

[wwarthen]

Looks like excellent progress. Congrats.

-Wayne

[kiwisincebirth]

I have provided a PR, which should be safe to merge, even if not perfect it doesn't impact existing users, and the existing code has not been altered (there was one code cleanup).

• It would be good to get a list (specific example) of common things that it would be good for this to utility to handle, not already handled
• I am aware of the need parameters e.g. starting slice to assign, number of slices to assign, etc, However i was a bit hindered by existing code (and command) structure, and was hesitant to preform a major restructure at this point. once you review you might understand, also wanting to keep it simple.

Also

• There is an issue (documented in code) around ROM drive allocation. my preference is to make minor change to the defined device attributes. However that is a conversation in itself
• Documentation needs to be updated, after it settles down

for testing here are the options:
--- will assign a small number of devices, place at beginning of list
        rAm - "A" - Ram drive (0-1)
        rOm - "O" - Rom drive (0-1)
     Floppy - "F" - All floppy devices, even without media (0,1,2,...)
       Boot - "B" - Assign the boot device, typically first. (1)
   Preserve - "P" - Preserve and skip the next drive (1)
    Exclude - "X" - Unassign / Exclude the next drive (1)
--- remaining fill mostly to end, generally choose only 1 of the following:
Boot Slices - "S" - Assign slices from boot hard drive only (0-P)
  Hard Disk - "H" - Assign slices evenly from all hard drives (0-N)
  Legacy HD - "L" - Up to 8 slices assigned from all hard drives (0-7)
Exclude ALL - "Z" - Un-assign all remaining drives (0-P)

[wwarthen]

I have provided a PR, which should be safe to merge, even if not perfect it doesn't impact existing users, and the existing code has not been altered (there was one code cleanup).

Thanks Mark! I will merge shortly.

• It would be good to get a list (specific example) of common things that it would be good for this to utility to handle, not already handled

Not entirely sure how to approach this. I could post a question in the RC2014 group, but we are likely to get a very wide range of desired fucntionality based on personal preferences. I'm not entirely sure we want to open that can of worms...

• I am aware of the need parameters e.g. starting slice to assign, number of slices to assign, etc, However i was a bit hindered by existing code (and command) structure, and was hesitant to preform a major restructure at this point. once you review you might understand, also wanting to keep it simple.

Yes, the original code had a very specific command line syntax. It was not designed for more sophisticated options. I like the way you handled this for now.

Also

• There is an issue (documented in code) around ROM drive allocation. my preference is to make minor change to the defined device attributes. However that is a conversation in itself

The device attributes are pretty much just used internally. Happy to consider a change. The worst aspect of such changes is keeping HBIOS in sync with OSes and applications.

• Documentation needs to be updated, after it settles down

for testing here are the options:
--- will assign a small number of devices, place at beginning of list
        rAm - "A" - Ram drive (0-1)
        rOm - "O" - Rom drive (0-1)
     Floppy - "F" - All floppy devices, even without media (0,1,2,...)
       Boot - "B" - Assign the boot device, typically first. (1)
   Preserve - "P" - Preserve and skip the next drive (1)
    Exclude - "X" - Unassign / Exclude the next drive (1)
--- remaining fill mostly to end, generally choose only 1 of the following:
Boot Slices - "S" - Assign slices from boot hard drive only (0-P)
  Hard Disk - "H" - Assign slices evenly from all hard drives (0-N)
  Legacy HD - "L" - Up to 8 slices assigned from all hard drives (0-7)
Exclude ALL - "Z" - Un-assign all remaining drives (0-P)

OK.

Thanks, Wayne

[kiwisincebirth]

Not entirely sure how to approach this. I could post a question in the RC2014 group, but we are likely to get a very wide range of desired fucntionality based on personal preferences. I'm not entirely sure we want to open that can of worms...

Yes, the original code had a very specific command line syntax. It was not designed for more sophisticated options. I like the way you handled this for now.

IMO - it is much simpler (for a lot of cases) - can always extend it latter but a much bigger job for maybe much less return - in my experience if open it up, you end up speaking to vocal minority

Maybe a case of education also - e.g. Putting combo image slices up high, either using COPYSL or an appropriate DD (Linux) command. But I get that people get set in there ways. I came across a recent Youtube video Lil' Bits whom though hd1k/hd512 was tied to a hardware configuration.

[kiwisincebirth]

The device attributes are pretty much just used internally. Happy to consider a change. The worst aspect of such changes is keeping HBIOS in sync with OSes and applications.

See PR #479 - Which shows the change. Three code impacts that I found (including assign.asm) - I think you can see how the masking is easier since ROM %0100 and FLASH %0110 are closer. turns out RAM %0101 and RAM-FLOP %0111 are also closer if detecting a RAM memory device (including RF) is ever needed.

[wwarthen]

The device attributes are pretty much just used internally. Happy to consider a change. The worst aspect of such changes is keeping HBIOS in sync with OSes and applications.

See PR #479 - Which shows the change. Three code impacts that I found (including assign.asm) - I think you can see how the masking is easier since ROM %0100 and FLASH %0110 are closer. turns out RAM %0101 and RAM-FLOP %0111 are also closer if detecting a RAM memory device (including RF) is ever needed.

This looks good and I intend to merge this shortly. I think there is probably another code adjustment in CP/M 3 needed. I will take a look at that after merging.

Thanks, Wayne

[wwarthen]

This looks good and I intend to merge this shortly. I think there is probably another code adjustment in CP/M 3 needed. I will take a look at that after merging.

Never mind. I forgot that CP/M 3 cannot be started from ROM.

Thanks, Wayne

[kiwisincebirth]

@wwarthen - Added PR #481 for documentation

ONE THING : Not sure but my algorithms don't consider available available RAM, they will just assign all drives (if given the chance). Thus when I assign all drives ZSDOS I get 37 Disk Buffer Bytes Free - not sure if this will be an issue. but while writing doc it stated if you use too many drives it will abort.