Mark Meany, 12 Hinkler Road, Thornhill, Southampton, Hant's. SO2 6FT 29 July 92 Hi again, Let me start by apologising to Earthsoft for not including all the files associated with EarthMagic last month. As requested I heave put the required file on this disk in the correct directory! I have also squeezed Earthrexx on the disk, but this required moving the libs directory out of the EarthRexx directory. Hope this does not offend. To print out all the documentation, wait for a free weekend to crop up, boot your system as normal ( assuming Rexx is available on it and PPType is also available ), change directory from the CLI to 'acc26:earthrexx/docs' and then type 'rx print_docs'. To check this works I renamed ppmore as pptype on my hard drive, followed the above steps and then continually clicked on PPMores close gadget :-) The game I had been working on has ground to a halt. The reason for this is that I am unhappy with the limitations of the program. At present the game can load levels from disk, exits work now, but I feel the size of the play area is too restrictive and my approach to coding it requires too much memory. I am having a re-think. What I am hoping to come up with is a method of screen generation that will allow huge play areas without gobbling up too much memory. I am also looking a little closer at the hardware and how to use it. Many of the techniques I used in the game were new to me, so the program was something of an experiment. I can see a number of areas for improvement, but would rather spend the time searching for a better approach that working on a non-starter. If anyone is interested in seeing the final code and playable version of the game send a disk and sae. If there is enough interest I will finish it off, but I doubt that many people have got 1 meg CHIP ram at the moment. Remember the displayer utility from a few disks back. I have now added an option that will run the a68k editor, a project from way back in the early days of ACC. I have done some work on the editor as well, making it WB2.0 compatible and adding an extra directory to the include list so that the programmer does not have to have all files in the designated include directory. The net result is a tutorial displayer with integrated example displayer/executer and pop-up assembler. I have taken advantage of this utility and started building an assembly language manual for the Amiga that has loads of text files, loads of examples plus a means of experimenting with the source. The whole thing is gelled together by a menu similar to the ACC menu ( actually just a graphical variant ). At present the manual occupies four disks, two are systems specific and two are dedicated to hardware programming. The text files have all been written using Scribble, so the text is nice and tidy as well as having been spell checked. To allow the import of ASCII files written using text editors ( such as devpac or TXed ) I have written a couple of utilities. These only make minor changes to a file, such as expand TAB's into spaces since Scribble imports TAB's in an uncontrollable manner. Another utility strips line feeds from lines in a semi intelligent manner, the requirement was that source files would be unaffected by this utility as would paragraphs in an normal text file. Using these utilities, I can convert an old text file rapidly into a form that Scribble can display nice and flush without the need to go through and delete line feeds or space out areas that contain TAB's. More info on this adventure soon. I have supplied a couple of sources this month that take advantage of the new dos.library commands. I have yet to purchase the new libraries and devices manuals so no Intuition examples yet, besides I haven't finished with the older 1.3 version yet. I was recently sent a utility called Power Patcher. When run, this little beast patches the operating system so that PowerPacked data files are decrunched when loaded by ANY program. I have tried it out by assembling crunched source files that incbind raw data files that had also been crunched. No problems. Devpac took a little longer, but produced the desired executable. The problem is I was not sent any documentation with the program and do not know if it is PD, Shareware or whatever. The program is copyright Michael Berg, 1991. Can anyone supply me with more information? Just before I finished putting this disk together I decided to have a go at writing a PowerPacker patch myself. The idea was to replace the Open() LVO in graphics library so it pointed to a routine that would check the file being opened. If the caller had used MODE_OLDFILE and the file was crunched, the file would be loaded into memory, decrunched and saved on the ram: disk. A handle to the decrunched file in ram: would be returned. Well I have got a very crude patch running that does just this. I have tried loading crunched files into TXed, no problem. Devpac and many other programs must use Lock() when determining the size of a file being loaded which means a patch must also be written for Lock(). The result is that data is read from the decrunched file in ram:, but the number of characters loaded corresponds to the size of the original crunched file. Oh well, back to the drawing board. I have supplied the source for the patch for you to experiment with. A complete patch will probably have to track files Opened and Locked in a linked list, when an Examine() is attempted on a crunched file, the File Info Block of a decrunched version will be returned. By patching the Examine() function, but not ExNext() programs such as SID may still yield correct file lists. Anyone got any thoughts on how to proceed with this program. For an interesting method of designing a screen, see Axal's multi sprite example. Great little trick. A playfield could be used at the same time with all sprites given a lower priority ( ie behind the playfield ) which would result in the sprites creating the background. If bobs were then blitted into the playfield they would appear in front of the sprites. No need for background saves or correcting x,y positions to account for background scrolling. I like it! Is it not possible to use four sprites and so allow a background consisting of 16 colour blocks? While looking at your source Axal I noticed in your mapping example that the blitter loop ( rt_map_blitblock ) could be optimised simply by moving the following lines out of the loop. move.l #$09f00000,bltcon0(a5) normal blitter mode move.l #-1,bltafwm(a5) no masks move.w #0,bltamod(a5) no modulo for blocks move.w #38,bltdmod(a5) set screen modulo These values will not change while in the block blit loop, so there is no need to set them for every block. Just make sure they are set before blitting the first block. Martin McKenzie, in your HAM bob source you setup and display a screen without setting BPL1MOD or BPL2MOD. This is OK on 1.2 and 1.3 machines, but your screen is corrupt beyond recognition on a 2.0 Amiga. You must set these registers for your code to work on all machines. Dave Edwards, what happened to shipf.bmsk and shipr.bmsk? They were not on the disk you sent. Not to worry, I knocked a couple up from the relevant ship bitmap files. Also, check the author of the interleaved blitting file on disk 24:-) Well that's all from me for now. Back soon, Mark.