Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: <20222@cbmvax.commodore.com> Date: 1 Apr 91 06:29:11 GMT References: <23788@well.sf.ca.us> <23837@well.sf.ca.us> <781@tnc.UUCP> <20213@cbmvax.commodore.com> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 99 In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >See page VII-4 and VII-5 of AmigaMail, which shows the source code to >the "official" bootsector program. If the program OPENs dos.library, it >returns a ZERO in D0, if if fails, it returns -1. Not that I am arguing, >just telling you what your own documentation says. Except the trick is that if dos.library is opened successfully, the call never returns. The docs don't actually say it returns (though I can see how you'd assume that). >> Note that even 2.0 trackdisk is only about 7K long. > >I provide additional features that trackdisk doesn't, like the ability >to search for a disk in any drive. This function is NOT performed by >trackdisk, but by DOS. That wouldn't add more than a hundred or two bytes to trackdisk. Perhaps there are other features you have, though, that trackdisk doesn't, or things that trackdisk relies on the system to provide. >I actually use 12K or 14K. I decode the MFM a sector at a time when >needed. Are you sure that the using the blitter in NASTY mode isn't >faster than the CPU? I've been asking for ROM routines to do what 90% >of games do (without the OS). And one last point (I do know the OS :) >the OS (1.3) uses QBlit to encode/decode MFM. Not the fastest way, by >any means. Nasty should be of little or no benefit (unless you busy-wait for the blit to finish). You didn't test it? As for 1.3, yes it uses QBlit, but that allows it to sleep until the blit is finished (more cycles for other tasks or the blitter). 2.0 uses the CPU, which is faster than the blitter for decoding when the checksum is needed. It still uses the blitter for writes, and for re-reads of a sector to chip ram (rare). All initial reads of a sector and read to fastmem are done by the CPU. >> Unless your're pulling partial tracks off and using them before >>the revolution is complete, or unless you're going to write it out again, >>this makes no difference - and for writing all it saves you is a block-move >>to eliminate the gap. > >It DOES save a block move, which is not a particularly fast thing to do. >I hope that 2.0 pulls partial tracks off and uses them before the revolution >is complete! First, the block move is not needed on read (though 1.3 did it). It's only needed when preparing a track for writing, and it's a very small amount compared to the 200+ms you'll wait while the disk revolves. This is why a massive reduction in overhead produced little improvement in disk speed (some, just not immense amounts). The big win was direct transfer to fast- ram (for machines with fast-ram), since this allows fs buffers to be in fastmem. As for using sectors before a read completes, that's fine if you've taken over the machine and can have the processor watch the dma happen in a busy-loop, or have it pull the bytes off the disk itself (with interrupts disabled). That's not acceptable under multitasking. >There ARE cases where the allocation routines don't return (at least under >1.3). In too many cases, the OS throws up the ol' AG_NoMemory guru alert, >instead of waiting for some other process to free some memory and retrying. Yes, 1.3 is not very stable under ~4K free. 2.0 is annoyingly stable down to almost nothing (thanks to our developers and especially Bill Hawes, who wrote memoration and has an evil mind...) >> Good _games_, ones that have a depth beyond flashy graphics, and >>have replayability, do continue to sell (though they do best when first >>released, like most authored products). Sure, they do eventually trend >>towards 0, but by no means do they walk off a cliff for a good game >>(or even a well-done flashy game). > >Wrong. If a dealer has the luck to sell out every copy of a game that >he has after 3 months, he won't order more. He'd rather use the shelf >space for a new game. I guess those brand-new copies of Dungeon Master on the shelf at B. Daltons are an illusion, then. Ditto for Shadow of the Beast, Falcon, F/A 18, Red Storm Rising, etc. I believe that in Europe it may be like that (I wouldn't know) given higher piracy, but it doesn't appear so here in the US for _good_ games. Average or below games: sure. Lemmings will be on the shelves for a LONG time (and the Lemmings sequels/data disks I'm sure will be coming). >SetPatch didn't fix it. There is a program that comes with CrossDos called >TDPatch that might fix it though. We WERE in touch with CATS on this one. >At least you ADMIT there is such a bug. Just one of too many gotchas. Gladly, >2.0 will someday be available to EVERYONE and should have far fewer gotchas. Yes, I know Len Poma. The other thing tdpatch fixed was the RAWREAD/ RAWWRITE bug with single drives, where it would regect your request most often (cmp.l $8000,xx instead of cmp.l #$8000,xx). The random hang under heavy disk activity if there were empty drives WAS fixed by setpatch. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)