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

RE: [cosmacelf] Re: Programming Help

Expand Messages
  • William Waters
    Tony, Your first guess is correct. I wish to locate many programs in EPROM, then move any one of the images to location 0x0000 for execution. No changes are
    Message 1 of 13 , Aug 31, 2003
    • 0 Attachment
      Tony,

      Your first guess is correct. I wish to locate many programs in EPROM, then
      move any one of the images to location 0x0000 for execution. No changes are
      to be made, this would be simpler and faster than using the tape interface.
      And yes, I have 2 working Netronics ELF-II systems, One is an original and
      working unit with 2 home-brew memory cards supporting 48K of mixed RAM/EPROM
      and the other unit is homebrew but built to the Netronics design, sort-a,
      with a 32K EPROM in the high half of address space and 16K of RAM...

      A full featured Relocation program would be the ultimate, but life does not
      allow me the time to learn the 1802 and assembler to that level of
      expertise, thus the quest to find an existing program that will work. The
      referenced program does support a simple block move mode which is all I
      need.

      Thanks

      Will


      -----Original Message-----
      From: sbirdasn [mailto:sbirdasn@...]
      Sent: Sunday, August 31, 2003 6:57 PM
      To: cosmacelf@yahoogroups.com
      Subject: [cosmacelf] Re: Programming Help


      Will,

      Exactly what is your requirement for code movement, and where is the
      problem?

      I will assume that you have a working ELF and its monitor program
      running.

      Let's assume that your real goal is to have a bunch of mutually
      exclusive programs that all run in "zero page", but you don't want to
      hand enter them each time.

      If that is the case, then the program you're using won't solve your
      problem directly from my quick scan of the listing. The code you
      posted is meant to do mild pushing of code snippits around and
      automaticly patch the branches that it finds along the way. The
      problem is that everything else is left unchanged, such as register
      initializations. So it's utility is fairly minimal.

      For instance, any code that uses a "programmed" addressing mode will
      not be changed, and thus will be rendered useless until corrected.

      The best way to do what I'm assuming you want is to place "images" of
      each program you want to use in the eprom at a known address (but
      assembled to be run at location $0000). Then copy that code from the
      ROM address to location $0000, ready to run. The key here is to
      not "touch" the program's built in branches or other data structures
      in any way, since the code as stored in the EPROM will not run at the
      location it is permanently stored at, thus requiring the copy
      operation to use the desired program.

      If my guess is correct, then you want to make a somewhat simpler
      version of the listed program that only knows how to copy memory
      chunks from one address to another *without* modifying it in any way.

      That will take some changes to the code to remove the unwanted
      functionality. You also need to figure out how to transfer control
      from the ELF monitor to the copy routine while taking note of what PC
      the monitor code is using and any other register resources that might
      conflic with the transfer of control from the ELF monitor to the
      memory move routine.

      Well, that or simply enter a long jump at address $0000 to a special
      piece of bootstrap code that will change the PC from R0 to R3 (or
      whatever PC is used by the memory move routine) before starting to
      run the relocation code that is going to do the job of copying
      programs.

      If you're really going to store programs in EPROM, why not totally
      automate the process. Decide on a table structure that will contain
      the location of the program code in ROM, and the required target
      address to copy it to, and then make sure that the desired code is
      present ready to run as copied. Then make a small piece of data entry
      code that will allow you to enter an index into the list of available
      programs to be copied, and then look up the offset into the structure
      array for the required parameters to control the copy process.

      The structure table only needs three words, containing source
      address, destination address, and number of bytes to copy. If you
      waste a bit of space and skip a fourth word, you can take the raw
      index entry, multipy by 8 (shift left 4X) and use it directly as an
      indexed offset into the copy parameter table.

      If you really want to have warm fuzzy feelings, use that fourth word
      to store a two-byte checksum of the program and verify that the copy
      came out right at the specified RAM. Then give some indication to the
      user of the status of the copy operation.

      The moral of the story is that lots of 1802 code is not easily
      relocatable by a simple search and replace algorithum. Also, lots of
      code can only be easily moved on page increments. Because the 1802
      doesn't have true relative branches, short branches get broken when
      the branch instruction and destination addresses are in seperate
      pages. Well, more precisely, THE PAGE THAT THE BRANCH CAN REACH IS
      DETERMINED BY THE PAGE CONTAINING THE SECOND BYTE OF THE BRANCH
      INSTRUCTION (branch address). Therefore, if a branch (short)
      straddles two pages, the branch will be to the address of the second
      page, not the first. (Oh, remember that a long branch has no such
      limitations.)

      Hope this helps.

      Tony Naef.

      --- In cosmacelf@yahoogroups.com, "William Waters" <engineer1@s...>
      wrote:
      > In my quest to get my recreated Netronics ELF-II to function as I
      had
      > planned, I will store the many programs in EPROM, and plan to copy
      a
      > program that I am wanting to run down into SRAM. Member Scott
      > LaBombard sent me a scanned image of a program by Enos Jones out of
      > the Questdata publication, Volume: 2, Issue 12 called "Relocator".
      >
      > Among other functions, this program will do block moves from one
      > memory location to another. My plan is to place the "Relocator"
      > program in memory at 0xF400, and have the Stack start location
      below
      > 0x4000 (top of SRAM). I would enter "Relocator" from the
      > Netronics Monitor located at 0xF000. Try as I have, I have not
      been
      > able to get the program to work. I am using an ER3 EPROM Emulator
      > that allows making changes to the binary image `on-the-fly', thus
      > I don't have to burn EPROMs to try the changes.
      >
      > Though I have done extensive assembly code work in the past, it has
      > not been with the 1802, so the many features of this processor I
      > still lack knowledge of. I have tried changing the stack location,
      > and the register values that reference functions, but the program
      > runs wild. The listing notes that the PC is assumed to be R3, so I
      > tried setting the values in R3 prior to program execution, but
      still
      > no go. I have uploaded the .pdf to the files section under "Elf
      > Programs" with the file name of "ElfReloc.pdf". If one of the
      > members could guide me on what needs to be changed to get this
      > program running at the new memory locations, that would be GREAT.
      >
      > Again, the program is to reside starting at 0xF400, with the stack
      > located below 0x4000. Photos of this project can be seen in the
      > Photos section of the users group under `Wills ELF Projects",
      > where there are photos of my Original Netronics ELF-II project and
      > the smaller copy of the same.
      >
      > Thanks for the help!!
      >
      > Will
      > engineer1@s...



      ========================================================
      Visit the COSMAC ELF website at http://www.cosmacelf.com, or view the
      Wiki/FAQ at http://1802.bitting.com/

      To unsubscribe from this group, send an email to:
      cosmacelf-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • sbirdasn
      Will, Here s a little something I hammered out that will do the job nicely. It even does some rudimentry user input checking, patterned after the original elf.
      Message 2 of 13 , Sep 1, 2003
      • 0 Attachment
        Will,

        Here's a little something I hammered out that will do the job nicely.
        It even does some rudimentry user input checking, patterned after the
        original elf. If your elf hardware has different input hardware,
        you'll have to adjust this code to match.

        I'm too lazy to really put it into a form that will assemble with one
        of the cross assemblers, but it is so simple you can just hand code
        it if you want to. That's your cost for getting "free code".

        One note, the RCA assembler uses the A(symbol) format to supply as
        the parameter a 16-bit address value. Therefore, seeing A.0(symbol)
        is like supplying the LSB of the word address to the assembler for
        use in the instruction. It's really like the official data sheets
        when they describe instruction behavior.

        Have fun.

        Tony Naef.

        ;test memory move routine
        ;
        ;assumptions: R0 is PC (jump to routine from 0000 long branch),
        ;OR -- any PC other than R2, RC, RD, RE, RF
        ;Use your own judgement on how to call this simple routine.
        ;R2 is stack, this code as written places it at the end of 16K
        ;uses 4 scratch pad registers,
        ;RC = Index table pointer
        ;RD = Source address
        ;RE = Destination address
        ;RF = total number of bytes to move.
        ;
        ;Routine is stupid, no checking for block overlap is done.
        ;
        ;There is even a copy verification check via checksum listed in table
        ;
        ;Note: Many of the notations are standard RCA style assembly format.
        ;Comments are a cross between the two.
        ;

        STACK EQU 03FFH

        ORG 0F400H

        MOVE_ENTRY:

        LDI A.1(STACK) ..initialize stack
        PHI R2
        LDI A.0(STACK)
        PLO R2

        LDI A.1(TBL_BASE) ..set lookup table base address
        PHI RB
        LDI A.0(TBL_BASE)
        PLO RC

        SEX R2

        WAIT:
        BN4 WAIT ..elf style I/O for a two-digit entry of
        table index

        IN 4
        OUT 4 ..show what was typed to user.
        DEC R2

        WAIT1:
        B4 WAIT1 ..wait for input switch released

        SHL ..index is entered as 0,1,2,3...
        SHL ..this adjusts for table entries taking 8
        bytes
        SHL ..for each program stored in ROM

        STR R2 ..put index on stack for doing math with.

        SDI A.0(TBL_END - TBL_BASE) ..check for value larger than
        table size
        BM WAIT ..get new index value if too big for table.
        ..max size is 256 bytes, or 32 entries.

        GLO RC
        ADD
        PLO RC
        GHI RC
        ADCI #0
        PHI RC

        LDA RC ..load source address from table
        PHA RD
        LDA RC
        PLO RD

        LDA RC ..load destination address from table
        PHA RE
        LDA RC
        PLO RE

        LDA RC ..load byte count to be moved.
        PHA RF
        LDN RC ..we will be rolling back on table later
        PLO RF

        MOVE:
        LDA RD ..copy block from source to destination
        STR RE
        INC RE
        DEC RF ..keep track of bytes moved

        GLO RF ..when count goes to zero, we're done
        BNZ MOVE
        GHI RF ..16-bit resolution, useful size is <16K
        BNZ MOVE ..You can put a branch forever here or
        something
        ..to return control to caller here.
        ..the rest is an optional checksum
        calculation.

        DEC RC ..re-point to destination, and size in table
        DEC RC
        DEC RC

        LDA RC ..now the destination address is the "source"
        PHI RD ..for the checksum calculations
        LDA RC
        PLO RD

        LDA RC ..get the block size moved to control the loop
        PHI RF
        LDA RC
        PLO RF

        SEX RD ..index to copied program bytes

        LDN #0 ..clear checksum
        PHI RE
        PLO RE

        ADD_BYTE:
        GLO RE ..calculate running 16-bit sum of all bytes,
        ADD
        INX
        PLO RE
        BNF NO_CARRY
        GHI RE ..carries increment high address too
        ADCI #0
        PHI RE

        NO_CARRY:
        DEC RF ..see if all bytes added yet

        GLO RF
        BNZ ADD_BYTE
        GHI RF
        BNZ ADD_BYTE

        SEX RC ..we left table pointer at the checksum,

        GHI RF ..logical operations use R(X) for one operand
        XOR
        BNZ BADCOPY ..a perfect match will be 0000h
        INX ..get LSB of result
        GLO RF
        XOR
        BNZ BADCOPY

        REQ ..make sure Q is off if good compare.

        SHOWBYTE:
        SEX R2 ..a perfect match will have 00h sent to display

        STR R2 ..any other value indicates bad checksum compare.
        OUT 4
        DEC R2

        STOP:
        BR STOP

        BADCOPY:
        SEQ ..a second indication that something's wrong.
        BR SHOWBYTE

        TBL_BASE: ..table format is 4 words, high order
        address first.
        DW A(PROG1) ..source address of program to be moved
        DW A(0000H) ..destination address
        DW A(PROG1END-PROG1) ..size of block to be moved.
        DW 1234H ..optional 16-bit checksum

        DW A(PROG2)
        DW 0100H
        DW A(PROG2END-PROG2)
        DW 4321H

        .. repeat for all programs that can be moved...

        TBL_END:

        ORG 9000H ..an arbitrary place to store the programs in
        ROM.

        PROG1:
        DB nn nn nn nn ..raw code listing assembled for desired
        target address.
        DB nn nn nn nn
        PROG1END:

        PROG2:
        DB nn nn nn nn ..raw code listing assembled for desired
        target address.
        DB nn nn nn nn
        PROG2END:

        ..Lather, rinse, repeat...



        --- In cosmacelf@yahoogroups.com, "William Waters" <engineer1@s...>
        wrote:
        > Tony,
        >
        > Your first guess is correct. I wish to locate many programs in
        EPROM, then
        > move any one of the images to location 0x0000 for execution. No
        changes are
        > to be made, this would be simpler and faster than using the tape
        interface.
        > And yes, I have 2 working Netronics ELF-II systems, One is an
        original and
        > working unit with 2 home-brew memory cards supporting 48K of mixed
        RAM/EPROM
        > and the other unit is homebrew but built to the Netronics design,
        sort-a,
        > with a 32K EPROM in the high half of address space and 16K of RAM...
        >
        > A full featured Relocation program would be the ultimate, but life
        does not
        > allow me the time to learn the 1802 and assembler to that level of
        > expertise, thus the quest to find an existing program that will
        work. The
        > referenced program does support a simple block move mode which is
        all I
        > need.
        >
        > Thanks
        >
        > Will
        >
      • joshbensadon
        Will, ... program ... then ... This code will branch you to 0xF0F4, is that where you want to go? Where is this relocator? Here, try this code... I entered it
        Message 3 of 13 , Sep 1, 2003
        • 0 Attachment
          Will,


          > I then attempted placing a small patch of code at 0xF4F0 to set the
          program
          > counter to R3 as the program assumes it to be already set. I would
          then
          > execute the program by jumping to F4F0 from the Monitor ROM.
          >
          > F4F0 F8 F4 A3 R3.0 = F4
          > F4F3 F8 F0 B3 R3.1 = F0
          > F4F6 D3 PC = R3

          This code will branch you to 0xF0F4, is that where you want to go?
          Where is this relocator?
          Here, try this code... I entered it in HEX, your favorite.
          It's the same code I posted earlier, except this time
          in machine language. It basically moves memory to ram until
          16k ram is full. It does not modify any code along the way.
          The table must start at xx00, but the stored programs can
          start at any location. Jump to FFE6 to run it.
          Change FFEA to any page to relocate this code.


          .org $FF00
          FF00 80 00 pgmtable .dw $8000 start of program 0
          FF02 82 00 .dw $8200 start of program 1
          FF04 86 45 .dw $8645 start of program 2
          ... etc

          .org $FFE6
          FFE6 6C inp 4
          FFE7 FE shl ;x2 for address words
          FFE8 AD plo rd ;Table must start at xx02
          FFE9 F8 FF ldi pgmtable/256 ;rD points to table
          FFEB BD phi rd

          ;set starting write address
          FFEC F8 00 ldi 0 ;Write to 0000
          FFEE AE plo rE
          FFEF BE phi rE ;rE points to destination

          FFF0 4D lda rd ;get address of first 2 pages
          FFF1 BC phi rc
          FFF2 4D lda rd
          FFF3 AC plo rc ;rC points to source

          FFF4 4C RRLoop lda rc ;read a source byte (and advance)
          FFF5 5E str rE ;write a destination byte
          FFF6 1E INC rE ;(and advance)
          FFF7 9E ghi rE ;Test for end of RAM
          FFF8 FE shl ;x2
          FFF9 FE shl ;x4 for 16K ram check
          FFFA 3B F4 bnf RRLoop
          FFFC C0 00 00 lbr 0000


          > The above did not seam to work either. I do not have original
          binary or any
          > better than what was in the .PDF.

          What are you programming your eeprom with?

          Anyway,
          Good luck, the code is as small and simple as possible.
          Josh
        • William Waters
          Josh, First off I must say thanks so very much for the help. I spent the afternoon experimenting with the code you sent. For whatever reason I had a few
          Message 4 of 13 , Sep 1, 2003
          • 0 Attachment
            Josh,

            First off I must say thanks so very much for the help.

            I spent the afternoon experimenting with the code you sent. For whatever
            reason I had a few problems getting it to work, but came up with the below
            solution that seams to work just fine.

            I added the following:

            FFC0 F8 C7 A3 ; set up R3
            FFC3 F8 FF B3 ;
            FFC6 D3 ; set R3 as PC
            FFC7 3F ; wait for In press
            FFC8 C7
            FFC9 37 ; wait for In release
            FFCA C9
            FFCB 30 D3 ; jump to program
            ....
            FFD3 7B ; set Q for Effect
            ....
            Added 2 additional FE (shl) in the loop such that the program moves only 4K
            into RAM (this should work, right???).
            ....
            Added 7A 00 ; Clear Q and just sit there

            A cycle of the 'RUN' switch and the program is at 0x0000 ready to run.

            So far I have tested the Netronics Tiny Basic and TMSI Tiny Basic and both
            relocate down to RAM and both Run Fine.

            All I have to work with are the document "A Short Course in Programming" by
            Tom Pittman, an original blue RCA 1800 Instruction Summary card, and source
            listings of various programs. The programming Guide to the 1802 sure would
            be handy. I have spent many years writing assembly code for the Zilog Z8
            microcontroller family, but the 1802 is quite a bit different.

            To answer your question, my EPROM program is a Needham's Electronics EMP-20,
            and the Emulator is an ER3 EconoRom-III by Tech-Tools.

            I will continue 'tinkering' with your move program and get my final EPROM
            loaded with the applications next.

            Thanks again!!!

            Will
            -----Original Message-----
            From: joshbensadon [mailto:joshbensadon@...]
            Sent: Monday, September 01, 2003 7:51 AM
            To: cosmacelf@yahoogroups.com
            Subject: [cosmacelf] Re: Programming Help


            Will,


            > I then attempted placing a small patch of code at 0xF4F0 to set the
            program
            > counter to R3 as the program assumes it to be already set. I would
            then
            > execute the program by jumping to F4F0 from the Monitor ROM.
            >
            > F4F0 F8 F4 A3 R3.0 = F4
            > F4F3 F8 F0 B3 R3.1 = F0
            > F4F6 D3 PC = R3

            This code will branch you to 0xF0F4, is that where you want to go?
            Where is this relocator?
            Here, try this code... I entered it in HEX, your favorite.
            It's the same code I posted earlier, except this time
            in machine language. It basically moves memory to ram until
            16k ram is full. It does not modify any code along the way.
            The table must start at xx00, but the stored programs can
            start at any location. Jump to FFE6 to run it.
            Change FFEA to any page to relocate this code.


            .org $FF00
            FF00 80 00 pgmtable .dw $8000 start of program 0
            FF02 82 00 .dw $8200 start of program 1
            FF04 86 45 .dw $8645 start of program 2
            ... etc

            .org $FFE6
            FFE6 6C inp 4
            FFE7 FE shl ;x2 for address words
            FFE8 AD plo rd ;Table must start at xx02
            FFE9 F8 FF ldi pgmtable/256 ;rD points to table
            FFEB BD phi rd

            ;set starting write address
            FFEC F8 00 ldi 0 ;Write to 0000
            FFEE AE plo rE
            FFEF BE phi rE ;rE points to destination

            FFF0 4D lda rd ;get address of first 2 pages
            FFF1 BC phi rc
            FFF2 4D lda rd
            FFF3 AC plo rc ;rC points to source

            FFF4 4C RRLoop lda rc ;read a source byte (and advance)
            FFF5 5E str rE ;write a destination byte
            FFF6 1E INC rE ;(and advance)
            FFF7 9E ghi rE ;Test for end of RAM
            FFF8 FE shl ;x2
            FFF9 FE shl ;x4 for 16K ram check
            FFFA 3B F4 bnf RRLoop
            FFFC C0 00 00 lbr 0000


            > The above did not seam to work either. I do not have original
            binary or any
            > better than what was in the .PDF.

            What are you programming your eeprom with?

            Anyway,
            Good luck, the code is as small and simple as possible.
            Josh




            ========================================================
            Visit the COSMAC ELF website at http://www.cosmacelf.com, or view the
            Wiki/FAQ at http://1802.bitting.com/

            To unsubscribe from this group, send an email to:
            cosmacelf-unsubscribe@yahoogroups.com



            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          • joshbensadon
            Will, Excellent! ... Great idea! Light effects :) Perhaps you could add a 64 right after the 6C for more effects? ... only 4K ... Now you re getting into it!
            Message 5 of 13 , Sep 2, 2003
            • 0 Attachment
              Will,

              Excellent!

              > FFD3 7B ; set Q for Effect

              Great idea! Light effects :)
              Perhaps you could add a 64 right after the 6C for more effects?

              > Added 2 additional FE (shl) in the loop such that the program moves
              only 4K
              > into RAM (this should work, right???).

              Now you're getting into it! :)
              Alternatively, you could use
              FA 10 And Immediate with 10
              32 xx Jump if Zero
              This would save you 2 bytes (4 machine cycles), not that it
              really matters but more for getting you thinking. I use just
              one shift, that saves me 1 byte (which I really need because
              I crammed this routine into a small free spot in my RS-232
              monitor program). Two shifts, and you're breaking even
              with the "And Immediate" solution.

              > "A Short Course in Programming" by Tom Pittman,

              That's a great document, you don't need much more.
              I suggest you look back on the messages and find
              the thread about Calling Subroutines.

              > but the 1802 is quite a bit different.

              Yes, the 1802 marches to the beat of it's own drum.

              > Thanks again!!!


              You're very welcome, I look forward to hearing more about
              your success in the comming weeks/months?
              This is only a hobby for the most part, right?

              Regards,
              Josh

              PS. I've not done any work with the Z8. The processors
              I've done a lot of work on are 68HC11, 8051, PIC16x, PIC12x.
              Some work on 8085, 8088, Z80, 6809
            Your message has been successfully submitted and would be delivered to recipients shortly.