___ ______ ___ _________ _________ ___ \__\ \ __\ \ \__ \______ \ \ _____\ \__\ ___ \ \ \ __\ _____\ \ \ \ ___ \ \ \ \ \ \ \ ____ \ \ \ \ \ \ \ \ \_____ \ \____ \ \__\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \__\ \_______\ \______\ \________\ \__\ \__\ * m a g a z i n e * -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- I C T A R I U S E R G R O U P -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hi there, welcome to Ictari Disk #5. First of all sorry this disk is late. The compilation phase has got a lot more difficult and time consuming now, but next month I will hopefully have a second working ST to help cut down time. Many people have expressed a preference for an alternative method of distribution. After some thought, and merging of ideas, I have come up with the following. First of all, members may continue as they are, i.e send 1 disk a month with return postage. However humans being humans tend to forget and thus several people have forgot from time to time or have been late, etc. Therefore you may either :- (a) send me loads of disks, which I will use to send you the diskzines, or (b) send me the money for me to purchase disks on your behalf. I have therefore come up with the credit system whereby 1 disk and return postage is equal to 1 credit. If you'd rather send money, then 1 credit costs 50p per DD disk, and 25p postage. You can also send combinations, e.g to purchase 10 credits you can do any of the following: Send me œ7.50 Send me œ5.00 + 10 stamps Send me 10 Disks and œ2.50 Send me 10 Disks and Ten Stamps Postage can be cut down to 20p if you rather have second class. Credits can also be used to receive PD from Ictari PD if it is required. Cheques should be made to Mr N.Bates. If I can get disks cheaper then the price will drop. Your money will be used to buy disks and if you decide not to continue subscribing to Ictari or wish for no more PD or should Ictari dissolve (I hope not), then you will receive any disks/ stamps owing to you. This is just an alternative option to those wishing to use it, if you prefer you can continue with the old system. You might be thinking, that if you were to buy 10 credits, what happens when you wish to make a contribution to ictari. Well I've thought that out as well. All you do is send the contribution to me on disk or leave it on Ictari BBS when it is running or write me a letter. If you send a disk then that disk will count as one credit extra to be added to your total and thus spent as you require. The idea is that not everybody will contribute to Ictari Diskzine every month, and therefore this way you don't have to send blank disks every month to receive it and feel guilty for not including a contribution. I expect most people will send two disks every two months and thus make a contribution every other month. What do you think of this idea? Going on to Ictari PD, send me 1 credit to receive the current full list of what's on offer or alternatively I might include a list on Disk 6. I will however add that the list is not very big, due to me losing half my PD collection after a virus attack. Anyway the idea is that the cost of the PD you want is some PD you've got that's not on the list - if you have any that is. I would also appreciate if you could or would write a description and setup requirements, etc. The questionnaires I have received back seem to support the ideas of Ictari PD, and Ictari BBS. Thanks everyone for their comments and opinions. I'm glad no one thinks I should be lined up and shot. Ictari Disk Magazine 6 released August 12th 1993. (It will not be late again) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Here is the new feature, that will be included next month. Here you can talk about whatever you like, and maybe you will receive replies - maybe not :-) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Thanks to all those who sent help to me detailing my database program problems. The problem appears to be a fault in my version of WERCS so I will attempt to get a new version. I tried using a @ for the TEXT string but this only allowed the user to type 1 character only. The other approach was to fill the string with junk and remove the unwanted junk in my program. Thanks Morf for the code on that. ------------------------------------------------------------------------- I have decided to fix my old Atari STFM computer, so that I will now have two computers, thus making producing Ictari a lot easier. I have been successful and only need a keyboard. Trantor has my spare keyboard so I'll shall get him to send it back to me. So hopefully next month Ictari will be produced a lot quicker. ------------------------------------------------------------------------- Ictari PD is now definitely official. See the enclosed documentation about it. Unfortunately I have not had the time to document all my PD YET!!!, but I hope to for next month. If anyone wants to add to the list by sending PD, with or without descriptions, hardware requirements, etc, to me, I would be pleased. If anyone wants any of the PD detailed, then just send a disk and return postage. ------------------------------------------------------------------------- I hope to purchase a modem very soon and therefore I shall very likely create Ictari BBS, which will only initially act as a method of leaving messages for me, or for reading messages etc. This is because I don't own a Hard Disk and therefore uploading, and downloading will be unavailable. Fortunately my 4 Megs of memory will allow me to set up a BBS without a Hard Drive. Also Ictari BBS will only be open at certain times. This is because I need my phone line for normal use as well. :-). ------------------------------------------------------------------------- Reply to Paul Winter on MONST It is possible to modify an executable by loading it as a binary file, modifying it and then saving it as a binary file. If you don't change the length of the file, then you can simply use the MONST registers M0 and M1 for the start and end of the file when you save as binary. Obviously, loading an executable as a binary file will not allow you to single-step through the program or indeed execute any part of it. It will also mean that you won't have access to the symbol table. This may not be exactly what Paul was looking for but it does work. The reason for all this is that when MonST loads an executable, it reads the GEM header of the file and sets up a basepage which then allows it to execute parts or all of the program. If you then wanted to save the program again, you would have to look at the text, data and BSS information when the Help key has been pressed then try and build an executable file to disk together with a GEM header at the start of the file. All this seems like too much hard work for me, so you'd be better just loading it as an executable and finding the bit you want to change, then re-loading it as a binary file and modifying it and then re-saving it as a binary file. Another reason for not trying to build an executable to save to disk as binary is relocatable code. If an executable is relocatable, there's a relocation table after the GEM header that has a list of addresses which need to be relocated. When such a program is executed, BDOS calculates an offset which depends on where in memory the program has been loaded and adds this to all the relocation words. Now if you load an executable into MonST, it will be relocated, thus modifying the program, so if you save this as a binary file hoping to be able to run it again, you're going to be disappointed. The above bit about relocation is mostly my guesswork and I'm sure there's loads of people out there who know exactly how it works, but that's my (vague) understanding of it. By the way, the only use of this I can think of is hacking other people's programs! If you had written it yourself you would have the source code and would be able to modify it then re-compile/re-assemble it. Also, the bit I said about the symbol table won't apply as the programmer will have stripped the symbol table from the executable if they had any sense (and a suitably equipped compiler). ------------------------------------------------------------------------- Does anyone have any information on writing CPXs? I think Atari's extensible control panel is extremely sexy and would like to write some CPXs for it. I have Lattice C 5.5 and this does have facilities for building CPXs but still refers to Atari documentation for event CPXs. How do you actually get hold of the official Atari documentation? Do you have to pay Atari a ridiculous amount of money to become an official developer? How much is it? Surely it would make sense to make the information freely available to ALL ST programmers by releasing it into the PD libraries. This should lead to more 'well behaved' applications being written and in general improve the quality of software available. Okay, so written documentation may be expensive for them to produce but I'm sure they could afford to upload it to a BBS. ------------------------------------------------------------------------- MultiTOS I have recently bought MultiTOS version 1.01 and on the whole was very impressed. However, when running on my TOS 1.02 1040STFM, it is quite easy to crash MultiTOS. When an alert box or other form is being displayed, such as 'Desktop info' simply click somewhere else on the screen and the system will crash with 11 bombs (Reserved vector error). I have worked out what is happening here. On TOS 1.02 when you click somewhere else on the screen while a dialog is being displayed, the system bell sounds. For some reason, this causes MultiTOS to crash, regardless of whether the bell has been set on or off from the Control Panel. An extremely small C program will replicate this crash under MultiTOS: /* ** **** Warning: *** ** This program will crash with 11 bombs under MultiTOS! */ #include void main(void) { putch(7); /* bell character */ } Could someone tell me if this also happens on newer versions of TOS as HiSoft recommend that you upgrade to at least TOS 1.4. I don't think I'll bother though as I mean to buy a Falcon eventually. ------------------------------------------------------------------------- I have a number of Atari related books, i.e. Abacus. Atari ST Internals. (Quite good, lots of errors and only covers basic aspects but is a useful reference). Abacus. Atari ST Tricks and Tips. (Not particularly good but might be useful for beginners, covers BASIC, C and Assembler). Abacus. ST Disk Drives : Inside and Out. (Fairly good, consists mainly of listing for various programs but does not really explain disk formats properly). Abacus. GEM on the Atari ST. (Very useful as a reference book for the GEM VDI and AES calls but very little explanations or examples, covers C and Assembler code). Compute Vol 1. The VDI. (very good but most examples in C with a few Assembler examples. Good explanations of most VDI calls). Compute Vol 2. The AES. As above Compute Vol 3. The TOS. As above. The Concise Atari ST 68000 programmers reference guide. (OK as a reference guide but has no explanations at all and is quite difficult to find required information). Sigma Press. Real-Time 3D graphics for the Atari ST. (Very good for explaining real-time vector graphics in Assembler but is very heavy going, definitely NOT for the beginner). Unfortunately none of the books above cover the low level details of the ST TOS, VDI, AES or hardware and so are not much use for advanced programmers. For example, it would be extremely useful to have information on other programming techniques such as Vector stealing, boot sector programs, digital sound sampling, data compression, etc, etc. The most useful source of detailed programming techniques that I know of is the Programmers Forum in the ST Applications magazine from the ST Club, Nottingham which is very good (I assume you do subscribe, if you don't I would recommend that you do so immediately). ------------------------------------------------------------------------- I would like to make some comments on your editorial file first. Marcus Platt wants information on the 68000 CPU and you mention writing a tutorial. I would recommend he buys a book on the processor, a tutorial on disk that is any good is going to require several megs of disk space and will still not be as good as a proper book. The book I use and can recommend is 68000 ASSEMBLY LANGUAGE PROGRAMMING by KANE,HAWKINS & LEVENTHAL from OSBORNE/McGRAW-HILL (ISBN 0-931988-62-4) although there are a number of similar books available. Another useful book, once you have learned the instruction set, is the 68000 REFERENCE GUIDE by WOOLCOCK & BURKITT from MELBOURNE HOUSE PUBLISHERS (ISBN 0-86161-166-7) which details each instruction operation with the flags that are changed, etc. Signetics and Motorola also publish a small pocket size reference book which is similar to the above if you can get hold of one. ------------------------------------------------------------------------- The Atari Developers Kit documentation was reviewed in Issue 16 of ST Applications by Jon Ellis (the ST Club may be able to supply a back issue) although I got the impression it was not worth the œ100 that Atari were charging. The Hitch-hikers Guide to the BIOS is also available from the ST Club on disk TXD*07 and details the BIOS function calls. ------------------------------------------------------------------------- You asked for comments on the disk magazine, well I have a few but these are my own personal thoughts on what I would like. You are at liberty to completely ignore them if you want (and I suspect you will). Firstly get yourself a good spelling checker or get someone else to proof read your final text files. The odd spelling mistake or 'typo' may be OK but when they run into hundreds it gets a bit irritating for some people. Secondly I would like your 'magazine' to concentrate on purely programming problems and solutions rather than a magazine of idle chat, jokes, etc. The are already plenty of 'diskzines' available which cover such topics (the ST Club PD catalogue advertises a whole page of them) but there are none which can be used by programmers to solve difficult software problems. This does depend, of course, on getting the programmers with the expertise to co- operate by providing solutions. There are hundreds of PD programs around which usually contain the authors name and address, perhaps you could contact them to see what sort of response you get, after all it could be to their advantage to subscribe as well. Thirdly the method of distributing the magazine seems to me to be a bit fraught. Presumably each subscriber has to send you a disk each month which you then return with the data on it. I suspect that people, human nature being what it is, will eventually forget or never get round to sending a disk. I would think that a more reliable method would be for each subscriber to send you sufficient money to cover the cost of disk, envelope and postage for say 6 months and you just send them out each month. If the disk content was good enough and provided useful information I would be quite happy to do this. Anyway it's just a thought. Another service your group could usefully perform is for members with special hardware set-ups to declare what they have and for them to try programs for other users. For example, I have written a program which should work on a large screen (such as Overscan or Reflex) or on the Falcon but as I don't have any of these systems, I cannot try it properly. I would like to be able to send the program to a member who has such a system who could try it out and report back with any problems. He would be able to keep the copy of the program as compensation for his time. ------------------------------------------------------------------------- Ok, first of all, I will now use a spell checker on all the documentation produced for Ictari UG. There happy now. :-). Secondly, Ictari UG is solely for serious programming and midi. Although I will include the odd humour, etc - but only space permitting. Priority will always go to the serious stuff. As to your idea of contacting PD authors, I like it and will do so in the near future. As to your comments about distribution of Ictari Diskzine, I can only but agree, and as a result I have come up with the CREDIT system, details of which are on this disk. Finally you talk about what one of my initial main aims of Ictari was, where members can use other members system setups, to test their programs on all different hardware, eg Tos versions, ST/STE/Mega/Falcon, Colour/Mono, etc. Part of the idea of the Profiles section is to find out about members setups. I also placed a questionnaire on Disk #4 to collect all this information, in order to find out who is good at what language, etc. ------------------------------------------------------------------------- There are a number of machine code programming problems that I would like answered if any of your members can supply the information (preferably in the form of a stand alone sub-routine). (1) How to re-position the mouse pointer to any pre-defined point on the screen, i.e. supply a sub-routine with the x any y co-ordinates of the screen position and the routine moves the mouse pointer to that position. (2) How to replay sound samples generated by the Sample Master Plus cartridge. This unit generates .AVR files but the manual only gives the file header format without any code to enable the programmer to replay the sampled sound. What is needed is a sub- routine which is passed the start address of the sound sample (in register A0 say) and then the sound is replayed in interrupts in the background. Ian Hancock seems to be an expert in this field, perhaps he could help. ------------------------------------------------------------------------- It would also be interesting to know how many 'subscribers' you have at present and what their interests are, i.e. Basic, Assembler, C, STOS, etc. ------------------------------------------------------------------------- I am currently collecting this information from the questionnaire on disk #4 ------------------------------------------------------------------------- In answer to your questions, I tend to exclusively program utilities and small applications. I can always find a way to solve someone else's problems but am incapable of programming anything purely for my own use! I will send you some stuff as soon as I can figure out a way of dumping library routines and macros into the source for you. I would primarily like to get knowledge out of (and into) ICTARI and am pleased to see some source routines in there. I would like to see the start of a group project, with each interested member picking out facets that they might be able to code and then explaining their routine in the next mag. That would require you to take the role of steering committee (?) though, not to mention finding a suitable project that hasn't already been thoroughly done. Failing that, I wouldn't mind trying to set up a suite of small utility routines for group use only. On a different note - the gem tutorial was missing part of one file, I have enclosed the whole lot, in case you haven't got any of them. ------------------------------------------------------------------------- Group project is an excellent idea. I would like to see an Ictari Doc Displayer, that uses a built in compression, so disk space can be saved. This is being worked on by me but I have given up on C programming UNTIL I have obtained LATTICE C v5. I suppose I could attempt it in 68k, but GEM and 68k don't mix very well in my opinion. Anyone have any ideas for a group Ictari Project ?. What part of the GEM tutorial was missing, is there any more missing?. I lost the copy you sent me. ------------------------------------------------------------------------- The Gemdos manual in disk #3, while very useful to a lot of people, does contain some errors. On the Section on Executable files, the three longs in the header are actually two longs and a word, making the text segment start at $1c from the start of the file. Also, since GEMDOS Ver 0.15, the last two reserved's are no longer reserved. The long at $16 is now called PRGFLAGS and the one at $1a (word length) is called ABSFLAG. I have enclosed my own file called EXEC_STR.TXT to try to summarise the current structure of executable files. There was a bit somewhere about deleting part of a file without copying the file to another. The only other way I know is to edit the FAT table directly. I've included DISK_STR.TXT for those who wish to pursue this. Bear in mind the different sized FAT entries on floppies and hard disks. Since you seem to have various people exploring text viewers and C linking, I will leave that to them. I now have the developers info books - interesting in places! What I now would like is the bits not in: How do *.SYS (GDOS drivers) work? What extra functions are in MULTITOS and how do you know it's loaded? ------------------------------------------------------------------------- To Paul Winter : - Run MonST from Desktop, not from GenST or Devpac.prg(Devpac 3) or auto folder. According to manual this is only way to save binary file. Alternatively, I have included BED(Binary Editor)which may be of some use to you or others. ------------------------------------------------------------------------- To Arthur Wadolkowski : - Load file into any editor(i.e. Tempus/Protext etc), mark start of block and end of block to be deleted and delete! I have included on this disk Deskicon which may help you with your icon problem. ------------------------------------------------------------------------- To Marcus Platt :- Regarding STOS Extension 'TOME' According to ST Format STOS Tome is/was available from : SHADOW Software, 1 Lower Moor, Whiddon Valley,Barnstaple,N.Devon. EX32 8NW. Price - œ18.95 This extension is supposed to be able to allow you to create backgrounds with tiles and by using it's own built in commands and some screen copy commands,you can have fast smooth scrolling backgrounds as well as many other features(unspecified in ST Format). Whether this is still available or not, I don't know. ------------------------------------------------------------------------- On this disk I have also included GFASOUND which I obtained through a PD library (minus GFABASRO.PRG - as I didn't have enough room since I didn't compress it) -- this may be useful to any GFA programmers. ------------------------------------------------------------------------- GFASOUND is available from Ictari PD ------------------------------------------------------------------------- Maybe others have already let you know, but just in case , ASTRA on Ictari #4 was corrupted on extracting. ------------------------------------------------------------------------- My copy was ok, anyone else experience problems? ------------------------------------------------------------------------- Last but not least - regarding DOCCY.S, the problem may be with the macros you are using since some of these require other macros from the Budgie library used in conjunction with them - as a beginner in 68k , I'm not really sure but it may help. ------------------------------------------------------------------------ Does anyone know how to use the STE's BLITTER chip for sprite manipulation ? Any source code would be much appreciated :) ------------------------------------------------------------------------- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- E N D O F S E C T I O N -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-