SCz180: Creating new CP/M Slices on an SD Card - How?

[David Reese]

Hello, All,

A while back, I partitioned a micro SD card for my SC126.  In the process, four CP/M "slices" were created by the transfer of a disk image from RomWBW to hold files I would need for creating a FAT32 partition to facilitate transfer of files from other systems.  During the partitioning, I used FDISK80, which allows the user to reserve space for up to eight slices.  I've decided that four slices, three of which already contain files, is not going to be enough.

How does one go about creating new CP/M slices once the space for them is reserved?  I don't see where this can be done from FDISK80 (maybe I missed something?).  I'd like to know (before I clean up the slices populated by hd0.img) if there is some other utility I need to use to accomplish this task.

Thanks in Advance,

David

[Steve Cousins]

Hi David,

If I've understood you correctly (which I quite possibly have not) then I think this is what you do:

You have space reserved for 8 slices but can only see the first 4, which RomWBW assigns to drive letters. With the version of RomWBW you probably have you can not add more drive letters but you can assign them to more than just the first 4 slices. You can use the ASSIGN command to set which physical slice is referenced by each of the 4 drive letters. Once you have assigned the slice you can use CLRDIR in the normal way to prepare the slice for use. You will need to use ASSIGN again after a reset or power-up to re-establish the drive letter reference.

Wayne has/is modifying RomWBW so that is will make better use of the available drive letters. Currently for the SCZ180 platform 4 are allocated to the CF card and 4 to the SD card. This relationship is fixed regardless of the presence of the media. In the future, you should get 8 drive letters assigned to one card if the other is not present.

Steve

[David Reese]

On Saturday, February 15, 2020 at 4:49:48 PM UTC-6, Steve Cousins wrote:

Hi David,

If I've understood you correctly (which I quite possibly have not)

Thanks for your reply, Steve.  You have understood exactly what I'm wanting to do.  Since my SC126 is presently operating, here's a little cut/paste:  RetroBrew HBIOS v2.9.2-pre.13

 

then I think this is what you do:

You have space reserved for 8 slices but can only see the first 4, which RomWBW assigns to drive letters. With the version of RomWBW you probably have you can not add more drive letters but you can assign them to more than just the first 4 slices. You can use the ASSIGN command to set which physical slice is referenced by each of the 4 drive letters. Once you have assigned the slice you can use CLRDIR in the normal way to prepare the slice for use. You will need to use ASSIGN again after a reset or power-up to re-establish the drive letter reference.

So, given the present slice map:

   G:=SD0:0
   H:=SD0:1
   I:=SD0:2
   J:=SD0:3

I would need to re-assign G: to SD0:4, H:  to SD0:5, etc., using ASSIGN, then CLRDIR to prepare for initial use.  After data is stored on these slices, I would just need to re-assign them to be able to access them?

If I'm thinking correctly, I can see a SUBMIT job in my future to do the equivalent of bank-switching my slices... at least until I screw up the courage to flash my RomWBW to the latest version when Wayne completes the work you've mentioned below:

 

Wayne has/is modifying RomWBW so that is will make better use of the available drive letters. Currently for the SCZ180 platform 4 are allocated to the CF card and 4 to the SD card. This relationship is fixed regardless of the presence of the media. In the future, you should get 8 drive letters assigned to one card if the other is not present.

Wayne's work with RomWBW is nothing short of incredible.  I can see some thought will need to go into error-trapping in the present work with drive allocation to prevent losing data.  If I might make the observation, since FDISK80 allows for reserving 8 slices on a given disk, maybe we should make eight slices available to SD Card AND CF Card?  That would make maxing out the available data store for this machine rather more straightforward.  (That is, of course, unless there is a hardware constraint.).  Yeah, I know 32 MB of storage is more than any CP/M system I've worked with previously, but why not go for broke if we can.

I will practice eventually with the present version of it just to learn how to do the flashing properly.

I wish I could code Z80 assembly language to the degree required to be of some help, but not yet. 

Thanks,

David

[Wayne Warthen]

Some comments below...

Thanks, Wayne

 

You have space reserved for 8 slices but can only see the first 4, which RomWBW assigns to drive letters. With the version of RomWBW you probably have you can not add more drive letters but you can assign them to more than just the first 4 slices. You can use the ASSIGN command to set which physical slice is referenced by each of the 4 drive letters. Once you have assigned the slice you can use CLRDIR in the normal way to prepare the slice for use. You will need to use ASSIGN again after a reset or power-up to re-establish the drive letter reference.

So, given the present slice map:

   G:=SD0:0
   H:=SD0:1
   I:=SD0:2
   J:=SD0:3

I would need to re-assign G: to SD0:4, H:  to SD0:5, etc., using ASSIGN, then CLRDIR to prepare for initial use.  After data is stored on these slices, I would just need to re-assign them to be able to access them?

Assuming your SC126 has C:-F: mapped to a non-existent IDE drive, then I would suggest that you ASSIGN:

C:=SD0:0

D:=SD0:1

E:=SD0:2

F:=SD0:3

G:=SD0:4

H:=SD0:5

I:=SD0:6

J:=SD0:7

If I'm thinking correctly, I can see a SUBMIT job in my future to do the equivalent of bank-switching my slices... at least until I screw up the courage to flash my RomWBW to the latest version when Wayne completes the work you've mentioned below:

 

Wayne has/is modifying RomWBW so that is will make better use of the available drive letters. Currently for the SCZ180 platform 4 are allocated to the CF card and 4 to the SD card. This relationship is fixed regardless of the presence of the media. In the future, you should get 8 drive letters assigned to one card if the other is not present.

Yes, the latest RomWBW code does make things easier.  It will automatically assign 8 drives to one media if that is the only media inserted in the system.  I have not published a full pre-release with this code yet, so you would need to grab the latest source from the GitHub master branch and do your own build.

 

Wayne's work with RomWBW is nothing short of incredible.  I can see some thought will need to go into error-trapping in the present work with drive allocation to prevent losing data.  If I might make the observation, since FDISK80 allows for reserving 8 slices on a given disk, maybe we should make eight slices available to SD Card AND CF Card?  That would make maxing out the available data store for this machine rather more straightforward.  (That is, of course, unless there is a hardware constraint.).  Yeah, I know 32 MB of storage is more than any CP/M system I've worked with previously, but why not go for broke if we can.

There is a maximum of 16 drive letters on CP/M (A: - P:).  Two drive letters must be used for RAM disk and ROM disk, leaving 14 drive letters.  So, it would not be possible to assign 8 drive letters to each media (that would be 18 drive letters).  The assignment of drive letters at boot up is a "best effort" thing where I try to assign a reasonable number of drive letters based on the disk interfaces in the system.  It is far from perfect, but it probably strikes a reasonable balance between optimum allocation and code complexity.  It was always intended that advanced users would use a PROFILE.SUB startup file that contains ASSIGN commands that setup a custom drive letter layout.

As an aside, note that RomWBW does support up to 255 slices on one media.  That would represent 2GB of usable storage.  Sadly, CP/M 2.2 is limited to 8MB filesystems, thus the need for slicing the space up and juggling drive letters.  Yes, I know that later CP/M variants support larger file systems, but I wish to maintain compatibility across all the variants supported.