Hi Jim,
> define "nonsense sector sizes"
> there are new large sector drives coming out,
> where 1k sectors, 2k sectors, and 4k sector sizes are not uncommon.
At the moment, FreeDOS only supports 512 bytes. I know of
no drives which have sectors above 8 kB sector size and
there are no drives where sector size is not a power of
two. In particular, sector size 0 is typical nonsense...
For a simple test, I would say 512 is fine, 512-8192 is
okay and everything else means that your int 21.7303 did
probably not work correctly, either for that drive or in
general for any reason, such as FAT32 support not present
or switched off or not compatible with a drive/ramdisk...
Of course DOS / Windows can still try to give you useful
results even then, but if it cannot even decide that the
sector size is between 512 and 8k, you should better give
good old int 21.36 a try for the drive in question ;-)
Make sure you wipe the buffer before calling int 21.7303
so you can tell the difference between nonsense results
and results left over from something else.
> I need a freedos box. (maybe I should wipe it again?).
You can also start FreeDOS from USB flash stick, CD or DVD
using for example syslinux, isolinux or maybe grub4dos :-)
I was even able to start it from SD cards in cardreaders,
even external ones. Laptops with built-in SD reader, too.
> extFAT32FreeSpaceStructure *pds = (extFAT32FreeSpaceStructure
> *)calloc(sizeof(extFAT32FreeSpaceStructure), 1);
Nice moment for wiping would be after that.
> char * str = (char *)calloc(strlen("c:\\")+1, 1);
> str[0]='A'+drive;
> str[1]=':';
> str[2]='\\';
> str[3]='\0';
There are probably more elegant ways for this...
> dosmemput(str, strlen(str)+1,
> _go32_info_block.linear_address_of_transfer_buffer + 48);
...
Apparently you use DJGPP. This has magic int21 call
helpers, so you can probably avoid dpmi_int and go32.
Please read the documentation about int86, int86regs,
int86x and similar. Much easier than manual DPMI and
of course much less error prone - unless of course
you manage to find an int21 call for which DJGPP is
not aware of the correct magic (e.g. 21h.33ffh ;-))
Another nice thing is:
#define peek(sg, f) _farpeekw( _dos_ds, ((uint32)(sg)<<4)+(f) )
#define peekb(sg, f) _farpeekb( _dos_ds, ((uint32)(sg)<<4)+(f) )
#define poke(sg, f, v) _farpokew( _dos_ds, ((uint32)(sg)<<4)+(f), (v) )
#define pokeb(sg, f, v) _farpokeb( _dos_ds, ((uint32)(sg)<<4)+(f), (v) )
Also, I think DJGPP has some generic data exchange
buffer which you can use for smaller tasks, so you
do not have to allocate manually even if you do not
use the magic int86 / int86x calls although those,
as said, make your life much easier anyway :-).
Regards, Eric
PS: In general, DPMI stuff is easier than Go32:
__dpmi_regs r;
int size = 512;
int segV = __dpmi_allocate_dos_memory(size/16, &selV);
r.x.ax = 0x4f00; /* vesa info */
r.x.es = segV; /* buffer segment */
r.x.di = 0; /* buffer offset */
pokeb(segV, 0, 'V');
pokeb(segV, 1, 'B');
pokeb(segV, 2, 'E');
pokeb(segV, 3, '2');
__dpmi_int(0x10, &r); /* video BIOS */
if (r.x.ax == 0x004f) {
...
_movedatab(selV, 0, _my_ds(), (uint32)&mybuffer[0], sizeof(mybuffer));
... display VESA info ...
}
__dpmi_free_dos_memory(selV);
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
