Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.hardware Subject: Re: NEW Commodore Upgrade for A1000 Owners! Message-ID: <21931@cbmvax.commodore.com> Date: 26 May 91 04:15:04 GMT References: <1991May07.224440.2764@ariel.unm.edu> <1991May8.012740.26800@cunixf.cc.columbia.edu> <1991May13.172116.1@wombat.newcastle.edu.au> <21865@cbmvax.commodore.com> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 74 In article mmm@reaper.Chi.IL.US (Michael Marvin Morrison) writes: >In article <21865@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> SA4d and SA4djr both will be functional in the next 2.0 release >>(their bug was kludged around as of beta 37.86 or so). > >I have a dumb question.. If the software doesn't run because of a bug in it, >then why is Commodore 'kludging' the ROMS? >if C= knows what the bug was then why not just report it to the company and >have them fix it. We do when possible. Some no longer are updating/supporting their products, some are out of business, some are busy with other projects, and some aren't interested in the hassle of upgrades (especially for games). Some, on the other hand, have even argued against us kludging a fix for their program (these tend to be companies with good update policies to begin with). >I simply can't imagine a company not willing to fix a piece of productivity >software because it doesn't run under the new OS, especially if the problem >was THEIR fault in the first place. Stretch and you'll manage it. Seriously, we looked at the work required to do the kludge, the risk (both of introducing a bug and in changing behavior causing someone else to break), and the number of people and programs that would be affected by the kludge. > Maybe if Commodore didn't have to >debug other peoples code, 2.0 would have been out by now. Again IMHO. And >again assuming that it wasn't a prob with 2.0. It wasn't a rom bug. And you're right, 2.0 would have been out sooner (we added several months of compatibility work at the very end) if we hadn't done this. Overall, it was probably a win, though a few of the high-return kludges (like Jumpy the Magic Timer Device) were rather mind-warping. During this phase we did do some important work, like greatly improving the handling of Midi baud rates by minimizing Disables and level 6 interrupts. Midi is very close to the best possible on the current hardware implementation now. Note that the kludges are all documented in a file, which we will use in examining whether they should be removed if they get in the way of future versions of the OS. We won't remove them just for the sake of it, but they may be removed. >Hopefully these kludges don't effect the speed of the new OS, as that should >not be comprmised. Most don't. A couple do, though usually in quite minor ways. > Actually, I am interested in knowing what some of these >people did. They must have been jumping directly into the ROMS at some point, >for disk access?, to snag some known code? The majority were things like depending on a register being preserved when they shouldn't (remember this, asm programmers!), using the wrong type of flag in a structure (like ACTIVEWINDOW vs. WINDOWACTIVATE, which is why many of the flags have been renamed for 2.0 to include a prefix), stealing bitplane pointer from workbench, grabbing timers without allocating them, and/or assuming the modes they're set up in, etc. The only ROM-jumpers that were fixed were those that jumped to the reset vector at the start of the ROM in order to reset the machine (you MUST go to ROM code, since ram disappears on RESET, and the address of the start of the ROM changed). >Sorry to come down like this, but it has been burning me for some time now. >What debugging tool does C= use to find out all of these goodies? 680x0 analyzers are our friends. (Plus enforcer/mungwall/billboards/ etc.) -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai