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

    Lez - the TMS9909 FDC you're including in some of the eBay kits. A couple of us have bought these before from Chinese suppliers and they haven't worked. Have you got a spare you can pop in the post to me and I'll try it?



      Originally posted by Stuart View Post
      Lez - the TMS9909 FDC you're including in some of the eBay kits. A couple of us have bought these before from Chinese suppliers and they haven't worked. Have you got a spare you can pop in the post to me and I'll try it?

      Sadly I have no stock of TMS99xx ICs left, they weren't exactly good sellers, I think I only sold three ! I purposefully overpriced then to encourage people to buy direct.. not sure whether that worked or not ??

      As far as the TMS9909 FDC.. your best option maybe is to try to salvage some from old Ti PCBs ?? Or take the risk from as you do get your money back if they're DUFF.. But the three weeks it takes for stuff to arrive from China is a pain !

      I was quoted $8.50 each for the TMS2797 FDC as I recall


        Looking for Ti TMS99xx ICs or Legacy ICs in general ??

        If your hunting for TMS99xx ICs or any legacy type IC let me know and I'll see If I can find a cheap source ! Can't guarantee to find every IC but I'll do my best to find a inexpensive supplier.


          Originally posted by daveSCMP View Post
          The source is uncommented as yet, I did it as I was curious how CDOS was loaded and linked into Cortex OS. There are 3 files for each version of FDC. The boot sector gets loaded to >6100, which then loads file SYSTEM$ above it at >6900. Links are then made into CDOS. The FORMAT code is loaded and called as required.

          I don't have any Cortex hardware, just used the excellent emulator. Though there is one small point to note. the emulator disks for TMS9909 all have their boot sector 16 word header block skewed by one byte (TMS2797 are correct).
          Thank you for posting. Doing the disassembly and figuring out what is code and what is data is already a big step! Perhaps with the help of some old timers we can recreate a documented source for CDOS over the coming months. As a start I have skimmed through the usergroup news letters and from that (in particular issue 6 and 9), and the file "boot.asm" of the Cortex Basic source I gather the following:

          Every CDOS disk is bootable. The first track on the first side holds the CDOS core. That binary is preceded by a header in the following format:

          *      Track 0  Sector 1  Data Format
          *                         -----------
          *             0     2     4     6     8     A     C     E
          *          +-----+-----+-----+-----+-----+-----+-----+-----+
          *   00     | WP  | PC  |-----|-----|-----|-----|-----|-----|
          *          +-----+-----+-----+-----+-----+-----+-----+-----+
          *   10     |-----|-----| LN  | SA  |-----|-----|-----| CS  |
          *          +-----+-----+-----+-----+-----+-----+-----+-----+
          *      WP = Entry WP
          *      PC = Entry PC
          *      LN = Two times number of bytes to transfer
          *      SA = Load address for absolute code program
          *      CS = Checksum on words hex00 to hex1C inclusive
          The Cortex Basic BOOT code to me seems faulty, in that it reads one one sector to few for LN/2 bytes. Perhaps this is why LN is set to 0 and all sectors of track 0 are read -- I'm not sure, the data sheet is silent on what happens upon issuing a "read zero sectors" command. Once that track is loaded at address SA (0x6900), the BOOT routine does a BLWP through the vector at the head of the header.

          The next track holds the directory. The first sector on that track is a bitmap of used sectors, the remaining 15 sectors on that track are the directory entries.

          The first 32 bits of the bitmap are always 1, to reflect that the 16 sectors on track 0 and 1 are in use by the system. The bitmap is a bit puzzling, in that I don't understand how it can work with 80 track disks. On a single density disk (128 bytes / sector) there are 1024 bits in the map and 80 tracks * 16 sectors per track makes 1280 (and double sided disks have 2560 sectors). I guess single density disks are limited to 256KB and double density drives limited to 512KB. Will need to check the code to verify this.

          In the remaining 15 sectors of track 1 are directory entries that are each 64 bytes long, i.e. a maximum of 30 files on a single density disk, and a maximum of 60 files on a double density disk.

          Each directory entry is as follows:

          Offset    Contains
          0000      flag word
          0002      8 bytes with file name (zero padded if <8 bytes long)
          000a      5 words with file header
          0014      6 words, unused
          0020      16 words with file segments
          The flag word is either:

          Value    Meaning
          0000     directory slot is empty
          5a5a     executable file, no auto-run
          a5a5     executable file, auto run
          ffff     sequential data file
          xxxx     any other value is record size of random access file
          The file header format depends on the type of file. Offsets are from the start of the directory entry.

          Binary code file:

          Offset   Contains
          000a     always zero
          000c     load address
          000e     entry address
          0010     length in bytes
          0012     ? (checksum?)
          Basic code file:

          Offset   Contains
          000a     pointer
          000c     pointer
          000e     pointer
          0010     length in bytes
          0012     ? (checksum?)
          Sequential & random access data file:

          Offset   Contains
          000a     ?
          000c     ?
          000e     ?
          0010     ?
          0012     length in bytes
          The file segments consists of 8 segments, each described by two words. The first word is the starting sector number, the second is the number of (sequential) sectors in the segment. The starting sector number uses an LBA scheme, i.e. the first sector on track 2 is sector 32 and so forth.

          The remainder of the disk contains the data of the files.

          Hope this helps making a start with further documenting CDOS.


            Does anyone have a 'through listing' of the Cortex ROM? (I mean a listing showing the actual addresses, not a listing showing pre-linking addresses). Tried to make one by putting everything in one large asm file (taking out the END's and duplicated COPY's), but that seems to crash asm990.


              I've got an 'assembler output listing' if that is any good - so has a column showing the resolved addresses, like:

               463  0000 00B6 CLKI   EQU  $
               464  00B6 020C        LI   R12,>1EE0         REF ONCHIP DECREMENTER
               464  00B8 1EE0  
               465  00BA 1D01        SBO  1                 RE-ENABLE CLOCK INTERRUPT
               466  00BC 0620        DEC  @CNTDWN           COUNTDOWN
               466  00BE ED38' 
               467  00C0 C320        MOV  @BELCNT,R12       GET BELL COUNTER
               467  00C2 ED42' 
               468  00C4 091C        SRL  R12,1             COUNT
               469  00C6 C80C        MOV  R12,@BELCNT       RESTORE IT
               469  00C8 ED42'
              Is that any use?


                Originally posted by Stuart View Post
                Is that any use?
                Not sure.. If I want to quickly find what code or data is residing at for example address >3FFE, will that listing allow me to find the source for that address quickly?


                  Yep. Address >3FFE contains >20F6, and is a pointer to the code for the ENTER statement. Let me know if you want a copy - I'll have to e-mail it as it's too big to upload as an attachment.

                  1814  3ffa 2c9e'       data rany              random        18
                  1815  3ffc 0164'       data baud              baud          19
                  1816  3ffe 20f6'       data entery            enter         1a
                  1817  4000 5142'       data ploty             plot          1b
                  1818  4002 513e'       data uploty            unplot        1c
                  1819  4004 1ad8'       data colory            colour        1d


                    Originally posted by Stuart View Post
                    Let me know if you want a copy - I'll have to e-mail it as it's too big to upload as an attachment.
                    Yes please, that would be very helpful. Arguably it is a lot more useful than the scan of the original listing that is on the website now and weighs in at some 135MB.



                      With the help of Stuart's listing, I annotated the daveSCMP source for the CDOS 2.00 core (i.e. the tms2797 file). It would seem that in later versions (perhaps from 1.20 on) the disk layout was changed to be able to deal with 80 track floppies. The layout info I posted earlier seems to be for CDOS 1.10.

                      I am not sure I fully understand the CDOS 2.00 code around the disk allocation bitmap. This bitmap is loaded in a buffer that overwrites the Cortex Basic initialisation code. However, for double sided disks it would seem to overwrite part of the error messages as well.

                      Perhaps somebody else can take these annotations to a higher level, or have a go at SYSTEM$.
                      Attached Files


                        Originally posted by pnr View Post
                        I am not sure I fully understand the CDOS 2.00 code around the disk allocation bitmap. This bitmap is loaded in a buffer that overwrites the Cortex Basic initialisation code. However, for double sided disks it would seem to overwrite part of the error messages as well.
                        If you take a look at text.asm and error.asm, the area used by the start-up code and error messages is actually used as a scratch buffer once the system is up and running. When processing an error, the EPROMs are temporarily re-enabled and the appropriate error message is retrieved. Clever stuff.



                          Originally posted by tms9995 View Post
                          Clever stuff.
                          Hmmm..... A clever hack or a silly kludge?

                          Whatever it is, it complicates my plan for a Cortex Basic that resides as an image file on the CF card and gets loaded by a boot loader in ROM.

                          One possible solution could be to use the mapper and allocate 24K of RAM to be a soft copy of the ROM. This soft copy gets loaded from the CF card and is further used as the backup copy of the code. Cortex Basic would require some slight modification to the code in 'error.asm'. This would be on top of the tweaking that is needed in any case (different base address of the VDP and the mapper, default to unit #3, etc.)

                          As far as anybody is aware, are there any other 'specials' in Cortex Basic that would complicate that plan?


                            A clever hack for the original design and hardware I think. I believe it also switches the ROMs back on when you use the command that resets the character set - copies the original character data from the ROMs again.

                            For the ports of Cortex Basic that I've done, I removed the code that switches the ROMs back on. I don't run any software that overwrites the error messages, and I've put in two copies of the character set - one a 'working' copy plus a 'master' that gets copied over the working copy when you reset the characters. Loose a bit of memory, but not worried.


                              The Mini Cortex PCB has arrived (picture). Now I need to find the time to actually build and test it


                                Originally posted by pnr View Post
                                The Mini Cortex PCB has arrived (picture). Now I need to find the time to actually build and test it
                                Found the time to build it. It appears to work, except for the mapper. Need to do further testing, and probably will have to make a "revision 2" PCB.