Quote from: GeoffB17 on 00:39, 01 August 21Hi Geoff,
I'm trying to work out how JonB was able to work around the problem, and you are not.
QuoteAh, yes I think I can figure out how he did it. Instead of telling the OS there is an offset he probably just stores the offset himself and re-use the existing DPB (and maybe even DPH, not sure how to do that).Upon a read or write sector request you can then simply use the self-stored track offset for that drive. Hmm..
The problem relates to the fact (as I understand things) that while CP/M provides space for 16 drives, and each space in this table points to a data structure (the info I have refers to the DPH, but it could be the DPB, but one of these points to the other anyway ?) but there is only so much space available for these structures. JonB was hitting this limit too. I was pestering him re 'Why CAN'T you use ALL the drives', when John Elliott suggested that it was possible that if the drives were the same then you could repeat the pointer in the table - and this proved to work.
QuoteCPM 3 should be able to handle 32 MB (and it seems it does, CPM 2.2 could only manage 8 MB)
Maybe the difference relates to what you say about your 'drives'?
In JonB's case, he has partitioned his 128Mb DOM as 13 @ 8Mb drives (devices). His package includes a 'format' program to do a format of all the drives. The 8Mb format is I understand a standard CP/M option. So his system does not need any messing with offsets, etc. Therefore his devices CAN all use the same DPB/DPH.
You are using a different system. i.e. the 32Mb capacity for each drive (what does this do regarding the block size, # extents, directory entries I wonder?
; disk parameter block for 32 MByte starting at cylinder 1 (0 = reserved for future use)
; block size is 4096 bytes
; with 2048 directory entries we need 2048 x 32 = 65536 bytes space
; which would need 16 blocks of 4096 bytes hence all 16 bits of
; AL0 and AL1 are set.
; by using 1024 (128 byte) sectors per track we really get 256 physical sectors
; (of 512 bytes) per track. So the physical sector number can be directly used
; as the lower 8 bits of the LBA. The total number of tracks is also 256.
; By using an offset it would be possible to enable more CPM 'drives' on the same
; IDE drive by setting this offset.
idedpb:
defw 1024 ; SPT (in 128 byte sectors)
defb 5 ; BSH
defb 31 ; BLM
defb 1 ; EXM
defw 8191 ; DSM total number of blocks
defw 2047 ; # of directory entries
defb 0ffh ; AL0 bitmap (16 bits/blocks needed)
defb 0ffh ; AL1 bitmap
defw 8000h ; CKS fixed drive, no dir check
ideoffs: defw 1 ; OFF offset from drive start
defb 2 ; PSH for 512 bytes physical sectors
defb 3 ; PHM mask for 512 byte physical sectors
QuoteThe DOM is 128 MB but has only 256000 sectors (available) so not really 128 MB (guess there are some spare/reserved sectors). That is why I now have declared only 3 identical 32 MB parts
Maybe this is causing your problem? Can you maybe pre-format your DOM as (I assume) 4 identical devices, each using the same DPB/DPH?
f0b3 fd 73 00 720 1737 ld (iy+0), e
f0b6 fd 72 01 721 1738 ld (iy+1), d
f0b9 11 11 00 722 1739 ld de, 11h
f0bc cd 98 f2 723 1740 call svc_alloc_tpa
f0bf d2 59 f1 724 1741 jp nc, svc_d_hook_6
f0c2 fd 75 10 725 1742 ld (iy+10h), l
f0c5 fd 74 11 726 1743 ld (iy+11h), h
So you search for something like FD 75 10 FD 74 11 in the area of code after the SVC_D_HOOK entry point, back up the six bytes before that sequence, and replace them with 21 dpb_low dpb_high 00 00 00. Call SVC_D_HOOK for all the other drives you want to allocate, and then reinstate the original six bytes.SVC_D_HOOK starts at:
F05C: DD E5 DD 21 02 00 DD 39 FD E5 E5 D5 CD 49 F1 E5
F06C: 3E 02 D2 42 F1 11 1D 00 CD 7A F2 D2 40 F1 E5 FD
F07C: E1 54 5D 13 36 00 C5 01 1C 00 ED B0 C1 FD 70 02
F08C: DD 5E F8 DD 56 F9
F092: FD 73 00 FD 72 01 11 11 00
code to patch:
F09B: CD 76 F2 D2 37 F1
F0A1: FD 75 10 FD 74 11
Bytes to be replaced after first SVC_D_HOOK call start at
SVC_D_HOOK + $3F (here $F09B)
Patchcode:
ld hl,idedpb ; my IDE DPB for all drives
nop
nop
nop
To confirm the patch is in place I send the 6 bytes in hex over the serial port to the laptop, first the 6 original bytes, then the patched bytes and finally after the calls have been made the restored bytes. They look fine.CD 76 F2 D2 37 F1 21 BA 12 00 00 00 CD 76 F2 D2 37 F121 BA 12 00 00 0021 1F FF 00 00 00Quote from: JohnElliott on 23:09, 03 August 21Ah yes, I see where that goes wrong. I should have used the first IX pointed address (where I copy my idedpb to), it now uses the idedpb in my FID. Will try again this evening.
This probably isn't related to your main issue, butCode Select21 BA 12 00 00 00
doesn't look right to me. The DPB should have been allocated in common memory, so it should be something likeCode Select21 1F FF 00 00 00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Quote from: JohnElliott on 22:51, 04 August 21Ah, so I am missing two bytes in the allocation vector space, will change that and use as much of the other calculations to make the whole DPB more configurable.
Allocation vectors have to be separate per drive, so can't be combined like a DPB. For a drive with 8192 blocks the size required is (8192 / 4) + 2 = 2050 bytes.
The calculations used to be online in the Spectrum +3 CP/M manual, but this seems to be a dead link at the moment so I'll copy-paste the relevant section.