CP/M BIOS setup

From: Richard Erlacher <richard(a)idcomm.com> BIOS or format Dont bother. I understand. I will even repeat it if you dont think so. WHAT I'M SAYING is "THAT DISK" if you do successfully do this will likely be the only one (or only ones like it) to work. THere are formats that resist and defy your assumptions. nor downloaded other been there done that and then some. I only retain masters, clearly marked copies and others. Much of the non commercial stuff is on the WC CP/M CDrom and there is my personal archive. AS I read disks I also convert them to a standard set of formats and over the years that has kept the accumulation of massive piles to a dull roar. content, Likely because they are ISIS, DD CP/M written on Intel (using M^2FM). Some of the soft sector controllers used USART in sync mode and have really odd formats that the 177x can munge. It was all the time. You haven't heard the why nots. a there, to If you dont understand the odd things of BIOS design you can't possibly understand how some of the truly strange formats result. resonable only I've done it a lot and it's not innate that I apply a lot of experience to doing what must be a black art to some. it's not. most of what you do will be highly biased by the controller, drive and CPU. given same Ah now we are getting to something far more practical. deblocking can easily be automated but your dealing with a BIOS and the automation has to be incorperated at build time. IE: the BIOS has to be built to permit adding MODULES that do functions with standardized interfaces so adding a floppy or hard disk is easier. Of course somethings can be handled easier if you have memory to burn. For example if you have 4k of ram you can copy as many sectors as will fit regardless of their physical size and the code will figure out how to accomodate the geometry by calculation. In the end you will be reproducing a PC bios without plug and play and limited to SCSI and IDE drives (not so bad) as they are the only ones that can be queried directly for geometry or better yet addressed as blocks. Older non IDE controllers are harder as their register or parameter passing schemes are a PITA. Examples of controllers that are awkard and different from each other in some or many ways. Teltek S100, basically two addresses with a packet messaging interface. requires a drive specific setup based on geometry and other low level drive specific functions. It will also deblock for you if you pass logical sector info. Compupro Disk 3A S100, DMA interface to ram, local z80 for processing and has involved setup. requires a Buffer space in ram of sector size minimum, system has to deblock. WD1002-HDO (host interface) like the others requires drive specific setup and does not deblock. Interface differs. local sector buffer only WD1002-wxa ISA-8 Not like WD1002-HDO but does have setup requiremnts and also deblocking is not done. has local sector buffer only. SCSI --> host board is like the WD1002hdo save you now have to deal with the SCSI layer. SCSI --> SCSI drive (over 40-50mb) block addressed at 512byte sector level, supplies geometry on query, larger drive have cache. IDE (larger than 40-50mb class) caching or at least sector buffers, respond to geometry query on most. Interface on later designs have variable geometry and block mode addressing to simplify matters. Likely the easiest and most consistant to interface. Thats a can of worms and worrying the right deblock, alloc or directory size are the most trivial of problems to work out. Now if you want ot make interfacing them easy and faster build the bios so that it KNOWS NOTHING about the disk save for a generic idea of a 8mb hard disk. dpblk1: DEFW 256 ; SPT pass a ALLOC size chunk DEFB 5 ; BSH Values for 4k alloc DEFB 31 ; BLM blkmask DEFB 3 ; EXM extent msk DEFW 2047 ; DSM disk size in blocks (4k) -1 (8mb) DEFB 512 ; DRM allocated directory entries (512 8k files =4mb) DEFB 11110000b ; directory alloc DEFB 00000000b ; byte 2 DEFW 00 ; check size (fixed disk) DEFW 0 ; track offset (do partitoning elsewhere) chk1: DEFS 0 alv1: DEFS 256 ; 2048 bits are needed to store alloc map for 8mb. dirbuf1: DEFS 128 this will pass as Setsector a binary value of 0-256 and in set track a binary value that is also in the range of 0-255. If these two are concatenated the result wil be a 16bit value that is the relative sector for a 8mb disk. If it is right shifted twice the result will be a block address (512byte) and a index to the correct 128 byte sector within the block. For a drive that can accept block (physical sector) addresses this will be all you need other than commands around it. To partition that likely large drive do some 24 or 32 bit math and add 65536(8mb partition) to it to find the start of the next partition. If the disk is only CHS addressing take that resulting 14bit block address and divide by # phys-sectors to get the sector wanted. Then divide the residue for the cylinder and head. For partitioning just add to the track number the required tracks to clear the 8mb space prior. For deblocking anything works and the floppy deblocker is used. There is no reason to deblock the hard disk seperatly from the floppy save for one thing, by keeping it seperate you will not slow the apparent floppy access due to thrashing. This is a consideration of available space (ram) and if banked ram is avalable it's a good place for it. DEBLOCKING IS caching at the physical sector level. so if you deblock groups of sectors of a total size that equals the ALLOC size you will get performance. the BDOS does directory access minimally at the alloc level, a single read captures an alloc address so your committed access is alloc/128 sectors. If the sectors happen to be sequential on the media so much the better(there is a hint there about interleave). All you need is space. If your doing that make SPT equal to ALLOC (32 for 4k) and just read the block starting at the address passed as track and use sector as the index as the index into the deblock buffer. Works better for floppies if you buffer and deblock whole tracks. Allison