cpm-86 disk image

[Philippe]

Hello there,

I have built a working cpm-86 emulator with virtualbox (with these guide
: http://www.z80.eu/blog/index.php?m=08&y=12&d=29&entry=entry120807-180000).

In order to do that, I run the included MAKEDISK.BAT in a virtual
WindowsXP, writing in a virtual floppy. Then I rename the resulting
image file from img to dsk and use it as a boot floppy for the virtual
cpm-86 machine.

Now I try to add a second floppy to the cpm-86 system with another image
(made from this file : http://www.cpm.z80.de/download/cbasic86.zip) but
now the question :
how can I generate a cpm-86 readable floppy image (readable by
virtualbox and by cpm-86) ?

Many thanks for helping.

Philippe

[Peter Dassow]

On 15.08.2012 18:37, Philippe wrote:
> I have built a working cpm-86 emulator with virtualbox (with these guide
> :
> http://www.z80.eu/blog/index.php?m=08&y=12&d=29&entry=entry120807-180000).
>
> In order to do that, I run the included MAKEDISK.BAT in a virtual
> WindowsXP, writing in a virtual floppy. Then I rename the resulting
> image file from img to dsk and use it as a boot floppy for the virtual
> cpm-86 machine.

That's because you need a non-compressed image file.

> Now I try to add a second floppy to the cpm-86 system with another image
> (made from this file : http://www.cpm.z80.de/download/cbasic86.zip) but
> now the question :
> how can I generate a cpm-86 readable floppy image (readable by
> virtualbox and by cpm-86) ?

Your mentioned cbasic86.zip contains only CP/M program and data files,
not a floppy image file. You will be able to generate a blank floppy
disk (image) inside the emulator / while running the emulator with CP/M-86.
Then you should convert the VirtualBox image file with my small utility
(I added a usage hint in my blog, too).
After the image file is "cpmtools" compatible, you can manipulate the
image file with cpmtools commands.
When you're done, convert the "cpmtools" image back to a VirtualBox
compatible image file again with my small utility.
You should be able now to work with the "new" image/floppy.

Regards
Peter

[Peter Dassow]

On 17.08.2012 12:37, Peter Dassow wrote:
> [...]

> When you're done, convert the "cpmtools" image back to a VirtualBox
> compatible image file again with my small utility.
> You should be able now to work with the "new" image/floppy.

For your convenience and as a proof, I added even a disk image with
added CBASIC-86 to my blog entry at www.z80.eu/blog/ ...

Regards
Peter

[Philippe]

Le 17/08/2012 13:11, Peter Dassow a ï¿œcrit :

I appreciate your help but things are not very clear for me. Can you
explain step by step how you have created the empty floppy in cpm86
(running in virtualbox), move them to a cpmtools writable format, put
the files inside and then move them back to virtualbox ?

Again I really appreciate your help.

Regards.

Philippe

[Ivan Shmakov]

>>>>> Peter Dassow <z8...@arcor.de> writes:

[...]

> For your convenience and as a proof, I added even a disk image with
> added CBASIC-86 to my blog entry at www.z80.eu/blog/ ...

BTW, out of curiosity (I vaguely recall running a Unix-based
CP/M + Z80 emulator a few times, having no experience with
either CP/M proper or CP/M-86) I've downloaded and extracted the
image (floppy.flp of cpm86fl2.zip), and... It didn't work.

So, the first question: is floppy.flp a "raw" floppy disk image
(as could be guessed by its size, which is exactly 1440 KiB)?
If it indeed is, it was my understanding that PC BIOS expects
the first sector to be marked with 0x55, 0xAA in its two last
bytes for the media to be considered "bootable":

--cut: http://en.wikipedia.org/wiki/Boot_sector --
[...] The BIOS merely passes control to whatever exists there, as
long as the sector meets the very simple qualification of having the
boot record signature of 0x55, 0xAA in its last two bytes. [...]
--cut: http://en.wikipedia.org/wiki/Boot_sector --

For floppy.flp, the last two bytes are as follows:

$ od -Ax -j 510 -N 2 -t x1 < floppy.flp
0001fe 01 90
000200
$

Naturally, QEMU refuses to boot from such a media.

Also, I've tried a few images from http://cpm.z80.de/.
Unfortunately, these seem to be in a vendor-specific CopyQM
format, which I know of no utility (beside CopyQM) can support.
Unfortunately, CopyQM fails with "Drive not ready" under
FreeDOS/QEMU for me, and I'm reluctant to try it on some "real"
hardware (with a FDD.)

Any suggestions?

TIA.

--
FSF associate member #7257 http://sf-day.org/

[Steve Nickolas]

On Sat, 18 Aug 2012, Ivan Shmakov wrote:

> Naturally, QEMU refuses to boot from such a media.

qemu -no-fd-bootchk

-uso.

[Peter Dassow]

On 17.08.2012 20:12, Ivan Shmakov wrote:
> [...]
>
> > For your convenience and as a proof, I added even a disk image with
> > added CBASIC-86 to my blog entry at www.z80.eu/blog/ ...
>
> BTW, out of curiosity (I vaguely recall running a Unix-based
> CP/M + Z80 emulator a few times, having no experience with
> either CP/M proper or CP/M-86) I've downloaded and extracted the
> image (floppy.flp of cpm86fl2.zip), and... It didn't work.

What exactly did not work ? I documented my success with screenshots,
but I didn't wanted to make a step-by-step manual.
You can make more than one mistake even in configuration of the VM itself.

> So, the first question: is floppy.flp a "raw" floppy disk image
> (as could be guessed by its size, which is exactly 1440 KiB)?

Yes. But it's track/head order differs from other floppy image formats.

> If it indeed is, it was my understanding that PC BIOS expects
> the first sector to be marked with 0x55, 0xAA in its two last
> bytes for the media to be considered "bootable":

No. BIOS is not related with DOS. BIOS will try to load the first
sector, regardless what's inside this sector. If loaded in memory
(typically at 0000:7C00), IP is set to the first byte of the loaded
sector. "Magic Numbers" like 55 AA are only important for Microsoft
operating systems.

> --cut: http://en.wikipedia.org/wiki/Boot_sector --
> [...] The BIOS merely passes control to whatever exists there, as
> long as the sector meets the very simple qualification of having the
> boot record signature of 0x55, 0xAA in its last two bytes. [...]
> --cut: http://en.wikipedia.org/wiki/Boot_sector --

Wikipedia Bullshit. There is no quality control what is published.
That's the proof, CP/M-86 needs no "magic numbers".

> For floppy.flp, the last two bytes are as follows:
>
> $ od -Ax -j 510 -N 2 -t x1 < floppy.flp
> 0001fe 01 90
> 000200
> $

You're totally wrong with your assumptions. It doesn't matter what is
stored at the end of the sector.

>
> Naturally, QEMU refuses to boot from such a media.

Naturally ? I didn't try QEMU, but you can't speak about nature in
conjunction with QEMU. I don't like QEMU, it's too specific in its
intended use. VMWare has a far better quality and is much more compatible.

> Also, I've tried a few images from http://cpm.z80.de/.
> Unfortunately, these seem to be in a vendor-specific CopyQM
> format, which I know of no utility (beside CopyQM) can support.
> Unfortunately, CopyQM fails with "Drive not ready" under
> FreeDOS/QEMU for me, and I'm reluctant to try it on some "real"
> hardware (with a FDD.)

You don't need to expand the compressed CopyQM image because I already
saved a decompressed (but not otherwise modified version!) version.
I don't know what you have tried, but it seems to be wrong. I used
CopyQM with VMWare and an installed MS-DOS 7.1 without any problems.

Regards
Peter

[Peter Dassow]

On 17.08.2012 18:26, Philippe wrote:
>>> [...]
>>> When you're done, convert the "cpmtools" image back to a VirtualBox
>>> compatible image file again with my small utility.
>>> You should be able now to work with the "new" image/floppy.
>> For your convenience and as a proof, I added even a disk image with
>> added CBASIC-86 to my blog entry at www.z80.eu/blog/ ...
>>
>> Regards
>> Peter
>>
> I appreciate your help but things are not very clear for me. Can you
> explain step by step how you have created the empty floppy in cpm86
> (running in virtualbox), move them to a cpmtools writable format, put
> the files inside and then move them back to virtualbox ?
>
> Again I really appreciate your help.

When you managed it to boot CP/M-86 (having two drives ready
configured), you can use the CP/M command "DSKMAINT".
More easy is you make a copy of the boot disk image, mount this with the
second floppy drive and after booting CP/M-86 from A:, delete everything
from B: (e.g. with command "era b:*.*").
As a result, you get a blank floppy.
Instead of using a second floppy drive, try to use the harddisk (as
described in my blog again).

Regards
Peter

[Ivan Shmakov]

Indeed, it works that way, thanks!

However, I'm still curious on whether a "typical" PC BIOS (as of
the time cheaper PC's still had FDC's) forces this check or not?

[Ivan Shmakov]

>>>>> Peter Dassow <z8...@arcor.de> writes:
>>>>> On 17.08.2012 20:12, Ivan Shmakov wrote:

[...]

>> So, the first question: is floppy.flp a "raw" floppy disk image (as
>> could be guessed by its size, which is exactly 1440 KiB)?

> Yes. But it's track/head order differs from other floppy image
> formats.

ACK, thanks.

[...]

>> --cut: http://en.wikipedia.org/wiki/Boot_sector --
>> [...] The BIOS merely passes control to whatever exists there, as
>> long as the sector meets the very simple qualification of having the
>> boot record signature of 0x55, 0xAA in its last two bytes. [...]
>> --cut: http://en.wikipedia.org/wiki/Boot_sector --

> Wikipedia Bullshit. There is no quality control what is published.

If there's a reliable source supporting a different point, feel
free to edit the page accordingly.

My edition of Norton's "Programmer's guide to the IBM PC & PS/2"
(1988, translated in 1994) states (Chapter 5, "Boot disks"
section) that the BIOS indeed checks the boot media signature.

> That's the proof, CP/M-86 needs no "magic numbers".

There's no CP/M-86 until the BIOS bootloader passes control to
it. Which is unlikely to happen without having the
aforementioned signature in the first logical sector of the boot
media.

[...]

> I don't like QEMU, it's too specific in its intended use. VMWare has
> a far better quality and is much more compatible.

Given a piece of code which I'm free to study and improve, for
what reason should I consider surrendering those freedoms and
use a non-free alternative instead?

>> Also, I've tried a few images from http://cpm.z80.de/.
>> Unfortunately, these seem to be in a vendor-specific CopyQM format,
>> which I know of no utility (beside CopyQM) can support.
>> Unfortunately, CopyQM fails with "Drive not ready" under
>> FreeDOS/QEMU for me, and I'm reluctant to try it on some "real"
>> hardware (with a FDD.)

> You don't need to expand the compressed CopyQM image because I
> already saved a decompressed (but not otherwise modified version!)
> version.

That's just a single image; there're quite a few more at
http://cpm.z80.de/.

> I don't know what you have tried, but it seems to be wrong. I used
> CopyQM with VMWare and an installed MS-DOS 7.1 without any problems.

I'm curious, where can one order a copy of MS-DOS 7.1 nowadays?

[Ivan Shmakov]

To note is that I've added the CP/M-86 1.44" image to my
iPXE-based "Network boot" menu, too. Now, virtually any x86
machine (or an "emulation" thereof) in my LAN, may boot a
CP/M-86 system given a suitable iPXE command sequence or script.

The relevant parts of the iPXE "menu" script I've used are as
follows:

#!ipxe

:menu
menu Boot menu
# ...
item cpm86 Boot CP/M-86 [cpm.z80.de/download/144cpm86.zip; memdisk]
# ...
item shell Run iPXE Shell
choose boot && goto ${boot}

# ...

:cpm86
kernel /diskless/memdisk.lkrn
initrd ../bin/144cpm86.img
boot || exit 1

# ...

PS. I'm quite sure that this configuration will work over Internet,
too, but I'm somewhat reluctant to share the server's URI to
point iPXE at, as this version of CP/M-86 doesn't seem like a
free software (as in "free speech".)

[Peter Dassow]

On 17.08.2012 21:23, Ivan Shmakov wrote:
>
> > Wikipedia Bullshit. There is no quality control what is published.
>
> If there's a reliable source supporting a different point, feel
> free to edit the page accordingly.

I did it a few minutes ago (see Wikipedia's "Talk" section).

> My edition of Norton's "Programmer's guide to the IBM PC & PS/2"
> (1988, translated in 1994) states (Chapter 5, "Boot disks"
> section) that the BIOS indeed checks the boot media signature.
>
> > That's the proof, CP/M-86 needs no "magic numbers".
>
> There's no CP/M-86 until the BIOS bootloader passes control to
> it. Which is unlikely to happen without having the
> aforementioned signature in the first logical sector of the boot
> media.

You're right, it's not CP/M-86 which needs no "magic numbers", it's the
BIOS itself which needs no magic numbers. Regardless of this, CP/M-86
does not need any magic number in the boot sector, but MS-DOS will check
this.

> > I don't know what you have tried, but it seems to be wrong. I used
> > CopyQM with VMWare and an installed MS-DOS 7.1 without any problems.
>
> I'm curious, where can one order a copy of MS-DOS 7.1 nowadays?

I guess FreeDOS will do it also, but anyway, I have still an original
Windows 98 SE CD, so I can use MS-DOS 7.1 (which is included).
If you want to discuss legal or illegal use of an old microsoft
operating system, try another newsgroup like alt.lawyers or even
alt.philosophy.law ...
And btw. ... CopyQM was designed to run with MS-DOS, not FreeDOS.

Regards
Peter

[s_dub...@yahoo.com]

On Friday, August 17, 2012 2:47:48 PM UTC-5, Peter Dassow wrote:
> On 17.08.2012 21:23, Ivan Shmakov wrote:
>

[snip]

>
>
> You're right, it's not CP/M-86 which needs no "magic numbers", it's the
>
> BIOS itself which needs no magic numbers. Regardless of this, CP/M-86
>
> does not need any magic number in the boot sector, but MS-DOS will check
>
> this.
>

You forgot; the last byte is 00h for single sided, 01h for double sided media for cp/m-86 (this is an early ibm convention).

Also, the hard drive controller 'option rom' -- the seagate scsi st-01 controller is one which revectors int13h thru its own int40h, and does in fact enforce the AA55h signature word, and it will not boot cp/m-86, but a Future Domain scsi controller doesn't do that and it will boot cp/m-86 from A:. IOW an option rom can modify the rom bios because the option roms are initialized later, or last, in the POST code.

Of the more modern pentium class systems with floppy drives, there are a rumored few which enforce the floppy boot sector signature, but they are rare.

Steve

[Ivan Shmakov]

>>>>> Ivan Shmakov <onei...@gmail.com> writes:

[Cross-posting to news:comp.os.linux.networking and
news:comp.os.msdos.misc, for an example setup for booting the
Debian GNU/Linux 6.0.4 Live and FreeDOS Balder images over a
network is provided. I'm looking for both a better-suited
newsgroup, and a configuration to boot a ZX Spectrum emulator.]

> To note is that I've added the CP/M-86 1.44" image to my iPXE-based
> "Network boot" menu, too. Now, virtually any x86 machine (or an
> "emulation" thereof) in my LAN, may boot a CP/M-86 system given a
> suitable iPXE command sequence or script.

[...]

> PS. I'm quite sure that this configuration will work over Internet,
> too, but I'm somewhat reluctant to share the server's URI to point
> iPXE at, as this version of CP/M-86 doesn't seem like a free software
> (as in "free speech".)

... On a second though, here it is:

http://ritic.am-1.org/diskless/ipxe/world-default

One can run it with QEMU (or QEMU/KVM) like:

$ qemu \
-kernel virtio-net.lkrn \
-net nic,model=virtio \
-net user,bootfile=http://173.0.50.100/diskless/ipxe/world-default

It seems that the version of QEMU I use fails to provide DNS to
the child, so I had to use "plain" IPv4 addresses within both
the command line above and the "world-default" iPXE script, as
well as providing a copy of balder10.img on my server (as
http://ibiblio.org/ apparently requires the proper Host: HTTP
header.)

For booting "real" hardware, one'd need a DHCP server, and also
a TFTP one (unless a recent version of iPXE is burned into the
boot ROM.)

E. g., the ISC DHCP server may be configured roughly as follows
(assuming a static MAC to IPv4 mapping.)

### dhcpd.conf -*- Default-Generic -*-

default-lease-time 600;
max-lease-time 7200;

subnet 192.0.2.0 netmask 255.255.255.0 {
use-host-decl-names on;
option subnet-mask 255.255.255.0;
option routers 192.0.2.1;
option domain-name-servers
192.0.2.53;
# option ntp-servers 192.0.2.123;

if exists user-class and option user-class = "iPXE" {
filename "http://173.0.50.100/diskless/ipxe/world-default";
} else {
## download iPXE from a TFTP server
next-server 192.0.2.69;
filename "undionly.kpxe";
}
host diskless.example.org {
hardware ethernet 00:27:0e:05:e5:9e;
fixed-address 192.0.2.97;
}
}

### dhcpd.conf ends here

Also note that the Debian 6.0.4 Live "standard" image is some
177 MiB in total, and thus takes a while to load from
http://cdimage.debian.org/ (AKA http://130.239.18.163/.) It's
provided as an example only; one should really consider putting
it somewhere within his or her own network! (There's also a
section for loading the "Xfce desktop" image, but its menu entry
was commented-out, so not to abuse the cdimage server.)

The files provided (below /bin/) are as follows. (I'd like to
thank Aioe for its wonderful "441 Lines longer than 79 chars".)

Image: 144cpm86.img
Copy-of: http://z80.eu/downloads/cpm86fl2.zip (floppy.flp)
Description: CP/M-86 1.44" bootable floppy
Originally from http://cpm.z80.de/download/144cpm86.zip.

Image: balder10.img
Copy-of: http://ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/
unofficial/balder/balder10.img
Description: Balder 1.0 (FreeDOS) 1.44" bootable floppy

Image: memdisk.lkrn
Copy-of: http://snapshot.debian.org/archive/debian/20120630T153537Z/pool/
main/s/syslinux/syslinux-common_4.05%2Bdfsg-6_all.deb
(./usr/lib/syslinux/memdisk)
Description: MEMDISK implements a RAM disk by hooking INT 13h
This one comes from the SYSLINUX project.

Image: memtest86+.0
Source: https://git.ipxe.org/people/mcb30/memtest.git/commit/f9d3679f3770
Description: Memtest86+ memory tester (PXE)
This version of Memtest86+ was built with an experimental PXE
support.

Image: memtest86.bin
Copy-of: http://snapshot.debian.org/archive/debian/20120514T041508Z/pool/
main/m/memtest86/memtest86_4.0s-1_amd64.deb (./boot/memtest86.bin)
Description: Memtest86 memory tester

Image: pxelinux.0
Copy-of: http://snapshot.debian.org/archive/debian/20120630T153537Z/pool/
main/s/syslinux/syslinux-common_4.05%2Bdfsg-6_all.deb
(./usr/lib/syslinux/pxelinux.0)
Description: PXELINfUX loads Linux from a network using PXE

[Ivan Shmakov]

>>>>> Peter Dassow <z8...@arcor.de> writes:
>>>>> On 17.08.2012 21:23, Ivan Shmakov wrote:

[...]

> (see Wikipedia's "Talk" section).

ACK, I see. (Thanks to all the participants for an interesting
discussion, BTW.)

JFTR:

--cut: http://en.wikipedia.org/wiki/Talk:Boot_sector#Boot_signature --
[...] Consider for example this Microsft source [1] which makes clear
that it is the BIOS that first checks for the signature.
Crispmuncher 02:48, 18 August 2012 (UTC).

[1] http://support.microsoft.com/kb/149877

There is BIOS source code online e. g. at [2] which enforces these
rules: for a hard disk the 0xAA55 signature check is made, while
for a floppy disk the rule is that the first byte of the boot
sector must be less [greater or equal -- Matthiaspaul] than 0x06
and the first 9 words must not all be identical. While that
doesn't reveal the distribution of signature checks in modern
BIOSes, it does provide a latest date for their introduction.
Ewx (talk) 08:16, 18 August 2012 (UTC)

[2] http://www.intel-assembler.it/portale/5/ibm-at-286-souce-code/ibm-at-286-souce-code.asp
--cut: http://en.wikipedia.org/wiki/Talk:Boot_sector#Boot_signature --

[...]

>>> I don't know what you have tried, but it seems to be wrong. I used
>>> CopyQM with VMWare and an installed MS-DOS 7.1 without any
>>> problems.

>> I'm curious, where can one order a copy of MS-DOS 7.1 nowadays?

> I guess FreeDOS will do it also,

Actually, I believe it was a QEMU's fault. I'm reluctant to try
it on a "real" hardware, so I'd probably try other versions of
QEMU, or perhaps Bochs.

> but anyway, I have still an original Windows 98 SE CD, so I can use
> MS-DOS 7.1 (which is included).

While I've certainly used some version of DOS until early 1999,
I was then eager to switch to GNU/Linux, which I deem a
fortunate choice to this day.

I've never had a version of Windows installed on my computers,
and bought no license, either.

[...]

[Peter Dassow]

On 17.08.2012 21:08, Ivan Shmakov wrote:
>>>>>> Steve Nickolas <usot...@buric.co> writes:
>>>>>> On Sat, 18 Aug 2012, Ivan Shmakov wrote:
>
> >> Naturally, QEMU refuses to boot from such a media.
>
> > qemu -no-fd-bootchk
>
> Indeed, it works that way, thanks!
>
> However, I'm still curious on whether a "typical" PC BIOS (as of
> the time cheaper PC's still had FDC's) forces this check or not?

I tried to discuss this further at the mentioned Wikipedia boot sector page.
Then I stopped and thought, why not trying it in reality with a more
modern Thinkpad notebook which still has a build-in floppy drive ?
So I added a new blog entry at http://www.z80.eu/blog/ for a photo as a
proof that it does work also with much more modern PCs.
Btw. VMWare's PhoenixBIOS is really new enough for another proof that it
works with newer hardware (although this "hardware" is virtual).

Regards
Peter

[Tarkin]

On Aug 18, 2:25 pm, Peter Dassow <z8...@arcor.de> wrote:
> On 17.08.2012 21:08, Ivan Shmakov wrote:
>

> >>>>>> Steve Nickolas <usots...@buric.co> writes:
> >>>>>> On Sat, 18 Aug 2012, Ivan Shmakov wrote:
>
> >   >> Naturally, QEMU refuses to boot from such a media.
>
> >   > qemu -no-fd-bootchk
>
> >    Indeed, it works that way, thanks!
>
> >    However, I'm still curious on whether a "typical" PC BIOS (as of
> >    the time cheaper PC's still had FDC's) forces this check or not?
>
> I tried to discuss this further at the mentioned Wikipedia boot sector page.
> Then I stopped and thought, why not trying it in reality with a more
> modern Thinkpad notebook which still has a build-in floppy drive ?

> So I added a new blog entry athttp://www.z80.eu/blog/for a photo as a

> proof that it does work also with much more modern PCs.
> Btw. VMWare's PhoenixBIOS is really new enough for another proof that it
> works with newer hardware (although this "hardware" is virtual).
>
> Regards
>   Peter

Given the age of CP/M-86, I am curious to know why the floppy boot
signature
was ever enforced. Could it be an artifact of a specific period of PC
history?

TTFN,
Tarkin

[Harald Peters]

is that image Public Domain?

Op Sat, 18 Aug 2012 13:46:52 +0200 schreef Ivan Shmakov
<onei...@gmail.com>:

Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/