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

Re: [cosmacelf] Re: Arecibo Project

Expand Messages
  • Lee Hart
    ... Well, let s think about it. Suppose you built a display out of those 8x8 LED blocks that are sold for making moving message signs. Jameco #1955221 is 8x8,
    Message 1 of 19 , Apr 7, 2010
    • 0 Attachment
      aa3nm wrote:
      >> For example, have one Elf blink out the code on its Q LED, and
      >> another Elf receive it (with a phototransistor on a flag line) and
      >> display it?
      >
      > Great idea!
      >
      >> It's unfortunate that the 73-bit height is just a bit more than the
      >> 64-bit horizontal resolution of an 1861 display.
      >
      > True, That is a shame... or it may be an opportunity?

      Well, let's think about it. Suppose you built a display out of those 8x8
      LED blocks that are sold for making moving message signs. Jameco
      #1955221 is 8x8, 0.85" square, high efficiency red. You'd need 30 of
      them to make a 24x80 dot display, which is big enough for your Arecibo
      message. Drive them as a matrix to minimize the logic.

      Or, make a hardware implementation of the 1861 that you can program to
      output 10 bytes per scan line (8x10=80), so the image can be displayed
      horizontally with square pixels.

      Or, there are some nice graphic LCD panels that could display a 23 x 73
      pixel image nicely.
      --
      Lee A. Hart | Ring the bells that still can ring
      814 8th Ave N | Forget the perfect offering
      Sartell MN 56377 | There is a crack in everything
      leeahart earthlink.net | That's how the light gets in -- Leonard Cohen
    • aa3nm
      Yes, all those are possible... But if you are thinking of a receiver, remember there is no clock sent along with the data. That means the 0s have no
      Message 2 of 19 , Apr 8, 2010
      • 0 Attachment
        Yes, all those are possible... But if you are thinking of a receiver, remember there is no clock sent along with the data. That means the 0s have no transitions and there are quite a few of them. Timing would need to be rather tight unless differential encoding was added in the sending side.

        The easiest decoder might be to connect the Q to something a PC could sense and decode it on screen. That isn't my thing though.

        Another idea for improvement is squeezing some "air" out of the data and making the complete image fit into a quarter K. In the data format I chose there are 73 wasted bits... Squeeze them out and there is more room for data. 8 bytes down, 37 to go... That only leaves 36 Bytes for the code, could be tough.

        I'm interested to see if anyone else runs it on some other machine too.

        Enjoy,

        Steve


        --- In cosmacelf@yahoogroups.com, Lee Hart <leeahart@...> wrote:
        >
        > aa3nm wrote:
        > >> For example, have one Elf blink out the code on its Q LED, and
        > >> another Elf receive it (with a phototransistor on a flag line) and
        > >> display it?
        > >
        > > Great idea!
        > >
        > >> It's unfortunate that the 73-bit height is just a bit more than the
        > >> 64-bit horizontal resolution of an 1861 display.
        > >
        > > True, That is a shame... or it may be an opportunity?
        >
        > Well, let's think about it. Suppose you built a display out of those 8x8
        > LED blocks that are sold for making moving message signs. Jameco
        > #1955221 is 8x8, 0.85" square, high efficiency red. You'd need 30 of
        > them to make a 24x80 dot display, which is big enough for your Arecibo
        > message. Drive them as a matrix to minimize the logic.
        >
        > Or, make a hardware implementation of the 1861 that you can program to
        > output 10 bytes per scan line (8x10=80), so the image can be displayed
        > horizontally with square pixels.
        >
        > Or, there are some nice graphic LCD panels that could display a 23 x 73
        > pixel image nicely.
        > --
        > Lee A. Hart | Ring the bells that still can ring
        > 814 8th Ave N | Forget the perfect offering
        > Sartell MN 56377 | There is a crack in everything
        > leeahart earthlink.net | That's how the light gets in -- Leonard Cohen
        >
      • Lee Hart
        ... That s not difficult to deal with. If both Elfs are running with a crystal, the cumulative timing error even across many bits shouldn t be a problem. Or,
        Message 3 of 19 , Apr 8, 2010
        • 0 Attachment
          aa3nm wrote:
          > Yes, all those are possible... But if you are thinking of a
          > receiver, remember there is no clock sent along with the data.

          That's not difficult to deal with. If both Elfs are running with a
          crystal, the cumulative timing error even across many bits shouldn't be
          a problem.

          Or, send each 24-bit frame with a start and stop bit (standard
          asynchronous format).

          Or, change the encoding to a self-clocking code like pulse ratio, where
          a "1" is a long high and a short low; and a "0" is a short high and a
          long low.

          > Another idea for improvement is squeezing some "air" out of the data
          > and making the complete image fit into a quarter K. In the data
          > format I chose there are 73 wasted bits... Squeeze them out and
          > there is more room for data. 8 bytes down, 37 to go... That only
          > leaves 36 Bytes for the code, could be tough.

          You could Huffman pack the data. Basically, you create a list of
          numbers, which are the number of consecutive 1's or 0's before a change.
          For example, if the number was 100111000011111, you would send 1 2 3 4
          5. Each of these numbers is sent in binary, with extra bits between them
          to mark the end of each number (so small binary numbers can be sent with
          fewer bits).

          --
          Lee A. Hart | Ring the bells that still can ring
          814 8th Ave N | Forget the perfect offering
          Sartell MN 56377 | There is a crack in everything
          leeahart earthlink.net | That's how the light gets in -- Leonard Cohen
        • aa3nm
          This may be off topic enough, but it was just too coincidental not to post. Sorry if it s too far off. For the Hams in the group, I just received email about
          Message 4 of 19 , Apr 9, 2010
          • 0 Attachment
            This may be off topic enough, but it was just too coincidental not to post.

            Sorry if it's too far off.

            For the Hams in the group, I just received email about the Radio Club at Arecibo providing a Moon Bounce opportunity (EME on 432 Mhz) April 16, 17, & 18. A rare chance to do this mode with as little as 100 W and a 5 element antenna.

            For the non-Hams, (The timing is just too weird - I really didn't know about this when I started this thread) the largest antenna on the planet will be steered toward the moon and used by amateur radio operators to communicate with other hams by bouncing signals off the Moon. With the antenna gain being so large it will allow those who have never attempted this type of link to give it a shot. Lots of little "pea shooters" will be going after the biggest of the "Big Guns". If you have a friend who's a ham, or find local amateur radio club that may be involved it could be cool to drop in on.

            I don't think this has been done in the past few decades, if at all (but I could be wrong, someone will correct me if I am).

            I'll post a PDF of the announcement in the project folder, and I promise it was only a coincidence.

            73
            Steve
            aa3nm
          • Dennis Boone
            ... Here s my version, and coincidentally my first Elf/1802 program. Unlike the original, mine repeats ad nauseum. Got it down to 251 bytes. Quick, add a
            Message 5 of 19 , Apr 10, 2010
            • 0 Attachment
              > It seems possible to fit both the program and data into 256 bytes,
              > though it looks like you ran just a little over.

              Here's my version, and coincidentally my first Elf/1802 program. Unlike
              the original, mine repeats ad nauseum. Got it down to 251 bytes.
              Quick, add a feature! Assembled with rc/asm and tested in Mike's
              emulator; haven't fed it to my Elf2k hardware yet.

              De


              ; arecibo.asm, Boone, 04/10/10
              ; Blink the Arecibo M13 message on Elf's Q LED
              ;
              ; Modifications:
              ; 04/10/10 Boone Initial coding
              ; End Modifications

              ; Must run in page 0

              ORG 0

              ; Set up indexes and counters

              INIT:
              LDI 0
              PHI 6 ; R6 - count of bits left in cur byte
              PHI 7 ; R7 - X - Pointer into data bits
              LDI BITBLOCK & 00FFH
              PLO 7
              SEX 7

              ; Flash the LED a lot

              BYTELOOP:
              LDI 8 ; 8 bits per byte, usually
              PLO 6
              LDX ; Fetch the byte
              OUT 4 ; Display the byte
              PLO 5 ; R5 - scratch for byte in progress
              GLO 7
              BZ LASTWORD
              BR BITLOOP

              LASTWORD:
              DEC 6 ; ...but only 7 bits in last byte

              BITLOOP:
              GLO 5
              SHL ; Cut a bit out of the herd
              PLO 5
              BNF WAIT ; If it's not 0...
              SEQ ; ...turn on the LED

              WAIT:
              GHI 6 ; Handy spare 00

              SPIN:
              SMI 1 ; Waste some time
              BNZ SPIN
              REQ ; Turn off the LED
              DEC 6 ; 98 bottles of beer on the wall...
              GLO 6 ; We outta bits yet?
              BNZ BITLOOP
              GLO 7 ; How about bytes?
              BNZ BYTELOOP

              AGAIN:
              BR INIT ; Da capo...

              DONE:
              END INIT

              ; The data bits

              ORG 02EH ; Last data byte address is key

              BITBLOCK:
              DB 002H,0A8H,000H,050H,050H,012H,022H,025H,095H,055H,052H,040H,000H
              DB 000H,000H,001H,080H,000H,00DH,000H,000H,01AH,000H,000H,054H,000H
              DB 000H,0F8H,000H,000H,000H,006H,01CH,061H,088H,000H,032H,01AH,031H
              DB 086H,0BEH,0FBH,0EFH,080H,000H,000H,010H,000H,004H,000H,000H,000H
              DB 020H,000H,00FH,0C0H,001H,0F0H,000H,000H,018H,061H,0C6H,020H,020H
              DB 008H,068H,063H,09AH,0FBH,0EFH,0BEH,000H,000H,000H,040H,0C0H,010H
              DB 001H,080H,000H,083H,000H,03FH,006H,007H,0C0H,00CH,000H,010H,008H
              DB 004H,010H,030H,010H,018H,060H,040H,00CH,043H,000H,001H,098H,000H
              DB 031H,00CH,001H,086H,004H,004H,008H,004H,010H,018H,004H,040H,030H
              DB 008H,080H,020H,020H,080H,080H,080H,080H,006H,000H,0C0H,030H,004H
              DB 075H,080H,008H,008H,000H,010H,07CH,000H,021H,074H,0B6H,004H,0E4H
              DB 0FEH,0E1H,0C1H,0B8H,002H,083H,0B2H,005H,007H,0E4H,00AH,00CH,008H
              DB 036H,000H,000H,000H,000H,038H,020H,000H,075H,015H,054H,0E0H,00AH
              DB 0A0H,000H,014H,000H,00FH,080H,000H,07FH,0C0H,003H,080H,0E0H,00CH
              DB 000H,060H,034H,001H,060H,0CCH,006H,061H,014H,014H,042H,024H,048H
              DB 080H,045H,010H,000H,084H,020H,001H,000H,040H,000H,094H,000H,079H
              DB 0F4H,0F0H

              ; End
            • aa3nm
              Dennis, Very nicely done! I flipped some of the syntax around and succeeded in assemblying it under Pseudosam. I ve processed the .OBJ file as I discribed
              Message 6 of 19 , Apr 10, 2010
              • 0 Attachment
                Dennis,

                Very nicely done!

                I flipped some of the syntax around and succeeded in assemblying it under Pseudosam. I've processed the .OBJ file as I discribed under a topic related to Elftools and posted a .WAV file along with the other files in the project folder. I put your last initial at the head of the file names --> BArecebo.XXX

                The .wav file is in ELFII format and filtered (as discussed) so Elftools can re-ingest it.

                Again, nicely done!

                Steve

                --- In cosmacelf@yahoogroups.com, Dennis Boone <drb@...> wrote:
                >
                > > It seems possible to fit both the program and data into 256 bytes,
                > > though it looks like you ran just a little over.
                >
                > Here's my version, and coincidentally my first Elf/1802 program. Unlike
                > the original, mine repeats ad nauseum. Got it down to 251 bytes.
                > Quick, add a feature! Assembled with rc/asm and tested in Mike's
                > emulator; haven't fed it to my Elf2k hardware yet.
                >
                > De
                >
                >
                > ; arecibo.asm, Boone, 04/10/10
                > ; Blink the Arecibo M13 message on Elf's Q LED
                > ;
                > ; Modifications:
                > ; 04/10/10 Boone Initial coding
                > ; End Modifications
                >
                > ; Must run in page 0
                >
                > ORG 0
                >
                > ; Set up indexes and counters
                >
                > INIT:
                > LDI 0
                > PHI 6 ; R6 - count of bits left in cur byte
                > PHI 7 ; R7 - X - Pointer into data bits
                > LDI BITBLOCK & 00FFH
                > PLO 7
                > SEX 7
                >
                > ; Flash the LED a lot
                >
                > BYTELOOP:
                > LDI 8 ; 8 bits per byte, usually
                > PLO 6
                > LDX ; Fetch the byte
                > OUT 4 ; Display the byte
                > PLO 5 ; R5 - scratch for byte in progress
                > GLO 7
                > BZ LASTWORD
                > BR BITLOOP
                >
                > LASTWORD:
                > DEC 6 ; ...but only 7 bits in last byte
                >
                > BITLOOP:
                > GLO 5
                > SHL ; Cut a bit out of the herd
                > PLO 5
                > BNF WAIT ; If it's not 0...
                > SEQ ; ...turn on the LED
                >
                > WAIT:
                > GHI 6 ; Handy spare 00
                >
                > SPIN:
                > SMI 1 ; Waste some time
                > BNZ SPIN
                > REQ ; Turn off the LED
                > DEC 6 ; 98 bottles of beer on the wall...
                > GLO 6 ; We outta bits yet?
                > BNZ BITLOOP
                > GLO 7 ; How about bytes?
                > BNZ BYTELOOP
                >
                > AGAIN:
                > BR INIT ; Da capo...
                >
                > DONE:
                > END INIT
                >
                > ; The data bits
                >
                > ORG 02EH ; Last data byte address is key
                >
                > BITBLOCK:
                > DB 002H,0A8H,000H,050H,050H,012H,022H,025H,095H,055H,052H,040H,000H
                > DB 000H,000H,001H,080H,000H,00DH,000H,000H,01AH,000H,000H,054H,000H
                > DB 000H,0F8H,000H,000H,000H,006H,01CH,061H,088H,000H,032H,01AH,031H
                > DB 086H,0BEH,0FBH,0EFH,080H,000H,000H,010H,000H,004H,000H,000H,000H
                > DB 020H,000H,00FH,0C0H,001H,0F0H,000H,000H,018H,061H,0C6H,020H,020H
                > DB 008H,068H,063H,09AH,0FBH,0EFH,0BEH,000H,000H,000H,040H,0C0H,010H
                > DB 001H,080H,000H,083H,000H,03FH,006H,007H,0C0H,00CH,000H,010H,008H
                > DB 004H,010H,030H,010H,018H,060H,040H,00CH,043H,000H,001H,098H,000H
                > DB 031H,00CH,001H,086H,004H,004H,008H,004H,010H,018H,004H,040H,030H
                > DB 008H,080H,020H,020H,080H,080H,080H,080H,006H,000H,0C0H,030H,004H
                > DB 075H,080H,008H,008H,000H,010H,07CH,000H,021H,074H,0B6H,004H,0E4H
                > DB 0FEH,0E1H,0C1H,0B8H,002H,083H,0B2H,005H,007H,0E4H,00AH,00CH,008H
                > DB 036H,000H,000H,000H,000H,038H,020H,000H,075H,015H,054H,0E0H,00AH
                > DB 0A0H,000H,014H,000H,00FH,080H,000H,07FH,0C0H,003H,080H,0E0H,00CH
                > DB 000H,060H,034H,001H,060H,0CCH,006H,061H,014H,014H,042H,024H,048H
                > DB 080H,045H,010H,000H,084H,020H,001H,000H,040H,000H,094H,000H,079H
                > DB 0F4H,0F0H
                >
                > ; End
                >
              • RentalWarning
                I m wondering if some crude compression could avail quite a bit more code space. Something like dealing with the data in nibbles: 1xxx - xxx = transmit xxx as
                Message 7 of 19 , Apr 12, 2010
                • 0 Attachment
                  I'm wondering if some crude compression could avail quite a bit more code space. Something like dealing with the data in nibbles:

                  1xxx - xxx = transmit xxx as three bits of data
                  0nnn - nnn = nnn specifies how many zeros to transmit

                  I came up with this after noticing most of the data is zeros. I have not tried this scheme to see how many bytes it might save.

                  Possibly, the range of "nnn" should be 4 to 11 as fewer zeros could be equally or more efficiently stored with the 1xxx method.

                  One might be able to craft a better compression scheme that is also simple.

                  Kevin

                  --- In cosmacelf@yahoogroups.com, "aa3nm" <steve@...> wrote:
                  >
                  > Dennis,
                  >
                  > Very nicely done!
                  >
                  > I flipped some of the syntax around and succeeded in assemblying it under Pseudosam. I've processed the .OBJ file as I discribed under a topic related to Elftools and posted a .WAV file along with the other files in the project folder. I put your last initial at the head of the file names --> BArecebo.XXX
                  >
                  > The .wav file is in ELFII format and filtered (as discussed) so Elftools can re-ingest it.
                  >
                  > Again, nicely done!
                  >
                  > Steve
                  >
                  > --- In cosmacelf@yahoogroups.com, Dennis Boone <drb@> wrote:
                  > >
                  > > > It seems possible to fit both the program and data into 256 bytes,
                  > > > though it looks like you ran just a little over.
                  > >
                  > > Here's my version, and coincidentally my first Elf/1802 program. Unlike
                  > > the original, mine repeats ad nauseum. Got it down to 251 bytes.
                  > > Quick, add a feature! Assembled with rc/asm and tested in Mike's
                  > > emulator; haven't fed it to my Elf2k hardware yet.
                  > >
                  > > De
                  > >
                  > >
                  > > ; arecibo.asm, Boone, 04/10/10
                  > > ; Blink the Arecibo M13 message on Elf's Q LED
                  > > ;
                  > > ; Modifications:
                  > > ; 04/10/10 Boone Initial coding
                  > > ; End Modifications
                  > >
                  > > ; Must run in page 0
                  > >
                  > > ORG 0
                  > >
                  > > ; Set up indexes and counters
                  > >
                  > > INIT:
                  > > LDI 0
                  > > PHI 6 ; R6 - count of bits left in cur byte
                  > > PHI 7 ; R7 - X - Pointer into data bits
                  > > LDI BITBLOCK & 00FFH
                  > > PLO 7
                  > > SEX 7
                  > >
                  > > ; Flash the LED a lot
                  > >
                  > > BYTELOOP:
                  > > LDI 8 ; 8 bits per byte, usually
                  > > PLO 6
                  > > LDX ; Fetch the byte
                  > > OUT 4 ; Display the byte
                  > > PLO 5 ; R5 - scratch for byte in progress
                  > > GLO 7
                  > > BZ LASTWORD
                  > > BR BITLOOP
                  > >
                  > > LASTWORD:
                  > > DEC 6 ; ...but only 7 bits in last byte
                  > >
                  > > BITLOOP:
                  > > GLO 5
                  > > SHL ; Cut a bit out of the herd
                  > > PLO 5
                  > > BNF WAIT ; If it's not 0...
                  > > SEQ ; ...turn on the LED
                  > >
                  > > WAIT:
                  > > GHI 6 ; Handy spare 00
                  > >
                  > > SPIN:
                  > > SMI 1 ; Waste some time
                  > > BNZ SPIN
                  > > REQ ; Turn off the LED
                  > > DEC 6 ; 98 bottles of beer on the wall...
                  > > GLO 6 ; We outta bits yet?
                  > > BNZ BITLOOP
                  > > GLO 7 ; How about bytes?
                  > > BNZ BYTELOOP
                  > >
                  > > AGAIN:
                  > > BR INIT ; Da capo...
                  > >
                  > > DONE:
                  > > END INIT
                  > >
                  > > ; The data bits
                  > >
                  > > ORG 02EH ; Last data byte address is key
                  > >
                  > > BITBLOCK:
                  > > DB 002H,0A8H,000H,050H,050H,012H,022H,025H,095H,055H,052H,040H,000H
                  > > DB 000H,000H,001H,080H,000H,00DH,000H,000H,01AH,000H,000H,054H,000H
                  > > DB 000H,0F8H,000H,000H,000H,006H,01CH,061H,088H,000H,032H,01AH,031H
                  > > DB 086H,0BEH,0FBH,0EFH,080H,000H,000H,010H,000H,004H,000H,000H,000H
                  > > DB 020H,000H,00FH,0C0H,001H,0F0H,000H,000H,018H,061H,0C6H,020H,020H
                  > > DB 008H,068H,063H,09AH,0FBH,0EFH,0BEH,000H,000H,000H,040H,0C0H,010H
                  > > DB 001H,080H,000H,083H,000H,03FH,006H,007H,0C0H,00CH,000H,010H,008H
                  > > DB 004H,010H,030H,010H,018H,060H,040H,00CH,043H,000H,001H,098H,000H
                  > > DB 031H,00CH,001H,086H,004H,004H,008H,004H,010H,018H,004H,040H,030H
                  > > DB 008H,080H,020H,020H,080H,080H,080H,080H,006H,000H,0C0H,030H,004H
                  > > DB 075H,080H,008H,008H,000H,010H,07CH,000H,021H,074H,0B6H,004H,0E4H
                  > > DB 0FEH,0E1H,0C1H,0B8H,002H,083H,0B2H,005H,007H,0E4H,00AH,00CH,008H
                  > > DB 036H,000H,000H,000H,000H,038H,020H,000H,075H,015H,054H,0E0H,00AH
                  > > DB 0A0H,000H,014H,000H,00FH,080H,000H,07FH,0C0H,003H,080H,0E0H,00CH
                  > > DB 000H,060H,034H,001H,060H,0CCH,006H,061H,014H,014H,042H,024H,048H
                  > > DB 080H,045H,010H,000H,084H,020H,001H,000H,040H,000H,094H,000H,079H
                  > > DB 0F4H,0F0H
                  > >
                  > > ; End
                  > >
                  >
                • RentalWarning
                  Scratch that method. I tested it and it does not result in compression. There s got to be a way. I ll keep thinking...
                  Message 8 of 19 , Apr 12, 2010
                  • 0 Attachment
                    Scratch that method. I tested it and it does not result in compression. There's got to be a way. I'll keep thinking...

                    >
                    > I'm wondering if some crude compression could avail quite a bit more code space. Something like dealing with the data in nibbles:
                    >
                    > 1xxx - xxx = transmit xxx as three bits of data
                    > 0nnn - nnn = nnn specifies how many zeros to transmit
                    >
                    > I came up with this after noticing most of the data is zeros. I have not tried this scheme to see how many bytes it might save.
                    >
                    > Possibly, the range of "nnn" should be 4 to 11 as fewer zeros could be equally or more efficiently stored with the 1xxx method.
                    >
                    > One might be able to craft a better compression scheme that is also simple.
                    >
                    > Kevin
                    >
                  • Dennis Boone
                    ... This does reduce the size of the data by about 20 bytes, to 1512 bits. I haven t tried coding the sender, so I con t know how much the code grows, but I
                    Message 9 of 19 , Apr 12, 2010
                    • 0 Attachment
                      > 1xxx - xxx = transmit xxx as three bits of data
                      > 0nnn - nnn = nnn specifies how many zeros to transmit

                      > Possibly, the range of "nnn" should be 4 to 11 as fewer zeros could be
                      > equally or more efficiently stored with the 1xxx method.

                      This does reduce the size of the data by about 20 bytes, to 1512 bits.
                      I haven't tried coding the sender, so I con't know how much the code
                      grows, but I suspect it'll be more than 20 bytes.

                      De
                    • Doug Jackson
                      RLE is pretty easy to implement :-) Doug
                      Message 10 of 19 , Apr 12, 2010
                      • 0 Attachment
                        RLE is pretty easy to implement :-)

                        Doug

                        Lee Hart wrote:
                        >
                        >
                        > On 4/12/2010 8:13 PM, RentalWarning wrote:
                        > > I'm wondering if some crude compression could avail quite a bit more
                        > code space. Something like dealing with the data in nibbles:
                        > > 1xxx - xxx = transmit xxx as three bits of data
                        > > 0nnn - nnn = nnn specifies how many zeros to transmit
                        >
                        > Take a look at some of the common methods to compress data, like Huffman
                        > and LZW encoding.
                        >
                      • Lee Hart
                        ... Take a look at some of the common methods to compress data, like Huffman and LZW encoding. -- Lee A. Hart | Ring the bells that still can ring 814 8th Ave
                        Message 11 of 19 , Apr 12, 2010
                        • 0 Attachment
                          On 4/12/2010 8:13 PM, RentalWarning wrote:
                          > I'm wondering if some crude compression could avail quite a bit more code space. Something like dealing with the data in nibbles:
                          > 1xxx - xxx = transmit xxx as three bits of data
                          > 0nnn - nnn = nnn specifies how many zeros to transmit

                          Take a look at some of the common methods to compress data, like Huffman
                          and LZW encoding.

                          --
                          Lee A. Hart | Ring the bells that still can ring
                          814 8th Ave N | Forget the perfect offering
                          Sartell MN 56377 | There is a crack in everything
                          leeahart earthlink.net | That's how the light gets in -- Leonard Cohen
                        • thinkpast
                          The Arecibo Project code by Dennis caught my attention. I think I see some error and some improvements: BYTELOOP: LDI 8 ; 8 bits per byte, usually PLO 6 LDX ;
                          Message 12 of 19 , May 6 12:48 PM
                          • 0 Attachment
                            The Arecibo Project code by Dennis caught my attention. I think I see some error and some improvements:

                            BYTELOOP:
                            LDI 8 ; 8 bits per byte, usually
                            PLO 6
                            LDX ; Fetch the byte
                            OUT 4 ; Display the byte

                            Should that be "LDXA" to fetch the address and *increment* the register X points to?

                            Also:

                            BZ LASTWORD
                            BR BITLOOP
                            LASTWORD:
                            DEC 6
                            BITLOOP:

                            has too many branches - how about this?

                            BNZ BITLOOP
                            LASTWORD:
                            DEC 6
                            BITLOOP:

                            Also, there's an issue about how to "transmit", or blink the Q LED. Here's what Dennis does:

                            (get bit)
                            BNF WAIT ; If it's not 0...
                            SEQ ; ...turn on the LED
                            WAIT:
                            GHI 6 ; Handy spare 00 into D
                            SPIN:
                            SMI 1 ; Waste some time subtracting 1
                            BNZ SPIN
                            REQ ; Turn off the LED
                            (loop to get next bit)

                            This means the LED is off or on for long strings of consecutive 1's or 0's. It's possible to "lose count", and if your "signal" is lost you don't know if that's a run of zeros or not. In the signal trade we call that a lack of a "clock" signal. You want to send something all the time, if you want to "include" a clock.

                            The simplest fix I came up with is:

                            (get bit)
                            BNF WAIT ; If it's not 0...
                            SEQ ; ...turn on the LED 1/3 time if a 1
                            WAIT:
                            GHI 6 ; Handy spare 00 into D
                            SPIN:
                            SMI 1 ; Waste some time subtracting 1 from D
                            BNZ SPIN ; LED is on or off 1/3 time

                            SEQ ; ...turn on the LED
                            SPIN2:
                            SMI 1 ; 1/3 time with LED on
                            BNZ SPIN2

                            REQ ; Turn off the LED
                            SPIN3:
                            SMI 1 ; 1/3 time with LED ALWAYS off
                            BNZ SPIN3

                            ..so a 1 is when the LED is on 2/3 time, and a 0 is when the LED is on 1/3 time. So you always have a "signal". For Morse code enthusiasts, this is a series of "dits" and "dahs" (and space) for zero and one.

                            That's not hard to "detect" at the other end - measure the length of the pulses, and you'll see two kinds, "short" and "long". A simple timer set to a length between the "short" and "long" pulses will see a 1 or 0 - that's your "detector".

                            (Note: a more "efficient" scheme would be to send a 01 for a zero, 10 for a one. But this is harder to detect, and I think it takes more space to code up. Also, more effort to decode. Remember, you want the Space Aliens to have it easy!)

                            But I can't make this code "fit" the space. The SMI 1/BNZ SPINx code is four bytes, it adds up! Is there a shorter way to make a timed loop? Can a coroutine save space? Are there other code efficiencies in the program? I'm not a good enough 1802 programmer to know, but it's so few bytes that most tricks don't seem to be productive.

                            Herb Johnson
                          • Dennis Boone
                            ... No, because the OUT increments it. ... I think that one may actually be left over from having something else in between the two branches in an earlier
                            Message 13 of 19 , May 6 1:15 PM
                            • 0 Attachment
                              > BYTELOOP:
                              > LDI 8 ; 8 bits per byte, usually
                              > PLO 6
                              > LDX ; Fetch the byte
                              > OUT 4 ; Display the byte

                              > Should that be "LDXA" to fetch the address and *increment* the register
                              > X points to?

                              No, because the OUT increments it.

                              > BZ LASTWORD
                              > BR BITLOOP
                              > LASTWORD:
                              > DEC 6
                              > BITLOOP:

                              > has too many branches - how about this?

                              I think that one may actually be left over from having something else in
                              between the two branches in an earlier version.

                              > This means the LED is off or on for long strings of consecutive 1's or
                              > 0's. It's possible to "lose count", and if your "signal" is lost you
                              > don't know if that's a run of zeros or not. In the signal trade we call
                              > that a lack of a "clock" signal. You want to send something all the
                              > time, if you want to "include" a clock.

                              Yeah, I didn't address that all. In fact, I'm not sure the actual
                              Arecibo transmission did either.

                              De
                            • thinkpast
                              ... I considered eliminating the OUT to save a byte. But I did not know it also incremented the register X points to. (We agreed about the extra branch
                              Message 14 of 19 , May 9 7:25 AM
                              • 0 Attachment
                                --- In cosmacelf@yahoogroups.com, Dennis Boone <drb@...> wrote:

                                > > LDX ; Fetch the byte
                                > > OUT 4 ; Display the byte
                                >
                                > > Should that be "LDXA" to fetch the address and *increment* the register
                                > > X points to?
                                >
                                > No, because the OUT increments it.

                                I considered eliminating the OUT to save a byte. But I did not know it also incremented the register X points to.

                                (We agreed about the extra branch instruction.)

                                > > This means the LED is off or on for long strings of consecutive 1's or
                                > > 0's. It's possible to "lose count", and if your "signal" is lost you
                                > > don't know if that's a run of zeros or not. In the signal trade we call
                                > > that a lack of a "clock" signal. You want to send something all the
                                > > time, if you want to "include" a clock.
                                >
                                > Yeah, I didn't address that all. In fact, I'm not sure the actual
                                > Arecibo transmission did either.

                                There's a Wikipedia account about the original transmission. Of course, it's a matter of taste and interest as to how to blink an LED, but Lee Hart suggested a receiver to match this particular transmitter. I think it would be easier to decode short and long blinks than off/on blinks. But all this is in fun, to meet the 256-byte challenge posed. It's a good exercise in knowing what 1802 codes do. Thanks for your implementation.

                                Dennis, if you don't object, I'll put your code and some of my suggestions with the other "1802 membership" stuff I have on my Web page.

                                Herb Johnson
                              • thinkpast
                                ... Finally got around to adding Dennis s code and my variant to the membership card Web site: http://www.retrotechnology.com/memship/arecibo.html Comments
                                Message 15 of 19 , Aug 30, 2010
                                • 0 Attachment
                                  --- In cosmacelf@yahoogroups.com, "thinkpast" <hjohnson@...> wrote:

                                  > There's a Wikipedia account about the original transmission. Of course, it's a matter of taste and interest as to how to blink an LED, but Lee Hart suggested a receiver to match this particular transmitter. I think it would be easier to decode short and long blinks than off/on blinks. But all this is in fun, to meet the 256-byte challenge posed. It's a good exercise in knowing what 1802 codes do. Thanks for your implementation.
                                  >
                                  > Dennis, if you don't object, I'll put your code and some of my suggestions with the other "1802 membership" stuff I have on my Web page.

                                  Finally got around to adding Dennis's code and my variant to the "membership card" Web site:

                                  http://www.retrotechnology.com/memship/arecibo.html

                                  Comments welcome. - Herb Johnson
                                • Dennis Boone
                                  Herb, Your code adds 4 bytes to the program. I think I can save you one byte. The GHI 6 instruction you added isn t really necessary, as the end value of the
                                  Message 16 of 19 , Aug 30, 2010
                                  • 0 Attachment
                                    Herb,

                                    Your code adds 4 bytes to the program. I think I can save you one byte.
                                    The GHI 6 instruction you added isn't really necessary, as the end value
                                    of the first loop is 0.

                                    With the removal of the extra branch you found there are 7 bytes spare
                                    in my version, so your version does fit into 256 bytes, with 4 bytes to
                                    spare.

                                    Next feature? :)

                                    De
                                  Your message has been successfully submitted and would be delivered to recipients shortly.