Release version of GPL Ghostscript 8.70 for classic Amigas

(webpage updated: 12th Oct 2013)

URL for text only version of this webpage:

NEW: Click for my x86-native Operating System project webpage

Sender email address:

two plus three equals

List of new features in GS870 since release of GS8

Navigate around this webpage by recursively clicking links starting from this index

My x86 Operating System project

pre-emptive multitasking already (2.july.2007)

Fully 64 bit.

Fully multiprocessor x86 OS.

Fully pre-emptive kernel.

<----- NEW!

dont look so glum!

It does everything everyone wants.

An alternative to Vista, heard of Vista?

Challenging Vista with the AmigaOS philosophy,

AmigaOS pioneered the right way to do many things

but they refuse to challenge Vista or Linux.

Vista is 64 bit multiprocessor x86, wake up before it reaches your desk.

It is the Amiga concepts that matter not the Amiga trademark.

Someone must take those concepts into the future and Amiga WONT.

64 bit Unix and Vista can only be overtaken by a brand new design: voila!


There is no warranty for this product you use it entirely at your own risk, if you only write to ram: files and your machine is not connected to other computers then usage will be pretty safe but no guarantee of this is given. A.F.P.L Ghostscript is unconnected with GNU Ghostscript!

PHOTO: novel created from a chapter of documentation with the novel feature. In the foreground is a long arm stapler which is required to staple the middle of the A4 pages. I tend to create 1 novel per chapter. The novel feature correctly deals with page numbers. If there are too many pages you need to subdivide the chapter into sub booklets otherwise the pages become difficult to fold collectively.

A4 pages with 4 pages per side, 2 quid coins showing it is double sided.

The A4 pages are cut in half, and the 2 halves are combined and stapled.

The end product A6 booklet.

Close up showing correctly numbered pages.

PHOTOS: making a titchy A6 booklet from a chapter of a document using the pamphlets feature. I use this feature for documents I am not sure about OR if there isnt much printer paper left. Here are commands for doing this, somedoc.pdf is the document and the booklet is physical pages 97 to 158 (pages 110 and 111 in the last photo are in fact physical pages 128 and 129 for this document):

makedir somedrive:temp_pamphlet
gs:bin/pamphlet somedoc.pdf 97 158 somedrive:temp_pamphlet/temp
execute ram:script1
execute ram:script2

This creates 3 PS documents in somedrive:temp_pamphlet/ which are, and

You then print via gs, this does one side of the pages. Now depending on the printer you print the other sides by printing either or You have to reinsert the pages the right way. You need to reverse the order of these pages and that gives you the pages in the first photo above. You then cut that column of pages in half, put one half above the other and go to the second photo. There is a lot of technique involved, the novels feature tends to be better quality as you dont have to cut the pages.

You need the 22nd May 2007 core and binary archives for this as the system has been enhanced as of 22nd May 2007 (today).

PHOTO: gs:examples/tiger.eps converted to landscape format. This is NOT a graphic rotation but a PS level rotation. The printer will receive a rotated document. The instructions used to generate the image can be seen in the shell in the photo! Note the Workbench backdrop is the previous photo, done via: SYS:prefs/WBPattern and selecting Placement=Workbench, Type=Picture, Picture Name=above picture. The landscape feature is for documents which have been done the wrong way for your printer. Note the aspect in the photo isnt quite right I think that is because 800 x 600 isnt a true aspect: to correctify that you would need to put 2 way resolution args in the "" which counteract the wrong aspect. Actually it is better to correctify when invoking the viewer that way the document remains correct eg -r100x200 is how you do a 2-way resolution.

PHOTO: my whoosh24 PS + PDF viewer viewing gs:examples/tiger.eps on 512MB + 8MB chipmem WinUAE on a 1280 x 800 AMD powered laptop.

PHOTO: example of thumbnails feature created thus:

gs:lib/pdf2ps.amiga "" gs:examples/tiger.eps
gs:lib/pdf2ps.amiga "" gs:examples/
gs:lib/pdf2ps.amiga "" gs:examples/annots.pdf
c:join as
set GSFUNCTION T ; local variables so other shells can do other things.
gs:lib/pdf2ps.amiga ""
unset GSTHUMBNAIL ; remove the settings so other things can be done,
gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE -r300

PHOTO of another thumbnails example:

Useful Amiga links ALD Martin Blom's Linux-x-Amiga cross compilers x86-AROS boot CD


What is Ghostscript8.54?

PS ----->|                  |---> print->|-->Turboprint: max 16777216 colours 24 bit
         |   This port of   |            |-->AmigaOS: max 4096 colours 12 bit
PDF ---->| Ghostscript 8.54 |            |-->inbuilt GS drivers (eg Samsung ML-4500)
         |                  |            |-->ijs (ixemul only)
         |                  |
         |                  |---> view->|-->6 Cyber viewers eg WB truecolor 24 bit
         |                  |           |-->6 AGA viewers eg 262144 colour HAM
         |                  |
         |__________________|---> convert->|-->jpeg

thats what this particular port of Ghostscript is!
It also understands current Postscript at all current levels: 1,2,3 as specified by Adobe and current PDF too.
My contribution to the GPL GS870 source consists of:
  1. A fairly major fixing of Florian Zeillers GS510 turboprint device to make it fully compliant with GS8 onwards. To maximise the future of this device I split it up into 3 devices in line with other GS devices such as jpeg and png. My own viewers are also split into 3 devices. Florian's original device only understands Turboprint 7, whereas I have fixed it to understand Turboprint 3,4,5,6,7
  2. Totally writing from scratch brand new viewers for both graphics cards and AGA. For AGA my work allows you to view PS in HAM8 , and for graphics cards to view PS in 24 bit colour eg on depth 24, 16 or 15 screens. I have written 6 different Cyber viewers and 6 different AGA viewers.
  3. Totally written from scratch are 3 methods for printing via AmigaOS printer including 12 bit 4096 colour printing.
  4. I fully debugged the printer driver for the Samsung ML-4500 600dpi b/w laser printer. (my own printer), at £75 its a real bargain. This is present as -sDEVICE=samsung_gdi. This driver isnt yet ported to GS854 though is in GS813.

As a result this port is a major departure from all other ports (there are many). This big departure from all other Amiga GS ports was out of Anecessity as the original AmigaOS specific facilities were malfunctioning quite severely on GS8:
The Turboprint sources used on all other ports exhibited total failure compiled AS-IS, ie they wouldnt print a single pixel. So a lot of work was necessary to rejuvenate Turboprint.
The original AmigaOS specific viewers would crash quite severely, and after several months of battling with GS8 I finally figured out how to do my own viewers. At this point I begun from scratch a whole suite of viewers (12 in total, 6 Cyber, 6 AGA) plus brand new printer code for AmigaOS and Turboprint.






Download the following archives


makedir somewhere ; >= 35 meg free

NOW DECOMPRESS all 4 downloaded archives to the same directory, gs870core.lha, gsfonts.lha, gs870noixemul.lha OR gs870ixemul.lha, icon_scripts.lha.

This now generates everything in somewhere/ which will be gs870:



This now can be done via the icon script startup, eg by double clicking it. The icon script install needs to be done first which just sets the env variable gs870 to the install directory.

; somewhere is the directory all the archives were
; decompressed to in install summary
assign GS870: somewhere
assign GS: gs870:
assign GSFonts: GS870:
assign gscache: t:
assign Ghostscript: GS870: ; if you have Turboprint + use PS:

; From every shell you use gs870 from type eg:
stack 2000000

; a gs_shell icon could be created with s:gs_shell-startup
; being the above 4 assigns + stack setting followed by a call
; to the normal s:shell-startup




various assigns are required, the assigns incorporate the version no. that way you can run multiple versions of Ghostscript at the same time.
(I could have replaced these 4 assigns by 1 multiassign but then it would have been confusing for someone without the docs).
You need gs: setup for various scripts to function. gs: doesnt reference the version number which reduces project maintenance.
A 5th assign Ghostscript: is needed if you have Turboprint and want to use PS:

SETTING UP gs: FOR script use

Put in the startup:

assign gs: gs870:

This is needed for the AmigaOS scripts in gs:lib and gs:bin to function,



assign GS870: to the directory containing subdirectories bin doc lib examples etc,

assign GS870: somewhere



assign GSFonts: thus:

assign GSFonts: GS870:fonts

GS854 onwards require more fonts than GS8,
Multiassigns are fine eg you can do a multiassign over lots of Ghostscript versions fonts.

GS870 etc can share fonts with GS850, via:

assign GSFonts: GS850fonts:


GS870 needs a new assign gscache: which is a file cache. Assign this to eg t: or ram: eg:

assign gscache: t:



a. Choose or open a shell to run Ghostscript from.
b. Make a big stack: eg type in the shell:

stack 2000000

should be adequate. If you dont do this Ghostscript may fail to run and it wont tell you why! If you dont have much memory you may have to go for a smaller stack, eg 150000.
Any shell you run this port from will need a large stacksize set.


Before you can use this Ghostscript 870 port, you need assigns:
GS870: gs: GSFonts: and gscache: and Ghostscript:
and a large stacksize eg 2000000 from the shell you will run it from. Ghostscript 870 needs to be run from a shell, one of the Turboprint testers Michael Merkel has written a GUI frontend to help run GS8 onwards. There is a more primitive icon interface also.

This info and documentation isnt documented anywhere else so make sure to read it in reverse order beginning at no. 1, as it is in reverse chronological order with the most recent improvements at the top, some portability changes which dont affect the user arent mentioned eg some 68k API calls are unsuitable for other AmigaOS variants and have been replaced. Alternatively read it forwards till you reach things you've already read!

77. 20th June 2010: various ICC colour profile programs written and uploaded, and also libtiff ported. The ICC programs are outside of GS and deal with tiffs jpegs and ICC colour profile files. They interact with GS by converting PDF + PS to tiff using -sDEVICE=tiff24nc and converting tiff to pdf using a libtiff program. Click here for further info.

76. 15th Oct 2009: Major overhaul of the project and GS870 ported, with major increase of supported printers.

75. 6th April 2008: the viewer now begins at the top left of each page, previously it started at the centre.

74. 6th April 2008: the viewer now begins by exactly filling the current window width.

73. 6th April 2008: striking tab makes the viewer exactly fill the current window width.

72. 2nd March 2008: striking 0 makes the viewer remagnify to exactly fit the current window.

71. 2nd March 2008: the viewer remagnifies the first page of a document to exactly fit the window. (unless whooshw is set to 1 in which case the image fits the window width). Further pages are according to 63. below.

70. 2nd March 2008: 68k AmigaOS GPL GS860 is released. GPL has more printer support than AFPL.

69. 2nd March 2008: the viewer is hidden better while the image is being computed.

68. 2nd March 2008: the viewer now gives the page number and document name in the window title.

67. 2nd March 2008: the assigns have been enhanced, the binary just needs 2 assigns now: gs860: and gs860fonts: and users just need one assign gs: this means the documentation and scripts can remain unchanged across versions which will speed up doing new ports.

66. 2nd March 2008: a new icon script for multiselect conversion has been done, not fully betatested but it functions fine on 68k. It allows you to multiselect from a requester which documents to convert.

65. 2nd March 2008: the viewer usage info window now only appears on the first page of the first document viewed in a session. Next document you view there is no info window.

64. 2nd March 2008: error messages as regards memory allocation for various viewer buffers now only appear on the first page of the document.

63. 2nd March 2008: when viewing a multipage document the viewer now opens the next page with a window of the same size, position AND magnification.

62. 2nd March 2008: a new env variable whooshaa makes the viewer anti alias everything by default. set this env variable to 1 for this. This was requested by Tony Pascoal.

61. 2nd March 2008: 4 new env variables controlling the viewer window: whooshxpos controls the x position of the top left, whooshypos controls the y position of the top left. whooshwstart controls the width of the initial viewer window and whooshhstart controls the initial height. These were requested by Joseph Duchatelet.

60. 10th Feb 2008: I created point and click icons for viewing documents, and converting to jpeg or PS.

59. 22nd May 2007: all the scripting mechanisms now are via "execute" and not directly as WinUAE keeps losing the script s flags from script files. This is a workaround enhancement specifically for WinUAE use.

58. 11th May 2007: many inadvertent references to gs850 have been removed from the novels, pamphlets, books and billboards features.

57. 14th Jan 2007: 68k-AmigaOS AFPL Ghostscript 8.54 released,

56. 17th June 2006: Make image transformations permanent by pressing p for p.ermanent.

55. 17th June 2006: Make text more coarse or bright colour text more delicate by pressing w, an upside down m representing the opposite of the function m no 54.

54. 17th June 2006: Make text more delicate by pressing m. I call this "maximum-alias". Is a customisation of the anti-aliasing feature 50.

53. 17th June 2006: New viewer sharpening feature, press s to get a sharper image. Experimental, done out of curiousity, is just a na´ve deblurring.

52. 17th June 2006: New viewer blurring feature, press b to get blurring via each pixel replaced by the average of the 3x3 surrounding square.

51. 17th June 2006: Much faster averaged zoom zoom-out, via many tricks. Now reasonably fast even at 400dpi. Requires a lot of memory.

50. 14th June 2006: For the whoosh24 viewer on cybergrafix machines with lots of memory there is now optional anti-aliasing. Just press a to a.nti-alias the image and u to u.ndo this. Only available for the original magnification and zoomed in magnifications. Zoom-out instead uses the colour-averaging instead of anti-aliasing.

49. 14th June 2006: The viewers now contain colour-averaging zoom-out. When computing the image each output pixel is the average of all the contributory input pixels. This makes the image always look "photographic" as you zoom out.

48. 14th June 2006: some shell output is now to a pop up window. eg if you press space or v in the viewer. The v option now also shows the physical page number.

47. 20th Jul 2005: I've customised GS850 to do "BOOKS". Here you input a PDF document doc.pdf and it outputs 2 PS files one containing the odd numbered pages and the other the even numbered ones. You then print the odd pages document. Reinsert the pages and print the even numbered ones for a double sided printout. You can choose between forward and reverse page numbering for the even numbered pages. A blank even numbered page is automatically generated if it is required.

46. 18.jul.2005: I've customised GS850 to do BILLBOARDS, here you input a document and for each page a whole series of pages are output: you can cut these out and they will exactly fit together to form a huge image eg a billboard.

45. 16.jul.2005: I've customised GS850's source so you can now create novels. This prints 2 pages per page side so the double printouts rearrange into a correctly numbered novel.

44. 15.jul.2005: I've customised GS850's source so you can now create pamphlets and create thumbnail documents Pamphlets puts 4 document pages on each side of a physical page, so if cut in 2 horizontally the cut pages recombine into a correctly numbered pamphlet. Thumbnails fits eg 25 pictures 5 x 5 on a page. (or 9 or 16 etc).

43. 14.jul.2005: I've customised GS850's source so you can now view and print pdf and ps documents in landscape

42. 26.jun.2005: for the viewers 5 will now recentre the image, :requested by someone.

41. 26.jun.2005: there is a new env-variable "whooshreverse" which makes scrolling happen in the reverse direction. Set it to 1 to reverse scrolling and 0 the default for normal scrolling.

40. 23.feb.2005: control-C no longer crashes GS850. use control-C from the shell to fully exit the program in the middle of a program.

39. 23.feb.2005: new keyboard commands for the viewers: you can use the calculator keys of your keyboard to move 1/2 a screen in the 8 directions via 1, 2, 3, 4, 6, 7, 8, 9. Also + and - are now alternative ways to zoom-in and zoom-out. You can use the same keys from the main keyboard as well. The letter c will now give you a framecount on the shell.

38. 23.feb.2005: x86-native-aros BitMapScale() rescaling bugs fully resolved now, via my own rewriting of rescaling. My own code now does the rescaling in 68k cybergraphics as well. For AGA the OS is used.

37. 28.jan.2005.730pm: Samsung driver ported to GS850. So as of today GS850 fully supercedes GS813 here.

36. 27.jan.2005: AFPL Ghostscript 8.50 released for 68k-AmigaOS and x86-AROS.

35. 8.nov.2004.midnight: Morphos noixemul port attempt made available, use at your own risk. Use the nofpu 68020 port if you encounter any problems.

34. 1.sep.2004: Cary Driscoll has sent me a new version of his Final Writer to PDF script.

33. 10.jul.2004: feedback based improvements to PS: and Turboprint instructions,

32. 9.jun.2004: x86-AROS port of GS813 complete and available for download.

31. 19.may.2004: linux-hosted gcc-3.3.1 for x86-AROS ported to 68k-host, enables port of GS813 to x86-AROS mentioned on 9th Jun 2004.

30. 18.apr.2004: feedback that only the nofpu 68k port of GS813 should be used on Morphos. (both fpu and nofpu 68k versions of GS8 were fine on Morphos)

29. 28.mar.2004: Cary Driscoll sent me a Final Writer to PDF script

28. 24.mar.2004.3pm: Have created 2 AmigaOS shell scripts for converting ps to pdf via gs: GS813:lib/ps2pdf.amiga and GS813:lib/ps2pdf.full.amiga, Read these 2 scripts for usage info. Obtain these scripts by decompressing as explained in no.27 below. Further similar scripts will be done eventually,

27. [removed this entry as its no longer relevant.]

26. 22.mar.2004.4pm: UPGRADED GS8 TO GS813! involved a lot of tidying up and reorganising the internal code. Future versions of GS should happen much faster, though I wont try and track each and every version.

25. ??.Mar.2004: control-C now results in the program exiting with return value 20 instead of 100 as it was previously,

24. 5.mar.2004.midday: various fine tunings of zoom + scroll acceleration:

i. screen flashes when you reach the upper and lower bounds,

ii. flit steps are finest possible.

iii. delays between flit steps removed,

iv. upper and lower size filters brought in wherever relevant to prevent floating point overflow,

23. 4.mar.2004.11am: 2 new env variables to control zoom step and zoom acceleration step, whooshzoomstep and whooshzoomsubstep eg:

setenv whooshzoomstep 1.05
setenv whooshzoomsubstep 1.01

:this would zoom you in by a factor of 1.05 each time you press up-arrow, and if you kept left-shift down and typed up arrow 3 times this zoom in factor would be increased to 1.05 * 1.01 * 1.01 * 1.01 ie 1.081816,

22. 4.mar.2004.11am: If you type 'v' from the viewer it now shows you what the current keyboard scroll speed is.

21. 4.mar.2004.11am: zoom + scroll acceleration mechanism introduced in no. 20 below now lets you "see" what the new zoom or scroll step is by flitting the image back and forth.

20. 1.mar.2004.345pm: you can speed up or slow down keyboard-scroll and zoom now:

Left-Shift+Up-Arrow	=> speed up zoom by a factor of 1.005 per key press
Left-Shift+Down-Arrow	=> slow down zoom by factor of 1.005
Left-Shift+Right-Arrow	=> speed up keyboard scroll by 1 pixel per key press
Left-Shift+Left-Arrow	=> slow down keyboard scroll by 1 pixel per key press

19. 1.mar.2004: due to repeated requests you can now scroll in all 4 directions via the arrow keys. The new default mechanism for this is to type control-arrowkey. However if you wish you can customise this eg to CAPSLOCK-arrowkey, ie CAPSLOCK will toggle between zoom and scroll for the up down keys. This is how you customise it, you use new env variable whooshqualifier, and set to any of the following values, default==3==CONTROL

Right SHIFT		1
Left ALT		4
Right ALT		5
Left Amiga		6
Right Amiga		7

So eg

setenv whooshqualifier 2
will make CAPSLOCK toggle the up-down arrowkey behaviour between zoom and scroll. CAPSLOCK is not the default as toggle mechanisms can be confusing. Defaults need to be the safest possible options.

Technically speaking whooshqualifier can be set to any of the IEQUALIFIERB_#? values in include file devices/inputevent.h provided it makes sense EXCEPT left-shift as this already has a meaning. Really the above list looks like the useful values.

18. 1.mar.2004: Greatly improved keyboard scrolling. I noticed that the original scrolling caused a mouse sleep for every scroll step. (putting in the mouse sleep feature (no.11 below) is yielding dividends). The keyboard scrolling is now 10 times faster and much smoother with only very occasional mouse sleeps. Unset the whoosharrowspeed env variable as the new default of 5 seems sufficiently good.

17. 1.mar.2004: I found a subtle viewer bug, the keyboard commands were all case sensitive, ie uppercase commands were ignored eg via CAPSLOCK. This has been fixed: keyboard commands are now case insensitive.

16. 1.mar.2004: Sometimes requests come for less Screen Beeps, you can switch off all screen beeps except one on AGA via env variable whooshbeep. AGA has a bug where the lower 4 bits of the blue component are ignored. The fix for this bug requires a screen beep for the new correct colours to "happen". To switch off screen beeps:

setenv whooshbeep 0

15. 1.mar.2004: people keep asking for this, so here it is:

c:version gs
now produces a meaningful result. The output of the command is non standard as I dont use or like version numbers (too arbitrary and meaningless).

14. 1.mar.2004: ESC key will now quit the viewer, this was requested very recently,

13. 1.mar.2004: viewer shell output can now be fully switched off via env variable whooshquiet, BEWARE: this will currently switch off all error messaging. Switch off viewer shell output thus:

setenv whooshquiet 1

:people keep asking for this, so I have done it. Note that shell output will also tell you all env variables values used the first time they are read in.

12. 22.jan.2004: The timeout for the viewer to discard scrolling events has been changed, this results in much nicer scrolling behaviour. The timeout used to be 0.1 seconds, now it is 0.33 seconds. A new env variable has been introduced to control this timeout: whoosh100 this measures in 1/100 seconds the timeout. If this number is either too large or too small scrolling becomes less pleasant. Too large causes timelag, too small causes jumpiness.

11. 22.jan.2004: The viewer mouse pointer now sleeps during rescaling, this way you know that scrolling has halted briefly due to AGA thinking! This is relevant for when you scroll around after zooming in. You will realise eg on AGA that rescaling is a relatively slow process.

10. 22.jan.2004: Some irrelevant intuition events have been removed, removing some annoying viewer timelags.

9. Turboprint specific gs8 cli args have been reconnected, click here for further information

8. colour + b/w viewers now available for depth-8 WBs on graphics cards, also available now are depth-8 custom screen viewers for graphics cards.

7. ironical feature: the viewers now uses SIMPLE_REFRESH windows for the viewers instead of SMART_REFRESH. SIMPLE_REFRESH is smart! This results in faster and better behaved viewer graphics. It should also require less chip ram, all window refresh is now done by the viewer code. The problem with SMART_REFRESH is that there are 2 agents of refresh, namely the program and the OS. This makes it inefficient also it requires extra layers+regions chip ram. The SIMPLE_REFRESH viewers now feel much nicer.

6. The env variable whooshw has now been extended to cover all custom screen viewers. Previously it only applied to the WB viewers.

set whooshw 1 

:this command makes the viewer recompute the image resolution so it exactly fills the screen width taking into account window border sizes. I could do a height version as well but not sure if this has any value. Note that the underlying image will exactly fit the width, however the viewer window itself may be less than full width because of env variables whooshviewx, whooshviewy, whooshxsafe, whooshysafe. So eg on AGA super-hires the viewer window width would only be 800 pixels by default.

5. There is now an option for non-interleaved BitMaps, such BitMaps are better for low chip ram situations on AGA setups. This feature is probably irrelevant for Graphics cards as they dont use bitplanes. The disadvantage of non-interleaved is that when the viewer image is changing it doesnt look clean. As always there is a tradeoff, if there wasnt a tradeoff then there would be no need for an option!

Anyway to use non-interleaved BitMaps you do:

set whooshinterleave 0 ; => non interleaved BitMaps

Note that WB windows are always interleaved so the env variable has no effect for the WB viewers.

4. For AmigaOS printing if BitMap allocation fails eg if env variable overhead is too high, then instead of giving up the code now repeatedly halves the overhead till it either succeeds or hits 0!. So if you tried 100meg overhead it would try in turn: 100meg, 50meg, 25meg, 12.5meg etc till it reaches a 1 line bitmap, if the 1 line bitmap fails it gives up.

3. New env variables have been introduced to restrict the viewer window size, this has the effect of freeing up chip memory to be available for the scroll space. This will mainly be of use to people with low chip memory situations on AGA.

The env variables and example usage:

set whooshviewx 100 ; will restrict viewer window 
                    ; to width 100 pixels
set whooshviewy 200 ; will restrict viewer window 
                    ; to height 200 pixels

2. There was a slight bug in the original release version with regards to env variable whooshscreen, if set as a local variable it was ignored. This has now been fixed!

So in the original release you had to type

setenv whooshscreen magic_number

Now you can do what was actually intended namely:

set whooshscreen magic_number 

1. Other minor changes: default res is now 74dpi x 74dpi, this is the maximum integer res that fits completely in a default width 640 window for typical pages.

:the program needs "safe" default values so first time users get best program behaviour.

Cyber 1 bit custom screens erroneously had "AGA" in the title, this has been fixed!


gs:bin/gs -h

This will list out a lot of info, eg important switches, and a list of all current devices. With GS854 onwards the device list is now alphabetically arranged.





set print 0 ; printer off
set window 1 ; viewer on
set whooshsuper 1 ; WB on
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/annots.pdf

How to use the viewer!

The GS> prompt



set print 0 ; printer off
set window 1 ; viewer on
set whooshsuper 0 ; WB off, custom view on
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/annots.pdf

Select a screen of depth 15, 16 or 24. The choice of depth is up to you, higher depth == more colours but probably slower.

How to use the viewer!

The GS> prompt



set print 0 ; printer off
set window 1 ; viewer on
set whooshsuper 1 ; WB on
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/annots.pdf

With GS8 you have to use -sDEVICE=whooshg, whereas with GS854 onwards you can use either -sDEVICE=whoosh8 or -sDEVICE=whooshg

How to use the viewer!

The GS> prompt



set print 0 ; printer off
set window 1 ; viewer on
set whooshsuper 0 ; WB off, custom viewer on
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/annots.pdf

NOTE: With GS8 you have to use -sDEVICE=whooshg, whereas with GS854 onwards you can use either -sDEVICE=whoosh8 or -sDEVICE=whooshg

Fastest viewing is via a depth 8 Cyber screen, these appear to be functioning correctly now. If they fail then try out depths 15 , 16 or 24.

How to use the viewer!

The GS> prompt



set print 0 ; printer off
set window 1 ; viewer on
set whooshsuper 1 ; WB on
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/annots.pdf

How to use the viewer!

The GS> prompt



set print 0 ; printer off
set window 1 ; viewer on
set whooshsuper 0 ; WB off, custom view on
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/annots.pdf

Fastest viewing is via a depth 8 Cyber screen, these appear to be functioning correctly now. If they fail then try out depths 15 , 16 or 24.

How to use the viewer!

The GS> prompt





For AGA this is actually the default viewer so you can just type:

gs:bin/gs gs:examples/tiger.eps
gs:bin/gs gs:examples/annots.pdf

However you may have various env variables set from trying out other viewer options so the full way to use this viewer is:

set print 0 ; printer off
set window 1 ; window on
set whooshsuper 0 ; wb off == custom on,
set whoosh216 0 ; 216 colour off == HAM8 on
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/annots.pdf

How to use the viewer!

The GS> prompt

Note that zoom in respects the HAM8 structure but zoom out doesnt. Thus naive zoom in is fine, but if you zoom out beyond the initial resolution the image is imperfect.



set print 0 ; printer off
set window 1 ; window on
set whooshsuper 0 ; wb off == custom on,
set whoosh216 1 ; 216 colour on == HAM8 off
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/annots.pdf

How to use the viewer!

The GS> prompt

This viewer is good for simple colour docs as well as for colour text: HAM8 isnt so good at sharp colour changes.
If you want realistic colours use the HAM8 viewer.



set print 0 ; printer off
set window 1 ; window on
set whooshsuper 0 ; wb off == custom on,
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/annots.pdf

NOTE: With GS8 you have to use -sDEVICE=whooshg, whereas with GS854 onwards you can use either -sDEVICE=whoosh8 or -sDEVICE=whooshg

How to use the viewer!

The GS> prompt

For AGA 256 shades of gray viewing is only available thus on a custom screen.
This viewer has the advantage of photorealism (albeit in gray) and sharp "colour" changes. Compare with 216 colour viewer which gives sharp colour changes but no photorealism, and the HAM8 viewer: photorealism, pseudo-18-bit colour but no sharp colour changes.
:You can't win!



set print 0 ; printer off
set window 1 ; window on
set whooshsuper 0 ; wb off == custom on,
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/annots.pdf

How to use the viewer!

The GS> prompt

This is the fastest render method and fastest viewing.
It is the only viewer option that uses 1 bit plane, this makes it dazzlingly fast. The dithering is not wonderful though!
If you need to browse through a 200 page pdf file for info, use this method.



set print 0 ; printer off
set window 1 ; window on
set whooshsuper 1 ; wb on == custom off,
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/annots.pdf

How to use the viewer!

The GS> prompt

This viewer allows you to view your doc on the WB screen which can be convenient. The colours are allocated via the OS, they arent perfect, the higher your WB depth the better the colours. I think the colours are acceptible on a 16 colour WB, even an 8 colour WB is alright actually. If you want perfect colours use the HAM8 custom screen viewer



set print 0 ; printer off
set window 1 ; window on
set whooshsuper 1 ; wb on == custom off,
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/annots.pdf

How to use the viewer!

The GS> prompt



To exit from the prompt type quit eg:

GS> quit

The GS> prompt is a Postscript interpreter prompt, you can enter any Postscript language statements which then accumulate. You can also print or view another doc file by same method as preceding doc file thus, eg you wish to process gs:examples/tiger.eps you then type:

GS> (gs:examples/tiger.eps)run





Click on a point on the image and drag the mouse, the image should move with the mouse. That's it!



Try normal scroll first. Now click + release right mouse button. The image should start scrolling automatically, it uses the most recent nonzero normal-scroll velocity. When it hits the image boundary it will bounce off, ad infinitum.
While automatic scrolling is happening, try doing normal scroll by dragging the left mouse button, on releasing left mouse button automatic scroll now continues in the direction you pushed the image.
Click right mouse button again to switch off the facility.
Right mouse button toggles on and off the automatic scroll facility.



This facility only becomes available after the initial render is complete: wait till the screen flashes and then you can use it.
Naive zoom is based on zooming into and out-of an unchanged underlying bitmap. So as you zoom in the pixels become bigger!
It is nonetheless quite useful and also forms the basis of the hacked proper zoom. As the underlying bitmap is unchanged it is quite fast and seems quite useful. Although the underlying bitmap is unchanged you have to do quite a bit of zooming in before you notice the pixels.
The pixels anyway are quite interesting to study!
Naive zoom is done via the keyboard, press up arrow and you zoom in. Keep the key depressed and you zoom in continuously. On key release possibly 2 extra zoom ins occur. It is better to keep the key depressed continuously instead of pressing it repeatedly, the reason is that if you press the key repeatedly every single key press is queued up by the OS and acted upon. OTOH if you press the arrow key continuously the OS only queues up approx. 2 key events.

key meaning
Up arrow rapid naive zoom in
Down arrow rapid naive zoom out
left arrow (<--) scroll left
right arrow (-->) scroll right
Left Mouse button Direct scroll image by click and drag
Right Mouse button Toggle on or off automatic scroll
h h.alve the image size
d d.ouble the image size
r r.eset to original resolution
v v.alue of current zoom is echoed to the shell
q or ESC or CLOSEWINDOW q.uit, same effect as clicking closewindow

If you type an unrecognized key such as y then the shell will echo a list of currently recognized keys + what they mean.
You can zoom out till the image vanishes into 1 pixel, and you can zoom in until 1 pixel fills the screen.
The interpretation of the 4 arrow keys means that if you have a wheel mouse you can move left + right + into + out-of the image. I havent got a wheel mouse myself so I have never tried this. Apparently the wheel + mouse movements are translated into arrow events.
To speed up naive zoom, shrink the viewer window. If the window is half the size then the viewer will become 4 times as fast.
If using a custom screen viewer then you can also speed things up by selecting a lower resolution screen from the screen requester.
:eg lo-res should be 8 times as fast imaging as super-hi-res-laced.



If you use naive zoom the pixels grow bigger as you zoom in. What you may want is to now have the image rerendered at a new higher resolution so you get same image but with tiny pixels. This is how you do it, its a hack-mechanism as I havent found a way to make GS8 do this directly:
On each page of a doc, using naive zoom select a view you like and press z. z==z.oom.
Do this on each page if it is a multipage doc. Now exit GS8 completely, ie at the GS> prompt type quit

GS> quit

Now rerun GS870 from scratch with the identical command line you used before, on each page this time you will get the view you selected first time round with the new resolution.
This is done via global env variables zoom#?. On this second zoomed in viewing you can repeat the procedure by typing z on each page at a selected view.
Each time the zoom#? env variables are read in and immediately deleted after being read in. If you wish to reuse them several times then make a backup of them via:

copy env:zoom#? somewhere



For faster viewer graphics use a custom screen viewer with a lower resolution, eg Hires will be 4 times as fast as super-hi-res-laced.
Also to speed up the graphics shrink the viewer window, if you halve the window size then graphics should speed up by a factor of 4.
So if you follow both of the above tips you get a stunning speed up of 16!
On AGA if you use 1 bit b/w custom screen viewer that gives you a further speed up of 8, so combined with the above 2 tips you get a speed up of 128!!
:simple maths has impressive consequences with this program!
For graphics cards the 1 bit viewer can be done at depth 8 which gives you a further factor of 3 ie total speed up of 48,



Ghostscript inbuilt printer drivers dont know about AmigaOS, so to print directly via them you have to use a trick, example: epson driver, type all on one line:

gs:bin/gs -sDEVICE=epson -dNOPAUSE -sOutputFile=par: tiger.eps

A different method which I prefer is to use printer binaries, type all on one line:

gs:bin/gs -sDEVICE=epson -dNOPAUSE -sOutputFile=ram:annots%d annots.pdf

Producing files ram:annots1, ram:annots2, etc, to print page 4:

copy ram:annots4 par:




ICC colour profiles

Background of the problem

Methodology of using ICC colour profile files

ICC program downloads

Speed optimised conversion between ICC profiles

Using colour profiles with GS

Background of the problem

If you take a photo with a digital camera, that is a jpeg. You view that on your monitor as an onscreen image A. Now you print that with your printer on 75g/m2 paper and get a printed image B. You print again on 160g/m2 paper and get a printed image C.

We have 3 images now from the same jpeg: A, B, C

And we have a problem: the colours are different in each image!

Also if we use paper by a different manufacturer we also get different colours. Printer paper is in fact not white but ALWAYS has a tint, as can be proven by holding the paper next to a white screen on a monitor. There is equipment which will measure this tint!

Each image on its own looks kind of correct, but the different images just do not agree on many colours.

If you use a 35mm scanner you get an even worse problem that each brand of film has different biases. The scanner has a fixed interpretation of colours, but a Fuji scan is biassed to green (or blue?) and Kodak to red (IIRC).

Basically each medium and each machine has a different bias.

What is needed is a way to counteract the biasses so that ALL devices and media agree on each colour, at least as long as a colour isnt beyond the limits of the machine eg a monochrome printer just cannot express green but you would want it to agree with a monitor on grey scale images.

ICC colour profiles are THE industry established way to do this and is based on work that goes back to at least 1931. The ICC standard is backed by a huge amount of major companies including Microsoft, Adobe, HP, Polaroid, Eastman Kodak, NEC, etc.

A device such as a monitor, camera, scanner, printer uses its own private coordinates which we will refer to as RGB for the typical case where there are 3 coordinates for each pixel which quantify how much red, green and blue. Without colour profiles RGB is the RGB your monitor uses.

And usually each coordinate will be an 8 bit unsigned integer 0, 1, 2, ... 255. But the same RGB coordinates eg R=50, G=100, B=150 will look different on different devices.

A printer typically has 4 cartridges Cyan, Magenta, Yellow and blacK. CMYK, but the driver typically works with an RGB image, eg the bitmap of a jpeg. The driver then converts the RGB coordinates into CMYK, but we regard the driver as being part of the hardware! Some printers have 6 cartridges but the extra 2 are light magenta and light cyan, which is an optimised form of CMYK.

Thus the device coordinates could be other things than RGB but RGB is the usual, even when the low level hardware eg ink powder is CMYK. I only look here at RGB with 8 bit components as that is already way beyond mainstream printers which are 1 bit per component.

Usually a digital camera and a monitor will agree, but unfortunately other devices dont agree on the same RGB values. And eg a Samsung camera produces different colours from a Sony.

What the ICC colour profile does is measure the absolute colours produced by the device's RGB interpretation, by measuring a set of sample RGB values and then interpolating the measurements for the unmeasured values.

By measuring absolute colours relative to an absolute illumination we can now convert RGB coordinates from one device to another and preserve colours.

One form of absolute measure of colour is CIEXYZ, which uses 3 ABSOLUTE coordinates X, Y and Z. These coordinates correspond to the nerve impulses of the RGB cones of an average observer multiplied by a 3x3 matrix so that one coordinate is the brightness.

Basically the eye is regarded as a device and CIEXYZ maps the device RGB to the eyes coordinates which means CIEXYZ is LITERALLY the colour seen by the eye. The measurement itself is done by machine. Because it models the eye's response, CIEXYZ deals with the problem of "metamerism" where different colours look the same: eg R + G looks like Y.

When you view Y the R and G cones of the eye respond, this means that the perception of colour is not absolute and is ambiguous. Hardware also has its own ambiguity, eg different RGB values can look the same on the monitor or when printed.

digital cameras, jpegs and monitors TEND to use a standardised icc colour profile called sRGB. This is why there tends to be no problem when using these. But once you get more adventurous you run into the problem of colour incoherence between devices. The sRGB profile on Windows XP is stored at somewhere like:


and you will find plenty of other icc colour profiles in the same directory, HOWEVER just one profile is relevant to a particular plan. Use the wrong profile and you have garbage. A profile is NOT some choice for you but is decided by the hardwares biases. ie you cannot just go and use any profile! The above Windows directory can contain a lot of colour profiles, but typically none are relevant to you other than sRGB.icc.

ICC colour profiles are ????.icc or ????.icm, thus you can search for them on another OS if you have an Amiga emulator using c:list from a shell thus:

c:list some_directory all files pat=#?.ic(m|c) lformat=%p%n

With this sRGB profile for instance R=255, G=0, B=0 has XYZ coordinates 0.4124 0.2126 0.0193

if you use a 35mm scanner on Windows this will create an uncompressed tiff file where the bitmap uses the scanners hardware specific RGB coordinates and embeds an icc colour profile which counteracts the biasses of both the scanner and the scanned film brand. ie if you scanned a Fuji and a Kodak film of the same image the profile converts the 2 bitmaps to the same colours as the original scene.

Another way to look at it is that RGB images are in fact palette images, where the RGB coordinates are the palette colour and the ICC colour profile is the palette to what your eyes see.

In the early days computers used fixed palettes, then the A500 used retargettable palettes. Then computers used truecolour and palettes became obsolete. But today palettes are used again, and these are ultrasophisticated palletes. Creating perfect imagery.


Methodology of using ICC colour profile files

Thus to convert images between devices so that the colours agree you need an icc colour profile for each device.

When you buy hardware, search the Windows CD for the hardware for files #?.icc and #?.icm in case they have supplied ready made colour profiles. For scanning 35mm, colour profiles are very expensive and you have to rely on ready made ones. eg if you scan a film from 1950 you can hardly calibrate that today!

For printers there are companies who will create an ICC profile for your printer for 15 pounds. You download say a tiff file with sample colours, print this without colour correction, post it to them and they will email you a colour profile file.

You will need a colour profile for each brand of paper you intend to print with, and each brand of ink in case you decide to use cheaper imitation inks.

I do NOT address here the problem of obtaining the ICC custom profiles, you will have to get those either from the hardware's CD or from profiling companies. Or you can find them on Apples and Windows. In fact I cannot create ICC colour profiles as that is a HARDWARE problem and I only look at software problems. Do a google search for "custom ICC profile" to get your printer software calibrated.

For jpegs and tiffs without profiles, the sRGB.icc profile will usually work. Tiff embeds profiles, but libtiff doesnt interpret the profile in any way, software which views the tiff may or may not utilise the profile. To guarantee the colours look alright you need to manually remap the tiff to the sRGB profile using the programs here.

ICC program downloads

The download of my own programs is icc_programs_fpu_201011190012.lha, icc_programs_68k_nofpu_20101107.lha, and you also need the programs of libtiff libtiff3.8.2.lha. icc_programs_fpu_201011190012.lha can be just decompressed and used without any install. libtiff3.8.2.lha needs to be decompressed and you need to assign tiff: to the directory. If you use Geekgadgets you can decompress it to gg: and you must also assign tiff: to gg:

For Morphos you need the nofpu version.

All the programs when run without args will echo usage info.

Each program dealing with jpegs uses libjpeg and each program dealing with tiffs uses libtiff, and each program dealing with ICC colour profiles uses icclib.

The programs work via my own intermediate simplified bitmap format which I call .bitmap. To work with an image such as jpeg or tiff you need to convert that to a .bitmap file. The .bitmap format is very straightforward: it begins with the string "bitmap", followed by a space char, followed by the bitmap pixel width written in ascii decimal eg 123 or 000123 etc, followed by a space followed by the bitmap pixel height in ascii decimal, followed by a space followed by the rgb bytes.

I have now also implemented a CMYK form of .bitmap's, and my software will automatically process between RGB and CMYK bitmaps. This is necessary for using CMYK ICC profiles and to have a CMYK profile made for a printer.

All my ICC programs will echo usage info if run without args, the usage info does improve with time, so you should occasionally find the usage info from the program itself and not from here.

The ICC programs here may not be redistributed in any way without my permission.

For example if you want to work on a jpeg xyz.jpg, you need to convert it to xyz.bitmap thus:

jpeg_to_bitmap xyz.jpg xyz.bitmap

If you want to work on a tiff file xyz.tif then you convert it to abc.bitmap thus:

tiff_to_bitmap xyz.tif abc.bitmap

if the tiff file has an embedded icc profile this will be output to abc.icc and the program will echo this action. And if the tiff file has dpi info, this will be output to abc.dpi

For instance say you have a 35mm scanner which outputs tiff files with embedded profiles and you want to view the tiff on an sRGB monitor using a jpeg viewer which doesnt deal with colour profiles AND you want to print the image with a printer with colour profile printer.icc


tiff_to_bitmap xyz.tif abc.bitmap

This creates abc.bitmap and abc.icc

Now you need to remap this bitmap with profile abc.icc to sRGB

bitmap_icc_icc_cached abc.bitmap abc.icc abc_sRGB.bitmap sRGB.icc p p cache_directory

cache_directory is a directory initially empty, which gradually fills with cache info. It needs to be on a volume with a lot of free space.

You will need to obtain sRGB.icc from someone with Windows as explained above.

Here the p p args are the "rendering intents", p = perceptual, a = absolute, s = saturation, r = relative, P = absolute perceptual, S = absolute saturation. These are IDENTICAL to the options you see on Windows XP printer drivers!

The best options seem to be p p and r r. Usually you should use p p for everything unless you have a good reason not to!

The first rendering intent is that for converting the input image to XYZ, and the second intent is that for converting the absolute XYZ to the second device.

Its best to use perceptual or relative for everything ie p p or r r.

abc_sRGB.bitmap is now the same bitmap relative to the sRGB colour profile. Thus if you now convert this to jpeg it will view with the correct colours:

bitmap_to_jpeg abc_sRGB.bitmap abc_sRGB.jpg 1

The last arg is a scaling factor which usually is 1. Higher numbers are just to counteract jpeg artefacts. But now I use tiff files instead which dont have artefacts. ie if you set the last arg to 2, it will double each pixel to 2 x 2, and these are then subject to jpeg artefacts.

if you view abc_sRGB.jpg with ANY jpeg viewer it will now have the correct colours, IDENTICAL to the colours you see on Photoshop. In fact I use Photoshop to verify if I have coded correctly! As Photoshop is DEFINITIVE on the ICC idea. ICC is THE Photoshop methodology for commercial imaging.

However had we converted abc.bitmap to abc.jpg instead that would have wrong colours. Often that would look ok, but if you compared it to Photoshop you would realize why you need ICC.

To convert to jpg for viewing you must always convert to sRGB first using sRGB.icc

To convert abc.jpg to the printer's profile we need:

bitmap_icc_icc_cached abc.bitmap abc.icc abc_printer.bitmap printer.icc p p ongoing_cache

abc_printer.bitmap is now the bitmap for the printer's profile.

We can convert this to an lzw compressed tiff file with embedded icc profile printer.icc thus:

bitmap_to_tiff abc_printer.bitmap abc_printer.tif printer.icc

Tiff doesnt change the supplied bitmap in any way, but saves also an optional embedded profile for nonstandard colour interpretation eg scanned 35mm

Alternatively we can convert the sRGB bitmap to a tiff without embedded profile thus:

bitmap_to_tiff abc_sRGB.bitmap abc_sRGB.tif

bitmap_to_tiff has an optional 3rd arg which is the optional .icc file, if there is no .icc file the tiff file will be viewed relative to sRGB, which will produce the wrong colours if the image is in fact relative to some other profile. And you can also give a .dpi file, as output by tiff_to_bitmap.

But whether or not a profile is embedded, the bitmap is IDENTICAL. Programs such as Photoshop will display the tiff via the profile: change the profile and the picture changes but the bitmap is unchanged.

This is done because any change of the bitmap will usually lose information, thus the scanner hardware bitmap remains unchanged. In particular you could change the profile later. This is why the tiff format is very useful for quality image processing.

Now if your printer.icc was calibrated by printing a tiff without colour profile, then in fact if we convert abc_printer.bitmap to tiff without profile it will print with correct colours:

bitmap_to_tiff abc_printer.bitmap abc_printer2.tif

if you view abc_printer2.tif it will look wrong, however it will print correctly with full colour correction

These programs also allow you to say convert jpeg to tiff eg to convert xyz.jpg to xyz.tif

jpeg_to_bitmap xyz.jpg xyz.bitmap
bitmap_to_tiff xyz.bitmap xyz.tif

And you can lzw compress an uncompressed tiff with embedded profile thus:

tiff_to_bitmap xyz_uncompressed.tif xyz_uncompressed.bitmap
bitmap_to_tif xyz_uncompressed.bitmap xyz_compressed.tif xyz_uncompressed.icc LZW

Other attributes such as resolution will be lost, but on Photoshop both images will look identical.

If the tiff file has resolution data:

tiff_to_bitmap xyz.tif xyz.bitmap
bitmap_to_tiff xyz.bitmap xyz.tif xyz.icc xyz.dpi LZW

Note that if you have a profile aware tiff viewer, when you view abc_printer.tif it will in fact have the right colours, subject to the limits of the devices.

The embedded printer.icc profile is used by the viewer to render the image relative to sRGB.

jpegs sometimes have embedded ICC profiles, these dont seem to be dealt with by libjpeg. I have written a program called get_profile in the above download which will extract embedded profiles from jpeg files. You can use this to extract the ICC profile from a jpeg with embedded ICC profile thus:

get_profile infile.jpg out.icc

If there is no embedded profile it will tell you this. Thus you can use it also to determine if a jpeg has an embedded profile.

This now will NOT extract profiles from .tif's but WILL extract large embedded profiles from jpegs. To extract profiles from .tif's use the following command:

tiff_to_bitmap xyz.tif xyz.bitmap db

This will extract JUST the ICC profile if any as xyz.icc, with the last arg, d==.dpi not output, b==.bitmap not output.

Without that arg, all 3 will be output if relevant.


Speed optimised conversion between profiles

The original version used a program called bitmap_icc_icc to colour convert, but this could be extremely slow. The new version is bitmap_icc_icc_cached which is much faster and will cache the conversion data of all profile conversions you use.

NOTE: this optimisation requires 48M of free memory to function. Thus if you just have a 16M machine then you cannot use this. Amiga Forever seems to default to a mere 16M, you need to reconfigure AF to 500M which is tricky to do.


Using colour profiles with GS

The above programs deal with bitmaps directly eg jpegs and tiffs. To deal with PS and PDFs you need to convert these to bitmaps. Now jpegs are a lossy format, thus it is better to convert to tiff.

The tiff programs I have written are compatible with gs -sDEVICE=tiff24nc

For instance if you wanted to print tiger.eps relative to a colour profile printer.icc with a 600dpi printer setting:

gs:bin/gs -sDEVICE=tiff24nc -r600 -dBATCH -dNOPAUSE -sOutputFile=tiger.tif tiger.eps
tiff_to_bitmap tiger.tif tiger.bitmap
bitmap_icc_icc_cached tiger.bitmap sRGB.icc tiger_print.bitmap printer.icc p p ongoing_cache

And now convert tiger_print.bitmap to whatever bitmap format the printing software uses.

In the download there are also some libtiff utilities, including a program to convert tiff to PDF and another to convert tiff to PS as well as BMP etc. Run a prog without args and it will echo usage info. Thus you can convert tiger_print.bitmap to PDF thus:

bitmap_to_tiff tiger_print.bitmap tiger_print.tif
tiff:bin/tiff2pdf -o tiger_print.pdf -u i -x 600 -y 600 tiger_print.tif  

Here the -u i -x 600 -y 600 args mean xres=600dpi and yres=600dpi

If you want to convert many pages to PDF, you need to convert them to PS using tiff2ps, and then concatenate the PS pages, and then use the GS framework to convert that to PDF.

With the programs you can convert say jpeg to PDF, by converting the jpeg to .bitmap, then the .bitmap to .tif, then the .tif to .pdf

tiff:bin contains other useful conversion programs eg to convert between tiff and .bmp .gif and other things.



The new command line to enter into turboprefs is:

gs:bin/gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -q

You may of course put eg -sDEVICE=tp1 if you want to do fast low colour printouts,


22feb2004: C. Driscoll has explained to me via email how to set up PS: for GS870 and what is going on,

MORPHOS users: CLICK for Turboprint GS510 things: (:24.mar.2004.1050pm)

Morphos users: CLICK for extra magic required to make PS: function. :apparently "just drop the gs-handler in L: and place the PS mount file in devs:dosdrivers."

:Note that Turbo GS510 only understands Turboprint 7, whereas in my ports the Turboprint devices understand Turboprint 3,4,5,6,7: required careful surgery, I believe in backward and forward and sideways compatibility! If I didnt you wouldnt be able to use this port eg on Morphos or OS4 or on early A1200's,

Setting up PS: consists of 3 parts: handler + mountlist + assign:

1. The handler: you need to recycle the GS510/l/gs-handler thus:

makedir GS870:bin/l
copy GS510/l/gs-handler GS870:bin/l ; IYSWIM!

2. The mountlist: recycle the GS510 DEVS: mount file, to DEVS: not sure what the mountlist is called,

3. The assign: C. Driscoll tells me that Ghostscript: needs to be assigned in such a way that you get Ghostscript:l/gs-handler, thus you need eg:

assign Ghostscript: GS870:bin  ; startup each time you boot,

The Ghostscript: assign is only relevant to PS:, its not a GS870 thing but a PS: thing. C. Driscoll also says you can if you wish edit the mountlist to say L:gs-handler, however that gs-handler has Ghostscript: and Ghostscript:GS embedded in the code, so even if you edit the mountlist you will continue getting the Ghostscript: requester.

So the path of least resistance seems to be to leave the mountlist unchanged and follow steps 1, 2 and 3!


How to quit the viewer early

The viewer will only quit early if you type control-C in a shell WHEN there is no viewer window present. As you have to act fast to do this, there is a trick way to do it without having to rush:

while the viewer window is open, press space in the shell (or IconX shell) which launched the viewer. Now close the viewer window. Now type control-C in the shell (or IconX) window. Press return and the program should quit.


gs:bin/gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -dFirstPage=2 -dLastPage=4 -q annots.pdf
gs:bin/gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -q gs:examples/tiger.eps

:all on one line, the -dFirstPage and -dLastPage tricks are only available for pdf docs, not for ps docs. annots.pdf is in GS870:examples/

The GS> prompt



gs:bin/gs -sDEVICE=tp8 -dBATCH -dNOPAUSE -dFirstPage=2 -dLastPage=4 -q annots.pdf
gs:bin/gs -sDEVICE=tp8 -dBATCH -dNOPAUSE -q gs:examples/tiger.eps

Please note: for GS8 you have to use -sDEVICE=tp8g, with GS854 you can use either -sDEVICE=tp8 or -sDEVICE=tp8g

With GS854 the name has been changed to be easier to remember.

:all on one line, the -dFirstPage and -dLastPage tricks are only available for pdf docs, not for ps docs. annots.pdf is in GS870:examples/

The GS> prompt



gs:bin/gs -sDEVICE=tp1 -dBATCH -dNOPAUSE -dFirstPage=2 -dLastPage=4 -q annots.pdf
gs:bin/gs -sDEVICE=tp1 -dBATCH -dNOPAUSE -q gs:examples/tiger.eps

:all on one line, the -dFirstPage and -dLastPage tricks are only available for pdf docs, not for ps docs. annots.pdf is in GS870:examples/
This produces the fastest render, its good for text only documents. Its also good if the document only has solid regions of black on a white background (no grays or colours).
If the document has lots of delicate colours or gray then use tp24 or tp8

The GS> prompt


AmigaOS point and click icons

Download icon_scripts.lha, this presents icons for a point and click approach.

The following info is also in the archive.

make sure that your startup has:

assign gs: gs870:

The interface is via the visible icons only, the other scripts are auxiliary and not to be directly called.

double click the "view" icon and you get a requester for what document to view, that is then viewed.

double click convert_to_jpg and you input a ps or pdf document which is then converted to jpg in ram: eg if you select gs:examples/annots.pdf you get ram:annots1.jpg, ram:annots2.jpg ...

double click convert_to_pdf and you select a document to convert to a pdf in ram:

multi_convert_to_pdf allows you to multiselect from the requester which documents to convert. After conversion the documents are moved to the selected completion directory. DONT try this on gs:examples as it will move the examples out! This hasnt been fully tested, so please make a backup or test from ram.

you can customise these scripts to do other things.

they function via c:iconx it is possible you may need c:xicon instead for some systems.





set print 1 ; printer on
set window 0 ; viewer off
set overhead 4000000 ; set a total print memory overhead
;of approx 4meg, this is split into 2
;equal sized double buffers,
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh24 -dNOPAUSE gs:examples/annots.pdf

Hopefully it prints.
It prints on my Star-LC10 via epson emulation only in b/w, I have so far not found anyone with a directly AmigaOS supported colour printer to test this. So maybe it will fail!
The GS> prompt



set print 1 ; printer on
set window 0 ; viewer off
set overhead 4000000 ; set a total print memory overhead
;of approx 4meg, this is split into 2
;equal sized double buffers,
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh8 -dNOPAUSE gs:examples/annots.pdf

NOTE: With GS8 you have to use -sDEVICE=whooshg, whereas with GS854 onwards you can use either -sDEVICE=whoosh8 or -sDEVICE=whooshg

The GS> prompt



set print 1 ; printer on
set window 0 ; viewer off
set overhead 4000000 ; set a total print memory overhead
;of approx 4meg, this is split into 2
;equal sized double buffers,
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/tiger.eps
gs:bin/gs -sDEVICE=whoosh1 -dNOPAUSE gs:examples/annots.pdf

The GS> prompt



gs:bin/gs -sDEVICE=jpeg -r150 -dJPEGQ=100 -dNOPAUSE -dBATCH -sOutputFile=ram:annots%d.jpeg annots.pdf

:all on one line would convert annots.pdf to jpeg files ram:annots1.jpeg, ram:annots2.jpeg etc at 150dpi, 1 jpeg for each page.

It would do this at 100% quality because of the -dJPEGQ=100 switch. If you want 10% quality you use -dJPEGQ=10 instead etc.

NOTE that 100% quality is NOT the same as lossless jpeg as the latter is commercial and discouraged by the opensource community, instead if you want lossless images use -sDEVICE=png which is a free open standard (I hope!).
-sDEVICE=jpeg is useful for interfacing with web-browsers as jpegs can be viewed via browsers.
So you can make a PS page available for a browser by converting it to jpeg via -sDEVICE=jpeg and then linking to this in the html.

General info about the command line: all Ghostscript arguments such as -dJPEGQ are CASE SENSITIVE ie -dJPEGQ=20 is GOOD, but -djpegq=20 is WRONG and -DJPEGQ=20 is WRONG. Also the order of the args MATTERS, Ghostscript processes the arguments left to right, some orderings are good and some are not! The above presentation of arguments is correct and other presentations are correct. This is different from a lot of Unix programs where arguments can be presented in any order.

I find its best to put the device as the first arg and right at the end to put the output file followed by the input files:

gs -sDEVICE=????? ...... -sOutputFile=???? infile1 infile2 infile3

From left to right the args of the jpeg example are:

1. first gs:bin/gs is the path to the Ghostscript binary, on *nix probably just gs ok

2. -sDEVICE=jpeg is the jpeg device ie convert documents to jpeg, for list of devices: gs:bin/gs -h ok

3. -r150 is the resolution in dpi (dots per inch, ie pixels per 2.54cm, computer monitor is approx -r100), ok

4. -dJPEGQ=100 is a device specific argument specific to -sDEVICE=jpeg explained above, ok

5. -dNOPAUSE means Ghostscript shouldnt pause annoyingly between pages, ALWAYS do this ok

6. -dBATCH means Ghostscript should exit on completion, ALWAYS do this ok

7. -sOutputFile=some_path/somefile%d means the output file, ok

8. %d means create an output file for each page substituting %d by the pagenumber. ok

9. And lastly are presented a list of PS or PDF files to convert. ok

Note that this website is about the 68k-AmigaOS Ghostscript binary available from this webpage, however various info will apply to all Ghostscripts. Many things are only applicable to this specific version of Ghostscript, namely things I coded myself. Today most people use 68k-AmigaOS in emulated form, eg for PC's there is a commercial product called "Amiga Forever" which is an Amiga emulator for PCs. Via that people with PCs can use this port. There is also an excellent free Amiga Emulator for PCs called WinUAE but you need to supply the ROM image and system disk images. People also can use the binary here via the AmigaOne (A1) and Morphos on Pegasos which are both PPC versions of AmigaOS with integrated 68k-AmigaOS emulators. There is also the AROS reimplementation of AmigaOS for PCs, I dont know if they have a 68k-emulator yet, I think that is one of their projects. I did a version of the program for AROS some years ago but many features have been implemented since then and I havent done any further builds for AROS.
2006.8.1: someone has pointed out that the original command I gave created a 72dpi jpeg which was a bit low res. So I've modified the shell command above to give the res, here at -r150, you can use any other number eg -r100 or -r300 etc.



topic originally from Thursday 8th May 2003 1115pm

For typing with GS you need some language layer otherwise its a real pain, thus use my own language layer:

The problem is that GS uses a coordinate system with the wrong origin + wrong axes directions wrong measure etc. Thus to make it user friendly use the above file.

All commands beginning with Upper case initial letter are my own commands, so if you look inside the above file anything beginning with lower case is an inbuilt PS command eg show is the inbuilt PS command for printing text.

Begin by calling gs as usual with the above file as input, eg

gs -sDEVICE=whoosh24 -dNOPAUSE -r30

This will take you immediately to the GS> prompt.

Now try this:

GS> (Hello world!)show
GS> (this is a test)show
GS> Newline
GS> 255 255 0 Square
GS> (see a yellow square?)show
GS> 0 255 255 Square 
GS> Newline (:cyan square)show
GS> Newline
GS> /NimbusSanL-Regu Font
GS> (:new font being set)show
GS> 5 Fontsize /NimbusSanL-Regu Font
GS> Newline
GS> (Big 5cm!)show
GS> Newline
GS> 1 Fontsize /NimbusSanL-Regu Font
GS> (smaller font!, see
GS> Newline
GS> (for all available fonts)show
GS> Print

You can do this also for any GS device, whenever you enter Print it will print the current stuff to the printer or other device.

gs -sDEVICE=anydevice -dNOPAUSE

This can also be done from a pre-made file, eg:

gs_000 -sDEVICE=somedevice

Then at the GS> prompt type:

GS> (typetest) run Where the file typetest contains the above commands, this makes life a lot easier to debug the PS file. You can also add your own language layer to extend

You can do all this directly with PS but its a lot of work as eg the units of measurement are 1/72 inch,

Also PS does rgb colours with floating point values between 0 and 1 for each component. retargets this to the traditional computer 0-255 values! keeps track of vertical position on the page, the Newline procedure resets the position to the start of the next line.

By using my layer file, you have user friendly usage of GS for text using all GS fonts in and any other ps fonts.

Thus you can write a letter with commercial quality printout just armed with GS and

Handwritten Postscript generally requires debugging eg one line may collide with another or run off the edge. eg the above example had some bugs, now removed!

Also with each page printed everything gets reset, thus my Print procedure reinitializes the page each time, otherwise when you try a second page it will be just blank!

Really using the GS> prompt is just like using the BASIC language on eg a BBC computer of yester-year.

A procedure for automatically doing newlines would be

/Line {show Newline} def,

you could feed this new procedure in at the GS> and immediately start using it.



To multiply eg 12.3 x 13.8:

GS> 12.3 13.8 mul ==

To add use add, likewise use sub, div,

To do (2 + 3)/4:

GS> 2 3 add 4 div ==

GS is a stack machine, if we present it with a number, it pushes it onto the stack. When we present it with an operator eg add it pops the operands from the stack, applies the operator and pushes the answer onto the stack. To pop + view the top thing on the stack you type ==. So eg to add 1 2 3 4 5 we could type:

GS> 1 2 3 4 5 add add add add == If the GS prompt says eg GS> < 4 > that means there are 4 unpopped things on the stack. Its useful for debugging.



There is a lot of further useful information on the website:
In particular there is a lot of useful usage info in the doc file for the pre-release, some of the pre-release devices have been superceded by new devices in this release, the pre-release doc file is:
So browse around and see what is there. In the early stages of the project I was more energetic about the website. As the project neared completion I begun to get very exhausted from the whole effort and less things made their way to the website.



Via gs813:bin/gs -h here is a list of all devices in this recompile, with GS813 the list is alphabetical:

bbox bit bitcmyk bitrgb bj10e bj200 bjc600 bjc800 bmp16 bmp16m bmp256 bmp32b bmpgray bmpmono bmpsep1 bmpsep8 cdeskjet cdj550 cdjcolor cdjmono cljet5 cljet5c deskjet devicen djet500 eps9high eps9mid epson epsonc epswrite faxg3 faxg32d faxg4 ibmpro jpeg jpeggray laserjet lj5gray lj5mono ljet2p ljet3 ljet3d ljet4 ljet4d ljetplus miff24 nullpage pbm pbmraw pcx16 pcx24b pcx256 pcxcmyk pcxgray pcxmono pdfwrite pgm pgmraw pgnm pgnmraw pj pjxl pjxl300 pkm pkmraw pksm pksmraw png16 png16m png256 pngalpha pnggray pngmono pnm pnmraw ppm ppmraw psdcmyk psdrgb psgray psmono psrgb pswrite pxlcolor pxlmono samsung_gdi spotcmyk stcolor tiff12nc tiff24nc tiffcrle tiffg3 tiffg32d tiffg4 tifflzw tiffpack tp1 tp24 tp8 tp8g uniprint whoosh1 whoosh24 whoosh8 whooshg xcf
Now do you believe me when I say there is a lot of learning curve?!! NO???
Included in the above list are a lot of graphics formats eg jpeg, png, bmp, there are also lots of wierd things such as many fax formats.
Via the webpage I have created some lists that summarise many of the above devices.





There are 4 ways to print, 3 are in this port a 4th one can only be compiled fully via an ixemul recompile hence is missing from this noixemul recompile:
  1. Turboprint
    If your printer is supported by Turboprint then this is the recommended path
  2. Inbuilt Ghostscript printer drivers.
    My printer Samsung ML-4500 b/w 600dpi laser is supported by neither Turboprint nor AmigaOS. This means the only way to print with it on an Amiga is via Ghostscript, this is actually how this port begun. I had to download the Ghostscript c-source driver from a Linux site, then spend a week or 2 debugging it finally I could print! This is the samsung_gdi driver in the device list.
  3. AmigaOS printer driver
    If your printer has an AmigaOS driver (many dont) then this is another method.
  4. ijs
    Available in the ixemul recompile which isnt uploaded yet, (needs a lot of explaining how to set things up for ixemul). -sDEVICE=ijs is an impenetrably complicated method. Its clever but usage is near impossible to understand, I've made some 3 attempts to understand it and given up. Anyway this method allows you to download and use external drivers from the internet and use them with GS8. I think Hewlett-Packard are involved with the concept :I think ijs is one of those a-bit-too-clever ideas! If you get too clever with computers you end up with something which is too difficult to use, L-unix anybody??



Sometimes HTML can look like PS! eg on some browsers this doc looks a bit like PS. Dont be fooled though!
PS and HTML are based on totally different concepts:
:PS deals with an absolute page, with absolute colours, absolute positions etc. this means that the same PS document printed out via 10 different printers will always print the identical image (up to the colour + resolution capabilities of each printer).
PS does not deal with bitmaps and pixels, it does everything in an infinite resolution abstract space. This makes all PS images infinitely rescalable. ie PS has truly abstracted the printer.
This means that if you take the printouts from 2 different printers and place one on top of the other and hold them up to the light, both images should superimpose exactly (up to 1 or 2mm at least).
HTML is generally totally relative. If you view this HTML manual via IBrowse, AWEB and Voyager the outcome is totally different in each case. HTML is geared around video screens whereas PS is geared around printers.
:HTML is highly subjective, this allows for a lot of creative license on the part of web browser authors.
HTML is also rendered much faster and it is easier to read HTML source code than PS source code.
PS is a totally standardised foolproof imaging mechanism. What is very useful is you know the precise image the user will see. With HTML the user may get a totally different web-page from the one you thought you designed.
PS is a fantastic method for outputting images, because it is cross-platform and cross-printer. :any platform any printer always the same image! Thus it is very portable and bypasses the need to write printer drivers. In addition to this Ghostscript acts as an excellent generic cross platform printer driver, what is particularly useful is that it sits above the OS rather than within the OS.
The problem of communicating to printers via the OS is that this will usually be non-portable. AmigaOS will talk to its printers quite differently from Mac etc.
Of course its more complex than I have described as the quality of the printer driver also matters eg if you print via Turboprint you get far more authentic colours and dithering.
This documentation is in HTML rather than PS for 2 reasons:
  1. 1. HTML render is fast,
  2. 2. Links!: HTML is interactive via its links PS is not.

:PS is about quality printouts on paper, not mouse+video screen where HTML is more suited.



If you read the OS3.0 graphics docs, the graphics.library Blitter functions have a bug where things fail momentously if bitmaps exceed a width or height of about 1000 pixels. Someone forgot to set an Agnes Big blit flag. This oversight cramps the performance of all my AGA viewers.
These bugs appear not to be present in graphics cards, I fix the problem for AGA machines by imposing a width + height limit of 800 pixels for all bitmaps.
Because graphics.library and cybergraphics.library both use 16 bit arguments (WORD and UWORD), I have imposed a limit of approx 2^15 on all bitmaps Cyber or AGA.
The AGA 800 pixel limit can be increased or decreased for AGA or graphics cards via 2 env-variables whooshxsafe and whooshysafe eg

set whooshxsafe 900 ; limit all bitmaps to
; width <= 900 pixels
set whooshysafe 850 ; limit all bitmaps to
; height <= 850 pixels
; For AGA severe problems will
; happen at 1000 pixels

For graphics cards lowering whooshysafe can be used to speed up the render.



If you have problems eg the Cyber viewers fail to view on your graphics card then:
  1. Study, download the latest version of the program if any
  2. If the problem persists email me:

Note that as the Cyber viewers have only been tested on 4 cards that they may fail on other cards. I hope not, but who knows!



The SetRGB32CM() bug: unfortunately the SetRGB32CM() AGA OS call doesnt set the lower 4 bits of the blue component. You can prove this by calling SetRGB32CM() and then studying the blue component via GetRGB32(). I have fixed this bug by directly hacking to memory the correct lower 4 bits of blue. This bug fix could throw an emulator.
For graphics cards I assume the bug is absent so I dont apply the fix, the fix can however be switched on via env variable whooshfix,

set whooshfix 1

For graphics cards SetRGB32CM() is only used if you select a depth 8 screen.
Depth 15, 16 and 24 screens dont use a palette so the bug is irrelevant for their use.



Debug env variables for -sDEVICE=whoosh24, whoosh8, whooshg and whoosh1:

set whooshv 1 ; verbose on
set whooshdeb 1 ; debug on
:two different levels of shell output, useful for debugging.

set whooshscreen 102400 ; set custom screen to
; a specific screenmode

set whooshwbres 1 ; custom screen to use
; same screenmode as workbench

set whooshw 1 ; WB viewer image to exactly fill
; workbench screen width

Viewer + printer env variables:

set print 0 ; printer off
set print 1 ; printer on
set window 1 ; viewer on
set window 0 ; viewer off
set whooshsuper 1 ; WB viewing on
set whooshsuper 0 ; WB viewing off ==
; custom screen viewer on

set whoosh216 1 ; 216 colour AGA viewing on
set whoosh216 0 ; HAM8 AGA viewing on
set whooshxsafe 850 ; limit bitmaps to width 850
set whooshysafe 700 ; limit bitmaps to height 700
set whooshfix 1 ; switch on SetRGB32CM() bug fix for
; Cyber
set whoosh100 33 ; set viewer refresh timeout to 33/100 seconds ; mustnt be too high mustnt be too low! set whooshfix 0 ; switch off SetRGB32CM() bug fix for
; Cyber
set whoosharrowspeed 30 ; left and right arrow viewer
; scrolling speed, default=15
set overhead 10000000 ; whoosh24, whoosh8, whoosh1
; total print overhead of 10 million
; bytes, ½ this no. of bytes sent to
; printer at a time.
set whooshallzoom 0 ; get AGA very fast h/w autoscroll
; but no zoom in option viewer.
; default is 1==slower but more useful s/w scroll
set whooshreverse 1 ; make scrolling happen in the reverse directions
; some people prefer this,

whoosh100 illustrated above is a new env variable, introduced on 22nd January 2004, it is a fine tuning of the viewer. :it is the timeout for ordinary viewer refresh events. What this means is if you eg scroll around with the viewer, hundreds of mouse events may be generated for this. If each mouse event results in a redraw, then you may have to wait ages for the viewer to catch up. Thus the viewer will ignore such events if they are too late, in particular if they are greater than whoosh100/100 seconds old. The default is 33, ie if an event is later than 1/3 second it will be ignored. Some events are never ignored such as resizing the viewer window.
I think this covers the main env variables. There are dozens of further hidden env variables but these were for debug experiments, and should not be used by the user. Eventually they will all be removed. All of them begin with the prefix whoosh
A generic example of using the above env variables:

set print 0 ; printer off
set window 1 ; viewer on
set whooshsuper 0 ; WB viewer off
; == custom screen on
set whooshwbres 1 ; use WB res
gs:bin/gs -sDEVICE=whoosh24 gs:examples/tiger.eps

would give you a 24 bit colour custom screen viewer (HAM8 for AGA) using the WB resolution.


Miscellaneous downloads

When gs encounters an error it tells you the file position, however what you really want is the line number, so there is now a small program to convert file position to line number in the binary download.

Example usage:

gs:bin/pos_to_line examples/tiger.eps 1000

:would tell you the line number of file position 1000 in tiger.eps,

To get usage info type:



gs:bin/pos_to_line ?
gs:bin/pos_to_line examples/tiger.eps 1000 1200

:would print out all text from file position 1000 to 2000 and then tell you the line number of file position 1000 in tiger.eps, eg when I tried it, it does:

/_i currentflat def
/i {dup 0 eq {pop _i} if setflat} bdef
/j /setlinejoin ldef
/J /setlinecap ldef
/M /setmiterlimit ldef
/w /setlinewidth ldef
% path construction operators
/_R {.25 sub round


Michael Merkel's GS8GUI

Michael Merkel who was one of the original betatesters for the Turboprint part of the port has written a GUI frontend for the ports of GS I have done.

Its an independent project and this is the URL.


Printing Billboards

This requires the 11th May 2007 binary archive or later.

The current core download as of today (17th July 2005) now contains pdf2ps.amiga.

Lets say you want to convert gs:examples/annots.pdf page 2 to 3 x magnification billboard:

Here is how you would do it just to view the parts. To actually print the frames you need to edit gs:bin/view1 and uncomment eg the turboprint command: a row by row column of frames will then be generated by your printer starting with the lowest row and working left to right. You then cut the right + top edges of each frame and glue consecutive frames together. In the "billboard" command below, the first argument is args in "" for GS: we filter out just page 2 here, the next arg is the document, then is the magnification factor: here its 3, then a script file which will be generated (output) ram:script0, then a temporary filename prefix here hd:temp, scratch files hd:temp#? will be generated by the mechanism, then a script file you supply which will view/print the resulting PS files: gs:bin/view1 (ready made one), then the horizontal overlap factor: here its 4 meaning each consecutive horizontal page overlaps with 1/4 of its predecssor. Lastly the vertical overlap factor here 8: vertically frames overlap by 1/8.

:if there are gaps between consecutive frames reduce these 2 parameters till consecutive frames match with absolute precision: should be pixel perfect.

If you run gs:bin/billboard without args it will give you usage info, x0 and y0 define the overlap factors of 1/x0 and 1/y0.

Note that if you dont filter out one page via -dFirstPage and -dLastPage you will get a billboard for every page of the document using a square mile of paper: BEWARE!

delete hd:temp#?
gs:bin/billboard "-dFirstPage=2 -dLastPage=2" gs:examples/annots.pdf 3 ram:script0 hd:temp gs:bin/view1 4 8
; :all on one line,
; ie without paths its:
;; billboard "-dFirstPage=2 -dLastPage=2" annots.pdf 3 script0 temp gs:bin/view1 4 8
execute ram:script0

In gs:bin/view1 you can uncomment a line to print the billboard via Turboprint. You can also comment out the line that deletes the images after printing.
You can use this system to generate huge photograph images from an a4 printer: combining the resulting a4 sub-images will be quite a lot of effort.


Printing Novels

This requires the 11th May 2007 binary archive or later.

This puts 2 PDF document pages per physical page side in such a way that when you print on both sides you can column up the pages, fold in half and obtain the correctly numbered pages of a novel. For example a 9 page document is prints as:
(1)[ 2 : . ]
(3)[ 4 : 9 ]
(5)[ 6 : 7 ](8)

As with pamphlets you can use the novel feature several times and then combine these into a tome.

Example: say you want to put pages 90 to 210 of doc.pdf into a novel.

This system ONLY functions for pdf's. To do this with a PS document you need to convert it to PDF first via GS:lib/ps2pdf.amiga which is Ghostscript's PDF distiller script.

Here is how you now convert pages 90 to 210 of doc.pdf to 2 x 1 x 2 novel. You need a temporary file prefix eg hd:temp or ram:temp (if you have lots of memory). The temp file prefix hd:temp, 90 and 210 are then entered into the following commands. WARNING: all files with prefix hd:temp will be deleted at the start!

delete hd:temp#?
gs:bin/novel doc.pdf 90 210 hd:temp
execute ram:script1
execute ram:script2
gs -sDEVICE=???? ??????
;gs -sDEVICE=???? ??????
;gs -sDEVICE=???? ??????
;if unsure whether or then view the first
;page of say with the -sDEVICE=whoosh24 viewer and
;see if it matches the first page to be printed. If it matches now
;print else print Stick a note on the
;printer saying which option to use.

If you run gs:bin/novel with too few args eg no args it will give you usage info.

The above commands will generate, and these are 3 PS files. First print with GS. This generates the upper faces of the novel. Once printed you have to re-insert these into the printer. If these are in forwards order now print and if in reverse order print Make sure the pages arent upside down!

This will print the lower faces on the same pages.

IMPORTANT: make sure to wait till the pages have cooled down before reinserting. Otherwise the printer will lose its grip and the printout could be wrongly positioned.

Experiment with say 20 pages of a document. If you only want one of forwards or reverse ordering of the second print then comment out the appropriate line of gs:bin/script3n

My printer has 2 output schemes which create opposite out-tray orderings of the print.

When both sides are printed you may need to do a final reversing of page order. I probably need to improve the scheme sometime so that a final reversing isnt necessary.

If you arent sure, instead of printing view, and with whoosh24 and note the page numbering, then figure out from this how to do the reinsertion.

You can create commercial quality booklets with this scheme.


Printing Pamphlets and Books

This requires the 11th May 2007 binary archive or later.

This puts 4 pages per page side in such a way that if you cut the pages in half horizontally, place one half column above/below the other and remove one possibly blank page at the top, staple together you get a pamphlet with correctly sequenced page numbers.

For example the first printout of a 30 page document will have the following page number layout:
10 23

Later in phase 2 of the procedure under the 2 will be 1, under the 10 9, under 23 24, and nothing under the empty subframe. ("Notes" candidate!)

The second printout will look like:
4 29
12 21

Later under 4 + 29 + 12 + 21 will be 3 + 30 + 11 + 22 respectively. You dont want to have to do this by hand as its really painful!

BTW I've been thinking about this idea ever since GS8, but couldnt see how to do it then when looking at something Christoph Poelzl asked I suddenly made a breakthrough.

There is quite a bit of puzzle element to the procedure, eg when I first tried it one side was upside down, then when I got it the right way round I was looking at the wrong side of the page, things only make sense if you look at the correct side!

You can also publish your own book by dividing the book into pamphlets and then stitching the pamphlets together into a book.

The pamphlet scheme has some sort of physical limit for convenient browsing, to create a tome you need lots of pamphlets. I think the professionals stitch with string and dont use staples. Staples are for amateurs like me. The problem with staples is though they look bright and shiny today in 10 years time they will have corroded. That shiny lustre will have flaked off causing a health hazard.

Example: say you want to put pages 90 to 210 of doc.pdf into a pamphlet. You can determine the page count of a document via the number GS -sDEVICE=whoosh24 says when you view the document. You can make a tome by splitting the document into several pamphlets.

This system ONLY functions for pdf's. To do this with a PS document you need to convert it to PDF first via GS:lib/ps2pdf.amiga which is Ghostscript's PDF distiller script.

Here is how you now convert pages 90 to 210 of doc.pdf to 2 x 2 x 2 pamphlet. You need a temporary file prefix eg hd:temp or ram:temp if you have enough ram. The temp file prefix hd:temp and 90 and 210 are then entered into the following commands. WARNING: all files with prefix hd:temp will be deleted at the start!

delete hd:temp#?
gs:bin/pamphlet doc.pdf 90 210 hd:temp
execute ram:script1
execute ram:script2
gs -sDEVICE=???? ??????
;gs -sDEVICE=???? ??????
;gs -sDEVICE=???? ??????
;if unsure whether or then view the first
;page of say with the -sDEVICE=whoosh24 viewer and
;see if it matches the first page to be printed. If it matches now
;print else print Stick a note on the
;printer saying which option to use.

If you run gs:bin/pamphlet with too few args eg no args it will give you usage info.

The above commands will generate and these are 3 PS files. First print with GS. This generates the upper faces of the pamphlet. Once printed you have to re-insert these into the printer. If the reinsertion is in forwards order you now print and if in reverse order

The first time you try this everything will go wrong.

The second print prints the lower faces on the same pages.

IMPORTANT: make sure to wait till the pages have cooled down before reinserting. Otherwise the printer will lose its grip and the printout could be wrongly positioned.

If you comment out one of the 2 commands in gs:bin/script3 you can make only one of the 2 possibilities of forwards versus reverse happen.

My printer has 2 output schemes which create opposite out-tray orderings of the print: I move a lever up or down, if the lever is down the pages leave the printer to the floor (unlimited capacity) and when its up they accumulate within the printer. :both schemes are stacks but one is a face down stack and the other a face up stack.

This scheme is complicated but thats because the problem itself is geometrically quite complicated.

Creating pamphlets is very satisfying.


2 sided printout of Books

This requires the 11th May 2007 binary archive or later.

This takes an input PDF document doc.pdf, and outputs 3 PS documents, and

The odd pages are in and the even pages plus maybe a parity synchronising blank page in as well as in contains the even pages in ascending order and in descending order.

So you print then reinsert the pages and print either or to get a 2 sided printout.

(You can convert these 2 PS files to PDF via GS:lib/ps2pdf.amiga, :this script is self documenting)

Example: say you want to print pages 90 to 210 of doc.pdf thus, Note you can find the number of pages in a PDF document by running GS -sDEVICE=whoosh24 and noting the number at the start.

This system ONLY functions for pdf's. To do this with a PS document you need to convert it to PDF first via GS:lib/ps2pdf.amiga which is Ghostscript's PDF distiller script.

Here is how you now convert pages 90 to 210 of doc.pdf to 2 x 1 x 1 book format. You will need to supply the first and last pages 90 and 210 as shown in the example below. You also need a temporary file prefix eg hd:temp. (I use ram:temp). The temp file prefix hd:temp and 90 and 210 are then entered into the following commands. WARNING: all files with prefix hd:temp will be deleted at the start!

delete hd:temp#?
gs:bin/book doc.pdf 90 210 hd:temp
execute ram:script1
execute ram:script2
gs -sDEVICE=???? ??????
;gs -sDEVICE=???? ??????
;gs -sDEVICE=???? ??????
;if unsure whether or then view the first
;page of say with the -sDEVICE=whoosh24 viewer and
;see if it matches the first page to be printed. If it matches now
;print else print Stick a note on the
;printer saying which option to use.

If you run gs:bin/book with too few args eg no args it will give you usage info.

The above commands will generate, and these are 3 PS files. First print with GS. This generates the odd numbered pages. Once printed you have to re-insert these into the printer, if they are in forwards order print and if in reverse order print

According to the number of pages there may be 1 synchronising blank page.

IMPORTANT: make sure to wait till the pages have cooled down before reinserting. Otherwise the printer will lose its grip and the printout could be wrongly positioned.

If you know you only need either forwards or reverse order you can comment out the appropriate line in gs:bin/script3b


Printing and viewing thumbnails

This requires the 22nd July 2005 binary or later.

Say you want to view/print doc.pdf in 4 x 4 thumbnails:
gs:lib/pdf2ps.amiga "" doc.pdf

This will generate with 4 x 4 thumbnails, ie 16 pages per page.
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16

Pages 17, 18 etc will be thumbnailed to the next page etc, and you can have any number of pages eg 3 or 101.

eg you can store the 6 pages of GS:examples/annots.pdf on one 3 x 3 thumbnail page!


Printing and viewing in landscape

This requires the 15th July 2005 binary or later. Usage has changed since 14th July.

In response to a request by Christoph Poelzl I've customised GS854 onwards so it now can print in landscape.

You need the current binary.

To print/view in landscape say annots.pdf,
pdf2ps.amiga "" annots.pdf

This creates a landscape PS file eg eg view it at low res:
gs -sDEVICE=whoosh24 -r50 -dBATCH -dNOPAUSE


Converting problematic True Type fonts to PS fonts

WIARD Thomas (thomas dot wiard at radiofrance dot com) contacted me with the following problem which is about embedding problematic true type fonts in a document as PS fonts.

Various true type fonts (Trebuchet TimesNewRoman CourierNew and Arial) converted to PS fonts via ttf2pt13 from aminet and embedded in a document via Wordworth7 were not rendering "-". The "-" was being rendered with the default undefined symbol which is a square.

We established that the problem was not with GS.

Using nonembedded fonts rendered the - but didnt look the way intended.

The fonts needed to be converted to PS to use on Wordworth7 and to be embedded to preserve the look of the document eg when used with GS.

All attempts to do this were not rendering the "-" for all the fonts, some attempts rendered the "-" for some of the fonts.

Eventually the following method was found by WIARD Thomas which is entirely via AmigaOS:

1) convert the .TTF font with 'ttf2pt1 -a -b' command into the .PFB file format
2) launch TypeSmith 2.5 software
3) import the .PFB file
4) at the question : "the font has a custom encoding. Load with TypeSmith encoding ?" reply YES
5) export the .PFB file
6) choose the parameter : encoding type - TypeSmith encoding

and then the .PFB file is correct !


Converting PDF and PS to ascii

Someone asked me how you do this, I've converted the ps2ascii script to AmigaOS for this. You use GS:lib/ps2ascii_amiga which is in the core download since 26th June 2005


execute gs:lib/ps2ascii_amiga gs:examples/annots.pdf ram:annots.txt


Converting ascii to PS

You need A2ps.

I use it to print ascii on my printer.


Deblurring pdf and ps photos

To deblur a photo in a ps or pdf file, you first need to increase the blurring a few times via b p b p ... and then use the deblur function s a few times eg s p s p.

The deblur function used directly isnt so good it works better by first increasing the blur factor. If you increase the blurring first and then deblur as explained above the effect is quite impressive.


Double sided printing

How do you print on both sides of the pages?

Here is the brute force way! Its only for pdf documents.

Say the device is tp24 and you want to print doc.pdf, you need to run 2 scripts:

First find out how many pages eg via:

gs -sDEVICE=whoosh24 doc.pdf

gs will say how many pages, exit via control-C to the shell.

Then run:

gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -dFirstPage=1 -dLastPage=1 doc.pdf
gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -dFirstPage=3 -dLastPage=3 doc.pdf
gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -dFirstPage=5 -dLastPage=5 doc.pdf
gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -dFirstPage=7 -dLastPage=7 doc.pdf
gs -sDEVICE=tp24 -dBATCH -dNOPAUSE -dFirstPage=9 -dLastPage=9 doc.pdf

When this completes, take the column of pages, re-enter them into the printer thinking very carefully about the geometry of what you are doing.

Depending on how your printer outputs things you now either print pages 2,4,6,... or pages 100, 98, 96, .... 2 by the same technique.

There are 4 things that can go wrong: upside down, wrong numbering, wrong synch, wrong side (double superposed),

My printer can output 2 different ways so both possibilities can apply.

When I use this technique I use a c program to generate the script for me. The program is gs_scripter. You run it thus:

gs_scripter 100 1

This will create a script file ram:script which goes from the first number to the second number in steps of 2:

somescript 100
somescript 98
somescript 96
somescript 94

You then create somescript to call gs to print out exactly one page by the -dFirstPage=10 -dLastPage=10 trick. This trick is only available for pdf. To do this for ps you have to convert the ps doc to pdf via gs and then use this trick.

If anyone knows a better way to do this please contact me.


Simplified usage: requester scripts and aliases

As typical usage of GS requires 3 standard arguments and a filepath it makes sense to do this via a script or to use an alias.

Put the following line in s:shell-startup

alias g "gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE []"

Now to run gs all you do is from the shell press g space tab on King-con, This gives you a requester where you enter the document via the mouse. And gs now views that document!

g space tab click click click enter

You can also enter the above alias in the shell directly:

alias g "gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE []"
g ram:xyz.pdf

will then view ram:xyz.pdf. The square brackets is how aliases do arguments.

That is much faster than a gui, you just press 3 keys, g, space and then tab. Make sure to install King-Con. I've been told that the VNC shell can also do this but I never managed that myself.

You can also go via a shell script. If you give this an icon you can run it from the WB. To do file requesters in shell scripts you need eg:

c:requestfile title "enter PS or PDF file to view:" > env:tempname

and to access the filename $tempname eg:

gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE "$tempname"

These 2 tricks (c:requestfile and $tempname) are essential for shell scripts to communicate with file requesters.

For a script you need to set the stack or it can malfunction, eg the following script does things correctly:

stack 500000
c:requestfile title "enter PS or PDF file to view:"  > env:tempname
gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE "$tempname"


Viewing page 1 of annots.pdf

Over the months a number of people have emailed me saying that page 1 of examples/annots.pdf is missing some colour boxes which are supposed to be there.

:someone has explained to me how to view/print annots.pdf correctly: you need -dPrinted=false eg:

GS:bin/gs -sDEVICE=whoosh24 -dPrinted=false GS854:examples/annots.pdf
GS:bin/gs -sDEVICE=tp24 -dPrinted=false GS854:examples/annots.pdf

-dPrinted=false only affects PDF files and is some technical PDF thing,

GS now has this info within the annots.pdf document!



C.Driscoll has sent me an Arexx script for converting FinalWriter open documents to PDF

Here is further FW script he sent me: FW2PDF.lha (updated for Wide orientation by Cary Driscoll, 26th June 2005).

Ernest Unrau contacted me and send some Adobe Illustrator scripts he has made which he finds useful: Unrau.lha.



Thanks to all the people who have participated in testing the product, in particular the 2 Turboprint testers Peer Richter <> who was very responsive with the more severe parts of fixing Turboprint and Michael Merkel <> who located a lot of problems both with Turboprint and the Cyber viewers.
Also thanks to Steve Hargreaves for a lot of useful feedback which has helped to speed up the development.
Fixing Turboprint depended on several weeks of tests and feedback by Peer and Michael, and getting the Cyber viewers to function depended on the feedback of Michael and Steve.
More recently many thanks to Christoph Poelzl for extensive feedback on Pegasos + Morphos.
Further thanks to:
Jan-Erik Karlsson
for explaining how to use Geekgadgets in particular gcc2.95.3-4
Paul Sadlik
for feedback on Turboprint and the Cyber viewers
Tony Mulvihill
for feedback that Turboprinting was functioning correctly
Daniel Rangel
for verifying that the Cyber custom screen viewers were functioning
Richard de Rivaz
for various feedback earlier on
Jörgen Danielsson
for being the first tester
C Driscoll
for explaining about PS:
various other people are mentioned on the website


============== OTHER PORTS ===============================

I have now done various new ports:

68k hosted cross compiler gcc-3.3.1 for x86-AROS, a port to 68k AmigaOS host of the existing Linux hosted AROS gcc-3.3.1. I have successfully used this to port GS854 to x86-AROS.

Currently I am working on GS854 in a low key way: it is essentially a completed project although there will always be ongoing small improvements

Now that I have a faster machine (2.6GHz Intel Celeron WinUAE OS3.9) I am attempting other ports. Trying to gradually move my work to x86-AROS. My system is now based on WinUAE which I think is better than a real A1200 in most respects.

I am also working on various nonport projects, 68k but should recompile to any CPU. My policy is generally to not talk or announce stuff until its done.

I find that porting is a very inefficient way of doing things: in the time it takes me to fix some obscure port problem I could have written a major subsystem of my own work. All my 68k work only uses OS3.0, this way I maximise my potential user base to everything including AROS,

Another annoying thing about cross-platform ports is the Unix API, the AmigaOS API is a real joy in comparison. Armed with the RKMs you can breeze through major work in a way which is just not possible via the cross platform path. There is also something inherently fun and pragmatic about 68k AmigaOS. My A500's ROM was 1/2 Meg, a "small" version of Linux is 50meg (compressed?): the Amiga was never ashamed to be small,

Fun OSes lead to fun programs,

POSIX THREADS FOR 68k Amigas PORTED, includes some example threaded programs to try out on 68k Amigas. (updated: wed.25.feb.2004.night),

NEW ANNOUNCEMENT: STAND-ALONE AMIGA 68020 IXEMUL RPM4.0 HAS BEEN PORTED (this is the full port *EXCEPT* no database support, "rpm --install xyz.rpm" is fully functioning which is the useful thing. reliable version of ixemul.library included in the download)


Crucial File updates

New idea showing file updates that *must* be downloaded,

Sun.28.mar.2004.1145pm: TP_PS_files.lha for Morphos people,


From 2004 onwards, new developments will be put here (as an experiment). This makes them more accesible.

If you havent installed my port of Ghostscript yet, then probably you should skip this part of the website: try and navigate around the site via the topmost index

12th Oct 2013

There is no new port yet not for lack of trying, but that the central source has become very problematic. I have made more than one attempt to port gs9.?? without success. I can build the binary, but it doesnt function properly. gs8.70 on this webpage should deal with most documents, so in practise its not a major problem. It has handled all commercial pdf's that I have downloaded. Its unrealistic to expect all amiga software to be absolutely current, I use some quite ancient Amiga software myself. Note that Windows does not endorse PDF's even, but PDF's are the de facto document standard. All open source projects tend to become increasingly problematic to port to AmigaOS. which is because open source projects tend to be *nix projects, and become increasingly dependent on their strange environment. The Windows community have no interest at all in these things, and have been much more successful than Linux. So you need to ask yourself what exactly is it that you want? And no matter how good Ghostscript is, Adobe will always be the precedent as they own the PDF specification. so we are talking about a standoff between several projects: *nix, Windows, Apple, AmigaOS, Ghostscript, Adobe. Ghostscript goes with *nix, Adobe goes with Windows and Apple, Ghostscript doesnt like AmigaOS, Adobe doesnt like Ghostscript, and Adobe will always win. You can email me if you want to express any opinion about this.

I personally prefer to invest my time in new works, and am finding it difficult to find enough time for these. An example new work is that I have created an AmigaOS project for processing colour profiles, which I use all the time myself. That is a much more satisfactory project for me as a programmer.

IMHO you need to own multiple systems now if you want to participate with everything, I personally own AmigaOS, Linux and Windows XP systems. I then use whichever is the most expedient, AmigaOS for my programming and emails, Windows for web browsing, and Linux for testing portable software. But if I tried to do all these activities just on one system, it would be highly unsatisfactory.

5th May 2013

I am attempting a port of gs907. But this is proving quite tricky. The initial build didnt even function for "gs --help". I eventually resolved that bug, "gs --help" does now function correctly. But the binary doesnt function for any device. I am trying to resolve these problems, but I have to do this as a background project as there is too much uncertainty. Currently I am very busy with non computing things, but when time permits, I work on this problem. With the major version change from 8.?? to 9.?? there have been major changes to the source. if I can get 9.07 to function, then the further minor version changes 9.?? should be less problematic (I hope!).

On the bright side, the problem is probably less severe than when I ported gs8.00, where there were major version drift problems.

19 april 2012

I have had endless problems eg WinUAE stopped booting! I decided it was best to reinstall completely from scratch. Previously I had used a preconfigured Picasso gfx card emulation. I decided now to install it myself. It was very tricky to install WinUAE fully beginning with Amiga Forever for the Cloanto Amiga 4000 ROM, but using the latest 2.4.0 WinUAE and installing AmigaOS 3.9 with the 3.9 CD from H&P. Eventually I succeeded and have more than 600MB with this, and use the 1024x768 gfx as the fonts are a good size with this on an HD monitor. Fonts are too small with 1920x1080. I see that AROS now have a 68k AROS Amiga ROM as well as various PPC versions of AROS, but I havent tried that. I found also that with Amiga Forever you can configure to huge amounts of memory, their default has insufficient memory. They need to merge the facilities of Amiga Forever with WinUAE, eg AF only allows drive letters whereas WinUAE automounts all volumes correctly as an option, and AF allows a second screen which I am not sure is available with WinUAE.

I decided to migrate a lot of stuff from the original WinUAE drive and while doing this I found all the stuff for the AROS GS8.50 port I did years ago. Once I have some spare time I will see if this works with current AROS, it functions with AROS of that time around 2004. If it works I will make it available, but I have to search for the installation information as the installation has changed a lot since then.

At the moment I am getting very little of anything done, but eventually I will try to further the project here. This year is proving very problematic, there are many things I need to do but too much time is being wasted on pointless problems.

3rd Oct 2011

I havent updated this webpage for ages firstly because I had been working on some of my other projects. Secondly for several months I havent done any computing as I had a lot of non computing things to deal with. Recently I have updated my ICC programs to deal with ICC v4.2 but I havent had time to upload this to the website. If you are interested in this new code please email me and I can send the most recent 68k version.

I tried to port Ghostscript 9 but this proved to be very problematic and I then had to deal with a lot of non computing problems and didnt even have time to check my emails!

I will resume this work at some point, but I probably need to schedule at least a further 2 weeks for the problem and at the moment I dont have 2 weeks for anything!

18th Nov 2010

I have done a lot of ICC embedded colour profile coding recently,

The code now runs acceptably fast with 68k WinUAE. The original version was a bit too slow, but the new code is probably 20x as fast as the original!

With the current 68k fpu and nofpu downloads, the binaries are very stable, the icon scripts are a beta. With the icon scripts you can convert images using the mouse.

I also have ported the binaries to Ubuntu x86 Linux, email me if you want to try those as I havent uploaded them: if enough people request the Linux version I will upload them.

I have also made all the photos on the website smaller using a new image resize icon script multirewidth_to_jpeg_multicached0.ics: all converted to HD width (1920) at maximum jpeg quality. The website with images now loads much faster.

2nd October 2010

As you can see, the website has moved to new servers.

I have done a lot of new ICC coding for 68k AmigaOS, and have got the system to function for Morphos also. The Morphos compatibility is because of requests from a Morphos user. I only guarantee to look at 68k AmigaOS compatibility. It was very time consuming to get Morphos compatibility, but the Morphos user told me its extremely fast on Morphos.

On 68k it took 6 minutes 45 seconds to change colour profile of a 70 megapixel image.

I need to update the ICC usage info, and also to tidy up the code and scripts.

The ICC code brings some useful Photoshop functionality to 68k AmigaOS.

The 68k ICC code now is much faster than the original version and is fast enough now for practical use. The original version was a bit too slow. But now the speed is good.

I have tested out the 68k ICC code with a script to convert multiple pictures to HD backdrop size jpegs of 1920 x 1080 pixels. That way I can use different scanned 35mm photos as HD backdrops with correct aspects and colour.

I will try to document this.

I have also completed version -1 of my language!

I want to make one change to the object orientation and it will then be version 0.

Once that has been very thoroughly tested that will be version 1.

13th July 2010

This website COULD be moving!

I am likely to change service provider because the current charges are too expensive, I calculated that I would probably have saved over 100 quid for the last 6 months by using a different provider.

I dont know if I can keep this URL or my current email address.

As a result, this website could TEMPORARILY vanish, but I will try to move it to a new URL if necessary.

But there may be a delay when the website is not available. I will try to communicate where the new website is

20th - 21st June 2010

Some useful ICC colour profile programs implemented

I have implemented some useful programs for processing ICC colour profiles. The documentation and downloads are here and can be found also from the contents table near the top of the webpage

These will allow you to eg convert a tiff file with embedded profile output by say a film scanner to the standard monitor sRGB profile and save this as a jpeg which will view with correct colours on the monitor.

Without doing the colour conversion the jpeg will have the wrong colours. The programs also allow you to utilise the colour profile of a printer. See the above link for the full information.

Example: (see the above link for the full explanations)

You have a 35mm film scanner on some OS and scan a Kodak photo using a supplied ICC colour profile for the scanner for the Kodak film brand. The scanner outputs a tiff file photo.tif with an embedded ICC profile. You have had your printer calibrated for Rey 160g paper from some company on the internet, the calibration is the ICC file printer.icc

You have some software print_jpeg which prints jpegs without embedded colour profiles. And the calibration was done by printing a test jpeg on the Rey 160g paper and posting the print to the internet company who emailed you the above printer.icc

You want to print the tiff file so that the colours are correct.

This is how you do this using the programs I have written:

tiff_to_bitmap photo.tif photo.bitmap 
	; this also outputs photo.icc the embedded profile (if any)
bitmap_icc_icc photo.bitmap photo.icc photo_printer.bitmap printer.icc p p
	; this will create photo_printer.bitmap, p = perceptual rendering intent
bitmap_to_jpeg photo_printer.bitmap photo_printer.jpg 1
	; creates photo_printer.jpg
print_jpeg photo_printer.jpg

	; this will print with the correct colours on the Rey 160g paper

Another example: you now want to convert the tiff to a jpeg without embedded profile which will view correctly on a typical monitor. Typical monitors use the standard sRGB.icc profile. See the above link about sRGB.icc which is produced by HP.

tiff_to_bitmap photo.tif photo.bitmap 
	; this also outputs photo.icc the embedded profile
bitmap_icc_icc photo.bitmap photo.icc photo_monitor.bitmap sRGB.icc p p
	; this will create photo_monitor.bitmap, p = perceptual rendering intent
bitmap_to_jpeg photo_monitor.bitmap photo_monitor.jpg 1
	; creates photo_monitor.jpg
some_jpeg_viewer photo_monitor.jpg

	; this will view with the correct colours on a typical monitor

Note that if you view photo_printer.jpg on a monitor the colours will be totally wrong.

To understand this you need to regard all image files as having an ICC profile, ones which dont, have the default sRGB.icc profile. But the above photo_printer.jpg is a trick, its colour profile is in fact printer.icc but software will think it is sRGB.icc

The time you realise the need for ICC profiles is when you print a jpeg and the colours are quite different from the monitor. You keep trying different settings and its continuously wrong, you end up with 20 prints all wrong. With ICC files, the prints are correct FIRST TIME. No wasting ink trying to get the brightness and contrast right.

I have actually now implemented full ICC profile support for my Samsung CLP-315 printer using the above programs, and with the ICC colour profile the output images are sublime. Furthermore it prints correctly FIRST TIME, because what you see on screen is what it prints. With perceptual intent in fact the print is better as the shades are more subtle than the monitor.

Note that the bitmap_icc_icc program can be quite slow as it uses a huge amount of floating point matrix maths eg it took 20 minutes to convert 1 example on WinUAE. Where you always use the same 2 profiles I have written an optimisation where the conversion is cached. The same example took about 7 seconds on WinUAE using the cached conversion. An example where you would be using the same 2 profiles is converting from monitor to printer, always sRGB.icc and printer.icc For such recurring conversions you can thus convert from monitor to printer in a few seconds. You need to look at the above link on this.

Another example of recurring conversion is where you are printing out an entire film where its always from say kodak.icc to printer.icc

Example: you want to print photo1.jpg photo2.jpg ... photo10.jpg from your sRGB digital camera and you have printer.icc the profile for your printer.

start_file temp
	; creates temporary file temp
bitmap_icc_icc temp sRGB.icc monitor_to_printer_cache printer.icc p p
	; creates cached conversion, could take 20 minutes on WinUAE

delete temp

jpeg_to_bitmap photo1.jpg temp.bitmap
bitmap_cached temp.bitmap temp_printer.bitmap monitor_to_printer_cache
	; creates temp_printer.bitmap, EXTREMELY fast on WinUAE, eg 7 seconds.
bitmap_to_jpeg temp_printer.bitmap temp_printer.jpg 1
print_jpeg temp_printer.jpg
	; first photo is printed

jpeg_to_bitmap photo2.jpg temp.bitmap
bitmap_cached temp.bitmap temp_printer.bitmap monitor_to_printer_cache
bitmap_to_jpeg temp_printer.bitmap temp_printer.jpg 1
print_jpeg temp_printer.jpg
	; second photo is printed


jpeg_to_bitmap photo10.jpg temp.bitmap
bitmap_cached temp.bitmap temp_printer.bitmap monitor_to_printer_cache
bitmap_to_jpeg temp_printer.bitmap temp_printer.jpg 1
print_jpeg temp_printer.jpg
	; tenth photo is printed

delete temp.bitmap temp_printer.bitmap temp_printer.jpg
	; remove temporary files

Note: all the image conversion is streamed so doesnt use much memory, but does use a lot of disk space. The image processing also deals with huge bitmaps eg 70megapixel, but make sure you have enough disk space. The cached conversion needs a lot of memory for the memory cache.

When I say streamed I mean that the image flows directly from file to file, without having to fill up memory. This allows one to process images much larger than memory without needing virtual memory.

The libtiff port contains some useful conversion programs eg to convert tiff to pdf, and to convert bmp and gif to tiff. ie you can use them with my own programs to print .gif's and .bmp's. And convert .gif to pdf by converting .gif to .tif to pdf

gs's -sDEVICE=tiff24nc converts pdf and ps to tiffs compatible with my code, dont use the other tiff devices of gs with my code.

I have also implemented 64 bit Ubuntu x86 versions of these programs, they arent uploaded. If you think I should upload them please email me.

21st May 2010

21st May: I am working now towards colour profile support for this printer. This code is all outside of Ghostscript, but you use Ghostscript as part of the process to print documents. But you can also print an image directly without going via PS or PDF.

I have also now implemented tiff support, tiff is useful because it allows you to compress images without losing info.

The colour profile support will be for ICC colour profiles, the way this works is that you buy colour profiling from a company. The company sends you a tiff test image file, (that is why I implemented tiff support) you then print the tiff file without colour correction.

You post the printed tiff file to the company and they measure the absolute colours creating an ICC profile file which they email to you.

The plan then is that you print images supplying the ICC profile and now the printed colours should be "correct".

When you use a digital camera, the jpeg will contain an ICC profile for that camera. By using the ICC profile for the camera and the ICC profile for the printer the printer should print the correct colours.

But I havent yet coded this as I have been working on the precursor functionality.

Each brand of paper and ink will need a different colour profile. Also each rendering algorithm needs a different colour profile.

Originally I was going to try manual colour profiling, this is very time consuming, but because it has to be done for each brand of paper it becomes unfeasible in general. Because of that I realised the correct way was to use the ICC technology.

ICC is the current state of the art, and a lot of Windows wares dont properly support it. ie its there but most people dont utilise it as its a bit complicated. The people who do use it are the professionals, especially the people who use Apple, but not the mainstream Windows users.

To some extent users are deterred from professional methodology,

2nd - 27th April 2010

In chronological order:

2nd April: I am writing my own stand-alone 68k AmigaOS driver for the Samsung CLP315 colour laser printer. The driver ALREADY prints jpegs, but I need to do further work on the colour correction. Unfortunately I have run out of both the cyan and black cartridges so cannot do any further work till I get replacements.

The driver is a universal driver in that it should function on all OS's, it converts say a jpeg into a printer-file, which on AmigaOS you then copy to par: to print. It hits the metal directly, by setting the 1200dpi x 1200dpi printer pixels directly to the cartridge colours.

It functions in multiple steps using a suite of utilities, first the jpeg is converted into a simple bitmap format, and the further steps convert the bitmap. The last step converts to the printer-file.

The user can write their own alternative intermediate steps, and the intermediate steps can be rearranged. For example you could write an overlay image or a watermark or fades etc.

To print say a jpeg the steps are: convert jpeg to bitmap file, add margins to prevent printer printing right to the edge, then rotate 90░, then rescale, convert to the printer palette, convert to printer-file, send printer-file to printer.

However with 70 megapixel images the printer-file can be too large, so instead we rescale twice: rescale, convert to printer palette, rescale, convert to printer-file, send to printer.

Alternative intermediate steps are eg to convert to monochrome, or to colour correct.

in particular the user can experiment with their own colour correction, and in a way which is fully portable.

The only problem is that on WinUAE it can be quite time consuming because of the emulation latency. however when I tried it on Linux it takes maybe 2 minutes to generate the printer-file: depends what transforms are done.

I can probably greatly speed up the process, but I will leave that till later.

The intermediate files can be quite huge, eg 400MB. If the intermediate steps are combined into one program it should be a lot faster, but its more complicated to do it in one program and a risk of bugs. Also there is much more reconfigurability if you use multiple steps.

I have written several script files which use alternative conversions from jpeg to printer. You can also directly generate bitmaps with a small amount of C (or with any language which can write binary files). So for instance you could print out a Workbench window just by writing it out as a bitmap file, then using the other steps to print that.

The Samsung CLP315 is a printer in the shops at the moment, and is cheap eg 122 quid. The colours are very rich, and it prints good images on plain 80g/m▓ paper. Also a full set of cartridges is quite cheap on Amazon, 40 quid cheaper than all other places!

I think its the cheapest colour laser at the moment. If you have this already please email me as I can probably send you a beta of the driver to try out. I have built it on both 68k AmigaOS and Ubuntu. The Ubuntu build greatly speeds up testing, but the program is written in the 68k AmigaOS environment.

But the suite of programs will port to any OS at all,

The processing can be speeded up also by going for a lower resolution, although the printer works with 1200dpi x 1200dpi, I think the print quality is a lot less, thus there is no point printing it at 1200dpi. But the image sent to the printer has to be at 1200dpi. Once I get the new cartridges I will try to determine what the highest res is that the printer can express.

For example to print at 300dpi, you would work at 300 dpi, then at the last stage scale that up by 400% for the printer. The optimal resolution needs to be 1200/integer. eg 1200/2 or 1200/3 or 1200/13, possibly the optimal x-resolution is different from optimal y-res.

4th April: I built the PC here in 2006, probably on a 2010 PC the driver on WinUAE will be adequately fast. I should be able to make the driver a lot faster on the 2006 PC. The speed depends also on the render steps, a lower res pathway is faster. and eg a 2 megapixel photo should render much faster than 10 megapixel and that much faster than 70 megapixel.

For me I want to be able to do this from WinUAE. Using shell utilities will give a much higher reconfigurability than the XP photo printing wizard. When you print above an OS you CANNOT control the printer pixels. The reason for this is that 99.999% of colour printers only have a palette of 8 colours, whereas photos have a 16 million colour palette. Thus the OS has to "dither" the image that you supply. ie you cannot control the pixels. This is also why some images print really badly.

When an image prints badly, you need to be able to control the printer pixels in order to improve the print. Note also that once the printer file is created, you can then print a 100 copies at maximum speed. The printer file also has a "number of copies" setting, currently I have this set at 1. I havent tested yet whether this functions for higher values (too many other things to work on!). It isnt necessarily a good idea, in case the cartridges or paper run out, and you may want to ongoingly reuse the printer file by different amounts.

The printer ignores some settings. At the moment I am just working on the A4 plain paper settings. The printer does many other sizes and materials, eg envelopes, glossy photo, cotton, letter, A5, .... But these will require further work to get right. DO NOT USE INKJET PHOTO PAPER ON LASER PRINTERS, as this will void the warranty. instead you use glossy photo paper. You should check the manual for ALL materials you use. IMHO there is no point using glossy photo paper, as this printer on plain paper can produce colours as rich as an inkjet on photo paper. However, printing on envelopes and cotton sounds interesting.

I have timed how long it takes to process a 10 megapixel jpeg by a particular approach: it took 14 minutes 49 seconds on WinUAE on the 2006 Sempron 2800+ tower. The slowest step is the conversion to printer-file, which took 8 minutes 26 seconds. This is to print a full A4 page. Monochrome printing should be 4 x as fast (for the last step). When you do a lot of printing it tends to be text which is monochrome. Thus the speed is just about acceptable.

If you use GS to generate the pages and use the "novel" format, that will give 2 pages per A4. That will amount to 4 minutes per monochrome document page which is ok. I think using a faster machine should be a lot better.

On Ubuntu on the same machine the above takes 1 minute 7 seconds. Thus WinUAE is some 13 x slower, the emulation latency. Apparently Amithlon allowed x86 native binaries to be run, that would enable very fast code. I think the PPC emulation of 68k must be much more efficient as the endianess is the same.

When I sent the printer file to the printer there were some banding artefacts, however I then printed the cartridge test that I wrote and the artefacts coincide exactly with where the black ink hasnt run out! I cannot wait for the new cartridges to arrive, its very exciting controlling printers directly.

6th April: converting the same 10 megapixel jpeg to A5 instead takes 8 minutes 14 seconds.

14th April: the new cartridges eventually arrived, meanwhile I had given up waiting and resumed work on other projects. With the full cartridges the image is correct, no artefacts but a lot of colour correction will be needed. I tried out a number of ideas but none of them worked.

I will continue working on this as a background project as I have to bring the compiler project to completion. I think the work is to remap the colours so that on printing the colours look correct. But it could also be the dithering technique. When I view on the monitor the image sent to the printer using the printer palette it is correct. But the printed image is the wrong colours.

I should be able to do something about this, but it is work. Because the process is done in steps, someone could try their own colour remapping or dithering by putting an extra step written in C. I tried using very large pixels but this didnt work. There is some strange phenomenon at work.

One approach is to use colour profiles, but I have to do some study on that. It seems there are companies where you print a test image, and post it to them and they create a colour profile for you using equipment which costs the same as a car (so they claim). You have to do this for each type of material you print with. That way you can optimise the quality even for a specific brand of paper.

I may also colour remap manually. I created a test image and it looks feasible to match colours by eye. There seem to be major artefacts with some colours, but this may be a problem with the cartridges: I will replace the other two cartridges and see if any improvement. I printed the same test image using XP and that also had artefacts, and the colour matching is slightly incorrect, some of the hues are wrong. The XP image colours are less intense. Too unintense, and prints with my own code are overintense. Some of the colours look really nice, eg vivid blue, green, yellow, black, red.

There some other ideas I want to try.

16th April: After a lot of experimenting, I found the problem isnt about colour remapping. It seems the printer can do just 4 colours, not 8! (the 4 colours are the 4 cartridge colours, those 4 cartridges are the palette) eg to do blue, you need a cyan and a magenta pixel. But they need to be at different points on the page. The original code was drawing them at the same point, which sometimes functions but sometimes completely malfunctions.

I rewrote the code so that the cartridges are kept apart and now the colours started to look correct. The printed image looks correct, but the colours arent the same as on screen. I guess some colour remapping could help but it doesnt seem necessary. Keeping the cartridges apart is not enough, the way its done also matters.

If you look close up at the image, the quality is not too good. I think I probably need to use a different dithering algorithm.

When I changed all the cartridges there were then no artefacts with the XP print, but the colour mapping is not quite correct. some colours have subtly wrong hues, and others have subtly wrong brightness. Probably correct colour matching is impossible.

IMHO the important thing is the print looks believable, it doesnt need to be correct.

18th April: after a lot of work the printer now is creating quite impressive prints, really vivid colours with hues reasonably correct. The problems are not to do with palette remapping, but are at a more basic level. I had some settings where the print was good except some dark hues were indistinct. After trying a lot of other ideas without success, I decided to retry this but the print was now much worse. I couldnt understand why the same settings were creating a much worse print. After a lot of effort I found that some setting which I thought had no effect in fact had major effect. That proved to be key, and by getting the setting just right the indistinct hues were now as good as the monitor. I could make the hues even more distinct but unfortunately various artefacts then also started to appear.

The dithering now is much finer than earlier, this is to do with getting the algorithmic parameters right.

Actually I am not completely convinced that you cannot use 8 colours, I think some of the problems are in fact Moire effects from the remapping algorithm. But the 4 colour approach is producing good results, the more basic the destination palette the more reliable the system.

I think my 600dpi b/w Samsung is much higher quality prints than this colour Samsung. If you want to print text it can be better to get a monochrome printer.

19th April: the one photo prints perfectly. But then when I tried a different photo lots of quality problems. I looked with a microscope at the photo on a commercial product. From that I got some new ideas. I also looked with the microscope at prints done with this printer. From that I see the printer has a lower level of rendering similar to commercial printing.

Unfortunately you cannot control that level. I implemented some code to print in a way similar to commercial printing. It has less artefacts but you can see the dots and its not as fine as my own system.

I tried also printing with 8 colours again, and observed problem artefacts. Most of the photo was really high quality, just a few problems.

With the different prints some parts of the image will be absolutely perfect, but a problem elsewhere. When I say perfect, I mean no pixels at all, perfect colour, and perfect image definition. ie completely flawless.

The difficult thing is to get the entirety perfect.

I think I have to take a break from this now as I have other stuff to do, but it has been a partial success. I have learnt and discovered a lot of new ideas. And I can print any image, its just that each image needs different settings and it is work to get the settings right.

20th April: I implemented some further ideas, and also tested various other ideas. The rendering now is quite good, but a few small regions of a print will have artefacts. The system is good for brighter images. These render more or less perfectly. In fact all the artefacts now are in the image itself and not from the printer. I can render to the screen the image sent to the printer. From this the screen image has the identical artefacts as the printed image. The printed image has much more intense colours. The artefacts are some kind of Moire effect between the photo image and the algorithm.

I decided that a few small artefacts were preferable to the major lowering of resolution from using the commercial printing approach. If the resolution were a lot higher then the commercial approach is good.

22nd April: I have managed to get rid of the artefacts. I had an idea and it worked. Furthermore the other parts of the photo became clearer. I then tried taking the idea further, but the image quality wasnt as good. With these things you have to get the parameters just right. With one attempt at going further, the image became like some of those bold colour posters. All the graininess vanished and the image became really bold well defined regions of single colours. I will keep that system as a "special effect". Those images look a bit psychedelic. What interested me was that the graininess completely vanished. I was hoping I could modify the idea to get correct colour images without graininess. But I couldnt get that. This subject really is like alchemy. At the moment I can generate images without graininess in the bright parts of the picture.

I have also done some reading on the subject from the internet. I want to implement one of the ideas I read about. When I read the idea it didnt seem relevant. But later when I was looking at the monitor representation of the print I realised the idea could greatly enhance the prints. I am not sure if the idea I have is what they meant!

but most things I read about produce WORSE results than my own ideas. I think people only publish the bad ideas, and make money from the unpublished ideas. The code now already uses a lot of ideas, most of which are my own ideas. There are also too many patents in this subject, this is bad because if you develop your own ideas, some by coincidence will be patented. One of the first ideas I had I read later was "invented" by someone in Germany in the early 20th century. The idea was a principle I thought up in order to convert truecolour to CMYK.

I find it incredible that with just a 4 colour palette you can print full colour images.

23rd April: I implemented the idea I read about but it doesnt have much effect. After a lot of work I now have a particularly good system. This prints at 8 colours at 600 dpi with no artefacts. 8 colours can cause problems, but the many parameters seem to evade the problems. With 4 colours I can only manage 300dpi where the pixels are much more visible. To conserve ink, I print at a5. The current system discerns between hues: ie when 2 hues are different on screen they are usually different in the print. chiaroscuro hues are preserved. (brightness variations, chiaroscuro is the effect of drawing with charcoal).

One of the optimisations has introduced a subtle increase of graininess, I think I can counteract that with a refinement of the optimisation. without the optimisation there is virtually no graininess.

With this new system, an a5 print of one photo is better quality than an earlier print at a4 of the same photo: more intense colours, no artefacts, less graininess, more subtleties of colour variation. Absolutely stunning image, and just on plain 80g/m2 paper.

24th April: the prints now have more subtle hues than the monitor! ie what are different hues in the print are indistinguishable on the video monitor! that shows the folly of trying to make a print look like the video image as printers can do some things better than the monitor. At some point I probably should try some colour remapping, some hues are wrong, but you can only see that if you compare them with the original. ie the image itself looks correct. I think its a problem of subtractive colour, that subtractive colour is unreliable. Another interesting thing is that the image sent to the printer when viewed on screen with the same palette looks quite different. I think on screen the colours are adding, heading toward white, but in the print they are subtracting, heading towards black. Both look correct, but they arent the same. For example on the screen red + green + blue is white, but for a print that is black.

Colour remapping will depend on the rendering system, change the system and you would need a different remapping. Thus I shouldnt try any colour remapping until the system has stabilised.

If this interests you, you should email me, use the email form at the top of the webpage.

27th April: I have made a huge amount of progress since the last update. I now am using a system comparable to commercial printing. Earlier when I tried this it wasnt too good. But the system now is quite different. Computer printing is fundamentally different from traditional printing, you can only do something comparable you cannot use the identical principal.

I have a test photo and now the print is immensely better than the best print earlier, and you cannot see any pixels. However there is a slight amount of interference effects in a few places where there are subtle chiaroscuro hues. I am trying to counteract this problem. I can get rid of the phenomenon but at the cost of pixels becoming visible.

Once I have this under control I will work on manually remapping the printer colours. There are now no printer artefacts at all except for the interference effects mentioned. The earlier artefacts seem to be all algorithmic artefacts. There is no graininess at all now. The image is now entirely smooth and precise.

The colours depend on the algorithm, if I change parameters the colours of the print change a bit. Thus I have to stabilise the algorithm before working on colour remapping.

There are a lot of strange phenomena, eg if I exchange x and y the prints are no good, for some reason the printer is polarised

4-5th February 2010

Markus Lunk emailed that the images on this website cost time to load for his setup. I have modified the php so you can visit the website without images if you visit the URL with a parameter thus:

He also suggested I use a higher level of jpeg compression for the images, I will try to do this as soon as time permits.

if you use Ibrowse you can also switch off image loading at the browser for much faster websurfing:

left click just below the title bar away from any gadgets, then right click to access the menu and select:

Preferences---Image loading---none

this website then loads EXTREMELY fast

Note also that if your browser is any good you can read the website in parallel to the browser loading the images. you dont have to politely wait for ALL images to be loaded before reading the website.

AWEB also had the option to switch off image loading, and some people said it was the fastest web browser.

15th October 2009

GPL Ghostscript 870 for 68k AmigaOS released!

At last I have got the port released. This port has major improvements over the previous release. And I have overhauled the entire build process, so this build is very correct. Noticeable drift had begun to occur of the build process at 860 which required some major work to resolve. There are also a huge amount of drivers in this build. The binary is approx 13MB. There are 2 binaries, noixemul and ixemul, ixemul has a few more features and is virtually a complete port but noixemul has fewer run time dependencies.

Christoph has verified that the turboprint device is functioning correctly on Morphos, he says its all round better than with earlier ports.

Document processing is EXTREMELY FAST, where gs860 would take minutes gs870 takes seconds. And there are fewer error messages. the installation instructions have changed a lot, you CANNOT use the 860 install.

The install and startup now requires the following assigns:






and as before use a large stack eg 2000000

GS itself uses gs870: gscache: and gsfonts:, scripts and documentation use gs: and Turboprint's PS: uses Ghostscript:

scripts and documentation use the gs: assign to avoid having to update them with new version numbers!

But its best just to set all 5 assigns regardless of which usages you intend to use.

reread CAREFULLY the new install instructions. If you want to bookmark the announce it is "". #announce is the marker for this part of the webpage.

For a fast install and startup, download the 4 archives gs870core.lha, gsfonts.lha, gs870noixemul.lha OR gs870ixemul.lha, AND icon_scripts.lha. THEN decompress them all to a new directory. Double click the install icon, which JUST sets the env variable gs870. Now double click the startup icon which sets the assigns. And now set the stack to say 2000000 from the shell or script, and you can run the program.

But read later the install instructions for fuller info.

please email me without delay if you encounter any problems at whoosh777 at

I havent made any announces at any forums, please publicise the release for me.

To avoid delays I havent written the newest features to the chronology, but I will write them later dated at 15th October.

The full set of drivers is:

   alc1900 alc2000 alc4000 alc4100 alc8500 alc8600 alc9100 ap3250 appledmp
   atx23 atx24 atx38 bit bitcmyk bitrgb bj10e bj10v bj10vh bj200 bjc600
   bjc800 bjc880j bjccmyk bjccolor bjcgray bjcmono bmp16 bmp16m bmp256
   bmp32b bmpgray bmpmono bmpsep1 bmpsep8 cdeskjet cdj1600 cdj500 cdj550
   cdj670 cdj850 cdj880 cdj890 cdj970 cdjcolor cdjmono cdnj500 cfax chp2200
   cljet5 cljet5c cljet5pr coslw2p coslwxl cp50 declj250 deskjet devicen
   dj505j djet500 djet500c dl2100 dnj650c epl2050 epl2050p epl2120 epl2500
   epl2750 epl5800 epl5900 epl6100 epl6200 eplcolor eplmono eps9high eps9mid
   epson epsonc epswrite escp escpage faxg3 faxg32d faxg4 fmlbp fmpr fs600
   gdi hl1240 hl1250 hl7x0 hpdj1120c hpdj310 hpdj320 hpdj340 hpdj400 hpdj500
   hpdj500c hpdj510 hpdj520 hpdj540 hpdj550c hpdj560c hpdj600 hpdj660c
   hpdj670c hpdj680c hpdj690c hpdj850c hpdj855c hpdj870c hpdj890c hpdjplus
   hpdjportable ibmpro ijs imagen iwhi iwlo iwlq jetp3852 jj100 jpeg
   jpeggray la50 la70 la75 la75plus laserjet lbp310 lbp320 lbp8 lex2050
   lex3200 lex5700 lex7000 lips2p lips3 lips4 lips4v lj250 lj3100sw lj4dith
   lj4dithp lj5gray lj5mono ljet2p ljet3 ljet3d ljet4 ljet4d ljet4pjl
   ljetplus ln03 lp1800 lp1900 lp2000 lp2200 lp2400 lp2500 lp2563 lp3000c
   lp7500 lp7700 lp7900 lp8000 lp8000c lp8100 lp8200c lp8300c lp8300f
   lp8400f lp8500c lp8600 lp8600f lp8700 lp8800c lp8900 lp9000b lp9000c
   lp9100 lp9200b lp9200c lp9300 lp9400 lp9500c lp9600 lp9600s lp9800c
   lps4500 lps6500 lq850 lx5000 lxm3200 lxm5700m m8510 md1xMono md2k md50Eco
   md50Mono md5k mj500c mj6000c mj700v2c mj8000c ml600 necp6 npdl nullpage
   oce9050 oki182 oki4w okiibm paintjet pbm pbmraw pcl3 pcx16 pcx24b pcx256
   pcxcmyk pcxgray pcxmono pdfwrite pgm pgmraw pgnm pgnmraw photoex picty180
   pj pjetxl pjxl pjxl300 pkm pkmraw pksm pksmraw png16 png16m png256 png48
   pngalpha pnggray pngmono pnm pnmraw ppm ppmraw pr1000 pr1000_4 pr150
   pr201 ps2write psdcmyk psdrgb psgray psmono psrgb pswrite pxlcolor
   pxlmono r4081 rinkj rpdl samsung_gdi samsunggdi sj48 spotcmyk st800
   stcolor svg t4693d2 t4693d4 t4693d8 tek4696 tiff12nc tiff24nc tiff32nc
   tiffcrle tiffg3 tiffg32d tiffg4 tiffgray tifflzw tiffpack tiffsep tp1
   tp24 tp8 tp8g txtwrite uniprint whoosh1 whoosh24 whoosh8 whooshg xcf xes

further on SOME of the above drivers:

bj10v	 Canon BubbleJet BJ10v/BJ15v (japanese)
bj10vh	 Canon BubbleJet BJ10v/BJ15v/BJ35v (japanese)
bjc880j	 Canon Color BubbleJet BJC-880J (japanese)
       bjccolor Canon BJC-250, BJC-250ex, BJC-1000, ... Floyd-Steinberg
       bjccmyk  Canon BJC-250, BJC-250ex, BJC-1000, ... GhostScript
         standard dithering
       bjcgray  Canon BJC-250, BJC-250ex, BJC-1000, ... Grayscale mode
       bjcmono  Canon BJC-250, BJC-250ex, BJC-1000, ... Monochrome mode
       cdj1600  HP DeskJet 1600
       cdj670   HP DeskJet 670
       cdj850   HP DeskJet 850
       cdj880   HP DeskJet 880
       cdj890   HP DeskJet 890
       cdj970   HP DeskJet 970
cdnj500  HP DesignJet 500
chp2200  HP Business Inkjet 2200
       dl2100   DEC DL2100
dmprt	 dot matrix printer driver for Ghostscript (it can use 
	 dviprt printer config files, japanese)
escpage  Epson ESC/Page driver for Ghostscript (japanese)
fmpr	 Fujitsu FMPR (japanese)
fmlbp	 Fujitsu FMLBP2xx Page Printer (japanese)
gdi	 Samsung's old driver for their SmartGDI laser printers:
	 ML-4500, ML-2xx, ML-1xxx, ML-5080, ML-6040, ... and
	 Lexmark E210, same as "samsunggdi"
       hl1240   Brother HL-1240 and compatible 600-dpi PCL-5 printers
       hl1250   Brother HL-1250 and compatible 1200x600-dpi PCL-5 printers
hpdj1120c HP DeskJet 1120 ("pcl3" driver)
hpdj310  HP DeskJet 310 ("pcl3" driver)
hpdj320  HP DeskJet 320 ("pcl3" driver)
hpdj340  HP DeskJet 340 ("pcl3" driver)
hpdj400  HP DeskJet 400 ("pcl3" driver)
hpdj500  HP DeskJet 500 ("pcl3" driver)
hpdj500c HP DeskJet 500c ("pcl3" driver)
hpdj510  HP DeskJet 510 ("pcl3" driver)
hpdj520  HP DeskJet 520 ("pcl3" driver)
hpdj540  HP DeskJet 540 ("pcl3" driver)
hpdj550c HP DeskJet 550c ("pcl3" driver)
hpdj560c HP DeskJet 560c ("pcl3" driver)
hpdj600  HP DeskJet 600 ("pcl3" driver)
hpdj660c HP DeskJet 660c ("pcl3" driver)
hpdj670c HP DeskJet 670c ("pcl3" driver)
hpdj680c HP DeskJet 680c ("pcl3" driver)
hpdj690c HP DeskJet 690c ("pcl3" driver)
hpdj850c HP DeskJet 850c ("pcl3" driver)
hpdj855c HP DeskJet 855c ("pcl3" driver)
hpdj870c HP DeskJet 870c ("pcl3" driver)
hpdj890c HP DeskJet 890c ("pcl3" driver)
hpdjplus HP DeskJet Plus ("pcl3" driver)
hpdjportable HP DeskJet Portable ("pcl3" driver)
jj100    Star JJ-100 (japanese)
       la50     DEC LA50
       la70     DEC LA70
       la75     DEC LA75
       la75plus DEC LA75+
lbp310	 Canon LBP-310 (japanese)
lbp320	 Canon LBP-320 Pro/LBP-350 (japanese)
       lex2050  Lexmark 2050
       lex3200  Lexmark 3200
       lex5700  Lexmark 5700
       lex7000  Lexmark 7000, Lexmark IJ900, Compaq A900, Z51
lips2p	 Canon LIPS-II+ (japanese)
lips4v	 Canon LIPS IV vector mode driver
lips4	 Canon LIPS IV raster mode driver
       ln03     DEC LN03
lx5000   Lexmark 5000
       lxm3200  Lexmark 3200, Z31, Z12
md1xMono Alps MD-1000/1300/1500 (monochrome mode, japanese)
md2k	 Alps MD-2000/2010/4000/1000/1300/1500
md50Mono Alps MD-5000, Oki DP-5000 (monochrome mode, japanese)
md50Eco	 Alps MD-5000, Oki DP-5000 (economy mode, japanese)
md5k	 Alps MD-5000, Oki DP-5000
mj500c	 Epson Stylus Color IIs, 200, 1500 (japanese)
mj700v2c Epson Stylus, Epson MachJet (japanese)
mj6000c	 Epson Stylus Color 400, 800, 1520 (japanese)
mj8000c	 Epson Stylus Color 3000 (japanese)
ml600	 Okidata Microline 600CL/620CL (japanese)
npdl     NEC MultiWriter, PC-PR1000/2000 (japanese)
       oki4w    Okidata OkiPage 4w+
opvp	 Gluecode for Vector Driver API
pcl3     PCL-3(+) printers: Many, especially older HP inkjets,
	 non-HP inkjets as Sharp AJ, Xerox DocuPrint, ...
pr1000	 NEC PC-PR 1000 (japanese)
pr1000_4 NEC PC-PR 1000/4 (japanese)
pr150	 NEC PC-PR 150 (japanese)
pr201	 NEC PC-PR 201 (japanese)
rpdl     Ricoh RPDL I/II/III/IV drver for Ghostscript (japanese)
samsunggdi Samsung's old driver for their SmartGDI laser printers:
	 ML-4500, ML-2xx, ML-1xxx, ML-5080, ML-6040, ... and
	 Lexmark E210, same as "gdi"
       xes      Xerox XES (2700, 3700, 4045, etc.)

mag16	 MAG file format (from Red Hat's japanese driver pack)
mag256	 MAG file format (from Red Hat's japanese driver pack)

uniprint/: Some additional .upp files

30th April - 13th October 2009

14th Oct 2009 150am: well I have managed to port gs870 to noixemul, but it required some effort. The build is unoptimised, thus I still have to rebuild again.

13th Oct 2009

1130pm: and now the catch: for a nice port I need to use ixemul. If I use noixemul it is trickier. The build at 720pm was ixemul. I cannot remember whether ixemul builds run on non 68k systems? If ixemul runs on all systems I dont want to waste time on workarounds for noixemul. Basically do 68k ixemul programs run on the A1 and Morphos?

720pm: the port of GS870 to 68k is now complete! and things seem to be functioning correctly. Furthermore there are no warnings with the problem document I mentioned, whereas the rebuilt gs860 gave warnings. Also GS870 is immensely faster than GS860 on the problem document! I have just done an unoptimised build, which is a 14MB binary! I will need to do an optimised build. Also I will need to work on the documentation, generate the downloads, and verify that I havent forgotten anything eg I need to ensure that the icon scripts I created for 860 function for 870. I need to study the notes I made working on this port, etc. Various administrative activities before I can release the port. Thus there will be a delay before the port is released. gs870 WILL be released THIS WEEK, but NOT TODAY!

3am: I have just completed another phase of the port. The port has 2 optional dependencies which werent available. I have now ported those 2 products, which were unproblematic to port. if they arent available then some obscure features arent built eg some strange driver. I will continue tomorrow, the remaining phases are quite tricky. And there are some problems I havent managed to deal with, which I have to revisit. They have made too many changes, things which have been unchanged since GS8. There is still no certainty to the port!

This is day 6 of the total work including bridging the version drift at 860. that work at 860 is in fact part of the port to 870 because if the work hadnt been done at 860 it would have been necessary at 870 and it would have been a lot more difficult. On the bright side, there will be major new functionality, IF the port completes.

12th Oct 2009: I am working now on porting GS870, there are a lot of changes from 860. I am about half way through the first phase of the port. This port is trickier than earlier ones, I will need to test a lot of things (if it completes). There is no certainty at all yet that the port will complete.

11th Oct 2009: I am still enhancing the 860 version. I decided to try printing the problem document with the novel feature and then found that the new build has omitted the necessary functionality. Also a lot of other functionality in the released version isnt in the new version. I am reinstating such things. The only way to know some functionality is missing is if some usage doesnt function.

The new build has a LOT of extra functionality but also omits a lot. eg the new build seems to support a lot of newer printers eg it appears to support some colour lazer printers eg by Samsung (I havent verified this yet) but the support of various legacy printers has been removed and the support of other printers has been removed with people meant to use ijs. I am reinstating ALL the removed printers including ancient legacy ones.

10th Oct 2009 330am: I have resolved all the version drift that I am aware of with GS860. Extremely tricky to do. As a result there is a HUGE increase of functionality and document compatibility with GS860. I need to do some further improvements and then will begin on GS870. I wont release the enormously enhanced GS860 UNLESS I cannot complete GS870. (as the time needed to rerelease 860 will be better used towards 870. in fact I may do the further improvements at 870 instead of wasting time at 860, I have to study which is more pragmatic. Some work is better done at 860.)

Because "normal" documents were processing without any problem I wasnt aware of the version drift. However a few weeks ago I tried printing some unusual document and GS860 didnt render at all. But the document should have rendered.

I have had to do a major overhaul of the build process, even after that the document still didnt render. Very elusive problem. It required a lot of further technical changes to the build and then at around 323am the document rendered perfectly with -sDEVICE=whoosh24. Not only that but a ginormous amount of extra functionality also has now built. Essentially incompatibility is emerging between 68k-AmigaOS and the GS build. But I have managed to patch the incompatibility.

without the example problem document I couldnt have corrected the problem as each time GS860 appeared to have built and was processing normal documents correctly. But each time it was failing completely with the problem document.

I have printed a lot of stuff without any problem with gs860 which is why I wasnt aware of the version drift.

The problem really is a confluence of many different problems.

Someone asked me what version drift is. Version drift is where you are dealing with an external project which has ongoing new versions. Gradually incompatibilities emerge, eg some AmigaOS1.2 games no longer functioned on the A1200. or with my A500 I changed the ROM and some disk chip to install OS2.0, but now some games no longer functioned. The version has "drifted" from your frame of reference. eg Blue Ray DVDs are version drift from the DVD player you bought in 2003. or Obama is version drift from the George Bushes. get my drift?

8th Oct 2009: have just returned from holiday, I have begun towards attempting to port to GS870. There has been a gradual version drift since GS8, as a result I am attempting first of all to remedy the version drift at GS860 which I have begun on today. Once that is complete I will then try to forwards port that to GS870.

I will probably need to do various other maintenance work at GS860. As a result, the port to gs870 will take longer than earlier ports. However, provided the port to 870 is successful it should be a particularly good port.

The maintenance work could either be done at 860 or 870, ie either maintenance of 860 and then forwards to 870, or forwards to 870 and then maintenance. The former seems the better approach.

2nd Sep 2009: I have just completed the last tricky coding problem of the compiler project. There is a lot left to do but its all straightforward. I am going on holiday within a few weeks, what I have decided to do is start the next port attempt to GS870 as soon as I get back from holiday. Hopefully I can complete the port by mid October. Up to the holiday I will try to complete as much of the compiler as possible. I have decided to try to complete all the core features BEFORE stabilising the work. I need to also do some maintenance work with the GS project.

The person who contacted me about an idea that I mentioned on 29th July, he is still working on the idea. He is progressing but its not clear how long the work will take.

29th July 2009: I am implementing conventional objects for my language, these are extremely difficult to implement as objects involve complicated self reference. I completed the main implementation of enums a few weeks ago. The object paradigm is completely different from C++, extremely easy to learn and use but extremely difficult to design and implement.

Someone has contacted me about a very interesting idea as regards Ghostscript, its a project idea of his which relates to the project here. He is looking at the feasibility of the idea. I wont say what the idea is until he determines it is feasible.

I will attempt the next port of GS within the next few months. As soon as I have obects implemented and stabilised with my language I will work on that. Probably August, but could be September or October. (depends on when I go on holiday).

30th June 2009: with 30 minutes left of June 2009, I have JUST completed implementing enough language features to make my language general purpose, catching up with old C. But there are some further language features before the initial language project is complete. eg I havent completed implementing the object orientation mechanism, nor the enum mechanism, both of which are RADICALLY different from C++ and other languages. Also I havent checked or compiled the new code.

(general purpose means enough functionality to write any app, eg old C is general purpose as all of Unix was written with old C. old C is the original form of C from 1978 eg the C examples in the first edition RKMs are old C)

17th June 2009: I have just completed another major feature set of the language. Just one feature set left and the initial language is complete and can be used for coding the rest of my OS with.

I am on schedule to complete the initial complete language this month! (I will do a bit of further work on it before RESUMING AT LAST the OS project) I hope within this month to have my own ultra modern kernel AND language AND compiler.

30th April: I am moving to completion of implementing the initial form of switch statements for my language, all the really important features are now complete. ie source code is compiling to asm correctly, very efficiently too.

Just one major feature left to test, and much later on one further unproblematic feature to implement.

Soon I will be able to code my OS using my language, just 3 language features left to implement before the language can be used for development. The things the compiler can already do are quite exciting, it is virtually a fully fledged language now.

Later in the year I will try to port whichever is the most recent stable version of Ghostscript. Centrally they are working on GS8.65 at the moment, if that is released and stable when I decide that is likely to be the decision.

12th March: I removed the earlier update as it was digressing a bit!

At the moment I am way behind schedule for my language and compiler project. I have got the trickiest things all functioning and am now implementing the remaining parts of the language.

Right now I am working on the latter phases of switch statements. These are quite different from C switches.

The project is moving steadily to completion but is taking longer than envisioned. The work is all downhill now, but some of it is quite tricky

In previous years I would have attempted another Ghostscript port by now, I will attempt one but it will be later than in previous years as I need to bring the language to an initial stage of completion.

I will attempt another port of Ghostscript within this year, but cannot say when. Probably sooner than later. To be honest GS860 here should be all you need.

26th Sep, 9th Nov 2008

9th Nov 2008: I have an interesting subproject of the 68k-GS8.60 project to examine, not sure if it is feasible. It emerged from an email discussion with someone. I wont be able to work on this till later as I am running out of time to try and get the first version of my compiler project completed this year. But it is something I intend to try as soon as time permits. I will explain what its about IF I find out it is feasible. It is something VERY interesting to me at least. The projects on the other webpage are moving towards the 3-year point, but it feels like 7 years!

At the 3-year point I hope to have my own language, my own compiler and my own 64 bit multicore x86 kernel complete.

26th Sep 2008: some people have emailed using temporary email addresses

You can contact me directly via whoosh777 at as I have been unable to reply to the temporary email addresses.

I dont write the email address directly otherwise I get huge amounts of junk mail!

Someone from Holland emailed today saying they were unable to view the OS video on Vista. Consequently I have converted that video to mp4 format now. That video is in fact from some time ago and shows the OS querying the HD and showing mouse events: buttons, and position. There is no mouse pointer yet but there is mouse position which is echoed in the video! A lot of things have been done since then.

I can convert to other video formats as well but I dont know which video formats can be viewed on AmigaOS, if you can tell me which I can try to convert to such. I bought some Windows software which converts between all video formats except mpeg2 as I didnt want to pay an extra 8 quid for the mpeg2 patent!

The OS currently still just uses primitive 1980 80x25 ascii graphics. Once the compiler is functioning, I will then begin work on modern graphics eg windowing etc. The compiler is moving gradually to completion but the coding is very tricky. But just a few really tricky things are left and then its all downhill but a lot nonetheless downhill.

I will do further GS ports later on, but right now all the work is on the compiler.

24-28th july 2008

My compiler project now builds and runs on Linux as a cross compiler. The build and source are now fully portable and I should be able to build it on any OS. There are no OS or h/w dependencies so far with the output.

I could get the compiler to output to any OS or h/w at all but the plan is just to focus on my own OS and 64 bit x86.

One advantage of being Linux hosted is I could make the compiler run on an internet server and allow people to try it out across the internet without giving them access to the binary, just to prove its for real.

I do the coding on WinUAE, Linux is for locating bugs. The build on Linux is 10 x as fast as on WinUAE. AmigaOS topaz 11 fonts allow me to edit with some 128 chars across the screen, super clear. Linux uses rescalable fonts: too blurry at that res. AmigaOS topaz fonts are hand optimised which is the only way to create text editor fonts.

27th July: Slight change of plan. I decided to try and get the same version of Linux as the company where I have another website. But I found they dont use Linux but FreeBSD. I will see if I can port my language to FreeBSD now. FreeBSD is based on AT&T Unix, its free and its not Linux but Unix. I think C itself was originally from AT&T, Unix was based on C and I am creating my own OS based on my own language.

28th July: if I can get a desktop on FreeBSD,

17th july 2008

I have been learning some server side scripting. Using this you can display the website without the foreground photos. The webpage is now index.php instead of index.html. Provided you visit just with the URL the system will select the correct homepage file, the full procedure for selecting the homepage file is too complicated to remember.

For some reason IBrowse continues reloading the original photos. to stop that I think you need to immediately click "stop", and then click "DONT display foreground photos" and not click stop this time.

Clicking "Reload" is likely to display with the photos again!

Via further server side scripting you can send an email via this webpage. To prevent people misusing this your IP number will be sent to you, it will NOT be sent to me. I have already received an advert from the facility!

I could make an option for the website to remember whether you want the photos displayed or not but that would require recording your IP number in some format eg creating a file If you want that as a voluntary option email me using the form and I can implement that.

Note that all website hosting companies capture your IP number, but they cannot determine your email as email is a DIFFERENT service from browsing webpages. From your IP number they know which city and country but they dont know who you are, but for instance your IP number could get blocked. Your webbrowser also tells them info such as web-browser, referral link, etc.

But AFAIK it never reveals your identity beyond your IP number which right now is

Dont worry, I havent recorded your IP, your number only appears to you here!

21st June 2008

Here are the webstats for May 2008, some weeks ago I mentioned about referral stats. But many people reach the site directly via the URL.

These are the country webstats for May 2008, which show about 233 people visited during May:

United States 37  15.9% 
Germany 36  15.5% 
United Kingdom 20  8.6% 
Israel 18  7.8% 
Canada 15  6.5% 
Poland 15  6.5% 
France 14  6.0% 
Italy 13  5.6% 
Russian Federation 9  3.9% 
Switzerland 9  3.9%
Ireland 7  3.0% 
Spain 6  2.6% 
Australia 5  2.2% 
Sweden 5  2.2% 
Netherlands 4  1.7% 
Norway 3  1.3% 

I calculated the number 233 because if 15.9% is 37 for the US then the total is 37/0.159

There are many other countries with either 1 or 2 people visiting. About 10 people visited today, 30 over the last 7 days, 237 over the last month, 1800 since June 2007. More people have visited this year than last year!

10th June 2008

10th June: According to the webstats people sometimes reach the website via google searches for things like -sDEVICE=jpeg. As a result I have put direct access to that specific device right at the top of the webpage. Its a useful representative device. And I have made the explanation of that specific usage reasonably complete, and explained about AmigaOS: perhaps some people reading that may then decide to try out AmigaOS.

Recently I have been learning about internet selling, and decided to apply the ideas to this webpage. That is why there are many changes to the presentation, eg I have applied principles of advert webpages to this webpage. This is a free product, but many principles of commercial products apply.

eg for commercial products web traffic analysis is a central principle and you are supposed to optimise the webpage design for web traffic. And I have applied commercial webpage structure principles to the webpage.

webpages themselves are a form of software and can be optimised,

The redesign is based on ideas I learnt from the webpage design modules of a course on internet selling. But I now design the webpage entirely using hand coded html as that is better than any html editor.

The guys running courses on internet selling all claim to have made HUGE amounts of money from internet selling.

9th June 2008

9th June: according to the webstats people regularly visit a webpage I wrote in 2003. I have put a link to this in the index, iff-->jpeg-->ps-->print (convert iff to jpeg to ps to print)

I will probably move that info to the main webpage, people find that page via google searches for converting iff to jpeg. I have also put links to 2 other pages from 2003: jpeg-->iff, jpeg viewer (convert jpeg to iff, view jpegs) print jpegs via turboprint.

In case you want to print out King Tut from the Amiga 500 Deluxe Paint: convert the iff file to jpeg and either print that with jpeg_to_turbo, or convert the jpeg to PS and print that via GS. you can also then convert the PS to eg png via GS.

with all programs I write, if you run the program without args it will give usage info.

6-8th June 2008

8th June: have made further enhancements to the html. NOTE: The updates are colour coded, one colour means new downloads, another colour means user contrib and this colour means no new downloads but eg web maintenance. The html enhancements should make it easier to read the info and easier to navigate without going via links. All enhancements now are hand coded html and tried out with 68k-IBrowse. Just one problem that IBrowse doesnt seem to use the Arial font, other browsers do show that.

The backdrop photo was taken from an aeroplane somewhere above Europe, clouds look much better from above the clouds!

6th June: Have completely redone the webpage formatting by hand coded html with approximately the same effect and coded to all function on IBrowse. The html is much clearer now eg with the hand html I set the font to Arial with ONE outermost html declaration, whereas the editor html put more than 2000 font declarators!

Handcoding the html keeps the html as mostly ascii with a small amount of formatting.

The amount of work to handcode the site is approx the same as using an editor.

I had to restart the reformatting from the backup I made before I editted.

Some gfx-humour: the graphix for HAM8 in the webpage follows the HAM8 rule.

24th May 2008

I have just updated the webstats for the first time in years and have been studying the webstats, here are some of the referring Amiga websites for May 2008:,,,,

you can visit those to see where some of the current Amiga scene is,

Some references are via search engines in the Netherlands, Italy, Germany, Sweden, France, Japan, Spain, Turkey, ...

Even one or two from the UK!

A lot of referrals from the polish website above, and a moderate number from the russian website.

Looks like for May 2008 the most referrals are from, then and then Also referrals from

For the whole of 2008 there are also referrals from,,,,,,,,

and searches from further places eg Taiwan and Czechoslovakia,

I think there are many french referrals but not from any one site but dispersed. Thus it doesnt show up directly in the stats. There are also many from Holland but all via search engines. I have no idea how GS got referred from futuregamer!

If anyone wants to translate the contents list to any languages that could be useful,

if I have some alternative contents in german, polish, russian, french, dutch ... linked to the english explanation it will probably suffice.

eg "landscape" might not make any sense if you dont speak english but the instructions themselves probably make sense from the shell commands. (it is for rotating a printout by 90 degrees, but I have no idea what the word for that is in any other language. The term "landscape" is because paintings of landscapes ie fields, forests, mountains, rivers etc are 90 degrees from "portrait" paintings, picture of a person looking at the artist. For the same reason you have to rotate a camera by 90 degrees for some pictures. Why dont they just use square pages!)

because "landscape" rotates by 90 degrees it also converts to "portrait"!

"landscape" has many meanings, it means an actual landscape eg a view from a mountain of other mountains, it means a picture of a landscape, it means a sideways printout and it is also a verb meaning to create a landscape eg landscape gardening where they artificially make a garden interesting eg creating a fountain and some paths and a pond, and other artefacts. ie they landscape the garden.

All the meanings are derived from the initial meaning of an actual landscape:

landscaping <-- actual-landscape --> landscape-picture --> landscape-printout (sideways)

The web traffic is less than it used to be, but it is still reasonable numbers. For people thinking of quitting the Amiga scene I urge you to get WinUAE above Windows, you need to use that with Picasso gfx card emulation. That allows you to use a 24 million colour Workbench on a laptop. And you can use Windows for things which are Windows only. That way you can use ALL Windows hardware from 68k-AmigaOS 3.9. ALL the photos above are of or by WinUAE 68020-fpu AmigaOS3.9. Both WinUAE's have approx 512MB.

The way I did it was to capture the OS3.1 ROM and OS3.0 system floppy disks of my A1200 via tools from aminet. Then I installed AGA WinUAE using those. I visited the AIAB website and installed AIAB (Amiga In A Box) which has Picasso emulation all set up ready to use. I installed OS3.9 from the OS3.9 CD above the emulated OS3.1 I forget whether I installed OS3.9 before or after AIAB, probably after. I then customised the AIAB startup-sequence so that the later stuff was the same as my A1200 startup. I used AmigaOS c:list to locate where Windows keeps its backdrops and I sometimes use Windows backdrops on the Workbench. The Windows backdrop manager doesnt tell you where the backdrops are kept. but "c:list WinDH_C: all pat=#?Azul#? lformat=%p%n" finds the backdrop.

On my 22 inch monitor that allows me to get about 128 x 67 topaz 11 chars on screen, versus 100 x 51 for my laptop. ie about 68 percent more chars. The 22 inch monitor is approx the size of a landscape A3 page. The laptop is about the size of an A4 landscape page.

topaz 8 would be much more eg 100 x 71 on the laptop but the font is too small.

I have both machines booted up at the moment, 2 WinUAEs on this desk and I use either a flash USB2 drive or a 500GB USB2 HD to transfer material between the 2 machines. (I have to boot up with the HD already connected otherwise Windows will reallocate drive letters and WinUAE wont function, I have carefully made the HD drive letters to be the same for both machines. AmigaOS 1.0 in 1986 was much more advanced by NOT using drive letters. )

As a system WinUAE is MUCH BETTER than Windows or Linux. I know where everything is with WinUAE, and YAM is much better than Window's Outlook Express. With AmigaOS you can move around the system much faster than any other OS. And Window's windows sometimes block access to other windows, eg you cannot move the one window A until you respond to the other window B. But you may want to move A to read some info to respond to B, cant be done! With AmigaOS all windows can always be moved.

5th May 2008

Someone asked me about a 68060 build. The reason I dont do those is because feedback in the past is that there isnt any speed difference versus 68020.

However as a one off I have done a 68040-fpu build and a 68020-fpu build (removed as pointless!)

68040 and 68060 builds are identical. These builds are just of interest to people with real 68040 or 68060 machines. 68030 and 68020 builds are also identical.

The 68020-fpu build is also there, the 2 binary downloads are with the other downloads.

I have tried out the 68040-fpu build on WinUAE emulating 68040 and it functioned correctly.

For Morphos ONLY USE the 68020nofpu build.

You can determine which version of gs you have via:

version gs:bin/gs

just in case you forget!

In general I wont do 68040 builds at all, and only sometimes will do 68020fpu builds. Alternative builds will only be available when they are in synch with the 68020nofpu build.

23rd April 2008

Wiard Thomas contacted me some weeks ago with a document he had created using various fonts where "-" was not getting rendered with each font. Instead it was being rendered as an undefined symbol which is a square.

First of all we established that the problem was not with GS.

The problem is quite involved: Thomas was using various true type fonts, Trebuchet, TimesNewRoman, CourierNew and Arial. He needed to convert them to PS to use with Wordsworth7. The fonts were to be embedded in the document to preserve the exact look of the document.

The fonts were converted from True type to PS via ttf2pt13 from aminet.

After some weeks of trying a lot of different ideas Thomas eventually found a way to do the document correctly. I have uploaded the procedure he used as a topic converting problematic True Type fonts to PS fonts.

It seems the problem is with the true type fonts which have been carelessly presented. Font information is lost in translation. Thomas eventually found a conversion pathway using ttf2pt13 where the information was converted correctly. Click the above topic to see how he did it. The topic contains a description of the problem as well.

6-7th April 2008

Further to the release of GPL Ghostscript 860 in the previous update I have implemented some further enhancements:

When the whoosh24 viewer is launched it now fills the entire width of the window exactly. Furthermore hitting the tab key will now make the image exactly fill the width of the viewer. If you look at the tab key you will see:


which summarizes the action!

A further enhancement is that the viewer now opens each page at the top left. Previously it would open each page in the middle. I decided that the main use of the viewers is for reading text where you want to start at the top left. Also for reading text you want to make maximum use of the window width especially for cinematic monitors.

The full idea is like this: the resolution you select via -r is the resolution of the underlying bitmap. That bitmap is then scaled using colour averaging to exactly fill the width of the window. You can change the position and dimensions of the initial window via the env variables mentioned in the previous update eg go for full screen default viewer window.

The -r argument thus controls the image quality but not the image itself. The bigger this argument is the longer it is before you see pixels. The default value is -r100 but if you have a lot of memory try eg -r200 or even higher. Go for the biggest value where there are no "couldnt allocate..." messages. If you get any such messages it means either a much slower algorithm has to be used OR that some features are disallowed.

Exactly filling the width means to read the text you only need to scroll vertically. The fastest way to scroll vertically is by hitting 8 or 2 which moves half a page. That is the best approach for reading text. If you look at the calculator keys you will see they have an up arrow at 8 and a down arrow at 2 which tell you which direction you scroll by half a page.

all the keys 0 1 2 3 4 5 6 7 8 9 now have a function, 0 fits the page fully exactly,

7 8 9
4   6
1 2 3 

moves half a page in all 8 directions and 5 recentres. If you have a laptop then there are no calculator keys but the digit keys at the top have these same functions. Less useful for a laptop! Just buy a USB keyboard for the laptop and you get the calculator keys. Laptop keyboards are totally useless.

The design idea of the viewers is to MAXIMISE the image and to MINIMISE the panel. That is why the controls are from the keyboard. Very annoying when program controls eat up too much space. I dont want to look at the controls I want to look at the image.

Download and decompress the gs binary to the right place for the new features.

The idea with the viewer now is that you setup the position and dimensions of the window first and then press eg 0 to see the entire window or press tab if you want to see just the entire width. You can then change that view eg via the up-down arrows and other keys.

For instance setup the window to look like an A4 or A5 page, then press 0. Or set up a short wide window and press tab to read the text and act upon it on some other on screen things.

2nd March to 1st April 2008

GPL Ghostscript 860 for 68k AmigaOS released!

This is the most recent stable version of Ghostscript. Ghostscript is now GPL and not AFPL. There are a lot of changes. GPL is better as there seems to be more inbuilt printer support eg support for some colour laser printers especially japanese ones. They went for GPL as it brings in the Linux users which greatly increases the user base. The japanese and korean companies tend to support anything to do with Linux, which will give GS more manufacturer support.

The newest features I have implemented are documented here.

First the installation has been simplified: just decompress all the downloads to the same place. Then double click the icon "install" which merely sets the env variable gs860 to the gs860 directory of the install. The icon script "startup" then is the startup instructions, IN ADDITION you need to set a large stack eg in s:shell-startup. I use a 2MB stack, but 150K should be alright. Alternatively read the download + install + startup instructions via the contents at the top of the website.

35MB should be enough for the install, installed to RAM was about 33MB.

The binary itself needs 2 assigns: gs860: and gs860fonts: this enables multiple versions of my port to function at the same time and to allow multiple versions to share the same fonts. However ALL scripts and documentation now is relative to ONE assign gs: If you want to use multiple versions of the port then you have to go via gs860: gs854: etc. But scripts now should only be used from the version which is gs: You can only use scripts from one version of gs at a time, but can use multiple versions of the binary at the same time. This is mainly to speed up porting.


Program needs gs860: gs860fonts: and large stack per shell used.

User and scripts need gs:

This means that the version number is only needed for the startup, the usage now can be entirely via gs: This has various advantages, it will speed up future ports as all the documentation can remain unchanged. Furthermore all the scripts and auxiliary programs can remain unchanged as they dont reference the version number.

I have implemented many new features, first to point out a consequence: via 2. and 8. and 3. you can setup via env variables that the viewer views pages at exactly a4 size (if your monitor is big enough otherwise a5 eg laptop). 2 defines the position and size of the initial window, 8 is automatic remagnification of the first page to exactly fit the current window and 3 is that each further window opens with the same position + size + magnification as the previous one.

The features are:

1. You can now have all viewer pages be antialiased by default by setting env variable whooshaa to 1. This was requested a long time ago by Tony Pascoal.

2. You can set the position and size of the viewer window via env-variables: whooshxpos whooshypos whooshwstart whooshhstart This was requested by Joseph Duchatelet.

3. For multipage documents the viewer now opens the next page with the same viewer position + size + magnification. That way you can say render at 300dpi then zoom out till the size is good and then future pages are all done the same way.

4. The viewer now gives the page number first, then the document name then the copyright message. eg "p5 annots.pdf view ę whoosh777...." For the first page it doesnt give the document name.

5. If the viewer cannot allocate enhancement buffers it only gives an error message once, the same error on later pages of the same viewing dont give an error message.

6. The viewer startup info window now only appears on the first page of the first document viewed in a session. Next document you view it doesnt appear.

7. The view windows are better hidden now until ready to view when they move into view. In previous versions the viewer was appearing too early.

8. The viewer now remagnifies the first page of a document to exactly fit the window. (unless you have whooshw set to 1).

9. You can at any time remagnify the image to fit the current window by striking 0.

10. There is a viewer script in icon_scripts.lha for multiselect conversion to eg pdf. For this you multiselect the documents you wish to convert, you select a destination directory and a completion directory. The documents selected via left shift select are then converted to the destination directory and then moved to the completion directory. This functions on 68k AmigaOS but I dont know if it will function on other setups. Use at own risk eg experiment in ram:

If there are any problems at all email me as soon as possible as I will be going on holiday soon. There is now just one build the 68020-nofpu version as that makes the project more responsive. If I have to support 2 versions it just leads to motivation problems. Each extra thing I have to do becomes a reason to delay doing any work. eg if I had to do the 68020-fpu version as well it would probably have delayed things by another day. AFAICS there is very little difference between the fpu and nofpu builds. Project maintenance is highly labourious. Having 2 builds doubles the hassle. In the end it is too much.

Everything now is via gs: eg the documentation and scripts now refer to eg gs:bin/gs and gs:lib/ps2pdf.amiga, originally it was via gs854: and c: but the problem with c: is that if you have installs of 2 different versions of the project that the earlier version gets called instead.

The gs: assign gets around that problem by not being a multiassign. The problem with c: is it is a multiassign and if gs854: and gs860: are in the multiassign gs854: is probably earlier. Also when a new version is done I dont need to change all the documentation from eg gs854:bin/gs to gs860:bin/gs. gs860: is still there but just for the binary.

The downloads now have the fonts already in gs860: that just simplifies the startup instructions as the startup icon can automatically do:

assign gs860fonts: gs860:fonts

even though you can redirect gs860fonts: anywhere. I am just removing delay and complication factors. The downloads are now all within a gs860 directory, that is just to be able to give the directory an icon in the archive so that you can access the install and startup icons without any extra action. To use this build you just decompress to 1 directory, double click install, double click startup, set a large stack from the shell and you can now use the program.

The earlier way I did things was more efficient but more complicated to explain and more effort to maintain. I decided the most important thing was development and maintenance efficiency. From the user POV it is better I support more versions than more builds.

I have run out of time just now, but once time permits there are some further things I want to study. This port has been very relentless work, I worked harder than usual as I wanted to get the work done before my holiday!

3rd March: I have uploaded another icon script to icon_scripts.lha, which is multiselect_view, this enables you to select several documents to view consecutively.

I need to emphasise that the point and click icon scripts are very straightforward for many things, you need some auxiliary programs for some things which are supplied. For instance the script to multiselect view documents is:

stack 500000

; NOTE: pattern used here as acceptpattern doesnt function on all systems

RequestFile title "multiselect documents to view" pattern "#?.(eps|ps)" multiselect drawer gs:examples > env:temp

multisplit env:temp ram:script gs:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE -r100

execute ram:script


Now if you replace -sDEVICE=whoosh24 by -sDEVICE=tp24 and omit -r100 the script will now print the multiselected documents via Turboprint. And if you replace gs:examples by some other directory the requester will open at that directory.

You need the auxiliary program multisplit which is in the archive. What that does is read the multiselection from the first arg env:temp and generate a new script file ram:script by putting the following args gs:bin/gs ... followed by each multiselection.

Thus you can use multisplit for other things not just GS. For GS you must have a large stack set eg 500000 here otherwise the script wont function!

displaybeep creates a noise set by Sys:Prefs/Sound on 68k-AmigaOS. On some non 68k systems displaybeep doesnt function, replace it by any program or script that makes a sound.

The multi_convert_to_pdf script shows how to do more complex actions via multisplit such as convert and move. That script puts TWO auxiliary scripts in the multisplit args.

The difference between these scripts and MUI is these are user level whereas MUI is expert level. Any user can create functionality in a few minutes which isnt on Adobe Acrobat! eg you could convert document pages into webpages by using c:echo to manufacture the html for each document and gs to convert the pages to jpegs via -sDEVICE=jpeg

1st April 2008: someone was asking me about not having to set the stack each time. What you can do is set the stack in s:shell-startup. On AmigaOS when you open a shell the commands in s:shell-startup are called first. So you can put:

stack 1000000

say at the end of s:shell-startup

s:shell-startup is mainly for things which are per shell and not system wide, eg aliases, local env variables, stacks. When you set any of these it doesnt affect other shells, ie they are localised actions.

I dont want to make gs set its own stack as the size may either be too much for some machines or too little for some problems. Furthermore people expect to be able to set stacks from the shell and it would conflict with that.

I am implementing some new enhancements to the GS viewers, I hope to upload them before next week. Probably I should do a full rebuild as well.

============= 29th Feb 2008 ================

Beginning work on Ghostscript 8.60 for 68k-AmigaOS

If I run into problems I will attempt an earlier version instead.

First thing I am doing is moving the project development to flash disk, instead of hard disk. That allows me to develop from any machine.

930am: making gradual progress. WinUAE seems much slower when a flash drive is connected even if you dont access the flash drive, so I probably will revert to HD again.

330pm: I have made reasonable progress since 930am but a lot left to do.

8pm: I think I can probably complete the port of GS860 by Monday, there have been problems but it has been less problematic than gs854. To speed up the development I think I will only do a 68020-nofpu build. Doing 2 builds just delays everything. 68020-nofpu builds run on all systems and are fine. I have been making various improvements to the build which should speed up future builds. I have also been enhancing the install.

I now keep the project on a flash drive but build in ram: which was the coding paradigm used with the A500: copy everything to ram: and work from there.

============= 27th Feb 2008 ================

I am planning to begin on the next port of GS on Friday, I will take tomorrow off from computing and begin on Friday. I have completed what I was working on with the language. Just making a few improvements.

I have written some batch conversion point and click icon scripts, one script converts an entire directory to another directory and then moves the converted files. The other script allows you to multiselect files to convert from a file requester. After conversion the documents are moved to another directory.

Someone has been trying these on their system but there is a problem with one of the scripts, trying to resolve that. On my system the scripts function fine. Everything done just with AmigaOS scripts, no MUI or AREXX used. I will upload them once the problems are resolved.

============= 22nd Feb 2008 ================

I have had some feedback on the point and click icons. AmigaOS icon scripts are a very powerful paradigm. They allow you to use the Workbench as a GUI, where the buttons are icons.

I was asked about output to know when a script is complete.

I have written a small utility for this, I thought there was a program in C: for this but it appears to be only available at the OS level.

At the end of a script if you put displaybeep this will produce a sound when the script is complete. You can select alternative sounds via "Sys:Prefs/Sound". All the program does is to call the intuition.library OS call DisplayBeep(). You can run it via the icon also: The source for it is displaybeep.c

That way you dont need to keep looking at the computer waiting for it to complete and can get on with other things. An interrupt concept!

One other thing: you can move an icon to the Workbench also just by moving it with the mouse instead of selecting "Leave out" from the WB menu. The fastest way to return it to the directory is via the WB menu "Put away". If you forget which directory the icon is from, you can find that by left clicking the icon and then right selecting Icons--information from the Workbench menu. That gives the full path.

Because there are so many alternative usage paradigms sometimes some of them get forgotten. Often the most effective way to do things is with AmigaOS scripts, c:list is especially good.

Also with the point and click icons, there are TWO stacks, one is the stack you see in Icons--information, and the other is the stack within the script. I think the Icons--information stack is the stack for c:iconx the default tool, and the stack within the scripts is for gs.

The easiest way to customise the icon scripts is to copy them to ram by moving the icon with the mouse. Then rename via the menu: Icons--Rename and then customise the script: left click the script icon then press left-shift down and simultaneously double click the icon of a text editor eg Sys:Tools/Memacs. If you left click the text editor icon first then left shift double click the script icon that also functions. At the end move the new customised icon back to the directory.

Copying the icon via Workbench menu Icons--copy doesnt function on 68k-OS3.9 if the filename is long: overflow problem. If the filename is short then its ok and you then select rename.

Next port likely to begin in February (2008)

Things are progressing much faster now with my language and compiler project, as a result I have drastically improved the estimated timeline for the compiler project. It was the previous phase of work which took much longer than expected.

I want to complete the compiler subtopic I am working on just now which relates to some tricky implementation problems, have at least one day of holiday from ALL computing and then will begin working on the next Ghostscript port.

Some complicating factors: I may be away from the internet while working on the port which could delay making the work available.

I cannot guarantee to succeed at the port, it is a port attempt.

Fortunately I have WinUAE on a laptop so I can take the project with me.

============= 19th Feb 2008 ================

I have completed an initial version of a major component of my compiler project. I have been working towards this since mid November 2007. It is one of the most difficult subprojects of the work I am doing. This is now running fine on 68k-AmigaOS, the initial compiler is a 68k-AmigaOS hosted cross compiler.

A lot of cool features of the new language are already functioning correctly. If I give the compiler example programs it processes them detecting many errors. But there is no code generation yet.

This should bring forward the timeline for working on Ghostscript.

start in February: 30% probable.

start in Feb or March: 80% probable.

I now have 2 computers on my desk with UAE, a laptop and my tower system with a HUGE landscape a3 size monitor!

The monitor is 1680 x 1050, but I use it at a mere 1024 x 768 as that is the highest res that Memacs accepts. They should do a 68k-AmigaOS 3.10 and resolve some of the annoying bugs and make it UAE compatible. I think a LOT of people would buy 68k-AmigaOS 3.10.

H and P where are you?

============= 13th Feb 2008 ================

I have enhanced the point and click icons:

The viewer script now views to fill the width of the Workbench. That is the optimal way to read a document as you only need to scroll downwards.

The convert_to_jpg now converts with maximum quality.

I have also given the directory an icon to make it easier to try out.

You can customise the start directory of the view icon, the current icon starts at gs854:examples but you can change that to wherever you want the viewer to look for documents.

If you single click any of the icons and from the Workbench menu via the right mouse button select "Icons--Leave out" then the icon appears directly on the Workbench. You can then directly double click the icon when you want to view without going via directories. This is a standard AmigaOS paradigm, which anyone who had an A1200 or earlier will know.

The point and click icons are several standard ideas combined to create a very convenient reconfigurable interface.

This is the new download.

============= 10th Feb 2008 ================

I have created some AmigaOS icons for a point and click approach, eg an icon "view" where you double click, select document and it views. An icon "convert_to_jpg" where you select a document and it is converted to jpegs in ram:. And an icon "convert_to_pdf" where you select a PS document to convert to pdf in ram:

For convert_to_pdf, you will need

assign c: gs854:bin add

in the startup,

This assign is now part of the startup assigns instructions

The download and documentation are here.

============= 3rd Feb 2008 ================

Further to 27th Jan, March is starting to look more likely.

I am starting to make better progress now with my language coding, some of the problems had been very tricky eg dealing with circular type definitions eg the equivalent of:

struct a { struct b b ; struct c c ; } ;
struct b { struct a a ; struct c c ; } ;
struct c { struct b b ; struct a a ; } ;

struct x { struct y *y ; struct x *x ; } ;
struct y { struct x x ; struct y *y ; } ;

struct z { struct z a ; struct z b ; } ;

Here x, y are ok but a, b, c, z arent. All are circularly defined, it takes some work in software to determine well-definition the problem is that to evaluate a you recurse to evaluating b and c, but b recurses back to a: the problem is that a is in the middle of being evaluated. In a way it is a meta level problem.

Because of the better progress it looks like I can bring the timeline for the GS work sooner.

New probabilities:

Begin in March: 60 percent probable.

Begin in Feb: 30 percent probable.

Begin in Jan: 0 percent probable.

Sometimes I get asked about putting zoom buttons on the viewer. The reason I havent done that is because it is MUCH FASTER to use the keyboard. On the Amiga when you click a window it becomes the ACTIVE window and it OWNS the keyboard. Any key you press on the keyboard goes to that window. That gives you more than 50 HARDWARE buttons.

If you look at the keyboard you will see 4 arrow buttons, you can hit one of those VERY FAST, but to move the mouse to a screen button is very time consuming first you move the mouse near the button then it takes some effort to manoeuvre the mouse to the exact place.

Now to the right of the arrow keys you will see:


Those allow you to move very fast around an image in 8 directions and 5 recentres. That means the arrow keys and digits give you 13 HARDWARE controls of the viewers. There are further keys also which are shown when the viewer starts. To put all those on screen will eat up A LOT OF SPACE. A lot of CLUTTER.

The hand is much faster than the mouse. And if you press a wrong key a window appears to tell you the keyboard controls.

I want all the space to be for the page being viewed, I dont want some HUGE control panel and a tiny image. Instead the controls ARE ALL HARDWARE LEVEL, keyboard and mouse. No onscreen controls which MAXIMISES the viewspace. This is a design principle.

I have some financial software and it has 2 ways for moving a share to a portfolio: either the menu or a keyboard shortcut. The keyboard is almost instant but the menu is nerve grating. But it has been known since the earliest home computers that the keyboard is the best way to control a computer.

With the image itself there are no scroll gadgets, MUCH MORE DIRECT scrolling by clicking and dragging the image. Scroll gadgets eat up screen space and are inconvenient as you have to move 2 gadgets, first you move y then you move x. Click and drag is the most direct way you move BOTH x and y directly.

Today all the Windows programs are starting to use this same concept, but I implemented that in 2003. Even Google Earth uses this idea where you click and drag the planet. I think Java now has this concept built into their design.

But via AmigaOS my viewers give you a super efficient implementation of the mechanism. Just move the mouse to anywhere on the image. Press the left button down and move the mouse without releasing the button and the image will move with the mouse. Release the left button when the image is where you want. This phenomenon is called "click and drag", which means moving the mouse with the left button pressed. AmigaOS uses the idea for moving an icon to a directory. That is called "drag and drop". Click and drag, drag and drop. Some of the PC programs show a hand which grabs the image, but some dont change the image. Not changing the image is better as the tip of the mouse defines where the mouse is.

Personally I want speed and efficiency and not pretty gimmicks, XP programs go OTT with gratuitous imagery eg reflections etc!

The viewers use more of a game paradigm, when you play a computer game you use the mouse or joystick directly, it would be silly to press buttons in a game eg to press a left button to move left! My idea was you play with the image directly. Its a question of paradigm, 3 different paradigms: keyboard, gadgets, menus. Some people have touch screens more efficient than the mouse. I think the arrow keys and 1,2,3,4,5,6,7,8,9 controls are unforgettable. The text window at the start reminds you of all the controls.

I have just bought a huge 22 inch TFT, 1680 x 1050. Less than half the price of my 1024 x 768 monitor from years ago. I thought my laptop 1280 x 800 was big, but this is hugely bigger. I set WinUAE to this res, and tried the viewers. I wasnt sure what would happen! In fact it was alright, 47cm x 30cm view. At 500 dpi there wasnt enough memory for the zoom facility. You can get even bigger monitors but they are very expensive. Java on XP runs into efficiency problems with such a big size. A cool thing about huge screens is you can have lots of windows in full view simultaneously. Looking at webpages at 1680 x 1050 is really cool.

Someone requested that I allow the caller to set the position of the viewer. He is working on some unusual meta level ideas connecting up different programs simultaneously. That is on my todo list.

============= 27th Jan 2008 ================

Further to the timeline given on 7th Nov 2007, I will probably start attempting the next port in March or April 2008 keeping to the given timeline. I havent got too much done this month. The more precise timeline is that I will BEGIN the work very probably in March or April and will allocate AT LEAST 3 weeks. Provided the work is progressing I would go beyond 3 weeks if necessary. This next port is going to be more difficult than earlier ones.

If I make plenty of progress with my language project in February then I will start in March, but I cannot guarantee that. It is possible but is a problem mainly of motivation.

Begin by 30th April: 98 percent probable.

Begin by 24th March: 40 percent probable.

Begin by 21st February: 10 percent probable.

Begin by 31st January: 0.5 percent probable.

The realistically optimistic start point will be approx 24th March 2008 But there is no guarantee at all of that. Anyway March would be an improvement of the timeline by 1 month. The pessimistic start point would be approx 21st April 2008. OTOH February is just about within the realms of possibility but unlikely.

============= 20th November 2007 =================

Someone emailed me about a topic I wrote about from 2003! I had completely forgotten about it and it is something worth trying out so I have reinstated it here.

It is about using GS as a typewriter, where you directly enter text interactively, either to the GS viewer window or to a printer.

You need to download and then an example usage is:

gs -sDEVICE=whoosh24 -r30 -dNOPAUSE
GS> Newline
GS> (Hello world!)show
GS> 255 255 0 Square
GS> 255 0 0 Square
GS> Newline
GS> 0 0 255 Square
GS> 0 255 0 Square
GS> Print
GS> quit

For the full explanation see here.

You should be able to print directly to Turboprint the same way eg:

gs -sDEVICE=tp24 -dNOPAUSE

GS> Newline
GS> (Hello printer!)show
GS> Newline
GS> 255 0 0 Square
GS> 255 255 0 Square
GS> 0 0 255 Square
GS> Print
GS> quit

Dont give any res as that is set at Turboprefs, for the viewer you need to give a lower res otherwise it wont all be visible. The fontsize and font can be changed, see the explanation on that.

============= 7th November 2007 =================

To be definite I think I will attempt the next port of Ghostscript within the first 4 months of 2008. I will reduce that timeline if I can.

I recently decided to shelve implementing C/C++ and instead develop my own language. This is proving a good decision as I am progressing much quicker. So I may be able to work on Ghostscript sooner than previously thought. I will continue to implement C at some future point probably AFTER the OS is complete.

The change of plan is because I realised that implementing C++ will probably take 4 x as long as developing and implementing a new language AND I had no plans to use C++ just to implement C++. I will continue the implementation of C eventually as I need that for meta reasons. Anyway its all to do with time: going via my own language will buy me a lot of time. I dont want my various projects to take a second longer than necessary.

The problem with things like C++ is that you can get drawn into them and implement them just because its a challenge. which is what was happening. But the challenge for me is the OS, which I began in early 2006 so it is almost 2 years of work now and I have achieved a huge amount of progress eg I have completed a 64 bit x86 multiprocessor kernel and am progressing towards my own 64 bit compiler of my own language for that. The language is now mostly designed and I am beginning the second major phase of implementation work today. (I am implementing it before the design is complete as language design always goes on forever, eg C is still being worked on today)

I always prefer to work on new ideas, C is from 1978 and C++ I think is 1985, 22 years ago. They are still working on the design of C today 29 years from the original version!

============= 30th October 2007 =================

When I reach an appropriate completion point with my various projects I will attempt a new port of 68k-AmigaOS Ghostscript. My aim is to complete my various projects within 2008, I dont know for sure I can but that is the wish.

I think a new Ghostscript port attempt will be in 2008, as I have just November left this year for programming. They have been making too many changes to GS recently, so I will probably attempt the earliest stable version after 854.

This is a transition problem, the next version will probably be less recent in time. The version after that should be more recent.

Although I am developing my own projects I will continue supporting 68k-AmigaOS. Generally speaking I like pioneering works, eg the Amiga 500 and old C. I like things created out of necessity also like OS3.0. The bad guys have won but the early stuff is always the best. OS 1.2 kix linux.

AFAIAC GS854 gives me all I need, but I will continue beyond that,

Were it not for all the changes I would attempt the most recent stable version, but there are problems ahead so I need to be conservative.

No idea what is happening in the amiga scene now, last I heard Acer had bought up Gateway (I never liked Gateway). Big fish eats medium sized fish. Anyway I write this update on MicroEMACS V2.1 on WinUAE 68k-AmigaOS 3.9 on a rather cool dual core laptop (not as fast as my tower).

============= 16th September 2007 =================

Someone emailed me saying QNX realtime is now opensource. I should point out some theory: a realtime OS is one where ALL OS actions are time-guaranteed. Each and every thing you can do in a realtime OS has a time guarantee. eg if you write a script you can guarantee that it will complete say in 0.5 seconds.

But time guarantees can only be done by limiting EVERYTHING. You have to limit the number of tasks, limit the number of files, limit the sizes of files etc. A realtime OS will typically use fixed size tables for all OS resources. That is the only robust way to timeguarantee things. This has 2 advantages: the OS is much simpler to implement and much faster. But there is a MAJOR DISADVANTAGE: EVERYTHING IS LIMITED. You may be able to reconfigure the limits but high limits will be very wasteful of resources and will lead to wasteful guarantees. eg if you limit to 100 tasks and there is 1G then you have to preallocate 10M per task. That way a task will start really quickly as the limited memory it needs is already there waiting. But it limits the memory per task to 10M. Now 10M is enough for most things, but once in a blue moon a program wants 500M.

The time guarantee for say a script is calculated by adding the time guarantees for each step, and multiplying by say the size of a loop etc. But that can only be done if you limit the size of a loop.

So an OS such as AmigaOS or Unix where NOTHING is limited is much more sophisticated but there is no timeguarantee. It is vastly more flexible but not quite as fast. Usually realtime OS's are for safety critical use eg factories, nuclear power plants, etc where you need to guarantee response time to an emergency.

The net effect is that a realtime OS reacts superfast ie it reacts in realtime, it reacts immediately to problems. But that is done by keeping everything small, ie cheating. To the untrained eye it can look very impressive.

When commercial wares go free that usually means abandonware, I suspect Linux are eating into QNX's customer base and going opensource is a last ditch attempt out. Todays machines being so much faster I think realtime is less relevant. Safety critical things are probably better via human operators, who keep an eye on things and press a red button. You dont need realtime, you can just set up a dedicated mechanism for each safety critical thing. eg setup a temperature controlled power off switch. That is much more robust than going through an OS. NEVER RELY ON COMPUTERS! A fuse is an excellent example of a realtime mechanism which doesnt use computers. The fuse reacts immediately to excess current.

BTW AMD CPUs have a disclaimer that they mustnt be used for safety critical things. So strictly speaking you cannot use AMD for realtime.

I think realtime isnt much use to AmigaOS, the only way forwards for AmigaOS is to create a brand new system like I am doing with my own OS and then to host the classic system above that. integrating the classic system is a bad idea as it will constrain the new system. Hosting itself is a special form of integration, but it avoids constraints. But this means the classic system is orthogonal to the host system. Which means you may as well host the classic system above ANY system. But then are you moving forwards? The answer is yes if the new system furthers the successful ideas of the old system. But to create a new system you dont need to go via Amiga.

My own OS project is my own response to the systems I have used: AmigaOS, Unix and Windows XP. Working on my own OS I am getting major work done, I am realising everything I ever wanted to do in computing. I have already completed more things than I can count, and it is all geared to the newest x86 PCs you see in the shops including ironically the Gateway ones. So it is the longest run of success I have ever achieved. The day I bought an x86 machine my luck changed from lose-lose to win-win. I am not denying what the Amiga is but am doing what I want to do. I dont know where the Amiga is going or why but I accept AmigaOS up to and including 68k-AmigaOS 3.9. Up to 3.9 it all makes sense. Some people like and want the things they are doing. It really depends on your frame of reference. If they are doing what you want then you should support their work.

============= 5th September 2007 =================

Someone emailed saying the photos on this page are too big AFA the time it takes. However I need them like that for reasons of psychology as it is the Microsoft philosophy of pushing everything to the limit unnecessarily.

If you are on dialup, ALWAYS switch off picture loading as that eats up a lot of time even if the pictures are small. I know that both IBrowse and AWeb allow pictures to be switched off. Trying this just now on IBrowse, I selected from the menu:

Preferences -- image loading -- none

And this webpage loaded literally in 2 seconds on slow broadband, with no pictures just unfilled rectangles for where the pictures should be.

As pictures can be switched off on both the main Amiga browsers I will leave them as they are. As mentioned above if you are on dialup you will save a lot of time and money by switching off pictures altogether. On some websites on some buttons the button action is written IN the image. For this situation just load the individual button image individually:

With IBrowse it is done thus: move the mouse above the picture, then press right mouse button and select "Load image". That individual picture is loaded.

If you have configured to a different language then reconfigure temporarily to english for the above actions.

============= 30th July 2007 =================

The next version of GS looks like it will be tricky, they are making a lot of changes attempting to unify GS with Linux. GS is thus getting full endorsement from Linux which will probably be a good thing as long as they dont make too many changes.

I will work on that further in the future, as before it will be for 68k-AmigaOS.

If you use Michael Merkel's GUI for GS854 email him and say which variant of AmigaOS you use so he gets an idea of what the user base is.

For 68k-GS854 the user base is about 1300 people, half of whom use the 68020-nofpu build and half use the 68020-fpu build.

I hope someone does UAE for my own OS eventually that way we can use this port from there. My OS will supply a full 64 bit x86 virtual machine, so it will be ideal both for UAE and for hosted x86 AmigaOS. That virtual machine is already implemented but no API yet and no graphics, various functionality not implemented but it does function already eg the videos on the other webpage. The text there is to a non virtual shared 1980 screen. The most difficult part of the problem is already done.

I am thinking of implementing C++ instead of C for the next phase of my compiler project. The compiler would then compile BOTH C and C++. The preprocessor is already implemented 68k-AmigaOS hosted, and I will begin the C++ compiler as soon as the current OS subproject has stabilised, again initially 68k-AmigaOS hosted.

I found that Geekgadgets C++ does in fact function, g++, however eg try-catch doesnt function.

============= 17th July 2007 =================

Michael Merkel's redone external GUI for GS854 is here. Contact him for any feedback as that is his project.

I should point out that Unix/Linux people wont like my OS project either as I am also trying to go beyond where Unix reached. Unix hasnt changed much since the 1970s and Linux is merely an unofficial version of Unix.

The reason AmigaOS is still popular is because external projects modernised it: cybergraphics modernised the obsolete interleaved bitmaps to modern gfx cards and Turboprint modernised the printing. Those 2 projects allowed AmigaOS to continue to outdo Windows and Linux. And MUI modernised the windowing. MUI is 10 years ahead of XP. My GS854 viewers in fact dont use MUI but use low level AmigaOS gfx and intuition functionality. Geekgadgets modernised the development side by catching up with Unix. External projects have also kept the Amiga compatible with PC hardware eg USB. Amiga didnt do that, external people did.

My OS project is just modernisation completely externally, AmigaOS itself was a challenge to Apple, Unix and PCs of that time. AmigaOS is a bit like the concorde aircraft, a very modern idea: supersonic superfast airtravel between europe and the US but they didnt further the idea. Now some aeroplane company could create a new supersonic aircraft. But to continue with concorde is to be stuck with 1970s constraints. The hovercraft is another example. Nobody stopped concorde from being continued, they have only themselves to blame. Now the helicopter invention was continued and is a major success story.

I want to make a career from programming and that wont happen with AmigaOS. I need a user base which is 10000 x as big as AmigaOS's current user base. Amiga just are NOT going to deliver that user base: they COULD by going x86 but they WONT! Its too late anyway as I already have a 64 bit multiprocessor pre emptive kernel. I am creating a system sufficiently ambitious to be worth programming for, the way the A500 was.

I think PPC itself is highly influenced by MIPS, almost identical asm, according to wiki MIPS was 1985 and PPC 1991. So similar that gcc's PPC is a customisation of gcc's MIPS. eg MIPS has 32 registers r0 to r31 and r0 is hardwired to 0. MIPS does the instruction after a branch. The original MIPS had 32 bit instructions with 3 registers. Is it a coincidence that PPC does all these things? x86 is much better for moving from 32 bit to 64 bit as little endian memory extends fields leftwards, whereas big endian extends fields rightwards which is the wrong direction.

============= 4th July 2007 =================

Michael Merkel has been enhancing his GUI, not completely sure what his plan is.

At the top of the webpage I mention about my OS project, I have almost got 64 bit x86 multiprocessor pre-emptive multitasking functioning. I know some people wont like what I am doing, but the ideas that Amiga started MUST be continued and brought to x86. The current Amiga variants official and unofficial are just NOT challenging Windows. The Amiga is the most asynchronous OS I have used, its windowing architecture is much better than Linux and XP.

The thing is the classic Amiga was for the 68000 in 1986 and we are 21 years later. Vista is geared to 64 bit multiprocessor x86 machines eg my laptop here is Vista "capable" and has a dual 64 bit cpu the AMD Turion X2. The Amiga architecture even now outdoes Linux and XP but it really needs to be totally redone in order to fully eclipse Windows.

With this microkernel I am completing, a completely modern AmigaOS COULD be done. Now I cannot do that myself as AmigaOS is proprietory, but if someone wanted to they can do that above my system. I am making this system according to my own ideas on things. The only way to modernise AmigaOS is to do something equivalent to what I have done. What I am doing is inspired by the best of both AmigaOS and Unix. All developers agree that the perfect world is somewhere in between the Amiga and Unix. The problem with SOME of the current Amiga projects is they are just copying Linux on everything. That is NOT the answer. Linux is just a revamped 1970's architecture.

The Amiga is the most usable and the most programmable OS ever. But Unix is probably the most sophisticated OS ever, Unix is from around 1978 and C was invented in order to do Unix. The problem with Unix is it is so unusable. Geekgadgets on AmigaOS is essentially an emulation layer of Unix hence "ixemul" ie Unix emulation. I do a lot of things with Geekgadgets which in a way is itself something in between Unix and AmigaOS.

The problem is the Amiga user base have an almost religious belief in the Amiga when in fact the interesting thing about the Amiga is not the specifics but the philosophy of the machine. It is like different countries make fighter planes but all fighter planes are the same philosophy. It is the concepts and philosophy which need to continue not necessarily the product. The problem with Windows is it looks like an Amiga but is the exact opposite philosophy: the Amiga empowers whereas Windows is a disempowerment philosophy. If I make enough money with my OS I think I will buy up AmigaOS and have it modernised to x86.

According to my webstats there are about 1300 users of my GS854 port. That confirms the theory that there are a few thousand people in the scene. Now if I look at February 1994's Amiga Format magazine their ABC (Audit Bureau of Circulation) says 140299 readers jan to jun 1993. I have heard it said that about 2 million A1200's got sold. So the Amiga 1200 despite all its problems was probably 100 to 1000 times as big a scene. The Amiga ideas should be reaching a much wider audience. And the people in charge IGNORE the majority of users who DEMAND x86. Well I am implementing EVERYTHING I have heard requested in forums. If you want to make a career in computing you need to support projects which listen to the users and create systems worth investing time on and aim for a large user base. The Amiga is a company which has been bought up by another company Gateway and you need to explain to me why Gateway dont have A1's in their shops! In fact my OS will run on the Gateway 64 bit x86 PCs I see in the supermarket. (I am not criticising them but just pointing out a contradiction).

It will probably be more than a year before my project completes, I hope to complete before the end of 2009. But the microkernel is ALMOST complete and I could sell that if I wanted.

Two videos are here a video of multiprocessor multitasking on a 2-cpu system and on a 1-cpu system. On a 1-cpu system it is the same as uniprocessor multitasking. Read the info to understand the video better as multiprocessor multitasking is quite different. You can tell how many cpus you have by looking carefully at the text output of the demo. It has taken me 1.5 years to reach this point and the code will run on up to 256 cpus: x86 is limited to a maximum of 256 cpus. It is completely my own design and it is 100% asm.

Someone told me I wont win any Oscars for those videos!

I think we have to stop thinking in terms of brand names but in terms of developers. If you keep the brand name but completely change the developers then it is a completely different project. Things may get better or worse or different. Examples of things getting better was components of AmigaOS being redone in C from BCPL and asm. You can judge a project by seeing what users say in forums. If most users are disappointed or angry then it is a bad project.

Progress comes from new projects starting out of frustration with existing projects. Sometimes people will remove popular features and a new project may try to reintroduce the features. It is the developers that matter not the brand name. Amiga's OS really is Sassenrath who created exec. But Sassenrath left the scene a long time ago and today is involved with REBOL (IIRC).

Note that XP was completely inadequate for 64 bit multiprocessors which is why there is a brand new version of Windows: Vista. In fact 64 bit x86 was designed by AMD according to Microsofts wishlist. Most XP users dont want to switch because XP is mature and they have invested in a lot of apps. XP is comparable to OS3.9. So even something as recent as XP cannot cope with the Gateway PCs you see in the supermarket.

I had the good fortune of starting my project a year before Vista was released. But compelling reasons for going x86 were known 2 years ago. AmigaOS users have been demanding x86 for at least 4 years if not 6, go read which is the most barometric of the forums. Apple also I think have changed drastically a number of times. To go beyond OS3.9 AmigaOS has to change drastically. My OS is the required change and has the advantage of escaping all the contractual trickery. Gateway are basically sitting on the rights to AmigaOS. Which is why the Amiga is turning into a VW-enthusiast computer.

I remember some Amiga magazine celebrating Gateways purchase of the Amiga. That magazine doesnt exist today! For backwards compatibility there are 2 paths, use external emulation eg UAE for 68k binaries OR have a hosted native classic AmigaOS so programs can be ported. Integrated emulation is a BAD idea as it integrates all the problems. WinUAE is proven to be the best backwards compatibility path.

I have so many indispensible programs on the Amiga that I will probably be using 68k-AmigaOS 3.9 for at least another 5 years. example programs other than GS!: PGPGoesMUI, YAM, Gui-FTP, Memacs. I use all 4 almost daily. I also have numerous utilities of my own, sometimes I create temporary utilities: I write a utility to do something very specific and discard it afterwards. I use the Amiga where it is better than the alternatives, I dont use it for some retro reason. The Amiga user experience is much better than Linux or XP.

============= 11th-12th June 2007 =================

Mathias has completed the GUI work he was doing, Michael Merkel is enhancing that and merging it with his original GS8GUI work. It is called GSGUI now to avoid referencing version numbers, possibly it may get renamed further.

The code looks good, I havent tried Michael's enhancements yet.

============= 5th June 2007 =================

I think Mathias is currently working on the GUI.

Someone emailed about the screenshots taking long to render, however if you use IBrowse or Internet Explorer the text part of this webpage is rendered first then the images are gradually rendered. So you can use the webpage fully before the images are rendered.

I need to have those images for presentational reasons, I now go for maximum use of technology which is the Microsoft idea. I urge anyone who uses the internet to get broadband. you can switch off rendering on IBrowse via the menu sequence: (preferences)(image loading)(none). Individual images can then be loaded by right clicking on the image rectangle and selecting (load image).

If you use dialup you should do ALL WEBSURFING WITH IMAGE LOADING SWITCHED OFF, as all images cost time and money. Images are only if you use broadband. If a button has the writing on the button then load that image individually.

The irony is that broadband is much cheaper than dial up, broadband here is about 20 quid a month, which is about 66 pence per day ie about 1 euro. That is 24 hour access and 8x the speed of dialup. So if it takes you 20 minutes to download a file with dialup at 1.5p per minute that costs you 30p. But with the broadband it will take 2.5 minutes and cost you 0.115p. 20 minutes + 30p versus 2.5 minutes + 0.115p. In fact you can get it cheaper and faster than that but you need a BT phone line.

To switch off images on Internet Explorer menu deselect: (tools)(internet options)(advanced)(Multimedia)(Show pictures). To display an individual image right click on the image and select (show picture).

Tip: if you use computers always reconfigure to the US + english eg is better than as it has the highest volume of traffic. If you go to that always redirects to the local google which you want to avoid. Localisation isolates.

============= 26th May 2007 =================

Mathias PARNAUDEAU is currently doing a C version of Michael Merkel's GS8GUI, he can be contacted at: mathias dot p at wanadoo dot fr, (x dot y at z represents x.y@z).

I will make some changes to the program useful for that, some technical improvements.

============= 22nd May 2007 =================

Jinxes and gremlins! I decided to download and install directly GS854 and create a pamphlet from that. Ran into many problems, so the upload wasnt quite synchronised with the setup I have here. Each problem I resolved another would manifest. Eventually the pamphlet created.

I think the problem is now resolved, so you need to download and decompress the core and binary archives again. eg I found that the core archive didnt have the amiga specific scripts. I have improved the pamphlets, books, novels and billboards features so that now all scripts are called via "execute" and not directly as running scripts directly on WinUAE tends to malfunction as it keeps losing the script s flag from files.

Anyway there are photos now near the top of the webpage of the pamphlets feature. Strictly speaking it is not a pamphlet but an A6 booklet created from A4 prints with 4 pages on each side.

If you run into any problems at all with any of the features email me as it is too time consuming for me to test out absolutely everything.

Someone emailed me about viewer speed, the viewers currently use a resolution of 126dpi, which is higher than necessary so you can speed the viewers up considerably by changing the res. to 100dpi which is the res of a high res TFT: 1280pixels/13inches==98.5dpi. That will speed the viewers up by 59%, using 72dpi will make the viewers 3x as fast.

A lot of people will have fast machines eg I use 300dpi for the viewers all the time but you need plenty of memory and speed for that. To speed up printing use lower resolutions, most printers have several resolutions the lower ones are for faster printing. There is a tradeoff between time and quality.

Each computer is different, each printer is different, each document is different, each processing of the document is different, so there are many problems that emerge. Speed can be one problem, getting a faster computer wont necessarily make any difference as the problem ultimately is the printer as that is physical with ink, printers are literally manufacturing equipment. This project has generally tried to deal with the problems I have encountered using GS.

I found I incorrectly said the pamphlets are A5 documents in fact they are A6, that is now corrected. pamphlets=A6, novels=A5, Books=A4.

============= 13th May 2007 =================

I have uploaded a further photo, this time of the landscape feature. That feature is mainly for printing documents which are done the wrong way. It is a PS level rotation of 90░ and NOT a graphic rotation. I havent implemented a graphic rotation as documents arent meant to be rotated: a document should be correct as-is. Rotation is a printer problem. If you really want to rotate a page it is better just to print the page and then rotate the A4 page with your hands, or make a paper aeroplane.

With any software project there is a danger of digression where you start implementing things which really should be done in a different project: the thing to do is to precisely define the project and avoid things outside of the definition. Good definition is essential for an effective project. I have digressed a bit with this project but I try to keep the digression under control.

The definition of this project is really to make stable versions of AFPL Ghostscript available on 68k-AmigaOS 3.x with quality viewing and printing. With the focus now on systems with gfx cards and lots of memory. Furthermore to deal with the problems encountered with downloaded documents.

eg in the above photos you will see there is about 330 + 8 MB free in a 512MB system, so the viewer is utilising about 174MB for the bitmaps. As you can see I am using an indulgent 300dpi res which is low res laser printer res. Via emulation 68k is regarded as hardware independent virtual asm which coincidentally runs on real 68k hardware! Many viewer features are only available for gfx cards. Most users will run the program emulated, the photos above are ALL above the WinUAE emulator. The photos are of a virtual classic 68020 + fpu Amiga ??00 3.? with gfx card. The advantage of this is the program is fully available to more people. I have probably printed 4000 pages of documentation using it above WinUAE and can vouch that it is faster than necessary, rendering another page every few seconds, whereas the printer takes maybe 30 seconds per page. So 68k-GS854 will whizz through a document and exit, and then the next 30 minutes is the printer catching up from the cached parallel port. For example it takes 19 seconds to render Annots.pdf for my 600dpi printer, which is about 3 seconds per page and that is with an internet intensive download program running in the background. I'll time it again later when the background program completes and I'll time it on my Sempron 2800+ tower as that is much faster than this laptop. Also the viewers achieve real time graphics on WinUAE. So I personally believe that native builds arent necessary, 10 years ago probably emulation was unacceptably slow but not today. Full page photo images will always be slow as that is some 400MB of bitmap.

later: tried it just now, the tower takes 14 seconds to generate the 6 pages of annots.pdf at 600dpi for my printer. Printing takes exactly 2 minutes, total time= 2:14, so rendering:printing==14:120 ie rendering is 14/134 = 10%, the bottleneck is the printer not the emulation. 600 pages would therefore take 1400 seconds to render = 23 minutes and 200 minutes to print = 3 hours 20 minutes.

Anyway the idea is 68k-GS854 is MEANT TO BE EMULATED and MEANT TO BE GOOD EMULATED, if it isnt there is something wrong with your emulator and you should try and get E-UAE for your system. AFAIK E-UAE is even being done for Apples (but not apricots or acorns), remember that ALL webpages arent even emulated they are INTERPRETED, and everyone thinks they are good.

All printers are ultimately portrait, so landscape documents are always a nuisance hence the landscape feature. Thumbnails are a way of overviewing a document: it allows you to directly see how a document is structured, eg the photo above of annots.pdf thumbnails gives an overview of the entire document. Novels are for handy (convenient) printouts and are my preferred way of printing documentation, the photo at the top being quite typical. Some documents the fonts are too small in "novel" format, for those I use the books format. The pamphlets feature is an even smaller version of the novels feature which fits 4 correctly numbered pages on each side of a physical page. The pamphlets feature is useful for printing very large doubtful documents. That way you get 8 pages per physical page, which means 104 pages via 13 A4 pages. Some people like very small imagery, so may well prefer the pamphlets feature: you would need a high res printer as well. Alternatively 2 x 2 thumbnails gives you sequentially numbered pages of the same size.

============= 11th May 2007 =================

830pm: I found the novels, pamphlets, books and billboards features had references to gs850. This has now been corrected. I hadnt noticed this earlier as I usually have gs850 and gs854 installed. You need to download the binary archive again if you plan to use any of these features. The gs binary is unchanged but many other things have been changed.

At the top of the webpage I have uploaded a photo of the novel feature. One further correction: the documentation said you have to copy pdf2ps.amiga to gs854data:, it is in fact already there. So I have corrected that.

Via a better camera I have uploaded a better photo of the GS854 viewer at the top of the webpage. I have also uploaded a photo of the thumbnails feature. In the photo I have made thumbnails of tiger.eps,, and annots.pdf from gs854:examples. By following the instructions I gave on this webpage I found the instructions to be not quite correct, that has now been corrected. Thumbnails were the 44th set of new features I implemented.

I use WinUAE at 800 x 600 resolution on a 1280 x 800 x86 laptop, that isnt the highest res. but I find it the best for ascii fixed width fonts, the ones I use being AmigaOS default topaz 11 which at 800 x 600 I find to be unbeatable. I use those fonts for *everything*. In the photos you can see the 800 x 600 topaz 11 fonts in use. I prefer fixed width fonts as they have alignment power that variable width fonts lack.

I suppose thumbnails isnt the most accurate description of the feature, it is more of a tiling feature, with one page per tile.

============= 12th April 2007 =================

I would like to draw your attention to the new features summary. That lists all new features since GS8, many of which never got documented elsewhere. Some new features are also described in the text window when you run the viewer.

Someone contacted me who has an ECS 68k machine with OS3 without gfx card. Some of the info on the webpage which refers to AGA machines probably applies to such a machine. I asked him to try out the AGA WB viewer as that probably is the best one for such a machine. No idea if that will function as the code was written for either AGA or cybergraphics machines.

The more recent gfx features are only for cybergraphics 68020 compatible machines.

People sometimes ask me about GUIs, the GUI of the viewers is the keyboard and the mouse! ie its a hardware GUI, eg you can move 1/2 a page in all 8 directions by pressing the keys:

7 8 9
4   6
1 2 3

That was a neat suggestion from someone in Sweden, he also suggested that 5 should recentre the image. All of which I implemented. That is features no. 39 and no. 42 on 23rd feb and 26th jun 2005 in the new features summary.

Hardware GUIs are an ancient concept and the ultimate way to control a machine, the ultimate h/w GUI is the joystick. IIRC Nintendo dont use a mouse they use a wii! PROOF that h/w GUIs are the fastest way to do things. The fastest way to quit XP is alt-f4, and to quit WinUAE also alt-f4.

If you ever try the x86 gfx card demos try pressing w as that gives you the wire frame version of the demo.

The reason my viewers dont have an on-screen GUI is because on-screen GUIs eat too much viewspace, a typical on-screen GUI eats 30% of the height. I want a BIG picture, NOT a big control panel.

Another very useful feature in the new features summary is no. 43: convert documents to landscape format. That rotates a document by 90░ at the PS level. You need that if you have an a4 printer and you download an a4 landscape document as an a4 landscape document requires an a3 printer.

============= 4th April 2007 =================

For printing schemes such as "novel" I found a trick to determine which of the 2 documents to use for printing the reverse sides. As I can never remember which of the two it is. The trick is to select say and view the first page of that with -sDEVICE=whoosh24 and compare that to the page which would have been printed. If it matches that page then is the correct one and if it doesnt match, use (depends on the printer and the mechanical config of the printer eg my printer here can be configured either way: print to floor or print upright).

And then stick a note on the printer saying which option it is as a note anywhere else will get lost.

I have put this info into each scheme's documentation.

============= 18th March 2007 =================

I've put my first attempt at a screenshot at the top of the webpage.

It looks 100 x better than that, its just this camera refuses to take a clear picture.

There is a screenshot and video of my OS DMA HD code and mouse + keyboard events being echoed on my os web page.

the camera is clear for videos, blurry for snapshots. I'll replace the above picture by one more illustrative of the program's features.

============= 14th January 2007 =================

AFPL Ghostscript 8.54 for 68k-AmigaOS released!

6am: I decided to work through the night till the port of AFPL Ghostscript 8.54 to 68k-AmigaOS was complete. This is a 68020-nofpu-O2 binary. Except for the version number, installation and usage is just like for 8.50. However there are numerous changes so dont even think about sharing any resources between the 2 installs other than fonts. To avoid delays it hasnt been thoroughly tested out. Also to avoid delays I havent implemented any further enhancements, there are some enhancements I said via email I would do, these will be delayed till later.

Except for the fonts you need to do a full new install,

you CANNOT merge gs854 with gs850, but you CAN install BOTH.

That is one of the reasons for the assigns, it allows multiple versions to be used. Leave the gs850 install in place until you are sure gs854 is running correctly.

I will generate a 68020-fpu-O2 binary later today.

I havent made any announces as it is too much stress, so please announce the release on my behalf, use these links: this announce, installation instructions, topic index,

the announce can be terse such as: "68k-AmigaOS AFPL Ghostscript 8.54 released" with just the above links given. Further info via the topic index here.

1220pm: the 68020-fpu-O2 binary is now uploaded, possibly better for real 68k machines.

Fonts can be shared between the 2 installs via:

assign gs854fonts: gs850fonts:

This is the current version of the program, I had been waiting to see if a brand new version would appear but timed-out waiting. Version number ports such as this are very stressful as any number of changes could have happened and there is no guarantee that the port will complete.

I am buying a laptop now so I can work on things at any time. I have never seen 68k AmigaOS on a laptop so that will be a new experience. (via UAE). I'm not keen on laptops but as a practical matter it seems a good idea to get one. What would be useful is if someone created a laptop tower say 3 x as high as a laptop so you could build your own system.

2007-feb-16: I have a laptop now which is really cool, it is slower but more advanced than my tower system. Also I have fully ported my OS project to the laptop. No project updates and no response to emails as I had to use a very expensive internet service.

having said that, laptop keyboards + slider mice are totally and utterly useless. Working with the laptop hardware is VERY interesting. I tried WinUAE from the laptop in an aeroplane miles above the english channel which was supercool. mobile phones are a bit passÚ when you have a laptop. Someone needs to figure a way to connect laptops to the mobile phone system, that would be better than wireless modems.

Work on the OS is now accelerating as I have got so much already implemented.

============= 12th January 2007 =================

3am: much left to do but I am ahead of envisioned schedule,

If anyone is in contact with Peer Richter please ask him to email me, I can attempt a build which will deal with the font problem he asked me about years ago. If Tony Pascoal is reading this, I'll try to deal with one of the questions you keep asking about. I'll only tell you which question if successful. While working on this port I had an idea how to do it,

1030pm: that idea looks trickier than I thought, so I have to postpone it till later. I am continuing with the main work and think I can probably complete by midnight Wednesday.

============= 11th January 2007 ==================

650pm: progress continues towards AFPL Ghostscript 8.54, there are a lot of changes since 8.50, should be a good version

============= 10th January 2007 ==================

230pm: I am making gradual progress with the port of AFPL Ghostscript 8.54. There is a long way to go yet. I have a time-window of about 10 days within which I want to complete the work.

9pm: I've completed one of the more stressful parts of the port. There is further stress ahead.

============= 9th January 2007 ==================

1130pm: well GS8.54 it is then! I'll start tomorrow.

============= 8th January 2007 ==================

I still havent received the info I requested. If I dont hear anything by the end of tomorrow I will probably start work on 8.54 first thing on Wednesday (health permitting).

============= 7th January 2007 ==================

I've just returned from my holiday. As mentioned in the previous info update I am evaluating which version of GS to do next. I am awaiting some info by email to base the decision on. That info may need further clarification which could delay things by some further days. As soon as I have the info I need I will make the decision. If I dont get any further info beyond what I know just now then I will work on GS8.54. I hope I can make a decision by approximately next Sunday. I have various real world commitments ahead which will get in the way of programming but I will start on the work and then continue as and when time allows. I may be forced to buy a laptop to get more done sooner. If an interesting version of GS is imminent then I would wait for that.

============= 2nd December 2006 ================

I wont be doing any computing from next week till January 2007. If you email me there will be no reply until Jan 2007. In January I will evaluate which version of GS to do a new port for. If a new version of GS is imminent at that time I will wait for that via a timeout otherwise I will work on the most recent stable version which will be at least 8.54.

I say that just in case the next version was to be in say mid February, then it would be better to wait till then: I will make a timelined decision in January. If it is less certain than that I would ask people to email me whether I should wait or not. If the next version wasnt a super stable one I would immediately begin work on 8.54 in January. WHERE do I draw the line? Answer: I dont know but I know WHEN I will draw the line which will be in January!

If someone gave you 10000 what would you spend it on? You can only decide that at the time you get the 10000. First get the money THEN decide. If you will get the money in January, decide in January AFTER the money has cleared in your bank account.

============= 22nd November 2006 ===================

The C pre-processor mentioned below is complete. It needs a lot of testing but all the basics seem fine. It makes use of the early phases of the compiler project. It contains various enhancements versus standard C pre processing which I will document later on. My aim was to attempt completing this by the end of this month, so I am 8 days ahead of schedule.

============= 31st October 2006 ===================

Info on aliases and shell scripts for simplified usage of GS has been moved to here. Moving to earlier pages can only be done from outside GS because of the way Ghostscript has been designed so you need to use Michael Merkel's GUI interface for that.

Anyone who wants to try out my C pre-processor email me and I'll send a binary after #define is implemented. The C pre-processor part of my C compiler project is universal so can be used for any OS. The binary I will send is 68k-AmigaOS hosted. Today I will be working on macro expansion. Languages such as Modula dont use a pre-processor and are generally much cleaner than C. C was invented in the 1970s to make Unix portable. C is the heart of Unix. The Amiga was designed around C eg the classic Amiga's hardware registers form a C struct called struct Custom defined in hardware/custom.h.

9th November 915pm: #define is now implemented. I havent tried it out yet. I've done enough for today so I will probably try it out tomorrow.

1015pm: suddenly realised I forgot to implement ## expansion. I'll start on that tomorrow. At the moment the ## will remain unexpanded.

10th November 4pm: #define is now ready to be compiled and tried out. 630pm: various bugs which I am working on.

My C compiler will probably be free but wont be made available early except maybe in demo form.

============= 23rd September 2006 ===================

I have completed 2 major subprojects of my x86 OS project, a central low level kernel component and the second phase of the compiler project. Those are probably the 2 most difficult subprojects of the entire project. The kernel component was done entirely in x86 asm which was particularly severe. The compiler project is done entirely in C. I now have enough stuff implemented to do really interesting things.

AFPL Ghostscript centrally is at version 8.54. So version drift is just at 4 (8.54-8.50==0.04). For 2006 I mainly have October and November for my projects and I need to allocate at least 2 weeks for a GS attempt. I also need to take a holiday in what remains of the summer.

What I have decided is to begin on a new GS port by the end of January 2007 at the latest. As 8.54 has been around some time that probably means they are working towards a major version. So it is worth waiting, I want to avoid blowing time on minor versions. October and November tend to pass by very quickly, December and early January are too cold to do anything useful, so before you know it, it will be mid January 2007.

============ 9th August - 6th September 2006 ================

By some error the 68020-nofpu and 68060-fpu builds of 6th August were both 68020-fpu builds. Correct builds were done on 9th August. If you arent sure, c:version will tell you what each build is. As I have macros which automatically generate the version string correctly.

I think its only worth doing a 68020-nofpu and a 68020-fpu build. The 68020-nofpu build is the only build guaranteed to run on all systems. 68020-fpu builds are known to be problematic on PPC, they are fine on 68k systems and WinUAE.

Sometimes people ask me about speed, on WinUAE on an AMD Sempron 2800+ GS850 takes a few seconds per page both for viewing and for my 600dpi laser printer. With the printer the bottleneck is the printer, GS850 generates the binaries very quickly but then XP's buffered parallel port takes ages to actually print the pages. You can print via GS850 and Turboprint on WinUAE.

IMO GS850 generates pages faster than they can be read or printed. So it doesnt need further speed.

To get best performance from GS850 you need to process pages in batches eg:

gs850:bin/gs -sDEVICE=some_device -dFirstPage=1 -dLastPage=100 -dBATCH -dNOPAUSE xyz.pdf

If you process pages 1 at a time the performance isnt so good as GS850 has to do a full initialisation per page.

The -dFirstPage= and -dLastPage= options are only available for pdf's. To do this for PS files you need to convert the PS files to pdf first via gs850:lib/ps2pdf.full.amiga or via gs850:lib/ps2pdf.amiga Both these scripts contain usage info within the script comments. I converted these 2 scripts to AmigaOS scripts from the Unix versions.

These 2 args are not necessary if you want to process the entire document for either PS or PDF.

============ 6th August 2006 ================

I've done 3 new builds of 68k-GS850. These contain a few small changes,

I've redone the 68020-no-fpu build as well as 68020-fpu and 68060-fpu builds. If you use Morphos then ONLY USE the 68020-no-fpu build as fpu builds cause problems on Morphos.

I did the fpu builds as someone with a 68060-PPC machine requested this,

The new viewers at very high resolutions can malfunction, if this happens its quite harmless but you should do a hard reboot ie reboot by switching the power off and then on again and use a lower resolution next time. Such malfunction seems to be caused by an OS3.9 bug where huge memory allocations which fail dont return error.

My current plan is still to port GS9 when that is released.

It is possible that apart from the version info that 68060 and 68020 builds are identical. I will try and determine this.

============ 1st August 2006 ================

Someone has pointed out to me that the command line I gave for converting PS and PDF to jpegs creates low res jpegs at 72dpi. So I've modified the info, you need to give eg -r150 as a further arg to get better jpegs. :I've put this info in the documentation here.

I've been also asked to create an fpu build. So I will generate a 68020-fpu build. There is one obscure enhancement I also need to make to the recent improvements.

I will probably also do a 68060-fpu build as well, feedback in the past says 68060 builds have no advantage over 68020 builds. I'll do one so you can verify this.

I need to make the obscure enhancement first before doing the alternative builds, in total it will take some time, so I'll try and complete this by next Monday.

============ 19th June 2006 ================

I am taking a break now from the GS850 work. Make sure to read the updates from the 14th of June to the 18th, as a lot of new material is there. One of the reasons I made so much progress was my mind was fresh and I found the topics very interesting. If you look at a software topic for too long you stop making progress: I am reaching that point now so need to take a break.

Once I feel sufficiently rested I will do some further tidying up. There are some further features that I may implement: I have some ideas I want to try out where I am not sure what the effect will be. Also I need to create documentation for the new features on this webpage: for the moment the documentation is the updates 14th to 18th.

comment: if you want a photographically accurate view of a document page, and have plenty of memory you can run GS850 -sDEVICE=whoosh24 with -r400, eg:

gs850:bin/gs -sDEVICE=whoosh24 -dBATCH -dNOPAUSE -dFirstPage=20 -r400 xyz.pdf

then on each page press h twice. Although there is a bit of blurring this looks like a photograph of a lazer printed page. Remember that a lazer print of the same page has at least 36 x as many pixels. Blurring is the only way to achieve the same look with 1/36 of the info. You can then also zoom in up to 400dpi without loss of visual info. If you dont have enough memory then experiment to find the highest res which succeeds. On WinUAE on the Sempron machine here 400dpi on a typical document takes 7 seconds to render the first page and then 3 seconds per subsequent page which seems quite acceptable. The full image being 3400 x 4400 pixels.

============ 18th June 2006 ================

1pm: Redownload yesterdays binary as an improved binary is now available. Reread yesterdays info as I added some useful further info there today: eg on how to deblur photos in pdf and ps files, the s function on its own isnt enough.

The new binary no longer has a limit of 16 million pixels for the fast zoom out. If the image is too big you get a warning and may get some artefacts when the image is 5 x 5 pixels or less.

The fast zoom out algorithm is only available for images up to 18916 x 18916 pixels.

Pop up windows no longer vanish automatically, press return when you've read the info.

============ 17th June 2006 ================

Further enhancements of 68k-AFPL-Ghostscript-8.50 for download!

Download the new binary of 68020 no-fpu AFPL Ghostscript 8.50. (updated 1pm 18th June 2006)

Further enhancements to the download of 14th June 2006:

(a list of the key commands appears at the start of the first page when viewing, and also if you press eg space at any time)

With all the new viewer features you can press 'p' to make the change permanent, and as before 'u' to undo.

A new viewer feature to make text more delicate: press m, I had to invent some jargon for this which I call "maximum-alias". It is a customisation of the existing anti-aliasing but with the difference that averaged pixels are removed. This avoids blurring.

Press w for the opposite of m which is "minimum-alias", as both start with 'm' the w is an upside down m. w makes fonts more coarse, you can use it instead of m if you have bright text on a dark background. w makes bright text delicate and dark text coarse, it is the dual of m.

Press b for blurring. What this actually does is replace each pixel by the average of the 9 surrounding pixels, ie the 3 x 3 square with our pixel in the middle. People wonder whether averaging is a way to anti alias, I didnt know whether it was until I implemented this. The answer is it isnt any good as it is too blurry. Ironically the useful thing that blurring does is allow deblurring of photos in ps and pdf files: see later, you need to use b to blur a few times till the pixels "disappear" and then to deblur perhaps twice via the s function described next.

As an experiment press s for sharpen. This is sort of the opposite of blurring. It is just an experiment and is just a na´ve deblurring. Proper deblurring I think requires a lot of theory.

You can see the effect of deblurring by first pressing eg b p b p b p to blur 3x and now press s to deblur. You will see the image becomes sharper. However if you recurse the results arent too good.

The averaged zoom out of the 14th is now much faster especially as the image becomes smaller. This was achieved by a lot of tricks. It is very memory hungry and eg here it allows me to zoom out on a 400dpi image reasonably quickly on a 512MB WinUAE system.

Feature (A) mentioned yesterday is the blurring feature. The speed ups of the zoom out are actually much better than the idea (B) mentioned on the 14th.

I remembered this time to remove the GNU debug info from the binary, which makes the size more acceptable.

The new viewer features only become visible on zoom-out if you press p. So eg to try out blurring when zoomed out you press: b p.

If you keep recursing maximum-alias many times you can get extraterrestrial text! (m p m p m p m p m p ...., and zoom in close, it does depend though on the input page).

Try out the sharpen feature on the pictures on the later pages of gs850:examples/annots.pdf.

If you want to deblur a photo in a pdf you have to use a trick. If you try s directly the effect isnt too good. However ironically if you first increase the blurring a few times via b p b p .. and now deblur a few times eg s p s p you get excellent deblurring with the new image better than the original blurred pixelly picture. I tried this out on a newspaper cover pdf I downloaded. What it is, is that the s function is ideal for something created via the blurring function applied a few times. I have put this info in the index.

The fast zoom out only functions for images with less than 16 million pixels. So if your image is bigger than this the zoom out will be slow: try a slightly lower res. This limit is plenty for current monitors (4000 x 4000), eg I viewed a newspaper page at 400dpi which was too slow but at 250dpi it was fast. If you visit websites of newspapers they sometimes make pdf's of past editions available or pdf's of cover pages. A4 at 400dpi is fine (15.47 million pixels), but a newspaper at 400dpi is too big, 250dpi fine.

The slow zoom out initially is actually fast because of optimisations, but it becomes too slow as you zoom out too much. The new algorithm OTOH accelerates as you zoom out. For the next build I will put an error message if the image was too big. The really neat thing about the enhanced zoom out is that even when the image is the size of a matchbox it still looks photographically authentic. And at playing card size you can read the article titles. I keep thinking it looks just like XP wares.

I think I can remove the 16 million pixel limitation by allowing artefacts when the image is just a few pixels wide. eg 64 million pixels could have artefacts when the image is 2 x 2 pixels.

============ 16th June 2006 ================

Feature (A) mentioned yesterday is now written but not checked or tested yet. I realised today a way to make zoom out much faster. I will see if I can implement this for the next upload, depends how tricky the coding becomes.

4am: I've implemented (A). I'll explain what it is when the upload is ready. I didnt know what (A) would actually look like, now that it is implemented I know what the effect is.

============ 15th June 2006 ================

I am currently implementing the feature (A) mentioned yesterday. There are a number of other image transformation features I want to implement and then I'll make an upload.

============ 14th June 2006 ================

Improved version of 68k-AFPL-Ghostscript-8.50 released!

Download a new version of 68020 no-fpu AFPL Ghostscript 8.50. This is sort of a BETA. It contains many enhancements to the viewers (only available for machines with gfx cards and lots of memory):

Zoom-out now uses colour-averaging, as you zoom out ALL input pixels are used to compute the output pixels via averages. This means the visual information is always fully correct. This makes a big difference to the image quality. It leads to smoother zoom out images. The original algorithm is still there for comparison by setting env variable whooshbms to 1. To test this out try viewing at 100dpi or lower as that increases the frames per second.

Optional anti-aliasing is now available for the initial magnification or higher (zoom-in). If you zoom-out there is no anti-aliasing. ie if you press r then that is the original magnification. That and higher magnifications are "zoom in" and have anti-aliasing available, lower magnifications are "zoom out" and dont use anti-aliasing as those are more pictorial than textual, the colour-averaging being instead a form of anti-aliasing.

The zoom-out colour-averaging is a more satisfactory work as anti-aliasing is one of those impossible subjective problems.

To try the anti-aliasing just press a for a.nti-alias at the original or higher magnifications. Press u for u.ndo to revert the image to the original un-anti-aliased image. Anti-aliasing is optional because it is debatable whether anti-aliasing is a good idea: un-anti-aliased text has maximum contrast.

The anti-aliasing only happens on the underlying image so if you zoom in and alternately press a and u you can see what happens to the pixels.

As everyone now has plenty of memory I have increased the default resolution of the viewers to 126dpi. If you use a classic machine then change this to a lower setting eg 84, via -r84 on the command line. Previously the default setting was 84 which allows a full page to be rendered with just 2mb chipram. Unfortunately that can lead to badly rendered e characters.

The frames per second of zoom out depends on the resolution. If you want it to be more impressive eg for non text pages then decrease the res to eg 100dpi. Or set whooshw to 1.

These new features are ONLY available for the whoosh24 viewer and ONLY for cybergraphics machines. You also need plenty of memory: for an a4 page at Z dpi you need 300 x Z x Z bytes. So eg at 100dpi you need a 3MB buffer. 200dpi would require a 12MB buffer, 300dpi a 27MB buffer etc. Note also that 200dpi will be 4 x as slow as 100dpi, 300dpi 9 x as slow as 100dpi etc.

If you want to try colour-averaging anti-aliasing then render at double res and then press h in the viewer: this idea is easier to do from the outside. (no need to press a as that isnt for zoom-out).

I have enhanced the text output of the program a bit so it now outputs some things to a new window instead of to the shell. So eg in the viewer if you press v a window pops up telling you the current resolution and physical pagenumber etc.

As said above this is a beta, so there could be problems. The zoom out is "science" the anti-aliasing is "art".

130pm: I forgot to remove the GNU debug things from the binary. This is now done, so if you downloaded before 130pm re-download again.

----%%%%%%%%% info from here onwards not uploaded yet %%%%%%%%%%%---------

430pm: I am implementing some further viewer document enhancers. The problem that happens with GS850's fonts is they are automatically generated, that leads to unforeseeable glitches. My anti-alias scheme attempts reverting this via aesthetic principles. Now AmigaOS's topaz fonts are hand generated so though not anti-aliased they look fine.

I am looking now at a scheme to enhance the fonts without anti-aliasing, the idea is to refine the fonts without blurring.

One other thing if the dot of an i is 1 pixel the current upload averages that, I will change that in order to preserve contrast.

6pm: I have created a variant of the anti-aliasing scheme which makes text more delicate without blurring. It is a modified version of the existing anti-aliasing algorithm. As there is a duality between background colour and foreground colour I have a converse scheme which makes fonts less delicate. The duality is that if you make the foreground colour more delicate you make the background colour more coarse. So eg black text on white background requires the other function from white text on black background.

Although not intended for images I tried both schemes on tiger.eps and the results are very interesting if you recurse a few times: each colour region starts to change shape. (I press eg m p m p m p m p ... )

You can now make the output images permanent by pressing p (p.ermanent), this means you can eg recursively anti-alias to see what happens.

I have also prevented 1 pixel dots of i's getting antialiased away. An i without a dot is an iota.

There is one other image transformation feature I want to implement, I want to implement that before making an upload. Its a feature which will be really interesting to recurse. (A)

I'll be watching the Germany vs Poland world cup match tonight so wont be coding then! (it looks like the top teams dont make a full effort until later in the tournament)

850pm: its half time during the match, 0-0 so far. While watching I realised a really obscure improvement to the main viewer, I'll say what it is if I manage to implement it. (B) Just before the match I tried out the code for making text delicate and located a very subtle glitch in the main algorithm so after the match I will correct that: it was a break in the lower part of a right ) symbol: not a true break but a break by averaged pixels. I want the line of input pixels to be unbroken as a design constraint. later: I see this glitch isnt in the current upload but occured since then, the original code was correct on this. (C)

I think antialiasing in general is a very deep problem. Here I am not looking at the general problem but mainly the problem of text rendered by GS850.

1230am: a careful study of (B) shows the idea isnt feasible to implement. The idea I had was sound its just that the info I need is too intractable to obtain. AFA (C) goes I found a different improvement which does affect the current upload. I havent begun on (A) and I've run out of time. I'll begin on (A) tomorrow.

Recursing the code to make text delicate creates extraterrestrial imagery on some document pages!

============ 13th June 2006 ================

I'm not completely convinced by the concept of antialiased text. The problem is it creates blurring which causes eyestrain as you keep trying to focus your eyes, eg if you look away from the monitor at reality everything is infinite res and sharp. Un-antialiased text is fine, stop complaining.

You are supposed to be thinking about the information presented not the rendering there-of. The best computer fonts I know of are the AmigaOS topaz fonts. Unantialiased imagery is part of the fun of the computer experience.

Remember to view at 100dpi as that is computer monitor res. Best thing is to view the image, then zoom-in via the up-arrow till the magnification is just right, then press v, look on the shell for the current x and y res and round that to the nearest integer. eg here on a document it says xres == 149.990624 so that means I should view that document at 150dpi, so I need to run GS850 with -r150. Usually xres==yres, but you can set them to be different at the cost of aspect. The whooshw env variable makes the viewer view so the page exactly fits the width of the monitor.

Having said that I will implement one or another anti-aliasing scheme, each way I've looked at has disadvantages. If you want a visually perfect image you should print the page. The real problem is that monitor resolution is too low: the only way to get authentic imagery is via blurring.

Schemes which look impressive close up make almost no difference at normal magnification.

One scheme I tried made the image so blurry that you will go mad if you look at it for too long. I think that is one thing I dont like about XP, the image is too blurry. If you use XP backdrops on WinUAE via Prefs they look much better on WinUAE due to lack of antialiasing.

Much more successful as an idea is the averaged zoom in, eg if you zoom out from an un-antialiased page it always looks correct.

6pm: I think I have an antialiasing scheme now which is reasonable.

Although this antialiasing is only intended for text I tried viewing tiger.eps just now and it does that correctly. It creates in between colours.

midnight: I've made several improvements to the anti aliasing. I think it is now sufficiently good to make available. I've run out of time just now but I'll try and get the new work uploaded by Thursday. I need to test the antialiasing on further documents and recheck the code.

It looks more impressive if you zoom in on the pixels. I've implemented an undo facility so you can switch between the original pixels and the new pixels.

============ 12th June 2006 ================

7pm: I am coding now a first attempt at antialiasing.

Last thing last night I did a full build of 68020-no-fpu O2 optimised GS850 as it currently stands.

The averaging-zoom-out is now acceptably fast, possibly 2x as slow as the original zoom. With this there is now no pixel-dancing as you zoom-out. The image also has the look of images on Windows XP, so XP must be using such techniques for some things at least (not everything).

This new zoom-out now uses a more efficient rendering pathway, this allows it to catch up vs the original system.

It should be particularly good for photos. If you zoom out now on the tiger the tiger's whiskers dont fragment.

Now when you zoom out to the point where the entire image is 1 pixel that 1 pixel is the average colour of the entire input image. So if the input image is say 70MB it is an average of that. The averaging is total which means the full info is always there. I could speed things up by skipping pixels but as I can do a total average reasonably fast I wont. If you skip pixels that could lead to visually incorrect imagery.

You see that the full info is there as you zoom out: the image is always visually correct. And it looks like a printout from a printer except a bit blurry in places.

Anyway I'm continuing now with the anti-aliasing coding,

830pm: The coding is progressing well, dont know if I can complete this tonight.

145am: The first version of anti-aliasing is now functioning. It needs further improvement. I think I have to do a lot of further experimenting. Anyway it is functioning correctly. I need to improve the heuristics. Have been trying it out on some x86 documentation.

The anti-aliasing happens fairly fast. The zoom-in doesnt do any further processing, this means I can zoom in first then press a on the keyboard and see pixel by pixel what has happened. Doing this I see it isnt quite right: subjectively speaking.

============ 11th June 2006 ================

4pm: I am reactivating the GS850 project this afternoon, 4 days ahead of the promised timeline. First thing is to backup everything just in case things go wrong. I then have to survey the state of the project as there is several weeks of work beyond the current binary on this webpage.

A subset of the new work is good but most of it needs to be undone. An interesting thing I did achieve was a legacy problem Peer Richter found where incorrectly defined fonts were being filled in but no problem on GS510. The problem was with the fonts not with GS, entirely by chance I found a way to make GS850 revert to the GS510 behaviour on this. That requires a different build of GS850.

The GS850 work will be done in parallel to my other projects. To prevent any project eating all my time I now always work on more than one project: management of time-risk.

Once the project is coherent again I will begin working on the anti-aliasing. I have an initial algorithm now designed to try out. The anti-aliasing is the interesting part of the new work but other organisational gruntwork needs to be done first.

645pm: well I'm progressing now on the work. I've decided I'll make various other improvements as well. As I wrote my own bitmap rescaling I am looking at enhancing that for reductions by replacing the current na´ve rescaling by averaged rescaling. That will be slower but should produce better colours.

Note that averaged rescaling wasnt feasible for classic AmigaOS as that used a palette scheme.

Looks like I can do averaging in the x-direction without major changes, I will see if I can do averaging in both directions which will be better. But only if it doesnt require total rewriting of the code.

BTW that will produce na´ve antialiasing by zoom out. Anyway this change will produce averaged-colour zoom-out. For my anti-aliasing code I want something more sophisticated than just averaging as averaging will just blur the image.

It will definitely be quite a bit slower as the entire page needs to be sampled, I need to find how much slower. Na´ve rescaling only has to sample relevant pixels which makes it very fast. Do you want speed or do you want colour quality?

All the new features will just be for the truecolour viewers, I could do them for the greyscale viewers but I think on modern machines you should just use the truecolour viewers.

9pm: Well I have implemented + debugged the averaging zoom-out, and it takes a 2D average which is the best approach. It is absolutely fantastic. I have run the original viewer side by side with the new viewer, viewing tiger.eps and the new viewer always looks completely correct as you zoom out, it looks like a photo at all times.

The only catch is that it is a lot slower, perhaps 2 or 3 frames per second. I think I can definitely speed it up considerably but I have to study the code carefully.

I think my planned anti aliasing should help with tiger.eps as well for when you zoom in.

I have tried viewing some x86 documentation at 200dpi then pressing h (zoom out by 2x) to get averaged antialiasing of 100dpi. This looks just like a laser printed page, the only problem is it is a bit blurry in many places. The problem with averaging anti aliasing is it blurs thin lines. It also blurs edges. My planned antialiasing will avoid the blurring problem by maintaining sharp contrasts.

1045pm: I am working on making the averaging zoom out faster. I think I have found a way to do it which doesnt require major changes. Not sure I can complete this tonight, I'll see how far I can get.

145am: I have now a fast version of averaging zoom out. At least it is fast on this Sempron machine. I tried an 800dpi page to then press h 3 x for 8 x zoom out: For this the averaging zoom out was slow as 800dpi is almost 200MB of bitmap. (greyscale could be better for very high res as it reduces the memory footprint by 3x ) Also the 800dpi averaged down to 100dpi isnt really any better than 400dpi averaged down.

I am almost ready to implement my first anti-aliasing algorithm that will produce much clearer imagery. The build I am looking at is an unoptimised 68020-fpu build. For general downloads 68020-nofpu builds are better as the fpu builds dont run on Morphos.

============ 8th June 2006 ================

I will soon reactivate the project, by 15th June at the latest as said in the previous update.

I will attempt implementing antialiasing for the viewers in response to Tony Pascoal's requests.

It looks like quite an interesting problem, interesting in a visual way, however before I can begin on it I have to do a lot of tidying up of the project.

Anti aliasing should greatly enhance the viewers (I hope).

I will also attempt to port GS9 as and when they release it. Versions near GS9 on either side wont be as interesting as GS9. Centrally they are at GS8.54, its a good sign that the numbers are changing slowly as that means the product is very mature.

Right now I am working on a lot of x86 hardware problems as well as software projects. All the development done on WinUAE. I think I have printed more than 5000 pages of x86 documentation with my GS850 port eg yesterday I printed yet another document on x86 hardware, 20 pages of interesting hardware info.

============ 27th May 2006 ================

I am making a study now of creating antialiasing for the whoosh24 and possibly whoosh8 viewers, this is in response to requests by Tony Pascoal.

There are 2 general ways to do antialiasing, the better way is to integrate antialiasing into eg the font definition. Unfortunately that is way beyond the scope of this project. For my OS project I will try and do integrated antialiasing for the OS fonts but for the GS project it is beyond the scope of the project. Something which is fine for one project is not fine for another project, its a problem of decision sequencing. The problem here is that font antialiasing is a specification or definition problem and not an implementation problem.

So instead the antialiasing will be done in a workaround way. Workaround antialiasing is a complicated and ill defined problem. eg someone might create a document explaining antialiasing and give examples of images that need antialiasing: you DONT want the rendering to anti-alias the examples as they are meant to be bad!

That is similar to the problem of giving examples of spelling mistakes, you DONT want a spell checker to correct that!

Anyway I have an initial antialiasing scheme designed to try out.

Note also that integrated font anti aliasing would be much much faster than workaround anti aliasing.

I will reactivate the GS850 coding temporarily by 15th June 2006, first I will need to do some tidying up. And I cannot restart the coding immediately as it is just 1 thread in the tapestry of my life. When the coding has been restarted and the tidying done and other changes done, then I will code and try out the initial scheme, anti-aliasing is to some extent subjective and in fact is only necessary because monitors have such low resolution. If they can increase the resolution of monitors by 6x then anti-aliasing will be obsolete.

Anti aliasing is just a legacy artefact, unfortunately monitors havent evolved their way out of the legacy swamp. Note that if monitor resolution is increased 6x then graphics will become 36x slower.

The anti-aliasing I am designing is geared to fonts and curve based 2 colour graphics: that is exactly the type of pages you find in typical documents eg x86 documentation. Where you have b/w pages with text and curve based diagrams. General purpose antialiasing wont help at all as it will just blur very low res text.

Studying the problem and designing a scheme I can do now, but the coding cannot be begun yet.

============ 23rd April 2006 ==============

The 68k-GS850 project will continue indefinitely. I'm just very very busy with the OS project. But when the time is right I'll reactivate the GS work. I will always have and use 68k-AmigaOS and 68k-GS.

The 68k-GS project is at a very mature point so I can keep the pan boiling at low heat. I have some GS things I want to implement for my own use, and when I reactivate the project I will work on those.

The only way to work on many projects is to be very efficient with time, once a project has matured you have to then reduce the time invested.

I dont just work on projects to while away time but I code for a purpose. Once the purpose is attained the point of focus needs to move to a new project. For me personally 68k-GS has attained its purpose of allowing me to do customised prints and viewing of PS and PDF files. The "novel" and "landscape" and other such schemes were things I'd wanted right from the start but it took a long time before I could see how to implement them.

I use the "novel" scheme all the time, it saves me a lot of ink and paper and IMO is the best way to present documentation. What I usually do is print each chapter of a PDF as a "novel" booklet. I staple the booklet with a long arm stapler. I use the whoosh24 scheme to plan the printout, usually the first thing is to determine the last page of the contents and print the contents out as a booklet. I then note on the contents booklet which chapters I've printed out and what the physical pages are.

============ 8th April 2006 ==============

Click for further info on my OS project. See the day before yesterday and yesterday.

============ 7th April 2006 ==============

Further info regarding my operating system project I mentioned yesterday.

I will probably also move things concerning the project to another web page.

With something like AmigaOS there are 2 ways forwards, you can either (a) try and develop the system further or (b) you can create a completely new system which coexists with the original system. The problem with the former approach which I think OS4 are taking is that there are limiting constraints from 1986 when the original designers thought that the 68000 series would go on to infinity. x86 is Aesop's tortoise and 68k is the hare. You have to then try and workaround the legacy design constraints. This you can do but it can complicate everything for everyone.

OS4 and Morphos have gone for 68k binary compatibility eg they can run my 68k-gs850 port from their system shell or workbench. They can do that as they have integrated 68k-emulators. UAE is fundamentally unintegrated so it will run 68k-gs850 eg thats what I do but only from its standalone space. UAE only emulates the hardware, the OS is by the Amiga company. UAE is not an OS it is virtual hardware implementing the hardware reference manual and the Motorola 68k manuals. It doesnt reference or implement the RKMs. It has some integration eg the filesystems are integrated with XP. UAE is a hardware layer.

Integrated emulators are different from unintegrated ones because integrated emulators are above the OS and act through the OS whereas unintegrated emulators are below the OS. Integrated emulators dont use a ROM, they use the actual OS. The advantage of unintegrated emulators is they can run above any OS, the disadvantage is they are unintegrated.

AROS took an interesting path in they implemented a hosted AmigaOS above x86-Linux. 68k programs need to be rebuilt and then will run x86 native. eg I rebuilt my 68k-gs850 port and it does run correctly, they dont have Turboprint but you can eg use the whoosh24 68k-gs850 viewer.

AmigaOS could take the hosted native path, you then get x86-native AmigaOS but hosted above another OS such as Linux or XP. That's a good medium term strategy, you get people on all hosts to use your system and you only go for source-compatibility. The same x86 binaries will run on all x86 hosts, and the same PPC binaries will run on all PPC hosts. So you get partial binary compatibility: cpu level binary compatibility. Classic 68k programs wont run, but that creates a market for you to write your own versions of those programs. If it rains a lot instead of complaining make money by selling umbrellas.

If they use the same h/w conventions as AROS then the same binaries will run on both systems. eg my x86-native-AROS-gs850 port on this page would then run on x86-native-AmigaOS.

The PC universe is different from the Amiga universe in that they have gone for clone-compatibility. And it has paid off handsomely. Everyone is successful.

AmigaOS has run away from the clones whereas x86 have run with the clones, eg you can run ATi Radeon's Chimp and butterfly demo on an Nvidia gfx card on an AMD or run it on an ATi card on an Intel, it looks better on the ATi.

It was a major turning point in x86-history when Bill Gates decided to run with the clones and IBM ran away and joined forces with Motorola and Apple. Microsoft overtook IBM as a company. IBM were running in the wrong direction along the track: clockwise, easy to overtake! History has many lessons.

Running with the clones means the best developers win, whereas running away means you have to rely on loyalty, and most computer users have limited loyalty. If you cant beat them join them. AROS can hardly sue AmigaOS for using their h/w conventions, they will probably be flattered.

Now I am creating a brand new system without any reference to any other OS. x86-native AmigaOS could definitely be run above my system and I am designing the architecture so that emulators and hosted OS's will run as fast as they would hitting the h/w directly. Hosted OS's do hit the CPU directly, and you can code in x86-asm "mov eax,ebx", "push ecx", and gfx can hit the h/w directly: gfx h/w is just ram (a lot of the time).

Its just an external HAL vs an internal HAL. Same difference.

You wont in general be able to hit the MMU directly as that brings in security problems, but target user progs should also not hit the MMU directly as that brings in target OS security problems, so you just redirect user MMU ops twice instead of once.

host-hw------host-os---target-os---target-user-prog :indirect

host-cpu---------------------------target-user-prog :direct cpu

host-gfx-hw------------target-os---target-user-prog :direct os-gfx

host-gfx-hw------------------------target-user-prog :direct user-gfx

host-gfx-hw--host-os---target-os---target-user-prog :indirect gfx

:hosted OS's are native in many respects, its only hosted emulators which arent native, all emulators arent native. Actually modern x86 CPUs are emulated as x86 is emulated by a RISC core. I think a lot of people think hosted OS's are slow, they arent.

AFAIK AROS began hosted only and then later they achieved native.

Its not that AmigaOS could be hosted, its already been done by AROS. AmigaOS has some catching up to do with AROS. As I said: run with the clones.

I've already coded and run and debugged many boot experiments in x86 asm. I boot from a floppy. I have 2 PC's, I code on WinUAE, assemble on XP via FASM, and then boot the floppy from the other PC. Everything so far is in asm, however x86 assemblers are quite sophisticated, by using a lot of macros its not that much more difficult than coding in C. FASM asm has structs, and typechecking at the operand size level.

Anything you can do in C you can do in x86 asm though you dont have many registers: eax, ebx, ecx, edx, esi, edi. Things get complicated if you run out of registers. But I've developed mitigating techniques. You have to write the code differently from how you would code it in C. Its not like 68k where you have d0,d1,d2,d3,d4,d5,d6,d7,a0,a1,a2,a3,a4,a5,a6. Some things can only be done with ecx, some only with ebx, some only with eax and edx. Eg for division, the numerator is always (2^32 * edx + eax), the division goes to eax and the modulo to edx with a flag set if the answer is too big.

So to divide ecx by ebx with the answer to esi:

  push eax
  push edx
  mov edx,0
  mov eax,ecx
  div ebx
  mov esi,eax
  pop edx
  pop eax


Its not like some CPUs where its just 1 asm op. eg with RISC the equivalent would probably just be "div r2,r3,r4". With 68k to divide d2 by d3 with result to d4 its probably:

  move.l d2,d4
  divu.l d3,d4

You can do (A) via a macro:

macro  mydiv32 quotient32*,numerator32*,denominator32*
	push eax
	push edx
	mov edx,0
	mov eax,numerator32
	div denominator32
	mov quotient32,eax
	pop edx
	pop eax

and invoke it thus:

  mydiv32 esi,ecx,ebx

FASM macros are clever so you could even make the macro do the division directly if quotient32 happens to be eax.

IMO the 68030+MMU was the best CPU ever from the programmers POV. No other CPU compares for convenience. People who say PPC and 68k are better than x86 are right, the strength of x86 is they workaround the malarchitecture with a lot of force. x86 is a deeply flawed specification but the implementation is first class.

Its going to be some time before I even have a mouse pointer. The first steps are the slowest and most difficult. I have 4 system-bootstrap phases already coded and debugged. And I have debugged the initialisation code of various system components. I have run into some BIOS limitation with accessing the floppy drive so I am currently working around that via an extra phase. I've written code to probe the PCI bus which functions correctly, though I havent succeeded yet coding the h/w located by the query. I need to work on a lot of other things before I can attempt any further PCI coding.

If there are any bugs with my boot code the machine tends to reset. I've probably spent days with jmp bugs, jmp is very tricky. Boot code is generally very jumpy, the whole system will fail because of some trivial error eg some bit wasnt set or you were executing 16 bit code when you should have been executing the 32 bit version of the identical code.

My code is quite safe though as its only accessing the floppy disk, and its only reading the drive. Its when you start writing to drives that you have to be very careful and use a scratch drive.

Modern PCs are just huge Amiga 500s, thats the way I look at them.

Anyway AFA AmigaOS is concerned, I think the best way to move an OS is to host it. To create a new OS you really need to create it native otherwise you'll be influenced too much by the host architecture. What you do then is internally host the OS. Then you can move the hosted part to an external host. Lastly you can replace the external host by your own version. OS's are very large viruses.

x86-AROS really is the defining example of this methodology, they reimplemented AmigaOS above a Linux host, and then implemented their own host to get x86-native-AROS. and I think they are working on a Windows host.

Through layering you can have PPC-native binaries which will run on both Morphos and OS4. The guys at Morphos and OS4 will not approve but it can be done. that's a project.

Noone likes being cloned, but if you cannot stop a clone its better to be inter compatible. With x86 everyone wins who accepts the existence of their clones, going even further its a good idea to clone your clones. Learn from what your clones are doing, Intel does that. From the user POV, clones maintain pressure on companies preventing complacency. Apple and Amiga were very complacent as they had no opponents. Their only opponents were at a great distance from x86 and Windows. Today AROS is progressing at such a rate that AmigaOS is under pressure and the only way out is to copy AROS.

I'm not waiting, I'm constructing my own way out.

The absence of clones was bad for the Amiga because the central company could do anything they wanted and we the users could do nothing about it. AROS + Amithlon + WinUAE are basically clones pushing through a contradictory belief that x86 is the way to go. Microsoft also has no competition, but they cooperate with all hardware clones. I for one will be competing against Windows. There are so many ways to outdo Windows, a whole bookful.

============ 6th April 2006 ==============

I'm creating my own operating system now. It is an x86 native operating system. It will be super-modern and I have already completed various initial stages, enough to know that I can complete the whole project though its going to take a LOT of work.

My filesystem project will supply the filesystem for the project. My filesystem will be integrated into my OS. All other private projects I've been working on will also be integrated into the system.

The 68k GS project will continue unchanged as its unlikely that GS will build on my OS as I'm making a total departure from *nix. The AROS port of GS will also continue.

The OS is being cross developed on 68k AmigaOS on WinUAE. This is a long term project and I intend to compete against Linux and Windows. I'm implementing the ideas I've been saying for quite some time that AmigaOS should do.

x86-native AmigaOS could be implemented above my project the same way Morphos implements AmigaOS above the Quark kernel. However that is not for me to decide: I wont do a unilateral reimplementation of AmigaOS. I could but I wont, I'm not into reimplementation and emulation.

Big endian x86-AmigaOS could also be implemented above my project.

Various components of my project can be ported just like that to say 68k AmigaOS as I do that anyway to test them out.

Unlike some projects I am not hostile to AmigaOS, I think everyone who wants to become a programmer MUST familiarise themselves with classic 68k AmigaOS as it is the best example of how things should be done. There are only 2 classic operating systems: 68k-AmigaOS and Unix. Unix is clever but very painful, 68k-AmigaOS is the only sophisticated OS which is fun.

I am not copying AmigaOS in any way however I do want to achieve the same objectives that AmigaOS achieved: directness, ease of use, high programmability, (who doesnt!).

This is something that should have been done in 1995, Microsoft have had too easy a ride and Linux can never challenge Microsoft as they are caged within the framework of Unix.

The advantage of doing it today is that x86 hardware is just at the point of becoming interesting, and AMD are pushing through good architecture. Today Intel copies AMD's designs. The 68030 MMU is still better than even the latest x86 MMUs. The 68030 MMU allows pages from 256 bytes to 32K with early out at all levels. x86 MMUs only allow pages of 4K or 2MB or 4MB, and only allow early out at the second last level: that's how they achieve 2MB and 4MB pages. 4K/entry_size * 4K == 2MB or 4MB. The x86 MMU is similar to the 68030MMU but less flexible.

The 68030MMU is a dream machine. eg the 68030MMU can emulate an x86 MMU but not vice versa.

Even today AmigaOS can still compete against Windows, the thing is I cannot do their work for them. I know what needs to be done and I know how to do it. I can stand around for years wishing and hoping they make some obvious decisions or I can make those decisions myself.

From my POV its better for me just to get on and create my own system. Otherwise another 5 years will go by and it will be 2011 and there will be no observable change. In those 5 years I could implement a fully featured OS. I've already got most of a filesystem implemented within 1.5 years, so I can definitely implement an entire OS in 5 years.

The guys who created AmigaOS in the first place werent happy with Apple and Unix and they created their own system the way they thought it should be done. They created a 4096 colour pre-emptive multitasking computer when Apple was unitasking monochrome and MS was a unitasking 80 x 25 text screen with flashing cursor and Unix just had voluntary multitasking in the kernel.

============ 3rd Apr 2006 ==========

I'm making good progress with my other projects, enough so that I've restarted my FS project. Once I've made enough further progress I'll schedule time for some 68k-GS things.

At the moment I'm learning and experimenting with x86 hardware. This requires huge amounts of documentation printouts: which I do with my GS850 port. As an example there was a 230 page document on cross platform h/w info which I wasnt sure was useful. So I printed it in double sided "pamphlet" form via my pamphlet extension of GS850. So instead of 230 pages it was now just 230/8 == 29 small pages. I then cut this with a scissors, not very carefully! It was too many pages to staple, I then flicked through to locate any useful things. There were just a few pages of interest.

So instead of wasting half a ream of paper, I just wasted a twentieth. It also gives you a 4x saving of ink.

The pamphlet scheme is the best way to deal with bloated reference documents. If a chapter looks really interesting then print it full size. With obscure computer documents you'll often only be interested in say 2 chapters out of 10.

With double sided printing you have to wait for the paper to cool down. I think hot paper causes problems with the toner and you can get creases in the paper. So after printing the first side, remove the paper from the printer and leave it for 1/2 hour before doing the reverse side.

A different approach is to use the whoosh24 viewer to study the index of a document. Find eg a chapter that looks interesting. Use trial and error with whoosh24 to determine the physical pages of the document. And eg you can start reading the chapter with whoosh24 to see if it is worth printing. You then can print that eg in novel format eg:

8> gs850:bin/novel   ; to get the usage info


gs850:bin/novel pdf_document first_page last_page temp_file

8> makedir hd:temp_dir 
8> gs850:bin/novel docs:xyz.pdf 103 150 hd:temp_dir/xyz_

8> protect ram:script#? +s
8> ram:script1  ; typically takes a lot of time,
8> ram:script2
8> gs -sDEVICE=somedevice -dBATCH -dNOPAUSE -sOutputFile=par: hd:temp_dir/
8> gs -sDEVICE=somedevice -dBATCH -dNOPAUSE -sOutputFile=par: hd:temp_dir/
; some printer configs you print instead, depends on the paper transport geometry.
; you may need to reverse the second printout. You now eg staple the column into a 
; novel sized publication. 60 pagenumbers will staple without problem: 15 A4 pages.
; I bought a long arm stapler from the shop Staples, it is by Rexel and has a 10 inch reach.
; if you printout a 1000 pagenumbers (250 x A4) it will be impossible to staple.
; so you need to plan.

For documents I like I often use novel format unless the font is too small.

If you want to do this for a PS document, you need to convert it to PDF first via gs850:lib/ps2pdf.amiga or gs850:lib/ps2pdf.full.amiga which call gs850. Read these 2 conversion scripts for usage info in the comments.

The novel and pamphlet schemes will save you a lot of money in paper and ink as well as save a lot of storage space.

If you want to put a huge amount of info on 1 page use the thumbnails scheme, probably more useful for pictures.

You can also combine schemes eg convert to thumbnails, convert thumbnails to pdf, and then convert pdf to novel: put 512 pages onto 2 x A4 with 8x8 thumbnails, you'll need a very high res printer and a microscope!

You can merge PS documents via c:join, I think do this with documents which have the same pagesizes. Then you can convert these to pdf, then eg convert to thumbnails.

============ Wed 8th Mar 2006 ==========

I've been asked about what I'll do next with this project. The only thing I can promise is that when GS9 is centrally released I will try and start on a 68k AmigaOS port within 3 months of hearing that. I say 3 months because maybe I will be on holiday or in the middle of something else. I will of course try and start a lot sooner perhaps 2-3 weeks, but I cannot promise that.

Centrally AFPL GS is now at GS853, that was released in November 2005 so I think I shouldnt target it as they will probably soon release maybe GS854. If it was a major release then I would.

Going by the past I think probably they will release GS854, then GS855 and then GS9. Major versions such as GS8, GS850, GS9 are the best as they tend to be super stable. GS853 contains new features but some of the new features are beta. With major releases AFPL try and stabilise everything. Stability is much more important than currency eg GS8 is better than GS813.

To be quite frank I think GS850 does everything one can want. I have printed 1000s of pages of downloaded pdf documentation with it. If you keep enhancing a program you eventually reach the point of absurdity. IMHO GS, WinUAE, gcc and a lot of GNU have already reached the point of absurdity: they already do more than you can ever want. Actually sometimes programs get worse if they have too many enhancements.

========== Fri 27th Jan 2006 ==========

At the moment I'm working on a whole series of programming projects. When I originally ported GS8 I was actually in the middle of a project, I needed to print out the PPC manuals and that was beyond my Star LC10 dot matrix printer. So I bought a b/w laser printer, but it wouldnt print via the Amiga, but there was a GS driver. People on told me that the way to print was via GS. That eventually led to me attempting to port GS8. My port attempt received a lot of criticism: no gfx card support and no Turboprint support. 5 months later and I had addressed all the major criticisms. Beyond that over the months I gradually dealt with all the feedback, many things are here. As you can see there are 47 improvements since the release of GS8.

GS8 led to me looking at open source in general and I worked on more open source projects than I care to remember, however none with the depth of GS. Eventually I became a bit disillusioned with open source, so I decided that beyond GS I wouldnt be involved with open source except where it is absolutely necessary eg I've dabbled with gcc eg porting AROS's Linux hosted gcc to 68k host which is somewhere on this website!

I eventually got converted to the idea of x86 AmigaOS, and use WinUAE. I took an interest in x86-native-AROS, as they seemed to have hit the nail on the head as far as strategy for AmigaOS. I've now more or less left AROS and am working instead on my own private programming projects. I've taken the cue from AROS and am trying to learn x86 programming and am progressing, gradually, as x86 is a severe system.

I've restarted in the last few weeks the project I stopped in order to port GS8 way back whenever it was. So I am working now on a multitude of projects, all my own projects and none are in the public domain. eg I've just managed to reorganise the memory subsystem of my FS project so that I can reuse it in other projects. My memory subsystem has a debug option which does total tracking of memory allowing me to rapidly locate memory bugs. All my projects are developed on 68k AmigaOS WinUAE, but done portably so I could transfer them almost anywhere.

I use 68k-GS850 to do all my printing and the "novel" etc schemes I created are very useful for dealing with huge printouts. So because I am myself a user of the program I will try and generally keep the program up to date.

============ Tue 10th Jan 2006 ==========

Wanting to print out a chapter of some documentation in "novel" format, ie 2 pages per physical page and on both sides correctly numbered I decided to follow my instructions on this webpage. I found a bug in the instructions which I've corrected, the 3rd line said "ram:temp" when it should have said "hd:temp". The error happened because I usually use ram:temp. Although printing in novel format sounds scary if you follow the instructions it is straightforward. The scariness is in creating the mechanism not in using it. At the very end you may need to reverse the order of the column of double sided prints. I probably need to improve the scheme sometime so that a final reversing isnt necessary.

At the moment all my time is learning about x86 hardware, its very interesting but takes a lot of effort to understand. I learnt that the Pentium from 1993 can do 2 instructions per clock cycle, the P6 from 1995 can do 3. As soon as I've made some further progress I'll resume work on the FS project, which currently is a 68k project though I want to get it to run on x86 as well by hitting the x86 hardware directly outside of Windoze which is why I'm learning about x86.

I'm printing lots of documents with 68k-gs850 and it is coping with the documents just fine, so I dont see any urgency in a new port. I use the whoosh24 viewers to locate which pages to print, no point printing an entire document if I only need say 3 chapters out of 12. Eventually I will do a new 68k port of GS. I will have to also port the novels + pamphlet etc schemes forward as well as those are changes to the central source, and those facilities are only available on my port of GS850.

My view is that programs should do what they're supposed to do and you get on and use them. I dont subscribe to the idea of neverending version improvements. AFPL GS centrally seems to have stabilised as really they've done everything that possibly can be done. This is a good state of affairs, the last thing you want is people pretending to be busy!

============ Friday 2nd December 2005 ==========

I havent left!

At the moment all my time is on my filesystem project. I'm just finishing off towards the next filesystem prototype. Eventually I will do a new forwards port of GS850.

============ Monday 12th September 2005 ========

in response to requests I spent maybe 2 weeks attempting a port to Morphos. Porting to Morphos looks very very difficult and has so far been unsuccessful. :I can build the binary, but all fonts do not get rendered, and turboprint doesnt function at all.

The problem is very deeply situated. So if you use Morphos please use the 68020-nofpu binary from this webpage as that functions fully correctly and does everything documented on this webpage.

In attempting to port to MOS, I found how to workaround a problem that Peer Richter told me a long time ago. Fonts from long ago dont all conform to the current specification. The workaround allows documents with such fonts to be rendered correctly: if you have a letter O, this is defined by an inner curve and an outer curve. The problem fonts have both curves going in the same direction and rely on parity to decide which points are rendered: doubly rendered points are not rendered. Correct fonts have the 2 curves going in opposite directions. So the modern specification renders the problem fonts O as a disk. The 2 schemes apparently are incompatible, GS510 rendered fonts incorrectly by parity, GS850 renders correctly. I have found how to make GS850 render "incorrectly" for compatibility with GS510 and early fonts.

:the binary with the workaround hasnt yet been uploaded yet, it needs a bit of further coding and I'll then upload it.

I will continue attempting a port to MOS, but only as a background activity as its starting to eat too much time and there's no guarantee of success.

Right now all my time is on my FS project. I'll schedule some time ASAP to complete the problem font workaround.

============ Sunday 24th July 2005 =========

Temporarily at least I have bought 70Mb of extra webspace, so all archives are now in .lha format as I now have enough webspace. Previously I had less than 1Mb free.

If anyone tries out any of the new features within the next two weeks please email me to say how it went.

============ Friday 22nd July 2005 =========

5pm: I've now improved the usage of the pamphlet scheme. Its now simpler and better. Also improved are the book and novel schemes.

With all 3 schemes you no longer need to supply page_count and offset but instead supply first-page and last-page. With the pamphlet scheme you now cut the column in half and then just place one half above/below the other half. Previously you had to alternate pages from the 2 halves which was a pain. also the new scheme creates less unused pages within the book: when you place the one half column above the other at the top there may be a fully unused half page you need to remove. The total amount of paper used is the same, but the amount used within the book is less by one half page in half the possible circumstances.

Furthermore with all 3 schemes for the reinserted print the schemes all create both the forwards version which is and the reverse page numbering version which is

As the usage has changed I've changed the names of the relevant auxiliary programs, they are now "book", "novel", "pamphlet" replacing "book1", "novel2" and "pamphlet4" this will avoid wrong usage.

The instructions for these 3 schemes have been changed accordingly.

The usage of these 3 schemes is now much easier to remember:
auxiliary_program document first_page last_page temp_file_prefix
execute ram:script1
execute ram:script2

2 bug fixes: when I first implemented them the thumbnail and pamphlet schemes both functioned. But when implementing later features I rearranged that code and it now malfunctioned.

Thumbnail and pamphlet are now functioning correctly again.

I'll retest all the other recent features in case any bugs are there too.

============ Thursday 21st July 2005 =========

In response to a request I've created one further feature: BOOKS.

This will take a pdf document say doc.pdf and output 2 ps documents, say and will contain the odd numbered pages and the even numbered pages. That way you can print the odd numbered pages, reinsert the paper and then print the even numbered ones getting a double sided printout. If there are an odd number of pages there will be one extra blank even page to prevent the numbering getting out of synch. Also you can choose whether the even numbered pages are in reverse order.

I've made a slight change to the recent pamphlets and novels features so they now output and, this is just for future compatibility.

============ Monday 18th July 2005 =========

11pm: I've had some feedback that a full install of GS850 led to crashes, I recently modified gs850core.lha to include pdf2ps.amiga and this may have decompressed incorrectly: ISTR that although I generate the archives with Geekgadgets that Geekgadgets doesnt decompress them properly, whereas I think OS3.9's Unarc does decompress properly.

I've regenerated the archive again, luckily I backed up the archive before decompressing it, if anyone runs into probs with the new install contact me ASAP so I can try and correct this.

I've done a full fresh install to ram: of the current downloads and tried out the billboard feature with the just the whoosh24 viewer enabled and everything functioned fine. So I think the downloads are all clean now.

On my system script flags all seem to be lost from the downloads, so you will need to do
protect xyz +rwds

on each script file that the shell says isnt a script file, eg gs850data:pdf2ps.amiga,

Try out all features directly from the shell before using non shell approaches as the shell will give informative error messages.

Earlier progress report: I've enhanced the BILLBOARDS feature mentioned yesterday:

The feature now only displays the precise image to be cut out,

BEWARE: GS850 devices have their own margins, so the overlap factor needs to be bigger than the margin: this means you need to use the smallest two numbers (4 and 8 in the billboards documentation). On my printer 4 and 8 are fine, the smallest allowed value is 2 where each image overlaps with half of its predecessor. If on your printer there are gaps between frames you need to reduce these 2 parameters.

So 2 will function, 3 should function and 4 probably will function:
assign c: gs854:bin gs854:lib add
billboard "-dFirstPage=3 -dLastPage=3" doc.pdf 10 script0 temp gs850:bin/view1 2 2
execute script0

:is the wasteful command using 2 everywhere that always will function. Although not mentioned in these commands all the work is done by GS854.

I've tried this out with tiger.eps and consecutive frame boundaries match with total precision. This will reduce the effort of reassembling the frames into a bigger image. In fact you only need to cut along 2 edges: the right edge and the upper edge: the remaining overlap then allows vertically and horizontally consecutive frames to be glued together.

BUGFIX: in yesterdays upload I found there was a bug with the height, I'd wrongly used the width instead of the height in one place in the code. This has been corrected.

============ Sunday 17th July 2005 =========

I've implemented one further feature in GS850: BILLBOARDS.

The idea of billboards is to create a large picture made of many pages joined together. This is how they make billboards, I've seen them do it: they have lots of paper rectangles they glue to the billboard creating the advertisement. :from a distance you dont see the joins between the rectangles.

With my implementation you specify a magnification eg 3 and horizontal and vertical overlap factors as there are gaps between consecutive images.

Please read the progress reports since the 15th for the various other recent new features implemented.

Billboards is the most difficult of the new features to use, second most difficult is pamphlets, then novels, thumbnails and landscape are the most straightforward to use.

IMO novels are the most useful of these new features.

thumbnails IMO are good for planning huge printouts. eg for the 1200 page document I mentioned, my plan is to print maybe the first 80 pages as 4 x 4 thumbnails on 5 sides of 3 a4 pages and then plan how to do the full printout via several novel printouts.

============ Saturday 16th July 2005 =========

8pm: with the novel and pamphlet schemes mentioned today and yesterday, note that script4 is quite time consuming, you can monitor progress of the mechanisms via "list hd:temp#?" where hd:temp is the temp file prefix of either scheme. Pages are generated in an erratic order. One other thought, with really huge documents eg there is a 1200 page document I want to print out a good idea is to subdivide it into "volumes" of a few chapters where each volume (group of chapters) is done as another pamphlet/novel volume. In particular with the novel scheme you can then create a series of booklets covering the whole document. A 1200 page document would be 1200/4==300 a4 pages with the novel scheme, a booklet of 30 a4 pages seems feasible so maybe that could be 10 booklets.

I've customised GS850 so it now does NOVELS.

This fits 2 document pages per physical page side, so if you doubly print the pages they reassemble into a novel.

It is similar yet different to the pamphlet scheme mentioned in yesterdays progress report.

IMO this is the most useful way to print documents: firstly there is no cutting involved, secondly the page size seems right approx the size of a novel page via A4, and thirdly it allows 4 pages per page which is economical. eg a 100 page document will take 25 A4's.

For pamphlets and novels you need to download pdf2ps.amiga and copy it to GS850Data:

For both the pamphlet and novel scheme I've changed the default to be the same as on my printer to simplify creating the upload, so now the default is to reinsert the pages in reverse order. Just copy script3_normal and script3n_normal to script3 and script3n respectively in gs850:bin if you want to reinsert in the same order.

For both schemes also make sure to wait till the paper has cooled down before reinserting otherwise the printer may lose its grip.

As an example of the NOVEL feature if you print a 9 page document this way, you get numbers:
[2 . : . 1][4 9 : . 3 ][ 6 7 : 8 5]

:putting the 9 pages onto both sides of 3 a4 pages, you then column up these pages fold in half and staple or stitch into a novel.

I've tried this out just now and it really looks like a booklet that accompanies a commercial product.

============ Friday 15th July 2005 =========

I've customised GS850 so it now does THUMBNAILS, PAMPHLETS, and LANDSCAPE.

:available for all printers and viewers.

I mentioned landscape yesterday, I've changed the way its invoked so read the above link even if you've tried yesterday's binary.

Thumbnails allows you to have eg 4, 9, 16, 25 ... pages printed on one page, eg if you specify a thumbnail factor of 3 you get 9 pages on one page arranged thus:
1 2 3
4 5 6
7 8 9

10 11 12
13 14 15
16 17 18

The pamphlets feature will print 4 pages on each side of a page, if you cut these along the horizontal bisector the resulting cut pages can be placed in a column and stapled or stitched into a brochure.

eg for a 30 page brochure the first page will have on one side:
4 29

and on the other side:
. 1
30 3

you then cut 4 29 from 2 ., and 30 3 from . 1 on the other side of 29 is 30 and on the other side of 2 is 1,

The second page has on one side:
6 27
8 25

and on the other:
28 5
26 7

You can then stitch together lots of pamphlets into a book, and thereby join the home publishing revolution!

Turn the most fearsome documents into dinky pamphlets.

I've always wanted to implement these features but couldnt see how to do it, after studying Christoph Poelzl's request for landscape I realised the right way to do it.

As soon as I have some time I'll implement a 2 x 1 brochure where you have 2 pages on each side. This will probably be more useful than the 2 x 2 brochure just implemented.

The great thing about the pamphlet idea is that say a 100 page document will fit on 13 pages, greatly reducing wastage and cost.

A 1000 page document will fit in just 125 pages.

============ Thursday 14th July 2005 =========

In response to a request by Christoph Poelzl I've customised GS850 so it now can print in landscape.

Other techniques for doing landscape dont seem to function.

You need the new binary and pdf2ps.amiga.

To print/view in landscape say annots.pdf,
assign c: gs850:bin add
pdf2ps.amiga "" annots.pdf

This creates a landscape PS file eg eg view it at low res and see that its rotated by 90░:
gs -sDEVICE=whoosh24 -r50 -dBATCH -dNOPAUSE

============ Monday 27th June 2005 =========

There was a bug in yesterdays new binary, the normal scrolling wasnt functioning, have corrected this.

download the GS850 binary again

I've checked and the scrolling is now fine as is the new reverse scrolling.

============ Sunday 26th June 2005 =========

In chronological order:

Someone requested that with the viewers I make 5 recentre the image and also that scrolling is in the reverse directions:

There is a new env variable "whooshreverse" which if nonzero makes the scroll directions the reverse. download the new GS850 binary with this

Someone asked about whether FW2PDF.lha can be made to deal with "Wide" orientation. I contacted Cary Driscoll, who has improved FW2PDF.lha (FinalWriter to PDF) for this.

Someone else asked various questions one of which I've found the answer to: how do you extract ascii from PDF or PS. I've customised ps2ascii to do this, use GS850:lib/ps2ascii_amiga by downloading gs850core.lha for this: updated today.

He also asked how to conveniently do double sided printing, I've given an explanation for a brute force way to do double sided printing. I tried -dDuplex but that doesnt do it. See the above link for a shell utility I've written for this.

Ernest Unrau contacted me and sent some Adobe Illustrator scripts he has made which he finds useful: Unrau.lha.

Right now all my time is taken up with my filesystem project, where I'm making rapid progress.

============ Monday 9th May 2005 ===========

I've found the answer to the C question I asked on the 6th, I got the answer from SASC6.50's documentation. The question is really "how do you do a directory scan in standard C?",

Answer code fragment:

#include <sys/dir.h>

DIR *dfd = 0 ;
struct dirent *dptr = 0 ;

dfd = opendir( "ram:" ) ;
if( dfd==0 )exit( 20 ) ;

while( 1 )
	dptr = readdir( dfd ) ;
	if( dptr==0 )break ;
	printf( "%s\n" , dptr->d_name ) ;
closedir( dfd ) ;

I need this info to do a portable version of copy_directory_to_my_fs.

============ Friday 6th May 2005 ===========

C Question: (Answered on 9th May!)

can anyone tell me how you do recursive directory scans with standard C?

I know how to do it with dos.library but not via the standard C api.

Regarding unsupported printers: Although a printer may appear to be unsupported on AmigaOS there may in fact be a GS driver out there. Far eastern printer companies such as Epson and Samsung will often have a GS driver lurking somewhere on the internet, probably beyond the reach of Google. So dont give up and run into the arms of Windows XP.

Eg I saw an interesting cheap colour laser printer and have located a GS driver and am looking into this specific printer. When buying a laser printer see if it can do A3 as that allows posters + landscape a4 and also find out how much ram it has. Low ram will prevent renders which wont fit: ie heavy duty images cannot be rendered if there isnt enough ram in the printer. Of the printers you can afford buy the one with the most ram. Dont believe the pages per minute number as actual printing is much slower. pages per minute appears to mean empty pages per minute. A heavily rendered page is much slower.

If you have seen an interesting printer which isnt supported by Turboprint contact me and I will try and locate a GS driver to build into GS850. Turboprint drivers tend to create higher fidelity images than manufacturers drivers as Turboprint has very advanced dithering + colour correction. But if there is no Turboprint driver you should use a manufacturer's GS driver instead.

============ Sunday 1st May 2005 ===========

A few changes made to the homepage, I've moved the external links away from the top otherwise people will leave before visiting!

I've also put a link to my filesystem project which is where I'm spending all my time now: major work underway creating a very advanced fully 64 bit filesystem. I've already got an unintegrated + synchronous fully 64 bit filesystem up and running on 68k eg WinUAE. Later I will make it asynchronous: one thing at a time.

I have some major further internal changes to the filesystem before I intend to start benchmarking it. My filesystem does not use dos.library.

The fact this web-page has been silent is a good sign as it means things are good as they are. As and when it seems appropriate I will reawaken the project. So its currently hibernating and GS850 seems a good release. The GS850 project is living happily ever after as story books say!

============ Thursday 24th February 2005 ===========

I've put some new links to various external Amiga websites at the top of this web-page. GS850 is in the ALD database, but I need to put some further info there sometime soon. If anyone can send me link banners for any of the URL's I will put the banner. The banner needs to be similar in size to a text link as this website is mainly ascii based.

I've received some in depth feedback on using 68k GS850 on Pegasos II (G4@1000MHz) with MorphOS 1.4.3, everything seems to be running smoothly, I may try and upload this info.

============ Wednesday 23rd February 2005 ===========

(some new info (342am) at the end of this update)

Note on emails: if you email me make sure to mention either GS850 or AmigaOS in the subject line, because I get so much junk mail that if the subject line is not familiar I delete the email.

I've been working on various GS850 things, for AROS and cybergraphics 68k the viewers now use my own rescaling code. I got feedback that control-C could crash the program. I think I have this now fixed and GS850 now cleanly exits on control-C, control-C needs to be done in the shell window and not in the viewer window.

The control-C problem was because in earlier GS's my code on exitting would make an internal call which AFPL have changed in an incompatible way without any explanation of how to use the replacement. Anyway by experimenting I have found a replacement mechanism.

Someone emailed requesting for + and - in the viewers to be alternative ways to zoom in + out. I have implemented this, also implemented are: 1, 2, 3, 4, 6, 7, 8, 9 will now move the viewer 1/2 a window in each of the 8 directions so you can move quickly around an image. You can enter these new keyboard commands either from the main keyboard or from the "calculator" keys: the idea being to use the calculator keys. The letter c will give the framecount on the shell. Later I will try and give 5 a function but it will take some study of my code to make 5 do what I want, so for now 5 doesnt do anything.

Initially I made the digits move the image exactly 1 windows distance but there was a lack of visual continuity.

The new downloads are 68k_binary_archive and x86_binary_archive.

Decompress the archive for your system to GS850:,

All new functionality is always explained in cumulative reverse chrononlogical order in this part of the website

I have various new ideas for the port but need to wait till I have a convenient time window.


If you have a fast machine with lots of memory, you can render a page at say 600dpi, and then by zooming out you retain image quality,

gs -sDEVICE=whoosh24 -r600 -dBATCH -dNOPAUSE tiger.eps

(gs here is GS850:bin/gs and tiger.eps is GS850:examples/tiger.eps)

:check the shell output to verify that the full image was rendered, if it wasnt then try a lower resolution,

with the new numeric key commands you can whizz across the image at great speed,

============ Tuesday 1st February 2005 ===========

Continuing from a question by Castellen on Cary Driscoll has sent me a further Final Writer script, FW2PDF.lha.

Also Georg Steger has fixed an x86-AROS graphics bug in BitMapScale( ), I havent yet tried this out but he says there is a huge increase of speed with the x86-AROS GS850 viewers.

============ Friday 28th January 2005 ============

730pm: I have managed to port now the Samsung printer driver mentioned in yesterday's update. I had to rebuild the entire program from scratch, which took about 2 hours 20 minutes on WinUAE on a 2.6GHz Intel Celeron. So the GS850 port now fully supercedes my earlier GS813 port.

============ Thursday 27th January 2005 ============

AFPL Ghostscript 8.50 released today for 68020 AmigaOS and i386 AROS!

The AmigaOS version is nofpu-68020, the AROS version is i386 both builds selected for maximum compatibility.

8.50 is a major release version of AFPL Ghostscript and contains a lot of new rendering code not present in any earlier Ghostscripts resulting in improved image quality. eg GS8.50 contains new rendering code that optimises font quality at very low resolutions. The quality of line curves within images also looks improved. The program also appears to be faster than earlier Ghostscripts.

Please replace the GS813 fonts by the new gs850fonts.lha, as I got feedback of a problem from Cary Driscoll. The problem has been resolved by regenerating the entire fontset from scratch as I had lost track of how the GS813 fontset had been generated. The replacement fonts can also be used for eg GS813 and GS8.

There is just one omission from this build: I havent managed to build in the driver for my Samsung printer. I will try and build it in eventually. So GS813 is still needed for that specific purpose.

============ Wednesday 19th January 2005 130am ============

I am progressing with the port to GS850, I have run into several problems already and it is quite time consuming despite the faster machine. At the moment there is a problem with the driver for my printer as it calls a macro and AFPL have decided to add an extra argument, the original macro used a default argument which is no longer defined. So I'm trying to get around this discrepancy.

============ Monday 17th January 2005 445pm ============

I've just completed my computer holiday and have found AFPL Ghostscript 8.50 was released centrally on 11th December 2004.

So I am beginning now to port GS813 forwards to GS850. GS850 is a very stable build and meant for general release. So if you relook at the previous info updates below you will see I was right to wait for GS8.5x.

First I will do a 68020 no fpu build as this will run everywhere. Later I will attempt a sideways port of GS850 to x86-AROS.

============ Monday 8th November 2004 midnight =========

I have been told that the stable AFPL Ghostscript 8.5x will be out quite soon, maybe even this month. So I have decided that I will wait till this is released and then port it to 68k. I have allocated up to 4 weeks for this work.

Usually I dont do much computing in December, so if AFPL GS8.5x is released at the end of November my port attempt should begin by approx mid January 2005. The first week of January is usually nightmarishly cold so I'm usually too busy shivering to do anything but babble incoherently at that time of year.

I think now it is best to port on a "movable" basis: allocate a certain amount of time eg 3 weeks but not allocate when!

I certainly have the time to port GS8.32 right now, but GS8.32 is a 3rd beta towards GS8.5x and GS8.32 has known critical bugs such as which the AFPL people are working on right now. So it would be an error to port GS832.

By porting GS8.5x, 68k will be bang up to date for many months, also Morphos and x86-aros versions should follow: but the first priority will be to port the 68k version. The Morphos version will probably only run on very recent Pegasos II's.

============ Sunday 7th November 2004 10pm =========

10pm: Things get complicated, I was about to begin on porting Ghostscript 8.15 when I noticed that it is GPL and not AFPL. Yet it supercedes Ghostscript 8.14 which is AFPL. This is slightly annoying as I dont really want to partake in GPL. Trying to change license is too complicated and I am not too keen on GPL.

So I am trying to find out when AFPL Ghostscript 8.5x is planned, if this is quite soon I may wait till it is out and port that. If it isnt for some time then I will now port AFPL Ghostscript 8.32 the 3rd beta towards 8.5x. This would contradict some of my intentions mentioned recently, where I said I wanted to target GS's which have been out for a healthy amount of time. But AFAICS the most recent stable AFPL GS is 8.14 which seems too nonrecent, and GPL 8.15 is said to fix bugs in 8.14,

Conclusion: my plans are changed now to either GS8.32 now or wait a bit and port GS8.5x very soon after it is released: this could be in January though.

It seems there are 3 different GS's, AFPL, GPL and GNU,

============ Saturday 6th November 2004 sunset =========

I should have read the small print!

ok, further to what I said on 31st Oct below:

I have decided to begin porting AFPL Ghostscript 8.15 to 68k AmigaOS, and it seems I probably shouldnt have ported 8.13, no harm that I ported it but I probably shouldnt have, this is why:

29th August:  version 8.31 2nd beta, 
23rd Sep:     version 8.15 first release of 8.1x, STABLE,
26th October: version 8.32 3rd beta towards 8.5x,

So it seems that 8.13, 8.31, 8.32 are only for internal purposes, thus the only *correct* port to do now is 8.15, and after 8.15 the next *correct* version would be 8.5x. As you can see 8.15 though numerically less than 8.31 was released *after* it,

The current 8.13 is fine, but I was somehow aware that 8.00 was a better program in its own right: eg 8.00 was better behaved on Morphos than 8.13. So it seems that there was a basis to this perception. I wonder how many other Ghostscript ports shouldnt have been done!

Trust me when I say this: only *stable* releases should be targetted, stability is much more important than currency. Stable releases always have an undefinable extra something (zhe ne se kwa?), hmmm... maybe what they have is definable and is stability! (zhe se kwa??)

Try and download to storage *all* archives related to 8.13 on this webpage as 8.13 will be removed once 8.15 is ready: as there isnt enough webspace for both versions. In particular download the x86-aros version of 8.13 ASAP eg now, if x86-aros interests you in any way, because after 68k 8.15 is completed there will be a time interval with *no* x86-aros Ghostscript on this page.

============ Sunday 31st October 2004 midnight =========

midnight: further to what it says in the "sunset" update below, I will say on this webpage which version I decide to target, right at the outset. The work will firstly be on a new 68k GS version (68020 fpu and 68020 nofpu). After the 68k version is complete I will then port the 68k version sideways to x86-AROS. The priority is on the 68k version, and the main time window for the work will be 6th Nov to 30th Nov 2004.

sunset (6pm): Approximately 1 week into November I will begin new work on Ghostscript, I will probably try and target the most recent stable version of GS rather than the most recent version. So if the newest version has been around for say 1 week I wont target it, and if the version before that wasnt around too long I wont target that. The reason for this unusual approach is that some versions of GS can have problems, so the assumption is that a version which has been around for a long time must have been a particularly good version.

So eg GS8 was a particularly stable version, and GS813 was soon superceded by GS814 which I think was around for quite a long time. So GS814 would have been a better choice than GS813.

I have absolutely no idea how long the port will take, but I hope it could be done within two weeks.

Valid HTML 4.01!