embedded DVD - RAM / RW

The file system is typically ISO9660, its description (and the entire standard) can be located on the net. You can write another filesystem if you want to, of course, but if you expect wintel PCs to read what you have written it better be ISO9660.

Writing to the DVD takes more, though. You need to implement some part of the MMC standards, you can find them at

. You need to "record" the file system image sequentially, i.e. you need to have it prepared or be able to prepare it while recording.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

analox wrote:

Didi, I thought ISO 9660 was only for CD-Roms and DVDs had others like UDF or FAT32 (at least if talking about DVD-RAM)

I was thinking of formatting/prewriting the media on a PC - e.g format the disk in the PC and prewrite it with a big dummy-file and sequentially write the data "into" that given file without the need to bother about the file-system related stuff

A simple app on the PC could then extract the paylod out of that file and store it as needed

w.b.

You sure can do that (I do it for my DPS backups...) but you will have to create the filesystem thinking 2048 byte block rather than 512 (which is the norm for ATA disks). Whether and how this can be done under windows or whatever I just don't know. But since the DVD is read only, it won't buy you much over ISO9660 even if you manage it, I see no advantage here/ DVD-RW+ allow some random access, but I would not seriously investigate the option of using one just as a HDD, it will fail after a while of rewriting the same location.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

analox wrote:

I had been thinking about similar issues for a future feature. We'll need to save sets of images or other files onto DVD over time. But not all at once. The ability to append files to existing media would be very useful and convenient here. We also don't have any disk space to spend on creating a image before burning to DVD.

So I had ruled out ISO9660 for that reason - it seems like an all-at-once file system, except for things like adding extra sessions which I think I'd want to avoid. Packet based systems seemed great, but I have never used them. I certainly would want something that a generic PC or Mac can read out of the box (ie, no special software). I assume that UDF can do all this, but I don't know much about it. Does it fit the bill, or should I investigate other solutions?

-- Darin Johnson

But why do you want to avoid them? Recording multiple tracks (closing/opening a new session for each track will only consume some space without really buying you much) and having a separate filesystem per track is really a convenient way of doing it. May be not ISO, each track can be say a FAT32 floppy-like or MO-like image, no problem doing that; the only issue is that on a wintel PC I don't know if you can set which track to be the current image to access (I do it by a single command under DPS), but this is obviously solvable. For your purpose - no room to prepare the filesystem - may be just writing the raw data in separate tracks would be just fine, closing session(s) from time to time etc. These are just suggestions without having insight in your issue, of course.

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Dar> > But since the DVD is read only,

obviously I meant FAT, not FAT32. It is 12 bits on a floppy and 16 on an MO... or LS-120 etc. Apparently I have had to listen or read that FAT32 slogan too many times... :-)

Dimiter

Didi wrote:

DVD-RAM is the easiest to work with, It looks like a hard drive with

2kbyte sectors. It also reads back the data that you write automatically and re-writes the data (when needed) into spare sectors on the disk with out you knowing it. This makes it MUCH more reliable than any other DVD media. The main problem is that the disks cost a little more, most PCs dont come with a DVD-RAM capable drive and it is the slowest of the DVD media for both reading and writing (about 3Mbytes per second max).

-howy

well, speed would be no problem as the M16 itself would be limiting anyway (and the costs dont mind either, 3-5 EUR is very good for us for 4 GIG)

the problem is how to finally get the medium UDF compliant ...

of course I could simply write physically from 0 to 4.x GIG and read that back on the PC side again physically, without MS - filesystem in between it (if medium opened with \\.\physicaldrive) but that would be only second choice ..

I'd like to have the medium as compatible as possible

w.b.

This is totally meaningless without context. Google is NOT usenet. If you are still posting from a google entry that has not repaired the reply mechanism, see my sig below. Please be sure to read the referenced URLs.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: 
Also see

You could format the disk with a PC, write a few 2Gig files to it (4Gig files may give you problems on some OSes so keep your files to just under 2Gig if you want Win98 to handle it properly)

Now you have a 4.5Gig contiguous area on the disk that your application can write to and any OS also can see since the area is encapsulated with big files.

Your device could learn to format the disk by just writing the first 20 or so Mbytes of FAT32 format data to the DVD-RAM. Your program can be smart about it since there are 2 identical FATs and the data in the FATs is pretty easily predictable.

You would not want to force a user to format the DVD-RAMs in this way on a PC since they would have to wait for 1+ hours for this method (writinf the 2Gig files would be required to form the FATs). Your device would be able to do a much quicker job of it since it doesnt need to write the huge file area, just the FAT32 format area.

-howy

CBFalconer, thank you for your wonderful help.

You're still getting it wrong. I was under the impression that Google had finally managed to fix their broken interface - certainly other people posting via Google manage correctly. Perhaps you have a special method of making contextless posts to limit the number of people willing to help you, or perhaps Google Groups is only partly fixed and you haven't found a workaround.

David Brown schrieb:

thank you too, that is SO useful. I am so sick of those wonderful comments, why don't you go and ...............

Then feel free to ask your questions somewhere else. This newsgroup is used, for the most part, by professional developers and serious hobby developers. As with any newsgroup, we have our style and "unwritten rules" - we have them for good reasons. If you break these rules, you'll be told (we all make mistakes sometimes) - when you respond with sarcasm, you alienate a substantial proportion of the knowledgeable and helpful posters in this group.

Welcome to the PLONK file.

-- "I don't know where bin Laden is. I have no idea and really don't care. It's not that important." - G.W. Bush, 2002-03-13 "No, we've had no evidence that Saddam Hussein was involved with September the 11th." - George Walker Bush 2003-09-17