CP/M BIOS setup

be about That I have a fully documented CCS and it clasifies as the early basic CP/M bios of low to average functionality. It's robust but closer to a minimal example. to Not all and they may be very hard to find. DPH, DPB ahve pointers to them as a result of the BIOS call to Seldisk. The SKEW however may not be used in the SECTRAN call at all! Often the skew translate is a table but it can be calculated and for DD the SECTRAN call is applied at the logical sector level and doesn't apply well for double density who have sector sizes larger than one logical sector. So skew in that case will likely be burried in the raw read/write routine. Or possibly even at the logical sector level inside the the physical sector. So wome things are not guarenteed and also not easily found. to Oh like I said I can be... but if you know it's easier as even with 33mhz z180 your going to flog a while getting to the same answer. skew, The Ah, no. Most boot sectors are not skewed and like you observed may not be the same density or sector size. diskettes, Likely but not always true. There were patches and the CP/M version can be misleading. Many of the clones use base 2.2 ID so apps will run normally, most all are written using z80 unique instructions where DRI used only 8080. automatically, we beginning, BDOS is not part of the CP/M file system! It's in the boot tracks. file directory You would be forced to do that and huristically that will be a PITA! PIP is in the file system whereas BDOS is out on the boot tracks. the boot tracks in the CCS case is SSSD and the system tracks can be DSDD! The bios entries for DPH, DPB do not say if the disk is DSDD or even if it's floppy. It will tell you how many logical sectors per track, If skew is used. If directory is checked, allocation size and the size of the area used ofr data storage. You will have to figure out from that a lot of things that are variable and can still end up as the same answer. hard it's been done but the usual is to hook the disk IO routine and lod a mini hard disk bios in high memory. Teltek, Konan and a few others did that. A better way is to provide slots that can be filled with an address of the driver(s). The reason for the difficulty is the wide assortment of controllers and the varied protocals to talk to them. If it was always IDE or SCSI it would be simpler. determine to No folklore. There are detailed tables out there for every drive and disk going if one care to look. What do you think Multidisk does/is? come Optimal ones for hard disk in the timeframe they wrote in was simple. hard disks are FAST and Z80s (pre 1990) are NOT. No amount of optimization is possible. Actually if you have banked memory caching is the solution as it steps neatly around the problems. FYI: the problem is that CP/M does a lot of realatively small transfer with lots of references to the directory. the true limiter to performance is not data rate but latency (mostly from shuffling the head). When Laird wrote a fast drive was a Quantum D540(31mb MFM 5.25 FH) with a average latency of around 30mS. recreate No. the boot tracks are always written by a specialized utility like SYSGEN (which is not generic code) that is always system specific. the Most of those I converse with with that set of questions have no sources to work from and find 8080 or Z80 asm code scary to terrifying. Often they dont know the ports in use nor what they mean. Rare is the one with Docs for their system at the time the question is launched. They often think it's just like a PC where dos boots on all if the disk fits. it Like Laird said and I'll say _optimal_ for what? I"d never use the word optimal. Again, expereince most want a drop in replacement like a PC. Most do not code at that level or dont wish to try. Many dont have docs needed. So what they want is not optimal, just something that works. myself, so to Lesse, I have five systems with hard disks all were added later two with code supplied. I find peace with the fact that they work and are reliable. Only one have I applied rigorous and experimental methods to the extreme to see what was possible and effective... Occams razor won most often. Here it is: hard disks and performance. Assume nothing about the hard disk used rare is the old drive/controller that can really help you. DMA or a seperate processor will help if the CPU is loaded or memory is short. Caching at the track or cylinder level with a LRU method really helps if you have space (64-128k is good). You will cache(call it host buffer if you like) anyway as most hard disk have sector sizes larger than 128 bytes requireing deblocking. Caching the directory seperate from the data area cache really pays as it saves head thrashing. Achieve the above or subset with direct and efficient code. I've tried this using a IDE drive (still working the code out) and most decent over 100mb drive have caching (quantum PRO AT series does). use it as it isolates you from things like skew and all. If you using a an old SA4000, forget all this as making it work is three quarters the battle. Allison