hd1k_combo.img is too small in size for large media, I: and J: drives are not initialised

[skullandbones]

I used a 16GB micro SD card in a SD card adapter and dd'ed the hd1k_combo.img to the SD card.

Using Linux on my RPi4:

sudo dd if=hd1k_combo.img of=/dev/sda bs=8M
6+1 records in
6+1 records out
51380224 bytes (51 MB, 49 MiB) copied, 1.28754 s, 39.9 MB/s

By default drives C: through to J: are assigned to the first 8 slices (0 to 7) of the SD card.

However when trying to access drive I:

B>DIR I:
I: [K : - c : m ap : r aw
I: l ine : n ak : 3 . : [ %d]
I: f unc :  vi : ///  :  
I: a  : t  : uste pM
B>inicom2.7.1
INICOM2.7.1?

The minicom terminal program gets confused by the corrupted strings, hence "inicom2.7.1" appearing.

Similarly, for the J: drive:

B>DIR J:
J:|(  :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
  :  :   : >
J:   :   :   :  
J:   : P 5 :  5 : 
J:   :   :   :  
J: P 9 :  | :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J:   :   :   :  
J: 

The observation is due to the SD card being previously used such as being EXT4 formatted and not a pre-formatted SD card from an on-line store.

This occurs because hd1k_combo.img does not contain pre-formatted blank slices for drives I: and J:. Meaning that dd is not able to write to the locations occupied by the 6: and 7: slices that map to drives I: and J:

I am aware that some people use 64MB cards so drive J: is technically off the end of the card. I am assuming 1MiB (partition table) + 8 * 8MiB slices = 65MiB which does not fit on a 64MB card.

So for large cards such as 16GB I recommend that hd1k_combo.img is extended to include the pre-formatted blank slices for drives I: and J: because that would allow no access errors for the default I: and J: assignments. Meaning that I: and J: would not need to be manually formatted using CP/M and would work out of the box.

I think it would also be helpful to have a h1k_blank.img so that custom combo images can be made with blank slices in between other slices that have files.

Thanks, Dean

[wwarthen]

Hi @skullandbones,

I definitely see what you are getting at. However, it would be painful to extend the number of slices in the combo images at this point.

It is a common practice for users to put their personal data in slices after the end of the combo slices. By doing it this way, they can overlay the combo image as often as they want (to update their system) without destroying the slices they place after the end of the combo image. If I extend the combo image with empty slices, then their personal data will be destroyed when they do their next update of the combo image.

It is also very common for users to append other slices to the combo image (ex. hitechc.img). If the combo image itself was expanded to 8 slices, then the appended image would not show up until the user ASSIGNed it to a drive.

I get that there are arguments on either side of this, but I think I need to give preference to not making this type of change without a very strong reason. Such changes tend to cause existing users a lot of grief.

With all this said, I do think I could add some clarification to the Hard Disk Images section of the RomWBW User Guide.

I'll leave this issue open for the moment if you have any further thoughts on this. It will also be a reminder to me to update the User Guide.

Thanks,

Wayne

[skullandbones]

@wwarthen some observations:

All the following discussion refers to hd1k_combo.img

I am using my Raspberry Pi4 as the Linux host.

Partition table

fdisk -l hd1k_combo.img
Disk hd1k_combo.img: 49 MiB, 51380224 bytes, 100352 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9921862d

Device          Boot   Start     End Sectors  Size Id Type
hd1k_combo.img1         2048 1050623 1048576  512M 2e unknown
hd1k_combo.img2      1050624 1837055  786432  384M  6 FAT16

The partition table does the following:

1. Skips over the first 1MiB to reserve space for the partition table + slice metadata and comes from hd1k_prefix.dat.
2. Partition 1 reserves 512MiB for 64 x 8MiB slices
3. Partition 2 reserves 384MiB for a FAT16 file system

This is OK so far.

Media size

Adding up the reserved space = 1MiB + 512MiB + 384MiB = 897MiB

Therefore, the minimum media size is 1GB and agrees with your section "4.4 Hard disks" in your User Guide.

However, if people don't care about the FAT partition then the minimum media size is 128MB to accommodate 8 slices which needs 1 + 8*8 = 65MiB.

Some people use 64MB media which is unsuitable for hd1k_combo.img because slice 7 aka J: drive goes off the end of the media because the minimum media size for 8 slices is exceeded. Meaning that hd1k_combo.img is OK to be flashed to 64MB media because the size of hd1k_combo.img is 49MiB so it fits. But because slice 6 and 7 are not written to by hd1k_combo.img then it could give a novice user a bad experience as slice 7 will not work as expected.

So I think the User Guide could be a bit more explicit in specifying the minimum media size for hd1k_combo.img.

novice users first image

After I built my RC2014, I was in a hurry to find an image for the CF card to try to test my system. I found hd1k_combo.img and dd'ed it. The system booted-up, and I quickly did dir for each drive and found that I: and J: gave corrupted listings. From my experience, I knew straight away that the media for slices 6 and 7 had not been initialised.

But from a novice user's point of view, it might not be so obvious that I: and J: drives have to be manually initialised using CLRDIR.

Updating media using the latest hd1k_combo.img

I agree that it is useful to have I: and J: drives for user data and to preserve those drives when doing an update.

However, if a hd1k_combo.img is written to the media then the partition table gets reset back to the "factory settings" and potentially could make the FAT partition inaccessible due to mismatching with the actual FAT filesystem being used by the user. This depends on how fussy the OS is, the start sector of partition 2 will remain the same but the FAT type and end sector may mismatch with the FAT partition contents.

Updating media using dd

I think hd1k_combo.img is useful for initialising media.

dd can be used to read and write specific slices by using the following command formula

To read the first slice
sudo dd if=/dev/sdb of=1st_slice.img bs=1M skip=1 count=8

To read the second slice
sudo dd if=/dev/sdb of=2nd_slice.img bs=1M skip=9 count=8

In the general case for slice n
sudo dd if=/dev/sdb of=nth_slice.img bs=1M skip=(1+8*n) count=8

To write to the first slice
sudo dd if=1st_slice.img of=/dev/sdb bs=1M seek=1 count=8

To write to the second slice
sudo dd if=2nd_slice.img of=/dev/sdb bs=1M seek=9 count=8

In the general case for slice n
sudo dd if=nth_slice.img of=/dev/sdb bs=1M seek=(1+8*n) count=8

dd can also be used to read and write directly into hd1k_combo.img

Suggested recommendations

I think it would be helpful to have a hd1k_blank.img because this would allow individual slices to be initialised in the media using dd and can be manually added to custom combo images. What do you think ?

I get the idea of not overwriting I: and J: drive aka slices 6 and 7. Using dd these slices can be copied off the media to make a backup.

I think it would be helpful to update the User Guide to highlight the limitations of using hd1k_combo.img. What do you think ?

Thanks, Dean

[wwarthen]

Hi @skullandbones,

Good ideas. My upcoming check-in has an update to the User Guide (see 5.1.2 Hard Disk Images). It also adds a blank hd512 and hd1k disk slice image.

Please let me know what you think.

Thanks,

Wayne

[wwarthen]

RomWBW Development Snapshot v3.3.0-dev.61 includes the changes to address this issue. If there are no further comments, I will close this issue tomorrow.

Thanks,

Wayne

[skullandbones]

@wwarthen I have looked at your update to ReadMe.txt in https://github.com/wwarthen/RomWBW/commit/9072bc6d70be7aa56b997e6d7288107c5bc7cc6f

Some comments:

1. The partition sizes are in binary notation so technically it is more precise to say 512MiB and 384MiB. If decimal notation is used for binary sizes then the reader becomes confused. This is especially important when discussing media sizes which are in decimal notation versus partition sizes which are binary notation. Meaning that 1MB is smaller than 1MiB.

Also there are typos, 512K should be 512MB (or better as 512MiB), and 384K should be 384MB (or better as 384MiB).

1. You said

   Note that the pre-allocated FAT partition must still be formatted using `FDISK32` in order to actually use it (see [FAT Filesystem Preparation]).

   Or alternatively may be formatted to FAT32 on an external computer using tools such as gparted on Linux.

2. You said

   The 512KB area of the combo disk image set aside for slices can contain approximately 64 slices (8MB per slice).

   Could be more precisely written as

   Partition 1 of the combo disk image is 512MiB in size and reserves space for exactly 64 slices (8MiB per slice).

3. You said

   If your actual hard disk is less than 512KB, then this will correspondingly reduce the number of possible slices.

   This is an incorrect statement. Media of size 512MB is too small to fully hold the partition table + partition #1. The minimum media size is 1GB.

4. You said

   If your hard disk is smaller than 64MB, then you will find that some of the higher drive letters do not work because they exist "off the end" of the hard disk.

   This is also an incorrect statement. The minimum media size is 128MB.

It might be that 64MB media has some extra sectors at the end as I bet it might not be precisely 64MB (decimal) in size. From a user point of view, 128MB would be safe to use as a minimum for having 8 working slices 0 to 7.

1. You said

   If the combo disk image is being used, only the first 6 drive letters (A: - H:) will have any content because the combo disk image only provides 6 slices.

   This statement is confusing, probably has some typos.

My suggestion is

If the combo disk image is being used, only the first 6 drive letters of the hard disk (C: to H:) will have any content because the combo disk image only provides 6 slices.

1. You said

   If you want to use any slices beyond the first 6, you must initialize them using `CLRDIR` first.

   Might be better written

   If you want to use any slices beyond the first 6 on the hard disk,then you must initialize them using `CLRDIR` first.

I hope that helps ?

Dean

[skullandbones]

@wwarthen with my RC2014 kit, there was a preformatted 64MB CF card.

Here is my analysis using Linux.

dmesg shows the CF card size

[sda] 125440 512-byte logical blocks: (64.2 MB/61.3 MiB)

fdisk shows

sudo fdisk -l /dev/sda
Disk /dev/sda: 61.3 MiB, 64225280 bytes, 125440 sectors
Disk model: STORAGE DEVICE  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

I think this is formatted using the 512 legacy scheme.

This is bad news because 8 slices needs 8 8 1024 * 1024 bytes which is 67,108,864 bytes and is more than 64,225,280 bytes available on the CF card.

That suggests that J: drive is hanging off the end of the CF card.

The other possibility is that slices are actually 8MB in size which is 8 1000 1000 bytes = 8,000,000 bytes.

So I think that you have managed to confuse me or truely, the J: drive will fail as the available size is too small.

Hmm.

Dean

[wwarthen]

Thanks for your comments @skullandbones. Very helpful!

@wwarthen I have looked at your update to ReadMe.txt in 9072bc6

Some comments:

1. The partition sizes are in binary notation so technically it is more precise to say 512MiB and 384MiB. If decimal notation is used for binary sizes then the reader becomes confused. This is especially important when discussing media sizes which are in decimal notation versus partition sizes which are binary notation. Meaning that 1MB is smaller than 1MiB.

I absolutely agree with you. The problem is that if I use MiB, it would be extremely confusing if I didn't use MiB very consistently in all documentation. Even worse, MiB was never used in legacy documentation. I'm worried about making a bad situation worse. ☹️

Also there are typos, 512K should be 512MB (or better as 512MiB), and 384K should be 384MB (or better as 384MiB).

Thanks, fixed in the next check-in.

1. You said

Note that the pre-allocated FAT partition must still be formatted using `FDISK32` in order to actually use it (see [FAT Filesystem Preparation]).

Or alternatively may be formatted to FAT32 on an external computer using tools such as gparted on Linux.

Actually, my reference to FDISK32 was completely wrong. It should have been a reference to the FAT FORMAT command. The actual partition is pre-allocated, so FDISK32 is not needed with the combo image. I have fixed this in the next check-in and added another line about using a modern computer.

1. You said

The 512KB area of the combo disk image set aside for slices can contain approximately 64 slices (8MB per slice).

Could be more precisely written as

Partition 1 of the combo disk image is 512MiB in size and reserves space for exactly 64 slices (8MiB per slice).

Agreed, fixed in the next check-in.

1. You said

If your actual hard disk is less than 512KB, then this will correspondingly reduce the number of possible slices.

This is an incorrect statement. Media of size 512MB is too small to fully hold the partition table + partition #1. The minimum media size is 1GB.

I'm not following you on this one. Let's say you have a 256MB hard disk. You will still be able to use 32 slices on this hard disk. Yes, the partition does not entirely fit on the hard disk, but that causes no functional issues. Am I missing something here?

1. You said

If your hard disk is smaller than 64MB, then you will find that some of the higher drive letters do not work because they exist "off the end" of the hard disk.

This is also an incorrect statement. The minimum media size is 128MB.

It might be that 64MB media has some extra sectors at the end as I bet it might not be precisely 64MB (decimal) in size. From a user point of view, 128MB would be safe to use as a minimum for having 8 working slices 0 to 7.

As above, I'm not understanding your comment. 32MB media would support the use of 4 slices (4 drive letters). I think it is correct to say that the higher drive letters will not work. Help me understand if I have misunderstood.

1. You said

If the combo disk image is being used, only the first 6 drive letters (A: - H:) will have any content because the combo disk image only provides 6 slices.

This statement is confusing, probably has some typos.

My suggestion is

If the combo disk image is being used, only the first 6 drive letters of the hard disk (C: to H:) will have any content because the combo disk image only provides 6 slices.

Absolutely right. Fixed in the next check-in.

1. You said

If you want to use any slices beyond the first 6, you must initialize them using `CLRDIR` first.

Might be better written

If you want to use any slices beyond the first 6 on the hard disk,then you must initialize them using `CLRDIR` first.

Yes, fixed in the next check-in.

I hope that helps ?

Greatly appreciated.

Thanks,

Wayne

[wwarthen]

@wwarthen with my RC2014 kit, there was a preformatted 64MB CF card.

Here is my analysis using Linux.

dmesg shows the CF card size

[sda] 125440 512-byte logical blocks: (64.2 MB/61.3 MiB)

fdisk shows

sudo fdisk -l /dev/sda
Disk /dev/sda: 61.3 MiB, 64225280 bytes, 125440 sectors
Disk model: STORAGE DEVICE  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

I think this is formatted using the 512 legacy scheme.

This is bad news because 8 slices needs 8 8 1024 * 1024 bytes which is 67,108,864 bytes and is more than 64,225,280 bytes available on the CF card.

That suggests that J: drive is hanging off the end of the CF card.

The other possibility is that slices are actually 8MB in size which is 8 1000 1000 bytes = 8,000,000 bytes.

So I think that you have managed to confuse me or truely, the J: drive will fail as the available size is too small.

Hmm.

Dean

I'm afraid you have gotten ahead of me. It is on my todo list to produce a much deeper explanation of the hard disk layout, but simply have not gotten to it yet. If you look at "Hard Disk Anatomy" in the Doc directory, you will see the outdated documentation that covers only the hd512 layout.

Frankly, you are doing a much deeper dive into the disk layout than anyone has ever bothered with before! 🙂 Since you seem to have a good handle on partitions, slices, etc. I will try to provide a brief explanation below that may help you.

First, be clear that there are 2 different layouts available in RomWBW: hd1k and hd512.

For hd512:

Each slice is exactly 8,320KiB. Each slice contains a 128KiB system area plus a 64MiB filesystem. There is no "prefix". Slices are placed on the hard disk starting at the very first sector. The hard disk partition table lives inside the 128KiB system area of the first slice. There is no partition table entry for the RomWBW slices. There is a single partition table entry for the FAT filesystem starting at 520MiB. The RomWBW slices just occupy the unpartitioned space before the start of the FAT partition. To determine the size of the hard disk space needed, you just use 8,320KiB slice_count. This means that for a hard disk to contain 8 slices, it must be 8,320KiB 8 = 66,560KiB. It also means that the maximum number of slices that the 512MiB area of the hard disk before the FAT partition would be 520MiB / 8,320KiB. This works out to be exactly 64 slices.

For hd1k:

Each slice is exactly 8MiB. The 128KiB system area lives inside the 8MiB. The hard disk contains a 1MiB prefix area that encompasses the hard disk partition table. Slices are placed on the hard disk immediately following the 1MiB prefix. The partition table contains 2 entries. The first entry is for RomWBW slices which starts at 1MiB (after the prefix) and is exactly 512MiB in size. The second entry is the FAT partition which starts at 513MiB and is exactly 384MiB in size. To determine the size of the hard disk space needed, you just use 1MiB + (8MiB slice_count). This means that for a hard disk to contain 8 slices, it must be 1MiB + (8 8MiB) = 65MiB. It also means that the maximum number of slices that the 512MiB RomWBW partition area of the hard disk before the FAT partition would be 512MiB / 8MiB. This works out to be exactly 64 slices.

I hope this is understandable. Yes, it does mean that for either hd512 or hd1k, the size of a hard disk required to contain 8 full slices will be a little more than 64MiB. In reality, this does not much matter because there really is no such thing as a true 64MiB hard disk. As you see in your analysis above, your "64MB" hard disk is really 61.3MiB. My point is that, in reality, a 64MB hard disk is not going to allow you to store 8 slices. One more thing that may not be obvious. The choice to pre-allocate 8 slices was not made to optimize the number of slices that fit on a 64MB hard disk. That choice has to do with optimizing the number of drive letters that will safely fit in RAM for CP/M. Note that if you have 1 hard disk, you get 8 drive letters. With 2 hard disks, you will get 4 drive letters allocated per drive. If you have more than 2 hard disks, you will get 2 drive letters assigned per drive.

I suppose, in the end, your specific situation is exactly as you point out. The eighth slice (J: drive) will not be useable on your 61.3MiB hard disk.

Thanks,

Wayne

[skullandbones]

@wwarthen thanks for your explanation. I need to think through the numbers because it can be confusing.

Meanwhile, my concern now is that RC2014 kits are being sold with 64MB CF cards which I think are too small for 8 slices.

On my RC2014 with the 64MB CF card

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      SIO0:       RS-232            115200,8,N,1
Char 1      SIO1:       RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      MD1:        ROM Disk          384KB,LBA
Disk 2      IDE0:       CompactFlash      61MB,LBA
Disk 3      IDE1:       Hard Disk         --

Configuring Drives...

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

J>b:stat 
A: R/W, Space: 248k
B: R/W, Space: 36k
C: R/W, Space: 7296k
D: R/W, Space: 6964k
E: R/W, Space: 6940k
F: R/W, Space: 7296k
G: R/W, Space: 6860k
H: R/W, Space: 7356k
I: R/W, Space: 8168k
J: R/W, Space: 8168k

There are no files on I: and J:.

I think that the k units appear to be decimal.

I am from the Linux embedded world so I know that using MB for binary notation is bad practice as can be seen in the boot-up output

Disk 2      IDE0:       CompactFlash      61MB,LBA

as we know that the 64MB CF card is 61.3 MiB so here the boot-up is showing 61MB in binary notation.

I understand your point of not confusing users by switching to MiB but it makes troubleshooting and diagnostics harder due to the ambiguous units of MB.

Linux tools relating to hard disk partitioning tend to show both MB and MiB values to avoid any confusion. I don't know if it is too late to modify your boot sequence to show both units ?

Perhaps in your documentation you could show both units but that is likely to be more confusing. Maybe have a statement that indicates MB is binary notation unless talking about media sizes which are decimal notation. But I fear that will just propagate the long standing confusion.

Now I am wondering how to demonstrate that the J: drive has insufficient disk behind it. I know nothing about the CP/M filesystem.

Dean

[wwarthen]

Meanwhile, my concern now is that RC2014 kits are being sold with 64MB CF cards which I think are too small for 8 slices.

Your assertion is absolutely correct. However, I am not aware that it is Spencer is claiming that they do. I don't know what can be done about this. The 64MB CF Cards are, in fact, only 61.3MiB. There is no way that 8 slices are going to fit in that space.

The dedicated CP/M that Spencer provides for the non-RomWBW systems actually uses a "last" drive that is intentionally truncated to avoid the last drive hanging over the edge. RomWBW cannot do this because it is fundamental to the slice assignment mechanism that all slices be identical.

J>b:stat A: R/W, Space: 248k B: R/W, Space: 36k C: R/W, Space: 7296k D: R/W, Space: 6964k E: R/W, Space: 6940k F: R/W, Space: 7296k G: R/W, Space: 6860k H: R/W, Space: 7356k I: R/W, Space: 8168k J: R/W, Space: 8168k

There are no files on I: and J:.

I think that the k units appear to be decimal.

I'm pretty sure the k units printed by the STAT command are KiB. They look smaller than the slice size because they are expressing the useable space left on the drive. The useable space is reduced by the directory area.

I am from the Linux embedded world so I know that using MB for binary notation is bad practice as can be seen in the boot-up output

Disk 2      IDE0:       CompactFlash      61MB,LBA

as we know that the 64MB CF card is 61.3 MiB so here the boot-up is showing 61MB in binary notation.

I understand your point of not confusing users by switching to MiB but it makes troubleshooting and diagnostics harder due to the ambiguous units of MB.

Linux tools relating to hard disk partitioning tend to show both MB and MiB values to avoid any confusion. I don't know if it is too late to modify your boot sequence to show both units ?

It is never too late, but it is a very big job. It would be somewhat easier to just replace all occurrences of MB with MiB, but I still worry that it will be out of sync with all of the OS tools which will be using M or MB to mean MiB. To some extent, you need to accept we are dealing with 40 year old systems and the MiB term did not exist at the time. Actually, at that time, many people were using MB for megabyte and Mb for 1 million bytes. Not sure if you were around at this time, but I was! 😀

Perhaps in your documentation you could show both units but that is likely to be more confusing. Maybe have a statement that indicates MB is binary notation unless talking about media sizes which are decimal notation. But I fear that will just propagate the long standing confusion.

You have definitely sensitized me to this issue. I do like the idea of adding something in the documentation to clarify this terminology.

Now I am wondering how to demonstrate that the J: drive has insufficient disk behind it. I know nothing about the CP/M filesystem.

Yeah, that is a little painful. Basically, you would need to copy a ton of files to the drive and try to fill it up. Before you did, you would start to get disk i/o errors.

Ideally, RomWBW would detect that a drive does not fit within the physical hard disk at the time of the drive assignment and simply refuse to assign it. Again, that would be a big job. The code space constraints of these systems is painful.

Thanks,

Wayne

[wwarthen]

Based on this conversation, I took another pass at the User Guide.

I have added a new section, "4.7 Hard Disk Capacity", and revised "5.1.2 Hard Disk Images" with links between them. I hope this is an improvement.

Thanks,

Wayne

[skullandbones]

@wwarthen your update to ReadMe.txt looks good to me.

I only have 1 nitpick you said

The combo disk image layout was designed to fit well on a 1GB hard disk.
The 64 CP/M slices (approximately 512MB) and 384MB FAT filesystem all 
fit well within a 1GB hard disk.

I am not sure why you say approximately 512MB when it is exactly 512MB (512MiB).

Just for fun, I am using a 4GB SD card in a CF card adaptor instead of a real CF card. It seems to work. So logically it is a CF card but really it is an SD card and we still call it a hard disk. Now my head hurts ;-)

Thanks,

Dean

[wwarthen]

Hi @skullandbones,

I am not sure why you say approximately 512MB when it is exactly 512MB (512MiB).

Well... it is exactly 512MB for the hd1k layout. But it is exactly 520MB for the hd512 layout. Originally, I called out the difference, but when re-reading it, it seemed like too much detail for the point I am trying to make in this paragraph. With that said, I am very open to suggested rephrasing.

Just for fun, I am using a 4GB SD card in a CF card adaptor instead of a real CF card. It seems to work. So logically it is a CF card but really it is an SD card and we still call it a hard disk. Now my head hurts ;-)

Yup, the whole concept of "hard disk" on these systems is a bit of a mind bender. 😀

Thank you for the continued suggestions and review.

Thanks,

Wayne

[wwarthen]

Meanwhile, my concern now is that RC2014 kits are being sold with 64MB CF cards which I think are too small for 8 slices.

Your assertion is absolutely correct. However, I am not aware that it is Spencer is claiming that they do. I don't know what can be done about this. The 64MB CF Cards are, in fact, only 61.3MiB. There is no way that 8 slices are going to fit in that space.

The dedicated CP/M that Spencer provides for the non-RomWBW systems actually uses a "last" drive that is intentionally truncated to avoid the last drive hanging over the edge. RomWBW cannot do this because it is fundamental to the slice assignment mechanism that all slices be identical.

I spent my "treadmill" time this morning thinking about the issue that a slice can hang off the end of your physical media. As you pointed out, the 64MB CF Cards normally distributed by Spencer are very susceptible to this since there will be 8 slices assigned to drive letters, but the last drive letter will refer to a slice that is half missing. Very dangerous because nothing stops a user from putting files on the drive and it will work fine... for a while. After the physical drive size threshold is crossed, you will get drive corruption and lost data. Not good.

OK, so I was properly motivated to find a solution. I have just checked in an update that works reasonably well. I can't really prevent someone from assigning an invalid slice to a drive letter. This is because users can swap media. However, I have added a check that prevents any usage of a slice that is not fully contained on the physical media (and fully contained within the partition in the case of hd1k). Any attempt to access such a drive will result in an immediate OS error like "no drive". So, for example, on a CF Card like Spencer distributes, any attempt to access the J: drive will result in the "no drive" error. I suppose this is not super user friendly, but will prevent uses of such a slice.

This new code consumes 48 bytes of an area of memory that is precious, but probably worth the hit. I guess I could make the feature optional via configuration if I get any complaints. I have not yet updated the documentation, but I will do so.

Anyway, the changes are now available in "RomWBW Development Snapshot v3.4.0-dev.2".

Thanks,

Wayne

[wrljet]

Wayne,

I have a question... Why did the version numbering change to v3.4.0-dev?

Bill

[skullandbones]

@wwarthen for Linux users, I worked out a more effective way of preparing the media by using partition 1 and this avoids worrying about messing up the partition table.

Assuming the media is /dev/sda and the media has not previously been used with RomWBW.

Step 1: Write the partition table + slice metadata

sudo dd if=hd1k_prefix.dat.img of=/dev/sda bs=1M

Remove the media and reinsert the media so that the new partition table is used.

Step2: Initialise a lot of slices

cat hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img hd1k_blank.img > hd1k_blanks.img

Write the blank slices to partition 1

sudo dd if=hd1k_blanks.img of=/dev/sda1 bs=1M

Step 3: Write the combo or custom image

I created a mega custom image of all the available disk images

cat hd1k_cpm22.img hd1k_zsdos.img hd1k_nzcom.img hd1k_cpm3.img hd1k_zpm3.img hd1k_ws4.img hd1k_games.img hd1k_z80asm.img hd1k_hitechc.img hd1k_aztecc.img hd1k_bascomp.img hd1k_fortran.img hd1k_tpascal.img hd1k_qpm.img > hd1k_mega.img

Write the mega custom image to partition 1

sudo dd if=hd1k_mega.img of=/dev/sda1 bs=1M

The user slices live beyond the mega custom image so the mega custom image can be used to update the media after the ROM has been updated.

Step 4: Partition 2 can be formatted at FAT32

Using CP/M or a host computer, format partition 2 as FAT32.

Step 5: Setup a custom ASSIGN

I was hoping to create a config file or batch file that would allow easy remapping of drive letters to slices depending on which scenario or profile that I wished to use.

This is the point that I am stuck at.

Perhaps ASSIGN.COM could be extended to read a user-defined config file ? For example, having a config file for Hi-TECH, or a config file for Z80 assemblers. Also I: and J: could be assigned slices past the end of the custom image.

In other words, could a user specify the default ASSIGN settings in slice 0 of the media aka drive C: and this could override the default ASSIGN selection ?

Thanks,

Dean

[wwarthen]

Hi @wrljet,

I have a question... Why did the version numbering change to v3.4.0-dev?

Good question.

I had to make a "breaking" change. Specifically, I changed a field in HBIOS from a nibble to a byte. The OSes and some applications rely on the size of this field and were also changed.

The OSes and the applications check the major and minor version number and either abort or issue a warning if the running HBIOS is not the same as they were built for. So, I bumped the minor version number to that the OSes and applications will abort or complain if someone updates their ROM but not their disk image(s).

You could argue that this is all happening in the dev branch, so people using that branch are supposed to be careful and understand these things. However, I felt this change could cause enough grief that I wanted to prevent mistakes.

Thanks,

Wayne

[wwarthen]

@wwarthen for Linux users, I worked out a more effective way of preparing the media by using partition 1 and this avoids worrying about messing up the partition table.

Very nice approach. You have clearly grasped the concept of slices. This is the kind of stuff they were designed to do!

I was hoping to create a config file or batch file that would allow easy remapping of drive letters to slices depending on which scenario or profile that I wished to use.

This is the point that I am stuck at.

Perhaps ASSIGN.COM could be extended to read a user-defined config file ? For example, having a config file for Hi-TECH, or a config file for Z80 assemblers. Also I: and J: could be assigned slices past the end of the custom image.

In other words, could a user specify the default ASSIGN settings in slice 0 of the media aka drive C: and this could override the default ASSIGN selection ?

Saving a "global" assignment configuration has a few issues. Not the least of which is even more use of RAM in a precious area.

What I have been recommending to folks like you is that you create a specific slice to boot from. It would probably be one of the slices beyond the size of your mega combo image. I tend to put such custom slices starting at slice 32 just to keep them far away from any reimaging of the disk. That slice would have a PROFILE.SUB file which will be automatically run at boot. This batch file can set up your desired environment by using ASSIGN, ZPATH, etc.

You mentioned using multiple scenarios. You could accomplish this with multiple .SUB files in your boot slice and running the desired one manually. Alternatively, you could set up multiple boot slices and each one would have a PROFILE.SUB which is run automatically.

You could go as far as creating a custom ROM that automatically boots your desired boot slice.

Anyway, does any of this help?

Thanks,

Wayne

[skullandbones]

@wwarthen I have found my next challenge: DOS vs UNIX end of line characters for text files.

It seems that my attempts at getting the SUBMIT command to work with my PROFILE.SUB file was failing because the SUBMIT command was not liking the end of line characters. I was using my modified TE.COM text editor to create a PROFILE.SUB file. If I used a single ASSIGN statement then the SUBMIT command worked, however, if I used 2 ASSIGN statements then the SUBMIT output showed no output but returned to the prompt. When I used ZDE.COM to create a PROFILE.SUB with 2 ASSIGN statements then the SUBMIT command worked.

Looks like I am going to have to hack TE.COM to fix the end of line characters.

I used DUMP.COM to observe that CR-LF was been used by TE.COM. The problem was that I added a blank line to the end of the file. When I deleted the blank line, SUBMIT.COM was happy and the drive letter assignment worked.

It would be nice to have UNIX2DOS and DOS2UNIX commands on CP/M. This is because my files on the FAT partition will be UNIX format due to me using Linux.

Thanks,

Dean

[wwarthen]

I do remember having some odd problems like this with SUBMIT. Not surprising that Unix EOL would be a problem. However, I am surprised that a blank line would be a problem. Interesting. Regardless, glad you figured it out.

[wwarthen]

By the way, you may want to try SUPERSUB. It is a replacement for SUBMIT that overcomes the deficiencies in SUBMIT. SUPERSUB is already included on the boot disk images.

I did notice that the version of SUPERSUB that I included is v1.1. I will be replacing it with v1.3 in the next check-in. However, the changes are not likely to affect you.

Thanks,

Wayne

[skullandbones]

@wwarthen I think this issue topic can now be closed as the original issue has been resolved.

Thank you for all your hints.

Dean

[wwarthen]

Thanks @skullandbones. Will close this issue now. Feel free to open new issues as desired.

-Wayne