Announcement

Collapse

Forum 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.


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.


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.



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.


"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.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    {Stuart} The 9995 data manual shows a gate of a 7407 connected between /RESET and READY to achieve this.
    probably a diode will do instead so /reset pulls down ready


    {Stuart} Not that I'm aware of. What I've done before though is get the micro to continually send a short text string as it increments and prints the baud rate value. When you see the text string correctly, read the baud rate.

    what is the issue with baud rate calculations?
    for auto baud a common technique is to hit an odd numbered character (eg: 'A' = 0x41) and measure the start bit width with a loop by polling RIN status bit of the 9902


    EDIT:
    if you are having problems with the 9995 keeping up with the terminal program sending it data then try setting the terminal program to transmit 2 stop bits to give it more of a chance, failing that use interrupts on the 9902 and/or re purpose the RTS line to hold off the PC
    Last edited by Tony Rowell; January 2, 2014, 05:08 PM.

    Comment


      The board may be moderating newcomer posts, but I just found the last message you sent to my personal e-mail today, Jim--three weeks after you sent it (it was there all along, I just missed it somehow). I'll get an answer out to you shortly!

      One note on TMS9900 FPGA cores: the F18A VGA replacement (from Matthew Hagerty of CodeHackCreate) for the TMS9918A has a fully functional TMS9900 core incorporated into it, designed to work as a system coprocessor.
      Enter My Mind At Your Own Risk!

      Comment


        Originally posted by Tony Rowell View Post
        what is the issue with baud rate calculations?
        for auto baud a common technique is to hit an odd numbered character (eg: 'A' = 0x41) and measure the start bit width with a loop by polling RIN status bit of the 9902
        Yes, this is the technique used by the code on my TMS9995 breadboard system. You then look up the loop count in a table to get the value to load into the 9902 data rate registers for the matching baud rate. So actually if you're changing from a 1 wait state system to a no wait state system, the loop count values will change, although the values to load into the 9902 will not, as they are based on the clock frequency which is not changing. So you could just tweak the code to load the value for the 9902 for the baud rate you want to use directly, rather than looking it up in a table.

        Comment


          Originally posted by pnr View Post

          - connecting READY to /RESET should eliminate the automatic wait state. Has anybody done the recalculation work for the baud rate table?

          Paul
          My take on this is that Paul is asking for new baud rate values for the TMS9902 once the TMS9995 is running without wait-states? Surely since the system clock frequency doesn't change, the values for the 9902 remain the same?

          Dave.

          Comment


            Originally posted by tms9995 View Post
            My take on this is that Paul is asking for new baud rate values for the TMS9902 once the TMS9995 is running without wait-states? Surely since the system clock frequency doesn't change, the values for the 9902 remain the same?

            Dave.
            you should be able to just ratio the count. Take the loop timing the start bit and using the 9995 data sheet write down the number of clock cycles and memory accesses for each line of code (it is only a 3 instruction loop). Do this for both with and without wait states, the ration between the 2 cycle counts gives you the scaling factor for the baud rate

            Comment


              Originally posted by Ksarul View Post
              The board may be moderating newcomer posts, but I just found the last message you sent to my personal e-mail today, Jim--three weeks after you sent it (it was there all along, I just missed it somehow). I'll get an answer out to you shortly!

              One note on TMS9900 FPGA cores: the F18A VGA replacement (from Matthew Hagerty of CodeHackCreate) for the TMS9918A has a fully functional TMS9900 core incorporated into it, designed to work as a system coprocessor.
              can you point me to a reference to the 9900 core in the FPGA, I've had a look at the F18A pages and I cant see any mention of it but I'm probably just being blind.

              Comment


                Originally posted by Tony Rowell View Post
                you should be able to just ratio the count. Take the loop timing the start bit and using the 9995 data sheet write down the number of clock cycles and memory accesses for each line of code (it is only a 3 instruction loop). Do this for both with and without wait states, the ration between the 2 cycle counts gives you the scaling factor for the baud rate
                I have to agree with Dave, if you are using the TMS9902 for the serial comms then any wait states (or not) for the main memory should have no affect on the comms.
                The baud rates are defined by the clock feed to the TM9902 and it's register settings.

                Jim

                Comment


                  Originally posted by Tony Rowell View Post
                  can you point me to a reference to the 9900 core in the FPGA, I've had a look at the F18A pages and I cant see any mention of it but I'm probably just being blind.
                  The details on the F18A are rather scattered around.
                  There quite a bit mentioned in the thread here.
                  http://atariage.com/forums/topic/207...and-resources/

                  I've one in my Cortex and it does work well.

                  Jim

                  Comment


                    Here's the reference to the 9900 on the F18A page:

                    http://codehackcreate.com/archives/335

                    It is the second listed feature.

                    Guillaume Tello makes extensive use of it with his MLC Compiler.
                    Enter My Mind At Your Own Risk!

                    Comment


                      Originally posted by Ksarul View Post
                      Here's the reference to the 9900 on the F18A page:

                      http://codehackcreate.com/archives/335

                      It is the second listed feature.

                      Guillaume Tello makes extensive use of it with his MLC Compiler.
                      Thanks, I'd missed that




                      Originally posted by Jim Hearne View Post
                      I have to agree with Dave, if you are using the TMS9902 for the serial comms then any wait states (or not) for the main memory should have no affect on the comms.
                      The baud rates are defined by the clock feed to the TM9902 and it's register settings.
                      Jim
                      that is true but ...

                      if you are doing auto baud using a software loop to measure the width of the start bit you do need to take it into count. For example, if removing the wait states makes the timing loop take half the time it does with wait states then the same start bit will take twice the number of loops which would make it appear that the serial port is half the baud rate it really is.

                      Comment


                        Originally posted by Tony Rowell View Post
                        that is true but ...

                        if you are doing auto baud using a software loop to measure the width of the start bit you do need to take it into count. For example, if removing the wait states makes the timing loop take half the time it does with wait states then the same start bit will take twice the number of loops which would make it appear that the serial port is half the baud rate it really is.
                        Yes, if you were doing auto baud rate calculations it would make a difference.

                        But the original mention of baud rates by Paul was
                        - connecting READY to /RESET should eliminate the automatic wait state. Has anybody done the recalculation work for the baud rate table?
                        My (and i think Dave's) point was that you wouldn't need to recalculate the baud rate table just because you removed the wait states.

                        It was Stuart that started talking about auto baud rates afterwards.

                        Jim

                        Comment


                          C on a 9995

                          Good progress over the last few days:

                          [1] Flow control seems to be less of an issue. My first attempts were with sending a Cortex Basic source and this overflows. The monitor seems quick enough to handle most baud rates when receiving object files. I'm using CoolTerm, which suits my needs quite well - it even has an option to slow the transmission rate for file sends.

                          [2] The data sheet indeed shows an open collector buffer in the zero wait state circuit. However, I think this is meant to show a "wired-AND" circuit. As the breadboard memory does not generate a ready signal, just connecting READY to /RESET should work I think. Once I have the baud rate thing sorted, I'll try with a 2.7K resistor in between: even if READY is mysteriously also an OC output that should not fry the 9995 chip.

                          [3] As Tony pointed out, I was asking for the recalculation of clock cycles in the auto baud rate measurement loop. I think I will patch the ROM multiplying loop counts by 1.4; I hope that is close enough.

                          [4] I've done some work with the C99 compiler on WHTech (ftp://whtech.com/programming/c99/). I've taken the DOS/Unix port (in directory "cross assembler" -- misnomer that) and compiled C99; it works out of the box. The output is almost asm990 compatible, a tiny patch was enough to make it work. However, there was no runtime support file with the DOS/Unix port. I've taken CSUP from the TI99/4A version (REL4) and disassembled it. With some minor tweaking it is good to go for the breadboard and the EVMBUG environment.

                          [5] The assembler output can be linked with lnk990 (first link csup, then the compiler output) to generate a combined object file. This file has LF line endings, whereas EVMBUG expects CR line endings. A small program, "flip", makes this change and it is ready for downloading.

                          [6] On the breadboard start EVMBUG, and type LMC 8000. An "Are you ready" prompt appears, type Y. EVMBUG responds with a single XON (DC1) control character (which I think may have started the paper tape reader on a ASR33). Next tell CoolTerm to send the 'flipped' combined object file, and wait for the EVMBUG prompt to appear. Next tell EVMBUG to begin execution at 8000 and pronto!.

                          [7] Stuart, the LMC routine contains a passive bug: at location >0698 it sets R12 (CRU base) to >0080, this should be >0000. This part of the routine skips any text that comes after the terminating colon, simply waiting for a ~5 second period without a start (space) bit. The luck is that a floating CRUIN line apparently reads as a 1, so you won't notice this as a bug. If you want me to, I can send you disassembly for the LMC routine in EVMBUG.

                          The code generated by C99 is far from efficient, but it is a nice way to bootstrap into better tools. Probably similar workflows to the above could work with the Cortex built-in monitor program, and certainly with MDEX.

                          Let me know if I need to post the C99 patch, the runtime support routine and the source to "flip".

                          Paul

                          Comment


                            Hi Paul,
                            It looks like you might have got past the moderation point now, i got you message above at 8.30 on the 4th ?

                            I've just noticed quite a few other messages from you have appeared dated back on the 2nd.

                            Sorry Tony/ Paul, i didn't realise that the Cortex did auto board rate, actually, i presume now you were talking about EVMBUG on the breadboard and not the Cortex at all.

                            Jim

                            Comment


                              Originally posted by pnr View Post
                              [7] Stuart, the LMC routine contains a passive bug: at location >0698 it sets R12 (CRU base) to >0080, this should be >0000. This part of the routine skips any text that comes after the terminating colon, simply waiting for a ~5 second period without a start (space) bit. The luck is that a floating CRUIN line apparently reads as a 1, so you won't notice this as a bug. If you want me to, I can send you disassembly for the LMC routine in EVMBUG.

                              Paul
                              Thanks Paul. I'll correct that. It seems to be a bug in the original EVMBUG on the TMS9995 Evaluation Module that I took a copy of.

                              Stuart.

                              Comment


                                C on a 9995

                                I'm following you progress with interest, I'd like to be able to program in C on the Cortex, just under CDOS would be fine.
                                Jim
                                MDEX seems easier than CDOS, but that may be driven by my ignorance of CDOS. A quick glance at the manual did not reveal much about binary file formats and the API for binary programs. Perhaps others have better info on this. In any case, I need to 'upgrade' my breadboard to handle banking out the ROM and loading Cortex basic in the low 24K of RAM, so that I can experiment a bit. First step would be to create a 'tag loader' program, because the Cortex built-in monitor does not appear to provide that service.

                                Comment

                                Working...
                                X