Click for: WEBPAGE INDEXweb page last updated tue.3.jun.2003.9pm

This webpage has been superceded by my homepage. However it may contain obscure useful info. email me via my email address at the top of my homepage for any info. I thought I had removed this webpage. My homepage contains both general Ghostscript info as well as things specific to my port of Ghostscript.

====== tue.3.jun.2003.9pm ======== I gave myself a NEW-FEATURES-DEADLINE of 31st May 2003, after that date no new features to be done. I am sticking to that deadline, so now I am only completing existing + already designed features. Currently I am working on the last viewer feature before release, a screen shot of the current AGA WB viewer viewing the eye of the tiger in closeup on a 8 colour WB screen is eye.iff. Any of the existing features that prove to be difficult to complete will be abandoned, I dont want to dislodge Hyperion from the Guinness book of records entry for project delay. I have like a zillion other programming projects that I want to return to, thus I want to get this gs8 project stitched up and delivered. It has already taken much too long. All my other projects are non-ports ie they are fully my own work. Writing programmes that are fully your own work is a much healthier activity than porting. Porting programmes is a bit like hiring a Limousine or a fancy suit: it makes you look rich but its a fake activity. Of course I will continue working on GS#? and maintaining this website, but as a background activity. Pointing to the entry below, yes I had to abandon gcc3.2.2 as it is so very memory inefficient. It compiles much faster than gcc2.95.3-4 unfortunately dozens of files refused to compile due to insufficient memory. So I had to abandon that ship. Whats the use of something fast if it wont fit in the space allotted, its as useless as buying a fridge that is too wide to fit through any of the doors. ====== wed.14.may.2003.220am ======== My compiler setup suddenly started crashing a lot, so I thought: time for a full new re-install. (:painful process). Another thought: let me see if I can find gcc2.95.3-5, the current work is with gcc2.95.3-4. It wasnt available, I looked on google, then fed google gcc2.95.3 and amiga, and to my utter amazement it came up with this website!!!! google had noticed that I said the new version of gs8 was being done with gcc2.95.3-4, talk about thoroughness! you have to be very careful what you say on the internet, google notices everything! No gcc2.95.3-5 though, and I know its not on this website! Suddenly something dawned on me, I returned to the gcc2.95.3-4 download, and yes, my eyes dont deceive me: gcc3.2.2. I was so focussed on gcc2.95.3-5 that I only saw the trailing .2.2 in gcc3.2.2. Because .2.2 isnt as big as .95.3 my mind ignored it. Number-psychology! I looked at the date, it appears to have been uploaded on 2nd April. That is some April fools trick! Anyway I am wasting no time in installing this. Beginning after writing this update. Meanwhile with other stuff, progress is good. Finally today got feedback that the gray scrolling WB Cybergraphics viewer is at last functioning. I received one email telling me this today yet sent on Friday. This email arrived after I had rearranged the gray viewer to render to an rgb window. blueyonder! blueyonder! The ISP powered by mad snails! (actually powered by MS!!) Therefore... I shouldn't be too rude, blueyonder are giving me £20 off my May bill as a reward (bribe!) for having suffered one year. They sent me a birthday card with one candle for this!!! The birthday card was as convincing as one from the "Clinton Cards" stores we have here in the UK, I actually thought it was from my brother!! They used a hand-writing font very similar to my elder brothers handwriting! Call me a cynic but I think a lot of blueyonder probs are deliberate, to trick you into using their extortionate 50p/minute "help"line, (argue-in-your-face line is more accurate). Nice junk mail PR, shame about the actual service! Enough about blueyonder, back to the topic, There are a number of hitches that need ironing out eg the embarrassing fact that gs -h has decided to start crashing!!! I am pushing now towards a release or at least second pre-release in a matter of weeks. If possible this month even but that may be overoptimistic. The main work I feel is now done, hence the slightly relaxed tone of this update. Its like after you finished your last exam: you feel good and you basically dont care about anything. There are still problems that need resolving, I am hoping some of them may evaporate on recompiling with the even newer compiler. ====== Fri 9th May 2003 415am ======== Have just upgraded the AmigaOS printing option of -sDEVICE=whoosh from 216 colour version to the full 12-bit 4096 colour version: this is the maximum colour output possible with AmigaOS. Thus -sDEVICE=amiga_printer is now fully obsolete. This completes the obsolescence of all -sDEVICE=amiga_#? devices. Note that this is full 12 bit colour and not HAM pseudo 12 bit, its an OS-hack, where you provide 12 bitplanes *and* a colour palette of 4096 colours: thus eg colour no. (5<<8) + (13<<4) + 11 is (r==5, g==13, b==11). I set up this palette with 3 nested for loops, one for each component value. I like these sorts of workaround hacks, its great seeing people extract extra mileage out of limited conditions. By holding up against the light a printout of the tiger via 4096 colour against a printout sent to me by a tester done with the new gs8's 24 bit rgb turbo device tp24 I verified that the aspect of the 4096 version is fully correct. None of the testers are sending me feedback on whether the turbo option of -sDEVICE=whoosh has the aspect right. I think this means the aspect must be right, for if it were wrong they'd be queuing up to tell me!! As a developer people love telling you that your stuff malfunctions! But when I fix aforementioned malfunctions they remain very silent, not a squeak! I found out what made my earlier attempt at AmigaOS 4096 colour printing fail some weeks ago with a crash: struct BitMap only has space built in for 8 bitplanes. Thus when you try to do the 12 bitplanes necessary for 4096 colour, MEMORY TRASH!!!, CRASH!!!! The reason I had allocated the BitMap directly was because this is how it was done in the Turboprint example code for developers. I am a bit wiser now: the reason the Turboprint example allocates the BitMap directly is because it is using an array of rgb triplets, which could have an odd number of bytes per row, which is beyond the brain of AmigaOS. Turboprint and Cybergraphics both use just 1 bitplane for 24 bit rgb (with no alignment bytes between rows), thus they dont run into the lack of bitplane slots problem. Things can get complicated. The way out for 4096 colour is via graphics.library's AllocBitMap(...) function. For 4096 colours you cant use WritePixelLine8(...) as you would need a WritePixelLine12(...) which doesnt exist. Cybergraphics has its own ways of doing this for 24 bit colour eg the very useful WritePixelArray(...) but not AmigaOS. Thus whether or not you have Turboprint or Cybergraphics, with the new gs8 you will always get the maximum utilisation of your setup! I think there are now 4 things left on my to do list, for -sDEVICE=whoosh I want to put in 1-bit b/w printing for Turboprint and AmigaOS printer, as well as 8-bit gray for both. ====== Wed 7th May 2003 330am ======== A whole suite of fast inbuilt viewers have been now written, and are currently being tested + improved. They include for Cybergraphics, a scrolling WB window viewer and custom screen viewer. There are 2 such WB viewers: one is 24bit rgb, the other is 8bit gray. For classic AGA, there is a colour scrolling WB window viewer which will function on all WB screens. eg if you have an 8 colour screen you will view in colour. Colours are allocated by the OS, so the viewer will run well in parallel to your browser. Also the more colours your WB screen has the better the colour matching. If you really want true colours on AGA then use the fast inbuilt autoscroll custom screen HAM8 viewer. As you know you cannot do HAM8 on a WB window, hence no such viewing option! There are also 8 bit gray viewers and a 1 bit b/w viewer. For this new gs8 the new 24 bit rgb custom screen viewer will be the default viewer for people with Cybergraphics and the custom screen HAM8 viewer will be the default viewer for classic AGA machines. :this choice is based on maximising colours, render speed and scroll speed. WB viewers look neat but they are much slower than autoscroll custom screens. Thus if you have classic AGA as I do, then you can view ps + pdf in 2^18==262144 colours! ie pseudo-true-colour. For colour text the inbuilt 216 colour viewer is better as it has no colour "inertia". There is no dithering anywhere! (dithering? yuk!). Of course until you have tried it this is all just words. There is a lot of work underway on gs8, so recent web-silence is not due to inactivity. I am trying to push forwards at rapid speed towards either a full release or a second pre-release. One other thing, Green Dragon has been asking me for ages how to print landscape on a non landscape printer, in particular he wanted to read Thomas Merz's GS manual. Finally today I managed it as a 1 off hack. I had to convert the ½ meg pdf doc into a 5 meg ps doc, and then hack this to print "sideways", thus eg on my Samsung laser it prints correctly sideways in landscape on a4. Doing this involved translating + rotating user co-ordinate axes on each and every single page. It resets its axes repeatedly so on each page the axes need to be reset, it really has been designed to be not read! For some reason page 1 wouldnt print, so I had to use printer binaries to get around this. So far I have printed out pages 2 to 9. I then whizzed off and emailed Green Dragon! If you want to look download Thomas Merz's GS manual Decompressed it is 5.6meg (meg==10^6 and not Meg==2^20). Its fairly ancient, as it reaches only GS5.01 (pre-cambrian). So beware! you may stumble over some fossils, and its not Amiga specific which usually means trouble. All sorts of wonderful things happen on other systems, However sometimes the older things are the best. It looks quite interesting anyway. Not had time to read it, perhaps tomorrow! ====== Sun 27 April 2003 930pm ======== Now all 3 main turboprint sub devices are correctly functioning. eg fonts_closeup shows a closeup of a printout of fonts 0.5mm high to 2mm high done by tester DarkAngel@blackbunker.de on a Canon_S820 printer. Currently the fast HAM8 viewer option of -sDEVICE=whoosh is functioning correctly on my machine. For classic AGA, HAM8 is not suitable for docs which use colour fonts, here I wrote last night a fast 216 colour viewer option for -sDEVICE=whoosh. This is the best way to view docs who try to get clever with font colours on AGA machines. :A pointless gimmick IMO! The doc I ran into had a never ending series of contents pages written in a blue font: get a life, puleez! Colour fonts are good for images but not text. Have a look at Time magazine for proof: the cover usually has "TIME" in a red font: this is an image, however the articles are always in b/w. Ditto any other journal. Reason: colour text doesnt look good, image text is a different matter though, here the text is essentially a picture so different rules apply. HAM8 only has a 64 colour palette as such it is perfect for eg b/w text + curves and full colour pictures, but not so good for colourful text fonts. I am now beginning work on a fast cybergraphics viewer for -sDEVICE=whoosh. Cybergraphics is great from a programmers POV because it expects data in exactly the form that GS8 or jpeg.library or Turboprint deal with ie arrays of rgb triplets: unsigned bytes: r0,g0,b0,r1,g1,b1,...Thus there is no pixel conversion overhead when connecting 2 of these s/w modules. Also they dont bother themselves with alignment bytes. HAM8 code is the trickiest to do. My new viewers are totally different from the original -sDEVICE=amiga. -sDEVICE=amiga is a bit too close to the render procedure as a result it takes about 10 years to generate the tiger. With my viewers the image is generated in one sweep of the page. ie my viewers are post-render, thus they are very fast. -sDEVICE=amiga ties itself into the render process a bit too closely, this makes it very interesting to watch but oh-so-very-slow to render even a 1 bit b/w image. With my 1 bit b/w subdevice -sDEVICE=whoosh1 the 1 bit b/w tiger is rendered almost *instantly* it is so fast there is no real visible sweep of the page. And I didnt even try to make it fast. All my code is currently done in C. :I am not a speed-maniac, I believe in fast-algorithms done in C, rather than low level supposedly fast machine code. I have often observed that a fast algorithm in unoptimised C will be many times faster than allegedly fast machine code. There is an American saying: work smarter not harder! smarter==efficient-algorithm, harder==machine-code. The other problems with machine code are: its very easy to overlook a bug + it is maintainence unfriendly + unportable + takes much longer to write: with C you can generate programs very fast + fit much more action on your text editor. Really the only place for machine code is in time critical parts of code, usually innermost loops. When a program is awake it spends most of its time inside innermost loops. So it is only here that you get speed ups by coding in assembler. ====== Thur 17 April 2003 130am ======== I am now changing the turboprint print method to rgb24 and not cmyk which is how GS510-turboprint does it. I'll explain why: People create documents in an rgb environment. They use rgb digitised photos on an rgb monitor. rgb this, rgb that, rgb everything. cmyk sucks. rgb is very good eg r + g + b == white. cmyk unreliable: cyan + magenta + yellow is supposed to equal black. But it doesnt. Its almost black but its a few bricks short of a ton. Otherwise why do you have black cartridges. Printers have to use cmyk, so I think it is best to confine the cmyk conversion to the very last stage for the printer. rgb is really nice and mathematical. rgb is truly additive, cmyk is almost but not quite subtractive. Because the images people try to print are rgb, as soon as this is converted to cmyk there will be loss of information. It is generally true that when you have a loss of information procedure it is best to do this as the last thing rather than the first. schematically the GS510 method is: rgb doc ---> cmyk ---> GS8 cmyk render ---> TP cmyk -->printer cmyk My approach: rgb doc ---> GS8 rgb render ---> TP rgb ---> cmyk to printer. With my approach info is lost in the last right-most arrow, with GS510 info is lost in the first leftmost arrow. My approach must be a better approach. Surely? At least its the concept they use for HiFi: distortions always get propagated down the line. I could be completely wrong on this, but I doubt it. ====== Sun 13th April 2003 ========== Have received emails from both my turboprint testers that succesful 24 bit rgb turboprint printouts have been achieved: Thus the strategy outlined below (yesterdays update) of splitting turboprint into multiple devices is yielding fruit! There are still some problems of inverse colour printouts occuring which will need ironing out. eg a black square on a white background was rendered as a white square on a black background. And I thought this test would save printer ink! The printouts also appear to be faster than with GS510 turboprint, this would probably because a lot of work has been done by AFPL GS to speed up the internal GS rendering routines. It is these very changes that made the GS510 turboprint sources fail to function with GS8. But now we are gaining the advantages. :these speed ups are on an unoptimized 68020 no FPU recompile, so with an optimized 68060 recompile it should really fly. Only a stopwatch will reveal whether 68060 no FPU is faster than 68060 FPU version: GS8 has some clever integer maths for the no FPU version. GS8 printing to Turboprint via customized miff24 device has also been achieved: various adjustments will be needed here also. :This method is also suitable for ultra huge bitmaps. Eg a 1200dpi x 1200dpi a4 24 bit rgb bitmap is over 400 meg in size, yet I managed such on my 2 + 4 + 8 meg A1200 through my ancient Star LC10 printer: the printer being 240dpi x 72dpi only prints the left edge of the picture! (This was through AmigaOS printer rather than Turboprint printer). :The lines were being delivered in an ongoing fast rate too, absolute minimum time overhead for this method. Really the time overheads are internal-GS8 overhead + external Turboprint overhead. ====== Sat 12th April 2003 ========== %%%%%% 3:30pm %%%%%%%% BIG BREAKTHROUGH: got email at around 3:30pm from one of the turboprint testers that -sDEVICE=turboprint printed succesfully in 2 colour b/w monochrome. This is the first print and the first succesful print too. Although being 2 colour this is a very important print method as it will enable print of text only docs. Both 8 bit options 256-shades of gray and 256 colour also printed but with wrong colours. The 24 bit rgb and 16bit rgb tests all crashed with divide by zero error which is often a printer.device error, it often means some i/o parameter is wrong (probably zero). A full recompile is being done containing new tests which will help to pinpoint the problem(s). The problem seems to be that turboprint presents itself to GS8 as one device: b/w 2 colour monochrome. Once this device is opened, turboprint tries to redefine itself as a different device by naively changing parameters. I feel the only correct remedy is to split up turboprint into multiple devices turboprint24, turboprint16, turboprint8, turboprint8g and turboprint1, :this is what I have done and will be tested in the next test. I have also customized -sDEVICE=miff24 (absent from the pre-release) so it will print via AmigaOS printer or Turboprint. I have tested the AmigaOS printer part on my ancient Star LC 10 dot matrix and it prints *very* fast. The Turboprint part will be tested by the turboprint testers possibly tomorrow and will provide an alternative way to do 24 bit rgb printing via turboprint. ====== Tue 8th April 2003 ===== By using brute force debugging techniques and a lot of time (over a week) both my own time and my turboprint testers time about 20 wrong parameters have been located in the turboprint sources. It is only due a high level of stubborness on my part that these were ever found! These wrong values probably didnt matter in earlier GS's eg GS510 as they are essentially irrelevant or dependent parameters, but they do matter with GS8 due to tighter consistency checks of parameter values. They lead to internal "rangecheck" errors which cause a rapid exit of GS8 leaving a rather disappointed user staring at his shell in disbelief! There are about 5 printing modes b/w, 256 shades of grey, 256 colour, 16 bit rgb, 24 bit rgb. Each one had some 4 wrong values. 5 * 4 == 20. These have now been corrected and I await test results. Some values I'm not sure about and will be resolved by trial and error. eg are these printing modes additive or subtractive colour. My guess is they are additive but I could be wrong, only tests will reveal There are further parameters which I know nothing about and have left unset. So its not over yet. In parallel I have begun work on an asynchronous jpeg_to_turbo, which will be memory efficient eg decompress 1 line at a time to be sent to turboprint. While the 1 line is making its way to the printer via turborint the next line is being prepared. Other variants of the program should be possible eg miff24_to_turbo looks like it might be useful for ultra high resolution text documents. Maybe I could also make a jpeg_to_amiga also as turboprint uses an extension of the AmigaOS printer.device protocols. One other thing I have received some feedback on how to make download links download by just clicking, it seems it is at the level of my ISP. So I will be emailing them to make some change to mime types. The same person also informed me that I should put < table width="100%" > on each page! This has now been done. Thanks for this webpage-maintainance feedback. ====== Wed 2nd April 2003 ===== I was wrong about the "**** unable to..." error message below. It seems the problem was deeper, probably a makefile level problem. Am now working on this. First version of a new program now available for download: jpeg_to_turbo. Possibly useful to Turboprint 3,4,5,6 owners. ======= April Fools Day 2003 ======= Well the turboprint debugging has begun. turboprint is not going to surrender without a fight! Even if we're going to lose we are going to fight turboprint all the way. It will be decided on points. We are currently taking initial steps to localise where in the source code the non printing is coming from. GS8 is up to its usual tricks again wrong footing the turboprint testers. GS8 has a repertoire of tricks it will throw at anyone who dares to use it. Gradually I am mapping out all its tricks. Today it tried its "**** unable to open the initial device, quitting" trick! You can almost hear it laughing. Through feedback from the turboprint testers whooshjpeg now views jpegs correctly on Cybergraphics: not yet on the website, I will fine tune it so it uses Cybergraphics as the default viewer if Cybergraphics is detected before uploading it. Currently the default is always HAM8. the Cybergraphics viewer now has 2 flavours: 1. Interactively selected screenmode, 2. Automatically computed screenmode. Both will probably have their own usefulness. This new whooshjpeg will soon be on the website. Its wierd, I've never seen whooshjpeg on Cybergraphics, yet I've constructed it on the basis of people 100s of miles away seeing it for me! In fact until one of my testers told me today that it was a driver I had always thought Cybergraphics was some hardware. ======= Saturday 29 Mar 2003 ======= The new turboprint testers have been sent the full install procedure for the new optimised 68020 FPU GS8. This will form the basis for the install for the eventual release. It is quite complex and took me several hours to generate the install. But this work will not need to be done again. We are gradually gearing up for the initial tests. Its like the pilots pressing all those buttons before the plane can even begin moving: but when it moves it eventually lifts off to soar gradually into the stratosphere and off towards the sunset. Like an aeroplane GS8 is the product of a whole roomful of people, including several Amiga people. Everything with GS8 has complexity-potential. As its the weekend, things will be moving very gradually eg one tester is away till tomorrow, =======Thursday 27-Mar-2003 ========== The main project is now complete. Just Turboprint remains to be done, as mentioned above I need testers to volunteer, preferably someone who has managed to print via the Ghostscript 5.10 that comes with Turboprint. I have some volunteers now, so no further volunteers for the moment. This way you would get the full Ghostscript 8.00 facilities eg Postscript level 3 interpreter: GS510 only reaches level 2. GS8 enables you to print all current PS + PDF docs. This website will gradually shift its focus to: 1. Utilities that enhance the GS8 experience. eg to deal with technical issues one runs into when one uses GS8. a bit like the IFF <---> JPEG converters I wrote, and my HAM8 + 216 colour jpeg viewers. Also I will make available any useful 3rd party products eg jpeg2ps which is a fantastic utility. ps2jpeg of course is done by GS8 via -sDEVICE=jpeg! 2. I will also start to extract and document useful usage info. eg I will provide info on how to use GS8 to convert PS to PDF documents, as this is quite complicated: I may try to Amigafy this procedure. Eventually when OS4 developer material becomes available I will probably port GS8 to OS4. 68k GS8 on G3 should be pretty good though. So far I have been in GS8-developer frame of mind. Now I can start to change gear to GS8-user frame of mind, here any difficulties I run into I will try to fix and make available to everyone for free. =======Tuesday 25-Mar-2003 + Wednesday 26-Mar-2003========== The JPEG to IFF converter is complete and is available for DOWNLOAD. Converts 24bit JPEGS (JFIFs) to HAM8 or 216 colour IFF. Greyscale jpegs always converted to 256 shades of grey IFF> Such a converter has interesting consequences eg: because the HAM8, 216-colour and shades of grey converters use fixed palettes, it means you can combine different pictures made by one of these conversions. We can now convert IFF <----> JPEG <----> PS !!!IFF <----> JPEG conversion is my own code using jpeg.library and iffparse.library. jpeg.library is by Paul Huxham. JPEG ----> PS is via jpeg2ps.lha by Thomas Merz and finally PS ----> JPEG is via GS8's -sDEVICE=jpeg !This is all very useful because we thus have a 6 way bridge: AMIGA <----> INTERNET <----> DTP !!! So if you have an Amiga digitiser, this will create an IFF file, convert this to JPEG via iff_to_jpeg this can now be inserted into a webpage (JPEG == jfif ). Convert this JPEG to PS with jpeg2ps and you can now put your photo into a document. Likewise convert ps or pdf doc to jpeg to ham8 or 216-colour iff to load into eg Dpaint! Via JPEG ----> IFF you can load internet images into eg Dpaint with a fixed palette. =======Monday 24-Mar-2003 ========== The IFF to JPEG converter is now available for download, first version! IFF ----> JPEG ----> GS8 ----> PRINT!!!!I've just written an iff_to_jpeg converter have tested it out on Venus.LoRes, . So by combining this with jpeg2ps you can convert an IFF to ps. Give this to GS8 and you can view or print it! I will next extend my iff_to_jpeg to deal with HAM + HAM8 IFF's, this will then be available for download. =======Sunday 23-Mar-2003 ========== I have just completed writing my own jpeg viewer for AGA machines: view 24 bit jpegs by 2 methods: 1. HAM8 viewer, designed to be suitable for monochrome text and curves: unbroken + sharply defined curves. Available for all graphics modes, particularly good on super-hi-res-laced. Good for pictures and text, designed with ps documents in mind. 2. 216 colour palette viewer, sharply defined colours, no dithering: each 24 bit colour is mapped to the nearest of the 216 colours and thats it. Perfect for viewing GS8:examples/annots.pdf which uses a lot of cheerful colours! 3. grey-scale jpegs eg from jpeggray will always be rendered with a 256 shades of grey palette. Both viewers are written utilizing the current jpeg.library from www.aminet.net. This library is superb and does all the hard work for you, and comes complete with usable examples and autodocs. I created my viewer by customizing the main.c example. jpeg.library makes jpegs easier than IFF's!! jpeg.library will even create jpegs for you if you hand it an array of rgb triplets. =======Friday 21-Mar-2003 ========== Have completed a generic mechanism for arbitrary script files available for most GS8 output devices. Example, for device -sDEVICE=pnggray which is 8 bit gray PNG: you would create an optional script file GS8:bin/view_pnggray which could say .k name___ .bra { .ket } Sys:Utilities/Multiview {name___} delete {name___} By using vPNG data type (rather than vPNG viewer) this produces superb WB rendering of text. Quite comparable with Apdf quality IMO. The device script retargetting mechanism is fully functioning, but will be fine-tuned further for increased usefulness. Via this redirection mechanism all those viewers you've seen on www.aminet.net suddenly become GS8 viewers!! Thus via vPNG from www.aminet.net and png16m we instantly get a HAM8 viewer => (2^6)^3=2^18=262144 colour viewer on classic Amigas. For some reason I thought HAM8 was millions of colours, still its a big amount. This is the first viewer that shows the Tiger with green eyes on my AGA machine and varying level of orangeness for the stripes. And best of all NO DITHERING!!!!!! vPNG makes the new GS8 exude quality. The AmigaOne off-the-shelf-components concept comes to GS8. Likewise you can create an external viewer script for eg jpeg, png16, png16m, png256 (8 bit colour), and most graphics formats in: gs8_fileformats.txt Unlimited number of possibilities. For a printer device the script could compress the binary files. =======Monday 17-Mar-2003 ========== FULL COLOUR VIEWER NOW FUNCTIONING. This is done by redirecting the output of GS8 jpeg device to an external reconfigurable jpeg viewer. Multiview does the trick because I viewed the tiger in colour with GS8 jpeg device calling Multiview at 2am this morning. I am so pleased about this. It needed a certain amount of help from dos.library but I managed it. "dos.library" is so practical. GS8 jpeg device is full 24 bit colour so all that is needed is an external shell driven 24 bit jpeg viewer for graphics cards. I know jpeg device is 24 bit, `cos it says so in the source code. The 2 existing amiga viewers are going to be unslotted forever from my port at least. They have wasted weeks of my time with their Bus Errors and crashes and they look horrid on my AGA machine. Bye bye amiga viewers, hello external jpeg viewers. If you dont like this decision: tough. Porting Amiga GS is going to be so much easier now, it will be a breeze. the GS8-jpeg-viewer mechanism needs a bit of fine tuning which I will now get into. Some technical GS8 thingies need to be resolved. turboprint of course will be staying: and is currently undergoing testing in Sweden by a volunteer. =======Sunday 16-Mar-2003 ========== Sorry for not recently updating the website, I've been so busy on this second version of GS8, also whatever time I had was spent replying to GS8 emails. I'll have to become a bit more organised! I've had some very interesting feedback which will eventually make its way onto the website. The new turboprint driver has today been sent off for testing. I've finally solved the problem of setting GS8's stack size. The mechanism used is very transparent. Without any user-startup code you can just type eg gs8 -sDEVICE=epson -sOutputFile=ram:tiger GS8:examples/tiger.eps and as if by magic all the assigns will happen, the stack will be reset to whatever you want, GS8:bin/gs_000 will be run in place of gs8 in the above command line. on exit the stack will be reset to its original value and if you wish the assigns can be removed. No more user-startup bloat. The mechanism uses 2 programs pretender and pretendee and 2 ascii files need to be created. The mechanism works via indirection trickery encapsulating the assigns, stacksize, programme to be run into 2 ascii files: one is a parameter file and the other a normal AmigaDOS script file. Also the same mechanism can be used for any other stack greedy shell program. Click here for GENERIC STACKSIZE SOLVER=======Sunday 9-Mar-2003 ========== YESSSS!!! progress: I took a risk and have managed to compile and link a 68020 NO FPU OS3.0 ixemul.library OPTIMIZED version of GS8: This version is considerably smaller in size than the unoptimized 68000 no FPU version: 2628120 bytes unstripped vs 3558400. The Turboprint driver has compiled and linked perfectly: I will soon send this out for testing: by one person first. SEE THE TIGER IN GLORIOUS COLOUR! By using the jpeg device I have created the tiger in colour: tested on MultiView, AWEB and IBrowse. The Multiview image is inferior to the browsers. AWeb clips the image at the lower end slightly but otherwise is a slightly better image than IBrowse which doesn't clip and gives the full image. TIP: Make sure your Workbench screen is in at least 16 colours via Prefs/ScreenMode (preferably 32 colours) to get true-ish colours from your browser. gs8:bin/gs_020 -sDEVICE=jpeg -sOutputFile=ram:tiger.jpeg examples/tiger.eps View the image for yourself: tiger.jpeg (79k)THIS KIND OF MAKES THE VIEWERS OBSOLETE AND POINTLESS! AWEB and Ibrowse produce a really fantastic image! The Workbench viewer is functioning perfectly. The custom-screen viewer still crashes and is worse than the original version on the GS8 downloadable on the main web-page here. I will probably remove this viewer as some people dont like the presence of crashable features. The inbuilt printer driver for my Samsung ML-4500 laser printer: -sDEVICE=samsung_gdi is functioning perfectly. The workbench driver is functioning perfectly: GS8:bin/gs_020 -sDEVICE=amiga_printer -sOutputFile=- GS8:examples/tiger.ep prints out the tiger on my dot matrix Star LC-10 printer from 1989! The convert ps or pdf to iff function is performing perfectly: GS8:bin/gs_020 -sDEVICE=amiga_ilbm -sOutputFile=ram:tiger GS8:examples/tiger.eps produces ram:tiger_0001.ilbm etc I checked this with dpaint. This is a much better image than either of -sDEVICE=amiga or -sDEVICE=amiga_custom but unfortunately is still di-chrome (2 colour palette). By changing from noixemul to ixemul the control-C to exit is not quite functioning properly so I am trying to fix this. Doing an optimized version at this stage was probably a wrong decision: compilation takes much longer + a lot of new error messages appear. Really I should iron out the problems in the unoptimised version before stepping things up. =======Satuday 8-Mar-2003 ========== Work has resumed on this GS8 port. I am restarting the recompilation afresh for 68020 + NO FPU + OS3.0 + ixemul.library as explained in the summary above. Whilst offline I had endless new ideas for the port including the above change of the base machine which I think will exclude no-one. This new-base machine might also require the presence of some other libraries: if so I will go to great lengths to make this as painless as possible. There are also some new things I am looking into but which I wont mention until I am sure that I can achieve them, so I dont falsely raise peoples hopes. =======Wednesday 24-feb-2003: 3:30am approx.====== I'm away from the internet now till approx. 8 March, so no further info till then. With the replacement signal handler, when the Tiger window opens it starts being rendered, but GS still abandons the render. However now the window magically vanishes: so at least now I have a graceful (vs disgracefule ;) ) exit. No more abandoned windows but I'm still not there. I went to test my Samsung laser and GS said unknown device: doh! I forgot to slot it in. Slotted it in and began the makefile but its taking forever. So I'm afraid this is as far as I'll get for now. As soon as I return to computing approx. 8 or 9 March, I'll resume fixing this port. I know fixing this is possible as I managed it with those less fresh sources. Maybe there is a signal ambiguity: an Amiga signal value being accidently interpreted as a GNU signal somewhere? With the existing port I know I solved the prob by doing something that didn't logically make sense. =======Tuesday 24-feb-2003: 7pm approx.====== Well I eventually managed to compile everything, I needed to alter some things though to achieve this. In the process I encountered my first non-english makefile (german) and Phase 5 mentioned in another file! The linking could not be completed due to memory exhaustion of ld. I have 8+4 meg fast + 2 meg chip A1200. VMM came to the rescue using VMM on ld I added 20meg extra VM: how convenient ;) Some Cybergraphics functions were missing for link stage. Eventually pointed source to appropriate inline file. To get past the linker I had to compile the main amiga source file (gdevamiga.c) with the -O option. No hitches so far from Turboprint driver. (Printer drivers seem better behaved than Viewers). Linking completes. I run "bin/gs_000 examples/tiger.eps", window pops open fills with grid of dots as usual and then GS quits with "bus error" with an abandoned Tiger window on WB. I try again, this time similar, eventually click on closewindow and get freeze crash. I study the source, the signal handler stuff that ate up many days on the previous GS8 had been all hacked out with comments. Bus error is a signal. signals need handlers, I reinstall my previous GS8's signal handler stuff, + modify it slightly to test out an idea. Recompile by hand (using makefile would eat up an hour before it even starts : no time for makefile nonsense) and try again. This time a lot of the Tiger is drawn (most of the stripes) then it is abandoned. This abandoned tiger is on my WB as I write this update! This at least is progress. This is where I am now, I have 2 immediate ideas to test out right away. If I hadnt had my notes of the previous GS8, reaching this point would probably have taken another week. Step by step I want to home in onto a fully functioning GS8 by whatever it takes. GS8 needs to be tamed. There may be further updates tonight which will go above this, I am going to be away from Computers + the internet from tomorrow till approx 9 March so there wont be more updates between 25 feb till 7Mar at least. But after that the website will resume. =======Monday 23-feb-2003====== Still not reached the link stage. Even when the link stage is completed there will be further hurdles. The main Amiga sources including Turboprint driver have now compiled successfully after a certain amount of adjusting to fit in with the changes of how the new AFPL GS does things. I think AFPL GS are trying vigorously to distance themselves from GNU GS, this is a bad thing but it wont stop me doing this port. Someone has now volunteered to test for me the 68040FPU version, so there will be a 68040FPU version: note I can compile but cannot run such a version so having someone to test it out is vital. =======Sunday 23-feb-2003====== My computer has been on non stop since Satuday night for the whole of Sunday recompiling GS8. I am missing 2 header files proto/cybergraphics.h and proto/Picasso96.h email me if you know or binmail them even. I may be able to do without them as I noticed the INLINE is switched off for these 2 files (presumably for a good reason). I have compiled the file containing these 2 by commenting the 2 #includes out and putting "extern struct Library *CyberGfxBase". There was no cybergraphics or Picasso stuff in my previous GS8. I cannot wait to try out the result of this recompile. As I dont have cybergraphics of Picasso I'll need someone to volunteer to test these out for me. By using the notes I scribbled when solving endless problems with the previous recompile I am saving myself many days work. Whilst GS8 was recompiling I studied furiously through some HTML book, YES!! I have debugged this website! Anyone notice? I've lost the background white colour though. I gave up trying to do it via HTML editors, they dont allow you to edit an existing site. I solved these websites by replacing 1 table construct by 2 consecutive ones: 1 for the text and 1 for the downloads. Took several hours to extract this from the book. One example is worth a thousand subsections. gcc2.95.3-4 is functioning just fine now. I have to deal with 3 different impenetrable entities: gcc, Ghostscript and HTML. I also have no X11 includes X11/Xlib.h etc I installed X11R6.3 from GeekGadgets but no includes. I'll probably remove the X11 stuff for now as I did with the previous GS8. Isn't X11 the unix mechanism for sending the screen displays (windows etc) from the remote host to the terminal screens? I am still far from the linking stage. That is the final barrier. My A1200 will be compiling away (controlled by the makefiles) tonight and after breakfast I'll switch on the Monitor and ponder over the error messages. On Sat. night I used VNC instead of KingCon, I didnt realise the default history size was tiny so I lost most of the recompile error messages. I've returned to using KingCon shell. This recompile is going far smoother than the previous ones. =======Saturday 22-feb-2003======

Last night at 3:00:00 am precisely I succesfully compiled hello world with gcc2.95.3-4 so I have managed to install this brand new compiler. Installing this compiler is very difficult and I very nearly gave up, but I'm there now so I can laugh!

Now I understand Geek Gadgets a bit.

I am now beginning the logistically complex job of doing the fresh recompile. There are some 1000 source files in total with about 500 #?.c files and approx 20 makefiles for this compile (of these only about 4 need work though, the rest are unchanged unix-gcc makefiles).

I'm beginning from scratch with minimal + controlled cut and paste from the current GS8 makefiles. But essentially it is a clean + fresh recompile in every respect.

I've had a quick look at the Turboprint driver source code: it looks very promising, with a lot of options. A pity that my printer isn't supported: as such I need someone to volunteer to test out the turboprint driver once I've managed to recompile.

I've had various feedback from people wanting the usual assigns back for eg Dopus so I'll probably do recompiles for the usual assigns.

I'll also for the final version probably do a 68060 recompile as I've heard from someone who has such a setup.

I wont do a 68040 recompile unless someone requests it (by email). So if you want this, ask. They probably then also need to volunteer to test run it as I have neither a 68040 or a 68060.

=======21-feb-2003======

INFO: For explanations of the inbuilt drivers I have uploaded an excerpt from the makefiles that explains those cryptic device names: devices.list (5kb)explains what pjxl etc are! 

The GS8 here is the full unix-gcc GS8 with the (unix-specific?) X11 drivers removed and the 4 Amiga specific drivers + Samsung-laser driver slotted in. These removed X11 (display?) drivers are probably irrelevant to us. Likewise Apple specifics are probably missing, email me for any you wish slotted in and I'll attempt it.

dirsizes now has pattern matching filter, eg dirsizes -r -f -p #?.c ram: on one line to get size-sorted list of #?.c files however deeply placed.

=======20-feb-2003======

USEFUL TIP: Suddenly dawned on me that to view the docs all you have to do is point your web-browser at GS8:doc the web-browser will automatically know what to do, from this page you access the whole cross-platform html doc files via links.

I have had some very interesting feedback including the source code for the GS Turboprint driver and also the Amiga source code for GS650 and derivatives. I am now attempting to install a very recent gcc (2.95.3-4) and do a brand new recompile incorporating the Turboprint driver and the more sophisticated Ghostscript Amiga viewers.

So fresher compiler and fresher Amiga-sources as well as Turboprint support (I hope!) It will be a little while though before the process completes. I will be away from the internet for a while from next Wednesday but I'll see how much I can achieve before then. I am currently battling with installing the new gcc. With any luck the WB viewer will display in colour.

Note that the printer driver used affects the picture you get eg if I print tiger.eps with the Workbench epson driver I get a totally different tiger picture from using the inbuilt epson driver. So the Turboprint driver may result in faster and better rendering. I cant vouch for it though. With pictures in particular there are unlimited degrees of freedom for a driver to utilize.

For the final version I may do some extra "Turboprint-only" recompiles in order to reduce the program size by removing all other drivers.

The dirsizes program has been improved: it now has a files-only filter and a size-filter: only sort things exceeding a certain size.

So eg to filter and size-sort out all files >1000000 bytes on a CD no matter how deeply situated type :"dirsizes -f -r -s 1000000 CD:"all on one line. I have tested this on an AmigaActive magazine CD and it did it fine.
updated dirsizes.lha (9kb)Useful utility for efficiently clearing disk space: fun + useful

Get a GoStats hit counter