Loading ...
Sorry, an error occurred while loading the content.
 

Altair Checksum Loader Bugs

Expand Messages
  • deramp5113
    If you experienced some frustrating moments in the past getting BASIC to load from paper tape (whether using a front panel bootloader or the Multi-Boot Loader
    Message 1 of 4 , Mar 22, 2013
      If you experienced some frustrating moments in the past getting BASIC to load from paper tape (whether using a front panel bootloader or the Multi-Boot Loader (MBL) ROM), the problems may have not been of your own doing!

      The version 4.0 checksum loader present on many paper tapes (8K BASIC 4.0, Extended BASIC 4.x, DBL 4.0, etc.) has a bug. Depending on your configuration, you may have inadvertently stumbled across this bug.

      In the 4.0 loader, sense switches A15-A12 specify the console terminal serial settings and switches A11-A8 set the tape serial port settings. When loading tape through the 2SIO port, A11-A8 should be set to 0000 for 2 stop bits or to 0001 for 1 stop bit. However, the checksum loader samples the TERMINAL switches to determine stop bits for the LOADER serial port.

      Here is the code initializing the loader serial port:

      mvi a,003H
      out 010H ;reset 1st ACIA on the 2SIO
      in 0FFH ;read front panel switches
      ani 010H ;get A12 alone (TERMINAL stop bits)
      rrc
      rrc
      adi 011H ;011h for 8N2, 015h for 8N1
      out 010H ;output to 1st ACIA on the 2SIO

      As posted previously, the MBL ROM simply ignores the stop bit switches and always selects two stop bits:

      mvi a,003H
      out 010H ;reset 1st ACIA on the 2SIO
      mvi a,011H ;011h gives 8N2
      out 010H ;output to 1st ACIA on the 2SIO

      So what about the version 3.2 loader used on the 4K BASIC V3.2 tape? This loader does nothing to change the 2SIO serial port -- it assumes the front panel bootloader has already set the serial port correctly. Not as flexible as the 4.0 loader (which could conceivably switch to a different load device after the initial bootload completes) but it works!
    • mfeberhard
      I saw this when I disassembled the loaders some years ago. (My disassebly of the 3.X and 4.X loaders are in the Files section.) I think this bug survived
      Message 2 of 4 , Mar 22, 2013
        I saw this when I disassembled the loaders some years ago. (My disassebly of the 3.X and 4.X loaders are in the Files section.) I think this bug survived because most people either loaded through the console (so the ports were the same) or had a parallel-port load device, such as an OP-80 reader. This bug would only be a problem if you loaded from the 2SIO serial port, but used some other port as your console - not too common a configuration.

        This is really easy to fix - the correct instruction sequence would be:

        IN SWTCHS
        ANI 01H ;SWITCH *A8* SPECIFIES STOP BITS
        RLC
        RLC ;PUT IN PLACE FOR SIO2WS1
        ADI SIO2DS1+SIO2WS3
        OUT SIO2C0

        (formatting mangled by HTML)

        This fix is nice because it is exactly the same length - so the three bytes that change could even be patched manually.

        You could easily fix this code, then create a new paper tape image with my MAKEALT utility.

        -Martin
      • Dan Roganti
        ... such as, a Teletype with a papertape option --the most common console of the day. The term bug being thrown around here is an outgrowth of the system
        Message 3 of 4 , Mar 22, 2013
          On Fri, Mar 22, 2013 at 5:58 PM, mfeberhard <eberhard@...> wrote:
           

          I saw this when I disassembled the loaders some years ago. (My disassebly of the 3.X and 4.X loaders are in the Files section.) I think this bug survived because most people either loaded through the console (so the ports were the same)


          such as, a Teletype with a papertape option --the most common console of the day.
          The term bug being thrown around here is an outgrowth of the system environment being used today and not then. You can always replicate the system environment back then by using a term program connected to your 2SIO and downloading, from within the Term program, the papertape *.bin files.

           
        • mfeberhard
          Well, it *is* a bug... MITS documentation says that switch A8 sets the laoader s stop bits for the 2SIO, but the code actually looks at switch A12 - which the
          Message 4 of 4 , Mar 22, 2013
            Well, it *is* a bug... MITS documentation says that switch A8 sets the laoader's stop bits for the 2SIO, but the code actually looks at switch A12 - which the documentation says should set the console stop bits.

            For example, If you used a MITS 88-VLCT terminal as your console (which connects to a parallel port) and you used a "MITS" 88-TTY teletype (with a paper tape reader) as your loader, then you would experience this bug - using all MITS hardware from the time of the Altair. And the Teletype loader would not work with the switches set according to the MITS documentation.

            -Martin

            --- In altaircomputerclub@yahoogroups.com, Dan Roganti <ragooman@...> wrote:
            >
            > On Fri, Mar 22, 2013 at 5:58 PM, mfeberhard <eberhard@...> wrote:
            >
            > > **
            > >
            > >
            > > I saw this when I disassembled the loaders some years ago. (My disassebly
            > > of the 3.X and 4.X loaders are in the Files section.) I think this bug
            > > survived because most people either loaded through the console (so the
            > > ports were the same)
            > >
            >
            > such as, a Teletype with a papertape option --the most common console of
            > the day.
            > The term bug being thrown around here is an outgrowth of the system
            > environment being used today and not then. You can always replicate the
            > system environment back then by using a term program connected to your 2SIO
            > and downloading, from within the Term program, the papertape *.bin files.
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.