I'm trying to work out a set of diskdef entries for the cpm utils. I started with a blank SD card:

#dd if=/dev/zero of=/dev/sdc bs=4M conv=sync

I then put the card in an SC 131 running RomWBW and issued the following commands:
b:pip c:slice0=con:
Slice0
Ctrl-z
b:pip d:=slice1=con:
Slice1
Ctrl-z
etc, for six slices.
I then inspected the result back on the PC:

#dd if=/dev/sdc of=sdcard bs=1M count=65

$ hexdump -C sdcard
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................| 000001c0 01 00 2e 0f d0 ff 10 00 00 00 f0 ff 3f 00 00 00 |....Ðÿ....ðÿ?...|
000001d0 c1 ff 06 0f d0 ff 00 00 40 00 00 a0 0f 00 00 00 |Áÿ..Ðÿ..@.. ....|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............Uª| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
00006000 00 53 4c 49 43 45 30 20 20 20 20 20 00 00 00 01 |.SLICE0 ....| 00006010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0000e000 53 6c 69 63 65 30 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice0..........| 0000e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0000e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0000e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
00806000 00 53 4c 49 43 45 31 20 20 20 20 20 00 00 00 01 |.SLICE1 ....| 00806010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00806020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0080e000 53 6c 69 63 65 31 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice1..........| 0080e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0080e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0080e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
01006000 00 53 4c 49 43 45 32 20 20 20 20 20 00 00 00 01 |.SLICE2 ....| 01006010 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 01006020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0100e000 53 6c 69 63 65 31 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice1..........| 0100e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0100e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0100e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
0100f000 53 6c 69 63 65 32 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice2..........| 0100f010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0100f080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0100f200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
01806000 00 53 4c 49 43 45 33 20 20 20 20 20 00 00 00 01 |.SLICE3 ....| 01806010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 01806020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0180e000 53 6c 69 63 65 33 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice3..........| 0180e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0180e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0180e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
02006000 00 53 4c 49 43 45 34 20 20 20 20 20 00 00 00 01 |.SLICE4 ....| 02006010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 02006020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0200e000 53 6c 69 63 65 34 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice4..........| 0200e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0200e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0200e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
02100000

So the directory entries start ar offset 0x6000, 0x80600, 0x1006000, 0x1806000, etc.

My first observation is that the slices are exactly 8MB (0x80000), not 8MB+128K which is what "Hard Disk Anatomy.pdf" in the RomWBW Docs directory says.:

The size of a RomWBW CP/M slice is fixed. The RomWBW Hard Disk Geometry is:
Sector = 512 Bytes
Track = 16 Sectors (8KB per Track)
Cylinder = 16 Tracks (256 Sectors per Cylinder, 128KB per Cylinder)
Total Slice Size is 65 Cylinders or 8,320KB (128KB System Area + 8MB Filesystem)

Looks like each slice is 64 cylinders,not 65.

In any case, how do I convert this to diskdef entries?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'm sorry Bob, this is my fault. The "Hard Disk Anatomy" document describes the older "hd512" disk format. The current version of RomWBW introduced the preferred "hd1k" format. As you say it is now exactly 8MB with the beginning of the 8MB used for
the system area. The first slice starts at 1MB. I need to update the Hard Disk Anatomy to describe both formats.

If you look at the RomWBW distribution, in the Source/Images directory, you will see a diskdefs file. You will find entries for wbw_hd512_x as well as wbw_hd1K_x. Use the hd1k entries.

Thanks,

Wayne

On Monday, July 24, 2023 at 12:48:11 PM UTC-7, Bob Kircher wrote:

I'm trying to work out a set of diskdef entries for the cpm utils. I started with a blank SD card:

#dd if=/dev/zero of=/dev/sdc bs=4M conv=sync

I then put the card in an SC 131 running RomWBW and issued the following commands:
b:pip c:slice0=con:
Slice0
Ctrl-z
b:pip d:=slice1=con:
Slice1
Ctrl-z
etc, for six slices.
I then inspected the result back on the PC:

#dd if=/dev/sdc of=sdcard bs=1M count=65

$ hexdump -C sdcard
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................| 000001c0 01 00 2e 0f d0 ff 10 00 00 00 f0 ff 3f 00 00 00 |....Ðÿ....ðÿ?...|
000001d0 c1 ff 06 0f d0 ff 00 00 40 00 00 a0 0f 00 00 00 |Áÿ..Ðÿ..@.. ....|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............Uª| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
00006000 00 53 4c 49 43 45 30 20 20 20 20 20 00 00 00 01 |.SLICE0 ....| 00006010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0000e000 53 6c 69 63 65 30 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice0..........| 0000e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0000e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0000e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
00806000 00 53 4c 49 43 45 31 20 20 20 20 20 00 00 00 01 |.SLICE1 ....| 00806010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00806020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0080e000 53 6c 69 63 65 31 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice1..........| 0080e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0080e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0080e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
01006000 00 53 4c 49 43 45 32 20 20 20 20 20 00 00 00 01 |.SLICE2 ....| 01006010 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 01006020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0100e000 53 6c 69 63 65 31 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice1..........| 0100e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0100e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0100e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
0100f000 53 6c 69 63 65 32 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice2..........| 0100f010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0100f080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0100f200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
01806000 00 53 4c 49 43 45 33 20 20 20 20 20 00 00 00 01 |.SLICE3 ....| 01806010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 01806020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0180e000 53 6c 69 63 65 33 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice3..........| 0180e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0180e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0180e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
02006000 00 53 4c 49 43 45 34 20 20 20 20 20 00 00 00 01 |.SLICE4 ....| 02006010 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 02006020 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0200e000 53 6c 69 63 65 34 0d 1a 1a 1a 1a 1a 1a 1a 1a 1a |Slice4..........| 0200e010 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a |................| *
0200e080 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |åååååååååååååååå|
*
0200e200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
02100000

So the directory entries start ar offset 0x6000, 0x80600, 0x1006000, 0x1806000, etc.

My first observation is that the slices are exactly 8MB (0x80000), not 8MB+128K which is what "Hard Disk Anatomy.pdf" in the RomWBW Docs directory says.:

The size of a RomWBW CP/M slice is fixed. The RomWBW Hard Disk Geometry is: Sector = 512 Bytes
Track = 16 Sectors (8KB per Track)
Cylinder = 16 Tracks (256 Sectors per Cylinder, 128KB per Cylinder)
Total Slice Size is 65 Cylinders or 8,320KB (128KB System Area + 8MB Filesystem)

Looks like each slice is 64 cylinders,not 65.

In any case, how do I convert this to diskdef entries?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bob,
I've got the definitions that you want in a zip that contains how I used cpmtools to
get the directory 's etc. I've zipped my subdirectory and copied it to my PCloud account.

https://u.pcloud.link/publink/show?code=XZDDlAVZ6IKhKBrwpN5ad8VGTn7It09eL2p7

Larry Kraemer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for that info, Larry. I'm afraid it doesn't work for me though; looking at the file it appears it's for hd512 slices not hd1024. Looks like some good information in your file, I need to go over it carefully.

Wayne, it doesn't look like the wbw_hd1k_n entries are working for me either.

My objective is to create an SD card (and/or CF card for my SC126 also running RomWBW) with 255 disk slices. I don't know why other than "because it's possible"; I can't imagine actually requiring that much storage. The entire Walnut Creek CD would fit
on 60-some-odd slices, and the software that comes with RunCPM another 60+ even if there were no duplication. As I said,"because it's possible". Rather than run clrdir x: -y 200+ times, times, I'm looking to somehow automate that. Possibly via a
submit script, or paste an image together on a PC using dd, cat etc.

It would be useful to specify a diskdef file on the command line for cpmls et al rather than editing /usr/local/share/diskdefs while experimenting with diskdefs entries. Can this be done?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bob Kircher <rek1047@gmail.com> writes:

It would be useful to specify a diskdef file on the command line for
cpmls et al rather than editing /usr/local/share/diskdefs while
experimenting with diskdefs entries. Can this be done?

That would be very useful.

Have you tried to ping the author about this?

And it'd be nice if additionally installed software could drop their
relevant diskdefs as snippets into an /etc/cpmtools/diskdefs.d like
directory. Looking for ~/.cpmtools/diskdefs.d and the monolithic ~/.cpmtools/diskdefs too would be the cherry atop all this.

--
Take Back Control! -- Mesh The Planet!
I do not play Nethack, I do play GNUS! o;-)
Solid facts do not need 1001 pictures.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

OK, I see what you are trying to do. What I suggest is that you create individual slices. Then, to create the final image, you just concatenate them together. You will see that there is a file called "hd1k_prefix.dat" in the Binary folder of the
distribution. That file must come first, then you can just concatenate slices after it (up to 256 of them). In diskdefs, you will see an entry called "wbw_hd1k". This is used to manipulate a single slice.

No, cpmtools does not provide a command line option to specify the diskdefs file (I sure wish it did).

Thanks,

Wayne

On Tuesday, July 25, 2023 at 6:08:41 PM UTC-7, Bob Kircher wrote:

Thanks for that info, Larry. I'm afraid it doesn't work for me though; looking at the file it appears it's for hd512 slices not hd1024. Looks like some good information in your file, I need to go over it carefully.

Wayne, it doesn't look like the wbw_hd1k_n entries are working for me either.

My objective is to create an SD card (and/or CF card for my SC126 also running RomWBW) with 255 disk slices. I don't know why other than "because it's possible"; I can't imagine actually requiring that much storage. The entire Walnut Creek CD would fit

on 60-some-odd slices, and the software that comes with RunCPM another 60+ even if there were no duplication. As I said,"because it's possible". Rather than run clrdir x: -y 200+ times, times, I'm looking to somehow automate that. Possibly via a submit
script, or paste an image together on a PC using dd, cat etc.

It would be useful to specify a diskdef file on the command line for cpmls et al rather than editing /usr/local/share/diskdefs while experimenting with diskdefs entries. Can this be done?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks, Wayne, that gave me the information I needed to make it work. The file hd1k_prefix.dat allows for 64 slices and a 384MB fat partition though. So I set up another SD card, this time creating a 2GB RomWBW partition starting at 8:0:1 like hd1k_
prefix.dat does, rather than 0 like my first attempt. I created a file on each of the first eight slices, and cpmtools can access the slices using wbw_hd1k_<n>. My next task is to generate the other 251 diskdef entries. Then work out the seek/seek
arguments for a script to dd to paste together the final part.

Yeti, I don't know how to contact the author. The idea of a diskdefs.d directory sounds fantastic.

Thanks all
-Bob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bob Kircher <rek1047@gmail.com> writes:

Thanks, Wayne, that gave me the information I needed to make it work.
The file hd1k_prefix.dat allows for 64 slices and a 384MB fat
partition though. So I set up another SD card, this time creating a
2GB RomWBW partition starting at 8:0:1 like hd1k_prefix.dat does,
rather than 0 like my first attempt. I created a file on each of the
first eight slices, and cpmtools can access the slices using
wbw_hd1k_<n>. My next task is to generate the other 251 diskdef
entries. Then work out the seek/seek arguments for a script to dd to
paste together the final part.

Yeti, I don't know how to contact the author.

I think its homepage is <http://www.moria.de/~michael/cpmtools/>, unless
there are several versions out there.

The idea of a diskdefs.d directory sounds fantastic.

Maybe someone has an even better idea?

--
Take Back Control! -- Mesh The Planet!
I do not play Nethack, I do play GNUS! o;-)
Solid facts do not need 1001 pictures.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bob Kircher <rek1047@gmail.com> writes:

Yeti, I don't know how to contact the author.

I think its homepage is <http://www.moria.de/~michael/cpmtools/>, unless
there are several versions out there.

The idea of a diskdefs.d directory sounds fantastic.

Maybe someone has an even better idea?

--
Take Back Control! -- Mesh The Planet!
I do not play Nethack, I do play GNUS! o;-)
Solid facts do not need 1001 pictures.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, July 26, 2023 at 2:31:56 PM UTC-7, Bob Kircher wrote:

Thanks, Wayne, that gave me the information I needed to make it work. The file hd1k_prefix.dat allows for 64 slices and a 384MB fat partition though. So I set up another SD card, this time creating a 2GB RomWBW partition starting at 8:0:1 like hd1k_

prefix.dat does, rather than 0 like my first attempt. I created a file on each of the first eight slices, and cpmtools can access the slices using wbw_hd1k_<n>. My next task is to generate the other 251 diskdef entries. Then work out the seek/seek
arguments for a script to dd to paste together the final part.

Glad you got it figured out Bob. I am actually pretty interested in your experiment. While the maximum of 256 slices should not be a problem, I am not aware of anyone actually doing it in practice.

Thanks,

Wayne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, July 26, 2023 at 10:34:49 PM UTC-4, Wayne Warthen wrote:

Glad you got it figured out Bob. I am actually pretty interested in your experiment. While the maximum of 256 slices should not be a problem, I am not aware of anyone actually doing it in practice.

Thanks,

Wayne

assign

A:=SD0:0
B:=MD0:0
C:=MD1:0
D:=SD0:1
E:=SD0:2
F:=SD0:3
G:=SD0:251
H:=SD0:252
I:=SD0:253
J:=SD0:254

dir j:

| SLICE254

type j:slice254

Slice


There you have it. 255 slices. I should have a 256th, but I'm not sure it won't run into the FAT partition immediately after it.

HBIOS unit number [0..2]: 2
Capacity of disk 2: ( 15G) 31193088 Geom dbf81010
Nr ---Type- A -- Start End LBA start LBA count Size
1 RomWBW 2e 8:0:1 1023:15:16 2048 4194304 2G
2 FAT16 06 1023:0:1 1023:15:16 4196352 4194304 2G
3 00 *** empty ***
4 00 *** empty ***

I was under the impression RomWBW ignored the partition table, and the only purpose of a type 2E partition is so other partitioning software (fdisk, gparted, etc) will leave it alone. Is that still the case?

Something that could have been an issue was making a slice bootable on the SD card. When booting CP/M or Z-System, I get an error:

syscopy c:=b:

SYSCOPY v2.1 for RomWBW CP/M, 15-May-2020 (CP/M 2 Mode)
Copyright 2020, Wayne Warthen, GNU GPL v3

Transfer system image from B: to C: (Y/N)? y
Reading image...
Non-system disk error

I made it bootable by putting the card in my SC126 system, which has an SD card adapter and also a compact flash adapter. I could then boot off the compact flash and syscopy would successfully copy from the CF boot slice to the SD card. How would I do
it if I didn't happen to have the other system?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 27, 2023 at 8:42:39 AM UTC-7, Bob Kircher wrote:

On Wednesday, July 26, 2023 at 10:34:49 PM UTC-4, Wayne Warthen wrote:

Glad you got it figured out Bob. I am actually pretty interested in your experiment. While the maximum of 256 slices should not be a problem, I am not aware of anyone actually doing it in practice.

There you have it. 255 slices. I should have a 256th, but I'm not sure it won't run into the FAT partition immediately after it.

Something that could have been an issue was making a slice bootable on the SD card. When booting CP/M or Z-System, I get an error:

syscopy c:=b:

SYSCOPY v2.1 for RomWBW CP/M, 15-May-2020 (CP/M 2 Mode)
Copyright 2020, Wayne Warthen, GNU GPL v3

Transfer system image from B: to C: (Y/N)? y
Reading image...
Non-system disk error

I made it bootable by putting the card in my SC126 system, which has an SD card adapter and also a compact flash adapter. I could then boot off the compact flash and syscopy would successfully copy from the CF boot slice to the SD card. How would I do

it if I didn't happen to have the other system?

I assume B: is still a ROM Disk in your system. A ROM Disk has no system tracks, hence to system to copy. To account for this problem, I include files with the system track image on the ROM Diskl.

I think you want to use "SYSCOPY C:=B:ZSYS.SYS".

Thanks,

Wayne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)