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

One-stitch pattern uploaded - initial analysis

Expand Messages
  • jhogerhuis
    I collected raw disk sector data saving a 1-stitch, one row pattern. One file labeled load-1-bit-on.bin has the lamp lit on control panel when checking that
    Message 1 of 5 , Nov 30, 2004
    • 0 Attachment
      I collected raw disk sector data saving a 1-stitch, one row pattern.
      One file labeled

      load-1-bit-on.bin has the lamp lit on control panel when checking that
      pattern.

      load-1-bit-off.bin has the lamp unlit on control panel when checking
      that pattern.

      on.txt is a hex dump of load-1-bit-on.bin
      off.txt is a hex dump of load-1-bit-off.bin

      one_bit_diff.txt is the output of the GNU/Linux diff command run on
      on.txt and off.txt.

      The result is this:

      1c1
      < 0000000 2001 1000 0901 fb01 003e 0000 0209 0000
      ---
      > 0000000 2001 1000 0901 fb01 0040 0000 0209 0000
      77,83c77,82
      < 00006d0 0000 0000 0000 0000 e007 213f 0ff3 0001
      < 00006e0 0119 3000 0000 ff00 ffff ffff ffff ffff
      < 00006f0 ffff ffff ffff ffff ffff ffff ffff ffff
      < 0000700 2201 0100 2201 0200 0000 2101 0000 0081
      < 0000710 f207 f907 0000 ff00 ffff ffff ffff ffff
      < 0000720 ffff ffff ffff ffff ffff ffff ffff ffff
      < 0000730 0000 0000 0000 0000 0000 0000 0000 0000
      ---
      > 00006d0 0000 0000 0000 0000 e007 213f 0ff3 0000
      > 00006e0 0119 3000 0000 0000 0000 0000 0000 0000
      > 00006f0 0000 0000 0000 0000 0000 0000 0000 0000
      > 0000700 2201 0100 2801 0800 0000 2101 0000 0081
      > 0000710 f207 f907 0000 0000 0000 0000 0000 0000
      > 0000720 0000 0000 0000 0000 0000 0000 0000 0000

      Note on 'diff' output: the first column of numbers is just an offset
      into the file. The data is in hex, and only lines that differ are
      shown in diff output. The command line was diff on.txt off.txt so the
      first block of each block pair is the "on" pattern.

      First of all, the header line changes: the 10th byte 0x3e -> 0x40
      Maybe part of a checksum?

      Other interesting things to note about the header is the binary coded
      decimal '0901' pattern number.

      I basically only changed one logical 'bit' but look how all those 0's
      turned into f's. The binary 0's are in the "off" pattern and the
      binary 1's (FF's) are in the "on" pattern. Why did so many bits
      change? Speculation?

      Next up will be all permutations of a 1-row 2-bit pattern, and 3-bit
      pattern.

      After that probably I'll do all 16 permutations of a 2X2 pattern.

      Eventually we can try out some larger ones.

      -- John.
    • mikezcnc
      It is a very interesting way of poking into the code and you ve got great results. From what you are saying, you are using linux-is there a reason for it other
      Message 2 of 5 , Nov 30, 2004
      • 0 Attachment
        It is a very interesting way of poking into the code and you've got
        great results. From what you are saying, you are using linux-is there
        a reason for it other than personal interest? How are you getting
        code-by connecting a FB100 to a PC and taking it from there. Does
        FB100 have any controls on it or is just that, an FDD. If so then how
        do you get data out of it? Just curious about your test bed.

        Have you considered using Tandy 100 and Basic interface to use as a
        controller, since FDD connects to Tandy, as you have found out?

        I was thinking of using a logic analyzer on the knitter I/O.

        Mike



        --- In kminternals@yahoogroups.com, "jhogerhuis" <jhoger@p...> wrote:
        >
        > I collected raw disk sector data saving a 1-stitch, one row pattern.
        > One file labeled
        >
        > load-1-bit-on.bin has the lamp lit on control panel when checking
        that
        > pattern.
        >
        > load-1-bit-off.bin has the lamp unlit on control panel when checking
        > that pattern.
        >
        > on.txt is a hex dump of load-1-bit-on.bin
        > off.txt is a hex dump of load-1-bit-off.bin
        >
        > one_bit_diff.txt is the output of the GNU/Linux diff command run on
        > on.txt and off.txt.
        >
        > The result is this:
        >
        > 1c1
        > < 0000000 2001 1000 0901 fb01 003e 0000 0209 0000
        > ---
        > > 0000000 2001 1000 0901 fb01 0040 0000 0209 0000
        > 77,83c77,82
        > < 00006d0 0000 0000 0000 0000 e007 213f 0ff3 0001
        > < 00006e0 0119 3000 0000 ff00 ffff ffff ffff ffff
        > < 00006f0 ffff ffff ffff ffff ffff ffff ffff ffff
        > < 0000700 2201 0100 2201 0200 0000 2101 0000 0081
        > < 0000710 f207 f907 0000 ff00 ffff ffff ffff ffff
        > < 0000720 ffff ffff ffff ffff ffff ffff ffff ffff
        > < 0000730 0000 0000 0000 0000 0000 0000 0000 0000
        > ---
        > > 00006d0 0000 0000 0000 0000 e007 213f 0ff3 0000
        > > 00006e0 0119 3000 0000 0000 0000 0000 0000 0000
        > > 00006f0 0000 0000 0000 0000 0000 0000 0000 0000
        > > 0000700 2201 0100 2801 0800 0000 2101 0000 0081
        > > 0000710 f207 f907 0000 0000 0000 0000 0000 0000
        > > 0000720 0000 0000 0000 0000 0000 0000 0000 0000
        >
        > Note on 'diff' output: the first column of numbers is just an offset
        > into the file. The data is in hex, and only lines that differ are
        > shown in diff output. The command line was diff on.txt off.txt so
        the
        > first block of each block pair is the "on" pattern.
        >
        > First of all, the header line changes: the 10th byte 0x3e -> 0x40
        > Maybe part of a checksum?
        >
        > Other interesting things to note about the header is the binary
        coded
        > decimal '0901' pattern number.
        >
        > I basically only changed one logical 'bit' but look how all those
        0's
        > turned into f's. The binary 0's are in the "off" pattern and the
        > binary 1's (FF's) are in the "on" pattern. Why did so many bits
        > change? Speculation?
        >
        > Next up will be all permutations of a 1-row 2-bit pattern, and 3-bit
        > pattern.
        >
        > After that probably I'll do all 16 permutations of a 2X2 pattern.
        >
        > Eventually we can try out some larger ones.
        >
        > -- John.
      • John R. Hogerhuis
        ... Reverse engineering is a lot like science. You gather data (like I did in this case), form hypotheses, and gather more data to test/verify the hypothesis.
        Message 3 of 5 , Nov 30, 2004
        • 0 Attachment
          On Tue, 2004-11-30 at 06:42, mikezcnc wrote:
          > It is a very interesting way of poking into the code and you've got
          > great results.

          Reverse engineering is a lot like science. You gather data (like I did
          in this case), form hypotheses, and gather more data to test/verify the
          hypothesis.

          > From what you are saying, you are using linux-is there
          > a reason for it other than personal interest?

          Well freedom is the #1 reason. Linux is not under monopoly control and I
          can change or fix any of the software because all of the source code is
          available.

          But generally I run only Linux on my network because it is a malleable,
          secure, powerful OS and thousands of high quality Free Software programs
          are available for download at places like SourceForge.net and
          Freshmeat.net. I run the Debian GNU/Linux distribution on all moy boxes.

          Furthermore there is no knitting software for these machines that runs
          under Linux. So any work I do on this platform could be picked up by
          someone else.

          I can run Windows stuff, and I do professional Windows development, but
          I run it on W2K under VmWare.

          > How are you getting
          > code-by connecting a FB100 to a PC and taking it from there.
          Well I have a laptop with two serial ports (one is a USB<->Serial
          adapter). One is connected via null modem adapter + Tandy Portable Disk
          Drive (TPDD) cable to the km. The other is connected via TPDD cable to
          the Brother FB100 disk drive.

          I have a 'snooper' serial analyzer program that I run. It just passes
          traffic between the two ports and lets me view the data. I can save logs
          of that, but they are ASCII text.

          So to write the data I run

          snooper -b9600 /dev/ttyS0 /dev/ttyUSB0

          I have written a little bit of Forth code that lets me do a read of the
          data just as the KM would.

          So to read the data I run gforth test.fs and once at the prompt I type
          READ-SECTOR. This runs a Forth script that reads the sector and writes
          it out to disk as a binary file.

          I'll post this code soon just in case someone finds it useful.

          To really make this work though you need at least one TPDD or DAK cable
          and a KM.

          I think there is a version of gforth for Windows. If not my test code
          could be adapted to any modern Forth interpreter.

          > Does
          > FB100 have any controls on it or is just that, an FDD. If so then how
          > do you get data out of it? Just curious about your test bed.

          Just a FDD. I write commands to it over its serial link and read them
          via the serial link. These are fairly odd disk drives in that they have
          a serial interface rather than a parallel type of interface.

          >
          > Have you considered using Tandy 100 and Basic interface to use as a
          > controller, since FDD connects to Tandy, as you have found out?

          Yes some of my testing has been to use a Tandy 102 with short BASIC
          programs to try things out.

          >
          > I was thinking of using a logic analyzer on the knitter I/O.
          >

          Yep. In fact you could hook it to the processor bus and watch all the
          instructions and we could actually trace execution that way.

          But for the serial port I'd suggest using a hardware serial protocol
          analyzer or a laptop with two serial ports and serial protocol analyzer
          software as I do. Otherwise you'll waste a lot of time setting up a
          logic analyzer to trace a serial link.

          -- John.
        • mikezcnc
          I see that you are very advance in your project. I looked into forth several times and it is a very powerful language. I never understood why wasn t it picked
          Message 4 of 5 , Nov 30, 2004
          • 0 Attachment
            I see that you are very advance in your project. I looked into forth
            several times and it is a very powerful language. I never understood
            why wasn't it picked up over C, but now I recall it was because of
            documenting; forth is difficult to read if the programmer did not
            include comments.

            I wrote couple of emails to different places and gor responce form
            one that they are looking into helping us out. We'll see.

            Mike

            --- In kminternals@yahoogroups.com, "John R. Hogerhuis" <jhoger@p...>
            wrote:
            > On Tue, 2004-11-30 at 06:42, mikezcnc wrote:
            > > It is a very interesting way of poking into the code and you've
            got
            > > great results.
            >
            > Reverse engineering is a lot like science. You gather data (like I
            did
            > in this case), form hypotheses, and gather more data to test/verify
            the
            > hypothesis.
            >
            > > From what you are saying, you are using linux-is there
            > > a reason for it other than personal interest?
            >
            > Well freedom is the #1 reason. Linux is not under monopoly control
            and I
            > can change or fix any of the software because all of the source
            code is
            > available.
            >
            > But generally I run only Linux on my network because it is a
            malleable,
            > secure, powerful OS and thousands of high quality Free Software
            programs
            > are available for download at places like SourceForge.net and
            > Freshmeat.net. I run the Debian GNU/Linux distribution on all moy
            boxes.
            >
            > Furthermore there is no knitting software for these machines that
            runs
            > under Linux. So any work I do on this platform could be picked up by
            > someone else.
            >
            > I can run Windows stuff, and I do professional Windows development,
            but
            > I run it on W2K under VmWare.
            >
            > > How are you getting
            > > code-by connecting a FB100 to a PC and taking it from there.
            > Well I have a laptop with two serial ports (one is a USB<->Serial
            > adapter). One is connected via null modem adapter + Tandy Portable
            Disk
            > Drive (TPDD) cable to the km. The other is connected via TPDD cable
            to
            > the Brother FB100 disk drive.
            >
            > I have a 'snooper' serial analyzer program that I run. It just
            passes
            > traffic between the two ports and lets me view the data. I can save
            logs
            > of that, but they are ASCII text.
            >
            > So to write the data I run
            >
            > snooper -b9600 /dev/ttyS0 /dev/ttyUSB0
            >
            > I have written a little bit of Forth code that lets me do a read of
            the
            > data just as the KM would.
            >
            > So to read the data I run gforth test.fs and once at the prompt I
            type
            > READ-SECTOR. This runs a Forth script that reads the sector and
            writes
            > it out to disk as a binary file.
            >
            > I'll post this code soon just in case someone finds it useful.
            >
            > To really make this work though you need at least one TPDD or DAK
            cable
            > and a KM.
            >
            > I think there is a version of gforth for Windows. If not my test
            code
            > could be adapted to any modern Forth interpreter.
            >
            > > Does
            > > FB100 have any controls on it or is just that, an FDD. If so then
            how
            > > do you get data out of it? Just curious about your test bed.
            >
            > Just a FDD. I write commands to it over its serial link and read
            them
            > via the serial link. These are fairly odd disk drives in that they
            have
            > a serial interface rather than a parallel type of interface.
            >
            > >
            > > Have you considered using Tandy 100 and Basic interface to use as
            a
            > > controller, since FDD connects to Tandy, as you have found out?
            >
            > Yes some of my testing has been to use a Tandy 102 with short BASIC
            > programs to try things out.
            >
            > >
            > > I was thinking of using a logic analyzer on the knitter I/O.
            > >
            >
            > Yep. In fact you could hook it to the processor bus and watch all
            the
            > instructions and we could actually trace execution that way.
            >
            > But for the serial port I'd suggest using a hardware serial protocol
            > analyzer or a laptop with two serial ports and serial protocol
            analyzer
            > software as I do. Otherwise you'll waste a lot of time setting up a
            > logic analyzer to trace a serial link.
            >
            > -- John.
          • John R. Hogerhuis
            ... Well I have a setup for analysis, that s about it. If anyone can think of good experiments to do, let me know and I ll report the results. ... I mostly
            Message 5 of 5 , Nov 30, 2004
            • 0 Attachment
              On Tue, 2004-11-30 at 10:46, mikezcnc wrote:
              > I see that you are very advance in your project.

              Well I have a setup for analysis, that's about it. If anyone can think
              of good experiments to do, let me know and I'll report the results.

              > I looked into forth
              > several times and it is a very powerful language. I never understood
              > why wasn't it picked up over C, but now I recall it was because of
              > documenting; forth is difficult to read if the programmer did not
              > include comments.

              I mostly just use Forth for prototyping. Basically forth "words" can be
              stacked like Legos. You end up making a lot of very simple words that
              can be strung together at the interpreter prompt to do more complex
              stuff. So it's very useful for interactively trying things out, in order
              to get a feel for the protocol or hardware you are dealing with.

              It is probably more useful in embedded systems contexts, particularly on
              constrained systems (8 or 16 bit CPUs or microcontrollers with very
              little RAM).

              I tend to rewrite the final application in C.

              >
              > I wrote couple of emails to different places and gor responce form
              > one that they are looking into helping us out. We'll see.

              Cool! Keep us apprised.

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