Acorn RISC OS Software available for download:
Last updated: 17 Jan 2010 (Scripts)
The following software was written on / ported to an A5000 with RISC OS 3.11
and some of the newer stuff on a StrongARM RiscPC with RISC OS 3.7.
Most of it is unlikely to work on RISC OS 2. All software is provided in ZIP archives;
you can uncompress them using SparkPlug / SparkFS, to name but two
Since there is little room for this homepage the following programs are usually
not kept locally any more but refer to the Stuttgart FTP server (apart from some
exceptions, probably). Please inform me if any links to that server have changed
so you can't access them anymore.
Software I wrote:
Metamorphosis (release #2) (429345 bytes):
A megademo I wrote some time ago. Includes texturemapping and vectormorphing.
This is the StrongARM compatible release #2. Freeware.
Deep4All V0.12 (15373 bytes):
A viewer for sprites of any colour depth which also works on older (pre-RiscPC)
machines. Converts a number of image formats (JPEG, GIF, TIFF, ...) to sprites
in the background using ChangeFSI. Freeware.
FastSpool V0.20 (8788 bytes):
Fast data transfer to the parallel port (Freeware). Needs a computer with a new
style parallel port (e.g. A5000, RiscPC,...).
A much more powerful, commercial version called FastSpool+ was released at
Acorn World 97 in association with
Warm Silence Software. FastSpool+
is fully integrated into RISC OS, providing its own Filing System, true background printing
(i.e. the spooler won't stall when you leave the desktop), supports more printers, can also
drive old parallel hardware fast and and and. Available for £15 from october '97.
Fractulus V0.10 (44540 bytes):
Fractulus is basically a multitasking fractal generator environment. The frontend
provides the user interface, the actual calculation is done by small programs I call
cores. The interface between cores and frontend is documented so everyone with a
little knowledge in ARM assembler can write their own. Fractulus can also create
movies by calculating a sequence of sprites. Freeware.
BreadPatch.zip V1.4: NEW (2 Sep 98) (29276 bytes)
This is a patch for the Breadbox V0.44 by Denys Bogatz.
It cures some bugs in the original version and gives the program simple IO (which
makes programs like the Last Ninja-series work). This version
also handles vectored Kernel-calls correctly (now the
as well). Also $DC00 gives the correct value when reading now which makes
some programs work that used to have difficulties reading the joystick in port 2.
This version can patch both release #1 and release #2! That means both release #2's,
the one you got when you bought it from Pulse Computer and the one that's now available
as Shareware. Make sure you read the !Help file so you use the right patch.
Click here to download a Mahjongg variant
I wrote a couple of years ago for my C64.
Optimum Palettes (13822 bytes):
This CLI-program reads 32bpp sprites and converts them to 1/2/4/8bpp sprites with an
optimized palette using an iterative error-gradient approach. It's rather slow in
spite of being written in assembler, but the result usually looks very
good. It's currently Videoware but will probably become Shareware soon.
PCLTools NEW (20 Oct 97) (59922 bytes):
This is a collection of utilities for PCL printers (e.g. DeskJets, LaserJets). Programs
marked PP will only work on a pageprinter (e.g. Laserjets).
- asc2pcl: (PP) This allows fast text printing by using the
printer-resident fonts. You can define your own formats (like 2up landscape). It
also contains a powerful search and replace-engine that lets you for instance do
context-sensitive C-printing (like Zap's coloured C-mode). Recompiled.
- PDumperLJ: This is a patched version of Acorn's PDumperLJ V1.17. It uses
more advanced compression techniques which means it doesn't work on older printers
any more (AFAIK older than LaserJet 3) but compacts regular stuff like text to
less than half the size of the original PDumper.
- rpcl: Converts PCL printouts as created by the Acorn printer drivers
(B/W, CMYK) to sprites. New version converts all the pages contained in a
printout, storing each in its own sprite file.
- plr: (PP) Reads in PCL printouts and positions them according to your
specifications. Creates multiple pages if necessary. This allows you for instance
to place 2 printouts @ 400dpi on one 600dpi page in landscape. New version can also
handle multiple raster areas per input file, start/end-page and arbitrary page
- ppcl: Reads in PCL data or B/W sprites and outputs PCL data in various
compression formats. The resulting data should then be processed with plr. Recompiled.
- PCLtoRGL: This is a post-processor that converts CMYK printout files as
created by Acorn's !Printers to RGL printout files. RGL is a related printer language.
Formerly available as a seperate archive.
- psprite: Converts sprites to monochrome or CMYK sprites or PCL data using
error-diffused dithering with user-configurable brightness mapping. Runs
in a TaskWindow, doesn't need to keep the whole source sprite in memory, doesn't
need !Printers, can print new style sprites even on old machines and is about 4 times
the speed of printing sprites with the Acorn printer driver.
- Axis4HD NEW (26 Jan 98) (4391 bytes):
This patch allows you to install the classic game Axis on any filing system
(although, as the title indicates, the main motivation was installation on a harddisc).
You need the original discs to perform the patch. The discs will be stored in a
compressed image file; since I didn't feel like optimising the compressor much time-wise
this procedure takes a while, but the decompressor is really fast which is the main thing.
The patch does not contain a WIMP frontend, it's CLI-based and shouldn't
be attempted by anyone who's not familiar with the CLI.
Please do not use this patch to spread pirate copies of Axis (OK, since the
game didn't have a copy protection in the first place this patch doesn't give you
any new opportunities, but anyway...). Also don't hold TBA responsible if
anything goes wrong -- me neither, BTW, because it's Freeware.
UPDATED (3 Sep 2006) (134070 bytes): Wanna compile Vice for RISC OS yourself?
Then you might want this archive which contains some tools to make life a lot easier
(especially if you're on the Vice mailing list and have to keep up to date with the
development version). The tools are now released under the GNU Public License (GPL).
This archive also contains a set of Makefiles for version 1.20. Also includes a
script riscosconfig.sh which can be used to build it using the GCCSDK
crosscompiler on Unix systems.
- Source Tools
NEW (16 Mar 2003) (22176 bytes): Some useful tools for people handling source
trees, both of which originated from my Vice port and can also be found in
ViceROKit. instsrc installs a source tree in unix
format (dir.file/ext) into RISC OS format (dir.ext.file). cmake
creates makefile dependencies for all C/C++ sources visible in the current directory.
The tools come precompiled and with full source code, released under the GNU Public
License (GPL); documentation can also be found in the archive.
NEW (1 Jan 2003) (8797 bytes): Little utility to stamp files containing
mail/news post (as in NewsBase) with the date given in the header. This addresses
a bug in NewsBase's expiry algorithm which uses the filestamp rather than the
file header to determine whether a file is obsolete. Comes with full source code
under the GPL, requires WimpLib to compile.
- DigitalRenderer 0.52
(32bit) NEW (15 Jan 2006) (17567 bytes):
Important Note: further development of this module will most likely be carried
out in the GCCSDK Project, so the version
presented here may be obsolete. In case you're having trouble with the module version
or would just like to verify you've got the latest build, please consult GCCSDK as well.
This module for playing sound
samples from applications has a long history and dates back to the days when I ported
Frodo (hence also the name, BTW, because the sound synthesis code
in Frodo was called Digital Renderer). Nowadays, development is mostly driven by my
requirements in Vice which go considerably beyond what I needed for Frodo.
The original version replaced the channel handler which worked OK but is something one
shouldn't normally do. I recently gave the whole thing a serious overhaul and rewrote
it to use the standard voice generator interface, also fixing a number of bugs in the
process. Version 0.40 also offers a pseudodevice "DRender:" which allows
playing samples just like on Unix by opening a special file and writing to it.
Version 0.50 can also use the 16bit sound hardware available on newer machines
transparently. So rather than continue publishing it hidden in some of my ports
(most notably Vice) I now offer it as a standalone archive; it should prove very
useful to most people writing applications containing sound code, especially ones where
synthesis has to be done in real time (e.g. in emulators). Full documentation of the
SWIs, a C-header file, assembler and AOF stubs are provided in the archive.
- Interfaces: single buffer, streaming (arbitrary length buffer), direct
- Data formats: 8bit ulaw, 16bit signed linear
- Pseudodevice "DRender:" (filing system number 167, registered)
- Transparently uses old 8bit logarithmic or new 16bit linear sound hardware
This is the binary release of the module; for source code go
- GameSupport 0.03
(32bit) NEW (15 Jan 2006) (14534 bytes): This module originates from
my Doom port DIY. When I was working on release 4.3 I got fed up
with serious crashes being able to total the machine because the runtime environment
didn't allow deinstalling handlers. So I made the handlers as application-independent
as possible and pushed them into a module, GameSupport. This includes an asynchronous
frame buffer (i.e. switching the displayed screen bank happens in the background
and doesn't stall the foreground task), sound- and keyboard handlers and some
misc support code. Some vectors (most of all sound) still have to branch into application
code (because the module can't know what to synthesize), but you can make the module
sit on the OS exit handler and thus make sure there are no branches into application
code after it was mapped out (normally the OS should do that, but RISC OS doesn't
seem to consider this necessary; don't ask me what they were thinking...). There's
also a rather low-level hack of mine that tries to recover SL from the
stack of an SCL program if that was corrupted when a fatal signal was raised.
You can also activate logging of important events (registering / deregistering
handlers, handlers being called etc.) into a file for debugging; that file is
opened and closed for every log message to make sure you get some info even in
case your machine locks up. As all of my modules, all resources are officially
registered. The archive contains module, documentation and stubs for interfacing
with C (header file, assembler glue code and resulting object code).
This is the binary release of the module; for source code go
NEW (1 Jan 2003) (6077 bytes): This is a small utility which reads
a Draw file or sprite, calculates its size in millimeters and returns the
scaling factor required to make it fit into a user-specified bounding box.
I use this for my LaTeX package diagrams.sty to
determine the scaling factor on RISC OS. The archive contains an executable
binary of the program as well as the C source code (requires
WimpLib to compile) and is released under GPL.
- Wimplib 0.01 UPDATED
(2 Sep 99) (67611 bytes): this library dates back to the days when I ported
Frodo, bits of it were also used for Doom,
but so far it was mostly a couple of source- and headerfiles that got modified as needed.
While I was working on Vice I finally made a real library out of it,
containing some low-level OS glue code, some very handy timer stuff, the frame buffer
used in Doom as well as a better interface to windows and icons.
Wimplib is in no way exhaustive; a lot of stuff is missing because I didn't need
it, so don't expect the full SWI functionality of RISC OS to be supported by this lib.
That's why I'm releasing the library with the full source code, i.e. you can
modify the source and add the things you're missing. This version is public domain.
- Wimplib 0.11 beta
(32bit) UPDATED (15 Jan 2006) (337136 bytes): newer version, as required
for Vice 1.5, but still beta (may include debug output and possible bugs) and will
change frequently. The biggest change is the addition of a powerful text window class,
a basic C++ binding for WIMP apps and a complete rewrite of the fractal demo app in C++;
more information when it has left the beta stage. Also the assembler stuff was finally
split up to make linking more efficient and there's an SCL-conformant emulation layer
for some common POSIX extensions (such as read, write, readdir,
stat or fileno). The license is now LGPL.
This updated version is 32bit compatible, but the library that comes with the archive
is compiled on a 26bit system, so you have to compile it yourself if you want a 32bit
version. I also included Makefiles for building the Library with the GCCSDK
crosscompiler on Unix systems.
- libfastlz 0.01 (32bit)
(12 May 2003) (19197 bytes). This is a small LZ77-based compression library
designed for very fast decompression. It was originally developed by me for
compression of WAD lumps for my Doom port DIY; I recently
made it into a separate library to avoid duplicating code between armDeu and the
main DIY engine. The library is portable across many different platforms and should
also compile fine on most Unix systems; the optimized ARM assembler code for
decompression is 32bit-transparent. The library is distributed under GPL.
Source code for relocatable modules I wrote:
Since it's highly unlikely I'll continue developing much for RISC OS, I decided to
release the source code to some of my relocatable modules under the GPL on 15 Jan
2006. All modules are written in BBC BASIC's inline assembler and require my library
stdlib containing standard definitions and
functions. Copy the library into your BASIC library path (so it will be found by
the LIBRARY command) before attempting to build any of the modules. Please
note that most sources attempt to write their output to a file matching my harddisk's
layout, so you'll probably have to adapt this file to your harddisk to actually get
any useful output (search the sources for OS_File statements to find the
line in question). Generally speaking, I didn't change much prior to the GPL release
but basically changed the licensing text and made sure the output files are built
correctly (and functioning).
Since modules aren't linked into programs but, being OS-extensions, are called via
SWIs, my understanding of the GPL at this point is that the resulting modules can be
used by anyone, but use of the source code itself is restricted by the GPL. This is
what I intended with this licensing scheme, but in case I misinterpreted anything,
I'd appreciate hearing about it rather sooner than later. In case there are C headers
and assembler stubs provided, these are licensed under LGPL and can therefore be
used in all kinds of projects.
Right, that's that; hopefully some of these will be useful to other developers and
be improved one way or another. I'd appreciate being informed about updates to any
of these modules, BTW.
- D64ImageFS 0.11:
NEW (15 Jan 2006) (54186 bytes).
This is an image filing system for D64 images (as used by C64 emulators). It lets
you access D64 images like any other RISC OS directory, including writing to them.
Version 0.10 can also handle 1571 images and cures a few smallish bugs.
Version 0.11 doesn't add any functionality, it's merely the first GPL release of
the full archive, including the source code. Note that this module is not 32bit
compatible (but that should be a pretty straightforward job if anyone wants to
- Digital Renderer 0.52:
NEW (15 Jan 2006) (42546 bytes).
This is a source-only release. For binaries and a full description of what it does,
Note that further development of this module will most likely be carried
out in the GCCSDK Project, so the version
presented here may be obsolete. If you want to make sure you've got the latest
version, please consult GCCSDK as well.
- Game Support 0.03:
NEW (15 Jan 2006) (35513 bytes).
This is a source-only release. For binaries and a full description of what it does,
- BPlot 0.03
NEW (15 Jan 2006) (42334 bytes).
This archive contains the source code of the bitmap plotter BPlot I originally
wrote for Frodo and which is also used (optionally) in
VICE. Due to the history of the module, the BASIC source
PGen2 doesn't create a binary module but rather an AOF assembler file
which you have to translate into a module (since the plotter was originally linked
with the emulator and only was made into a module later on). This can be a bit tricky
and ugly with the free tools, but I can't be bothered to rewrite this thing. Creating
the object file is straightforward and I succeeded making the module using
drlink -bin -base &fffffffc -o BPlot o.Plotters and then cutting the
first word out from the module (that's why the -base-statement above is
needed). Like I said: it's ugly, but I can't be bothered to change it.
Software I ported:
Frodo V4.1: NEW (5 Sep 97) (328896 bytes)
Frodo is a Freeware C64-emulator written in C++ by
Christian Bauer. It needs
a computer with a lot of oomph so if you want 100% emulation speed you really need
a StrongARM. For more info see Christian Bauer's
homepage. This is V4.1 which includes binaries of Frodo, FrodoPC and FrodoSC.
Click here to download a Mahjongg variant
I wrote a couple of years ago for my C64.
dvi_dvi_lj: (202238 bytes)
This archive contains two DVI utilities:
Both programs are Public Domain / fall under the GNU General Public License.
- dvidvi: Allows you to change the layout of DVI-files, like for instance
placing multiple DVI-pages one one page.
- dvilj: This is a DVI to PCL5 printer driver that allows printing DVI files on
LaserJets. It was written by Gustaf Neumann and
modified by Karl Berry. I did some modifications
myself, like supporting Draw- and Sprite-Files as well as introducing
compression of raster areas as well as fonts, cutting down printout size dramatically.
The latest version also supports arbitrary resolutions. The advantage compared to printing
from DVIview is speed (40-60 pages/minute on an A5000). The disadvantage is a
somewhat more complex installation.
TeXUtils: (329525 bytes)
This archive contains a number of utilities to use with TeX:
The programs included in this archive are Public Domain or fall under the GNU
General Public License.
- C++2LaTeX: Name says it all, basically. Converts C(++) source code
into LaTeX source code, using different text styles, depending on the context (so it's
like Zap's coloured C mode).
- html2LaTeX: Converts html source code to LaTeX source code. Good for simpler
stuff but tends to fall over a little (not crashing or anything) with more complex sources.
- LaTeX2rtf: Converts LaTeX source code to rtf (Rich Text Format, as used by
Micro$oft Word, for instance). It can only deal with standard LaTeX commands, so you
have to edit a bit if you defined your own LaTeX commands in the document.
- rtf2LaTeX: Converts the other way around. This seems to work pretty well,
actually. I haven't tried it with really big or complex documents yet, however.
- rtf2TeX: Does the same but the target format is TeX.
- Doom It Yourself: (NEW (11 Mar 98) My port of
iD's Doom sources, licensed under GPL. Works on various Unix variants including
Solaris (Sparc), HPUX, Linux, as well as RISC OS. More information on the
for RISC OS (32bit):
NEW (3 Sep 2006) (4521608 bytes). Vice is a GPL Commodore emulator originating
from the UNIX world which has been developing quite radically over the past couple of
years and is the most accurate free CBM emulator around. This archive contains
the full binary Vice distribution, i.e. emulators for C64, C128, CBM2, PET, Plus4 and
VIC20 as well as a VSID player for all the lovers of the old C64 tunes. Version 1.12
was the first 32bit-compatible RISC OS release and required the new Shared C Library
available from the Castle website. Note that
due to space restrictions, the link above no longer references an archive on my homepage
but the archive in the official Vice download area. Also note that from version 1.13 on,
the Digital Renderer module is no longer part of the VICE release but must be
downloaded and installed separately (see !ViceRsrc.!Help). Get the latest
For more information on Vice and the source code see the official
Warning: Vice is huge and needs lots of processing power. The emulators need
a Wimpslot between 9MB and 13.5MB and you can't hope to get anywhere near 100%
emulation speed unless you've got a StrongARM; for 100% speed even under complex
emulation conditions (such as most games) you'll need an Iyonix-class machine and
even that one will struggle with really demanding stuff. So it's quite pointless
to download this huge archive if you don't have a 16MB RiscPC with StrongARM
If you want to compile your own version for RISC OS you'll need a C/C++
environment like GCC
(preferably 2.95.4 or newer, since 2.7.2 had some annoying optimizer bugs),
a make utility, the wimplib 0.11 and to make life
a little easier also ViceROKit which contains
Makefiles and tools. I recommend crosscompiling with GCCSDK on a fast Unix
But why is it so demanding?
It just emulates ancient 8-bit systems after all, right? Well, the problem is
that the C64 in particular was really taken to the limit like no other system I'm
aware of. A lot of software only works if the entire system is emulated with cycle
accuracy. On this level, even machine instructions are no longer atomic and you have
to emulate what multi-cycle instructions are doing in each of the cycles rather than
the final result. A typical example is a fastloader for floppy disks, which came with
more or less all of the larger games. In order to successfully emulate this, you have
to emulate the entire chipsets of both the computer and its floppy drive (the 1541
had its own microprocessor and was basically a fully-blown computer minus video and
audio) at cycle accuracy, or at least the two processors and the IO chips. This
is by orders of magnitude more complex than just emulating an isolated 6510 processor.
Another example would be video effects, many of which demand cycle accuracy as well,
for instance the trick to remove horizontal borders. Doing a good C64 emulation is
really in a league of its own since it demands a level of accuracy that would be
severe overkill for more or less all other platforms. Don't compare the performance
of a good C64 emulator like VICE with emulators for other 6510-based systems unless you
know what happens under the hood (in which case you'll probably be amazed how well it
performs in spite of the complexity).
And regarding the RISC OS port: VICE would run considerably faster if there was
actual RISC OS hardware with something you could call "memory bandwidth"
without laughing, but unfortunately the last system where that parameter could be
called sufficient (in relative terms) was the original ARM6-based RiscPC back in '94.
Note: the actual porting work for these libraries was usually done
by other people, most of them were straightforward compile jobs, often to
make them work with GCC rather than Norcroft. I did fiddle around somewhat with
the TIFFlib code, however, and removed the OSLib dependencies from the
Acorn driver. I hope these ready-to-use libraries consisting of headers and ALF
library (and in some cases some elementary executables) will help people getting
things done. Neither archive contains the full distributions as these are readily
available on the net, so if you're looking for documentation, tools etc. you'll
have to download that as well.
- NetLib for UnixLib 3.7:
NEW (25 Apr 2000) (46712 bytes). This is basically just a compiled version
of the netlib directory of UnixLib37b (by default no network support is available).
This is necessary because socketlib and UnixLib don't coexist together too well.
For all copyright issues see the main UnixLib distribution.
- ZLib version 1.1.3:
NEW (1 Jan 2003) (42597 bytes). The well-known standard compression library
by Mark Adler; the full distribution can be downloaded from
- JPEG version 6b:
NEW (1 Jan 2003) (200736 bytes). The latest version of the JPEG standard
library; includes the executables djpeg and cjpeg. The full distribution can
be downloaded from here.
- PNG version 1.0.6:
NEW (1 Jan 2003) (103918 bytes). The latest version of the PNG library. Define
the macro RISCOS when including the headers. Requires zlib. The full
distribution can be downloaded from here.
- TIFF version 3.4 beta 037:
NEW (1 Jan 2003) (396576 bytes). The latest version of the TIFF library, compiled
with maximum supported formats. That means it also requires zlib and
jpeg. Includes some tool executables as well: gif2tiff
and tiffmedian. The full distribution can be downloaded from
- GIF version 2.0:
NEW (1 Jan 2003) (18479 bytes). A free GIF library by Gershon Elber and
Eric S. Raymond.
Useful Software by 3rd Parties
In this section I will present small bits of software that are useful and hard
to find otherwise; I will not mirror easily accessible packages.
- kbd.zip: NEW (24 Oct 2000)
(4804 bytes). This archive contains two relocatable modules for keyboard handling. Both these
modules were created using Nick Craig-Wood's "riscpckeys" archive
available from e.g. Hensa, but unfortunately this patcher does no longer work
with recent versions of the modules (e.g. RO3.7 or newer), therefore I put the
resulting modules rather than the patcher on my site. The modules can be used
independently of each other.
These modules go into your PreDesk boot directory. For more info peruse the
ReadMe file provided in the archive.
IntKeyBrd+ is a keyboard handler module for US-Layout keyboards (flat
return key, backslash above it); this is no longer necessary on RO4 or newer, but
before that there was no support for US layout, so if you have one of these
keyboards (the best you can get for programming), use this module.
allows you to swap Caps Lock and left Ctrl key for those stupid PC keyboards which
put Caps Lock rather than Ctrl above the left shift key.
Everything that doesn't fit in any of the other categories...
NEW (06 Dev 2000) (247067 bytes) LaTeX format file for bigvirtex of the
new armTeX release
including US english and german (traditional) as languages (the standard
format contains US english only). You should use this if you want correct
german hyphenation, which is not provided by german.sty. Copy
the file in the same directory as the other formats (look for latex/fmt)
and change the latex script in armtex.bin to read
bigvirtex &lplain %* rather than bigvirtex &latex %*
and everything should work fine.
NEW (06 May 2002) (4137 bytes): LaTeX2e style for portable diagrams
(plain TeX using PostScript files with \psfig, armTeX using
DrawFiles and Sprites with \DVIview_diagram or pdfTeX using
PDF/PNG/JPG files with the inbuilt \pdfimage command). The archive
contains some documentation on how to use the package and is released under
Generic source code I wrote
NEW (27 Aug 2005) (4955 Bytes). Generic Sudoku-solver for arbitrary
matrix sizes (not just the original 3x3), written in C++ and licensed under
GPL. The program is run from the command line and requires a CSV-file with
the input matrix as first parameter. Unspecified cells in this matrix are
represented by whitespace or zero. An example CSV-file is also included in
the archive. All you need to build this program is a halfway up-to-date
C++ compiler, no additional libraries are required.
NEW (28 Jan 2006) (1878 bytes). This is a tiny C-program useful for testing
a computer's memory bandwidth in cache and main memory. It's written in pure
ANSI-C and should therefore build on pretty much any system; that's its main
point, to have a 100% portable and therefore comparable bandwidth measurement,
rather than being precise to the umpteenth digit. By default, it performs its
operations on data blocks of size 1024 (-c size) to determine
cache bandwidth and blocks of size 8388608 (-m size) to determine
main memory bandwidth, both for 10 seconds (-s duration).
Operations performed are memcpy() (read-write) and memset()
(write-only) from the C runtime library and a custom blocksum-operator (should
reflect read-only performance; it only sums up the block because you can't just
read memory in C and do nothing with it). You can find some timing results of
running this program here.
NEW (10 Apr 2006) (2612 bytes).
This patch enables Unix versions of PrBoom
2.4.* to access compressed WADs using my open source fastlz library.
It was originally developed for 2.4.0, but works on 2.4.1 just as well and probably will
for the entire 2.4.*-series. Handling compressed WADs is now system-specific because 2.4.*
mmap()s the WADs and requires different source code for Unix and Windows; I also have
a patch for 2.2.4/2.2.5 here which works for both systems, in case anybody's interested. I
developed the fastlz-library for my own Doom port DIY and got really
fond of WAD compression (OK, compared to the sizes of Doom3-mods this is peanuts
either way, but what the heck). WADs can be compressed and decompressed using
armDeu (also open source and multiplatform).
To apply the patch, you'll need the PrBoom source, of course. Copy the patch in your
prboom-source-directory, CWD there and type
"gunzip -c prboom-2.4.0-fastlz.diff.gz | patch -p1". Then copy the
fastlz library in PrBoom's src-directory and build it there. Then build the
PrBoom sources just as you normally would, at the end of which there'll be a linker error
because I didn't change the Makefile and the linker needs fastlz/libfastlz.a.
You can either add that file to the linker line in src/Makefile (look for
prboom_LDADD) or you just CWD to src, copy and paste the link command
that threw the error and add the library manually. Any linker errors still persisting
after that are not my fault ;-). Enjoy.
Some useful scripts
General note: I'm pretty sure the following scripts work on Unix systems only, don't
try them on Windows. I also assume the existence of fundamental utilities like
grep or sed.
NEW (17 Jan 2010) (5153 bytes).
This is a useful shell-script for tagging FLAC files (Free Lossless Audio Codec,
the recommended file format for archiving your CDs) created from CDs via
cdda2wav. Provided you allowed cdda2wav to look up the CD in
a CDDB database, you should have files audio.cddb and audio.cdindex
in the directory with the FLACs. This script has to be executed in the directory of
the CD-RIP you want to tag. It reads the data in audio.cddb
and tags the FLAC files using metaflac (which should be included in most
FLAC packages). The script doesn't convert the WAV files output by cdda2wav
to FLAC but assumes the FLACs are already there (albeit untagged). Tagging the FLAC
files in a seperate step after encoding them is pretty painless because apparently
the FLAC encoder always reserves space for tagging; I've never seen noticeable delays
in any of the 500 albums I've tagged so far. Note that the script calls metaflac
with the switch --preserve-modtime so the files will still have their
original timestamp after tagging; don't mistake this for "nothing happened".
Also note that unless you call the script with the --dowrite switch, nothing
will be written but the commands that would be executed are written to stdout.
This output can usually be fed directly into another shell to actually execute
the tagging (in case you want to do modifications too complex to be addressable with
the scripts' other switches), but there are some exceptions, i.e. tags containing special
characters like the exclamation mark or double quotes. I didn't bother to properly escape
these for output because cases were I need to use the output for tagging are pretty rare
to begin with and these special characters are also pretty uncommon, so it just
wasn't worth it IMHO.
Some notes on parsing: getting artist and album is done by parsing the DTITLE
entry. The usual format convention for this entry is "ARTIST / ALBUM",
which of course raises problems if either ARTIST or ALBUM contain slashes.
In these cases, you'll most likely have to fix this by using the script's
--artist and --album switches. Another thing to watch out for are
DTITLE-entries spreading over multiple lines. I addressed this effect for
track titles, but not for the DTITLE entry, so in case this happens (you'll
have multiple DTITLE entries then) you'll also have to specify the album
(and maybe the artist) by hand. Note that all these cases are very rare (unless maybe
you're collecting AC/DC bootlegs), so trying to address them generically in
a script really isn't worth the effort IMHO.
- --artist string: override the artist tag with string
- --album string: override the album tag with string
- --genre string: override the genre tag with string
- --year string: override the date tag with string
- --performer string: add the performer tag string (not available
in audio.cddb; mostly useful for classical recordings)
- --dowrite: actually write the tags with metaflac, otherwise
the commands that would be executed are written to stdout
- --incremental: incremental mode, tags are added to existing ones. When
not specified (the default), tags that will be written are reset first.
NEW (17 Jan 2010) (166 bytes).
Mini shell-script that reads the tags from all FLACs in the current directory (and below)
and dumps them to stdout. Useful for checking whether
add-meta-data.sh did the right thing.
NEW (17 Jan 2010) (1742 bytes).
A useful Ruby-script which copies FLAC files (and only those) from one directory to
another, alternatively transcoding them to OGG files on the way; I wrote it for my portable
audio player (I only store my CD RIPs as FLACs). In case you transcode to OGG, the script
can dispatch parallel transcodes (two by default), so you can make good use of multicore
machines. The reason I transcode to OGG is not fundamentalism ("bad MP3, good OGG")
but that OGG and FLAC share the same tagging namespace, so all tags in the FLAC files can
be transferred to the OGGs automatically. Requires Ruby Gems and a FLAC-enabled
version of oggenc.
- --src directory: source directory is directory
- --dest directory: destination directory is directory
- --create: when specified, the destination directory will be extended
by the leaf directory of the source path, so if your source is
/home/rips/GreatBand-ShittyAlbum and your destination is /external/player,
the files will actually be copied to /external/player/GreatBand-ShittyAlbum.
Caveat: since the source is most likely a Linux filing system and destination is
usually something like VFAT, this may not always be possible because some characters
that are legal on one are illegal on the other and vice versa.
- --quality floatval: quality for oggenc is floatval.
If this parameter is not specified, files will not be transcoded but copied as FLACs.
- --threads intval: in case of OGG-transcoding only, use intval
threads. Setting this to the number of cores of your CPU is usually the best approach.
You can contact me by email here.
Back to my private homepage.