• Please review our updated Terms and Rules here

I want to store a large, contiguous array of bytes on a floppy disc. Is Fat12 needed?

C

codyw1996

Member
Joined
Nov 12, 2016
Messages
27
Hi, I'm an 8086 16 bit assembly programmer.

I need to be able to store large arrays of pixel data outside of memory. It's map data for a game.
The idea is that maps will be loaded from storage into memory (during level transitions), then screen sized chunks of it will be copied as a frame into the video buffer.

Anyway, I had originally intended to store the map data on my 40 meg fat16 hard drive, so I had to do a huge amount of research on File allocation tables and how they work.

After I started writing the routines, I realized that instead of doing all of this hard work I could probably just completely format a floppy disc to all zeros (Remove the filesystem) then just directly fill the sectors of the floppy disc with the array data.

That way, I wouldn't have to worry about adhering to the weird structure of the FAT. I don't need DOS to be able to read the disc, the floppy disc need only be used as a data disc for my game.

My 286 laptop has no floppy drive, so I tested this out in Dosbox using a mounted floppy drive image, and it Works!
I can just specify a sector on the floppy, then either read it, or write memory out to it.

However, I know that fat12 included some error correcting redundancy stuff built in. Are real floppies really that unreliable? If I tested this on actual hardware would garbage data be a very common occurrence?

Maybe I could just have the data mirrored in several places on the floppy disc, then read it twice to make sure the bytes match, or maybe I'd just need a bunch of nops between reads and writes?
 
FAT12 has some redundancy for itself (file lists, locations, etc.) but not for the actual data / file contents.

I think your idea to mirror the data is good so long as the writes are small since the floppy drive isn't the fastest device to copy data to! Floppies aren't that unreliable that you'd need to do a lot of constant checking. The disks degrade over time and I do believe that usage (writing) accelerates the degradation. I used a Tandy 1000 for years as a kid and rarely had disks die on me ... but then the disks were new back then so I'm not sure if the age of disks now will cause a problem.

If possible, I'd recommend saving a short 16 or 32-bit checksum with the data.
 
Let's put a few things into perspective here.

1. All disks include at least a cyclical redundancy checksum (CRC) on each sector. Many hard disks use an ECC (error correcting code) instead of a CRC; the effect is the same, but auto-correction of single-bit and some double bit errors is afforded. All of this happens behind the scenes and is a hardware function integrated into the controller.
2. Hard disks spin at least 10x faster than floppies, with a corresponding increase in data rate. For all but the earliest hard disks, seek times are faster than floppies--and you get the benefit of addressing more than 2 sides of the media without moving the heads.
3. You can minimize seeks by de-fragmenting hard disks, then pre-allocating your storage area on the drive (i.e. pre-write your file in a single session without writing any other files while the original file is open). With minimal buffering, traversing the FAT is inconsequential.
4. Much of disk access time is spent waiting for an operation to complete. If you can be doing something else while the drive is being accessed, delays due to drive access can be effectively hidden. It may take some fancy programming, but it certainly doable, even on an XT.
5. If you opt to bypass DOS and use BIOS for access, be aware that the PC does not permit a read or write to cross a physical 64K boundary in the case of 8-bit DMA. DOS conceals this from you by moving data from a known buffer or buffers. not crossing physical DMA bank boundaries.
6. By far, the fastest and least troublesome access is afforded with RAM disks; that is, virtual disks stored in memory, be it conventional, EMS or XMS. However, this necessarily impacts memory available to your application.
 
I'm still puzzling over the intended application here. The vagaries of the FAT filesystem are completely transparent to applications that use normal DOS calls for reading and writing. Why go to the trouble?
 
Sounds more like a design intended for cassette than for any type of disk. But if you insist on creating a self booting game that has its own unique file structure, the BIOS read sectors function permit reading an entire track at once. Design most of your levels to use complete tracks and few calls to disk will be needed.
 
Are real floppies unreliable? Absolutely! They couldn't even be relied upon back in the day. *Everyone* at my school lost some key bit of work because of floppy disk issues.

As for the application, personally I would probably use a large flat file and access it though DOS calls (Int 21h) but equally writing directly to media is interesting in itself, so sure, why the hell not :)
 
I find 5.25" floppies to be more reliable than hard disks and SD cards.

Most of the data loss I ever saw on 5.25" disks was due to operator error. The rest (not much) was due to using cheap disks. The only disks I've seen fail otherwise in 35 years of usage are due to really lousy storage conditions.

The vast majority of the disks that I wrote up to 35 years ago were still perfectly readable a couple years ago when I started using them again. Some of them I've rewritten, but many of them I haven't, and I still use them regularly.
 
I just tested it out on my new old 386 desktop, and it works fine. I don't even need nops between sector reads, I guess the BIOS handles all of that.
For reference I use BIOS service 13, function 2 to read the sectors in to memory.
 
Picking up on a couple of things..

I still use floppies. The old type DSDD type are still VERY reliable, if used carefully etc as noted above. They are more reliable that HD types, long term.

However, if I was doing something like this, I'd use the HD as it's so much faster, BOTH because of the actual drive, and also the available buffering. I'd use a random access file, reclen the length of the screen data, and just select the required record, read the data, display it. KISS. Could use exactly the same mechanics with RAM disk, or SSD if the machine will take it.

Geoff
 
You must log in or register to reply here.
Back
Top