It's not trivial, but the allocation map enumerates the logical blocks. Also, each file may have multiple directory entries, where the extent tells you what order the data (allocation blocks) are in. This all is predicated on the Disk Parameter Block (DPB) for the image - which is not always stored in the image itself. I think all Heath formats have a DPB in sector 0, but other formats (e.g. MMS) do not. The RC byte in the directory entry tells you how many "records" (128 byte) are contained in the *last* extent. Complicating things, each directory entry may contain more than one extent - depending on the DPB.
I'm not sure the best place to get the information you need. CP/M "system alteration guide" usually has a lot of information, as does the "programmers guide". There is also example C code in the cpmtools project, although that is not always easy to read.
One source for cpmtools code is https://github.com/lipro-cpm4l/cpmtools
This all is just a starting point. Maybe look into it and then more-specific questions will arise.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fc05b025-4cfa-477b-9be8-725704010a50n%40googlegroups.com.
My favorite reference for CP/M internals is Andy Johnson-Laird’s “The Programmer’s CP/M Handbook.” Includes ASM and C code examples. Well worth studying… I have the paper copy but found this on line:
http://oldcomputers.dyndns.org/public/pub/manuals/a_programmers_cpm_handbook_(1983).pdf
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Douglas Miller
Sent: Friday, September 10, 2021 12:43 PM
To: se...@googlegroups.com
Subject: Re: [sebhc] H8D Utility 3: Reading CP/M files from disk image
It's not trivial, but the allocation map enumerates the logical blocks. Also, each file may have multiple directory entries, where the extent tells you what order the data (allocation blocks) are in. This all is predicated on the Disk Parameter Block (DPB) for the image - which is not always stored in the image itself. I think all Heath formats have a DPB in sector 0, but other formats (e.g. MMS) do not. The RC byte in the directory entry tells you how many "records" (128 byte) are contained in the *last* extent. Complicating things, each directory entry may contain more than one extent - depending on the DPB.
I'm not sure the best place to get the information you need. CP/M "system alteration guide" usually has a lot of information, as does the "programmers guide". There is also example C code in the cpmtools project, although that is not always easy to read.
One source for cpmtools code is https://github.com/lipro-cpm4l/cpmtools
This all is just a starting point. Maybe look into it and then more-specific questions will arise.
On 9/10/21 11:25 AM, Les Bird wrote:
CP/M experts (Darrell?),
I'm having a hard time understanding the CP/M disk structure. I'm working on H8DUtility 3 again and added viewing of HDOS files from the app (see screen shot) but for the life of me I cannot seem to figure out how CP/M works. I've searched and searched but can't find examples of how to get to the file data from a CP/M directory entry (the CP/M directory structure is discussed a lot). The directory entry gives me "extent", "sectors" and an allocation map (16 bytes) but I have no idea how to use that data to get me to where the data is on the disk image. Hoping someone here can describe how this works.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fc05b025-4cfa-477b-9be8-725704010a50n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1df4846f-2419-a3dc-a69b-691498faefb1%40gmail.com.
It is also worth noting that reading files is "relatively"
simple, but writing (adding) files to a disk is a whole other
effort, and requires great care as not to corrupt the
disk/filesystem.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/016b01d7a663%24dfc6a670%249f53f350%24%40gmail.com.
Les: if it’s of any use, my “VPIP” utility builds a copy of the CP/M directory in RAM. I used Johnson-Laird’s book as a reference. VPIP source attached plus some test jig code… see routine bldcdir() . Only accessing the directory, not the file contents themselves, but may be some useful skeleton code in here for you.
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Les Bird
Sent: Friday, September 10, 2021 4:09 PM
To: SEBHC <se...@googlegroups.com>
Subject: Re: [sebhc] H8D Utility 3: Reading CP/M files from disk image
Thanks guys, very helpful.
Glenn, that book is excellent. Great detail on how the file system works.
Les
On Friday, September 10, 2021 at 4:03:25 PM UTC-4 Douglas Miller wrote:
It is also worth noting that reading files is "relatively" simple, but writing (adding) files to a disk is a whole other effort, and requires great care as not to corrupt the disk/filesystem.
On 9/10/21 11:49 AM, glenn.f...@gmail.com wrote:
My favorite reference for CP/M internals is Andy Johnson-Laird’s “The Programmer’s CP/M Handbook.” Includes ASM and C code examples. Well worth studying… I have the paper copy but found this on line:
http://oldcomputers.dyndns.org/public/pub/manuals/a_programmers_cpm_handbook_(1983).pdf
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Douglas Miller
Sent: Friday, September 10, 2021 12:43 PM
To: se...@googlegroups.com
Subject: Re: [sebhc] H8D Utility 3: Reading CP/M files from disk image
It's not trivial, but the allocation map enumerates the logical blocks. Also, each file may have multiple directory entries, where the extent tells you what order the data (allocation blocks) are in. This all is predicated on the Disk Parameter Block (DPB) for the image - which is not always stored in the image itself. I think all Heath formats have a DPB in sector 0, but other formats (e.g. MMS) do not. The RC byte in the directory entry tells you how many "records" (128 byte) are contained in the *last* extent. Complicating things, each directory entry may contain more than one extent - depending on the DPB.
I'm not sure the best place to get the information you need. CP/M "system alteration guide" usually has a lot of information, as does the "programmers guide". There is also example C code in the cpmtools project, although that is not always easy to read.
One source for cpmtools code is https://github.com/lipro-cpm4l/cpmtools
This all is just a starting point. Maybe look into it and then more-specific questions will arise.
On 9/10/21 11:25 AM, Les Bird wrote:
CP/M experts (Darrell?),
I'm having a hard time understanding the CP/M disk structure. I'm working on H8DUtility 3 again and added viewing of HDOS files from the app (see screen shot) but for the life of me I cannot seem to figure out how CP/M works. I've searched and searched but can't find examples of how to get to the file data from a CP/M directory entry (the CP/M directory structure is discussed a lot). The directory entry gives me "extent", "sectors" and an allocation map (16 bytes) but I have no idea how to use that data to get me to where the data is on the disk image. Hoping someone here can describe how this works.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fc05b025-4cfa-477b-9be8-725704010a50n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1df4846f-2419-a3dc-a69b-691498faefb1%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/016b01d7a663%24dfc6a670%249f53f350%24%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a2cba384-951e-4a78-a67f-5f640c24fd9dn%40googlegroups.com.
Click on the link in my original email, not the reply (the URL got truncated/"folded"). Here's the direct link:
-----Original Message-----
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of s shumaker
Sent: Friday, September 10, 2021 5:06 PM
To: se...@googlegroups.com
Subject: Re: [sebhc] H8D Utility 3: Reading CP/M files from disk image
I'm getting errors on that link but Archive.Org also has a copy.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/df97b1f4-b4f6-7820-b1d5-17770870d6af%40att.net.
More general. It’s about understanding how CP/M directory structure works in general, regardless of the media format.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855728FF5D5D771CAC0D0D7F7D69%40SN6PR01MB3855.prod.exchangelabs.com.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c79657c2-d2cf-4a84-be2d-79b82ebf8250n%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/eefVyCPeSbQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/2eb38df4-7555-46cd-8dff-7f2b9e7f18fdn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/bbf1bc60-a26b-4333-9f22-0a34c9900d26n%40googlegroups.com.
Note, the H37 skew was *physical* skew, the sectors were formatted on the track in an order that optimized sequential access. For physical skew, you don't need any special handling to access the data, assuming the data is organized in numerical sector order (1,2,3...). The issue for the images is that you don't have the skew information to reformat a new diskette that is identical to the original. The data will still be the same, but it may not perform as well.
The H17 disks had a *logical* skew, at least for some OSes, and
that does require knowledge of in order to access the data. It is
also possible to format H17 diskettes using a physical skew (on
top of the logical skew), which complicates things a lot when
trying to predict performance.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAKhgrKs2anDXMc%3DUXFnFC6h8PtLK4aKSwHip0ZLtDzUddxJD-Q%40mail.gmail.com.