My *new* address : 71 Shearwater Drive, Langford Village, Bicester, Oxon. OX6 OYS. Hi Mark & All! Sorry this sending is rather(!) late but for various reasons I haven't done anything much in the way of coding since the first week of July. Things are fairly hazy but I remember moving sometime between now and then and I still haven't found any of my ROM Kernals... This months stuff is basically just revised versions of the PKDOS routines that I was working on last month. I am working on a game using the v0.33 routines so I am going to do no more work on these routines until thats out of the way. NB1: Last months code, as on the ACC disks, had a couple of VERY SERIOUS BUGS that may have nerved anyone using it: 1. Fast memory blocks could not be allocated (else crash) 2. The disk routines did not identify which drives were on the system- a typing error caused the code to think every drive on the system was attached, causing obvious problems as the code searched for disks on the system. In the source directory should be revised versions of both the pkdos general test file - just updated from last month - and a revised version of the slideshow code: This has a lower memory overhead, plays music, and loads and decodes IFF gfx from DOS disks using no system code... comments are used fairly liberally so it should be fairly easy to see how the code works & cut'n'paste various parts of it into your code. Note how easy it was to write given the amount of work handled by PKDOS! Other improvements include a now working bob mask calculator, and general tidying up of the code. If time allows I will throw all of the code and routines into one relocatible file with jumptable entries for all of the routines... this will result in a reduction in memory usage as similar routines are merged and the code is made more modular. It will also enable a final non-DOS version of the code to be assembled residing in low/high memory detecting & using all memory present with no other overheads :-) One thing missing at present is an AllocAbs() type funtion : this could prove useful in avoiding memory fragmentation - or how about routines that allocate from the top of a free memory section instead of the bottom ? The file makememlist.s contains code to build a valid memlist based on the exec memlists. NB If you use this make sure to 'allocate' where your code is residing! NB2: Much of the disk routine is by DEAN ASHTON, taken from DISKCODER. Thanks! You did a great job! As I am writing this letter I can't help looking left a bit to the other end of the desk and gazing at a '386 SVGA loadsa megs' PC, and wondering as to the future of the Amiga. The A500(+) is out of production and at the moment we are left with what is hopefully the entry level machine for a new range of Amigas. Implausible rumours abound at the moment in the 'non-serious' Amiga press: AFormat,AComputing etc. The only believable stuff I have read was in RAW issue 3 (a diskmag) that talks about an A600 (but we know the A600 now available was going to be called the A300 don't we?), an A2200 and AmigaStation. The A600 (renamed A800?) that is talked about has a 14Mhz processor and Commodores new 1.71MB drives. Both of these parts are already available and will cause only very limited compatibility problems - 14Mhz upgrades can be purchased over the counter (AdSpeed et al) and Commodore US has now catalogued the 1.71MB drives. If these rumours do solidify into real products I just hope that Commodore gets the pricing right - it has throttled sales (intentionally?) of the A3000 by pricing it too high: I can buy 2 of those aforementioned PC systems for 2.5 grand - not much more than one discounted A3000 with associated freebies - but which would you rather have? I also hope Commodore gets it right because the Amiga deserves to survive as being one of the last home computers, and one of the few platforms that is 'creative' + fun to use + to develop for! If you thought that the above was slightly apocalyptic, try reading this months 'Strategy Plus' editorial/essay : it basically forecasts THE END of the computer gaming industry, leaving only the dedicated console platforms behind... Yours sincerely, Paul Kent 30/7/92 ...one step closer... PS. Mark: I can't find the source to MapEd so I can't update it! Does your game use less than 512k CHIP yet? < Nope!! MM >