Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

BD-R with UDF filesystem - FS redirector with 64-bit sizes (Miscellaneous)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 23.12.2020, 22:24

> In fact, it accesses the CD/DVD hardware using yet another interface
> which is provided by hardware-specific CD/DVD drive drivers :-) The
> interface luckily is quite minimalistic, mostly linear sector based.
There is a special CD device driver interface which is actually a kludgy combination of two device driver interfaces (one a character device and the other a block device). It's actually quite a mess. It really isn't designed for writing to the CD at all (it assumes all CD's will be read-only, only contain music or data files, and you will never need to write to them). The CD interface is really designed around audio/music CD's which aren't formatted as files the way almost everything else is (including modern movies). It is a type of redirector interface, though a very different type of implementation than the network redirector.

That's why the standard DOS CD thing doesn't really work all that well and really shouldn't be used for things like DVDs or even writable (or rewritable) CD's. In my USB drivers, I'm trying to include the standard CD interface where it makes sense (so "standard" CD software, like the kind that plays music, will work). But I need to go way beyond that interface to really make it work with all the modern optical media possibilities.

As mentioned elsewhere, CD's don't normally use the INT 13h interface, but I think that is really because of the legacy need to work with audio CD's. If audio CDs were formatted as files, there probably wouldn't even be a special CD interface and it might have been implemented as INT 13h (or SCSI or something similar).

> So basically the answer to this thread would be some sort of UDFCDEX
> which talks to your standard optical drive driver on one side and
> to DOS on the other side. But I fail to understand why it would be
> important to access files above 2 GB with that.
A mentioned elsewhere, it might need that to look at the huge movie files on a BD formatted with UDF. But as also mentioned, even huge movie files can be broken up into smaller files even though that is not "standard".

> BluRay contains heavy content protection and it is very unlikely
> that any media player for DOS can open such files. Also, it is
> quite unlikely that DOS media players have the necessary drivers
> for hardware-accelerated playback of advanced high resolution
> video compression formats, or are able to unleash the multi-core
> power of your CPU to decompress the video fast enough without
> the graphics card features for that.
That only applies if you're using BD's for movies. If your using BDs for file storage (like backing up a hard drive), none of the graphics stuff is needed and the speed is not really all that critical, either (it's nice if it's fast, but it's not a real requirement).

> So as mentioned before, FAT32 on BluRay might not be that bad
> after all. And you could make a generic driver which tells DOS
> that a new FAT (not CDEX) drive has appeared on one side, while
> talking to a (possibly different sector size) standard CD/DVD
> driver on the other side. Also nice for DVD-RAM or CD-whatever.
As alluded to above, I don't think the DOS side should be the standard CD interface since it's really designed around audio CDs and not files. I think the DOS side should probably be either a regular FAT-type interface or a network redirector interface.

I think that the interface to the hardware would be a FAT32 (or UDF or whatever) interface. That is, it would essentially "advertise" itself as a "FAT32 interface" (or whatever), and the hardware driver only needs to recognize that the device (or partition on the device) is formatted as FAT32 and "attach" or "bind" the hardware to the shim. The hardware driver would not need to actually "understand" how FAT32 works -- it only needs to understand how to locate specific sectors on the media. The shim is the only thing that needs to understand how FAT32 works. With this type of interface, FAT32 would not even need to be implemented in the kernel like it is now. You could "add" FAT32 support to even older versions of DOS, sort of a similar concept to the LFN drivers that currently exist for DOS. The basic idea is to separate the reading/writing of sectors (the hardware part) from the "interpretation" of the sectors and ability to tell DOS about the files (the software part).

Again, this seems like it could work, but I have no idea what kinds of issues one would run across in an actual implementation and it may turn out to be a really bad idea.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 233 users online (0 registered, 233 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum