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

    "How bizarre"
    Indeed!

    "is there anyway to download in bulk?"
    Yes, if you select a check-in (either via the timeline menu, or by clicking on the link in the files view) you get to a screen where you can download a tarball or zip file (and view side-by-side diffs, etc.).

    "Any thoughts?"
    - Yes, my bad: I missed several files in the repo, I've just added those. I am pleased to hear to it seems to work with Cygwin: the source code uses the sbrk() function call, which is not supported by Windows itself; the Cygwin folks must have added emulation for that.
    - You do not have to define __pdp11__. This was added by the bkunix project to deal with differences between big and little endian systems. I will clean those bits up in due course.
    - I've also added out2lmc, which converts a runnable a.out file to an object file for downloading to the breadboard.

    "Here's what I do"
    That is correct. Once more my bad, I forgot to include the source for cc itself (now fixed). This little program does all the work that you now do by hand. Note that cc has hardcoded paths to the component programs, so be sure to update that.

    Let me know how you get along.

    Paul

    Comment


      Originally posted by pnr View Post
      "How bizarre"
      "is there anyway to download in bulk?"

      Yes, if you select a check-in (either via the timeline menu, or by clicking on the link in the files view) you get to a screen where you can download a tarball or zip file (and view side-by-side diffs, etc.).

      Paul
      Ahh, finally figured it out. You have to log-in (anonymously is fine) to get the link. Didn't know that!

      OK, I'll give the latest a try. Typical isn't it? I decided to get involved 48 hours before it was ready...

      Thanks again,

      Dave.

      Comment


        Good progress Paul!

        Floating point - the Cortex source code contains a set of floating point routines, if that's the sort of thing you're interested in. If you look in the Cortex source here [http://www.powertrancortex.com/basic...M%20Source.pdf], the main FP routines start on page 490.

        Memory Management - the memory mapper chip lets you map each 4K block in the processor 64K address space to any 4K block in the extended 1M memory. I don't think the Cortex 'manages memory' so to speak - it is totally reliant on the programmer to control.

        Disk - a simple solution might be to use Compact Flash. No DMA, but a doddle to connect (I've got one in my TM990 system) plus you can remove the disk and read/write to it on the PC.

        Stuart.

        Comment


          Originally posted by Stuart View Post
          Good progress Paul!
          Disk - a simple solution might be to use Compact Flash. No DMA, but a doddle to connect (I've got one in my TM990 system) plus you can remove the disk and read/write to it on the PC.
          No DMA is perhaps the way to go as another base camp on the way to the summit; it is certainly a simpler approach.
          So far, all I have found on the web are interfaces with 8-10 ttl chips. Is that what you had in mind, or is there a solution with just a few chips?

          Comment


            Originally posted by pnr View Post
            No DMA is perhaps the way to go as another base camp on the way to the summit; it is certainly a simpler approach.
            So far, all I have found on the web are interfaces with 8-10 ttl chips. Is that what you had in mind, or is there a solution with just a few chips?
            Ah, to clarify, what I meant to say was an IDE interface then a CF card on a cheap little IDE-CF adaptor. You can treat the IDE I/F as a simple memory-mapped device so all you need is to sort out some address decoding for the chip selects. The design for my TM990 is here: http://www.avjd51.dsl.pipex.com/tm99...erface_sch.pdf. You probably won't need the address and data bus buffers. U8 is only needed for the TMS9900 which always does a read-before-write so it needs different read and write port addresses - don't think you need that for the 9995. You can operate the IDE I/F on an 8-bit bus - all the IDE registers you need for basic operation are 8-bit, and to keep things simple you don't need to latch two bytes on/off the IDE 16-bit data bus, just use 8 bits. You'll lose half the capacity of the CF card because you're only using half of each 16-bit word, but you're hardly going to filling a whole CF card up.

            I based my design on the information here: http://www.retroleum.co.uk/electroni...ide-interface/.
            Last edited by Stuart; March 19, 2014, 04:41 PM.

            Comment


              Originally posted by Stuart View Post
              You can operate the IDE I/F on an 8-bit bus - all the IDE registers you need for basic operation are 8-bit, and to keep things simple you don't need to latch two bytes on/off the IDE 16-bit data bus, just use 8 bits.
              Brilliant. That remark made me remember something that I had seen for a ZX81 a decade ago. Couldn't find that anymore, but it was similar to this:
              http://piters.tripod.com/simpif.htm
              I guess hooking up to the breadboard could be almost as simple. I have a CF-to-dual-header converter board, but that would still require a lot of wires to hook up to the breadboard. Perhaps I should order some of these:
              http://www.vetco.net/catalog/product...ducts_id=13672

              Originally posted by Stuart View Post
              You'll lose half the capacity of the CF card because you're only using half of each 16-bit word, but you're hardly going to be filling a whole CF card up.
              Yup. Back in '76 the system that Ritchie used had about 10MB of disk space actually used. Even a 32MB card would be large enough.

              Paul

              Comment


                A disk for the breadboard

                That CF card idea is really panning out. First, there is a breadboard friendly breakout board:
                https://www.sparkfun.com/products/retired/493
                Take a look at the schematics and circuit cellar article. Unfortunately, it has been retired, but this swedish web shop still has some (at a whopping 18 euros):
                http://www.lawicel-shop.se/
                I've ordered one, two more available.

                The article does not make it quite clear, but CF cards operate in 1 of 3 modes. To get the IDE mode, pin 9 has to be grounded at power up. If that pin is left floating, it comes up in memory mode, an execptionally easy mode to interface:
                http://xetexracing.com/page3/page39/...F%20Memory.pdf
                Also note that support for IDE mode was obligatory for CF cards, but is optional for CF+ cards. Memory mode is obligatory in both standards, and hence a safer bet. Best of all, memory mode allows 8 bit access to data as well, so the whole card can be used.

                For those who want to have all the detail, here is the spec:
                ftp://ftp.wintel.fi/manuals/General/CompactFlash.pdf

                It would seem that indeed a CF card can be interfaced to the 9995 with just one or two TTL chips for address selection and alike.

                Paul

                Comment


                  Originally posted by pnr View Post
                  To get the IDE mode, pin 9 has to be grounded at power up. If that pin is left floating, it comes up in memory mode.
                  Interesting, I did wonder how one controlled the mode, and never did find out. Pin 9 is /OE, and that isn't present on the IDE interface. So if using an IDE-CF adaptor, it's always going to be in IDE mode.

                  If one writes some data to a CF card on one system in memory mode, presumably one would read the same data from the card on a different system in IDE mode? Might be a point worth checking in case you were to offer TMS9995 code downloads to write to the CF card on a PC? (Would need a utility/app to write 'raw data' to the CF card on the PC of course, unless you were going to support FAT formatting or similar.)

                  Stuart.

                  Comment


                    I refer to Stuart's schematic for the breadboard. Attached an alternative page 2, page 1 is almost identical (note /reset, /int1 and /ram_oe). The 4 inverters and the 2 or gates are left over from page 1.

                    I think this should work and it still fits on 2 strips of breadboard. The 74hct688 could also be a 74hct138 with some loss of addressing precision. It has to be a hct part though, as CF cards are not TTL compatible. Choosing a '138 might make the wiring a bit easier. The card registers appear at memory location 0xfe00-0xfe07; this is chosen so that the timer register and nmi vector remain addressible.

                    The 9902(A) is selected when A3 is low; this should avoid conflict with the built-in flag register at cru address 0x1ee0. Connecting /int to /int1 is optional, it is only needed when running Xinu with buffered I/O (Xinu console I/O works with polling).

                    The remaining CF card connections are handled on the Sparkfun breakout board.

                    Any comments?
                    Attached Files

                    Comment


                      Looks convincing.

                      You might need an HCT245 buffer for the data bus to the CF card? In practise I found on my TM990 system that the data buffers had to be HCT and all the other signals were fine with LS chips. YMMV according to board layout and how many chips you've got hanging off each signal?

                      Stuart.

                      Comment


                        Originally posted by pnr View Post
                        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?

                        Paul
                        I agree that the kernel itself wouldn't need FP support, but I think it would be nice to have it implemented in the Compiler for those who wish to use it.

                        Dave.

                        Comment


                          Originally posted by pnr View Post

                          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?

                          Paul
                          As Stuart said, the memory mapper in the Cortex was really left up to the user to play with. Neither MDEX or Cortex Basic/CDOS use it. NOS probably does, but I still haven't got around to experimenting with that OS yet.

                          The mapper resides at 0xF100-0xF11E as 16 x 12-bit registers (but only 8 bits are used in the Cortex). Each register represents 4K of the 64K TMS9995 RAM, so 0xF100 is for 0x0000-0x0FFF all the way up to 0xF11E which is for 0xF000-0xFFFF. Each register can take the value of 0x00 to 0xFF where each value points to a 4K block of the (maximum) 1MB RAM. Thus if 0xF110 is set to 0x10, then TMS9995 RAM 0x8000-0x8FFF is mapped to 0x10000-0x10FFF. The mapper is turned on/off using the CKON/CKOF instructions.

                          The emulator implements this if you want to try it out.

                          Dave.

                          Comment


                            Originally posted by pnr View Post

                            Note that cc has hard-coded paths to the component programs, so be sure to update that.

                            Let me know how you get along.

                            Paul
                            Thanks for updating the repository with the latest files. I got it all built and it works fine. I have a couple of questions:

                            1) Are you planning on any more changes (floating point perhaps)? I want to start tweaking it for Cortex use and don't want to deviate too from your 'masters' if there are more changes to come.

                            2) As you said, the paths in cc are hard coded. As supplied, they are set to './' which only works if you are working in the bin99 directory. If a path is set to bin99 or the files are copied to /usr/local/bin, then it errors saying it can't find ./cpp. So, if you are in ./myproject and do a 'cc -o prog prog.c, cc will execute fine but fail on the call to each sub-process. For now, I have added a -DINSTDIR /usr/local/bin to the makefile to build cc with the path defined. It would be nice to build cc so that the tool-chain can be run from any directory it is copied to (that has a path set to it). Any ideas on the best/proper way to do this?

                            Thanks again for all your work on this.

                            Dave.
                            Last edited by tms9995; March 25, 2014, 12:29 PM.

                            Comment


                              Originally posted by tms9995 View Post
                              I agree that the kernel itself wouldn't need FP support, but I think it would be nice to have it implemented in the Compiler for those who wish to use it.
                              Yes. I think I might do the FP port as well, but not right away. After week 8 doing the port started to feel like real work, and this is strictly hobby.

                              The Cortex FP routines are interesting: they use a 48-bit format, which is unusual, "one-and-a-half precision" so to speak. Other than that it appears to use the hex base format that is apparently the native format for the ti990 series. They don't look all that optimised at first glance.

                              Attached is a commented disassembly of the single precision FP routines from MDEX QBasic. They look like somebody thought about every clock tick in those routines: the conditional jumps seem organised such that the most common code path is fastest. One night I tried to understand the division algorithm but I could not grasp it; never found the time to sit down once more for another try. Anybody feel intrigued?

                              For clarity sake: there is a similar library with the double precision version of these routines on the MDEX QBasic disk.
                              Attached Files

                              Comment


                                Originally posted by tms9995 View Post
                                Thanks for updating the repository with the latest files. I got it all built and it works fine. I have a couple of questions:

                                1) Are you planning on any more changes (floating point perhaps)? I want to start tweaking it for Cortex use and don't want to deviate too from your 'masters' if there are more changes to come.
                                Happy to hear that you could replicate it. Yes, I'm planning more changes. However, I am accepting patches, so your version can stay current.

                                Originally posted by tms9995 View Post
                                2) As you said, the paths in cc are hard coded. As supplied, they are set to './' which only works if you are working in the bin99 directory. If a path is set to bin99 or the files are copied to /usr/local/bin, then it errors saying it can't find ./cpp. So, if you are in ./myproject and do a 'cc -o prog prog.c, cc will execute fine but fail on the call to each sub-process. For now, I have added a -DINSTDIR /usr/local/bin to the makefile to build cc with the path defined. It would be nice to build cc so that the tool-chain can be run from any directory it is copied to (that has a path set to it). Any ideas on the best/proper way to do this?
                                Yeah, this needs to be fixed. On linux and osx the binaries need different names (cc99, ld99, etc.), because they would otherwise shadow the normal system programs of the same name. Rather than a fixed path, I was thinking to do a relative path, i.e. cc finds as and ld in the same directory as itself (e.g. /local/bin/) and c0, c1, crt0.o, etc. in "../lib" relative to its own directory. Finding out the full path of the current process is not standardised though, so would need some #ifdef'ing for each os.
                                http://stackoverflow.com/questions/1...-proc-self-exe

                                Want to submit a patch that works with Cygwin? I'll do the patch for osx.

                                Paul

                                Comment

                                Working...
                                X