232 Hale Road WIDNES Cheshire WA8 8QA Dear ACC Members, 22/6/91 Firstly, let me get the "let's pat ourselves on the back" session over with. The fact that you're reading this letter alone means that you've chosen to subscribe to the ACC discs. This is probably one of the wisest de- cisions you have made (the wisest of course being purchasing an Amiga!). In particular, if you're an assembler coder, you've made a very wise decision. All in all, well done to Mark, Mike Cross, Steve Marshall and all other ACC disc contributors for creating a truly gourmet disc. Check out some of the opposition and see what I mean... Now some messages. Raistlin, old chap, how are you? Wondering why I typed the DOCs the hard way (a question that you asked a little while back)? The following reasons should be enough: 1) Since they're all my own work, there should be no hassles about copyright. Very important for a PD disc magazine! If I write a DOC file, using all my own words, and attach the message "Please spread far and wide, it's Public Domain" to it, no problems should arise. 2) I enjoy doing it. So there. 3) Some of the information sources being used by coders do not conform to the standards that they should do. Abacus Books, for example, seem incapable of removing typograph- ical errors from their publications (try saying that out loud after a few whiskies!), and other sources use vague and imprecise language. For example, the choice of lan- guage in the Amiga ROM Kernel Manual leaves a lot to be desired in terms of conciseness and precision, particul- arly the Interrupts chapter, where their terminology for exceptions and traps is in conflict with Motorola's own. See "typed_interrupts.doc" for my personal gripe about this. Satisfied, old bean? good. Oh, and should you want the include files I've created as well, contact Mark at the usual address or myself at the above address, sending a blank disc and a S.A.E. for return postage. And as Mark has already mentioned, be sure you've got a spare six months set aside to read them all... Now, a message for Mike Cross. Having seen the competition questions, I am relieved to find someone of like mind concering two individuals who num- ber stealing parked cars and abducting lamp posts among their hobbies. I am advising all who contact me to avoid these individuals in much the same way as one tries to avoid tetanus. Apart from our common contempt for such, I am grateful for the information about such matters as scrolling using the blit- ter. Continue the good work! And there's more. Neil Johnston, please get in touch. You requested a blitter DOC. Two courses of action are open to you. You can either obtain the now infamous typed_hardware.doc file form Mark or myself, provided that you're prepared to wade through a 207K file for the information (which inc- ludes example source code routines and associated custom data structures), or you can write to me direct and ask for a custom-written, simplified version that suits you. This might take a bit of time, but if you ask for such a file it will be provided. Send a blank disc in either case, and await the results. Now a bug report for Mark (and anyone else using the exec_support.i file I sent off). The DeletePort() function will HANG THE MACHINE if the ar- gument to the function is a pointer to an IORequest which has NOT BEEN SENT. I cannot yet find a truly flawless way of determining if an IORequest has ever been used, and hence only call WaitIO() if a pending IORequest still exists. So, during debugging, comment out the call to WaitIO() if you do not post an IORequest to the system during a trace (within MonAm, for example), to prevent the system hanging. Oh, and to answer Mark's query about using a converted version of exec_support.i (using the GenAm includes instead of my own mutilated ones), why not supply both? It's only a short file anyway. If anyone wants a particular version, then they've got both. As usual, feel free to manipulate any which way turns you on (the same goes for all other users of these files!) and if you create any enhancements for this and other inc- lude files, send them to me for update purposes. On the subject of bug reports/updates/enhancements, I have but one plea. PLEASE SPRINKLE LIBERALLY WITH INFORMATIVE COMMENTS! In particular, the code supplied by Raistlin causes me to wince with despair at the sparsity of informative comments explaining the purpose of various code segments. Trying to debug stuff like this if it doesn't work is a pain in places whose exist- ence has yet to be confirmed by medical science. Apart from that, I like to know HOW a program works after seeing it in action, and the lack of comments is a big hurdle to overcome in doing this. Yes, it IS boring when one is ven- ting forth one's spleen, but it's in a good cause, as I found out when look- ing at the 68000 helper code. Raistlin/Hearwig take note, there's a bug lying in your code, and it's bloody hard to find. I've sent along a quick fix to ACC with this letter, but I'm not ecstatically happy with my fix. Take a look at the revised source for more info. Now, some ACC regulars may wonder where I've been hibernating for the past few weeks. Well, I've been wrestling with the problems involved in gene- rating objects in 3D and then blasting them onto the screen in (almost) real- time, the sort of thing that the creators of Elite have done. Basically, I'd had an argument with a friend of mine about how it was done, so after he laid down a challenge to the effect of "O.K., smart arse, let's see you do it then if it's so easy" and I (foolishly) accepted it, I spent the next few days at the Amy creating what ended up as a 100K source file. Now the details of defining an object didn't turn out to be too bad. Also, working out how to transform all of the object's coordinates from the definition frame of reference to the display frame of reference (involving rotating about three axes etc) didn't turn out to be that bad. Drawing each of the objects that I defined in wire-frame mode wasn't too hard either. No, what caused the REAL headaches was the fill algorithm. At first, I thought, "use the blitter". This sounded sensible when I first thought it, but I was soon to realise that this was not so. For a more detailed explanation see my DOC file entitled "Fill Algorithms" elsewhere on the disc. Abandoning the blitter and doing the fill the hard way caused me two huge problems. One, rewriting the entire program. This was because I'd deci- ded to be clever and use the 68000 level 3 interrupt to handle all blitter operations. Abandoning the blitter for fills meant abandoning the entire in- terrupt structure that I'd slaved over for three weeks. I HATE it when this kind of thing happens but such is life... Two, working out HOW to perform the fill. Well, it turns out that I've solved the problem of how to do the fill and create solid objects. Now I'm moving on to the vexed problems of clipping algorithms (more about those some other time) so that I can have part of an object on screen when I move it off the edge of the screen. When all of this is finished, and I have a nice collection of spaceships to display, I'll send the source (and the executable object code too-that way anyone who's interes- ted can see it in action without having to piddle about assembling the source first, then see the source in detail later). Right. Next item, fractals. Not another hard topic, I hear everyone groaning even as I write this. Well, I've written a DOC file on the subject of creating fractals on the Amiga. It doesn't cover ALL possible fractals, it restricts itself to those fractals that can be generated using math functions such as add and multiply (no partial differential equations or any other Ph.D type material). This file has been the subject of a rewrite thanks to contact with one Laurence Vanhelsuwe, a programmer from Belgium I worked with in 1987 and who lists Rockford and Gargantuan among his credits. If you are reading this, Laurence, thanks for the tips. Those who have spent three months wading through my typed_hardware.doc file will notice him being credited with a neat blitter usage trick too. He is now working for Commodore-Amiga itself on an Amiga 3000 with all manner of bells and whistles on it, and if I placate his whims in a suitable manner (freshly minted tenners usually do the trick) he drops me the latest insider gossip & various snippets of interest to the out- side world. So, there's something for all from my humble half-meg Amy this month (Yes, I'm still waiting for an expansion!). Speaking of memory expansions, I am planning (when the money's forthcoming) to bolt one of those Cortex boxes onto the side of my Amy, the ones that allow up to 8 megs of RAM to be added to the machine. And what does one do with 8 megs of RAM? Well, I had a loan of one for a week, and believe me, I'm HOOKED. This is SERIOUS memory! Gee, the fun that can be had running DevPac with 1 meg of editor space at the same time as DPaint III and PowerWindows, AND have a test program with a 640x256 HAM screen on at the same time! There's even room for MED V3.0 to fit into a corner while all this is going on! And it's really hilarious calling up Work- Bench with "8078160 free memory" on the title screen! How sad I was when the dread day came to hand it back to its rightful owner. Sigh. For those who are interested in buying one of these boxes, Cortex advertise the unit in Amiga Format under the slogan "A Brain ... The Next Best Thing" complete with pic- tures of a removed brain and a Cortex box (about par for the course for ad- vertising agencies in my experience) and it costs from £250 upwards (minimum configuration 2 megs, maximum memory a delicious 8 megs!). It's possible to buy the 2 meg box & plug in your own RAM chips if you can get the chips any cheaper, but I'd read the warranty before trying it. Oh, by the way. Compatibility problems have arisen across the Amiga family now that the A3000 has joined the stable. Reading the spec sheets and seeing things like a 25MHz 68030 and 68882 coprocessor as standard, 4 megs of RAM and 40MB hard disc as the SMALLEST hard disc add-on usually causes one to fantasise wildly about owning such a beast. Well, I've been informed that one or two programs that run on A500/1000/1500/2000 machines crash the A3000. And to make matters worse, some of those that crash the A3000 are those that are the best-behaved on the other machines, always doing things according to the Commodore diktat and using the operating system for everything. How strange! What makes this even sadder is that the staff at Commodore-Amiga Technical Section, West Chester, Pennysylvania, don't know why this happens. Oops!!! I can already hear the sarcastic laughter of ST'ites (funny how that sounds a lot like "Shi'ites" when said fast enough!) getting their revenge after hav- ing to listen to insults about their baby for years, so if any readers are unfortunate enough to have an ST-owning younger brother or girlfriend, KEEP THIS UNDER WRAPS! Now, I'd like to make the following observations about Unity. I hope that this group is NOT going to infringe copyrights, and I cite the following reasons: 1) Several individuals I have discussed copyright matters with recently have made it known that they are hiring a team of lawyers to deal with copyright infringement and piracy. I would not like to see PD outfits destroyed or seriously damaged because a few individuals began taking code from commercial sources without permission. 2) I am hoping in the near future to secure a post with a software house, and since I wish to make my living as a programmer, I do NOT want any of my work to become the subject of litigation. However, I do NOT wish to knock the idea altogether, merely request those who are interested to exercise caution. I for one would have been grateful if the kind of information that I've compiled in my DOC file series was available to me when I first bought my Amiga without my having to shell out over seventy pounds on books. So long as those interested confine themselves to spreading material labelled as spreadable, then all well and good. In fact, to get them off to some kind of start, I've a message for them:the typed_xxx.doc series of files from my DOC DISC is spreadable courtesy of yours truly, so get your fingers out and get copies off Mark for spreading!!! But seriously, I write a whole host of files for both PD and commercial reasons, and those files that I wish to see spread free and gratis always come with a message to that ef- fect. Also, on those occasions when I DO use other people's ideas (with their permission, of course), I always leave the appropriate credits where due. One final point about Unity, that someone could answer for me. Where ARE the female coders? I have yet to hear of ONE female coder! If you're out there, and you're a genuine female coder (as opposed to Count Zero in drag) then make your existence known! Especially if you know how to code polygon filling code in real time... Now a little bit of help for Leon. You really want to know just how many disc formats there are? The answer is simple:as many as you can come up with. I kid you not. I recently saw an advertisement for a company that takes files in one format and transfers them to another format. In the advertise- ment they quoted over 3,000 formats that they could handle! Now, it needs to be stressed that TWO disc formats exist on a single disc! First, there is the hardware disc format, as laid down by the hardware onto the disc surface. Games companies play with the hardware disc format to implement copy-protection schemes and increase the usable space on a disc. Second, there is the software disc format. Once a hardware disc for- mat (which determines whether, for example, MFM or GCR coding is used - see specialist texts on disc hardware for more information on this), then there often exists a software disc format. This is covered in a DOC file on my DOC DISC called DISCINFO.DOC (which also contains a tutorial on using Sectorama) for the Amiga, and details the standard software format (which consists bas- ically of what bytes are written to which tracks and sectors and in what or- der by the system when a disc is formatted). Again, ask Mark for a copy of this file. So, from the Amiga's standpoint, unless you start doing advanced tricks such as creating GCR discs (used by Macintosh computers and the new Mac emulator for the Amiga) or laying down new hardware formats to squeeze in some extra data for a game, then the hardware format you get is the one given to you by the Format command, and the software format likewise (unless you're in the business of creating PC and ST discs on an Amiga using Dos-2-Dos, for example). Now this software disc format includes the definition of the boot- block (see the file typed_bootblock.doc on my DOC DISC or get a copy from... you get the idea now!). And it is by examining the bootblock that the Amiga determines whether or not the disc is a valid AmigaDOS disc or not (the text "DOS." appears in the first four bytes if the disc is a DOS disc). A disc of type "NDOS" is probably formatted OK to start with, but has been corrupted in some way (DiskDoctor tries to repair such discs if possible, but be careful, the disc may be beyond resurrection) and has probably lost some vital inform- ation such as the disc bit map or the root block (in which case your disc is in deep s**t!!!). Oh, and if you have an Amiga 1000 with a KickStart disc, I urge you to examine the first four bytes of the KickStart disc. The text in the first four bytes of the bootblock should be "KICK". Anyway, I hope that that little lot helps. If you want to create your own disc formats, then feel free to experiment, but DON'T do it on important discs please, I will not be held responsible for any damage you do as a result! And now for Neil's latest request, a set of C tutorials. Before any other coders start thinking "Eh? C? Why?", then Neil has already stated very good reasons for wanting them. Books such as the ROM Kernel Manual are lit- tered with examples coded in C, and being able to understand them helps when producing the assembler version (this is how I generated the typed_xxx.doc stuff:I decoded the C source and coded some assembler versions! Well, I did a whole host of other things too, such as improving the disgusting Americanised grammar and making it more comprehensible, brag, brag...). So, just for Neil (and anyone else wanting to understand the source code examples in the RKM and allied publications) I'll provide a set of files to teach ACC coders how to decipher C programs. When they're on line, I'll be in touch with Mark and let him have the files as they come into being. Right, that's about it. I've got to go and get on with the C files & masses of other stuff now, so (you guessed it)... Live fast, code hard & die in a beautiful way, Dave Edwards.