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

Re: [gnu-m68hc11] PCBUG11

Expand Messages
  • yann gouy
    ... yes, it will very useful to me. ... I m working with the F1 variant, so if it could help, just ask. ... no, only the code of the boot in rom has been
    Message 1 of 11 , May 1, 2000
      --- Clifford Heath <cjh@...> a écrit:
      > Folk,
      >
      > I've been looking closely at PCBUG11 and its talker
      > programs with a
      > view to doing something similar for Linux.
      >
      > The talkers I have are in .boo form (binary boot
      > block with a single
      > byte 0xFF prepended), except for a hacked version of
      > the source code
      > that was posted recently. Anyhow, I wrote "boo2s19"
      > and after using
      > it I ran the m6811-elf-objdump disassembler over the
      > output, and then
      > walked through the resultant talke.asm file adding
      > the comments and
      > labels from the hacked version, and a few of my own.
      >
      > The result is that I have talker assembly code that
      > goes through
      > m6811-elf-as and produces .s19 files with identical
      > contents to the
      > original .boo files. I also have a fairly accurate
      > understanding of
      > the protocol used between PCBUG11 and the talker.
      >
      > The next step is to try to run a talker in the
      > simulator. If that works,
      > I might write a debug proxy that translates GDB's
      > remote protocol into
      > PCBUG talker commands, so you could use a standard
      > talker in your chip
      > with gdb instead of PCBUG11. Does this sound useful
      > to anyone?

      yes, it will very useful to me.

      >
      > I should say that I don't want to target gdb
      > directly into the chip as
      > I often work with limited RAM and the much simpler
      > talker program from
      > PCBUG11 is preferable. Obviously I could produce a
      > new talker program
      > that does the same things (actually there are a few
      > things that could
      > be done better), but then I'd have to target every
      > hardware variant and
      > just using the PCBUG talkers is preferable.
      >

      I'm working with the F1 variant, so if it could help,
      just ask.

      > Does anyone know where the source code of the
      > PCBUG11 talkers is published?

      no, only the code of the boot in rom has been
      published, as far as I know.

      > Does anyone know where the protocol is documented
      > (not at all, I bet)?

      I believe you're right. :-<
      but if anyone knows someone at motorola, may be he can
      ask?

      > If anyone wants copies of my work in progress, just
      > ask, I'll be happy
      > to mail it or post on my website. Obviously if
      > anyone wants to contribute
      > to the project, I'll be pleased also.
      >

      I'm ready for both. 'cause I need it to complete my
      projet and I'd be happy to help.

      bye



      =====
      Yann

      La Terre est le berceau de l'Humanite,
      mais nul ne reste eternellement dans son berceau.
      Tchleskovsky
      (inventeur du principe de la fusee a reaction)
      (pere spirituel de Youri Gagarine)

      ___________________________________________________________
      Do You Yahoo!?
      Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
    • Angel Vidal
      Clifford Heath wrote: ... Hi Clifford, I m new in the list and I don t know if this source can help you. It s a tarker I found in my old disks and that I used
      Message 2 of 11 , May 1, 2000
        Clifford Heath wrote:
        ...
        > Does anyone know where the source code of the PCBUG11 talkers is published?


        Hi Clifford,
        I'm new in the list and I don't know if this source can help you. It's a
        tarker I found in my old disks and that I used anytime for one project
        with hc11. I've got nine more talkers but I didn't can uncompress
        it(possible file corrupted, I'm trying).

        This files are from 1988-1990, but the assembler languaje is the same (I
        hope).

        While I try umcompress the other files here is one that I modified four
        or five years ago to load my project in memory...
        Here is:

        *************************** TALKEREE.ASC 3/4/90
        **************************
        * Motorola Copyright 1988,1990
        *
        * MCU resident, Interrupt driven Communication routines for 68HC11
        *
        * monitor. Provides low level memory and stack read/write operations.
        *
        *
        *
        * This talker DOES NOT uses XIRQ
        *
        * ------------------------------
        *
        *
        *
        * N.B. TALKEREE.ASC is designed to work with the 68HC11A1 or other
        *
        * compatible MCU types. This version of the TALKER is designed to
        *
        * execute from internal EEPROM located at $B600-$B7FF.
        *
        * TALKEREE must have been previously downloaded in some manner, for
        *
        * instance using PCBUG11 BOOTA8 option, and EEPROM & LOADS
        commands.*
        * To initiate communication with TALKEREE, an SCI break condition
        *
        * must be detected by the 68HC11 running in bootstrap mode.
        *
        * When PCBUG11 is executed with option TALKEREE, a 10mS break is
        *
        * output to the 68HC11's SCI, prior to establishing communication.
        *
        *
        * CONSTANTS
        TALKBASE equ $B600
        BOOTVECT equ $00C4 Start of bootstrap vector jump table.
        STACK equ $003F User may alter this parameter if required
        REGBASE equ $1000
        *
        JSCI equ $00C4
        JXIRQ equ $00F1
        JSWI equ $00F4
        JILLOP equ $00F7
        JCOP equ $00FA
        JMPEXT equ $7E Mnemonic for jump extended instruction
        BRKCODE equ $4A Break point signal code to host.
        BRKACK equ $4A Break point acknowledge code from host.
        *
        * REGISTERS
        BAUD equ $2B
        SCCR1 equ $2C
        SCCR2 equ $2D
        SCSR equ $2E
        SCDR equ $2F
        *
        RDRF equ $20
        TDRE equ $80
        OR equ $08
        FE equ $02
        *
        * PROGRAM
        org TALKBASE
        TLKRSTART EQU * First dynamically set up Boot vector jump table.
        LDAA #JMPEXT
        LDY #NULLSRV
        LDX #BOOTVECT
        SETVECT EQU *
        STAA ,X
        INX
        STY ,X
        INX
        INX
        CPX #$100
        BNE SETVECT
        LDX #SCISRV
        STX JSCI+1
        LDX #TLKRSTART
        STX JILLOP+1
        *
        USERSTART EQU *
        LDS #STACK
        LDX #REGBASE
        CLR SCCR1,X
        LDD #$302C
        STAA BAUD,X Initialise SCI to 9600 baud, no parity, no
        interrupt
        STAB SCCR2,X and enable SCI tx & rx.
        LDAA #$40 Enable STOP, and I bit interrupts, disable XIRQ.
        TAP
        *
        IDLE JMP IDLE Now hang around for SCI interrupt from host.
        * A RESET from host changes above jump destination to start of user
        code.
        *
        SCISRV EQU * On detecting interrupt,
        LDAA SCSR+REGBASE assume receiver caused it.
        ANDA #RDRF
        BEQ SCISRV otherwise program will hang up
        *
        RXSRV EQU * Talker code processes received data.
        LDAA SCDR+REGBASE Read command byte, & echo it as acknowledge
        COMA Inverted
        BSR OUTSCI to host.
        BPL INH1 If command bit 7 set, then process inherent
        command
        BSR INSCI else read byte count from host into ACCB.(0=256)
        XGDX Save command and byte count.
        BSR INSCI Read high address byte
        TBA into ACCA
        BSR INSCI then low address byte into ACCB
        XGDX Restore command in ACCA,count in ACCB,address in
        X
        CMPA #$FE
        BNE RXSRV1 If command is memory read, then
        *
        TREADMEM EQU * REPEAT
        LDAA ,X read required address
        BSR OUTSCI send it to host
        TBA (save byte count)
        BSR INSCI and wait for acknowledge
        TAB (restore byte count)
        INX Increment address
        DECB Decrement byte count
        BNE TREADMEM UNTIL all done
        RTI and return to idle loop or user code.
        *
        RXSRV1 EQU *
        CMPA #$BE
        BNE RXSRVEX If command is memory write then
        *
        TBA move byte count to ACCA
        TWRITMEM EQU * REPEAT
        BSR INSCI Read next byte from host into ACCB,
        STAB ,X and store at required address.
        LDY #$0001 Set up wait loop to allow for 28C64 prog time,
        where
        WAITPOLL DEY Y operand must be manually set to $0359 (3mS)
        BNE WAITPOLL
        LDAB ,X Read stored byte and
        STAB SCDR+REGBASE echo it back to host,
        INX
        DECA Decrement byte count
        BNE TWRITMEM UNTIL all done
        RXSRVEX EQU * and return
        NULLSRV RTI
        *
        INSCI EQU *
        LDAB SCSR+REGBASE Wait for RDRF=1
        BITB #(FE+OR) If break detected then
        BNE TLKRSTART restart talker.
        ANDB #RDRF
        BEQ INSCI
        LDAB SCDR+REGBASE then read data received from host
        RTS and return with data in ACCB
        *
        OUTSCI EQU * Only register Y modified.
        XGDY Enter with data to send in ACCA.
        OUTSCI1 LDAA SCSR+REGBASE
        BPL OUTSCI1 MS bit is TDRE flag
        XGDY
        STAA SCDR+REGBASE Important - Updates CCR!
        RTS
        *
        INH1 EQU *
        CMPA #$7E If command is read MCU registers then
        BNE INH2
        *
        INH1A TSX Move stack pointer to X
        XGDX then to ACCD
        BSR OUTSCI send stack pointer to host (high byte first)
        TBA
        BSR OUTSCI then low byte
        TSX Restore X (=stack pointer)
        LDAB #9 then return 9 bytes on stack
        BRA TREADMEM i.e. CCR,ACCB,ACCA,IXH,IXL,IYH,IYL,PCH,PCL
        *
        INH2 EQU *
        CMPA #$3E If command is write MCU registers then
        BNE SWISRV1
        *
        BSR INSCI get stack pointer from host (High byte first)
        TBA
        BSR INSCI
        XGDX Move to X reg
        TXS and copy to stack pointer
        LDAA #9 Then put next 9 bytes from host on to stack
        BRA TWRITMEM
        *
        SWISRV EQU * Breakpoints generated by host-placed SWI
        instruction.
        LDAA #BRKCODE Force host to process breakpoints
        BSR OUTSCI by sending it the break signal
        SWIIDLE CLI
        BRA SWIIDLE then wait for response from host.
        (Ibit=0,Xbit=1)
        *
        SWISRV1 EQU *
        CMPA #BRKACK If host has acknowledged breakpoint state then
        BNE RXSRVEX
        TSX move stack pointer to SWI stack frame and
        LDAB #9
        ABX
        TXS
        LDD 7,X Send user code breakpoint return address to host
        BSR OUTSCI (high byte first)
        TBA
        BSR OUTSCI (low byte next)
        LDD #SWIIDLE force idle loop on return from breakpoint
        processing
        STD 7,X
        BRA INH1A but first return all MCU registers to host
        *
        END
      • yann gouy
        Hi Clifford, I m still waiting for news from you. cause it s no use to devellop the same stuff twice and there s nothing new on your web site. looking for
        Message 3 of 11 , May 19, 2000
          Hi Clifford,

          I'm still waiting for news from you.

          'cause it's no use to devellop the same stuff twice
          and there's nothing new on your web site.

          looking for you, bye.




          =====
          Yann

          La Terre est le berceau de l'Humanite,
          mais nul ne reste eternellement dans son berceau.
          Tchleskovsky
          (inventeur du principe de la fusee a reaction)
          (pere spirituel de Youri Gagarine)

          ___________________________________________________________
          Do You Yahoo!?
          Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
        • Clifford Heath
          ... Sorry, I ve been frantic with a product release at work and have done very little new. My gnu as version of the talker source is at home, but I have
          Message 4 of 11 , May 21, 2000
            > I'm still waiting for news from you.

            Sorry, I've been frantic with a product release at work and have done
            very little new. My gnu "as" version of the talker source is at home,
            but I have attached my notes on the talker protocol and the boo2s19.c
            file so you can disassemble your own.

            I'll publish the talker source soon (it's just talkee.asm, which was
            published by Mot around 1990, but mine works with "as"). It's very
            little different from the other versions I've disassembled, but as some
            of those use an external ACIA for which I have no hardware details, I
            can't produce commented versions for them. I could simply include the
            code in a conditional section however...

            Hopefully I'll get time to start modifying dl11 to talk "talker"
            protocol soon.

            --
            Clifford Heath, Open Software Associates, Ph +613 9895 2194, Fax 9895 2020
            56-60 Rutland Rd (or PO Box 625), Box Hill 3128, Melbourne, VIC, Australia.
            mailto:cjh@... http://www.osa.com.au/~cjh
          • Clifford Heath
            ... There is now. My disassembly, makefiles, etc and a GNU talker is at . See also the DL11 main page at
            Message 5 of 11 , May 24, 2000
              > and there's nothing new on your web site.

              There is now. My disassembly, makefiles, etc and a GNU talker is at
              <http://www.osa.com.au/~cjh/electronics/talker.tgz>.

              See also the DL11 main page at
              <http://www.osa.com.au/~cjh/electronics/dl11.html>.

              A task that I'd love someone else to volunteer for is to "diff" the various
              disassembled talkers and produce a generic assembly version with conditional
              compilation for the various targets. The talkers from Dickens are there too
              and they're slightly different, but I haven't worked out how or why. I only
              have E series chips ('9s and '20s) so have little motivation for this, maybe
              I can just leave it to folk wanting to use my later stuff?

              Next I'd like to add a PCBug11 mode into DL11 with a minimal command set
              just to prove that I can talk to a talker, before looking at the gdbserver
              port.

              One slight problem is that I don't want to infect DL11 with the GPL - I want
              to contribute my work in a way that allows commercial use. Haven't worked
              out what to do about that yet, any suggestions? Maybe I'll just keep the
              gdbserver code as a (GPL'd) patch to DL11...

              --
              Clifford Heath, Open Software Associates, Ph +613 9895 2194, Fax 9895 2020
              56-60 Rutland Rd (or PO Box 625), Box Hill 3128, Melbourne, VIC, Australia.
              mailto:cjh@... http://www.osa.com.au/~cjh
            • yann gouy
              ... I ve download the whole stuff. ... I ll try to work on it, but not before this week-end ( cause of volley-ball tournament) The talkers ... i have a F1
              Message 6 of 11 , May 25, 2000
                > There is now. My disassembly, makefiles, etc and a
                > GNU talker is at
                > <http://www.osa.com.au/~cjh/electronics/talker.tgz>.
                >
                > See also the DL11 main page at
                > <http://www.osa.com.au/~cjh/electronics/dl11.html>.
                >

                I've download the whole stuff.

                > A task that I'd love someone else to volunteer for
                > is to "diff" the various
                > disassembled talkers and produce a generic assembly
                > version with conditional
                > compilation for the various targets.

                I'll try to work on it, but not before this week-end
                ('cause of volley-ball tournament)

                The talkers
                > from Dickens are there too
                > and they're slightly different, but I haven't worked
                > out how or why. I only
                > have E series chips ('9s and '20s) so have little
                > motivation for this, maybe
                > I can just leave it to folk wanting to use my later
                > stuff?

                i have a F1 chip, I'll see how it works on it.

                >
                > Next I'd like to add a PCBug11 mode into DL11 with a
                > minimal command set
                > just to prove that I can talk to a talker, before
                > looking at the gdbserver
                > port.
                >
                > One slight problem is that I don't want to infect
                > DL11 with the GPL - I want
                > to contribute my work in a way that allows
                > commercial use. Haven't worked
                > out what to do about that yet, any suggestions?
                > Maybe I'll just keep the
                > gdbserver code as a (GPL'd) patch to DL11...
                >

                why not provide a minimal "GPL-PCBUG11" apart of dl11?
                so, you can download the talker with dl11 and talk to
                it with the "GPL-PCBUG11".

                A+ (CU in french)


                =====
                Yann

                La Terre est le berceau de l'Humanite,
                mais nul ne reste eternellement dans son berceau.
                Tchleskovsky
                (inventeur du principe de la fusee a reaction)
                (pere spirituel de Youri Gagarine)

                ___________________________________________________________
                Do You Yahoo!?
                Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
              • yann gouy
                Hi, ... after a quick look, it s that the talkers are similar, they are just different in the initialisation of the stack, the SCI registers an,d the registers
                Message 7 of 11 , May 27, 2000
                  Hi,

                  > A task that I'd love someone else to volunteer for
                  > is to "diff" the various
                  > disassembled talkers and produce a generic assembly
                  > version with conditional
                  > compilation for the various targets.

                  after a quick look, it's that the talkers are similar,
                  they are just different in the initialisation of the
                  stack, the SCI registers an,d the registers base
                  address.

                  The talkers
                  > from Dickens are there too
                  > and they're slightly different, but I haven't worked
                  > out how or why.

                  they are different only in the RAMWT and RAMRD
                  sub-routines that don't exist, they are "inline" in
                  the code. that means the code is quicker.

                  I've made a try to assemble the talkers, it works fine
                  except 2 warnings about unterminated constant string I
                  can't figure out.

                  It will be very easy to implement multi-chip talkers,
                  they 'll only differ by the headers, the rest of the
                  code is the same.

                  bye


                  =====
                  Yann

                  La Terre est le berceau de l'Humanite,
                  mais nul ne reste eternellement dans son berceau.
                  Tchleskovsky
                  (inventeur du principe de la fusee a reaction)
                  (pere spirituel de Youri Gagarine)

                  ___________________________________________________________
                  Do You Yahoo!?
                  Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
                • Clifford Heath
                  ... The A and E are virtually identical, but some of the others have bigger differences. Talkd uses $3000 but I don t see any code that sets that - is this
                  Message 8 of 11 , May 28, 2000
                    > after a quick look, it's that the talkers are similar,
                    > they are just different in the initialisation of the
                    > stack, the SCI registers an,d the registers base
                    > address.

                    The 'A and 'E are virtually identical, but some of the others have
                    bigger differences. Talkd uses $3000 but I don't see any code
                    that sets that - is this a config register setting or is this chip
                    genuinely different? Talkea and talked use an external ACIA I
                    think. Talkk has bigger differences - is the bootmode vector table
                    at the start of memory instead of $C4?

                    > [Dickens' talkers] are different only in the RAMWT and RAMRD

                    Fair enough. My comment in the code says "why is this a sub?"...

                    > I've made a try to assemble the talkers, it works fine except 2
                    > warnings about unterminated constant string I can't figure out.

                    Strange, I don't get those. Do they come when assembling talke.s?

                    > It will be very easy to implement multi-chip talkers, they'll
                    > only differ by the headers, the rest of the code is the same.

                    Yes. We need to extend the talkers to have EEPROM and EPROM
                    capability built in. Once we know how and why the Motorola talkers
                    differ, we'll have a generic extended version. A TalkerEE was
                    published recently that copies programming code from ROM to RAM,
                    that could be useful. It'd be nice if we could squeeze it back
                    into 256 bytes though... I think that the memory map shouldn't be
                    built in to the talker, rather there should be separate write-RAM
                    and write-ROM commands (and RAM-based parameters for time-out, ELAT
                    address and bitmask). In other words I'm not committed to using
                    the PCBug11 protocol, just in learning from the implementations.

                    --
                    Clifford Heath, Open Software Associates, Ph +613 9895 2194, Fax 9895 2020
                    56-60 Rutland Rd (or PO Box 625), Box Hill 3128, Melbourne, VIC, Australia.
                    mailto:cjh@... http://www.osa.com.au/~cjh
                  • yann gouy
                    ... after a quick look, it s that the talkers are ... yes, it is! but i was wrong, there are mainly 2 families of talkers: - those where the SCI is
                    Message 9 of 11 , May 29, 2000
                      --- Clifford Heath <cjh@...> a écrit : > >
                      after a quick look, it's that the talkers are
                      > similar,
                      > > they are just different in the initialisation of
                      > the
                      > > stack, the SCI registers an,d the registers base
                      > > address.
                      >
                      > The 'A and 'E are virtually identical, but some of
                      > the others have
                      > bigger differences. Talkd uses $3000 but I don't
                      > see any code
                      > that sets that - is this a config register setting
                      > or is this chip
                      > genuinely different? Talkea and talked use an
                      > external ACIA I
                      > think. Talkk has bigger differences - is the
                      > bootmode vector table
                      > at the start of memory instead of $C4?

                      yes, it is!

                      but i was wrong, there are mainly 2 families of
                      talkers:
                      - those where the SCI is interrupt-driven,
                      - those where the SCI is polled.

                      the problem is I haven't understand the way the vector
                      table is used when SCI is polled. if the instruction
                      "jmp xx" is absolute jump, it refers to incorrect
                      address. if it refers to differential address, it is
                      not more correct.

                      >
                      > > [Dickens' talkers] are different only in the RAMWT
                      > and RAMRD
                      >
                      > Fair enough. My comment in the code says "why is
                      > this a sub?"...
                      >

                      in the code, I've made from yours, the 2 sub have
                      disappeared. let see in the joined file.

                      > Strange, I don't get those. Do they come when
                      > assembling talke.s?

                      don't care, it was when I use cpp to make some
                      #include, but no longer use.

                      > Yes. We need to extend the talkers to have EEPROM
                      > and EPROM
                      > capability built in. Once we know how and why the
                      > Motorola talkers
                      > differ, we'll have a generic extended version. A
                      > TalkerEE was
                      > published recently that copies programming code from
                      > ROM to RAM,
                      > that could be useful. It'd be nice if we could
                      > squeeze it back
                      > into 256 bytes though... I think that the memory
                      > map shouldn't be
                      > built in to the talker, rather there should be
                      > separate write-RAM
                      > and write-ROM commands (and RAM-based parameters for
                      > time-out, ELAT
                      > address and bitmask). In other words I'm not
                      > committed to using
                      > the PCBug11 protocol, just in learning from the
                      > implementations.
                      >

                      sure, the memory-map mustn't be in the talker, nor the
                      eeprom interface. I believe the simpler the talker,
                      the more generic it will be.

                      furthermore, when looking to pcbug11, we have to
                      mention that eeprom regions are given to it and
                      writing to eeprom is driven by pcbug11. why? I believe
                      because waiting for 10 ms is far more easy implemented
                      on the PC side that on the MCU side (mine is running a
                      16 MHz quartz, even SCI boot speed is unusual)

                      bye


                      =====
                      Yann

                      La Terre est le berceau de l'Humanite,
                      mais nul ne reste eternellement dans son berceau.
                      Tchleskovsky
                      (inventeur du principe de la fusee a reaction)
                      (pere spirituel de Youri Gagarine)

                      ___________________________________________________________
                      Do You Yahoo!?
                      Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
                    • Clifford Heath
                      ... I m not sure what you mean here. If SCI is not using interrupts, does it matter what the vector points to? ... Well, I was thinking of having a generic
                      Message 10 of 11 , May 29, 2000
                        > the problem is I haven't understand the way the vector
                        > table is used when SCI is polled. if the instruction
                        > "jmp xx" is absolute jump, it refers to incorrect
                        > address. if it refers to differential address, it is
                        > not more correct.

                        I'm not sure what you mean here. If SCI is not using interrupts,
                        does it matter what the vector points to?

                        > sure, the memory-map mustn't be in the talker, nor the
                        > eeprom interface.

                        Well, I was thinking of having a generic write-ROM command
                        that does "prepare-to-store", "program-byte", "delay",
                        "finish-store" operations, allowing the action of those four
                        commands to be customised (by writing RAM previously) to support
                        EPROM/EEPROM/external flash/etc. But I can see the advantage
                        of what you're saying.

                        Another thing, perhaps the SWI interrupt only needs to return
                        the SP instead of all registers, and read-memory can do the
                        rest?

                        We'll still need a read-memory-block operation, but perhaps it
                        will be more compact to do write-RAM in two separate operations,
                        write-16 and write-1 (for example).

                        > I believe the simpler the talker, the more generic it will be.

                        Agree. I'd like to avoid nesting interrupts the way the talkers
                        do, nesting SCI interrupts inside SWI ones. I'm happy if the
                        program uses SCI interrupts, and I'm also happy if the talker
                        does - but only to interrupt the program. Once inside the talker
                        code, the SCI should be polled. That means that "continue" must
                        re-enable SCI interrupts if they were disabled.

                        > furthermore, when looking to pcbug11, we have to
                        > mention that eeprom regions are given to it and
                        > writing to eeprom is driven by pcbug11. why? I believe
                        > because waiting for 10 ms is far more easy implemented
                        > on the PC side that on the MCU side (mine is running a
                        > 16 MHz quartz, even SCI boot speed is unusual)

                        Ok, so the delay loop would contain an SCI-poll waiting for a
                        non-null byte - use null bytes to create the timing, so that
                        accurate 2ms delays can be used for EPROM. That's nice, because
                        you can create a "EPROM write byte" packet as a series of
                        commands with null bytes interspersed for delays. The whole
                        packet gets written at one time.

                        --
                        Clifford Heath, Open Software Associates, Ph +613 9895 2194, Fax 9895 2020
                        56-60 Rutland Rd (or PO Box 625), Box Hill 3128, Melbourne, VIC, Australia.
                        mailto:cjh@... http://www.osa.com.au/~cjh
                      • yann gouy
                        ... problem is I haven t understand the way the ... ok, but what about SWI? ... yes, it s a good idea. this way, we only get the main information but it s
                        Message 11 of 11 , May 29, 2000
                          --- Clifford Heath <cjh@...> a écrit : > > the
                          problem is I haven't understand the way the
                          > vector
                          > > table is used when SCI is polled. if the
                          > instruction
                          > > "jmp xx" is absolute jump, it refers to incorrect
                          > > address. if it refers to differential address, it
                          > is
                          > > not more correct.
                          >
                          > I'm not sure what you mean here. If SCI is not using
                          > interrupts,
                          > does it matter what the vector points to?
                          >

                          ok, but what about SWI?

                          >
                          > Another thing, perhaps the SWI interrupt only needs
                          > to return
                          > the SP instead of all registers, and read-memory can
                          > do the
                          > rest?

                          yes, it's a good idea. this way, we only get the main
                          information but it's enough to obtain the whole set of
                          registers, it's quicker (less bytes via SCI) and the
                          talker will be smaller.

                          >
                          > We'll still need a read-memory-block operation, but
                          > perhaps it
                          > will be more compact to do write-RAM in two separate
                          > operations,
                          > write-16 and write-1 (for example).

                          you mean 16 bytes and 1 byte.
                          I don't know if it is so useful. why not keeping the
                          general format of frames: Type, Length, Value(s).


                          > Agree. I'd like to avoid nesting interrupts the way
                          > the talkers
                          > do, nesting SCI interrupts inside SWI ones. I'm
                          > happy if the
                          > program uses SCI interrupts, and I'm also happy if
                          > the talker
                          > does - but only to interrupt the program. Once
                          > inside the talker
                          > code, the SCI should be polled. That means that
                          > "continue" must
                          > re-enable SCI interrupts if they were disabled.
                          >

                          OK, so we must implement a talker that polls the SCI
                          and that only use the SWI as an interrupt

                          > Ok, so the delay loop would contain an SCI-poll
                          > waiting for a
                          > non-null byte - use null bytes to create the timing,
                          > so that
                          > accurate 2ms delays can be used for EPROM.

                          no, I think :
                          - write-commands to program the eeprom interface
                          (EELAT, EPROG, ...) just the way a convential program
                          should.
                          - a write-command to give the data to be written to
                          the talker
                          - the PC waits for a certain amount of milli-second
                          (minus the time to send and received datas to/from the
                          talker to be very accurate) then send write-commands
                          to stop the eeprom programming.

                          That's
                          > nice, because
                          > you can create a "EPROM write byte" packet as a
                          > series of
                          > commands with null bytes interspersed for delays.
                          > The whole
                          > packet gets written at one time.
                          >

                          I think 1 simple command are missing:
                          - "bsr address" to execute a pluging you have
                          downloaded. by pluging, I mean write-eeprom routine,
                          write-flash routine and so on, what ever you need.

                          bye


                          =====
                          Yann

                          La Terre est le berceau de l'Humanite,
                          mais nul ne reste eternellement dans son berceau.
                          Tchleskovsky
                          (inventeur du principe de la fusee a reaction)
                          (pere spirituel de Youri Gagarine)

                          ___________________________________________________________
                          Do You Yahoo!?
                          Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
                        Your message has been successfully submitted and would be delivered to recipients shortly.