Conference hydra::amiga_v1

    Oh! forgot to mention that contray to what I always felt,the
    broadcasters tongue did not fall off when he sad the A___a word.
    
    							bill

    The 'location zero bug' has been the topic of much discussion.  As I
    understand it, some programs (incorrectly) assumed that location zero
    would always contain a value of zero.  It always had in the past.
    Commodore decided it was time to end this sloppy coding practice, so
    they purposefully stuffed a non-zero value there in the 1.3.2 update.

    While patching location zero to contain the value zero 'fixes' the
    problem without breaking anything else, it's really only masking the
    fact that the *program* employs improper code.  They've treated the
    symptom rather than the disease.

    re:.2
    
    According to the story on Usenet, what happened was CBM's debug version
    got shipped by mistake.  It poisons location zero as a way of trapping
    coding problems like bad pointers that would otherwise just lurk as
    a subtle bug.  Like the one referred to in .0.  I can't think of any
    good reason why a program should expect or need location zero to
    contain a specific value.
    
    It's kind of sad that they blame CBM for the problem.  It's a bug they
    should fix.
    
    -Dave

    re .2 I can see your point? But If the software(application program)
    is at fault then you would expect the problem to occure all the
    time. turbo Silver runs on the other vendors 030 products with no
    problem.Th earticle I read also stated that CBM had said that the
    problem was fixed,and should not occure in the future.I don't
    understand enough about programming to access this type of problem,
    but I thought I would post it just in case someone was suffering
    from it.But now that we are in the discussion what is the primary
    use of location zero. If it is not reserved for the operating system,
    and could be used by applications how should it initilize? Also is
    it good design to have hardware that writes to location zero for
    no apparent reason? Remember I don't have a good grasp of his location
    zero stuff but am very interested in what should be happening to
    it.
    								bill

    One of the most common programming errors is to use an uninitialized
    pointer to access some data. Usually uninitialized pointers have a
    value of 0 - hence they are pointing to location zero. 
    
    That is one reason why the VAX is setup to not allow access to page 0 -
    all these errors are trapped via the Memory Management Hardware.
    
    The way to avoid using a NULL pointer (C speak) is to test the value to
    see if it is NULL (usually = 0). This can be miss coded to look where
    the pointer is pointing and test that for a zero. If not zero use the
    value as a new pointer for the next operation. This is where
    applications are broken. They should be fixed.
    
    Any application that randomly changes memory is broken and on a system
    without MMU protection will cause other applications problems. 
    
    I don't know what the problem with the CBM's 030 product was (it
    contains a MMU - could it be protecting some portion of memory?).
    
    Usually the 680x0 systems use the locations at 0000 as the interrupt
    vectors - although these can be moved on the 020 and 030, not sure
    about the 000 and 010 cpus.
    
    John

    re: .4
    
    The hardware was *not* writing to location zero, the new version of
    software shipped with that hardware was.