Hi there,I am trying to remember how I did it but I am drawing a blank.
I have a Gotek running FlashFloppy in my PC I'm using for CP/M-86. I'm having a hard time finding out the magic sequence to use cpmtools to create new floppies.
Using the cpm86-144feat format, I can seem to create an image, and the CP/M-86 machine can read the directory, but the files are all wrong - truncated, etc. Like the sectors are out of order.
I was trying to create an image like:
dd if=/dev/zero of=test.img bs=1440k count=1
mkfs.cpm -f cpm86-144feat test.img
cpmcp -f cpm86-144feat test.img test.txt 0:
Does anyone know of the incantation to create an image? It doesn't even have to be a 1.44mb image. I just want to transfer some software over to my machine, like modem9.
Thank you!
Rob
Hi there,
I have a Gotek running FlashFloppy in my PC I'm using for CP/M-86. I'm having a hard time finding out the magic sequence to use cpmtools to create new floppies.
Using the cpm86-144feat format, I can seem to create an image, and the CP/M-86 machine can read the directory, but the files are all wrong - truncated, etc. Like the sectors are out of order.
I was trying to create an image like:
dd if=/dev/zero of=test.img bs=1440k count=1
mkfs.cpm -f cpm86-144feat test.img
cpmcp -f cpm86-144feat test.img test.txt 0:
Does anyone know of the incantation to create an image? It doesn't even have to be a 1.44mb image. I just want to transfer some software over to my machine, like modem9.
I'd copy a pretty large ASCII text file so you can look at the sectors and follow the
data to make sure it is correct.
dd if=/dev/zero bs=1440k count=1 | tr '\000' '\345' >test.img
mkfs.cpm -f fea1 test.img
cpmcp -f fea1 -T fea1,rawob /path/to/file/test.img test.txt 0:
Rob,
I've made another mistake on the cpm86-144 definition for /etc/mediaprm.
It should be DS QD sect=9 ssize=512
((512 * 9) * 2) * 80 = 737280
Larry
It does sound a lot like either sector skew or track/side placement. That is all a product of the BIOS you are running. Perhaps it's time to reverse-engineer the real disk layout. Can you take a known-good disk and create a raw image of it, and eitheranalyze it for sector skew/side placement or else post it so others can look at it? Ideally, that disk would contain text files that can be more-easily pieced back together.
Or with a working system, ask the BIOS. It does require a short program
to call the Get Disk Parameters function.
--
http://davesrocketworks.com
David Schultz
On Saturday, March 26, 2022 at 3:54:27 PM UTC-5, David Schultz wrote:
Or with a working system, ask the BIOS. It does require a short program
to call the Get Disk Parameters function.
--
http://davesrocketworks.com
David Schultz
Confirming the DPB by asking CP/M will help, but the skew and side placement won't be shown without more work.
Rob,
You can can log the A: drive, then do:
DIR A: DSK:
That will be a good starting point.
[code]
If you have a functional CP/M system, you can use DDT to find the Disk Parameter Block Address,
the Allocation Address, along with the information stored there for the logged floppy drive.
1. Log the floppy drive you wish to locate the DPB data for. I will use A: for this example
2. Run DDT and enter the code below:
A: <Carriage RETURN>
DDT
-f0100,0200,00 #fill memory with zero's
-A0100 #assemble program at 0100
0100 mvi c,0f #0f in C for Open file
DIR A: DSK:
STAT A: DSK:
B:
STAT B: DSK:
What method have you been using to write the image file to floppy? I can send you the .RAW or image type you
require.
The total capacity of the disk is based on the DPB. Depending on the specifics of your BIOS implementation, the DPB could be stored on the floppy and used during login to access the drive - in which case you'll need to replicate that. Note thatcpmtools does not do that, and mkfs.cpm only initializes the directory area according to what you told it was the DPB. If your version of CP/M-86 does store the DPB on the floppy, then that might explain the "156K" - it is blinding using invalid/
It might be easier to make an image of a working CP/M-86 diskette and post it. I'll be glad to analyze it for you and get the specifics of the format. If you have the source code for the BIOS, you can post that as well and I'll be glad to dig into it.
Oh interesting, with the 144cpm86.raw image as the selected image, STAT A: DSK: reports:
1,420: Kilobyte Drive Capacity
With the image I created using dd, mkfs.cpm and cpmcp, it reports:
156: Kilobyte Drive Capacity
so something is very different between those two images.
I wonder if mkfs.cpm isn't creating the proper directory?
Looking at the boot sector (first sector on disk), it appears that there is a data block after the initial JMP instruction. This data block includes a diskette label string, but I don't see data that resembles a DPB. There is also another 0x90 bytewhich may, or may not, be a duplicate format byte.
Can't tell if that source came from DRI or a vendor, but the standard DRI reference BIOS code that is available does not perform any such a check. The CPMDEV.ZIP code (PCBIOS.A86) is looking for a boolean value in the last byte of the boot sector, andhas no 1.44M DPB, so is not exactly matching what we're looking for here.
As far as being able to create compatible disks, it is probably necessary to duplicate the boot tracks of a "working" disk of the same format, and fill in the files you want. But if that is not working, it may be the sector skew and without source codefor the BIOS, or digging into the DPH/DPB (through DDT or a program), it may come down to creating a disk on the actual PC that contains a large text file that can be easily re-ordered - a large HEX file or assembler listing would work - and then
All you need to do is fill the directory sectors with 0xe5. I can't find
a way to make dd do that.
Also be aware that "BIOS" has a subtly different meaning in the IBM-PC/DOS world than in CP/M. DOS formally placed the BIOS in the ROM, while in the CP/M world the BIOS was the portion of CP/M that implemented the interfaced to the specific platform. Idon't believe that the IBM-PC "BIOS ROM" could be directly used as the CP/M-86 BIOS, so there had to be a "shim" (at least) to interface the CP/M-86 BIOS calls to the platform ROM "BIOS". I'm not sure what DOS defined as far as "format data" in the boot
The original post does say "PC", which I would assume means it is an IBM-PC - but that may be an incorrect assumption.
On 25/03/22 02:03, David Schultz wrote:I forgot about one little detail. If you want the disk to be bootable,
All you need to do is fill the directory sectors with 0xe5. I can't
find a way to make dd do that.
perhaps creating a file containing some E5s, of appropriate power-of-two
lent (easy to create with a flexible enough hex editor) and using it as
input file (if=e5.bin) ?
Best regards from Italy,
dott. Piergiorgio.
I forgot about one little detail. If you want the disk to be bootable,
it is going to have to look like a boot disk to the ROM BIOS. Which
means that first sector is important too.
I do see CPM listed among the various partition types: https://tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 108:47:38 |
Calls: | 9,684 |
Files: | 13,725 |
Messages: | 6,175,688 |