Please note, my old email address of ralph@inputplus.demon.co.uk no longer works. Please use ralph@inputplus.co.uk instead.
Ossanna and Kernighan’s troff typesetting program has interested me for a long time, ever since reading Kernighan and Pike’s The Unix Programming Environment. I’ve set up the troff.org web site to try and provide a central resource for fellow fans of the program. I’ve still much material to add, but it already appears in first place in a Google search for ‘troff’.
I also kick started the transcription of Dale Dougherty and Tim O’Reilly’s Unix Text Processing which members of the GNU groff mailing list have done a superb job on.
In a previous century I owned a couple of ARM based microcomputers made by the, now defunct, UK computer manufacturer Acorn. As a result I’m interested in seeing the hardware and their RISC OS operating system emulated on modern machines. That prompted a ‘Nirvana for ARM/RISC OS Emulator?’ email to various parties which laid out what I think would be ideal features. We’re not there yet!
ARMulator, written by ARM, is an ARM emulator released years ago under the GNU GPL. One version of it can now be found as part of GNU GDB, other diverging versions can be found in ArcEm and riscose, see below. ARMulator doesn’t emulate or provide an operating system, or any peripheral hardware, like a keyboard, it’s an ARM instruction interpreter.
ARMphetamine is an on-going project by Julian Brown to develop a fast ARM emulator, including dynamic recompilation of ARM instructions to the host processor, currently x86. The source code is available under the GNU GPL. Currently, it’s only used to try and boot Linux/ARM but it could in theory be used in ArcEm or riscose, see below.
ArcEm is an Acorn Archimedes hardware emulator originally by Dr. David Alan Gilbert. It uses ARMulator, see above, to interprete ARM instructions and emulates the hardware of the surrounding machine. The emulated machine is capable of running RISC OS 3.11, and the emulator runs on a variety of operating systems. Being released under the GNU GPL makes it the ideal emulator for future contributions. (Disclaimer: I’ve made some contributions to arcem.)
Archie is an Acorn Archimedes hardware emulator that runs under DOS. Written by Chris Lloyd, it’s stagnated at version 0.9 for some time but Chris is intending to resume development. No source code is available, just executables. The emulated machine works with RISC OS 3.11 amongst other operating systems.
Red Squirrel, by Graeme Barnes, is another closed-source Acorn hardware emulator. This one requires a Microsoft Win32 operating system. It offers a wider variety of emulated processors and hardware than ArcEm or Archie, and private developement versions, and the spin-off commercial product VirtualA5000, use an ARM-to-x86 JIT translator for greater emulation speed. It may one day spread to other operating systems, but since it is currently closed-source I’d prefer to see ArcEm be improved instead.
!emulator, by Jan de Boer, aims to emulate the Archimedes A310 on StrongARM Risc PCs in order to run old software. Various support files containing ROM images are available.
Arculator and RPCemu by Tom Walker are emulators of pre-Risc PC machines, e.g. Archimedes A310, and Risc PCs respectively. Source code is available.
riscose, by Matthew Bloch, is a different approach to ArcEm, Archie, Red Squirrel, and !emulator. Instead of emulating the hardware and relying on a RISC OS ROM image to provide the operating system, as in the original machine, it re-implements the API the OS provides. This means a ROM image that is still under copyright isn’t required. More importantly, when control passes from the ARM executable to the OS, native code built for the host processor is being executed at native speed. (An advanced and well-known similar effort for Microsoft Windows operating systems is WINE.) riscose comes with three alternatives for running the instructions in the ARM executable. ARMulator, see above, is the default and most tested. sleeve, by the late Chris Rutter, is a faster replacement for ARMulator although I’m not sure of its completeness. The last is called ‘native’, and can be used on systems where the host processor is also an ARM. riscose is still in an early stage of development, but it can run CLI programs like a RISC OS port of grep and Sophie Wilson’s Twin text editor. Currently released under the GNU GPL licence, consideration is being given to moving to the GNU LGPL. (Disclaimer: I’ve made some contributions to riscose.)
If you’re starting from scratch and trying to run these programs you may wish to pick up operating system support files from Mike Gilbert’s Archiology web site.
ROM images of RISC OS, and its predecessor, Arthur, are also floating around although they tend to get taken down at the request of the copyright holder when their location becomes too well known. It could be worth investigating Jan de Boer’s !emulator above. Here’s the SHA1 digests and file sizes for some of the ROM images so you can be certain it’s a valid image once you’ve extracted it from your machine; I’d welcome additional ones or contradictions.
arthur-0.30.rom 6aebd686d97dfdf6726fa5f3246ef35b840b286d 524288 arthur-1.20.rom 1181ff9c2c2f3d6d414054ec33b2260404bafc81 524288 riscos-2.00.rom b82a78830dac386f9b649b6d32a34f9c6910546d 524288 riscos-3.00.rom b4fa494d51dd704c9da9653c2acc6acd08cc8cf4 2097152 riscos-3.10.rom 68533e0a93657a879c1697c04f32d517345b1a61 2097152 riscos-3.11.rom 3487729e87bebc9cb51665838c27beff22f7b3bd 2097152 riscos-3.19.rom ba8c7abe0e6c6c5d7138481c6c052425cbc8b8f4 2097152 riscos-3.50.rom c31318e712ee7de92e46f9df6c791b614d4c9304 2097152 riscos-3.60.rom 3cf75aa4d4dc8fe57110a124fbd1560d46c549b1 4194304 riscos-3.61.rom 71e67684e1d22f422ab9c586c6b0f900384e8f14 4194304 riscos-3.70.rom 42c3dd0ae43149849b674ea025cb2206512a5b4a 4194304 riscos-3.71.rom c5fe0645e48894fb4b245abeefdc9a65d659af59 4194304 riscos-3.80.rom 7e461a6aeb9b1cdc03ea734d0c3a9e1a65d3f98a 4194304 riscos-4.02.rom 405d23390882477addd45a05a34f130cc8ecb8c6 4194304 riscos-4.39.rom faf99b27907800ea46c590c5f45e43083d06f2ad 4194304 ncos-1.06.rom 4400bd142eebdc71b7ac1794f2cf7dc39de983e2 4194304 ncos-1.11.rom 7c9e2039bc096038ab236719211a236e9a28192f 4194304
I’ve been trying to read Acorn ADFS discs on a Linux/x86 machine for some time. With the 2.4 Linux kernels progress has been made but problems still remain. Acorn ADFS D, E, and F format floppy discs have 1024 bytes per sector. As I understand it, the kernel’s drivers/block/floppy.c that allows you to mount /dev/fd0, etc., can only cope with 512 byte sectors. Also, ADFS sectors are numbered from zero whereas the Linux floppy driver can only handle sectors numbered from one, although a patch exists to fix this. These points could do with some investigation if someone’s got the time.
Using Alain Knaff’s excellent fdutils I managed to slowly create a disc image of an E format floppy by driving the floppy disc controller directly. This avoids the 512 bytes per sector limitation of drivers/block/floppy.c but doesn’t give a ‘mountable’ device.
cyl=0
while test $cyl -le 79; do
for head in 0 1; do
fdrawcmd rate=2 track=$cyl length=5120 short \
read `expr 4 \* $head` $cyl $head 0 3 5 0x1b 0xff
done
cyl=`expr $cyl + 1`
done
It is also far from ideal since the drive steps across from cylinder zero on every read of a track. Still, it showed reading an ADFS E format floppy was possible and I was planning on writing a small C program using ioctl(fd, FDRAWCMD, ...) that avoided the drive-stepping problem, speeding the whole rip up, when I came across John Elliott’s LibDsk.
LibDsk isn’t well known in Acorn circles; Darren Salt seems to be the only person who I’ve found reference it. It’s intended use is as a library for accessing foreign disc formats by emulators or their related utilities. Hence new versions being announced on the comp.sys.sinclair Usenet newsgroup. It can support a wide variety of operating system floppy formats, including Acorn DFS and ADFS, on a range of operating systems, including Linux, and will work with hardware, e.g. /dev/fd0, and raw disc images. Note, it doesn’t understand the filesystem data, e.g. directories or file permissions, but just the physical format of the media. In addition to the library it builds a few utility programs. dskid(1) tries to auto-detect the format of the given disc. Here is it’s output for an E format disc.
$ dskid /dev/fd0 Driver: Linux floppy driver Sidedness: 0 Cylinders: 80 Heads: 2 Sectors: 5 First sector: 0 Sector size: 1024 Data rate: 2 Record mode: MFM R/W gap: 0x04 Format gap: 0x05 Drive status: 0x28
dsktrans(1) will translate from one format to another, i.e. it can be used to translate from the floppy in /dev/fd0 to a raw image file on disc.
$ dsktrans /dev/fd0 foo.raw -otype raw Input driver: Linux floppy driver Output driver:Raw file driver $ ls -l foo.raw -rw-r--r-- 1 ralph ralph 819200 Nov 22 18:46 foo.raw
Thankfully, it does this much faster than my home-made fdrawcmd solution above. Beware of the strange argument processing used throughout the DskLib utilities before version 1.1.0, they seem to insist of the optional arguments coming after the mandatory ones, completely at odds with the normal Unix convention. Trying ‘dsktrans -otype raw /dev/fd0 foo.raw’ will give a cryptic ‘Identifying disc: Disc rejected by driver.’ error because ‘-otype’ is treated as the input file, which probably doesn’t exist. The man page does mention this. Unknown options are ignored, so giving ‘-otype’ when ‘-type’ is required goes unremarked and the default type is used. Perhaps John would welcome a patch from someone with spare time that makes the argument processing more flexible? dsktrans should be able to write a raw floppy image to a floppy disc too, and dskform(1) will format a disc. I haven’t tried either of these but I see no reason for them not to work.
2006-12-03: Andrew Benham has informed me about his web page: Reading DFS and ADFS floppy disks under Linux.
I’m intending to add here details of Linux’s adfs.o kernel module, including its limitations.
I’ve various bits of Acorn material that I’m willing to sell to a good home. It’s all had one careful owner since new: me. Email ralph@inputplus.co.uk if you’re interested.
ISBN 1-85250-110-3. Part numbers 0470,291, 0470,292, 0470,293, 0470,294, and 0470,295.
Four volume set plus index. Immaculate condition, including box.
ISBN 1-85250-148-0. Part number 0470,296. 139 pp.
Immaculate condition. “This Guide describes the standards of ‘look and feel’ to which you should write a RISC OS application. It covers aspects of designing a new application, and implementing the design...”
I’ve run Red Hat since version 4.1 back in March 1997, although a problem or two I found with RPM updates, especially security-related ones, means I’ve moved from Red Hat 7.2 to Debian Woody and am very pleased with it.
The Amstrad E-m@iler Plus looks like a cheap way, £30, to get an ARM-based machine with half-VGA gray flat screen if its default software can be replaced. I've started collecting a little information on its components and would welcome hearing from anyone else who’s interested in this.
The Emailer Plus’s successor, the Amstrad E3, has a colour half-VGA flat screen and hardware to assist in a videophone implementation. It also uses a more recent processor allowing Amstrad to use the Linux operating system. This in turn means they have obligations under Linux's GNU GPL license. Even though it’s more expensive, at £70, it’s still a reasonable price considering the hardware it contains and is therefore also of interest for re-use with different software.
Has anyone else experienced the otherwise excellent Google Groups failing to thread articles correctly? I started a thread with message A only to realise I’d forgotton to choose a decent subject. So I replied to myself, creating message B which, despite having a correct References header, Google Groups fails to place under the original post resulting in two threads instead of one.
I’ve now heard from Google and they acknowledge it’s a bug but don’t yet have a date for its correction.
I’ve been a fan of RAND’s MH, and now nmh, for a long time. If you’re a competent typist and find today’s mail user agents too slow to process the many emails you receive, take a look at Why Choose MH?, part of Jerry Peek’s book.
Epson ink-jet printers often use ‘Intelledge’ ink cartridges. These have a small chip on them that keeps track of the amount of ink used in the cartridge. This way, when the cartridge is empty, or more precisely when the chip tells the printer it’s empty and it should therefore refuse to print, the owner can’t refill the cartridge with ink thereby avoiding purchasing a new whole cartridge.
Apart from this being mean-spirited of Epson, it also causes problems due to its implementation. The chip on the ink cartridge has small pads on its surface that press against matching springy ‘hooked’ pins when the cartidge is in place. The problem is that sometimes these pins can hook onto the cartridge instead of just pressing against the chip’s pads. One way this can occur is when the chip isn’t sitting squarely on its plastic pegs. The result is a printer that doesn’t work, because it knows there is a problem talking to the ink cartridge, and a cartridge that won’t come out of the printer because it’s been ‘hooked’ by the pins.
Eventually, the cartridge can be removed but this normally results in one or more of the pins being broken. Neither the pins, nor the small plastic clip they fit into, are standard electronics parts, nor are they available from Epson as a spare part, even to a authorised repairer. The normal remedy is to purchase a new print head. As a spare part these tend to cost so much, e.g. £124.55 inc. VAT exc. labour and delivery, that it’s more economical to buy a new printer.
It may be possible to concoct a work-around with soldering iron in hand. I’ve dismantled my Epson Photo 1270 sufficiently to see its possible, but not attempted it yet.
Along the way, I’ve encountered others who’ve had exactly the same experience with the same result: an expensive, typically newish, printer turned into scrap. They may have had some success in solving the problem by now so in case you wish to contact them, they are: Dean Bradley <zdbradley@hotmail.com>, Bryan Lin <blin35@iname.com>, AlanRab <arabinoff@earthlink.net>, Tony Robinson <tonyrobbo@freeuk.com>, and Joris Van Daele <joris@execulink.com>. If they have any news please pass it back to me.
In conclusion, I’d never buy an Epson printer again. Their inclusion of the Intelledge cartridge is attempting to tie the owner of the printer into purchasing expensive Epson ink cartridges. Their implementation of it leads to bent and broken pins yielding an ‘uneconomical to repair’ printer. Their competitors, e.g. Canon, now produce comparable photo printers without the Intelledge hand-cuffs, and have the advantage of separate ink cartridges for each colour whereas, with some of Epson’s models, when you’ve run out of one colour, e.g. cyan, you have to replace the whole colour cartridge despite the other colours being unused.
If anyone has any related information I’d be happy to add it here for the benefit of those that come later.
If you attended Charlotte Sharman Primary School in London, you’re in good company. You may find the Charlotte Sharman Alumni page of interest.
‘Corderoy’ is quite an unusual surname. My immediate family aren’t involved with any genealogical research, but I’ve heard from Brian Corderoy of London, who is. If you’re also researching the surname feel free to email him — ‘briancorderoy at aol.com’. Louise A’Barrow, née Corderoy, would also like to hear from you — ‘wheeliebarrow at tesco.net’.
Also being researched is the Worth family. In particular, James Worth who married Elizabeth Ada Barbary at St. Saviours Church, Battersea on 30th June 1895 and lived at 17 Longhedge Street in Battersea. James’s father was also James Worth and a Veterinary Surgeon. Elizabeth was born at 91 Vauxhall Street on 20th August 1876. If you’ve any information regarding these three please get in touch and I’ll pass you onto the interested parties.
$Revision: 1.57 $