PDA

View Full Version : Detecting and setting disk formats in CP/M Plus



Alphasite
February 27th, 2018, 06:17 PM
For my TRS-80 Model 4 CP/M Plus I have five disk formats (SSDD, DSDD, SSQD, DSQD, and DS 255-track fake floppy for the HxC and emulators).

The tracks all have eighteen 256-byte sectors*. The bootstrap is in sector 1. I then have sectors 2 and 3 dedicated to the system configuration data. CPMLDR fits in sectors 4 through 17. This means the bootstrap can just load all of track 0 into memory and then jump to CPMLDR at the load address+300H.

The bootstrap is only 114 bytes so there's plenty of room in sector 1. What I'm thinking of doing is making the first three bytes of the bootstrap a dummy instruction string like 21 XX 00 where XX is the drive type flag and the next byte is 00 for now just in case I decide to expand later.

This way I could use the disk login routine to read track 0 sector 1 and update the dph for the drive.

Does anyone see any problem with this? Is there any reason I couldn't use one of the buffers pointed to by the dtabcb for the drive to store the sector so I could just use the BIOS sector read routine to load sector 1?

The alternative would be to just distribute a set of floppies in the SSDD format and then have people build a new CPM3.SYS with their desired drive configuration and then use the disk formatter and COPYSYS to make a new boot floppy.



*I was using five 1K sectors but the Model 4P assumes a disk with 512-byte or higher track 0 sector 1 is a Model III-mode OS and insists on loading the ROM image. You are supposed to be able to hit "N" and bypass the ROM image load but there's a bug in the boot ROM and it doesn't work. I patched the ROM on my 4P but since I'm going to release this I don't think it's reasonable to expect other people to do this. I could do what Radio Shack did for their CP/M Plus and have just track 0 with 256-byte sectors but I'd prefer to have all the tracks the same to simplify disk format and copy.

durgadas311
February 27th, 2018, 06:48 PM
Does anyone see any problem with this? Is there any reason I couldn't use one of the buffers pointed to by the dtabcb for the drive to store the sector so I could just use the BIOS sector read routine to load sector 1?


The buffers you provide to BDOS3 can't really be used in the BIOS arbitrarily. BDOS "owns" them once it starts. You could use them at cold boot time (before initializing BDOS), but not after that. Since you'll need to check disk format at SELDSK time, BDOS is already managing the buffers. You'd have to implement the same scheme as the BDOS to manage the buffers in co-operation (non-conflicting) with the BDOS.

Alphasite
February 27th, 2018, 07:42 PM
The buffers you provide to BDOS3 can't really be used in the BIOS arbitrarily. BDOS "owns" them once it starts. You could use them at cold boot time (before initializing BDOS), but not after that. Since you'll need to check disk format at SELDSK time, BDOS is already managing the buffers. You'd have to implement the same scheme as the BDOS to manage the buffers in co-operation (non-conflicting) with the BDOS.

Okay, thanks. I was hoping that CP/M wouldn't have any valid data in the buffers if it was calling the login routine for the drive since the login routine is only called the first time SELDSK is called for the drive (from the sample BIOS source comments):

;seldsk
;select disk drive. drive code in <c>.
;invoke login procedure for drive
;if this is first select. return
;address of disk parameter header in <hl>

SELDSK calls the login routine and according to the sample BIOS source comments that's where the disk format should be checked:

; This entry is called when a logical drive is about to
; be logged into for the purpose of density determination.

; It may adjust the parameters contained in the disk
; parameter header pointed at by <DE>

I think I can allocate the buffer for the read in banked memory. I'll give it a shot and see.

durgadas311
February 27th, 2018, 11:16 PM
I think I can allocate the buffer for the read in banked memory. I'll give it a shot and see.

Yes, that should work. CP/M 3 allows directory buffers to be in bank 0 since only the BDOS will be accessing them (from bank 0). The same would hold for this buffer. The reason data buffers must be in common memory is because they need to be copied to/from the user space in bank 1.

Alphasite
March 4th, 2018, 06:53 PM
Okay, my first try corrupted the system. I've looked at the Visual 1050 CP/M Plus source code and it seems that @rdrv has the drive. I also know that DE has a pointer to the XDPH. Can I overwrite the following parameters to call fd$read directly:

; relative drive number in @rdrv (8 bits)
; absolute drive number in @adrv (8 bits)
; disk transfer address in @dma (16 bits)
; disk transfer bank in @dbnk (8 bits)
; disk track address in @trk (16 bits)
; disk sector address in @sect (16 bits)
; pointer to XDPH in <DE>

Chuck(G)
March 4th, 2018, 08:04 PM
So what do you do about reading disks that you didn't make?

I count at least 25 different 5.25" CP/M formats for the TRS-80. There were lots of system variations. I can produce samples for each.

Alphasite
March 4th, 2018, 08:32 PM
So what do you do about reading disks that you didn't make?

I count at least 25 different 5.25" CP/M formats for the TRS-80. There were lots of system variations. I can produce samples for each.

If it's not one of the four I have defined and that can be formatted with the disk utility then I'll leave the XDPH for the drive alone.

For foreign formats I have drive E which can be defined to whatever you want via a config program. I took that idea from the Ampro my friend had at the time.