Club Amiga de Montreal

home *** CD-ROM | disk | FTP | other *** search

/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 569a.lha / EdPlayer_v1.1 / EdP.history.README.pp / EdP.history.README

Wrap

Text File | 1991-11-07 | 13.0 KB | 216 lines

---------------------------------------------------------------------------- A History of changes to EdPlayer. All previous users, PLEASE read this file to see what's new!! ---------------------------------------------------------------------------- EdPlayer v1.1a: 11/03/91 Oops!! Version 1.1 broke EdPlayer's compatability with people using OS 1.3 with an overscanned screen. This version fixes that bug. Also this version allows the iconified window, which stretches to the left when printing long filenames in large fonts, to also stretch to the right if it can't go any further left. ---------------------------------------------------------------------------- EdPlayer v1.1: 10/25/91 This is just a minor update to 1.0. I kinda rushed it out, because some bugs needed fixing right away. Also some useful stuff added. * req.library added. If EdPlayer can't open kd_freq.library, it will look for req.library. I'm also thinking about the posibility of asl... * powerpacker.library added. If you were using PowerPatch for EdPlayer alone, you can remove it from your startup-sequence, as I suspect EdP will be much more effecient WITHOUT it. Also you can see neat messages like ...LOADING CRUNCHED... and ...DECRUNCHING... if you're NOT using the patch. A new AREXX command, "DCOL", allows setting of the decrunch effect. * New AREXX command "ERAS" allows erasing the program. * ARexx commands are no longer case-sensitive. I guess this is kind of a frill, but I like it better this way. NOTE: the "MIDL" command still NEEDS a case-sensitive parameter for midi_dest. * Can load PP encrypted (password protected) modules. Will bring up a password requester when needed. Also passwords can be entered via ARexx, see LOAD and JUKE in the DOCs for an explanation... * Iconified window now supports bigger fonts * Iconified window now has NAME of current song! Also scrollbar has a new trick that puts the song name there after a scroll. * PAL/Overscanned WB screens supported better. EdPlayer 1.0 used to open in the NTSC, no overscan position all the time. EdP 1.1 tries to center itself, and appear flush with the bottom. * FADE bug fixed.... NOT!!!! This is NOT a BUG! PLEASE read the DOCs in the BUTTONS section under FADE for a NEW & IMPROVED description of why EdPlayer fades the way it does!! The FADE code didn't change. * Slight bug in program mode made it impossible to enter songs with European characters in the names (like ü, ä, etc.). This is now fixed. Never do signed arithmetic on ASCII bytes... >127 looks neg :-) Hmm, now that I look at it, it doesn't seem like such a "minor" update after all... oh well... ---------------------------------------------------------------------------- WISH LIST: Before reporting a suggestion, please make sure it's not in the wish list. If it's not, then report it! The following is a wish list of features that MIGHT OR might NOT appear in a future version of EdPlayer: * I wish EdP supported ASL.library * I wish EdP could override the audio filter * I wish EdP had FastForward/Rewind buttons like IntuiTracker * I wish EdP had user-definable defaults for PAL/NTSC, FADE, etc. * I wish EdP had a random-play program mode. * I wish EdP could switch the VU meters for novice users 1234 ==> 1432 so that the left/right speakers go like: LRRL ==> LLRR * I wish EdP worked on ALL A3000s, AAAARGH!!! * I wish EdP could support MED song+samples format $*#&^*!!! And don't forget: * I wish EdP supported ProTracker and MED 3.20! (hint!!) ;-> !!!! ---------------------------------------------------------------------------- EdPlayer 1.0: Sometime in July 1991, I think. New features in EdPlayer 1.0: * All of them. Well what did you EXPECT??? duh! ---------------------------------------------------------------------------- Well that ends the useful part of this file. Now for the entertaining part. Only read on if you have some time and want to hear a good story... ============================================================================ THE HUNT FOR THE MEMORY MONSTER ============================================================================ The following is a true story of what happened to me as I tried to debug EdPlayer. Some scenes depicted may be insutable for inexperienced programmers or sensitive coders. Reader discretion is the recommended default configuration. * * * * There I was, sitting at home on my summer vacation, with nothing better to do in my life than work on EdPlayer. One of the things that prompted me to write EdPlayer in the first place was the total lack of any mod player that was RELIABLE and had ALL the features I wanted in ONE program (including ARexx). This is probably why I was turning red and looking around for a nice brick that would fit in my monitor. EdPlayer was not working. All the features I really hated -- the way IntuiTracker crashes during serial port activity, the way XTPlay fragments the memory beyond belief after playing an unknown number of modules -- ALL of these features were things I NEVER wanted to see in one of MY programs. They were some of the main reasons I was writing EdPlayer, after all! And yet, there they were. They were just sitting there in EdPlayer v0.8, fragmenting my CHIP RAM down to 2K blocks if I played the MegaBall high score tune, GURUing my machine if I used the modem, and really annoying me like no bug had annoyed before. But I had been CAREFUL!! I checked and double-checked all my allocations and de-allocations. So I loaded the thing into my debugger. The bug refused to happen in trace mode, so I tried running it with breakpoints in it. Still the bug didn't appear. So I just ran the thing with no breakpoints and no stopping... The bug appeared! "AHA! Now I've got you!!" I yelled at the hex dump on my screen. I rebooted (the bug forced me to do that... it kinda gurus!) I tried the breakpoints again without success. Then I tried it no stopping again. The bug was GONE! It wouldn't appear anymore! "It's FIXED!!!" my brother cheered, but I told him that I hadn't done ANYTHING, and the bug was STILL THERE. I demonstrated outside of the debugger. Yup, still there. A few days of letting the debugger tourture me just made things worse. Every now and then, the bug would appear briefly, and when I moved the debugger in for the kill, screaming "AHA! Now I've got you!!" at every chance, the bug would disappear like magic. Worse yet, the bug was making its appearences less and less frequently, as if it were "learning" how to avoid me. I know it sounds unreal, but it felt real enough... I couldn't look directly AT the bug. But maybe I could see its footprints in the system... I wrote down the GURU number and address, which turned out to be the SAME each time the bug struck. It was always an unaligned address error, at the same ROM location every time. Was EdPlayer misusing an OS function? Nope. The bug struck OTHER programs, and didn't even affect EdPlayer! "Maybe it's not EdPlayer's fault," my mom suggested. But by now I had stopped using the debugger, and from CLI, I was able to generate LOADs of bugs, rebooting after each one. I showed my mom the basic pattern: Open a shell. RUN EDPLAYER. Type "avail". See your free memory. LOAD a song into EdPlayer. Type avail, see memory. Press PLAY, and quickly type avail again. See avail's opening banner. See SOFTWARE FAILURE -- TASK HELD. EdPlayer continues to function, as if nothing were wrong. The gadgets work and all. EdPlayer 0.8 was a task masher! A few weeks of this got me really steamed. I had disassembled the area of ROM in question down to the bare bits. It turned out to be Exec's AvailMem() command, which was natural since "avail" was dying all the time. I don't know the legal technicalities of disassembling ROMs, but I figured since I wasn't giving it to anyone, it was OK. It turned out that as AvailMem() tried to compute the LARGEST free block of CHIP mem, it has to ride down a chain of MemChunks, and hits an unaligned chunk at 0xffffffff! But it GETS WORSE... I wrote a little prog to find the LARGEST CHIP block without using AvailMem(), by directly following the MemChunks and testing each one for odd addresses, printing them all out when it's done. (I'm _NOT_ distributing this program, as it looks a bit too similar to those ROMs...) Anyway, now I could issue "myavail" at a CLI and not worry about a GURU. Here comes the scary part folks! The Amiga's memory list is GLOBAL. That is, there is only ONE list for the ENTIRE machine. But I opened two shells and ran EdP 0.8 from one of them, and tried myavail in both shells, and then I saw it. I couldn't believe my eyes!! The myavail in EdPlayer's shell clearly showed the mangled, unaligned chunks. The myavail in the OTHER shell showed a perfectly clean memory list! I tried typing the command in both shells, over and over, in random order. I tried rebooting dozens of times. The results were the same: The GLOBAL memory list looked DIFFERENT depending on which dos process looked at it, with the same viewing program!!!! One list was destroyed, and the other was fine! But there's ONLY ONE LIST!!!!! #include <twilight_zone.music> The BUG had earned itself the nickname of "The Memory Monster." It was driving me nuts. I was going out of my mind. "Why don't you just release EdPlayer?" my brother asked. I looked at him, horrified. "Lots of module players do weird things with the CHIP ram," he explained. I was about to tell him what I thought of his comment, when suddenly I thought about his comment: "LOTS of module players"... HMMMMMM............ That was it. It was SO obvious. There was no bug in *MY* code! There was some kind of major flaw in the actual module-playing code that is used by LOTS of module players! "AHA! Now I've got you!!" Several more weeks went by as I heaped on more and more debugging and monitoring code to the player routines, mostly mt_init since the problem appears at the start of a song. By this time I was taking a summer math course at Lehigh, but luckily I had my Amiga with me so I didn't go insane (well, not completely insane, anyway). I had mt_init keep a table of memory writes. First in the table was the module's starting address, and next was the ending address (start+size). All the entries after that were places in memory that mt_init was writing, which I was hoping would be out-of-bounds at some point. I was hoping to do some REALLY slick code to keep mt_init from going out-of-bounds. But I was in for more torture: The table didn't seem to have any illegal entries!! So where was my Monster??? I had to put it aside for a few days. I just couldn't take it. I had been chasing this thing for so long, and at EVERY step of the way, the Monster seemed to learn new tricks and find new places to hide. Then, right in the middle of class one day, an idea poped into my head. It was a last chance, but I had a good feeling about it. After class, I came straight home. I approached the Amiga. #define SPEED (slow_motion) My hard drive whined as it gained speed and saw the size of my startup-seqence. I calmly waited for a chance to launch the debugger. #include <terminator_style.music> I looked again, much more closely, at the list of mt_init memory writes. In particular, I examined the last entry in the list. The last entry exactly MATCHED the module ending address. But the so-called ending address was computed with (start+size), a computation that produces the first memory location AFTER the real end of the module. There it was: mt_init was writing JUST past the end of the mod, in a very camouflaged way. I stood there, looking at my much-hunted foe for the first time. A slight grin flickered across my face. #include <hasta_la_vista_baby.8SVX> The Memory Monster never had a clue what hit it. It was dead before it could say "GURU." It was a quick and painless death, and when the smoke and dust had cleared, I was just a little bit disappointed. I had been hoping to do some really fancy code to kill the monster. Instead, all I got to do was allocate 4 more bytes of mem than the module size needed, to hold the extra memory write (which I assume is important for something, and therefore I should allocate mem to catch it). Well, I allocated 8 bytes just to be on the safe side, but it was still a bit of a let down. But what was I sad about? The Memory Monster, after months of torturing me, was finally dead at my feet. The memory fragmenting, the serial port crashes, ALL the weirdness disappeared. All of those "different" bugs were merely the many manifestations of the Memory Monster. It was all behind me now, all fixed. I felt pretty good. EdPlayer's version number was bumped up to 0.9, and after some finishing touches, it became 1.0 and got released. #include <standing_ovation.h> ============================================================================ EdPlayer v1.0 got me a whopping total of $30 in donations. yippie --Ed.