[Freemint-list] Load MINT.CNF at odd address

[Thorsten Otto]

On Monday 20 March 2017 15:51:00 Markus Fröschle wrote:
> All OS disk I/O functions, no matter if they are BIOS, GEMDOS or XBIOS,
> have void * parameters for the buffer address and no documented alignment
> requirements, so all these functions should be able to deal with unaligned
> buffers, IMHO.

Sure, it is not documented, but at least at the BIOS level that does not make 
much sense. I could imagine that there are other harddisk drivers that also 
have problems with this. Also, while looking at cnf.c, i can't see any 
indication that the first byte of the buffer is ever accessed, for unget 
reasons or whatever. At least it is not initialized when allocating the 
buffer. So i would think that it is just superflous, maybe some relict of an 
older version of the functions. And even if it is needed, it could easily be 
fixed there by allocating 1 byte more and setting inf->src to buf + 2.

>I guess we should rather have a look into the EmuTOS IDE driver instead (I'd 
>assume the ACSI driver shouldn't have this problem as it reads byte-wise 
>anyway).

If you are going to support that in EmuTOS, it might be better to handle that 
in blkdev.c rather than in each indiviual driver. The problem that i see is 
that you would need a static temporary buffer for copying the data, and it 
must be large enough to hold the largest supported  physical sector size. 
Doing Malloc() from a bios or driver function might not be an option. Or 
alternatively, reuse some other buffer that is garantueed to be not needed at 
this time, and do the copy in 512byte chunks.