Fujiology Archive

home *** CD-ROM | disk | FTP | other *** search

/ Fujiology Archive / fujiology_archive_v1_0.iso / !MAGS / ICTARI / ICTARI40.ZIP / ICTARI40.TXT < prev next >

Wrap

Text File | 1996-11-14 | 42KB | 777 lines

ICTARI USER GROUP ISSUE 40 November 1996 ___ ______ ___ _________ _________ ___ \__\ \ __\ \ \__ \______ \ \ _____\ \__\ ___ \ \ \ __\ _____\ \ \ \ ___ \ \ \ \ \ \ \ ____ \ \ \ \ \ \ \ \ \_____ \ \____ \ \__\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \__\ \_______\ \______\ \________\ \__\ \__\ * m a g a z i n e * =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I C T A R I U S E R G R O U P 63 Woolsbridge Road, Ringwood, Hants, BH24 2LX Tel. 01425-474415 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= INDEX FOR ISSUE 40 ================== ASSEMBLY ST Assembly Language Workshop. Chapter 5. C Memory debug utility. GFA Text manipulation/search routines. GFA VDI functions. STOS Line clipping techniques. Lottery program. FORTRAN FORTRAN on the Atari. MISC Falcon register information. Current membership list. In next months issue of ICTARI (this may change) :- ASSEMBLY C Bezier curve routine. GFA Functions for using ARGV arguments in command lines. File recognition routine. Using the Iconified window Server in GFA. STOS Slideshow program and tutorial. FORTRAN BC-FORTRAN 77 development system. FORTRAN-C compiler. Compiler-Driver for BC-FORTRAN 77. MISC A quick guide to creating an HTML document. ---------------------------------------------------------------------- EDITORIAL ========= THE FUTURE OF ICTARI -------------------- A few months ago I mentioned that I was planning to purchase a PC, well I have now built my own system around a 133MHz Pentium with the all the usual bits and pieces, 8 speed CD-ROM, 32Mb RAM, 17 inch monitor, 1.6Gb HD, etc, etc. The problem, as I said before, is that I do not have sufficient room to run both the PC and the Atari so I am going to have to dispose of the Atari hardware, software, books and magazines eventually. This means, of course, that I will be unable to continue with the editing of Ictari after this year. Although the membership has fallen over the last few months from about 60 members down to about 30 at present, I believe the members that still remain are quite happy to continue programming on the Atari and some members are still providing useful contributions to the magazine. I would hope that Ictari will continue into next year but this will depend on someone being prepared to take over my role as editor after Christmas. I have the next issue already prepared which I will send out as usual in December but if no one has volunteered to take over by then, this could be the last issue. If you have found these magazines useful over the past three years and you would like to continue receiving them, then please seriously consider whether you could do the job of editor. It is not difficult although ideally you do need a hard disk as well as a colour and monochrome monitor. Naturally I will be happy to assist in any way I can and I can probably provide the necessary software and hardware, if required. You do not need to spend a LOT of time on editing the mag, most of the time is spent just deciding what material to include on the next disk, preparing this text file and then making 30 copies of the master disk for despatch which takes about an hour. If anyone in the UK is interested (and I sincerely hope there is) please ring me any time so that we can discuss it further. Naturally I am sorry that I have had to step down as editor as I have enjoyed putting the Ictari magazines together over the last three years but personal circumstances have meant that I need to have a PC to fulfil other commitments which I cannot do on the Atari. However, I do hope that this will not be the end of Ictari, but that is really up to you. I look forward to hearing from someone SOON. ---------------------------------------------------------------------- CORRESPONDENCE ============== To: Everyone From: Jason J Railton Re: Stuff... I hope you liked the two-player TANKS game, from ICTARI #39. It wasn't a demo. That was the game. I'll try to get my BUZZSAW game finished soon too. It's difficult to set the difficulty levels just right, and some of the special effects I'd planned for bonuses are proving a little complicated. I just need to spend some time on it. I haven't done a thing on my 3D maze for ages though. I'm not really bothered that ST Format has finished, as there wasn't much in it worth reading over its last year. It is a shame, however, that the PD, repair and hardware companies have lost their advertising space. Good luck to the new magazine, anyway. I won't be getting rid of my ST for a long time, I can assure you. Anyway, I've sent in a tutorial on clipping lines to the screen edge. You can use the techniques in any language that has a line drawing command, and if you look on ICTARI #31 you'll find some machine code line drawing routines written by Peter Hibbs to use them with. Run either CLIPPING.PRG or CLIPPING.BAS (STOS) with CLIPPING.TXT in the current directory, to read the tutorial. Step through it with the SPACE key. You can also send CLIPPING.TXT to the printer, but then you won't get the diagrams or demos. I've already covered rotating lines, and I'll go on to describe 3D and perspective for future articles. Finally, I'll talk about functions such as SIN and COS in machine code. (For those who can't wait, you use a table of values of INT(16384*sin(r)) in your sums.) */ The CLIPPING.PRG program is very good as it describes the clipping techniques used together with animated graphics of the functions. Unfortunately it bombs out in Monochrome but is excellent in colour. It would be very useful if this idea could be used in other tutorial type articles. ICTARI /* ---------------------------------------------------------------------- To: ICTARI From: John Hayward I am trying to write a program that can produce touch tone beeps through the ST's monitor speaker (like a telephone) using STOS. I have tried doing this using sound samples but they were not of sufficient quality to dial correctly, What I need is some method of playing sounds using the Yamaha sound chip with exact frequencies in Hertz. The values required are as follows :- Frequency ---------digits--------- 697Hz 1 2 3 (A) 770Hz 4 5 6 (B) 852Hz 7 8 9 (C) 941Hz * 0 # (D) 1209Hz 1336Hz 1477Hz 1633Hz For example, if button 8 is pressed, the 852Hz and 1336Hz tones are sent out to the exchange to signify digit 8. This shareware program is unusual, I am using it to create a crude form of E-mailing system which does not require a Modem or a subscription to an on-line service. If you have access to a television with Teletext you can advertise things on a notice board on channel 3, page 388/389 and there is a place where you can sell computers on channel 4, page 435. To place ads you use an unorthodox method of writing your message, you convert each individual letter into a two digit code (A=11, Z=36, etc) and you then call a premium line phone number and type in every single code which takes about 5 minutes and I estimate would cost about £2-£2.50 per advert. My program will convert the text message into a series of tones and play them down the line at relatively high speeds which results in cheaper bills with no errors. As well as selling hardware on the ads you can also advertise PD libraries, BBSes or whatever so you might find the program useful to advertise ICTARI. */ I think it may be more difficult to implement than you imagine. I don't program in STOS so I can't tell you how to do it using that language but I have written a small machine code program to test out the basic idea and it does not seem to work. I suspect there could be several reasons that it fails to work properly, the main one being the frequencies that the Programmable Sound Generator (PSG) can generate. As you probably know the tones are derived from a source oscillator of 125KHz which is then divided down by the PSG counters to produce a range of tones. The problem is that it is not possible to produce ANY tone, only an approximation of the tone. For example, to calculate the division factor for a given tone you would use the following formula :- divide_factor = 125000/f where f is the desired frequency. So a frequency of 1633Hz would give a value of 76 which is the value that would be loaded into the PSG registers for channel A (or B or C). To calculate the actual frequency produced you would use the following formula :- f = 125000/divide_factor If you use the divide_factor value mentioned above to find the actual frequency it calculates as 1644.73Hz which is quite a bit different from the 1633Hz required. The other frequencies work out as follows :- Required Divide Actual Frequency Factor Frequency 697 179 698.32 770 162 771.60 852 146 856.16 941 132 946.96 1209 103 1213.59 1336 93 1344.08 1477 84 1488.09 1633 76 1644.73 It may be possible to fiddle about with the divide_factor to get slightly nearer to the required frequency but I doubt whether it would still be reliable enough for general use. When I worked for British Telecom I designed some equipment to generate tone calls and I seem to remember that the tone detectors in the exchange equipment have a tight tolerance on the tone frequencies to avoid cross channel interference. Also the tones must be reasonably good sine waves with very little distortion to ensure reliable detection. This may be another problem with your scheme, any distortion introduced into the sounds will make it less reliable. Another factor is phase difference between the two tones which also has to be within certain limits. It may be possible for other computer platforms (such as the PC) to generate accurate tones but I don't think the Atari is capable of doing this unless you can use the D-A converter in the STE using sampled sounds. You said that this did not work but how exactly did you do it. Presumably you sampled the tone output from a telephone and played them back using the D-A converter chip in the STE. Probably the best way to achieve your aim using the Atari would be to use the tone generator chip which is used in telephones and is available for a few pounds. The chip could be controlled from the Atari parallel port to generate the required tone pairs but this will, of course, require some hardware building on your part. If you would like further details of the chip let me know. ICTARI /* ---------------------------------------------------------------------- To: ICTARI From: Mark Foot Can anyone suggest a method of having a library of SmartIcons as per Windows, whereby a user can select those he/she wishes to have available within a program. I am writing a 'programming language' in C for a robotics project and I would like user selectable tools via icons. Has anyone managed to fit a second serial port to a 520ST? If so any hints and tips on hardware and software aspects would be appreciated. ---------------------------------------------------------------------- To: ICTARI From: Charles Ayres In your last issue of ICTARI there was a request for information regarding PAGE 6 magazine for the Atari 8 bit. I am happy to tell you it is still going strong thanks to Les Ellingham and Sandy (his wife). It is now called Page 6 New Atari User as Les took over the old ATARI USER magazine when it went out of production. Unfortunately this magazine is now printed in A5 format and is only available on subscription from :- PAGE 6 PO BOX 54 STAFFORD ST16 1DR Annual subscription rates are as follows :- UK MAGAZINE ONLY (6 ISSUES) £15.00 UK MAGAZINE WITH DISK (6 ISSUES) £25.00 ---------------------------------------------------------------------- To: Peter Hibbs From: David Preston Thanks for your additional comments re WordGrid. I have to admit I'm no wiser (more puzzled if anything) about the problem with Mortimer's print spooler. I use Hisoft's spooler (HSPOOLER.PRG) from the "Introduction to Programming Utilities" pack, and there doesn't seem to be a problem with that one. I don't have Mortimer though, so I can't try that out. Is Mortimer usually co-operative? (I suppose it must be or you'd use something else!) To: *.* What about everyone else - any other problems with WordGrid, with print spoolers or w.h.y.? Or any similar problems with your own Hisoft Basic progs? To: STOS programmers What a swiz! (Is swiz a real word?) Anyway, I was fiddling about converting a GFA listing of a fractal (Mandelbrot set) generating prog from an ancient coverdisk, into STOS. It worked ok but slowly (no surprises there, then!) so I set about optimising it a bit. I'd used nice structures (repeat...until etc.) originally, but found that nasty goto's and stuff were significantly quicker. It's all very well trying to write decent looking code, but if the language doesn't co-operate you're spragged. (Now that _is_ a real word.) One thing that did emerge however is that it's much quicker if you have to use floats in your maths to use _all_ floats. Or at least don't have a mixture of ints and floats in individual calculations. Even for...next loops should count in floats if the counter is used with floats in a calculation within the loop. I think the manual suggests that mixing number types in calculations is inefficient, but sometimes you need to discover the truth of these things for yourself! To: Kevin Cooper Re - Subject DLL's I'm not sure what you mean by "the standard graphic format will be the standard device independent format" - surely something like the PNG format as described in Ictari recently would be an ideal choice? RTF would seem right for WP, but spreadsheets are a more complex matter, as different applications have different features/functions etc. It depends if you want to just transfer data (where a DIF file might suffice) or have a common (standard) data file format to save formulae etc. And bear in mind that some software producers (eg. Lotus) have been known to be less than chuffed about people using their standards... To: UK members With this new Channel 5 in the offing, and the need to retune VCR's to avoid a clash with the new channel, does anyone know if/how this will affect those of us using our ST's on a telly? */ I find Mortimer very useful actually although it needs to be on a hard disk to be practicable. It provides a reasonably good and very fast text editor as well as a number of other handy facilities. I would be happy to send you my copy with manual if you want to try it out with your program, let me know if you want it. Alternatively you could just mention the problem in the document file with your program and let the end user disable the spooler. PDH /* ---------------------------------------------------------------------- To: Kevin Cooper and everybody else From: Mårten Lindström VRML ---- If you do implement a VRML browser, I think you will be really in the forefront of things. I had personally never even heard of VRML until I read your message. However, with the help of Alta Vista, I quickly found the specification for VRML 1.0 (in HTML format) on the net - and I have now sent it to Ictari. It sounds like a very nice idea but probably a lot of work to implement. To others who also didn't know what VRML is, and still don't: VRML (Virtual Reality Modelling Language) is a language for describing a "world" of 3D objects (and light sources etc.) of which some may be possible for the user to manipulate (presently only in the form of clickable links - to other VRML worlds or to HTML texts - but this is intended to be developed in the future). VRML has got absolutely nothing to do with HTML (HyperText Markup Language) or SGML (Standard Generalized Markup Language - of which HTML is an application), except that its name was originally inspired from them. VRML doesn't compete with them. HTML and SGML deal with TEXT documents, VRML with 3D worlds. To: Ictari Editor, Article Writers and Readers From: Mårten Lindström __________________ HTML FOR ICTARI? ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ It seems to me that things are definitely moving towards more and more HTML. And I am not just speaking of the Internet where new specifica- tions etc. seem to be often provided ONLY in HTML format. Even else- where, such as on software distribution disks - where README files etc. used to be only in plain text ("ascii"), you will now often find alternative HTML versions. HTML (with a good browser) not only allows documents to LOOK better but can sometimes even add to the information contents. Where, for instance, programming syntax is described in printed books, ITALIC style is often used to denote a VARIABLE; this can be very easily translated into HTML markup but will be lost in plain text. Being able to use different HEADING LEVELS (displayed in different font sizes) can also be very helpful to make a presentation clearer. And, of course, HTML allows PICTURES to augment the text. Back in the distant past (Ictari 10) our Dear Editor did raise the question of whether Ictari should change from plain text to something richer allowing pictures (apparently without much positive response though I am not to blame 'cause I hadn't yet joined), but, of course, HTML wasn't an option back then (before the Atari HTML-Browser). In addition to all this, HTML has some further advantages: ∙ It is non-proprietary. Bound to neither a software company nor a specific platform. (And, again, its support is only rising.) ∙ Good HTML browsers come as _FREEWARE_ (both on Atari and PC). ∙ It is viewable as plain text too (no control characters used). Admittedly not quite as neat-looking as a dedicated plain text file could be. But since both newlines and extra spaces will be ignored by the HTML browser, they can be freely used to adorn the layout of the text when viewed as uninterpreted "ascii". ∙ It is very SIMPLE TO WRITE HTML documents with no more software than a plain text editor. REALLY, it IS!!! I have written a brief "quick and dirty" guide to converting a plain "ascii" text to HTML, and could perhaps write a more in- depth article on HTML too, if there is interest for it. Perhaps making that article in HTML format :-) I have also sent in the specification documents for HTML 2.0 and 3.2, the latter actually being a bit more accessible, I would say, though lacking some explanations and recommendations of the HTML 2.0 docs. (See some further notes below.) ∙ HTML is per definition highly adaptable to any display (or even to speaking machines) or user preferences. If you have ever used CAB or HTML-Browser you can see how it, on the fly, reformats the text to fit whatever window width you choose, and this is how any browser should work. (Thus, you SHOULD be able to browse even on an ST low-resolution screen - 320x200.) You sometimes hear that you need an 800x600 display to go browsing the Web. This is CRAPTALK!!! It may be true that some lousy authors use unnecessary large pictures, as well as various effects created with unsound or even outright illegal HTML constructs, to cover up poor text contents. But good HTML should be written to be enjoyable even on very small screens (there ARE Macintosh Classic users out there who browse the Web with apparently not more than 460 monochrome pixels width available). And it should (as far as possible) provide alternative meaningful text for those who - for whatever reason - cannot see the graphics. In fairness, the last of these advantages may also be seen as a disad- vantage: HTML is NOT a page description language. It is used to mark up the PURPOSE and MEANING of various parts of the text, and leave the display for the browsing software and human to decide on. Thus HTML lacks a legal and sound method for such a simple thing as indenting a text section (though self-brewed solutions abound, one more horrible than the other). And so you may perhaps prefer something like Post- Script, Acrobat or maybe even RTF for a printed document with well- defined layout, page breaks & numbering etc. ''~`` ( o o ) ,-----ooO---(_)---Ooo-----. / \ / SO, WHAT DOES EVERYBODY \ ( THINK ABOUT USING ) \ MORE HTML IN ICTARI ? / \ / `-------------------------' Some follow-up questions: ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ∙ Does everybody have a copy of CAB or HTML-Browser? (It IS freeware you know.) ∙ Are you HAPPY with CAB /HTML-Browser? I find CAB to compare amazingly well with the PC's MS Internet Explorer (which I must admit is what I use for online browsing) and Netscape, though there are a few weak spots: - For one thing, CAB seems strangely unable to make proper use of the ordinary ST low resolution (320x200 in 16 colours). Outline font sizes don't match the system bitmap font size well (though to some extent explainable by how GDOS/NVDI deals with it) and, very oddly, CAB doesn't seem to make use of the COLOUR!!! A REALLY GOOD browser should work equally well in any resolution, taking advantage of what colours there are. - CAB also doesn't seem to keep more than one document in memory at a time. Caching pages in RAM could save considerable time when jumping back and forth - e.g. between a table of contents and the "contents" (sub-documents). I am (possibly) considering writing an alternative HTML browser with the following specifications: + Small(er than CAB) - possibly so small that it could even fit on each and every Ictari disk (?). + Fast(er than CAB (?) ) + Taking full advantage of ST low resolution as well as any other resolution. - Simple. Bare minimum of functionality (definitely no support for online Web browsing) and perhaps initially not supporting some more advanced HTML features such as the tables of HTML 3. Would there at all be any need for such a program? To: All From: Mårten Lindström HTML versions (again) ------------- Since last month I have found out some more on this topic and it seems that the real reason that HTML 3.0. was abandoned was that a) - Producers of HTML browsers were too lazy to implement it and instead thought it more fun to implement their own non- standard extensions. b) - Illiterate people, knowing nothing about the HTML 3.0 specification but styling themselves "web designers" or something similar, took on the habit of calling their sites "HTML 3.0 enhanced" when in reality they had just jammed some non-standard extension into their HTML, supported only by their personal favourite browser. From another (and kindlier) perspective, one could perhaps just say that the HTML 3.0 specification was too big and ambitious. HTML 3.2 is thus much smaller than 3.0 and is furthermore largely a result of "reverse engineering" of existing extensions (though adapting these for coherence among browsers and compliance with the SGML foundation of HTML where this was violated). Most of HTML 3.2 is therefore already now supported by the newest browsers - including the Atari CAB - AND there is also validation software (for PCs at least) and services available to certify HTML 3.2 compliance of documents. Non-ascii characters in HTML ---------------------------- Last month I said that the British pound sterling symbol (£) could be represented as £ in HTML. It seems however that this isn't strictly in the HTML specification (neither 2.0 nor 3.2) though it is RECOMMENDED in the HTML 2.0 document. In practice it seems that at least the browsers I have tried DO understand £ Generally, a character can in HTML (and SGML) be expressed in one of THREE ways: ∙ directly as a character (byte) e.g. £ ∙ as a "numeric reference" e.g. £ ∙ as an "entity reference" e.g. £ Since the CHARACTER "£" IS in the HTML character set - at code position 163 - the first two methods should always work. I.e. £ will unambiguously be interpreted as a pound symbol by ANY truly HTML- compliant browser on any platform, and so will the character with number 163 (that appears as "ú" in the Atari character set, so Atari browsers need to translate it before display). The third method however formally requires that the "entity" be defined in the so-called DTD for HTML (DTD = Document Type Definition - an SGML term for what essentially constitutes the definition of the HTML language, or at least a significant part of it). And "pound" isn't (yet?). The same thing applies for most other "extended" (non-ascii) characters (including overline " ") EXCEPT the modified LETTERS, all of which have entities defined for them ("Mårten" is in strict conformance with HTML :-)). Of course the most compact and perhaps simplest method is to use direct characters - remembering to use the "ANSI" (aka ISO 8859-1 aka Latin-1) character set. The major reason not to do that is if one fears that 8-bit characters might be corrupted during electronic transmission. This isn't a problem if documents are distributed by disk of course, but it is also not a problem if the document is placed on a typical WWW site using the HTTP protocol, since this protocol preserves 8-bit characters. Other protocols can cause problems though, and conversions by local networks between different character sets might possibly also corrupt 8-bit characters. To: Kevin Cooper From Mårten Lindström ATARI STANDARDS FOR DATA FORMATS ================================ The only data types for which there is any standard - AS DEFINED BY BUILT-IN TOS SUPPORT - are, I'm afraid, pictures. Apart from bitmap images, supported via VDI call vr_trnfm (and then the other raster functions) as well as - on printers and memory devices only - v_bit_image, TOS can, of course, handle VECTOR images supplied as GEM metafiles (.GEM) files - i.e. a series of recorded VDI commands, to be replayed on screen or printer. There actually isn't any one function that simply can take a .GEM file as input and play it. (Maybe such a function would be a useful project for a DLL?) Instead each VDI command of the .GEM file has to be interpreted and played individually. For text, the only real standard is plain "ascii" text - without formatting controls. There is no built-in TOS support neither for any richer text format nor for a spreadsheet or database format. When exchanging data via the clipboard or - with MultiTOS or compatible - the drag-and-drop protocol, the exporting application generally has to offer the same data in a variety of formats for the importer to choose from. In the case of text, a plain text file should definitely be one of the offered formats, but for richer text .1WP (1st Word Plus), RTF (Rich Text Format) and nowadays perhaps most important .HTM(L) would be among the most widely supported alternatives. When creating "DLL" import functions, on the other hand, each function could of course be defined to convert only to one, especially useful, format. (Again, possibly HTML for text (?)). One useful project would, I think, be routines that try to translate between .GEM metafiles and PostScript. I have personally not seen the specifications for PostScript and I am too mean to buy a book. Maybe someone would write an article on PostScript? To: Pete Bailey From: Mårten Lindström I don't know the answer to your main question, as to what method would be best to change the Atari drop-down menus into pull-down menus. I have got something called ST Control (which I haven't used much) and which came with a utility that I think did just that - and working fine on my ST as I recall it. So I guess it SHOULD be possible somehow (maybe I shall have a look at that program again). Your desperation is an echo of mine when I was trying to coerce TOS into changing the system font (the result of which was my PC_LINES program, published in an earlier Ictari). This change too has a tendency to be inexplicably reset. I guess this is almost inevitable with any such type of "unforeseen" system configuration, unsupported by solid high-level functions and requiring semi-clean means. As to some of your secondary questions: Q: Is XBRA worth losing sleep over? A: XBRA probably won't provide any help in this. As long as all programs adhere to it, it makes it possible to simply and cleanly uninstall vectors as well as to detect all of the previously installed programs. But when TOS (at least all the older versions) install vectors it will probably disregard XBRA completely. Q: Does Katherine Peel mean that interrupts should be disabled during installation only or for the full duration of the new vector? A: Definitely during the installation only. If you leave interrupts disabled almost nothing will work - including the keyboard and certainly the GEM mouse. To: Peter Hibbs STYLE OF ASSEMBLY LISTINGS ========================== Oh dear, and I have always thought that my way of writing was the most readable that could possibly ever be :-). It goes to show that taste is a very personal thing. Or as we like to put it here in Sweden: Smaken är som baken - delad. ( In English: Taste is like the behind - divided. ) (Sorry about this piece of poetry, but I couldn't resist it.) I am quite certain that my habit of writing register names in upper case did not originate in my own twisted mind, but I am less sure of from where I got it. The disassembled BIOS listing in the Abacus book "ST Internals" is written in the same style though. Back when, trembling and insecure, I wrote my first lines of assembly code I found some comfort in this way of marking register names as something quite different from mere memory labels etc. This was back when I was still confused that "a7" could also be written as "sp". Since then the habit has stuck, and I even often (as a kind of therapy while collecting my thoughts) convert imported pieces of code to this style, more familiar to me. I suppose you are right of course that it must slow down my typing, but I have never reflected much on that. Maybe it only slows down the speed of my typing to that of my thoughts. I feel a need to put some thought in just about every line of assembly code to ensure it's OK. It had honestly never occurred to me that anyone could find this style DETRIMENTAL to readability. Though - when thinking about it - it is only natural of course for everyone to prefer what one is most used to. So from now on I will start making sure that my assembly contributions conform with the predominant style of all lowercase. */ Mårten, I didn't mean to imply any criticism at all, as you say ones style of writing code is usually a matter of taste, I was merely interested in your reason for using caps. I also use capital letters for some parts of my code, i.e. assembler directives (MACRO, ENDM, IF, ENDIF, etc) and object names (FORM_LIST, etc) mainly so that they are easy to find when scanning through a listing. You mentioned the PostScript language, I have bought a book on this language with the same idea in mind but I soon found that it is unbelievably complicated and I didn't understand much of it at all. It is basically a language built into the file, for example, a PostScript font is not like a Calamus font which just defines a set of co- ordinates and simple commands, a PostScript font seems to be a mini source code that tells the PS interpreter how to process the font data to draw the character image. Any code you would need to write would have to be an interpreter (like a BASIC interpreter) with about as many commands and functions, no mean feat. If you would REALLY like to see the book I would be prepared to lend it to you provided you are willing to pay the postage charges to and from Sweden and it is quite a heavy book, over 700 pages. PDH /* ---------------------------------------------------------------------- To: All From: Peter Hibbs In Ictari issue 9 I published a set of TOS Macros (TOSMACRO.S) and it has just come to my notice that there is an error in the f_datime MACRO that reads the date/time stamp on a disk file. The code should be amended so that it reads as follows :- f_datime MACRO 1\mode,2\fhandle,3\buffer move \1,-(sp) move \2,-(sp) move.l \3,-(sp) gemdos #87,#10 ENDM I should point out that this was not entirely my fault, the source of my information was the Atari Internals book which incorrectly shows the second and third arguments reversed in the example code, hence my error. I then checked the Compute! book volume 3, The Atari TOS, which shows the arguments correctly but then states that the first word of the buffer holds the date and the second word holds the time when it is, in fact, the other way round. Next I looked at the Concise Programmers Guide by K Peel (Aug 86) which also shows the wrong buffer allocation and in addition has the flag settings reversed as well, i.e. it shows 0 for set and 1 for read which is the opposite of the correct values. The Atari Compendium, however, shows everything correctly although it does not give any help to machine code programmers. I think the moral of this sorry tale is DON'T BELIEVE ANYTHING YOU READ IN A BOOK UNTIL YOU HAVE CHECKED IT YOURSELF. ---------------------------------------------------------------------- To: ICTARI From: Theo Ros Is there anyone who can explain how picture dithering is performed. */ I think this question has been asked before and nobody knew then but if anyone does, write in soon. ICTARI /* ---------------------------------------------------------------------- To: Everyone From: Owen Rogers I'm afraid I've finally decided to hang up my mouse and move to the PC. I like my programs to be used, not sit around in a PD Library so I've bought MS Visual Basic for my PC. This is just a thank you to everyone at Ictari for helping me finally release my first GEM program MUSICBASE and really everyone I've talked to and who have helped me (Including LAPD, Floppyshop and those great people who sent me those STOS manuals). I don't think I've met such friendly and helpful people than in the Atari community. Thanks again to everyone I've known and met and especially to LAPD who were the only people who took a 13 year old boy (me!) from the Welsh valleys seriously about programming! If there is anyone out there who has one of my programs that needs registering, don't bother! So now in the words of Sooty I'll say.. BYE, BYE EVERYBODY BYE, BYE ------------------------------ End of file ---------------------------