Hi Jeremy, kind of generic subject line but a nice question :-). > For some projects I would like to work on I need to modify the kernel to > not overwrite certain sections of memory at startup...
In general, you can modify the load segment (using the SYS option, editing the EXEFLAT options in the "makefile" for the kernel, editing the #define DOS_PSP 0x0060 line. Those 3 SHOULD be enough, but we saw some spurious bytes getting modified in the first 64k when we tested that method to get FreeDOS to boot on Sanyo / Tandy style computers ;-)). Still it kind of worked. So for Tandy, the load segment is 0x1000, and FreeDOS leaves the first 64k of RAM alone (apart from interrupt table, 40:xx and 50:xx of course). > The specific items are boot time support for non-FAT filesystems... ... > The other item I'd like to eventually get to (probably sometime after I > fix ATAPICDD, so a year or two down the road) is a replacement for the > BIOS int 13h. How does the ontrack and such software work so DOS > doesn't overwrite them? Well THAT is usually done by decrementing the 40:13 word to tell your DOS that you have less than 640k installed. This method is also used to allocate space for the EBDA (40:xx extensions), by MEMDISK of SYS- LINUX / ISOLINUX, by some malware, by OnTrack, EzDrive, and so on :-). And talking about your int 13 plans: It would be REALLY fancy to have a version of UDMA2 which can be loaded BEFORE the kernel. Remember that UDMA2 supports CHS and LBA disk access (functions 2, 3, 42, 43 of int 13) to disks with up to 2 TB size even on a BIOS which has a limit of for example 32 GB disk size as long as UDMA2 is able to get the real disk size from somewhere. Pre-LBA BIOSes are usually not suitable for use with UDMA2 because it has to query EDD information to find the UDMA chipset. Still the UDMA2 driver can also work in classic DMA mode so you could modify it to work even with pre-LBA BIOSes (in conjuction with reading the disk size directly from the disk and then overriding the disk-size-query related BIOS functions by functions provided by UDMA2 itself). Sorry for getting a bit technical on this. I think the actual pre-boot UDMA2 driver would be easier to make than you may have thought. Eric PS: I noticed that UDMA2 hangs the (dpmi16bi as far as I remember) game RAPTOR. None of the "obvious" command line option combinations for UDMA2 2.7 worked to solve the problem. Suggestions welcome. PPS: UDMA2 normally redirects access to the BIOS when it hits non-aligned buffers and has no UDMA-XMS buffer around. In other words, you would either need "XMS" for the pre-boot UDMA2 driver (MEMDISK is a good example for that) or you would need a buffer in the first 640kb and some UDMA2 modifications to use that buffer to make sure that the real BIOS never has to deal with disk access (because we assume that the real BIOS cannot deal with the big disks which forced you to use pre-boot-UDMA2...). Note that classic-DMA mode cannot use buffers in XMS space. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Freedos-kernel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
