Running on DR-DOS v7.03, the int 25h call zeroes di leading to a crash
here when di is expected to preserve the stack pointer. So push di twice
and pop it twice. The second pop always gets the saved sp, regardless of
whether int 21h or int 25h/26h are used.
Refer to https://github.com/SvarDOS/edrdos/issues/57#issuecomment-2119360035
getbpb now returns 0 instead of S_DONE in case of an uninitialized
partition, copying the default BPB into the BPB.
The previous return of S_DONE in case of uninitialized partitions
resulted in rp->r_bpptr not getting set in bldbpb. This in
combination with indicating success resulted in garbage returned
via rp->r_bpptr.
The DPB values are now being set to the default BPB ones in media_check
ea951d8136/kernel/fatfs.c (L1728)
via call to bpb_to_dpb in case of an uninitialized partition.
This may have side effects. But because DF_NOACCESS is still set, I
think it is the right way to do it.
The commit also masks high bit of AL for INT25/26 containing the drive
number. Some programs may set the bit according to RBIL:
"examination of CPWIN386.CPL indicates that if this call fails with
error 0408h on an old-style (<32M) call, one should retry the
call with the high bit of the drive number in AL set"
Leaving the bit set may render the given drive number unusable.
It should do no harm to mask it to increase the chance of the operation
to succeed. Also, the AH should be set to zero, because drive is given
only in AL.
When country was converted to a submodule (by me) the production
installation target was hacked onto the kernel subdirectory Makefile
which wasn't ideal. Introduce a production target into the country
Makefile that does the installation. Since we want the submodule to be
buildable standalone, we can't include the variable definitions from the
upper level, such as $(DIRSEP) and $(CP), so the caller has to pass those
in at build time if using the production target.
Tested on Linux (GCC + Watcom) and DOS (Watcom)
1/ Watcom 1.9
a) Kernel and other directories building fine
b) Share doesn't support Watcom for TSR.
2/ Turbo C 2.01
a) Kernel build needs some functions that are missing.
b) Sys not building for the same reason,
c) Share building nicely.
d) Need to figure out how to get tc201 compiler to Github Actions
3/ IA16-GCC
a) not currently supported by build.bat so commented out
1FE0h:2200h happens to be linear 22000h. Like the memory map
update to the FAT32 loaders for #127 this allows to load a
file of up to 128 KiB (rounded to cluster size) with an /L
parameter for SYS of up to 0x200.
