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

    Originally posted by tms9995 View Post
    I have the original WINDOW code somewhere. As you say, it was setup to work with a VT100. I will try to dig it out...
    I think that disk may already be in the disk image set on your Cortex site. Isn't it "MDEX Window Screen Editor Release.dsk"?

    Paul

    Comment


      Many thanks, I've got the schematic.
      I use these cables at work at lot http://uk.farnell.com/ftdi/ttl-232r-...ire/dp/1740364
      But on my project I was going to add the MAX232 (or modern equivalent) to convert to true RS232 and then you can either connect to an existing serial port or a easily obtainable RS232 to USB cable.
      This gives you the option of using the serial port with old hardware (terminal, serial printer, serial mouse etc) as well as a PC interface.

      Jim

      Comment


        Originally posted by pnr View Post
        I think that disk may already be in the disk image set on your Cortex site. Isn't it "MDEX Window Screen Editor Release.dsk"?

        Paul
        Yep, looks like it's all there. Some nice person even wrote a README to describe how to build it for different terminals

        Dave.

        Comment


          Anyone know if the MPE Cortex version of MDEX that we have access to uses any 9995-specific instructions or features? Should it run on a 9900 (the docs say it should run on 99xx(x), but not sure how literally to take that)? What does it need in terms of minimum hardware? RAM from >0000 upwards? Serial port at CRU >0080? Disk system?

          Stuart.

          Comment


            The Marinchip version it is derived from was intended to run on a TMS9900, Stuart, so unless MPE made some internal changes that incorporated some 9995-specific code, I'd say that it should still run on a vanilla 9900 system.
            Enter My Mind At Your Own Risk!

            Comment


              Originally posted by Stuart View Post
              What does it need in terms of minimum hardware? RAM from >0000 upwards? Serial port at CRU >0080? Disk system?
              RAM Yes, it needs RAM from >0000 upwards. Not sure how much it needs, I think at least 32KB. The first >100 bytes contain int/xop vectors and a jump table.
              Programs normally load at base address >100, and for the existing software packages I didn't see an easy way to change that. The MDEX kernel is about 7KB plus the size of the drivers, my build is just shy of 9KB including drivers. It is configured to load at >C000, this is a system generation parameter.

              Serial Serial is really defined by the console terminal driver, it need not be a UART (and the Cortex driver is an example of that). If you use a 9902 chip it need not be at >0080: the CRU location is a parameter in the driver. In my build it is indeed at >0080.

              Disk Yes, MDEX is really built around the concept of a disk. This too is only defined in terms of an interface to a driver: any device that can pretend to be a disk with 128 byte sectors will work.

              Printer MDEX also assumes the existence of a printer, but does not require it to actually work. Out of laziness I have linked in a Centronics driver, which will surely hang if I would try to access the printer. The more elegant solution would be to use a "null" driver that simply discards any data sent to it.

              Comment


                CF Card interface

                I'm experiencing a strange instability when accessing the CF Card.

                When reading a sector occasionally a byte is missed from the sequence. It is not entirely reproducible, but also not entirely random: I cannot recall that this has happened during the initial boot load and when manually testing sector reads with the "DU" disk utility some sectors always read okay, other sectors miss a byte once every 7 tries or so. During manual testing it is always the first byte that is skipped, but the "FDIAG" utility also reports a byte missing further in a sector on some runs.

                My hypothesis is that I have some sort of noise or timing issue, causing the CF Card data counter to occasionally advance in error. I have an old 2 channel scope, but no logic analyzer. Haven't wheeled out the scope yet.

                Any suggestions for setting up test cases to narrow down what might be causing this? All input welcome.

                Paul

                Comment


                  Earlier you posted a link to <http://searle.hostei.com/grant/cpm/>. Did you see the section "IMPORTANT CONSTRUCTION NOTES" about a 1/4 of the way down the page? Copied below. I know that with the TI-99/4A C/F adaptor device, some CF cards work and some don't. Have you tried different cards - in particular an older, lower capacity card?

                  COMPACT FLASH
                  1. For reliable operation, the leads to the CF card must be short.
                  2. Some cards are more sensitive to noise on the lines. FujiFilm cards work very well, SanDisk cards work but need short wires. To get one card working I needed to connect a very small capacitor (15-22pF) between the address lines and Gnd. Ferrite beads on the lines also help.
                  3. If the results are intermittent, ensure you follow the above guidelines.
                  4. The CF specification says that the logic levels should be "CMOS" values. However, from ALL cards that I have tried, although this is specified, the TTL levels work perfectly. If in doubt, you could replace the Z80 with a CMOS device and replace the 74LS138 with a 74HCT138 and replace the 74LS32 with 74HCT32. This way, all lines to the CF will be CMOS levels. However, this should not be necessary.
                  5. Cards larger than 128MB can be used (use the 128MB BIOS and formatter) but only the first 128MB will be recognised by CP/M - this should be more than ample, though. Avoid new high speed cards as these are very sensitive to noise (due to the high speed) and will require short leads.
                  6. Route leads as directly to the Z80 and to U5 and U8 as possible. On my picture, the address lines were taken from the end of a chain of connections which works perfectly for my FujiFilm cards. However, the SanDisk card was not reliable with this, but worked perfectly when I took the address lines straight to the Z80 CPU.

                  Comment


                    Originally posted by pnr View Post
                    I'm experiencing a strange instability when accessing the CF Card.

                    When reading a sector occasionally a byte is missed from the sequence. It is not entirely reproducible, but also not entirely random: I cannot recall that this has happened during the initial boot load and when manually testing sector reads with the "DU" disk utility some sectors always read okay, other sectors miss a byte once every 7 tries or so. During manual testing it is always the first byte that is skipped, but the "FDIAG" utility also reports a byte missing further in a sector on some runs.

                    My hypothesis is that I have some sort of noise or timing issue, causing the CF Card data counter to occasionally advance in error. I have an old 2 channel scope, but no logic analyzer. Haven't wheeled out the scope yet.

                    Any suggestions for setting up test cases to narrow down what might be causing this? All input welcome.

                    Paul

                    Hi Paul,

                    The MPE FD/WD E-Bus card is used to connect to the Western Digital WD1002 hard and floppy drive interface board, this in turn connects to MFM hard drives.
                    The interface to the WD1002 board is essentially what developed into IDE when miniaturised WD1002 electronics were incorporated onto the drive itself.
                    It's a different pinout but pretty much the same signals.
                    And of course the CF interface is just IDE on a different connector.
                    On the MPE card the pcb has been hacked to included a delay on both the _WE and _RE (_DBIN) signals.
                    You can see it on the schematics in the manual which is on my web site.
                    http://www.quantums.info/cortex/MPE%...schematics.pdf
                    I assume the _WE and _RE were becoming active too soon without the delay.

                    Just a thought.

                    Jim
                    Last edited by Jim Hearne; June 12, 2014, 12:04 AM.

                    Comment


                      Originally posted by Jim Hearne View Post
                      I assume the _WE and _RE were becoming active too soon without the delay.
                      That sounds familiar. On the IDE card for my TM990 system, the /READ signal to the interface is delayed through three OR gates to "give a falling edge on /READ after /CS0 becomes active". l would have seen the need for that before somewhere (probably a Z80 CF interface) as I wouldn't have done it myself.

                      Stuart.

                      Comment


                        I read up on the WD1002 and it is amazing how little has changed in 30 years. Thanks for that insight.

                        It could well be DBIN/OE timing. The CF card spec says that the address lines should be stable 40ns before the negative flank of OE. If I read the 9995 data sheet correctly, at 3 MHz DBIN has its negative transition worst case ~40ns after addresses stabilize, although ~80ns is more likely. In IDE mode addresses should be stable 70ns before the negative flank of IORD. I would not be surprised if many CF cards use IDE mode timing for memory mode as well.

                        When I have a chance I'll experiment with delaying DBIN to OE by 20..30ns and see if it makes a difference.

                        Comment


                          Originally posted by pnr View Post
                          When I have a chance I'll experiment with delaying DBIN to OE by 20..30ns and see if it makes a difference.
                          It only made things worse. However, I did finally notice that the missing byte was always an >FF byte and that made me think that power or grounding might be iffy. Indeed, routing a direct link from CPU ground to CF card ground made the problem go away.

                          Comment


                            Anyone interested in a TMS99110 for $20 plus postage, from a Chinese vendor, if we can get some sort of money-back guarantee that they work? There are some available apparently.

                            Stuart.

                            Comment


                              I would, but I do not have the technical ability to do anything with it.

                              Comment


                                I'd be interested in a few of them, Stuart. I'm hoping that I can get my hands on the plans used to build an accelerated TI-99/4A that used a 99110. . .so having a couple of them for the experimentation would be very useful.
                                Enter My Mind At Your Own Risk!

                                Comment

                                Working...
                                X