Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.

Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.

Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.

Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.

Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.

Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.

Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.

New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.

Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Powertran Cortex

  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by Ksarul View Post
    I believe Stuart can as well.
    Not me.



      Originally posted by Ksarul View Post
      This is very good news, as Al's been out of contact with the TI community for a long while. I bought his Fortran99/Fortran9640 program many years ago. It was a nice implementation of Fortran.
      That may become available for posterity as well. Al wrote:

      Thank you for your letter of Dec 31, 2013. I have been a bit busy so did not have time to respond.

      I have attached the last build I did for the TIC C compiler, it was about 20 years ago. Unfortunately I lost the source code for the companion TASM assembler. Much of the work for the TIC C compiler was based on the public domain 68000 C compiler that was in circulation at the time (even though it was a bit buggy). Paul Charlton at the time sent me some code he was working on from the same source baseline that was helpful, as well as Clint Pulley's testing it for me.

      The 99 FORTRAN source code will take me a little longer to get together. The build is much larger and includes many function libraries, a lot which were contributed by Elmer Clausen.
      I think Al more than deserves to be inducted into the TI hall of fame (



        I fully agree there! He was a great long-term supporter of the TI, and the fact that he kept copies of most of his code preserved says volumes of good in addition to what was already known! Let me know how you want to transfer the files and I'll arrange to get them up on WHT. We might also want to put some kind of message from him with the data to show that he's given his permission to post it.
        Enter My Mind At Your Own Risk!



          Originally posted by Ksarul View Post
          Let me know how you want to transfer the files and I'll arrange to get them up on WHT.
          Thanks for the offer! The files are with Don O'Neil of WHTech and he has promised to have them uploaded later this week.



            Has somebody given him the "lost" issues 1, 5 & 8 of the user magazine ?

            I've also got all the 5.25" disk images and scans of documentation from MPE that I've done so far.



              TIC is up on


                Thanks Paul. If/when you have 5 minutes spare, could you do a step-by-step of how to compile a simple "hello world" program that can be assembled to run on the 9995 breadboard? I see the XOPs for input and output are already there, but I'm a little stuck as to where exactly to start.

                Thanks to Al as well. Found a little more about him on [] - search for his name on the page.



                  TIC step by step

                  That link is what put me on Al's trail: there're only a few Beards in Franklin, MA.

                  Doing a straight "hello, world!" is a bit hard, because there is no standard library with printf in it; even a simple printf is 1..2 KB. Instead I have simple program that tests both input and output.

                  So, start with the following file, and call it 'test.c':
                  char s[81];
                    while( gets(s) ) {
                    return 0;
                  This gets a string from the keyboard (and accepts editing with backspace, ctrl-h) and then prints that same line back to the user. If you type a ctrl-z the program exits (see the C99 manual for details, I used those routines as a basis). Compile this C program with TI-C to an assembler file:
                  ./tic test.c
                  TI-C will place the output in a file called 'test.S'. Now assemble this file to an object file:
                  ./asm990 -o test.obj test.S
                  The runtime routine is supplied with the source and is called crt0.S. Also assemble the runtime routine to an object file (of course you need to do this only once, the resulting object file is the same for all projects):
                  ./asm990 -o crt0.obj crt0.S
                  Next link the two parts together, taking care that crt0.obj comes first.
                  ./lnk990 -o final.obj crt0.obj test.obj
                  The resulting 'final.obj' file is ready for downloading to the breadboard, were it not for the fact that it expects an object file with '\r' line endings and what we have produced has '\n' line endings (on linux and osx, haven't tried on windows). This can be fixed by a little tool 'flip':
                  ./flip <final.obj >final.lmc
                  The 'final.lmc' file can be downloaded to the breadboard, using the LMC command. For that, reboot the breadboard, type 'A' to get the start-up menu and select '1' from that menu for EVMBUG. At the MON? prompt, type (note the use of uppercase):
                  MON? LMC 8000
                  EVMBUG will respond with 'Are you ready (Y/N)?' and type Y (again this has to be an uppercase Y). Now tell your terminal emulator to send the file 'final.lmc' to the breadboard. Once the file has been received, set the internal registers using the IR command:
                  MON? IR
                  WP ???? F000
                  PC ???? 8000
                  ST ???? 0
                  After typing each register value, end with a space to move to the next register, the enter key finalizes the command. Finally the progam can run, using the 'EX' command:
                  MON? EX
                  If all went well the code should run as expected.

                  Note (1)
                  The source code for the 'flip' build tool is:
                  #include <stdio.h>
                  int main()
                    char c;
                    while( (c = getchar())!=EOF ) {
                      if( c==0x0a )
                        c = 0x0d;
                      else if( c==0x0d )
                        c = 0x0a;
                    return 0;
                  I think I need to do a ROM with EVMBUG modified to accept '\n' and perhaps also '\r\n', just to remove this annoying build step which will undoubtedly confuse the hell out of first time users of the breadboard system.

                  Note (2)
                  I have found my fresh build of TI-C to have a crash prone optimizer. To disable the optimizer, compile with the -O flag (see manual, -O means switch off, +O means switch on to TI-C). Perhaps Al's 20 year old win binary does not have this problem.

                  Note (3)
                  The compiler probably needs some TLC to make it fully usable. I found that static functions have their names preceded by a hash ('#') in the assembler output and asm990 does not accept this. In my fresh build calling a function pointer seemed to generate the wrong code. Modifying the main routine to automatically call asm990 and lnk990 after compiling also makes it a lot more user friendly. Personally, I'd like to finish the Ritchie compiler port first, so if somebody else feels called to make some touch ups to TIC, feel free.

                  Note (4)
                  If somebody needs C source for a simple version of 'printf', I can post one on request.

                  Sorry for an overly long post. Let me know if you get stuck somewhere and I'll post further instructions. Perhaps in due course this material could make an interesting additional page on your website.



                    RIP Neil Quarmby

                    sadly I have to report that one of the people that made the Cortex possible, Neil Quarmby lost his battle against a brain tumour on Friday and passed away.
                    Rest in peace Neil


                      Sad news indeed. Presumably this is him: link?


                        Originally posted by Stuart View Post
                        Sad news indeed. Presumably this is him: link?
                        yes, that is Neil


                          Ritchie C compiler port

                          I'm happy to report that the compiler port has now sufficiently progressed that it can compile a 200 line C program correctly: printf is now working. The output code is about 1.3 kb, so using some very rough arithmetic the 4,000 line 'c1' pass of the compiler should come in at about 26 kb, versus 22 kb for the pdp-11 version. I'm also progressing on the minimal Xinu system, but I cannot claim that it works as yet.

                          To give you folks an idea of where it is at, I have made the development repo public, it can be found on:

                          If anybody wants to attempt a build of their own, I'm happy to give details.


                            Base Camp 1

                            There has been some good progress and I've reached "Base camp 1", so to spreak:
                            - The Ritchie C compiler has been ported, only floating point remains to be done. Structures, unions and bit fields are all supported, as are longs.
                            - There is a full unix assembler with e.g. support for local labels and synthetic jumps
                            - Other tool chain elements (ld, nm, strip, etc.) have been ported as well

                            The toolchain port has been guided and tested by a port of 1983 Xinu to Stuart's breadboard: that port is now largely done:
                            - The core (processes, semaphores, messages) has been fully ported
                            - The real time clock (using the 9995 timer) has been ported
                            - The IO api has been ported
                            - One device driver, the console terminal, has been ported
                            It is currently some 7.5KB in size, with a disk driver and file system it will probably end up at about 11KB.

                            All in all, it has been a productive 90 days, also considering that the TI-C compiler became available as another option in that time frame as well.

                            Now it is time to ponder where to go next and I'd like input. I have three topics on my mind:

                            1. Floating point

                            Operating system kernels normally don't need floating point, so I have no direct need to port this, but completing the compiler port is perhaps worthwhile in its own right. The pdp11 floating point instructions are rather different from those on the 99110 or the 990/12. I am tempted to emulate pdp11 style instructions and make the compiler porting work easier. Any alternative ideas? Any pointers to high speed floating routines for the 9995/99105?

                            2. Memory management

                            I'd like to extend the little breadboard with some memory management. I am torn between doing something very simple and replicating the Powertran design. From the schematics alone I am not entirely sure how the Powertran manages memory. Who can tell me how it was designed to work?

                            3. Disk

                            I'd like to extend the little breadboard with a disk. A very simple solution would be to use ram disk, but this requires the CPU to copy the data and I prefer something with dma. Another solution is to use a microcontroller with attached sd card to more or less emulate the Powertran setup with a 9911 and a 9909. I'm thinking something like this design:

                            Either I could use the PIC device of the above or a Propeller chip. The advantage of the former is that it is a 5V part and that the flash is on chip. The advantage of the latter is that it is easy to program and probably has more processing power, but it is a 3.3V part. The 5V/3.3V could be bridged with resistors. However, adding resisters is perhaps wise anyway, to limit current if the microcontroller accidently drives the lines at the same time as the CPU due to a microcontroller programming error.

                            Who has ideas for the simplest thing that could possibly work?



                              Originally posted by pnr View Post
                              I'm happy to report that the compiler port has now sufficiently progressed that it can compile a 200 line C program correctly: printf is now working. The output code is about 1.3 kb, so using some very rough arithmetic the 4,000 line 'c1' pass of the compiler should come in at about 26 kb, versus 22 kb for the pdp-11 version. I'm also progressing on the minimal Xinu system, but I cannot claim that it works as yet.

                              To give you folks an idea of where it is at, I have made the development repo public, it can be found on:

                              If anybody wants to attempt a build of their own, I'm happy to give details.
                              Hi Paul,

                              I've been watching your progress and decided to dive in and try and do a build with the compiler so far. I didn't want to do a full Linux install so decided to try Cygwin, which seems OK for the task.

                              First of all, is there anyway to download in bulk? Clicking each file followed by the download button is reasonably time consuming to say the least.

                              I had to tweak the makefiles, but really only to do with DESTDIR and the 'install' options - no big deal. The makefile for c2 didn't work at all. I needed to change the build to $(CC) ${LDFLAGS} -o c2 c20.o c21.o. Again, no big deal.

                              I have now built cpp, c0, c1, c2 and as. crt is fine but it needs ld which I can't get to build. Looking at ld.c and nm.c they have what looks like 'local' includes for ar.h and a.out.h (i.e. they are in "" rather than <>). Any thoughts? Also, do I have to define __pdp11__ ?

                              Also, I'm pretty much guessing at the command line options for c0, c1 and c2. Here's what I do:

                              ../bin99/cpp main.c main_cpp.c
                              ../bin99/c0 main_cpp.c main_c0.1 main_c0.2
                              ../bin99/c1 main_c0.1 main_c0.2 main_c1.s
                              ../bin99/c2 main_c1.s main.s
                              ../bin99/as -o main.o main.s

                              Great work though!



                                How bizarre. Neither one of us had posted for ages and then both at the same time...!
                                Last edited by tms9995; March 19, 2014, 02:13 PM.