Short: Fix for the two disk audio/gfx demonstration Type: demo/mega Author: Steve Borden Uploader: Kimmo.Ketolainen@nic.funet.fi Uploaded-to: nic.funet.fi (930502) From nin15b48@merrimack.edu Sat May 1 12:08:05 1993 From: nin15b48@merrimack.edu Newsgroups: alt.sys.amiga.demos Subject: ** Jesus On E's: FIXED!!! ** Date: 30 Apr 93 23:07:57 GMT JESUS ON E'S -- THE FIX!!! --------------------------- OK folks, here it is -- a patch to get LSD's notorious "Jesus On E's" demo working! If your copy crashes after running for about 30 seconds, this should do the trick. On the other hand, since the remaining twenty-eight minutes of the demo aren't much different from the first 30 seconds, you really haven't missed much. But anyway, you will probably want to see this for yourself, so here is the fix which I wrote. It is a uuencoded one-track DMS file which you should install on the demo boot disk. It SHOULD get the demo working (at least it did for me). For those of you who are interested, I've included a detailed explanation of why it doesn't work on some systems. The patch itself is after the explanation. WHY DOESN'T IT WORK?? --------------------- The reason that Jesus On E's (and a few other demos) fails is due to a small difference in clock speed between NTSC and PAL Amigas. The NTSC CPU clock runs at 7.15909 MHz, while the PAL clock runs at 7.09379 MHz. Thus, a single clock cycle lasts 139.68256 nanoseconds on NTSC machines and 140.96837 ns on PAL machines. Note that even when an NTSC Amiga is switched into PAL mode, THE CLOCK SPEED DOES NOT CHANGE! Only the refresh rate and resolution of the display changes. Normally this tiny difference in clock speed is not a problem. However, it CAN have an effect on the reading (or writing) of floppy disks. Here's why: First, all Amiga floppy drives, whether NTSC or PAL, spin the disk at the same rate: 300 rpm. Thus, a single revolution takes 0.2 seconds. MFM bits are read from or written to the disk at a rate of approximately 1 bit every 2 microseconds. Note the word "approximately". The actual bit rate is derived from the system clock and must consist of an integral number of clock cycles. A little math shows that 14 clock cycles is as close as we can get to exactly 2 microseconds: NTSC bit time: 139.68256 ns * 14 = 1.95556 us PAL bit time: 140.96837 ns * 14 = 1.97356 us Using these figures and the fact that one disk revolution takes 0.2 seconds, it is possible to calculate how much data will fit on a single track: NTSC: 0.2 s / 1.95556 us = 102272 bits = 12784 bytes = 6392 words PAL: 0.2 s / 1.97356 us = 101339 bits = 12667 bytes = 6333 words So a disk formatted on an NTSC drive can hold about 118 more MFM bytes or 59 more MFM words per track than a PAL disk. These extra bytes wind up in the "gap" area between the first and last sector on the track. Normally this is not a problem, except in the following situation: A "normal" (i.e. trackdisk.device readable) disk track consists of 11 sectors plus an unused gap area between the last and first sector. Since the rotational speed of a disk drive is not 100% accurate, the gap is there to prevent the last sector written from overwriting the first sector if the drive is rotating too fast. Each sector starts with a "sync" mark. To load a track, you allocate a buffer in memory to hold the track data and tell the disk DMA controller how many words you want to read. The number of words should be slightly greater than the actual number of words on the track to compensate for possible speed variations. The disk drive then waits for the first sync mark it finds and loads in the number of words requested. There are two basic possibilities of what will wind up in the data buffer, depending on which sector the drive syncs to first. If the drive happens to sync to sector 1, the buffer will look like this: S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 GAP (and part of S1) If the drive syncs to another sector, say sector 8, the buffer will look like this: S8 S9 S10 S11 GAP S1 S2 S3 S4 S5 S6 S7 (and part of S8) This is where Jesus On E's trackloader fails! It assumes that is loading >from a PAL disk, which contains fewer bytes per track than an NTSC disk, so it doesn't read a full NTSC track! If the drive is lucky enough to sync to sector 1 (and there's only about a 1/11 chance of that) the track will be read OK, since only unused GAP data will be missing. But if the drive syncs to any other sector, say sector 8, as in our example, it will stop reading data too early, and the last sector (S7 in our example) will be incomplete. Needless to say, this could cause a few problems. :] THE PATCH: --------- The patch modifies the Jesus On E's trackloader by increasing the number of words read per track so that it can read NTSC disks as well as PAL disks. There is one possible glitch in that it does not increase the size of the track data buffer as well, so if there is any data or code immediately after the track buffer it will be overwritten. (I couldn't verify whether this was happening because it wasn't intuitively obvious where the buffer was located, and I don't have the time to go hunting for it.) I guess the easiest way to find out if the patch works correctly is for someone with a true PAL machine to apply it and see if the demo runs any differently. All I can say is that I didn't see any problems...and I sat through the whole gruelling 28 minutes of it twice. (I also had a splitting headache afterwards!) Also note that if you try to restart the demo by pressing both mouse buttons, or if it restarts automatically at the end, the patch will be disabled. Good luck. Let me know how this works. .-------------------------------------------------------------------------. | == Steve Borden == E-mail: nin15b48@merrimack.edu | `-------------------------------------------------------------------------' =========================================================================== joepatch.dms section 1/1 UUXFER ver 2.0 by David M. Read BEGIN----------------------Cut Here-------------------------- begin 644 joepatch.dms M1$U3(0`````````!*^'V&0```````"-K```L`````````0````$````````` [...] M$F>'_(7\_2H?73W79M;S*/ZS;>EO-SKGW8_[I0V??^L$Y'2NOC-&]L:C^]/] ('=R"P#,@S&0? ` end END------------------------Cut Here--------------------------