From writing a BIOS, I can't think of any way the BIOS directly supports additional drives - there are a few complexities, such as the vector tables that track drive usage and the space in the BIOS that is set aside for the Disk Parameter Headers and the Disk Parameter Block - so unless there's spaces in the BIOS for these already, you'll need to add them into the "Driver" and I imagine the easiest way to address an additional drive would be a "shim" that intercepts calls to the BDOS at 0005, or otherwise the jump table for the BIOS where the BIOS starts.
Once you intercept and shim the entry point, you can check if the current disk is one that you're responsible for, and add in your own handler, then you can process the disk calls however you want and write in your own DPB and DPH and Usage tables, etc. Keep in mind that if you intercept the BDOS calls, you only need to intercept one address, and if you intercept the BIOS you will have to intercept all of the relevant calls.
There should be some code for RAMDISKS that exists already - I recall seeing some examples in the Amstrad disks I have, and it might be easier to begin with that code, and to then write in your own access routines, rather than using their memory paged routines to existing RAM.
Given what you've already approached Myke, I think you'd find writing your own BIOS shim pretty achievable.
The main things you need at the Disk Parameter Header, which tells how to find the Disk Parameter Block.
The Disk Parameter Block addresses the issues of heads, sectors, block sizes etc. It's pretty well documented.
if you do that much, you might be able to use a bios directly. The main challenge is that things like the Allocation Vector Table are sized based on your disk, and can get pretty big if your allocations are too small, and your drive is fairly large - It uses a byte for every 8 allocations, and if you have a lot of allocations ( let's assume you have 128 byte sectors, and you use 8 of them in an allocation, that means the AV table is 64 bytes long and needs to be held somewhere and you need a gap for it in the BIOS or elsewhere, along with similar tables for every other drive on your machine ). Probably the easiest way is to include this stuff in gaps in your driver code.
Also, there are ways to avoid this entirely and use your own format too, especially if you intercept the call at 0005 instead of the BIOS jump table.
Also there are Sector Translation tables to add in.
Here's examples of mine.
DW TRANS0 ; Put in label for vector here if translation table. 00=no translate - Same as L: drive
DW 00 ; Scratchpad.
DW 00 ; Scratchpad.
DW 00 ; Scratchpad.
DW DIRBF ; 128 byte scratchpad buffer for file directory. ( used by BDOS )
DW DPBLOKI ; Disk Parameter Block.
DW 00 ;
DW ALL00 ;
TRANS0:
DB 0,1,2,3
DB 4,5,6,7
DB 8,9,10,11
DB 12,13,14,15
DB 16,17,18,19
DB 20,21,22,23
DB 24,25,26,27
DB 28,29,30,31 ; This gives us a clean sector number starting with 0.
DPBLK: ; Standard to all disks. ( can be different ) This is where I remember what the DPB parameters are .
DW $20 ; Sectors per track. ie, 0 to 31.
DB 3 ; BSF Block Shift Factor - 3 bits over Bit6 ( Bit6 = 128 = allocation ). Bit7 = 256., Bit 8=512 and Bit9 is 1024 ( 0 to 1023 ). Number of bits past Bit6.
DB 7 ; BLM Block Mask - Related directly to the above. =2^BSF-1... 7 is a 3 bit mask, so BSF must be 3.
DB 0 ; EXM - Extent Mask -
DW 242 ; DSM - Disk size -1 - ie, 242= 243 BLOCKS. if the block size=1024k then 248,832 bytes on disk. Block=Allocation Unit.
DW 63 ; DRM - Directory Max - Directory Entries = 64 entries. If 1024K allocation holds 32 directory entries then this means 2 allocations for directory.
DB %11000000 ;AL0 - Alloc 0 = 192, but WATCH THE BITS. Why the heck they did this I do not know. One bit for each allocation.
DB %00000000 ;AL1 - Alloc 1 - If all 16 bits are set, then it means 16 directory allocations... MAX... Why did they not just use a number here?
DW 16 ; CKS - Check size = (DRM+1) /4 for removable media. = 64/4 = 16... In this case, If fixed then DRM=0 = Do not check directory records - Not sure why.
DW 02 ; OFF - Track Offset. Skipped tracks = Added to SETTRK when called. Can be used for partitioning a big disk into smaller disks. 2 = 2 system tracks.
DPBLOKI: ; Two bytes per allocation disk
DW $20 ; 00,01 ; L drive is 32 sectors per track - DISK 11! 128 byte "sectors" = records
DB 4 ; 02 ; 4 and 15(next ) = 128 byte sectors, 2048K allocations (blocks) = 2^4 x 128 blocks.
DB 15 ; 03 ; See above. 4 bit mask.
DB 1 ; 04 ; Extent mask. Blocks are 2K, so should be 1.
DW 316 ; 05,06 ; This has 316 2K blocks. ( Allocation = 1 K ). Would be a 720k disk.
DW 127 ; 07,08 ; 4 x 2k directory allocation = 128 file extents max. (128 total ) I think my format might be a little off though.
DB %11110000 ;09 ; Only set 4 bits so we know 4 allocation is directory
DB %00000000 ;0A
DW 0 ; 0B,0C ; Might be necessary to make as 0 for fixed.
DW 1 ; 0D,0E ; 1 track offset. This gives 2K for boot of BDOS and to load the CCP and other files. Enough.
MARKER1: DB '>'
ALL00: BLOCK 64 ; Allocation Vector reservation for drive 0 64 bytes. I won't use all of this for a 720 drive with 2K allocation.
MARKER2: DB '<'
edit: Noted my documentation was a bit incorrect so edited some and added in my notes section. This was because as I progressed with my emulator I wanted more disk space so I kept "expanding" my disk... Was original 32K, then 64K, now it's about 512K, so the DPBLOKI parameters are probably correct for your RAMDISK even though the comments are wrong. I need to pay more attention to my documentation.
