mirror of
https://github.com/joncampbell123/dosbox-x.git
synced 2025-10-14 02:17:36 +08:00
61 lines
2.3 KiB
Plaintext
61 lines
2.3 KiB
Plaintext
One persistent issue in any MS-DOS HDD image I generate is that
|
|
I can never get BASIC.COM, BASICA.COM, and GWBASIC.EXE to run.
|
|
|
|
Even from the command line, it will always print "You cannot SHELL to basic".
|
|
|
|
It turns out from some investigation that BASIC/GWBASIC uses the byte
|
|
value at 0000:050F as a flag whether or not it is currently running.
|
|
|
|
If the flag value is nonzero, GWBASIC thinks it's already running and
|
|
prints the error message.
|
|
|
|
Problem is that for some reason, there is junk at 0000:0500-0000:05FF
|
|
that looks like the remnants of a directory listing, when booting
|
|
my disk images.
|
|
|
|
DOSBox-X does not write those byte values, which is why the same
|
|
executable runs just fine under the DOSBox-X DOS kernel.
|
|
|
|
If GWBASIC refuses to run when clearly it is not already running,
|
|
break into the debugger and type:
|
|
|
|
SM 0:50F 0
|
|
|
|
and hit enter. Resume emulation and BASIC/GWBASIC should then
|
|
run without complaint.
|
|
|
|
-------------------------------------------------------------------
|
|
|
|
Update:
|
|
|
|
The reason that GWBASIC has this problem appears to center around
|
|
some boot-time code in MS-DOS. At some point, the first sector of
|
|
the root directory is loaded to 0000:0500. MS-DOS leaves it there
|
|
after booting, where it is visible to any DOS program after boot.
|
|
|
|
GWBASIC uses byte value at 0000:050F to determine running.
|
|
|
|
So how is it able to run? Well, if 0000:0500 is a copy of the root
|
|
directory, then 050F is the 15th byte of the first directory entry.
|
|
|
|
In the original FAT filesystem design, bytes 14 and 15 were not used.
|
|
When MS-DOS prior to version 7 creates a directory entry, those
|
|
bytes are zero. On a bootable MS-DOS system, 0000:050F points to the
|
|
first directory entry byte offset 15 which is normally IO.SYS and
|
|
those bytes are zero.
|
|
|
|
Starting with MS-DOS 7.0 (Windows 95), Microsoft defined bytes 14
|
|
and 15 to carry the file creation time stamp. If IO.SYS has those
|
|
bytes set, and Windows 95 does not clear that area, then GWBASIC
|
|
will fail the same way.
|
|
|
|
The HDD images generated by my script were made using the Linux
|
|
mtools, which support long filenames and will set the file creation
|
|
timestamp as well. Therefore, files added by mtools (including the
|
|
IO.SYS file) will have nonzero bytes 14 and 15 and GWBASIC will
|
|
refuse to run.
|
|
|
|
The solution is for the script to zero those bytes after using
|
|
mtools to add IO.SYS, and GWBASIC will run.
|
|
|