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

Early version of C Compiler for 1802 available

Expand Messages
  • ted_rossin
    I ve always wanted to figure out how to write a compiler. I started on this project a few years back for PIC processors then stopped working on it. I picked
    Message 1 of 18 , Oct 12, 2007
    • 0 Attachment
      I've always wanted to figure out how to write a compiler. I started
      on this project a few years back for PIC processors then stopped
      working on it. I picked it up again this spring with a new target
      (the 1802) and it now seems to work well enough that I thought I
      might share it with the group.

      You can pick up the compiler, assembler and simulator here:

      http://www.geocities.com/ted_rossin/Electronics/RCA/RCA.html

      My web page explains the limitations but not in great detail. This
      is an early version but I thought I should get it out there so folks
      can give me feed back on what features they need in order to be able
      to use it. It does not produce the best code in the world (it never
      will) but I hope to improve the code generator once I get all the
      main features of the language implemented.

      The web page also has a zip file with some example programs to flash
      LEDs and draw some graphics using the 1861. It just feels wrong to
      code in C for the 1802 but it is fun.

      The web only has code for Windows but I plan to put out code for
      Linux soon. It works on Debian. I just have not taken the time to
      figure out if I compile it on Debian if it will run on other
      distributions.

      Let me know what you think.
    • Patrick Draper
      ... Generally speaking if you want to provide wide binary compatibility on Linux, you find an old distribution and compile it there. It doesn t need to be too
      Message 2 of 18 , Oct 16, 2007
      • 0 Attachment
        On Fri, Oct 12, 2007 at 09:01:37PM -0000, ted_rossin wrote:
        > Linux soon. It works on Debian. I just have not taken the time to
        > figure out if I compile it on Debian if it will run on other
        > distributions.

        Generally speaking if you want to provide wide binary compatibility
        on Linux, you find an old distribution and compile it there.

        It doesn't need to be too old, just old enough. I have a SuSE 9
        distribution that I will never update which I use for a build
        environment. The binaries run just about everywhere I try them.

        --
        Patrick Draper |Don't |sig3@...
        Austin, Texas |Fear |Father Order runs at a
        http://www.pdrap.org |The |good pace, but old Mother
        Be Microsoft Free - Use Linux|Penguin|Chaos is winning the race.
      • J.C. Wren
        Dude.... This is SO excellent! I ve always wanted a C compiler for the 1802. Time to start playing... --jc
        Message 3 of 18 , Oct 16, 2007
        • 0 Attachment
          Dude.... This is SO excellent! I've always wanted a C compiler for the
          1802. Time to start playing...

          --jc
        • J.C. Wren
          I ll be happy to test it under Gentoo for you. cause the fact that it s a .exe sorta turned out to be a problem. In the REAL world, computers don t run
          Message 4 of 18 , Oct 16, 2007
          • 0 Attachment
            I'll be happy to test it under Gentoo for you. 'cause the fact that
            it's a .exe sorta turned out to be a problem.

            In the REAL world, computers don't run .exe's... Then there's Windoze.

            --jc

            Patrick Draper wrote:
            > On Fri, Oct 12, 2007 at 09:01:37PM -0000, ted_rossin wrote:
            >
            >> Linux soon. It works on Debian. I just have not taken the time to
            >> figure out if I compile it on Debian if it will run on other
            >> distributions.
            >>
            >
            > Generally speaking if you want to provide wide binary compatibility
            > on Linux, you find an old distribution and compile it there.
            >
            > It doesn't need to be too old, just old enough. I have a SuSE 9
            > distribution that I will never update which I use for a build
            > environment. The binaries run just about everywhere I try them.
            >
            >


            [Non-text portions of this message have been removed]
          • ted_rossin
            The Linux version is now on the web. I compiled this on a Debian distribution. Also, both versions have been updated to allow single term post auto increment
            Message 5 of 18 , Oct 17, 2007
            • 0 Attachment
              The Linux version is now on the web. I compiled this on a Debian
              distribution. Also, both versions have been updated to allow single
              term post auto increment and auto decrement.

              Some examples:
              Result = Value++;

              // Implement simple delay
              Delay = 98;
              while(Delay--);

              Will not work:

              Result = 25 + Value++;

              I'm working on the multi-term case now.


              I'd like to figure out what it takes to produce a file that can be
              run under Elf OS. Off hand, it looks like it just wants a binary
              file with a 6 byte header:

              LoadStartHigh LoadStartLow
              LoadEndHigh LoadEndLow
              StartHigh StartLow

              My hope is that I can just make a minor change to the assembler to
              output this format. The only ugly area is that my compiler will
              create holes for variables that are not initialized. I may need to
              sort these out but my guess is that I can just fill in the
              uninitialized locations with zero.

              I'm not sure if registers need to be saved and restored by a
              program. I don't have a machine that can run Elf OS and just
              limited access to a Linux box so I've never used Elf OS. It looks
              very cool but I can't play.
            • rileym65
              Some Elf/OS information for you. The header is as follows 2 bytes - Load address, high byte first 2 bytes - Length of load image, high byte first. This is
              Message 6 of 18 , Oct 17, 2007
              • 0 Attachment
                Some Elf/OS information for you. The header is as follows

                2 bytes - Load address, high byte first
                2 bytes - Length of load image, high byte first. This is not the last
                address but a count of bytes to load
                2 bytes - Start address, high byte first.

                Normally programs are loaded at 2000h upwards. Elf/OS uses all memory
                below 2000h

                There are 2 methods you can use to return back to Elf/OS at the end of
                a program, either a jump to Elf/OS's cold boot address at 300h, at
                this address you do not need to preserve anything.

                2nd method is if the stack has been properly maintained and R4,R5, and
                R6 are properly maintained, then you can SRET back to Elf/OS.

                Mike

                --- In cosmacelf@yahoogroups.com, "ted_rossin" <ted_rossin@...> wrote:
                >
                > The Linux version is now on the web. I compiled this on a Debian
                > distribution. Also, both versions have been updated to allow single
                > term post auto increment and auto decrement.
                >
                > Some examples:
                > Result = Value++;
                >
                > // Implement simple delay
                > Delay = 98;
                > while(Delay--);
                >
                > Will not work:
                >
                > Result = 25 + Value++;
                >
                > I'm working on the multi-term case now.
                >
                >
                > I'd like to figure out what it takes to produce a file that can be
                > run under Elf OS. Off hand, it looks like it just wants a binary
                > file with a 6 byte header:
                >
                > LoadStartHigh LoadStartLow
                > LoadEndHigh LoadEndLow
                > StartHigh StartLow
                >
                > My hope is that I can just make a minor change to the assembler to
                > output this format. The only ugly area is that my compiler will
                > create holes for variables that are not initialized. I may need to
                > sort these out but my guess is that I can just fill in the
                > uninitialized locations with zero.
                >
                > I'm not sure if registers need to be saved and restored by a
                > program. I don't have a machine that can run Elf OS and just
                > limited access to a Linux box so I've never used Elf OS. It looks
                > very cool but I can't play.
                >
              • nils_eilers
                Thank you very much for that pretty thing, Ted! A C compiler for the 1802 is... without words! :-)) I use xubuntu 7.04 Linux and TedsElf runs fine with
                Message 7 of 18 , Oct 17, 2007
                • 0 Attachment
                  Thank you very much for that pretty thing, Ted!
                  A C compiler for the 1802 is... without words! :-))

                  I use xubuntu 7.04 Linux and TedsElf runs fine with wine-0.9.33.

                  cc1802 and asm1802 runs on xubuntu: I've compiled and tested some of your
                  examples and it all works!

                  I've written a "hello world" for the ascii-display - wow! great! :-)

                  Trying to download Clock.zip from your website gives "Sorry, the page
                  you requested was not found.", and trying to assemble Clock.txt with
                  asm1802 results in a core dump - why?

                  Nils
                • ted_rossin
                  Thanks for giving the compiler a try. Don t push too hard on it as it does not have many miles on it yet. The best advice I can give if you run into problems
                  Message 8 of 18 , Oct 18, 2007
                  • 0 Attachment
                    Thanks for giving the compiler a try. Don't push too hard on it as
                    it does not have many miles on it yet. The best advice I can give
                    if you run into problems with complex equations generating bad code
                    is to recode them with intermediate variables.

                    For example, Last night I found that this equation fails:

                    EndA = (StartA & 0xfff8) | ((Tmp>>3)&7);

                    It does the | operation on (Tmp>>3) before the & 7. I hope to have
                    this fixed soon.


                    Sorry about the problems with Clock. I uploaded clock.zip instead
                    of Clock.zip. That has been fixed. The problem with the source is
                    that it is missing a comma on the last line. I uploaded a fix for
                    the source as well. You can also just add a comma between '_' and '-
                    '. An older version of the assembler that did not do equations
                    handled this ok. Now it is pickier. I was not able to reproduce
                    the core dump. I just get and invalid equation error.

                    I ran with valgrind (the killer memory check tool) on Linux to see
                    if there is a memory problem and saw no problems. Bummer. Well, I
                    hope that with better source files this will not get in the way of
                    progress. I'll keep an eye out for it.

                    --- In cosmacelf@yahoogroups.com, nils_eilers <no_reply@...> wrote:
                    >
                    > Thank you very much for that pretty thing, Ted!
                    > A C compiler for the 1802 is... without words! :-))
                    >
                    > I use xubuntu 7.04 Linux and TedsElf runs fine with wine-0.9.33.
                    >
                    > cc1802 and asm1802 runs on xubuntu: I've compiled and tested some
                    of your
                    > examples and it all works!
                    >
                    > I've written a "hello world" for the ascii-display - wow! great! :-
                    )
                    >
                    > Trying to download Clock.zip from your website gives "Sorry, the
                    page
                    > you requested was not found.", and trying to assemble Clock.txt
                    with
                    > asm1802 results in a core dump - why?
                    >
                    > Nils
                    >
                  • ted_rossin
                    Hi Mike, In the Elf OS manual on the web there is an example which is where I got the 2nd 16-bit value was the end address: { HEXDUMP BAUD ... If you are
                    Message 9 of 18 , Oct 18, 2007
                    • 0 Attachment
                      Hi Mike,

                      In the Elf OS manual on the web there is an example which is where I
                      got the 2nd 16-bit value was the end address:

                      {"
                      HEXDUMP BAUD
                      :0000 20 00 20 05 20 00 9E 52 E2 64 22 D5

                      If you are familiar with 1802 opcodes, you will notice there are
                      more
                      bytes here than the original assembly program had. The assembler
                      adds a 6
                      byte header to the file. This header is called the execution header
                      and tells
                      Elf/OS where the program is to be loaded and where the exec address
                      is.
                      "}

                      Has the file format changed to this?

                      HEXDUMP BAUD
                      :0000 20 00 00 06 20 00 9E 52 E2 64 22 D5

                      Let me know which way is correct and I can add this output format to
                      the assembler. The compiler should work as is if it is given a
                      crazy big stack size to move the program out:

                      cc1802 -mem_config 0 -stack_size 0x2100 fun.c
                      or for 1861 video apps:
                      cc1802 -nlb -mem_config 3 -stack_size 0x2100 video4.c

                      Both of these will put the stack at location 0x2100 and have it grow
                      towards 0x2000. The first example should be run from location
                      0x2100 while the video4 example should be run from location 0x2300.
                      It will place video memory from 0x2100 to 0x22ff.

                      As far as jumping back to the OS, it seems that user code can add a
                      little function with some #asm #endasm code to do the jump to
                      0x300. But, I could add an option to do the jump at the end.
                      It also seems possible to restore the stack (R2),R4,R5 and R6 and
                      return back home to Elf/OS.

                      One day it would be nice to supply C function wrappers for all the
                      user level Elf/OS enty points. In this case the compiler would need
                      to save and restore some registers. It seems that I could add an
                      option to save the regs at start up in a private area and then have
                      the wrappers restore the regs before making the calls. I used R6
                      for a long jump subroutine (for the 1861 video -nlb mode) and used
                      R14 for the address passed to Call and LongJump so I just don't play
                      well with others. It doesn't seem too ugly to make this work and it
                      would make user level progams look pretty clean.



                      --- In cosmacelf@yahoogroups.com, rileym65 <no_reply@...> wrote:
                      >
                      > Some Elf/OS information for you. The header is as follows
                      >
                      > 2 bytes - Load address, high byte first
                      > 2 bytes - Length of load image, high byte first. This is not the
                      last
                      > address but a count of bytes to load
                      > 2 bytes - Start address, high byte first.
                      >
                      > Normally programs are loaded at 2000h upwards. Elf/OS uses all
                      memory
                      > below 2000h
                      >
                      > There are 2 methods you can use to return back to Elf/OS at the
                      end of
                      > a program, either a jump to Elf/OS's cold boot address at 300h, at
                      > this address you do not need to preserve anything.
                      >
                      > 2nd method is if the stack has been properly maintained and R4,R5,
                      and
                      > R6 are properly maintained, then you can SRET back to Elf/OS.
                      >
                      > Mike
                      >
                    • rileym65
                      The example in the documentation is wrong. The kernel uses bytes 2 and 3 as the count of bytes to load using the o_read function so these 2 bytes are
                      Message 10 of 18 , Oct 18, 2007
                      • 0 Attachment
                        The example in the documentation is wrong. The kernel uses bytes 2
                        and 3 as the count of bytes to load using the o_read function so
                        these 2 bytes are definitely a count of bytes to load and not the
                        ending address. note that this allows for the the resulting file to
                        be larger than will actually be loaded, which could be usefull for
                        storing additional data for a program or even overlay support.

                        Seems to me it should be easy for the compiler to add some startup
                        code to a compiled program and add extra variable space to store the
                        values of R2, R4, R5, and R6. Additionally depending on what terminal
                        device is being used, RE should also be stored (this is used by the
                        BIOS's default bit-banged serial device). otherwise a long jump to
                        the cold boot address will return control to Elf/OS, except that the
                        default directory will be the root directory instead of any
                        subdirectory that may have been at default.

                        If you need any help in dealing with Elf/OS calls...just let me know.

                        Mike

                        --- In cosmacelf@yahoogroups.com, "ted_rossin" <ted_rossin@...> wrote:
                        >
                        > Hi Mike,
                        >
                        > In the Elf OS manual on the web there is an example which is where I
                        > got the 2nd 16-bit value was the end address:
                        >
                        > {"
                        > HEXDUMP BAUD
                        > :0000 20 00 20 05 20 00 9E 52 E2 64 22 D5
                        >
                        > If you are familiar with 1802 opcodes, you will notice there are
                        > more
                        > bytes here than the original assembly program had. The assembler
                        > adds a 6
                        > byte header to the file. This header is called the execution header
                        > and tells
                        > Elf/OS where the program is to be loaded and where the exec address
                        > is.
                        > "}
                        >
                        > Has the file format changed to this?
                        >
                        > HEXDUMP BAUD
                        > :0000 20 00 00 06 20 00 9E 52 E2 64 22 D5
                        >
                        > Let me know which way is correct and I can add this output format to
                        > the assembler. The compiler should work as is if it is given a
                        > crazy big stack size to move the program out:
                        >
                        > cc1802 -mem_config 0 -stack_size 0x2100 fun.c
                        > or for 1861 video apps:
                        > cc1802 -nlb -mem_config 3 -stack_size 0x2100 video4.c
                        >
                        > Both of these will put the stack at location 0x2100 and have it grow
                        > towards 0x2000. The first example should be run from location
                        > 0x2100 while the video4 example should be run from location 0x2300.
                        > It will place video memory from 0x2100 to 0x22ff.
                        >
                        > As far as jumping back to the OS, it seems that user code can add a
                        > little function with some #asm #endasm code to do the jump to
                        > 0x300. But, I could add an option to do the jump at the end.
                        > It also seems possible to restore the stack (R2),R4,R5 and R6 and
                        > return back home to Elf/OS.
                        >
                        > One day it would be nice to supply C function wrappers for all the
                        > user level Elf/OS enty points. In this case the compiler would need
                        > to save and restore some registers. It seems that I could add an
                        > option to save the regs at start up in a private area and then have
                        > the wrappers restore the regs before making the calls. I used R6
                        > for a long jump subroutine (for the 1861 video -nlb mode) and used
                        > R14 for the address passed to Call and LongJump so I just don't play
                        > well with others. It doesn't seem too ugly to make this work and it
                        > would make user level progams look pretty clean.
                        >
                        >
                        >
                        > --- In cosmacelf@yahoogroups.com, rileym65 <no_reply@> wrote:
                        > >
                        > > Some Elf/OS information for you. The header is as follows
                        > >
                        > > 2 bytes - Load address, high byte first
                        > > 2 bytes - Length of load image, high byte first. This is not the
                        > last
                        > > address but a count of bytes to load
                        > > 2 bytes - Start address, high byte first.
                        > >
                        > > Normally programs are loaded at 2000h upwards. Elf/OS uses all
                        > memory
                        > > below 2000h
                        > >
                        > > There are 2 methods you can use to return back to Elf/OS at the
                        > end of
                        > > a program, either a jump to Elf/OS's cold boot address at 300h, at
                        > > this address you do not need to preserve anything.
                        > >
                        > > 2nd method is if the stack has been properly maintained and R4,R5,
                        > and
                        > > R6 are properly maintained, then you can SRET back to Elf/OS.
                        > >
                        > > Mike
                        > >
                        >
                      • nils_eilers
                        Hello Ted, aah... the comma again. First, I thougt it might have been the same comma again that led to the loss of Mariner 1 in 1962 ;o) but then I read how
                        Message 11 of 18 , Oct 18, 2007
                        • 0 Attachment
                          Hello Ted,

                          aah... the comma again. First, I thougt it might have been the same
                          comma again that led to the loss of Mariner 1 in 1962 ;o) but then I
                          read how things really happened: http://en.wikipedia.org/wiki/Mariner_1

                          However...

                          The comma is NOT guilty - once more!

                          It's the end of the line marker.

                          CP/M => DOS => Windows use CR LF (\r \n or 0x0D 0x0A)
                          All *nixes and Mac OS X use only LF (\n or 0x0D)

                          I found the bug on studying the source in the editor e3: what the
                          hell... a dot is at every line-end!

                          This dot is the CR.

                          I removed them and got a file with only LF-endings- and that's what
                          asm1802 likes, no core dump again, code runs fine.

                          Can you reproduce it? Does it help if you use something like
                          in=fopen("filename", "rt"); instead of in=fopen("filename", "r")?

                          BTW: why can't long branches be used with 1861 video?

                          Regards,
                          Nils
                        • J.C. Wren
                          Minor correction. As you say, Unixes use LF, but it s 0x0a, not 0x0d. Macs use 0x0a 0x0d (MacOS, not Leopard). --jc
                          Message 12 of 18 , Oct 18, 2007
                          • 0 Attachment
                            Minor correction. As you say, Unixes use LF, but it's 0x0a, not 0x0d.
                            Macs use 0x0a 0x0d (MacOS, not Leopard).

                            --jc

                            nils_eilers wrote:
                            > Hello Ted,
                            >
                            > aah... the comma again. First, I thougt it might have been the same
                            > comma again that led to the loss of Mariner 1 in 1962 ;o) but then I
                            > read how things really happened: http://en.wikipedia.org/wiki/Mariner_1
                            >
                            > However...
                            >
                            > The comma is NOT guilty - once more!
                            >
                            > It's the end of the line marker.
                            >
                            > CP/M => DOS => Windows use CR LF (\r \n or 0x0D 0x0A)
                            > All *nixes and Mac OS X use only LF (\n or 0x0D)
                            >
                            > I found the bug on studying the source in the editor e3: what the
                            > hell... a dot is at every line-end!
                            >
                            > This dot is the CR.
                            >
                            > I removed them and got a file with only LF-endings- and that's what
                            > asm1802 likes, no core dump again, code runs fine.
                            >
                            > Can you reproduce it? Does it help if you use something like
                            > in=fopen("filename", "rt"); instead of in=fopen("filename", "r")?
                            >
                            > BTW: why can't long branches be used with 1861 video?
                            >
                            > Regards,
                            > Nils
                            >
                            >
                            >
                            > ========================================================
                            > Visit the COSMAC ELF website at http://www.cosmacelf.com
                            > Yahoo! Groups Links
                            >
                            >
                            >
                            >
                          • J.C. Wren
                            Ooops, my bad. Mac OS uses only 0x0d. I don t think anything actually uses 0x0a,0x0d. --jc ... [Non-text portions of this message have been removed]
                            Message 13 of 18 , Oct 18, 2007
                            • 0 Attachment
                              Ooops, my bad. Mac OS uses only 0x0d. I don't think anything actually
                              uses 0x0a,0x0d.

                              --jc

                              J.C. Wren wrote:
                              > Minor correction. As you say, Unixes use LF, but it's 0x0a, not 0x0d.
                              > Macs use 0x0a 0x0d (MacOS, not Leopard).
                              >
                              > --jc
                              >
                              > nils_eilers wrote:
                              >
                              >> Hello Ted,
                              >>
                              >> aah... the comma again. First, I thougt it might have been the same
                              >> comma again that led to the loss of Mariner 1 in 1962 ;o) but then I
                              >> read how things really happened: http://en.wikipedia.org/wiki/Mariner_1
                              >>
                              >> However...
                              >>
                              >> The comma is NOT guilty - once more!
                              >>
                              >> It's the end of the line marker.
                              >>
                              >> CP/M => DOS => Windows use CR LF (\r \n or 0x0D 0x0A)
                              >> All *nixes and Mac OS X use only LF (\n or 0x0D)
                              >>
                              >> I found the bug on studying the source in the editor e3: what the
                              >> hell... a dot is at every line-end!
                              >>
                              >> This dot is the CR.
                              >>
                              >> I removed them and got a file with only LF-endings- and that's what
                              >> asm1802 likes, no core dump again, code runs fine.
                              >>
                              >> Can you reproduce it? Does it help if you use something like
                              >> in=fopen("filename", "rt"); instead of in=fopen("filename", "r")?
                              >>
                              >> BTW: why can't long branches be used with 1861 video?
                              >>
                              >> Regards,
                              >> Nils
                              >>
                              >>
                              >>
                              >> ========================================================
                              >> Visit the COSMAC ELF website at http://www.cosmacelf.com
                              >> Yahoo! Groups Links
                              >>
                              >>
                              >>
                              >>
                              >>
                              >
                              >
                              > ========================================================
                              > Visit the COSMAC ELF website at http://www.cosmacelf.com
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >


                              [Non-text portions of this message have been removed]
                            • ted_rossin
                              Thanks for clearing that up. I ll add a mode to save and restore R2,R4,R5,R6 and RE as well as fix up the assembler to output the 6 byte header. What register
                              Message 14 of 18 , Oct 18, 2007
                              • 0 Attachment
                                Thanks for clearing that up. I'll add a mode to save and restore
                                R2,R4,R5,R6 and RE as well as fix up the assembler to output the 6
                                byte header.

                                What register is the program counter when a program is run? Is it
                                the power up R0 or R3? If it is R3 then I'll have to remove the code
                                that loads up R3 and sets it as the PC. Chances are that it will not
                                matter unless that code lines up on the all-evil page boundary.
                                Which would most likely happy with my luck.

                                Thanks again.

                                --- In cosmacelf@yahoogroups.com, rileym65 <no_reply@...> wrote:
                                >
                                > The example in the documentation is wrong. The kernel uses bytes 2
                                > and 3 as the count of bytes to load using the o_read function so
                                > these 2 bytes are definitely a count of bytes to load and not the
                                > ending address. note that this allows for the the resulting file to
                                > be larger than will actually be loaded, which could be usefull for
                                > storing additional data for a program or even overlay support.
                                >
                                > Seems to me it should be easy for the compiler to add some startup
                                > code to a compiled program and add extra variable space to store the
                                > values of R2, R4, R5, and R6. Additionally depending on what
                                terminal
                                > device is being used, RE should also be stored (this is used by the
                                > BIOS's default bit-banged serial device). otherwise a long jump to
                                > the cold boot address will return control to Elf/OS, except that the
                                > default directory will be the root directory instead of any
                                > subdirectory that may have been at default.
                                >
                                > If you need any help in dealing with Elf/OS calls...just let me
                                know.
                                >
                                > Mike
                                >
                                > --- In cosmacelf@yahoogroups.com, "ted_rossin" <ted_rossin@> wrote:
                                > >
                                > > Hi Mike,
                                > >
                                > > In the Elf OS manual on the web there is an example which is
                                where I
                                > > got the 2nd 16-bit value was the end address:
                                > >
                                > > {"
                                > > HEXDUMP BAUD
                                > > :0000 20 00 20 05 20 00 9E 52 E2 64 22 D5
                                > >
                                > > If you are familiar with 1802 opcodes, you will notice there
                                are
                                > > more
                                > > bytes here than the original assembly program had. The assembler
                                > > adds a 6
                                > > byte header to the file. This header is called the execution
                                header
                                > > and tells
                                > > Elf/OS where the program is to be loaded and where the exec
                                address
                                > > is.
                                > > "}
                                > >
                                > > Has the file format changed to this?
                                > >
                                > > HEXDUMP BAUD
                                > > :0000 20 00 00 06 20 00 9E 52 E2 64 22 D5
                                > >
                                > > Let me know which way is correct and I can add this output format
                                to
                                > > the assembler. The compiler should work as is if it is given a
                                > > crazy big stack size to move the program out:
                                > >
                                > > cc1802 -mem_config 0 -stack_size 0x2100 fun.c
                                > > or for 1861 video apps:
                                > > cc1802 -nlb -mem_config 3 -stack_size 0x2100 video4.c
                                > >
                                > > Both of these will put the stack at location 0x2100 and have it
                                grow
                                > > towards 0x2000. The first example should be run from location
                                > > 0x2100 while the video4 example should be run from location
                                0x2300.
                                > > It will place video memory from 0x2100 to 0x22ff.
                                > >
                                > > As far as jumping back to the OS, it seems that user code can add
                                a
                                > > little function with some #asm #endasm code to do the jump to
                                > > 0x300. But, I could add an option to do the jump at the end.
                                > > It also seems possible to restore the stack (R2),R4,R5 and R6 and
                                > > return back home to Elf/OS.
                                > >
                                > > One day it would be nice to supply C function wrappers for all
                                the
                                > > user level Elf/OS enty points. In this case the compiler would
                                need
                                > > to save and restore some registers. It seems that I could add an
                                > > option to save the regs at start up in a private area and then
                                have
                                > > the wrappers restore the regs before making the calls. I used R6
                                > > for a long jump subroutine (for the 1861 video -nlb mode) and
                                used
                                > > R14 for the address passed to Call and LongJump so I just don't
                                play
                                > > well with others. It doesn't seem too ugly to make this work and
                                it
                                > > would make user level progams look pretty clean.
                                > >
                                > >
                                > >
                                > > --- In cosmacelf@yahoogroups.com, rileym65 <no_reply@> wrote:
                                > > >
                                > > > Some Elf/OS information for you. The header is as follows
                                > > >
                                > > > 2 bytes - Load address, high byte first
                                > > > 2 bytes - Length of load image, high byte first. This is not
                                the
                                > > last
                                > > > address but a count of bytes to load
                                > > > 2 bytes - Start address, high byte first.
                                > > >
                                > > > Normally programs are loaded at 2000h upwards. Elf/OS uses all
                                > > memory
                                > > > below 2000h
                                > > >
                                > > > There are 2 methods you can use to return back to Elf/OS at the
                                > > end of
                                > > > a program, either a jump to Elf/OS's cold boot address at
                                300h, at
                                > > > this address you do not need to preserve anything.
                                > > >
                                > > > 2nd method is if the stack has been properly maintained and
                                R4,R5,
                                > > and
                                > > > R6 are properly maintained, then you can SRET back to Elf/OS.
                                > > >
                                > > > Mike
                                > > >
                                > >
                                >
                              • ted_rossin
                                I ll mess with the line termination craziness a little later. I ve got some other situations to deal with at the moment. The 1861 can t handle any 1802
                                Message 15 of 18 , Oct 18, 2007
                                • 0 Attachment
                                  I'll mess with the line termination craziness a little later. I've
                                  got some other "situations" to deal with at the moment.

                                  The 1861 can't handle any 1802 instruction that takes 3 cycles
                                  (except in the interrupt handler for magic timing) as this will cause
                                  the interrupt rate to jitter. Only 2 cyle instructions are allowed.
                                  I tried a few experiments and found that this law must be followed or
                                  the video will just tear. I even tried high-res mode where the DMA
                                  pointer is not messed with but no luck. Just like the data sheet and
                                  the article in Popular Electronics said years ago. Just don't do it.

                                  My way around it can be found in the assembler listing. Here is an
                                  example:

                                  0267 .pagefit 10,0xe9
                                  0268
                                  0269 0x03e0 0x3a 0xe9 bnz WhileTrueHead3
                                  0270 0x03e2 0xf8 0x04 ld WhileTail3.1
                                  0271 0x03e4 0xbe st r14.1
                                  0272 0x03e5 0xf8 0xed ld WhileTail3.0
                                  0273 0x03e7 0xae st r14.0
                                  0274 0x03e8 0xd6 sep 6 ; LongJump(R14=WhileTail3)
                                  0275 0x03e9 WhileTrueHead3:

                                  I dedicate R6 to be a LongJump subroutine which is just the same code
                                  as the standard call and return (R4, R5) trick the RCA geeks came up
                                  with but it does not save the return address. This is all done with
                                  basic 2 cycle instructions. But, to do the conditional jump (bnz) I
                                  need to make sure that I'm not crossing a page boundary from the bnz
                                  instruction to the WhileTrueHead3 label. If I did, then the
                                  assembler would yell at me as the 1802 would jump backward in the
                                  same page instead of forward. The .pagefit pseudo op asks the
                                  assembler for 10 words in the current page. If it can not fit, it
                                  will pad the current page out with 0xe9 so that the branch will start
                                  in a new page. The current version of the compiler uses 0xe2 but
                                  I've spent the evining tracking down and fixing a problem with the
                                  interrupt handler trashing my stack so I now use R9 for my main stack
                                  pointer and R2 for the interrupt handler. It is a good thing that
                                  this processor has 16 registers as they are nearly all needed. The
                                  0xe2 or 0xe9 is just a sex 2 or sex 9 instruction which acts as a two
                                  cycle NOP. The 1802 NOP (0xc4) is a 3 cycle instruction so it can
                                  not be used.

                                  It is ugly but it works with out pushing painful problems onto a
                                  linker that I still need to code up.

                                  --- In cosmacelf@yahoogroups.com, "J.C. Wren" <jcwren@...> wrote:
                                  >
                                  > Ooops, my bad. Mac OS uses only 0x0d. I don't think anything
                                  actually
                                  > uses 0x0a,0x0d.
                                  >
                                  > --jc
                                  >
                                  > J.C. Wren wrote:
                                  > > Minor correction. As you say, Unixes use LF, but it's 0x0a, not
                                  0x0d.
                                  > > Macs use 0x0a 0x0d (MacOS, not Leopard).
                                  > >
                                  > > --jc
                                  > >
                                  > > nils_eilers wrote:
                                  > >
                                  > >> Hello Ted,
                                  > >>
                                  > >> aah... the comma again. First, I thougt it might have been the
                                  same
                                  > >> comma again that led to the loss of Mariner 1 in 1962 ;o) but
                                  then I
                                  > >> read how things really happened:
                                  http://en.wikipedia.org/wiki/Mariner_1
                                  > >>
                                  > >> However...
                                  > >>
                                  > >> The comma is NOT guilty - once more!
                                  > >>
                                  > >> It's the end of the line marker.
                                  > >>
                                  > >> CP/M => DOS => Windows use CR LF (\r \n or 0x0D 0x0A)
                                  > >> All *nixes and Mac OS X use only LF (\n or 0x0D)
                                  > >>
                                  > >> I found the bug on studying the source in the editor e3: what the
                                  > >> hell... a dot is at every line-end!
                                  > >>
                                  > >> This dot is the CR.
                                  > >>
                                  > >> I removed them and got a file with only LF-endings- and that's
                                  what
                                  > >> asm1802 likes, no core dump again, code runs fine.
                                  > >>
                                  > >> Can you reproduce it? Does it help if you use something like
                                  > >> in=fopen("filename", "rt"); instead of in=fopen("filename", "r")?
                                  > >>
                                  > >> BTW: why can't long branches be used with 1861 video?
                                  > >>
                                  > >> Regards,
                                  > >> Nils
                                  > >>
                                  > >>
                                  > >>
                                  > >> ========================================================
                                  > >> Visit the COSMAC ELF website at http://www.cosmacelf.com
                                  > >> Yahoo! Groups Links
                                  > >>
                                  > >>
                                  > >>
                                  > >>
                                  > >>
                                  > >
                                  > >
                                  > > ========================================================
                                  > > Visit the COSMAC ELF website at http://www.cosmacelf.com
                                  > > Yahoo! Groups Links
                                  > >
                                  > >
                                  > >
                                  > >
                                  >
                                  >
                                  > [Non-text portions of this message have been removed]
                                  >
                                • nils_eilers
                                  You re right: LF is 0x0A indeed! Things are even more complex: http://en.wikipedia.org/wiki/Newline
                                  Message 16 of 18 , Oct 19, 2007
                                  • 0 Attachment
                                    You're right: LF is 0x0A indeed!

                                    Things are even more complex: http://en.wikipedia.org/wiki/Newline
                                  • nils_eilers
                                    I took a look at the 1802 datasheet to find out what instructions are 3 cycle instructions. I found: - Long branches - Long skips - NOP But then at Figure 25
                                    Message 17 of 18 , Oct 19, 2007
                                    • 0 Attachment
                                      I took a look at the 1802 datasheet to find out what instructions are
                                      3 cycle instructions. I found:

                                      - Long branches
                                      - Long skips
                                      - NOP

                                      But then at "Figure 25 State Transition Diagram" there's "force S1
                                      (long branch, long skip, nop, ETC.) - what about the etc?

                                      Are there any other 3 cycles instructions beyond interrupts?
                                    • rileym65
                                      R3 is the considered the main program counter. Mike
                                      Message 18 of 18 , Oct 19, 2007
                                      • 0 Attachment
                                        R3 is the considered the main program counter.
                                        Mike

                                        --- In cosmacelf@yahoogroups.com, "ted_rossin" <ted_rossin@...> wrote:
                                        >
                                        > Thanks for clearing that up. I'll add a mode to save and restore
                                        > R2,R4,R5,R6 and RE as well as fix up the assembler to output the 6
                                        > byte header.
                                        >
                                        > What register is the program counter when a program is run? Is it
                                        > the power up R0 or R3? If it is R3 then I'll have to remove the code
                                        > that loads up R3 and sets it as the PC. Chances are that it will not
                                        > matter unless that code lines up on the all-evil page boundary.
                                        > Which would most likely happy with my luck.
                                        >
                                        > Thanks again.
                                        >
                                        > --- In cosmacelf@yahoogroups.com, rileym65 <no_reply@> wrote:
                                        > >
                                        > > The example in the documentation is wrong. The kernel uses bytes 2
                                        > > and 3 as the count of bytes to load using the o_read function so
                                        > > these 2 bytes are definitely a count of bytes to load and not the
                                        > > ending address. note that this allows for the the resulting file to
                                        > > be larger than will actually be loaded, which could be usefull for
                                        > > storing additional data for a program or even overlay support.
                                        > >
                                        > > Seems to me it should be easy for the compiler to add some startup
                                        > > code to a compiled program and add extra variable space to store the
                                        > > values of R2, R4, R5, and R6. Additionally depending on what
                                        > terminal
                                        > > device is being used, RE should also be stored (this is used by the
                                        > > BIOS's default bit-banged serial device). otherwise a long jump to
                                        > > the cold boot address will return control to Elf/OS, except that the
                                        > > default directory will be the root directory instead of any
                                        > > subdirectory that may have been at default.
                                        > >
                                        > > If you need any help in dealing with Elf/OS calls...just let me
                                        > know.
                                        > >
                                        > > Mike
                                        > >
                                        > > --- In cosmacelf@yahoogroups.com, "ted_rossin" <ted_rossin@> wrote:
                                        > > >
                                        > > > Hi Mike,
                                        > > >
                                        > > > In the Elf OS manual on the web there is an example which is
                                        > where I
                                        > > > got the 2nd 16-bit value was the end address:
                                        > > >
                                        > > > {"
                                        > > > HEXDUMP BAUD
                                        > > > :0000 20 00 20 05 20 00 9E 52 E2 64 22 D5
                                        > > >
                                        > > > If you are familiar with 1802 opcodes, you will notice there
                                        > are
                                        > > > more
                                        > > > bytes here than the original assembly program had. The assembler
                                        > > > adds a 6
                                        > > > byte header to the file. This header is called the execution
                                        > header
                                        > > > and tells
                                        > > > Elf/OS where the program is to be loaded and where the exec
                                        > address
                                        > > > is.
                                        > > > "}
                                        > > >
                                        > > > Has the file format changed to this?
                                        > > >
                                        > > > HEXDUMP BAUD
                                        > > > :0000 20 00 00 06 20 00 9E 52 E2 64 22 D5
                                        > > >
                                        > > > Let me know which way is correct and I can add this output format
                                        > to
                                        > > > the assembler. The compiler should work as is if it is given a
                                        > > > crazy big stack size to move the program out:
                                        > > >
                                        > > > cc1802 -mem_config 0 -stack_size 0x2100 fun.c
                                        > > > or for 1861 video apps:
                                        > > > cc1802 -nlb -mem_config 3 -stack_size 0x2100 video4.c
                                        > > >
                                        > > > Both of these will put the stack at location 0x2100 and have it
                                        > grow
                                        > > > towards 0x2000. The first example should be run from location
                                        > > > 0x2100 while the video4 example should be run from location
                                        > 0x2300.
                                        > > > It will place video memory from 0x2100 to 0x22ff.
                                        > > >
                                        > > > As far as jumping back to the OS, it seems that user code can add
                                        > a
                                        > > > little function with some #asm #endasm code to do the jump to
                                        > > > 0x300. But, I could add an option to do the jump at the end.
                                        > > > It also seems possible to restore the stack (R2),R4,R5 and R6 and
                                        > > > return back home to Elf/OS.
                                        > > >
                                        > > > One day it would be nice to supply C function wrappers for all
                                        > the
                                        > > > user level Elf/OS enty points. In this case the compiler would
                                        > need
                                        > > > to save and restore some registers. It seems that I could add an
                                        > > > option to save the regs at start up in a private area and then
                                        > have
                                        > > > the wrappers restore the regs before making the calls. I used R6
                                        > > > for a long jump subroutine (for the 1861 video -nlb mode) and
                                        > used
                                        > > > R14 for the address passed to Call and LongJump so I just don't
                                        > play
                                        > > > well with others. It doesn't seem too ugly to make this work and
                                        > it
                                        > > > would make user level progams look pretty clean.
                                        > > >
                                        > > >
                                        > > >
                                        > > > --- In cosmacelf@yahoogroups.com, rileym65 <no_reply@> wrote:
                                        > > > >
                                        > > > > Some Elf/OS information for you. The header is as follows
                                        > > > >
                                        > > > > 2 bytes - Load address, high byte first
                                        > > > > 2 bytes - Length of load image, high byte first. This is not
                                        > the
                                        > > > last
                                        > > > > address but a count of bytes to load
                                        > > > > 2 bytes - Start address, high byte first.
                                        > > > >
                                        > > > > Normally programs are loaded at 2000h upwards. Elf/OS uses all
                                        > > > memory
                                        > > > > below 2000h
                                        > > > >
                                        > > > > There are 2 methods you can use to return back to Elf/OS at the
                                        > > > end of
                                        > > > > a program, either a jump to Elf/OS's cold boot address at
                                        > 300h, at
                                        > > > > this address you do not need to preserve anything.
                                        > > > >
                                        > > > > 2nd method is if the stack has been properly maintained and
                                        > R4,R5,
                                        > > > and
                                        > > > > R6 are properly maintained, then you can SRET back to Elf/OS.
                                        > > > >
                                        > > > > Mike
                                        > > > >
                                        > > >
                                        > >
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.