Welcome!

Perhaps the original disks are copy protected?

Error message seems vague and not particularly representative of real conditions - What is file "mode", normally you access files
READ or WRITE (sometime READ/WRITE) - these typically cause a read or write error, and not reported tied to an executable
address in the program - I suspect this is an error generated by that program (but I don't know, I've never seen either the
program or that error)

Is the drive ifself bad (most likely dirty) - can you format/read/write other disks in the drive without problems?
Can you compare the the files you copied to the hard-drive with the original ones on the floppy and are any differences
reported?

For archiving floppy disks, and also testing floppy disk setups, I urge you to look at "ImageDisk".
You can get it from "Daves Old Computers" - IMD runs under DOS .. if you don't have a suitable DOS
system, there is also a bootable floppy image to run DOS/IMD standalone.

Thanks for your reply.

DaveDDS wrote on 2025-07-29, 21:39:

Perhaps the original disks are copy protected?

No, that's not it. The README file on the disk (that I was also still able to read) actually instructs you to copy the files from the disk to hard drive for better performance.
It was also not a commercially exploited game, it was one of those disks that was given away for free as a promotional thing.

DaveDDS wrote on 2025-07-29, 21:39:

Error message seems vague and not particularly representative of real conditions - What is file "mode", normally you access file […]
Show full quote

Error message seems vague and not particularly representative of real conditions - What is file "mode", normally you access files
READ or WRITE (sometime READ/WRITE) - these typically cause a read or write error, and not reported tied to an executable
address in the program - I suspect this is an error generated by that program (but I don't know, I've never seen either the
program or that error)

That's my idea as well. In it's compiled state I can spot this piece of text in the main executable:

1<<FMSG>>Device timeout Device fault Out of paper (Variable required 2FIELD overflow 4Bad file name or number 5File not found 6Bad file mode 7File already open 8FIELD statement active 9Device I/O error :File already exists ;

So it seems to be some kind of array with possible error codes related to the game files.

DaveDDS wrote on 2025-07-29, 21:39:

Is the drive ifself bad (most likely dirty) - can you format/read/write other disks in the drive without problems?
Can you compare the the files you copied to the hard-drive with the original ones on the floppy and are any differences
reported?

The drive itself is a brand new external TEAC FDD that I purchased just for this archival operation, since none seem to exist online anywhere. I am able to read other disks successfully with it, so I feel like the drive in itself is okay, but the problem is the specific floppy disk I'm trying to archive. When I try to copy files off of it, it also throws errors like this during the copy operation, that make me think it has bad sectors.

1The disk media is not recognized. It may not be formatted.

When I then eject the disk and manually "nudge" the tape inside a little by turning the little wheel on the back, I can usually get it to work on a second try.
But whether or not that yields a very trustworthy result, I'm not too sure.

File comparison is also hard for this same reason. After reading a few files, it often gets stuck in a read error loop (errors like "bad file descriptor").

DaveDDS wrote on 2025-07-29, 21:39:

For archiving floppy disks, and also testing floppy disk setups, I urge you to look at "ImageDisk".
You can get it from "Daves Old Computers" - IMD runs under DOS .. if you don't have a suitable DOS
system, there is also a bootable floppy image to run DOS/IMD standalone.

I'll have to look into this to see if this yields any better results, thanks!
But I think all signs point to the disk/data having degraded/corrupted over time. I hope some stuff might still be salvageable at all.

oldskool wrote on 2025-07-29, 22:56:

... File comparison is also hard for this same reason. After reading a few files, it often gets stuck in a read error loop (errors like "bad file descriptor").

You could read the files again, hopefully you could do this a few times, then see if the read copies match.

I'll have to look into this to see if this yields any better results, thanks!
But I think all signs point to the disk/data having degraded/corrupted over time. I hope some stuff might still be salvageable at all.

Among other things, you can make several attempts reading the disk with ImageDisk, then combine the reads to
"collect" sectors that may not have been read in some attempts.

ImageDisk will also read the whole disk without regard for files.. This means it won't be seeking around to access files one by one..
This might be easier on the media... If you are able to "collect" all the sectorsm you could then write the image back to a "fresh"
disk and then read from that!

Are there visible "marks" on the media?
Often when it degrades, media starts to "shed" tracks as they are read, causing visible streaks along the
head paths - keep a careful eye on this, if it is getting more pronounced as you try reads, be very careful.

Assuming you can try a few more times, here's some things that might help recover some sectors (which
ImageDisk can combine into a good image).

- Try reading on a few different (and clean) drives - slight variances in heads, pressure, alignment , read electronice
etc. can sometimes read on one but not another.

- Try slight alignment adjustments - this can help if it gets slightly closer to the factory writing drive alignment,
or slightly to the side of more serious corrupter track areas.

DaveDDS wrote on 2025-07-30, 01:15:

Are there visible "marks" on the media?
Often when it degrades, media starts to "shed" tracks as they are read, causing visible streaks along the
head paths - keep a careful eye on this, if it is getting more pronounced as you try reads, be very careful.

No, the tape inside the disk actually looks flawless. No scratches, no dents, no folds, not even dust particles. So I don't think the disk is physically in bad state.

DaveDDS wrote on 2025-07-30, 01:15:

Assuming you can try a few more times, here's some things that might help recover some sectors (which
ImageDisk can combine into a good image).

This is what I want to try, but I'm having some trouble getting the bootable disk image for ImageDisk to work.

I used WinImage to write the .BIN file to an empty disk, but unfortunately it won't boot. I verified that the files are successfully written to the disk (a `dir a:\` matches the list of files mentioned in the readme). When I enter my boot device selector and select the FDD, I can hear it read/spin up, but it won't load anything and kicks me right back to the boot selector. WinImage successfully formatted, wrote and verified the disk, but it just won't boot from it. Any suggestions on what else I could try?

Are there any real identifying strings in this executable showing it really is a qb7.1 compiled executable?

wierd_w wrote on 2025-07-30, 16:10:

Are there any real identifying strings in this executable showing it really is a qb7.1 compiled executable?

I haven't seen any strings specifically mention anything about qb, so I'm not sure if it is. If there are any other common strings in those kind of executables, I'm happy to look (I've tried qb, basic, quick, microsoft and terms like that, but nothing hit so far).

oldskool wrote on 2025-07-30, 15:54:

... This is what I want to try, but I'm having some trouble getting the bootable disk image for ImageDisk to work.

I used WinImage to write the .BIN file to an empty disk, but unfortunately it won't boot. I verified that the files are successfully written to the disk (a `dir a:\` matches the list of files mentioned in the readme). When I enter my boot device selector and select the FDD, I can hear it read/spin up, but it won't load anything and kicks me right back to the boot selector. WinImage successfully formatted, wrote and verified the disk, but it just won't boot from it. Any suggestions on what else I could try?

To confirm that BOOTIMD.ZIP on my site is good, I've just:

Download it from my site, extracted it, then:

Booted BOOTIMD.BIN under DOSBOX:
- It booted fine, unpacked everything and could run IMD

Booted BOOTIMD.BIN under VMWARE playey:
- It booted fine, unpacked everything and could run IMD

Booted BOOTIMD.BIN under 86BOX (386 emulated)
- It booted fine, unpacked everything and could run IMD

Wrote BOOTIMD.BIN to a 3.5" 1.44M floppy under DOS using included XDISL.COM
- It booted fine, unpacked everything and could run IMD

Wrote BOOTIMD.BIN to a 3.5" 1.44M floppy using included DSKWRITE.EXE
.. I think I might have an old version of WINIMAGE somwhere, but not handy
.. System running Win7Pro - didn't have a native floppy drive, so I used a USB floppy.
It booted fine on a system with an FD, unpacked everything and could run IMD

-- Please note --
I've updated BOOTIMD.ZIP in the last couple of days to refresh some older
stuff in it (I think before I mentioned it here...)
Make sure you have this latest version:
->DavesOldComputers
->Software/Images (near bottom of main page)
->BootableDiskette (around middle of page)

-- Other notes--
Have you booted other floppys?
Perhaps your system isn't configured correctly to boot from floppy.

Perhaps your problems stem from a bad drive/FDC ... can you write other bootable disks
and have them work?

If you have a writer, you could make a CD/DVD with the boot disk image on it (I use something called
"Magic ISO" to make CDs/DVDs with (sometimes many) bootable floppy images)
- But you really want to figure out why you floppy is not booting first - could be related!

oldskool wrote on 2025-07-30, 15:54:

No, the tape inside the disk actually looks flawless. No scratches, no dents, no folds, not even dust particles. So I don't think the disk is physically in bad state.

Not looking for scratches, dents or dust.

Typically when media begins to degrade, fine bits of the magnetic coating begin to seperate (flake off) from
the inner disk ... usually to small to see the bits, it shows up visibly as mild "rings" of a slightly different color/texture
from the part in between head paths.

DaveDDS wrote on 2025-07-30, 17:33:

Have you booted other floppys? Perhaps your system isn't configured correctly to boot from floppy. […]
Show full quote

Have you booted other floppys?
Perhaps your system isn't configured correctly to boot from floppy.

Perhaps your problems stem from a bad drive/FDC ... can you write other bootable disks
and have them work?

No, looks like my issue is here. I just tried writing an old DOS 6.22 boot disk, but it also won't boot.
I figured it might have to do with my BIOS having secure boot enabled due to my Win11 installation, but even after temporarily disabling this and rebooting the machine, it still wouldn't boot from the disk.

I suppose my system is not capable of doing this anymore.
Is there any way to get IMD running from within Windows? I suppose the command line isn't going to cut it, but perhaps through other DOS emulators or such?

DaveDDS wrote on 2025-07-30, 17:33:

If you have a writer, you could make a CD/DVD with the boot disk image on it (I use something called
"Magic ISO" to make CDs/DVDs with (sometimes many) bootable floppy images)
- But you really want to figure out why you floppy is not booting first - could be related!

Unfortunately, I don't have a writer, nor empty CD-R's laying around.

oldskool wrote on 2025-07-30, 18:25:

I suppose my system is not capable of doing this anymore.

Is this a new (ie: fairly recent) system?

You could try pulling the hard drive completely, set BIOS to as close to "normal boot" as you can?
Can a floppy be picked in the boot order (or whatever is similar in your BIOS)?

Is there any way to get IMD running from within Windows? I suppose the command line isn't going to cut it, but perhaps through other DOS emulators or such?

Unfortunately no, IMD access the floppy controller hardware directly and in some "unusual" ways.
DOS doesn't restrict what software can do, newer/muti-threaded OSs heavily restrict what can be accessed and done.

I also wrote IMD with a DOS port of my own MICRO-C compiler, a 16bit toolchain. And even if I were willing to spend the
months/years needed to work around with special permissions, special drivers and other ways to bypass the OS restrictions
(which I'm not) - moving it to another "modern" toolchain would also be much more work thanI care to do for something
that gets less and less interest daily (nothing/nobody "new" cares a bit about Imaging floppy disks
- "I think I might have heard about those antiques once - but have never seen one")

And.. IMD also needs DOS because it does some very real-time sensitive analysis - this is why I recommend
a "vanilla" DOS system without drivers/interrupts activating in the background - and not at all possible on
"modern" operating systems (where background activity is happening all the time)

I've not run into system(s) which can't boot DOS .. but I tend to stick with older stuff that
works well for me - it does seem odd (to me) that you have a system with a physical floppy disk
interface that's such a new design it can't boot from it.

Perhaps you can make a bootable flash drive somehow?
I've got systems where BIOS make USB flash appear as aaccessable drive (even in DOS), I can boot from USB
floppy, then FDISK and FORMAT/S to make a bootable system - but the only way of getting DOS to you is via
a floppy boot image. Perhaps there are tools to make a USB flash stick bootable with a floppy image?

DaveDDS wrote on 2025-07-30, 19:11:

Is this a new (ie: fairly recent) system?

Yes, it's just my daily driver that's about a year old, so definitely all very recent hardware.

DaveDDS wrote on 2025-07-30, 19:11:

it does seem odd (to me) that you have a system with a physical floppy disk
interface that's such a new design it can't boot from it.

I'm sorry if I was unclear, but the drive is not a physical/buit-in drive, it's an external USB drive.

DaveDDS wrote on 2025-07-30, 19:11:

Perhaps you can make a bootable flash drive somehow? I've got systems where BIOS make USB flash appear as aaccessable drive (eve […]
Show full quote

Perhaps you can make a bootable flash drive somehow?
I've got systems where BIOS make USB flash appear as aaccessable drive (even in DOS), I can boot from USB
floppy, then FDISK and FORMAT/S to make a bootable system - but the only way of getting DOS to you is via
a floppy boot image. Perhaps there are tools to make a USB flash stick bootable with a floppy image?

I tried making a bootable USB drive with IMD, but it seems to be doing the same. I think probably some stuff in my BIOS is not having it booting something that old, even with Secure Boot disabled.
I may still have an old PC in storage that has a physical FDD, but I will have to check if it's even still complete and boots at all. But sounds like that might be my only hope for next steps.

oldskool wrote on 2025-07-30, 21:37:

... I'm sorry if I was unclear, but the drive is not a physical/buit-in drive, it's an external USB drive. ...

Oh... Then forget IMD ... it needs hardware access to an actual PC FDC (Nex 765)
It won't work at all on a USB druve!

I'd guess it's a single bit error, most likely.
Run it through an online decompiler and see what it spits out.
Maybe it's a simple bit error.

You mentioned "WINIMAGE", have you tried reading the disk with that?

That doesn't have anywhere near the capability of IMD, but it will read the disk sequentially without
having to seek all over the place ... it should also let you know if there are read errors in any sector.

If you manage to get a good read, you should be abe to write it back to a new disk, then read it
file by file.

myne wrote on Yesterday, 02:38:

I'd guess it's a single bit error, most likely.

I wouldn't be so convinced, floppy disk sectors are protected by a pretty good CRC (Cyclic Redundancy Check)
to detect errors - It's very hard to corrupt data in a way to get the same CRC, and I'm pretty sure it can't be done
with a single-bit change.

Which is why it's o odd that he was able to get "good reads" and the files
still fail.... (Not that I trust Winblows/USB-floppies all that much)

The error message seems "cryptic" and suggests that some file may be accessed in a very
unusual way... I'm wondering it it's something about DosBox that's not quite the same as
real DOS system... Have you tried running the game under 86BOX, PCEM, VMware or Virtualbox?
(I have various DOS boot images on my site (See DBDOS) which will boot under those - heck
even "reak" DOS booted under DosBox would be worth trying).

Under all of the above, you could "mount" an image read from the diskette (WINIMAGE)
as drive B:

Run it through an online decompiler and see what it spits out.
Maybe it's a simple bit error.

Curious - what are you referring to by "online decompiler" .. an executable
program will have *many* byte instructions code/operands, and knowing if
one has changed would require some sort of reference to the original.
(On the x86, even "identical" operations can have different encoding)

DaveDDS wrote on Yesterday, 09:37:

You mentioned "WINIMAGE", have you tried reading the disk with that? […]
Show full quote

You mentioned "WINIMAGE", have you tried reading the disk with that?

That doesn't have anywhere near the capability of IMD, but it will read the disk sequentially without
having to seek all over the place ... it should also let you know if there are read errors in any sector.

If you manage to get a good read, you should be abe to write it back to a new disk, then read it
file by file.

I have tried it, but the disk definitely seems to have some damage/corruption. I will get disk errors pop up like "sector not found" and "The disk media is not recognized. It may not be formatted.".
It seems to throw this error for different tracks/heads on each read though (as if sometimes it will read a sector, but other times it won't).

Upon another closer inspection of the disk in full daylight, I also noticed there actually seems to be some slight physical discoloration/damage on it. I suppose this could also be (partly) where the issues are coming from.

oldskool wrote on 2025-07-29, 22:56:

[…]
Show full quote

Copy code to clipboard

1<<FMSG>>Device timeout Device fault Out of paper (Variable required 2FIELD overflow 4Bad file name or number 5File not found 6Bad file mode 7File already open 8FIELD statement active 9Device I/O error :File already exists ;

This series of error strings is almost an exact match for the ones in a QB45 executable. (The one I looked at also had "CASE ELSE expected" in there.) The game was most likely compiled by a similar Microsoft compiler.

"Bad file mode" can occur when you open a file as "BINARY" and then try to use INPUT/OUTPUT statements for file i/o, as one example. But that would indicate a bug in code, which shouldn't be there unless the code is now corrupt.

One thing that is worth checking is that none of the files are flagged as read-only. Maybe that could also lead to an error?

bakemono wrote on Yesterday, 10:45:

One thing that is worth checking is that none of the files are flagged as read-only. Maybe that could also lead to an error?

That was one of my initial thoughts as well. Using the ATTRIB tool, I only saw the "Archive" attribute on them, none were read-only. I also did ATTRIB -R on the files just to be extra sure that wasn't the issue. But unfortunately that didn't change anything. I'm more and more starting to think that my disk is unfortunately damaged in such a way that some of the files are corrupted.