Copying files to ISO

Is there a free tool for creating a CD ISO from RISCOS files?

I’m not going anywhere need physical CD’s, just local ISO files.

Is there a free tool for creating a CD ISO from RISCOS files?

I’ve done a quick port of genisoimage 1.1.11 to RISC OS. It can create an ISO from a folder(s). The ISO then successfully mounts in RISC OS using CDFaker.

Great, that should do exactly what I need. Where can I obtain a copy?

Jon, do you need this for an JASPP/ADFFS-related project? I could produce a minimal tool from existing CDVDBurn code specially for you if you tell me your needs.

Free of charge of course, because I like what you do with JASPP very much.

Great, that should do exactly what I need. Where can I obtain a copy?

You can download it from here.

An example command to create an iso from a folder,

genisoimage -v input-charset iso8859-1 -J -r -V test -o test.iso test_folder

Thanks Chris, I’ll give it a try.

do you need this for an JASPP/ADFFS-related project?

Sort of. I wanted to copy StarFighter 3000 TNG into an ISO in runnable form as the 2GB partition under RISCOS isn’t big enough to contain multiple copies of it.

Thanks for the offer of a bespoke copy for the project, I might take you up on that in the future when I further integrate CD-ROM emulation into ADFFS. Before then I’ll have to figure out how to distribute ISO’s, as the default 2GB partition size and the way PackMan works aren’t workable for ISO’s.

TBH I think I need to write a partition resizer and a streaming package manager before ISO distribution is viable.

Unfortunately Chris, it’s been compiled for ARM v6 and I need it to run under RO 3.71.

Would it be possible to recompile it for ARM v3, or provide the source?

it’s been compiled for ARM v6 and I need it to run under RO 3.71.

There’s a version that should run on RO 3.71 here.

Sadly half the command line parameters don’t appear to work and it doesn’t support Acorn filetypes. Going by the manual a charset of “default” and “-U” should allow lowercase and retain all characters, but it’s still converting to uppercase and replacing a lot of characters.

Another odd thing I noticed is it crashes UnixLib when run for a second time, I had to reboot after every run.

Thanks anyway, its fine for creating MS-DOS ISO images.

it doesn’t support Acorn filetypes

Unless you went full ,xyz with a reader as well, maybe you could use .zip archives in the iso?
Fewer files possibly could ease the strain a bit too?
I noticed Chris has allocated -min 2223K which is pretty big.

Acorn filetypes can be included in an ISO image using Joliet extensions, which CDVDBurn does quite well. Also includes upper and lower case.

Going by the manual a charset of “default” and “-U” should allow lowercase and retain all characters, but it’s still converting to uppercase and replacing a lot of characters.

Looks like not all CDFS are created equal.

RO 3.71 shows all upper case. RO 5.2x shows correct case.

After a bit of googling I found the patches to mkisofs that allow saving of RISC OS file types. I’ll make this available for download once it’s tested.

Looks like not all CDFS are created equal.

Does CDFS under RO 3.71 support Joliet filenames? I’m guessing that’s where the lowercase filename is come from with genisoimage.

I’m guessing native Acorn CD’s write the lowercase filename to the extended 8.3 filename and allow all characters.

I’ll make this available for download once it’s tested.

Thanks, I’ll rerun my test and see if it works. It does need a 1:1 char mapping though, without any translation at all.

There’s a version of mkisofs with RISC OS file type support available here.

Before running the below command, all files with a file type need renaming to e.g. obey,feb. I used !Rename to rename the files recursively in a folder. Available from here. I briefly tested it on RO 3.71 and it produced a valid iso with file types intact. Not sure if ‘-U’ does a 1:1 character mapping.

mkisofs -archimedes -U -o isoimage.iso <foldername>

I couldn’t get !Rename to work (I think “&1,&x” is the correct rename pattern), I don’t think it will work under RedSquirrel anyway as “,xxx” is how RS names the files to retain the filetype.

I manually renamed a file to test, but the output is identical to genisoimage on RO3.71, namely all uppercase, replaced characters and no filetypes.

Looks like not all CDFS are created equal.
RO 3.71 shows all upper case.

You’re complaining because a nearly twenty four year old version of the OS doesn’t do it “the nice way”?

FWIW, Rockridge support was added to CDFS 2.48 in 22nd April 2005.

Rockridge support was added to CDFS 2.48 in 22nd April 2005

That would explain a lot as my RO3.71 is currently using 2.29. It must be RR not Joliet that’s providing longfiles etc.

I couldn’t get !Rename to work (I think “&1,&x” is the correct rename

It worked OK under RPCEmu and RO 3.71. Prototype is ^. and ‘Directories’ and ‘Applications’ ticked.

Soft-loading CDFS 2.63 gets the correct case back. Which characters are getting replaced?

Looks like the UnixLib suffix swapping is changing some of the paths. There’s an updated mkisofs here.

Also before running mkisofs to turn off suffix swapping type this command,

set UnixEnv$mkisofs$sfix ""

Acorn filetypes on CD: Acorn defined the “ARCHIMEDES” extension name for ISO9660 compatible embedding of filetype/datestamp/access rights or load/exec address. It is basically the two usual words. A flag is used to signal “replace the first character of the filename/dirname with the ! character” to allow the ever-important “pling” to be used in an ISO9660 conforming way (ISO9660 only allows upper-case letters, digits and the underscore). Look at any old Acorn CD, you will quickly get the idea how that works.

Early CDFS forces all characters to upper-case if left unpatched. I think the patch was by David O’Shea, I am sure I have it somewhere. It found its way into the cumulated RISC OS 4 patch maintanied by Darren Salt: http://old-www.moreofthesa.me.uk/progs.patches.html

Many versions of CDFS suffer from the old “how to map the extension to the filetype” problem. DOSMap had various interesting bugs back in the days up to I think RISC OS 3.8. There is the additional problem that CDFS cannot properly treat filenames with the standard extension separator “.” if such a file has the “ARCHIMEDES” extension. CDBurn therefore integrates a special creation option where the “/” is left in the filename instead of translating it to the “.” (which keeps CDFS happy, but breaks ISO9660 compatibility), alternatively it suppresses the “ARCHIMEDES” extension.

Some day, I have to write all of that up somewhere.

As soft CD/DVD emulation is becoming more common it seems a good time to at least look at tht possibility of doing a R/W ImageFS for ISO images. Thankfully ISO9660 is fairly simple in structure, do not have anything on Joliet at the moment.

Joliet is just a parallel directory structure to the ISO9660 part that supports UCS-16 characters in the filenames and unlimited directory depth. No additional complexity. RockRidge is a lot more complicated.

Good luck writing an ImageFS for ISO images – the “read” part is simple, but the “write” part is not. ISO9660 basically uses fixed blocks for everything, so you start to move things around quickly when directory records need extension. ISO9660 allows for no file fragmentation at all. UDF was invented for that (and is a lot more complex).

Anyway, I have donated a CDVDBurn 3 licence to the JASPP, so Jon can now happily create “proper” CDFS CDs :-)

Well aware of the continous file requirement.

But you still want to have an ImageFS that can write?

That is the reason most of us refuse to use UDF in fact.

UDF provides sensible support for file fragmentation like most other FSes, in conjunction with being specially engineered for optical write-once or better-write-seldomly media. The only reasons to refuse to use UDF is “we don’t have it” (RISC OS users) or “I want/need ISO9660 compatibility” (rest of the world).

inserting blocks into a image for file addition can be a bit of a pain, though it will allow for a reasonable read/write (as writing is rare) ISO ImageFS. People rarely write to a CD/DVD even when possible, so the same should be with the ImageFS, only when a file in full needs added, it is a storage FS not an active use FS.

If your provide a full R/W ImageFS for ISO images, people will start to use it. They will write to it. Randomly. Why would they want to use it if not for writing? For read-only, they already have CDFS-with-CDFaker or CDROMFS. You are right that CD/DVD writing is usually (unless using UDF) done in one go (which is probably “rarely” by your definition), but we are still talking about ISO images, do we?

I am sure you can explain how you will enforce “file in full addition” when implementing an image filing system in RISC OS? Secret flag somewhere in Fileswitch that I missed last time I read the PRMs?

BTW, could you please stop using hard line breaks every 30 to 50 characters? It makes your posts even harder to read and a headache to quote sensibly.

The line breaks, now at 40 chars max is to make the text readable when people do strange formating, especially so it can be read by people that use a low resolution monitor (like me) enen when someone decides to insert code that has longer lines in it.

This only happens in very very specific situations. I encountered it probably three times in all the years since 2009(?). It is usually quickly fixed when the author of the post gets notified.

So because of this rare situation, you are ruining the formatting for all the normal stuff. A truly bizarre idea.

I could take it out to 80 chars if that is more acceptable to you.

Any hard break is unacceptable, because it ruins the formatting of the forum post for everyone – for those with low-res monitors (Full HD) as well as those with high-res monitors (4K), for those with narrow browser windows and also for those with wide browser windows.

No thanks, this is no longer the 1990s.

When writing in the forum, only put line breaks in when you want a new paragraph. Then the browser will wrap the text to the size of window being used.

Putting line breaks in at 40 characters makes your posts look stupid (especially when you occationally leave one out, as in the first post) and leads to lots of unecessary scrolling.

And that means my one year old monitor does not exist? (800×480 native res).

No, but it does mean that your one year old monitor is extremely unusual. I’ve not seen a monitor less than 1600×1200 or 1920×1080 for ages; my ancient laptop, with an 11" screen, is 1366×768.

Edit: just took a look at Amazon UK. They do list an 8" monitor, but it’s 1024×768. They don’t list any monitors with fewer pixels than that.

I’ve never seen such tiny monitors, but I’ve managed to find them online. I certainly wouldn’t want to have to use one! That 11" 1366×768 is horribly tiny from my point of view.