• Please review our updated Terms and Rules here

Need help adapting a drive parameter block

T

tschak909

Experienced Member
Joined
Mar 26, 2018
Messages
121
Location
Denton, TX USA
Hi guys,

Am adapting Coleco Adam CP/M to handle larger drives. The sector access method does not change at all, as it can easily address a 1024 byte block as a 32-bit quantity. So in theory I should be able to simply adjust the DPB:

But I've fallen flat on my face.

Method used:
Create 8mb disk image.

```
dd if=/dev/zero of=bigcpm.dsk bs=1024 count=8192
```

use hexedit to fill disk with 0xE5

mount on drive B, and sysgen the resulting disk. (This should always work because sysgen literally just writes the system loaded from an existing disk to the first 12 blocks of a disk, regardless of geometry.)

then hexedit the disk, and edit the DPB for the disk drive, this is at 0xDDB6 in memory, which corresponds to 0xFB6 on disk image:

Original values for a 160K ADAM Disk Image:

08 00 03 07 00 92 00 3f 00 c0 00 10 00 0D 00

SPT = $0008
BSH = $03
BLM = $07
EXM = $00
DSM = $0092
DRM = $003F
AL0 = $C0
AL1 = $00
CKS = $1000
OFF = $0D

I tried to modify to:

80 00 05 1F 01 FF 07 FF 03 FF 00 00 00 0D 00

SPT = $0080
BSH = $05
BLM = $1F
EXM = $01
DSM = $07FF
DRM = $03FF
AL0 = $FF
AL1 = $00
CKS = $0000
OFF = $0D

But this gives me the following screenshot: Any ideas? Anybody still around who can actually help debug this level of hackery? ;)
-Thom

cpmkablooie.png
 
Don't forget there's the DPH (Disk Parameter Header) and DPB (Disk Parameter Block) and you need to change both, and allocate more space the for vectors.

So you need to consider the Allocation Vector and Check Vector ( Well, DEFINITELY the AV, though the CV is related to the number of directory entries and might not change... ) and make sure that you have a suitable space for the AV's in the DPH since your BIOS is going to write them based on the increased number of alloctions. Your DSM has gone from 92 to 7FF - You need about 16 times the space in the AV table and you're BDOS is going to just keep writing like crazy assuming it's all there and who knows what it's going to overwrite, also, you're going to have to increase your allocation size if you want to max things out, and that means your allocations are going to get bigger, and so all your other numbers are going to change as well, including your masks and your extent mask looks a little small since you could well end up with a whole heap of extents per directory entry.

Booting probably won't change, but only as long as it doesn't use allocations for anything and just reads raw data record by record from the disk without using the BDOS, but if any part of the boot process uses the BDOS, you need to redimension the drive correctly, ensure the vectors have sufficient space, adjust the DPB to reflect the new geometry and then you should be good to go :)
 
Yeah, am not using CKS at all, so the CV is of no consequence, the AV on the other hand...

So for those following along, the size of the AV is calculated with: 2 * ( DSM / 8 + 1 )

I've gotta go find space.

-Thom
 
tschak909 said:
So for those following along, the size of the AV is calculated with: 2 * ( DSM / 8 + 1 )
Click to expand...

I'll simplify it a bit further also for the other readers since it's a good chance for me to also make sure I'm clear in my head about what I'm saying and if I explain anything poorly, one of the experts on the forum can correct me :) Also, it might help people who are new to what you're doing and want to read more about it - though I suspect it's a topic that either needs a LOT more space, and maybe some graphics diagrams, or should be kept hidden in the bios for people to tinker - :)

The DSM is the number of blocks in total on the disk, so it's your total disk size divided by your block size - or 160K = 146 (92hex) x 1024 or thereabouts which was the original DSM. This is going to increase to 2047 in the new DPB.

Each allocation needs one bit in the allocation vector, which tracks disk usage. So 146 / 8 = 18.25 so the Allocation Vector is 19 bytes long, resides somewhere in the BIOS and is overwritten by the BDOS. Also, there is a bit for allocation 0, since it counts from 0.

7FF blocks is 2047 blocks, which will take 256 bytes. What I suggested might be the cause was that a buffer intended to hold just 19 bytes now needs to hold 256 bytes, of which the other 237 bytes were probably used by buffers for other drives and functions within the BIOS/BDOS and hence when booting and using the drive, this would have overflowed and overwritten other "unknown" content, messing up the OS function.

The allocation vector is referenced from the Disk Parameter Header, which also contains the location of the Disk Parameter Block. You can find out where these are by asking the BIOS.

Thom also said he's not using the check vector ( either it's read only or the disk is using some other kind of disk change determination, in this case CKS is 0000 which means "not used" ) which is important to note, because the the allocations grow from 1024 bytes to 4096 bytes to allow for 2048 blocks to address 8Mb of space. This is reflected in the Block Shift factor increasing by two, and the Block Mask getting bigger. Also because there's now more than 256 blocks, the logical block numbers in the allocation tables will change from 8 bit to 16 bit, but as an extent only holds 16K, this doubles in size, but the extra block size increase if 4 times, so this quarters the number of allocations in the extent - Double, then quarter means half ( 2 x 0.25 ) so we will only use half the allocations in an extent, potentialy leaving the extent half-filled and wasting space.

As a result, the directory entry will not increase from holding 1 extent to 2 extents - hence the increase in the extent mask, notifying the BDOS that two extents are located in each directory entry.

Otherwise, the increase in the Directory Max actually reflects a 16 fold increase in the directory size (entries) due to the block size increase for directory allocations, but the value iss 4 times larger than this, indicating this drive is going to hold a massive number of file entries and alocations - 16 times more in fact. Since this is four times larger than the block size increase alone accounts for, the AL0 and AL1 ( which are bit patterns that are copied over the initial allocation vector bytes AL0 and AL1 - literally ) has increased from C000 ( 2 bits ) to FF00 ( 8 bits ) and reflects this fourfold increase in directory allocations despite now having 16 times the directory size.

So the DPB was correct that I could see and assuming all that is needed is for the disk controller to keep increasing the track number, which either translates to increase in logical blocks or increase in tracks.

Hence I suspected the error may have been in the DPH, not the DPB... Although I don't know that system or how it accesses the disk.

Also, I made similar omissions when I was writing up a new CP/M version a few months back, and accidentally obliterated my stack, so I sometimes remember to check both before I go creating random large disks. :)

As I start to document my new OS, I'll try to explain the above a lot better so that it's more easily understood - but for the most, DRI provided maths so that the values can be quickly generated and understood without having to know what the OS actually does with the bits and bytes in both the DPH and DPB.
 
Last edited:
I assume since you are using a disk image file that this is some sort of simulator? I'm guessing that the CP/M BIOS being used is designed to work with floppies, so you might not be able to just change to a 8M disk image and a different DPB and get things to work. The BIOS probably expects track and sector values to be consistent with the floppy geometry. Your new DPB changes sectors/track which completely alters what the BDOS passes to the BIOS, let alone the larger disk size specified by DSM. Also note that the reserved tracks represents a completely different size of boot area (212K vs. 13K), and the native SYSGEN may not handle that properly.

This is in addition to the larger ALV required. It may not be possible to change from a floppy to an 8M disk without altering the BIOS.
 
durgadas311 said:
I assume since you are using a disk image file that this is some sort of simulator? I'm guessing that the CP/M BIOS being used is designed to work with floppies, so you might not be able to just change to a 8M disk image and a different DPB and get things to work. The BIOS probably expects track and sector values to be consistent with the floppy geometry. Your new DPB changes sectors/track which completely alters what the BDOS passes to the BIOS, let alone the larger disk size specified by DSM. Also note that the reserved tracks represents a completely different size of boot area (212K vs. 13K), and the native SYSGEN may not handle that properly.

This is in addition to the larger ALV required. It may not be possible to change from a floppy to an 8M disk without altering the BIOS.
Click to expand...

I assumed the BIOS is being altered and that it's an emulator or hardware using some kind of LBA since it's an image - though I did miss that the SPT went from 08 to 80... Thanks for mentioning.

I'm waiting on the OP to come back and let us know if the disk is working :)

The funny thing about pushing crazy LBA image modes to real hardware - sometimes it can actually work. I wrote up a theoretical format for the Sinclair Spectrum Microdrive a couple of years ago that worked off of the concept that since the new drive emulators were all using images, it would be theoretically possible to push the image size to 640K using the inbuilt 5x overscan error correction mode as an arbiter of the extra disk space by reduplicating all the sectors (except the directory sectors) for each file, even though the actual format itself is limited by the geometry to slightly less than 128K as it doesn't have the sectors to drive anything else. But I reasoned it was possible to duplicate sectors due to the strange format it had... So someone who was building a physical emulator asked me if I could produce a disk image and after a couple of tries, we successfully got a 640K formatted microdrive that only used around 40 x 512 byte sectors but a real computer was able to read and access the disk and read 640K of real data... ( I made a screen shot slideshow so the data could be seen... It was filled with art ). It worked though because the emulator just read and spat out the sectors from the image... And I worked with the emulator developer to make sure the format worked correctly. Before that I got a range of results from failed to 256k with different emulators depending on how close they got to the original hardware... Though the original hardware also would have worked if it was possible to build a stringy floppy with ten times the media inside. The only downside was it meant each file took around 40 seconds to load but it was reliable and would load an image without failure.

BTW, do you know what the screenshot is and means? I don't know the Coleco Adam so I was assuming it was just a corrupted directory structure when viewing the disk post-formatting, but it may be something else.

David.
 
The Sysgen is its own thing. The CP/M boot on Adam just loads the first 12 blocks of data into memory starting at $DA00.
A disassembly of the boot loader is here: http://adamarchive.org/archive/Tech...-M 2.2 & Assembler - Boot Loader (MilliV).pdf

The underlying EOS literally treats all media as a linear block address, with each block being 1024 bytes.

So I basically need to do some byte finding to find 512 available bytes within the BIOS space.

-Thom
 
So two drives then I take it...

If you're going to install two, it may be possible to share the allocation vector table space as long as you're not accessing both at the same time and you trigger a rebuild of the table each time a different drive is selected.

I would have thought that you're probably not going to find 512 bytes of spare space in any CP/M BIOS I can think of, but the BIOS loads at DA00!!!!! That is a big BIOS!!! My BIOS loads in at FC00 in about 1k of space. Do you have a BIOS assembly listing and other CP/M files that you can customise and compile?
 
Well, if all you want to do is test to see if it's the issue, just place the allocation vector table in lower TPA memory... It will work just fine within the OS itself as long as you don't load in a big program - more than enough to quickly test if it's the only issue :) I have a habit of using 8000 for that kind of testing, since much CP/M software won't go that high... And you can always shim below the OS and reduce the TPA size and make such a strategy permanent.
 
You must log in or register to reply here.
Back
Top