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

    Originally posted by Stuart View Post
    I've got Cortex BASIC load/save to a CF on my TM990, so that should be easy to port across if you want it. I've got a basic disk OS that supports load/save/dir/format using a similar disk format to the TI-99/4A floppies, then I've added *extended commands to Cortex BASIC to load/save programs by making calls into the disk OS.
    That sounds promising, but I'm confused. If I understand correctly, after reset Cortex Basic only has a BOOT command that can read a boot loader from track 0 of a floppy. In the case of CDOS its core loads itself into memory between 0x6000 and 0x8000 and it patches Cortex Basic to have new LOAD and SAVE commands; it looks for a file SYSTEM$ on disk and loads this somewhere. SYSTEM$ patches Cortex Basic with OPEN/CLOSE/GET/PUT commands. I have not found sources for CDOS.

    It sounds like you have done your own CFCard DOS using raw access (i.e. not building on top of FAT); how does it load itself, or is it simply in ROM? Also sounds like this DOS does not patch Cortex Basic at all. How do the *extended commands work, the documentation is silent on that, other than that it seems to require the memory mapper and extended memory (could not find the relevant routine in the source listing, at least not at first glance). At least, I think the breadboard would need some way to page out the ROM even just for space reasons alone.

    I'n not sure I will do any porting, but I would be really grateful if you could elaborate a bit.

    Comment


      So my TM990 boots to the TIBUG monitor, which is an earlier version of EVMBUG used on the breadboard. I then have a DOS which sits in write-protected battery-backed RAM - but could equally be in (EP)ROM. The DOS has a simple command line interface like EVMBUG. To save a (machine code) program it prompts for save start address, save end address then file name and optional file description. To load a (machine code) program it prompts for load address then file name. Cortex BASIC I've previously downloaded then saved the memory image to CF, and I can load it again as needed to run from RAM.

      The *extended command handler on the Cortex steps through extended memory (so needs the memory mapper as you say) looking for a header block for the extended command. But I've modified the copy for my TM990 so the header blocks for the load/save/dir/delete commands are in the code. Saving a file in BASIC calculates the save start and end addresses needed, then passes these to the DOS which then prompts for the file name, saves the block of memory, then returns to BASIC. Load works in a similar way. So BASIC isn't 'patched' as such by loading a DOS, I've just modified the BASIC source code to work with the DOS already available. The DOS is 3870 bytes and needs ~1.5K RAM for buffers and so on.

      DOS commands are:
      -- Read/display the CF identity information
      -- Show CF interface status
      -- Spin down/spin up - for the simple pleasure of being able spin a hard drive down and back up
      -- show sector data in hex
      -- fill a sector
      -- save memory block
      -- load memory block
      -- load memory block and execute from specified address
      -- display directory
      -- rename file
      -- edit description saved with each file
      -- delete file
      -- format disk
      -- rename disk

      Comment


        Stuart, thank you for that explanation, much clearer now. I think I will pass on porting that. My motivation was to take the breadboard experience closer to the cortex experience for casual builders of the breadboard (all five of them ) and that would not be achieved. Moreover, I would have to get into the Cortex basic source, the file format and the source of your OS, and that is perhaps a bit much for now. Still, I very much appreciate your explanation.

        Perhaps I should look at MDEX for an easier way to achieve something similar. I had a look at system generation, and at first glance it would seem to be not all that hard. The disk driver has only three api calls (init, read, write) and the terminal driver seems to have the 9902 code intact as the secondary device. The on disk format of the file system seems to be dead simple (see newsletter #21). I would appreciate any and all suggestions from the MDEX experts.

        Is there already an open source PC tool to create MDEX file systems and add files to it?

        Paul

        Comment


          Originally posted by pnr View Post
          and the terminal driver seems to have the 9902 code intact as the secondary device.
          Attached a first draft of the ported terminal driver.
          Attached Files

          Comment


            Originally posted by pnr View Post
            Perhaps I should look at MDEX for an easier way to achieve something similar. I had a look at system generation, and at first glance it would seem to be not all that hard. The disk driver has only three api calls (init, read, write) and the terminal driver seems to have the 9902 code intact as the secondary device. The on disk format of the file system seems to be dead simple (see newsletter #21). I would appreciate any and all suggestions from the MDEX experts.

            Is there already an open source PC tool to create MDEX file systems and add files to it?

            Paul
            Hi Paul,

            I still haven't tested the cc99/Cortex mods you did for me. Sorry! (It's on the list).

            I'm pretty familiar with MDEX, so any help you need please ask. You have probably already read it, but I did a README on the "MDEXx0 Sysgen Release.dsk" that concisely (I hope) explains the Sysgen process. If not, I'd be happy to try and clarify things for you.

            The MDEX Disk Utility I wrote is useful for extracting MDEX files from a disk image but I didn't create anything to put things back in the other direction. You can have to source if it would save you the time of developing your own algorithms (the interlacing with double density disks takes a little figuring out).

            Dave.

            Comment


              Thanks for the offer of help. I would appreciate the source to the mdex disk extraction routines, to add create and write capabilities. Also would appreciate review of the draft driver(s).

              Four questions on my mind today:
              - the mdex core seems to have 8" metrics hard coded (single sided, 26 sectors, 77 tracks, 128 bytes per sector), but also seems to accept disks with >77 (virtual) tracks. How does it know the disk capacity? Can I create a 1MB virtual disk and will that work? Or am I limited to 640KB?
              - the init routines store pointers to the device data block in locations >00fe, >00fc and >00fa for the console, fd0 and fd1 respectively. What is the significance of that, how does the mdex core use those pointers?
              - what is the meaning of the the console 'flashit' API routine? It flashes a Cortex led, but when is that used? What does this API do on an M9900 Marinchip system?
              - the console has an API consisting of 6 function calls, the disk has a single API called with 3 function codes. Just inconsistent design or any signficance to that?

              My current line of thinking is to map fd0 and fd1 to two (unfragmented) files on the cf card FAT file system, of say 1MB each. fd0 could then hold all available mdex binaries and fd1 would be a work disk. Probably doing a simple linear map of sectors is the easiest.

              For the initial system generation I would use your Cortex emulator. Once I have a new kernel generated, it should be able to self host. It will be interesting to compare LSX Unix and MDEX, as both are about the same size kernel (~12KB) and roughly contemporaneous ('76 versus '78 ).

              Thanks in advance for any suggestions.

              Paul

              EDIT:
              I can partially answer my own questions. I've looked at the mdex.rel file and at its REF/DEF's:
              Code:
              	REF	CRTCON		config
              	REF	DBGROM		config
              	REF	DIRSEC		config
              	REF	DIRTRA		config
              	REF	DSKSIZ		config
              	REF	STDWS		config
              	REF	SYSVER		config
              	REF	TCRDLY		config
              
              	REF	TREADC		term dev
              	REF	TRESET		term dev
              	REF	TRSTAT		term dev
              	REF	TWRITE		term dev
              	REF	TWSTAT		term dev
              
              	REF	PIOPSF		disk dev
              	REF	UT$FD1		disk dev
              	REF	UT$FD2		disk dev
              	REF	DSK$DF		disk dev
              
              	REF	PIOPRT		print dev
              	REF	UT$PR1		print dev
              
              	DEF	INTCHK
              The first 8 REF's are DEF'ined in the config.asm file, the others in the various device drivers. Findings:
              1. The 'flashit' routine does not get REF'ed, so it is not used by mdex -- probably just something that MPE needed during development. We can forget about it.
              2. The DSKSIZ config parameter specifies the number of sectors (26*77 in the original, 16*80 for the Cortex). Probably can be set much higher.
              3. The device data blocks UT$FD1 and UT$FD2 also contain a sector/track count; probably should be set matching DSKSIZ
              Last edited by pnr; May 25, 2014, 01:22 PM.

              Comment


                Hi Paul,

                I was in the process of answering your questions when I noticed you'd beat me to it!

                flashit just flashes the front panel LED when MDEX has finished loading. As you say, probably something MPE did to know it was running whilst they were developing the TMS9929 drivers etc.

                The table of pointers to the device drivers was something MPE did to allow us to modify simple things without the use of the System Generation Kit, which was 495 British Pounds (no idea how I get up the proper symbol as I type this!). It just enabled us to locate the tables easily.

                As you discovered, the disk capacity is defined in config.asm. I have no idea how high you can take it....

                Dave.

                Comment


                  Originally posted by pnr View Post

                  - what is the meaning of the the console 'flashit' API routine? It flashes a Cortex led, but when is that used? What does this API do on an M9900 Marinchip system?

                  1. The 'flashit' routine does not get REF'ed, so it is not used by mdex -- probably just something that MPE needed during development. We can forget about it.
                  Interesting! I always thought the flashit* routine got called once at the end of the MDEX boot. But, you're right - it's not part of MDEX. So I did a little digging and it's actually part of the MDEX Loader. It can be found on "MDEX Boot Loader Source Release.dsk".

                  Comment


                    Originally posted by pnr View Post
                    Thanks for the offer of help. I would appreciate the source to the mdex disk extraction routines, to add create and write capabilities. Also would appreciate review of the draft driver(s).

                    Attached is the main chunk of code for the MDEX Disk Utility. The BlockToOffset function is what converts MDEX Block Number to a linear disk address.

                    Dave.
                    Attached Files

                    Comment


                      Originally posted by tms9995 View Post
                      Attached is the main chunk of code for the MDEX Disk Utility
                      Thanks a zillion. Attached a reworked command line version that can create/add/remove/list/etc. disk images. There are two create options, -c and -f. The former creates a standard 640KB Cortex mdex disk image, the latter creates an image to place on a CF Card. I've chosen to use a mimic of DSDD 8" drive, this gives a capacity of about a megabyte. To keep things simple, each logical 128 byte mdex sector maps one-to-one to the first 128 bytes of a 512 byte CF Card sector. This wastes 75%, but simplifies the driver enormously (and even at 4MB, it is only 0.1% of a 4GB CF card).

                      To get a listing of an image use the -l option:
                      Code:
                      $> mdexdsk -l imagefile.dsk
                      To add a file to the image, use the -a option:
                      Code:
                      $> mdexdsk -a imagefile.dsk driver.asm
                      I've used this tool to transfer the new terminal driver to a sysgen disk and using the Cortex emulator it seems to assemble (there is a mysterious relocation error during assembly, but output code is still generated) and link. Now on to the CF card driver and extending the breadboard with a way to map out the rom.

                      Any and all help is welcome.

                      Paul
                      Attached Files

                      Comment


                        Dave,

                        Working on the CF Card disk driver. Am I correct in assuming that the mdex kernel only uses the first part of the device data block (dtmstr to dtsize and that the rest (dtdeva to dtrvrtry) is private to the driver? I.e. I need to keep the first bit intact as is, and I can discard the second half? Or is it different in either direction (1. mdex treats pointer as opaque ID and never looks at the data structure at all; 2. mdex needs the whole structure as-is)?

                        Paul

                        Comment


                          Originally posted by pnr View Post
                          Dave,

                          Working on the CF Card disk driver. Am I correct in assuming that the mdex kernel only uses the first part of the device data block (dtmstr to dtsize and that the rest (dtdeva to dtrvrtry) is private to the driver? I.e. I need to keep the first bit intact as is, and I can discard the second half? Or is it different in either direction (1. mdex treats pointer as opaque ID and never looks at the data structure at all; 2. mdex needs the whole structure as-is)?

                          Paul
                          Hi Paul,

                          I have to confess I'm not really sure. Looking at the driver source and memory dumps of MDEX using debug, unit table ut$fd1 runs from dtmstr to dtrvrtrv + 16 bytes and ut$fd2 runs from dtmstr to dtsize8 + 16 bytes. They are obviously declared as global but I'm not sure of how much of these tables are actually used by the kernel. But, I suspect you know all this...

                          I suppose I could run a modified version of the emulator and put traps in to see if/when these areas of memory are accessed?

                          Dave.

                          Comment


                            Originally posted by tms9995 View Post
                            I suppose I could run a modified version of the emulator and put traps in to see if/when these areas of memory are accessed?

                            Dave.
                            Or add "stop on memory 0xXXXX access" as a debugging feature for the standard emulator?

                            Comment


                              Originally posted by Stuart View Post
                              Or add "stop on memory 0xXXXX access" as a debugging feature for the standard emulator?
                              It's a good idea. I'll have a think about it. Single address or range with Read/Write qualifiers and the same for the CRU. Sounds good?

                              Comment


                                Sounds good. What you might want to do is have a look at the breakpoint options available in the Classic99 TI-99/4A emulator (http://www.harmlesslion.com/zips/classic99.zip, then page 26 of the manual PDF file).

                                Comment

                                Working...
                                X