Ghostscript release for Cortex-A8

Despite the compatibility list’s claim that the current RISC OS port of Ghostscript (8.54 RISC OS release 1.04) works on the Cortex-A8 there have been several reports (e.g., in this forum) suggesting that it does not work. Furthermore, the compatibility list claims that GView crashes with a segmentation fault, which does not make any sense. It is most likely that whoever added that entry actually saw Ghostscript crash.

On the Ghostscript for RISC OS download page you can now find a Cortex-A8 compatible release (Ghostscript 8.54 RISC OS release 1.05).

The compatibility list shows whether apps are compatible or not. It does not only list the apps that are compatible but also if they are not what the issues are. I hope that helps to understand the purpose of that list.

In general apps written in C can be recompiled with the Cortex-A8 compatible compiler settings and that should suffice. Assembler parts however will need some more attention to ensure that old ‘quirks’ are not relied upon.

I would like to get some information regarding the compatibility of Ghostscript to correct its entry in the list, which I believe is wrong. So far, three users have reported that Ghostscript 8.54 RISC OS release 1.04 (the version that was current until yesterday and the one to which the list entry refers) crashes on the Cortex-A8, but the list claims it is compatible, which I believe is wrong.

So, has anyone ever got Ghostscript 8.54 RISC OS release 1.04 to work on the Cortex-A8?

The information I have is that the existing port (release 1.04) does not work, but that the new release of yesterday (release 1.05) works.

I can confirm that 1.04 does crash on my system, with a ROM built from the latest source. With !PrintPDF 0.85 and 1.05 of Ghostscript, all seems fine.

Sorry for my misunderstanding. With the latest release of the OMAP3 ROM the 1.04 version of Ghostscript crashes. Looking at the report for GView in the compatibility list it seems that changes in RO5 may have impact on compatibility issues. Just tested your 1.04 and 1.05 version on my beagleboard (running the latest ROM supplied by Jeffrey) and I can confirm that 1.04 crashes whereas 1.05 shows a nice gs> prompt.

The success report in the compatibility list refers to the June 25th ROM release which i have not got laying around. So if anyone else has a copy of that ROM i would certainly be willing to try that to test the 1.04 release of Ghostscript.

Tank, can you try whether GView 1.52 works, please?

I would be surprised if the ROM date had an impact. It would be good if someone who still runs some older ROM build could try.

As for testing Ghostscript, just running it is not quite enough. You really have to view a PS and a PDF file (e.g., via GView) and convert a PS file to PDF (e.g., via PrintPDF) to make sure that the core functionality we are interested in is working.

My initial test, I mentioned above, was to print a page from OvationPro. This creates the PDF (Via !PrintPDF) which I then used to test GView. This causes the following error.

GView 1.52 just opens a white background window with the title “GhostScript output” that has the text “No writable memory at this address” when a PDF is dropped onto the iconbar icon.

I guess the new Ghostscript needs a bit more memory to work. Just set the Wimpslot for Ghostscript a bit higher in GView’s configuration. This worked for me.

I still can’t get GhostScript to work. The latest version 1.05 opens a GView Window saying processing and does nothing further. I should add that this is when it is given a pdf to show. The ROM is a recent one (June or later). I have set the WimpSlot in GView choices to as much as 10MB. I have tried command line with errors like Last Error 2, Unrecoverable error code 1.

Does this happen with every PDF file or just with a particular one? It is still possible that you have hit a genuine Ghostscript bug with a particular file. Does GView show “calling Ghostscript for file/pdf:1”? Setting the WimpSlot to the suggested value (3800k) should be enough, there is no benefit from allocating more, Ghostscript will take care of that itself.

*Wimpslot 4000k 4000k
*run <GView$X> --help

OK I got GView to show a pdf. With settings 60 dpi, Wimpslot 10MB anti-aliasing 4 bits both text and graphics, it took 2 and a half minutes to show a one page 14,175 byte pdf! And the result wasn’t very good. With the same settings except 120 dpi it took 11 minutes to show this one page pdf. It only has text on it! My Nixiyo would do the same in 10 seconds. The answers to Martin’s other questions are all yes. I have had some success at the command line in converting files, but don’t know the command for simply viewing a file.

I think this is down to ‘slow’ USB on the Beagleboard. Try putting everything in a ram disc. It should go much quicker.

The OTG port on the XM is USB full speed only, 480Mbit/s, isn’t that fast enough?

OK, I have stuck the pdf, !GView and a directory, that I have called Scraps, in RAMDisc0, altered one line in the !GView run file so that it uses Scraps instead of the !Scrap in !Boot and, yes, it’s as fast as Nixiyo in showing the pdf. Thanks for suggestion. I probably didn’t need to copy GView to the Ramdisc, but I didn’t want to ‘mess up’ the copy on the ‘hard disc’ (USB stick). The output was also just as good as on my Nixiyo. The first time I tried to create the RAM disc in the Task display, the task manager icon vanished. :-(( I remember this was a problem on early versions of the ROM on the Iyonix. So there’s a bug. As for the OTG port, I haven’t got into using that and don’t have BBxM.

The OTG port on the XM is USB full speed only, 480Mbit/s

Not true :)

Firstly, “full speed” is 12Mbit/s. Secondly, the OTG port supports all USB 1/2 speeds. It’s actually the EHCI port that’s limited to 480Mbit/s (“high speed”); but unlike previous BB models this limitation doesn’t affect the user, since the onboard hub (as with most/all USB 2 hubs) contains the necessary hardware to allow full & low speed devices to be used with a HS upstream port.