Started by gertk, 13:58, 31 July 21
0 Members and 1 Guest are viewing this topic.
Quote from: GeoffB17 on 00:39, 01 August 21I'm trying to work out how JonB was able to work around the problem, and you are not.
QuoteThe 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.
QuoteMaybe 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
QuoteMaybe 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), ef0b6 fd 72 01 721 1738 ld (iy+1), df0b9 11 11 00 722 1739 ld de, 11hf0bc cd 98 f2 723 1740 call svc_alloc_tpaf0bf d2 59 f1 724 1741 jp nc, svc_d_hook_6f0c2 fd 75 10 725 1742 ld (iy+10h), lf0c5 fd 74 11 726 1743 ld (iy+11h), h
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 drivesnopnopnop
CD 76 F2 D2 37 F1 21 BA 12 00 00 00 CD 76 F2 D2 37 F1
21 BA 12 00 00 00
21 1F FF 00 00 00
Quote from: JohnElliott on 23:09, 03 August 21This probably isn't related to your main issue, but Code Select Expand21 BA 12 00 00 00doesn't look right to me. The DPB should have been allocated in common memory, so it should be something like Code Select Expand21 1F FF 00 00 00
Quote from: JohnElliott on 22:51, 04 August 21Allocation 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.
Page created in 0.092 seconds with 39 queries.