Announcement

Collapse

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

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

    There appear to be affordable 99105's on eBay right now:
    http://www.ebay.nl/itm/TI-TMS99105AJ...-/361226822289

    Comment


      Originally posted by pnr View Post
      There appear to be affordable 99105's on eBay right now:
      http://www.ebay.nl/itm/TI-TMS99105AJ...-/361226822289
      Thanks for the info, I ordered another one in anticipation of some trials later.

      For what it is worth, I wrote a small utility program intended for boot ROM builds, specifically for images larger than 32K. I haven't yet had the time to test it on actual chip, but it can be used to reproduce Stuart's cortex basic ROM (i.e. file compare returns identical results). I created a github repository for it: https://github.com/Speccery/packer99
      There probably are still many bugs in it, I literally just got it to the point where it seems to produce meaningful results.

      Next on the fun things to do is to actually modify and rebuild the ROM, with a different build ORG for the Basic to be able to page out the ROM after copying. I am also planning to put the FPGA project into github once I've cleaned it up from extra files.

      Erik

      Comment


        A little bit of progress.

        I had a little bit of time to work on the firmware. I got my own builds of Stuart's ROM working, and finally got to write a few lines of additional assembly code, so that I could build a new ROM. I was very happy to see that my code worked the first time around! The code is simple, but still there was a sense of achievement here as there were a bunch of loops and I am not yet very familiar with the TMS9900 assembly.
        In this ROM the Basic has been compiled to address range from >2000 up to >7FFF (it actually ends at >7AB0). Thus the Basic starts code starts now from a 4K page boundary.
        I wrote a little bit of code to initialize the memory paging registers, switch on paging, copying of the BASIC portion of ROM to RAM in 4K chunks i.e. page by page, and finally paging in the RAM pages to address space from >2000 to >7FFF. Only after doing this I realized that by coincidence in the ROM the addresses are exactly the same as in RAM.
        Below there is a screenshot of this working (I selected option 2 after reset), including a Basic program dumping the paging registers in the FPGA. The MSB being set on the first two page registers indicates that the Flash ROM chip is enabled there. Obviously those could be copied to RAM too.
        Screenshot 2016-04-02 23.27.57.jpg

        Comment


          Originally posted by speccy View Post
          Below there is a screenshot of this working
          Clearly I don't know how to properly attach screenshots so that they do not become miniaturized...

          Comment


            Originally posted by speccy View Post
            Clearly I don't know how to properly attach screenshots so that they do not become miniaturized...
            Yeah, I got stumped by that as well. It would seem that the forum squeezes images down to just a few KB and that makes screenshots unusable.

            Originally posted by speccy View Post
            The MSB being set on the first two page registers indicates that the Flash ROM chip is enabled there.
            That's an interesting approach. The original Cortex uses all bits for address space (up to 1MB of RAM), my mini-Cortex uses the high bit as a write-protect bit. The original Cortex uses the CKON and CKOF external instructions to en-/disable the MMU, I use a CRU bit for that. What do you use?

            Ordered an FPGA board. Indeed, it has 72 I/O's on the GPIO connectors, plus 5V, 3V3 and GND lines. I guess I could pair it up with a strip of breadboard, use a 3.6V regulator (e.g. LM7536) to power a TMS99105 from the 5V rail and hook all CPU signal lines to the FPGA. I suppose I could use the FT232 on the FPGA board to interface with a 9902. That should be enough hardware to explore stuff like the macro instructions and the co-processor interface.

            As a first step I think I should be happy to get my feet wet with VHDL and getting to operate the onboard switches and leds. Not sure I understood your earlier point about the programming cable and the SPI side channel. Would one of these be the safest choice?

            Comment


              Originally posted by pnr View Post
              That's an interesting approach. The original Cortex uses all bits for address space (up to 1MB of RAM), my mini-Cortex uses the high bit as a write-protect bit. The original Cortex uses the CKON and CKOF external instructions to en-/disable the MMU, I use a CRU bit for that. What do you use?
              Stuart sent me the schematics of the mini-Cortex, I tried to follow that in the FPGA design, I hope I got it right. There is a flagsel register in the CRU address space at address >0140. Bit at >140 controls ROM enable and at >141 enables the MMU. I am aware from the original Cortex schematics how it handles the MAP signal generation. I had a debate with myself on what should be done here, and decided to follow the implementation of mini-Cortex. The FPGA also decodes CKON and CKOF (see source link below), although the synthesis process doesn't create them as they're not used.

              I created my own firmware combo that now includes EVMBUG, BASIC and FORTH. This exceeds 32K so I needed and wanted to use the MMU to also support paging of my 256K ROM.

              By the way, does anybody happen to have extra mini-Cortex PCBs I could buy? I would like to replicate the breadboard design on something a little more stable.
              I really would like to start to design my own PCBs, (I have installed cadsoft eagle and played a little with it, but I haven't done anything real yet - it seems that you've used ExpressPCB, so maybe that's a better choice).

              For reference, I uploaded the design to github a few days ago:
              https://github.com/Speccery/fpga99
              The interesting files to look at are toplevel.vhd and fpga99-xc6slx9.ucf. The latter is the user constraints file, which maps the signals to physical pins on the FPGA. The mapping there matches my pseudo random mapping on the breadboard.


              Originally posted by pnr View Post
              Ordered an FPGA board. Indeed, it has 72 I/O's on the GPIO connectors, plus 5V, 3V3 and GND lines. I guess I could pair it up with a strip of breadboard, use a 3.6V regulator (e.g. LM7536) to power a TMS99105 from the 5V rail and hook all CPU signal lines to the FPGA. I suppose I could use the FT232 on the FPGA board to interface with a 9902. That should be enough hardware to explore stuff like the macro instructions and the co-processor interface.
              If you want to follow what seems to work well on the TMS9995, you should power the TMS99105 from the 3.6V rail too or add level shifters in order not to burn the FPGA.

              Originally posted by pnr View Post
              As a first step I think I should be happy to get my feet wet with VHDL and getting to operate the onboard switches and leds. Not sure I understood your earlier point about the programming cable and the SPI side channel. Would one of these be the safest choice?
              Looking at one of the pictures it seems the components on the programmer are the same as in my programmer (I just have a PCB, no case). Probably they are based on the same design, so that should be fine. Price is reasonable too.

              For getting your feet wet you can look at my design, at least there the signals are familiar so it should be easy to get going. I can also post another design for the same FPGA board to get you started without extra hardware. It is based on Jan Gray's XR16 CPU soft core and only uses the FPGA's onboard resources, plus the FTDI USB UART.

              Comment


                Originally posted by speccy View Post
                By the way, does anybody happen to have extra mini-Cortex PCBs I could buy? I would like to replicate the breadboard design on something a little more stable.
                Yes, I have one lying around. PM me with your e-mail and we'll sort out shipping. As discussed in this thread, the PCB needs two tracks corrected to work. More troublesome is the CF Card converter board. As far as I know the last few that were floating around have all been bought. I guess if I take down my breadboard Cortex I could part with one.

                Originally posted by speccy View Post
                I really would like to start to design my own PCBs, (I have installed cadsoft eagle and played a little with it, but I haven't done anything real yet - it seems that you've used ExpressPCB, so maybe that's a better choice).
                I found ExpressPCB very easy to work with, happy to share the files.

                Originally posted by speccy View Post
                For reference, I uploaded the design to github a few days ago
                Cool.


                Originally posted by speccy View Post
                If you want to follow what seems to work well on the TMS9995, you should power the TMS99105 from the 3.6V rail too or add level shifters in order not to burn the FPGA.
                I understand that. I meant using a low-drop voltage regulator to create a 3.6V rail from the 5V rail. Now thinking that perhaps a LT3080 with a 470K variable resistor is a better choice.

                Originally posted by speccy View Post
                Looking at one of the pictures it seems the components on the programmer are the same as in my programmer (I just have a PCB, no case). Probably they are based on the same design, so that should be fine. Price is reasonable too. For getting your feet wet you can look at my design, at least there the signals are familiar so it should be easy to get going.
                Thanks. For now I'm just gathering bits and pieces. No serious hobby time until Summer. Dave Pitts is making great strides with getting more and more old Unix software to run on the 990 and I need to catch up there too.

                Comment


                  Originally posted by pnr View Post
                  Yes, I have one lying around. PM me with your e-mail and we'll sort out shipping. As discussed in this thread, the PCB needs two tracks corrected to work. More troublesome is the CF Card converter board. As far as I know the last few that were floating around have all been bought. I guess if I take down my breadboard Cortex I could part with one.
                  Thanks a lot Paul, that is great news! Don't worry about the CF Card converter board, I just ordered from eBay a CF to IDE connector board, I'll hack my way from there.


                  Originally posted by pnr View Post
                  I found ExpressPCB very easy to work with, happy to share the files.
                  A big thank you again, perhaps this will finally get me started with my own boards. Has been on my to-do list for years if not decades already. I did with a friend an MC68000 board back a long time ago, nothing since then, but a LOT of manual wiring. For example I wired up by hand a TMS320C25 DSP board on an ISA bus protoboard a long time go. Worked fine with maximum clock speed, and landed me my first actual job in the industry - good memories but I think I've done my share of hand wiring... Although it is nice to be able to wire something up quickly.

                  Comment


                    ExpressPCB - I use it as well. It doesn't have a maximum board size like most of the other free programs seem to have. But it saves in a proprietary format so that you have to have the board made by them. Unless you buy a copy of Robot Room Copper Connection which imports ExpressPCB and exports Gerbers - it's pretty good for checking your board as well. [http://www.robotroom.com/CopperConne...CB-Files.html]

                    Once you've got Gerbers, you might want to try sitopway.com for getting the boards made. Send Gerbers, quantity etc. to sales@sitopway.com and they'll normally get back to you with a quote within 24 hours or so. They take PayPal as well which is handy.

                    Stuart.

                    Comment


                      Thank Stuart! Useful information. Paul also gave me the same tips, that is good to know.

                      I started to put some stuff into a wiki page at github for this design.
                      https://github.com/Speccery/fpga99/wiki

                      This is somewhat off-topic, my apologies, but I wanted to quickly ask if someone has some recommendations regarding setting up a blog for this type of stuff? I have a bunch of other older hardware/software projects too that might interest someone (?), so I'd like to setup Wordpress in some hosted service. I would like to be in full control of that, so I'm not looking to jumping some of the free blog services. To say it differently, by setting up an external site it would probably force some structure and be easier for me too to organize and document some of my earlier stuff...

                      Erik

                      Comment


                        Wow - the matrix has me - I was trying to post some follow up but it said it went to admin for approval...

                        I was trying to say thanks to Stuart, and to say I did write some early documentation of the FPGA stuff into a wiki at github https://github.com/Speccery/fpga99/wiki

                        Erik

                        Comment


                          Some updates from my side: I've been continuing to work on the FPGA / TMS9995 breadboard when I've had some time.
                          The FGPA now has a working SPI controller, which has enabled me to start working on TMS9900 assembly programming to write some software to be able to work with FAT filesystem, FAT16 initially. It turns out the assembly programming is a whole lot slower than working with VHDL...

                          Regarding the SPI controller, I've hooked it up to a 2GB SD card, and I've gotten to a point where the code knows how to talk to the SD card, can open a partition and list its root directory, find a specific file in there, and then go through the the file while following the FAT entries (to print it, I tested a file of about 230K bytes, seems to work well). I got that working a couple of days ago, and now my plan is to build a small shell which would enable me to load programs to memory from the FAT filesystem. That should speed up software development process, burning the flash chip again all the time makes the development process slow.

                          Initially I found working with EVMBUG somewhat non-intuitive, but I've grown to like that old piece of code. I would want to make few improvements though, such as displaying the workspace registers when hitting a breakpoint or single-stepping. Also support for lower case would be nice too. I've continued a little the disassembly process that Stuart has done, not many more pieces of code yet disassembled but some are. It would be nice to have the entire source, to be able relocate the code and freely modify it. For the FAT code it has been nice to be able to run it from RAM, and do quick patches with EVMBUG to fix bugs.

                          The SPI controller VHDL code is now on the github site (it's embedded in the other VHDL code). Just out of interest I also synthesized just the SPI portion for an Altera CPLD (EPM3064 - this is 5V tolerant and has PLCC44 package, so it could be easily added to any board), as I was thinking the SPI controller might be interesting to others. The synthesis result did not occupy the whole CPLD, so there would be space for some other stuff too. In the FPGA implementation the SPI port runs currently at 6.25MHz, which pretty much means that it always transfers a byte of data before the CPU has time to access it again. It would be easy to run it even faster, or slower for that matter.

                          Another thing I really would want to improve is to add support for interrupts from the UART within the firmware. I think I read from somewhere that the TMS9902 can create spurious interrupts, so I am wondering if you guys have some experience with it? It would be nice to have a proper receive buffer, to stop losing characters. An alternative is to put another UART into the FPGA itself, I've used a design which has a 8 or 16 byte hardware receive FIFO. It could be interesting to implement a TMS9902 register compatible UART in the FPGA. Another option would be to setup the built-in timer of the TMS9995 and poll the UART from a timer interrupt routine.

                          Erik

                          Comment


                            Originally posted by speccy View Post
                            Some updates from my side: I've been continuing to work on the FPGA / TMS9995 breadboard when I've had some time.
                            The FGPA now has a working SPI controller, which has enabled me to start working on TMS9900 assembly programming to write some software to be able to work with FAT filesystem, FAT16 initially.
                            That is great progress!

                            Originally posted by speccy View Post
                            Regarding the SPI controller, I've hooked it up to a 2GB SD card, and I've gotten to a point where the code knows how to talk to the SD card, can open a partition and list its root directory, find a specific file in there, and then go through the the file while following the FAT entries (to print it, I tested a file of about 230K bytes, seems to work well).
                            2GB/FAT16 would seem to be a good choice. Note that according to the SD spec larger cards must use FAT32. One issue I had with CF cards is that some are formatted with a Volume Boot Record (= a partition table) in the first sector, and others start with a Partition Boot Record (= the PBP etc.). Does that happen with SD cards as well? (flash USB disks seem to be the same as CF cards). I've only found one vague reference on how to tell the two forms apart: apparently old IBM boot roms would look at the first nine bytes and if all are zero it is a Volume Boot Record.

                            Originally posted by speccy View Post
                            I got that working a couple of days ago, and now my plan is to build a small shell which would enable me to load programs to memory from the FAT filesystem. That should speed up software development process, burning the flash chip again all the time makes the development process slow.
                            Yes. My own plan was that the flash chip would have code that looked at /boot on the card and would build a boot menu from the items found there. It would then load and run the selected item. However, I have no working code for that and ideas are a dime a dozen.

                            Originally posted by speccy View Post
                            Initially I found working with EVMBUG somewhat non-intuitive, but I've grown to like that old piece of code. I would want to make few improvements though, such as displaying the workspace registers when hitting a breakpoint or single-stepping. Also support for lower case would be nice too. I've continued a little the disassembly process that Stuart has done, not many more pieces of code yet disassembled but some are. It would be nice to have the entire source, to be able relocate the code and freely modify it. For the FAT code it has been nice to be able to run it from RAM, and do quick patches with EVMBUG to fix bugs.
                            Having line editing and even better a simple history feature would be great as well. Have you seen this document from Stuart:
                            ftp://bitsavers.informatik.uni-stutt...1_TIBUGlst.pdf
                            It is not EVMBUG, but the code is closely related to it.

                            Originally posted by speccy View Post
                            Another thing I really would want to improve is to add support for interrupts from the UART within the firmware. I think I read from somewhere that the TMS9902 can create spurious interrupts, so I am wondering if you guys have some experience with it? It would be nice to have a proper receive buffer, to stop losing characters.
                            Not sure I have noticed this. The 9902 has multiple interrupt sources and the service routine must check the status register to find out which source(s) triggered the current interrupt. I think it is hard to overrun EVMBUG, but easy to overrun Cortex Basic. I have solved that by adding a small character delay when sending Cortex Basic source code to the breadboard.

                            Paul

                            Comment


                              Originally posted by pnr View Post
                              That is great progress!
                              Thanks Paul!

                              Originally posted by pnr View Post
                              2GB/FAT16 would seem to be a good choice. Note that according to the SD spec larger cards must use FAT32. One issue I had with CF cards is that some are formatted with a Volume Boot Record (= a partition table) in the first sector, and others start with a Partition Boot Record (= the PBP etc.). Does that happen with SD cards as well? (flash USB disks seem to be the same as CF cards). I've only found one vague reference on how to tell the two forms apart: apparently old IBM boot roms would look at the first nine bytes and if all are zero it is a Volume Boot Record.
                              The card I am currently using does have a normal MBR, my code just goes through the 4 entries looking for a FAT16 partition and goes there. From sources in the net it seems some SD cards do not have normal formatting, they just start off with the boot sector. I suppose that could be detected by looking for a x86 jump instruction in the beginning of the sector. I'm also planning to add support for FAT32, it seems there are only a few changes necessary to minimally support FAT32. SDHC support would also be needed there. I have to investigate more, but it seems SDHC only requires the code to treat 32-bit addresses as sector numbers instead of sector aligned absolute addresses on the card - my code already does this, it just upshifts the sector numbers by 9 before issuing that to the card.

                              Originally posted by pnr View Post
                              Yes. My own plan was that the flash chip would have code that looked at /boot on the card and would build a boot menu from the items found there. It would then load and run the selected item. However, I have no working code for that and ideas are a dime a dozen.
                              That is a nice idea!

                              Originally posted by pnr View Post
                              Having line editing and even better a simple history feature would be great as well.
                              Thinking about command history is how I discovered the character loosing issue: as an example, pressing the up key sends 3 characters (ESC [ A). The middle one is lost while the test code snippet was HEX printing the first one. EVMBUG primarily looses characters when it is printing stuff in a busy loop. Actually a simple way to fix this would be to have the XOP 12 also check for incoming characters and buffer them for later, that would work without interrupts.

                              Originally posted by pnr View Post
                              Have you seen this document from Stuart:
                              ftp://bitsavers.informatik.uni-stutt...1_TIBUGlst.pdf
                              It is not EVMBUG, but the code is closely related to it.
                              No I haven't, thanks!

                              Originally posted by pnr View Post
                              Not sure I have noticed this. The 9902 has multiple interrupt sources and the service routine must check the status register to find out which source(s) triggered the current interrupt. I think it is hard to overrun EVMBUG, but easy to overrun Cortex Basic. I have solved that by adding a small character delay when sending Cortex Basic source code to the breadboard.
                              I was initially testing the SPI controller with FORTH, editing on my Mac or PC and copying the code over. Really long line delays were necessary in order not to loose characters. Thinking this a bit more, a receive buffer would not help (unless it was very large) since at least FORTH not only echoes back the characters but also prints "ok"s at the end of each line, so in addition to processing delay it adds more stuff to send to the host. I was also thinking about making an XMODEM receiver to solve that, but I suppose when it can boot from the SD card, things are solved.

                              I was also thinking for debugging purposes to create a modified simulator, that would run on the host but pass all I/O commands (CRU and memory mapped I/O) over the serial line to the actual hardware for execution. Would be nice for filesystem code debugging.

                              Erik

                              Comment


                                Paul,
                                I was able to pick up the mini cortex PCB from the post office today. Thank you very much for sending it!

                                Erik
                                IMG_4632.jpg

                                Comment

                                Working...
                                X