Don't think so. I think you can imgmount a floppy image *before* booting from a HD-image, and then the floppy-image will be accessible after boot.

Yes, unfortunaly that is only true for imgmounts, not for non-images (like real floppys or directorys)

Remco

remcohn wrote:

Yes, unfortunaly that is only true for imgmounts, not for non-images (like real floppys or directorys)

Remco

then create an image from real floppies

yes, unfortunaly, i need to read and write data from real floppys regularly in my application. isnt there any way to get this working? just with real floppys?

remco

Why do you need to boot into a different dos?

yeah, remco,
frankly I'm afraid I didn't really grasp the precise scope of your problem.

I have a windows 3.11 program, written in FoxPro. When its run in a normal dosbox enviroment, it complains that there is not enough diskspace free. This is the case with either a directory-emulated C drive, or a imgmount C drive.
The only way i was able to solve this problem was by booting a 'real' dos enviroment, with a real command.com and stuff. Then the program runs perfectly in win 3.11.
But when i boot (`boot -l c`) i lose all my non-imgmount drives, like my real floppy drive. And the whole purpose of the program is to read data from a floppy, process it, and write something back.
I understand i can imgmount a floppy, and write images back and forth in windows, but that would take WAY too much time.

thanks for your time,
Remco

freesize didn't help ?

mount C \blah\blah\blah -freesize nnnnnn

No, fortunately not. Not even a imgmount c drive (with everything including 'TEMP' pointing to the C drive).
Looks like it uses some 'funny' non-standard calls to determinate the free space, which only works with a real dos environment.

Remco

currently only works with a real dos env 😉
We are always looking for those kind of bugs to improve the compatibility of DOSBox.

Have you run it in the debugger version of dosbox (see dev forum) to see if some big warning pops up on an unhandled call ?

How can i enable logging in the debug version? most of the stuff i see a "CPU:Illegal/Unhandles opcode 63", but that starts the moment i start windows 3.11

Remco

create a new configfile using that build
then there is an option logfile in there.

Found the interesting part i think:
60727970: CPU:Illegal/Unhandled opcode 63
60727981: CPU:Illegal/Unhandled opcode 63
60727994: FILES:file create attributes 0 file C:\APW\00737346.TMP
60727995: CPU:Illegal/Unhandled opcode 63
60728004: DOSMISC:DOS:Unhandled call 68 al=66. Set al to default of 0
60728005: CPU:Illegal/Unhandled opcode 63
60728028: CPU:Illegal/Unhandled opcode 63
60728034: CPU:Illegal/Unhandled opcode 63
60728052: CPU:Illegal/Unhandled opcode 63
60728058: CPU:Illegal/Unhandled opcode 63
60728069: CPU:Illegal/Unhandled opcode 63
60728082: FILES:file create attributes 0 file C:\APW\00737347.TMP
60728083: CPU:Illegal/Unhandled opcode 63
60728093: CPU:Illegal/Unhandled opcode 63

Remco

hm, found some more unhandles calls:
60714866: CPU:Illegal/Unhandled opcode 63
60714883: FILES:Special file open command 80 file C:\APW\FOXW2500.ESL
60714884: CPU:Illegal/Unhandled opcode 63
60714893: DOSMISC:DOS:Unhandled call 5C al=00. Set al to default of 0
60714894: CPU:Illegal/Unhandled opcode 63
60714902: DOSMISC:DOS:Unhandled call 5C al=01. Set al to default of 0
60714903: CPU:Illegal/Unhandled opcode 63

but the error in the program is about the temp file in my post above

Remco

ah yes. could you for completeness sake attach the full log as well.

I hope you dont mind a zip file, the unzipped file is 400k.

Remco

call 68:
http://www.delorie.com/djgpp/doc/rbinter/id/83/31.html
DOSBox clears the cf. but we don't check if handle in bx is valid.

call 5c:
http://www.delorie.com/djgpp/doc/rbinter/id/28/30.html
we only change al to 0. We possible could give an errorcode and raise carry flag.

so both shouldn't be a problem?